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 obtener más información, vea «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 obtener más información, vea «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, use la utilidad ghe-cluster-repl-bootstrap
y complete las tareas de seguimiento que detalla la herramienta.
-
Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, vea «Acceder al shell administrativo (SSH)».
-
Para comenzar la configuración de alta disponibilidad, ejecute el siguiente comando. Las marcas
-p
y-s
son opcionales. Si usa las marcas, reemplace PRIMARY-DATACENTER y SECONDARY-DATACENTER por los nombres de los centros de datos primario y secundario.Note
- De forma predeterminada, la utilidad usará el nombre del centro de datos primario en
cluster.conf
. - Si no se define ningún nombre para el centro de datos primario, la utilidad usará
mona
. - Si no se define ningún nombre para el centro de datos secundario, la utilidad usará
hubot
.
Shell ghe-cluster-repl-bootstrap -p PRIMARY-DATACENTER -s SECONDARY-DATACENTER
ghe-cluster-repl-bootstrap -p PRIMARY-DATACENTER -s SECONDARY-DATACENTER
- De forma predeterminada, la utilidad usará el nombre del centro de datos primario en
-
Una vez que se ejecute la utilidad, verá la salida con instrucciones adicionales. Para finalizar la configuración, complete las tareas indicadas en la salida.
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 obtener más información, vea «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 obtener más información, vea «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 en su clúster usando la utilidad ghe-cluster-repl-teardown
. Como alternativa, puede inhabilitar manualmente la replicación.
Deshabilitación de la replicación usando ghe-cluster-repl-teardown
-
Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, vea «Acceder al shell administrativo (SSH)».
-
Para inhabilitar la replicación, ejecute el comando siguiente:
Shell ghe-cluster-repl-teardown
ghe-cluster-repl-teardown
-
Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.
Finished cluster configuration
Deshabilitación manual de la replicación
-
Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, vea «Acceder al shell administrativo (SSH)».
-
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 archivocluster.conf
antes de editarlo.Shell sudo vim /data/user/common/cluster.conf
sudo vim /data/user/common/cluster.conf
-
En la sección
[cluster]
de nivel superior, elimina los pares clave-valorredis-master-replica
ymysql-master-replica
. -
Borra cada sección para un nodo de réplica. En el caso de los nodos de réplica,
replica
se configura comoenabled
. -
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
otmux
.ghe-cluster-config-apply
-
Después de que finalice la ejecución de configuración, GitHub Enterprise Server muestra el siguiente mensaje.
Finished cluster configuration