Ya son muchos años montando entornos de virtualización con diferentes tecnologías, y os puedo asegurar que con el paso del tiempo van surgiendo problemas que en muchos casos no tienen sentido lógico, o al menos parece que no lo tienen, hasta que realmente descubres el porque del problema.
Me voy a remitir a un problema surgido recientemente en una instalación de HA con XenServer, la cual llevaba unos 3 años en funcionamiento con XenServer 6.2 , sin ningún tipo de problema, pero tras la actualización de la misma a XenServer 6.5 e implementación de nuevos servidores comenzó a mostrar el problema que podeis leer en el titulo de este articulo.
El problema era ni mas ni menos que, tras activar la HA y después de unas horas de correcto funcionamiento, el servidor secundario ( Slave ) se reiniciaba de forma automática, y las maquinas virtuales que corrían sobre el sufrían un reinicio forzado, para después arrancar de nuevo en el servidor maestro.
Dado que, aunque los servidores eran del mismo modelo y características, uno de ellos contaba con una versión muy antigua de Bios, se procedió a realizar la actualización de la misma pensando, en principio que este podría ser el problema, pero tras la actualización de Bios y reinstalación del XenServer en este servidor, el problema continuaba produciendose… había que seguir investigando…
Después de la revisión exhaustiva de los logs del servidor, encontramos el siguiente problema, el cual se podía ver en el log del archivo xha:
21:34:05 BST 2016 [debug] FH: I have lost.
21:34:05 BST 2016 [err] Survival rule failed (1905) FH: Survival Rule is not met for the local host. – Self-Fence.
21:34:05 BST 2016 [info] watchdog_selffence.
Este error coincidía en el tiempo con el reinicio involuntario del servidor… obviamente ahí estaba el problema, pero por que se producía? y lo mas importante, como solucionarlo?
Pues bien, la explicación sencilla y fácil de comprender para este problema es la siguiente:
En algún momento se produce un problema de conectividad o un time-out en el servidor, y este pierde el conocimiento del estado de las maquinas virtuales, digamos que pierde el acceso al archivo de heartbeat, por lo que no es capaz de saber si las maquinas virtuales se están ejecutando a la vez en mas de un servidor. Como mecanismo de seguridad, XenServer reinicia el servidor de forma automática y las maquinas que corren sobre el, para asegurarse de que no esta ocurriendo esto.
Cuando el servidor se reinicia se une al pool de nuevo y continua funcionando correctamente, hasta que vuelve a ocurrir el error.
Ahora bien, como lo solucionamos…
Pues bien, la solución es a priori muy sencilla, ya que lo único que debemos hacer es aumentar el timeout de HA, para evitar que se produzca el fallo.
Después de detener el HA en nuestro pool usamos el siguiente comando:
xe pool-ha-enable heartbeat-sr-uuids=xxxxxxxxx ha-config:timeout=xx
Debeis tener en cuenta que el timeout por defecto es de 30 (segundos), por lo que debemos aumentarlo lo suficiente para que no se produzca el error, pero solo lo necesario, ya que este timeout marca el tiempo que las maquinas tardaran en migrar de un servidor a otro en caso de producirse una caída del mismo.
Después de solventar el problema, por supuesto, debemos averiguar el porque de este fallo en nuestro entorno… En mi caso particular este timeout se producía por un fallo en el switch de almacenamiento, el cual, aunque aparente funcionaba con normalidad, estaba saturando las conexiones por un fallo de hardware del mismo, y no estaba relacionado con la actualización del entorno a la versión 6.5 , pero casualmente empezó a ocurrir justo después de la misma, lo cual te desvía del problema en principio…
Espero que, con esta entrada pueda ayudar a muchos que como yo, tienen este fallo y están volviendose locos para dar con el problema, el cual a mi personalmente me volvió loco durante varios días, ya que se trataba de un entorno en producción y era necesario e imprescindible solucionarlo cuanto antes…
Saludos y hasta la próxima…
