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.
Note
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.
- Zuweisen von aktiven Knoten zum primären Rechenzentrum.
- Hinzufügen von Replikatknoten zur Clusterkonfigurationsdatei.
- 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.
-
SSH in einen beliebigen Knoten in deinem Cluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
-
Öffne die Cluster-Konfigurationsdatei aus
/data/user/common/cluster.conf
in einem Text-Editor. Beispielsweise kannst du Vim verwenden. Erstelle eine Sicherung der Dateicluster.conf
, bevor du die Datei bearbeitest.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
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 desprimary-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.
- Änder den Namen des primären Rechenzentrums optional in eine aussagekräftigere oder genauere Bezeichnung, indem du den Wert
-
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ürprimary-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 ... ...
Note
Wenn du den Namen des primären Rechenzentrums in Schritt 3 geändert hast, suche nach dem Schlüssel-Wert-Paar
consul-datacenter
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 Bezeichnungprimary
benannt hast, verwende das folgende Schlüssel-Wert-Paar für die jeweiligen Knoten.consul-datacenter = primary
-
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
odertmux
auszuführen.ghe-cluster-config-apply
-
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“.
-
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.
Note
Wenn du Hochverfügbarkeit nach einem Failover neu konfigurierst, kannst du stattdessen die alten Knoten aus dem primären Rechenzentrum verwenden.
-
SSH in einen beliebigen Knoten in deinem Cluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
-
Sichere die bestehende Clusterkonfiguration.
cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
-
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
-
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
-
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
-
Entscheiden Sie sich für ein Muster für die Hostnamen der Replikatknoten.
Warning
Hostnamen für Replikatknoten müssen eindeutig sein und sich vom Hostnamen für den entsprechenden aktiven Knoten unterscheiden.
-
Öffne die temporäre Clusterkonfigurationsdatei aus Schritt 3 in einem Text-Editor. Beispielsweise kannst du Vim verwenden.
sudo vim ~/cluster-replica.conf
-
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 ... ...
- Ändern Sie den zwischen Anführungszeichen stehenden Hostnamen in der Abschnittsüberschrift und den Wert für
-
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
-
Benenne die primären MySQL- und Redis-Knoten im sekundären Rechenzentrum. Ersetzen Sie
REPLICA MYSQL PRIMARY HOSTNAME
undREPLICA 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
Warning
Überprüfe die Clusterkonfigurationsdatei, bevor du den Vorgang fortsetzt.
- Vergewissern Sie sich im Abschnitt
[cluster]
der obersten Ebene, dass die Werte fürmysql-master-replica
undredis-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 Wertprimary-datacenter
im Abschnitt[cluster]
der obersten Ebene entsprechen.consul-datacenter
muss mit dem Wertdatacenter
übereinstimmen, der dem Wertprimary-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 alsenabled
konfiguriert sein.
- Nutze die Gelegenheit, Abschnitte für Offlineknoten zu entfernen, die nicht mehr verwendet werden.
Eine Beispielkonfiguration findest du unter „Beispielkonfiguration“.
- Vergewissern Sie sich im Abschnitt
-
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
odertmux
auszuführen.ghe-cluster-config-init
-
Nachdem die Initialisierung abgeschlossen ist, wird von GitHub Enterprise Server die folgende Meldung angezeigt.
Finished cluster initialization
-
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
odertmux
auszuführen.ghe-cluster-config-apply
-
Überprüfen Sie nach Abschluss der Konfiguration, ob die Clusterreplikation ordnungsgemäß eingerichtet ist und funktioniert.
ghe-cluster-repl-status
-
Nachdem die Konfigurationsausführung abgeschlossen ist, zeigt GitHub Enterprise Server die folgende Meldung an.
Finished cluster configuration
-
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.
-
SSH in einen beliebigen Knoten in deinem Cluster. Weitere Informationen findest du unter Auf die Verwaltungsshell (SSH) zugreifen.
-
Öffne die Cluster-Konfigurationsdatei aus
/data/user/common/cluster.conf
in einem Text-Editor. Beispielsweise kannst du Vim verwenden. Erstelle eine Sicherung der Dateicluster.conf
, bevor du die Datei bearbeitest.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
Lösche im Abschnitt
[cluster]
der obersten Ebene die Schlüssel-Wert-Paareredis-master-replica
undmysql-master-replica
. -
Löschen Sie jeden Abschnitt für einen Replikatknoten. Bei Replikatknoten ist
replica
alsenabled
konfiguriert. -
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
odertmux
auszuführen.ghe-cluster-config-apply
-
Nachdem die Konfigurationsausführung abgeschlossen ist, zeigt GitHub Enterprise Server die folgende Meldung an.
Finished cluster configuration