Cuantos servidores mantienen el dominio Microsoft.com? creéis que es un solo servidor, con millones de gigas de ram, para dar servicio a todos sus visitantes? cada vez que se les queda pequeño, lo tiran y compran otro? Imagino que harán un desarrollo horizontal, en el que en vez de crecer de gigas de ram, por ejemplo, se añade un servidor mas. Debe haber una máquina que gestiones las conexiones, y que diga, esta para ti, esta para el otro... Hay muchos tipos de balanceo, que voy a intentar explicar. Hay que tener en cuanta un aspecto básico a la hora de implementar un balanceador. Si tenemos 10 servidores web, Apache, y montamos un LBN para gestionar las peticiones de manera eficiente, y se nos cae el balanceador, tiramos por tierra nuestra gestión TI ya que ni para uno, ni para otro. Hay que montar una contingencia para el caso de caídas del balanceador.
El típico modo de balanceo siempre ha sido Round And Robin DNS, lo que hace es que lanza las peticiones una vez a un servidor, otras veces a otro. El problema de este método es que si bien reparte peticiones, no reparte cargas. Por ejemplo, petición A se encamina a server A, la siguiente petición B se encamina a server B. La siguiente petición C irá a server A, pero que pasa si la conexión A requiere mucho proceso en el servidor, o mucho tráfico, y la petición B, en el momento de realizar la petición C, ya ha sido terminada?.
Como gestiona los NBL los servidores que tienen detrás a su cargo. Pues sencillo, si como siempre has estudiado teoría de redes, como siempre recomiendo.
En capa 2 del nivel OSI el NBL envía solicitudes ARP o consulta en su tabla para determinar las Mac´s-ip de los dispositivos. En capa 3 del nivel OSI el NBL hace una solicitud ICMP para comprobar si está vivo el servidor. En capa 4 del nivel OSI el NBL hace un TCP syn al puerto deseado en la petición, por ejemplo al puerto 80 de un servidor interno, o como es interno, y en nuestra casa podemos hacer lo que queramos, el que sea. Espera un TCP syn ACK.
Hay appliance o sotwares NBL que realizan estas comprobaciones en nivel OSI capa 7, por ejemplo hacer una peticion HTTP para comprobar la disponibilidad del server en base a su respuesta. Lo mismo para balanceadores FTP. Cuantas mas pruebas de salud realicemos, mas lento ira el balanceador, por lo que se recomienda realizar todas las comprobaciones, en otro server, y que este le pasa la información de "disponible o no disponible". por ejemplo, tener un servidor linux configurado con unos scripts que realicen las comprobaciones, y que devuelva unos cuantos códigos de estado al balanceador es una buena idea. Estas "integraciones" casi siempre son posibles si realizamos el NBL por software, ya que si lo realizamos con un Hardware pues dependemos del fabricante...
Mas cosas interesantes, sesiones !!. Pongamos por ejemplo, una compra de cualquier comercio on-line. No solo se establece una conexión TCP simple, sino que son numerosas, y a distintos sitios ( como por ejemplo al pagar, conectarnos a la pasarela de pago mediante una conexion segura con puerto TCP distinto). Hay que tratar el concepto de transacción, ya que no nos vale con tener una conexión TCP única, sino el conjunto de conexiónes. Todo debe ir con el mismo session ID. A este concepto se le llama Session Persistence ( El NBL debe saber el usuario en cuestion, y cuando empieza/acaba el conjunto de transacciones). Según el NBL, se puede identificar el Session Persistence de dos maneras, una mucho mas efectiva y costosa (computación) que la otra. Mediante Ip/puerto de origen el NBL puede redirigir todas las conexiones hacia el mismo servidor, hasta tener un TCP FIN o reset. Esta manera en sencilla, pero puede ser poco efectiva, por ejemplo, si el cliente del NBL es un proxy. Otra manera de establecer la persistencia es mediante Cookie. Cookie de lectura es mas sencilla de implementar, porque el NBL solo "leerá" la cookie, que previamente debe identificar el servidor web ( meter en la cookie que emite, un campo con el identificador interno del server, para que el NBL sepa con quien trabajar esa conexion).
Ahora viene la complejidad del asunto, hemos repasado los aspectos básicos de los NBL, a modo introductorio. Ahora toca ver los fabricantes de NBL como implementan estas soluciones, si mediante "siguiente,siguiente, siguiente" o lo que sea. Bien, como montaríamos un cluster de firewalls balanceados? Recuero que en anteriores post hablamos de los Firewall´s statefull, que guardan el estado de las conexiones, etc, pues montar un NBL de firewall´s TELA MARINERAAAAAAAAAA. Pero ya sabeis que en entornos complejos, no se van a quedar sin firewall porque tengan que actualizarlo, o porque se ha roto...
Os dejo tranquilos por hoy con los NBL, y mañana os comentaré las herramientas que tengo en mi lista para detectar si nuestros objetivos están bajo un NBL o de que tipo es.
Gracias por leerme !!!!
