GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Mantenimiento de Nodos: ¿NLB STOP ó NLB DRAINSTOP?

Volver a: [Instalar y Configurar Microsoft Cluster NLB (Network Load Balancing) en Windows Server 2003]


Al trabajar con un Cluster NLB, habitualmente es necesario realizar tareas de mantenimiento en alguno o todos los Nodos del Cluster NLB. Por ejemplo, ciertos cambios de configuración realizados sobre IIS requieren que se ejecute el comando IISRESET (ej: iisreset /noforce) para finalizar de aplicar dicho cambio, produciéndose un corte en el servicio IIS. Teniendo en cuenta que el Cluster NLB no monitoriza el estado de las aplicaciones que balancea, será necesario utilizar los comandos NLB STOP ó NLB DRAINSTOP para aplicar el cambio correctamente, y evitar que el NLB envíe peticiones al Nodo que tiene el servicio caído. ¿Qué diferencia existe entre NLB STOP y NLB DRAINSTOP?

La problemática está muy clara. Si por ejemplo paramos el servicio IIS en un Nodo de un Cluster NLB de servidores Web, el propio NLB no será consciente de que el IIS está parado en dicho Nodo, y en consecuencia, seguirá enviando a dicho Nodo las peticiones que le correspondan, lo cual, teniendo en cuenta que el servicio está temporalmente caído en dicho Nodo, finalizarán mostrando al usuario final algún tipo de error. Lo que nos debe quedar claro, es que NLB se limita a repartir las peticiones, sin comprobar si los servicios están levantados, colgados, etc., NLB sólo y exclusivamente se limita a repartir peticiones entrantes.

Por ello, al realizar una tarea de mantenimiento sobre un Nodo, será necesario indicarle al NLB que dicho Nodo no debe utilizarse para despachar peticiones entrantes (evitando así que los usuarios reciban errores al conectar con el Nodo caído), algo que podemos realizar con los comandos NLB STOP o NLB DRAINSTOP. Una vez ha sido ejecutado el correspondiente comando NLB STOP o NLB DRAINSTOP, podremos realizar la correspondiente tarea de mantenimiento (ej: ejecutar un IIS RESET, realizar un cambio en la aplicación de producción, reiniciar el Nodo, etc.), y una vez finaliza la misma, podremos recuperar el servicio en dicho Nodo del Cluster ejecutando el comando NLB START (en caso de tener que realizar la operación en múltiples Nodo, pues lo repetimos en cada Nodo, y aquí paz y después gloria ;-).

Diferencia entre NLB STOP y NLB DRAINSTOP

La primera duda en resolver es ¿Qué diferencia existe entre NLB STOP y NLB DRAINSTOP? Imaginemos un Cluster NLB formado por un Nodo A y un Nodo B (por ponerles nombres).

Pues bien, la ejecución del comando NLB STOP en el Nodo A del Cluster NLB implica que dicho Nodo dejará de recibir peticiones de inmediato, de tal modo, que a partir de dicho momento todas las peticiones dirigidas al Cluster NLB serán atendidas por el Nodo B (sólo y exclusivamente). Por culturilla, si tenemos una Aplicación Web en NLB configurada para requerir autenticación básica, al realizar el NLB STOP sobre un Nodo A, los usuarios que estuviesen accediendo y autenticados sobre dicho Nodo A empezarán a acceder al Nodo B. Es importante tener en cuenta que con el cambio de Nodo no se volverá a pedir las credenciales al usuario (al menos en este caso, que es el que he probado, aunque tengo la impresión que es Internet Explorer el que cachea las credenciales y se las entrega al Nodo B, sin preguntarnos). Otro problema es la sesión de la Aplicación Web. Si existe algún mecanismo de almacenamiento compartido de la Sesión de la Aplicación Web (ej: en una base de datos SQL Server), el balanceo desde el Nodo A hasta el Nodo B no implicará ningún problema. Sin embargo, en caso de no existir un almacenamiento compartido de la Sesión en la Aplicación Web, al cambiar de Nodo se perderá la Sesión, lo cual podría implicar algún tipo de error para el usuario (podría... esto depende de cada Aplicación Web, como esté desarrollada, para que se utilice la Sesión en la Aplicación Web, etc.)

Sin embargo, el comportamiento de NLB DRAINSTOP es diferente. Si ejecutásemos el comando NLB DRAINSTOP sobre el Nodo A del Cluster NLB, dicho Nodo dejará de procesar nuevas peticiones entrantes, pero seguiría procesando las peticiones entrantes ya existentes en el momento de la ejecución del comando NLB DRAINSTOP.

Hasta aquí, parece más recomendable utilizar NLB DRAINSTOP. Sin embargo, esto depende, pues parece no ser así.

Supongamos que tenemos un Cluster NLB para balancear un IIS, y desde un navegador en un Cliente A se accede al Cluster NLB, siendo la petición procesada por el Nodo A del Cluster NLB. Seguidamente, sin que exista más actividad, ejecutamos el comando NLB DRAINSTOP en el Nodo A. ¿Qué ocurrirá? Así a priori, se podría pensar que se pararía el NLB en el Nodo A ¿Verdad? Pues va a ser que no. En la práctica, tras ejecutar el comando NLB DRAINSTOP sobre el Nodo A, dicho Nodo se quedará en estado Draining, como se muestra en la siguiente pantalla capturada (véase el nodo VIIS02MOB).

En este caso, y teniendo en cuenta que no hay actividad entre ningún cliente y el Nodo A del Cluster, surge una pregunta (the question) ¿Cuándo finalizará la ejecución del comando NLB DRAINSTOP? Pues tardará un ratito, un par de minutos en este caso, para finalizar dejando el Nodo A en estado stopped.

Para comprobar el avance del comando NLB DRAINSTOP, puede utilizarse el comando NLB PARAMS, a través del cual podremos comprobar las conexiones activas del Nodo (esta información aparece al final de la salida de la ejecución de NLB PARAMS). La utilidad de comprobar las conexiones activas a través de NLB PARAMS, es debido a que mientras existan conexiones activas, el Nodo seguirá en estado draining, y sólo cambiará a estado detenido (stopped) cuando se alcancen cero conexiones activas. El comando NLB PARAMS sólo puede ejecutarse desde la línea de comandos, no existiendo posibilidad de ejecutarlo desde la interfaz gráfica (es decir, NLB Manager). Aquí se presenta un riesgo importante, desde el punto de vista de Operación: si nos conceden una ventana horaria para realizar un cambio en producción, lo que quizás no nos podamos permitir (o sí, depende del caso), es que el cambio tarde mucho más tiempo en realizarse al utilizar NLB DRAINSTOP. Esto es algo a evaluar en cada caso, no sólo técnicamente.

Llegados a este punto, podemos encontrar claramente la diferencia entre NLB STOP y NLB DRAINSTOP: Mientras NLB STOP tiene efecto de forma inmediata, el comando NLB DRAINSTOP puede tardar bastante más en dejar en estado detenido (Stopped) al Nodo del Cluster, con la ventaja de realizar una parada mucho más suave, esperando a que finalicen las conexiones de usuario (y con el riesgo de que un usuario cansino, nos haga tirarnos un buen rato esperando hasta que se cambie del estado draining a stopped).

Es importante, tener en cuenta que en ocasiones (y dependiendo de cuál sea el servicio que se está balanceando en el NLB), podríamos detectar que el comando NLB DRAINSTOP no progresa (o tarda demasiado), es decir, es decir, no llega a finalizar manteniendo al Nodo en estado training pero sin llegar a alcanzar el estado detenido (stopped), aún pasando una gran cantidad de tiempo (lo que decíamos antes). En esta situación, tenemos dos posibles salidas:

  • Ejecutar NLB STOP. De esta forma, cambiaremos el estado del Nodo a detenido (stopped) de forma inmediata. Quizás sea esta la alternativa más sensata.
  • Ejecutar NLB START. Si nos arrepentimos, siempre podemos volver a iniciar de nuevo el NLB en el Nodo, ejecutando el comando NLB START.

Como conclusión, en función de cuál sea la aplicación que se está exponiendo a través del Cluster NLB, es posible que la ejecución del comando NLB STOP sea suficiente (ej: una Aplicación Web en IIS con almacenamiento compartido de la Sesión, podría operarse con NLB STOP), no siendo necesaria la utilización del comando NLB DRAINSTOP, y con la ventaja adicional de que NLB STOP tiene efecto inmediato (NLB DRAINSTOP puede tardar varios minutos, o incluso no progresar por conexiones colgadas, que requieran finalmente la ejecución el comando NLB STOP).

¿Cómo ejecutar los comando NLB STOP, NLB DRAINSTOP, NLB PARAMS y NLB START?

Resuelta la primera duda (qué diferencia existe entre NLB STOP y NLB DRAINSTOP), nos encontramos con la segunda ¿Cómo podemos lanzar comandos NLB STOP, NLB DRAINSTOP, etc.?

Principalmente, tenemos dos forma de ejecutar estos comandos: por línea de comandos (es decir, desde una ventana del Símbolo del Sistema) o desde la interfaz gráfica del NLB (la herramienta administrativa NLB Manager). Antes de continuar, se debe tener en cuenta que el comando NLB PARAMS sólo se puede ejecutar desde el Símbolo del Sistema, no existiendo alternativa gráfica para ejecutar NLB PARAMS.

Para ejecutar estos comandos desde una ventana de Símbolo del Sistema, nos conectaremos al Nodo deseado (ej; a través de una conexión RDP de Terminal Server, a través de una conexión Telnet, etc.), abriremos una ventana de Símbolo del Sistema y los ejecutaremos tal cual, es decir, ejecutaremos nlb stop, ó nlb drainstop, ó nlb params, o nlb start. No requieren parámetros adicionales, por lo tanto, su ejecución es muy sencilla.

Para ejecutar estos comandos a través de la herramienta administrativa NLB Manager, nos conectaremos al Cluster NLB deseado desde el menú Cluster -> Connect to existing, seguidamente click con en el botón derecho sobre el Nodo deseado, click en Control Host, y seguidamente click sobre la opción de menú deseada (e: Start, Stop, Drainstop). A continuación se muestra una pantalla capturada, con fin orientativo.

Y hasta aquí llega este capítulo, que sinceramente, tenía ganas de escribirlo. Espero que guste.

Volver a: [Instalar y Configurar Microsoft Cluster NLB (Network Load Balancing) en Windows Server 2003]


[Fecha del Artículo (UTC): 12/05/2009]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas