Acerca de XenServer HA

XenServer High Availability (HA) permite que las máquinas virtuales se reinicien automáticamente en caso de que se produzca una falla de hardware subyacente o se pierda cualquier servidor administrado. HA se trata de asegurarse de que las máquinas virtuales importantes se ejecuten siempre en un fondo de recursos. Con HA activado, si uno de sus servidores falla, sus máquinas virtuales se reiniciarán de forma inteligente en otros servidores del mismo grupo, lo que permitirá restaurar los servicios esenciales en caso de fallo del sistema o del componente con una interrupción mínima del servicio. Si se produce un error en el servidor maestro de grupo, XenServer HA selecciona automáticamente un nuevo servidor para que se haga cargo como maestro, de modo que pueda seguir administrando el grupo. Cualquier servidor de un grupo puede ser un servidor maestro, y la base de datos del grupo se replica constantemente en todos los nodos y también se hace backup en almacenamiento compartido en el latido SR para mayor seguridad.

XenServer HA tiene dos aspectos clave: la detección fiable de fallos en el servidor y el cálculo de un plan de fallas para permitir una recuperación rápida, que se tratan en detalle a continuación.

Heartbeats para disponibilidad

Detectar fallos de servidor de forma fiable es difícil, ya que es necesario distinguir de forma remota entre un servidor que desaparece durante un tiempo y un fallo catastrófico. Si decidimos erróneamente que un servidor maestro se ha descompuesto y elegimos un nuevo maestro en su lugar, puede haber resultados impredecibles si el servidor original fuera a hacer una reaparición. Del mismo modo, si hay un problema de red y un fondo de recursos se divide en dos mitades iguales, debemos asegurarnos de que solo la mitad acceda al almacenamiento compartido y no ambos simultáneamente. XenServer resuelve todos estos problemas al tener dos mecanismos: un latido de almacenamiento y un latido de red.

Cuando habilita HA en un pool, nomina un repositorio de almacenamiento iSCSI, Fibre Channel o NFS para que sea la SR de latido. XenServer crea automáticamente un par de pequeños discos virtuales en este SR. Todos los servidores del fondo de recursos utilizan el primer disco como disco de quórum compartido. Cada servidor se asigna un bloque único en el disco compartido y escribe regularmente en el bloque para indicar que está vivo. Cuando se inicia HA, todos los servidores intercambian datos a través de canales de red y de almacenamiento, indicando qué servidores pueden ver en ambos canales, es decir, qué rutas de E/S funcionan y cuáles no. Esta información se intercambia hasta que se alcanza un punto fijo y todos los servidores del grupo están satisfechos de que están de acuerdo sobre lo que pueden ver. Cuando esto sucede, HA está habilitado y el grupo está protegido. Este proceso de armado de HA puede tardar unos minutos en conformarse con grupos más grandes, pero solo es necesario cuando HA se habilita por primera vez.

Una vez que HA está activo, cada servidor escribe regularmente actualizaciones de almacenamiento en el disco virtual de latido y paquetes de red a través de la interfaz de administración. (Es vital garantizar que los adaptadores de red seanunido/en-us/xencenter/current-release/hosts-nics.html[()]para la resiliencia y que las interfaces de almacenamiento utilicenmultirutas dinámicas[]/en-us/xencenter/current-release/storage-pools-multipathing.htmlen los casos en que se admita.) Esto garantizará que cualquier adaptador único o fallo de cableado no provoque ningún problema de disponibilidad.

Cercado de servidores

El peor escenario para HA es la situación en la que se cree que un servidor está fuera de línea, pero en realidad todavía está escribiendo en el almacenamiento compartido, ya que esto puede resultar en la corrupción de los datos persistentes. Para evitar esta situación, XenServer utiliza vallas de servidor, es decir, el servidor se apaga automáticamente y se aísla del acceso a los recursos compartidos del grupo. Esto evita que el servidor que falla escriba en cualquier disco compartido y dañe la consistencia de los datos almacenados durante la conmutación por error automática, cuando las máquinas virtuales protegidas se mueven a otros servidores en buen estado del grupo.

Los servidores se autocercarán (es decir, se apagarán y se reiniciarán) en caso de fallo de latido, a menos que cualquiera de las siguientes situaciones sea cierto:

  • El latido del almacenamiento está presente para todos los servidores, pero la red se ha particionado (de modo que ahora hay dos grupos de servidores). En este caso, todos los servidores que son miembros de la partición de red más grande permanecen en ejecución y los servidores en la autovalla de partición de red más pequeña. La suposición aquí es que la interrupción de la red ha aislado las VM y deben reiniciarse en un servidor con redes en funcionamiento. Si las particiones de red son exactamente del mismo tamaño, solo una de ellas se autovaldrá de acuerdo con una función de selección estable.
  • Si el latido del almacenamiento desaparece pero el latido de la red permanece, los servidores comprueban si pueden ver todos los demás servidores a través de la red. Si esta condición es cierta, los servidores permanecen en ejecución en el supuesto de que el servidor de latidos de almacenamiento ha desaparecido. Esto no compromete la seguridad de las máquinas virtuales, pero cualquier falla en la red dará lugar a cercas, ya que eso significaría que ambos latidos del corazón han desaparecido.

Planificación de la capacidad para fallas

El sistema heartbeat nos proporciona una notificación fiable de fallos del servidor, por lo que pasamos al segundo paso de HA: planificación de la capacidad para fallas.

Un grupo de recursos consta de varios servidores (por ejemplo, 32), cada uno con cantidades potencialmente diferentes de memoria y un número diferente de máquinas virtuales en ejecución. Con el fin de garantizar que ninguna falla en un solo servidor imposibilita reiniciar sus máquinas virtuales en otro servidor (por ejemplo, debido a la memoria insuficiente en cualquier otro servidor), XenServer HA calcula dinámicamente un plan de fallas que calcula las acciones que se realizarían en cualquier fallo del servidor. Además de tratar los errores de un solo servidor, XenServer HA puede hacer frente a la pérdida de varios servidores en un grupo, por ejemplo, cuando el fallo de una partición de red elimina a un grupo completo de servidores.

Además de calcular las acciones que se tomarán, el plan de errores tiene en cuenta el número de errores de servidor que se pueden tolerar en el grupo. Hay dos consideraciones importantes involucradas en el cálculo del plan de alta disponibilidad para un grupo:

  • Capacidad máxima de fallo. Es el número máximo de servidores que pueden fallar antes de que no haya recursos suficientes para ejecutar todas las máquinas virtuales protegidas en el grupo; XenServer calcula este valor teniendo en cuenta las prioridades de reinicio de las máquinas virtuales del grupo y la configuración del grupo (el número de servidores y su CPU y memoria). capacidad).
  • Límite de errores del servidor. Se trata de un valor que puede definir como parte de la configuración de alta disponibilidad que especifica el número de errores de servidor que desea permitir en el grupo, dentro del plan de alta disponibilidad. Por ejemplo, en un fondo de recursos de 16 servidores, cuando se establece el límite de errores del servidor en 3, XenServer calcula un plan de conmutación por error que permite que los tres servidores puedan fallar y seguir ejecutando todas las máquinas virtuales protegidas del grupo. Puede configurar el límite de errores del servidor a un valor inferior a la capacidad máxima de error, por lo que es menos probable que el grupo se vuelva demasiado comprometido. Esto puede ser útil en un entorno con RBAC habilitado, por ejemplo, para permitir a los usuarios de RBAC sin permisos de operador de grupo poner en línea más máquinas virtuales sin romper el plan de alta disponibilidad; consulteControl de acceso basado en funciones y HA (RBAC)a continuación.

Se generará una alerta del sistema cuando el valor máximo de capacidad de falla caiga por debajo del valor especificado para el límite de fallos del servidor.

Protección de sobrecomisión

Cuando se habilita por primera vez HA en un grupo, se calcula un plan de errores en función de los recursos disponibles en ese momento. XenServer HA calcula dinámicamente un nuevo plan de errores en respuesta a eventos que afectarían al grupo, por ejemplo, al iniciar una nueva máquina virtual. Si no se puede calcular un nuevo plan debido a la insuficiencia de recursos en el grupo (por ejemplo, no hay suficiente memoria libre o cambios en discos virtuales y redes que afectan qué máquinas virtuales se pueden reiniciar en qué servidores), el grupo se vuelve demasiado comprometido.

La prioridad de reinicio de alta disponibilidad se utiliza para determinar qué máquinas virtuales se deben iniciar cuando un grupo está sobrecomprometido. Al configurar la prioridad de reinicio para las máquinas virtuales que desea proteger en el cuadro de diálogo Configuración de alta disponibilidad o en el Asistente para configurar alta disponibilidad , puede ver la capacidad máxima de falla del grupo que se vuelve a calcular dinámicamente, lo que le permite probar varias combinaciones de reinicio de VM según las necesidades de su empresa y vea si la capacidad máxima de fallo es adecuada al nivel de protección que necesita para las máquinas virtuales críticas del grupo.

Si intenta iniciar o reanudar una máquina virtual y esa acción haría que el grupo se comprometiera en exceso, aparecerá una advertencia en XenCenter. El mensaje también se puede enviar a una dirección de correo electrónico, si está configurado. A continuación, se le permitirá cancelar la operación, o continuar de todos modos, haciendo que el grupo se comprometa en exceso.

Trabajar con un grupo habilitado para HA

La práctica recomendada para HA es no realizar cambios de configuración en el grupo mientras HA está habilitado. En su lugar, se pretende que sea la “salvaguardia de las 2am” que reiniciará los servidores en caso de que se produzca un problema cuando no haya un administrador humano cercano. Si está realizando activamente cambios de configuración en el grupo, como la aplicación de actualizaciones de software, HA debe deshabilitarse mientras dure estos cambios.

  • Si intenta apagar una máquina virtual protegida desde XenCenter, XenCenter le ofrecerá la opción de quitar primero la máquina virtual del plan de fallas del grupo y, a continuación, cerrarla. Esto garantiza que las paradas accidentales de VM no provocarán tiempo de inactividad, pero que aún puede detener una VM protegida si realmente lo desea.
  • Si necesita reiniciar un servidor cuando HA está habilitado, XenCenter utiliza automáticamente las prioridades de reinicio de VM para determinar si esto invalidaría el plan de fallas del grupo. Si no afecta al plan, entonces el servidor se apaga normalmente. Si se infringe el plan, pero la capacidad máxima de falla es mayor que 1, XenCenter le dará la opción de reducir el límite de fallos del servidor del grupo en 1. Esto reduce la resiliencia general del grupo, pero siempre garantiza que se tolerará al menos una falla del servidor. Cuando el servidor vuelve a aparecer, el plan se vuelve a calcular automáticamente y el límite de fallos del servidor original se restablece si procede.
  • Al realizar la instalaciónactualizaciones de softwaremediante el Asistente para instalar actualizaciones, debe deshabilitar HA en el grupo haciendo clic en la opción Des activar HAhasta que se haya instalado la actualización. Si no deshabilita HA, la actualización no continuará. Tendrá que supervisar el grupo manualmente mientras se instalan las actualizaciones para asegurarse de que los errores del servidor no interrumpan el funcionamiento del grupo.
  • Cuando se habilita HA, algunas operaciones que podrían comprometer el plan para reiniciar las máquinas virtuales pueden estar deshabilitadas, como quitar un servidor de un grupo. Para realizar estas operaciones, debe deshabilitar temporalmente HA o puede apagar las máquinas virtuales protegidas antes de continuar.

Control de acceso basado en funciones y HA (RBAC)

En entornos XenServer donde se implementa el control de acceso basado en roles (RBAC), no todos los usuarios podrán cambiar la configuración de alta disponibilidad de un grupo. Los usuarios que pueden iniciar máquinas virtuales (operadores de máquinas virtuales), por ejemplo, no tendrán permisos suficientes para ajustar la capacidad de conmutación por error de un grupo habilitado para HA. Por ejemplo, si iniciar una máquina virtual reduce el número máximo de errores de servidor permitidos a un valor inferior a la capacidad máxima de falla actual, el operador de máquina virtual no podrá iniciar la máquina virtual. Sólo los usuarios de nivel Administrador de Pool o Operador de Pool pueden configurar el número de errores de servidor permitidos.

En este caso, el usuario que habilita HA (con una función Administrador de Pool o Operador de Pool) puede establecer el límite de error del servidor a un número que sea realmente inferior al número máximo de errores permitidos. Esto crea capacidad de demora y garantiza que los usuarios con menos privilegios puedan iniciar nuevas máquinas virtuales y reducir la capacidad de failover del grupo sin amenazar el plan de fallas.