Emergencias en Citrix XenServer
Hola amigos, esta semana veremos en nuestra sección de Citrix XenServer como actuar en caso de caída de uno de nuestros hosts físicos y recuperar el estado normal de nuestras máquinas virtuales.
El entorno al que se puede aplicar este procedimiento es un pool clásico de dos o más hosts donde tenemos corriendo nuestras máquinas virtuales sobre un almacenamiento compartido y con un licenciamiento gratuito.
Como todo fallo, antes de actuar hemos de detectar la fuente del problema y el alcance/impacto para poder tomar las medidas necesarias para solucionarlo. Podemos evaluar la situación de un entorno XenServer caído mediante el siguiente esquema, similar al que nos plantea Citrix:
El master del pool está caído
Es la situación más grave, veréis que se pierde totalmente el control del Pool. No se pueden listar ni realizar operaciones sobre las máquinas virtuales, se desconecta el XenCenter… De todos modos, las máquinas virtuales siguen corriendo con normalidad en todos los Hosts, excepto las del servidor/es afectado/s.
El host con el rol de master es el que gestiona la base de datos del pool. En el momento que el master no es accesible, todos los demás hosts pierden el acceso a dicha información y asumen que están corriendo en modo de emergencia.
Desgraciadamente, no siempre cambia a ese modo automáticamente y cuando haces una consulta a la XAPI, se queda esperando si hacer nada, sin dar el error de que se encuentra en estado de emergencia.
“En mi laboratorio de pruebas, no se ha cambiado a modo de emergencia ningún host al dar botonazo al host master”. De todos modos, tanto si el siguiente comando nos devuelve “true” como “false”, procederemos igual.
#xe host-is-in-emergency-mode
Si el Host que teníamos como Master no es posible que vuelva a funcionar de nuevo, por ejemplo por un fallo de hardware, hay que transferir el rol de master a otro miembro del pool. Para ello ejecutamos el siguiente comando en un host que esté funcionando correctamente.
[root@xsrv03]# xe pool-emergency-transition-to-master
Host agent will restart and transition to master in 10 seconds…
Ahora si ejecutamos por ejemplo:
[root@xsrv03]# xe host-list
Ya veremos que la XAPI nos devuelve los hosts del pool. Ya tenemos control sobre el pool. Verificamos que el host que le hemos traspasado el rol de master, lo ha asumido correctamente:
[root@xsrv03]# xe pool-list
uuid ( RO) : f9e97ade-85db-0191-403a-b56b93d364c7
name-label ( RW): PRODXEN
name-description ( RW): .: Production Cluster :.
master ( RO): cede8d8c-c750-4067-a6b9-eb55744e44fc
default-SR ( RW): e6532b42-d048-2ef4-9b6c-688632108e34
[root@xsrv03]# xe host-list uuid=cede8d8c-c750-4067-a6b9-eb55744e44fc
name-label ( RW): xsrv03
Una vez recuperado el control del pool, tenemos que forzar al nuevo master a restablecer las conexiones con el resto de hosts. Este comando nos devolverá el listado de UUIDs de los hosts slaves que contiene el pool.
[root@r xsrv03]# xe pool-recover-slaves
e212ac38-c349-490a-9902-06b9355700cd
Ahora el pool puede volver a trabajar con normalidad, si disponemos de N+1, solamente tendremos que levantar las VMs caídas en del host “master” en los otros hosts disponibles. Si las máquinas virtuales no se dejan volver arrancar porqué según la XAPI están corriendo sobre el host caído, sigue leyendo ;)
A partir de aquí el resto de situaciones de caídas de Host, son menos aparatosas. Si detectamos un host caído y no podemos volver a levantar las máquinas virtuales en otro Host, tenemos el comando:
#xe vm-reset-powerstate vm=<NameLabel de la VM> force=true
Este comando avanzado forzará el estado de apagado la máquina virtual que especifiquemos. Pero ojo, solo ejecútalo si estas 100% seguro que esta máquina virtual no está corriendo en ningún otro host ya que este, libera el bloqueo que establece XenServer a nivel de base de datos, para que no se pueda levantar la VM en cualquier otro host del pool por duplicado. En ese caso, tendríamos corrupción de discos en la máquina virtual. Como es un comando “peligroso” hay que ejecutarlo siempre con el flag force=true o –force
Tenemos también la opción para un host en concreto:
#xe vm-reset-powerstate resident-on=<UUID Host caido> force=true
Hasta aquí por hoy, espero que como siempre, haya podido enseñarte algo útil para administrar tu entorno XenServer.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.