Cuando configuras la alta disponibilidad, hay una configuración automática unidireccional, una replicación asincrónica de todos los almacenes de datos (repositorios de Git, MySQL, Redis y Elasticsearch) desde el aparato principal hacia la réplica. La mayoría de los ajustes de configuración de GitHub Enterprise Server también se replican, incluyendo la contraseña de la Consola de administración. Para más información, consulta Administrar la instancia desde la interfaz del usuario web.
GitHub Enterprise Server admite una configuración activa/pasiva, en la que los dispositivos de réplica se ejecutan como en un modo de espera con los servicios de base de datos ejecutándose en modo de replicación, pero con los servicios de aplicación detenidos.
Después de que se haya establecido la replicación, ya no podrás acceder a la Consola de administración en los aplicativos de réplica. Si navega a la dirección IP o al nombre de host de la réplica en el puerto 8443, verá un mensaje de "Servidor en modo de replicación", el cual indica que el dispositivo se encuentra actualmente configurado como una réplica.
Los dispositivos de réplica aceptan solicitudes de cliente de Git y estas solicitudes se reenvían al dispositivo activo.
Note
Se permite un máximo de ocho réplicas de alta disponibilidad (tanto pasivas como activas o de replicación geográfica, así como instancias almacenadas en caché de repositorio) para GitHub Enterprise Server.
Escenarios de fallas específicas
Utiliza la configuración de alta disponibilidad para la protección contra lo siguiente:
- Bloqueos de software, ya sea debido a un error del sistema operativo o a aplicaciones irrecuperables.
- Errores de hardware, incluido hardware de almacenamiento, CPU, RAM, interfaces de red, etc.
- Errores del sistema del host de virtualización, que incluyen eventos de mantenimiento programado y no planeado para AWS, Azure, or GCP.
- Cortes lógicos o físicos en la red, si el dispositivo de conmutación por error está en una red independiente a la que no le afecta el error.
Una configuración de alta disponibilidad no es una buena solución para lo siguiente:
- Escalado horizontal. Mientras que puedes distribuir el tráfico geográficamente utilizando la replicación geográfica, el rendimiento de las escrituras queda limitado a la velocidad y la disponibilidad del dispositivo principal. Para más información, consulta Acerca de la Replicación geográfica.
- Carga de CI/CD. Si tienes una cantidad grande de clientes de IC que estén distanciados geográficamente de tu instancia primaria, puedes beneficiarte de configurar un caché de repositorio. Para más información, consulta Acerca del almacenamiento de repositorios en caché.
- Copia de seguridad del dispositivo principal. Una réplica de alta disponibilidad no reemplaza las copias de seguridad externas en tu plan de recuperación ante desastres. Algunas formas de corrupción o pérdida de datos se pueden replicar de inmediato desde el aparato principal hacia la réplica. Para asegurar una reversión segura a un estado antiguo estable, debes realizar copias de seguridad de rutina con instantáneas históricas.
- Actualizaciones de tiempo de inactividad cero. Para evitar la pérdida de datos y las situaciones de cerebro dividido en escenarios de promoción controlados, coloca el aparato principal en el modo de mantenimiento y espera a que se completen todas las escrituras entes de promover la réplica.
Estrategias de conmutación por error del tráfico de red
Durante la conmutación por error, debes configurar por separado y administrar el tráfico de red de redireccionamiento desde el aparato principal hacia la réplica.
Conmutación por error de DNS
Con la conmutación por error de DNS, utiliza valores TTL cortos en los registros DNS que se dirijan al aparato principal GitHub Enterprise Server. Recomendamos un TTL de entre 60 segundos y cinco minutos.
Durante la conmutación por error, debes colocar el aparato principal en modo de mantenimiento y redirigir sus registros DNS hacia la dirección IP del aparato réplica. El tiempo necesario para redirigir el tráfico desde el aparato principal hacia la réplica dependerá de la configuración TTL y del tiempo necesario para actualizar los registros DNS.
Si estás utilizando la replicación geográfica, debes configurar Geo DNS en tráfico directo hacia la réplica más cercana. Para más información, consulta Acerca de la Replicación geográfica.
Equilibrador de carga
Un diseño de balanceador de carga utiliza un dispositivo de red para dirigir el tráfico de Git y HTTP a los aparatos individuales del GitHub Enterprise Server. Puedes utilizar un balanceador de carga para restringir el tráfico directo al aparato con fines de seguridad o para redirigir el tráfico, de ser necesario, sin cambios en los registros DNS. Es altamente recomendable utilizar un balanceador de carga basado en TPC que admita el protocolo PROXY. Las búsquedas DNS para el nombre del host de GitHub Enterprise Server se deben resolver con el balanceador de carga. Es recomendable que habilites el aislamiento de subdominio. Si el aislamiento de subdominios está habilitado, un registro comodín adicional (*.HOSTNAME) también se debería resolver en el equilibrador de carga. Para obtener más información, vea «Habilitar el aislamiento de subdominio».
Durante la conmutación por error, debes colocar el aparato principal en el modo de mantenimiento. Puedes configurar el balanceador de carga para que detecte automáticamente cuando la réplica se haya promovido a principal, o puede que se requiera un cambio de configuración manual. Debes promover manualmente la réplica a principal antes de que responda al tráfico de usuarios. Para más información, consulta Utilizar el servidor de GitHub Enterprise con un balanceador de carga.
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
Utilidades para la administración de la replicación
Las personas con acceso SSH administrativo a una instancia en una configuración de alta disponibilidad pueden utilizar utilidades de línea de comandos para administrar la replicación. Para más información, consulta Utilidades de la ea de comandos.