layout: doc—
Nota:
Aún no se admite el uso de XenCenter aaaa.x.x con Citrix Hypervisor 8.2 CU1 en entornos de producción. Para administrar el entorno de producción de Citrix Hypervisor 8.2 CU1, use XenCenter 8.2.7. Para obtener más información, consulte la documentación de XenCenter 8.2.7.
Puede instalar XenCenter 8.2.7 y XenCenter aaaa.x.x en el mismo sistema. La instalación de XenCenter aaaa.x.x no sobrescribe la instalación de XenCenter 8.2.7.
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:
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:
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 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:
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.
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.
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.
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.