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.
