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 del servidor de archivo, como LFS y las cargas de archivos, se pueden atender directamente desde la réplica sin cargar ningún dato desde el principal. 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 todas las escrituras está limitado por la réplica más lenta , aunque las nuevas réplicas geográficas pueden poblar la mayoría de sus datos de las réplicas geográficas ubicadas en el mismo lugar, en lugar del 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.
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