Mehrere aktive Replikate können eine kürzere Entfernung zum nächstgelegenen Replikat ermöglichen. Beispielsweise kann eine Organisation mit Niederlassungen in San Francisco, New York und London die primäre Appliance in einem Rechenzentrum in der Nähe von New York und zwei Replikate in Rechenzentren nahe San Francisco und London betreiben. Mittels Geolocation-fähigem DNS können Benutzer an den nächstgelegenen verfügbaren Server weitergeleitet werden und schneller auf Repository-Daten zugreifen. Wenn die Appliance nahe New York als die primäre Instanz festgelegt wird, ist die Latenz zwischen den Hosts niedriger, als dies der Fall wäre, wenn die Appliance nahe San Francisco als die primäre Instanz festgelegt werden würde, deren Verbindung nach London wiederum eine höhere Latenz aufweist.
Das aktive Replikat vermittelt Anforderungen, die es nicht selbst verarbeiten kann, an die primäre Instanz. Die Replikate fungieren als ein Point of Presence und beenden alle SSL-Verbindungen. Der Traffic zwischen den Hosts wird über eine verschlüsselte VPN-Verbindung gesendet. Dies ähnelt einer Hochverfügbarkeitskonfiguration mit zwei Knoten ohne Geo-Replikation.
Git-Anforderungen und bestimmte Dateiserveranforderungen, beispielsweise LFS und Dateiuploads, können direkt vom Replikat aus bereitgestellt werden, ohne Daten aus der primären Instanz zu laden. Webanforderungen werden immer an die primäre Instanz weitergeleitet. Wenn das Replikat jedoch näher am Benutzer ist, sind die Anforderungen aufgrund der engeren SSL-Terminierung schneller.
Damit die Georeplikation ordnungsgemäß funktioniert, wird Geo DNS (beispielsweise der Route 53-Dienst von Amazon) benötigt. Der Hostname für die Instanz sollte im Replikat aufgelöst werden, das dem Standort des Benutzers am nächsten liegt.
Einschränkungen
Zum Senden von Anforderungen an das Replikat müssen die Daten an die primäre Instanz und an alle Replikate gesendet werden. Folglich wird die Leistung sämtlicher Schreibvorgänge durch das langsamste Replikat begrenzt. Neue Georeplikate können jedoch für den Großteil ihrer Daten ein Seeding aus bestehenden Georeplikaten am gleichen Standort durchführen anstatt aus der primären Instanz.
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. Um die Wartezeit und die Bandbreite, die durch verteilte Teams und große CI-Farmen verursacht werden, zu verringern, ohne den Schreibdurchsatz zu beeinträchtigen, kannst du stattdessen das Zwischenspeichern von Repositorys konfigurieren. Weitere Informationen findest du unter Informationen zum Zwischenspeichern von Repositorys.
Von der Geo-Replikation werden einer GitHub Enterprise Server-Instanz weder Kapazitäten hinzugefügt noch werden Leistungsprobleme in Bezug auf unzureichende CPU- oder Arbeitsspeicherressourcen behoben. Wenn die primäre Appliance offline ist, können aktive Replikate keine Lese- oder Schreibanforderungen verarbeiten.
Note
Für GitHub Enterprise Server sind maximal 8 Hochverfügbarkeitsreplikate (sowohl passive als auch aktive/geo-Replikate sowie Repository-Cache-Instanzen) zulässig.
Geo-Replikationskonfiguration überwachen
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