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.
GitHub Enterprise Server admite una configuración activa/pasiva, en la que el aparato réplica se ejecuta 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.
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.
Escenarios de fallas específicas
Utiliza la configuración de alta disponibilidad para la protección contra lo siguiente:
- Fallo de software, ya sea debido a una falla en el sistema operativo o a aplicaciones irrecuperables.
- Fallas del hardware, incluido el hardware de almacenamiento, la CPU, la RAM, las interfaces de red, etc.
- Fallas del sistema host de virtualización, incluidos los eventos no planeados y de mantenimiento programado en AWS.
- Red cortada lógica o físicamente, si el error de las aplicación está en una red separada no se ve impactada por la falla.
Una configuración de alta disponibilidad no es una buena solución para lo siguiente:
- Escalar. Mientras que puede 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 aparato principal. Para obtener más informació, consulta "Acerca de la replicación geográfica."
- Generar copias de seguridad de tu aparato 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 del tiempo de inactividad en 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 obtener más informació, consulta "Acerca de la replicación geográfica."
Balanceador 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 subdominio está habilitado, un registro comodín adicional (*.HOSTNAME) también se debería resolver con el balanceador de carga. Para obtener más información, consulta "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 obtener más información, consulta "Utilizar GitHub Enterprise Server con un balanceador de carga."
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
Utilidades para la administración de la replicación
Para administrar la replicación en GitHub Enterprise Server, haz uso de estas utilidades de la línea de comando conectándote al aparato réplica con SSH.
ghe-repl-setup
El comando ghe-repl-setup coloca un aparato GitHub Enterprise Server en modo de espera de réplica.
- Un tunel de VPN de WireGuard cifrado se configura para establecer la comunicación entre los dos aplicativos.
- Se configuran los servicios de bases de datos para la replicación y se inician.
- Se inhabilitan los servicios de aplicaciones. Los intentos de acceder al aparato réplica por HTTP, Git u otros protocolos compatibles generarán una página de mantenimiento o un mensaje de error de "aparato en modo réplica".
admin@169-254-1-2:~$ ghe-repl-setup 169.254.1.1
Verificar la conectividad ssh con 169.254.1.1 ...
Comprobación de conexión exitosa.
Configurando la replicación de base de datos en oposición al principal...
Success: Replica mode is configured against 169.254.1.1.
To disable replica mode and undo these changes, run `ghe-repl-teardown'.
Ejecuta `ghe-repl-start' para comenzar la replicación en oposición al principal recientemente configurado.ghe-repl-start
El comando ghe-repl-start inicia la replicación activa de todos los almacenes de datos.
admin@169-254-1-2:~$ ghe-repl-start
Starting MySQL replication ...
Iniciando la replicación de Redis...
Iniciando la replicación de ElasticSearch...
Iniciando la replicación de Páginas...
Iniciando la replicación de Git...
Exitoso: La replicación se está ejecutando para todos los servicios.
Utiliza `ghe-repl-status' para monitorear el estado y el progreso de la replicación.ghe-repl-status
El comando ghe-repl-status muestra un estado de OK, ADVERTENCIA o CRÍTICO para cada corriente de replicación de almacén de datos. Cuando cualquiera de los canales de replicación está en estado ADVERTENCIA, el comando se cerrará con el código 1. Del mismo modo, cuando cualquiera de los canales esté en un estado CRÍTICO, el comando se cerrará con el código 2.
admin@169-254-1-2:~$ ghe-repl-status
OK: replicación de mysql en sinc
OK: la replicación de redis está en sinc
OK: la agrupación de elasticsearch está en sinc
OK: los datos de git están en sinc (10 repos, 2 wikis, 5 gists)
OK: los datos de páginas están en sincLas opciones -v y -vv dan detalles sobre cada uno de los estados de replicación de almacén de datos:
$ ghe-repl-status -v
OK: replicación de mysql en sinc
| IO en ejecución: Sí, SQL en ejecución: Sí, Demora: 0
OK: la replicación de redis está en sinc
| master_host:169.254.1.1
| master_port:6379
| master_link_status:up
| master_last_io_seconds_ago:3
| master_sync_in_progress:0
OK: la agrupación de elasticsearch está en sinc
| {
| "cluster_name" : "github-enterprise",
| "status" : "green",
| "timed_out" : falso,
| "number_of_nodes" : 2,
| "number_of_data_nodes" : 2,
| "active_primary_shards" : 12,
| "active_shards" : 24,
| "relocating_shards" : 0,
| "initializing_shards" : 0,
| "unassigned_shards" : 0
| }
OK: los datos de git están en sinc (366 repos, 31 wikis, 851 gists)
| TOTAL OK FALLA PENDIENTE CON DEMORA
| repositorios 366 366 0 0 0.0
| wikis 31 31 0 0 0.0
| gists 851 851 0 0 0.0
| total 1248 1248 0 0 0.0
OK: los datos de páginas están en sinc
| Las páginas están en sincghe-repl-stop
El comando ghe-repl-stop inhabilita temporalmente la replicación de todos los almacenes de datos y detiene los servicios de replicación. Para reanudar la replicación, utiliza el comando ghe-repl-start.
admin@168-254-1-2:~$ ghe-repl-stop
Deteniendo la replicación de Páginas...
Deteniendo la replicación de Git...
Deteniendo la replicación de MySQL...
Deteniendo la replicación de Redis...
Deteniendo la replicación de ElasticSearch...
Exitoso: la replicación se detuvo para todos los servicios.ghe-repl-promote
El comando ghe-repl-promote inhabilita la replicación y convierte el aparato réplica en principal. El aparato se configura con los mismos ajustes que el principal original y se habilitan todos los servicios.
Promover una réplica no configura la replicación para aplicativos existentes automáticamente. Despues de promoverla, si así lo quieres, puedes configurar la replicacion desde el nuevo aplicativo principal hacia uno existente y hacia el aplicativo primario previo.
admin@168-254-1-2:~$ ghe-repl-promote
Habilitando el modo de mantenimiento en el aparato principal para evitar escrituras...
Deteniendo la replicación...
| Deteniendo la replicación de Páginas...
| Deteniendo la replicación de Git...
| Deteniendo la replicación de MySQL...
| Deteniendo la replicación de Redis...
| Deteniendo la replicación de ElasticSearch...
| Exitoso: la replicación se detuvo para todos los servicios.
Cambiando del modo réplica...
| Exitoso: se eliminó la configuración de la replicación.
| Ejecuta `ghe-repl-setup' para volver a habilitar el modo réplica.
Aplicando la configuración e iniciando los servicios...
Exitoso: la réplica se promovió a principal y ahora está aceptando solicitudes.ghe-repl-teardown
El comando ghe-repl-teardown inhabilita el modo de replicación por completo, eliminando la configuración de la réplica.