Alta disponibilidad

La alta disponibilidad es un conjunto de funciones automáticas diseñadas para planificar y recuperarse de forma segura de los problemas que provocan el cierre de los hosts de XenServer o los hacen inaccesibles. Por ejemplo, durante fallos de hardware de host o redes interrumpidas físicamente.

Información general

La alta disponibilidad garantiza que, si un host se vuelve inaccesible o inestable, las máquinas virtuales que se ejecutan en ese host se reinicien automáticamente de forma segura en otro host. Esto elimina la necesidad de que las máquinas virtuales se reinicien manualmente, lo que reduce al mínimo el tiempo de inactividad de las máquinas virtuales.

Cuando el coordinador de grupos se vuelve inaccesible o inestable, la alta disponibilidad también puede recuperar el control administrativo de un grupo. La alta disponibilidad garantiza que el control administrativo se restaure automáticamente sin ninguna intervención manual.

De manera opcional, la alta disponibilidad también puede automatizar el proceso de reinicio de las máquinas virtuales en hosts que se sabe que están en buen estado sin intervención manual. Estas máquinas virtuales se pueden programar para que se reinicien en grupos para dar tiempo a iniciar los servicios. Permite que las máquinas virtuales de infraestructura se inicien antes que las máquinas virtuales dependientes (por ejemplo, un servidor DHCP antes que su servidor SQL dependiente).

Advertencias:

Utilice la alta disponibilidad junto con el almacenamiento de rutas múltiples y las redes conectadas. Configure el almacenamiento de rutas múltiples y las redes conectadas antes de intentar configurar la alta disponibilidad. Los clientes que no configuran el almacenamiento de rutas múltiples y las redes conectadas pueden ver un comportamiento inesperado de reinicio del host (autodelimitación) cuando hay una inestabilidad en la infraestructura.

Todas las soluciones gráficas (NVIDIA vGPU y vGPU passthrough) se pueden usar en un entorno que utilice alta disponibilidad. Sin embargo, las máquinas virtuales que usan estas soluciones de gráficos no se pueden proteger con alta disponibilidad. Estas máquinas virtuales se pueden reiniciar según el mejor esfuerzo mientras haya hosts con los recursos gratuitos adecuados.

Comprometerse en exceso

Un grupo se compromete en exceso cuando las máquinas virtuales que se están ejecutando actualmente no se pueden reiniciar en otro lugar después de una cantidad de errores de host definida por el usuario. La sobreasignación puede ocurrir si no hay suficiente memoria libre en el grupo para ejecutar esas máquinas virtuales después de un error. Sin embargo, también hay cambios más sutiles que pueden hacer que la alta disponibilidad sea insostenible: los cambios en los dispositivos de bloques virtuales (VBD) y en las redes pueden afectar a las máquinas virtuales que se pueden reiniciar y en qué hosts. XenServer no puede comprobar todas las posibles acciones y determinar si infringen las exigencias de alta disponibilidad. Sin embargo, se envía una notificación asíncrona si la alta disponibilidad se vuelve insostenible.

XenServer mantiene de forma dinámica un plan de conmutación por error que detalla qué hacer cuando un conjunto de hosts de un grupo falla en un momento dado. Un concepto importante que hay que entender es el host failures to tolerate valor, que se define como parte de la configuración de alta disponibilidad. El valor de host failures to tolerate determina la cantidad de errores de host que se permiten y, al mismo tiempo, se pueden reiniciar todas las máquinas virtuales protegidas. Por ejemplo, considere un grupo de recursos que consta de 64 hosts y host failures to tolerate se establece en 3. En este caso, el grupo calcula un plan de conmutación por error que permite que tres hosts fallen y, a continuación, reinicie las máquinas virtuales en otros hosts. Si no se puede encontrar un plan, se considera que la agrupación está comprometida en exceso. 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 máquinas virtuales al grupo) provocan que el grupo se comprometa en exceso, las alertas se envían a través de XenCenter o por correo electrónico.

Aviso de sobrecompromiso

Si algún intento de iniciar o reanudar una máquina virtual provoca que el grupo se comprometa en exceso, se muestra una alerta de advertencia en XenCenter. A continuación, puede optar por cancelar la operación o continuar de todos modos. Al continuar, el grupo se compromete en exceso y se envía un mensaje a cualquier dirección de correo electrónico configurada. También está disponible como instancia de mensaje a través de la API de administración. La cantidad de memoria que utilizan las máquinas virtuales de diferentes prioridades se muestra en los niveles de host y grupo.

Esgrima host

A veces, un host puede fallar debido a la pérdida de conectividad de la red o cuando se produce un problema con la pila de control. En esos casos, el host de XenServer se autocontrola para garantizar que las máquinas virtuales no se ejecuten en dos hosts simultáneamente. Cuando se realiza una acción de protección, el host se reinicia de forma inmediata y abrupta, lo que provoca que todas las máquinas virtuales que se estén ejecutando en él se detengan. Los demás hosts detectan que las máquinas virtuales ya no se están ejecutando y, a continuación, las máquinas virtuales se reinician según las prioridades de reinicio que se les hayan asignado. El host protegido entra en una secuencia de reinicio y, cuando se reinicia, intenta volver a unirse al grupo de recursos.

Nota:

Los hosts de los grupos agrupados también pueden autoprotegerse cuando no pueden comunicarse con más de la mitad de los demás hosts del grupo de recursos. Para obtener más información, consulte Grupos agrupados.

Requisitos de configuración

Para utilizar la función de alta disponibilidad, necesita:

• Grupo de XenServer (esta función proporciona alta disponibilidad a nivel de host dentro de un único grupo de recursos).

  Nota:

  Se recomienda habilitar la alta disponibilidad solo en grupos que contengan al menos 3 hosts XenServer. Para obtener más información, consulte CTX129721: Comportamiento de alta disponibilidad cuando se pierde el latido en un grupo.

• Almacenamiento compartido, que incluye al menos un LUN iSCSI, NFS o Fibre Channel de 356 MB o superior: El SR latido. El mecanismo de alta disponibilidad crea dos volúmenes en la SR de latido:

  • Volumen de latido cardíaco de 4 MB: se usa para proporcionar latidos cardíacos.
  • Volumen de metadatos de 256 MB: para almacenar los metadatos del coordinador del grupo que se utilizarán en caso de que se produzca una conmutación por error del coordinador del grupo.

  Nota:

  Anteriormente, recomendábamos utilizar un repositorio de almacenamiento NFS o iSCSI dedicado como disco de latido de alta disponibilidad. Sin embargo, esto solo es beneficioso si el repositorio de almacenamiento no comparte recursos en el dispositivo de almacenamiento subyacente; de lo contrario, simplemente aumenta la complejidad y el uso de los recursos en el dominio de control (dom0) del host.

  Si su grupo es un grupo agrupado, su SR de latido debe ser un SR GFS2.

  El almacenamiento conectado mediante SMB o iSCSI cuando se autentica mediante CHAP no se puede usar como SR de latido.

• Direcciones IP estáticas para todos los hosts.

  Advertencia:

  Si la dirección IP de un host cambia mientras la alta disponibilidad está habilitada, la alta disponibilidad supone que la red del host ha fallado. El cambio en la dirección IP puede cercar el host y dejarlo en un estado de no arranque. Para solucionar esta situación, inhabilite la alta disponibilidad mediante el comando host-emergency-ha-disable, restablezca el coordinador del grupo mediante y pool-emergency-reset-master, a continuación, vuelva a habilitar la alta disponibilidad.

• Para obtener la máxima fiabilidad, le recomendamos que utilice una interfaz de enlace dedicada como red de administración de alta disponibilidad.

Para que una VM esté protegida por una alta disponibilidad, debe ser ágil. Esto significa que la máquina virtual:

• Debe tener sus discos virtuales en un almacenamiento compartido. Puede usar cualquier tipo de almacenamiento compartido. El LUN iSCSI, NFS o Fibre Channel solo es necesario para el latido del almacenamiento y se puede usar para el almacenamiento en disco virtual.

• Puede utilizar la migración en vivo.

• No tiene configurada una conexión a una unidad de DVD local.

• Tiene sus interfaces de red virtuales en redes de todo el grupo.

Nota:

Cuando la alta disponibilidad está habilitada, recomendamos encarecidamente utilizar una interfaz de administración integrada en los hosts del grupo y un almacenamiento con múltiples rutas para el Heartbeat SR.

Si crea VLAN e interfaces enlazadas desde la CLI, es posible que no estén conectadas y activas a pesar de haber sido creadas. En esta situación, una VM puede parecer que no es ágil y no está protegida por una alta disponibilidad. Puede usar el comando de la interfaz de línea de comandos pif-plug para activar la VLAN y los PIF de enlace, de modo que la VM pueda volverse ágil. También puede determinar con precisión por qué una VM no es ágil mediante el comando xe diagnostic-vm-status de la CLI. Este comando analiza sus restricciones de posición y puede tomar medidas correctivas si es necesario.

Reiniciar la configuración

Las máquinas virtuales se pueden considerar protegidas, con el mejor esfuerzo o desprotegidas por la alta disponibilidad. El valor de ha-restart-priority define si una VM se trata como protegida, con el mejor esfuerzo o sin protección. El comportamiento de reinicio de las VM en cada una de estas categorías es diferente.

Protegido

La alta disponibilidad garantiza reiniciar una VM protegida que se desconecta o cuyo host se desconecta, siempre que el grupo no se comprometa en exceso y la VM sea ágil.

Si una máquina virtual protegida no se puede reiniciar cuando falla un host, High Availability intenta iniciar la máquina virtual cuando hay capacidad adicional en un grupo. Los intentos de iniciar la VM cuando hay capacidad adicional ahora pueden tener éxito.

ha-restart-priority Valor: restart

Mejor esfuerzo

Si el host de una máquina virtual con el mejor esfuerzo se desconecta, la alta disponibilidad intenta reiniciar la máquina virtual con el mejor esfuerzo en otro host. Hace este intento solo después de que todas las VM protegidas se hayan reiniciado correctamente. La alta disponibilidad solo hace un intento de reiniciar una VM con el mejor esfuerzo. Si este intento falla, la alta disponibilidad no hace más intentos de reiniciar la VM.

ha-restart-priority Valor: best-effort

Sin protección

Si se detiene una máquina virtual desprotegida o el host en el que se ejecuta, la alta disponibilidad no intenta reiniciar la máquina virtual.

ha-restart-priority Valor: el valor es una cadena vacía

Nota:

La alta disponibilidad nunca detiene ni migra una VM en ejecución para liberar recursos para que se reinicie una VM protegida o de mejor esfuerzo.

Si el grupo experimenta errores en el host y el número de errores tolerables cae a cero, no se garantiza que las máquinas virtuales protegidas se reinicien. En tales casos, se genera una alerta del sistema. Si se produce otro error, todas las VM que tienen una prioridad de reinicio establecida se comportan de acuerdo con el comportamiento de mejor esfuerzo.

Comenzar pedido

El orden de inicio es el orden en el que XenServer High Availability intenta reiniciar las máquinas virtuales protegidas cuando se produce un error. Los valores de la propiedad order para cada una de las máquinas virtuales protegidas determinan el orden de inicio.

La propiedad order de una VM es utilizada por la alta disponibilidad y también por otras funciones que inician y apagan las VM. Cualquier máquina virtual puede tener la propiedad order establecida, no solo las máquinas virtuales marcadas como protegidas para alta disponibilidad. Sin embargo, la alta disponibilidad utiliza la propiedad order solo para máquinas virtuales protegidas.

El valor de la propiedad order es un entero. El valor predeterminado es 0, que es la prioridad más alta. Las máquinas virtuales protegidas con un valor order de 0 se reinician primero por la alta disponibilidad. Cuanto mayor sea el valor de la propiedad order, más tarde en la secuencia se reiniciará la VM.

Puede establecer el valor de la propiedad order de una máquina virtual mediante la interfaz de línea de comandos:

xe vm-param-set uuid=<vm uuid> order=<int>
<!--NeedCopy-->

O bien, en XenCenter, en el panel de opciones de inicio de una máquina virtual, defina el orden de inicio en el valor requerido.

Habilite la alta disponibilidad en su grupo de XenServer

Puede habilitar la alta disponibilidad en un grupo mediante XenCenter o la interfaz de línea de comandos (CLI). En cualquier caso, se especifica un conjunto de prioridades que determinan qué máquinas virtuales reciben la prioridad de reinicio más alta cuando un grupo está sobrecomprometido.

Advertencias:

• Al habilitar la alta disponibilidad, es posible que se inhabiliten algunas operaciones que comprometen el plan de reinicio de las máquinas virtuales (como eliminar un host de un grupo). Puede inhabilitar temporalmente la alta disponibilidad para realizar dichas operaciones o, alternativamente, hacer que las máquinas virtuales protegidas por alta disponibilidad no estén protegidas.

• Si la alta disponibilidad está habilitada, no puede habilitar la agrupación en clústeres en su grupo. Desactive temporalmente la alta disponibilidad para habilitar la agrupación en clústeres A continuación, puede habilitar la alta disponibilidad en su agrupación en clústeres. Algunos comportamientos de alta disponibilidad, como la autodelimitación, son diferentes para los grupos agrupados en clúster. Para obtener más información, consulte Grupos agrupados.

Habilite la alta disponibilidad mediante la CLI

1. Compruebe que tiene un repositorio de almacenamiento (SR) compatible conectado a su grupo. Los SR iSCSI, NFS o Fibre Channel son compatibles. Para obtener información sobre cómo configurar dicho repositorio de almacenamiento mediante la CLI, consulte Administrar repositorios de almacenamiento.

2. Para cada máquina virtual que quiera proteger, establezca una prioridad de reinicio y orden de inicio. Puede establecer la prioridad de reinicio de la siguiente manera:

   xe vm-param-set uuid=<vm uuid> ha-restart-priority=restart order=1
   <!--NeedCopy-->
   

3. Habilite la alta disponibilidad en el grupo y, opcionalmente, especifique un tiempo de espera:

   xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
   <!--NeedCopy-->
   

   Como alternativa, puede establecer un tiempo de espera predeterminado para su agrupación. Para obtener más información sobre cómo establecer un tiempo de espera, consulte Configurar el tiempo de espera de alta disponibilidad.

4. Ejecute el comando pool-ha-compute-max-host-failures-to-tolerate. Este comando devuelve la cantidad máxima de hosts que pueden fallar antes de que no haya recursos suficientes para ejecutar todas las VM protegidas del grupo.

   xe pool-ha-compute-max-host-failures-to-tolerate
   <!--NeedCopy-->
   

   El número de errores a tolerar determina cuándo se envía una alerta. El sistema vuelve a calcular un plan de conmutación por error a medida que cambia el estado del grupo. Utiliza este cálculo para identificar la capacidad del grupo y cuántos errores más son posibles sin perder la garantía de vida para las VM protegidas. Se genera una alerta del sistema cuando este valor calculado cae por debajo del valor especificado para ha-host-failures-to-tolerate.

5. Especifique el parámetro ha-host-failures-to-tolerate. El valor debe ser menor o igual que el valor calculado:

   xe pool-param-set ha-host-failures-to-tolerate=2 uuid=<pool uuid>
   <!--NeedCopy-->
   

Configurar el tiempo de espera de alta disponibilidad

El tiempo de espera es el período durante el cual los hosts de su grupo no pueden acceder a la red o al almacenamiento. Si algún host de XenServer no puede acceder a la red o al almacenamiento dentro del período de espera, puede autoprotegerse y reiniciarse. El tiempo de espera predeterminado es de 60 segundos. Sin embargo, puede cambiar este valor mediante el siguiente comando.

Establezca un tiempo de espera de alta disponibilidad predeterminado para su grupo:

xe pool-param-set uuid=<pool uuid> other-config:default_ha_timeout=<timeout in seconds>
<!--NeedCopy-->

Si habilita la alta disponibilidad mediante XenCenter en lugar de la CLI de xe, este valor predeterminado seguirá aplicándose.

Como alternativa, puede establecer el tiempo de espera cuando habilita la alta disponibilidad:

xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
<!--NeedCopy-->

Tenga en cuenta que si establece el tiempo de espera al habilitar la alta disponibilidad, solo se aplica a esa habilitación específica. Por lo tanto, si inhabilitas y vuelve a habilitar la alta disponibilidad más adelante, la función de alta disponibilidad vuelve a usar el tiempo de espera predeterminado.

Eliminar la protección de alta disponibilidad de una VM mediante la CLI

Para inhabilitar las funciones de alta disponibilidad de una máquina virtual, utilice el comando xe vm-param-set para establecer el parámetro ha-restart-priority como una cadena vacía. Al establecer el parámetro ha-restart-priority no se borra la configuración del orden de inicio. Puede volver a habilitar la alta disponibilidad para una máquina virtual configurando el parámetro ha-restart-priority en restart o best-effort según corresponda.

Recuperar un host inalcanzable

Si, por alguna razón, un host no puede acceder al archivo de estado de alta disponibilidad, es posible que un host se vuelva inaccesible. Para recuperar la instalación de XenServer, es posible que deba inhabilitar la alta disponibilidad mediante el comando host-emergency-ha-disable:

xe host-emergency-ha-disable --force
<!--NeedCopy-->

Si el host era el coordinador del grupo, se inicia normalmente con la alta disponibilidad inhabilitada. Los miembros del grupo se vuelven a conectar y desactivan automáticamente la alta disponibilidad Si el anfitrión era miembro del grupo y no puede ponerse en contacto con el coordinador del grupo, es posible que deba realizar una de las siguientes acciones:

• Forzar al host a reiniciarse como coordinador de grupos (xe pool-emergency-transition-to-master)

   xe pool-emergency-transition-to-master uuid=<host uuid>
   <!--NeedCopy-->
  

• Dígale al anfitrión dónde está el nuevo coordinador de la agrupación (xe pool-emergency-reset-master):

   xe pool-emergency-reset-master master-address=<new pool coordinator hostname>
   <!--NeedCopy-->
  

Cuando todos los hosts se hayan reiniciado correctamente, vuelva a habilitar la alta disponibilidad:

xe pool-ha-enable heartbeat-sr-uuid=<sr uuid>
<!--NeedCopy-->

Apagar un host cuando la alta disponibilidad está habilitada

Tenga especial cuidado al apagar o reiniciar un host para evitar que el mecanismo de alta disponibilidad asuma que el host ha fallado. Para cerrar un host de forma limpia cuando la alta disponibilidad está habilitada, inhabilite el host, evacúe el host y, por último, apague el host mediante XenCenter o la CLI. Para apagar un host en un entorno en el que la alta disponibilidad esté habilitada, ejecute estos comandos:

xe host-disable host=<host name>
xe host-evacuate uuid=<host uuid>
xe host-shutdown host=<host name>
<!--NeedCopy-->

Apagar una VM protegida por alta disponibilidad

Cuando una máquina virtual está protegida por un plan de alta disponibilidad y se configura para que se reinicie automáticamente, no se puede cerrar mientras esta protección está activa. Para apagar una máquina virtual, primero desactive su protección de alta disponibilidad y, a continuación, ejecute el comando CLI. XenCenter le ofrece un cuadro de diálogo para automatizar la desactivación de la protección cuando selecciona el botón Apagar de una máquina virtual protegida.

Nota:

Si apaga una VM desde el huésped y la VM está protegida, se reinicia automáticamente en las condiciones de falla de alta disponibilidad. El reinicio automático ayuda a garantizar que el error del operador no provoque que una VM protegida se apague accidentalmente. Si desea cerrar esta máquina virtual, inhabilite primero la protección de alta disponibilidad.