Subsecciones

- 4.2.1 Introducción
- 4.2.2 El interés comercial
- 4.2.3 Conceptos importantes
  - 4.2.3.1 Servicio RAS
  - 4.2.3.2 Técnicas para proveer de disponibilidad
- 4.2.4 Soluciones libres
- 4.2.5 LVS (Linux Virtual Server)
  - 4.2.5.1 Introducción
  - 4.2.5.2 Métodos de balanceo IP
  - 4.2.5.3 Aspectos Técnicos
  - 4.2.5.4 Instalación y configuración de un caso de estudio
  - 4.2.5.5 ?`Y la alta disponibilidad?
  - 4.2.5.6 Conclusiones

# 4.2 CLUSTERS HA

## 4.2.1 Introducción

Los clusters HA estan diseñados especialmente para dar un servicio de alta disponibilidad. Esto tiene muchas aplicaciones en el mundo actual donde existen gran cantidad de servicios informáticos que debe funcionar 24x7x365. Estos clusteres son una alternativa real a otros sistemas usados tradicionalmente para estas tareas de hardware redundante que son mucho más caros, por ejemplo los ordenadores Tandem.

## 4.2.2 El interés comercial

Desde ya hace unos a nos Heartbeat está en las distribuciones SuSE, Conectiva y Mandrake; incluso Mission Critical Linux se ha interesado en él. Todo esto es así porque el mercado de clusters HA es un mercado con muchos potenciales clientes y, lo que es quizás más importante, para los intereses comerciales de muchas empresas.

Piénsese como ejemplo una empresa de grandes almacenes que tiene ordenadores carísimos validando las operaciones de tarjeta de crédito. Estos ordenadores no deben cancelar el servicio nunca porque si lo hicieran todo el sistema de tarjetas de créditos se vendría abajo, con lo que se podrían ocasionar grandes pérdidas económicas.

Por todo esto se desarrollan proyectos que intentan conseguir esta disponibilidad pero no gracias a un soporte hardware carísimo, sino usando clusters. Las empresas que necesitan alta disponibilidad suelen pagar a la empresa que le ofrece este servicio aun cuando los programas sean de libre distribución, quieren unas garantías. Esto está haciendo que muchas empresas estén colaborando en proyectos libres de HA, cosa que no deja de ir en pro de la mejora del software en cuestión.

Las enormes diferencias entre el precio del hardware de las soluciones tradicionales y estas nuevas soluciones hacen que las empresas tengan un buen margen de beneficio dando un servicio de soporte.

Es bastante obvio por qué estos clusters estan más solicitados que los de alto rendimiento (HP): la mayoría de las empresas se pueden permitir en cierto modo máquinas potentes que les solucionen las necesidades de cómputo, o simplemente contar con el tiempo suficiente para que sus actuales equipos procesen toda la información que necesitan. En la mayoría de los casos el tiempo no es un factor crítico y por tanto la velocidad o la capacidad de cómputo de las máquinas no es importante. Por otro lado, que se repliquen sistemas de archivos para que estén disponibles, o bases de datos, o servicios necesarios para mantener la gestión de la empresa en funcionamiento, o servicios de comunicación interdepartamental en la empresa y otros servicios, son realmente críticos para las empresas en todos y cada uno de los días en los que estas están funcionando (e incluso cuando no están funcionando).

## 4.2.3 Conceptos importantes

Un buen cluster HA necesita proveer fiabilidad, disponibilidad y servicio RAS (explicado más adelante). Por tanto debe existir una forma de saber cuándo un servicio ha caído y cuándo vuelve a funcionar.

Esto se puede conseguir de dos maneras, por hardware y por software. No se van a tratar aquí los mecanismos que existen para conseguir alta disponibilidad por hardware, pues están más allá de los objetivos de este documento. Baste decir que construir estos ordenadores es muy caro pues necesitan gran cantidad de hardware redundante que esté ejecutando paralelamente en todo momento las mismas operaciones que el hardware principal (por ejemplo una colección de placas base) y un sistema para pasar el control o la información del hardware con errores a hardware que se ejecute correctamente.

Los clusters HA solucionan el problema de la disponibilidad con una buena capa de software. Por supuesto mejor cuanto más ayuda se tenga del hardware: UPS, redes ópticas, etc. Pero la idea tras estos sistemas es no tener que gastarse millones de euros en un sistema que no puede ser actualizado ni escalado. Con una inversión mucho menor y con software diseñado específicamente se puede conseguir alta disponibilidad.

Para conseguir la alta disponibilidad en un cluster los nodos tienen que saber cuándo ocurre un error para hacer una o varias de las siguientes acciones:

- Intentar recuperar los datos del nodo que ha fallado.

  Cuando un nodo cae hay que recuperar de los discos duros compartidos por los nodos la información para poder seguir con el trabajo. Generalmente hay scripts de recuperación para intentar recuperarse del fallo.

- Continuar con el trabajo que desempeñaba el nodo caído.

  Aquí no se intenta recuperar del fallo sino que cuando se descubre que ocurrió un fallo otro nodo pasa a desempeñar el puesto del nodo que falló.

  Esta es la opción que toma por ejemplo Heartbeat: permite que 2 ordenadores mantengan una comunicación por un cable serie o Ethernet, cuando un ordenador cae el ordenador que no recibe respuesta ejecuta las órdenes adecuadas para ocupar su lugar.

Las ventajas de escalabilidad y economía de los clusters tienen sus desventajas. Una de ellas es la seguridad. Cuando se diseña un cluster se busca que haya ciertas facilidades de comunicación entre las estaciones y en clusters de alta disponibilidad el traspaso de información puede ser muy importante.

Recordando el ejemplo anterior de las tarjetas de crédito, se ha visto que se podría crear un cluster de alta disponibilidad que costara varias veces menos que el ordenador centralizado. El problema podría sobrevenir cuando ese cluster se encargara de hacer operaciones con los números de las tarjetas de crédito y transacciones monetarias de la empresa. Las facilidades de comunicación podrían ocasionar un gravísimo problema de seguridad. Un agente malicioso podría hacer creer al cluster que uno de los nodos ha caído, entonces podría aprovechar el traspaso de la información de los nodos para conseguir los números de varias tarjetas de crédito.

Este es uno de los motivos por los que, en según qué entornos, estos sistemas no se hayan implantado.

### 4.2.3.1 Servicio RAS

En el diseño de sistemas de alta disponibilidad es necesario obtener la suma de los tres términos que conforman el acrónimo RAS.

- Reliability.

  El sistema debe ser confiable en el sentido de que éste actúe realmente como se ha programado. Por un lado está el problema de coordinar el sistema cuando éste está distribuido entre nodos, por otro lado hay el problema de que todo el software que integra el sistema funcione entre sí de manera confiable.

  En general se trata de que el sistema pueda operar sin ningún tipo de caída o fallo de servicio.

- Availability.

  Es lógicamente la base de este tipo de clusters. La disponibilidad indica el porcentaje de tiempo que el sistema esta disponible en su funcionalidad hacia los usuarios.

- Serviceability.

  Referido a cómo de fácil es controlar los servicios del sistema y qué servicios se proveen, incluyendo todos los componentes del sistema.

La disponibilidad es el que prima por encima de los anteriores. La disponibilidad de un sistema es dependiente de varios factores. Por un lado el tiempo que el sistema está funcionando sin problemas, por otro lado el tiempo en el que el sistema esta fallando y por último el tiempo que se tarda en reparar o restaurar el sistema.

Para medir todos estos factores son necesarios fallos. Existen dos tipos de fallos: los fallos que provocan los administradores (para ver o medir los tiempos de recuperación y tiempos de caídas) y los fallos no provocados, que son los que demuestran que los tiempos de reparación suelen ser mucho más grandes de los que se estimó en los fallos provocados.

La naturaleza de los fallos puede afectar de manera diferente al sistema: pudiendolo ralentizar, inutilizar o para algunos servicios.

### 4.2.3.2 Técnicas para proveer de disponibilidad

Cualquier técnica deberá, por definición, intentar que tanto el tiempo de fallo del sistema como el tiempo de reparación del mismo sean lo más pequeños posibles.

Las que tratan de reducir el tiempo de reparación se componen a base de scripts o programas que detectan el fallo del sistema y tratan de recuperarlo sin necesidad de un técnico especializado. En general son técnicas de automatización de tareas basadas en sistemas expertos (SE). Al reducir el tiempo de recuperación, el sistema puede no solamente funcionar activamente sin fallos durante más tiempo, sino que también se aumenta su confiabilidad.

i.- Técnicas basadas en redundancia

Por un lado hay las técnicas basadas en reducir el tiempo de fallo o caída de funcionamiento, estas técnicas se basan principalmente en efectuar algún tipo de redundancia sobre los dispositivos críticos. Saber cuáles son estos dispositivos suele ser cuestión de conocimiento acerca del sistema y de sentido común.

Las técnicas basadas en la redundancia de recursos críticos permiten que cuando se presenta la caída de uno de estos recursos, otro tome la funcionalidad. Una vez esto sucede el recurso maestro puede ser reparado mientras que el recurso backup toma el control. Entre los tipos de redundancia que pueden presentar los sistemas hay:

- Redundancia aislada.

  Es la redundancia más conocida donde existen 2 copias para dar una funcionalidad o servicio. Por un lado hay la copia maestro y por otro lado la copia esclavo. Cuando cae el servicio o recurso la copia redundante pasa a ser la utilizada, de esta manera el tiempo de caída es mínimo o inexistente.

  Los recursos pueden ser de cualquier tipo: procesadores, fuentes de alimentación, raids de discos, redes, imágenes de sistemas operativos...

  Las ventajas son cuantiosas: para empezar no existen puntos críticos de fallo en el sistema, es decir, el sistema al completo no es tomado como un sistema con puntos de fallos que bajen la confiabilidad del mismo. Los componentes que han fallado pueden ser reparados sin que esto cause sobre el sistema una parada.

  Por último, cada componente del sistema puede comprobar de manera periódica si se ha producido algún tipo de fallo en los sistemas de backup, de modo que se compruebe que éstos están siempre funcionales. Otra opción es que además de comprobar, presenten habilidades para localizar fallos en sistemas y los intenten recuperar de manera automatizada.

- N-Redundancia.

  Es igual que la anterior pero se tienen `N` equipos para ofrecer un mismo servicio, con lo cual presenta más tolerancia a fallos.

Así por ejemplo para dotar de sistema redundante a una red como la que muestra el esquema A de la figura debería haber el doble de recursos necesarios para construirla, e implementarlos como en el sistema B.

Figura: Clusters HA. Redundancia

En este caso se replicaron:

- LAN
- LAN para los servidores
- Los servidores
- El bus SCSI de acceso a discos duros
- Discos duros

Como se puede ver la replicación proporciona rutas alternativas, discos alternativos y en general recursos alternativos, y es aplicada sobre todos aquellos recursos que se consideren críticos en una red.

Otro apartado a la hora de considerar la instalación de dispositivos redundantes es la configuración o el modelo de funcionamiento de los mismos. Depende de como se haya implementado el software y como se haya dispuesto el hardware y define el modo de comportamiento de la redundancia. Esta redundancia puede ser del tipo:

1. Hot Standby.

   Este tipo de configuración es la que se ha visto hasta ahora. En cuando el nodo maestro cae existe un nodo backup que toma el control de sus operaciones. Hasta ahora no se ha tenido en cuenta un punto importante: el doble gasto en recursos que en un principio y si las cosas van bien se están desperdiciando.

   El servidor de backup simplemente monitoriza sus conexiones, la normal y la redundante en el caso de que esta exista, para asegurar que cuando el nodo maestro caiga tome correctamente el control de las operaciones. Exceptuando estas operaciones, el nodo backup no hace nada.

2. Toma de cargos mutua.

   La toma de cargos mutua es una configuración que soluciona la desventaja del apartado anterior. Mientras el nodo principal se ocupa de proveer de servicio, el nodo de backup hace las mismas operaciones que en apartado anterior y además puede efectuar otro tipo de operaciones. De este modo, la capacidad de este nodo se está aprovechando más que en el anterior y el costo del sistema se ve recompensado con un equipo más que se utiliza para efectuar trabajo útil. El problema está cuando el nodo maestro cae. En este caso, el comportamiento del backup puede tomar dos vías.

   - la primera es mantener sus actuales trabajos y tomar los trabajos que el maestro ha dejado sin hacer. Esta manera de comportarse presenta una bajada de rendimiento del sistema crítico, pero hace que este esté disponible. Depende del tipo de trabajo que se presente sobre el backup que ahora ha pasado a ser maestro el considerar la prioridad de que trabajos son más críticos.

   - la segunda opción es dejar estos trabajos postergados hasta que el antiguo maestro sea reparado (lo cual puede ser hecho por el nodo de backup, es decir el nuevo maestro) y cuando éste tome las tareas de backup, que continúe con el trabajo que en un principio estaba efectuando él antes de tomar el control.

     Esta es una solución mucho más elegante y más difícil de implementar. Presenta mejor rendimiento coste que la anterior.

3. Tolerante a fallos

   Los sistemas redundantes a fallos se basan en la N-Redundancia. Si se tienen `N` equipos y caen `N-1` el sistema sigue en funcionamiento. Este sistema se puede cruzar con la toma de cargos mutua para no perder rendimiento ni elevar el costo del sistema, sin embargo configurar un sistema de este tipo es bastante complejo a medida que aumenta `N`.

ii.- Técnicas basadas en reparación

Por otro lado están las técnicas basadas en reducir el tiempo de reparación. Este tipo de técnicas se componen a base de scripts o programas que detectan donde fallo el sistema y tratan de recuperarlo sin necesidad de un técnico especializado. En general son técnicas de automatización de tareas basadas en sistemas expertos.

Al reducir el tiempo de recuperación, el sistema puede no solamente funcionar activamente sin fallos más tiempo, sino que también aumentamos la confiabilidad. Se pueden separar en dos tipos de acciones que realizan que pueden ser independientes o dependientes entre si:

- Diagnóstico.

  La parte de diagnosis simplemente trata de conocer las posibles causas que han provocado el error y principalmente localizar el error.

  Una técnica muy utilizada en este campo es una especie de piggybacking aplicada a los pulsos o latidos entre ambos nodos. En esta técnica, se envía junto con el latido o pulso, la suficiente información como para prever cual será el estado de los componentes en próximos tiempos o incluso actualmente, lo cual es una ventaja a la hora de saber en todo momento el estado del sistema. La implementación Heartbeat de Linux-HA hace una implementación muy coherente y correcta de esta técnica.

- Reparación.

  Son técnicas mediante las cuales a través de sistemas expertos o cualquier otro tipo de actuación, el sistema caído puede llegar a ser restaurado desde una copia del sistema. En la mayoría de los casos basa su funcionamiento en puntos de comprobación o checkpoints que se efectúan sobre el sistema cada cierto tiempo, de manera que el servidor caído es restaurado al último checkpoint existente. Los puntos críticos de este apartado son:

  - aislar los componentes que fallan y sustituirlos o repararlos. Los componentes que fallan pueden ser localizados mediante programas que implementen sistemas de comprobación o sistemas expertos.
  - recuperación mediante puntos de comprobación o puntos de restauración.
  - acoplamiento al cluster actual tomando las acciones que tenía el nodo backup e informando al nodo maestro de que ya existe un nuevo backup en el sistema.
  Los puntos de comprobación son importantes ya que introducen un factor de sobrecarga en el sistema y al mismo tiempo son un factor crítico a la hora de efectuar restauraciones del mismo. Un sistema al máximo confiable debería guardar el estado de todos los programas que está corriendo y comunicárselos a su backup en tiempo real para que de este modo la caída de uno guardase el estado del complementario. Serían sistemas simétricos.

  Este tipo de sistemas solamente son implementados en hardware, ya que exigen medios de comunicación muy rápidos (aparte de la sobrecarga al procesador que genera estar controlando este tipo de labores). Los clusters implementan a un nivel mucho menos eficiente este tipo de checkpoints, y la eficiencia depende generalmente de la capacidad de los procesadores y de la capacidad de la red que une maestro y backups. Debido a esto los clusters solamente guardan configuraciones y servicios activos, pero no el estado de conexiones y demás componentes que harían que un usuario externo observase la caída del sistema de modo realmente transparente, como si este no existiese.

  Esta es una de las grandes diferencias entre entornos de alta disponibilidad y entornos de alta confiabilidad, de los cuales no se ha visto ninguno implementado debido a que la tecnología actual los hace inviables.

  Existen varias maneras de efectuar el punto de comprobación. Por ejemplo en los sistemas implementados a nivel de kernel o sistema, el sistema operativo se encarga de efectuar este de manera completamente transparente al usuario o administrador. En los sistemas a nivel de aplicación son generalmente las bibliotecas de funciones las que proveen de estas características.

  Otro factor a tener en cuenta acerca de los checkpoints, que marca el rendimiento del sistema, es su intervalo. Éste debe ser óptimo: no crear congestión y permitir copias de restauración lo suficientemente actuales como para que los servicios cuenten con la máxima disponibilidad. En ocasiones, cuando el checkpoint es muy grande puede provocar congestiones. En cualquier caso, el principal problema de un checkpoint es la información que necesita para hacer la colaboración eficiente, y esto como hemos visto depende siempre del tipo de sistemas.

  Como última característica de los checkpoints, hacer una pequeña mención en los sistemas con más de un nodo de redundancia, en los cuales se pueden imaginar dos modos lógicos de hacer los checkpoints:

  1. Como checkpoints aislados, donde cada nodo se encarga de hacer los checkpoints de otro nodo al que replica cada intervalo de tiempo o por una política propia del sistema (puede caer en el denominado efecto domino, en el cual se guardan copias de sistema que no corresponden con el estado actual de los nodos).
  2. Frente a los checkpoints en grupo o checkpoints organizados, en los cuales todos los nodos se ponen de acuerdo para hacer un sistema de checkpoints efectivo. A cambio requiere más dificultad de implementación, y quizá sobrecarga del sistema.

## 4.2.4 Soluciones libres

Linux-HA

Este es el mayor proyecto de software libre de clusters HA que existe, parte de este proyecto es Heartbeat y trabajan conjuntamente con el grupo encargado de LVS.

Han desarrollado varias aplicaciones comerciales sobre este proyecto y se está utilizando en varios servicios con éxito. Como parte de los objetivos que se persiguen se encuentran:

- Servicios de membership.

  Estos servicios permiten añadir y quitar miembros a un cluster. El problema es que la llegada de un miembro a un cluster orientado a estados puede hacer cambiar de estado a todo el cluster (esto suele ser lo que ocurre en este tipo de clusters) con lo que se envían demasiados paquetes de sobrecarga demasiado a menudo por tanto ante esto se plantean soluciones como clusteres jerárquicos. Es la solución que dentro de Linux-HA ha sido apoyada por Stephen Tweedie.

- Servicios de comunicación.

  Comunicar información crítica de forma que una caída en un sistema no haga que se pierda la información y a la vez enviar la información de una forma suficientemente segura para evitar posibles ataques externos. Como se ha visto esto es especialmente importante en clusters HA.

- Manejo del cluster.

  Una serie de servicios que hagan sencillo el manejo del cluster en general y de los nodos y procesos en particular. Al igual que un sistema operativo provee de servicios para administrarlo, un cluster también debe proveer de instrucciones para gestionar su funcionamiento.

- Monitorización de los recursos.

  Este punto está muy unido al anterior. Para que el administrador detecte prematuramente posibles fallos y pueda ver qué ocurre en el cluster necesita algunas facilidades de monitorización. Por supuesto estos dos puntos no son exclusivos de los clustersHA ni del proyecto Linux-HA sino que son necesarios en todos los clusters.

- Replicación y/o compartición de datos.

  Para conseguir que los datos que estuviera modificando uno de los nodos no se pierda cuando caiga se puede replicar la información y/o mantenerla en lugares compartidos por todos los nodos con lo que cualquier nodo podría continuar con los datos compartidos.

  Para conseguir tener unos discos compartidos se necesita un hardware caro como es SCSI y fibra óptica.

  La replicación de información no necesita un hardware caro (solamente una red tan rápida como el coste permita) pero se necesita mantener un equilibrio entre los periodos de actualización de las copias y el uso de la red. Un cluster HA no suele necesitar demasiado ancho de banda por lo que se puede dedicar gran parte para este uso.

HeartBeat

Esta tecnología implementa heartbeats, cuya traducción directa sería latidos de corazón. Funciona enviando periódicamente un paquete que si no llegara indicaría que un servidor no está disponible, por lo tanto se sabe que el servidor ha caído y se toman las medidas necesarias.

Dichos latidos se pueden enviar por una linea serie, por UDP o por PPP/UDP. De hecho los desarrolladores de Heartbeat recomiendan el uso de puertos serie por varias razones, entre las que destacan que están aislados de las tarjetas de red.

También incluye toma de una dirección IP y una modelo de recursos incluyendo grupos de recursos. Soporta múltiples direcciones IP y un modelo servidor primario/secundario. Por ahora ya se ha probado útil para varias aplicaciones incluyendo servidores DNS, servidores proxy de cache, servidores web y servidores directores de LVS. El proyecto LVS recomienda HeartBeat para aumentar la disponibilidad de su solución, pero no es parte de LVS.

En Linux-HA Heartbeat es un servicio de bajo nivel. Cuando un ordenador se une al cluster se considera que el ordenador se ha unido al canal de comunicaciones (por lo tanto late) y cuando sale que ha dejado el canal de comunicaciones.

Cuando un ordenador deja de latir y se considera muerto se hace una transición en el cluster. La mayoría de los mensajes de manejo del cluster que no son heartbeats se realizan durante estas transiciones.

Los mensajes de Heartbeat se envían por todas las lineas de comunicación a la vez, así si una linea de apoyo cae, se avisará de ese problema antes de que la linea principal caiga y no haya una línea secundaria para continuar el servicio.

Heartbeat también se preocupa por la seguridad permitiendo firmar los paquetes CRC de 32 bits, MD5 y SHA1. Esto puede evitar el desastre que podría provocarse si un nodo no miembro se enmascarase como nodo miembro del cluster. Hay varias operaciones de mantenimiento de seguridad que necesitan ser efectuadas en ese tiempo, como pueden ser cambio de claves y de protocolos de autentificación. Heartbeat está preparado para esos cambios disponiendo de ficheros para la configuración.

Heartbeat tiene el problema que si no se dispone de una línea dedicada, aunque ésta sea una línea serie, al tener un tráfico que aunque pequeño es constante, suele dar muchas colisiones con otros tráficos que puedan ir por la misma red. Por ejemplo openMosix y Heartbeat en una misma red que no tenga gran ancho de banda no funcionan bien, sobre todo si hay bastantes nodos, pues los heartbeats se envían de cualquier nodo a cualquier nodo, por lo que podrían llegar a ser un tráfico voluminoso.

Ldirectord.

Pensado especialmente para ser usado junto con LVS, utiliza Heartbeat. Monitoriza que los servidores reales sigan funcionando periódicamente enviando una petición a una url conocida y comprobando que la respuesta contenga una cadena concreta. Si un servidor real falla entonces el servidor es quitado del conjunto de servidores reales y será reinsertado cuando vuelva a funcionar correctamente. Si todos los servidores fallan se insertará un servidor de fallos, que será quitado una vez que los servidores vuelvan a funcionar.

Típicamente este servidor de fallos es el propio host desdel que se realiza el monitoraje.

LVS.

Sobre este proyecto se dedica la siguiente subsección, por tanto de momento basta decir que éste es seguramente el proyecto más implantado y uno de los pilares sobre los que se apoyan las soluciones comerciales.

## 4.2.5 LVS (Linux Virtual Server)

### 4.2.5.1 Introducción

LVS es un proyecto que incluye los programas y documentación necesaria parar montar un cluster de servidores bajo GNU/Linux. El proyecto LVS es utilizado principalmente para aumentar rendimiento y escalabilidad de servicios ofrecidos sobre la red, es ampliamente utilizado por grandes sites como `SouceForge.net` o `Linux.com`.

La principal idea es proveer de un mecanismo de migración de sockets. El mecanismo se basa en utilizar una máquina servidora a la que se dirigen las peticiones de los usuarios clientes. El interfaz público (en Internet) de esta máquina normalmente tiene asociada una dirección conocida como VIP. El cometido de esta primera computadora es direccionar dichas peticiones a otros servidores reales mediante varias técnicas, de este modo los usuarios clientes ven un único servidor. No ostante éste opera con varias máquinas para conceder un servicio único al exterior.

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.

En general se puede considerar LVS como una suma de herramientas que permiten efectuar la función ya especificada. Para cosneguirlo se requiere:

- 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

Ambos constituyen el código principal del proyecto LVS, pero se requieren otras muchas herramientas como ipchains, iptables o Netfilter (dependiendo de la versión del núcleo utilizada ), Ldirectord, Heartbeat, Piranha, MON, LVS-gui, etc.

El Servidor Virtual4.2 requiere de la configuración de todos estos servicios y herramientas para un funcionamiento adecuado, y no solamente del código de LVS. Es más, dentro del tipo de programas que conforman el Servidor Virtual no hay que olvidar los programas o demonios servidores habituales que proveerán realmente de servicio a los clientes finales (HTTPD, FTPD, SMTP, etc.).

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 SWEB4.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.

De esta manera se puede ver que tanto cliente como servidor real trabajan de manera transparente en lo que se refiere al nodo director.

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

Realmente LVS no es un cluster propiamente dicho. Un cluster se suele entender en base a una serie de máquinas que actúan de manera conjunta mediante relaciones entre ellas para resolver un problema (generalmente de cómputo). LVS no es un cluster en este sentido puesto que cada servidor es independiente y solamente está relacionado con los otros mediante un sistema de almacenamiento común4.4, los servidores solamente se relacionan con el nodo director para proveer de un servicio.

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.

### 4.2.5.2 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.24.5 como para las 2.44.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

VS-NAT tiene el mismo problema que los proxys inversos: el nodo director llega a ser un cuello de botella en cuanto las exigencias por parte de los clientes se hacen muy altas, o el número de servidores internos a la red crece por encima de los 20. Es por esto que este tipo de configuración es la menos utilizada de las tres.

VS-TUN

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

El servidor real atiende la petición de servicio y la responde, poniendo como dirección de los paquetes IP generados por este la dirección propia por la que llegó el servicio, es decir la VIP. Los envía directamente al cliente, sin tener que pasar los paquetes por el nodo director de nuevo. De esta manera se evita el problema de cuello de botella en el director.

Figura: Clusters HA. Configuración VS-TUN

Este mecanismo de redirección permite que los servidores reales puedan encontrar se no en una red local, como sucede en el caso de los dos anteriores, sino dispersos en otras redes a las cuales se pueda acceder desde el director, esto supone el poder distribuir los servicios no solo como método de incrementar el rendimiento, sino como distribución geográfica de los servidores, lo cual puede ser una ventaja para ciertos sistemas, o una desventaja para otros.

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

A pesar de ser el más utilizado por ser el que más alto rendimiento ofrece, está limitado en cuestión de escalabilidad debido a que la red sobre la que funciona está limitada a un único segmento ethernet por motivos de direccionamiento mediante ARP. Por otro lado no se necesita tiempo de encapsulación o desencapsulación de ningún tipo y tampoco ningún factor de redirección hacia el nodo servidor. El encaminamiento de los servidores reales a el cliente se puede hacer mediante otra conexión a red de alta velocidad de manera que el ancho de banda este garantizado.

Características generales de los técnicas de balanceo

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 Linux4.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.

### 4.2.5.3 Aspectos Técnicos

La instalación de LVS requiere el conocimiento de cada uno de los elementos que requieren para su funcionamiento correcto (que no son pocos). La instalación o puesta en marcha se puede separar en:

- 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 (firewalls4.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...

Es decir, una carga alta dependiendo de el sistema elegido.

Lo ideal sería utilizar tecnologías rápidas pero baratas como FastEthernet (100 Mbps) y separar en tantas redes como sea necesario para tener los mínimos cuellos de botella posibles y la máxima escalabilidad (en vista al futuro).

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 Heartbeat4.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.

LVS resuelve el problema de la persistencia de manera explícita, es decir, de la manera que el administrador le obligue a hacerlo.

En cualquier caso la configuración, diseño y elección de red dependen de los servicios, situación geográfica, coste y topología. También dependen de la seguridad del sistema. LVS tiene un apartado especial para poder hacer balanceo sobre firewalls, de manera que los firewalls que ejecutan las mismas reglas pueden actuar en paralelo, utilizando de este modo máquinas más baratas para dicha tarea. A parte de este servicio, en un entorno de producción será necesario aislar la red completamente del exterior mediante las reglas adecuadas en los firewalls. La utilización de los nodos diskless, proporciona como se verá más tarde, un mecanismo más sólido para la construcción de nodos.

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

Cuando un cliente quiere realizar una conexión con el director lanza un paquete ARP (o en su defecto lo manda el router, en cualquier caso el problema es el mismo) para saber cual es la dirección MAC del director. Éste hace el reenvió dependiendo del algoritmo de planificación y al mismo tiempo guarda en su tabla el estado de la conexión que se ha realizado.

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 borre4.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 transparente4.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 núcleo del nodo director será el que se encargue de establecer, mediante un algoritmo de balanceo, quien será el servidor real de cierta conexión. Este algoritmo se encuentra como código del núcleo y es elegido antes de compilar el kernel ya sea como modulo o como código interno al kernel.

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.

Todos los paquetes pertenecientes a conexiones realizadas son comprobados en su tabla hash para ver qué servidor real estaba gestionando la transacción y poder enviar los paquetes a dicho servidor. Cada entrada en la tabla hash ocupa 128 bytes y el número máximo de conexiones que el director puede realizar se puede configurar antes de la compilación del kernel, lo cual implica un estudio previo de las conexiones que se estima que se podría realizar al director para poder adecuar este a las necesidades del sistema, proveerlo de suficiente memoria para que no haya problemas con el número de conexiones4.12.

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).

Los dos últimos juegos de algoritmos no serán enunciados, pero sirven para balancear carga entre squid y también para balancear entre varios firewalls. Para más información ver la documentación del kernel parcheado o el HOWTO de LVS.

El algoritmo de Round Robin es el habitual en el mundo de la informática. Es un algoritmo estático y su ampliación a Round Robin con peso solamente implica que a los nodos más potentes se les asigna más cantidad de trabajo que a los menos potentes. En cualquier caso, Round Robin no es un algoritmo óptimo para balancear la carga cuando hay un elevado numero de conexiones.

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:

Tabla: Clusters HA. Resultado de la elección

SERVIDORES | A | B | C
PESOS | 4 | 3 | 2

Tabla: Clusters HA. Disposición de servidores con pesos en LVS
RESULTADO | A | A | B | A B | C | A | B | C |

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 abiertas4.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.

El programa ipvsadm servirá para especificar

- 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

Para configuraciones iniciales o sistemas complejos el script escrito en perl está preparado para varios sistemas operativos del tipo Unix, por lo que puede evitar más de un dolor de cabeza al configurar nuestro sistema. Este script configure obtiene la información de un fichero de texto (las fuentes contienen ejemplos de varios de estos ficheros) y genera otros archivos. Entre estos archivos están el script de inicialización de LVS preparado para ser incluido en la sección de comienzo rc.d, que configura desde las IP de las máquinas que se le pasaron hasta la tabla de rutas, pasando por los interfaces que no deben hacer ARP.

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 LVS4.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.

### 4.2.5.4 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

Tabla: Clusters HA. Relación de tipos de direcciones IP

Dirección IP | Significado
CIP | Dirección del cliente
VIP | Dirección virtual del servicio (en la red del cliente o accesible desde ésta)
DIP | Dirección del director en la red privada de servidores reales
RIPn | Direcció IP del servidor real
DIR-ROUTER | Resto de las direcciones pertenecientes a los routers

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 siguiente4.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.

En este punto es donde es necesario activar forwarding (router) en el director, y aún más, debe estar configurado NAT dinámico para enmascarar todas las respuestas que salen de los servidores reales cuando salen hacia el 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.

En estos pasos no he tenido en cuenta todas las peticiones ARP pertinentes. Estas peticiones pueden parecer que en un principio no tienen ningún efecto, pero uno de los problemas que hemos tenido en la configuración es que la cache de direccionamiento del kernel (así como la de ARP) contenían rutas que estropeaban el direccionamiento. Hemos tenido que limpiar estas caches mediante

`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 para que el LVS funcione de manera correcta, pero se necesitara de más reglas añadidas a ipchains o Netfilter para proveer de un sistema seguro.

- cliente (Redmond95) ip 192.168.10.2/24 sin gateway ni DNS (uno de los problemas es que requería DNS para que funcionase el cliente de HTTP, a pesar de no utilizar en ningún momento nombres simbólicos. No sabemos exáctamente a qué se puede deber esto.)

- servidores reales
  - nodo1 - ip 10.0.0.1/24 rutas a su propia red y gateway por defecto 10.0.0.21
  - nodo2 - ip 10.0.0.2/24 rutas a su propia red y gateway por defecto 10.0.0.21

- nodo director.
  - `ifconfig eth0 10.0.0.21 netmask 255.255.255.0 up ESTA ES LA DIP`
  - `ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up ESTA ES LA VIP`
  - `route add -net 192.168.10.0 netmask 255.255.255.0 dev eth0`
  - `route add -net 10.0.0.0 netmask 255.255.255.0 dev eth0`

- arranque de servicios en nuestro caso etc/init.d/apache start en los dos servidores reales y configuración de telnet en /etc/inetd.conf

- configuración del director:

  - primero hay que configurarlo como router para que haga NAT, es algo necesario, y se puede hacer mediante ipchains (como en nuestro caso) para los nuevos kernels, deben ser compilados sin compatibilidad hacia atrás con ipchains, es decir con iptables/Netfilter, y además no hace falta añadir ninguna regla ya que el soporte propio de NAT esta implementado en el kernel. En nuestro caso:
    - `echo 1>/proc/sys/net/ipv4/ip_forward`
    - `ipchains -A forward -p (UDP/TCP) -i eth0:1 -s localnet [PUERTO] -d 0/0 -j MASQ`

Esta cadena es susceptible de muchos cambios según el servicio que se quiera dar, por otro lado hay que recordar que se procurará que no pasaren los mensajes ICMP, entre ambas redes, así que las comprobaciones de destino (por ejemplo de RIP->CIP, se deberían hacer mediante traceroute). En un entorno de producción, esta cadena debe ser colocada según los requerimie ntos de seguridad del sistema, se debe permitir NAT, pero no descuidar la seguridad del sistema.

- Por otro lado, generalmente (y este ha sido otro problema a descubrir con ETHEREAL y TCPDUMP) los routers tienen habilitado el servicio ICMP-Redirects , que envían paquetes ICMP para que el cliente reenvíe el mismo mensaje a dicha IP. SE DEBE DESHABILITAR ESTE COMPORTAMIENTO, para poder deshabilitarlo, hacemos:
  - `echo 0 /proc/sys/net/ipv4/conf/all/send_redirect`
  - `echo 0 /proc/sys/net/ipv4/conf/eth0/send_redirect`
  - `echo 0 /proc/sys/net/ipv4/conf/default/send_redirect`

Configuración del director con ipvsadm

Con esto queda asegurado el buen funcionamiento NAT del servicio. En este punto es necesario probar el estado de la red de manera que se comporte según se espera, es mejor ver el comportamiento en un caso simple de fallo que en uno complejo, esto se puede probar haciendo un traceroute desde los servidores a el cliente y comprobar que se llega a el en dos saltos.

Una vez comprobado esto, podemos pasar a la configuración del nodo director para que actúe de la forma requerida mediante VS-NAT en un primer caso. Con la orden ipvsadm. Lo más importante es leer el manual de este programa que es realmente simple de configurar. En nuestro caso, hemos configurado los servicios telnet y www para ambos servidores con distintos algoritmos de balanceo.

    Luis:~# ./activa
    Luis:~# chmod 760 config
    Luis:~# ./config
    Luis:~# cat activa
    #!/bin/bash

    echo 1 > /proc/sys/net/ip4/ip_forward
    echo 0 > /proc/sys/net/ip4/conf/all/send_redirects
    echo 0 > /proc/sys/net/ip4/conf/default/send_redirects
    echo 0 > /proc/sys/net/ip4/conf/eth0/send_redirects
    ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up
    ifconfig eth0 10.0.0.21 netmask 255.255.255.0 up
    ipchains -A forward -i eth0:1 -p tcp -s 10.0.0.0/24 -d 0/0 -j MASQ

    Luis:~# cat config
    #!/bin/bash

    ipvsadm -A -t 192.168.10.1:23 -s wrr
    ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.2:23 -m -w 1
    ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.1:23 -m -w 1
    ipvsadm -A -t 192.168.10.1:23 -s wlc
    ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.2:80 -m -w 3
    ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.1:80 -m -w 1

    Luis:~# ipvsadm -L -n
    IP Virtual Server version 1.0.5 (size=4096)
    Prot LocalAddress: Port Scheduler Flags
      -> RemoeAddress:Port               Forward Weight ActiveConn InActConn
     TCP 192.168.10.1:23 wrr
      -> 10.0.0.0.1:23                   Masq    1      0          0
      -> 10.0.0.0.2:23                   Masq    1      0          0
     TCP 192.168.10.1:80 wlc
      -> 10.0.0.0.1:80                   Masq    1      0          0
      -> 10.0.0.0.2:80                   Masq    3      0          0

Con estas líneas queda configurado, podemos ver conexiones y estados mediante varios programas como:

- `ipvsadm -L -n`, muestra el estado de LVS
- `ipchains -L -M`, muestra conexiones enmascaradas
- `netstat -c -M`, muestra estado de conexiones enmascaradas de manera continua

Para hacer la prueba en el cliente, con un navegador conectamos con 192.168.10.1 en unas cuantas ventanas. Como el sistema de ficheros no es compartido en nuestro caso, pudimos ver como en algunas ventanas aparecía la página principal de un servidor y en otros casos (menos cantidad de ellos) la del servidor de menos peso.

Con el caso de `telnet` no sucede lo mismo. Para cada nueva conexión alterna entre uno y otro servidor, propio del algoritmo de RR. Para poder hacer estas comprobaciones hay que deshabilitar la cache del navegador de manera que este realice una nueva conexión cada vez que se haga la petición de la página.

Existen herramientas preparadas para medir el rendimiento del un servidor web, como `polygraph`. Existen diversos programas para probar como es el rendimiento de el servicio de los servidores o hacer un montón de conexiones desde un mismo cliente a nuestro servicio de LVS.

El rendimiento mejoraría seguro si en lugar de configurar nuestros servidores con NAT los configuramos con DR, para lo cual casi no tenemos que tocar nada, solamente deshabilitar NAT añadir interfaces lo con la dirección VIP y configurar un router entre los servidores reales y el cliente externo. En los servidores reales hacer un:

`echo 1 /proc/sys/net/ipv4/conf/lo/hidden`

Para evitar el problema de ARP y configurar el nodo director de la siguiente manera:

`ipvsadm -A -t 192.168.10.1:80 -s wlc`

Crea servicio www asociado a la dirección VIP balanceado mediante weight least-connectios

`ipvsadm -a -t 192.168.10.1:80 -r 10.0.0.1:80 -g -w 1`

Añade servidor a www con peso 1

`ipvsadm -a -t 192.168.10.1:80 -r 10.0.0.2:80 -g -w 3`

Añade servidor a www con peso 3

`ipvsadm -A -t 192.168.10.1:23 -s rr`

`ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.1:23 -g -w 1`

`ipvsadm -a -t 192.168.10.1:23 -r 10.0.0.2:23 -g -w 1`

El parámetro `-g` en la configuración de los clientes implica que la técnica de balanceo sera a traves de gateway, es decir mediante Direct Routing o encaminamiento directo. Solamente con cambiar el modo de encaminamiento en los servidores, que pasa a ser vía gateway (propio de DR), queda todo preparado. Por otro lado en la tabla de rutas de los servidores tiene que estar configurado el encaminador por defecto, y en caso de haber firewall éste debe dejar pasar los paquetes que vayan de VIP-CIP generados por la interfaz virtual de los servidores reales.

Como últimas conclusiones al apartado de configuración de LVS hemos de añadir que en las pruebas realizadas en nuestro caso, mediante la topología y diseño visto arriba sobre un solo tramo Ethernet y con MOSIX instalado y funcionando en los servidores reales (es decir CARLOS y PROG) y la máquina diskless accediendo mediante NFS a todos sus archivos, el rendimiento de la red es pésimo. Se producen colisiones contínuamente, lo que provoca errores y retransmisiones continuas.

Esta continua congestión, debida a que la red sea lenta (10 Mbps), deberá tenerse en cuenta seriamente el diseño de nuestra red al completo para que esta no se convierta en el cuello de botella del sistema.

Los programas sniffers ethereal y tcpdump nos han ayudado a detectar los problemas generados por ARP así como el problema de inconsistencias de la cache o el envío de ICMP_REDIRECTS, que hacían que las primeras pruebas fallasen continuamente. De esta manera, mediante filtros, se traceaba la red con fines de ver cual era el cambio de comportamiento respecto al explicado teóricamente en los apartados anteriores, y adecuarlo a las exigencias del método elegido en LVS.

### 4.2.5.5 ¿Y la alta disponibilidad?

Llegados a este punto, tenemos nuestro servidor LVS funcionando, pero ¿qué sucede en el caso de que uno de los servidores o directores falle? ¿cómo se comporta el sistema?

De la manera que lo tenemos configurado hasta este punto, un fallo en cualquier a de los nodos sería fatídico en el sistema. En el caso de que el fallo estuviese en uno de los nodos servidores, el nodo director intentaría reenviar los paquetes del cliente al servidor, de manera que obtendría fallo después de un tiempo, al estar el nodo o servicio caído.

En el caso del servidor el problema sería aún mayor, ya que produciría la pérdida total del servicio. La intención de cualquier sitio en Internet no es sólo proveer a sus usuarios de servicio durante algún tiempo, el servicio debe estar funcionando en lo que se denomina en el argot técnico-empresarial 24x7, es decir 24 horas al dia 7 días a la semana. Es aquí donde el proyecto LVS deja de manos de otras soluciones el proveer de alta fiabilidad al sistema. En un principio se recomienda utilizar ciertas herramientas con las que se han configurado varios sistemas como pueden ser:

- Piranha
- LVS-GUI + Heartbeat + Ldirectord
- MON + Heartbeat

Pero sirve cualquier otra opción que nos provea de algún método de mantener los servicios proporcionados en alto ante el mayor número de eventos catastróficos.

Nosotros hemos decidido utilizar MON y heartbeat para nuestro sistema, como ejemplo de configuración para cluster de alta fiabilidad HA, en este apartado explicaremos cómo hemos configurado MON y qué es este programa.

Para monitorizar los servidores reales, configuramos MON de la manera que se explicará en el nodo o nodos servidores, de manera que se éste continuamente monitorizando servidores o servicios, para controlar en todo momento el estado del cluster. Para asegurar la continuidad de un nodo servidor en el sistema se puede utilizar también MON, pero es mejor utilizar Heartbeat para hacer la replica de este servidor, y en caso de estar en un entorno de producción utilizar conexiones Ethernet y serial para asegurarnos de que la comunicación entre los directores es continua.

Para controlar la caída de los servidores reales podemos pensar en un principio como solución de aproximación, un programa que haga pings cada cierto intervalo a los servidores y compruebe si éstos están en la red. Este programa lanzaría la ejecución de la orden ipvsadm con los parámetros adecuados para quitar o introducir al servidor en la tabla del nodo director. Otra opción es utilizar el protocolo y sistema de gestión de redes SNMP para comprobar en cada momento mediante peticiones snmpget, sobre la MIB de los agentes (en este caso los servidores) si estos proveen de los recursos necesarios a la red, por ejemplo espacio de disco duro, un proceso servidor, o incluso la carga y funcionamiento de las interfaces. Este sistema es en un principio el más adecuado para la gestión de nuestro cluster, pero tiene ciertas desventajas que evitan que sea utilizado. Entre estas desventajas se pueden contar:

1. Inseguridad en la que esta actualmente SNMP.

   Hasta que no exista implementación en Linux de SNMPv3, ya que el mecanismo de autenticación es algo obsoleto y se necesita de un alto nivel de seguridad para poder correr SNMP en una red privada sin riesgos.

2. Complejidad y carga.

   SNMP permitiría una gestión a niveles muy complejos. Mediante scripts podríamos comprobar a intervalos regulares el estado de los parámetros de la MIB sobre cada servidor, lo que implicaría un modelo de monitorización complejo y adaptable en el sentido de que podríamos requerir mayor cantidad de información que en cualesquiera de los otros métodos, pero implicaría mucha más carga en la red.

   Probablemente la solución está en añadir una nueva red para el apartado de monitorización.

3. Mayor conocimiento y estudio del sistema.

   Lo que supone encarecer el tiempo de creación de este y abaratar luego su mantenimiento.

Existen más puntos a tener en cuenta a la hora de elegir SNMP como método de monitorización. En cualquier caso, el uso de traps de SNMP nos permitiría de manera cómoda establecer mecanismos suficientes como para que el sistema estuviese funcionand o de manera correcta sin ningún problema. Hasta el momento a nadie se ha puesto a diseñar una MIB especial para LVS en los que se pueda manejar los nodos directores de manera remota o incluso la monitorización de los nodos servidores, este sistema en el caso de ser implantado, sería de suma utilidad a la hora de realizar la gestión del cluster de una manera cómoda y sencilla desde otras estaciones y con programas como el HP-OPENVIEW o similares.

El método de utilizar scripts para monitorizar y actuar sobre el sistema es el punto opuesto a la opción SNMP. Tiene como desventajas, que es más lento de desarrollar y cada nueva acción de monitorización puede tener consecuencias colaterales en el sistema, por lo que en muchos casos es necesario realizar un estudio de cómo será la monitorización y comprobar que todos los componentes sean ortogonales entre sí. Como ventaja de este sistema es que es tan adaptable como lo queramos hacer, lo podemos programar en C, C++, Perl o shell scripts si nos apetece, y tan adecuado a nuestro sistema como lo necesitemos, esto es una ventaja y un inconveniente a su vez, ya que será difícil reutilizar el código de un sistema a otro, teniendo por tanto un ciclo de implementación en varios sistemas mucho más largo.

MON

El método que utilizaremos en este caso, es el que provee un paquete que incluye varios programas llamado MON. Este paquete está hecho prácticamente en perl, por lo que deberemos bajar no sólo el paquete MON sino todos los módulos de perl que se requieran para correr el programa.

La solución, MON, es una solución intermedia entre la mastodóntica SNMP y la casera SCRIPT. Es configurable, requiere poco tiempo de puesta a punto, y además también aporta tanta adaptabilidad a nuestras exigencias como nosotros queramos. Este paquete fue escrito por un administrador de sistemas de Transmeta llamado Jim Trocki, la compañía donde trabaja Linus Torvalds, y está prácticamente incluido en la totalidad de las distribuciones que conozco.

MON es un agente de tipo general para monitorizar tanto servicios como servidores y lanzar alertas que pueden ser fácilmente implementadas en C, perl o cualquier otro lenguaje. MON lee de un fichero de configuración su forma de actuación, dicho fichero tiene una forma similar en funcionamiento a SNMP, es una manera muy adaptable de monitorizar cualquier sistema.

En dicho fichero de configuración podemos encontrar las siguientes secciones:

- La primera es la sección hostgroups, que aporta los grupos a los que se realizara la monitorización.

- La segunda es la sección de vistas, que se compone de una o más vistas sobre los grupos de trabajo que contiene las especificaciones de la monitorización y la actuación que se hará acorde con cada evento. En las zonas de vistas se pueden separar en:
  - El servicio a monitorizar, pueden contenerse uno o más servicios en cada vista, de manera que se especifica en ellos.
  - El intervalo de resolución en el que se realizaran los sondeos de las monitoriza ciones.
  - Las traps, interrupciones o señales que se utilizarán.
  - El programa monitor que se utilizará para cada servicio.
  - La dependencia entre servicios y el comportamiento en caso de dependencias
  - El campo periodo que especifica entre qué fechas se realizará la monitorización y de qué manera se procederá en caso de ciertos eventos. Este campo posee a su vez otros campos como pueden ser
    - Periodo real
    - Programa de alerta o control de eventos
    - Varios parámetros para el funcionamiento y control de las alertas

Una vez explicada la estructura del fichero de configuración, pasaremos a explicar cuál es el método de funcionamiento de MON.

MON como ya hemos dicho se compone de un agente planificador que solamente se encarga de interpretar el fichero de configuración y realizar periódicamente y en las horas señaladas las llamadas oportunas a los programas de monitorizaci ón y alerta sobre los nodos perteneciente a un conjunto hostgroup. De esta manera, el programa monitor puede ser implementado por un programador, de manera que este es independiente de MON, mientras que acepte los parámetros que MON le envía y las variables de entorno que adquiere al ser hijo de este.

El programa monitor es llamado periódicamente para cada nodo perteneciente a un grupo de host o host particulares pertenecientes a dicha vista, hace su monitorización específica y da un código en la llamada exit(). Este código debe ser interpretado por la sección de alertas, de manera que se proceda a la ejecución necesaria para el manejo del evento en el caso de que el código de salida del monitor sea el que decide de que manera se controla el evento.

De esta manera, lo único que debe crear el programador son los programas monitor y alerta, donde el programa monitor se encargará de monitorizar los eventos de los que depende nuestro sistema, ya sean estos adquisición en una tarjeta de adquisición de datos como control de un puerto ttySX como el control de acceso a un servidor de un determinado servicio. Además programado mediante el lenguaje que resulte más cómodo al programador, lo que facilita la tarea.

Por otro lado el programa de alerta debe atender a dos tipos de parámetros y variables de entorno pasados por MON. El primer tipo son los códigos de retorno del programa monitor que deberá entender a la perfección para poder ejecutar el manejo del evento que detectase el monitor. El segundo son los parámetros que proporciona MON para el control de caída o puesta a punto de un servicio.

El paquete MON lleva incorporado unos cuantos programas monitores y alertas que se guardan dentro de /usr/lib/mon/, estos programas por defecto suelen bastar para llevar a cabo la monitorización que nosotros necesitamos. Entre estos programas se encuentran los siguientes monitorizadores:

`ftp.monitor` monitor de FTP, comprueba el estado para poder acceder a un servidor FTPD mediante la cuenta que le proporcionemos como parámetro en el fichero de configuración.

`http.monitor` monitor HTTP, igual que el anterior pero para www.

`telnet.monitor` idem que los anteriores.

`smtp.monitor` idem para este otro protocolo.

`dialin.monitor` entradas de llamadas en el modem.

`snmp.monitor` compatible con SNMP, para comprobar el acceso a un agente.

Y muchos otros monitores que permiten monitorizar en general servicios de red mediante programas conocidos como ping, o peticiones a determinada pagina del servidor o a determinado recurso. De esta manera podemos ver el carácter adaptable que posee este tipo de configuración.

Además de los monitores se encuentran los scripts o programas de alerta que funcionan de la misma manera que los monitores, son llamados por MON con determinados parámetros de manera que se actúa acorde con el evento que generó la alerta, subsanando algún problema, guardando en los log que lo provocó, solucionando en la manera de lo posible dicho problema e informando mediante algún método al administrador del sistema, acerca del evento que produjo la llamada. Existen más programas externos que controlan el funcionamiento de MON como son, monshow y mon-cgi, estos permiten ver y controlar desde línea de órdenes o desde un navegador mediante el acceso a una WEB el estado y funcionamiento de MON. En nuestro caso no los hemos probado, ya que la solución que buscábamos no dependía ni requería de este CGI.

Una vez explicado el funcionamiento de MON, debemos explicar qué servicios debemos monitorizar, de qué manera los podemos monitorizar y que medidas debemos tomar ante determinados eventos. Nuestra intención es explicar este apartado utilizando como ejemplo el caso de estudio aportado arriba, de manera que se pueda comprobar como es el funcionamiento de MON y qué factores son importantes a la hora de configurar un sistema de monitorización de este tipo.

Factores que intervienen en la configuración de MON

Para empezar debemos hacer un estudio de ciertos factores que nos pueden interesar y que pueden afectar a nuestro sistema como son.

1. Servicios que poseemos en nuestro cluster.
2. Máquinas dentro del cluster. Es necesario para controlar la resolución de la monitorización, y que la carga de esta no sea demasiado alta.
3. Comportamiento ante caídas.

El apartado de servicios es necesario conocerlo a fondo. Es muy sencillo decir que se necesita un servicio de HTTP, otro de FTP y otro de squid, pero saber los temporizadores de cierre de conexión de dichos servicios no es tan fácil, en cambio seguramente estemos interesados en poder disponer de una monitorización sobre estos servícios.

Pongamos el ejemplo de un servicio de telnet sobre el que se activa algún tipo de envoltura como TCP wrapper, o kerberos. Este telnet tardará algo más en terminar la configuración de la sesión telnet y por tanto el tiempo de establecimiento sera algo más alto. De esta manera cuando un script que intente comprobar el estado de un servidor telnetd y éste tarde más de lo que esperaba (aunque sea tan solamente un segundo), se mandará la alerta apropiada quitando el servicio del LVS, aunque dicho servicio funcione y por tanto se dispondrá de una máquina menos dentro cluster con la que hacer el balanceo. También puede ser necesaria hacer una previsión de cuándo se deben realizar más monitorizaciones sobre un servicio, o las horas a las que no son necesarias hacerlas. Hay que recordar que MON es un programa que corre en el nodo director, y al ser este un punto crítico del sistema es conveniente mantenerlo lo más descargado posible para que se dedique a lo que realmente debe hacer, balancear conexiones y proporcionar servicios.

El apartado de las máquinas que contiene el cluster es necesario para establecer la tasa o intervalo de monitorización. Este intervalo afectará en dos aspectos. El primero es la carga del nodo director donde se ejecuta MON, al estar continuamente lanzando programas monitores y de alerta, el nodo consume recursos como son memoria y CPU, por lo que puede ser un factor importante a tener en cuenta en caso de haber instalado un nodo director inadecuado en requerimientos para dicha labor.

Por otro lado está la carga sobre la red sobre la que tanto estamos hablando a lo largo de todo el proyecto. Mantener la red lo menos congestionada posible es cuestión de cuidar este tipo de apartados y de tener un diseño de red previo adaptado a las necesidades que se preveen para nuestro sistema.

Por último hemos de definir cual será el comportamiento ante caídas. Generalmente en nuestro caso, el comportamiento suele ser algo como, quitar la entrada del nodo director DIRECCIÓN-SERVICIO-PESO, para que dicho nodo no sea tenido en cuenta en las siguientes decisiones del nodo director.

Avisar al administrador mediante cualquier método o recurso, enviando mensajes al móvil o mails a la cuenta del administrador o dando pitidos incesantes para que alguien trate de solucionar el problema lo antes posible. Intentar solucionar el problema desde el nodo director suele requerir de sistemas expertos que evalúen las probabilidades de la causa que provocó la caída e intente solucionarse. Registrar los eventos que sucedieron de manera que se sepa cuales fueron las causas de caída del servicio en cualquier momento.

Se pueden monitorizar en un LVS cualquier tipo de servicios o recursos, desde la accesibilidad a un nodo con fping.monitor hasta el espacio que queda libre en el sistema de almacenamiento distribuido NFS. De manera general, se suele monitorizar como mínimo el acceso a los servidores y el acceso a los servicios.

La utilización del acceso a los servicios es más conveniente que el acceso a caída de un servidor, pero implica más carga de red, por lo que depende, qué método será elegido monitor del sistema. Los programas monitores de un servicio, suelen ser programas que hacen una petición al servicio de carácter general (como pedir la información de versión o página principal de un servidor HTTP), esto conlleva mucha más carga en la red y en el sistema general que un fping destinado a un grupo de hosts, pero por el contrario, si imaginamos una situación muy usual como es la de tener una máquina con varios servicios activados no es difícil entender que puede caer un servicio, y seguir funcionando el otro, y por lo tanto fping dará una monitorización errónea respecto a lo que en un principio requeríamos para el sistema.

### 4.2.5.6 Conclusiones

El servicio ofrecido por la conjunción de LVS, MON y Heartbeat pueden llegar a ser tan potente como otras aplicaciones o configuraciones propietarias que existen en el mercado a un precio mucho mayor. Uno de los problemas que no hemos comentado que tiene LVS de momento es que al caer el nodo director y retomar su trabajo el nodo de backup mediante heartbeat como veremos en el apartado de heartbeat, el contenido de la tabla hash, así como las conexiones y toda la información del nodo director se pierden, esto produce en los clientes que tenían una conexión en curso, la pérdida de dicha conexión.

En un principio y dependiendo de qué servicios puede ser más o menos drástico. La gente del proyecto LVS esta trabajando en mejorar este comportamiento, y se espera que dada la facilidad y adaptabilidad con la que pretende dotar Alan Robertson el proyecto heartbeat, cubrir este problema sea más simple 4.16.