La présence de plusieurs réplicas actifs peut réduire la distance du réplica le plus proche. Par exemple, une organisation possédant des bureaux à San Francisco, New York et Londres pourrait exécuter l’appliance principale dans un centre de données proche de New York et deux réplicas dans des centres de données proches de San Francisco et Londres. Avec un système DNS qui prend en charge la géolocalisation, les utilisateurs peuvent être dirigés vers le serveur disponible le plus proche et accéder plus rapidement aux données de dépôt. Le fait d’accorder à l’appliance proche de New York le statut d’appliance principale permet à l’organisation d’avoir une latence entre les hôtes plus basse que si l’appliance proche de San Francisco était l’appliance principale, ce qui allongerait les temps de latence avec Londres.
Le réplica actif redirige via proxy les demandes qu’il ne peut pas traiter lui-même vers l’instance principale. Les réplicas font office de point de présence mettant fin à toutes les connexions SSL. Le trafic entre les hôtes transite par une connexion VPN chiffrée, de façon similaire à une configuration à haute disponibilité à deux nœuds sans géoréplication.
Les demandes Git et les demandes de serveur de fichiers spécifiques, telles que le partage de fichiers volumineux et les chargements de fichiers, peuvent être traitées directement à partir du réplica sans avoir à charger les données de l’appliance principale. Les requêtes web sont toujours routées vers l’appliance principale, mais si le réplica est plus proche de l’utilisateur, les requêtes sont plus rapides en raison de la plus grande proximité de la terminaison SSL.
Un service GeoDNS, tel que Amazon Route 53, est nécessaire au bon fonctionnement de la géoréplication. Le nom d’hôte de l’instance doit être résolu sur le réplica le plus proche de la localisation de l’utilisateur.
Limites
L’écriture de demandes sur le réplica nécessite l’envoi des données à l’appliance principale et à tous les réplicas. Cela signifie que le niveau de performance de toutes les écritures est limité par le réplica le plus lent, même si les nouveaux géoréplicas peuvent amorcer la majorité de leurs données à partir des géoréplicas colocalisés existants, plutôt qu’à partir de l’appliance principale.
La latence entre les nœuds principaux et réplicas doit être inférieure à 70 millisecondes. Il n'est pas recommandé de configurer un pare-feu entre les réseaux des nœuds. Pour réduire la latence et la bandwidth causées par la dissémination des équipes et des grandes batteries de serveurs CI sans affecter le débit d’écriture, vous pouvez configurer la mise en cache des référentiels. Pour plus d’informations, consultez « À propos de la mise en cache des dépôts ».
La géoréplication n’ajoute pas de la capacité à une instance GitHub Enterprise Server ni ne résout les problèmes de performances liés à une insuffisance de ressources de processeur ou de mémoire. Si l’appliance principale est hors connexion, les réplicas actifs ne pourront pas traiter les demandes de lecture ou d’écriture.
Remarque : Il y a un maximum de 8 réplicas haute disponibilité (à la fois passifs et actifs/géoréplicas) autorisés pour GitHub Enterprise Server.
Supervision d’une configuration de géoréplication
Vous pouvez monitorer la disponibilité de GitHub Enterprise Server en vérifiant le code d’état retourné pour l’URL https://HOSTNAME/status. Une appliance qui peut servir le trafic utilisateur retourne le code d’état 200 (OK). Une appliance peut retourner 503 (service indisponible) pour cette URL et d’autres requêtes web ou d’API pour plusieurs raisons :
- L’appliance est un réplica passif, par exemple, le réplica dans une configuration de haute disponibilité à deux nœuds.
- L’appliance est en mode maintenance.
- L’appliance fait partie d’une configuration de géoréplication, mais est un réplica inactif.
Vous pouvez également utiliser le tableau de bord de vue d’ensemble de la réplication, disponible sur :
https://HOSTNAME/setup/replication