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 ocurren problemas como fallas de hardware del host e interrupciones de la red, el grupo XenServer responde reiniciando las máquinas virtuales afectadas en los hosts estables del grupo. Esta función le permite mantener sus máquinas virtuales en funcionamiento hasta que pueda corregir cualquier problema de hardware.

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

• Usar un latido de red para verificar la conectividad entre los hosts del grupo.
• Usar un latido de almacenamiento para verificar la conectividad entre los hosts y el almacenamiento compartido.
• Detectar si un host ha fallado.
• Detectar si un host o hosts se han vuelto inaccesibles.
• Cercar los hosts que no pueden comunicarse con la partición más grande de hosts en el grupo. Un host protegido se reinicia inmediatamente, lo que provoca que todas las máquinas virtuales que se ejecutan en él se detengan. Cuando se reinicia, 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 corran el riesgo de dañar los datos.
• Marcar un host fallido, cercado o inalcanzable como si ya no fuera parte del conjunto de hosts activos en el grupo.
• Marcar todas las máquinas virtuales que se estaban ejecutando en ese host como detenidas.
• Si el host fallido, cercado o inalcanzable es el coordinador del grupo, se reasigna el rol de coordinador a otro host del grupo.
• Reiniciar cualquier máquina virtual detenida según el plan de conmutación por error que haya configurado.
• Supervisar cualquier cambio en la configuración del grupo para verificar que se pueda implementar el plan de conmutación por error configurado.

Debido a que la función HA reinicia automáticamente las máquinas virtuales en otros hosts del grupo, XenServer debe estar seguro de que el host original (fallido o inalcanzable) de la máquina virtual ya no esté ejecutando la máquina virtual. Dos instancias de la misma máquina virtual ejecutándose al mismo tiempo pueden provocar daños en los datos de la máquina virtual. Para protegerse contra esta posibilidad, los hosts de XenServer en un grupo habilitado para HA son proactivos en cuanto a la autoprotección si se encuentran en situaciones que podrían llevar a que se ejecuten dos instancias de la misma VM.

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

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

Requisitos

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

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

  • Recomendamos que la piscina sea homogénea. Cada host del grupo expone el mismo conjunto de características de CPU a las máquinas virtuales y facilita que estas se reinicien en cualquier lugar del grupo.
  • Para que el mecanismo de latido funcione de manera efectiva, 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 HA.

• Almacenamiento compartido para todos los hosts en el grupo: para permitir que cualquier VM en el grupo se reinicie en cualquier host en el grupo después de una falla, todos los hosts en el grupo deben tener acceso al SR donde se almacenan los discos de la VM.

• Un SR de latido: Este SR puede ser el mismo SR donde se almacenan los discos de la VM. El grupo almacena información que le permite coordinar la detección y recuperación de fallas en caso de que ocurra una falla.

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

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

    La información almacenada en el SR de latidos del corazón incluye:

    • Volumen de latido de 4 MB: proporciona el latido de almacenamiento, que verifica que los hosts en el grupo tengan acceso al almacenamiento.
    • El volumen de metadatos: almacena los metadatos del coordinador de grupo que se utilizarán si hay una conmutación por error del coordinador de grupo. Este volumen ocupa el resto del espacio requerido.

• Comunicación de almacenamiento confiable y redundante para el SR de latido: Para que la función 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 confiable. Para SR iSCSI y Fibre Channel, configure rutas múltiples. Para los SR de NFS, utilice una red enlazada resistente como 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 anfitrión puede cercar. Evite esto utilizando únicamente direcciones IP estáticas en su grupo.

• Una interfaz vinculada dedicada en la red de administración: Para que la función HA tenga la vista más precisa del estado del grupo, necesita comunicaciones de red confiables y redundantes entre los hosts.

• La red de administración permite el tráfico UDP de latidos de red a través del puerto 694: Los latidos de red verifican que los hosts en el grupo estén activos y puedan comunicarse entre sí.

Para proteger una máquina virtual que se ejecuta en su grupo de alta disponibilidad, configure su máquina virtual con la siguiente configuración:

• Almacene los discos de VM en un almacenamiento compartido disponible para todos los hosts del grupo.
• Configurar sus interfaces de red virtual en redes de todo el grupo.
• Asegúrese de que la máquina virtual pueda utilizar 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 máquina virtual que cumple todos estos criterios se denomina ágil.

Una máquina virtual que utiliza NVIDIA vGPU o GPU pass-through no puede estar protegida por HA. Sin embargo, el mecanismo HA puede intentar reiniciar esta máquina virtual si hace el mayor esfuerzo posible.

Requisitos para grupos agrupados

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

Plan de conmutación por error de alta disponibilidad

El mecanismo de alta disponibilidad calcula un plan de conmutación por error para todo el grupo según los siguientes criterios:

• Requisitos de recuperación de VM: Cada VM puede tener una prioridad de reinicio y un orden de inicio definidos.
• Recursos del grupo disponibles: El recurso principal que se considera es la memoria del host.
• La cantidad de fallas de host que se deben tolerar: después de habilitar HA en su grupo, XenServer puede calcular la cantidad máxima de hosts que pueden fallar en el grupo antes de que no se puedan reiniciar las máquinas virtuales protegidas. Puede establecer la cantidad de fallas del host que se tolerarán en un valor menor o igual a este.

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

Para cada máquina virtual de su grupo, puede definir su comportamiento de recuperación.

Prioridad de reinicio

Puede asignar a una máquina virtual una de las siguientes prioridades de reinicio:

• Protegido: Si la VM o su host se desconecta inesperadamente, HA reinicia la VM en otro host. Este reinicio está garantizado, siempre que el grupo no esté sobrecargado y la máquina virtual sea ágil. Si falla el reinicio de la máquina virtual, HA intenta iniciar la máquina virtual cuando hay capacidad adicional en el grupo. Este valor es reinicio en la CLI xe y reinicio en XenCenter.
• Máximo esfuerzo: si el host que ejecuta la VM se desconecta inesperadamente, HA intenta reiniciar la VM en otro host. Solo realiza este intento después de que todas las máquinas virtuales protegidas se hayan reiniciado correctamente. La alta disponibilidad solo realiza un intento de reiniciar una máquina virtual de máximo esfuerzo. Si este intento falla, la alta disponibilidad no realiza más intentos para reiniciar la máquina virtual. Este valor es mejor esfuerzo en la CLI xe y Reiniciar si es posible en XenCenter.
• Desprotegido: si la VM o su host se desconecta 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 reinicie en XenCenter.

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

Orden de inicio

El orden de inicio es el orden en el que la alta disponibilidad de XenServer intenta reiniciar las máquinas virtuales protegidas cuando se produce una falla. Este valor se utiliza únicamente para máquinas virtuales protegidas. El valor predeterminado es 0, que es la prioridad más alta. Las máquinas virtuales 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 en la secuencia se reiniciará la máquina virtual.

Comportamiento en la piscina

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

Comportamiento durante la configuración

Cuando habilita HA en un grupo, el coordinador del grupo 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 máquina virtual no se pierdan cuando falla un host.
• Configura los metadatos del coordinador de grupo en el SR de latido.

Todos los miembros del grupo:

• Enviarse 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 en el grupo verifican 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 de un 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 grupo falla en un momento determinado. Este plan tiene en cuenta la cantidad máxima de fallas del host que se pueden tolerar y garantiza que se puedan reiniciar todas las máquinas virtuales protegidas. El plan se recalcula dinámicamente en función de las operaciones y el movimiento del ciclo de vida de la máquina virtual. Si los cambios (por ejemplo, la incorporación de nuevas máquinas virtuales al grupo) implican que ya no es posible reiniciar todas las máquinas virtuales protegidas después de la cantidad máxima de fallas del host, no se puede calcular un plan y el grupo se sobrecarga. Cuando el grupo 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 grupo de alta disponibilidad realiza las siguientes acciones (además de sus funciones habituales):

• Comprueba que el coordinador del grupo esté vivo. El host hace esto intentando adquirir un “bloqueo maestro” en el almacenamiento compartido. Si ya existe un coordinador de grupo, este intento falla
• Enviar un latido de red. Este latido de red se envía mediante UDP a través del puerto 694 en la red de administración a todos los demás hosts del grupo.
• Mantiene un registro del conjunto de vidas de los anfitriones en el grupo. 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 en el grupo para acordar si el conjunto en vivo debe actualizarse.
• Escribe en el archivo de estado en el volumen de latido de almacenamiento. Esta acción verifica que el host todavía tenga acceso al almacenamiento. También permite que los hosts comuniquen su estado entre sí (además de la comunicación con el latido de la red).
• Actualiza la base de datos en el SR de latidos. El host registra cualquier cambio en las configuraciones de las máquinas virtuales que aloja.

Algunas operaciones de pool están bloqueadas o no se recomiendan cuando HA está habilitado. Deshabilite temporalmente la alta disponibilidad para realizar estas operaciones:

• Agregar un host al grupo.
• Eliminar un host del grupo. Se bloqueará si esta acción puede provocar que el grupo se sobrecargue.
• Apagando un host en el pool. Se bloqueará si esta acción puede provocar que el grupo se sobrecargue.
• Cambiar la red de gestión.
• Cambio del SR adjunto a la piscina.
• Habilitación de agrupamiento. Algunos comportamientos y requisitos de alta disponibilidad son diferentes para los grupos agrupados. Para obtener más información, consulte Grupos agrupados.

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

• Apagado limpio de la máquina virtual desde XenCenter o la CLI xe. El mecanismo de alta disponibilidad no considera que esta máquina virtual ha fallado y no intenta reiniciarla. Para obtener más información sobre esta acción, consulte Apagar una máquina virtual protegida por alta disponibilidad
• Apagado limpio del host desde XenCenter o la CLI xe. El mecanismo de alta disponibilidad no considera que este host haya fallado y no intenta reiniciar ninguna máquina virtual alojada en él. Sin embargo, si esta acción provoca que el grupo se sobrecargue, XenServer lo bloqueará. Para obtener más información sobre esta acción, consulte Apagar un host cuando la alta disponibilidad está habilitada

Comportamiento durante fallas de hardware o inestabilidad de la infraestructura

Durante esta fase, todos los hosts del grupo son responsables de detectar su propio estado de conectividad y acordar el estado de conectividad de los demás hosts del grupo.

XenServer HA detecta y gestiona los siguientes tipos de fallas:

• Host o hosts fallidos: en esta situación, todos los hosts restantes notan muy rápidamente que el 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 anfitriones se eliminan del conjunto vivo.
• Partición de red: en esta situación, uno o más hosts no pueden comunicarse con uno o más hosts diferentes. Un host observa que no ha recibido latidos de red de uno o más otros hosts dentro del tiempo de espera definido e inicia un controlador de fallas. Este proceso de manejo de fallas se comunica a través del archivo de estado y el latido de la red en funcionamiento, y utiliza esa información para determinar qué particiones de red (grupos de hosts que pueden comunicarse entre sí) existen. Los anfitriones en la partición más grande son los que viven y sobreviven. Si hay particiones de igual tamaño, los hosts en 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 nota que no puede acceder al almacenamiento u otros hosts notan que sus actualizaciones no están presentes en el almacenamiento. Los hosts se comunican a través de las comunicaciones de latido de la red para verificar si otros hosts han perdido el acceso al almacenamiento:
  • Si todos los hosts han perdido almacenamiento, pero no la red, esto se considera una pérdida temporal de almacenamiento y los hosts permanecen activos a la espera de que se recupere el almacenamiento. Cualquier otro fallo y todos los hosts en el pool vallado. Esta regla evita que el almacenamiento sea un único punto de falla.
  • 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 grupo, ese host se autoprotege. El cercado es un comportamiento esperado diseñado como medida de protección para los datos de la máquina virtual. Asegura que una máquina virtual no se ejecute en dos lugares al mismo tiempo. Un anfitrión utiliza los siguientes criterios para decidir que necesita autoprotegerse:

• Si la pila de herramientas del host no se está ejecutando y no se puede reiniciar, el host se autoprotege.
• Si el host ha perdido tanto los latidos de red como los de almacenamiento, el host se considera inalcanzable y se autoprotege.
• Si el host ha perdido el latido de almacenamiento, pero aún recibe latidos de red:
  • Si el host aún puede comunicarse con todos los demás miembros del grupo 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 cerca todo el conjunto.
  • Si el host no puede contactar con uno o más hosts en el grupo, se autoprotege.
• Si el host ha perdido algún latido de red, pero aún conserva el latido de almacenamiento, determina si está en la partición de red más grande. En caso contrario, el host se autoprotege.
• Existe la posibilidad de que una falla en la comunicación de red divida el grupo en particiones de igual tamaño. Si, al utilizar la información del archivo de estado en el SR de latido, un host sabe que se encuentra en dicha partición de red:
  • 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 autoprotege.

Cuando se realiza una acción de vallado, el host se reinicia de manera inmediata y abrupta, lo que provoca que todas las máquinas virtuales que se ejecutan en él se detengan. El host protegido ingresa a una secuencia de reinicio y, cuando se reinicia, intenta volver a unirse al grupo de recursos.

Comportamiento durante la recuperación

Si el coordinador del grupo es el host que ha fallado, está cercado o se ha vuelto inaccesible, otros hosts intentan obtener el bloqueo maestro. El anfitrión que tenga éxito se convertirá en el nuevo coordinador.

Los hosts que se han autoprotegido se reinician e intentan volver a unirse al grupo.

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

• Reinicie 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 grupo espera hasta que el recurso esté disponible (por ejemplo, si los hosts previamente protegidos se vuelven a unir al grupo) y luego intenta iniciar las máquinas virtuales protegidas.
• Una vez que todas las máquinas virtuales protegidas se hayan iniciado correctamente, el coordinador del grupo realiza un intento de reiniciar cada máquina virtual de máximo esfuerzo.