À propos du remplacement de nœuds de cluster GitHub Enterprise Server
Vous pouvez remplacer un nœud fonctionnel dans un cluster GitHub Enterprise Server ou remplacer un nœud qui a échoué de manière inattendue.
Après avoir remplacé un nœud, votre instance GitHub Enterprise Server ne distribue pas automatiquement les travaux sur le nouveau nœud. Vous pouvez forcer votre instance à équilibrer les travaux entre les nœuds. Pour plus d’informations, consultez « Rééquilibrage des charges de travail de cluster ».
Avertissement : Pour éviter les conflits, ne réutilisez pas un nom d’hôte précédemment attribué à un nœud du cluster.
Remplacement d’un nœud fonctionnel
Vous pouvez remplacer un nœud fonctionnel existant dans votre cluster. Par exemple, vous voudrez peut-être fournir à une machine virtuelle des ressources de processeur, de mémoire ou de stockage supplémentaires.
Pour remplacer un nœud fonctionnel, installez l’appliance GitHub Enterprise Server sur une nouvelle machine virtuelle, configurez une adresse IP, ajoutez le nouveau nœud au fichier de configuration du cluster, initialisez le cluster et appliquez la configuration, puis mettez le nœud que vous avez remplacé hors connexion.
Remarque : si vous remplacez le nœud MySQL principal, consultez « Remplacement du nœud MySQL principal ».
-
Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.
-
En utilisant l’interpréteur de commandes d’administration ou DHCP, configurez uniquement l’adresse IP du nœud de remplacement. Ne configurez pas d’autres paramètres.
-
Pour ajouter le nœud de remplacement nouvellement provisionné, sur n’importe quel nœud, modifiez le fichier
cluster.conf
pour supprimer le nœud ayant échoué et ajouter le nœud de remplacement. Par exemple, ce fichiercluster.conf
modifié remplaceghe-data-node-3
par le nœud nouvellement provisionné,ghe-replacement-data-node-3
:[cluster "ghe-replacement-data-node-3"] hostname = ghe-replacement-data-node-3 ipv4 = 192.168.0.7 # ipv6 = fd12:3456:789a:1::7 consul-datacenter = PRIMARY-DATACENTER git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
Vous pouvez choisir d’échelonner l’attribution de cote de la base de données d’un nouveau nœud de réplique MySQL, ce qui vous permettra d’ouvrir votre appliance au trafic plus tôt. Pour plus d’informations, consultez « Échelonnage de l’attribution de cote de base de données ».
-
À partir de l’interpréteur de commandes d’administration du nœud avec le
cluster.conf
modifié, exécutezghe-cluster-config-init
. Cette commande initialise le nœud nouvellement ajouté dans le cluster. -
À partir du même nœud, exécutez
ghe-cluster-config-apply
. Cette commande valide le fichier de configuration, le copie sur chaque nœud du cluster et configure chaque nœud en fonction du fichiercluster.conf
modifié. -
Pour mettre hors connexion le nœud que vous remplacez à partir du nœud MySQL principal de votre cluster, exécutez la commande suivante.
ghe-remove-node NODE-HOSTNAME
Cette commande évacue les données de tous les services de données s’exécutant sur le nœud, marque le nœud comme hors connexion dans votre configuration et arrête le trafic acheminé vers le nœud. Pour plus d’informations, consultez « Utilitaires de ligne de commande ».
Remplacement d’un nœud en cas d’urgence
Vous pouvez remplacer un nœud défaillant dans votre cluster. Par exemple, un problème logiciel ou matériel peut affecter la disponibilité d’un nœud.
Remarque : si vous remplacez le nœud MySQL principal, consultez « Remplacement du nœud MySQL principal ».
Pour remplacer un nœud en cas d’urgence, vous allez mettre le nœud défaillant hors connexion, ajouter votre nœud de remplacement au cluster, puis exécuter des commandes pour supprimer les références aux services de données sur le nœud supprimé.
-
Pour supprimer le nœud qui rencontre des problèmes du cluster à partir du nœud MySQL principal de votre cluster, exécutez la commande suivante. Remplacez NODE-HOSTNAME par le nom d’hôte du nœud que vous mettez hors connexion.
ghe-remove-node --no-evacuate NODE-HOSTNAME
Cette commande marque le nœud comme étant hors connexion dans votre configuration et arrête le trafic acheminé vers le nœud. Vous pouvez exécuter cette commande en mode
no-evacuate
maintenant, car, plus loin dans cette procédure, vous allez exécuter des commandes qui indiquent aux services de données sur le nœud de copier tous les réplicas sur les autres nœuds disponibles dans le cluster. Pour plus d’informations, consultez « Utilitaires de ligne de commande ». -
Ajoutez votre nœud de remplacement au cluster.
- Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.
-
En utilisant l’interpréteur de commandes d’administration ou DHCP, configurez uniquement l’adresse IP du nœud de remplacement. Ne configurez pas d’autres paramètres.
-
Pour ajouter le nœud de remplacement nouvellement provisionné, sur n’importe quel nœud, modifiez le fichier
cluster.conf
pour ajouter le nœud de remplacement. Par exemple, ce fichiercluster.conf
modifié ajoute le nœud nouvellement provisionnéghe-replacement-data-node-3
:[cluster "ghe-replacement-data-node-3"] hostname = ghe-replacement-data-node-3 ipv4 = 192.168.0.7 # ipv6 = fd12:3456:789a:1::7 git-server = true pages-server = true mysql-server = true elasticsearch-server = true redis-server = true memcache-server = true metrics-server = true storage-server = true
-
À partir de l’interpréteur de commandes d’administration du nœud avec le
cluster.conf
modifié, exécutezghe-cluster-config-init
. Cette commande initialise le nœud nouvellement ajouté dans le cluster.
-
-
À partir du même nœud, exécutez
ghe-cluster-config-apply
. Cette commande valide le fichier de configuration, le copie sur chaque nœud du cluster et configure chaque nœud en fonction du fichiercluster.conf
modifié. -
Supprimez les références aux services de données sur le nœud que vous avez supprimé.
-
Recherchez l’UUID du nœud que vous avez supprimé. Pour rechercher l’UUID, exécutez la commande suivante, en remplaçant
HOSTNAME
par le nom d’hôte du nœud. Vous aurez besoin de cet UUID lors de l’étape suivante.ghe-config cluster.HOSTNAME.uuid
-
Pour supprimer des références aux services de données, exécutez les commandes suivantes. Remplacez
UUID
par l’UUID du nœud.Ces commandes indiquent à chaque service que le nœud est définitivement supprimé. Les services recréent tous les réplicas contenus dans le nœud sur les nœuds disponibles dans le cluster.
Remarque : ces commandes peuvent entraîner une charge accrue sur le serveur pendant que les données sont rééquilibrées entre les réplicas.
Pour le service
git-server
(utilisé pour les données du référentiel) :ghe-spokesctl server destroy git-server-UUID
Pour le service
pages-server
(utilisé pour les versions de sites GitHub Pages) :ghe-dpages remove pages-server-UUID
Pour le service
storage-server
(utilisé pour les données LFS Git, les images avatar, les pièces jointes de fichiers et les archives de publication) :ghe-storage destroy-host storage-server-UUID --force
-
-
Si vous le souhaitez, supprimez l’entrée du nœud supprimé dans votre fichier
cluster.conf
. Cela permet de conserver votre fichiercluster.conf
organisé et de gagner du temps pendant les exécutions ultérieuresconfig-apply
.-
Pour supprimer l’entrée du fichier, exécutez la commande suivante, en remplaçant
HOSTNAME
par le nom d’hôte du nœud supprimé.ghe-config --remove-section "cluster.HOSTNAME"
-
Pour copier la configuration vers d’autres nœuds du cluster à partir du shell d’administration du nœud où vous avez modifié
cluster.conf
, exécutezghe-cluster-config-apply
.
-
Remplacement du nœud MySQL principal
Pour fournir des services de base de données, votre cluster nécessite un nœud MySQL principal et au moins un nœud MySQL réplica. Pour plus d’informations, consultez « À propos des nœuds de cluster ».
Si vous voulez fournir la machine virtuelle à votre nœud MySQL principal doté de plus de ressources ou si le nœud échoue, vous pouvez remplacer le nœud. Pour réduire le temps d’arrêt, ajoutez le nouveau nœud à votre cluster, répliquez les données MySQL, puis promouvez le nœud. Un certain temps d’arrêt est nécessaire pendant la promotion.
-
Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.
-
En utilisant l’interpréteur de commandes d’administration ou DHCP, configurez uniquement l’adresse IP du nœud de remplacement. Ne configurez pas d’autres paramètres.
-
Pour vous connecter à votre instance GitHub Enterprise Server, connectez-vous avec SSH à l’un des nœuds de votre cluster. À partir de votre station de travail, exécutez la commande suivante. Remplacez HOSTNAME par le nom d’hôte du nœud. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME
-
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 fichiercluster.conf
avant de modifier le fichier.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
Le fichier de configuration du cluster répertorie chaque nœud sous un titre
[cluster "HOSTNAME"]
. Ajoutez un nouveau titre pour le nœud et entrez les paires clé-valeur pour la configuration, en remplaçant les espaces réservés par des valeurs réelles.- Veillez à inclure la
mysql-server = true
paire clé-valeur. - La section suivante est un exemple et la configuration de votre nœud peut être différente.
... [cluster "HOSTNAME"] hostname = HOSTNAME ipv4 = IPV4-ADDRESS # ipv6 = IPV6-ADDRESS consul-datacenter = PRIMARY-DATACENTER datacenter = DATACENTER mysql-server = true redis-server = true ... ...
- Veillez à inclure la
-
À partir de l’interpréteur de commandes d’administration du nœud où vous avez modifié
cluster.conf
, exécutezghe-cluster-config-apply
. Le nœud nouvellement ajouté devient un nœud MySQL réplica, et tous les autres services configurés s’exécutent là. -
Attendez la fin de la réplication MySQL. Pour surveiller la réplication MySQL à partir de n’importe quel nœud du cluster, exécutez
ghe-cluster-status -v
.Peu de temps après l’ajout du nœud au cluster, il est possible qu’une erreur sur l’état de réplication s’affiche pendant que la réplication se rattrape. La réplication peut prendre des heures selon la charge de l’instance, la quantité de données de base de données et de la dernière fois que l’instance a généré une valeur initiale de base de données.
-
Pendant votre fenêtre de maintenance planifiée, activez le mode maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».
-
Vérifiez que la réplication MySQL est terminée à partir de n’importe quel nœud du cluster en exécutant
ghe-cluster-status -v
.Avertissement : si vous n’attendez pas la fin de la réplication MySQL, vous risquez de perdre des données sur votre instance.
-
Pour définir le nœud principal MySQL actuel en mode lecture seule, exécutez la commande suivante à partir des nœuds de l’instance.
Shell echo "SET GLOBAL super_read_only = 1;" | sudo mysql
echo "SET GLOBAL super_read_only = 1;" | sudo mysql
-
Attendez que les identificateurs de transaction globaux (GTID) définis sur les nœuds MySQL principaux et réplica soient identiques. Pour vérifier les GTID, exécutez la commande suivante à partir de l’un des nœuds de l’instance.
Shell ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
-
Une fois que les GTID sur les nœuds MySQL principaux et réplica correspondent, mettez à jour la configuration du cluster en ouvrant le fichier de configuration du cluster à
/data/user/common/cluster.conf
dans un éditeur de texte.- Créez une sauvegarde du fichier
cluster.conf
avant de modifier le fichier. - Dans la section de niveau supérieur
[cluster]
, supprimez le nom d’hôte du nœud que vous avez remplacé de la paire clé-valeurmysql-master
, puis affectez le nouveau nœud à la place. Si le nouveau nœud est également un nœud Redis principal, ajustez la paire clé-valeurredis-master
.
[cluster] mysql-master = NEW-NODE-HOSTNAME redis-master = NEW-NODE-HOSTNAME primary-datacenter = primary ...
- Créez une sauvegarde du fichier
-
À partir de l’interpréteur de commandes d’administration du nœud où vous avez modifié
cluster.conf
, exécutezghe-cluster-config-apply
. Cela reconfigure le cluster afin que le nœud nouvellement ajouté devienne le nœud MySQL principal, et que le nœud MySQL principal d’origine devienne un nœud MySQL réplica. -
Vérifiez l’état de réplication MySQL à partir de n’importe quel nœud du cluster en exécutant
ghe-cluster-status -v
. -
Si la réplication MySQL est terminée, à partir de n’importe quel nœud du cluster, désactivez le mode de maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».