El manual para el clustering con openMosix - Clusters HA (II)

LVS (Linux Virtual Server)

A todo el conjunto de nodos que conforman el servicio y se comportan como si fuese un único servidor se le denomina Servidor Virtual. El cluster está formado por dos tipos de máquinas:

• por un lado están los nodos o servidores reales, que corren con los servicios habituales que estos suelen proveer,
• por otro lado están los nodos directores, de los cuales uno de ellos será el principal y el resto estarán preparados para hacer de refuerzo de éste (mediante técnicas o protocolos como heartbeat) para cuando caiga. Estas técnicas no son propias de LVS, como ya puede saberse a partir de las seccines anteriores.

• el código de ipvs, un parche al kernel para el nodo director
• el programa ipvsadm, encargado de configurar las tablas internas y algoritmos del kernel del nodo director

El funcionamiento de LVS es una aproximación a resolver el problema de la escalabilidad y el alto rendimiento muy elegante puesto que permite que cliente y servidor trabajen de la manera transparente permitiendo que el balanceo se lleve a cabo por el director. Comparado con métodos como el ofrecido por RR-DNS es mucho menos intrusivo y más confiable en su servicio.

Existen otras técnicas para ofrecer mayor escalabilidad y rendimiento en servicios de Internet. La alternativa RR-DNS es uno de los métodos más utilizados actualmente ya que permite independencia en arquitectura o sistema utilizado en el servidor Se basa en un algoritmo Round Robin en el servidor DNS, de manera que cuando un cliente solicita la dirección IP de un servidor ésta le es concedida según el algoritmo. Así por ejemplo si existen 4 máquinas servidoras que proporcionan el mismo servicio, a la primera conexión entrante que solicite el servicio se le asignará la dirección IP del primer servidor, a la segunda conexión la IP del segundo servidor y a la quinta conexión la IP del primero otra vez.

Uno de los defectos que tiene este método es que si uno de los servidores cae los clientes que asociaban el dominio a esa dirección IP lo seguirán haciendo, obteniendo un fallo en sus peticiones.

El servicio RR-DNS puede ser utilizado complementariamente a LVS, es decir, se utilizar RR-DNS para solicitar la IP de un Servidor Virtual LVS. Otra alternativa es el uso de clientes no transparentes, clientes que utilicen algún algoritmo para decidir que servidor utilizan en cada petición o sesión, lógicamente estos métodos son muy poco utilizados. Esto puede conseguirse mediante applets Java, por ejemplo.

Otras alternativas más conocidas son los proxies inversos, esta alternativa supone el mismo funcionamiento de un proxy, pero en el caso de los servidores. El Proxy recive las peticiones y gestiona una nueva conexión con uno de los servidores reales mediante algún tipo de algoritmo de balanceo, el servidor responde al proxy y este envía las peticiones de nuevo al cliente. Esta alternativa es muy utilizada, aunque presente menos índice de escalabilidad y más sobrecarga en los equipos que RR-DNS o LVS. El proxy acaba por resultar un cuello de botella ya que éste abre 2 conexiones TCP por cada conexión que se realiza al Proxy, esta solución a nivel de aplicacion se puede realizar mediante programas como SWEB^4.3.

Por último, están las alternativas propietarias de empresas como CISCO, IBM, COMPAQ y demás empresas que tienen bastante código tanto a nivel de aplicación, kernel y hardware específico para este tipo de tareas.

A pesar de que el director LVS se comporta como un conmutador (switch) de nivel 4 no actúa como un Proxy inverso. El modo de actuar es bien distinto. El nodo director utiliza un kernel especial parcheado que permite el balanceo de carga de los servicios mediante varios métodos de planificación, además es configurable mediante un programa en zona de usuario que permite pasarle los parámetros al kernel acerca de como debe balancear conexiones. El director se comporta como un conmutador de nivel 4 en la arquitectura OSI, balancea conexiones o datagramas según se le haya exigido en su algoritmo de balanceo.

El efecto de solicitar una petición sobre el Servidor Virtual LVS es el siguiente:

1. el cliente solicita un servicio o conexión a la dirección del Servidor Virtual LVS (llamada VIP) que posee la interfaz pública del nodo director
2. el nodo director se encarga de balancear la conexión según el algoritmo programado, hacia el servidor real dentro de la batería de servidores
3. el servidor contesta al cliente con su respuesta y la enví a hacia él.

La diferencia con un Reverse Proxy estriba en que LVS no requiere de la vuelta de las peticiones al director, ya que éstas pueden ser enviadas directamente al cliente, lo que evita que el director se convierta en un cuello de botella en el sistema, como ocurre en el caso de los proxys inversos.

LVS puede solucionar muy satisfactoriamente casos de adaptabilidad a requerimientos o escalabilidad, redundancia, alta fiabilidad y mayor crecimiento de los servicios ofrecidos. Por todo esto se puede considerar dentro de los clusters de Alta Fiabilidad (HA).

Figura: Clusters HA. Topología típica de un LVS básico

En cualquier caso y generalizando el concepto de cluster, LVS utiliza varias máquinas para aumentar el rendimiento y la fiabilidad de un servicio, es decir un problema, y como tal se puede considerar como un cluster. La idea de migrar sockets no tiene una solución general inmediata, MOSIX la solucionaba prohibiendo a los procesos servidores de cada máquina que migrasen a otros nodos, impidiendo un balanceo perfecto del sistema. El que un proceso que tiene un socket migre conlleva un problema de difícil resolución. LVS proporciona un sistema bastante adaptable para migrar sockets, por lo que es un sistema ideal y complementario a otros.

El nodo director se comporta como un router al que se le han añadido en el kernel tablas de encaminamiento para reenviar paquetes a los servidores reales para los servicios que se hayan configurado en el cluster LVS.

Existen tres maneras de efectuar el reenvío o encaminamiento en LVS: VS-NAT, VS-DR, VS-TUN.

• VS-NAT hace uso de NAT dinámico para efectuar transacciones entre servidor real y cliente.
• VS-DR o VS-Direct routing hace uso de direcciones virtuales mediante alias en dispositivos Ethernet para reenviar a la dirección Virtual del director (VIP) a cada servidor real.
• VS-TUN hace uso de ip-tunneling para reenviar los paquetes a los servidores reales, esto implica que el sistema operativo deba poder manejar la desencapsulación de estos paquetes especiales.

Métodos de balanceo IP

En esta sección se describirán las técnicas descritas anteriormente con las que LVS balancea los paquetes TCP/IP o UDP/IP hacia los servidores reales. Estas tres técnicas son bien distintas y permiten configurar LVS de una manera específica para cada solución que se quiera implementar. La elección de una u otra técnica depende principalmente del servicio que se quiera proveer, los conocimientos que se posean de los sistemas, el sistema operativo de los servidores, los recursos económicos que se estén dispuestos a gastar y consideraciones sobre el rendimiento.

VS-NAT

Es el caso más sencillo de configurar de todos y el que menor rendimiento tiene respecto a los otros dos.

VS-NAT hace uso de NAT para modificar direcciones, existen tanto la implementación para las versiones de kernel 2.2^4.5 como para las 2.4^4.6. Ambas implementaciones dan soporte SMP para LVS en el nodo director (que es el que tiene el kernel modificado), lo que permite una tasa de manejo de paquetes muy alta para clusters que proveen de mucho servicio.

VS-NAT se compone de un director que corre el kernel parcheado con LVS (ipvs) y de una batería de servidores que pueden correr con cualquier sistema operativo y cualquier tipo de servicio. El nodo director se encarga de recibir las peticiones de los clientes por su VIP mediante el algoritmo de balanceo elegido se reenvían los paquetes a el servidor real de manera que el servidor responde a la petición y los encamina al nodo director, el cual cambia las direcciones de la cabecera de los paquetes IP del servidor, para que el cliente los acepte sin problemas. Como se puede ver, el mecanismo es muy parecido por no decir igual que el de un Proxy inverso, excepto por que el redireccionamiento se hace a nivel de kernel.

Primero el director reenvía sus paquetes mediante el código ipvs, modificando los paquetes que se recibieron del cliente mediante el cambio de la dirección destino hacia los servidores reales y luego vuelve a hacer el cambio inverso mediante NAT dinámico a los paquetes que envían los servidores.

Figura: Clusters HA. Configuración VS-NAT

Este método es más utilizado que el anterior, se basa en redirigir los paquetes IP del nodo director al destino mediante técnicas de IP-tunneling, esto requiere que tanto el nodo director (que debe correr bajo Linux y por tanto puede ser compilado con IP-tunneling) como el servidor real puedan encapsular y desencapsular paquetes especiales. Para esto es necesario que la pila IP del sistema operativo lo soporte, y no todos los sistemas operativos lo soportan, en general la mayoría de Unix que existen en el mercado si lo soportan, por lo que en un principio no debe ser un grave inconveniente para la elección de este método como base de LVS.

El funcionamiento mediante este método de balanceo es el siguiente:

• el cliente hace la petición a la VIP del director
• el director elige mediante el algoritmo de balanceo cual será el servidor real que atienda la petición
• el servidor encapsula el paquete (que le llegó por la interfaz asignada a la VIP) en otro paquete IP con destino el servidor real

Figura: Clusters HA. Configuración VS-TUN

La desventaja de esta técnica está en que tanto el director como el servidor tienen que poder crear interfaces de tipo tunneling, y como consecuencia de hacer IP-tunneling siempre estará implícito un tiempo de procesador ocupado en encapsular o desencapsular los paquetes, que si bien en algunos sistemas puede ser insignificantes, en otros puede ser decisivo para la elección de otro método de balanceo.

VS-DR

VS-DR se basa en una tecnología de red local (en un único segmento) y en un cambio de direcciones IP-MAC para proporcionar el método de reenvío de los paquetes.

Al igual que VS-TUN no requiere reenviar los paquetes al nodo director, por lo que no presenta en él un cuello de botella. Es quizá el más utilizado de los tres, por ser el que mayor rendimiento obtiene, pero al igual que el resto, presenta una serie de desventajas en su uso y configuración.

El funcionamiento de VS-DR es similar al de VS-TUN en el sentido de que ambos utilizan la dirección VIP no solamente en el nodo director (donde esta la dirección VIP real a la que acceden los clientes) sino también en los nodos servidores. En este caso, los servidores poseen dos direcciones asociadas al nodo, una es la IP real asociada a la tarjeta Ethernet, la otra es una dirección loopback especial configurada con la dirección VIP, es conveniente dejar la interfaz loopback que tiene la dirección 127.0.0.1 sin modificar, por lo cual se debe hacer un alias de esta interfaz pero con la dirección conocida como VIP.

De este modo los clientes hacen la petición a la VIP del director, éste ejecuta el algoritmo de elección del servidor, solicitando mediante ARP la dirección del servidor al que pretende enviar para conocer la dirección MAC asociada a esta IP. Una vez que la conoce envía un los paquetes del cliente, sin ser modificados, en una trama Ethernet con destino la dirección del servidor real. Éste recibe la petición y comprueba que pertenezca a alguna de las direcciones que él posee, como hemos configurado la VIP en un interfaz loopback, la petición se efectuará sin problemas.

Este método requiere en ciertas ocasiones que el servidor acepte las peticiones asociadas al interfaz declarado como lo0:1, es decir el de loopback, en el caso de ser una máquina Linux.

Esto implica generalmente que el servidor pueda ser configurado para ello, por ejemplo en el caso de apache (uno de los servidores más utilizados de HTTP), en el fichero de configuración /etc/httpd.conf se debe especificar en una linea como

Listen dir_VIP:PORT_VIP

para que el servidor acepte las peticiones provenientes de esta interfaz. Esto puede resultar un inconveniente en ciertos servidores.

Figura: Clusters HA. Configuración VS-DR

Una vez vistos los tres mecanismos principales de las técnicas de balanceo se darán algunas consideraciones de carácter general acerca de las mismas.

Casi todas las implementaciones de LVS se suelen hacer con el cluster de servidores colocado en una red de área local, excepto las del tipo VS-TUN. Si disponemos de una conexión con el cliente de alto ancho de banda estaremos utilizando, en el peor de los casos, VS-NAT, y habrá más de 20 servidores reales en la red privada de 10 Mbps. Probablemente la red acabe congestionada con mucha asiduidad, provocando respuestas mucho peores de las que podría dar un servidor único, más caro.

Por otro lado está el factor de carga de los equipos. Cada servicio proporcionado por el servidor virtual puede tener como servidores reales destino un subconjunto de la batería de servidores. Esto implica que cada nodo debe ser convenientemente administrado y elegido con recursos y características correctas antes de la puesta en funcionamiento del LVS.

En el caso del nodo director sucede lo mismo, éste debe ser conveniente elegido para su cometido, el parche LVS no inhabilita el funcionamiento SMP del kernel de Linux^4.7 por lo que puede ser elegida una máquina de este tipo para hacer las funciones de nodo director. El funcionamiento de LVS se basa principalmente en engañar al cliente acerca de quién le está sirviendo. Así el cliente aceptará todos los paquetes que le vengan con la dirección VIP y determinados números de secuencia y asentimiento (en el caso de los TCP) con lo que solamente hay que elegir entre los diferentes mecanismos para poder llevar a cabo este cambio de direcciones: NAT, tunneling o mediante encaminamiento directo.

Otra de las desventajas que conlleva la instalación de un sistema LVS es la formación y el conocimiento con el que deben contar los diseñadores de la red y de cada sistema que intervienen en un sistema LVS. Al estar formado el sistema por un grupo hetereogéneo de elementos, en la mayoría de los casos con una relación de dependencia bastante fuerte, es necesario conocer extensivamente cada uno de los sistemas individuales, para que ninguno de ellos falle o baje su rendimiento. Por ejemplo es necesario saber el como hacer masquerading en el nodo director, como evitar ICMP Redirects en el director, como evitar los problemas ARP (se verá más tarde), como hacer auditorías a la red y gestionarla para ver donde tiene el sistema sus cuellos de botella y un largo etcetera de problemas potenciales que hacen que la puesta en marcha de uno de estos sistemas en entornos de producción sea más difícil de lo que en un principio pueda parecer.

Aspectos Técnicos

• Diseño de la red. Direcciones, topología, servicios y arquitectura del sistema global.
• Preparación y configuración de los nodos directores, puesto que puede haber más de un nodo director haciendo backup.
• Preparación y configuración de los nodos que actuarán como servidores reales.
• Configuración de los elementos de encaminamiento (enrutadores) y seguridad (firewalls^4.8).
• Configuración de la parte que proveerá al sistema de alta fiabilidad y redundancia.
• Configuración de un sistema de almacenamiento compartido.

Se podrían añadir otros tantos puntos para cada sistema específico. Pero para un sistema general en producción, los imprescindibles son los ya enunciados.

Apartado de Red

El diseño y elección de la topología de red es bastante crítica en la implantación del sistema ya que puede convertirse en uno de los cuellos de botella.

Generalmente los nodos servidores se encuentran en una red privada Ethernet a la que pertenecen tanto la batería de servidores como los nodos que actúen como director en el sistema. Hay que tener en cuenta que por esta red pasaran:

• las peticiones y respuestas de los clientes en el peor de los casos (VS-NAT),
• los paquetes de monitorización,
• paquetes de sistema de manejo y gestión del cluster, etc...

Esto probablemente implica separar por un lado la red por la que se efectúan todos los intercambios de petición entre el nodo director y los servidores reales, una red específica para el sistema de almacenamiento elegido y excepto en el caso de VS-NAT una red (o varias dependiendo del ancho de banda requerido para proveer servicio) para la salida de las respuestas de los servidores reales. Aun quedarían los paquetes de monitorización o redes destinadas a openMosix o similares.

Por último se podría utilizar una red más barata entre el nodo director y su nodo de backup, en el caso de utilizar Heartbeat^4.9.

Esta trama de redes no es necesaria en todos los sistemas, bastaría medir la congestión en la red para poder ver que servicios se deben separar de los otros para evitar las congestiones en cualquiera de los casos.

En lo referente al direccionamiento, generalmente solamente el nodo director debe tener una dirección pública, mientras que el resto de los nodos servidores suelen tener direcciones privadas reservadas. El mecanismo de direccionamiento utilizado en Ethernet provoca un problema que se tratará más tarde. En el caso de los servicios proporcionados. En la mayoría de los casos no interviene ningún factor externo en la configuración salvo casos como el explicado en el apartado anterior en el que se configura un servicio para un determinado interfaz de la máquina servidora. El único problema que plantean los servicios en un cluster del tipo LVS es el problema de la persistencia.

Se entiende por conexiones persistentes dos tipos de conexiones:

• una es del tipo de los servidores HTTP, en los cuales intervienen los tiempos de establecimiento de conexión activa, el tiempo de transferencia real y el tiempo de aproximadamente 15 segundos (aunque es muy variable) hasta que se cierra la conexión con el cliente.

  El manejo de esta persistencia es realmente sencillo.

• otro tipo de persistencia es la debida a dependencias entre varios sockets, como es el caso de servicios como FTP o el paso de HTTP a HTTPS en una transacción o compra vía Internet. Dichas conexiones son más difíciles de analizar, ya que dependiendo del servicio se establecerán factores de dependencia entre unos puertos u otros.

Por último se deben considerar todos aquellos factores relativos a la seguridad en redes que se puedan aplicar en servidores normales, de los que se encuentra amplia bibliografía.

Consideración respecto al tipo de encaminamiento elegido

En lo que se refiere al rendimiento de cada tipo de encaminamiento es obvio que hay que separarlo en dos, por un lado VS-NAT y por otro VS-TUN y VS-DR.

VS-NAT se basa en el NAT tradicional, esto implica que cada paquete ya sea de conexión o de cualquier otro tipo que entra por parte del router o cliente es evaluado de la forma antes descrita y reenviado al servidor real. La cabecera IP es modificada con los valores fuente del nodo director, el servidor procesa la petición y da su respuesta al nodo director, que otra vez hace NAT al paquete colocando como destino el nodo cliente, y se vuelve a enviar al router por defecto del director.

Este mecanismo exige no solamente el balanceo de las conexiones por parte del kernel, sino un continuo cambio de direcciones a nivel IP de todos los paquetes que pasan por el director, así como la evaluación de los mismos, lo que hace que el rendimiento de este método se vea limitado a la capacidad de proceso que posea el nodo director. Por tanto es muy fácil dimensionar mal las capacidades del director o de la red y hacer que la salida a través del director se convierta en un cuello de botella. En el caso de el VS-NAT existe una opción en el kernel para optimizar el reenvió de paquetes para que este sea más rápido, que consiste en no comprobar ni checksums ni nada, solamente reenviar.

En el caso de VS-DR o VS-TUN el rendimiento no cae tanto sobre el director. No obstante éste sigue siendo un punto crítico, pero las soluciones actuales en lo que se refiere a capacidad de proceso nos sobran para gestionar cantidades considerables. El mayor problema de estos dos tipos es el diseño de la red interior, para que esta no se congestione y por supuesto el problema ARP enunciado en el apartado anterior.

En ambos métodos, las respuestas de los servidores reales se envían directamente a los clientes a través de un enrutador que puede ser (o no) diferente del que envío la petición inicial al director. En el caso de VS-DR se exige, por el modo del algoritmo que todos los servidores reales pertenezcan al mismo tramo de una LAN, esta es la forma más común en entornos de producción de configurar LVS, ya que permite el mejor rendimiento y menos carga de la red de los tres.

El problema ARP

Otra consideración que afecta no solamente a la red sino a la configuración del sistema en general es el problema ARP. Como se ha visto hasta ahora la técnica de balanceo más utilizada es VS-DR, esta técnica ya ha estado descrita.

Para configurar LVS se puede hacer mediante tunneling o mediante DR, en cualquier caso habrá que añadir direcciones virtuales extras a la configuración de los servidores reales, asícomo a la del nodo director. Para esto se deberán compilar los núcleos de las máquinas con la opciones de ip aliasing en el apartado Networking.

En la figura se muestra el problema ARP.

Figura: Clusters HA. Problema del ARP

El servidor contesta y se reenvía la respuesta hacia el cliente. Pero ¿qué sucede si en lugar de contestar la máquina que hace las veces de director contesta una de las que esta haciendo de servidor? En este caso al lanzar el paquete ARP pidiendo Who has VIP tell cliente/router? en lugar de contestar el director contesta una de las máquinas que hace de servidor real. De esta manera la conexión se establece pasando por encima del LVS en una especie de bypass, sin tener en cuenta al nodo director, que no guarda los estados ni la conexión.

De hecho hasta aquí no se produce ningún error con respecto a el servicio realizado, ya que el servidor procede a la entrega de la respuesta, el problema esta en el caso de que la tabla ARP del router o cliente se borre^4.10 y vuelva a pedir ARP Who has VIP tell cliente/router concediéndose la MAC de otro servidor o incluso del nodo director, que no tiene ni idea de como lleva la conexión en ese momento ya que el no la estaba sirviendo. Como se puede ver es un problema inherente a la manera en la que hemos configurado nuestra solución que podría ser resuelto poniendo más de una tarjeta de red al director u otras soluciones. En cualquier caso, la red se comporta normalmente de manera aleatoria en la concesión de la MAC.

En cualquier caso la solución a este problema esta en conseguir que el director conteste a los paquetes ARP Who has VIP tell cliente/router, que son solicitados por el router o cliente.

Existen varias soluciones, desde parches para el kernel hasta un ifconfig -arp, pasando por meter una tarjeta de red más en el director o incluso modificando la tabla ARP del router para que no solicite ARP dinámicamente sino lo especificado.

Por ejemplo en /etc/ethers o directamente cambiando la tabla ARP de manera que todos los paquetes IP del router para la dirección VIP queden asociados al director. Cualquier solución es válida.

Al mismo tiempo exige un conocimiento bastante profundo del problema para los diseñadores de la red, ya que cada solución aportar unas ventajas y alguna desventaja. Generalmente se suelen utilizar dos opciones: añadir nueva tarjeta al director o adaptar el kernel de los clientes para que ellos no respondan a las peticiones ARP de alguna de sus interfaces, accediendo a /proc/sys/net/ipv4/lo/hidden o similar respecto al interfaz al que hemos asociado la VIP.

Hay que tener en cuenta que la especificación de -arp en el ifconfig se deshecha en kernels superiores al 2.0.* y exige el otro tipo de soluciones. Otra solución que se propone es modificar la tabla ARP que se encuentra en el cliente o router que hace el Who has VIP tell router, pero esto crea alguna complicación a la hora de tener que controlar la caída del nodo director de backup en el caso de que exista (caso muy probable) y la toma de sus funciones, ya que la MAC del nodo director actual cambia y por tanto debe cambiar la tabla MAC-IP configurada en el router.

Configuración y elementos que componen el nodo o nodos directores

El nodo director es uno de los puntos más críticos del sistema, por eso debe ser bien elegido y configurado para las tareas que debe hacer. Suele tener algún mecanismo de alta fiabilidad con un servidor replica que toma las funciones del nodo director cuando este cae de manera casi transparente^4.11 al sistema. La puesta a punto del nodo director (dejando a un lado el nodo réplica) esta formada por la configuración de varias de las herramientas de las que explicamos antes.

Lo primero es encontrar el código de lvs, este código se puede encontrar en la pagina oficial LinuxVirtualServer.

El paquete a descargar depende del kernel que se utilice, de esta manera se pueden elegir dos tipos de kernel donde instalarlo: la serie antigua (2.2) y la nueva (2.4). La manera de configurarlos es distinta.

El paquete LVS contiene más programas necesarios para la instalación de LVS y algunas herramientas de ayuda como el script configure del que hablaremos más tarde. El kernel del director debe ser parcheado, con el código de LVS una vez puesto el parche al kernel y compilado, se ejecuta y se configura mediante un programa en zona de usuario llamado ipvsadm que permite especificar el comportamiento del director.

Antes de seguir avanzando con la instalación de el kernel es necesario conocer, al menos por encima, el funcionamiento del núcleo que vamos a utilizar. Ver figura.

Figura: Clusters HA. Funcionamiento del kernel LVS

El director hace lo siguiente:

• las conexiones que se reciben del cliente (al interfaz que tiene la dirección virtual) son insertadas en el núcleo de decisiones de LVS,
• este núcleo se encarga de hacer la planificación mediante un mecanismo programado (algoritmo de balanceo)
• luego se insertan dichas conexiones en una tabla hash o tabla de dispersión.

Mediante la elección de las técnicas de balanceo ya vistas el núcleo se encarga de formar los paquetes IP que se enviarán a los nodos servidores.

En la zona de usuario se ejecuta el programa ipvsadm. Este programa viene dentro del paquete ipvs, debe ser compilado para cada versión específica del parche de kernel ipvs. El programa se encarga mediante la función setsockopt() de configurar el modo de funcionamiento del sistema, y mediante el sistema de ficheros /proc se encarga de leer las configuraciones que este tiene en cada momento.

Existen seis algoritmos para la elección del funcionamiento del nodo director. El algoritmo se selecciona en el kernel antes de la compilación, en el campo IPVS dentro de Networking options. Se pueden compilar como módulos o internos al kernel, se deben compilar todos los algoritmos que más tarde se utilizarán a la hora de encaminar a los servidores reales mediante la configuración de ipvsadm.

Se pueden distinguir dos familias de algoritmos, la dinámica y la estática. Los algoritmos a su vez se pueden separar en 3 tipos y sus derivados para pesos constantes.

• Round Robin y Round Robin con peso.
• Número de conexiones y número de conexiones con peso.
• Algoritmos basados en número de conexiones y localidad al nodo.
• Algoritmos relativos a cache-proxy (squid) y algoritmos relativos a fwmark (firewalls).

El algoritmo RR es semejante al utilizado en RR-DNS, pero en el caso de LVS la granularidad es mucho menor ya que se balancea por conexión. Un ejemplo de el algoritmo de Round Robin con peso, podría ser el caso de tener 3 servidores:

Como se puede ver las conexiones son balanceadas de manera alterna siguiendo un algoritmo sencillo de decremento del peso y nodo que lleva más tiempo sin ser utilizado. Esta es una manera muy sencilla de balancear la carga pero generalmente implicará que el balanceo no sea perfecto (en el caso de que el número de conexiones sea muy alto).

El algoritmo por número de conexiones (o least connections) y wheigthed least-connection responde a un algoritmo dinámico. Se basa en enviar las nuevas conexiones al nodo que tenga menos conexiones abiertas, esto requiere saber en todo momento cuantas conexiones abiertas tiene cada nodo, pero supone una ventaja en el comportamiento del sistema cuando el número de conexiones es elevado.

El algoritmo, que es sensible a los pesos, actúa dependiendo de los pesos que cada nodo tiene asignados en el director y se balancea según el número de conexiones abiertas^4.13. Este grupo de algoritmos balancea mejor la carga en lineas generales pero requiere un nodo director más potente para llevar el conteo del número de conexiones de cada nodo.

El algoritmo contador de conexiones con peso sería el siguiente.

Existe una batería de servidores para un determinado servicio con N servidores, a cada uno se le asigna un peso (i=1...N) y número de conexiones activas (i=1...N).

El número total de conexiones S no es más que la suma de las conexiones activas de cada nodo. De este modo la siguiente conexión para el servicio sera para el nodo j que cumpla:

(i= 1..N)

El único inconveniente es que el kernel no puede realizar esta operación, ya que no dispone de los números en coma flotante de forma que esta expresión debe ser cambiada a algo como de manera que la comparación pueda ser evaluada por el kernel. Lo más importante a tener en cuenta es que las conexiones con las que se trabaja son conexiones activas. Existen otros dos algoritmos más basados en el algoritmo least-connection que mejoran este en algunas situaciones, estos dos algoritmos se basan en la localidad de las conexiones, e intentan que el mismo cliente vaya, en caso de que el balanceo de la carga lo permita, al mismo nodo servidor que fue en otras conexiones realizadas por este cliente.

Una vez vistos los fundamentos teóricos para ver como debe compilarse el kernel puede pasarse a la instalación y compilación del mismo. Respecto a este punto se da por sentado que el administrador sabe aplicar parches al kernel y compilarlos de manera correcta.

Para empezar hay que obtener las fuentes del parche del kernel, el programa ipvsadm y el script configure.

Habrá que parchear el kernel (las versión de las fuentes del kernel deben coincidir con la versión de LVS), mediante el comando cat parche | patch -p1 o patch -p1 parche. Luego se deberán compilar con las opciones descritas anteriormente (para más información mini-Howto-LVS) y preparar el parche para las máquinas que vayan a actuar como director.

El nodo director puede ser una máquina sin discos que cargue su kernel a través de la red mediante TFTP (ver la sección referente a Nodos sin discos) para luego componer su directorio raíz mediante NFSroot. La opción de utilizar un diskette (o lilo) para ejecutar el kernel es la más utilizada.

Luego habrá que compilar e instalar las fuentes del programa ipvsadm y el sistema estará preparado.

A partir de aquí pueden hacerse dos tipos de configuraciones

• la primera exige un conocimiento del sistema LVS más profundo, ya que todos los parámetros se configuraran de manera manual mediante la orden ipvsadm
• la otra es utilizar el script en perl (para lo cual se debe tener instalado perl) para que configure los servidores y el director.

• servicios y servidores que conoce y gestiona el director
• pesos de cada servidor respecto al servicio ofrecido
• algoritmo de gestión (de scheduling)
• añadir servicios y servidores
• quitar servicios
• también existen un par de programas al tipo de ipchains que permiten guardar configuraciones

También incluye los programas y archivos de configuración necesarios para luego utilizar en el programa de monitorización MON. Es una ayuda cómoda para los que no quieran tener que configurar a mano de manera extensiva su LVS^4.14.

Para utilizar configure simplemente hay que seguir los pasos que se ven en uno de los ficheros de configuración por defecto que viene en la versión que se se haya obtenido, configurar los parámetros del sistema y ejecutar perl configure fich_de configuración. Al estar el script en perl son necesarios que los módulos necesarios para ejecutarlo. La salida del programa será un script del tipo rc.d que puede ejecutarse en los servidores reales y en el director (el script sabrá donde se ejecuta).

Otro factor a tener en cuenta a la hora de configurar servicios mediante ipvsadm son las conexiones persistentes. Hay que atender este tipo de conexiones en casos como una sesión HTTPS, en protocolos del tipo multipuerto como FTP (en los cuales los puertos 20 y 21 corresponden al mismo servicio) o sitios comerciales, donde un cliente debe cambiar del puerto 80 de HTTP al 443 para enviar por HTTPS sus datos bancarios.

Este problema requiere de configuraciones específicas en el director para que los servicios sean balanceados al mismo nodo, saltándose el algoritmo de balanceo. El caso de las conexiones persistentes es otro de los casos (junto con el de ARP) que dificulta la configuración de los servicios, pero al mismo tiempo es impensable un sitio en Internet que no vaya a proveer conexiones seguras a través de HTTPS o que simplemente tenga un FTP. En cualquier caso, la orden ipvsadm permite configurar este tipo de conexiones persistentes de manera bastante cómoda.

Instalación y configuración de un caso de estudio

(1,0)400

A continuación se adjunta un caso práctico de instalación de algunos servicios hasta ahora expuestos.

Corresponde a una de las experiencia prácticas que Carlos Manzanedo y Jordi Polo realizaron en su proyecto de fin de Ingeniería Informática en el año 2001 en la Universidad de Alcalá de henares (Madrid).

(1,0)400

Al realizar la instalación nos hemos encontrado con otros problemas debidos mayormente a la topología y diseño de la red utilizada. En la figura mostramos el esquema de nuestra imaplementación (VS-NAT y VS-DR) para probar LVS con servicios no persistentes como HTTP y telnet.

Figura: Clusters HA. NAT y DR un caso práctico

El nodo director es arrancado sin discos y esto no supone ninguna diferencia. La red interna pertenece a 10.0.0.0/24 y la externa a 192.168.10.0/24, el nodo director pertenece y encamina a las dos redes. Se ha utilizado un hub y cable coaxial para la conexión. Para trazar paquetes en la red se utilizaron herramientas GPL como ethereal o tcpdump (suelen venir en la distribución habitual que utilices) y generaciones de filtros para facilitar su uso.

Configuramos LVS con LVS-NAT, de manera que en un principio no nos tuvimos que preocupar del problema de ARP, que se puede evitar con

echo 1 /proc/sys/net/ipv4/conf/lo0:1/hidden

para que no mande respuestas ARP).

El funcionamiento es el siguiente^4.15:

1. el cliente solicita una conexión con algún servicio de VIP address, es decir ladirección virtual de los servicios),
2. crea algún paquete de nivel cuatro ya sea TCP o UDP que envía al director VIP,
3. éste reenvía el paquete al nodo servidor real que decida el algoritmo de encaminamiento pero cambiándole el dato destino (se cambia por la dirección del servidor real),
4. el paquete o petición llega al destino, es atendido por el servidor de dicho servicio (si existe) y se genera la respuesta que se envía al cliente.

Quizá la explicación sea algo liosa así que pongo un dibujo y explicación por puntos.

1. Cliente envía petición a VIP del director CIP-VIP
2. Director LVS consulta tabla-HASH para ver si hay conexión, si no la hay la crea según el algoritmo de scheduling del servicio.
3. Director envía la petición a el servidor elegido cambiando la dirección fuente CIP-RIP (paquete replica de el anterior CIP-VIP).
4. El servidor-real propio del servicio contesta mandando RIP-CIP a su gateway por defecto, es decir en nodo director DIP.
5. El director actúa como router-NAT y cambia el paquete de RIP-CIP a VIP- CIP y se lo envía al cliente.

echo 0  /proc/sys/net/ipv4/route/flush

para limpiar las rutas, que ha sido lo que más ha molestado.

Para configurar esta red arrancamos el servidor que baja su kernel por bootp/tftp y configura su directorio raíz con nfsroot, una vez que tenemos todos los ordenadores encendidos.

Configuración del sistema, relativa a IP's y tablas de rutas

En esta explicación por puntos de las pautas seguidas para configurar de forma manual el sistema no entraremos en detalles en lo que se refiere a conceptos o configuración de NAT o ipchains, aunque se requiere un conocimiento mínimo de ambos para poder configurar el sistema. De hecho, en este caso de estudio se dará una configuración mínima