Cluster solutions using tools from linux platforms

Transcripción

1 Serie Científica de la Universidad de las Ciencias Informáticas No. 5, Vol. 4, Año: 2011 ISSN: RNPS: Tipo de artículo: Artículo original Temática: Software libre Recibido: 09/05/2011 Aceptado: 27/05/2011 Publicado: 31/05/2011 Soluciones de clústeres usando herramientas libres sobre plataformas Linux Cluster solutions using tools from linux platforms César Miguel Calvo de la Paz Dirección de Tecnología y Sistemas, Minint, La Habana, Cuba Resumen El problema de la alta disponibilidad en los servicios informáticos siempre ha sido un objetivo de atención para quien administra y gestiona dichos servicios, en la actualidad existen varias soluciones para garantizar alta disponibilidad y servicios de calidad, algunas más efectivas, otras más difíciles de adquirir. El presente trabajo se propone brindar la experiencia adquirida durante el despliegue de soluciones de clústeres de alta disponibilidad y balance de carga usando tecnologías libres sobre plataformas Linux. Mostrando las gran cantidad de opciones que se tienen para lograr alta disponibilidad y balanceo de carga sin costo adicional. Después de haber desplegado las tecnologías que conforman la solución se pudo constatar los beneficios que puede aportar en un entorno de Centro de Datos donde se brinda servicios que no deben tener interrupción. La solución propuesta muestra altos niveles de escalabilidad ajustándose el despliegue final a los medios logísticos, al entorno de despliegue y al servicio a brindar. Es además, una solución gratis y portable, ya que se pueden mezclar diferentes sistemas operativos y arquitecturas para su despliegue. Palabras clave: Clúster, escalabilidad, portabilidad, balance de carga, alta disponibilidad. Abstract The high availability problem in informatics services has always been a target of attention for the administrators of those services, nowadays there are several solutions to provide high availability and services of high quality, some more effective, others more difficult to acquire. The present work is proposed to provide the acquired experience during the deployment of a high availability and load balance cluster solution using technologies from Linux platforms. After have deployed the conforming technologies of the solution we could acknowledge the benefits this solution can provide in a datacenter environment where several services that must remain uninterrupted must be

2 given. The solution shows high levels of scalability, adjusting the final deployment to logistic means, to the deployment environment, and to the service to provide. Is a portable solution because several version of operative systems can be mixed into its deployment. And besides it s free. Keywords: Cluster, scalability, portability, load balance, high availability. 1. Introducción La comunidad de software libre mediante el proyecto Linux-HA 1 cuenta ya con varias herramientas para garantizar alta disponibilidad o balance de carga sobre plataformas Linux. El proyecto Linux-HA ha brindado el mecanismo de Heartbeat 2 que nos permite chequear el estado de una máquina determinada para en caso de fallo, tomar los recursos brindados por la misma y brindarlos desde otro servidor. Esta solución es conocida como clúster de alta disponibilidad. Es una solución fácil de desplegar y muy simple, sin embargo tiene una gran desventaja y es que se desperdician recursos constantemente por que el clúster HA solo habrá un nodo asumiendo la carga del servicio, el otro permanecerá en espera hasta detectar la caída del servicio en el nodo primario para levantarlo localmente y asumir el toda la carga (Dow; Lefevre, 2007). A partir de aquí se ha buscado eliminar los inconvenientes de HA, introduciendo herramientas que permitan hacer un uso activo de los recursos sin comprometer los niveles de alta disponibilidad. En la actualidad existen muchos proyectos relacionados con soluciones de clúster en Linux, siendo uno de los más reconocidos UltraMonkey 3 (Dow; Lefevre, 2007). Sin embargo se puede llegar a implementar el propio clúster combinando alta disponibilidad y balanceo de carga sin necesidad de usar herramientas hechas para fines específicos y de esa forma ajustar la solución al entorno donde se pretenda desplegar. Para lograr esto se propone la configuración de LVS 4 (Axier, 2009) y opcionalmente Heartbeat. Con el uso de LVS se introdujo el balanceo de carga mediante el tratamiento de las conexiones TCP/IP que realiza el Linux-Director, quien actúa más o menos como un router a nivel de aplicaciones, decidiendo que peticiones son enviadas a cada uno de los nodos del clúster. Y con el uso de Heartbeat se garantiza la alta disponibilidad del servicio. 2. Desarrollo 1 Linux-HA: Proyecto de código abierto para proveer un framework de alta disponibilidad a los sistemas operativos Linux. A partir de este proyecto se creó el protocolo Herttbeat. 2 Heartbeat: Componente que se encarga de enviar continuos chequeos hacia una computadora a fin de conocer su estado. 3 UltraMonkey: Proyecyo de software libre orientado al uso conjunto de Linux HA y ldirector. 4 Linux Virtual Server: Proyecto de software libre orientado a garantizar balanceo de carga entre servidores.

3 Para desplegar un clúster HA solo se necesitan 2 servidores que son los que lograrán alta disponibilidad entre ellos, pero primero se hablará sobre el funcionamiento de Heartbeat teóricamente. Heartbeat funciona entre 2 o más máquinas enviando pulsos continuos para conocer el estado del resto de los servidores. Cuando se configura heartbeat, se selecciona un nodo máster que levanta un interfaz de red virtual 5 con el IP del clúster, cuando ese nodo muere, o deja de enviar respuesta a los pulsos recibidos, esa IP virtual es levantada en otro servidor quien se convierte en el nuevo máster. Cada IP virtual es considerada un recurso en un clúster HA. Los recursos son encapsulados como programas que funcionan de manera similar a scripts de Linux/Unix. Es decir que un recurso puede ser iniciado y terminado. Hasta el momento existen 2 formas fundamentales de desplegar heartbeat, la primera que es la forma en la que se despliega por defecto, donde solo se monitorea el estado del servidor. Es decir que si un servidor continúa enviando respuestas a los latidos se considera vivo, aun si el servicio no está corriendo correctamente. El otro método para desplegar HA es usando el modulo crm, que sería desplegar la versión 2 de heartbeat, donde si se monitorea el estado del servicio asociado al recurso brindado por el clúster. Según este método además de los latidos enviados entre servidores se monitorea el estado del servicio de manera que si este se cae, se intenta reiniciar dicho servicio en el nodo máster, y si no es posible, los recursos son pasados a otro nodo (Kay; Robertson, 2006). También existe la solución de HA con monitoreo de servicios usando el paquete mon que corre como un demonio adicional en el nodo y que monitorea el estado de los servicios (Dow; Lefevre, 2007). Figura1. Arquitectura de un clúster HA. En el despliegue de un clúster HA, uno de los servidores es quien responde a las peticiones de los clientes, ese servidor es considerado el nodo máster o nodo primario y es el que posee los recursos del clúster mientras esté vivo. 5 Interfaz de Red Virtual: Número ip que se le configura como alias a una interfaz de red real. Ej. eth0:0 eth0 es la primera interfaz real y tiene su ip, eth0:0 es la ip virtual o ip alias. Una interfaz real puede tener más de un ip virtual.

4 El mecanismo para enviar estos paquetes puede ser mediante un cable punto a punto entre ambos servidores a través de un segunda interfaz de red, o simplemente usando el mismo canal por el que se brinda el servicio. Para la instalación de HA se usa como sistema operativo SLES 10 SP2 x64, heartbeat 2.1.3, que soporta el uso del modulo crm 6 para monitorear el estado de los servicios que componen los recursos La solución de Linux Virtual Server (LVS) es usada para garantizar balanceo de carga ente servidores y funciona principalmente redireccionando las peticiones que recibe el ldirector 7 a cada uno de los servidores reales (RS) basándose en un grupo de parámetros que se configuran de acuerdo a las necesidades del servicio brindado y del entorno donde se desplegará la solución (Axier, 2009). LVS tiene 3 formas de implementarse, LVS-NAT, LVS-DR y LVS-TUN. LVS-NAT: La solución LVS-NAT es la más simple de ejecutar por que requiere muy pocas modificaciones en el ldirector y en los RS. Esta variante de LVS basa su funcionamiento en que el ldirector se usa como puerta de enlace para los RS, y todas las peticiones que llegan al clúster entran y salen a través del ldirector. Esta variante tiene un gran inconveniente y es que el ldirector se convierte en un cuello de botella 8 para el tráfico del clúster. Este tipo de despliegue es útil en pequeños entornos donde el número de conexiones al clúster no es alto y también donde se quiera tener un control estricto sobre las personas que acceden al contenido del servicio brindado ya que todas y cada una de las conexiones entrantes al clúster pasan por el LVS (Axier, 2009). 6 Crm: Módulo que se incorpora con la versión 2.0 de Heartbeat y que se encarga de monitorear los servicios en el servidor máster. 7 ldirector: Componente principal de un clúster LVS. El Linux Director es quien realiza el trabajo de re- direccionar las peticiones a los Real Servers. 8 Cuello de botella: Término generalmente usado para describir un punto de contención por donde debe pasar un gran volumen de datos. Los cuellos de botella impactan negativamente en cualquier despliegue informático.

5 Figura 2. Arquitectura de un clúster LVS-NAT. LVS-DR: LVS-DR es una implementación de LVS más refinada y permite un número de conexiones más alto. El funcionamiento de DR se basa en que cada RS responda de manera directa al cliente que originó la petición. De esta forma solo las peticiones entrantes son las que procesa directamente el ldirector. Para lograr esto, cada RS tiene el mismo VIP 9 que el ldirector, pero se deshabilitan en los RS el funcionamiento de las respuestas ARP, para que no ocurra conflicto IP, así de esa manera cuando llega una petición al VIP, solo el ldirector responde, procesa la petición de acuerdo a los parámetros que se configuren y entrega la petición a uno de los RS para que sea procesada. El RS la procesa y responde directamente al cliente que la generó sin ocurrir conflicto ya que el IP destino de la petición es el mismo (Axier, 2009). 9 VIP: Virtual IP: ES el IP que se le da al clúster. A través de este IP acceden los clientes y es el que se conoce.

6 Figura 3. Arquitectura, despliegue y funcionamiento de un clúster LVS-DR para el servicio Apache. Un detalle importante en el despliegue de un clúster DR es que se debe configurar cada RS para que no responda a las peticiones ARP que genera el switch, ya que si no se logra eso, el clúster se rompería, porque cada RS responde a las peticiones arbitrariamente sin pasar por el ldirector. LVS-TUN: Esta variante de LVS funciona de manera similar a LVS-DR, con la única diferencia que encapsula los paquetes IP en el área de datos de nuevos paquetes IP, cada paquete que es enrutado se encapsula en otro paquete TCP/IP en lugar de modificar la información al paquete inicial. La principal ventaja es que los RS pueden estar en subredes separadas al ldirector.

7 Fig.4). Arquitectura de LVS-TUN Si se usa LVS o HA por separado se ofrecen diferentes tipos de clúster, por una parte balance de carga y por otra, alta disponibilidad, sin embargo si se unen ambas soluciones se puede desplegar un clúster de alta disponibilidad y balance de carga integrado con muy buenos resultados. Muchos despliegues de aplicaciones se configuran usando LVS para balancear la carga y Heartbeat entre los ldirectors para garantizar alta disponibilidad del servicio ldirectord. De esa forma si uno de los RS muere, el ldirector es capaz de detectarlo y direccionar las peticiones al otro servidor que queda vivo, y si el que falla es el ldirector máster, heartbeat detecta el problema y promueve el otro servidor a máster. Como se muestra, en la figura 5 se usan 2 ldirectors para balancear la carga entre los 4 RS, pero realmente es un solo ldirector quien realiza el balanceo de carga entre los RS (Colectivo de autores, 2009). El VIP se mueve entre los 2 servidores LVS de acuerdo a la disponibilidad de los mismos, que es definida por Heartbeat. En este punto cabe destacar que la configuración mostrada en la figura 5 es las más óptima, ya que solamente con 2 LVS es suficiente, porque si se incrementa a más de 2 el número de ldirectors se estaría acentuando la desventaja principal de Heartbeat donde se desperdician los recursos, ya que solo 1 LVS hace el trabajo, el resto estará en espera a que falle el LVS máster para asumir los recursos y continuar brindando el servicio de balanceo de carga.

8 Fig.5). Despliegue de un clúster Heartbeat y LVS para garantizar alta disponibilidad y balance de carga. ESCENARIOS DONDE SE PUEDE APLICAR ESTAS HERRAMIENTAS PARA GARANTIZAR ALTA DISPONIBILIDAD O BALANCEO DE CARGA El mecanismo que usa LVS para garantizar el balanceo de carga transparente es mediante pares de chequeo-respuesta, donde se chequea cada RS de manera diferente en dependencia del servicio que brinda y se compara el resultado de la consulta con un resultado esperado a fin de detectar el estado del servicio en ese RS. Algunos de los servicios que se pueden desplegar usando un clúster LVS son: dns, ftp, http, https, imap, imaps, ldap, mysql, oracle, pgsql, radius, smtp, etc. Para cada uno de estos servicios el tipo de chequeo varía. DNS: El chequeo consiste en el nombre de un registro A MySQL, Oracle, PostgreSQL: El chequeo consiste en una consulta SELECT y solo se analiza que la respuesta sea una o más filas, no el dato en sí. FTP: El chequeo se realiza usando la clausula login y password para conectarse. El resto de los servicios que requieren autenticación también usan estas clausulas o las credenciales por defecto.

9 En el caso de Heartbeat es más amplio aún el espectro donde se puede aplicar la solución. Si se atiende al funcionamiento de Heartbeat se verá que su sencillez lo hace muy fácil de aplicar sin mucho esfuerzo, llegando incluso a monitorear el estado del servicio de cada nodo en cada latido (Kay; Robertson, 2006). Teóricamente es posible desplegar Heartbeat y garantizar alta disponibilidad para cualquier servicio que funcione sobre Linux. En ocasiones no se cuenta con los medios logísticos para llevar a cabo estas soluciones porque no se tienen los servidores que harían falta para tener un clúster HA, o una máquina destinada solamente a fungir como LVS. Sin embargo si se cuenta con una Infraestructura Virtual 10 funcional, ya sea mediante el uso de VMware ESX Server o Citrix XenServer o cualquier otro proveedor o plataforma, se tendría un grupo de opciones de despliegue enorme haciendo uso de la virtualización. A continuación se mostrarán algunas posibles arquitecturas donde se podría usar HA y LVS. Fig. 6). Despliegue de un sistema de clúster usando 2 servidores reales físicos y un balanceador de carga LVS virtual. En la figura no se provee alta disponibilidad para el LVS usando Heartbeat por que el servicio LVS se brinda a través de una VM 11 que se beneficia de las tecnologías que brinda VMware para balance de carga ya alta disponibilidad usando los clúster DRS y HA 12 respectivamente. Como se ve la complementación de ambas soluciones puede brindar un muy buen nivel de disponibilidad y calidad de servicio con un gasto moderado de recursos y sin desperdiciar capacidad computacional. 10 Infraestructura Virtual: Componente de software que es capaz de virtualizar sistemas operativos como si fueran máquinas reales. Existen varios competidores entre los cuales VMware se destaca como pionero y principal productor de software. 11 VM: Máquina Virtual. 12 DRS y HA: Sistema de clúster que provee la Infraestructura Virtual de VMware. Distributed Resource Schedule se usa para balancear la carga de VMs entre servidores ESX, y High Availability para que ante un fallo inesperado de un ESX, las VMs afectadas se restauren en otro servidor del clúster.

10 Fig.7). Despliegue de un sistema de clúster HA usando un servidor virtual como respaldo de un servicio http desplegado en un servidor físico (Ultramonkey Project, 2006). El ejemplo desplegado en la figura 7 es una buena forma de usar el clúster HA, porque se estaría minimizando el mayor inconveniente que tiene dicho clúster, que es el desperdicio de recursos computacionales. Al ser una VM la que se usa como respaldo, no hay desperdicio de recursos computacionales, pues la Infraestructura Virtual es capaz de no asignar recursos si no son solicitados por la VM, lo que significa que al Web Server Backup no le será asignados todos los recursos con los que inicialmente se configuró. Es conocido que las VMs según la concepción de VMware ESX Server, mientras no estén usando los recursos que le han sido asignados los delegan a otras VMs que los necesiten. Es por esto que el ejemplo mostrado es una buena variante para garantizar alta disponibilidad de un servicio con poco gasto de recursos. 3. Conclusiones Finalmente se puede concluir que las herramientas existentes en las plataformas Linux brindan un gran número de opciones para llevar a cabo despliegues de servicios con altos niveles de disponibilidad y calidad. El despliegue de cada uno de estos clúster por separado es una tarea simple y muy bien documentada, lo que hace de estas soluciones una herramienta muy útil en manos de un especialista, más aún si el ambiente de despliegue es propicio para su despliegue conjunto. Nótese que no se abordan detalles sobre configuraciones y parámetros específicos de cada una de las soluciones, y se hace de manera intencional, ya que el objetivo principal que se ha seguido durante el documento es el de mostrar la facilidades y ventajas que brinda cada una de las soluciones por separado e integradas.

11 Referencias - AXIER. Squid alta disponibilidad, LVS + Heartbeat COLECTIVO DE AUTORES. OPENSOURCEPROJECT.org.cn. LVS Persistence html - ELI M. DOW, FRANK LEFEVRE. Set up a Web server cluster in 5 easy steps LORN KAY, ALAN ROBERTSON, 40. LVS: Director failover using heartbeat ULTRAMONKEY PROJECT