Skip to main content

Konfigurieren der Hochverfügbarkeitsreplikation für einen Cluster

Sie können ein Replikat Ihres gesamten GitHub Enterprise Server-Clusters in einem separaten Rechenzentrum konfigurieren, sodass Ihr Cluster ein Failover auf redundante Knoten ausführen kann.

Informationen zur Hochverfügbarkeitsreplikation für Cluster

Sie können Schutz vor Unterbrechungen in einem Rechenzentrum oder in einer Cloudregion bereitstellen, indem Sie eine Clusterbereitstellung von GitHub Enterprise Server für Hochverfügbarkeit konfigurieren. In einer Hochverfügbarkeitskonfiguration wird eine identische Gruppe von Replikatknoten mit den Knoten in Ihrem aktiven Cluster synchronisiert. Wenn sich Hardware- oder Softwarefehler auf das Rechenzentrum mit dem aktiven Cluster auswirken, können Sie ein manuelles Failover auf die Replikatknoten ausführen und die Verarbeitung von Benutzeranforderungen fortsetzen. Dadurch werden die Auswirkungen des Ausfalls minimiert.

In einer Hochverfügbarkeitskonfiguration werden Knoten, die Datendienste hosten, regelmäßig mit dem Replikatcluster synchronisiert. Der Replikatknoten wird im Standbymodus ausgeführt. Von ihm werden keine Anwendungen bereitgestellt und keine Benutzeranforderungen verarbeitet.

Es wird empfohlen, Hochverfügbarkeit als Teil eines umfassenden Notfallwiederherstellungsplans für GitHub Enterprise Server-Clustering zu konfigurieren. Außerdem wird empfohlen, regelmäßige Sicherungen durchzuführen. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf einer Instanz.

Voraussetzungen

Hardware und Software

Für jeden vorhandenen Knoten im aktiven Cluster musst du einen zweiten virtuellen Computer mit identischen Hardwareressourcen bereitstellen. Wenn der Cluster beispielsweise 13 Knoten hat und jeder Knoten über 12 vCPUs, 96 GB RAM und 750 GB zugeordneten Speicher verfügt, müssen Sie 13 neue virtuelle Computer bereitstellen, die jeweils über 12 vCPUs, 96 GB RAM und 750 GB zugeordneten Speicher verfügen.

Installieren Sie auf jedem neuen virtuellen Computer dieselbe Version von GitHub Enterprise Server, die auf den Knoten im aktiven Cluster ausgeführt wird. Du musst keine Lizenz hochladen oder zusätzliche Konfigurationen ausführen. Weitere Informationen findest du unter GitHub Enterprise Server-Instanz einrichten.

Hinweis: Die Knoten, die du für die Hochverfügbarkeitsreplikation verwenden möchtest, müssen eigenständige GitHub Enterprise Server-Instanzen sein. Initialisieren Sie die Replikatknoten nicht als zweiten Cluster.

Netzwerk

Du musst jedem von dir bereitgestellten neuen Knoten eine statische IP-Adresse zuweisen, und du musst einen Lastenausgleich konfigurieren, damit Verbindungen akzeptiert und an die Knoten in der Front-End-Schicht des Clusters weitergeleitet werden.

Die Latenz zwischen primären und Replikatknoten muss kleiner als 70 Millisekunden sein. Es wird nicht empfohlen, eine Firewall zwischen den Netzwerken der Knoten zu konfigurieren. Weitere Informationen zur Netzwerkkonnektivität zwischen Knoten im Replikatcluster finden Sie unter Clusternetzwerk-Konfiguration.

Erstellen eines Hochverfügbarkeitsreplikats für einen Cluster

Um ein Replikat mit hoher Verfügbarkeit für Ihren Cluster zu erstellen, verwenden Sie das ghe-cluster-repl-bootstrap Hilfsprogramm, und führen Sie dann die Nachverfolgungsaufgaben aus, die das Tool enthält.

  1. SSH in einen beliebigen Knoten in deinem Cluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.

  2. Führen Sie den folgenden Befehl aus, um mit der Konfiguration der hohen Verfügbarkeit zu beginnen. Die Flags -p und -s sind optional. Wenn Sie die Flags verwenden, ersetzen Sie PRIMARY-DATACENTER und SECONDARY-DATACENTER durch die Namen Ihrer primären und sekundären Rechenzentren.

    Hinweise:

    • Standardmäßig verwendet das Hilfsprogramm den Namen des primären Rechenzentrums in cluster.conf.
    • Wenn kein Name für das primäre Rechenzentrum definiert ist, verwendet das Hilfsprogramm mona.
    • Wenn kein Name für das sekundäre Rechenzentrum definiert ist, verwendet das Hilfsprogramm hubot.
    Shell
    ghe-cluster-repl-bootstrap -p PRIMARY-DATACENTER -s SECONDARY-DATACENTER
    
  3. Nachdem das Hilfsprogramm ausgeführt wurde, erhalten Sie eine Ausgabe mit weiteren Anweisungen. Um die Konfiguration abzuschließen, führen Sie die in der Ausgabe aufgeführten Aufgaben aus.

Überwachen der Replikation zwischen aktiven Clusterknoten und Replikatclusterknoten

Die anfängliche Replikation zwischen den aktiven Knoten und Replikatknoten im Cluster nimmt eine gewisse Zeit in Anspruch. Die Dauer hängt von der Datenmenge ab, die repliziert werden soll, sowie von den Aktivitätsstufen für GitHub Enterprise Server.

Du kannst den Fortschritt auf jedem Knoten im Cluster überwachen, indem du Befehlszeilentools verwendest, die über die GitHub Enterprise Server-Verwaltungsshell verfügbar bist. Weitere Informationen finden Sie unter Auf die Verwaltungsshell (SSH) zugreifen.

Verwenden Sie den folgenden Befehl, um die Replikation aller Dienste zu überwachen.

ghe-cluster-repl-status

Du kannst ghe-cluster-status verwenden, um die allgemeine Integrität des Clusters zu überprüfen. Weitere Informationen findest du unter Befehlszeilenprogramme.

Neukonfigurieren der Hochverfügbarkeitsreplikation nach einem Failover

Nachdem Sie ein Failover von den aktiven Knoten des Clusters auf die Replikatknoten des Clusters ausgeführt haben, können Sie die Hochverfügbarkeit auf eine oder zwei Arten neu konfigurieren. Die von dir ausgewählte Methode hängt vom Grund ab, aus dem du ein Failover ausgeführt hast, sowie vom Zustand der ursprünglichen aktiven Knoten.

  • Stellen Sie eine neue Gruppe von Replikatknoten für jede der neuen aktiven Knoten im sekundären Rechenzentrum bereit, und konfigurieren Sie diese.
  • Verwenden Sie die ursprünglichen aktiven Knoten als die neuen Replikatknoten.

Der Prozess zum Neukonfigurieren von Hochverfügbarkeit ist identisch mit der anfänglichen Konfiguration von Hochverfügbarkeit. Weitere Informationen findest du unter Erstellen eines Hochverfügbarkeitsreplikats für einen Cluster.

Wenn Sie die ursprünglich aktiven Knoten verwenden, müssen Sie nach der Neukonfiguration der Hochverfügbarkeit den Wartungsmodus auf den Knoten aufheben. Weitere Informationen findest du unter Wartungsmodus aktivieren und planen.

Deaktivieren der Hochverfügbarkeitsreplikation für einen Cluster

Sie können die Replikation auf die Replikatknoten für Ihre Clusterbereitstellung von GitHub Enterprise Server mit dem Dienstprogramm beenden. Alternativ können Sie die Replikation manuell deaktivieren.

Deaktivieren der Replikation mithilfe von ghe-cluster-repl-teardown

  1. SSH in einen beliebigen Knoten in deinem Cluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.

  2. Führen Sie den folgenden Befehl aus, um die Replikation zu deaktivieren:

    Shell
    ghe-cluster-repl-teardown
    
  3. Nachdem die Konfigurationsausführung abgeschlossen ist, zeigt GitHub Enterprise Server die folgende Meldung an.

    Finished cluster configuration
    

Manuelles Deaktivieren der Replikation

  1. SSH in einen beliebigen Knoten in deinem Cluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.

  2. Ö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
    
  3. Lösche im Abschnitt [cluster] der obersten Ebene die Schlüssel-Wert-Paare redis-master-replica und mysql-master-replica.

  4. Löschen Sie jeden Abschnitt für einen Replikatknoten. Bei Replikatknoten ist replica als enabled konfiguriert.

  5. Wende die neue Konfiguration an. Die Ausführung dieses Befehls kann einige Zeit in Anspruch nehmen, daher empfehlen wir, den Befehl in einem Terminalmultiplexer wie screen oder tmux auszuführen.

     ghe-cluster-config-apply
    
  6. Nachdem die Konfigurationsausführung abgeschlossen ist, zeigt GitHub Enterprise Server die folgende Meldung an.

    Finished cluster configuration