Contar con múltiples réplicas puede permitir una menor distancia a la réplica más cercana. Por ejemplo, una organización con oficinas en San Francisco, Nueva York y Londres podrían ejecutar el aparato principal en un centro de datos cercano a Nueva York y dos réplicas en centros de datos cercanos a San Francisco y Londres. Al usar DNS con información de geolocalización, se puede dirigir a los usuarios al servidor disponible más cercano para que accedan a los datos más rápido. Designar como principal el aparato cercano a Nueva York ayuda a reducir la latencia entre los hosts, a diferencia de si se designa como principal el aparato cercano a San Francisco, que tiene mayor latencia con Londres.
Los proxies de la réplica activa solicitan que no se pueda procesar esta misma para la instancia principal. Las réplicas funcionan como un punto de presencia al terminar todas las conexiones SSL. El tráfico entre los servidores se envía a través de una conexión VPN encriptada, similar a una configuración de dos nodos de alta disponibilidad sin replicación geográfica.
Las solicitudes de Git y las solicitudes de archivos específicos a los servidores, tales como LFS y cargas de archivos, pueden servirse directamente de la réplica sin cargar ningún dato desde el primario. Las solicitudes web siempre se enrutan hacia el principal, pero si la réplica está más cerca del usuario, las solicitudes son más rápidas porque la terminación SSL está más cerca.
Se solicita un DNS geográfico, como Amazon's Route 53 service, para que la replicación geográfica funcione sin problemas. El nombre del host para la instancia se debe resolver con la réplica más cercana a la ubicación del usuario.
Limitaciones
Escribir solicitudes para la réplica exige que se envíen los datos al principal y a todas las réplicas. Esto significa que el rendimiento de todos los escritos se limita de acuerdo con la replica más lenta, aunque las geo-replicas nuevas pueden poblar la mayoría de sus datos desde geo-replicas existentes co-ubicadas, en vez de desde el primario. La replicación geográfica no le agregará capacidad a una instancia de GitHub Enterprise Server ni resolverá problemas de rendimiento relacionados con recursos de CPU o de memoria insuficientes. Si el aparato principal está fuera de línea, las réplicas activas no podrán atender ninguna solicitud de lectura o escritura.
Nota: Hay un máximo de 8 réplicas de disponibilidad alta (tanto pasivas como activas/geo replicas) que se permiten para GitHub Enterprise Server.
Monitorear la configuración de una replicación geográfica
Puedes verificar la disponibilidad del GitHub Enterprise Server al controlar el código de estado que devuelve la URL https://HOSTNAME/status. Un aparato que puede servir el tráfico de usuario devolverá un código de estado de 200 (OK). Un aparato puede devolver un 503 (Servicio no disponible) por distintas razones:
- El aparato es una réplica pasiva, como la réplica en una configuración de disponibilidad alta de dos nodos.
- El aparato está en modo de mantenimiento.
- El aparato es parte de una configuración de replicación geográfica, pero es una réplica inactiva.
También puedes utilizar el Tablero de resumen de replicación disponible en:
https://HOSTNAME/setup/replication