Skip to main content

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

Vous pouvez configurer un réplica de l’ensemble de votre cluster GitHub Enterprise Server dans un centre de données distinct, ce qui permet à votre cluster de basculer vers des nœuds redondants.

À propos de la réplication à haute disponibilité pour les clusters

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 de réplica fonctionnent en mode 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’un plan complet de reprise après sinistre pour le clustering de GitHub Enterprise Server. De même, nous vous recommandons d’effectuer des sauvegardes régulières. Pour plus d’informations, consultez « AUTOTITLE ».

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 « AUTOTITLE ».

Remarque

Les nœuds que vous envisagez d’utiliser pour la réplication à haute disponibilité doivent être des instances GitHub Enterprise Server autonomes. N’initialisez pas les nœuds répliques en tant qu’un deuxième cluster.

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 en savoir plus sur la connectivité réseau entre les nœuds du cluster de répliques, consultez AUTOTITLE.

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

Pour créer une réplique de haute disponibilité pour votre cluster, utilisez l’utilitaire, puis terminez les tâches de suivi que l’outil décrit.

  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 (espace réservé) et (espace réservé) restent optionnels. 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 .
    • Si aucun nom pour le centre de données principal n’est défini, l’utilitaire utilise .
    • Si aucun nom pour le centre de données secondaire n’est défini, l’utilitaire utilise .
    Shell
    ghe-cluster-repl-bootstrap -p PRIMARY-DATACENTER -s SECONDARY-DATACENTER
    
  3. Une fois l’utilitaire exécuté, vous verrez la sortie avec d’autres instructions. Pour terminer la configuration, effectuez les tâches répertoriées dans le résultat.

Surveillance de la réplication entre les nœuds de clusters 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 en savoir plus sur l’interpréteur de commande administratif, consultez AUTOTITLE.

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

ghe-cluster-repl-status

Vous pouvez utiliser pour examiner la santé globale de votre cluster. Pour plus d’informations, consultez « AUTOTITLE ».

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

Après la bascule des nœuds actifs du cluster vers les nœuds de réplica du cluster, la haute disponibilité peut être reconfigurée selon deux méthodes. 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 les nouveaux nœuds de réplique.

Le processus de reconfiguration de la haute disponibilité est identique au processus de configuration initiale de la haute disponibilité. Pour en savoir plus, consultez Création d’une 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 « AUTOTITLE ».

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

La réplication vers les nœuds de réplica de votre déploiement de cluster de GitHub Enterprise Server peut être interrompue à l’aide de l’utilitaire (espace réservé). Vous pouvez également désactiver manuellement la réplication.

Désactivation de la réplication à l’aide de

  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 de niveau supérieur, supprimez les paires clé-valeur et .

  4. Supprimez chacune des sections correspondant à un nœud de réplica. Pour les nœuds de réplica, (espace réservé) est défini comme (espace réservé).

  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