Las opiniones reflejadas en este Blog son personales. La información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
Hola
Se están dando algunos casos de clústeres de Windows Server 2008 en los que los procesos RSH (Resource Monitor Host) se caen o entran en estados de “deadlock”, lo que en los casos más graves puede acabar produciendo fallos en los recursos existentes en cada uno de los grupos. En otras circunstancias los procesos se reinician y el problema puede llegar a pasar desapercibido.
En el par de casos que me ha tocado vivir, los afectados principales han sido los recursos de disco y el propio nombre del cluster. Esto produce la caída de cualquier cosa que dependa de esos discos, con el agravante de que al no estar disponible el network name el uso de la consola de gestión se hace complicada, sobre todo en remoto. Y a mayor número de nodos, mayor probabilidad de encontrarnos el problema, y mayor complicación a la hora de resolverlo.
Una vez experimentados estos síntomas, cuando nos ponemos a rascar, nos encontramos este tipo de información en el visor de sucesos y en el log del cluster:
En los casos en los que el sistema es capaz de recuperarse solo, hay otra manera de detectar el problema, también bastante sutil. Cuando falla el monitor de un recurso, el sistema lo marca para que se ejecute en un proceso diferente, lo que dispara el numero de procesos RSH.exe que podemos ver en el task manager. Si ejecutamos este comando, podemos ver en que recursos tenemos esa casilla marcada (SeparateMonitor = 0x1), y si no lo hemos hecho a propósito puede que haya estada afectada por el problema:
La solución
Paradójicamente, la solución al problema está oculta detrás de un paquete de recomendaciones que se viene aplicando a problemas de lentitud de red en Windows Vista y en Windows Server 2008, curiosamente debido a las optimizaciones de red incluidas en estos sistemas operativos (TCP Offload, Receive-side scaling (RSS), TCP Window Scaling Auto Tunning, etc.).
Así es que para prevenir/resolver este problema hay que seguir estos pasos en todos los nodos del cluster
Una vez aplicados los cambios en todos los nodos, los reiniciamos ordenadamente para que estos apliquen, y comprobamos que todos los servicios que corran encima lo estén haciendo correctamente. Es posible que queramos volver a poner los valores “SeparateMonitor” a cero, como era el defecto. Lo podemos hacer con el comando cluster.exe, o bien por la interfaz gráfica (última casilla de la imagen , marcada es 1 y desmarcada es 0):
Espero que esto os pueda ahorrar algún disgusto, acompañado de unas cuantas horas de agobio en clústeres que estén corriendo algún tipo de servicio crítico en vuestra organización.
AGRADECIMIENTOS ESPECIALES:
Saludos
David Cervigón