Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-09-25. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Informationen zur Hochverfügbarkeitskonfiguration

In einer Hochverfügbarkeitskonfiguration bleibt eine voll redundante sekundäre GitHub Enterprise Server-Appliance mit der primären Appliance synchron. Dies erfolgt über die Replikation sämtlicher großer Datenspeicher.

In diesem Artikel

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. Die meisten GitHub Enterprise Server-Konfigurationseinstellungen werden ebenfalls repliziert, darunter auch das Verwaltungskonsole-Kennwort. Weitere Informationen findest du unter Verwalten Ihrer Instanz über die Web-Benutzeroberfläche.

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

Nachdem die Replikation eingerichtet wurde, ist die Verwaltungskonsole auf den Appliances für die Replikation nicht mehr zugänglich. Wenn du zu einer IP-Adresse oder zum Hostnamen des Replikats auf Port 8443 navigierst, wird die Meldung „Server im Replikationsmodus“ angezeigt, die darauf hinweist, dass die Appliance derzeit als Replikat konfiguriert ist.

Replikat-Appliances akzeptieren Git-Clientanforderungen, und diese Anforderungen werden an die aktive Appliance weitergeleitet.

Note

Für GitHub Enterprise Server sind maximal 8 Hochverfügbarkeitsreplikate (sowohl passive als auch aktive/geo-Replikate sowie Repository-Cache-Instanzen) zulässig.

Anvisierte Fehlerszenarien

Verwende eine Hochverfügbarkeitskonfiguration zum Schutz vor:

  • Softwareabstürze durch Ausfall des Betriebssystems oder nicht wiederherstellbare Anwendungen.
  • Hardwarefehler, beispielsweise Speicherhardware, CPU, RAM oder Netzwerkschnittstellen.
  • Virtualisierungshost-Systemfehler, einschließlich geplanter und nicht geplanter Wartungsereignisse für AWS, Azure oder GCP.
  • Logisch oder physisch getrenntes Netzwerk, wenn sich die Failoverappliance in einem separaten Netzwerk befindet, das vom Fehler nicht betroffen ist.

Eine Hochverfügbarkeitskonfiguration eignet sich nicht für:

  • Aufskalieren: Mithilfe der Georeplikation kannst du den Datenverkehr zwar geografisch verteilen, aber die Leistung der Schreibvorgänge ist auf die Geschwindigkeit und Verfügbarkeit der primären Appliance beschränkt. Weitere Informationen findest du unter Informationen zur Geo-Replikation.
  • CI/CD-Last: Wenn du über eine große Anzahl von CI-Clients verfügst, die geografisch weit von deiner primären Instanz entfernt sind, kannst du von der Konfiguration eines Repositorycaches profitieren. Weitere Informationen findest du unter Informationen zum Zwischenspeichern von Repositorys.
  • Sichern der primären Appliance: Eine Hochverfügbarkeitsreplikat ersetzt keine Off-Site-Backups in deinem 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, musst du regelmäßige Backups mit historischen Snapshots durchführen.
  • Upgrades ohne Downtime: Platziere zum Verhindern von Datenverlusten und Split-Brain-Situationen in kontrollierten Hochstufungsszenarien die primäre Appliance in den Wartungsmodus, und warte auf den Abschluss sämtlicher Schreibvorgänge, bevor du das Replikat hochstufst.

Netzwerk-Traffic-Failover-Strategien

Während des Failovers musst du den Netzwerk-Traffic separat konfigurieren und ihn manuell von der primären Instanz zum Replikat weiterleiten.

DNS-Failover

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

Während des Failovers musst du 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 du die Geo-Replikation verwendest musst du Geo DNS so konfigurieren, dass der Traffic an das nächstgelegene Replikat weitergeleitet wird. Weitere Informationen findest du unter Informationen zur Geo-Replikation.

Load Balancer

Ein Load-Balancer-Design verwendet ein Netzwerkgerät, um den Git- und HTTP-Traffic an einzelne GitHub Enterprise Server-Appliances zu leiten. Du kannst einen Load-Balancer verwenden, um aus Sicherheitsgründen den direkten Traffic zur Appliance einzuschränken oder um den Traffic bei Bedarf weiterzuleiten, ohne dass dazu Änderungen am DNS-Eintrag erforderlich sind. Es wird dringend empfohlen, einen TCP-basierten Load-Balancer zu verwenden, der das PROXY-Protokoll unterstützt. DNS-Nachschlagevorgänge für den GitHub Enterprise Server-Hostnamen sollten im Load-Balancer aufgelöst werden. Es wird empfohlen, dass Du die Subdomain-Isolation aktivierst. Bei aktivierter Subdomain-Isolation sollte ein zusätzlicher Platzhaltereintrag (*.HOSTNAME) ebenfalls im Lastenausgleich aufgelöst werden. Weitere Informationen findest du unter Subdomain-Isolation aktivieren.

Während des Failovers musst du die primäre Appliance in den Wartungsmodus versetzen. Du kannst 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. Du musst das Replikat manuell auf die primäre Instanz hochstufen, bevor es auf den Benutzer-Traffic antwortet. Weitere Informationen findest du unter GitHub Enterprise Server mit einem Load-Balancer verwenden.

Du kannst die Verfügbarkeit von GitHub Enterprise Server überwachen, indem du den Statuscode überprüfst, der für die https://HOSTNAME/status-URL zurückgegeben wird. Eine Appliance, die den Benutzerdatenverkehr verarbeiten kann, gibt den Statuscode 200 (OK) zurück. Ein Appliance kann aus mehreren Gründen 503 (Dienst nicht verfügbar) für diese URL und andere Web- oder API-Anforderungen zurückgeben:

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

Du kannst auch das Replikationsübersichts-Dashboard verwenden, das unter der folgenden Adresse verfügbar ist:

https://HOSTNAME/setup/replication

Dienstprogramm zur Replikationsverwaltung

Personen mit SSH-Verwaltungszugriff auf eine Instanz in einer Hochverfügbarkeitskonfiguration können Befehlszeilenprogramme verwenden, um die Replikation zu verwalten. Weitere Informationen findest du unter Befehlszeilenprogramme.

Weiterführende Themen