Configuration de la réplication à haute disponibilité pour un cluster

À propos de la configuration de la réplication à haute disponibilité pour un cluster

Vous pouvez fournir une protection contre les interruptions dans un centre de données ou une région cloud en configurant un déploiement de cluster de GitHub Enterprise Server pour une haute disponibilité. Dans une configuration à haute disponibilité, un ensemble identique de nœuds réplicas est synchronisé avec les nœuds de votre cluster actif. Si des défaillances matérielles ou logicielles touchent le centre de données où se trouve votre cluster actif, vous pouvez basculer manuellement vers les nœuds réplicas et continuer à traiter les demandes utilisateur, réduisant ainsi l’impact de la panne.

Dans une configuration à haute disponibilité, les nœuds qui hébergent les services de données sont synchronisés régulièrement avec le cluster réplica. Les nœuds réplicas fonctionnent en veille et ne gèrent pas les applications ni ne traitent les demandes des utilisateurs.

Nous vous recommandons de configurer la haute disponibilité dans le cadre d’une récupération d’urgence complète pour le clustering GitHub Enterprise Server. De même, nous vous recommandons d’effectuer des sauvegardes régulières. Pour plus d’informations, consultez « Configurer les sauvegardes sur votre instance à l’aide des Utilitaires de sauvegarde ».

Prérequis

Matériels et logiciels

Pour chaque nœud existant dans votre cluster actif, vous devez provisionner une deuxième machine virtuelle avec des ressources matérielles identiques. Par exemple, si votre cluster compte 13 nœuds et que chaque nœud est doté de 12 processeurs virtuels, de 96 Go de RAM et de 750 Go de stockage attaché, vous devez provisionner 13 nouvelles machines virtuelles possédant chacune 12 processeurs virtuels, 96 Go de RAM et 750 Go de stockage attaché.

Sur chaque nouvelle machine virtuelle, installez la même version de GitHub Enterprise Server que celle qui s’exécute sur les nœuds de votre cluster actif. Vous n’avez pas besoin de charger une licence ou d’effectuer une configuration supplémentaire. Pour plus d’informations, consultez « Configuration d’une instance GitHub Enterprise Server ».

Réseau

Vous devez attribuer une adresse IP statique à chaque nouveau nœud que vous provisionnez, et vous devez configurer un équilibreur de charge qui accepte les connexions et les dirige vers le niveau front-end de votre cluster.

La latence entre les nœuds principaux et réplicas doit être inférieure à 70 millisecondes. Il n'est pas recommandé de configurer un pare-feu entre les réseaux des nœuds. Pour plus d’informations sur la connexion réseau entre les nœuds du cluster réplica, consultez Configuration réseau de cluster.

Création d’un réplica à haute disponibilité pour un cluster

Pour créer un réplica de haute disponibilité pour votre cluster, utilisez l’utilitaire ghe-cluster-repl-bootstrap, puis effectuez les tâches de suivi détaillées par l’outil.

1. SSH dans n’importe quel nœud de votre cluster. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

2. Pour commencer la configuration de la haute disponibilité, exécutez la commande suivante. Les indicateurs -p et -s sont facultatifs. Si vous utilisez les indicateurs, remplacez PRIMARY-DATACENTER et SECONDARY-DATACENTER par les noms de vos centres de données principaux et secondaires.

   Remarque

   • Par défaut, l’utilitaire utilise le nom du centre de données principal dans cluster.conf.
   • Si aucun nom pour le centre de données principal n’est défini, l’utilitaire utilise mona.
   • Si aucun nom pour le centre de données secondaire n’est défini, l’utilitaire utilise hubot.
   Shell

   ghe-cluster-repl-bootstrap -p PRIMARY-DATACENTER -s SECONDARY-DATACENTER
   

3. Une fois l’utilitaire exécuté, vous verrez la production avec d’autres instructions. Pour terminer la configuration, effectuez les tâches répertoriées dans la production.

Supervision de la réplication entre les nœuds de cluster actifs et réplicas

La réplication initiale entre les nœuds actifs et réplicas de votre cluster prend du temps. La durée dépend de la quantité de données à répliquer et des niveaux d’activité de GitHub Enterprise Server.

Vous pouvez superviser la progression de n’importe quel nœud du cluster à l’aide des outils en ligne de commande disponibles via l’interpréteur de commandes d’administration GitHub Enterprise Server . Pour plus d’informations sur l’interpréteur de commandes administratif, consultez Accès à l’interpréteur de commandes d’administration (SSH).

Pour surveiller la réplication de tous les services, utilisez la commande suivante.

ghe-cluster-repl-status

Vous pouvez utiliser ghe-cluster-status pour examiner la santé globale de votre cluster. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».

Reconfiguration de la réplication à haute disponibilité après un basculement

Après avoir opéré un basculement des nœuds actifs du groupement vers les nœuds réplicas du groupement, vous pouvez reconfigurer la haute disponibilité de deux manières. La méthode que vous choisissez va dépendre de la raison pour laquelle vous avez effectué le basculement et de l’état des nœuds actifs d’origine.

• Provisionnez et configurez un nouvel ensemble de nœuds réplicas pour chaque nouveau nœud actif de votre centre de données secondaire.
• Utilisez les nœuds actifs d’origine comme nouveaux nœuds réplicas.

Le processus de reconfiguration de la haute disponibilité est identique au processus de configuration initiale de la haute disponibilité. Pour plus d’informations, consultez Création d’un réplica à haute disponibilité pour un cluster.

Si vous utilisez les nœuds actifs d’origine, après avoir reconfiguré la haute disponibilité, vous devez annuler le mode maintenance sur les nœuds. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».

Désactivation de la réplication à haute disponibilité pour un cluster

Vous pouvez interrompre la réplication vers les nœuds de réplicas pour le déploiement de votre cluster de GitHub Enterprise Server en utilisant l’utilitaire ghe-cluster-repl-teardown. Vous pouvez également désactiver manuellement la réplication.

Désactivation de la réplication à l’aide de ghe-cluster-repl-teardown

1. SSH dans n’importe quel nœud de votre cluster. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

2. Pour désactiver la réplication, exécutez la commande suivante :

   Shell

   ghe-cluster-repl-teardown
   

3. Une fois l’exécution de la configuration terminée, GitHub Enterprise Server affiche le message suivant.

   Finished cluster configuration
   

Désactivation manuelle de la réplication

1. SSH dans n’importe quel nœud de votre cluster. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».

2. Ouvrez le fichier de configuration de groupement sur /data/user/common/cluster.conf dans un éditeur de texte. Par exemple, vous pouvez utiliser Vim. Créez une sauvegarde du fichier cluster.conf avant de modifier le fichier.

   Shell

   sudo vim /data/user/common/cluster.conf
   

3. Dans la section [cluster] de niveau supérieur, supprimez les paires clé-valeur redis-master-replica et mysql-master-replica.

4. Supprimez chaque section relative à un nœud réplica. Pour les nœuds réplicas, replica est configuré comme enabled.

5. Appliquez la nouvelle configuration. L’exécution de cette commande peut prendre un certain temps. Nous vous recommandons donc de l’exécuter dans un multiplexeur de terminal comme screen ou tmux.

    ghe-cluster-config-apply
   

6. Une fois l’exécution de la configuration terminée, GitHub Enterprise Server affiche le message suivant.

   Finished cluster configuration