À propos de la géoréplication

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épliques servent de point de présence, terminant 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 LFS et les chargements de fichiers, peuvent être traitées directement à partir du réplica sans charger de données depuis le serveur principal. Les requêtes web sont toujours routées vers le serveur principal, mais si la réplique est plus proche de l'utilisateur, les requêtes sont plus rapides en raison de la 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.

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

Pour aller plus loin

•         [AUTOTITLE](/admin/enterprise-management/configuring-high-availability/creating-a-high-availability-replica#creating-geo-replication-replicas)