Acerca de la replicación de disponibilidad alta para clústers
Puedes configurar el despliegue de un clúster de GitHub Enterprise Server para que tenga disponibilidad alta, mientras que un conjunto idéntico de nodos pasivos se sincroniza con los nodos en tu 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 el modo de alta disponibilidad, cada nodo activo se sincroniza regularmente con un nodo pasivo correspondiente. El nodo pasivo se ejecuta en espera y no sirve a las aplicaciones ni procesa solicitudes de usuarios.
Te recomendamos configurar la disponibilidad alta como parte de un plan integral de recuperación de desastres para GitHub Enterprise Server. También te recomendamos realizar respaldos constantemente. Para obtener más información, consulta "Configurar copias de seguridad en tu aparato"
Prerrequisitos
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 11 nodos y cada nodo tiene 12 vCPUs, 96 GB de RAM, y 750 GB de almacenamiento adjunto, deberás aprovisionar 11 máquinas virtuales en donde cada una tenga 12 vCPUs, 96 GB de RAM, y 750GB 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, consulta "Configurar una instancia del GitHub Enterprise Server."
Nota: Los nodos que pretendes utilizar para la replicación de disponibilidad alta deben ser instancias independientes de GitHub Enterprise Server. No inicialices los nodos pasivos 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.
No te recomendamos configurar un firewall entre la red con con tu clúster activo y aquella con tu clúster pasivo. Lalatencia entre las redes con nodos activos y aquellas con nodos pasivos debe ser de menos de 70 milisegundos. Para obtener más información acerca de la conectividad de red entre nodos en el clúster pasivo, consulta la sección "Configuración de clúster de red".
Crear una réplica de disponibilidad alta para un clúster
- Asignar nodos activos al datacenter primario
- Agregar nodos pasivos al archivo de configuración de clúster
- Ejemplo de configuración
Asignar nodos activos al datacenter primario
Antes de que definas un datacenter secundario para tus nodos pasivos, asegúrate de que has asignado tus nodos activos al datacenter primario.
-
Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, consulta "Acceder al shell administrativo (SSH)."
-
En un editor de texto, abre el archivo de configuración de clúster ubicado en /data/user/common/cluster.conf. Por ejemplo, puedes utilizar Vim.
sudo vim /data/user/common/cluster.conf
-
Observa el nombre del datacenter primario de tus clústers. La sección de
[cluster]
en la parte superior del archivo de configuración del clúster define el nombre del datacenter primario, utilizando el par de clave-valorprimary-datacenter
. Predeterminadamente, el datacenter primario para tu clúster se llamadefault
.[cluster] mysql-master = HOSTNAME redis-master = HOSTNAME primary-datacenter = default
- Opcionalmente, cambia el nombre del datacenter primario a uno más descriptivo o preciso editando el valor de
primary-datacenter
.
- Opcionalmente, cambia el nombre del datacenter primario a uno más descriptivo o preciso editando el valor de
-
El archivo de configuración de clúster lista cada nodo bajo un encabezado de
[cluster "HOSTNAME"]
. Debajo del encabezado de cada nodo, agrega un par de clave-valor para asignar el nodo a un datacenter. Utiliza el mismo valor queprimary-datacenter
desde el paso 3 en adelante. Por ejemplo, si quieres utilizar el nombre predeterminado (default
), agrega el siguiente par de clave-valor a la sección para cada nodo.datacenter = default
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 ... ...
Nota: Si cambiaste el nombre del datacenter primario en el paso 3, encuentra el par de clave-valor para
consul-datacenter
en la sección para cada nodo y cambia el valor al datacenter primario que renombraste. Por ejemplo, si nombraste al datacenter primario comoprimary
, utiliza el siguiente par de clave-valor para cada nodo.consul-datacenter = primary
-
Aplica la configuración nueva. Este comando puede demorar un poco en finalizar, así que recomendamos ejecutar el comadno 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.
Configuración de clúster finalizada
Después de que GitHub Enterprise Server te regrese al prompt, habrás terminado de asignar tus nodos al datacenter primario del clúster.
Agregar nodos pasivos al archivo de configuración de clúster
Para configurar la disponibilidad alta, debes definir un nodo pasivo correspondiente para cada nodo activo en tu clúster. Con las siguientes instrucciones se crea una configuración de clúster nueva que define tanto los nodos activos como los pasivos. Lo que harás:
- Crear una copia del archivo de configuración del clúster activo.
- Editar la copia para definir los nodos pasivos 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 un ejemplo de configuración, consulta la sección "Ejemplo de configuración".
-
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, consulta la sección "Prerrequisitos".
Nota: Si estás reconfigurando la disponibilidad alta después de una recuperación de un fallo, puedes utilizar los nodos viejos del datacenter primario en su lugar.
-
Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, consulta "Acceder al shell administrativo (SSH)."
-
Respalda tu configuración de clúster existente.
cp /data/user/common/cluster.conf ~/$(date +%Y-%m-%d)-cluster.conf.backup
-
Crea una copia de tu archivo de configuración de clúster en una ubicación temporal, como /home/admin/cluster-passive.conf. Borra los pares únicos de clave-valor para las direcciones IP (
ipv*
), las UUID (uuid
), y las llaves públicas para WireGuard (wireguard-pubkey
).grep -Ev "(?:|ipv|uuid|vpn|wireguard\-pubkey)" /data/user/common/cluster.conf > ~/cluster-passive.conf
-
Elimina la sección de
[cluster]
del archivo temporal de configuración de clúster que copiaste en el paso anterior.git config -f ~/cluster-passive.conf --remove-section cluster
-
Asigna un nombre para el datacenter secundario en donde aprovisionaste tus nodos pasivos, luego actualiza el archivo temporal de configuración de clúster con el nombre nuevo del datacenter. Reemplaza
SECONDARY
con el nombre que elegiste.sed -i 's/datacenter = default/datacenter = SECONDARY/g' ~/cluster-passive.conf
-
Asigna un patrón para los nombres de host del nodo pasivo.
Advertencia: Los nombres de host para los nodos pasivos deben ser únicos y diferir del nombre de host para el nodo activo correspondiente.
-
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-passive.conf
-
En cada sección dentro del archivo temporal de configuración del clúster, actualiza la configuración del nodo. El archivo de configuración de clúster lista cada nodo bajo un encabezado de
[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 pasivo, de acuerdo con el patrón que elegiste en el paso 7 antes mencionado. - Agrega una nueva clave llamada
ipv4
, y configura el valor como la dirección IPv4 estática del nodo pasivo. - Agrega un par de clave-valor nuevo,
replica = enabled
.
[cluster "NEW PASSIVE NODE HOSTNAME"] ... hostname = NEW PASSIVE NODE HOSTNAME ipv4 = NEW PASSIVE NODE IPV4 ADDRESS replica = enabled ... ...
- Cambia el nombre de host citado en el encabezado de la sección y el valor de
-
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-passive.conf >> /data/user/common/cluster.conf
-
Designa los nodos de Redis y de MySQL en el datacenter secundario. Reemplaza
REPLICA MYSQL PRIMARY HOSTNAME
yREPLICA REDIS PRIMARY HOSTNAME
con los nombres de host de los nodos pasivos que aprovisionaste para que empaten con tus primarios existentes de MySQL y de Redis.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
Advertencia: Revisa tu archivo de configuración de clúster antes de proceder.
- En la sección de
[cluster]
de nivel superior, asegúrate de que los valores paramysql-master-replica
y pararedis-master-replica
sean los nombres de host correctos para los nodos pasivos en el datacenter secundario que servirán como los primarios de MySQL y de Redis después de una conmutación por error. - En cada sección para un nodo activo que se llame
[cluster "<em>ACTIVE NODE HOSTNAME</em>"]
, vuelve a revisar los siguientes pares de clave-valor.datacenter
debería coincidir con el valor deprimary-datacenter
en la sección de[cluster]
de nivel superior.consul-datacenter
debería coincidir con el valor dedatacenter
, cl cual debería ser el mismo valor paraprimary-datacenter
en la sección de[cluster]
de nivel superior.
- Asegúrate de que, para cada nodo activo, la configuración tenga una sección correspondiente para un nodo pasivo con los mismos roles. En cada sección para un nodo pasivo, verifica nuevamente cada par de clave-valor.
datacenter
debería coincidir con todo el resto de los nodos pasivos.consul-datacenter
debería coincidir con todo el resto de los nodos pasivos.hostname
debería coincidir con el nombre de host en el encabezado de la sección.ipv4
debería coincidir con la dirección IPv4 estática única del nodo.replica
debería estar configurado comoenabled
.
- Aprovecha la oportunidad para eliminar las secciones para los nodos sin conexión que ya no se utilicen.
Para revisar un ejemplo de configuración, consulta la sección "Ejemplo de configuración".
- En la sección de
-
Inicializa la configuración del clúster nuevo. Este comando puede demorar un poco en finalizar, así que recomendamos ejecutar el comadno en un multiplexor de terminal como
screen
otmux
.ghe-cluster-config-init
-
Después de que ésta termine, GitHub Enterprise Server mostrará el siguiente mensaje.
Finished cluster initialization
-
Aplica la configuración nueva. Este comando puede demorar un poco en finalizar, así que recomendamos ejecutar el comadno 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.
Configuración de clúster finalizada
-
Configura un balanceador de carga que aceptará las conexiones de los usuarios si conmutas por error a los nodos pasivos. Para obtener más información, consulta la sección "Configuración de red de clúster".
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 pasivo correspondiente, y puedes dirigir el tráfico al balanceador de carga para el datacenter secundario en caso de que exista un fallo. Para obtener más información sobre la conmutación por error, consulta la sección "Iniciar una conmutación por error a tu clúster de réplica".
Ejemplo de configuración
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 PASSIVE MYSQL MASTER
redis-master-replica = HOSTNAME OF PASSIVE 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
vpn = IPV4 ADDRESS SET AUTOMATICALLY
uuid = UUID SET AUTOMATICALLY
wireguard-pubkey = PUBLIC KEY SET AUTOMATICALLY
...
La configuración para el nodo pasivo correspondiente en el nivel de almacenamiento se debería ver como en el ejemplo siguiente.
- Las diferencias importantes con nodo activo correspondiente estarán restaltadas.
- GitHub Enterprise Server asigna valores para
vpn
,uuid
, ywireguard-pubkey
automáticamente, así que no deberías definir los valores para los nodos pasivos que vayas a inicializar. - Los roles del servidor, como se definen en las claves de
*-server
, coinciden con el nodo activo correspondiente.
...
[cluster "UNIQUE PASSIVE NODE HOSTNAME"]
replica = enabled
ipv4 = IPV4 ADDRESS OF NEW VM WITH IDENTICAL RESOURCES
datacenter = SECONDARY DATACENTER NAME
hostname = UNIQUE PASSIVE 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
vpn = DO NOT DEFINE
uuid = DO NOT DEFINE
wireguard-pubkey = DO NOT DEFINE
...
Monitorear la replicación entre los nodos de clúster pasivos y activos
La replicación inicial entre los nodos activos y pasivos 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 acerca del shell administrativo, consulta la sección "Acceder al shell administrativo (SSH)".
-
Monitorear la replicación de bases de datos:
/usr/local/share/enterprise/ghe-cluster-status-mysql
-
Monitorear la replicación de los datos de los repositorios y los Gists:
estado ghe-spokes
-
Monitorear la replicación de los adjuntos y los datos de LFS:
ghe-storage replication-status
-
Monitorear la replicación de los datos de las páginas:
ghe-dpages replication-status
Puedes utilizar ghe-cluster-status
para revisar la salud general de tu clúster. Para obtener más información, consulta la sección "Utilidades de la línea de comandos".
Reconfigurar la replilcación de disponibilidad alta después de un fallo
Después de que te recuperes de un fallo de los nodos activos del clúster hacia los nodos pasivos, puedes reconfigurar la replicación de disponibilidad alta en dos formas.
Aprovisionar y configurar los nodos pasivos nuevos
Después de recuperarte de un fallo, puedes reconfigurar la disponibilidad alta 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 pasivos para cada uno de los nodos activos en tu datacenter secundario.
-
Utiliza los nodos activos antiguos como los nodos pasivos 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 la sección "Crear una réplica de disponibilidad alta para un clúster".
Inhabilitar la replicación de disponibilidad alta para un clúster
Pudes parar la replicación hacia los nodos pasivos para el despliegue de GitHub Enterprise Server de tu clúster.
-
Ingresa por SSH a cualquier nodo dentro de tu clúster. Para obtener más información, consulta "Acceder al shell administrativo (SSH)."
-
En un editor de texto, abre el archivo de configuración de clúster ubicado en /data/user/common/cluster.conf. Por ejemplo, puedes utilizar Vim.
sudo vim /data/user/common/cluster.conf
-
En la sección de
[cluster]
de nivel superior, borra los pares de clave-valor deredis-master-replica
ymysql-master-replica
. -
Borra cada sección para un nodo pasivo. Para los nodos pasivos,
replica
se configura comoenabled
. -
Aplica la configuración nueva. Este comando puede demorar un poco en finalizar, así que recomendamos ejecutar el comadno 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.
Configuración de clúster finalizada
Después de que GitHub Enterprise Server te regrese al prompt, habrás terminado de inhabilitar la replicación de disponibilidad alta.