Skip to main content

Clusterknoten ersetzen

Wenn ein Knoten in einem GitHub Enterprise Server-Cluster fehlschlägt, oder wenn du einen neuen Knoten mit mehr Ressourcen hinzufügen möchtest, markiere alle zu ersetzenden Knoten als offline, und füge dann den neuen Knoten hinzu.

Wer kann dieses Feature verwenden?

GitHub bestimmt die Berechtigung zum Clustering und muss die Konfiguration für die Lizenz deiner Instanz aktivieren. Das Clustering erfordert eine sorgfältige Planung und zusätzlichen Verwaltungsaufwand. Weitere Informationen findest du unter Informationen zu Clustering.

Informationen zum Ersetzen von GitHub Enterprise Server-Clusterknoten

Du kannst in einem GitHub Enterprise Server-Cluster sowohl einen funktionierenden Knoten als auch einen Knoten ersetzen, der unerwartet ausgefallen ist.

Nachdem du einen Knoten ersetzt hast, verteilt Ihre GitHub Enterprise Server-Instance Aufträge nicht automatisch an den neuen Knoten. Du kannst erzwingen, dass deine Instanz Aufträge zwischen den Knoten ausgleicht. Weitere Informationen findest du unter Erneutes Ausgleichen von Clusterworkloads.

Warnung: Um Konflikte zu vermeiden, verwende keinen Hostnamen wieder, der zuvor einem Knoten im Cluster zugewiesen wurde.

Funktionierenden Knoten ersetzen

Du kannst einen vorhandenen funktionalen Knoten in deinem Cluster ersetzen. Beispielsweise solltest du einen virtuellen Computer (VM) mit zusätzlichen CPU-, Arbeitsspeicher- oder Speicherressourcen bereitstellen.

Um einen funktionalen Knoten zu ersetzen, installiere die GitHub Enterprise Server-Anwendung auf einem neuen virtuellen Computer, konfiguriere eine IP-Adresse, füge den neuen Knoten der Clusterkonfigurationsdatei hinzu, initialisiere den Cluster, und wende die Konfiguration an. Schalte anschließend den ersetzten Knoten offline.

Hinweis: Wenn Sie den primären MySQL-Knoten ersetzen, lesen Sie „Ersetzen des primären MySQL-Knotens“.

  1. Bereitstellen und Installieren von GitHub Enterprise Server mit einem eindeutigen Hostnamen auf dem Ersetzungsknoten.

  2. Konfiguriere mithilfe der Verwaltungsshell oder DHCP nur die IP-Adresse des Ersatzknotens. Konfiguriere keine anderen Einstellungen.

  3. Um den neu verteilten Ersatzknoten hinzuzufügen, entferne auf einem beliebigen Knoten in der Datei cluster.conf den ausgefallenen Knoten, und füge den neuen Ersatzknoten hinzu. Diese geänderte cluster.conf-Datei ersetzt z. B. ghe-data-node-3 durch den neu bereitgestellten Knoten 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
    

    Sie können das Datenbank-Seeding eines neuen MySQL-Replikationsknotens aufschieben, so dass Sie Ihre Anwendung früher für den Datenverkehr öffnen können. Weitere Informationen findest du unter Aufschieben des Datenbank-Seeding.

  4. Führe aus der administrativen Shell des Knotens mit der geänderten cluster.conf ghe-cluster-config-init aus. Dadurch wird der neu hinzugefügte Knoten im Cluster initialisiert.

  5. Führe auf demselben Knoten ghe-cluster-config-apply aus. Dadurch wird die Konfigurationsdatei validiert und auf jeden Knoten im Cluster kopiert. Außerdem wird jeder Knoten entsprechend der geänderten Datei cluster.conf konfiguriert.

  6. Um den Knoten, den Sie offline ersetzen, zu entfernen, führen Sie den folgenden Befehl vom primären MySQL-Knoten Ihres Clusters aus.

    ghe-remove-node NODE-HOSTNAME
    

    Mit diesem Befehl werden die Daten von allen Datendiensten, die auf dem Knoten ausgeführt werden, evakuiert, der Knoten wird in Ihrer Konfiguration als offline markiert und die Weiterleitung des Datenverkehrs an den Knoten wird gestoppt. Weitere Informationen findest du unter Befehlszeilenprogramme.

Knoten in einem Notfall ersetzen

Du kannst einen fehlerhaften Knoten in deinem Cluster ersetzen. Beispielsweise kann sich ein Software- oder Hardwareproblem auf die Verfügbarkeit eines Knotens auswirken.

Hinweis: Wenn Sie den primären MySQL-Knoten ersetzen, lesen Sie „Ersetzen des primären MySQL-Knotens“.

Um einen Knoten in einem Notfall zu ersetzen, nehmen Sie den fehlgeschlagenen Knoten offline, fügen Sie den Ersatzknoten zum Cluster hinzu, und führen Sie dann Befehle aus, um Verweise auf Datendienste auf dem entfernten Knoten zu entfernen.

  1. Um den Knoten, bei dem Probleme auftreten, aus dem Cluster zu entfernen, führen Sie vom primären MySQL-Knoten Ihres Clusters den folgenden Befehl aus. Ersetzen Sie NODE-HOSTNAME durch den Hostnamen des Knotens, den Sie offline schalten.

    ghe-remove-node --no-evacuate NODE-HOSTNAME
    

    Mit diesem Befehl wird der Knoten in Ihrer Konfiguration als offline markiert und der Datenverkehr an den Knoten geroutet. Sie können diesen Befehl jetzt im no-evacuate-Modus ausführen, da Sie später bei dieser Vorgehensweise Befehle ausführen, die Datendienste auf dem Knoten anweisen, alle Replikate auf die anderen verfügbaren Knoten im Cluster zu kopieren. Weitere Informationen findest du unter Befehlszeilenprogramme.

  2. Fügen Sie den Ersetzungsknoten zum Cluster hinzu.

    1. Bereitstellen und Installieren von GitHub Enterprise Server mit einem eindeutigen Hostnamen auf dem Ersetzungsknoten.
  3. Konfiguriere mithilfe der Verwaltungsshell oder DHCP nur die IP-Adresse des Ersatzknotens. Konfiguriere keine anderen Einstellungen.

    1. Um den neu verteilten Ersatzknoten oder einen beliebigen Knoten hinzuzufügen, ändern Sie die Datei cluster.conf, um den Ersatzknoten hinzuzufügen. Diese geänderte cluster.conf-Datei fügt z. B. den neu bereitgestellten Knoten ghe-replacement-data-node-3 hinzu:

      [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
      
    2. Führe aus der administrativen Shell des Knotens mit der geänderten cluster.conf ghe-cluster-config-init aus. Dadurch wird der neu hinzugefügte Knoten im Cluster initialisiert.

  4. Führe auf demselben Knoten ghe-cluster-config-apply aus. Dadurch wird die Konfigurationsdatei validiert und auf jeden Knoten im Cluster kopiert. Außerdem wird jeder Knoten entsprechend der geänderten Datei cluster.conf konfiguriert.

  5. Entfernen Sie Verweise auf Datendienste auf dem Knoten, den Sie entfernt haben.

    1. Suchen Sie das UUID des Knotens, den Sie entfernt haben. Um das UUID zu finden, führen Sie den folgenden Befehl aus, und ersetzen Sie HOSTNAME mit dem Hostnamen des Knotens. Diesen verwenden Sie dieses UUID im nächsten Schritt.

      ghe-config cluster.HOSTNAME.uuid
      
    2. Führen Sie die folgenden Befehle aus, um Verweise auf Datendienste zu entfernen. Ersetzen Sie UUID durch das UUID des Knotens.

      Diese Befehle geben jedem Dienst an, dass der Knoten dauerhaft entfernt wird. Die Dienste erstellen alle Replikate, die im Knoten auf den verfügbaren Knoten innerhalb des Clusters enthalten sind, neu.

      Hinweis: Diese Befehle können zu einer erhöhten Auslastung auf dem Server führen, während Daten über Replikate hinweg neu ausgeglichen werden.

      Für den git-server-Dienst (für Repositorydaten verwendet):

      ghe-spokesctl server destroy git-server-UUID
      

      Für den pages-server-Dienst (verwendet für GitHub Pages-Site-Builds):

      ghe-dpages remove pages-server-UUID
      

      Für den storage-server-Dienst (verwendet für Git LFS-Daten, Avatarbilder, Dateianlagen und Releasearchive):

      ghe-storage destroy-host storage-server-UUID --force
      
  6. Löschen Sie optional den Eintrag für den entfernten Knoten in Ihrer cluster.conf-Datei. Auf diese Weise bleiben Ihre cluster.conf-Datei organisiert und sparen Zeit während zukünftiger config-apply-Ausführungen.

    1. Um den Eintrag aus der Datei zu entfernen, führen Sie den folgenden Befehl aus, und ersetzen Sie HOSTNAME mit dem Hostnamen des entfernten Knotens.

      ghe-config --remove-section "cluster.HOSTNAME"
      
    2. Um die Konfiguration in andere Knoten im Cluster zu kopieren, führen Sie ghe-cluster-config-apply aus der Verwaltungsshell des Knotens aus, auf dem Sie cluster.conf geändert haben.

Ersetzen des primären MySQL-Knotens

Zum Bereitstellen von Datenbankdiensten braucht Ihr Cluster einen primären MySQL-Knoten und mindestens einen Replikat-MySQL-Knoten. Weitere Informationen findest du unter Informationen zu Clusterknoten.

Wenn Sie den virtuellen Computer für Ihren primären MySQL-Knoten mit weiteren Ressourcen ausstatten möchten oder wenn der Knoten fehlerhaft ist, können Sie den Knoten ersetzen. Um Ausfallzeiten zu minimieren, fügen Sie den neuen Knoten zu Ihrem Cluster hinzu, replizieren Sie die MySQL-Daten, und stufen Sie dann den Knoten höher. Eine gewisse Ausfallzeit lässt sich während der Höherstufung nicht vermeiden.

  1. Bereitstellen und Installieren von GitHub Enterprise Server mit einem eindeutigen Hostnamen auf dem Ersetzungsknoten.

  2. Konfiguriere mithilfe der Verwaltungsshell oder DHCP nur die IP-Adresse des Ersatzknotens. Konfiguriere keine anderen Einstellungen.

  3. Um eine Verbindung mit Ihre GitHub Enterprise Server-Instance herzustellen, stelle eine SSH-Verbindung mit einem beliebigen Knoten deines Clusters her. Führe auf deiner Arbeitsstation den folgenden Befehl aus. Ersetze HOSTNAME durch den Hostnamen des Knotens. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.

    Shell
    ssh -p 122 admin@HOSTNAME
    
  4. Öffne die Cluster-Konfigurationsdatei aus /data/user/common/cluster.conf in einem Text-Editor. Beispielsweise kannst du Vim verwenden. Erstelle eine Sicherung der Datei cluster.conf, bevor du die Datei bearbeitest.

    Shell
    sudo vim /data/user/common/cluster.conf
    
  5. Die Clusterkonfigurationsdatei listet jeden Knoten unter einer [cluster "HOSTNAME"]-Überschrift auf. Fügen Sie eine neue Überschrift für den Knoten hinzu, geben Sie die Schlüssel-Wert-Paare für die Konfiguration ein und ersetzen Sie die Platzhalter durch tatsächliche Werte.

    • Stellen Sie sicher, dass das Schlüssel-Wert-Paar mysql-server = true enthalten ist.
    • Der folgende Abschnitt ist ein Beispiel. Die Konfiguration Ihres Knotens kann anders aussehen.
    ...
    [cluster "HOSTNAME"]
      hostname = HOSTNAME
      ipv4 = IPV4-ADDRESS
      # ipv6 = IPV6-ADDRESS
      consul-datacenter = PRIMARY-DATACENTER
      datacenter = DATACENTER
      mysql-server = true
      redis-server = true
      ...
    ...
    
  6. Führe aus der administrativen Shell des Knotens mit der geänderten cluster.conf ghe-cluster-config-init aus. Dadurch wird der neu hinzugefügte Knoten im Cluster initialisiert.

  7. Führe aus der administrativen Shell des Knotens, wo du cluster.conf geändert hast, ghe-cluster-config-apply aus. Der neu hinzugefügte Knoten wird zu einem MySQL-Replikatknoten, und alle anderen konfigurierten Dienste werden dort ausgeführt.

  8. Warten Sie, bis die MySQL-Replikation abgeschlossen ist. Führen Sie ghe-cluster-status -v aus, um die MySQL-Replikation von einem beliebigen Knoten im Cluster zu überwachen.

    Kurz nach dem Hinzufügen des Knotens zum Cluster wird während des Abgleichs der Replikation möglicherweise ein Fehler für den Replikationsstatus angezeigt. Die Replikation kann Stunden dauern, je nach Auslastung der Instanz, der Menge der Datenbankdaten und dem Zeitpunkt, an dem die Instanz das letzte Mal einen Datenbank-Seed erzeugt hat.

  9. Aktivieren Sie während des Zeitfensters für die geplante Wartung den Wartungsmodus. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.

  10. Führen Sie ghe-cluster-status -v aus, um sicherzustellen, dass die MySQL-Replikation von allen Knoten im Cluster beendet wurde.

    Warnung: Wenn Sie nicht warten, bis die MySQL-Replikation abgeschlossen ist, besteht die Gefahr eines Datenverlusts in Ihrer Instanz.

  11. Mit dem folgenden Befehl können Sie von den Knoten der Instanz aus den aktuellen primären MySQL-Knoten in den schreibgeschützten Modus versetzen.

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql
    
  12. Warten Sie, bis die Global Transaction Identifiers (GTIDs) für den primären und Replikat-MySQL-Knoten identisch sind. Mit dem folgenden Befehl können Sie von einem beliebigen Knoten der Instanz aus die GTIDs prüfen.

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    
  13. Nachdem die GTIDs des primären und Replikat-MySQL-Knotens übereinstimmen, aktualisieren Sie die Clusterkonfiguration, indem Sie die Clusterkonfigurationsdatei in /data/user/common/cluster.conf in einem Text-Editor öffnen.

    • Erstelle eine Sicherung der Datei cluster.conf, bevor du die Datei bearbeitest.
    • Entfernen Sie im Abschnitt [cluster] der obersten Ebene den Hostnamen für den ersetzten Knoten aus dem Schlüssel-Wert-Paar mysql-master und weisen Sie stattdessen den neuen Knoten zu. Wenn der neue Knoten auch ein primärer Redis-Knoten ist, passen Sie das Schlüssel-Wert-Paar redis-master an.
    [cluster]
      mysql-master = NEW-NODE-HOSTNAME
      redis-master = NEW-NODE-HOSTNAME
      primary-datacenter = primary
    ...
    
  14. Führen Sie aus der administrativen Shell des Knotens, wo Sie cluster.conf geändert haben, ghe-cluster-config-apply aus. Dadurch wird der Cluster neu konfiguriert, sodass der neu hinzugefügte Knoten zum primären MySQL-Knoten wird, und der ursprüngliche primäre MySQL-Knoten zu einem Replikat-MySQL-Knoten wird.

  15. Überprüfen Sie den Status der MySQL-Replikation von einem beliebigen Knoten im Cluster, indem Sie ghe-cluster-status -v ausführen.

  16. Wenn die MySQL-Replikation abgeschlossen ist, deaktivieren Sie von einem beliebigen Knoten im Cluster aus den Wartungsmodus. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.