Alta disponibilidad

La alta disponibilidad es un conjunto de características automáticas diseñadas para planificar y recuperarse de manera segura de problemas que destruen servidores HASH (0x2e68218) o los hacen inaccesibles. Por ejemplo, durante fallas de hardware de host o de red interrumpidas físicamente.

Información general

La alta disponibilidad garantiza que cuando un host se vuelve inaccesible o inestable, las máquinas virtuales que se ejecutan en ese host se apagan y se reinician en otro host. Cerrar y reiniciar máquinas virtuales en otro host evita que las máquinas virtuales se inicien (manual o automáticamente) en un nuevo host. En algún momento más tarde, se recupera el host original. Este escenario puede dar lugar a dos instancias de la misma máquina virtual ejecutándose en hosts diferentes y a una alta probabilidad correspondiente de corrupción del disco de la máquina virtual y pérdida de datos.

Cuando el maestro de grupo 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 restablezca automáticamente sin ninguna intervención manual.

Opcionalmente, la alta disponibilidad también puede automatizar el proceso de reinicio de 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 el reinicio en grupos para permitir tiempo para iniciar los servicios. Permite que las máquinas virtuales de infraestructura se inicien antes de las máquinas virtuales dependientes (por ejemplo, un servidor DHCP antes de su servidor SQL dependiente).

Advertencias:

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

Todas las soluciones gráficas (nVidia vGPU, Intel GVT-d, Intel GVT-G, AMD MxGPU y vGPU pass-through) se pueden utilizar en un entorno que hace uso de alta disponibilidad. Sin embargo, las máquinas virtuales que utilizan 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 hay hosts con los recursos libres adecuados.

Sobrecomprometiéndose

Un grupo está en exceso cuando las máquinas virtuales que se están ejecutando actualmente no se pueden reiniciar en otro lugar después de un número definido por el usuario de errores de host.

La sobrecomisió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 las garantías de alta disponibilidad sean insostenibles: los cambios en los dispositivos de bloques virtuales (VBD) y las redes pueden afectar qué máquinas virtuales se pueden reiniciar en qué hosts. HASH (0x2c1a078) no puede comprobar todas las acciones potenciales y determinar si causan una violación de las demandas de alta disponibilidad. Sin embargo, se envía una notificación asíncrona si la alta disponibilidad se vuelve insostenible.

HASH (0x2c1a078) mantiene dinámicamente un plan de conmutación por error que detalla qué hacer cuando un conjunto de hosts en un grupo falla en un momento dado. Un concepto importante a entender son los errores del host para tolerar el valor, que se define como parte de la configuración de alta disponibilidad. El valor de los errores de host que se deben tolerar determina el número de errores permitidos sin pérdida de servicio. Por ejemplo, considere un fondo de recursos que consta de 64 hosts y los errores tolerados se establece en 3. En este caso, el grupo calcula un plan de conmutación por error que permite que tres hosts puedan fallar y reiniciar las máquinas virtuales en otros hosts. Si no se puede encontrar un plan, se considera que el grupo está sobrecomprometido. El plan se vuelve a calcular 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 adición de nuevas máquinas virtuales al grupo, hacen que el grupo se vuelva demasiado comprometido, se envían alertas (ya sea a través de HASH (0x2e6c8e8) o correo electrónico).

Advertencia de sobrecompromiso

Si algún intento de iniciar o reanudar una máquina virtual hace que el grupo esté sobrecomprometido, se mostrará una alerta de advertencia. Esta advertencia aparece en HASH (0x2e6c8e8) y también está disponible como instancia de mensaje a través de la API de administración. Si ha configurado una dirección de correo electrónico, también puede enviarse un mensaje a la dirección de correo electrónico. A continuación, puede cancelar la operación o continuar de todos modos. Procediendo hace que el grupo se vuelva demasiado comprometido. La cantidad de memoria utilizada por las máquinas virtuales de diferentes prioridades se muestra en los niveles de pool y host.

Esgrima de host

A veces, un servidor puede fallar debido a la pérdida de conectividad de red o cuando se encuentra un problema con la pila de control. En tales casos, las autovallas del servidor HASH (0x2e68218) para garantizar que las máquinas virtuales no se ejecutan en dos servidores simultáneamente. Cuando se realiza una acción de vallas, el servidor se reinicia de forma inmediata y abrupta, lo que provoca que todas las máquinas virtuales que se ejecutan en él se detengan. Los demás servidores detectan que las máquinas virtuales ya no se ejecutan y que las máquinas virtuales se reinician según las prioridades de reinicio asignadas a ellas. El servidor cercado entra en una secuencia de reinicio y, cuando se ha reiniciado, intenta volver a unirse al fondo de recursos.

Nota:

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

Requisitos de configuración

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

  • pool HASH (0x2e68218) (esta característica proporciona alta disponibilidad en el nivel del servidor dentro de un único grupo de recursos).

    Nota:

    Recomendamos que habilite la alta disponibilidad sólo en grupos que contengan al menos tres servidores HASH (0x2e68218). Para obtener más información, consulte CTX129721 - Comportamiento de alta disponibilidad cuando se pierde el latido en un grupo.

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

    4 MB de volumen de latidos: se utiliza para latidos cardíacos.

    Volumen de metadatos de 256 MB: para almacenar metadatos maestros de grupo que se utilizarán si hay una conmutación por error maestra.

    Notas:

    • Para obtener la máxima fiabilidad, se recomienda utilizar un repositorio de almacenamiento NFS o iSCSI dedicado como disco de latido de alta disponibilidad. No utilice este repositorio de almacenamiento para ningún otro propósito.
    • Si su grupo es un grupo agrupado, su SR de latido debe ser un SR de GFS2.
    • El almacenamiento conectado mediante SMB o iSCSI cuando se autentica mediante CHAP no se puede utilizar como SR de latido.
    • Cuando utilice NetApp o EqualLogic SR, aprovisione manualmente un LUN NFS o iSCSI en la cabina para utilizarlo como SR de latido.
  • Direcciones IP estáticas para todos los hosts.

    Advertencia:

    Si la dirección IP de un servidor cambia mientras está habilitada la alta disponibilidad, 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 que no se puede arrancar. Para remediar esta situación, deshabilite la alta disponibilidad mediante elhost-emergency-ha-disable comando, restablezca el patrón de grupo utilizando ypool-emergency-reset-master , a continuación, vuelva a habilitar la alta disponibilidad.

  • Para obtener la máxima fiabilidad, se recomienda utilizar una interfaz vinculada dedicada como red de administración de alta disponibilidad.

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

  • Debe tener sus discos virtuales en almacenamiento compartido. Puede utilizar cualquier tipo de almacenamiento compartido. iSCSI, NFS o LUN de canal de fibra sólo es necesario para el latido del almacenamiento y se puede utilizar para el almacenamiento en disco virtual.

  • Puede usar la migración en vivo

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

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

Nota:

Cuando se habilita la alta disponibilidad, se recomienda utilizar una interfaz de administración vinculada en los servidores del grupo y almacenamiento de múltiples rutas para el SR de latido.

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 máquina virtual puede parecer que no es ágil y no está protegida por la alta disponibilidad. Puede usar elpif-plug comando CLI para que la VLAN y los PIFs de enlace para que la VM pueda volverse ágil. También puede determinar con precisión por qué una máquina virtual no es ágil mediante el comandoxe diagnostic-vm-status CLI. Este comando analiza sus restricciones de ubicación y puede tomar medidas correctivas si es necesario.

Reiniciar los ajustes de configuración

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

Protegido

La alta disponibilidad garantiza reiniciar una máquina virtual protegida que se desconecta o cuyo host se desconecta, siempre que el grupo no se haya comprometido en exceso y la máquina virtual sea ágil.

Si no se puede reiniciar una máquina virtual protegida cuando un servidor falla, la alta disponibilidad intenta iniciar la máquina virtual cuando hay capacidad adicional en un grupo. Ahora es posible que los intentos de iniciar la máquina virtual cuando hay capacidad adicional tengan é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. Realiza este intento sólo después de que todas las máquinas virtuales protegidas se hayan reiniciado correctamente. La alta disponibilidad hace un solo intento de reiniciar una máquina virtual con el mejor esfuerzo. Si este intento falla, la alta disponibilidad no realiza más intentos de reiniciar la máquina virtual.

ha-restart-priority Valor:best-effort

Sin protección

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

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

Nota:

La alta disponibilidad nunca detiene ni migra una máquina virtual en ejecución para liberar recursos para que se reinicie una máquina virtual protegida o con el mejor esfuerzo.

Si el grupo experimenta errores en el servidor 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 máquinas virtuales que tienen un conjunto de prioridades de reinicio se comportan de acuerdo con el comportamiento del mejor esfuerzo.

Iniciar pedido

El orden de inicio es el orden en el que HASH (0x2c1a078) alta disponibilidad intenta reiniciar las máquinas virtuales protegidas cuando se produce un error. Los valores de laorder propiedad para cada una de las máquinas virtuales protegidas determinan el orden de inicio.

Laorder propiedad de una máquina virtual se utiliza por la alta disponibilidad y también por otras características que inician y apagan las máquinas virtuales. Cualquier máquina virtual puede tener el conjunto deorder propiedades, no solo las máquinas virtuales marcadas como protegidas para alta disponibilidad. Sin embargo, la alta disponibilidad sólo utiliza laorder propiedad para máquinas virtuales protegidas.

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

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

xe vm-param-set uuid=VM_UUID order=int

O bien, en HASH (0x2e6c8e8), en el panel Opciones de inicio para una máquina virtual, establezca el orden de inicio en el valor requerido.

Habilite la alta disponibilidad en su grupo HASH (0x2e68218)

Puede habilitar la alta disponibilidad en un grupo mediante HASH (0x2e6c8e8) o la interfaz de línea de comandos. En cualquier caso, especifique un conjunto de prioridades que determinan qué máquinas virtuales tienen la prioridad de reinicio más alta cuando un grupo está en exceso.

Advertencias:

  • Al habilitar la alta disponibilidad, algunas operaciones que comprometen el plan para reiniciar las máquinas virtuales, como quitar un servidor de un grupo, pueden estar deshabilitadas. Puede deshabilitar temporalmente la alta disponibilidad para realizar dichas operaciones o, alternativamente, hacer que las VM estén protegidas por alta disponibilidad desprotegidas.

  • Si está habilitada la alta disponibilidad, no puede habilitar la agrupación en clústeres en su grupo. Deshabilite temporalmente la alta disponibilidad para habilitar la agrupación en clústeres. Puede habilitar la alta disponibilidad en el grupo agrupado. Alguns comportamentos de alta disponibilidade, como auto-cercado, é diferente para pools em cluster. 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 al grupo. Los SRs iSCSI, NFS o Fibre Channel son compatibles. Para obtener información acerca de cómo configurar dicho repositorio de almacenamiento mediante la CLI, consulteAdministrar repositorios de almacenamiento de información.

  2. Para cada máquina virtual que desee 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
    
  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
    

    El tiempo de espera es el período durante el cual los hosts del grupo no pueden acceder a la red o al almacenamiento. Si no especifica un tiempo de espera al habilitar la alta disponibilidad, HASH (0x2e68218) utiliza el tiempo de espera predeterminado de 30 segundos. Si algún servidor HASH (0x2e68218) no puede acceder a la red o al almacenamiento dentro del período de tiempo de espera, puede autocercar y reiniciar.

  4. Ejecute el comandopool-ha-compute-max-host-failures-to-tolerate. Este comando devuelve el número máximo de hosts que pueden fallar antes de que no haya recursos suficientes para ejecutar todas las máquinas virtuales protegidas en el grupo.

    xe pool-ha-compute-max-host-failures-to-tolerate
    

    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 pool y cuántas fallas más son posibles sin pérdida de 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 paraha-host-failures-to-tolerate.

  5. Especifique el número de errores que se deben tolerar los parámetros. El valor debe ser menor o igual que el valor calculado:

    xe pool-param-set ha-host-failures-to-tolerate=2 uuid=pool-uuid
    

Elimine la protección de alta disponibilidad de una máquina virtual mediante la CLI

Para deshabilitar las funciones de alta disponibilidad para una máquina virtual, utilice elxe vm-param-set comando para establecer elha-restart-priority parámetro como una cadena vacía. Al establecer elha-restart-priority parámetro no se borra la configuración del orden de inicio. Puede habilitar de nuevo la alta disponibilidad para una máquina virtual estableciendo elha-restart-priority parámetro enrestart obest-effort según corresponda.

Recuperar un host inaccesible

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 su instalación HASH (0x2c1a078), puede que tenga que deshabilitar la alta disponibilidad usando elhost-emergency-ha-disable comando:

xe host-emergency-ha-disable --force

Si el host era el maestro del grupo, se inicia de forma normal con alta disponibilidad deshabilitada. Los miembros del grupo se vuelven a conectar y deshabilitan automáticamente la alta disponibilidad. Si el host era un miembro del grupo y no puede ponerse en contacto con el maestro, es posible que tenga que realizar una de las siguientes acciones:

  • Forzar el host a reiniciar como maestro de grupo (xe pool-emergency-transition-to-master)

     xe pool-emergency-transition-to-master uuid=host_uuid
    
  • Dígale al anfitrión dónde está el nuevo maestro (xe pool-emergency-reset-master):

     xe pool-emergency-reset-master master-address=new_master_hostname
    

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

xe pool-ha-enable heartbeat-sr-uuid=sr_uuid

Cerrar un host cuando se habilita la alta disponibilidad

Tenga especial cuidado al cerrar o reiniciar un host para evitar que el mecanismo de alta disponibilidad suponga que el host ha fallado. Para cerrar un host limpiamente cuando se habilita la alta disponibilidad,disable el host,evacuate el host y, finalmente,shutdown el host mediante HASH (0x2e6c8e8) o la CLI. Para apagar un host en un entorno donde 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

Apagar una máquina virtual protegida por alta disponibilidad

Cuando una máquina virtual está protegida bajo un plan de alta disponibilidad y configurada para reiniciarse automáticamente, no se puede apagar mientras esta protección esté activa. Para cerrar una máquina virtual, deshabilite primero su protección de alta disponibilidad y, a continuación, ejecute el comando CLI. HASH (0x2e6c8e8) le ofrece un cuadro de diálogo para automatizar la desactivación de la protección al seleccionar el botón de apagado de una máquina virtual protegida.

Nota:

Si apaga una máquina virtual desde el invitado y la máquina virtual está protegida, se reinicia automáticamente en las condiciones de error de alta disponibilidad. El reinicio automático ayuda a garantizar que el error del operador no dé lugar a que una máquina virtual protegida se deje apagada accidentalmente. Si desea apagar esta máquina virtual, deshabilite primero su protección de alta disponibilidad.