http://blogs.technet.com/davidcervigon/archive/2009/11/12/consideraci-n-importante-para-clusteres-de-windows-server-2008.aspx
--------------------------------------------------------------------------
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:
•Event ID: 1146 - The cluster resource host subsystem (RHS) stopped unexpectedly. An attempt will be made to restart it. This is usually due to a problem in a resource DLL. Please determine which resource DLL is causing the issue and report the problem to the resource vendor
•Cluster.log: Múltiples ocurrencias de ERROR_RESOURCE_CALL_TIMED_OUT(5910)
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:
•cluster res /prop |findstr SeparateMonitor
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
•Aplicar el fix mencionado en http://support.microsoft.com/default.aspx?scid=kb;EN-US;967224, para asegurarnos de que los cambios que hagamos en el paso siguiente tengan el resultado esperado.
•Ejecutar:
◦Netsh int tcp set global RSS=Disabled
◦Netsh int tcp set global chimney=Disabled
◦Netsh int tcp set global autotuninglevel=Disabled
◦Netsh int tcp set global congestionprovider=None
◦Netsh int tcp set global ecncapability=Disabled
◦Netsh int ip set global taskoffload=disabled
◦Netsh int tcp set global timestamps=Disabled
•Adicionalmente, y dado que no vamos a usar esas opciones a nivel de sistema operativo, pueden deshabilitarse también a nivel de opciones avanzadas del driver de la tarjeta de red:
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.
No hay comentarios:
Publicar un comentario