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 requests and specific file server requests, such as LFS and file uploads, can be served directly from the replica without loading any data from the primary. 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 Geo-Replikation ordnungsgemäß funktioniert, ist Geo DNS, beispielsweise der Route 53-Dienst von Amazon, erforderlich. 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. This means that the performance of all writes are limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. 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: There is a maximum of 8 high availability replicas (both passive and active/geo replicas) allowed for GitHub Enterprise Server.
Geo-Replikationskonfiguration überwachen
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.
Du kannst auch das Replikationsübersichts-Dashboard verwenden, das unter der folgenden Adresse verfügbar ist:
https://HOSTNAME/setup/replication