À propos de l’observabilité pour la haute disponibilité
Pour prendre en charge votre plan de reprise d’activité après sinistre et compléter vos sauvegardes, ou pour améliorer les performances réseau et d’écriture pour les utilisateurs géographiquement dispersés, vous pouvez configurer la haute disponibilité pour votre instance GitHub Enterprise Server. Pour plus d’informations, consultez « À propos de la configuration de la haute disponibilité ».
Après avoir configuré la haute disponibilité, vous pouvez garantir de manière proactive une redondance en surveillant l’intégrité globale de la réplication et l’état de chacun des nœuds réplica de votre instance. Vous pouvez utiliser des utilitaires de ligne de commande sur l’instance, un tableau de bord de vue d’ensemble, ou un système de surveillance à distance comme Nagios.
Avec la haute disponibilité, votre instance utilise plusieurs approches pour répliquer les données entre les nœuds principaux et réplica. Les services de base de données qui prennent en charge un mécanisme de réplication natif, tel que MySQL, sont répliqués à l’aide du mécanisme natif du service. D’autres services, tels que les dépôts Git, sont répliqués à l’aide d’un mécanisme personnalisé développé pour GitHub Enterprise Server, ou à l’aide d’outils de plateforme comme rsync.
Surveillance de la réplication à partir de votre instance
Pour surveiller l’état de réplication d’un nœud réplica existant pour votre instance GitHub Enterprise Server, connectez-vous à la console d’administration (SSH) du nœud et exécutez l’utilitaire de ligne de commande ghe-repl-status. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».
Vous pouvez également surveiller l’état de réplication à partir du tableau de bord de vue d’ensemble de votre instance. Dans un navigateur, accédez à l’URL suivante en remplaçant HOSTNAME par le nom d’hôte de votre instance.
http(s)://HOSTNAME/setup/replication
Surveillance de la réplication à partir d’un système distant
La sortie de l’utilitaire de ligne de commande ghe-repl-status est conforme aux attentes du plug-in check_by_ssh de Nagios. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».
Vous pouvez également surveiller la disponibilité de votre instance en analysant le code d’état retourné par une requête à l’URL suivante. Par exemple, si vous déployez un équilibreur de charge dans le cadre de votre stratégie de basculement, vous pouvez configurer des contrôles d’intégrité qui analysent cette sortie. Pour plus d’informations, consultez « Utilisation de GitHub Enterprise Server avec un équilibreur de charge ».
Selon l’emplacement et la façon dont vous configurez la surveillance, remplacez HOST par le nom d’hôte de votre instance ou l’adresse IP d’un nœud individuel.
http(s)://HOST/status
Un nœud actif pour la géoréplication, qui peut répondre aux demandes des utilisateurs, retourne le code d’état 200 (OK). Les demandes adressées à des nœuds individuels ou au nom d’hôte de l’instance peuvent retourner une erreur 503 (Service non disponible) pour les raisons suivantes.
- Le nœud individuel est un nœud réplica passif, par exemple le nœud réplica dans une configuration de haute disponibilité à deux nœuds.
- Le nœud individuel fait partie d’une configuration de géoréplication, mais il s’agit d’un nœud réplica passif.
- L’instance est en mode de maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
Pour plus d’informations sur la géoréplication, consultez « À propos de la géoréplication ».
Résolution des problèmes de réplication
Pour résoudre les problèmes de réplication sur votre instance, vérifiez que la réplication est en cours d’exécution et que les nœuds peuvent communiquer entre eux sur le réseau. Vous pouvez également vous servir d’utilitaires de ligne de commande pour investiguer la sous-réplication.
La réplication n’est pas en cours d’exécution
Vous devez démarrer la réplication sur chaque nœud avec l’utilitaire de ligne de commande ghe-repl-start. Si la réplication n’est pas en cours d’exécution, connectez-vous au nœud affecté à l’aide de SSH, puis exécutez ghe-repl-start. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».
Problèmes de communication entre les nœuds
La réplication nécessite que le nœud principal et tous les nœuds réplica puissent communiquer entre eux sur le réseau. Au minimum, assurez-vous que les ports 122/TCP et 1194/UDP sont ouverts pour la communication bidirectionnelle entre tous les nœuds de votre instance. Pour plus d’informations, consultez « Ports réseau ».
Pour la haute disponibilité, la latence entre le réseau comportant les nœuds actifs et le réseau comportant les nœuds de réplica doit être inférieure à 70 millisecondes. Nous vous déconseillons de configurer un pare-feu entre les deux réseaux. Vous pouvez utiliser ping ou un autre utilitaire d’administration de réseau pour tester la connectivité du réseau entre les nœuds.
Sous-réplication
Si vous exécutez l’utilitaire de ligne de commande ghe-repl-status sur un nœud réplica et que les dépôts Git, les réseaux de dépôts ou les objets de stockage sont sous-répliqués, un ou plusieurs nœuds réplica ne sont pas entièrement synchronisés avec le nœud principal. Une sous-réplication peut se produire si le nœud principal ne peut pas communiquer avec les nœuds réplica, ou si les nœuds réplica ne peuvent pas communiquer avec le nœud principal.
Si vous avez récemment configuré la haute disponibilité ou la géoréplication, la synchronisation initiale prend un certain temps. La durée de la synchronisation initiale dépend de la quantité de données et des conditions réseau.
Dépôts ou réseaux de dépôts sous-répliqués
Vous pouvez afficher l’état de réplication d’un dépôt spécifique en vous connectant à un nœud et en exécutant la commande, puis en remplaçant OWNER par le propriétaire du dépôt et REPOSITORY par le nom du dépôt.
ghe-spokes diagnose OWNER/REPOSITORY
Sinon, si vous souhaitez afficher l’état de réplication d’un réseau de dépôts, remplacez NETWORK-ID/REPOSITORY-ID par l’ID réseau et le numéro d’ID du dépôt.
ghe-spokes diagnose NETWORK-ID/REPOSITORY-ID
Objets de stockage sous-répliqués
Vous pouvez afficher l’état d’un objet de stockage spécifique en vous connectant à un nœud et en exécutant la commande suivante, en remplaçant OID par l’ID de l’objet.
ghe-storage info OID
Obtention de support de GitHub
Si vous consultez les conseils de dépannage de la réplication et que vous continuez à rencontrer des problèmes sur votre instance, collectez les informations suivantes et contactez Support GitHub Enterprise.
- Sur chaque nœud affecté, exécutez
ghe-repl-status -vv, puis copiez la sortie dans votre ticket. Pour plus d’informations, consultez « Utilitaires de ligne de commande ». - Sur chaque nœud affecté, créez un bundle de support à attacher à votre ticket. Pour plus d’informations, consultez « Fournir des données au support GitHub ».