Esta versión de GitHub Enterprise Server se discontinuó el 2024-09-25. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Configurar la replicación con disponibilidad alta para un clúster

Puedes configurar una réplica de todo tu clúster de GitHub Enterprise Server en un centro de datos diferente, lo cual le permitirá tolerar fallos en nodos redundantes.

En este artículo

Acerca de la replicación de disponibilidad alta para clústers

Puedes proporcionar protección contra interrupciones en un centro de datos o una región de la nube mediante la configuración de una implementación de clúster de GitHub Enterprise Server para lograr una alta disponibilidad. En una configuración de alta disponibilidad, un conjunto idéntico de nodos de réplica se sincroniza con los nodos del clúster activo. Si las características de hardware o software afectan el centro de datos que alberga tu clúster activo, puedes hacer una recuperación de fallos manual a los nodos de réplica y seguir procesando las solicitudes de los usuarios, minimizando así el impacto del servicio interrumpido.

En una configuración de alta disponibilidad, los nodos que hospedan servicios de datos se sincronizan periódicamente con el clúster de réplicas. Los nodos de réplica se ejecutan en espera y no sirven a las aplicaciones ni procesan solicitudes de usuarios.

Te recomendamos configurar la disponibilidad alta como parte de un plan integral de recuperación de desastres para clúster de GitHub Enterprise Server. También te recomendamos realizar respaldos constantemente. Para más información, consulta Configuración de copias de seguridad en la instancia.

Requisitos previos

Hardware y software

Para cada nodo existente en tu clúster activo, necesitarás aprovisionar una segunda máquina virtual con recursos de hardware idénticos. Por ejemplo, si tu clúster tiene 13 nodos y cada nodo tiene 12 vCPUs, 96 GB de RAM, y 750 GB de almacenamiento adjunto, deberás aprovisionar 13 máquinas virtuales en donde cada una tenga 12 vCPUs, 96 GB de RAM, y 750 GB de almacenamiento adjunto.

En cada máquina virtual, instala la misma versión de GitHub Enterprise Server que se ejecuta en los nodos en tu clúster activo. No necesitas cargar una licencia ni realizar alguna configuración adicional. Para más información, consulta Configurar una instancia del servidor de GitHub Enterprise.

Note

Los nodos que pretendes utilizar para la replicación de alta disponibilidad deben ser instancias independientes de GitHub Enterprise Server. No inicialices los nodos de réplica como un segundo clúster.

Red

Debes asignar una dirección IP estática a cada nodo nuevo que aprovisiones, y debes configurar un balanceador de carga para aceptar las conecciones y dirigirlas a los nodos que están a nivel del front-end de tu clúster.

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 obtener más información sobre la conectividad de red entre los nodos del clúster de réplica, consulta Configuración de la red de agrupaciones.

Crear una réplica de disponibilidad alta para un clúster

Para crear una réplica de alta disponibilidad para el clúster, debe completar las siguientes tareas. También puede revisar una configuración de ejemplo.

  1. Asignación de nodos activos al centro de datos primario.
  2. Adición de nodos de réplica al archivo de configuración del clúster.
  3. Revisión de una configuración de ejemplo.

1. Asigne nodos activos al datacenter primario

Antes de que definas un centro de datos secundario para tus nodos de réplica, asegúrate de que has asignado tus nodos activos al centro de datos primario.

  1. Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, vea «Acceder al shell administrativo (SSH)».

  2. Abra el archivo de configuración del clúster en /data/user/common/cluster.conf en un editor de texto. Por ejemplo, puedes utilizar Vim. Cree una copia de seguridad del archivo cluster.conf antes de editarlo.

    Shell
    sudo vim /data/user/common/cluster.conf

  3. Observa el nombre del datacenter primario de tus clústers. La sección [cluster] de la parte superior del archivo de configuración del clúster define el nombre del centro de datos principal, mediante el par clave-valor primary-datacenter.

    [cluster]
  mysql-master = HOSTNAME
  redis-master = HOSTNAME
  primary-datacenter = primary
    • Opcionalmente, puedes cambiar el nombre del centro de datos principal por uno más descriptivo o preciso editando el valor de primary-datacenter.

  4. En el archivo de configuración del clúster se enumera cada nodo bajo un título [cluster "HOSTNAME"]. Debajo del encabezado de cada nodo, agrega un par de clave-valor para asignar el nodo a un datacenter. Usa el mismo valor que primary-datacenter del paso 3 anterior. Por ejemplo, si quieres utilizar el nombre predeterminado (default), agrega el siguiente par clave-valor a la sección para cada nodo.

    datacenter = primary

    Cuando hayas terminado, la sección para cada nodo en el archivo de configuración del clúster se debería ver como en el siguiente ejemplo. El órden de los pares de clave-valor no importa.

    [cluster "HOSTNAME"]
  datacenter = default
  hostname = HOSTNAME
  ipv4 = IP-ADDRESS
  ...
...

    Note

    Si has cambiado el nombre del centro de datos principal en el paso 3, busca el par clave-valor consul-datacenter en la sección de cada nodo y cambia el valor al centro de datos principal cuyo nombre ha cambiado. Por ejemplo, si has asignado el nombre primary al centro de datos principal, usa el siguiente par clave-valor para cada nodo.

    consul-datacenter = primary

  5. Aplica la configuración nueva. Este comando puede tardar un tiempo en finalizar, por lo que se recomienda ejecutarlo en un multiplexor de terminal como screen o tmux.

     ghe-cluster-config-apply

  6. Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.

    Finished cluster configuration

Después de que GitHub Enterprise Server te regrese al prompt, habrás terminado de asignar tus nodos al datacenter primario del clúster.

2. Agregue de nodos de réplica al archivo de configuración del clúster

Para configurar la alta disponibilidad, debes definir un nodo pasivo correspondiente para cada nodo de réplica en tu clúster. Para crear una nueva configuración de clúster que defina nodos activos y de réplica, completarás las siguientes tareas.

  • Crear una copia del archivo de configuración del clúster activo.
  • Edita la copia para definir los nodos de réplica que corresponden a los nodos activos, agregando las direcciones IP de las máquinas virtuales nuevas que aprovisionaste.
  • Fusionar la copia modificada de la configuración del clúster con tu configuración activa.
  • Aplicar la configuración nueva para comenzar la replicación.

Para ver una configuración de ejemplo, consulta Revisar una configuración de ejemplo.

  1. Para cada nodo en tu clúster, aprovisiona una máquina virtual coincidente con especificaciones idénticas que ejecute la misma versión de GitHub Enterprise Server. Anota la dirección IPv4 y el nombre de host para cada nodo de clúster nuevo. Para obtener más información, consulte Requisitos previos.

    Note

    Si estás reconfigurando la alta disponibilidad después de una conmutación por error, puedes utilizar los nodos antiguos del centro de datos principal en su lugar.

  2. Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, vea «Acceder al shell administrativo (SSH)».

  3. Respalda tu configuración de clúster existente.

    cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup

  4. Crea una copia de tu archivo de configuración de clúster en una ubicación temporal, como /home/admin/cluster-replica.conf.

    grep -Ev "(?:|ipv|uuid)" /data/user/common/cluster.conf > ~/cluster-replica.conf

  5. Quita la sección de [cluster] del archivo temporal de configuración de clúster temporal que copiaste en el paso anterior.

    git config -f ~/cluster-replica.conf --remove-section cluster

  6. Asigna un nombre para el centro de datos secundario en donde aprovisionaste tus nodos de réplica, luego actualiza el archivo temporal de configuración de clúster con el nombre nuevo del centro dedatos. Reemplaza SECONDARY por el nombre elegido.

    sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-replica.conf

  7. Asigna un patrón para los nombres de host del nodo de réplica.

    Warning

    Los nombres de host para los nodos de réplica deben ser únicos y diferir del nombre de host para el nodo activo correspondiente.

  8. Abre el archivo temporal de configuración de clúster del paso 3 en un editor de texto. Por ejemplo, puedes utilizar Vim.

    sudo vim ~/cluster-replica.conf

  9. En cada sección dentro del archivo temporal de configuración del clúster, actualiza la configuración del nodo. En el archivo de configuración del clúster se enumera cada nodo bajo un título [cluster "HOSTNAME"].

    • Cambia el nombre de host citado en el encabezado de la sección y el valor de hostname dentro de la sección al nombre de host del nodo de réplica, de acuerdo con el patrón que elegiste en el paso 7 anterior.
    • Agrega una nueva clave denominada ipv4 y establece el valor en la dirección IPv4 estática del nodo de réplica.
    • Agrega un nuevo par clave-valor, replica = enabled.
    [cluster "NEW REPLICA NODE HOSTNAME"]
  ...
  hostname = NEW REPLICA NODE HOSTNAME
  ipv4 = NEW REPLICA NODE IPV4 ADDRESS
  replica = enabled
  ...
...

  10. Anexa el contenido del archivo temporal de configuración del clúster que creaste en el paso 4 al archivo de configuración activo.

    cat ~/cluster-replica.conf >> /data/user/common/cluster.conf

  11. Designa los nodos de Redis y de MySQL en el datacenter secundario. Reemplaza REPLICA MYSQL PRIMARY HOSTNAME y REPLICA REDIS PRIMARY HOSTNAME por los nombres de host de los nodos de réplica que has aprovisionado para que coincidan con los principales de MySQL y Redis existentes.

    git config -f /data/user/common/cluster.conf cluster.mysql-master-replica REPLICA-MYSQL-PRIMARY-HOSTNAME
git config -f /data/user/common/cluster.conf cluster.redis-master-replica REPLICA-REDIS-PRIMARY-HOSTNAME

    Warning

    Revisa el archivo de configuración del clúster antes de continuar.

    • En la sección [cluster] de nivel superior, asegúrate de que los valores de mysql-master-replica y redis-master-replica son los nombres de host correctos para los nodos de réplica del centro de datos secundario que servirán como principales de MySQL y Redis después de una conmutación por error.
    • En cada sección de un nodo activo denominado [cluster "ACTIVE NODE HOSTNAME"], vuelve a comprobar los siguientes pares clave-valor.
      • datacenter debe coincidir con el valor de primary-datacenter de la sección [cluster] de nivel superior.
      • consul-datacenter debe coincidir con el valor de datacenter, que debe ser el mismo que el valor de primary-datacenter en la sección [cluster] de nivel superior.
    • Asegúrate de que, para cada nodo activo, la configuración tiene una sección correspondiente para un nodo de réplica con los mismos roles. En cada sección para un nodo de réplica, verifica nuevamente cada par de clave-valor.
      • datacenter debe coincidir con todos los demás nodos de réplica.
      • consul-datacenter debe coincidir con todos los demás nodos de réplica.
      • hostname debe coincidir con el nombre de host del encabezado de sección.
      • ipv4 debe coincidir con la dirección IPv4 estática única del nodo.
      • replica debe configurarse como enabled.
    • Aprovecha la oportunidad para eliminar las secciones para los nodos sin conexión que ya no se utilicen.

    Para revisar una configuración de ejemplo, consulta Revisar una configuración de ejemplo.

  12. Inicializa la configuración del clúster nuevo. Este comando puede tardar un tiempo en finalizar, por lo que se recomienda ejecutarlo en un multiplexor de terminal como screen o tmux.

    ghe-cluster-config-init

  13. Después de que ésta termine, GitHub Enterprise Server mostrará el siguiente mensaje.

    Finished cluster initialization

  14. Aplica la configuración nueva. Este comando puede tardar un tiempo en finalizar, por lo que se recomienda ejecutarlo en un multiplexor de terminal como screen o tmux.

     ghe-cluster-config-apply

  15. Una vez finalizada la ejecución de la configuración, comprueba que la replicación del clúster está configurada y funciona correctamente.

    ghe-cluster-repl-status

  16. Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.

    Finished cluster configuration

  17. Configura un balanceador de carga que aceptará las conexiones de los usuarios después de conmutar por error a los nodos de réplica. Para más información, consulta Configuración de la red de agrupaciones.

Has terminado de configurar la replicación de disponibilidad alta para los nodos en tu clúster. Cada nodo activo comienza a replicar la configuración y los datos a su nodo de réplica correspondiente, y puedes dirigir el tráfico al balanceador de carga para el centro dedatos secundario en caso de que exista un fallo. Para más información sobre la conmutación por error, consulta Inicio de una conmutación por error a tu clúster de réplica.

3. Revise una configuración de ejemplo

La configuración de [cluster] de nivel superior se debería ver como en el ejemplo siguiente.

[cluster]
  mysql-master = HOSTNAME-OF-ACTIVE-MYSQL-MASTER
  redis-master = HOSTNAME-OF-ACTIVE-REDIS-MASTER
  primary-datacenter = PRIMARY-DATACENTER-NAME
  mysql-master-replica = HOSTNAME-OF-REPLICA-MYSQL-MASTER
  redis-master-replica = HOSTNAME-OF-REPLICA-REDIS-MASTER
  mysql-auto-failover = false
...

La configuración para un nodo activo en el nivel de almacenamiento de tu clúster se debería ver como en el ejemplo siguiente.

...
[cluster "UNIQUE ACTIVE NODE HOSTNAME"]
  datacenter = default
  hostname = UNIQUE-ACTIVE-NODE-HOSTNAME
  ipv4 = IPV4-ADDRESS
  consul-datacenter = default
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = UUID SET AUTOMATICALLY
...

La configuración para el nodo de réplica correspondiente en el nivel de almacenamiento se debería ver como en el ejemplo siguiente.

  • Las diferencias importantes con respecto al nodo activo correspondiente se marcan en negrita.
  • GitHub Enterprise Server asigna valores para uuid automáticamente, por lo que no debes definir los valores para los nodos de réplica que inicializarás.
  • Los roles de servidor, definidos mediante claves *-server, coinciden con el nodo activo correspondiente.
...
[cluster "UNIQUE REPLICA NODE HOSTNAME"]
  replica = enabled
  ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
  datacenter = SECONDARY DATACENTER NAME
  hostname = UNIQUE REPLICA NODE HOSTNAME
  consul-datacenter = SECONDARY DATACENTER NAME
  consul-server = true
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true
  uuid = DO NOT DEFINE
...

Supervisión de la replicación entre los nodos de clúster de réplica y activos

La replicación inicial entre los nodos activos y de réplica en tu clúster toma su tiempo. La cantidad de tiempo dependerá de la cantidad de datos a replicar y de los niveles de actividad de GitHub Enterprise Server.

Puedes monitorear el progreso de cualquier nodo en el clúster, utilizando las herramientas de línea de comandos que se encuentran disponibles a través del shell administrativo de GitHub Enterprise Server. Para obtener más información sobre el shell administrativo, consulta Acceder al shell administrativo (SSH).

Para supervisar la replicación de todos los servicios, usa el siguiente comando.

ghe-cluster-repl-status

Puedes usar ghe-cluster-status para revisar el estado general del clúster. Para más información, consulta Utilidades de la ea de comandos.

Reconfigurar la replilcación de disponibilidad alta después de un fallo

Después de recuperarse de un fallo de los nodos activos del clúster hacia los nodos de réplica, puede reconfigurar la alta disponibilidad en dos formas. El método que elijas dependerá de la razón por la cual ocurrió el fallo y del estado de los nodos activos originales.

  • Aprovisiona y configura un conjunto nuevo de nodos de réplica para cada uno de los nodos activos en tu centro de datos secundario.
  • Usa los nodos activos originales como nodos de réplica nuevos.

El proceso para reconfigurar la disponibilidad alta es idéntico a la configuración inicial de la misma. Para obtener más información, consulta Creación de una réplica de alta disponibilidad para un clúster.

Si usa los nodos activos originales, después de volver a configurar la alta disponibilidad, deberá anular el modo de mantenimiento en los nodos. Para más información, consulta Habilitar y programar el modo de mantenimiento.

Inhabilitar la replicación de disponibilidad alta para un clúster

Puede parar la replicación hacia los nodos de réplica para el despliegue de GitHub Enterprise Server.

  1. Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, vea «Acceder al shell administrativo (SSH)».

  2. Abra el archivo de configuración del clúster en /data/user/common/cluster.conf en un editor de texto. Por ejemplo, puedes utilizar Vim. Cree una copia de seguridad del archivo cluster.conf antes de editarlo.

    Shell
    sudo vim /data/user/common/cluster.conf

  3. En la sección [cluster] de nivel superior, elimina los pares clave-valor redis-master-replica y mysql-master-replica.

  4. Borra cada sección para un nodo de réplica. En el caso de los nodos de réplica, replica se configura como enabled.

  5. Aplica la configuración nueva. Este comando puede tardar un tiempo en finalizar, por lo que se recomienda ejecutarlo en un multiplexor de terminal como screen o tmux.

     ghe-cluster-config-apply

  6. Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.

    Finished cluster configuration