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.
El DNS geográfico, como el servicio Route 53 de Amazon, es necesario 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 latencia entre los nodos principal y de réplica debe ser inferior a 70 milisegundos. No recomendamos configurar un firewall entre las redes de los nodos. Para reducir la latencia y el ancho de banda que ocasiona la distribución de equipos y granjas grandes de CI sin afectar a la arquitectura de rendimiento de escritura, puedes configurar el almacenamiento en caché del repositorio. Para obtener más información, vea «Acerca del almacenamiento de repositorios en caché».
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: Se permite un máximo de ocho réplicas de alta disponibilidad (tanto pasivas como activas o de replicación geográfica) para GitHub Enterprise Server.
Monitorear la configuración de una replicación geográfica
Puede supervisar la disponibilidad de GitHub Enterprise Server si comprueba el código de estado que se devuelve para la URL https://HOSTNAME/status. Un dispositivo que puede servir el tráfico de usuario devolverá un código de estado de 200 (correcto). Un dispositivo puede devolver 503 (servicio no disponible) para esta dirección URL y otras solicitudes web o API por algunos motivos:
- 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