XenServer: High Availability – Alta disponibilidad

En esta lección se introducirán los conceptos fundamentales de XenServer High Availability (Alta Disponibilidad). Se describirá su configuración y algunos aspectos a tener en cuenta en su administración.

MA icono manual(ACCEDE AQUÍ AL INDICE DEL MANUAL DE CITRIX XENSERVER)

CONTENIDO DE LA LECCION

  • Caso práctico
  • ¿Qué es XenServer High Avalilability?
  • Conceptos de XenServer High Availability
  • Configuración y gestión de High Availability desde XenCenter
  • Configuración de High Availability con el comando xe
  • Operaciones afectadas por HA

Caso práctico

   En nuestra empresa ficticia “L023 Formación” no se quiere interrumpir ningún curso en el caso de que falle alguno de los servidores XenServer. Para ello se habilitará High Availability  en el resource pool XenServer ya existente, formado por tres hosts, configurándola para prevenir el fallo de uno de ellos.

xenserver high availability

 

¿Qué es XenServer High Availability?

   High Availability en XenServer sirve para asegurar que las máquinas virtuales más importantes de un resource pool estén siempre disponibles. Para esto, claro está, dicho resource pool debe proveer los suficientes recursos hardware.

   ¿Cuando puede verse comprometida la disponibilidad de una máquina virtual? Aquí debemos tener en cuenta varias posibilidades:

  • Fallo de software en la propia máquina virtual.
  • Fallo en el sistema de almacenamiento donde se encuentran ubicadas las máquinas virtuales.
  • Fallo hardware en un host XenServer y este detiene su funcionamiento.
  • Fallo en la conectividad de la red de un host XenServer.

   En las dos últimas podemos esperar que High Availability (HA a partir de ahora) solucione la situación. HA reiniciará las máquinas virtuales de un host caído o que ha perdido la conectividad en otro host miembro del pool protegido, si existen recursos suficientes para mantener un nivel óptimo de rendimiento de todas las máquinas virtuales y si la configuración de HA lo permite. Además, HA previene que una máquina pueda estar en ejecución en dos hosts distintos, lo que podría provocar una corrupción de los discos virtuales VDI asociados a ella. Por ello, si lo que ocurre es un corte en la red del host que ejecuta las máquinas virtuales, este mismo realizará un reinicio para apagar las que puedan estar en ejecución. Posteriormente, XenServer iniciará dichas máquinas en otro host del pool.

   Otro punto muy importante es que HA promueve automáticamente a master del resource pool a otro host si el master original cae. De esta manera se asegura una conexión administrativa con el resource pool y la continuidad en su funcionamiento.

NOTA: Citrix recomienda el uso de High Availability junto con almacenamiento en multipath (no tratado en esta versión del manual) y bonds de los interfaces de red.

   En el siguiente vídeo se observa un ejemplo completo: se parte de una situación en la que hemos habilitado HA en nuestro pool. El pool está compuesto por los servidores l023xse01, l023xse02 y l023xse03. Se produce un fallo del pool master l023xse01 que provoca su apagado. A continuación, automáticamente HA promueve a pool master el servidor l023xse02 y las máquinas virtuales que estaban en ejecución en el host que falla se iniciarán en el resto de servidores.

 

Conceptos de XenServer High Availability

   HA plan (plan de alta disponibilidad): en base a nuestras necesidades de continuidad del servicio, configuraremos el modo en el que deben comportarse nuestras máquinas virtuales ante el fallo de un host XenServer miembro de un pool. Esto lo haremos especificando para cada máquina virtual si debe reiniciase forzosamente, o sólo si es posible, en qué orden deben reiniciarse…. En base a estos valores, en entorno de XenServer calculará un plan de respuesta a una situación de fallo, dando como resultado el límite en el número de hosts del pool que pueden fallar de manera que puedan cumplir nuestras necesidades. Esto lo veremos en un ejemplo práctico más abajo.

   Storage Heartbeat y Network Heartbeat: son los mecanismos que utiliza XenServer para chequear el estado de los hosts del resource pool. El storage heartbeat es un pequeño fichero VDI en el que los hosts con HA habilitada escriben periódicamente. Network heartbeat realiza sirve para que los hosts se chequeen mutuamente a través de la red.

   Overcomitting: un pool con HA configurada entra en estado overcomitted cuando se ha alcanzado el número máximo de hosts que pueden fallar. A partir de ese momento no se puede asegurar que el resource pool esté protegido por HA.

   Host Fencing: si un host detecta que esta aislado del resto de hosts del pool, él mismo se reinicia parando todas las máquinas que tuviera en ejecución. Estas máquinas serán iniciadas en otro host automáticamente (si no se entra en conflicto con el HA plan). Así, cuando el host aislado vuelva a estar en línea, no se tendrán las mismas máquinas virtuales iniciadas en más de un host.

   Start Order: propiedad a configurar en XenCenter en una máquina virtual para protegerla por HA.  Establece una prioridad para el orden en el que se deben reiniciar automáticamente por HA. Los valores posibles son números enteros comenzando por 0: 0, 1, 2, 3… Las que tengan valor 0 se reiniciarán las primeras, las de valor 1 después, y así sucesivamente

   HA restart priority: propiedad a configurar en XenCenter en una máquina virtual para protegerla con HA. Sus posibles valores son “Restart” (reiniciar la máquina virtual siempre), “Restart if possible” (reiniciar la máquina virtual si no se entra en conflicto con el HA plan) y “Do not restart” (no reiniciar la máquina virtual).

 

Configuración y gestión de High Availability desde XenCenter

   Existen una serie de prerrequisitos para implementar HA en un entorno XenServer. Para los hosts y para las máquinas virtuales.

   Para los hosts XenServer estos prerrequisitos son:

  • Una dirección IP estática para cada host.
  • Un pool de hosts XenServer.
  • Un shared storage configurado en el resource pool con 4 MB de espacio libre para el HeartBeat y 256MB para metadata. Citrix recomienda tener un storage repository dedicado para esto.

   Para las máquinas virtuales el prerrequisito es que sean “ágiles”. Esto significa que:

  • Debe estar en un shared storage.
  • No debe tener configurada una conexión a un DVD local
  • Sus vif deben estar en una red wide-pool. Es decir, conectadas a un objeto network común a todos los hosts del pool.

   Además, se recomienda que el número de hosts XenServer mínimos que deben componer el pool en el que se va a habilitar HA sea de 3.

   Como en nuestro caso práctico se cumplen todos los requisitos, vamos a proceder a configurar HA en nuestro entorno. Se asignarán las propiedades de “Restart” a todas las máquinas virtuales y se asignarán los valores de 0 a 3 a las máquinas de cada aula consecutivamente.

   XenServer establece su HA plan, en lo que respecta a la memoria, en base al valor del máximo de memoria estática (memory-static-max). Calculando de manera sencilla, se establecerá el valor de memory-static-max en 1792 MB en cada máquina virtual. Como 1792*4 = 7168 MB, esto nos permitirá tener en ejecución en cada host cuatro máquinas virtuales (ver la Lección 12: Gestión de memoria de este manual).

   Para configurar HA desde XenCenter, seleccionamos el resource pool y en el panel derecho , en la pestaña “HA” hacemos clic en el botón “Configure HA…”. Con esto abrimos el asistente “Configure HA”. Seguimos con las diferentes ventanas del asistente:

1.- Ventana “HA configuration prerequisites”: se muestran los requisitos que debe cumplir el entorno XenServer para poder configurar y activar con éxito HA.

   Clic en “Next”.

2.- Ventana “Choose a heartbeat SR”: en ella se debe seleccionar el storage repository que será utilizado para “heartbeat”. Aparecen los storage repositories pertenecientes al resource pool. En la columna “comment” aparece una indicación para los storage repositories que no pueden utilizarse.

   En nuestro caso, seleccionamos L023nas01_iscsi01. En este están ubicadas las máquinas virtuales (aunque Citrix recomienda utilizar un storage repository dedicado al heartbeat).

Clic en “Next”.

3.- Ventana “Configure the HA restart priority, restart order and delay interval for the VMs in this pool”: aquí es donde se configura el plan de HA. En nuestro caso, los parámetros que establecemos en las máquinas virtuales son:

  • “Restart priority”: “Restart”.
  • “Start order”: en cada aula se configuran valores consecutivos para reinicio de 0, 1, 2 y 3.
  • “Delay interval”: 30 (segundos).

 

 

   Por otra parte, en esta ventana también se nos informa de que las máquinas virtuales son “ágiles” (columna “Agile”), y se nos propone, en base a los valores configurados para cada máquina virtual que el número máximo de fallos de hosts permitidos (Failures allowed””) dea de 1.

   En la parte superior de la ventana, se nos confirma que este plan es válido y que la alta disponibilidad esta garantizada (“HA is guaranteed. The maximum number of server failures that HA can protect against is 1”).

   Clic en “Next”.

4.- Ventana “Review configuration and activate HA”: resumen de las opciones de configuración de HA. Si es correcto, se hace clic en “Finish”.

    Tras confirmar la configuración propuesta, comienza el proceso de activación de HA en el resource pool. Una vez terminada, podemos volver en XenCenter a la pestaña “HA” del pool el estado actual de la alta disponibilidad en nuestro pool.

 

   Se puede observar en esta ventana que HA está activada (“Pool HA enabled”), que el número fallos de hosts XenServer configurado (“Configured failure capacity”) es de 1, que es la capacidad actual de respuesta ante fallos de host (“Current failure capacity”), y que el estado de latido tanto de red como de almacenamiento de los tres servidores del pool es correcto (“Heartbeating status”).

NOTA: si es necesario deshabilitar HA, al volver a habilitarla se mantienen los valores de su configuración.

Configuración de High Availability con el comando xe

   Para configurar y habilitar HA haciendo uso del comando xe se deben seguir los siguientes pasos:

1.- Establecer la propiedad de reinicio de cada máquina virtual que se desee proteger con el comando xe vm-param-set uuid=<vm_uuid> ha-restart-priority=<num> ha-always-run=true.

2.- Habilitar HA en el resource pool con xe pool-ha-enable heartbeat-sr-uuids=<sr_uuid>. En “heartbeat-sr-uuids” debemos escribir el uuid del storage repository que utilizaremos como heartbeat sr.

3.- Establecer el valor del número de fallos de host permitidos. Al configurar HA con XenCenter, este valor era calculado automáticamente en el campo “Failures allowed (max)” del asistente. Al hacer la configuración con el comando xe, este cálculo se le debe solicitar manualmente el pool con xe pool-ha-compute-max-host-failures-to-tolerate. El resultado lo debemos utilizar como parámetro en xe pool-param-set ha-host-failures-to-tolerate=<num> uuid=<pool-uuid>.

   Si es necesario deshabilitar HA, simplemente se debe ejecutar xe pool-ha-disable.

Operaciones afectadas por HA

   En un resource pool de XenServer con HA configurada, hay ciertas operaciones que pueden no ser bien entendidas por HA y hay otras que pueden entrar en conflicto con el HA plan. Vamos a reseñar algunas de ellas.

   La acción de apagar un host XenServer puede ocasionar que HA deje de ser operativa. Si la acción se está realizando desde XenCenter (dependiendo de los recursos del pool y de la configuración de HA) podría aparecer un mensaje advirtiendo de que HA ya no estará garantizada.

  Las máquinas virtuales que estuvieran en ejecución en el servidor se apagarán y no serán reiniciadas automáticamente.

   El resultado de apagar una máquina virtual si está protegida por HA será distinto dependiendo de si el pagado se realiza desde el sistema operativo de la máquina virtual o desde XenCenter. En el primer caso, HA reiniciará la máquina  virtual (si así está establecido en su configuración de HA) pues entenderá que el apagado ha sido debido a un fallo. Si por el contrario se realiza el apagado de la misma máquina virtual desde XenCenter se mostrará un mensaje advirtiendo de que la máquina virtual está protegida por HA.

   Si la apagamos, no será reiniciada automáticamente.

   La última de las operaciones que veremos afectadas por HA en XenServer es la de designación de un nuevo pool master. Esta acción se puede llevar a cabo desde la consola de alguno de los servidores del pool. No será posible llevarla a cabo mientras no se deshabilite HA.

MA icono siguiente Siguiente: Lección 14 – XenServer: Instalación de actualizaciones en resource pools