À propos des topologies de déploiement pour GitHub Enterprise Server
Vous pouvez déployer les machines virtuelles pour une instance GitHub Enterprise Server dans différentes topologies en fonction de votre environnement et des besoins des utilisateurs.
-
Pour prendre en charge un plan de récupération d’urgence et des sauvegardes supplémentaires, ou pour améliorer les performances réseau et d’écriture pour les utilisateurs géographiquement distribués, vous pouvez configurer la haute disponibilité. Dans une configuration à haute disponibilité, un nœud agit en tant que principal, tandis que les autres agissent en tant que réplicas. Pour plus d’informations, consultez « À propos de la configuration de la haute disponibilité ».
-
Pour fournir une mise à l’échelle horizontale pour les environnements avec des dizaines de milliers de développeurs, une topologie de cluster est disponible. Le clustering traite les situations où un nœud principal unique connaîtrait systématiquement un épuisement des ressources. Cette configuration nécessite une planification minutieuse et une surcharge administrative supplémentaire. GitHub vous aidera à déterminer votre éligibilité au clustering. Pour plus d’informations, consultez « À propos du clustering ».
Scénarios de défaillance
La haute disponibilité (HA) et le clustering apportent tous deux la redondance en éliminant le nœud unique correspondant au point de défaillance. Ils peuvent apporter la disponibilité dans les scénarios suivants :
- Incidents logiciels, dus à une défaillance du système d’exploitation ou à des applications irrécupérables.
- Défaillances matérielles, notamment sur le matériel de stockage, le processeur, la RAM, les interfaces réseau, etc.
- Défaillances du système hôte de virtualisation, notamment les événements de maintenance planifiés et non planifiés sur AWS, Azure ou GCP.
- Réseau logiquement ou physiquement interrompu, si l’appliance de basculement se trouve sur un réseau distinct non affecté par la défaillance.
Extensibilité
Le clustering offre une meilleure scalabilité en distribuant la charge entre plusieurs nœuds. Cette mise à l’échelle horizontale peut être préférable pour certaines organisations comptant des dizaines de milliers de développeurs. Dans le cadre de la haute disponibilité, l’échelle de l’appliance dépend exclusivement du nœud principal et la charge n’est pas distribuée au serveur réplica.
Différences dans la méthode et la configuration du basculement
| Fonctionnalité | Configuration du basculement | Méthode de basculement |
|---|---|---|
| Configuration de la haute disponibilité | Enregistrement DNS ayant une faible durée de vie faible pointant vers l’appliance principale ou l’équilibreur de charge. | Vous devez promouvoir manuellement l’appliance réplica dans les configurations de basculement DNS et d’équilibreur de charge. |
| Clustering | L’enregistrement DNS doit pointer vers un équilibreur de charge. | En cas de défaillance d’un nœud situé derrière l’équilibreur de charge, le trafic est automatiquement envoyé aux autres nœuds fonctionnels. |
Sauvegardes et récupération d’urgence
Ni la haute disponibilité ni le clustering ne doivent être considérés comme un remplacement pour les sauvegardes normales. Pour plus d’informations, consultez « Configuration des sauvegardes sur votre instance ».
Surveillance
Les fonctionnalités de disponibilité, en particulier celles proposant un basculement automatique comme le clustering, peuvent masquer une défaillance, car le service n’est généralement pas interrompu en pareil cas. Que vous utilisiez la haute disponibilité ou le clustering, il est important de superviser l’intégrité de chaque instance pour savoir qu’une défaillance se produit. Pour plus d’informations sur la surveillance, consultez « Seuils d’alerte recommandés » et « Surveillance de l’intégrité de votre cluster ».