Adición de nodos a una configuración de alta disponibilidad

Para los clientes de GitHub Enterprise Server que buscan escalar horizontalmente, migrar y operar un clúster es una opción, pero requiere muchos recursos y consume mucho tiempo. Como alternativa, se recomienda agregar nodos a una configuración de alta disponibilidad.

Los términos "nodo adicional" y "nodo sin estado" se usan indistintamente en este artículo. Los nodos sin estado solo pueden agregarse a las implementaciones de alta disponibilidad que contienen al menos una réplica.

Nodos adicionales

De todos los servicios que se ejecutan en un dispositivo GitHub Enterprise Server , Unicorn suele ser el más intensivo de CPU y memoria, seguido de Aqueduct, Git y MySQL. Dado que Unicorn y Aqueduct son servicios sin estado, son adecuados para el escalado horizontal y se pueden ejecutar en un conjunto independiente de nodos. Los servicios restantes pueden seguir funcionando con una sola instancia por centro de datos.

Los nodos adicionales permiten escalar las cargas de trabajo web y de trabajo horizontalmente. También pueden descargar Unicorn y Aqueduct desde el nodo principal, liberando considerables recursos de proceso y memoria para los servicios con estado restantes. Si experimenta interrupciones relacionadas con el rendimiento debido al uso elevado de CPU por instancias de Unicorn, se recomienda agregar nodos adicionales. No hay restricciones significativas en el número de estos nodos que puede agregar dentro de un centro de datos.

Criterios

Si experimenta un rendimiento degradado debido a un nodo principal sobrecargado en una configuración de alta disponibilidad, debe considerar la posibilidad de agregar nodos adicionales al entorno de alta disponibilidad. Al escalar los roles web y de trabajo horizontalmente más allá del nodo principal, estos nodos adicionales pueden ayudar a reducir la carga en el host principal.

Por ejemplo, si observa trabajos pendientes en las colas de Unicorn o Aqueduct, o experimenta otros tipos de contención de recursos, debería considerar este enfoque. Incluso si no hay cola visible, quedarse sin CPU en el nodo principal es otra señal clara. En estos casos, puede agregar nodos adicionales y reducir el número de trabajos por nodo, por lo que el nodo principal controla menos la carga de trabajo general.

Adición de un nodo

Cada nodo que agregue a una implementación de alta disponibilidad es una máquina virtual (VM) que ejecuta el software GitHub Enterprise Server. Debe ejecutar el mismo software que el principal. Por lo general, un nodo sin estado no necesita coincidir con las especificaciones de memoria, CPU o almacenamiento principal. Sin embargo, tanto el nodo sin estado como la instancia principal requieren conectividad de submilisegundos. Los requisitos de conectividad para las réplicas permanecen sin cambios.

Para agregar nodos al centro de datos principal en una configuración de alta disponibilidad, use el ghe-add-node comando . El ghe-add-node comando configura el dispositivo actual como un nodo dentro de la implementación de alta disponibilidad y está pensado para descargar tareas intensivas de CPU desde el nodo de datos principal, lo que permite el escalado horizontal. Estos nodos están diseñados para controlar las cargas de trabajo y web, lo que permite una distribución y administración de cargas de trabajo más eficaces. Este comando toma la forma:

/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

/usr/local/share/enterprise/ghe-add-node PRIMARY_IP [--hostname HOSTNAME]

•         `PRIMARY_IP`: la dirección IP del nodo principal.
  

•         `HOSTNAME` (opcional): nombre de host deseado para el host agregado.
  

Por ejemplo, para agregar un nodo con el nombre de host ghes-node-1 a la instancia principal de alta disponibilidad con dirección IP 192.168.1.1 en el centro de datos principal de alta disponibilidad, ejecutaría el siguiente comando:

/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

/usr/local/share/enterprise/ghe-add-node 192.168.1.1 --hostname ghes-node-1

A continuación, en el nodo principal, debe ejecutar los siguientes comandos:

ghe-config-apply
ghe-cluster-balance rebalance --yes

ghe-config-apply
ghe-cluster-balance rebalance --yes

El ghe-config-apply comando es un requisito para agregar nodos sin estado.

Para la versión preliminar pública, no hemos probado específicamente el tiempo de inactividad y no está claro si se requiere una ventana de mantenimiento.

Eliminación de un nodo adicional

Para quitar un nodo, ejecute ghe-remove-node desde el nodo que desea quitar. A continuación, en el nodo principal, debe ejecutar:

ghe-config-apply

ghe-config-apply

El ghe-config-apply comando es un requisito para quitar nodos sin estado.

Para la versión preliminar pública, no hemos probado específicamente el tiempo de inactividad y no está claro si se requiere una ventana de mantenimiento.

Volver a aprovisionar un nodo que anteriormente hospedó GitHub Enterprise Server

Puede usar un nodo que previamente hospedó y ejecutó GitHub Enterprise Server como nodo sin estado. Para ello, el nodo debe actualizarse a la versión 3.18 o superior y todos los nodos de la implementación deben ejecutar la misma versión. En ese nodo, compruebe si /data/user/common/cluster.conf ya existe. Si lo hace, deberá realizar la limpieza antes de ejecutar el comando ghe-add-node en el nodo sin estado.

Por ejemplo:

sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

sudo rm -f /etc/github/cluster /data/user/common/cluster.conf
sudo timeout -k4 10 systemctl stop wireguard 2>/dev/null || sudo ip link delete tun0 || true

Límites y comportamiento

No hay ningún límite teórico para el número de nodos que se pueden agregar. Sin embargo, en la práctica, agregar demasiados nodos puede causar problemas y afectar a la estabilidad o el rendimiento. En este momento, los nodos recién agregados procesarán un conjunto predefinido de tareas. No puede elegir qué tipo de tareas se descargan. El nodo adicional puede procesar todas las API.

Si una operación de Git está en la ruta, hay lógica para procesar las operaciones de Git solo en el nodo principal. El nodo adicional no controla las operaciones de Git. Por ejemplo, la eliminación de ramas es una operación de Git y no la controlará el nodo sin estado.

Los nodos sin estado no ejecutan cargas de trabajo de Elasticsearch, pero ejecutan kafka-lite.

Requisitos de sistema y redes

Por lo general, los nodos sin estado no necesitan coincidir con las especificaciones de memoria, CPU y almacenamiento del nodo principal. Los requisitos del sistema deben tener en cuenta el consumo de recursos existente de servicios web y de trabajo en el nodo principal y si el nodo principal descargará completamente esas cargas de trabajo en el nuevo nodo.

El nodo sin estado y la instancia principal requieren conectividad de submilisegundos. Por lo general, todos los nodos del centro de datos principal requieren conectividad de submilisegundos. Los requisitos de conectividad para la réplica no han cambiado.

Enrutamiento del tráfico y control de solicitudes

Principal enruta el tráfico a los nodos adicionales. En el caso de varios nodos sin estado, el primario envía nuevas conexiones al servidor con menos conexiones activas en ese momento.

Actualización de una implementación de alta disponibilidad con nodos adicionales

A continuación se muestra una secuencia de actualización de ejemplo:

• Inicie la ventana de mantenimiento.
• Detenga las réplicas.
• Actualice los nodos sin estado en paralelo.
• Actualice el nodo principal.
• Actualice las réplicas. Se pueden actualizar en paralelo o secuencialmente en función de las preferencias de recuperación ante desastres.
• Iniciar réplicas.
• Quite la ventana de mantenimiento.

Los nodos adicionales no deben provocar tiempo de inactividad adicional durante las actualizaciones.

Comportamiento de conmutación por error y recuperación ante desastres

No es necesario "anular" nodos adicionales, ya que no contienen ningún dato.

Durante la conmutación por error, el nodo de réplica se quita de la implementación original y se convierte en un nodo independiente. Los nodos sin estado deben volver a vincularse a la réplica promovida, tal como se vuelven a adjuntar réplicas adicionales tras una conmutación por error.

Si el nodo principal es funcional y desea promover una réplica para que sea principal, debe quitar los nodos sin estado del principal con el ghe-remove-node comando , antes de volver a agregarlos al nodo promocionado.

Si el nodo principal no es accesible e irrecuperable, los nodos sin estado se pueden volver a agregar sin quitarlos del nodo principal original.

Supervisión, registros y paquetes de soporte

En el nodo principal, los paneles de supervisión de la Consola de administración muestran métricas para todos los nodos, incluidos los nodos sin estado. Comandos como ghe-cluster-nodes y ghe-cluster-status contienen detalles sobre nodos sin estado. El nodo principal atiende todas las solicitudes de la Consola de administración.

Los registros se almacenan localmente en los nodos sin estado. Se pueden exportar desde estos nodos a servicios de administración de registros de terceros.

Puede usar los ghe-cluster-support-bundle comandos y ghe-support-bundle para generar y cargar paquetes de clúster o de un solo nodo.

Limitaciones conocidas

Esta característica no está diseñada para monorepositorios, pero la adición de nuevos nodos sin estado puede mejorar indirectamente las operaciones de monorepositorio al reducir las cargas de trabajo en la web y en los trabajos en el nodo principal. No hay características de autoscalado ni reducción de escala.