Cluster de Alta Disponibilidad y Alto Desempeño para Servidores

Transcripción

35
Cluster de Alta Disponibilidad y Alto Desempeño
para Servidores Web (ADAD-SW)
Osvaldo Miguel González Prieto
Universidad Nacional del Este - Facultad Politécnica
[email protected]
Resumen. Este proyecto pretende integrar soluciones de software libre en la composición de un cluster de
alta disponibilidad y alto desempeño, para garantizar un nivel de calidad equivalente al de las soluciones
propietarios existentes en el mercado. La alta disponibilidad, el alto desempeño y el balanceo de carga se
basan fundamentalmente en un concepto: redundancia. La mejor forma de asegurar la disponibilidad de
equipos y los servicios que ellos suministran de manera fiable, rápida y sin interrupción las 24 horas
durante 7 días a la semana, es la duplicación de todos sus elementos críticos y la disposición de los
elementos software y hardware necesarios para que los elementos redundantes actúen cooperativamente,
siempre de forma transparente para el usuario final, con resultados favorables como el aumento
significativo de velocidad de descarga, y características de robustez y eficiencia en las pruebas de alta
disponibilidad.
Palabras claves: alta disponibilidad, alto desempeño, balanceo de carga, redundancia, cluster.
Abstract. This projects aims to integrate free software solutions in the composition of a high availability
and high performance cluster, ensuring a quality level equivalent to the existing owners´ solutions in the
market. High availability, high performance and load balance, are mainly based on one concept:
redundancy. The best method for ensuring the availability of equipments and services they provide in a
reliable, fast and uninterrupted 24 hours a day, 7 days a week way, is the duplication of all its critical
elements and the disposition of needed software and hardware elements so that the redundant elements act
cooperatively, but always in a transparent way for the end user. The aim is to obtain as a result a
significant increase in download speed, as well as the robustness and efficiency in high availability tests.
Keywords: high availability, high performance, load balance, redundancy, cluster.
1. Introducción
El propósito de este proyecto es explorar y
experimentar las técnicas utilizadas para crear
un cluster de ordenadores que ofrezca servicio
Web de contenidos dinámicos, con los objetivos
de ofrecer todas las características posibles.
Alta disponibilidad y alto desempeño son
tecnologías emergentes. Éstas están cimentadas
sobre la base de soluciones propietarias, en su
mayoría ligadas habitualmente a costosas
arquitecturas hardware [1].
Linux HA Project [1] es el encargado de aunar
los esfuerzos de la comunidad libre para hacer
de Linux una excelente plataforma sobre la cual
ofrecer servicios de alta disponibilidad y alto
desempeño.
El proyecto ADAD-SW realiza en primer lugar,
un estudio teórico sobre arquitectura de
clustering de alta disponibilidad, alto desempeño
y escalabilidad, centrando su interés en la figura
del balanceador de carga. Posteriormente se
realiza un estudio y evaluación de las diferentes
propuestas surgidas desde el entorno del
software para este fin. Por último se monta y se
configura el cluster, donde se implementa la
arquitectura mínima necesaria, para evaluar las
capacidades que ofrece una solución clustering
basada en software libre Linux NAT4, que
permite ofrecer servicios Web y FTP5.
2. Importancia del trabajo
Con el actual ritmo de crecimiento del comercio
y el movimiento de datos de todo tipo en
Internet y la incuestionable importancia de la
informática en las empresas actuales de
cualquier tamaño, es cada día más importante
que los sistemas informáticos empleados en
éstas puedan funcionar de forma ininterrumpida,
ya sea para dar soporte interno (contabilidad,
4
5
Network Address Translation
File Transfer Protocol
ARTÍCULOS CIENTÍFICOS – INFORMÁTICA – Nº 4 – AÑO 2008
36
control de personal, desarrollo, etc.) como para
ofrecer servicios a través de Internet (comercio
electrónico, correo, portales, educación a
distancia, donde se utiliza fundamentalmente
Internet como medio de comunicación). A esta
necesidad de un servicio ininterrumpido, rápido
y fiable se denomina alta disponibilidad y alto
desempeño, con balanceo de carga; objetivo de
este proyecto.
3.2 Alta disponibilidad
La principal técnica para obtener estos sistemas
tolerantes a fallos es la redundancia, que
consiste en replicar las zonas críticas del
sistema, teniendo una unidad activa y varias
copias inactivas que, tras el fallo de la principal,
sean capaces de retomar su labor en el punto que
aquella falló, en el menor tiempo posible y de
forma transparente para el usuario [1].
3.3 Alto rendimiento
La redundancia permite alta disponibilidad a
partir de la instalación de varios servidores
completos, en lugar de uno sólo, que sean
capaces de trabajar en paralelo y de asumir la
caída de uno de ellos, así se podrá añadir y
quitar servidores del grupo conocido como
cluster según las necesidades [4].
Este tipo de cluster sirve para resolver
problemas complejos que requieren una gran
cantidad
de potencia computacional; por
ejemplo, para pronóstico del tiempo, simulación
y criptografía, etc. [9].
4. ADAD-SW
La persistente necesidad de mantener la
competitividad de las empresas, requiere
escalabilidad en las soluciones hardwares
adaptadas para que sean capaces de amoldarse al
dinamismo del mercado.
Otro factor de importancia surge de la
posibilidad de contar con el Sistema Operativo
Linux que se caracteriza por su estabilidad, libre
distribución,
multiplata-forma
y
multiprocesamiento, además existen varios
paquetes libres para la instalación y
configuración de un cluster, características
relevantes para el éxito del proyecto a un bajo
costo.
3. Clasificación de los Cluster
Existen varias taxonomías aplicadas a la
clasificación de los clusters. Una de ellas, por
ejemplo, tiene en cuenta el carácter propietario o
no de los mismos, dividiéndolos en clusters de
tipo I, construidos con componentes estándares,
y clusters de tipo II los de origen propietario [7].
Otra clasificación bastante utilizada en la
literatura técnica, y que resulta bastante útil para
el análisis de los clusters, es la que distingue los
fines aplicativos del cluster [9], son como sigue:
3.1 Balanceador de carga.
Cluster que permite que un conjunto de
servidores compartan la carga de trabajo y de
tráfico a sus clientes [9].
Se describe los diferentes tipos de balanceadores
de carga existentes. Posteriormente, se abordan
los mecanismos en los que se basa su
funcionamiento, en particular, los diferentes
métodos de distribución de carga (stateless o
stateful) y algoritmos de Scheduling; más
adelante se profundizará sobre estos temas.
También se plantean diferentes mecanismos
para reenviar los paquetes hacia los servidores:
NAT, DSR6 y otros sistemas que permiten
desarrollar balanceadores de carga distribuidos
geográficamente.
Otro aspecto ampliamente tratado es la
persistencia de sesión, necesario en aquellos
servidores que requieren que las diferentes
conexiones de una determinada sesión sean
procesadas por un mismo servidor, como cuando
el cliente realiza una transacción de información
con el servidor.
Tras esta introducción teórica, se abordan
soluciones de software libre que permiten
implementar las arquitecturas de clustering
expuestas anteriormente.
4.1 Métodos de balanceo de carga utilizado 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
6
Direct Server Return
37
función del servicio que se ha de balancear [4].
Debido a ello, un balanceador de carga puede
utilizar diferentes algoritmos de Scheduling para
balancear diferentes tipos de servicios, uno de
ellos es el Round-Robin utilizado en el cluster
ADAD-SW.
Secuencial (Round-Robin), características:
•
•
•
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.
4.2 Elementos que forman parte del cluster
Los elementos con los que cuenta un cluster son:
• Un nodo activo: donde corren los servicios.
• Un nodo pasivo: funcionando en modo
backup
• Dos servidores reales: destinados para
servicios HTTP y FTP.
• Software de Administración.
4.3 Métodos de reenvío
El método de reenvío consiste en la forma en
que el balanceador de carga reenvía los paquetes
a los servidores reales. Los métodos de reenvío
utilizados dependen en gran medida de 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. Cuando las
máquinas se encuentran en redes diferentes, con
routers y muchos kilómetros de por medio, se
utilizan técnicas de balanceo global [4].
NetworkAddressTranslation
Método de reenvío utilizado en el cluster
ADAD-SW; 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 [7].
4.3 Software utilizados
Una vez pasada la fase de análisis preliminar, se
inició la búsqueda de herramientas de software
que mejor se ajustaran a las necesidades ya
descritas: alta disponibilidad, balanceo de carga,
etc.
Linux Virtual Server (LVS)
Linux Virtual Server (LVS) es un proyecto que
incluye los programas y documentación
necesaria para montar un cluster de servidores
bajo GNU/Linux. El proyecto LVS es utilizado
principalmente para aumentar el rendimiento y
escalabilidad de servicios ofrecidos sobre la red;
es ampliamente utilizado por grandes sites como
SouceForge.net, Linux.com y otros [4].
Es un proyecto de código abierto iniciado por
Wensong Zhang en mayo de 1998 [9].
El objetivo es desarrollar un servidor Linux de
alto rendimiento que proporcione buena
escalabilidad, confiabilidad y robustez usando
tecnología clustering.
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. La
interfaz pública (en Internet) de esta máquina
normalmente tiene asociada una dirección
conocida como IP Virtual. El objetivo 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 obstante éste
opera con varias máquinas para conceder uno o
varios servicios al exterior [4].
El proyecto LVS se implementa como un
conjunto de parches al kernel Linux, y un
programa de espacio de usuario denominado
IPVSADM [5].
El sistema que tiene instalado LVS es
denominado director, cuya función no es otra
que balancear las peticiones de red que recibe
entre un conjunto de servidores reales que se
encuentran detrás de él.
LVS funciona a nivel TCP/IP, lo que se conoce
como un conmutador de nivel 4. Lo que ve LVS
son direcciones y puertos de origen y destino, y
38
toma decisiones para balancear la carga con esta
información. LVS toma las decisiones cuando se
abre una conexión (SYN), manteniendo una
tabla de conexiones, para saber a qué servidor
real enviar un paquete perteneciente a una
conexión ya establecida [9]. Por lo tanto, el
balanceo de carga que realiza LVS tiene, en
principio, granularidad a nivel de conexión.
LVS permite balancear muchos protocolos
distintos, en principio puede balancear cualquier
protocolo que trabaje en un solo puerto, y puede
trabajar con protocolos que usen varios puertos,
mediante persistencia o marcas de firewall [5].
Se puede usar iptables [8] para marcar los
paquetes pertenecientes a un servicio virtual
(con una marca de firewall) y usar esa marca
para que LVS identifique los paquetes
pertenecientes al servicio virtual.
LVS realiza balanceo de carga y facilita la alta
disponibilidad entre los servidores reales, si
alguno deja de funcionar, se elimina del cluster
mediante IPVSADM; cuando vuelva a estar
operativo, se añade de nuevo con IPVSADM
[2]. Sin embargo, el balanceador de carga pasa a
ser un SPOF, si se quiere alta disponibilidad se
tiene que añadir un balanceador de respaldo y
usar software de alta disponibilidad que le
permita tomar el papel del balanceador de carga
principal, mediante el uso del programa
HearBeat [1].
IP Virtual Server (IPVS)
El director ejecuta un kernel de Linux
"parcheado" con el código IP Virtual Server
(IPVS), que es la característica principal de
LVS. El director es un router con las reglas de
rutado modificadas. Cuando una nueva petición
de conexión para alguno de los servicios
ofrecidos por LVS, por ejemplo http, es recibida,
el director la reenviará a alguno de los
Servidores Reales para que sea atendida. A
partir de entonces, todos los paquetes del cliente,
pertenecientes a esa conexión, atravesarán el
director hacia un Servidor Real en particular. La
asociación entre el cliente y el Servidor Real se
mantendrá sólo durante el tiempo de vida de la
conexión TCP o cuando expire el timeout, que
establece el tiempo máximo de inactividad para
una conexión establecida [4].
IP Virtual Server (IPVS) es el software con el
que se implementa LVS. IPVS es un
balanceador de carga de capa de transporte.
HeartBeat
El HeartBeat tiene como objetivo crear un
backup del Director que es el punto frágil en el
cluster. Con un backup del Director, el
HeartBeat puede monitorear vía cable ethernet o
serial
el
servidor
original
enviando
periódicamente un paquete, que si no llegara,
indicaría que un servidor no está disponible, por
lo tanto se sabe que el Director ha caído;
entonces él automáticamente activa el backup,
que asume el lugar del Director Linux hasta que
el administrador pueda corregir el problema en
el servidor original [1].
Ldirectord
Es el demonio lanzado por Heartbeat para la
monitorización y control de los Servidores
Reales, así como para llevar a cabo la
administración de las tablas de forwarding del
kernel. Ldirectord comprueba el estado de los
Servidores Reales en intervalos de tiempo
predeterminados con el objetivo de mantener
actualizada la tabla del servidor virtual.
Ldirectord genera reglas IPVSADM para
gestionar el LVS. De esta manera, Ldirectord
permite actualizar dinámicamente las tablas que
definen el comportamiento del balanceador de
carga IPVS. Si uno de los Servidores Reales
deja de servir peticiones de alguno de los
servicios prestados por LVS, Ldirectord creará
una llamada a IPVSADM que hará que el
balanceador deje de reenviarle paquetes al
Servidor Real [4].
4.4 El problema con el Protocolo de
Resolución de Direcciones (ARP)
El Director actúa como un router IP aceptando
paquetes destinados a la VIP7 y enviándolos
posteriormente a un Servidor Real. El router por
el cual el cliente accede al cluster, envía
peticiones ARP periódicamente para conocer la
MAC8 asociada a la VIP y tener actualizada de
este modo su cache ARP, por lo que solamente
el Director activo deberá responder con su MAC
[4]. Así, el router, tras recibir la respuesta ARP,
enviará la petición de conexión al Director
activo que, a su vez, la reenviará a uno de los
Servidores Reales.
7
8
Virtual Internet Protocol
Media Access Control
39
En cambio, si el router obtiene la dirección
MAC de uno de los Servidores Reales en vez de
obtener la MAC del Director activo, entonces
los paquetes serán enviados directamente a ese
Servidor Real, ignorando el papel que debería
desempeñar el Director. Durante el transcurso de
la sesión, el router puede volver a enviar un
broadcast ARP (petición ARP) para mantener
actualizadas sus tablas [3]. En el caso de que en
esta ocasión, responda primero otro Servidor
Real, los paquetes de la conexión ya establecida
con el Servidor Real anterior, serán enviados al
Servidor Real que antes haya contestado al
router. Si éste no es el mismo que contestó en
primer lugar la vez anterior, le llegarán los
paquetes de una conexión ya establecida y se
limitará a enviar TCP RESETs9 (El TCP RESET
es un ataque del tipo denegación de servicio, que
consiste en privar a una máquina de un servicio
o recurso del que normalmente dispone) en
respuesta a los paquetes de una conexión ya
establecida, por lo que esa conexión finalmente
se perderá [11].
4.5 Configuración de los Software utilizados
en los Servidores Reales.
A continuación, se explica el papel que
desarrollan los diferentes elementos software
utilizados en los servidores reales rserver1 y
rserver2 del cluster ADAD-SW.
4.5.1 Sistema software para servir la
aplicación Web (Apache + PHP + MySQL)
En el cluster ADAD-SW, el contenido Web es
servido por el servidor Apache junto con el
módulo PHP de éste, y la base de datos utilizada
es MySQL.
4.5.2 Servidor FTP (ProFTPD)
A fin de probar la capacidad de ofrecer servicios
que requieren de persistencia, se optó por
configurar los servidores reales con un servidor
de FTP. Posteriormente, se configuraron los
balanceadores de carga para permitir ofrecerlos
adecuadamente. El sistema de monitorización
ldirectord que corre en los directors, también
fue configurado para que realizara la
9
El TCP RESET es un ataque del tipo denegación de
servicio, que consiste en privar a
una máquina de un servicio o recurso del que normalmente
dispone.
monitorización del correcto funcionamiento de
ProFTPD. Esta monitorización consiste en
"logearse" en el servicio y bajarse un archivo
predeterminado [6].
6. Diseño del Cluster ADAD-SW
El cluster ADAD implementa la arquitectura
mínima necesaria para evaluar las capacidades
de alta disponibilidad, alto desempeño con
balanceo de carga que ofrece una solución de
clustering basada en software libre LVS-NAT.
Los
clusters
de
alta
disponibilidad
(activo/pasivo) permiten garantizar la alta
disponibilidad de un servicio de red [4]. Por otra
parte, los clusters basados en balanceadores de
carga proporcionan arquitecturas altamente
escalables y manejables [1]. Heartbeat y LVS
permiten crear clusters de alta disponibilidad y
balanceadores de carga respectivamente.
ADAD-SW utiliza aspectos de la filosofía en la
que se basan los clusters de alta disponibilidad,
aprovechando también la alta escalabilidad que
ofrecen los balanceadores de carga.
Como resultado se obtiene una solución que
ofrece alta disponibilidad, alto desempeño,
escalabilidad y manejabilidad en los servicios
ofertados. ADAD-SW se sirve de IPVSADM
para configurar y monitorizar los servicios de
red que se están ofreciendo, actualizando las
reglas de reenvío según sea necesario.
Por otra parte, los servidores reales del cluster,
utilizan el servidor Apache junto con PHP y el
administrador de base de datos MySQL para
servir contenido Web dinámico. También se ha
experimentado satisfactoriamente con el servicio
FTP lo que ha permitido evaluar las capacidades
para garantizar la persistencia en aquellos
servicios que la requieren.
6.1 Topología Física del cluster ADAD-SW
Se compone de cuatro máquinas como se
muestra en la figura 1. Dos balanceadores de
carga (director1 y director2) y dos servidores
reales (servidor1 y servidor2). Estas cuatro
máquinas están conectadas entre sí mediante una
red Ethernet conmutada. Los balanceadores de
carga disponen de una segunda interfaz que les
conecta con la red exterior compartida. Además,
los servidores directores están interconectados
entre sí mediante un enlace serie.
40
A continuación, se enumeran todos los
elementos software a los que se ha recurrido
para implementar la arquitectura del cluster, el
papel que realiza cada uno de ellos en el
escenario ADAD-SW y qué relación se
establece entre todos ellos.
7.1 Servicios ofrecidos
Figura 1. Topología física.
6.2 Topología lógica del cluster ADAD-SW
Existen dos redes, la red cliente o externa y la
red del cluster o interna. Los servidores reales
pertenecen únicamente a la red interna, mientras
que los directores a ambas, actuando de este
modo como pasarelas, como se muestra en la
figura 1.
Cada interfaz de red tiene asignada una
dirección IP distinta. Sin embargo, cada una de
las dos interfaces del director activo en ese
momento, tiene también asignada una VIP
flotante.
La dirección VIP es idéntica para ambos
directores,
pero
nunca
están
activas
simultáneamente en los dos. La gestión
dinámica de las VIPs se realiza utilizando el
software Heartbeat.
7. Funcionamiento e interrelación de los
diferentes elementos software
El cluster ADAD-SW es un cluster
activo/pasivo de servidores virtuales Linux
(balanceadores de carga) que ofrecen los
servicios que corren en los servidores reales.
ADAD-SW se compone de un cluster
activo/pasivo, en el cual el servicio de alta
disponibilidad que se ofrece es un balanceador
de carga. Esto implica tener un escenario que se
compone de dos balanceadores de carga: uno
primario (activo o master) y otro de reserva
(pasivo o backup). En caso de alguna falla con el
servidor principal, el balanceador de carga de
reserva puede cambiar su rol y pasar a ser
activo. Por otra parte, los servidores reales
también han de poder detenerse en cualquier
momento sin que ello afecte a la disponibilidad
del servicio. Es por todo esto que se requiere de
una serie de software periférico al balanceador
de carga (LVS) y al cluster activo/pasivo
(Heartbeat), por lo que se recurre a una serie de
programas, scripts y demonios auxiliares que
permiten que todo funcione.
Los servicios ofrecidos por el cluster son dos:
Servicio Web, por el protocolo HTTP como
también por el protocolo HTTPS y transferencia
de archivos por el protocolo FTP. El primero de
ellos, consiste en un sitio Web, el siguiente
ofrece un servidor de FTP anónimo.
8. Pruebas realizadas
El cluster implementado en este proyecto, ofrece
servicio Web y de transferencia de archivo a los
clientes, los cuales acceden a ellos, de la misma
forma que lo harían si éstos fueran ofrecidos
desde un servidor normal y no desde un cluster.
De manera que los procesos de balanceo de
carga son transparentes para el usuario final, que
no se percata de que estos datos están siendo
prestados a través de un balanceador de carga.
8.1 Balanceo de carga
Escenario: Un cluster con nodos homogéneos,
formados por un Director Master, un Director
Backup y dos Servidores Reales, donde llega
una solicitud de página Web; con la ayuda de la
herramienta IPVSADM se puede ver el
comportamiento del balanceador de carga.
Cuando el cliente obtiene en su navegador el
contenido mostrado en la figura 2, no es
consciente de que en realidad esa página Web se
ha obtenido desde dos servidores reales
distintos. Si se miran las conexiones establecidas
en el balanceador de carga activo, se observa
que se han realizado dos conexiones TCP a
servidores reales distintos, como muestra la
siguiente tabla de sesiones:
Figura 2. Captura de pantalla en el momento de una
conexión en el puerto 80
41
Conclusión: El algoritmo de balanceo RoundRobin realiza una asignación secuencial y cíclica
de los paquetes que llegan al cluster, como se
puede observar en las últimas líneas de la Figura
2, lo cual demuestra el correcto funcionamiento
de la distribución de los paquetes.
8.2 Persistencia de sesión
Escenario: Las condiciones son similares a las
utilizadas en los test del balanceador de carga,
donde se realiza la conexión con el servicio,
luego se descarga un archivo de 708.476 KB,
también se solicita una página Web desde el
ordenador del cliente, con el propósito de
realizar comparaciones, durante este proceso se
realiza un análisis del comportamiento del
balanceador de carga, utilizando la herramienta
"IPVSADM", como se muestra en la figura 3.
La figura 3 muestra el contenido de la tabla de
conexiones cuando un mismo cliente está
utilizando los servicios Web, y FTP del cluster
ADAD-SW. Se observa como las conexiones
pertenecientes a los puertos del FTP, puerto 21
del servidor, se reenvían persistentemente a la
dirección 192.168.7.4, en cambio las conexiones
realizadas al servicio HTTP (puerto 80) son
balanceadas de acuerdo al algoritmo de
scheduling round robin.
8.3 Alta disponibilidad
Escenario: Para comprobar el buen desempeño
del cluster ADAD-SW, en cuanto a alta
disponibilidad se refiere, fueron aplicadas dos
etapas de pruebas, una en nivel de los
balanceadores
de
carga
o
directores,
desconectando el Director Master en espera de
que el Director Backup reaccione y tome el
puesto de balanceador de carga. Por otro, lado
en el nivel de los Servidores Reales, se adiciona
un tercer servidor, con el objetivo de una mejor
demostración del comportamiento del cluster en
el momento en que uno de ellos es desconectado
y vuelto a conectar. Para cada prueba realizada
fueron enviadas consecutivamente veinte mil
solicitudes de páginas Web, utilizando la
herramienta "ab".
De nada sirve contar con alta disponibilidad en
cuanto a servidores reales, si el balanceador
supone un único punto vital para todo el sistema.
Es por ello que el cluster ADAD-SW dispone de
dos balanceadores de carga en una arquitectura
de cluster activo/pasivo. Heartbeat es el
software que permite implementar esta
arquitectura. Los siguientes Logs mostrados en
la figura 4 y en la figura 5 del balanceador de
carga de reserva (director2), reflejan cómo se
realiza el proceso de takeover cuando se produce
un fallo en el balanceador de carga primario
(director1).
Figura 3. Captura de pantalla en el momento de la
conexión en el puerto 21.
Conclusión: El protocolo FTP necesita una
persistencia de sesión debido a los procesos que
realiza en el momento de la transferencia de
archivos, razón por la cual se utiliza el método
de persistencia de sesión PPC para este servicio.
Luego de varias pruebas realizadas al
comportamiento del balanceador de carga, las
cuales arrojaron resultados similares a la figura
<ref>conx2</ref> en la que podemos observar,
en las primeras líneas de la columna de
destination, el comportamiento del balanceador
de carga para este servicio, se obtuvieron los
resultados esperados de acuerdo a las
configuraciones realizadas.
Figura 4. Captura de pantalla del archivo ha.log
42
originado, sino que debe entender también el
funcionamiento interno de los sistemas finales
que lo generan; siempre y cuando se pretenda
resolver los problemas que plantea la posibilidad
de ofrecer alta disponibilidad, alto desempeño y
escalabilidad mediante la redundancia de los
sistemas que han de trabajar, aparentemente
como uno solo, en una solución cliente/servidor
virtual.
Figura 5. Captura de pantalla del archivo ldirectord.log
Conclusión: La alta disponibilidad, uno de los
principales objetivos de este proyecto, fue
lograda satisfactoriamente, ya sea en el nivel de
los Directores y de los Servidores Reales, como
se demostró anteriormente. El cluster ADADSW presentó un comportamiento estable y
fiable, a lo largo del arduo proceso de pruebas
realizadas para esta función.
8.4 Alto desempeño
Escenario: Para esta última batería de pruebas
fue adicionado un cuarto Servidor Real, con el
objetivo de obtener una mayor cantidad de
datos, los tests fueron realizados conectando un
Servidor Real, luego realizando tres grupos de
solicitudes de páginas Web de diez mil,
cincuenta mil y cien mil; esto cada vez que un
Servidor Real era conectado. Al final se buscó el
promedio de los Kbytes/seg que suministra el
informe del comando "ab", para cada cantidad
de Servidor Real conectado.
Conclusión: Para cada Servidor Real conectado,
se adiciona un desempeño considerable al
cluster ADAD-SW, lo que concuerda con la
afirmación de la conocida frase: "La unión hace
la fuerza". De esta forma el cluster ADAD-SW
ofrece un servidor Web de alto desempeño, con
capacidad de aumentar aun más esta
característica por cada Servidor Real adicionado.
9. Conclusión
Una infraestructura como el cluster ADAD
plantea dos problemas: uno telemático, en
cuanto al control y gestión del tráfico que
originan los sistemas finales en arquitecturas
cliente/servidor; y otro informático, que requiere
entender el comportamiento
de
estas
aplicaciones finales. Por ello, el telemático no
puede quedarse sólo en el tratamiento del tráfico
El hecho de ofrecer una aplicación
cliente/servidor mediante un conjunto de
máquinas, en vez de hacerlo a través de una
sola, permite ofrecer una serie de ventajas, en
cuanto
a
capacidad,
escalabilidad
y
disponibilidad, a costa de introducir nuevos
problemas por resolver que no se daban en la
arquitectura cliente/servidor tradicional.
Por otra parte, el modelo de ingeniería en el cual
se establece el software libre, que ha permitido
desarrollar todas las aplicaciones necesarias para
construir el cluster ADAD-SW, demuestra su
viabilidad y madurez para implementar
soluciones que respondan a problemas reales.
10. Principales logros alcanzados
Con este trabajo se ha logrado comprender el
paradigma de los clusters para servidores Web
construidos en base a software libre y hardware
comunes y económicos. Con lo que se adquiere
la suficiente capacidad para construir y
configurar clusters para servidores Web.
También se ha incursionado profundamente en
el análisis del funcionamiento de los paquetes
LVS, Heartbeat y los demás paquetes utilizados.
Cada uno de estos paquetes aporta su
funcionalidad de forma eficiente y sincronizada
y se obtiene como resultado un cluster para
servidores Web con características inigualables y
a un costo extremadamente reducido en
comparación a las mainframes para servidores
Web construidas por las grandes corporaciones.
Uno de los mayores logros es la construcción del
cluster ADAD-SW utilizando el Kernel 2.6, que
constituye una versión nueva, poco utilizada en
este tipo de proyectos. Varios de los paquetes
utilizados, como el Heartbeat y el Ldirectord,
no presentaban hasta el momento de la
instalación una adaptación para esta versión del
Kernel, lo que obligó a su instalación en forma
manual. A pesar de estos inconvenientes, se
43
lograron los objetivos con los resultados
esperados, como se comenta a continuación:
Balanceo de carga: el cluster presenta una
excelente distribución de carga, a pesar de
trabajar con uno de los algoritmos de balanceo
más simples, pero al mismo tiempo más ágil,
esta última característica es importante para
ofrecer un alto rendimiento. Posee también un
manejo eficiente de la escalabilidad del cluster;
una vez adicionadas las configuraciones
correspondientes al nuevo servidor real, el
balanceador
comprueba
su
correcto
funcionamiento y por último lo agrega en su
tabla de servidores reales activos de forma
automática, con lo cual alcanza una mayor
disponibilidad y desempeño.
Persistencia de Sesión: esta característica es
fundamental para el correcto funcionamiento del
protocolo FTP del cluster, trabaja con el método
de balanceo basado en Persitent Port
Connection que se basa en la combinación de
tres campos del paquete: IP origen, IP destino y
puerto destino, de forma a mantener una
conexión basada en solo uno de los Servidores
Reales.
Alta Disponibilidad: el cluster ADAD-SW
puede soportar caídas de varios nodos y seguir
operando sin alteración alguna. Esto ocurre
porque todos los Servidores Reales están
conectados al balanceador de carga que tiene la
capacidad de detectar el estado de cada uno de
ellos, tomar las correspondientes acciones
automáticamente en caso de que surgiera alguna
variación en el estado de los servidores y
trabajar con uno o con varios servidores. Cuanto
mayor sea el número de Servidores Reales,
mayor será la disponibilidad del cluster.
Alto Desempeño: La velocidad de respuesta del
cluster ADAD-SW es proporcional a la cantidad
de Servidores Reales activos conectados al
mismo.
11. Referencias
[1] Alan Robertson AR. The linux highavailability proyect. [10/04/07].
http://www.linux-ha.org
[2] Jorge Fuentes JF. Hispalinux
http://es.tldp.org/Manuales-LuCAS/doc-cursosalamanca-clustering/html/ch03s04.html
[3] Linux Virtual Machine LVM. Sistina (lvm y
gfs) [26/04/07].
http://www.sistina.com
[4] Linux Virtual Server LVS. Highperformance and highly avail-able server for
linux using clustering technology
http://www.linuxvirtualserver.org
[5] Joseph Mack MJ. Lvs-howto [26/04/07].
http://www.austintek.com/LVS/LVS-HOWTO
[6] MySQL Organization MO. Structured query
language software
www.mysql.com
[7] The Linux Documentation Project TLDP.
Kimberlite clustering technology.
http://www.tldp.org
[8] Ultra Monkey UM. Load balancing and high
availability solution [20/04/07].
http://www.ultramonkey.org
[9] Wikipedia Foundation WF. La enciclopedia
libre wikipedia [20/04/07].
http://es.wikipedia.org

Cluster de Alta Disponibilidad y Alto Desempeño para Servidores

Transcripción

Documentos relacionados

cluster headache - Instituto de Neurologí

Red Hat Enterprise Linux 5 Virtual Server Administration