Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Cette version de GitHub Enterprise a été abandonnée le 2023-03-15. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

À propos des nœuds de cluster

Les nœuds sont des instances de GitHub Enterprise Server qui fonctionnent dans un cluster. Chaque nœud exécute un ensemble de services qui sont fournis au cluster et, en fin de compte, aux utilisateurs.

À propos des nœuds de cluster

La topologie de cluster pour GitHub Enterprise Server fournit une mise à l’échelle horizontale pour les entreprises comptant des dizaines de milliers de développeurs. GitHub recommande le clustering si un nœud principal unique subit régulièrement un épuisement des ressources. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

Chaque nœud de votre cluster est une machine virtuelle qui exécute le logiciel votre instance GitHub Enterprise Server. Avant de déployer un cluster, vous pouvez passer en revue la configuration matérielle requise, les services requis et les recommandations de conception.

Remarque : le clustering GitHub Enterprise Server doit être configuré avec HTTPS.

Recommandations matérielles minimales

Chaque nœud doit avoir un volume racine ainsi qu’un volume de données distinct. Il s’agit de recommandations minimales. Selon votre utilisation, comme l’activité des utilisateurs et le choix des intégrations, des ressources supplémentaires peuvent être nécessaires.

ServicesMémoire minimale requiseEspace libre minimal nécessaire pour le volume de données
job-server,
memcache-server,
web-server
14 Go1 Go
consul-server,
mysql-server,
redis-server
14 Go10 Go
git-server,
metrics-server,
pages-server,
storage-server
14 Go10 Go
elasticsearch-server14 Go10 Go

Services nécessaires pour le clustering

Pour une redondance convenable, utilisez le nombre minimal de nœuds indiqué ci-dessous pour chaque service.

Remarque : Les besoins de votre organisation en matière de scalabilité dépendent de nombreux facteurs, notamment de la taille et du nombre de dépôts, du nombre d’utilisateurs et de l’utilisation globale.

ServicesNombre minimal de nœuds nécessaires
job-server,
memcache-server,
metrics-server,
web-server
2
mysql-server,
redis-server
2
consul-server3
git-server,
pages-server,
storage-server
3
elasticsearch-server3

Recommandations relatives à la conception des clusters

Le clustering permet aux services qui composent GitHub Enterprise Server de faire l’objet d’un scale-out indépendamment les uns des autres. Cette flexibilité permet de concevoir et d’implémenter un cluster qui répond aux différentes besoins de scalabilité des organisations. Par exemple, certaines organisations peuvent avoir besoin d’un débit de stockage plus important pour les récupérations (fetch) volumineuses ou fréquentes, tout en ayant une utilisation relativement limitée du serveur web. D’autres organisations peuvent bénéficier d’un bon niveau de performance avec moins de ressources de stockage, mais nécessiter qu’un grand nombre de nœuds exécutent pages-server ou elasticsearch-server. De nombreuses combinaisons différentes sont possibles. Rapprochez-vous de votre représentant de compte pour déterminer la configuration de cluster la mieux adaptée à vos besoins spécifiques.

  • Répartissez les nœuds redondants sur du matériel indépendant. Si vous partagez le processeur, la mémoire ou des dispositifs de stockage, vous perdrez en performances et introduirez des points de défaillance uniques. Le partage de composants de réseau peut aussi réduire le débit et accroître le risque de perte de connectivité en cas de panne.
  • Utilisez un stockage rapide. Les réseaux de zone de stockage (SAN) sont souvent optimisés pour une utilisation d’espace maximale, la disponibilité et la tolérance de panne, mais pas pour un débit absolu. Le clustering GitHub Enterprise Server assure redondance et disponibilité et fonctionne de manière optimale sur le stockage le plus rapide à disposition. Un stockage SSD local est recommandé.
  • Établissez des niveaux de nœuds qui font sens pour votre organisation. Exemple de configuration :
    • Niveau front-end avec deux nœuds et les services suivants :
      • web-server
      • job-server
      • memcache-server
    • Niveau base de données avec trois nœuds et les services suivants :
      • consul-server
      • mysql-server
      • redis-server
    • Niveau recherche avec trois nœuds et les services suivants :
      • elasticsearch-server
    • Niveau stockage avec trois nœuds et les services suivants :
      • git-server
      • pages-server
      • storage-server
      • metrics-server