 |
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).
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:
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.
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.
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.
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.
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.
Referido a cómo de fácil es controlar los servicios del sistema y qué servicios se proveen, incluyendo todos los componentes del 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.
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:
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.
Es igual que la anterior pero se tienen N equipos para ofrecer un mismo servicio, con lo cual presenta más tolerancia a fallos.
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:
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.
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.
Esta es una solución mucho más elegante y más difícil de implementar. Presenta mejor rendimiento coste que la anterior.
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:
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.
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:
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:
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:
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.
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.
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.
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.
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.
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:
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:
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).
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
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.
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:
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.
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.
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:
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:
El manejo de esta persistencia es realmente sencillo.
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.
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.
El director hace lo siguiente:
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.
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:
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
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.
(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.
|
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:
Quizá la explicación sea algo liosa así que pongo un dibujo y explicación por puntos.
VIP
RIP (paquete replica de el anterior CIP-VIP).
CIP a su gateway
por defecto, es decir en nodo director DIP.
CIP a VIP-CIP
y se lo envía al cliente.
echo 0 /proc/sys/net/ipv4/route/flush
para limpiar las rutas, que ha sido lo que más ha molestado.
Para configurar esta red arrancamos el servidor que baja su kernel por bootp/tftp y configura su directorio raíz con nfsroot, una vez que tenemos todos los ordenadores encendidos.
Configuración del sistema, relativa a IP's y tablas de rutas
En esta explicación por puntos de las pautas seguidas para configurar de forma manual el sistema no entraremos en detalles en lo que se refiere a conceptos o configuración de NAT o ipchains, aunque se requiere un conocimiento mínimo de ambos para poder configurar el sistema. De hecho, en este caso de estudio se dará una configuración mínima 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.
etc/init.d/apache start
en los dos servidores reales y configuración de telnet en /etc/inetd.conf
/proc/sys/net/ipv4/conf/all/send_redirect
/proc/sys/net/ipv4/conf/eth0/send_redirect
/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:
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.
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:
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:
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.
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.
Lo que supone encarecer el tiempo de creación de este y abaratar luego su mantenimiento.
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:
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.
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.
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.
