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

Agregue nodos al centro de datos de alta disponibilidad (HA) principal. Esto está pensado para descargar tareas intensivas de CPU desde el nodo principal, lo que permite el escalado horizontal de la GitHub Enterprise Server instancia.

En este artículo

Para GitHub Enterprise Server los clientes que buscan escalar horizontalmente, la migración a un clúster y el funcionamiento de un clúster es una opción, pero requiere mucho 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 GitHub Enterprise Server dispositivo, 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 que ejecuta el GitHub Enterprise Server software. 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:

Shell
/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:

Shell
/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:

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

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

Se recomienda una ventana de mantenimiento para agregar nodos sin estado.

Eliminación de un nodo adicional

Antes de retirar un nodo adicional, instale en cada nodo del despliegue de alta disponibilidad el mismo parche más reciente correspondiente a su versión de funcionalidad y programe una ventana de mantenimiento. Espere a que finalice cualquier actualización o ejecución de configuración antes de iniciar la eliminación.

  1. En el nodo principal de HA, compruebe el estado de cada nodo de la implementación de HA.

    Shell
    ghe-cluster-nodes
ghe-cluster-nodes --offline
nomad node status
ghe-cluster-status --extended --verbose

    Confirme que ambos ghe-cluster-nodes comandos enumeran los mismos nombres de host e incluyen el nombre de host del nodo que planea quitar. Confirme que cada nodo tiene el estado de Nomad ready y que connect-ssh y enterprise-version son ok para cada nodo. Confirme que los servicios con estado principales y las réplicas, si las hay, están en buen estado. Si no queda ninguna réplica, es de esperar una advertencia de que no se encontró ninguna réplica de MySQL. Los errores limitados a cargas de trabajo web, trabajo o memcache en el destino no bloquean la eliminación. Si falla cualquier otra comprobación a nivel de nodo o del servicio con estado, póngase en contacto con Soporte de GitHub antes de retirarlo.

  2. En el nodo principal de alta disponibilidad, quite el nodo adicional. Reemplace por HOSTNAME el nombre de host del nodo adicional.

    Shell
    ghe-remove-node --verbose HOSTNAME

    Si queda otro nodo no principal, el comando vacía el nodo de destino, lo elimina de la configuración de alta disponibilidad y ejecuta ghe-config-apply. Si no permanece ningún nodo no principal, el comando quita los metadatos del clúster y convierte la principal en una instancia independiente sin ejecutar ghe-config-apply. No ejecutar ghe-config-apply por separado en ninguno de los dos casos.

  3. Compruebe la eliminación.

    Si queda otro nodo no principal, ejecute los siguientes comandos en el nodo principal de alta disponibilidad. Compruebe que el nombre de host no esté presente y que la configuración de HA esté en buen estado.

    Shell
    ghe-cluster-nodes --offline
ghe-cluster-status --extended --verbose

    Si no permanece ningún nodo no principal, no ejecute los comandos de solo clúster. Confirme que la salida de eliminación contiene Cluster artifacts removed; now standalone.y confirme que el servidor principal atiende el tráfico de usuario y procesa las cargas de trabajo y web.

Si un nodo adicional está sin conexión, es inaccesible o tiene una versión diferente, o si falla ghe-remove-node o una comprobación de verificación, póngase en contacto con Soporte de GitHub. No edite cluster.conf manualmente.

Volver a aprovisionar un nodo que anteriormente alojaba GitHub Enterprise Server

Puede usar un nodo que se hospedó y ejecutó GitHub Enterprise Server previamente como un 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:

Shell
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 las réplicas permanecen sin cambios.

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.