Alta disponibilidad
La alta disponibilidad de XenServer permite que las máquinas virtuales se reinicien automáticamente en caso de una falla de hardware subyacente o la pérdida de cualquier servidor. La alta disponibilidad consiste en garantizar que las VM importantes se ejecuten siempre en un grupo de recursos. Con la alta disponibilidad habilitada, si uno de sus servidores falla, sus máquinas virtuales se reinician en otros servidores del mismo grupo. Esta capacidad permite que los servicios esenciales se restauren con una interrupción mínima del servicio en caso de fallo del sistema o del componente.
Si el servidor coordinador de grupos falla, la alta disponibilidad de XenServer selecciona un nuevo servidor para que asuma las funciones de coordinador de grupos. Cualquier servidor de un grupo puede ser un servidor coordinador de grupos. XenServer replica la base de datos del grupo de forma constante en todos los nodos. También realiza copias de seguridad de la base de datos en el almacenamiento compartido en el latido SR para mayor seguridad.
La alta disponibilidad de XenServer tiene dos aspectos clave:
- Detección fiable de fallos en el servidor
- Calcular un plan de fallas para permitir una recuperación rápida
Heartbeats para la disponibilidad
Detectar fallas de servidores de manera fiable es difícil, ya que necesita distinguir de forma remota entre un servidor que desaparece durante un tiempo y una falla catastrófica. Si la alta disponibilidad decide incorrectamente que un servidor de coordinador de grupos se ha averiado y elige un nuevo coordinador de grupos, puede haber resultados impredecibles si el servidor original regresa. Del mismo modo, si un problema de red hace que el grupo se divida en dos mitades iguales, debemos asegurarnos de que solo la mitad acceda al almacenamiento compartido y no ambas simultáneamente. XenServer resuelve todos estos problemas al disponer de dos mecanismos: un latido de almacenamiento y un latido de red.
Cuando habilita la alta disponibilidad en un grupo, designa un repositorio de almacenamiento iSCSI, Fibre Channel o NFS para que sea el SR latido. XenServer crea automáticamente un par de discos virtuales pequeños en este SR. El primer disco lo utilizan todos los servidores del grupo de recursos como un 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á activo. Cuando se inicia la alta disponibilidad, todos los servidores intercambian datos tanto a través de los canales de red como de almacenamiento. Esta acción indica qué servidores pueden ver en ambos canales y demuestra qué paths 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 coinciden en lo que pueden ver. Cuando se produce este acuerdo, se habilita la alta disponibilidad y se protege el grupo. Este proceso de armado de alta disponibilidad puede tardar unos minutos en conformarse con grupos más grandes, pero solo es necesario cuando se habilita la alta disponibilidad por primera vez.
Una vez que la alta disponibilidad está activa, cada servidor escribe actualizaciones de almacenamiento con regularidad en el disco virtual de latido y en los paquetes de red a través de la interfaz de administración. Asegúrese de que los adaptadores de red estén unidos para ofrecer resiliencia y de que las interfaces de almacenamiento utilicen rutas múltiples dinámicas donde sea compatible. Esta configuración garantiza que cualquier falla en el cableado o el adaptador individual no provoque problemas de disponibilidad.
Para obtener más información, consulte:
Cercado de servidores
El peor de los casos de alta disponibilidad es aquel en el que se piensa que un servidor está fuera de línea pero sigue escribiendo en el almacenamiento compartido. Este caso puede provocar la corrupción de los datos persistentes. XenServer utiliza una barrera de servidores para evitar esta situación. El servidor se apaga automáticamente y se aísla del acceso a los recursos compartidos del grupo. La delimitación evita que el servidor que falla escriba en discos compartidos. Este comportamiento evita que se dañen los datos almacenados durante una conmutación por error automatizada, cuando las máquinas virtuales protegidas se mueven a otros servidores del grupo.
Los servidores se autolimitan (es decir, se apagan y se reinician) en caso de fallo del latido, a menos que se mantenga alguna de las siguientes condiciones:
- 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 funcionamiento y los servidores de la partición de red más pequeña se autodelimitan. En este caso, se supone que la interrupción de la red ha aislado las máquinas virtuales y deben reiniciarse en un servidor con redes en funcionamiento. Si las particiones de red son del mismo tamaño, solo una de ellas se autocierra 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 de la red. Si se cumple esta condición, los servidores siguen ejecutándose en el supuesto de que el servidor de latido de almacenamiento ha desaparecido. Esta acción no compromete la seguridad de la máquina virtual, pero cualquier fallo de la red provoca un cercado, ya que eso significaría que ambos latidos del corazón han desaparecido.
Planificación de capacidad en caso de fallo
El sistema de latidos nos proporciona una notificación fiable de la falla del servidor, por lo que pasamos al segundo paso de la alta disponibilidad: la planificación de la capacidad para fallas.
Un grupo de recursos se compone de varios servidores (por ejemplo, 32), cada uno con cantidades de memoria potencialmente diferentes y un número diferente de VM en ejecución. La alta disponibilidad de XenServer calcula de forma dinámica un plan de fallos que calcula las medidas que se deben tomar en caso de fallo del servidor. Este plan de errores garantiza que ningún fallo de un solo servidor impida reiniciar sus máquinas virtuales en otro servidor (por ejemplo, debido a la falta de memoria en otros servidores). Además de hacer frente a los fallos de un único servidor, la alta disponibilidad de XenServer puede hacer frente a la pérdida de varios servidores de un grupo. Por ejemplo, la alta disponibilidad puede controlar cuando el fallo de una partición de red elimina un grupo completo de servidores.
Además de calcular qué acciones se toman, el plan de fallas considera la cantidad de fallas del servidor que se pueden tolerar en el grupo. Hay dos consideraciones importantes relacionadas con el cálculo del plan de alta disponibilidad para un grupo:
-
Capacidad máxima de fallos. Este valor es la cantidad máxima de servidores que pueden fallar antes de que no haya recursos suficientes para ejecutar todas las VM protegidas del grupo. Para calcular la capacidad máxima de error, XenServer considera lo siguiente:
- Las prioridades de reinicio de las máquinas virtuales del grupo
- La cantidad de servidores en el grupo
- La capacidad de memoria y CPU del servidor
-
Límite de errores del servidor. Puede definir este valor como parte de la configuración de alta disponibilidad, que especifica el número de errores del servidor que se deben permitir en el grupo, dentro del plan. Por ejemplo, cuando el límite de errores de un servidor para un grupo es de 3, XenServer calcula un plan de conmutación por error que permite que 3 servidores fallen y todas las máquinas virtuales protegidas puedan seguir ejecutándose en el grupo. Puede configurar el límite de errores del servidor a un valor inferior a la capacidad máxima de errores, lo que reduce las probabilidades de que el grupo se comprometa en exceso. Esta configuración puede resultar útil en un entorno con RBAC habilitado. Por ejemplo, esta configuración permite a los usuarios de RBAC con permisos más bajos que el operador de grupo poner más máquinas virtuales en línea sin romper el plan de alta disponibilidad. Para obtener más información, consulte la sección Alta disponibilidad y control de acceso basado en roles (RBAC).
Se genera una alerta del sistema cuando el valor máximo de capacidad de fallos cae por debajo del valor especificado para el límite de fallos del servidor.
Protección de sobrecompromiso
Cuando la alta disponibilidad se habilita por primera vez en un grupo, se calcula un plan de fallas en función de los recursos disponibles en ese momento. La alta disponibilidad de XenServer calcula dinámicamente un nuevo plan de fallas en respuesta a eventos que podrían afectar 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 todo el grupo, el grupo se compromete en exceso. Los ejemplos de recursos insuficientes pueden ser la falta de suficiente memoria libre o los cambios en los discos virtuales y las redes que afectan a las máquinas virtuales que se pueden reiniciar en qué servidores.
La prioridad de reinicio de alta disponibilidad se usa para determinar qué VM se iniciarán cuando un grupo esté sobrecomprometido. Cuando configura la prioridad de reinicio para las máquinas virtuales que quiere proteger en el cuadro de diálogo Configuración de HA o en el asistente Configurar HA, la capacidad máxima de errores del grupo se recalcula dinámicamente. Esta información le permite probar varias combinaciones de prioridades de reinicio de VM en función de las necesidades de su empresa. Puede ver si la capacidad máxima de fallas es adecuada para el nivel de protección que necesita para las máquinas virtuales críticas del grupo.
Si intenta iniciar o reanudar una VM y esa acción provocaría que el grupo se comprometa en exceso, se muestra una advertencia en XenCenter. El mensaje también se puede enviar a una dirección de correo electrónico, si está configurada. Se le da la opción de cancelar la operación o continuar de todos modos, lo que hace que el grupo se comprometa en exceso.
Trabajar con un grupo habilitado para HA
La mejor práctica para la alta disponibilidad es no realizar cambios de configuración en el grupo mientras la alta disponibilidad está habilitada. En cambio, se pretende que sea la “protección de las 2 de la mañana” que reinicia los servidores en caso de que surja un problema cuando no hay un administrador humano cerca. Si realiza activamente cambios de configuración en el grupo, como la aplicación de actualizaciones de software, inhabilite la alta disponibilidad durante estos cambios.
- Si intenta cerrar una máquina virtual protegida de XenCenter, XenCenter ofrece la opción de eliminar la máquina virtual del plan de errores y, a continuación, apagarla. Esta opción garantiza que los apagados accidentales de VM no provoquen tiempo de inactividad, pero que aún pueda detener una VM protegida si realmente lo quiere.
- Si debe reiniciar un servidor cuando la alta disponibilidad está habilitada, XenCenter usa automáticamente las prioridades de reinicio de VM para determinar si este reinicio invalida el plan de error del grupo. Si no afecta al plan, el servidor se cierra normalmente. Si se infringe el plan, pero la capacidad máxima de fallas es mayor que 1, XenCenter ofrece la opción de reducir el límite de fallas del servidor del grupo en 1. Esta acción reduce la resistencia general del grupo, pero siempre garantiza que se tolere al menos una falla del servidor. Cuando el servidor vuelve a funcionar, el plan se vuelve a calcular automáticamente y el límite de fallas del servidor original se restaura si corresponde.
- Al instalar actualizaciones de software mediante el asistente de instalación de actualizaciones, debe deshabilitar la alta disponibilidad en el grupo seleccionando Desactivar HA. Puede volver a habilitar la alta disponibilidad después de instalar la actualización. Si no inhabilita la alta disponibilidad, la actualización no continúa. Supervise el grupo manualmente mientras se instalan las actualizaciones para garantizar que los errores del servidor no interrumpan el funcionamiento del grupo.
- Cuando se habilita la alta disponibilidad, es posible que algunas operaciones que pueden comprometer el plan de reinicio de las máquinas virtuales estén inhabilitadas, como quitar un servidor de un grupo. Para realizar estas operaciones, inhabilite temporalmente la alta disponibilidad o puede apagar las máquinas virtuales protegidas antes de continuar.
Control de acceso basado en roles y alta disponibilidad (RBAC)
En los entornos de XenServer en los que se implementa el control de acceso basado en roles (RBAC), no todos los usuarios pueden cambiar los parámetros de configuración de alta disponibilidad de un grupo. Por ejemplo, los operadores de VM no tienen permisos suficientes para ajustar la capacidad de conmutación por error para un grupo habilitado para AD. Si iniciar una VM reduce la cantidad máxima de fallas de servidor permitidas a un valor inferior al valor actual, un operador de VM no puede iniciar la VM. Solo los usuarios de nivel Administrador de grupo u Operador de grupo pueden configurar el número de errores de servidor permitidos.
En este caso, el administrador del grupo o el operador del grupo pueden establecer el límite de errores del servidor en un número inferior al número máximo de errores permitidos. Esta configuración crea capacidad de inactividad y, por lo tanto, garantiza que los usuarios con menos privilegios puedan iniciar nuevas VM. Reduce la capacidad de conmutación por error del grupo sin poner en peligro el plan de fallas.