Esta versión de GitHub Enterprise Server se discontinuó el 2024-09-25. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Reemplazar un nodo de agrupación

Si se produce un error en un clúster GitHub Enterprise Server, o si deseas agregar un nuevo nodo con más recursos, marca los nodos que quieres reemplazar como sin conexión y agrega el nuevo nodo.

¿Quién puede utilizar esta característica?

GitHub determina la idoneidad para la agrupación en clústeres y debe habilitar la configuración de la licencia de la instancia. La agrupación en clústeres conlleva una planeación cuidadosa y una sobrecarga administrativa adicional. Para obtener más información, vea «Acerca de las agrupaciones».

En este artículo

Acerca de la sustitución de nodos de clúster GitHub Enterprise Server

Puedes reemplazar un nodo funcional en un clúster GitHub Enterprise Server o puedes reemplazar un nodo que ha producido un error inesperado.

Después de reemplazar un nodo, tu instancia de GitHub Enterprise Server no distribuye automáticamente los trabajos al nuevo nodo. Puedes forzar que la instancia equilibre los trabajos entre nodos. Para obtener más información, vea «Reequilibrio de las cargas de trabajo del clúster».

Warning

Para evitar conflictos, no reutilices un nombre de host asignado previamente a un nodo del clúster.

Reemplazar un nodo funcional

Puedes reemplazar un nodo funcional existente en el clúster. Por ejemplo, puede que desee proporcionar a una máquina virtual (VM) recursos adicionales de CPU, memoria o almacenamiento.

Para reemplazar un nodo funcional, instala el dispositivo GitHub Enterprise Server en una nueva máquina virtual, configura una dirección IP, agrega el nuevo nodo al archivo de configuración del clúster, inicializa el clúster y aplica la configuración y, a continuación, desconecta el nodo que has reemplazado.

Note

Si vas a reemplazar el nodo principal de MySQL, consulta "Reemplazo del nodo principal de MySQL".

  1. Aprovisione e instale GitHub Enterprise Server con un nombre de host único en el nodo de reemplazo.

  2. Mediante el shell administrativo o DHCP, configure solo la dirección IP del nodo de reemplazo. No configures los otros parámetros.

  3. Para agregar el nodo de reemplazo recién aprovisionado, en cualquier nodo, cluster.conf para quitar el nodo con error y agregar el de reemplazo. Por ejemplo, este archivo cluster.conf modificado reemplaza ghe-data-node-3 por el nodo recién aprovisionado, ghe-replacement-data-node-3:

    [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    Puede optar por diferir la propagación de la base de datos de un nuevo nodo de réplica de MySQL, lo que da lugar a que el dispositivo pueda abrir el dispositivo antes al tráfico. Para obtener más información, vea «Diferir la propagación de la base de datos».

  4. Desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init. Esto iniciará el nodo recién agregado en la agrupación.

  5. En el mismo nodo, ejecute ghe-cluster-config-apply. Esto validará el archivo de configuración, lo copiará en cada nodo del clúster y configurará cada nodo según el archivo cluster.conf modificado.

  6. Si estás desconectando un nodo que proporciona servicios de datos, como git-server, pages-server o storage-server, evacua el nodo. Para obtener más información, vea «Evacuación de un nodo de clúster que ejecuta servicios de datos».

  7. Para marcar el nodo con errores sin conexión, en cualquier nodo, modifique el archivo de configuración del clúster (cluster.conf) en la sección del nodo correspondiente para incluir el texto offline = true.

    Por ejemplo, este valor cluster.conf modificado marcará el nodo ghe-data-node-3 como sin conexión:

    [cluster "ghe-data-node-3"]
hostname = ghe-data-node-3
offline = true
ipv4 = 192.168.0.6
# ipv6 = fd12:3456:789a:1::6

  8. Desde el shell administrativo del nodo donde ha modificado cluster.conf, ejecute ghe-cluster-config-apply. Esto validará el archivo de configuración, lo copiará en cada nodo de la agrupación y marcará el nodo fuera de línea.

Reemplazar un nodo en una emergencia

Puedes reemplazar un nodo con errores en el clúster. Por ejemplo, un problema de software o hardware puede afectar a la disponibilidad de un nodo.

Note

Si vas a reemplazar el nodo principal de MySQL, consulta "Reemplazo del nodo principal de MySQL".

Para reemplazar un nodo en caso de emergencia, instala el dispositivo GitHub Enterprise Server en una nueva máquina virtual, configura una dirección IP, desconecta el nodo con errores, aplica la configuración, agrega el nuevo nodo al archivo de configuración del clúster, inicializa el clúster y aplica la configuración y, opcionalmente, evacua el nodo con errores.

  1. Aprovisione e instale GitHub Enterprise Server con un nombre de host único en el nodo de reemplazo.

  2. Mediante el shell administrativo o DHCP, configure solo la dirección IP del nodo de reemplazo. No configures los otros parámetros.

  3. Para marcar el nodo con errores sin conexión, en cualquier nodo, modifique el archivo de configuración del clúster (cluster.conf) en la sección del nodo correspondiente para incluir el texto offline = true.

    Por ejemplo, este valor cluster.conf modificado marcará el nodo ghe-data-node-3 como sin conexión:

    [cluster "ghe-data-node-3"]
hostname = ghe-data-node-3
offline = true
ipv4 = 192.168.0.6
# ipv6 = fd12:3456:789a:1::6

  4. Desde el shell administrativo del nodo donde ha modificado cluster.conf, ejecute ghe-cluster-config-apply. Esto validará el archivo de configuración, lo copiará en cada nodo de la agrupación y marcará el nodo fuera de línea.

  5. Para agregar el nodo de reemplazo recién aprovisionado, en cualquier nodo, cluster.conf para quitar el nodo con error y agregar el de reemplazo. Por ejemplo, este archivo cluster.conf modificado reemplaza ghe-data-node-3 por el nodo recién aprovisionado, ghe-replacement-data-node-3:

    [cluster "ghe-replacement-data-node-3"]
  hostname = ghe-replacement-data-node-3
  ipv4 = 192.168.0.7
  # ipv6 = fd12:3456:789a:1::7
  consul-datacenter = PRIMARY-DATACENTER
  git-server = true
  pages-server = true
  mysql-server = true
  elasticsearch-server = true
  redis-server = true
  memcache-server = true
  metrics-server = true
  storage-server = true

    Puede optar por diferir la propagación de la base de datos de un nuevo nodo de réplica de MySQL, lo que da lugar a que el dispositivo pueda abrir el dispositivo antes al tráfico. Para obtener más información, vea «Diferir la propagación de la base de datos».

  6. Si va a reemplazar el nodo principal de Redis, en cluster.conf, modifique el valor redis-master por el nombre del nodo de reemplazo.

    Nota: Si el nodo principal de Redis también es el nodo principal de MySQL, consulte "Reemplazar el nodo principal de MySQL".

    Por ejemplo, en este archivo cluster.conf modificado se especifica un nodo de clúster recién aprovisionado, ghe-replacement-data-node-1 como nodo principal de Redis:

    redis-master = ghe-replacement-data-node-1

  7. Desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init. Esto iniciará el nodo recién agregado en la agrupación.

  8. En el mismo nodo, ejecute ghe-cluster-config-apply. Esto validará el archivo de configuración, lo copiará en cada nodo del clúster y configurará cada nodo según el archivo cluster.conf modificado.

  9. Si estás desconectando un nodo que proporciona servicios de datos, como git-server, pages-server o storage-server, evacua el nodo. Para obtener más información, vea «Evacuación de un nodo de clúster que ejecuta servicios de datos».

Reemplazar el nodo principal de MySQL

Para proporcionar servicios de base de datos, su clúster requiere un nodo MySQL primario y al menos un nodo MySQL réplica. Para obtener más información, vea «Acerca de los nodos de agrupación».

Si desea proporcionar la máquina virtual para el nodo principal de MySQL con más recursos, o si se produce un error en el nodo, puede reemplazar el nodo. Para minimizar el tiempo de inactividad, agregue el nuevo nodo al clúster, replique los datos de MySQL y, a continuación, promueva el nodo. Se requiere algún tiempo de inactividad durante la promoción.

  1. Aprovisione e instale GitHub Enterprise Server con un nombre de host único en el nodo de reemplazo.

  2. Mediante el shell administrativo o DHCP, configure solo la dirección IP del nodo de reemplazo. No configures los otros parámetros.

  3. Para conectarte a tu instancia de GitHub Enterprise Server, accede mediante SSH a cualquiera de los nodos del clúster. En la estación de trabajo, ejecuta el siguiente comando. Reemplaza HOSTNAME por el nombre de host del nodo. Para obtener más información, vea «Acceder al shell administrativo (SSH)».

    Shell
    ssh -p 122 admin@HOSTNAME

  4. 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 archivo cluster.conf antes de editarlo.

    Shell
    sudo vim /data/user/common/cluster.conf

  5. En el archivo de configuración del clúster se enumera cada nodo bajo un título [cluster "HOSTNAME"]. Agregue un nuevo encabezado para el nodo y escriba los pares clave-valor para la configuración, reemplazando los marcadores de posición por valores reales.

    • Asegúrese de incluir el par clave-valor mysql-server = true.
    • La siguiente sección es un ejemplo y la configuración del nodo puede diferir.
    ...
[cluster "HOSTNAME"]
  hostname = HOSTNAME
  ipv4 = IPV4-ADDRESS
  # ipv6 = IPV6-ADDRESS
  consul-datacenter = PRIMARY-DATACENTER
  datacenter = DATACENTER
  mysql-server = true
  redis-server = true
  ...
...

  6. Desde el shell administrativo del nodo con el valor cluster.conf modificado, ejecute ghe-cluster-config-init. Esto iniciará el nodo recién agregado en la agrupación.

  7. Desde el shell administrativo del nodo donde ha modificado cluster.conf, ejecute ghe-cluster-config-apply. El nodo recién agregado se convertirá en un nodo mySQL de réplica y cualquier otro servicio configurado se ejecutará allí.

  8. Espere a que finalice la replicación de MySQL. Para supervisar la replicación de MySQL desde cualquier nodo del clúster, ejecute ghe-cluster-status -v.

    Poco después de agregar el nodo al clúster, es posible que vea un error para el estado de replicación mientras la replicación se actualice. La replicación puede tardar horas en función de la carga de la instancia, la cantidad de datos de la base de datos y la última vez que la instancia generó una semilla de base de datos.

  9. Durante la ventana de mantenimiento programado, habilite el modo de mantenimiento. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».

  10. Asegúrese de que la replicación de MySQL finaliza desde cualquier nodo del clúster mediante la ejecución de ghe-cluster-status -v.

    Warning

    Si no esperas a que finalice la replicación de MySQL, corres el riesgo de pérdida de datos en la instancia.

  11. Para establecer el nodo principal de MySQL actual en modo de solo lectura, ejecute el siguiente comando desde los nodos de la instancia.

    Shell
    echo "SET GLOBAL super_read_only = 1;" | sudo mysql

  12. Espere hasta que los Identificadores Globales de Transacción (GTIDs) establecidos en los nodos MySQL primario y réplica sean idénticos. Para comprobar los GTID, ejecute el siguiente comando desde cualquiera de los nodos de la instancia.

    Shell
    ghe-cluster-each -r mysql -- 'echo "SELECT @@global.gtid_executed;" | sudo mysql'

  13. Después de que los GTID de los nodos MySQL principal y réplica coincidan, actualice la configuración del clúster al abrir el archivo de configuración del clúster en /data/user/common/cluster.conf en un editor de texto.

    • Cree una copia de seguridad del archivo cluster.conf antes de editarlo.
    • En la sección de nivel superior [cluster], elimine el nombre de host del nodo que ha reemplazado del par clave-valor mysql-master y, a continuación, asigne el nuevo nodo en su lugar. Si el nuevo nodo también es uno principal de Redis, ajuste el par clave-valor redis-master.
    [cluster]
  mysql-master = NEW-NODE-HOSTNAME
  redis-master = NEW-NODE-HOSTNAME
  primary-datacenter = primary
...

1.Desde el shell administrativo del nodo donde ha modificado cluster.conf, ejecute ghe-cluster-config-apply. Esto volverá a configurar el clúster para que el nodo recién agregado se convierta en el nodo principal de MySQL y el nodo mySQL principal original se convierte en un nodo mySQL de réplica.

  1. Compruebe el estado de la replicación de MySQL desde cualquier nodo del clúster mediante la ejecución de ghe-cluster-status -v.
  2. Si finaliza la replicación de MySQL, desde cualquier nodo del clúster, deshabilite el modo de mantenimiento. Para obtener más información, vea «Habilitar y programar el modo de mantenimiento».