Quand vous configurez la haute disponibilité, il existe une configuration automatisée de la réplication asynchrone unidirectionnelle de tous les magasins de données (dépôts Git, MySQL, Redis et Elasticsearch) de l’appliance principale à l’appliance réplica. La plupart des paramètres de configuration GitHub Enterprise Server sont également répliqués, y compris le mot de passe de la Management Console. Pour plus d’informations, consultez « Géstion de votre instance à partir de l’IU WEB. ».
GitHub Enterprise Server prend en charge une configuration active/passive, où l’appliance réplica s’exécute comme solution de en attente avec les services de base de données en mode de réplication et les services d’application arrêtés.
Une fois la réplication établie, la Management Console n’est plus accessible sur les appliances réplicas. Si vous accédez à l’adresse IP ou au nom d’hôte du réplica sur le port 8443, vous verrez un message « Serveur en mode de réplication », qui indique que l’appliance est actuellement configurée en tant que réplica.
Les appliances réplicas acceptent les demandes du client Git, et ces demandes sont transférées à l’appliance active.
Note
Un maximum de 8 répliques à haute disponibilité (répliques passives et actives/géo, ainsi que des instances de cache de référentiel) est autorisé pour GitHub Enterprise Server.
Scénarios d’échec ciblés
Utilisez une configuration à haute disponibilité pour la protection contre :
- 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.
Une configuration à haute disponibilité n’est pas une bonne solution pour les opérations suivantes :
- Scale-out. Bien que vous puissiez distribuer le trafic géographiquement à l’aide de la géoréplication, les performances des écritures sont limitées à la vitesse et à la disponibilité de l’appliance principale. Pour plus d’informations, consultez « À propos de la géoréplication ».
- Chargement CI/CD. Si vous avez un grand nombre de clients CI qui sont géographiquement distants de votre instance principale, vous pouvez tirer parti de la configuration d’un cache de dépôt. Pour plus d’informations, consultez « À propos de la mise en cache des dépôts ».
- Sauvegarde de votre appliance principale. Un réplica à haute disponibilité ne remplace pas les sauvegardes hors site dans votre plan de reprise d’activité après sinistre. Certaines formes d’altération ou de perte de données peuvent être répliquées immédiatement de l’appliance principale au réplica. Pour garantir une restauration sécurisée à un état passé stable, vous devez effectuer des sauvegardes régulières avec des instantanés historiques.
- Mises à niveau sans temps d’arrêt. Pour éviter une perte de données et des situations de Split-Brain dans des scénarios de promotion contrôlée, placez l’appliance principale en mode de maintenance et attendez que toutes les écritures se terminent avant de promouvoir le réplica.
Stratégies de basculement du trafic réseau
Pendant le basculement, vous devez configurer et gérer séparément le trafic réseau de redirection de l’appliance principale au réplica.
Basculement DNS
Avec le basculement DNS, utilisez des valeurs de durée de vie courtes dans les enregistrements DNS qui pointent vers l’appliance principale GitHub Enterprise Server. Nous recommandons une durée de vie comprise entre 60 secondes et cinq minutes.
Pendant le basculement, vous devez placer l’appliance principale en mode de maintenance et rediriger ses enregistrements DNS vers l’adresse IP de l’appliance réplica. Le temps nécessaire pour rediriger le trafic de l’appliance principale au réplica dépend de la configuration de la durée de vie et du temps nécessaire pour mettre à jour les enregistrements DNS.
Si vous utilisez la géoréplication, vous devez configurer le service GeoDNS pour diriger le trafic vers le réplica le plus proche. Pour plus d’informations, consultez « À propos de la géoréplication ».
Équilibreur de charge
Une conception d’équilibreur de charge utilise un appareil réseau pour diriger le trafic Git et HTTP vers des appliances GitHub Enterprise Server individuelles. Vous pouvez utiliser un équilibreur de charge pour restreindre le trafic direct vers l’appliance à des fins de sécurité, ou pour rediriger le trafic si nécessaire sans modifications de l’enregistrement DNS. Nous vous recommandons vivement d’utiliser un équilibreur de charge basé sur TCP qui prend en charge le protocole PROXY. Les recherches DNS pour le nom d’hôte GitHub Enterprise Server doivent être résolues sur l’équilibreur de charge. Nous vous recommandons d’activer l’isolation des sous-domaines. Si l’isolation des sous-domaines est activée, un enregistrement générique supplémentaire (*.HOSTNAME) doit également être résolu sur l’équilibreur de charge. Pour plus d’informations, consultez « Activation de l’isolation de sous-domaine ».
Pendant le basculement, vous devez placer l’appliance principale en mode de maintenance. Vous pouvez configurer l’équilibreur de charge pour détecter automatiquement le moment où le réplica a été promu en appliance principale, ou cela peut nécessiter une modification de configuration manuelle. Vous devez promouvoir manuellement le réplica en appliance principale pour qu’il puisse répondre au trafic utilisateur. Pour plus d’informations, consultez « Utilisation de GitHub Enterprise Server avec un équilibreur de charge ».
Vous pouvez monitorer la disponibilité de GitHub Enterprise Server en vérifiant le code d’état retourné pour l’URL https://HOSTNAME/status. Une appliance qui peut servir le trafic utilisateur retourne le code d’état 200 (OK). Une appliance peut retourner 503 (service indisponible) pour cette URL et d’autres requêtes web ou d’API pour plusieurs raisons :
- L’appliance est un réplica passif, par exemple, le réplica dans une configuration de haute disponibilité à deux nœuds.
- L’appliance est en mode maintenance.
- L’appliance fait partie d’une configuration de géoréplication, mais est un réplica inactif.
Vous pouvez également utiliser le tableau de bord de vue d’ensemble de la réplication, disponible sur :
https://HOSTNAME/setup/replication
Utilitaires pour la gestion de la réplication
Les personnes disposant d’un accès SSH administratif à une instance dans une configuration à haute disponibilité peuvent se servir d’utilitaires de ligne de commande pour gérer la réplication. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».