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.

In diesem Artikel

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, müssen Sie die folgenden Aufgaben ausführen. Sie können sich auch eine Beispielkonfiguration ansehen.

  1. Zuweisen von aktiven Knoten zum primären Rechenzentrum.
  2. Hinzufügen von Replikatknoten zur Clusterkonfigurationsdatei.
  3. Beispielkonfiguration ansehen.

1. Zuweisen von aktiven Knoten zum primären Rechenzentrum

Bevor Sie ein sekundäres Rechenzentrum für die Replikatknoten definieren, stellen Sie sicher, dass Sie die aktiven Knoten dem primären Rechenzentrum zuweisen.

  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. Notieren Sie sich den Namen des primären Rechenzentrums Ihres Clusters. Im Abschnitt [cluster], der oben in der Clusterkonfigurationsdatei enthalten ist, wird der Name des primären Rechenzentrums mithilfe des primary-datacenter-Schlüssel-Wert-Paars definiert.

    [cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = primary
    • Änder den Namen des primären Rechenzentrums optional in eine aussagekräftigere oder genauere Bezeichnung, indem du den Wert primary-datacenter bearbeitest.

  4. Die Clusterkonfigurationsdatei listet jeden Knoten unter einer [cluster "HOSTNAME"]-Überschrift auf. Füge unter der Überschrift jedes Knotens ein neues Schlüssel-Wert-Paar hinzu, um den Knoten einem Rechenzentrum zuzuweisen. Verwende denselben Wert wie für primary-datacenter im oben erläuterten Schritt 3. Wenn du beispielsweise den Standardnamen (default) verwenden möchtest, füge dem Abschnitt für jeden Knoten das folgende Schlüssel-Wert-Paar hinzu.

    datacenter = primary

    Wenn du fertig bist, sollte der Abschnitt für jeden Knoten in der Clusterkonfigurationsdatei wie das folgende Beispiel aussehen. Die Reihenfolge der Schlüsselwertpaare ist nicht wichtig.

    [cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP-ADDRESS
  ...
...

    Hinweis: Wenn du den Namen des primären Rechenzentrums in Schritt 3 geändert hast, suche nach dem consul-datacenter-Schlüssel-Wert-Paar im Abschnitt für den jeweiligen Knoten, und ändere den Wert in das umbenannte primäre Rechenzentrum. Wenn du beispielsweise das primäre Rechenzentrum mit der Bezeichnung primary benannt hast, verwende das folgende Schlüssel-Wert-Paar für die jeweiligen Knoten.

    consul-datacenter = primary

  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

Wenn von GitHub Enterprise Server wieder die Eingabeaufforderung angezeigt wird, hast du den Vorgang abgeschlossen, bei dem du die Knoten dem primären Rechenzentrum des Clusters zugewiesen hast.

2. Hinzufügen von Replikatknoten zur Clusterkonfigurationsdatei

Zum Konfigurieren von Hochverfügbarkeit müssen Sie für jeden aktiven Knoten im Cluster einen entsprechenden Replikatknoten definieren. Um eine neue Clusterkonfiguration zu erstellen, die sowohl aktive als auch Replikatknoten definiert, führen Sie die folgenden Aufgaben aus.

  • Du erstellst eine Kopie der aktiven Clusterkonfigurationsdatei.
  • Sie bearbeiten die Kopie, um Replikatknoten zu definieren, die den aktiven Knoten entsprechen, und fügen die IP-Adressen der neuen virtuellen Computer hinzu, die Sie bereitgestellt haben.
  • Du führst die geänderte Kopie der Clusterkonfiguration wieder mit der aktiven Konfiguration zusammen.
  • Du wendest die neue Konfiguration an, um die Replikation zu starten.

Eine Beispielkonfiguration findest du unter „Beispielkonfiguration“.

  1. Stelle für jeden Knoten im Cluster einen übereinstimmenden virtuellen Computer mit identischen Spezifikationen bereit, auf dem dieselbe Version von GitHub Enterprise Server ausgeführt wird. Notiere dich die IPv4-Adresse und den Hostnamen jedes neuen Clusterknotens. Weitere Informationen findest du unter Voraussetzungen.

    Hinweis: Wenn du Hochverfügbarkeit nach einem Failover neu konfigurierst, kannst du stattdessen die alten Knoten aus dem primären Rechenzentrum verwenden.

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

  3. Sichere die bestehende Clusterkonfiguration.

    cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

  4. Erstellen Sie eine Kopie der bestehenden Clusterkonfigurationsdatei an einem temporären Speicherort, z. B. /home/admin/cluster-replica.conf.

    grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf

  5. Entfernen Sie den Abschnitt [cluster] aus der temporären Clusterkonfigurationsdatei, die Sie im vorherigen Schritt kopiert haben.

    git config -f ~/cluster-replica.conf --remove-section cluster

  6. Entscheiden Sie sich für einen Namen für das sekundäre Rechenzentrum, in dem Sie die Replikatknoten bereitgestellt haben, und aktualisieren Sie dann die temporäre Clusterkonfigurationsdatei mit dem neuen Rechenzentrumsnamen. Ersetze SECONDARY durch den Namen, den du ausgewählt hast.

    sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf

  7. Entscheiden Sie sich für ein Muster für die Hostnamen der Replikatknoten.

    Warnung: Hostnamen für Replikatknoten müssen eindeutig sein und sich vom Hostnamen für den entsprechenden aktiven Knoten unterscheiden.

  8. Öffne die temporäre Clusterkonfigurationsdatei aus Schritt 3 in einem Text-Editor. Beispielsweise kannst du Vim verwenden.

    sudo vim ~/cluster-replica.conf

  9. Aktualisiere in jedem Abschnitt in der temporären Clusterkonfigurationsdatei die Konfiguration des Knotens. Die Clusterkonfigurationsdatei listet jeden Knoten unter einer [cluster "HOSTNAME"]-Überschrift auf.

    • Ändern Sie den zwischen Anführungszeichen stehenden Hostnamen in der Abschnittsüberschrift und den Wert für hostname innerhalb des Abschnitts in den Hostnamen des Replikatknotens, und orientieren Sie sich dabei an dem Muster, das Sie im oben beschriebenen Schritt 7 ausgewählt haben.
    • Fügen Sie einen neuen Schlüssel mit der Bezeichnung ipv4 hinzu, und legen Sie den Wert auf die statische IPv4-Adresse des Replikatknotens fest.
    • Erstellen Sie das neue Schlüssel-Wert-Paar replica = enabled.
    [cluster "NEW REPLICA NODE HOSTNAME"]
  ...
  hostname = NEW REPLICA NODE HOSTNAME
  ipv4 = NEW REPLICA NODE IPV4 ADDRESS
  replica = enabled
  ...
...

  10. Füge den Inhalt der temporären Clusterkonfigurationsdatei, die du in Schritt 4 erstellt hast, an die aktive Konfigurationsdatei an.

    cat ~/cluster-replica.conf >> /data/user/common/cluster.conf

  11. Benenne die primären MySQL- und Redis-Knoten im sekundären Rechenzentrum. Ersetzen Sie REPLICA MYSQL PRIMARY HOSTNAME und REPLICA REDIS PRIMARY HOSTNAME durch die Hostnamen des Replikatknotens, den Sie bereitgestellt haben, sodass sie den vorhandenen primären MySQL- und Redis-Knoten entsprechen.

    git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME
git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME

    Warnung: Überprüfe die Clusterkonfigurationsdatei, bevor du den Vorgang fortsetzt.

    • Vergewissern Sie sich im Abschnitt [cluster] der obersten Ebene, dass die Werte für mysql-master-replica und redis-master-replica auf die richtigen Hostnamen für die Replikatknoten im sekundären Rechenzentrum festgelegt sind, die nach einem Failover als primäre MySQL- und Redis-Knoten dienen.
    • Überprüfe in jedem Abschnitt für einen aktiven Knoten mit der Bezeichnung [cluster "ACTIVE NODE HOSTNAME"] die folgenden Schlüssel-Wert-Paare sehr sorgfältig.
      • datacenter muss dem Wert primary-datacenter im Abschnitt [cluster] der obersten Ebene entsprechen.
      • consul-datacenter muss mit dem Wert datacenter übereinstimmen, der dem Wert primary-datacenter im Abschnitt [cluster] der obersten Ebene entsprechen muss.
    • Vergewissern Sie sich, dass die Konfiguration für jeden aktiven Knoten genau einen entsprechenden Abschnitt für genau einen Replikatknoten mit denselben Rollen aufweist. Überprüfen Sie in jedem Abschnitt für einen Replikatknoten sehr sorgfältig jedes Schlüssel-Wert-Paar.
      • datacenter muss allen anderen Replikatknoten entsprechen.
      • consul-datacenter muss allen anderen Replikatknoten entsprechen.
      • hostname muss dem Hostnamen in der Abschnittsüberschrift entsprechen.
      • ipv4 muss der eindeutigen statischen IPv4-Adresse des Knotens entsprechen.
      • replica muss als enabled konfiguriert sein.
    • Nutze die Gelegenheit, Abschnitte für Offlineknoten zu entfernen, die nicht mehr verwendet werden.

    Eine Beispielkonfiguration findest du unter „Beispielkonfiguration“.

  12. Initialisiere die neue Clusterkonfiguration. 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-init

  13. Nachdem die Initialisierung abgeschlossen ist, wird von GitHub Enterprise Server die folgende Meldung angezeigt.

    Finished cluster initialization

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

  15. Überprüfen Sie nach Abschluss der Konfiguration, ob die Clusterreplikation ordnungsgemäß eingerichtet ist und funktioniert.

    ghe-cluster-repl-status

  16. Nachdem die Konfigurationsausführung abgeschlossen ist, zeigt GitHub Enterprise Server die folgende Meldung an.

    Finished cluster configuration

  17. Konfigurieren Sie einen Lastenausgleich, der Verbindungen von Benutzern akzeptiert, wenn Sie ein Failover auf die Replikatknoten ausführen. Weitere Informationen findest du unter Clusternetzwerk-Konfiguration.

Du hast die Konfiguration der Hochverfügbarkeitsreplikation für die Knoten im Cluster abgeschlossen. Jeder aktive Knoten beginnt mit dem Replizieren von Konfigurationen und Daten auf die entsprechenden Replikatknoten. Wenn ein Fehler auftritt, können Sie den Datenverkehr zum Lastenausgleich für das sekundäre Rechenzentrum weiterleiten. Weitere Informationen zum Failover ausführen finden Sie du unter Initiieren eines Failovers zu Ihrem Replikatcluster.

3. Beispielkonfiguration ansehen

Die Konfiguration für den [cluster] auf oberster Ebene muss wie im folgenden Beispiel aussehen.

[cluster]
  mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
  redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
  primary-datacenter = PRIMARY-DATACENTER-NAME
  mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
  mysql-auto-failover = false
...

Die Konfiguration für einen aktiven Knoten auf der Speicherebene des Clusters muss wie das folgende Beispiel aussehen.

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
  ipv4 = IPV4-ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = UUID SET AUTOMATICALLY
...

Die Konfiguration für den entsprechenden Replikatknoten auf der Speicherebene muss wie das folgende Beispiel aussehen.

  • Wichtige Unterschiede zum entsprechenden aktiven Knoten sind fett hervorgehoben.
  • Von GitHub Enterprise Server werden Werte für , und uuid automatisch zugewiesen, sodass Sie die Werte für passive Knoten, die Sie initialisieren, nicht definieren dürfen.
  • Die von *-server-Schlüsseln definierten Serverrollen stimmen mit dem entsprechenden aktiven Knoten überein.
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = DO NOT DEFINE
...

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

  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