Arquitecturas de Clustering de Alta Disponibilidad y Escalabilidad (Linux Virtual Server), ACADE (LVS)

Transcripción

1 Ingeniería Técnica de Telecomunicaciones: Especialidad Telemática Proyecto Final de Carrera Arquitecturas de Clustering de Alta Disponibilidad y Escalabilidad (Linux Virtual Server), ACADE (LVS) Marcos Martínez Jiménez <marcos_martinez@wanadoo.es> Gabriel Bergés Pujol <gabb@menta.net> V1.0.1 Marzo 2003

2 Prefacio Prefacio Estructura y contenido de la memoria La memoria del proyecto ACADE (LVS) se estructura en tres bloques y el anexo. Los tres bloques o partes son: Parte 1: Conceptos teóricos fundamentales Parte 2: Software libre para Arquitecturas de Clustering de Alta Disponibilidad y Escalabilidad (ACADE). Parte 3: Cluster Acade (LVS). Descripción, funcionamiento y pruebas efectuadas. La primera parte recoge definiciones y aspectos teóricos básicos sobre balanceadores de carga, clusters y otros temas importantes relacionados con el proyecto. Para ampliar los conocimientos teoricos de esta parte ver [0]. Uno de los objetivos principales a la hora de iniciar el proyecto ACADE era el de ir más allá del mero estudio teórico e implementar un cluster de alta disponibilidad y escalabilidad que permitiera profundizar, mediante la experimentación, en todos los aspectos de este tipo de arquitecturas. Se montó un cluster activo/pasivo de balanceadores de carga (LVS) al que se nombró Acade, utilizando para ello software libre. La segunda parte hace un recorrido por las diferentes soluciones software disponibles para implementar arquitecturas de clustering de alta disponibilidad sobre plataformas libres, centrándose especialmente en aquellas soluciones que han formado parte del cluster Acade. El tercer apartado describe el funcionamiento del cluster Acade, detallando su topología, y el funcionamiento e interrelación de todos los elementos software utilizados.. Las descripciones se acompañan con capturas de pantalla, que ayudan a entender el comportamiento del software. Finalmente, el anexo reúne toda la documentación complementaria al proyecto. El apartado más importante del mismo es el Manual Acade (LVS) el cual se crea a partir de

3 Prefacio una serie de documentación propia de trabajo, generada durante el montaje del cluster Acade. El propósito del manual es facilitar el montaje de una arquitectura similar a la del proyecto ACADE, a cualquiera que pudiera estar interesado en ello. Convenciones utilizadas. Con el fin de facilitar una lectura clara y concisa, que ayude a una mejor comprensión de los conceptos expuestos en esta memoria, se han utilizado las siguientes convenciones tipográficas. Cursiva Las fuentes en cursiva se han utilizado para nombres de programas, términos técnicos en inglés, para fragmentos de texto importados de otros documentos o URLs. Además, estas últimas aparecen entre los símbolos <>. Monoespaciada Los caracteres monoespaciados son utilizados para comandos, variables de entrono, direcciones IP y MAC, números y nombres de puertos, nombres de máquinas, nombres de dispositivos y fragmentos de código. Negrita Utilizada para resaltar o remarcar palabras y determinados conceptos importantes. Fondo Gris Es usado para resaltar texto cuando éste representa la captura de la salida estándar de un programa, en ejemplos de comandos de la shell o para mostrar el código fuente de un programa. [Referencias bibliográficas]:

4 Prefacio En ocasiones, a fin de invitar al lector a ampliar determinados conocimientos, o bien para referenciar el origen de determinada información, se han utilizado referencias a la bibliografía que se recoge en la bibliografía situada al final de esta memoria. (Referencias internas) Para referenciar apartados expuestos en otras partes de la memoria, se indicará entre paréntesis el número del mismo. Por ejemplo (12.4) o así (anexo IV).

5

6 ÍNDICE I Índice 1. INTRODUCCIÓN DEFINICIONES Clustering Alta disponibilidad Alta escalabilidad... 2 Parte 1: Conceptos teóricos fundamentales 2. OBJETIVOS INICIALES DEL PROYECTO ACADE BALANCEADORES DE CARGA INTRODUCCIÓN DEFINICIÓN MEJORAS QUE APORTA EL BALANCEADOR DE CARGA Escalabilidad Disponibilidad Gestión y flexibilidad en el mantenimiento Seguridad Calidad de servicio (QoS) TIPOS MÉTODOS DE DISTRIBUCIÓN DE CARGA Stateless Stateful Algoritmos de Scheduling (Hashing) MONITORIZACIÓN DE LOS SERVIDORES Sistemas in-band Sistemas out-band Métodos para monitorizar la salud del servidor (Health Checks) MÉTODOS DE REENVÍO Network Address Translation (NAT) Direct Server Return (DSR) PERSISTENCIA DE SESIÓN Tipos de persistencia de sesión Métodos de persistencia basados en IP origen Métodos basados en la aplicación BALANCEADORES DE CARGA DE ALTA DISPONIBILIDAD CLUSTERING Y BASES DE DATOS... 39

7 ÍNDICE II Parte 2: Software libre para Arquitecturas de Clustering de Alta Disponibilidad y Escalabilidad (ACADE). 5. EL SOFTWARE LIBRE COMO MOTOR DE DESARROLLO SOCIAL BALANCEADORES DE CARGA LIBRES LINUX VIRTUAL SERVER PROJECT QUÉ ES LVS? LVS, IP Virtual Server (IPVS) MÉTODOS DE REENVÍO SOPORTADOS POR LVS LVS-NAT LVS-DR LVS-Tun El problema con el Protocolo de Resolución de Direcciones (ARP) PERSISTENCIA EN LVS FIREWALL MARKS ALGORITMOS DE SCHEDULING IMPLEMENTADOS POR LVS IPVSADM LVS, KERNEL TCP VIRTUAL SERVER (KTCPVS) DIRECT ROUTED WEB SWITCH (DRWS) HIGH UP TIME PROJECT (HUT) CLUSTER ACTIVO/PASIVO CON LVS HEARTBEAT FAKE LINUX DIRECTOR DAEMON LDIRECTORD SERCICE MONITORING DAEMON, MON SOFTWARE DE SERVIDOR APACHE PHP MYSQL DATABASE SERVER PROFTPD

8 ÍNDICE III Parte 3: Cluster Acade (LVS). Descripción, funcionamiento y pruebas efectuadas 9. CLUSTER ACADE (LVS) QUÉ ES EL CLUSTER ACADE (LVS)? COMPONENTES SOFTWARE UTILIZADOS (LVS+HEARTBEAT+LDIRECTORD) SERVICIOS OFRECIDOS TOPOLOGÍA FÍSICA DEL CLUSTER ACADE TOPOLOGÍA LÓGICA DEL CLUSTER ACADE FUNCIONAMIENTO E INTERRELACIÓN DE LOS DIFERENTES ELEMENTOS SOFTWARE DE ACADE Software utilizado en los balanceadores de carga Software utilizado en los Servidores Reales PRUEBAS REALIZADAS Balanceo de carga Persistencia de sesión Monitorización de contenidos Alta disponibilidad del balanceador de carga CONCLUSIONES Y VALORACIONES LIMITACIONES Y ASPECTOS POR DESARROLLAR EN ACADE Aspectos por desarrollar: LVS-DR y LVS-Tun Limitaciones de este modelo: Bases de Datos CONCLUSIÓN FINAL

9 ÍNDICE IV Índice de figuras FIGURA 1: UBICACIÓN DEL BALANCEADOR DE CARGA... 6 FIGURA 2: ESTABLECIMIENTO DE CONEXIÓN TCP FIGURA 3: DESTINATION NAT FIGURA 4: SOURCE NAT FIGURA 5: NECESIDAD DE PERSISTENCIA EN APLICACIONES TRANSACCIONALES FIGURA 6: MEGAPROXY PROBLEM, CASO FIGURA 7: MEGAPROXY PROBLEM, CASO FIGURA 8: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/PASIVO FIGURA 9: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/ACTIVO FIGURA 10: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/ACTIVO OPTIMIZADO FIGURA 11: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/ACTIVO OPTIMIZADO FIGURA 12: CLUSTERING Y BASES DE DATOS FIGURA 13: LVS-NAT FIGURA 14: TOPOLOGÍA LVS-DR FIGURA 15: LARS METHOD FIGURA 16: MONITORIZACIÓN MEDIANTE LATIDOS FIGURA 17: TAKEOVER MEDIANTE EL ENVÍO DE GRATUITOUS ARP FIGURA 18: CLUSTER ACADE EN ACCIÓN FIGURA 19: CLUSTER ACADE FIGURA 20: TAKEOVER EN ACADE FIGURA 21: ESQUEMA SOFTWARE ACADE (LVS) FIGURA 22: EJEMPLO DE ACCESO AL SERVICIO WEB DEL CLUSTER ACADE FIGURA 23: EJEMPLO DE ACCESO AL SERVICIO FTP VIA WEB DEL CLUSTER ACADE Contenido de los anexos Anexo I Listado de sitios web que implementan soluciones basadas en LVS Anexo II Manual de ipvsadm Anexo III Archivos y scripts de configuración principales de los LVS del cluster Acade Anexo IV Esquema y código SQL de la base de datos documentacion Anexo V Manual Acade Anexo VI Código PHP del sitio web (en el CD-ROM 2) Anexo VII Análisis empírico del funcionamiento de la pila TCP/IP en kernels Linux 2.4.x Anexo VIII Software necesario para implementar el cluster Acade (en el CD-ROM 1 y 2)

10 ACADE (LVS) Introducción Alta disponibilidad (HA) y alta escalabilidad son tecnologías emergentes. Éstas están cimentadas sobre la base de soluciones propietarias, en su mayoría ligadas habitualmente a costosas arquitecturas hardware. Linux HA Project es el encargado de aunar los esfuerzos de la comunidad libre para hacer de Linux una excelente plataforma sobre la cual ofrecer servicios de HA y escalabilidad. HA permite la prestación permanente de servicios 24/7/365 demandados por la creciente globalización del mundo empresarial. A su vez, la persistente necesidad de mantener la competitividad de las empresas, requiere escalabilidad en las soluciones hardware adoptadas para que sean capaces de amoldarse al dinamismo del mercado. Desde el entorno del software libre, se están generando soluciones a necesidades hasta ahora sólo cubiertas por soluciones basadas en software propietario y hardware específico. En este sentido, Linux Virtual Server (LVS) es la principal apuesta de dicho entorno. LVS y un conjunto de aplicaciones software asociadas, han alcanzado la madurez suficiente para seducir a los principales distribuidores de sistemas Linux como RedHat, Turbolinux y SuSE. Éste último como principal representante del consorcio UnitedLinux, llamado a ser el estándar con el que vestir al hardware de los principales fabricantes. AMD, Computer Associates, Fujitsu Siemens, Hewlett-Packard, IBM, Intel, NEC y demás, ya le han mostrado su soporte. Incluso el principal contrincante de UnitedLinux, RedHat, ha adoptado LVS. Mención especial requiere el caso de la escalabilidad, puesto que las soluciones basadas en el binomio software libre y hardware no específico aportan facilidad para la migración a sistemas o plataformas hardware de otros fabricantes. No sucede así con las soluciones hardware/software propietarias, las cuales obligan a grandes desembolsos tanto iniciales como en posteriores ampliaciones.

11 2 - Capítulo 1: Introducción 1.1 Definiciones Clustering En el ámbito telemático, un cluster es una agrupación de máquinas que, trabajando coordinadamente, resuelven un determinado problema o prestan un determinado servicio conjuntamente. Dado que el termino clustering es en si mismo algo confuso, utilizamos otros términos como por ejemplo, balanceador de carga, IP failover, Beowulf o MOSIX para describir implementaciones específicas de un tipo de cluster. Por ejemplo, los clusters Beowulf se diseñan para proporcionar alta capacidad de procesamiento paralelo y escalabilidad. Por otro lado, las soluciones de clustering de alta disponibilidad se diseñan con el fin de proporcionar la alta disponibilidad de un servicio o aplicación de red Alta disponibilidad Puede entenderse como alta disponibilidad de un servicio o aplicación de red, el hecho de prestarlo ininterrumpidamente y con relativa independencia del hardware que lo sustenta. Se consigue alta disponibilidad redundando los sistemas, como por ejemplo implementando algún tipo de arquitectura de clustering Alta escalabilidad Un sistema altamente escalable es aquel que ha sido concebido para amoldarse en todo momento, y con el mínimo coste, a unas necesidades que pueden ser cambiantes. La modularidad es un elemento básico para lograr la alta escalabilidad, permitiendo el crecimiento de la capacidad del servicio al añadir más nodos al cluster. Por su parte, un sistema no escalable requeriría renovar por completo la arquitectura que estuviera actualmente en uso.

12 ACADE (LVS) - 3 Parte 1: Conceptos teóricos fundamentales 2. Objetivos iniciales del proyecto ACADE El objetivo principal del proyecto ACADE era el de permitir a sus autores adentrarse en el mundo de las arquitecturas de clustering de alta disponibilidad y escalabilidad existentes en Linux. Dado que el proyecto se ha desarrollado en pareja, se valoró que se contaba con recursos humanos suficientes para no quedarse en el mero estudio teórico. Por ello, se decidió construir un cluster de alta disponibilidad y escalabilidad que permitiera profundizar, mediante la experimentación, en todos los aspectos de este tipo de arquitecturas. Se montó un cluster activo/pasivo de balanceadores de carga (LVS) al que se nombró Acade, utilizando para este fin únicamente software libre. Se pensó que llegar a ofrecer contenido web dinámico a través del cluster, implicaría haber alcanzado, con hechos tangibles, los objetivos iniciales del proyecto.

13 4 - Capítulo 2: Objetivos Iniciales del Proyecto ACADE

14 ACADE (LVS) Balanceadores de carga 3.1 Introducción Normalmente, un servicio de red funciona de la siguiente manera: los clientes solicitantes del servicio dirigen sus peticiones a un servidor. Éste responde ofreciéndoles el servicio solicitado en función de la petición. Las limitaciones de este modelo son dos: por un lado la disponibilidad del servicio, que está ligada al correcto funcionamiento de un único sistema servidor, y por otro el límite en la capacidad para atender, procesar y servir peticiones del mismo. Para ampliar la capacidad del servicio, hay dos opciones: o bien reemplazar el servidor por otro de mayores prestaciones, o bien añadir más servidores. En caso de optar por la segunda opción y dado que este cambio ha de ser transparente a los clientes, será necesario seguir ofreciendo el servicio sin variar el escenario anterior, es decir, manteniendo la dirección IP a la que los clientes dirigían sus peticiones (IP Virtual o VIP). A este tipo de arquitectura se la conoce con el nombre de servidor virtual, cuyo dispositivo clave para ser implementada con éxito es el balanceador de carga. Nótese que, mediante un cluster de alta disponibilidad activo/pasivo (3.9 y 7), también se consigue un servidor virtual, si bien este no ofrece un sistema escalable como el ofrecido por un balanceador de carga. 3.2 Definición El balanceador de carga es el dispositivo de red que se ubica entre los clientes y los servidores (figura 1), centralizando la recepción de peticiones. El balanceador de carga se limitará a reenviar las peticiones a los servidores reales, que son los encargados de procesarlas, incrementando de esta manera la capacidad de procesado de peticiones que tenía el antiguo sistema, basado es un solo servidor. El balanceador de carga toma las decisiones de reenvío de peticiones en función de un algoritmo de scheduling determinado. El método de reenvío puede implementarse de varias formas, en función de la arquitectura de red disponible para comunicar a los servidores reales con el balanceador de carga.

15 6 - Capítulo 3: Balanceadores de carga Red Cliente Balanceador de carga Figura 1: Ubicación del balanceador de carga. Servidor Virtual Servidores Reales 3.3 Mejoras que aporta el balanceador de carga El hecho de distribuir el trabajo entre diferentes máquinas permite que la capacidad de carga del servidor virtual sea muy superior a la que tendría un solo servidor real. Además, el balanceador de carga aporta escalabilidad, disponibilidad, facilidad de mantenimiento, seguridad y calidad de servicio Escalabilidad Si la demanda de un servicio es muy elevada, se puede incrementar el número de servidores reales que prestan dicho servicio, de esta manera, con sólo aumentar el número de servidores reales, se aumenta el número de conexiones que puede atender el servidor virtual. El balanceador de carga distribuye las peticiones de los clientes entre todos los servidores reales disponibles, usando para ello algoritmos de distribución de la carga, que permiten aumentar la capacidad de proceso que tendría un solo servidor. Suponiendo un balanceo perfecto, la capacidad del servidor virtual equivaldría a la suma de las capacidades de cada

16 ACADE (LVS) - 7 uno de los servidores reales por separado, pero en términos reales la capacidad del servidor virtual ronda entre el 80% y el 90% Disponibilidad La máquina encargada de balancear la carga hace un chequeo continuo de los servidores reales así como de las aplicaciones que corren en ellos. En caso de que un servidor real o una aplicación dejen de responder, el balanceador ya no le reenviará más peticiones hasta que el servicio esté disponible de nuevo. De esta forma, de cara al usuario final (cliente), el servicio ofrecido por el servidor virtual estará siempre disponible, incluso en el caso de que alguno de los servidores reales deje de prestar servicio. Si el sistema no dispone de los mecanismos necesarios, las conexiones que en ese momento tenía el servidor real fallido se perderán. En este sentido, el balanceador de carga hace automáticamente y con transparencia lo mismo que se haría manualmente, mediante configuraciones estáticas del balanceador de carga, pero disminuyendo notablemente los tiempos de respuesta ya que no se requiere de intervención humana para reconfigurar el balanceador Gestión y flexibilidad en el mantenimiento Si se necesita apagar algún servidor real o detener un servicio, debido a un cambio de hardware o a una actualización del software, el uso de un balanceador de carga permite hacerlo de forma controlada, en el sentido de que se dejan de reenviar las peticiones de los clientes a dicho servidor. De esta forma, es posible proceder a realizar las tareas de mantenimiento sin afectar a la disponibilidad del servicio. El proceso es totalmente transparente para los clientes, ya que siempre encontrarán disponibilidad del servicio en la IP habitual (VIP). El balanceador de carga aporta flexibilidad en la gestión del servidor virtual porque posibilita cambiar los servicios que está ofreciendo cada uno de los servidores reales en función de las necesidades de cada momento.

17 8 - Capítulo 3: Balanceadores de carga Los balanceadores de carga permiten redireccionar las peticiones a los servidores reales con independencia del sistema operativo que éstos últimos ejecuten. Este hecho permite mezclar diferentes plataformas en un mismo servidor virtual Seguridad Los balanceadores de carga se encuentran entre los clientes y los servidores reales, pudiendo actuar como filtro ante posibles ataques. Adicionalmente, el uso de NAT incrementa la seguridad debido al hecho de que las direcciones IP privadas de los servidores reales no son alcanzables directamente desde Internet. Los clientes únicamente ven la VIP que proporciona el balanceador, en cuyo interior se aplicarán las reglas de filtrado Calidad de servicio (QoS) Los balanceadores de carga pueden ser usados para distinguir diferentes tipos de clientes y servicios, permitiendo de este modo la implementación de políticas de calidad de servicio (QoS). Los clientes o servicios preferentes pueden disponer de: servicios ofrecidos por un servidor en particular, mayor prioridad de sus paquetes IP y una determinada calidad de servicio o ancho de banda. 3.4 Tipos Los balanceadores de carga se pueden clasificar dentro de 4 grandes grupos: los balanceadores de carga para servidores (server load balancing), los balanceadores de carga para firewalls (firewall load balancing), los balanceadores de caches (cache load balancing) y los balanceadores de carga entre sistemas servidores remotos (global server load balancing).

18 ACADE (LVS) - 9 server load balancing: Reparten la carga entre un grupo de servidores aumentando la capacidad del sistema. Solucionan el problema de la caída de un servidor y aumentan la escalabilidad del sistema. firewall load balancing: Reparten la carga entre un grupo de firewalls. Aumentan la capacidad y escalabilidad del sistema. cache load balancing: Descargan de trabajo a los servidores web al redireccionar las peticiones a sistemas de cache. global server load balancing: Permiten redireccionar las peticiones de los clientes hacia el servidor o centro de datos más idóneo para estos, mejorando los tiempos de respuesta y la calidad del servicio. La idoneidad del servidor elegido puede realizarse en función de la distancia (un servidor por país o región), o en base a otros factores como el tráfico, calidad del enlace, etc. Esta memoria se centra en los balanceadores del primer tipo (server load balancing), aunque también se tratan, en algunos casos, los balanceadores de carga globales entre sistemas remotos (6.3.3). 3.5 Métodos de distribución de carga Por método de distribución de carga, se entiende la manera en la que el balanceador toma la decisión de a qué servidor, dentro de la granja de servidores, asignar una conexión. El balanceo de carga puede realizarse de dos formas: stateless o stateful. Un balanceo de carga que utilice un algoritmo que simplemente distribuya el tráfico a un determinado servidor, sin tener en cuenta el estado de la información de cada sesión, es denominado stateless load balancing. Por el contrario, el balanceador que tiene en cuenta el estado de cada una de las sesiones, para tomar la decisión de a qué servidor dirigirlas, se denomina stateful load balancing. Independientemente de si el balanceador es stateful o stateless, éste utilizará un método de distribución que le ha de permitir determinar qué cantidad máxima de tráfico puede asignar a cada servidor. El objetivo es intentar realizar un reparto equitativo del tráfico en función

19 10 - Capítulo 3: Balanceadores de carga de las capacidades de cada servidor, ya que es posible que dentro de la granja de servidores no todos los equipos tengan las mismas prestaciones. Se puede clasificar el tráfico de red como TCP, UDP o simplemente IP. Un balanceador de carga capaz de identificar el tráfico como TCP o UDP, podrá también identificar las sesiones TCP o UDP en base al los puertos y direcciones IP origen/destino. El protocolo TCP es orientado a conexión. Las sesiones se establecen y finalizan mediante el intercambio de una serie de órdenes predeterminadas por el protocolo TCP. El balanceador puede entender o no este diálogo y utilizarlo para determinar el inicio y finalización de sesiones. Cliente Servidor Env ío SYN(SEQ=x ) SYN Recepción ACK SYN(SEQ=y, ACK=x ) Env ío ACK(SEQ= y +1) ACK SYN ACK Recepción SYN(SEQ=x ) Env ío ACK SYN(SEQ=y, ACK=x +1) Establecimiento de conexión TCP (Inicio de Sesión) three-w ay handshake Recepción ACK(SEQ= y +1) Intercambio de Datos Env ío FIN(SEQ=n) FIN Recepción ACK FIN(ACK=n+1) ACK FIN Recepción FIN(SEQ=n) Env ío ACK FIN(ACK=n+1) Finalización de sesión TCP Figura 2: Establecimiento de conexión TCP. Tanto el tráfico TCP como UDP funciona sobre IP. Por el contrario, algunos protocolos propietarios sólo pueden correr directamente sobre IP, en estos casos, el balanceador sólo podrá determinar las sesiones en base a las direcciones IP origen y destino Stateless Un balanceador de tipo stateless no puede determinar el inicio y fin de sesiones. UDP es un protocolo stateless, dado que no es orientado a conexión. Por el contrario, existen determinados servicios que requieren que todos los paquetes pertenecientes a una sesión

20 ACADE (LVS) - 11 UDP, sean enviados al mismo servidor real. Por ejemplo, en aquellos servicios en los que se requiere que se establezcan dos conexiones, una TCP y otra UDP, es requisito indispensable que los paquetes UDP se envíen siempre al mismo servidor real en el que se ha establecido la conexión TCP. En estos casos, dado que el balanceador identifica la sesión UDP únicamente en base a las direcciones IP y puertos origen/destino, el balanceador crea una regla, que lo configura dinámicamente para reenviar siempre al mismo servidor real los paquetes pertenecientes a esa sesión. Esta regla desaparece automáticamente, si durante un periodo predeterminado de tiempo no se recibe otro paquete que case con ella. La principal ventaja del balanceador de tipo stateless es la simplicidad de los algoritmos de scheduling utilizados para tomar la decisión de a qué servidor reenviar los paquetes. El hecho de que el balanceador stateless tenga menos elementos en los que basarse para la toma de decisiones de reenvío, repercute en un algoritmo de scheduling más sencillo y por tanto en menores requerimientos para su procesado Stateful El balanceo de carga stateful requiere que el balanceador sepa reconocer y entender el inicio, finalización y diálogo de las sesiones. De esta manera, cuando le llega una petición de conexión, el balanceador crea una regla que lo configura dinámicamente para reenviar todos los paquetes pertenecientes a esa sesión hacia un mismo servidor real. Del mismo modo, cuando el balanceador detecte el fin de esa sesión, borrará la regla que previamente le creó. En el caso de que la sesión no finalice y por un período de tiempo máximo predeterminado, no se reciban más paquetes pertenecientes a la misma, el balanceador también borrará la regla. El balanceo de carga de tipo stateful es mucho más eficiente que el balanceo de carga stateless, debido a que las decisiones de balanceo son realizadas también en base al estado de la sesión y no sólo en base a su identificación. Esta importante mejora en el balanceo es

21 12 - Capítulo 3: Balanceadores de carga posible gracias a que los algoritmos de scheduling disponen de más elementos de juicio para la toma de decisiones y que permiten un mejor reparto de las sesiones. El balanceador stateless considera por igual todas las sesiones pertenecientes a una misma IP, en cambio, el balanceador stateful es capaz de diferenciar la carga de las diferentes sesiones. Para lograr una mayor comprensión de lo anteriormente expuesto, considérese el siguiente escenario: Dos clientes efectúan peticiones a un mismo servidor virtual. El primero de ellos, genera 100 paquetes por segundo (60 de http, 30 de FTP y 10 de IRC) hacia el servidor virtual. El segundo cliente sólo genera 5 paquetes (3 de http y 2 de FTP). Un balanceador stateless considera que los 100 paquetes generados por el primer cliente forman parte de una misma sesión, y por tanto, reenvía los 100 a un mismo servidor real. Los 5 paquetes del segundo cliente, los considera pertenecientes a otra sesión, por lo que los reenvía a otro servidor real. Un balanceador stateful es capaz de diferenciar de entre los 100 paquetes enviados por el primer cliente, a qué servicios/sesión pertenecen cada uno de ellos, y por tanto puede repartir, por ejemplo, los 60 paquetes de http al servidor 1, los 30 de FTP al servidor 2 y los 10 de IRC al servidor 3. Dependiendo del las capacidades stateful del balanceador en particular, éste incluso podría llegar a diferenciar entre distintas peticiones http, en función, por ejemplo, de la página solicitada. Un balanceador stateful identificará cada una de las sesiones de cada cliente y realizará un balanceo de carga mucho más eficiente. Como contrapartida, los balanceadores de carga de tipo stateful requieren de una mayor capacidad de proceso.

22 ACADE (LVS) Algoritmos de Scheduling (Hashing) Los balanceadores de carga pueden utilizar diferentes métodos para decidir a qué servidor asignar las diferentes conexiones. Algunos de estos métodos son más efectivos que otros, en función del servicio que se ha de balancear. Es por esto, que un balanceador de carga puede utilizar diferentes algoritmos de scheduling para balancear diferentes tipos de servicios. Secuencial (Round-Robin): - Es el más sencillo por lo que consume muy pocos recursos. - Realiza una asignación secuencial y cíclica de los servidores. - Es poco eficiente ya que no tiene en cuenta el número de conexiones establecidas en cada servidor. De menor número de conexiones (Least Connections): - El balanceador conoce el número de sesiones establecidas en cada servidor real y reenvía las conexiones nuevas al servidor que menos conexiones tiene en ese momento. Distribución Ponderada por pesos (Weighted Distribution): - Este método permite al administrador asignar un peso a cada servidor, en función de su capacidad y el servicio que ha de prestar. - Se utilizan en combinación con Round-Robin y Least Connections. Por tiempo de respuesta (Response Time): - Complementa a otros algoritmos posibilitando la elección del servidor más rápido. Mediante pruebas al servidor: - Mediante la ejecución de programas en cada servidor, llamados agentes, el balanceador puede detectar de forma muy precisa las condiciones de carga de cada servidor. Por contra, esto implica una carga de trabajo extra para los servidores. Además, los agentes han de haber sido programados para el mismo sistema operativo que utilicen los servidores.

23 14 - Capítulo 3: Balanceadores de carga 3.6 Monitorización de los servidores Los balanceadores de carga se configuran para reenviar las conexiones de unos determinados servicios a los servidores reales encargados de ofrecerlos. Para que un balanceador de carga ofrezca alta disponibilidad de los servidores reales, es necesario que actualice su configuración cuando se produce un fallo en alguno de los nodos de la granja de servidores reales. Para poder cambiar dinámicamente esta configuración, se hace necesario la utilización de algún sistema de seguimiento del estado de los servidores y de sus aplicaciones. Estos sistemas monitorizan los servicios ofrecidos por cada servidor real y realizan las modificaciones necesarias en la configuración del balanceador, cuando detectan alguna anomalía. En función del tipo de monitorización que realizan, estos sistemas se pueden clasificar como sistemas in-band o como sistemas out-band Sistemas in-band Los sistemas in-band se caracterizan por utilizar el propio tráfico cliente-servidor para controlar el estado del servidor real. Cuando se detecta un problema, es posible iniciar una serie de controles más exhaustivos para determinar si el fallo se ha producido por la caída del servidor que estaba ofreciendo el servicio. Si es así, se reconfigura oportunamente al balanceador para que deje de reenviar peticiones a ese servidor Sistemas out-band Los sistemas out-band generan su propio tráfico para monitorizar la salud de los servidores reales, que pueden ir desde la simple comprobación de la conectividad, a nivel de capa de enlace de datos, a la comprobación del correcto funcionamiento de los servicios de red ofrecidos y las aplicaciones que los prestan.

24 ACADE (LVS) Métodos para monitorizar la salud del servidor (Health Checks) Chequeo básico Dentro de esta categoría entrarían aquellos chequeos que recurren a pruebas de conectividad de las capas inferiores de la pila OSI: Peticiones ARP en la capa de enlace de datos, peticiones echo ICMP (ping) en la capa de red o peticiones a un puerto TCP/UDP determinado, en la capa de transporte. Estas pruebas son tanto más efectivas a medida que se sube de nivel en la capa OSI, si bien, son siempre un método incapaz de determinar con las garantías suficientes si un servicio está funcionando correctamente. Por otra parte, este método no permite realizar ningún tipo de control sobre los contenidos. Por ejemplo, en el caso de que un servidor web sirva una página de indicación de error (404 URL no encontrada), el sistema de monitorización interpretará que el servidor muestra las páginas correctamente, ya que el sistema no efectúa ningún tipo de comprobación de los contenidos. En otro tipo de servicios, la simple contestación a una petición, aunque ésta sea con un código de error, bastaría para que el sistema los considerase activos. Chequeo específico de las aplicaciones Este tipo de chequeos pretenden determinar el correcto funcionamiento de una aplicación del servidor. La técnica más utilizada en este tipo de chequeo, consiste en realizar una petición del servicio y analizar la información obtenida en respuesta a la misma. De esta manera, es fácil determinar si la aplicación está respondiendo como se espera o no de ella. Por ejemplo, para chequear un servidor web, puede enviarse una petición HTTP y observar que el resultado de la respuesta obtenida concuerda con el esperado. Un chequeo a un servidor FTP, podría consistir en conectarse a éste e identificarse con el correspondiente LOGIN y PASS. Si se obtiene acceso al servicio, el sistema interpretará que la aplicación funciona correctamente. En ocasiones, la correcta prestación de un servicio requiere del correcto funcionamiento de los servicios que se prestan por otros puertos. Por ejemplo, en el caso de un sitio web de e-comerce, si el servicio https (puerto 443 SSL) no funciona correctamente, tampoco tiene sentido ofrecer el servicio http (puerto 80), ya que normalmente dependen uno del otro. En estos casos, puede recurrirse al agrupado de puertos, de manera que si uno de los puertos del grupo falla en alguno de los servidores reales, se considere como fallidos a todos los servicios del grupo.

25 16 - Capítulo 3: Balanceadores de carga Chequeo de contenidos El método de chequeo de contenidos se basa en la misma filosofía que la descrita anteriormente en el sistema de chequeo de aplicaciones. En este caso, el sistema también puede buscar determinados patrones o palabras clave, en la respuesta enviada por el servidor. Un método usado también para este fin, es el de efectuar checksums de la información recibida. En ocasiones, el chequeo de una sola aplicación en el servidor, no es suficiente para determinar su correcto funcionamiento cuando ésta depende de otras. Por ejemplo, puede estar funcionando el servicio web y estar fallando las consultas que éste realiza a la base de datos. Para evitar este tipo de situaciones, podría realizarse un chequeo adicional de los contenidos. Un chequeo de contenidos de una base de datos, podría efectuarse llevando un poco más allá el concepto de chequeo de aplicaciones. Así, una forma de resolver el problema descrito en el ejemplo anterior, sería realizar una petición de comprobación al servidor http, que debería retornar el contenido de una determinada base de datos. De no ser así, se interpretaría que las consultas a la base de datos en cuestión están fallando. Chequeo basado en agentes Otra posibilidad, es la de utilizar sondas o agentes para monitorizar la salud de las aplicaciones que corren en los servidores. Estas sondas envían la información recogida al controlador que corre en el balanceador. Mediante la API que proporcionan estos sistemas, es posible programar alarmas que disparen los mecanismos para reconfigurar el balanceador en caso necesario. Muchos de estos sistemas de chequeo son compatibles con estándares, como por ejemplo, SNMP. La elección de uno de estos métodos de monitorización de servidores o la combinación de varios de ellos, estará en función de las necesidades concretas para cada caso particular. No obstante, lo ideal sería optar por la decisión más equilibrada entre necesidades, recursos hardware disponibles, servicio que se quiere prestar y coste económico.

26 ACADE (LVS) Métodos de reenvío El método de reenvío consiste en la forma en la que el balanceador de carga reenvía los paquetes a los servidores reales. Los métodos de reenvío utilizados dependen en gran medida del la infraestructura de red que interconecta los diferentes elementos del balanceador de carga. En redes privadas, donde todas las máquinas pertenecen a la misma red, lo más usual es utilizar NAT, si bien existen técnicas que no necesitan rescribir las cabeceras de los paquetes IP, como Direct Server Return (3.7.2). Cuando las máquinas se encuentran en redes diferentes, con routers y muchos kilómetros por medio, se utilizan técnicas de balanceo global Network Address Translation (NAT) La traducción de direcciones de red es el método principal en el que se basa el balanceo de carga. Tal y como se describe en el RFC2663 [1] titulado Terminología y Consideraciones sobre Traducción de Direcciones IP : La Traducción de Direcciones de Red, Network Address Translation (NAT), es un método mediante el que las direcciones IP son mapeadas desde un dominio de direcciones a otro, proporcionando encaminamiento transparente a las máquinas finales. Existen muchas variantes de traducción de direcciones que se prestan a distintas aplicaciones. Sin embargo, todos las variantes de dispositivos NAT deberían compartir las siguientes características: - Asignación transparente de direcciones. - Encaminamiento transparente mediante la traducción de direcciones (aquí el encaminamiento se refiere al reenvío de paquetes, no al intercambio de información de encaminamiento). - Traducción de la carga útil de los paquetes de error ICMP. Este apartado se centra en algunos tipos de NAT utilizados en la implementación de balanceadores de carga. Para un estudio en profundidad de NAT véase [2] y [3].

27 imac 18 - Capítulo 3: Balanceadores de carga Destination NAT Consiste en cambiar la dirección destino, de la cabecera IP, de los paquetes enviados por el cliente. Esta dirección se sobrescribe en este caso con la dirección IP del servidor real seleccionado por el balanceador de carga. Cuando el paquete retorna al cliente, se restituye esta dirección para que figure como origen. De esta manera, el paso a través del balanceador de carga, se realiza de forma transparente para el cliente. A este tipo de NAT se le conoce también como half-nat dado que sólo se cambia la dirección destino del paquete. Ruta Cliente-Servidor 1 Origen C Destino B Cliente Dirección IP:C 6 O rigen B Destino C 1 C B 6 B C 2 3 Origen Destino C B Origen Destino C B RS1 Origen C Destino RS1 Balanceador de carga Dirección IP:B 3 2 C C RS1 B Router Dirección IP:R 5 Sw itch 4 B RS1 C C 5 4 O rigen B O rigen RS1 Origen RS1 Destino C Destino C B Destino C Servidores Re ale s Cabecera paq. IP Dirección IP:RS1 Ruta Servidor-Cliente Figura 3: Destination NAT. Source NAT Este tipo de NAT es poco frecuente y sólo se recurre a él en situaciones en las cuales el diseño de la red así lo requiere. En los casos en los que la topología de la red permite a los paquetes volver al cliente evitando el paso a través del balanceador, puede recurrirse a source NAT para éste fin. En determinados diseños de red, pueden existir otras alternativas al source NAT, éstas pasan por utilizar Direct Server Return (DSR) o bien por poner al balanceador como gateway por defecto de los servidores reales. Estas dos alternativas requieren que el balanceador de carga y los servidores reales estén en el mimo dominio de broadcast o capa de enlace.

28 imac ACADE (LVS) - 19 Source NAT se realiza cambiando las direcciones origen y destino de los paquetes. El balanceador de carga cambia la dirección origen de todos los paquetes por una dirección definida en el balanceador, llamada source IP, antes de reenviar los paquetes a los servidores reales. Cuando los paquetes llegan a los servidores reales, estos últimos los ven como peticiones realizadas por el balanceador de carga, puesto que los servidores no tienen conocimiento de la dirección de los auténticos clientes finales que originaron dichos paquetes. Las respuestas de los servidores reales tienen como dirección destino la IP del balanceador de carga y no la del cliente final. El balanceador recoge estas respuestas y rescribe nuevamente la cabecera IP de manera que la dirección de destino sea la IP del cliente y la de origen la source IP. Ruta Cliente-Servidor 1 Origen C Destino B Cliente Dirección IP:C 6 O rigen B Destino C 1 C B 6 B C 2 3 Origen Destino C B Origen Destino C B S RS1 Origen C Destino RS1 Balanceador de carga Dirección IP:B Dirección IP:S 3 2 S C RS1 B Router Dirección IP:R 5 Sw itch 4 B RS1 C S 5 4 O rigen B O rigen RS1 B O rigen RS1 Destino C Destino S C Destino S Cabecera paq. IP B: IP Virtual VIP S: Source IP Servidores Re ale s Ruta Servidor-Cliente Dirección IP:RS1 Figura 4: Source NAT. Desde el punto de vista del balanceador de carga se establecen dos sesiones. Una con el cliente y otra con el servidor real. Los servidores reales ven al balanceador de carga como un cliente, lo cual implica que el balanceador de carga ha de disponer de un número de puerto para cada una de las sesiones que establece con cada uno de los servidores reales. El número de puertos máximos que puede abrir un sistema es de Existe por lo tanto

29 20 - Capítulo 3: Balanceadores de carga una importante limitación en cuanto al número de máximo de conexiones simultáneas que el balanceador de carga puede manejar para una sola IP. Para superar esta limitación el balanceador ha de permitir configurar múltiples direcciones source IP. La principal ventaja de source NAT es la de permitir la implementación de balanceadores de carga independientemente de la topología de la red, con el inconveniente de que los servidores reales no ven la dirección IP original del cliente. Por tanto, aquellas aplicaciones que utilicen algún método de autenticación basado en IP no funcionarán apropiadamente con source NAT. Reverse NAT Este tipo de NAT es el utilizado en una red con direcciones privadas, sólo que en esta ocasión no son los clientes, sino los servidores reales de la red privada, los que inician sesiones hacia la red pública. El balanceador de carga realiza destination NAT para todas las sesiones iniciadas desde el cliente. Si el servidor real necesita iniciar una sesión con el cliente, el balanceador de carga deberá implementar reverse NAT, ya que las direcciones de los servidores reales son privadas y no son enrutables desde Internet. Cuando el balanceador implementa reverse NAT, lo hace cambiando la dirección origen de los paquetes para las sesiones iniciadas desde los servidores reales, por la dirección pública que el balanceador tenga predefinida. En función de las características del balanceador, ésta dirección puede o no ser la misma que la dirección IP virtual, por la cual el balanceador de carga presta los servicios ofrecidos por los servidores reales. Enhaced NAT El balanceo de carga mediante este tipo de NAT requiere de determinadas capacidades stateful en el balanceador. Este tipo de NAT permite que determinados protocolos específicos puedan ser correctamente balanceados. Algunos protocolos incorporan direcciones o puertos, en la carga útil del paquete, que deben cambiarse si se cambian las cabeceras del paquete IP. Un ejemplo de este tipo de protocolos serían los protocolos de streaming. Estas aplicaciones requieren de elevada capacidad de proceso por lo que acostumbran a servirse de forma concurrente desde muchos servidores. El streaming media

30 ACADE (LVS) - 21 es, por lo tanto, una de las aplicaciones típicas candidatas a servirse a través de un balanceador de carga, y suelen utilizar protocolos basados en el estándar Real Time Streaming Protocol (RTSP) descrito en el RFC2326 [4]. Los protocolos RTSP generalmente implican el establecimiento de dos conexiones. Una conexión TCP para el control y una UDP para el envío de los datos. La primera conexión se encamina hacia un puerto del servidor, conocido previamente y configurado para recibir este tipo de peticiones. La sucesivas conexiones se realizarán a un puerto aleatorio enviado a través de la sesión de control TCP que se establece con el cliente. El balanceador ha de saber identificar, de entre la información enviada en el dialogo que mantienen las aplicaciones finales a través de la conexión TCP, el número de puerto seleccionado para el envío de los datos. De esta forma, el balanceador sabrá recoger las peticiones de tramas UDP y balancearlas hacia el servidor real apropiado. Port-Address Translation (PAT) Este tipo de NAT posibilita cambiar el puerto de destino, contenido en las cabeceras de los paquetes enviados por los clientes, por el puerto de los servidores reales en el que realmente se ofrece el servicio, con lo cual, se puede configurar el servicio en un puerto diferente al estándar. El Internet Assigned Number Authority (IANA) [5] (Nota: sustituye al RFC1700) es el organismo encargado de asignar el número de puerto a determinados servicios conocidos, con el fin de estandarizar la relación servicio/puerto. El rango de puertos estándares va del 0 al El hecho de utilizar puertos superiores a 1024, ayuda a incrementar la seguridad del sistema frente a posibles ataques destinados a puertos conocidos. Por otra parte, PAT permite ejecutar simultáneamente sobre un mismo servidor real varios servidores de un determinado servicio. Con esta técnica, a veces se incrementa el rendimiento de los servicios ofrecidos, especialmente en arquitecturas que consten de varios procesadores. De esta manera, el balanceador puede realizar un balanceo de carga no sólo entre los diferentes servidores reales, sino también entre las diferentes instancias de un mismo programa servidor que ejecuta cada servidor real.

31 22 - Capítulo 3: Balanceadores de carga Direct Server Return (DSR) Direct Server Return (DSR) es una técnica que permite introducir importantes mejoras en cuanto a la eficiencia del balanceador. Estas mejoras en el rendimiento se consiguen gracias a dos factores. El primero de ellos es que en DSR, los paquetes de respuesta generados por los servidores reales, no han de ser procesados por el balanceador de carga, sino que estos viajan directamente desde el servidor real al cliente sin pasar por el balanceador. Este hecho permite reducir considerablemente el tráfico de paquetes que atraviesa el balanceador, ya que el tráfico de respuesta es generalmente mucho más grande que el de peticiones, sobretodo en servicios como el ftp o el streaming. El segundo factor es que el balanceador de carga no necesita rescribir las cabeceras IP de las peticiones. El reenvío de paquetes se hace ha nivel de capa de enlace de datos dejando la IP original inalterada. Para que los paquetes puedan llegar al servidor real seleccionado por el balanceador, es necesario que estos se encuentren en el mismo dominio de broadcast, en otras palabras, conectados mediante un switch o conmutador de capa 2. Dado que el balanceador no modifica la dirección destino de los paquetes antes de reenviarlos a los servidores reales, estos se reenvían hacia los mismos con la dirección VIP como destino. Para que los servidores reales procesen los paquetes que reciben por su interfaz de red, son necesarias dos cosas: primero que la dirección del paquete recibido sea la misma que la dirección configurada en la interfaz, y segundo, que dispongan de una aplicación con un socket escuchando en esa IP. Todo ello obliga a configurar un dispositivo con la VIP en cada servidor real, o de lo contrario no procesarán los paquetes que les reenvíe el balanceador. Para usar DSR, tanto el balanceador de carga como los servidores reales, deben de disponer de un dispositivo configurado con la VIP. El protocolo de resolución de direcciones (ARP) es utilizado en Ethernet para resolver la dirección MAC asociada a una determinada IP dentro de un mismo dominio de capa de enlace de datos. En DSR, tanto el balanceador de carga como los servidores reales disponen de un dispositivo configurado con la VIP. Es fácil advertir que si todos los dispositivos configurados con la VIP contestan a peticiones ARP, el router podría enviar las peticiones de los clientes directamente a un servidor real en lugar de al balanceador. Para evitar este y otros problemas, que se derivan de disponer direcciones IP duplicadas en

32 ACADE (LVS) - 23 un mismo segmento de red, se utilizan dispositivos virtuales (loopback) sobre los que configurar la VIP en los servidores reales. El dispositivo virtual de loopback, puede ser configurado con cualquier dirección IP, además de la , y tiene la propiedad de no responder a peticiones ARP en la mayoría de sistemas operativos. En Linux esto no es siempre así (6.3.4). Los servidores reales han de disponer de un dispositivo real con acceso al medio, además de disponer del dispositivo virtual con la VIP. De no ser así, además de no poder hacer llegar los paquetes al dispositivo virtual, el balanceador de carga no sabría con que direcciones MAC encapsular los paquetes destinados a un servidor real en concreto. El balanceador dispone de una lista con las direcciones IP de los servidores, sobre las que efectuará peticiones ARP. El balanceador encapsulará las peticiones de los clientes, sin modificar ningún parámetro del paquete, con la dirección MAC de la interfaz física de red de la que dispone el servidor. Cuando el servidor real genere la respuesta, pondrá como destino la dirección IP del cliente y como origen la dirección IP del dispositivo que ha procesado la petición, que no es otra que la VIP. De este modo no es necesario realizar reverse-nat, por lo cual no es necesario que el paquete sea procesado por el balanceador de carga antes de ser enviado al router de salida. 3.8 Persistencia de sesión Las principales mejoras que aporta el balanceador de carga se basan en la distribución de que realiza de las peticiones de los clientes. Si embargo, en ocasiones, el balanceo de carga puede estar reñido con la correcta prestación de un servicio. Muchas aplicaciones web como por ejemplo HTTP, establecen varias conexiones TCP con el servidor, por ejemplo, para descargar cada uno de los objetos que componen una página web (texto, fotografías, etc). Si todos los servidores reales disponen un sitio web estático con idéntico contenido, ofrecerlo a los clientes a través de un balanceador de carga no representa un problema. Al cliente le es indiferente si los distintos elementos de la página

33 24 - Capítulo 3: Balanceadores de carga provienen de uno o de varios servidores reales, puesto que el contenido de la página mostrada al cliente no ha de depender de si los elementos se han obtenido de distintos servidores. Por el contrario, una aplicación web en la cual el cliente envía información al servidor a través de formularios, o se autentifica como usuario en un sitio web realizando diferentes conexiones para ello, puede no funcionar correctamente si cada una de estas conexiones es reenviada por el balanceador a servidores reales distintos. Los diferentes servidores reales no tienen por qué saber qué información envió el cliente en la conexión anterior al servidor o qué variables envió el servidor al cliente (cookies). A este tipo de servicios que intercambian datos a nivel de aplicación, utilizando para ello el establecimiento de múltiples conexiones TCP, reciben el nombre de servicios o aplicaciones transaccionales. La figura 5, muestra un ejemplo de aplicación transaccional, en la cual la falta de persistencia impide al cliente la compra de una serie de productos en una aplicación de e- comerce. En ella, el cliente espera tener dos productos en el carrito de la compra cuando se dispone a efectuar el pago de la misma. Debido a la falta de persistencia, cada servidor real dispone de una perspectiva diferente de las compras realizadas por el cliente. Servidor Virtual Aplicación Transaccional Data S1 Conexión TCP 1 Intercambio de información HTTP para añadir producto 1 al carrito de la compa del cliente A Con. TCP 1 Server 1 Producto 1 en carrito de la compra del cliecnte A Cliente Conexión TCP 2 Nnuevo diálogo HTTP para añadir producto 2 al carrito de la compa del cliente A Conexión TCP 3 Diálogo HTTP para efectuar el pago del contenido del carrito de la compra del cliente A Balanceador de carga Con. TCP 2 Con. TCP 3 Server 2 Data S2 Producto 2 en carrito de la compra del cliente? Data S3 Fin detransacción Server 3 El carrito de la compra del cliente está Vacío Figura 5: Necesidad de persistencia en aplicaciones transaccionales.