Clusterknoten ersetzen

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 finden Sie unter Erneutes Ausgleichen von Clusterworkloads.

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.

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 finden Sie 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. Wenn du einen Knoten offline nimmst, der Datendienste wie git-server, pages-server oder storage-server bereitstellt, evakuiere den Knoten. Weitere Informationen finden Sie unter Evakuieren eines Clusterknotens, auf dem Datendienste ausgeführt werden.

7. Um den fehlgeschlagenen Knoten offline auf einem beliebigen Knoten zu markieren, ändere die Clusterkonfigurationsdatei (cluster.conf) im relevanten Knotenabschnitt, sodass der Text offline = true enthalten ist.

   Diese geänderte Datei cluster.conf markiert beispielsweise den ghe-data-node-3-Knoten als offline:

   [cluster "ghe-data-node-3"]
   hostname = ghe-data-node-3
   offline = true
   ipv4 = 192.168.0.6
   # ipv6 = fd12:3456:789a:1::6
   

8. Führe aus der administrativen Shell des Knotens, wo du cluster.conf geändert hast, ghe-cluster-config-apply aus. Dadurch wird die Konfigurationsdatei validiert, auf jeden Knoten im Cluster kopiert und der Knoten als offline markiert.

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.

Um einen Knoten im Notfall zu ersetzen, installiere die GitHub Enterprise Server-Anwendung auf einer neuen VM, konfiguriere eine IP-Adresse, schalte den fehlerhaften Knoten offline, wende die Konfiguration an, füge den neuen Knoten der Clusterkonfigurationsdatei hinzu, initialisiere den Cluster, und wende die Konfiguration an. Evakuiere dann den fehlerhaften Knoten.

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 fehlgeschlagenen Knoten offline auf einem beliebigen Knoten zu markieren, ändere die Clusterkonfigurationsdatei (cluster.conf) im relevanten Knotenabschnitt, sodass der Text offline = true enthalten ist.

   Diese geänderte Datei cluster.conf markiert beispielsweise den ghe-data-node-3-Knoten als offline:

   [cluster "ghe-data-node-3"]
   hostname = ghe-data-node-3
   offline = true
   ipv4 = 192.168.0.6
   # ipv6 = fd12:3456:789a:1::6
   

4. Führe aus der administrativen Shell des Knotens, wo du cluster.conf geändert hast, ghe-cluster-config-apply aus. Dadurch wird die Konfigurationsdatei validiert, auf jeden Knoten im Cluster kopiert und der Knoten als offline markiert.

5. 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 finden Sie unter Aufschieben des Datenbank-Seeding.

6. Wenn du den primären Redis-Knoten ersetzt, ändere in cluster.conf den redis-master-Wert in den Namen des Ersatzknotens.

   Note

   Wenn dein primärer Redis-Knoten auch dein primärer MySQL-Knoten ist, findest du weitere Informationen unter Ersetzen des primären Datenbankknotens.

   In dieser geänderten cluster.conf-Datei wird beispielsweise ein neu bereitgestellter Clusterknoten ghe-replacement-data-node-1 als primärer Redis-Knoten angegeben:

   redis-master = ghe-replacement-data-node-1
   

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

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

9. Wenn du einen Knoten offline nimmst, der Datendienste wie git-server, pages-server oder storage-server bereitstellt, evakuiere den Knoten. Weitere Informationen finden Sie unter Evakuieren eines Clusterknotens, auf dem Datendienste ausgeführt werden.

Ersetzen des primären Datenbankknotens (MySQL bzw. MySQL und MSSQL)

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

Wenn für deinen Cluster GitHub Actions aktiviert ist, musst du in den folgenden Schritten auch die Angaben für MSSQL berücksichtigen.

Wenn du deinem primären MySQL-Knoten (bzw. MySQL- und MSSQL-Knoten) weitere Ressourcen zuweisen oder einen fehlerhaften Knoten ersetzen musst, kannst du deinem Cluster einen neuen Knoten hinzufügen. Füge zum Minimieren von Downtimes den neuen Cluster hinzu, repliziere die MySQL-Daten (bzw. MySQL- und MSSQL-Daten), und stufe ihn dann höher zum primären Knoten. Eine gewisse Downtime ist während des Höherstufungsvorgangs erforderlich.

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 finden Sie 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.
   • Wenn GitHub Actions im Cluster aktiviert ist, musst du auch das Schlüssel-Wert-Paar mssql-server = true einschließen.
   • 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.

   Note

   Beim vorherigen Ausschnitt wird nicht davon ausgegangen, dass GitHub Actions im Cluster aktiviert ist.

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.

   Wenn GitHub Actions im Cluster aktiviert ist, musst du warten, bis die MSSQL-Replikation abgeschlossen ist.

   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 finden Sie unter Wartungsmodus aktivieren und planen.

10. Führe ghe-cluster-status -v aus, um sicherzustellen, dass die MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) von allen Knoten im Cluster abgeschlossen ist.

    Warning

    Wenn du nicht wartest, bis die MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) abgeschlossen ist, riskierst du Datenverluste in deiner Instanz.

11. Führe den folgenden Befehl im primären MySQL-Knoten aus, um diesen in den schreibgeschützten Modus zu 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. Führe den folgenden Befehl in einem beliebigen Clusterknoten aus, um die GTIDs zu überprüfen.

    Shell

    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'
    

    • Führe den folgenden Befehl aus, um zu überprüfen, ob die globale MySQL-Variable erfolgreich festgelegt wurde.
    Shell

     echo "SHOW GLOBAL VARIABLES LIKE 'super_read_only';" | sudo mysql
    

13. Wenn GitHub Actions im Cluster aktiviert ist, stelle eine SSH-Verbindung mit dem Knoten her, der zum neuen primären MSSQL-Knoten wird.

    Shell

    ssh -p 122 admin@NEW_MSSQL_NODE_HOSTNAME
    

    • Führe in einer screen-Sitzung den folgenden Code aus, um den MSSQL-Knoten zum neuen Knoten höherzustufen.
    Shell

    /usr/local/share/enterprise/ghe-mssql-repl-promote
    

    Dadurch wird versucht, auf den aktuellen primären MSSQL-Knoten zuzugreifen und ein ordnungsgemäßes Failover auszuführen.

14. 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.
    • Wenn GitHub Actions im Cluster aktiviert ist, musst du auch das Schlüssel-Wert-Paar mssql-server = true einschließen.

    [cluster]
      mysql-master = NEW-NODE-HOSTNAME
      redis-master = NEW-NODE-HOSTNAME
      primary-datacenter = primary
    ...
    

15. Starte eine screen-Sitzung in der Verwaltungsshell des Knotens, in der du cluster.conf geändert hast, und führe ghe-cluster-config-apply aus. Durch diesen Befehl wird der Cluster neu konfiguriert, der neu hinzugefügte Knoten wird zum primären MySQL-Knoten höhergestuft, und der ursprüngliche primäre MySQL-Knoten wird in ein Replikat konvertiert.

    Note

    Beim vorherigen Ausschnitt wird nicht davon ausgegangen, dass GitHub Actions im Cluster aktiviert ist.

16. Überprüfe den Status der MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) über einen beliebigen Knoten im Cluster, indem du ghe-cluster-status -v ausführst.

17. Wenn GitHub Actions im Cluster aktiviert ist, führe den folgenden Befehl über den neuen MySQL- und MSSQL-Knoten aus.

    Shell

    /usr/local/share/enterprise/ghe-repl-post-failover-mssql
    

18. Wenn die MySQL-Replikation (bzw. MySQL- und MSSQL-Replikation) abgeschlossen ist, deaktiviere den Wartungsmodus über einen beliebigen Knoten im Cluster. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.