Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-12-19. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Remplacement d’un nœud de cluster

Si un nœud échoue dans un cluster GitHub Enterprise Server, ou si vous souhaitez ajouter un nouveau nœud avec plus de ressources, marquez les nœuds à remplacer comme hors connexion et ajoutez le nouveau nœud.

Qui peut utiliser cette fonctionnalité ?

GitHub détermine l’éligibilité au clustering et doit activer la configuration de la licence de votre instance. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

À 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 ».

Warning

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.

Note

Si vous remplacez le nœud principal de la base de données, voir Remplacement du nœud principal de la base de données.

  1. Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.

  2. 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.

  3. 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 fichier cluster.conf modifié remplace ghe-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 ».

  4. À partir de l’interpréteur de commandes d’administration du nœud avec le cluster.conf modifié, exécutez ghe-cluster-config-init. Cette commande initialise le nœud nouvellement ajouté dans le cluster.

  5. À 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 fichier cluster.conf modifié.

  6. Si vous prenez un nœud hors connexion qui fournit des services de données, tels que git-server, pages-server ou storage-server, évacuez le nœud. Pour plus d’informations, consultez « Évacuation d’un nœud de cluster exécutant des services de données ».

  7. Pour marquer le nœud défaillant hors connexion, sur n’importe quel nœud, modifiez le fichier de configuration du cluster (cluster.conf) dans la section de nœud appropriée pour inclure le texte offline = true.

    Par exemple, ce fichier cluster.conf modifié marque le nœud ghe-data-node-3 comme étant hors connexion :

    [cluster "ghe-data-node-3"]
    hostname = ghe-data-node-3
    offline = true
    ipv4 = 192.168.0.6
    # ipv6 = fd12:3456:789a:1::6
    
  8. À partir de l’interpréteur de commandes d’administration du nœud où vous avez modifié cluster.conf, exécutez ghe-cluster-config-apply. Cette commande valide le fichier de configuration, le copie sur chaque nœud du cluster et marque le nœud comme étant hors connexion.

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.

Note

Si vous remplacez le nœud principal de la base de données, voir Remplacement du nœud principal de la base de données.

Pour remplacer un nœud en cas d’urgence, installez l’appliance GitHub Enterprise Server sur une nouvelle machine virtuelle, configurez une adresse IP, mettez le nœud défaillant hors connexion, appliquez la configuration, ajoutez le nouveau nœud au fichier de configuration du cluster, initialisez le cluster et appliquez la configuration, et éventuellement, évacuez le nœud défaillant.

  1. Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.

  2. 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.

  3. Pour marquer le nœud défaillant hors connexion, sur n’importe quel nœud, modifiez le fichier de configuration du cluster (cluster.conf) dans la section de nœud appropriée pour inclure le texte offline = true.

    Par exemple, ce fichier cluster.conf modifié marque le nœud ghe-data-node-3 comme étant hors connexion :

    [cluster "ghe-data-node-3"]
    hostname = ghe-data-node-3
    offline = true
    ipv4 = 192.168.0.6
    # ipv6 = fd12:3456:789a:1::6
    
  4. À partir de l’interpréteur de commandes d’administration du nœud où vous avez modifié cluster.conf, exécutez ghe-cluster-config-apply. Cette commande valide le fichier de configuration, le copie sur chaque nœud du cluster et marque le nœud comme étant hors connexion.

  5. 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 fichier cluster.conf modifié remplace ghe-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 ».

  6. Si vous remplacez le nœud Redis principal dans cluster.conf, modifiez la valeur redis-master avec le nom du nœud de remplacement.

    Note

    Si votre nœud Redis principal est également votre nœud MySQL principal, voir Remplacement du nœud principal de la base de données.

    Par exemple, ce fichier cluster.conf modifié spécifie un nœud de cluster nouvellement approvisionné, ghe-replacement-data-node-1, en tant que nœud Redis principal :

    redis-master = ghe-replacement-data-node-1
    
  7. À partir de l’interpréteur de commandes d’administration du nœud avec le cluster.conf modifié, exécutez ghe-cluster-config-init. Cette commande initialise le nœud nouvellement ajouté dans le cluster.

  8. À 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 fichier cluster.conf modifié.

  9. Si vous prenez un nœud hors connexion qui fournit des services de données, tels que git-server, pages-server ou storage-server, évacuez le nœud. Pour plus d’informations, consultez « Évacuation d’un nœud de cluster exécutant des services de données ».

Remplacement du nœud de base de données principal (MySQL ou MySQL et MSSQL)

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 votre cluster a GitHub Actions activé, vous devrez également prendre en compte MSSQL dans les étapes suivantes.

Si vous devez allouer davantage de ressources à votre nœud MySQL principal (ou MySQL et MSSQL) ou remplacer un nœud ayant échoué, vous pouvez ajouter un nouveau nœud à votre cluster. Pour réduire le temps d’arrêt, ajoutez le nouveau nœud, répliquez les données MySQL (ou MySQL et MSSQL), puis faites-la passer au nœud principal. Un certain temps d'arrêt est nécessaire pendant le processus de promotion.

  1. Provisionnez et installez GitHub Enterprise Server avec un nom d’hôte unique sur le nœud de remplacement.

  2. 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.

  3. 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
    
  4. 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
    
  5. 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.
    • Si GitHub Actions est activé dans le cluster, vous devrez inclure mssql-server = truela paire clé-valeur également.
    • 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
      ...
    ...
    
  6. À partir de l’interpréteur de commandes d’administration du nœud où vous avez modifié cluster.conf, exécutez ghe-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à.

    Note

    L'extrait précédent ne suppose pas que GitHub Actions soit activé dans le cluster.

  7. 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.

    Si GitHub Actions est activé dans le cluster, vous devrez attendre que la réplication MSSQL se termine.

    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.

  8. Pendant votre fenêtre de maintenance planifiée, activez le mode maintenance. Pour plus d’informations, consultez « Activation et planification du mode de maintenance ».

  9. Assurez-vous que la réplication MySQL (ou MySQL et MSSQL) est terminée à partir de n'importe quel nœud du cluster en exécutant la commande ghe-cluster-status -v.

    Warning

    Si vous n'attendez pas la fin de la réplication MySQL (ou MySQL et MSSQL), vous risquez de perdre des données sur votre instance.

  10. Pour définir le nœud principal MySQL actuel en mode lecture seule, exécutez la commande suivante à partir du nœud principal MySQL.

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql
    
  11. 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 n’importe quel nœud de cluster.

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    
    • Pour vérifier que la variable MySQL globale a été correctement définie, exécutez la commande suivante.
    Shell
     echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
    
  12. Si GitHub Actions est activé dans le cluster, connectez-vous en SSH au nœud qui deviendra le nouveau nœud MSSQL primaire.

    Shell
    ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
    
    • À partir d’une session screen exécutez la commande suivante pour promouvoir MSSQL vers le nouveau nœud.
    Shell
    /usr/local/share/enterprise/ghe-mssql-repl-promote
    

    Cela tentera d’accéder au nœud MSSQL principal actuel et d’effectuer un basculement approprié

  13. 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é-valeur mysql-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é-valeur redis-master.
    • Si GitHub Actions est activé dans le cluster, vous devrez inclure mssql-server = truela paire clé-valeur également.
    [cluster]
      mysql-master = NEW-NODE-HOSTNAME
      redis-master = NEW-NODE-HOSTNAME
      primary-datacenter = primary
    ...
    
  14. Dans le shell administratif du nœud où vous avez modifié cluster.conf, démarrer une screen session et exécuter ghe-cluster-config-apply. Cette commande reconfigure le cluster, en favorisant le nœud nouvellement ajouté au nœud MySQL principal et en convertissant le nœud MySQL principal d’origine en réplica.

    Note

    L'extrait précédent ne suppose pas que GitHub Actions soit activé dans le cluster.

  15. Vérifiez l'état de la réplication MySQL (ou MySQL et MSSQL) à partir de n'importe quel nœud du cluster en exécutant la commande suivante ghe-cluster-status -v.

  16. Si GitHub Actions est activé dans le cluster, exécutez la commande suivante à partir du nouveau nœud MySQL et MSSQL.

    Shell
    /usr/local/share/enterprise/ghe-repl-post-failover-mssql
    
  17. Lorsque la réplication MySQL (ou MySQL et MSSQL) est terminée, désactivez le mode maintenance à partir de n'importe quel nœud du cluster. Consultez Activation et planification du mode de maintenance.