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

Ajoutez des nœuds au centre de données haute disponibilité principal. Cela vise à décharger le nœud principal des tâches gourmandes en processeur, afin de permettre une mise à l’échelle horizontale de l’instance GitHub Enterprise Server.

Dans cet article

Remarque

La prise en charge de nœuds supplémentaires dans une configuration haute disponibilité est actuellement en préversion publique et susceptible d’être modifiée.

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 s’exécutant sur une GitHub Enterprise Server appliance, 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 GitHub Enterprise Server logiciel. 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.

Nous recommandons une fenêtre de maintenance pour ajouter des nœuds sans état.

Suppression d’un nœud supplémentaire

Avant de supprimer un nœud supplémentaire, installez le même correctif le plus récent pour votre version de fonctionnalité sur chaque nœud du déploiement haute disponibilité et planifiez une fenêtre de maintenance. Attendez la fin de la mise à niveau ou de la configuration avant de commencer la suppression.

  1. Sur le serveur principal HA, vérifiez l’état de chaque nœud dans le déploiement HA.

    Shell
    ghe-cluster-nodes
ghe-cluster-nodes --offline
nomad node status
ghe-cluster-status --extended --verbose

    Vérifiez que les deux ghe-cluster-nodes commandes répertorient les mêmes noms d’hôte et incluent le nom d’hôte du nœud que vous envisagez de supprimer. Vérifiez que chaque nœud a le statut Nomad ready, et que connect-ssh et enterprise-version sont ok pour chaque nœud. Vérifiez que les services avec état sur la réplique principale et sur les répliques, le cas échéant, sont sains. S’il ne subsiste aucune réplique, il est normal qu’un avertissement indique qu’aucune réplique MySQL n’a été trouvée. Les échecs limités aux charges de travail web, job ou memcache sur la cible n’empêchent pas la suppression. Si une autre vérification de niveau de nœud ou de service avec état échoue, contactez Support GitHub avant la suppression.

  2. Sur le nœud principal HA, supprimez le nœud supplémentaire. Remplacez HOSTNAME par le nom d’hôte du nœud supplémentaire.

    Shell
    ghe-remove-node --verbose HOSTNAME

    Si un autre nœud non principal reste, la commande vide la cible, la supprime de la configuration haute disponibilité et s’exécute ghe-config-apply. Si aucun nœud non principal n’est conservé, la commande supprime les métadonnées du cluster et convertit le principal en instance autonome sans l’exécuter ghe-config-apply. N’exécutez pas ghe-config-apply séparément dans les deux cas.

  3. Vérifiez la suppression.

    Si un autre nœud non principal reste, exécutez les commandes suivantes sur le nœud principal haute disponibilité. Vérifiez que le nom d’hôte est absent et que la configuration haute disponibilité est saine.

    Shell
    ghe-cluster-nodes --offline
ghe-cluster-status --extended --verbose

    Si aucun nœud non principal n’est conservé, n’exécutez pas les commandes de cluster uniquement. Vérifiez que la sortie de suppression contient Cluster artifacts removed; now standalone., puis vérifiez que le serveur principal sert le trafic utilisateur et traite les charges de travail web et de travail.

Si un nœud supplémentaire est hors ligne, inaccessible ou utilise une autre version, ou si ghe-remove-node ou une vérification échoue, contactez Support GitHub. Ne modifiez cluster.conf pas manuellement.

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

Vous pouvez utiliser comme nœud sans état un nœud qui a précédemment hébergé et exécuté GitHub Enterprise Server. 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.