Ajout de nœuds à une configuration de haute disponibilité

Ajoutez des nœuds au centre de données haute disponibilité principal. Cela est destiné à décharger les tâches nécessitant beaucoup de ressources processeur à partir du nœud principal, ce qui permet la mise à l'échelle horizontale de l'instance GitHub Enterprise Server.

Dans cet article

Remarque

La possibilité d’ajouter des nœuds de calcul supplémentaires à HA est disponible dans la préversion publique et est susceptible d’être modifiée. Pendant l'aperçu, partagez vos commentaires avec votre équipe de réussite client.

Pour GitHub Enterprise Server les clients qui cherchent à effectuer une mise à l’échelle horizontalement, la migration vers et l’exploitation d’un cluster est une option, mais elle consomme beaucoup de ressources et de temps. En guise d’alternative, nous vous recommandons d’ajouter des nœuds à une configuration haute disponibilité.

Les termes « nœud supplémentaire » et « nœud sans état » sont utilisés de manière interchangeable dans cet article. Les nœuds sans état ne peuvent être ajoutés qu’aux déploiements HA contenant au moins un réplica.

Nœuds supplémentaires

Parmi tous les services exécutés sur une appliance GitHub Enterprise Server, Unicorn est souvent le plus gourmand en processeur et en mémoire, suivi de près par l’Aqueduct, Git et MySQL. Étant donné que Unicorn et Aqueduct sont des services stateless, ils conviennent parfaitement à la mise à l’échelle horizontale et peuvent fonctionner sur un ensemble distinct de nœuds. Les autres services peuvent continuer à fonctionner avec une seule instance par centre de données.

Des nœuds supplémentaires vous permettent de faire évoluer horizontalement les charges de travail web et les tâches. Ils peuvent également décharger Unicorn et Aqueduct du nœud principal, libérant ainsi d’importantes ressources de calcul et de mémoire pour les autres services avec état. Si vous rencontrez des pannes liées aux performances en raison d’une utilisation élevée du processeur par les instances unicornes, l’ajout de nœuds supplémentaires est recommandé. Il n’existe aucune restriction significative sur le nombre de ces nœuds que vous pouvez ajouter dans un centre de données.

Critères

Si vous rencontrez des performances détériorées en raison d’un nœud principal surchargé dans une configuration haute disponibilité, vous devez envisager d’ajouter des nœuds supplémentaires à votre environnement haute disponibilité. En mettant à l’échelle les rôles web et de travail horizontalement au-delà du nœud principal, ces nœuds supplémentaires peuvent contribuer à réduire la charge sur l’hôte principal.

Par exemple, si vous constatez des retards dans les files d’attente d’Unicorn ou d’Aqueduct, ou si vous rencontrez d’autres types de conflits d’accès aux ressources, vous devriez envisager cette approche. Même s’il n’y a pas de mise en file d’attente visible, l’épuisement du processeur sur le nœud principal est un autre signal clair. Dans ces cas, vous pouvez ajouter des nœuds supplémentaires et réduire le nombre de workers par nœud, de sorte que le nœud principal gère moins la charge de travail globale.

Ajout d’un nœud

Chaque nœud que vous ajoutez à un déploiement haute disponibilité est une machine virtuelle exécutant le logiciel GitHub Enterprise Server . Il doit exécuter le même logiciel que le logiciel principal. En règle générale, un nœud sans état n’a pas besoin de correspondre à la mémoire, au processeur ou aux spécifications de stockage de la base de données primaire. Toutefois, le nœud sans état et l’instance principale nécessitent une connectivité en sous-millisecondes. Les exigences de connectivité du réplica restent inchangées.

Pour ajouter des nœuds au centre de données principal dans une configuration haute disponibilité, utilisez la ghe-add-node commande. La ghe-add-node commande configure l’appliance actuelle en tant que nœud au sein du déploiement haute disponibilité et vise à décharger les tâches nécessitant beaucoup d’UC à partir du nœud de données principal, ce qui permet la mise à l’échelle horizontale. Ces nœuds sont conçus pour gérer les charges de travail web et de travail, ce qui permet une distribution et une gestion des charges de travail plus efficaces. Cette commande prend la forme suivante :

Shell
/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

  •         `PRIMARY_IP`: adresse IP du nœud principal.

  •         `HOSTNAME` (facultatif) : Nom d’hôte souhaité pour l’hôte ajouté.

Par exemple, pour ajouter un nœud avec le nom ghes-node-1 d’hôte à l’instance principale haute disponibilité avec une adresse 192.168.1.1 IP dans le centre de données principal haute disponibilité, vous devez exécuter la commande suivante :

Shell
/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

Ensuite, sur le nœud principal, vous devez exécuter les commandes suivantes :

Shell
ghe-config-apply
ghe-cluster-balance rebalance --yes

La ghe-config-apply commande est requise pour ajouter des nœuds sans état.

Pour la préversion publique, nous n’avons pas testé spécifiquement les temps d’arrêt, et il n’est pas clair si une fenêtre de maintenance est requise.

Suppression d’un nœud supplémentaire

Pour supprimer un nœud, exécutez ghe-remove-node depuis le nœud que vous souhaitez supprimer. Ensuite, sur le nœud principal, vous devez exécuter :

Shell
ghe-config-apply

La ghe-config-apply commande est requise pour supprimer les nœuds sans état.

Pour la préversion publique, nous n’avons pas testé spécifiquement les temps d’arrêt, et il n’est pas clair si une fenêtre de maintenance est requise.

Reprovisionnement d’un nœud précédemment hébergé GitHub Enterprise Server

Vous pouvez utiliser un nœud qui a précédemment hébergé et exécuté GitHub Enterprise Server comme un nœud sans état. Pour ce faire, le nœud doit être mis à jour vers la version 3.18 ou ultérieure, et tous les nœuds du déploiement doivent exécuter la même version. Sur ce nœud, vérifiez si /data/user/common/cluster.conf existe déjà. Si c’est le cas, vous devez effectuer le nettoyage avant d’exécuter la commande ghe-add-node sur le nœud sans état.

Par exemple:

Shell
sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

Limites et comportement

Il n’existe aucune limite théorique au nombre de nœuds que vous pouvez ajouter. Toutefois, dans la pratique, l’ajout d’un trop grand nombre de nœuds peut entraîner des problèmes et avoir un impact sur la stabilité ou les performances. À ce stade, les nœuds nouvellement ajoutés traitent un ensemble prédéfini de tâches. Vous ne pouvez pas choisir le type de tâches qui sont déchargées. Toutes les API peuvent être traitées par le nœud supplémentaire.

Si une opération Git se trouve dans le chemin d’accès, il existe une logique en place pour traiter les opérations Git uniquement sur le nœud principal. Les opérations Git ne sont pas gérées par le nœud supplémentaire. Par exemple, la suppression de branche est une opération Git et ne sera pas gérée par le nœud sans état.

Les nœuds sans état n’exécutent pas de charges de travail Elasticsearch, mais ils exécutent kafka-lite.

Configuration requise pour le système et la mise en réseau

En règle générale, les nœuds sans état n’ont pas besoin de correspondre aux spécifications de mémoire, d’UC et de stockage du nœud principal. La configuration système requise doit tenir compte de la consommation de ressources existante des services web et de travaux sur le nœud principal et si le nœud principal décharge complètement ces charges de travail sur le nouveau nœud.

Le nœud sans état et l’instance principale nécessitent une connectivité en sous-millisecondes. En règle générale, tous les nœuds du centre de données principal nécessitent une connectivité en sous-millisecondes. Les exigences de connectivité du réplica restent inchangées.

Routage du trafic et gestion des demandes

Le principal achemine le trafic vers les nœuds supplémentaires. S’il y a plusieurs nœuds sans état, le nœud principal envoie les nouvelles connexions au serveur qui compte le moins de connexions actives à ce moment-là.

Mise à niveau d’un déploiement haute disponibilité avec des nœuds supplémentaires

Voici un exemple de séquence de mise à niveau :

  • Démarrer la fenêtre de maintenance.
  • Arrêtez les réplicas.
  • Mettez à niveau des nœuds sans état en parallèle.
  • Mettez à niveau le nœud principal.
  • Mettez à niveau les réplicas. Ils peuvent être mis à niveau en parallèle ou séquentiellement en fonction de vos préférences de récupération d’urgence.
  • Démarrez les réplicas.
  • Supprimer la fenêtre de maintenance.

Les nœuds supplémentaires ne doivent pas entraîner de temps d’arrêt supplémentaires pendant les mises à niveau.

Comportement de basculement et de reprise après sinistre

Il n’est pas nécessaire de « supprimer » des nœuds supplémentaires, car ils ne contiennent aucune donnée.

Lors du basculement, le nœud répliqué est retiré du déploiement d’origine et converti en nœud autonome. Les nœuds sans état doivent être reconnectés au réplica annoncé, de la même manière que les réplicas supplémentaires sont reconnectés après un basculement.

Si le nœud principal est fonctionnel et que vous souhaitez promouvoir un réplica comme nœud principal, vous devez supprimer les nœuds sans état du nœud principal avec la commande ghe-remove-node, avant de les ajouter de nouveau au nœud promu.

Si le nœud principal est inaccessible et irrécupérable, les nœuds sans état peuvent être re-ajoutés sans les supprimer de la base de données primaire d’origine.

Ensembles de surveillance, journaux et support

Sur le nœud principal, les tableaux de bord de surveillance de la console de gestion affichent des métriques pour tous les nœuds, y compris les nœuds sans état. Les commandes telles que ghe-cluster-nodes et ghe-cluster-status contiennent des détails sur les nœuds sans état. Toutes les demandes de console de gestion sont traitées par le nœud principal.

Les journaux sont stockés localement sur les nœuds sans état. Ils peuvent être exportés depuis ces nœuds vers des services tiers de gestion des journaux.

Vous pouvez utiliser les commandes ghe-cluster-support-bundle et ghe-support-bundle pour générer et téléverser des paquets pour des clusters ou des nœuds uniques.

Limitations connues

Cette fonctionnalité n’est pas conçue pour les référentiels uniques, mais l’ajout de nouveaux nœuds sans état peut améliorer indirectement le fonctionnement des monorepos en réduisant la charge de travail liée au Web et aux tâches sur le nœud principal. Il n’existe aucune fonctionnalité de mise à l’échelle automatique et de réduction.