Alta disponibilidad

Importante:

La actualización acumulativa 1 de Citrix Hypervisor 8.2 llega al final de su vida útil el 25 de junio de 2025. Planifique su actualización a XenServer 8 ahora para garantizar una transición fluida y un soporte continuo. Para obtener más información, consulte Actualizar.

Si utiliza los archivos de licencia de Citrix Virtual Apps and Desktops para licenciar los hosts de Citrix Hypervisor 8.2 Cumulative Update 1, estos archivos de licencia no son compatibles con XenServer 8. Antes de actualizar, debe adquirir los archivos de licencia de socket de XenServer Premium Edition para utilizarlos con XenServer 8. Estos archivos de licencia de socket están disponibles como un derecho de las suscripciones de Citrix para Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP y Citrix Platform License para ejecutar sus cargas de trabajo de Citrix. Los clientes de Citrix que aún no hayan realizado la transición a estas nuevas suscripciones pueden solicitar participar en una promoción gratuita de 10.000 licencias de socket de XenServer Premium Edition. Para obtener más información, consulte XenServer.

Si no obtiene una licencia compatible para XenServer 8 antes de actualizar, cuando actualice sus hosts, estos volverán a la edición de prueba de 90 días. La Edición de Prueba ofrece las mismas características que la Edición Premium con algunas limitaciones. Para obtener más información, consulte Descripción general de las licencias de XenServer 8.

La alta disponibilidad es un conjunto de funciones automáticas diseñadas para planificar y recuperarse de manera segura de problemas que inutilizan los servidores de Citrix Hypervisor o los hacen inaccesibles. Por ejemplo, durante una red interrumpida físicamente o fallas del hardware del host.

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 reinician de manera segura en otro host de manera automática. Esto elimina la necesidad de reiniciar manualmente las máquinas virtuales, lo que da como resultado un tiempo de inactividad mínimo de las mismas.

Cuando el maestro del grupo se vuelve inalcanzable 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 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 alta disponibilidad junto con almacenamiento multirruta y redes enlazadas. Configure el almacenamiento multirruta y la red enlazada antes de intentar configurar la alta disponibilidad. Los clientes que no configuran almacenamiento multirruta y redes enlazadas pueden experimentar un comportamiento de reinicio de host inesperado (autoprotección) cuando hay una inestabilidad en la infraestructura.

Se pueden usar todas las soluciones gráficas (NVIDIA vGPU, AMD MxGPU (obsoleto) y vGPU pass-through) en un entorno que utiliza 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 en la medida de lo posible mientras haya hosts con los recursos gratuitos adecuados.

Comprometerse en exceso

Un grupo está sobrecargado cuando las máquinas virtuales que se están ejecutando actualmente no se pueden reiniciar en otro lugar luego de una cantidad de fallas de host definida por el usuario. Se puede producir un exceso de compromiso si no hay suficiente memoria libre en el grupo para ejecutar esas máquinas virtuales después de una falla. Sin embargo, también hay cambios más sutiles que pueden hacer que la alta disponibilidad sea insostenible: los cambios en los dispositivos de bloque virtuales (VBD) y las redes pueden afectar qué máquinas virtuales se pueden reiniciar en qué hosts. Citrix Hypervisor no puede verificar todas las acciones potenciales y determinar si provocan violaciones de las demandas de alta disponibilidad. Sin embargo, se envía una notificación asincrónica si la alta disponibilidad se vuelve insostenible.

Citrix Hypervisor 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 determinado. Un concepto importante a comprender es la tolerancia de las fallas del host al valor , que se define como parte de la configuración de alta disponibilidad. El valor de fallas de host a tolerar determina la cantidad de fallas de host que se permiten mientras aún se pueden reiniciar todas las máquinas virtuales protegidas. Por ejemplo, considere un grupo de recursos que consta de 64 hosts y fallas de host a tolerar; está configurado en 3. En este caso, el grupo calcula un plan de conmutación por error que permite que tres hosts fallen y luego reinicia las máquinas virtuales en otros hosts. Si no se puede encontrar un plan, se considera que el grupo está sobrecargado. 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 adición de nuevas máquinas virtuales al grupo) provocan que el grupo se sobrecargue, se envían alertas a través de XenCenter o por correo electrónico.

Advertencia de compromiso excesivo

Si algún intento de iniciar o reanudar una máquina virtual provoca que el grupo se sobrecargue, se muestra una alerta de advertencia en XenCenter. Luego puede optar por cancelar la operación o continuar de todos modos. Al continuar, el grupo se sobrecarga y se envía un mensaje a todas las direcciones de correo electrónico configuradas. Esto también está disponible como una instancia de mensaje a través de la API de administración. La cantidad de memoria utilizada por las máquinas virtuales de diferentes prioridades se muestra en los niveles de grupo y host.

Cercado de acogida

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, el servidor Citrix Hypervisor se autoprotege para garantizar que las máquinas virtuales no se ejecuten en dos servidores simultáneamente. Cuando se realiza una acción de vallado, el servidor se reinicia de manera 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 están en ejecución y luego las reinician según las prioridades de reinicio asignadas a ellas. El servidor cercado ingresa a una secuencia de reinicio y, cuando se reinicia, intenta volver a unirse al grupo de recursos.

Nota: No

Los hosts en grupos agrupados también pueden autoprotegerse cuando no pueden comunicarse con más de la mitad de los otros hosts en el 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 hipervisores de Citrix (esta función proporciona alta disponibilidad a nivel de servidor dentro de un único grupo de recursos).

  Nota: No

  Le recomendamos que habilite la alta disponibilidad solo en grupos que contengan al menos 3 servidores Citrix Hypervisor. 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 tamaño 356 MB o mayor: el latido SR. El mecanismo de alta disponibilidad crea dos volúmenes en el SR de latido:

  • Volumen de latido de 4 MB: se utiliza para proporcionar un latido.
  • Volumen de metadatos de 256 MB: para almacenar los metadatos del grupo maestro que se utilizarán si hay una conmutación por error del maestro.

  Nota: No

  Anteriormente, recomendábamos utilizar un repositorio de almacenamiento NFS o iSCSI dedicado como su 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 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 servidor 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 bloquear el host y dejarlo en un estado en el que no se puede iniciar. Para remediar esta situación, deshabilite la alta disponibilidad mediante el comando host-emergency-ha-disable , restablezca el pool master mediante pool-emergency-reset-mastery luego vuelva a habilitar la alta disponibilidad.

• Para lograr la máxima confiabilidad, recomendamos utilizar una interfaz vinculada dedicada como red de administración de alta disponibilidad.

• La red de administración debe permitir el tráfico UDP de latido de red a través del puerto 694.

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

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

• Puede utilizar la migración en vivo.

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

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

Nota: No

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

Si crea VLAN e interfaces vinculadas desde la CLI, es posible que no se conecten ni se activen a pesar de haber sido creadas. En esta situación, una VM puede parecer poco ágil y no está protegida por alta disponibilidad. Puede utilizar el comando CLI pif-plug para activar la VLAN y vincular los PIF para que la VM pueda volverse ágil. También puede determinar con precisión por qué una máquina virtual no es ágil utilizando el comando CLI xe diagnostic-vm-status . Este comando analiza sus restricciones de ubicación y puede tomar medidas correctivas si es necesario.

Reiniciar la configuración

Las máquinas virtuales pueden considerarse protegidas, de máximo esfuerzo o desprotegidas por alta disponibilidad. El valor de ha-restart-priority define si una VM se trata como protegida, de máximo esfuerzo o desprotegida. El comportamiento de reinicio de las máquinas virtuales en 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 esté sobrecargado y la máquina virtual sea ágil.

Si no se puede reiniciar una VM protegida cuando falla un servidor, la alta disponibilidad intenta iniciar la VM cuando hay capacidad adicional en un grupo. Es posible que ahora los intentos de iniciar la máquina virtual cuando hay capacidad adicional tengan éxito.

ha-restart-priority Valor: reiniciar

Máximo esfuerzo

Si el host de una máquina virtual de máximo esfuerzo se desconecta, la alta disponibilidad intenta reiniciar la máquina virtual de máximo esfuerzo 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.

ha-restart-priority Valor: mejor esfuerzo

Desprotegido

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: No

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 de máximo esfuerzo.

Si el grupo experimenta fallas en el servidor y la cantidad de fallas 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 ocurre otra falla, todas las máquinas virtuales que tienen una prioridad de reinicio establecida se comportan de acuerdo con el comportamiento de máximo esfuerzo.

Orden de inicio

El orden de inicio es el orden en el que la alta disponibilidad de Citrix Hypervisor intenta reiniciar las máquinas virtuales protegidas cuando se produce una falla. Los valores de la propiedad de orden `` para cada una de las máquinas virtuales protegidas determinan el orden de inicio.

La propiedad de orden 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 establecida la propiedad de orden , no solo las máquinas virtuales marcadas como protegidas para alta disponibilidad. Sin embargo, la alta disponibilidad utiliza la propiedad de orden `` solo para máquinas virtuales protegidas.

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

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

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

O en XenCenter, en el panel Opciones de inicio de una VM, configure Orden de inicio en el valor requerido.

Habilite la alta disponibilidad en su grupo de hipervisores Citrix

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 mayor prioridad de reinicio cuando un grupo está sobrecargado.

Advertencias:

• Al habilitar la alta disponibilidad, es posible que se desactiven algunas operaciones que comprometen el plan de reinicio de las máquinas virtuales (como eliminar un servidor de un grupo). Puede deshabilitar temporalmente la alta disponibilidad para realizar dichas operaciones o, como alternativa, hacer que las máquinas virtuales protegidas por alta disponibilidad queden desprotegidas.

• Si la alta disponibilidad está habilitada, no podrá 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 su grupo agrupado. Algunos comportamientos de alta disponibilidad, como el autocercado, son diferentes para los grupos agrupados. Para obtener más información, consulte Grupos agrupados.

Habilite la alta disponibilidad mediante el uso de la CLI

1. Verifique que tenga 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 desee proteger, establezca una prioridad de reinicio y un 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-->
   

   Alternativamente, puede establecer un tiempo de espera predeterminado para su grupo. 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 suficientes recursos para ejecutar todas las máquinas virtuales protegidas en el grupo.

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

   La cantidad de fallas 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ántas fallas más son posibles sin perder la garantía de actividad de las máquinas virtuales 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 al 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 de alta disponibilidad es el período durante el cual los hosts de su grupo no pueden acceder a la red o al almacenamiento. Si algún servidor Citrix Hypervisor no puede acceder a la red o al almacenamiento dentro del período de tiempo de espera, puede autoprotegerse y reiniciarse. El tiempo de espera predeterminado es de 60 segundos. Sin embargo, puedes cambiar este valor utilizando 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 xe, este valor predeterminado aún se aplica.

Alternativamente, puede establecer un tiempo de espera cuando habilite 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 un tiempo de espera al habilitar la alta disponibilidad, solo se aplica a esa habilitación específica. Por lo tanto, si deshabilita y luego vuelve a habilitar la alta disponibilidad más tarde, la función de alta disponibilidad vuelve a utilizar el tiempo de espera predeterminado.

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

Para deshabilitar las funciones de alta disponibilidad de una máquina virtual, use el comando xe vm-param-set para establecer el parámetro ha-restart-priority como una cadena vacía. La configuración del parámetro ha-restart-priority no borra la configuración del orden de inicio. Puede habilitar nuevamente 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 se vuelva inaccesible. Para recuperar su instalación de Citrix Hypervisor, es posible que tenga que deshabilitar la alta disponibilidad mediante el comando host-emergency-ha-disable :

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

Si el host era el maestro del grupo, se inicia normalmente con la alta disponibilidad deshabilitada. Los miembros del grupo se reconectan y desactivan automáticamente la alta disponibilidad. Si el host era miembro del grupo y no puede comunicarse con el maestro, es posible que deba realizar una de las siguientes acciones:

• Obligar al host a reiniciarse como maestro de grupo (xe pool-emergency-transition-to-master)

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

• Dígale al host dónde está el nuevo maestro (xe pool-emergency-reset-master):

     xe pool-emergency-reset-master master-address=<new master 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-->

Apagado de 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 apagar un host de manera limpia cuando la alta disponibilidad está habilitada, deshabilite el host, evacúelo y, finalmente, apáguelo mediante XenCenter o la CLI. Para apagar un host en un entorno donde está habilitada la alta disponibilidad, ejecute estos comandos:

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

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 apagar una máquina virtual, primero deshabilite su protección de alta disponibilidad y luego 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 VM protegida.

Nota: No

Si apaga una VM desde dentro del invitado 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 un error del operador no provoque que una máquina virtual protegida se apague accidentalmente. Si desea apagar esta máquina virtual, primero deshabilite su protección de alta disponibilidad.