Informationen zur Hochverfügbarkeitskonfiguration

Beim Konfigurieren der Hochverfügbarkeit gibt es eine automatisierte Einrichtung einer unidirektionalen asynchronen Replikation sämtlicher Datenspeicher (Git-Repositorys, MySQL, Redis und ElasticSearch) von der primären zur Replikat-Appliance.

GitHub Enterprise Server unterstützt eine aktive/passive Konfiguration, bei der die Replikations-Appliance als Standby-Instanz mit Datenbankdiensten im Replikationsmodus ausgeführt wird, aber die Anwendungsdienste gestoppt werden.

Inhalt dieses Artikels

• Anvisierte Fehlerszenarien
• Netzwerk-Traffic-Failover-Strategien
• Dienstprogramm zur Replikationsverwaltung

Anvisierte Fehlerszenarien

Verwenden Sie eine Hochverfügbarkeitskonfiguration zum Schutz vor:

• Softwareabstürze durch Ausfall des Betriebssystems oder nicht wiederherstellbare Anwendungen.
• Hardwarefehler einschließlich Storage-Hardware, CPU, RAM, Netzwerkschnittstellen usw.
• Virtualisierungshostsystem-Fehler einschließlich ungeplanter und geplanter Wartungsereignisse auf AWS.
• Logisch oder physisch getrenntes Netzwerk. Wenn sich die Failover-Appliance in einem getrennten Netzwerk befindet, ist sie vom Fehler nicht betroffen.

Eine Hochverfügbarkeitskonfiguration eignet sich nicht für:

• Das horizontale Hochskalieren. Obwohl Sie den Traffic geografisch mittels Geo-Replikation verteilen können, ist die Leistung von Schreibvorgängen entsprechend der Geschwindigkeit und Verfügbarkeit der primären Appliance begrenzt. Weitere Informationen finden Sie unter „Informationen zur Geo-Replikation“.
• Das Sichern der primären Appliance. Eine Hochverfügbarkeitsreplikat ersetzt keine Off-Site-Backups in Ihrem Disaster Recovery-Plan. Einige Formen von Datenbeschädigungen oder -verlusten werden möglicherweise sofort von der primären Instanz zum Replikat repliziert. Um einen sicheren Rollback auf einen stabilen vergangenen Zustand zu gewährleisten, müssen Sie regelmäßige Backups mit historischen Snapshots durchführen.
• Upgrades ohne Ausfallzeit. Platzieren Sie zum Verhindern von Datenverlusten und Split-Brain-Situationen in kontrollierten Hochstufungsszenarien die primäre Appliance in den Wartungsmodus, und warten Sie auf den Abschluss sämtlicher Schreibvorgänge, bevor Sie das Replikat hochstufen.

Netzwerk-Traffic-Failover-Strategien

Während des Failovers müssen Sie den Netzwerk-Traffic separat konfigurieren und ihn manuell von der primären Instanz zum Replikat weiterleiten.

DNS-Failover

Verwenden Sie mit DNS-Failover kurze TTL-Werte in den DNS-Einträgen, die auf die primäre GitHub Enterprise Server-Appliance verweisen. Sie sollten einen TTL-Wert zwischen 60 Sekunden und fünf Minuten verwenden.

Während des Failovers müssen Sie die primäre Instanz in den Wartungsmodus versetzen und ihre DNS-Einträge an die IP-Adresse der Replikat-Appliance weiterleiten. Die zum Weiterleiten des Traffics von der primären Instanz zum Replikat erforderliche Zeit hängt von der TTL-Konfiguration und der zum Aktualisieren der DNS-Einträge erforderlichen Zeit ab.

Wenn Sie die Geo-Replikation verwenden, müssen Sie Geo DNS so konfigurieren, dass der Traffic an das nächstgelegene Replikat weitergeleitet wird. Weitere Informationen finden Sie unter „Informationen zur Geo-Replikation“.

Load-Balancer

A load balancer design uses a network device to direct Git and HTTP traffic to individual GitHub Enterprise Server appliances. You can use a load balancer to restrict direct traffic to the appliance for security purposes or to redirect traffic if needed without DNS record changes. We strongly recommend using a TCP-based load balancer that supports the PROXY protocol. DNS lookups for the GitHub Enterprise Server hostname should resolve to the load balancer. We recommend that you enable subdomain isolation. If subdomain isolation is enabled, an additional wildcard record (*.HOSTNAME) should also resolve to the load balancer. Weitere Informationen finden Sie unter „Subdomain-Isolation aktivieren“.

Während des Failovers müssen Sie die primäre Appliance in den Wartungsmodus versetzen. Sie können den Load-Balancer so konfigurieren, dass automatisch erkannt wird, wenn das Replikat auf die primäre Instanz hochgestuft wurde, oder dass eine manuelle Konfigurationsänderung erforderlich ist. Sie müssen das Replikat manuell auf die primäre Instanz hochstufen, bevor es auf den Benutzer-Traffic antwortet. Weitere Informationen finden Sie unter „GitHub Enterprise Server mit einem Load-Balancer verwenden“.

Sie können die Verfügbarkeit von GitHub Enterprise Server überwachen, indem Sie den für die URL https://HOSTNAME/status zurückgegebenen Statuscode überprüfen. Eine Appliance, die den Benutzer-Traffic verarbeiten kann, gibt den Statuscode 200 (OK) zurück. Es gibt einige Ursachen, weshalb eine Appliance den Statuscode 503 (Service Unavailable (Dienst nicht verfügbar)) zurückgibt:

• Die Appliance ist ein passives Replikat, beispielsweise ein Replikat in einer Hochverfügbarkeitskonfiguration mit zwei Knoten.
• Die Appliance befindet sich im Wartungsmodus.
• Die Appliance ist Bestandteil der Geo-Replikationskonfiguration, ist jedoch ein inaktives Replikat.

Sie können auch das Replikationsübersichts-Dashboard verwenden, das unter der folgenden Adresse verfügbar ist:

https://HOSTNAME/setup/replication

Dienstprogramm zur Replikationsverwaltung

Verwenden Sie zum Verwalten der Replikation auf GitHub Enterprise Server diese Befehlszeilendienstprogramme, indem Sie mittels SSH eine Verbindung zur Replikat-Appliance herstellen.

ghe-repl-setup

Der Befehl ghe-repl-setup versetzt eine GitHub Enterprise Server-Appliance in den Replikat-Standbymodus.

• Ein verschlüsselter Open-VPN-Tunnel ist für die Kommunikation zwischen den beiden Appliances konfiguriert.
• Datenbankdienste werden für die Replikation konfiguriert und gestartet.
• Anwendungsdienste werden deaktiviert. Wenn versucht wird, über HTTP, Git oder über andere unterstützte Protokolle auf die Replikat-Appliance zuzugreifen, wird die Wartungsseite „appliance in replica mode“ (Appliance im Replikatmodus) oder eine Fehlermeldung angezeigt.

admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verifying ssh connectivity with 169.254.1.1 ...
Connection check succeeded.
Configuring database replication against primary ...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Run `ghe-repl-start' to start replicating against the newly configured primary.

ghe-repl-start

Der Befehl ghe-repl-start aktiviert die aktive Replikation sämtlicher Datenspeicher.

admin@169-254-1-2:~$ ghe-repl-start
Starting OpenVPN tunnel ... 
Starting MySQL replication ...
Starting Redis replication ...
Starting Elasticsearch replication ...
Starting Pages replication ...
Starting Git replication ...
Success: replication is running for all services.
Use `ghe-repl-status' to monitor replication health and progress.

ghe-repl-status

Der Befehl ghe-repl-status gibt den Status OK, WARNING (Warnung) oder CRITICAL (Kritisch) für jeden Datenspeicher-Replikationsstream zurück. Wenn einer der Replikationskanäle den Zustand WARNING (Warnung) aufweist, wird der Befehl mit dem Code 1 beendet. Wenn einer der Kanäle den Zustand CRITICAL (Kritisch) aufweist, wird der Befehl entsprechend mit dem Code 22 beendet.

admin@169-254-1-2:~$ ghe-repl-status
OK: mysql replication in sync
OK: redis replication is in sync
OK: elasticsearch cluster is in sync
OK: git data is in sync (10 repos, 2 wikis, 5 gists)
OK: pages data is in sync

Die Optionen -v und -vv stellen Details zum Replikationszustand jedes Datenspeichers bereit:

$ ghe-repl-status -v
OK: mysql replication in sync
  | IO running: Yes, SQL running: Yes, Delay: 0

OK: redis replication is in sync
  | master_host:169.254.1.1
  | master_port:6379
  | master_link_status:up
  | master_last_io_seconds_ago:3
  | master_sync_in_progress:0

OK: elasticsearch cluster is in sync
  | {
  |   "cluster_name" : "github-enterprise",
  |   "status" : "green",
  |   "timed_out" : false,
  |   "number_of_nodes" : 2,
  |   "number_of_data_nodes" : 2,
  |   "active_primary_shards" : 12,
  |   "active_shards" : 24,
  |   "relocating_shards" : 0,
  |   "initializing_shards" : 0,
  |   "unassigned_shards" : 0
  | }

OK: git data is in sync (366 repos, 31 wikis, 851 gists)
  |                   TOTAL         OK      FAULT    PENDING      DELAY
  | repositories        366        366          0          0        0.0
  |        wikis         31         31          0          0        0.0
  |        gists        851        851          0          0        0.0
  |        total       1248       1248          0          0        0.0

OK: pages data is in sync
  | Pages are in sync

ghe-repl-stop

Der Befehl ghe-repl-stop deaktiviert die Replikation temporär für alle Datenspeicher und stoppt die Replikationsdienste. Führen Sie den Befehl ghe-repl-start aus, um die Replikation wieder aufzunehmen.

admin@168-254-1-2:~$ ghe-repl-stop
Stopping Pages replication ...
Stopping Git replication ...
Stopping MySQL replication ...
Stopping Redis replication ...
Stopping Elasticsearch replication ...
Stopping OpenVPN tunnel ...
Success: replication was stopped for all services.

ghe-repl-promote

Der Befehl ghe-repl-promote deaktiviert die Replikation und wandelt die Replikat-Appliance in eine primäre Instanz um. Die Appliance wird mit denselben Einstellungen wie die ursprüngliche primäre Instanz konfiguriert, und alle Dienste sind aktiviert.

Promoting a replica does not automatically set up replication for existing appliances. After promoting a replica, if desired, you can set up replication from the new primary to existing appliances and the previous primary.

admin@168-254-1-2:~$ ghe-repl-promote
Enabling maintenance mode on the primary to prevent writes ...
Stopping replication ...
  | Stopping Pages replication ...
  | Stopping Git replication ...
  | Stopping MySQL replication ...
  | Stopping Redis replication ...
  | Stopping Elasticsearch replication ...
  | Stopping OpenVPN tunnel ...
  | Success: replication was stopped for all services.
Switching out of replica mode ...
  | Success: Replication configuration has been removed.
  | Run `ghe-repl-setup' to re-enable replica mode.
Applying configuration and starting services ...
Success: Replica has been promoted to primary and is now accepting requests.

ghe-repl-teardown

Der Befehl ghe-repl-teardown deaktiviert den Replikationsmodus vollständig und entfernt die Replikatkonfiguration.

Weiterführende Informationen

• „Hochverfügbarkeitsreplikat erstellen“