Enterprise Server 3.22 est actuellement disponible en tant que version candidate.

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

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.

Atténuation de la saturation softirq à cœur unique

L’ajout d’un nœud sans état à un GitHub Enterprise Server déploiement à haute disponibilité envoie tout le trafic entre deux nœuds via un seul tunnel WireGuard. Étant donné que chaque paquet de cette paire de nœuds partage un port UDP, la carte réseau la dirige vers une file d’attente de réception et un cœur de processeur traite tous les paquets entrants. Sous forte charge, ce cœur atteint 100 %, tandis que les autres cœurs restent inactifs, et le nœud perd des paquets. GitHub Enterprise Server inclut les atténuations intégrées décrites ci-dessous.

1. Effectuer un scale-out avec plus de nœuds sans état

Chaque nœud sans état rejoint le nœud principal via son propre tunnel WireGuard, de sorte que le nœud principal traite le trafic de chaque nœud sur une file de réception distincte et un cœur CPU distinct. La répartition des charges de travail sur un plus grand nombre de nœuds sans état de plus petite taille permet à l’équilibreur de charge de répartir la charge entre les tunnels sur un plus grand nombre de cœurs du nœud principal, sans s’appuyer sur un hachage au niveau du tunnel. Deux nœuds réduisent approximativement de moitié la charge de réception par cœur, et trois la réduisent à environ un tiers.

GitHub Enterprise Server dimensionne les workers Web de chaque nœud en fonction de sa mémoire et plafonne cette valeur à 30. Maintenez app.github.github-workers à environ 30 par nœud ; des valeurs plus élevées consomment davantage de mémoire et, lors d’un blocage du tunnel, augmentent la profondeur de la file d’attente plutôt que le débit, car les processus de travail supplémentaires se bloquent sur le processus principal. Pour plus de capacité, ajoutez d’autres nœuds sans état.

2. WireGuard multi-tunnel (optionnel)

GitHub Enterprise Server peut répartir le trafic entre nœuds sur plusieurs tunnels WireGuard. Chaque tunnel utilise son propre port UDP, de sorte que différentes connexions atterrissent sur différentes files d’attente de réception et différents cœurs de processeur partagent le travail. Définissez le nombre de tunnels sur le nombre le plus bas de files d’attente de réception parmi les nœuds de votre cluster, c’est-à-dire la valeur « Combinée » de ethtool -l eth0.

Shell
ghe-config wireguard.num-tunnels 8
ghe-config-apply

La valeur par défaut est 1. Le maximum est de 16 ; les valeurs supérieures sont limitées. Un nombre de tunnels supérieur au nombre de files de réception de l’interface n’apporte aucun avantage. Pour revenir en arrière, supprimez ce paramètre et cliquez sur Appliquer.

Shell
ghe-config --unset wireguard.num-tunnels
ghe-config-apply

Avant d’activer (à usage unique) :

  • Dans votre pare-feu externe ou votre groupe de sécurité du cloud, ouvrez les ports UDP supplémentaires du tunnel entre tous les nœuds, y compris toutes les répliques. Les ports sont numérotés à partir de 1194, de sorte que 8 tunnels utilisent les ports UDP 1194 à 1201. La plage complète nécessite UDP 1194 à 1209.
  • L’activation du mode multi-tunnel met à jour le pare-feu de l’hôte. Appliquez-le une fois, en redémarrant tous les nœuds ou en rechargeant le pare-feu avec sudo ufw reload sur chaque nœud. Vérifiez que votre groupe de sécurité réseau limite déjà l’accès entrant en premier, car le rechargement ufw supprime brièvement et recrée les règles. Les modifications ultérieures num-tunnels n’ont pas besoin de cette étape.

3. Routage git-proxy local sur le serveur principal (automatique)

Les requêtes Git qu’un nœud sans état renverrait autrement via le tunnel restent désormais sur le serveur principal, où se trouvent déjà les données Git. Cela supprime une grande partie des paquets inter-tunnels et ne nécessite aucune action. Le serveur principal utilise d’abord son proxy Git local et revient à un nœud distant uniquement si celui-ci n’est pas disponible.

4. Pondération des demandes web basées sur la capacité (opt-in)

Lorsque les nœuds exécutent différents nombres de workers web, GitHub Enterprise Server peuvent distribuer des requêtes en proportion du nombre de workers de chaque nœud au lieu de uniformément. Activez-la lorsque le nombre de workers est déséquilibré, par exemple entre un nœud principal avec 100 workers et un nœud sans état avec 30.

Shell
ghe-config app.github.unicorn-weight-by-capacity true
ghe-config-apply

La valeur par défaut est désactivée.

Choisir ce qu’il faut activer

Commencez par ajouter davantage de nœuds sans état. Il s’agit de l’option la plus complète, répartit la charge sur plusieurs cœurs du principal via l’équilibreur de charge et n’a besoin d’aucun indicateur de fonctionnalité. Si un seul cœur est toujours saturé, activez WireGuard multi-tunnel. Activez la pondération basée sur la capacité uniquement lorsque le nombre de workers diffère entre les nœuds.

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.