Alta disponibilidad

La función de alta disponibilidad (HA) de XenServer® garantiza que sus máquinas virtuales sigan funcionando con un tiempo de inactividad mínimo y sin corrupción de datos. Cuando se producen problemas como fallos de hardware del host e interrupciones de red, el grupo de XenServer responde reiniciando las máquinas virtuales afectadas en hosts estables del grupo. Esta función le permite mantener sus máquinas virtuales en funcionamiento hasta que pueda solucionar cualquier problema de hardware.

XenServer garantiza la alta disponibilidad de las máquinas virtuales por los siguientes medios:

• Uso de un latido de red para verificar la conectividad entre los hosts del grupo.
• Uso de un latido de almacenamiento para verificar la conectividad entre los hosts y el almacenamiento compartido.
• Detección de si un host ha fallado.
• Detección de si uno o varios hosts se han vuelto inalcanzables.
• Aislamiento de los hosts que no pueden comunicarse con la partición más grande de hosts del grupo. Un host aislado se reinicia inmediatamente, lo que provoca la detención de todas las máquinas virtuales que se ejecutan en él. Una vez reiniciado, intenta volver a unirse al grupo de recursos. Esta precaución evita que las máquinas virtuales se ejecuten en dos hosts a la vez y se arriesguen a la corrupción de datos.
• Marcar un host fallido, aislado o inalcanzable como que ya no forma parte del conjunto activo de hosts del grupo.
• Marcar como detenidas todas las máquinas virtuales que se estaban ejecutando en ese host.
• Si el host fallido, aislado o inalcanzable es el coordinador del grupo, reasignar la función de coordinador a otro host del grupo.
• Reiniciar cualquier máquina virtual detenida de acuerdo con el plan de conmutación por error que haya configurado.
• Supervisar cualquier cambio en la configuración del grupo para comprobar que el plan de conmutación por error configurado se puede ejecutar.

Dado que la función HA reinicia automáticamente las máquinas virtuales en otros hosts del grupo, XenServer debe asegurarse de que el host original (fallido o inalcanzable) de la máquina virtual ya no la esté ejecutando. Dos instancias de la misma máquina virtual ejecutándose al mismo tiempo pueden causar corrupción de datos de la máquina virtual. Para evitar esta posibilidad, los hosts de XenServer en un grupo habilitado para HA son proactivos en el autoaislamiento si se encuentran en situaciones que podrían llevar a la ejecución de dos instancias de la misma máquina virtual.

La función HA mantiene sus máquinas virtuales clave en funcionamiento hasta que pueda resolver el problema de hardware o de red subyacente. Cuando se dé cuenta de que se ha producido un evento de HA, investigue y resuelva el fallo subyacente para que su grupo recupere su plena capacidad.

Este artículo describe los conceptos, requisitos y comportamientos esperados de la alta disponibilidad. Para obtener información sobre cómo configurar y administrar la alta disponibilidad, consulte Configurar la alta disponibilidad.

Requisitos

Para usar la función de alta disponibilidad, necesita los siguientes elementos en su entorno:

• Un grupo de XenServer: La función de HA opera dentro de un único grupo de recursos.

  • Recomendamos que el grupo sea homogéneo. Cada host del grupo expone el mismo conjunto de características de CPU a las máquinas virtuales y facilita que las máquinas virtuales se reinicien en cualquier lugar del grupo.
  • Para que el mecanismo de latido funcione eficazmente, recomendamos que el grupo tenga al menos 3 hosts.
  • Asegúrese de que todos los hosts del grupo estén en línea antes de habilitar la HA.

• Almacenamiento compartido para todos los hosts del grupo: Para permitir que cualquier máquina virtual del grupo se reinicie en cualquier host del grupo después de un fallo, todos los hosts del grupo deben tener acceso al SR donde se almacenan los discos de las máquinas virtuales.

• Un SR de latido: Este SR puede ser el mismo SR donde se almacenan los discos de las máquinas virtuales. El grupo almacena información que le permite coordinar la detección y recuperación de fallos en caso de un fallo.

  • El SR de latido debe estar en una LUN iSCSI, NFS o Fibre Channel. El almacenamiento conectado mediante SMB o iSCSI cuando se autentica con CHAP no se puede utilizar como SR de latido. Recomendamos que este SR sea altamente fiable y con baja latencia.

  • XenServer 8.4 requiere 4 GB para el SR de latido.

    La información almacenada en el SR de latido incluye:

    • Volumen de latido de 4 MB: Proporciona el latido de almacenamiento, que verifica que los hosts del grupo tienen acceso al almacenamiento.
    • El volumen de metadatos: Almacena los metadatos del coordinador del grupo para ser utilizados si hay una conmutación por error del coordinador del grupo. Este volumen ocupa el resto del espacio requerido.

• Comunicación de almacenamiento fiable y redundante para el SR de latido: Para que la función de HA tenga la visión más precisa de qué hosts pueden acceder al almacenamiento compartido, configure su entorno para garantizar que el tráfico de almacenamiento sea fiable. Para los SR iSCSI y Fibre Channel, configure la multiruta. Para los SR NFS, utilice una red enlazada resistente como su red de almacenamiento.

• Direcciones IP estáticas para todos los hosts: HA trata un cambio de dirección IP del host como si el host perdiera la conexión y asume que la red del host ha fallado. Como resultado, el host puede aislarse (fence). Evite esto utilizando solo IPs estáticas en su pool.

• Una interfaz enlazada dedicada en la red de administración: Para que la función de HA tenga la visión más precisa del estado del pool, se requieren comunicaciones de red fiables y redundantes entre los hosts.

• La red de administración permite el tráfico UDP de latido de red a través del puerto 694: El latido de red verifica que los hosts del pool están activos y pueden comunicarse entre sí.

Para proteger una VM que se ejecuta en su pool de alta disponibilidad, configure su VM con la siguiente configuración:

• Almacene los discos de la VM en almacenamiento compartido disponible para todos los hosts del pool.
• Configure sus interfaces de red virtuales en redes de todo el pool.
• Asegúrese de que la VM pueda usar la migración en vivo. Para obtener más información, consulte Requisitos de compatibilidad de migración.
• No conecte la VM a una unidad de DVD local.

Una VM que cumple todos estos criterios se denomina ágil.

Una VM que utiliza NVIDIA vGPU o GPU pass-through no puede ser protegida por HA. Sin embargo, el mecanismo de HA puede intentar reiniciar esta VM con el mejor esfuerzo posible.

Requisitos para pools agrupados GFS2

El comportamiento de alta disponibilidad para pools agrupados GFS2 utiliza un mecanismo subyacente diferente y, como tal, tiene algunos requisitos y comportamientos distintos. Para obtener más información, consulte pools agrupados GFS2.

Plan de conmutación por error de HA

El mecanismo de HA calcula un plan de conmutación por error para todo el pool basado en los siguientes criterios:

• Requisitos de recuperación de VM: Cada VM puede tener una prioridad de reinicio y un orden de inicio definidos.
• Recursos de pool disponibles: El recurso principal que se considera es la memoria del host.
• Número de fallos de host a tolerar: Después de habilitar HA en su pool, XenServer puede calcular el número máximo de hosts que pueden fallar en el pool antes de que las VM protegidas no puedan reiniciarse. Puede establecer el número de fallos de host a tolerar en un valor menor o igual a este.

Si no se puede calcular un plan de conmutación por error que cumpla estos criterios, el pool se considera sobrecargado. Si las VM protegidas no se pueden reiniciar en el pool, XenServer genera una alerta del sistema. Esta alerta también se muestra en el panel Notificaciones de XenCenter®.

Para cada VM de su pool, puede definir su comportamiento de recuperación.

Prioridad de reinicio

Puede asignar a una VM una de las siguientes prioridades de reinicio:

• Protegida: Si la VM o su host se desconectan inesperadamente, HA reinicia la VM en otro host. Este reinicio está garantizado, siempre que el pool no esté sobrecargado y la VM sea ágil. Si el reinicio de la VM falla, HA intenta iniciar la VM cuando hay capacidad adicional en el pool. Este valor es restart en la CLI de xe y Reiniciar en XenCenter.
• Mejor esfuerzo: Si el host que ejecuta la VM se desconecta inesperadamente, HA intenta reiniciar la VM en otro host. Realiza este intento solo después de que todas las VM protegidas se hayan reiniciado correctamente. La alta disponibilidad solo realiza un intento de reiniciar una VM de mejor esfuerzo. Si este intento falla, la alta disponibilidad no realiza más intentos de reiniciar la VM. Este valor es best-effort en la CLI de xe y Reiniciar si es posible en XenCenter.
• No protegida: Si la VM o su host se desconectan inesperadamente, HA no intenta reiniciar la VM. Esta es la configuración predeterminada. Este valor es una cadena vacía en la CLI de xe y No reiniciar en XenCenter.

La alta disponibilidad nunca detiene ni migra una VM en ejecución para liberar recursos y reiniciar una VM con una prioridad de reinicio más alta.

Orden de inicio

El orden de inicio es el orden en que la alta disponibilidad de XenServer intenta reiniciar las VM protegidas cuando se produce un fallo. Este valor se utiliza solo para las VM protegidas. El valor predeterminado es 0, que es la prioridad más alta. Las VM protegidas con un valor de orden de inicio de 0 se reinician primero. Cuanto mayor sea el valor del orden de inicio, más tarde se reiniciará la VM en la secuencia.

Comportamiento del pool

Después de haber habilitado HA en su pool de XenServer, el pool exhibe los siguientes comportamientos.

Comportamiento durante la configuración

Cuando habilita HA en un pool, el coordinador del pool realiza la siguiente configuración:

• Calcula el plan de conmutación por error inicial.
• Configura la base de datos para escribir actualizaciones en el SR de latido. Esta configuración garantiza que los cambios de configuración de la VM no se pierdan cuando un host falla.
• Configura los metadatos del coordinador del pool en el SR de latido.

Todos los miembros del pool:

• Envían latidos de red entre sí. Como resultado, hay un pequeño aumento en el tráfico de la red de administración a medida que los hosts del pool verificar que pueden comunicarse entre sí. Este tráfico de red continúa mientras HA esté habilitado.

Comportamiento durante el funcionamiento normal

Durante el funcionamiento normal, el coordinador del pool de HA realiza las siguientes acciones (además de sus funciones habituales):

• Mantiene dinámicamente un plan de conmutación por error. Este plan detalla qué hacer cuando un conjunto de hosts en un pool falla en un momento dado. Este plan tiene en cuenta el número máximo de fallos de host que se pueden tolerar y garantiza que todas las VM protegidas se puedan reiniciar. El plan se recalcula dinámicamente en función de las operaciones y el movimiento del ciclo de vida de la VM. Si los cambios (por ejemplo, la adición de nuevas VM al pool) significan que todas las VM protegidas ya no se pueden reiniciar después del número máximo de fallos de host, no se puede calcular un plan y el pool está sobrecargado. Cuando el pool se sobrecarga, XenServer genera una alerta a través de XenCenter, correo electrónico, trampa SNMP o alerta NRPE.

Durante el funcionamiento normal, cada miembro de un pool de HA realiza las siguientes acciones (además de sus funciones habituales):

• Comprueba que el coordinador del pool está activo. El host lo hace intentando adquirir un «bloqueo maestro» en el almacenamiento compartido. Si ya existe un coordinador del pool, este intento falla
• Envía un latido de red. Este latido de red se envía utilizando UDP a través del puerto 694 en la red de administración a todos los demás hosts del pool.
• Mantiene un registro del conjunto de hosts activos en el pool. El conjunto de hosts activos según cada host individual es el conjunto de otros hosts que cree que están activos. Si un host no ha recibido un latido de red de otro host dentro del período especificado por el tiempo de espera de HA (por defecto, 60 segundos), se comunica con los otros hosts del pool para acordar si el conjunto de hosts activos debe actualizarse.
• Escribe en el archivo de estado en el volumen de latido de almacenamiento. Esta acción verifica que el host todavía tiene acceso al almacenamiento. También permite a los hosts comunicar su estado entre sí (además de la comunicación con el latido de red).
• Actualiza la base de datos en el SR de latido. El host registra cualquier cambio en las configuraciones de VM para las VM que aloja.

Algunas operaciones del pool están bloqueadas o no son aconsejables cuando HA está habilitado. Deshabilite temporalmente la alta disponibilidad para realizar estas operaciones:

• Agregar un host al pool.
• Eliminar un host del pool. Bloqueado si esta acción puede hacer que el pool se sobrecargue.
• Apagar un host en el pool. Bloqueado si esta acción puede hacer que el pool se sobrecargue.
• Cambiar la red de administración.
• Cambiar el SR adjunto al pool.
• Habilitar la agrupación en clústeres. Algunos comportamientos y requisitos de alta disponibilidad son diferentes para los pools agrupados en clústeres. Para obtener más información, consulte Pools agrupados en clústeres.

Durante el funcionamiento normal, la realización de estas acciones en el pool no activa el plan de conmutación por error de HA:

• Apagado limpio de la VM desde XenCenter o la CLI de xe. El mecanismo de HA no considera que esta VM haya fallado y no intenta reiniciarla. Para obtener más información sobre esta acción, consulte Apagar una VM protegida por alta disponibilidad
• Bloqueo o apagado limpio de la VM desde el sistema operativo invitado, si HA se ha configurado para no reiniciar automáticamente las VM en caso de apagado interno. En este caso, el mecanismo de HA no considera que la VM haya fallado y no intenta reiniciarla. Para obtener más información sobre esta configuración, consulte Configurar el comportamiento de reinicio para las VM que se apagan internamente
• Apagado limpio del host desde XenCenter o la CLI de xe. El mecanismo de HA no considera que este host haya fallado y no intenta reiniciar ninguna VM que estuviera alojada en él. Sin embargo, si esta acción hace que el pool se sobrecargue, XenServer la bloquea. Para obtener más información sobre esta acción, consulte Apagar un host cuando la alta disponibilidad está habilitada

Comportamiento durante fallos de hardware o inestabilidad de la infraestructura

Durante esta fase, todos los hosts del pool son responsables de detectar su propio estado de conectividad y de acordar el estado de conectividad de otros hosts del pool.

XenServer HA detecta y gestiona los siguientes tipos de fallos:

• Host o hosts fallidos: En esta situación, todos los hosts restantes notan muy rápidamente que el host o los hosts fallidos han dejado de actualizar el archivo de estado y ya no envían latidos de red. Después de un retraso apropiado, estos hosts se eliminan del conjunto activo.
• Partición de red: En esta situación, uno o más hosts no pueden comunicarse con uno o más hosts. Un host detecta que no ha recibido latidos de red de uno o más hosts dentro del tiempo de espera definido y activa un controlador de fallos. Este proceso de controlador de fallos se comunica a través del archivo de estado y el latido de red en funcionamiento, y utiliza esa información para determinar qué particiones de red (grupos de hosts que pueden comunicarse entre sí) existen. Los hosts de la partición más grande son el conjunto activo y sobreviven. Si hay particiones de igual tamaño, los hosts de la partición que contiene el host con el UUID de host más bajo sobreviven.
• Conexión de almacenamiento fallida: En esta situación, un host detecta que no puede acceder al almacenamiento o que otros hosts detectan que sus actualizaciones no están presentes en el almacenamiento. Los hosts se comunican a través de las comunicaciones de latido de red para comprobar si otros hosts han perdido el acceso al almacenamiento:
  • Si todos los hosts han perdido el almacenamiento, pero no la red, esto se considera una pérdida temporal de almacenamiento y los hosts permanecen activos a la espera de que el almacenamiento se recupere. Cualquier fallo adicional y todos los hosts del pool se aíslan. Esta regla evita que el almacenamiento sea un único punto de fallo.
  • Si solo algunos hosts han perdido el acceso al almacenamiento, pero todos los hosts aún tienen acceso a la red, estos hosts se eliminan del conjunto activo.

Si un host sabe que aparecerá como fallido o inalcanzable para la mayoría del pool, ese host se auto-aísla. El aislamiento es un comportamiento esperado diseñado como medida de protección para los datos de las máquinas virtuales. Asegura que una máquina virtual no se ejecute en dos lugares a la vez. Un host utiliza los siguientes criterios para decidir que necesita auto-aislarse:

• Si el toolstack del host no se está ejecutando y no se puede reiniciar, el host se auto-aísla.
• Si el host ha perdido los latidos de red y de almacenamiento, el host se considera inalcanzable y se auto-aísla.
• Si el host ha perdido el latido de almacenamiento, pero sigue recibiendo latidos de red:
  • Si el host aún puede contactar con todos los demás miembros del pool y todos esos miembros también han perdido el latido de almacenamiento, el host permanece activo. Este caso evita que el almacenamiento actúe como un único punto de fallo y aísle todo el pool.
  • Si el host no puede contactar con uno o más hosts del pool, se auto-aísla.
• Si el host ha perdido algún latido de red, pero aún tiene el latido de almacenamiento, determina si está en la partición de red más grande. Si no lo está, el host se auto-aísla.
• Existe la posibilidad de que un fallo de comunicación de red pueda dividir el pool en particiones de igual tamaño. Si, utilizando la información del archivo de estado en el SR de latido, un host sabe que está en una partición de red de este tipo:
  • Si la partición contiene el host con el UUID más bajo, el host permanece activo.
  • Si la partición no contiene el host con el UUID más bajo, el host se auto-aísla.

Cuando se realiza una acción de aislamiento, el host se reinicia de forma inmediata y abrupta, lo que provoca la detención de todas las máquinas virtuales que se ejecutan en él. El host aislado entra en una secuencia de reinicio y, una vez reiniciado, intenta volver a unirse al pool de recursos.

Comportamiento durante la recuperación

Si el coordinador del pool es el host que ha fallado, ha sido aislado o se ha vuelto inaccesible, otros hosts intentan obtener el bloqueo maestro. El host que lo consigue se convierte en el nuevo coordinador.

Los hosts que se han autoaislado se reinician e intentan unirse de nuevo al pool.

Cuando un host se marca como inactivo y sus máquinas virtuales se detienen, el coordinador del pool es responsable de las siguientes acciones de recuperación.

• Reiniciar todas las máquinas virtuales protegidas según el plan de conmutación por error.
• Si no hay suficientes recursos para iniciar todas las máquinas virtuales protegidas, el coordinador del pool espera hasta que haya recursos disponibles (por ejemplo, si los hosts previamente aislados se unen de nuevo al pool) y luego intenta iniciar las máquinas virtuales protegidas.
• Después de que todas las máquinas virtuales protegidas se hayan iniciado correctamente, el coordinador del pool hace un intento para reiniciar cada máquina virtual de mejor esfuerzo.