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 primario de alta disponibilidad (HA), compruebe el estado de cada nodo de la implementación de alta disponibilidad.

    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 en el primario y en cualquier réplica se encuentran 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 fallos limitados a cargas de trabajo web, de tareas o de memcache en el destino no bloquean la eliminación. Si falla cualquier otra comprobación en el nivel de nodo o de servicio con estado, ponte en contacto con Soporte de GitHub antes de la eliminación.

  2. En el nodo primario de HA, elimina 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. Comprueba que el mensaje de eliminación contenga Cluster artifacts removed; now standalone. y, a continuación, verifica que el nodo primario atienda el tráfico de los usuarios y procese las cargas de trabajo web y de tareas.

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