Arquitecturas de Clustering de Alta Disponibilidad y Escalabilidad … · 2005-02-27 · Prefacio Prefacio Estructura y contenido de la memoria La memoria del proyecto ACADE (LVS)

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 <[email protected]> Gabriel Bergés Pujol <[email protected]>

V1.0.1 Marzo 2003

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

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]:

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

ÍNDICE I

Índice

1. INTRODUCCIÓN........................................................................................................... 1

1.1 DEFINICIONES............................................................................................................... 2 1.1.1 Clustering ............................................................................................................. 2 1.1.2 Alta disponibilidad ............................................................................................... 2 1.1.3 Alta escalabilidad................................................................................................. 2


2. OBJETIVOS INICIALES DEL PROYECTO ACADE .............................................. 3

3. BALANCEADORES DE CARGA................................................................................. 5

3.1 INTRODUCCIÓN............................................................................................................. 5 3.2 DEFINICIÓN .................................................................................................................. 5 3.3 MEJORAS QUE APORTA EL BALANCEADOR DE CARGA ................................................... 6

3.3.1 Escalabilidad........................................................................................................ 6 3.3.2 Disponibilidad ...................................................................................................... 7 3.3.3 Gestión y flexibilidad en el mantenimiento .......................................................... 7 3.3.4 Seguridad.............................................................................................................. 8 3.3.5 Calidad de servicio (QoS) .................................................................................... 8

3.4 TIPOS............................................................................................................................ 8 3.5 MÉTODOS DE DISTRIBUCIÓN DE CARGA ........................................................................ 9

3.5.1 Stateless .............................................................................................................. 10 3.5.2 Stateful ................................................................................................................ 11 3.5.3 Algoritmos de Scheduling (Hashing).................................................................. 13

3.6 MONITORIZACIÓN DE LOS SERVIDORES....................................................................... 14 3.6.1 Sistemas in-band................................................................................................. 14 3.6.2 Sistemas out-band............................................................................................... 14 3.6.3 Métodos para monitorizar la salud del servidor (Health Checks)..................... 15

3.7 MÉTODOS DE REENVÍO ............................................................................................... 17 3.7.1 Network Address Translation (NAT) .................................................................. 17 3.7.2 Direct Server Return (DSR)................................................................................ 22

3.8 PERSISTENCIA DE SESIÓN............................................................................................ 23 3.8.1 Tipos de persistencia de sesión .......................................................................... 25 3.8.2 Métodos de persistencia basados en IP origen .................................................. 26 3.8.3 Métodos basados en la aplicación ..................................................................... 30

3.9 BALANCEADORES DE CARGA DE ALTA DISPONIBILIDAD.............................................. 33

4. CLUSTERING Y BASES DE DATOS........................................................................ 39

Í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............ 41

6. BALANCEADORES DE CARGA LIBRES............................................................... 45 6.1 LINUX VIRTUAL SERVER PROJECT ............................................................................. 45 6.2 ¿QUÉ ES LVS? ........................................................................................................... 45

6.2.1 LVS, IP Virtual Server (IPVS)............................................................................ 46 6.3 MÉTODOS DE REENVÍO SOPORTADOS POR LVS .......................................................... 48

6.3.1 LVS-NAT............................................................................................................. 48 6.3.2 LVS-DR............................................................................................................... 51 6.3.3 LVS-Tun.............................................................................................................. 56 6.3.4 El problema con el Protocolo de Resolución de Direcciones (ARP)................. 57

6.4 PERSISTENCIA EN LVS ............................................................................................... 66 6.5 FIREWALL MARKS ...................................................................................................... 72 6.6 ALGORITMOS DE SCHEDULING IMPLEMENTADOS POR LVS........................................ 74 6.7 IPVSADM .................................................................................................................... 76 6.8 LVS, KERNEL TCP VIRTUAL SERVER (KTCPVS) .................................................... 87 6.9 DIRECT ROUTED WEB SWITCH (DRWS).................................................................... 87 6.10 HIGH UP TIME PROJECT (HUT)................................................................................ 88

7. CLUSTER ACTIVO/PASIVO CON LVS .................................................................. 91 7.1 HEARTBEAT ............................................................................................................... 91 7.2 FAKE .......................................................................................................................... 97 7.3 LINUX DIRECTOR DAEMON LDIRECTORD................................................................... 98 7.4 SERCICE MONITORING DAEMON, MON .................................................................... 100

8. SOFTWARE DE SERVIDOR ................................................................................... 103 8.1 APACHE.................................................................................................................... 103 8.2 PHP.......................................................................................................................... 104 8.3 MYSQL DATABASE SERVER.................................................................................... 105 8.4 PROFTPD ................................................................................................................ 106

ÍNDICE III

Parte 3: Cluster Acade (LVS). Descripción, funcionamiento y

pruebas efectuadas

9. CLUSTER ACADE (LVS).......................................................................................... 107

9.1 ¿QUÉ ES EL CLUSTER ACADE (LVS)? ....................................................................... 108 9.2 COMPONENTES SOFTWARE UTILIZADOS (LVS+HEARTBEAT+LDIRECTORD)............. 108 9.3 SERVICIOS OFRECIDOS .............................................................................................. 109 9.4 TOPOLOGÍA FÍSICA DEL CLUSTER ACADE ................................................................. 109 9.5 TOPOLOGÍA LÓGICA DEL CLUSTER ACADE................................................................ 110 9.6 FUNCIONAMIENTO E INTERRELACIÓN DE LOS DIFERENTES ELEMENTOS SOFTWARE DE ACADE............................................................................................................................ 111

9.6.1 Software utilizado en los balanceadores de carga........................................... 111 9.6.2 Software utilizado en los Servidores Reales..................................................... 120

9.7 PRUEBAS REALIZADAS.............................................................................................. 121 9.7.1 Balanceo de carga. ........................................................................................... 122 9.7.2 Persistencia de sesión....................................................................................... 123 9.7.3 Monitorización de contenidos .......................................................................... 124 9.7.4 Alta disponibilidad del balanceador de carga. ................................................ 125

10. CONCLUSIONES Y VALORACIONES................................................................ 129 10.1 LIMITACIONES Y ASPECTOS POR DESARROLLAR EN ACADE .................................... 130

10.1.1 Aspectos por desarrollar: LVS-DR y LVS-Tun .............................................. 130 10.1.2 Limitaciones de este modelo: Bases de Datos................................................ 130

10.2 CONCLUSIÓN FINAL................................................................................................ 131

ÍNDICE IV

Índice de figuras FIGURA 1: UBICACIÓN DEL BALANCEADOR DE CARGA............................................................... 6 FIGURA 2: ESTABLECIMIENTO DE CONEXIÓN TCP.................................................................. 10 FIGURA 3: DESTINATION NAT. .............................................................................................. 18 FIGURA 4: SOURCE NAT. ...................................................................................................... 19 FIGURA 5: NECESIDAD DE PERSISTENCIA EN APLICACIONES TRANSACCIONALES. ...................... 24 FIGURA 6: MEGAPROXY PROBLEM, CASO 1............................................................................. 29 FIGURA 7: MEGAPROXY PROBLEM, CASO 2............................................................................. 30 FIGURA 8: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/PASIVO................................................ 34 FIGURA 9: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/ACTIVO. .............................................. 35 FIGURA 10: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/ACTIVO OPTIMIZADO.......................... 36 FIGURA 11: CLUSTER DE ALTA DISPONIBILIDAD ACTIVO/ACTIVO OPTIMIZADO 2. ...................... 37 FIGURA 12: CLUSTERING Y BASES DE DATOS. ......................................................................... 39 FIGURA 13: LVS-NAT. ......................................................................................................... 49 FIGURA 14: TOPOLOGÍA LVS-DR.......................................................................................... 53 FIGURA 15: LARS’ METHOD. ................................................................................................. 64 FIGURA 16: MONITORIZACIÓN MEDIANTE LATIDOS................................................................. 91 FIGURA 17: TAKEOVER MEDIANTE EL ENVÍO DE GRATUITOUS ARP. ........................................ 94 FIGURA 18: CLUSTER ACADE EN ACCIÓN. ............................................................................ 107 FIGURA 19: CLUSTER ACADE. ............................................................................................. 110 FIGURA 20: TAKEOVER EN ACADE. ...................................................................................... 116 FIGURA 21: ESQUEMA SOFTWARE ACADE (LVS). ................................................................. 119 FIGURA 22: EJEMPLO DE ACCESO AL SERVICIO WEB DEL CLUSTER ACADE............................. 121 FIGURA 23: EJEMPLO DE ACCESO AL SERVICIO FTP VIA WEB DEL CLUSTER ACADE................. 122

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)

ACADE (LVS) - 1

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

2 - Capítulo 1: Introducción

1.1 Definiciones

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

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

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

ACADE (LVS) - 3


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.

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

ACADE (LVS) - 5

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

6 - Capítulo 3: Balanceadores de carga

Cliente

Red

Balanceador decarga

ServidoresReales

Servidor Virtual

Figura 1: Ubicación del balanceador de carga.

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.

3.3.1 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

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

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

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


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.

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

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

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


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.

Establecimiento deconex ión TCP(Inic io de Ses ión)

three-w ay handshake

Cliente Servidor

F inalización de sesión TCP

SYN

ACK SYN

ACK

Intercambio de Datos

FIN

ACK FIN

R ecepc ión SYN (SEQ=x )

Env ío SYN (SEQ=x )

Env ío AC K SYN (SEQ=y , AC K=x +1)

R ecepc ión AC K SYN (SEQ=y , AC K=x )

Env ío AC K(SEQ= y +1)

R ecepc ión AC K(SEQ= y +1)

Env ío F IN (SEQ=n)

R ecepc ión F IN (SEQ=n)

Env ío AC K F IN (AC K=n+1)

R ecepc ión AC K F IN (AC K=n+1)

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.

3.5.1 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

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.

3.5.2 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


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.

ACADE (LVS) - 13

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


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.

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

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

ACADE (LVS) - 15

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


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.

ACADE (LVS) - 17

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

3.7.1 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].


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.

i M ac

Clie nteOrigen DestinoDirecc ión IP:C

Direcc ión IP:R

Direcc ión IP:R S1

Balanceadorde carga

Direcc ión IP:B

Route r

Se rvidore sRe ale s

C B

Origen DestinoC B

Origen DestinoC B

RS1

Origen DestinoC RS1

O rigen DestinoRS1 C

Ruta Cliente-Servidor

Ruta Servidor-Cliente

Cabecera paq. IP

O rigen DestinoRS1 C

B

O rigen DestinoB C

O rigen DestinoB C

C B1

1

C B2

C RS13

2

3

RS1 C4

4

5

B C5

B C6

6

Sw itch

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.

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.

i M ac

Clie nteOrigen Destino

Direcc ión IP:C

Direcc ión IP:R

Direcc ión IP:R S1

Balanceadorde carga

Direcc ión IP:BDirecc ión IP:S

Route r


C B

Origen DestinoC B

Origen DestinoC B

RS1

Origen DestinoC RS1

O rigen DestinoRS1 S

Ruta Cliente-Servidor

Ruta Servidor-Cliente

Cabecera paq. IP

O rigen DestinoRS1 S

B

O rigen DestinoB C

O rigen DestinoB C

C B1

1

C B2

S RS13

2

3

RS1 S4

4

5

B C5

B C6

6

S

B: IP V irtual V IPS: Source IP

CSw itch

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 65.536. Existe por lo tanto


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

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


3.7.2 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

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 127.0.0.1, 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


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.

Server 1

Server 2

Server 3

Data S1

Data S2

Data S3

Balanceador decarga

Aplicación Transaccional

Conexión TCP 1Intercambio de información HTTPpara añadir producto 1 al carrito de

la compa del cliente A

Conexión TCP 2Nnuevo diálogo HTTP para añadir

producto 2 al carrito de la compa delcliente A

Conexión TCP 3Diálogo HTTP para efectuar el pago

del contenido del carrito de lacompra del cliente A

Fin deTransacción

Con. T

CP 1

Con. TCP 2

Con. TCP 3

Producto 1 en carritode la compra delcliecnte A

Producto 2 en carritode la compra delcliente ?

El carrito de lacompra del clienteestá Vacío

Cliente

Servidor Virtual

Figura 5: Necesidad de persistencia en aplicaciones transaccionales.

ACADE (LVS) - 25

Todo esto plantea la necesidad de habilitar mecanismos para determinar qué conexiones

han de ser balanceadas y cuales han de ser reenviadas persistentemente hacia un

determinado servidor real. El concepto de stateless y stateful visto en apartados anteriores

(3.5.1 y 3.5.2) determinará, en muchas ocasiones, los métodos utilizados para determinar

las necesidades de persistencia de un servicio y los mecanismos utilizados para

garantizarla. El problema principal es por tanto, cómo identificar el principio y el final de

las sesiones.

3.8.1 Tipos de persistencia de sesión

Cuando el balanceador de carga recibe una nueva petición de conexión, éste puede

balancear dicha petición o bien reenviarla persistentemente hacia un determinado servidor,

al considerarla parte de una sesión de aplicación que así lo requiere. El balanceo de carga

implica seleccionar un destino en base a las condiciones de los servidores reales. La

persistencia de sesión implica seleccionar un servidor real en base a la información del

primer paquete de la sesión TCP, o bien, en base a una información más relevante extraída

de los datos que el servidor real envía en respuesta al cliente. La información relevante del

primer paquete TCP SYN de una conexión está formada por la dirección IP origen, puerto

origen, dirección IP destino, y puerto destino. Gracias a esta información, el balanceador

de carga puede identificar al usuario en base a su dirección IP. Si el balanceador es capaz

de mirar en los datos de respuesta, encontrará información de aplicación más interesante.

Esto da lugar a dos tipos de persistencia de sesión, una en base a la información del

paquete TCP SYN y otra basada en los datos de la respuesta a nivel de aplicación. El

primer método recibe el nombre de Source IP based persistence, o persistencia basada en

IP origen. Los balanceadores que utilizan el segundo método son conocidos como

balanceadores de carga de aplicación y están basados en el método de balanceo delayed

binding (3.8.3).


3.8.2 Métodos de persistencia basados en IP origen

Estos métodos utilizan la información de las cabeceras TCP de los paquetes que atraviesan

el balanceador y de los datos de una tabla de sesiones. Cuando se recibe un paquete TCP

SYN, el balanceador busca la dirección origen del mismo en la tabla de sesiones. Si el

servidor no encuentra una entrada en la tabla para esa dirección origen, entonces creará una

entrada con esa dirección y reenviará el paquete hacia el servidor real que determine el

algoritmo de reenvío correspondiente. En caso contrario, si el servidor encuentra una

entrada en la tabla para la dirección origen del paquete, enviará el paquete al servidor que

indique dicha entrada, sin aplicarle el algoritmo de scheduling. Cuando el balanceador

recibe un paquete TCP FIN o RESET, finaliza la conexión pero mantiene la entrada en la

tabla de sesiones. De esta manera, el balanceador recuerda que la conexión realizada desde

esa IP origen, ha sido reenviada a un servidor real concreto y le reenviará todas las

conexiones pertenecientes a esa sesión.

El balanceador de carga es incapaz de comprender el protocolo (diálogo) que utilizan la

aplicación transaccional del servidor y la aplicación del cliente. Por ello, es incapaz de

determinar en que momento ha de finalizar la persistencia que impone la sesión de

aplicación. El método utilizado en este tipo de balanceadores de carga, para lograr la

persistencia de las diferentes conexiones TCP pertenecientes a una misma sesión de

aplicación, es la configuración de un temporizador conocido como session-persistence-

timer, que determina el tiempo máximo que ha de permanecer una entrada en la tabla de

sesiones desde el último TCP FIN o TCP RESET recibido. De esta manera, cuando finaliza

la ultima conexión activa para una sesión de aplicación, el temporizador empieza a contar.

Si finaliza el temporizador para una sesión de aplicación determinada, el balanceador

borrará la entrada que asocia a ese usuario con un determinado servidor real. De esta

manera, a los futuros paquetes pertenecientes a esa conexión se les volverá a aplicar el

algoritmo de scheduling. Si el balanceador recibe una nueva conexión de ese cliente antes

de que expire el temporizador, éste se pone a cero.

Mantener las sesiones de forma persistente es contrario al principio de balanceo de carga,

ya que mantener de forma persistente una conexión que no lo requiere, reduce

considerablemente el rendimiento del balanceador. Existen diferentes métodos, basados en

ACADE (LVS) - 27

el la IP origen, que permiten determinar con mayor o menor precisión la necesidad de

persistencia de las sesiones de aplicación, obteniendo así un mayor grado balanceo de

carga y consecuentemente un mayor rendimiento.

Persistent Port Connection (PPC), basado en IP origen, VIP y puerto

Cuando se utiliza este método, el balanceador de carga se basa en la combinación de tres

campos del paquete TCP SYN: IP origen, IP destino y puerto destino, por lo que se

encontrarán estos tres datos en la tabla de sesiones. Las siguientes conexiones serán

consideradas como pertenecientes a una sesión si casan con esta tripleta. De esta manera, el

balanceador reenviará hacia servidores distintos, los paquetes que, aun viniendo de la

misma IP origen, tengan como destino puertos de servicios diferentes, o bien direcciones

IP destino diferentes. La IP de destino deberá ser una dirección virtual configurada en el

balanceador (VIP).

Persistent Client Connection (PCP), basado en IP origen y VIP

En determinadas aplicaciones, es necesario que las conexiones TCP realizadas por un

mismo cliente sean procesadas por el mismo servidor real. Por ejemplo, una aplicación

transaccional de e-comerce, probablemente establecerá una sesión HTTP y otra SSL,

necesitando ambas ser atendidas por el mismo servidor real. Si el balanceador de carga se

basa en la tripleta IP origen, IP destino y puerto, probablemente asigne estas dos sesiones a

servidores reales distintos. Evidentemente, la aplicación transaccional no funcionará

correctamente (figura 5). La solución puede pasar entonces por un balanceador de carga

que simplemente tenga en cuenta la IP origen y destino de los paquetes, con lo que se

solventa el problema, si bien el balanceo de carga en menos eficiente. En este caso, es

recomendable ofrecer los servicios que requieren de esta técnica a través de una VIP

diferente, así no se verán afectados todos los servicios por la reducción de la eficiencia del

balanceo y tampoco dejarán de poder prestarse los mismos.

Agrupamiento de Puertos

Cuando utilizamos una misma dirección IP virtual (VIP) para diferentes aplicaciones, las

cuales no están todas interrelacionadas, es posible utilizar este método para agrupar sólo

aquellas aplicaciones que han de ser reenviadas de forma persistente hacia un mismo

servidor (6.5). De esta manera, es posible agrupar por ejemplo los servicios http y SSL


ofreciéndolos por la VIP1. Si nos interesa también que http corra separadamente a SSL es

posible ofrecer este servicio individualmente por otra VIP.

Conexiones Concurrentes

Este método está especialmente diseñado para aplicaciones como el passive-FTP. El

servicio FTP pasivo funciona de la siguiente manera. En primer lugar, el cliente establece

una conexión TCP al puerto 21 del servidor. A ésta se le llama conexión de control, y es

utilizada para indicarle al servidor los comandos que queremos ejecutar. Cuando el cliente

envía el comando PASV, el servidor selecciona un puerto arbitrario, por encima del puerto

1023, y se lo envía al cliente. Este puerto del servidor, será el utilizado por el cliente para

iniciar la conexión TCP para la transmisión de los datos. Por el contrario si se utiliza

active-FTP, entonces es el servidor el que utiliza un puerto especificado por el cliente para

iniciar la conexión de datos con él.

El método basado en IP origen y VIP es suficiente para permitir el correcto funcionamiento

del servicio FTP pasivo, como contrapartida, todas las conexiones de ese cliente serían

reenviadas al mismo servidor real, cuando en realidad tan sólo se requeriría que lo fuesen

la conexión de control y la de datos. El método concurrente resuelve este problema de la

siguiente forma. Cuando llega una petición con una determinada IP origen hacia la VIP, el

balanceador mira si existe una entrada en la tabla de sesiones, de no ser así, crea una

entrada y selecciona un servidor real para esa conexión. La siguiente conexión que se

establezca desde el cliente será, lo mas probable, la petición de conexión para el canal de

datos FTP. El balanceador interpreta eso y reenvía esa conexión hacia el mismo servidor

real. El resto de conexiones de ese cliente serán reenviadas a otro servidor real.

El Megaproxy problem

En algunas ocasiones la dirección IP origen del cliente no es suficiente para identificar a un

usuario en concreto. Generalmente, los ISP y muchas empresas tienen servidores proxy

desplegados en sus redes. Cuando los usuarios de estas redes salen a Internet, lo hacen a

través de un servidor proxy. El término megaproxy se utiliza para describir a potentes

servidores proxy de algunas grandes empresas que son utilizados por miles o incluso

cientos de miles de usuarios en grandes redes empresariales. Este tipo de escenarios

pueden plantear dos tipos de problemas para el balanceador de carga.

ACADE (LVS) - 29

El primero de ellos, se produce cuando un mismo usuario de este tipo de redes establece

dos o más sesiones con el balanceador de carga y éstas salen de su red a través de

servidores proxy diferentes.

Cliente 1

Cliente 3

Cliente n

Cliente 2

Cliente 4

Usuario

Balanceador de carga

ServidoresProxy

Internet

TCP SYN 1

TCP SYN 2

TCP SYN 1

TCP SYN 2

Red interna con múltiples servidores proxy

Las dos peticiones de conexión provienen del mismo cliente, sin embargola persistencia en función de la IP origen no funciona correctamente ycada conexión es tratada independientemente sin aplicar persistencia desessión.

Figura 6: Megaproxy problem, caso 1.

En estos casos, el balanceador de carga recibe el primer paquete TCP SYN y añade una

entrada en la tabla de sesiones. La segunda conexión proviene del mismo cliente, por lo

que debería ser asignada al mismo servidor real que la primera. Sin embargo, esto no

sucede así, ya que el proxy cambia la IP origen del cliente (privada) por su IP (pública).

Dado que cada petición ha salido por un servidor proxy diferente, el balanceador interpreta

erróneamente que ambas conexiones han sido iniciadas desde clientes distintos.

Resolver este problema pasa por detectar las direcciones IP origen de los servidores proxy

de esa red y agruparlos bajo un mismo origen virtual (virtual source). Este método de

persistencia agrupa todas esas direcciones para ser tratadas como un mismo origen virtual.

El segundo problema viene planteado por aquellos casos en los que muchos clientes de una

red situada tras un megaproxy, acceden a los servicios ofrecidos por el balanceador de

carga. Aunque estos clientes utilicen todos el mismo servidor proxy es posible que esto

represente un problema para el sistema balanceador.


Cliente 1

Cliente 2

Cliente n

Cliente A

Cliente B

ClienteC

ServidorProxy

Internet

TCP SYN A

TCP SYN B

Red interna con múltiples servidores proxyenviando peticiones de conexión albalanceador de carga

Todas la conexiónes se asignan al mismo balanceador de carga si ésteutiliza un mecanismo basado en IP origen.

TCP SYN 1C

TCP SYN 2C

Balanceadorde carga

TCP SYN A

TCP SYN B

TCP SYN 1C

TCP SYN 2C

Figura 7: Megaproxy problem, caso 2.

Dado que el método implementado por el balanceador de carga toma las decisiones de

reenvío en base a la dirección IP origen de los paquetes, y que estos tienen todos la misma

IP, todas las conexiones son asignadas al mismo servidor real. Mientras el tráfico

proveniente de ese servidor proxy no represente un porcentaje muy elevado, del total de

tráfico balanceado por el servidor virtual, no representará un problema serio.

3.8.3 Métodos basados en la aplicación

Vinculación retardada (Delayed Binding)

Los métodos de reenvío basados en la dirección IP origen de los paquetes, toman la

decisión de hacia dónde reenviar los paquetes, tras recibir el primer paquete TCP SYN de

una petición de conexión. Posteriormente, el resto de paquetes pertenecientes a esa

conexión son reenviados al servidor real seleccionado. El método delayed binding, mira la

información de aplicación contenida en los paquetes subsiguientes al de petición de

conexión. En la información de aplicación, existe información que puede ayudar al

balanceador a tomar una decisión de reenvío más inteligente. En una aplicación web, por

ACADE (LVS) - 31

ejemplo, las peticiones HTTP contienen URLs y cookies que el balanceador puede utilizar

para seleccionar el servidor real más apropiado.

El método de vinculación retardada, requiere que el balanceador de carga rescriba los

números de secuencia de las cabeceras TCP de los paquetes que balancea. En la figura 2

del apartado (3.5) se muestra el proceso de establecimiento de la conexión TCP, más

conocido como saludo a tres vías. En la misma figura, también se observa como funcionan

los números de secuencia de las cabeceras TCP intercambiados entre el cliente y el

servidor. Dado que el balanceador de carga espera a ver el contenido de los paquetes

siguientes al que establece la conexión antes de tomar la decisión de reenvío, ha de ser él el

que acepte y, por lo tanto, establezca las conexiones con los clientes. Cuando el

balanceador ya tiene la información necesaria para vincular la conexión del cliente a un

servidor real, será él el encargado de establecer una segunda conexión con el servidor real

asignado. Dado que el primer número de secuencia de la conexión TCP es aleatorio y

depende de la pila TCP/IP, el número que genera el balanceador de carga no coincidirá con

el que responda el servidor real seleccionado. Es por esto que el balanceador deberá

traducir los números de secuencia de todos los paquetes que le lleguen desde el cliente,

para que concuerden con los números de secuencia generados en la segunda conexión con

el servidor real. Este proceso puede llegar a cargar mucho al balanceador de carga, ya que

ahora ha de realizar además la traducción de los números de secuencia para cada uno de los

paquetes reenviados. Este proceso repercute también en unas necesidades de memoria

mayores en el balanceador.

Cookies

Cuando la aplicación a ofrecer por el balanceador de carga es un servicio http, es posible

implementar, gracias a la técnica de delayed binding y a la utilización de cookies, métodos

de balanceo que solventen el problema de los grandes servidores proxy.

Las cookies son variables enviadas por el servidor web al cliente en la cabecera HTTP.

Estas variables son manejadas por el navegador del cliente y almacenadas en el disco duro

de éste, y son enviadas dentro de las cabeceras HTTP de las siguientes peticiones que el

cliente efectúe para comunicarse con el servidor.


Cookie switching

Con el método de vinculación retardada, el balanceador de carga es capaz de entender las

cabeceras HTTP, y por lo tanto, las cookies de las peticiones de los clientes. El balanceador

puede, a partir de este momento utilizar uno de estos tres métodos de balanceo basado en

cookies (cookie switching): cookie-read, cookie-insert o cookie rewrite, para solucionar el

problema de los clientes situados tras grandes servidores proxy.

Cookie-read

Este método requiere en que el servidor web, de cada uno de los servidores reales, envíe

una cookie cada vez que éste acceda por primera vez a sus servicios. Posteriormente el

balanceador mira la cookie enviada por el cliente a partir de ese momento. La cookie

enviada por el servidor al cliente ha de servirle al balanceador para identificarlo, en base a

la cookie enviada por el servidor. De esta manera en lugar de identificar al cliente mediante

la dirección IP origen, se hace mediante la cookie. Este método no carga excesivamente al

balanceador, pero requiere que se modifique la página alojada en cada uno de los

servidores reales. Cada vez que se requiere añadir un nuevo servidor real al cluster, será

necesario retocar el código del sitio web a fin de adecuarlo a este método, por lo que las

capacidades de escalabilidad del sistema se ven mermadas.

Cookie-insert

Con este método no es necesario retocar el código del sitio web, ya que ahora no es el

servidor real el que envía la cookie al cliente, sino que lo hace el balanceador de carga.

Ahora, el balanceador reenvía la conexión a un servidor, y en la respuesta al cliente inserta

una cookie identificando el servidor asignado. Este método tiene como ventaja el que no es

necesario reprogramar las aplicaciones web, y tiene como inconveniente la sobrecarga que

produce en el balanceador. Además, podría surgir un problema al sobrepasar el tamaño

máximo permitido del paquete, siendo éste un problema de difícil solución.

Cookie-rewrite

Una solución más equilibrada es el cookie-rewrite, solución que está a medio camino entre

el cookie-read y el cookie-insert, aportando las ventajas de ambas. Mediante este método,

no se carga tanto al balanceador como con el método de cookie-insert, ya que no hay que

guardar los paquetes enteros en memoria para proceder a insertar la cookie. El servidor es

ACADE (LVS) - 33

el encargado de enviar la cookie al cliente, pero no determina el valor de esta variable,

simplemente lo establece en un número determinado de caracteres por ejemplo: (server =

XXXX). El balanceador es entonces el encargado de asignarle un valor a esta cookie,

sabiendo que éste deberá de ser de 4 dígitos para no alterar el tamaño final del paquete. De

esta manera, al no ser necesario guardar todo el paquete en memoria, se reducen

considerablemente los requerimientos de capacidad de proceso del balanceador.

3.9 Balanceadores de carga de alta disponibilidad

Los balanceadores de carga aportan, además de escalabilidad, la alta disponibilidad de los

servicios ofrecidos por los servidores reales. El problema que introduce el balanceador de

carga es que se convierte en un elemento vital en la prestación del servicio. Por lo que si

éste fallase, todo el sistema se vendría abajo. Nuevamente, la solución consiste en redundar

el elemento crítico del sistema para la prestación del servicio, el balanceador de carga.

Tradicionalmente, en networking se recurre a protocolos como el Virtual Router

Redundancy Protoco, (VRRP) [6], el cual permite a varios routers hacerse de backup unos

a otros. El diseño de sistemas de balanceadores de alta disponibilidad, se basa en conceptos

similares en los que se basa VRRP.

A fin de ofrecer alta disponibilidad, es posible disponer de dos balanceadores de carga

trabajando conjuntamente, bien en configuraciones en las cuales un balanceador hace de

backup del activo (activo/pasivo), o bien en configuraciones activo/activo, en las cuales los

dos balanceadores están balanceando tráfico, pero cualquiera de ellos puede asumir el

trabajo de su compañero en caso de que falle. Este tipo de arquitecturas reciben el nombre

de High-Availability (HA) clusters o clusters de alta disponibilidad. Los clusters o sistemas

de alta disponibilidad, en los cuales el servicio de alta disponibilidad es el balanceador de

carga, a menudo reciben el nombre de HA IP Clusters o HA Aplication Clusters, en

función de si utilizan balanceadores de carga basados en IP Origen o bien balanceadores de

carga de nivel de aplicación.


Una primera topología básica de un HA IP Cluster activo/pasivo podría ser la siguiente:

Internet

iMacCliente

Granja deServidoresReales 1


Balanceadorde carga 2(Pasivo)

Balanceadorde carga 1

(Activo)

RouterVIP VIP

Aquitectura de Alta disponibilidad 1( Cluster Activo/Pasivo )

Figura 8: Cluster de alta disponibilidad activo/pasivo.

En ella, cada balanceador de carga tiene su propia granja de servidores reales, esta

configuración simplifica algunos aspectos de la configuración, si bien infrautiliza los

equipos de red, ya que dispone de una granja de servidores completa de backup.

ACADE (LVS) - 35

Una arquitectura activo/activo básica podría tener un aspecto similar al que muestra la

siguiente figura:

Internet

iMacCliente




(Activo)


(Activo)

Router

Aquitectura de Alta disponibilidad 2( Cluster Activo/Activo )

Figura 9: Cluster de alta disponibilidad activo/activo.

Este tipo de arquitectura aprovecha mejor los recursos de red que la arquitectura anterior,

por otra parte la complejidad del sistema también aumenta.


La siguiente arquitectura combina aspectos de las anteriores dos:

Internet

iMacCliente

ServidoresReales


VIP 1InactivaVIP 2 Activa


VIP 1 ActivaVIP 2 Inactiva

Router

Aquitectura de Alta disponibilidad 3( Cluster Activo/Activo)

Switch

Figura 10: Cluster de alta disponibilidad activo/activo optimizado.

Dispone de dos balanceadores de carga activos, si bien cada uno de ellos trabaja con VIPs

activas diferentes, de manera que sólo se hacen cargo de la VIP del otro balanceador en

caso de fallo de éste. Por otra parte, la granja de servidores ahora es común a los dos

balanceadores, con lo cual no se desaprovechan equipos.

ACADE (LVS) - 37

Finalmente, es posible encontrar arquitecturas más complejas (figura 11), que redundan

también los routers de salida hacia Internet. Además, en este ejemplo, el balanceador

dispone de una interfaz de salida para cada uno de los servidores reales.

Internet

iMacCliente

ServidoresReales

Balanceadorde carga 2(Pasivo)


(Activo)

Router 1

VIP VIP

Aquitectura de Alta disponibilidad 4( Cluster Activo/Pasivo )

VRRPRouter 2

Figura 11: Cluster de alta disponibilidad activo/activo optimizado 2.


ACADE (LVS) - 39

4. Clustering y bases de datos

Cuando se trabaja con arquitecturas de clustering de alta disponibilidad y escalabilidad,

uno de los principales problemas que se pueden plantear a menudo, tendrá que ver con el

almacenamiento de los datos. Estos problemas aparecen tanto en los sistemas de clustering

de alta disponibilidad de IP como en los sistemas basados en balanceadores de carga.

Existen dos tipos de situaciones bien diferenciadas. Por un lado tenemos aquellos

escenarios en los cuales el cliente del servicio, únicamente realiza una lectura de los datos,

como se muestra en la figura 12, por otro lado, estarían aquellas aplicaciones

transaccionales en las cuales el cliente ha de poder modificar o escribir datos.


Balanceadorde carga

Data Data Data Data Data= = =

Cluster de Servidores de Aplicación Servidores de Aplicación Balanceados

Se rvidore sde

Aplicacion

Data

Dispositivode a lmacenamiento

compartido

Figura 12: Clustering y bases de datos.

40 - Capítulo 4: Clustering y bases de datos

Estas dos situaciones plantean problemas diferentes en función del método utilizado para

intentar solventarlas. Una estrategia puede ser la utilización de dispositivos de

almacenamiento compartidos por todos los miembros del cluster, lo que implica introducir

un único punto de fallo para todo el sistema. La otra, pasa por dejar que cada nodo

disponga de sus propios datos y recurrir a dispositivos de mirroring, o bien replicar los

datos periódicamente, reparando la posible inconsistencia que se puede producir en los

mismos.

El siguiente cuadro (tabla 1), muestra las tres estrategias principales para garantizar la

disponibilidad e integridad de los datos en los sistemas de clustering de alta disponibilidad.

Mecanismos para garantizar los datos o la disponibilidad de almacenamiento tras una caída Descripción Ventajas Inconvenientes

Mirroring

Cada servidor almacena sus propios datos; Los servidores realizan operaciones de copiado constantes para conseguir la sincronización de los datos.

Alta velocidad de recuperación de datos tras un desastre.

Alta sobrecarga de la red y del sistema para realizar las operaciones de sincronización. Posibilidad de perdida de algunos datos cuando ocurre un fallo.

No Compartir Nada

Los servidores están conectados con un sistema autónomo de almacenamiento compartido, pero posen además su propios sistemas RAID. Durante una fallida, el nodo superviviente asume la propiedad de los discos y servicios del servidor fallido.

Mínima sobrecarga de red para mantener la consistencia de datos del cluster.

Requiere conexiones redundantes y tecnología RAID para prevenir que el sistema de almacenamiento autónomo se convierta en un único punto de fallo que pueda afectar a la integridad de todo el sistema.

Compartirlo Todo

Los servidores comparten el acceso simultáneo al mismo disco.

Mínima sobrecarga de red para mantener la consistencia de datos del cluster.

Requiere conexiones redundantes, tecnología RAID, y un complicado sistema de control en el acceso a los datos para poder mantener su integridad.

Tabla 1: Características de las diferentes estrategias en el acceso a datos.

ACADE (LVS) - 41

Parte 2: Software libre para Arquitecturas de Clustering de Alta

Disponibilidad y Escalabilidad (ACADE).

5. El software libre como motor de desarrollo social Basado en la conferencia ¿Qué es el software libre? Dentro de las I Jornadas de Software libre en Baleares. Impartida por

Jesús González Barahona, Profesor Titular de la Universisda Rey Juan Carlos de Madrid, Departamento de Ciencias

Experimentales e Ingeniería.

El modelo en el que se basa la industria del software de hoy día, difiere notablemente del

marco con el que funcionan el resto de industrias “tradicionales”. Las licencias actuales de

software, son en gran medida las responsables de esta situación, pues en el marco actual de

soluciones software propietarias, las regulaciones sólo afectan al usuario, que está obligado

a cumplir lo establecido en la licencia del software que utiliza, quedando la empresa

desarrolladora exenta de cualquier responsabilidad.

En la industria tradicional es imposible pensar en una situación de esas características. Por

ejemplo, cuando una empresa fabricante de coches vende un modelo al usuario, la empresa

ha de fabricar el mismo en base a una estricta normativa que asegure la calidad y seguridad

del producto. El cliente se compromete a utilizar el producto en base a lo que dictan las

normas de circulación y la empresa, por otro lado, ofrece unas garantías si el cliente hace

un uso normal del vehículo. En cambio, una licencia de software sólo implica compromiso

por parte del usuario: no utilizar el software en más de una máquina o en máquinas

diferentes con solo una licencia etc. Esto da lugar a situaciones poco razonables en las que

un usuario debería pagar dos licencias para instalar un mismo programa, dos veces, en

máquinas de su propiedad. El modelo libre establece sus propios mecanismos naturales

para evitar situaciones monopolistas.

El software libre no se ajusta al modelo actual de industria de software, ni en el modelo de

ingeniería de software, utilizado para su desarrollo, ni en el tipo de las licencias utilizadas

para su distribución. Del modelo de desarrollo utilizado se sabe muy poco, básicamente

que es está distribuido globalmente y que el resultado funciona, en tanto que es un hecho

que algunos programas libres funcionan igual o mejor que soluciones propietarias.

42 - Capítulo 5: El software libre como motor de desarrollo social

Actualmente existen dos grandes corrientes en el mundo del software libre. Por un lado la

liderada por Richard M. Stallman, creador de la Free Software Fundation (FSF), y por el

otro la promovida por el movimiento Open Source. La primera basa sus motivaciones en

consideraciones éticas, la segunda en motivos prácticos. En cualquier caso las dos

confluyen el hecho de utilizar el mismo software.

El software libre establece un modelo de costes diferentes al tradicional. Si la empresa

utiliza el modelo propietario se le va todo el dinero en licencias, por el contrario, si la

empresa utiliza el modelo libre, se gastará el dinero en personal o en empresas de soporte

locales.

¿Qué es software libre?

Software libre es aquel software que cumple las siguientes cuatro características:

1. Libertad de uso

Los programas distribuidos bajo una licencia libre, permiten al usuario utilizar en la forma

que considere más oportuna y dándole plena libertad para que lo desee instalar, y hacerlo

en tantos sistemas como quiera.

2. Libertad de redistribución

El autor permite la libre distribución del programa conjuntamente con la de su código

fuente y su licencia. Copiar software libre no es ilegal, sino que además, es deseable y

contribuye a su divulgación.

3. Libertad para la modificación del código

Cualquier usuario tiene plena libertad para modificar el código fuente del programa. Esto,

trasladado a un entorno empresarial permite adaptar el programa a las necesidades

especificas de la empresa, en cambio, si la empresa opta por una solución propietaria, y

ACADE (LVS) - 43

esta no se ajusta del todo a sus necesidades, deberá esperar a que la empresa

suministradora de ese software decida implementar las características nuevas que la

empresa requiere, si es que esta lo hace. Por otro lado, eso permite que cualquier empresa

pueda dar soporte a un programa libre, si dispone de programadores preparados para ello,

pese a no ser la creadora del programa. Así, dado que existen diferentes empresas que den

soporte a un determinado programa, un empresario podría, eventualmente, cambiar de

empresa si no está satisfecho con el soporte obtenido. En el escenario actual, en el cual las

empresas suelen disponer de cuotas de mercado del 80% ó 90% para un determinado

producto, esto no es posible ya que se depende de la empresa creadora para el soporte a su

producto.

4. Libertad para redistribuir las modificaciones

Siempre y cuando las modificaciones se hagan también bajo una licencia libre, cualquiera

puede seleccionar un puñado de software y redistribuirlo a aquellas empresas capaces de

añadir sustanciales mejoras obteniendo mayor cuota de mercado, ya que software libre no

implica que no se pueda cobrar por su distribución. Es entonces cuando aparece la

competencia entre distribuciones y distribuidores que redundan en beneficio del usuario.

44 - Capítulo 5: El software libre como motor de desarrollo social

ACADE (LVS) - 45

6. Balanceadores de carga libres

Este capítulo se centra de manera especial en el balanceador de carga del proyecto Linux

Virtual Server. Por otro lado, también se mencionan otros proyectos enfocados a

proporcionar sistemas de balanceo de carga de código abierto sobre otras arquitecturas

libres.

6.1 Linux Virtual Server Project

Linux Virtual Server Project centra sus esfuerzos en proporcionar un servidor virtual

altamente escalable y de alta disponibilidad sobre Linux, denominado Linux Virtual Server

(LVS). IP Virtual Server (IPVS) es el software con el que se implementa LVS. IPVS es un

balanceador de carga de capa de transporte. En mayo de 2000 y dentro del marco de

trabajo que se venía desarrollando en el proyecto LVS, se empieza el desarrollo en paralelo

de un balanceador de carga de nivel de aplicación llamado Kernel TCP Virtual Server

(KTCPVS).

Por razones históricas se asocia LVS con el balanceador de carga IPVS, utilizándose

ambos términos indistintamente para referirse al servidor virtual Linux de capa transporte.

Pese a que KTCPVS es también un balanceador que permite implementar un servidor

virtual Linux (LVS), nos referiremos a él cómo balanceador de carga de aplicación.

Quedando reservado el término LVS para el balanceador de carga de capa de transporte.

6.2 ¿Qué es LVS?

Linux Virtual Server (LVS) es un cluster de máquinas que se muestran como un único

servidor a los clientes. Este aparentemente único servidor es llamado “servidor virtual”. A

los servidores integrantes del clúster se los conoce como realservers o servidores reales, y

están bajo el control del balanceador de carga conocido como director. LVS se implementa

mediante el parche para el kernel de Linux IP Virtual Server (IPVS).

46 - Capítulo 6: Balanceadores de carga libres

6.2.1 LVS, 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

realservers para que sea atendida. A partir de entonces, todos los paquetes del cliente,

pertenecientes a esa conexión, atravesarán el director hacia un realserver en particular. La

asociación entre el cliente y el realserver 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. Para la siguiente petición de conexión TCP, el director

escogerá otro servidor real que podría o no ser el mismo que el de la conexión anterior.

Para decidir cual de estos servidores ha de ser el destinatario de esta nueva conexión, el

director dispone de un abanico de conjuntos secuenciales de normas, o algoritmos de

scheduling. Por ejemplo, este algoritmo podría basar sus decisiones en aspectos como la

carga (número de conexiones establecidas, tráfico soportado, etc) de cada servidor, o

simplemente en el hecho de intentar realizar un reparto equitativo de las peticiones de

conexión entre todos los servidores del cluster.

Se entiende por un balanceador de carga con capacidades stateful, a aquel que es capaz de

entender y hacer un seguimiento de los paquetes que pertenecen a las conexiones que está

reenviando. En ocasiones, un servicio requiere que todas las conexiones TCP/UDP que se

realizan durante la prestación del mismo (sesión), sean procesadas por el mismo

realserver.

LVS dispone de algunas capacidades stafeful pese a ser un balanceador de carga de capa de

transporte basado en IP origen. El director tiene conocimiento del inicio y finalización de

las conexiones TCP/UDP, así como de los puertos y direcciones IP, si bien desconoce lo

que se están diciendo las aplicaciones en capas superiores. Para garantizar la persistencia

en la que se requiere ver más allá de la capa 4, es decir, cuando todos los paquetes de una

sesión han de ser reenviados al mismo realserver para la correcta prestación del servicio,

LVS permite crear reglas para garantizarla en servicios como ftp o https. Dado que LVS no

tiene conciencia de lo que pasa más allá de la capa de transporte, cuando se requiere

ACADE (LVS) - 47

aplicar persistencia más allá de esa capa, se le debe indicar a LVS el tipo de servicio que se

deberá prestar de forma persistente. LVS se basará entonces únicamente en la IP y el

puerto para crear las reglas que aseguren la persistencia de esos servicios. Las indicaciones

que fuerzan la persistencia de los servicios que la requieren, se le proporcionan a LVS en

el momento de introducir las reglas que definen su comportamiento véase ipvsadm (6.7).

Para los servicios que no necesitan persistencia, como por ejemplo contenido web estático

que no establezca sesiones mediante cookies, podría darse el caso de que el navegador web

que conecta con un site de estas características, hospedado en el LVS, obtenga los

diferentes objetos que conforman la web (código HTML e imágenes) de realservers

distintos.

Hay tres tipos de topologías en LVS, que se diferencian entre ellas, no sólo en como se

interconectan los nodos, sino también en la técnica que utiliza el director para el reenvío de

paquetes. Las topologías posibles en función del método de reenvío son: LVS-NAT(6.3.1),

LVS-DR(6.3.2) y LVS-TUN(6.3.3).

Cabe la posibilidad de implementar una arquitectura LVS que disponga de más de un

balanceador de carga (IPVS). En este tipo de soluciones de alta disponibilidad, con un

balanceador principal (master) y los otros de reserva (backup), sólo uno de ellos está

funcionando como activo. El resto de los balanceadores permanecen a la espera por si un

fallo en el servicio, o una detención voluntaria por parte del administrador del sistema, les

obligara a entrar en acción para sustituir al master. LVS dispone de un mecanismo de

migración de conexiones para evitar que las que ya están establecidas en el balanceador

master se pierdan, en el caso de que éste sea reemplazado por un balanceador de backup.

Para ello, LVS dispone de un demonio que envía periódicamente menajes multicast al resto

de los balanceadores, con el fin de que tengan convenientemente actualizadas sus

respectivas tablas de conexiones así como los servicios asociados a ellas. De esta forma, en

caso de relevo de un balanceador por otro, sólo se perderán aquellas conexiones que se

establecieron entre el envío del último mensaje multicast y el momento en el que se

produjo el fallo.


6.3 Métodos de reenvío soportados por LVS

LVS se implementa de tres formas posibles, LVS-NAT, LVS-DR y LVS-TUN, en función

del método de reenvío utilizado por el balanceador. NAT fue el primer método de reenvío

utilizado por LVS, se implementa mediante una red local. Su escalabilidad y rendimiento

no son los más elevados, pero la relativa facilidad, rapidez, y los bajos requerimientos

hardware, lo convierten en una opción interesante en aquellas situaciones en las cuales no

se dispone de un elevado número de nodos y elevada carga de tráfico. Sin salir del entorno

local, LVS-DR es el método que mayor rendimiento es capaz de desarrollar. Basa su

funcionamiento en técnicas avanzadas de enrutamiento directo (capa 2) y en el hecho de

que el flujo de tráfico de los clientes atraviesa el balanceador de carga en un solo sentido.

Fuera de este tipo de aplicaciones locales, LVS-TUN permite distribuir los nodos del

cluster a escala global, pudiendo ser cada uno de ellos, un cluster o centro de datos en si

mismo. Así como LVS-NAT se limitaba a rescribir las cabeceras IP de los paquetes y

LVS-DR a encapsular con las cabeceras de la capa de enlace de datos, LVS-TUN aplica

encapsulado IP.

6.3.1 LVS-NAT

Para una mayor comprensión del funcionamiento de un servidor virtual LVS-NAT, es

preciso remarcar que Port Address Translation (PAT) es la variante de NAT utilizada en

Linux, y por lo tanto en LVS. Así mismo, es posible recurrir a diferentes topologías de red

que permitan implementar NAT (figura 13).

ACADE (LVS) - 49

ServidoresReales

Switch

Balanceadorde

Carga

ServidoresReales

SwitchBalanceadorde

Carga

Internet

Router

iMac

LVS-NAT 1 LVS-NAT 2 (Acade)

Internet

Router

iMac

Figura 13: LVS-NAT.

Network Addres Translation (NAT) en Linux

Dada la escasez de direcciones IP en IPv4 y por motivos de seguridad, cada vez más redes

están utilizando direcciones privadas (como 10.0.0.0/8, 172.16.0.0/12 y

192.168.0.0/16 ) las cuales no pueden ser utilizadas en Internet. La necesitad de

realizar Network Addres Translation (NAT) se manifiesta cuando los hosts de una red

interna quieren acceder y ser accesibles desde Internet.

NAT es la característica gracias a la cual un grupo de direcciones IP son mapeadas con

otro. Cuando el mapeo de direcciones es de N-a-N, es llamado NAT estático; cuando el

mapeo es M-a-N (M mayor que N), NAT dinámico. Network Addres Port Pranslation

(también conocido como PAT) es una extensión del NAT básico, en dónde varias

direcciones de red y sus respectivos puertos TCP/UDP son traducidos a una sola dirección

de red y a su respectivo puerto. Éste es el tipo de mapeo con el que Linux IP Masquerading

fue implementado, y además es el utilizado por LVS-NAT. Una descripción más detallada

sobre NAT está disponible en el RFC1631 [2].


Funcionamiento de LVS-NAT

Cuando un paquete llega al balanceador de carga, éste le examina la IP y el puerto, y si

coinciden con alguno de los servicios definidos en la tabla de reglas del servidor virtual del

balanceador de carga, entonces será reenviado hacia uno de los servidores reales en

función de un algoritmo de scheduling. Para efectuar el reenvío, el balanceador de carga

deberá rescribir la dirección IP de la cabecera del paquete por la del servidor real que

corresponda. Esta nueva conexión, es añadida como una nueva entrada en la tabla hash

(tabla de sesiones) del director, y permanecerá en ella hasta que la conexión finalice o bien

ésta haya excedido los tiempos máximos de inactividad. Cuando un paquete de respuesta

realiza el camino inverso, el balanceador de carga rescribe la dirección origen para que ésta

sea la de la interfaz externa del balanceador de carga (VIP).

A continuación se muestra un ejemplo que describe el funcionamiento de LVS-NAT a la

hora de rescribir los paquetes.

Si el balanceador de carga está configurado para ofrecer los siguientes servicios virtuales:

Protocolo VIP Puerto Dirección IP del servidor real Puerto Peso

192.168.10.101 80 1 TCP 192.168.3.150 80

192.168.10.102 80 1

192.168.10.101 21 2 TCP 192.168.3.150 21

192.168.10.102 21 1

Cualquier paquete que llegue al balanceador de carga con la IP 192.168.3.150 y los

puertos 80 ó 21, sufrirá un cambio de la IP por la del servidor real que corresponda. Véase

esto en el siguiente ejemplo:

Supóngase la recepción por parte del balanceador de carga del siguiente paquete:

IP / Puerto ORIGEN

202.50.63.127:2314

IP / Puerto DESTINO

192.168.3.150:80

ACADE (LVS) - 51

El balanceador de carga lo identifica como un paquete que solicita un servicio virtual

configurado, y por tanto seleccionará un realserver, rescribiendo la cabecera IP para

reenviarlo de esta manera:

IP / Puerto ORIGEN

202.50.63.127:2314

IP / Puerto DESTINO

192.168.10.101:80

Cuando el servidor real conteste, lo hará reenviando un paquete de vuelta al balanceador de

carga con una cabecera IP como la que se muestra a continuación:

IP / Puerto ORIGEN

192.168.10.101:80

IP / Puerto DESTINO

202.50.63.127:2314

En el balanceador de carga, el paquete se vuelve a rescribir para enviarlo de vuelta al

cliente quedando de la siguiente manera:

IP / puerto ORIGEN

192.168.3.150:80

IP / Puerto DESTINO

202.50.63.127:2134

6.3.2 LVS-DR

Introducción

LVS-DR está basado en NetDispatcher de IBM, el cual presenta a un conjunto de

máquinas que ofrecen servicios de red como si de una sola se tratase. Esta tecnología se

utilizó para proporcionar servicios http en las olimpiadas de Atlanta y de Sydney, por lo

que destaca como una solución capaz de servir un gran volumen de peticiones. También se

utilizó para retransmitir vía web la partida de ajedrez entre Kasparov y la máquina Deep

Blue.

LVS-DR aporta dos considerables mejoras en las prestaciones que ofrece LVS-NAT. La

primera de ellas, consiste en un nuevo método de reenvío en el cual el director no necesita

rescribir la cabecera IP de los paquetes antes de reenviarlos, puesto que se limita a


encapsular los paquetes IP con las direcciones de Control de Acceso al Medio (MAC),

dejando inalterada la cabecera IP original. La segunda mejora radica en que los paquetes

de respuesta de los servidores, en su camino de regreso al cliente, no atraviesan el director

sino que van directamente al cliente, y se consigue porque los clientes en sus respuestas

ponen la VIP como origen de las mismas, resultando innecesario realizar NAT inverso.

Una configuración más avanzada de LVS-DR permite a cada servidor real disponer de un

enlace exclusivo de retorno al cliente. En la configuración de mayor rendimiento teórico,

cada servidor real está conectado a su propio router de salida. Estas dos mejoras se

traducen en un considerable aumento de las prestaciones del servidor virtual.

Para formarse una idea intuitiva de las diferencias de rendimiento entre LVS-DR y LVS-

NAT, podría establecerse una analogía entre LVS-NAT y un router (capa3), y LVS-DR y

un switch (capa 2). LVS-NAT rescribe las cabeceras IP antes de encapsular a nivel de capa

de enlace, mientras que LVS-DR se limita a encapsular directamente a nivel de capa de

enlace sin modificar las cabeceras IP originales.

Prerrequisitos de LVS-DR

- El cliente debe poder conectar con la VIP del director.

- LVS-DR utiliza el mismo medio físico para el conexionado de todos sus nodos.

Todas las máquinas integrantes del cluster deben poder enviarse entre ellas peticiones

ARP, lo cual implica que todas están en la misma red sin dispositivos de rutado por medio,

por lo que comparten el mismo segmento de la capa de enlace. En otras palabras

comparten el mismo “cable”. Los paquetes se enviarán del balanceador de carga a los

servidores reales empaquetándolos únicamente con una dirección MAC, sin rescribir la

cabecera IP.

La ruta que siguen los paquetes de respuesta no pasa a través del balanceador de carga,

sino que va de los servidores reales directamente al cliente sin pasar por el director. Para

requerimientos de alta capacidad de transferencia, cada servidor real puede disponer de su

propio router o conexión hacia el cliente o Internet.

ACADE (LVS) - 53

director

rserver2rserver1 rserver3

CIPs

Internet

router routerrouterrouter

Figura 14: Topología LVS-DR.

Para implementar LVS-DR es necesario forzar un comportamiento atípico al que realizan

los protocolos de la capa de enlace de datos de la pila TCP/IP, en lo que a resolución de

direcciones MAC se refiere (ARP).

Funcionamiento de LVS-DR

El funcionamiento de LVS-DR guarda numerosas similitudes con el método DSR (3.7.2)

abordado en la parte teórica de esta misma memoria.

Así, todas las máquinas del cluster tienen asignadas en sus interfaces la misma IP virtual

(la VIP), con la salvedad de que sólo la interfaz del director responde a las peticiones ARP.

Para ello, es necesario que las interfaces con la VIP de los servidores reales no respondan a

peticiones ARP (mediante interfaces virtuales: loopback, dummy o tun). De esta manera,

el router de entrada sólo tiene conocimiento de la dirección MAC del director por lo que


los paquetes entrantes serán siempre enviados al balanceador. Posteriormente, él será el

encargado de redireccionarlos al servidor real que corresponda.

El dispositivo loopback (lo) no responde a peticiones ARP por defecto. Sucede así en casi

todos los sistemas operativos, excepto en Linux para las versiones 2.2.x, 2.4.x del kernel

(incluso cuando utilizamos la opción –noarp al configurar la interfaz con ifconfig).

Para saber más acerca de cómo solventar este problema y configurar dispositivos que no

respondan a peticiones ARP, en estas versiones del kernel de Linux, y los problemas que

de ahí se pueden derivar véase (6.3.4)

La VIP es la dirección IP encargada de ofrecer los servicios de red que ofrece el cluster,

por tanto, estos servicios se configuran en los servidores reales para recoger las peticiones

realizadas a esa IP. La VIP de los servidores reales está asignada a un dispositivo que no

responde a peticiones ARP (por ejemplo lo:0). ¿Cómo puede entonces el director

resolver la MAC asignada a la VIP para reenviar allí las peticiones? La solución es

sencilla: no lo hace. El balanceador no se configura para reenviar los paquetes

directamente a la VIP de los servidores reales, sino que se configura para hacerlo a las

MAC de las RIP de los mismos (eth0). El balanceador utiliza peticiones ARP para

resolver las direcciones MAC de las RIP con las cuales encapsular los datos para que

lleguen a los servidores reales. Cuando los paquetes llegan a los servidores reales, la capa

de enlace de datos de la capa OSI retira el encabezado MAC del paquete y se lo pasa a la

capa de red. Ésta ve que la dirección IP destino del paquete no se corresponde con la

dirección RIP de la interfaz por la que ha entrado (dado que el director no tocó la cabecera

IP, sólo encapsulo el paquete con la MAC), si bien, observa al mirar en su tabla de rutado

que la dirección destino (la VIP) es local, y reenvía el paquete a esa interfaz, que no es otra

que la interfaz virtual que no responde a peticiones ARP, de esta forma, el servidor real se

reenvía los paquetes a si mismo.

Cuando el paquete llega a la interfaz configurada con la VIP, el paquete es recibido por el

socket encargado de atender peticiones a ese puerto donde será procesado.

El software que ofrece el servicio de red que presta el servidor virtual y que recoge todo lo

que entra por la VIP, procesa el paquete recibido, genera la respuesta y la envía de vuelta

ACADE (LVS) - 55

al cliente por la VIP. Entonces la pila TCP/IP de Linux determina, en base a la dirección

destino del paquete (CIP) y a la tabla de rutado del sistema, que el paquete ha de ser

enviado al gateway por defecto para proseguir su camino de retorno al cliente. El gateway

por defecto está conectado a la segunda interfaz del servidor real, de manera que el paquete

retorna sin atravesar el director.

A continuación se muestra un ejemplo clarificador que explica de manera detallada cómo

trabaja LVS-DR:

El director recibe un paquete desde el cliente solicitando los servicios http que sirve el

cluster:

IP : Puerto ORIGEN IP : Puerto DESTINO Datos

CIP:3456 VIP:80 - El director consulta en la tabla de reglas del servidor virtual (IPVS) y tras aplicar el

algoritmo de scheduling pertinente, decide reenviar el paquete hacia la dirección RIP del

servidor real 1. El sistema operativo consulta entonces la cache ARP y si no encuentra en

ella la dirección MAC asociada a la RIP del servidor 1 lanzará una petición ARP

(broadcast ARP) para obtenerla.

Envabezado MAC Encabezdo IP Solicitud ARP

MAC origen (MAC DIP)

MAC destino Broadcast ARP(FF-FF-FF-FF-FF-FF)

IP origen(DIP)

IP destino(RIP)

¿Cuál es tu MAC?

Petición ARP (enviada por el director)

Envabezado MAC Encabezdo IP Respuesta ARP MAC origen (MAC RIP)

MAC destino Broadcast ARP (MAC DIP)

IP origen(RIP)

IP destino(DIP)

Esta es mi MAC (MAC RIP)

Respuesta ARP (enviada por el servidor real 1) El director, ahora, ya dispone de todos los datos necesarios para crear un paquete de capa

de enlace de datos como este:

MAC Origen MAC Destino Datagrama IP

IP : Puerto ORIGEN IP : Puerto DESTINO Datos MAC (DIP) MAC (RIP) CIP:3456 VIP:80 -


El paquete llega al servidor real, entonces la capa de enlace de datos retira la cabecera

MAC y entrega el paquete a la capa de red, la cual consulta su tabla de rutado y encuentra

que la VIP (destino final del paquete) es local. Entonces, la pila TCP/IP de Linux entrega

el datagrama al socket que está escuchando el dispositivo asociado a la VIP.

El servidor real procesa los datos localmente y genera un paquete de respuesta, el cual

tendrá unas cabeceras como estas:

IP:Puerto Origen IP:Puerto Destino Datos

VIP:80 CIP:3546 -

Acto seguido, el servidor real envía el paquete por la VIP, consulta su tabla de rutado y

decide que lo ha de enviar al gateway por defecto, por lo determina que el paquete deberá

salir a través de la interfaz (eth1) hacia el router/cliente. La respuesta no atraviesa el

director en su camino de regreso. El paquete le llegará al cliente con la VIP como

dirección origen, de manera que el servicio se ofrece de forma transparente al cliente que

no es consciente de que su petición ha atravesado o no el balanceador de carga.

6.3.3 LVS-Tun

Este método de reenvío permite implementar balanceadores de carga globales, es decir,

balanceadores de carga en los que los servidores reales pueden estar geográficamente

dispersos en diferentes redes. El balanceador crea túneles virtuales IP para reenviar los

paquetes a cada uno de los servidores reales del sistema balanceador. La utilización de esta

característica combinada con la utilización de protocolos como el VRRP permite crear

sistemas de alta disponibilidad más efectivos que otras soluciones como podrían ser el

Round-Robin de DNS y similares.

LVS-Tun está basado en LVS-DR y dispone de similares prestaciones en cuanto a

escalabilidad y capacidad. Si los servidores reales se encuentran en la misma red que el

director, entonces VS-DR y LVS-Tun son equivalentes en cuanto a términos de

rendimiento y facilidad de configuración. En LVS-Tun, el director o balanceador de carga

ACADE (LVS) - 57

encapsula los paquetes de petición dentro de un paquete IPIP (tunneling) antes de

reenviárselo al servidor real. El servidor real debe de ser capaz de desencapsular el paquete

IPIP, proceso que consiste en quitar el primer encabezado IP una vez que éste ha cumplido

su misión y posteriormente, utilizar el segundo. No todos los sistemas operativos son

capaces de manejar paquetes IPIP, por lo cual, es necesario que los sistemas operativos

utilizados en los servidores reales puedan hacerlo. En principio, son sólo los sistemas

operativos que utilizan un kernel Linux los capacitados para desarrollar correctamente esta

función, si bien con algunas pequeñas modificaciones, es posible utilizar sistemas

FreeBSD para implementar servidores reales en una arquitectura LVS-Tun.

Al contrario de lo que sucedía en LVS-DR, LVS-Tun permite que el director esté en una

red remota a la de los servidores reales, y que cada uno de estos pueda estar en redes

separadas e incluso que los servidores reales puedan estar en países diferentes. Si es este el

caso, los servidores reales deberán generar paquetes de respuesta con (VIP destinado a

CIP), no originados en la red VIP, con lo que los routers de los servidores reales deberán

ser reprogramados para aceptar paquetes con la dirección origen VIP. Los routers

normalmente eliminan estos paquetes como medida anti-spoofing, del mismo modo, los

servidores reales deberán contestar al cliente poniendo como dirección origen la VIP, lo

que puede representar un problema con algunos firewalls.

6.3.4 El problema con el Protocolo de Resolución de Direcciones (ARP)

El problema

Con LVS-DR y LVS-Tun, todas las máquinas, director y servidores reales, del LVS tienen

una dirección IP extra: la dirección IP virtual (VIP).

Cuando todas las máquinas y direcciones IP están en el mismo “cable”, todas comparten el

mismo segmento de la capa de enlace o dominio broadcast, por lo que pueden enviar

peticiones ARP a las demás. Si un cliente solicita una conexión a la VIP, deberá ser

entonces conectado a la VIP del director y no a la VIP de un servidor real, para ello, sólo

el director deberá contestar las peticiones ARP del router.


El director actúa como un router IP aceptando paquetes destinados a la VIP y enviándolos

posteriormente a un servidor real. El router por el cual el cliente accede al LVS, envía

peticiones ARP periódicamente para conocer la MAC asociada a la VIP y tener actualizada

de este modo su cache ARP, por lo que solamente el director deberá responder con su

MAC. Así, el router, tras recibir la respuesta ARP, enviará la petición de conexión al

director que, a su vez, la reenviará a uno de los servidores reales.

En cambio, si el router obtiene la dirección MAC de uno de los servidores reales en vez de

obtener la MAC del director, entonces los paquetes serán enviados directamente a ese

servidor real, ignorando el papel que debería desempeñar el director. Si los paquetes del

cliente son reenviados constantemente al mismo servidor real, el cliente estará teniendo

una sesión normal, ya que estará siempre conectado al mismo servidor real. Durante el

transcurso de la sesión, el router puede volver a enviar un broadcast ARP (petición ARP)

para mantener actualizadas sus tablas. 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 RESETs en respuesta a los paquetes de una

conexión ya establecida, por lo que esa conexión finalmente se perderá.

Resumiendo, si la dirección MAC del director es la que figura siempre en las tablas ARP

del router, ya que éste ha sido el primero en responder a tal petición (por tener una CPU

más rápida, por ejemplo), entonces el LVS funcionará siempre sin necesidad de cambios

en los servidores reales, si bien no es una solución deseable para un entorno de producción.

No todas las versiones del kernel Linux se comportan de igual forma ante peticiones ARP,

por lo que supone un problema en algunas ocasiones, especialmente con la versiones más

recientes del kernel. A continuación, se explica como abordar los diferentes problemas que

aparecen con las diferentes versiones del kernel.

El problema de los ARP se resuelve en kernels 2.0.x mediante la utilización de diversos

dispositivos que no responden a las peticiones ARP (por ejemplo dummy0,tunl0,

lo:0) en donde la VIP les puede ser asignada. Para otros sistemas operativos, el flag

ACADE (LVS) - 59

NOARP del comando ifconfig debería detener las respuestas ARP, a las peticiones

ARP, en los servidores reales. En cambio, con kernels linux 2.2.x ó 2.4.x, los dispositivos

que no respondían a peticiones ARP en versiones 2.0.x del kernel, ahora sí que lo hacen.

Existe una opción -arp (NOARP) para ifconfig que (de acuerdo con las paginas man)

desactiva las respuestas a las peticiones ARP en estos dispositivos, y la opción arp que

vuelve a activarlas otra vez. Linux no siempre respeta este flag. Por ejemplo, no pueden

activarse las respuestas a peticiones ARP en dispositivos dummy0 en versiones 2.0.36 del

kernel de Linux, y no pueden desactivarse para dispositivos tunl0 en versiones 2.2.x. El

dispositivo eth0 se comporta adecuadamente en versiones 2.0.36, pero en versiones 2.2.x

o 2.4.x, responde a peticiones ARP ¡incluso aunque se le especifique que no lo haga! Este

comportamiento de no respetar el flag NOARP en los kernels 2.2.x y 2.2.4 no es

considerado como un “problema” por aquellos que desarrollan el código TCP/IP de Linux,

por lo cual no es de esperar que esto vaya a cambiar.

Otra particularidad es que en los kernels 2.0.36, los dispositivos “alias”, por ejemplo

eth0:1, podían configurarse independientemente del dispositivo primario eth0. Así, el

dispositivo eth0:1 se comportaba como si estuviera en una tarjeta de red diferente. El

comportamiento frente a peticiones ARP de los dispositivos alias podía ser configurado de

manera independiente a como se configurase el dispositivo primario eth0. Con el kernel

2.2.x, los dispositivos alias son ahora sólo nombres alternativos. Si se cambia una opción

(por ejemplo -arp), activándola o desactivándola, para un alias (o para el dispositivo

primario), todos los dispositivos alias también modifican su configuración. Con los kernels

2.2.x la configuración de los dispositivos alias pertenece al dispositivo primario (es decir

es sólo un dispositivo con varias IPs).

Cuando LVS corría sobre máquinas con kernel 2.0.36, la VIP solía configurarse como un

alias (lo:0, tunl0) al dispositivo ethernet principal (eth0), permitiendo a los nodos

del LVS disponer de una única tarjeta de red.

Desde entonces, hay que tener cuidado cuando sólo se dispone de una sola tarjeta de red en

los servidores reales (lo mas usual). En un servidor real, con una sola tarjeta de red eth0,

configurada con la RIP, ésta debe contestar a peticiones ARP (para poder recibir paquetes).


Si se crea un alias eth0:1 ó lo:0 para soportar la VIP, éste también contestará a las

peticiones ARP, incluso si se configuró con –noarp mediante ifconfig. Resumiendo,

si un servidor real está corriendo sobre un kernel 2.2.x y tiene la VIP en un ip_alias,

entonces la VIP del servidor real contestará a las peticiones ARP recibidas, que fueron

enviadas anteriormente por el router.

Con kernels 2.4, la utilización de alias IP sigue estando disponible, si bien presenta las

mismas limitaciones que teníamos con los kernels 2.2.x. Por otro lado, las nuevas

herramientas que vienen con 2.4 (iproute2 e ip_tables) no reconocen alias, los cuales han

sido reemplazados por IPs secundarias.

Las soluciones

Puede abordarse el problema de los ARP de varias maneras, de entre las diferentes

soluciones posibles, destacarían los siguientes métodos.

Detener las respuestas desde los servidores reales ante peticiones ARP para resolver

la VIP.

- Configurar dispositivos para que no respondan peticiones ARP (NOARP

flag).

- Parchear las versiones 2.2.x ó 2.4.x del kernel.

Ocultar la VIP de los servidores reales para que estas no vean las peticiones ARP.

- Poner una Network Interface Card (NIC) extra en los servidores para

soportar la VIP.

- Poner los servidores reales en una red diferente a la de la VIP (Lars’

Metod)

- Cebar al router del director con la MAC correcta para la VIP (la de director).

- Hacer que los servidores reales contesten con la MAC del director.

- Detener las peticiones ARP a la VIP hechas a los servidores reales.

-Modificar tabla de routado del router.

ACADE (LVS) - 61

- Permitir a los servidores reales aceptar paquetes con una IP destino igual a la VIP,

incluso si el servidor real no tiene una interfaz con esa IP.

- Proxy Transparente, (Horms’ Method)

Configurar dispositivos para que no respondan peticiones ARP (NOARP flag)

Esta es la solución que se aplicaba en versiones 2.0.x del Kernel. Consistía en la

posibilidad de poder configurar diferentes dispositivos de manera que no respondieran a

peticiones ARP. Lo normal era utilizar estos dispositivos para soportar la VIP, por ejemplo

un alias al dispositivo loopback lo:0 al que asignarle la VIP. Actualmente, este

dispositivo ya no se comporta así. Actualmente, en los kernels 2.2.x y 2.4.x, si se asigna la

VIP al dispositivo loopback mediante un alias, y se envía una petición ARP a la VIP, ésta

contestará diciendo que su MAC es la del dispositivo eth0. Ver (anexo VII)

Esta solución es sólo aplicable en aquellas situaciones en las que los servidores reales están

corriendo versiones 2.0.x del kernel de linux, lo cual es poco probable si tenemos en cuenta

que la última versión estable liberada en el momento de escribir estas líneas es la 2.4.20.

Ocultar dispositivos frente a peticiones ARP en kernels 2.2.x ó 2.4.x parcheados

Algunas de las soluciones arriba enunciadas, implican parchear el kernel de los servidores

reales. El parche que se aplica a los servidores reales (el parche “hidden”) es diferente al

que se aplica en el director (el parche “ipvs”). El primero evita que un dispositivo

determinado conteste a peticiones ARP, el segundo convierte al kernel del director en un

balanceador de carga.Para hacer que los dispositivos no respondan a peticiones ARP en los

servidores reales es necesario proceder de la siguiente manera:

Parchear el kernel con el parche adecuado la versión correspondiente, ver (kernels 2.2.x ó

kernels 2.4.x), y posteriormente ocultar el dispositivo de la siguiente manera:

#para activar la propiedad que permite ocultar dispositivos

echo 1 > /proc/sys/net/ipv4/conf/all/hidden

#para hacer que el dispositivo lo:0 no responda ARPs

echo 1 > /proc/sys/net/ipv4/conf/<nombre_interface>/hidden


Para comprobar que el dispositivo ocultado lo:0 no está respondiendo a peticiones ARP,

y suponiendo que se asigna la VIP al dispositivo lo:0 se puede hacer lo siguiente:

- Antes de ocultar el dispositivo lo:0, se envía un ping desde otra máquina a la VIP,

entonces se ejecuta el siguiente comando: arp -a, lo cual muestra que la dirección MAC

para la VIP es la del dispositivo eth0 de la máquina desde la cual se envió el ping.

- Se borra la entrada para la VIP de la cache arp con arp –d <VIP>. Y se comprueba

que esta entrada ya no está en la cache arp -a.

- Se envía un ping nuevamente y se comprueba como vuelve a aparecer una entrada MAC

para la VIP.

- Entonces se oculta el dispositivo lo:0 tal como se ha explicado:

echo 1 > /proc/sys/net/ipv4/conf/all/hidden

echo 1 > /proc/sys/net/ipv4/conf/lo:0/hidden

y se vuelve a enviar un ping a la VIP desde otra máquina. Lo más probable es la VIP

conteste al ping ya que la entrada para la VIP continua estando en la cache arp de la otra

máquina.

- Se borra entonces la entrada arp –d -VIP y se hace ping de nuevo, en esta ocasión no

se debería obtener respuesta.

Obtener el parche para Kernels 2.2.x

Dado que el parche hidden para kernels mayores o iguales a 2.2.14 forma parte

actualmente de la distribución Linux, se puede utilizar esta característica con un kernel

estándar. Los parches ARP permiten ocultar dispositivos frente a peticiones ARP,

retomando la característica no_arp de los kernels 2.0.x.

Obtener el parche para Kernels 2.4.x

El parche hidden de Julian para el kernel 2.2.x no esta incluido en los kernels 2.4.x. Se

puede descargar el mismo desde <http://www.ssi.bg/~ja/#hidden>. Actualmente este

parche se distribuye con el IPVS Netfilter module para kernel 2.4, y la última versión

disponible en estos momentos se puede bajar directamente desde:

ACADE (LVS) - 63

<http://www.linuxvirtualserver.org/software/kernel-2.4/ipvs-1.0.7.tar.gz>.

Una vez descomprimido el tarball se puede encontrar en el directorio:

ipvs-x.x.x/contrib/patches/hidden-x.x.x.diff.

La última versión del parche hidden se encontrará siempre en la web de software y parches

de Julian Anastasov <http://www.ssi.bg/~ja/#hidden>.

Por ejemplo, en el caso de que se esté parcheando un kernel 2.4.5 con los archivos de

ipvs-1.0.7, se seguirán los siguientes pasos:

cd /usr/src/linux

patch -p1 <../ipvs-1.0.7/contrib/patches/hidden-2.4.5-1.diff

Después, bastará recompilar el kernel utilizando las mismas opciones que se seleccionaron

para el kernel 2.4 del director. Ahora ya se pueden ocultar las interfaces (ver, Ocultar

dispositivos frente a peticiones ARP en kernels 2.2.x ó 2.4.x parcheados, en este mismo

apartado)

Poner una NIC extra en los servidores para soportar la VIP

Consiste en añadir otra tarjeta de red en los servidores reales. El único motivo por el que se

añade este dispositivo de red (eth1), es para poder configurar una VIP en el servidor.

Mientras que esta NIC adicional, no sea conectada al medio físico o se introduzca una

entrada para ella en la tabla de rutado del kernel, no responderá a peticiones ARP. Es decir,

la NIC no será conectada hub/switch. De esta manera, se consigue que esta interfaz no

responda a peticiones ARP en un kernel 2.2.x. Si bien será esta VIP la que ofrezca los

servicios de red a través de la eth0 y no a través de la eth1, ya que la eth0 no

responderá con su MAC cuando se reciba una petición ARP para la VIP (como sucedía si

la VIP era soportada por lo:0).

Lars’ Method

Este método requiere poner a los servidores virtuales en una red diferente, ocultándola de

esta manera de las peticiones ARP.


Este método fue implementado en un principio para LVS-Tun, si bien es también válido

para LVS-DR. Con este método, la topología del servidor virtual queda como aparece en la

siguente figura:

realserver realserverrealserver

director

c lient

router

V IP 192.168.1.150 eth0

DIP 10.1.1.1 eth1

R IP 10.1.1.4 eth0R IP 192.168.1.150 lo:0

R IP 10.1.1.3 eth0R IP 192.168.1.150 lo:0

R IP 10.1.1.2 eth0R IP 192.168.1.150 lo:0

CIP

router router router

Hacia el Cliente

Figura 15: Lars’ Method.

Con el método Lars’, el director dispone de dos tarjetas de red, lo que permite que los

servidores reales pertenezcan a otra red diferente. La VIP pertenece a la red

192.168.1.0/24 y las eth0 de los realservers a la 10.1.1.0/24. Todas los

dispositivos de red responden a peticiones ARP, sin embargo las peticiones ARP del router

a la VIP no llegan a los realservers dado que las RIP de los servidores reales no son

accesibles desde Internet.

Este método requiere que el director no reenvíe paquetes para la VIP, esto es fácil de

implementar dado que el director dispone de dos NICs.

ACADE (LVS) - 65

Hacer que los servidores reales contesten con la MAC del director

Se puede forzar a que cuando se recibe una petición ARP para resolver la MAC de la VIP,

se conteste con la MAC del director. De esta manera, los servidores reales responderán con

la MAC del director frente a peticiones ARP para la VIP. Para ello se pueden utilizar

entradas estáticas en la cache ARP, que se pueden conseguir de dos formas:

#arp –s director.acade.net 00:20:18:28:04:E9

otra forma de hacer lo mismo es editando el archivo /etc/ethers de los clientes:

director.acade.net 00:20:18:28:04:E9

En los ejemplos, se da por supuesto que se tiene una entrada en el archivo /etc/hosts,

el cual mapea la dirección IP del director con el nombre y dominio del director

director.acade.net. Si no se dispone de la entrada, basta con poner la dirección IP

en lugar de su nombre.

Este método no requiere parchear el kernel de los servidores reales así como tampoco

necesita de una NIC adicional como en el método Lars’, si bien en un entorno de

producción con un algún mecanismo de recuperación ante fallos, como Heartbeat, se hace

necesario un método adicional que cambie las entradas ARP estáticas de la cache de los

servidores reales. Para este tipo de configuraciones (failover), el método Horms’

proporciona un mayor grado de flexibilidad.

Modificar tabla de routado del router

Si se dispone de un router propio de salida que incorpora de dos NICs, puede utilizarse una

de ellas para el director y la otra para los realservers, de manera que las peticiones a la

VIP sean enrutadas hacia el director.

Proxy Transparente (TP), Horms’ Method

TP se enfrenta al problema de las peticiones ARP de forma parecida a la que lo hacía el

método que forzaba a los dispositivos a no responder a peticiones ARP, sólo que en vez de

hacerlo ocultando esos dispositivos, al colocarlos en una red distinta, lo hace forzando a


que estos dispositivos sólo acepten peticiones a determinados servicios. Es decir, mediante

ipchains o iptables, es posible configurar una interfaz para que sólo responda al servicio

que se desea, ignorando cualquier otra petición, ya sea ARP, ICMP, etc.

El método Horms’ utiliza también la característica transparent proxy de ipchains que

permite aceptar paquetes con destino igual a la VIP, por un host (director o realserver) que

no tiene un dispositivo con esa IP. Este método puede ser utilizado en los servidores reales

para solventar el problema con los ARPs o para permitir al director aceptar paquetes para

la VIP. Cuando se utiliza en el director, trasnparent proxy le permite ser el gateway por

defecto del LVS-DR (véase 13.4.2 del LVS-HOWTO) [7]

Una de las ventajas de este método, es que facilita el cambio de reglas en arquitecturas

faliover en las cuales se utiliza un balanceador de backup para asegurar la disponibilidad

del servicio.

Desafortunadamente, las versiones de proxy transparente en LVS para kernels 2.2 y 2.4 son

completamente distintas. Así, puede utilizarse proxy transparente en los kernels 2.2, tanto

en los servidores reales como en el director, mientras que el kernels 2.4.x, sólo en los

servidores reales.

6.4 Persistencia en LVS

En una situación de balanceo de carga normal, se asume que cada conexión de red es

independiente de las demás, de modo que cada conexión puede ser asignada a un servidor

diferente si el algoritmo de scheduling así lo cree conveniente. No obstante, en ocasiones

hay servicios que requieren que todas las conexiones de un mismo cliente sean asignadas al

mismo servidor real, lo cual recibe el nombre de persistencia de sesión. LVS identifica las

conexiones de los clientes en base al contenido de las cabeceras de los protocolos IP, TCP

y UDP, y utiliza por lo tanto métodos de persistencia basados en IP origen para garantizar

la persistencia de los servicios que la requieren.

ACADE (LVS) - 67

El resultado de aplicar un método de persistencia en LVS, implica que el cliente se

conectará al mismo servidor real para diferentes conexiones TCP o UDP, entendiendo

como conexión TCP el tiempo que transcurre desde que se establece la conexión TCP a

tres bandas hasta que ésta finaliza, ya sea de manera acordada TCP FIN, o de forma

abrupta, TCP RESET. Al conjunto de conexiones TCP/UDP realizadas, necesarias para la

correcta prestación de un determinado servicio, se le conoce como sesión, y al mecanismo

que permite garantizar que todas estas conexiones sean reenviadas a un mismo servidor,

como método de persistencia de sesión.

Servicios que requieren aplicar mecanismos para asegurar la persistencia de sesión

Existen tres situaciones en las que es necesario aplicar mecanismos de persistencia para la

correcta prestación de un servicio ofrecido LVS:

- Cuando el cliente necesita acceder siempre a al mismo servidor, debido a que sólo éste

dispone de la información intercambiada con el cliente durante la prestación de un

determinado servicio. Por ejemplo, debido al intercambio de llaves realizado durante una

sesión https .

- Si el cliente solicita un servicio que se ofrece a través de dos puertos diferentes, los cuales

han de ser abiertos en el mismo servidor real. Por ejemplo, el servicio FTP activo (puertos

20, 21), o el FTP pasivo (puerto 21 y otro puerto alto por encima del 1023), o bien los

servicios de un sitio de e-commerce (puertos 80, 443).

- Cuando un mismo cliente realiza conexiones pertenecientes a una misma sesión, pero

utiliza direcciones IP origen diferentes en cada una de las conexiones, debido a que está

accediendo a Internet a través de un proxy diferente en cada conexión. Esta situación se la

conoce también como el megraproxy problem, la cual es descrita en el apartado del mismo

nombre de esta memoria (3.8.2). Una forma de solucionar este problema, es asumiendo

que los diferentes servidores proxy por los cuales sale el cliente, pertenecen a la misma red.

Entonces, es posible configurar al balanceador para que considere a todas las conexiones,

realizadas desde un rango de direcciones de red determinado, como si fueran de un mismo

cliente u origen virtual (virtual source). En LVS, se conoce a este tipo de persistencia

como persistent granularity.


FTP es un ejemplo muy claro para entender la necesidad del uso de la persistencia. El

cliente establece dos conexiones con el servidor, una de ellas es la conexión de control

(puerto 21) para el intercambio de la información de control y la otra es la conexión de

datos (usualmente el puerto 20) para la transferencia de los datos. En el FTP activo, el

cliente informa al servidor del puerto por el que le escuchará, la conexión de datos es

inicializada por el servidor desde el puerto 20 y dirigida al puerto que el cliente le informó.

SSL es otro servicio que necesita conectarse siempre al mismo servidor durante toda la

sesión debido al uso de las llaves. Cuando se establece una conexión SSL, en el puerto 443

para servidores Web seguros y en el puerto 465 para servidores de correo seguro, una llave

para la conexión debe de ser escogida e intercambiada. Las últimas conexiones para el

mismo cliente son garantizadas por el servidor durante la vida de la llave SSL.

Mecanismos de persistencia implementados en LVS

LVS no puede interpretar el contenido de los paquetes más allá de la capa de transporte,

por este motivo no sabe determinar el inicio y finalización de sesiones. LVS implementa

métodos de persistencia basados en IP origen (3.8.2). LVS permite implementar Persistent

Client Connection (PCC) o Persistent Port Connection (PPC), en función de la versión del

kernel utilizada. De este modo, los kernels anteriores o iguales a la versión 2.2.10 sólo

permitían PCC, en cambio los kernels iguales o superiores a la versión 2.2.12 implementan

PPC, pudiendo implementar también PCC poniendo un ‘0’ al configurar el número de

puerto mediante la opción –p de ipvsadm (6.7). LVS no es capaz de implementar, por si

sólo, el método de agrupación de puertos descrito en el apartado (3.8.2), pero sí mediante

la utilización de marcas de firewall (6.5).

Funcionamiento de los mecanismos de persistencia en LVS

La tabla de sesiones utilizada por LVS muestra el estado de las conexiones de los clientes

que atraviesan el balanceador. Cada conexión balanceada por LVS se refleja mediante una

entrada en esta tabla de sesiones (hash table), constado cada una de ellas de los siguientes

campos:

ACADE (LVS) - 69

IPVS connection entries

pro expire state source virtual destination

El primer campo especifica el protocolo TCP o UDP. El segundo indica el tiempo que la

regla permanecerá en la tabla, si no se recibe otro paquete que coincida con el resto de

campos. Si se recibe un paquete que case con una entrada en la tabla, el campo state

puede cambiar de valor. El cambio de estado (state) implica reajustar el valor del

contador (timeout), mostrado en el campo expire. La siguiente captura muestra el

cambio de estados por los que va pasando una sesión, y el reajuste que del temporizador

(expire) en función del cambio:

pro expire state source virtual destination TCP 14:56 ESTABLISHED 192.168.3.157:1044 192.168.3.150:80 192.168.10.101:80 TCP 14:49 ESTABLISHED 192.168.3.157:1044 192.168.3.150:80 192.168.10.101:80 TCP 01:59 FIN_WAIT 192.168.3.157:1044 192.168.3.150:80 192.168.10.101:80 TCP 00:05 CLOSE 192.168.3.157:1044 192.168.3.150:80 192.168.10.101:80 TCP 00:02 CLOSE 192.168.3.157:1044 192.168.3.150:80 192.168.10.101:80 TCP 00:00 CLOSE 192.168.3.157:1044 192.168.3.150:80 192.168.10.101:80

Cuando el balanceador detecta el fin de una conexión TCP no la borra de la tabla, sino que

la mantiene durante 10 segundos, pasado este tiempo y si no recibe un nuevo paquete que

case con el resto de campos de la tabla (VIP, IP origen y puerto), elimina la entrada. Para

saber como especificar servicios de manera persistente véase (6.4 y 6.7).

Particularidades

- Persistencia en ftp

El método más optimizado para ofrecer el servicio ftp, en función de lo descrito hasta

ahora, sería recurriendo al agrupado de puertos mediante marcas de firewall, sin embargo,

existe otra posibilidad que es la de cargar el módulo ip_masq_ftp (para versiones

2.2.x), o el módulo ip_vs_ftp (en versiones 2.4). Estos módulos permiten ofrecer el

servicio ftp en LVS-NAT aplicando únicamente la persistencia a los puertos necesarios

para la prestación del servicio ftp (20 y 21 para el modo activo, 21 y un puerto alto para el

modo pasivo). Se procederá de la siguiente forma para configurar el servicio ftp en el

balanceador de carga (director1).


root@director1:~# modprobe ip_vs_ftp root@director1:~# lsmod Module Size Used by Not tainted ip_vs_ftp 4516 0 (unused) ip_vs_rr 1476 2 (autoclean) ip_vs 77272 5 (autoclean) [ip_vs_ftp ip_vs_rr]

Posteriormente, se configurará mediante ipvsadm, el comando que establece el servicio

ftp como persistente:

root@director1~#ipvsadm -A -t 192.168.3.150:21 -p 600 root@director1~#ipvsadm -a -t 192.168.3.150:21 -r 192.168.10.101 –m root@director1~#ipvsadm -a -t 192.168.3.150:21 -r 192.168.10.102 -m

- Persistencia http

Con la primera versión del protocolo http, HTTP 1.0, cuando el cliente solicitaba la

descarga de una página, se establecía una conexión TCP para descargar cada uno de los

objetos que contenía. No tenía demasiado sentido establecer una conexión TCP para

descargar el poco código de la página, cerrar la conexión y volver a establecer conexiones

nuevas para descargar el resto de objetos que componen la página (por ejemplo, imágenes).

Con HTTP 1.1 [9] las conexiones persistentes son posibles. Los extremos de la

comunicación cliente/servidor negocian para ver si la conexión persistente está disponible.

El servidor http mantiene la conexión abierta tras haber enviado toda la información

solicitada, por un periodo de tiempo de 16 segundos, normalmente (KeepAliveTimeout), si

pasado este tiempo el navegador del cliente no solicita nuevos objetos, la conexión se

cierra. El cliente puede cerrar la conexión en cualquier momento si así lo desea (por

ejemplo cuando ya tenga todos los objetos que conforman la página).

Si se solicita una página web alojada en el cluster desde un navegador tan difundido como

pueda ser Microsoft Internet Explorer y posteriormente se visualiza el contenido de la tabla

de sesiones del balanceador de carga LVS, se observa lo siguiente:

root@director1:~# ipvsadm -lcn

IPVS connection entries

pro expire state source virtual destination

TCP 14:59 ESTABLISHED 192.168.3.157:1063 192.168.3.150:80 192.168.10.102:80

TCP 14:59 ESTABLISHED 192.168.3.157:1062 192.168.3.150:80 192.168.10.101:80

ACADE (LVS) - 71

Se observa que el navegador ha establecido dos conexiones TCP para obtener el contenido

de la página web, lo que conlleva a plantearse la siguiente pregunta, ¿Es que Microsoft

Internet Explorer no implementa el protocolo HTTP 1.1? Antes de salir corriendo a

anunciar esta afirmación a bombo y platillo, sería recomendable continuar leyendo, pues

no es eso lo que está sucediendo. Lo que ocurre, es que los navegadores web lanzan

múltiples conexiones TCP concurrentes hacia el servidor, en su carrera por ser el

navegador más rápido en mostrar las páginas al cliente. Por otra parte, cada una de esas

conexiones ha utilizado el protocolo HTTP 1.1 para descargar diferentes objetos, de lo

contrario habría establecido tantas conexiones como objetos tuviese la página.

Para finalizar éste apartado, se muestran a continuación algunos ejemplos que permiten

configurar algunos servicios de forma persistente utilizando diferentes métodos de reenvío.

Estos ejemplos han sido extraídos de:

<http://www.linuxvirtualserver.org/docs/persistence.html>

- Persistencia http en LVS/NAT ipvsadm -A -t virtualdomain:www –p ipvsadm -a -t virtualdomain:www -r 192.168.1.2 –m ipvsadm -a -t virtualdomain:www -r 192.168.1.3 –m ipvsadm -a -t virtualdomain:www -r 192.168.1.4 –m

- Persistencia http en LVS/TUN ipvsadm -A -t virtualdomain:www –p ipvsadm -a -t virtualdomain:www -r 192.168.1.2 –I ipvsadm -a -t virtualdomain:www -r 192.168.1.3 –I ipvsadm -a -t virtualdomain:www -r 192.168.1.4 –I

- Persistencia ftp en LVS/DR ipvsadm -A -t virtualdomain:ftp -p 540 ipvsadm -a -t virtualdomain:ftp -r 192.168.1.2 –g ipvsadm -a -t virtualdomain:ftp -r 192.168.1.3 –g ipvsadm -a -t virtualdomain:ftp -r 192.168.1.4 –g

- Persistent Client Connection (PCC) en LVS/DR ipvsadm -A -t virtualdomain:0 –p ipvsadm -a -t virtualdomain:0 -r 192.168.1.2 –g ipvsadm -a -t virtualdomain:0 -r 192.168.1.3 –g ipvsadm -a -t virtualdomain:0 -r 192.168.1.4 –g


- Persistent granularity (Megaproxy Problem) ipvsadm -A -t virtualdomain:www -p -M 255.255.255.0 ipvsadm -a -t virtualdomain:www -r 192.168.1.2 ipvsadm -a -t virtualdomain:www -r 192.168.1.3 ipvsadm -a -t virtualdomain:www -r 192.168.1.4

6.5 Firewall marks

El método original para configurar el balanceador de carga LVS consiste en el uso de

comandos ipvsadm junto con una o varias direcciones IP virtuales. De esta manera, es

posible configurar diferentes servicios bajo una misma dirección IP virtual (VIP) o

configurarlos bajo diferentes direcciones IP virtuales (VIPs). Por otro lado, este método no

es muy escalable si el número de VIPs o servicios es muy elevado, debido a que se deberán

de configurar múltiples VIP en el dispositivo de red. Además, las conexiones para cada

servicio son independientes unas de otras, a no ser que se recurra a métodos de persistencia

basados en IP origen. Es por eso que el método basado en la VIP, no es el más

recomendable en muchas ocasiones.

En abril de 2000, Horms introdujo un método más flexible que mediante marcas de

firewall (fwmarks), permitía administrar de manera más simple y flexible un elevado

número de servicios. Más tarde, Ted Pavlic mostró como utilizar fwmarks para agrupar

servicios, de forma que estos fueran tratados conjuntamente por un mismo servidor real.

De esta manera, LVS puede utilizar el método de agrupamiento de puertos (3.8.2).

Fwmark es utilizado actualmente para:

- Agrupar servicios bajo un mismo balanceador de carga. Por ejemplo:

- Grupo 1, puertos 80, 443 para sitios web de e-commerce.

- Grupo 2, puertos 20, 21 para un servidor FTP.

- Agrupar un gran número de direcciones IP virtuales (VIP).

ACADE (LVS) - 73

Es preferible preparar a LVS mediante fwmarks antes que hacerlo con el método

tradicional, basado en la VIP, salvo en aquellos casos en los que únicamente configuremos

servicios de un solo puerto, o servicios que no requieran de ningún método de persistencia.

Cuando se usa el método basado en fwmarks, no tiene por qué existir una interfaz en el

servidor virtual configurada con la VIP. Para utilizar fwmarks, es necesario que los

paquetes del cliente sean entregados y aceptados por el balanceador, el cual no tiene la IP

destino de los paquetes del cliente (la VIP configurada). De esta manera, mediante

ipchains (kernels 2.2) o iptables (kernels 2.4), se configura al balanceador para recoger,

examinar y marcar los paquetes enviados por los clientes. Posteriormente, los paquetes

serán enviados a IPVS, que los balanceará basándose en la IP origen, IP destino, puerto y

en la marca colocada por el firewall (iptables o ipcahins). Es fácil darse cuenta de lo

sencillo que es ahora realizar port grouping, ya que tan solo hay que crear mediante

iptables o ipchains, las reglas que marquen de igual forma a aquellos paquetes

pertenecientes a los servicios que deseamos agrupar. Dado que las marcas de firewall no

son más que números, es fácil para el balanceador saber discernir qué paquetes han de ser

considerados como pertenecientes al mismo servicio, y que por lo tanto deben de ser

reenviados hacia el mismo servidor real.

¿Cómo enrutar paquetes hacia la VIP de un balanceador cuando éste carece de ella?

En condiciones normales, los mecanismos de rutado del router no enviarán los paquetes de

los clientes hacia el balanceador de carga, ya que éste carece de una interfaz configurada

con la VIP (destino de los paquetes), y no puede responder a las peticiones ARP que lanza

el router. Es posible modificar convenientemente la configuración del router para lograr

que envíe paquetes al balanceador. Hay dos formas de conseguirlo:

- Colocar la MAC del director en el router forzando al balanceador de carga a

contestar a las peticiones ARP con su MAC. Ésto es posible modificando el archivo

/etc/ethers en el director o balanceador de carga.

- Añadir una regla de rutado en el router.


¿Cómo hacer que el balanceador acepte los paquetes que no están destinados a una

dirección IP de su propiedad?

La forma más sencilla de implementar fwmarks, si únicamente se ofrecen servicios por la

VIP, es hacerlo configurando una interfaz de red con la VIP en el balanceador. Por otra

parte, existen varios métodos para permitir la entrega local de un paquete que ha llegado a

una máquina que no es la dueña de la IP destino del paquete.

- Si se van a utilizar un número reducido de VIPs, es posible ponerlas en un dispositivo de

red o bien en el dispositivo virtual lo.

- Como se muestra a continuación, si se requiere de un rango de direcciones IP, es posible

configurar un alias para soportar todas las direcciones de una red, sin necesidad de asignar

una IP a dicho dispositivo.

ifconfig lo:0 192.168.1.0 netmask 255.255.255.0

Para ver algunos ejemplos de cómo utilizar iptables o ipchains para marcar diferentes tipos

de paquetes véase el capítulo 8 del LVS-HOWTO [7].

6.6 Algoritmos de Scheduling implementados por LVS

El director es la máquina encargada de balancear la carga entre los diferentes servidores

reales. Para hacerlo se basa en conjunto secuencial de normas, llamadas algoritmos de

scheduling, que permite al director, decidir en cada momento a que servidor debe reenviar

los paquetes pertenecientes a una misma conexión. LVS (ipvsadm) puede implementar

hasta ocho distintos tipos de algoritmos.

Round-Robin (rr)

El algoritmo de Round-Robin envía cada petición de entrada al siguiente servidor de la

lista. Por ejemplo, en el supuesto de tener tres servidores, A, B y C, la primera petición la

recibiría el servidor A, la segunda el B y la tercera el C. El ciclo se vuelve a repetir

empezando nuevamente por el servidor A. Virtual server proporciona algunas ventajas

sobre el tradicional Round-Robin DNS.

ACADE (LVS) - 75

Weighted Round-Robin (wrr)

Este algoritmo está diseñado para mejorar el manejo de servidores con diferentes

capacidades de proceso. A cada servidor se le puede asignar un peso, que es un valor

entero que indica la capacidad de proceso y que determina la proporción del trabajo que le

será asignado. A mayor peso, se le envían más peticiones.

Weighted Round-Robin es mejor que Round-Robin cuando la capacidad de proceso de los

servidores reales es diferente. Actualmente, el Round-Robin es un caso particular del

Weighted Round-Robin, en el cual todos sus pesos son iguales.

Least-Connection (lc)

Dirige las conexiones de red al servidor con el menor número de conexiones. Este

algoritmo es de naturaleza dinámica ya que necesita contar las conexiones activas para

cada servidor dinámicamente, y es adecuado en el caso de que la carga varía notablemente.

Weighted Least-Connection (wlc)

El Weighted Least-Connection scheduling es un perfeccionamiento del Least-Connection

en el cual se le puede asignar un peso variable a cada servidor real.

Locality-Based Least-Connection (lblc)

Asigna trabajos destinados para la misma IP para el mismo servidor, si el servidor no está

sobrecargado y disponible. En caso contrario, lo asigna al servidor con menos trabajo y lo

mantiene para designaciones futuras.

Locality-Based Least-Cocnnection with Replication (lblcr)

Asigna trabajos destinados para la misma IP al servidor Least-Connection configurado

para esa IP. Si todos los servidores están sobrecargados, repone al servidor con menos

trabajo y lo añade a la lista de disponibles.

Destination Hashing (dh)

Asigna trabajos a los servidores a base de buscar una asignación estática, por la IP destino,

en la tabla hash.


Source Hashing (sh)

Asigna trabajos a los servidores a base de buscar una asignación estática, por la IP origen,

en la tabla hash.

6.7 Ipvsadm

Ipvsadm es la herramienta para administrar el Servidor Virtual Linux (LVS) que permite

configurar, mantener y visualizar el estado de la tabla del servidor virtual del kernel de

Linux. Así, mediante la interfaz de usuario ipvsadm, es posible configurar los servicios y

servidores que direccionará IPVS, el peso asignado a cada servidor, útil cuando unos

servidores son más rápidos que otros, y el algoritmo de scheduling utilizado para elegir el

servidor real al que deberán reenviarse los paquetes tratados por el balanceador.

Ipvsadm puede ser invocado desde la línea de comandos o utilizado para crear scripts de

inicialización que definan el comportamiento de IPVS.

Podemos utilizar ipvsadm para realizar las siguientes funciones:

- Añadir servicios

- Desactivar servicios

- Borrar servicios

- Lanzar o detener el demonio de sincronización de estado

- Salvar la configuración actual del LVS (ipvsadm-save)

- Restaurar una configuración para el LVS (ipvsadm-restore)

A continuación, se explica con la ayuda de algunos ejemplos, cómo trabajar con ipvsadm

para configurar y administrar el servidor virtual. La estructura de este capítulo está

inspirada en el manual de ipvsadm (anexo II). Para una información más detallada de

todas las opciones de la herramienta ipvsadm consúltese el mismo.

El formato de ejecución de ipvsadm es el siguiente:

ipvsadm COMANDO PARAMETROS

ACADE (LVS) - 77

Que en función del comando (MAYÚSCULAS/minúscula) da lugar a dos formatos básicos

de ejecución:

ipvsadm COMANDO [protocolo] dirección-del-servicio [método-de-scheduling]

[opciones de persistencia]

ipvsadm comando [protocolo] dirección-del-servicio dirección-del-servidor

[método de reenvío] [peso]

El primero de ellos define los servicios del LVS y el algoritmo utilizado para asignar, a un

servidor real determinado, las peticiones a esos servicios. Opcionalmente, si el servicio

requiere de persistencia, es posible definir el timeout y la máscara de red.

El segundo formato de instrucción, especifica los servidores reales que han de ser

asociados a cada uno de los servicios virtuales prestados por el LVS. Cuando se añade un

servidor real, el método de reenvío debe de ser especificado o de lo contrario se tomarán

los valores por defecto.

Si se ejecuta ipvsadm sin especificar ningún comando, el programa lista los servicios

configurados y los servidores reales que están configurados para prestarlos. Lo que

equivale a llamar a ipvsadm con el comando –L ó –l.

root@director1:~# ipvsadm IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.3.150:ftp rr persistent 600 -> rserver1.acade.net:ftp Masq 5 0 0 TCP 192.168.3.150:http rr -> rserver1.acade.net:http Masq 5 0 0 -> rserver2.acade.net:http Masq 5 0 0

En esta captura se muestra un LVS configurado para ofrecer los servicios ftp y http. Para

cada servicio se listan los servidores reales a los que LVS reenviará las peticiones. En el

ejemplo, las conexiones ftp se redirigirán al rserver1, mientras que las conexiones http

serán reenviadas tanto al rserver1 como al rserver2. El algoritmo de scheduling

utilizado en ambos casos es Round Robin rr.


Conjuntamente a este comando, se pueden especificar otros parámetros. Así, si se utiliza –

lc se obtendrá una lista de las conexiones establecidas en el LVS.

root@director1:~# ipvsadm -lc IPVS connection entries pro expire state source virtual destination TCP 07:14 NONE calipso.odisea.net:0 192.168.3.150:0 rserver1.acade.net:0 TCP 06:40 NONE sem_alpha1.acade.net:0 192.168.3.150:0 rserver1.acade.net:0 TCP 12:15 ESTABLISHED sem_alpha1.acade.net:1033 192.168.3.150:ftp rserver1.acade.net:ftp TCP 00:09 TIME_WAIT calipso.odisea.net:1099 192.168.3.150:ftp-data rserver1.acade.net:ftp-data TCP 13:09 ESTABLISHED calipso.odisea.net:1095 192.168.3.150:ftp rserver1.acade.net:ftp

El ejemplo muestra dos equipos conectados al único servidor real que presta servicio de ftp

en el LVS. En el primero de los formatos que se han descrito, los comandos son letras en

mayúsculas, en el segundo minúsculas. De esta manera es fácil reconocer si es una

instrucción de configuración de servicio virtual, o bien una de especificación de servidor

virtual.

A continuación se detallan algunos de los COMANDOS (o comandos básicos) para

configurar y visualizar el estado del LVS.

COMANDOS

-A, --add-service

Añade un servicio virtual que queda definido únicamente por la tripleta: Dirección IP,

número de puerto y protocolo. Alternativamente, un servicio virtual podría ser definido por

una firewall-mark (6.5).

root@director1:~#ipvsadm –A –t 192.168.3.150:80 –s rr

Este comando configura el balanceador de carga con el servicio http, y de esta manera

IPVS se hará cargo de todos los paquetes destinados a la IP 192.68.3.150 dirigidos al

puerto 80 (http). Posteriormente con ipvsadm –a, se han de añadir los servidores

reales a los que se reenviarán las peticiones al servicio que se acaba de configurar.

ACADE (LVS) - 79

-D, --delete-service

Este comando elimina un servicio virtual así como cualquier servidor real asociado y debe

de ir acompañado del uno de los siguientes parámetros -t | -u | -f (-t para TCP, -

u para UDP y -f para firewall-mark).

Por ejemplo, en un director que tenga los siguientes servicios y servidores reales

configurados: root@director1:~# ipvsadm -l IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.3.150:ftp rr persistent 600 -> rserver1.acade.net:ftp Masq 5 0 0 TCP 192.168.3.150:http rr -> rserver2.acade.net:http Masq 5 0 0 -> rserver1.acade.net:http Masq 5 0 0

Entonces, para borrar el servicio http y sus servidores asociados, se usará la instrucción con

el comando anteriormente descrito: root@director1:~# ipvsadm -D -t 192.168.3.150:http

Si se listan de nuevo los servicios, se observa que el de http y sus servidores reales ya no

están: root@director1:~# ipvsadm -l IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.3.150:ftp rr persistent 600 -> rserver1.acade.net:ftp Masq 5 0 0

-C, --clear

Borra todas las entradas de la tabla de servicios del servidor virtual y sus respectivos

realservers, pero NO elimina las entradas de la tabla de conexiones establecidas como

muestran las siguientes capturas. root@director1:~# ipvsadm IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.3.150:ftp rr persistent 600 -> rserver1.acade.net:ftp Masq 5 0 0 TCP 192.168.3.150:http rr -> rserver2.acade.net:http Masq 5 0 0 -> rserver1.acade.net:http Masq 5 0 0


La captura anterior muestra los servicios definidos en el balanceador de carga: ftp y http.

También muestra los servidores reales a los que se reenviarán peticiones para dichos

servicios: rserver1.acade.net para ftp y rserver1.acade.net,

rserver2.acade.net para http.

root@director1:~# ipvsadm -lc IPVS connection entries pro expire state source virtual destination TCP 09:16 NONE sem_alpha1.acade.net:0 192.168.3.150:0 rserver1.acade.net:0 TCP 01:48 TIME_WAIT sem_alpha1.acade.net:1065 192.168.3.150:ftp-data rserver1.acade.net:ftp-data TCP 14:49 ESTABLISHED sem_alpha1.acade.net:1064 192.168.3.150:ftp rserver1.acade.net:ftp root@director1:~# ipvsadm -C root@director1:~# ipvsadm -l IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn root@director1:~# ipvsadm -lc IPVS connection entries pro expire state source virtual destination TCP 08:56 NONE sem_alpha1.acade.net:0 192.168.3.150:0 rserver1.acade.net:0 TCP 01:28 TIME_WAIT sem_alpha1.acade.net:1065 192.168.3.150:ftp-data rserver1.acade.net:ftp-data TCP 14:28 ESTABLISHED sem_alpha1.acade.net:1064 192.168.3.150:ftp rserver1.acade.net:ftp

Posteriormente se muestran las conexiones establecidas ipvsadm –lc. Se borran los

servicios y servidores configurados en el balanceador ipvsadm –C. Se observa que sólo

se borran los servidores y servicios, no así las conexiones establecidas en el balanceador.

comandos

-a, --add-server

Permite añadir un servidor real. De esta manera se le puede indicar al balanceador a que

servidor real debe de enviar los paquetes pertenecientes a un servicio configurado

previamente con el parámetro –A. Para añadir un servidor al balanceador, primero

configuraremos el servicio con -A:

root@director1:~# ipvsadm -A -t 192.168.3.150:80 -s rr root@director1:~# ipvsadm -l IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP virtualip.acade.net:http rr

ACADE (LVS) - 81

Posteriormente se añaden los servidores reales a los cuales se reenviarán los paquetes

pertenecientes a una conexión del servicio que se acaba de definir en el balanceador:

root@director1:~# ipvsadm -a -t 192.168.3.150:80 -r 192.168.10.101 -m root@director1:~# ipvsadm -a -t 192.168.3.150:80 -r 192.168.10.102 -m root@director1:~# ipvsadm -l IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP virtualip.acade.net:http rr -> rserver2.acade.net:http Masq 1 0 0 -> rserver1.acade.net:http Masq 1 0 0

-d, --delete-server

Permite borrar un servidor real, con lo que dejan de reenviársele paquetes.

-l, -L, list

Lista la tabla de servidores virtuales mostrando todos los servicios configurados en ellos.

Si además se especifica una service-address, se mostrarán únicamente las entradas

para este servicio.

--start-daemon state

Lanza el demonio de sincronización de estado que está implementado dentro del kernel de

Linux. Este comando es utilizado cuando se implementa LVS en un entorno de alta

disponibilidad en una arquitectura de clustering activo/pasivo. El demonio permite tener

varias máquinas parcheadas con IPVS actuando como balanceadores de carga. El

balanceador de carga primario, lanzará el demonio con state igual a master, y los

esclavos configurarán el demonio en modo backup. A partir de ese momento, el demonio

configurado como master enviará periódicamente mensajes multicast con los cambios del

estado de su tabla de conexiones. Los demonios de los balanceadores esclavos recibirán

estos mensajes multicast y, a su vez, también actualizarán sus tablas. Así, en el caso de que

el balanceador primario falle, el balanceador de carga de reserva podrá substituirlo y tendrá

la mayoría de las conexiones reflejadas en su tabla por lo que la mayor parte de las

conexiones establecidas en el momento del fallo seguirán pudiendo acceder a los servicios.

De esta forma sólo se perderían aquellas conexiones establecidas después del último

multicast enviado antes de que el master fallara.


Un análisis del código fuente del parche IPVS (linux-x.x.x-ipvs-

x.x.x.patch.gz ip_vs_sync.c) para el kernel de Linux, permite encontrar la

estructura del mensaje UDP multicast, tal y como se muestra en la siguiente captura:

+/* + The master mulitcasts messages to the backup load balancers in the + following format. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Count Conns | Reserved | Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IPVS Sync Connection (1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | . | + | . | + | . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | IPVS Sync Connection (n) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +*/

A su vez, un campo IPVS Sync Connection (n) se define así:

+/* + * IPVS sync connection entry + */ +struct ip_vs_sync_conn { + __u8 reserved; + + /* Protocol, addresses and port numbers */ + __u8 protocol; /* Which protocol (TCP/UDP) */ + __u16 cport; + __u16 vport; + __u16 dport; + __u32 caddr; /* client address */ + __u32 vaddr; /* virtual address */ + __u32 daddr; /* destination address */ + + /* Flags and state transition */ + __u16 flags; /* status flags */ + __u16 state; /* state info */ + + /* The sequence options start here */ +};

De esta manera el mensaje multicast que tuviera que enviar la información correspondiente

a las siguientes conexiones:

ACADE (LVS) - 83

root@director2:/#ipvsadm -lcn IPVS connection entries pro expire state source virtual destination TCP 02:25 ESTABLISHED 192.168.3.157:1050 192.168.3.150:80 192.168.10.102:80 TCP 02:25 ESTABLISHED 192.168.3.157:1049 192.168.3.150:80 192.168.10.101:80

Sería así: Frame 34 (94 bytes on wire, 94 bytes captured) Ethernet II, Src: 00:20:18:28:04:e9, Dst: 01:00:5e:00:00:51 Internet Protocol, Src Addr: 192.168.3.155 (192.168.3.155), Dst Addr: 224.0.0.81 (224.0.0.81) User Datagram Protocol, Src Port: 1025 (1025), Dst Port: 8848 (8848) Data (52 bytes) 0000 01 00 5e 00 00 51 00 20 18 28 04 e9 08 00 45 00 ..^..Q. .(....E. 0010 00 50 12 6e 40 00 01 11 c2 9a c0 a8 03 9b e0 00 .P.n@........... 0020 00 51 04 01 22 90 00 3c da 88 02 20 34 00 6f 06 .Q.."..<... 4.o. 0030 04 19 00 50 00 50 c0 a8 03 9d c0 a8 03 96 c0 a8 ...P.P.......... 0040 0a 65 00 00 00 01 04 06 04 1a 00 50 00 50 c0 a8 .e.........P.P.. 0050 03 9d c0 a8 03 96 c0 a8 0a 66 00 00 00 01 .........f....

La parte en negrita, correspondería al “protocolo” utilizado por los demonios IPVS de

sincronización de conexiones, que evidentemente concuerda con la definición hecha en el

código fuente del parche IPVS.

Count Conns Reserved Size

02 20 34 00

reserved protocol client

port (1049)

virtual port (80)

destination port (80)

client address

(192.168.3.157)

virtual address

(192.168.3.150)

destination address

(192.168.10.101)

status flags

state info (Established)

6f 06 04 19 00 50 00 50 C0 A8 03 9d C0 A8 03 96 C0 A8 0a 65 00 00 00 01 IPVS Sync Connection (1)

reserved protocol client

port (1050)

virtual port (80)

destination port (80)

client address

(192.168.3.157)

virtual address

(192.168.3.150)

destination address

(192.168.10.101)

status flags

state info (Established)

04 06 04 1a 00 50 00 50 C0 A8 C3 9d C0 A8 03 96 C0 A8 0a 66 00 00 00 01 IPVS Sync Connection (2)

--stop-daemon

Detiene el demonio de sincronización de conexiones.

-h, --help

Ayuda, muestra una descripción de la sintaxis de los comandos.


PARAMETROS

Los comandos mostrados hasta el momento, requieren o aceptan algunos de los parámetros

que se listan a continuación:

-t, --tcp-service service-address

Se utiliza para especificar un servicio TCP. service-address se usa en la modalidad

host[:port]. Pudiéndose especificar el servidor real con su dirección IP o bien con su

nombre host (tal y como aparece en /etc/hosts). La especificación del puerto es

opcional, si se omite se utiliza cero por defecto, lo cual sólo es válido si el servicio es

persistente (opción -p). La opción –p y un cero en el nombre de puerto, configura al

balanceador para realizar Persistent Client Connection (PCC) en vez de Persistent Port

Connection (PPC) . Véase (3.8.2) ó (6.4) para entender las diferencias entre estos dos tipos

de persistencia.

-u, --udp-service service-address

Usado para especificar un servicio UDP. La dirección especificada en service-

address sigue los mismos convenios explicados para el parámetro –t del apartado

anterior.

-f, --fwmark-service integer

Permite utilizar una marca de firewall (entero mayor que 0) en lugar de una dirección,

puerto y protocolo (TCP ó UDP), para designar un servicio virtual. Para marcar los

paquetes, estos deberían procesarse previamente con iptables (opción -m). Las marcas de

firewall pueden ser utilizadas para asociar diferentes servicios virtuales (port grouping).

De manera que una sola definición de servicio virtual en IPVS, cubra diferentes servicios

virtuales correspondientes a múltiples tripletas: dirección, puerto y protocolo; siempre que

estos servicios estén ofrecidos, todos ellos, en los mismos servidores reales. De lo

contrario, se podrían enviar peticiones a servicios no ofrecidos en el servidor destino.

De esta forma, las firewall-marks permiten agrupar convenientemente diferentes

direcciones IP, puertos y protocolos bajo un solo servicio virtual. Lo cual simplifica la

configuración cuando son requeridos un elevado número de servicios y se necesita agrupar

la persistencia, que de otro modo requeriría de múltiples servicios virtuales (6.5).

ACADE (LVS) - 85

-s, --schedules scheduling-method

Parámetro usado para especificar el algoritmo utilizado por el scheduler para asignar a un

servidor real los datagramas UDP y las conexiones TCP. Los algoritmos se implementan

como módulos del kernel. Actualmente se pueden utilizar los siguientes métodos de

scheduling:

rr Round Robin

wrr Weighted Round Robin

lc Least-Connection

wlc Weighted Least-Connection

lblc Locality-Based Least-Connection

lblcr Locality-Based Least-Connection with Replication

dh Destination-Hashing

sh Source-Hashing

Para obtener información detallada de los métodos, consúltese (6.6)

-p --persistence [timeout]

Especifica qué servicios virtuales son persistentes. Si esta opción es especificada, las

múltiples peticiones de un cliente son redireccionadas hacia el mismo servidor real

seleccionado para la primera petición. Opcionalmente, el timeout de las sesiones

persistentes permite ser cuantificado en segundos por el usuario, de lo contrario, se utiliza

el valor por defecto que es de 300 segundos. Esta opción es utilizada en aquellos

protocolos, como SSL o FTP, en los que es importante que los clientes conecten

constantemente con el mismo servidor real.

Nota: Si un servicio virtual ha de manejar conexiones FTP, entonces requiere ser

configurado para aplicar reglas de persistencia para el servicio, en el caso de que se utilice

Direct Routing o Tunneling como mecanismo de reenvío. Si se utiliza Masquerading

(NAT) junto a un servicio FTP, entonces no es necesario configurar el servicio de manera

persistente, pero deberá cargarse el módulo del kernel ip_vs_ftp, usando para ello los

comandos insmod o modprobe.


-r --real-server server-address

Las peticiones a un servicio virtual han de ser asociadas a un servidor real. En este sentido,

el algoritmo de scheduling seleccionará un servidor real de entre los que especifiquen con

ese parámetro. El parámetro server-address es la dirección del servidor real, y

también permite especificar un número de puerto. La dirección del servidor real

(server-address) puede proporcionarse mediante la dirección IP o el nombre de host.

El puerto puede indicarse también mediante el número de puerto o bien mediante el

nombre de servicio para ese puerto (http, ftp, etc).

En el caso de utilizar el método de reenvío masquerading (NAT), la dirección del servidor

real es normalmente una dirección IP privada [8], y el puerto puede ser diferente al del

asociado con ese servicio. Para servicios fwmark, el puerto puede ser omitido, en ese caso

el puerto destino en el servidor real será el puerto destino de la petición enviada al servicio

virtual.

[packet-forwarding-method]

Este parámetro establece el método utilizado para reenviar los paquetes hacia los

servidores reales.

-g --gatewaying(Direct Routing)

Es el seleccionado por defecto y es el más rápido dado que no se rescriben las

cabeceras IP puesto que se trabaja a nivel de capa de enlace (capa 2), véase (6.3.2).

-i --ipip(Tunneling)

Encapsula los paquetes IP en IP para su reenvío. Permite que los servidores reales

se encuentren en redes externas, véase (6.3.3).

-m --masquerading (NAT)

Utiliza Network Address Translation (NAT) como método de reenvío. Las

cabeceras IP son reescritas para reenviar los paquetes. Se trabaja a nivel de capa 3,

véase (6.3.1). -w, --weight weight

El peso (weight) es un número entero que especifica la capacidad relativa de un servidor

real frente al resto de servidores reales del cluster. Los valores válidos para este van de 0 a

65535, pero el valor por defecto es 1. Se puede especificar un servidor inactivo

ACADE (LVS) - 87

asignándole un peso igual a cero. Un servidor inactivo no recibirá nuevas peticiones, sea

cual sea el método de scheduling del LVS, pero seguirá ofreciendo sus servicios.

Configurar un servidor inactivo puede utilizarse para evitar la sobrecarga de un

determinado servidor real, o bien para dejarlo fuera de servicio y poder realizar labores de

mantenimiento.

--mcast-interface interface

Especifica la interfaz por la cual el demonio de sincronización de conexiones enviará o

recibirá los mensajes multicast. Este parámetro se utiliza junto a --start-daemon, que

lanza el demonio de sincronización de conexiones.

root@director1:~# ipvsadm –-start-daemon=master –-mcast-interface=eth1

6.8 LVS, Kernel TCP Virtual Server (KTCPVS)

KTCPVS es un balanceador de carga enmarcado dentro del Linux Virtual Server Project

(6.1). KTCPVS implementa balanceo de carga de nivel de aplicación, también conocido

como conmutación de capa 7, dentro del kernel de Linux,. Debido a la sobrecarga que

supone el balanceo de carga de capa 7, es recomendable su implementación dentro del

kernel. A pesar de que KTCPVS es menos escalable que IPVS, es más flexible porque el

contenido de las peticiones es conocido antes de ser redireccionado a los servidores. Este

balanceador de carga está en sus primeros estadios de desarrollo, por lo que no es aun apto

para entornos de producción.

6.9 Direct Routed Web Switch (DRWS)

DRWS es un balanceador de carga de capa 7 y está basado en modificaciones del IPVS

0.9.8. DRWS ha sido desarrollado por Ping-Tsai Tsai <[email protected]> en el High

Speed Network Lab del Department of Computer & Information Science, NCTU.


Al igual que en LVS-DR, DRWS permite que los servidores reales contesten al cliente

directamente, con lo que el balanceador de carga dispone de más recursos para manejar las

peticiones entrantes de los clientes.

DRWS está disponible en <http://speed.cis.nctu.edu.tw/~motse/drws.htm>

6.10 High Up Time Project (HUT)

Este proyecto ofrece similares prestaciones a las que actualmente permite el proyecto LVS,

pero este ha sido desarrollado para sistemas BSD.

El High Up Time Project (HUT) es un sistema de clustering de alta disponibilidad

construido con dos o más servidores reales. HUT corre bajo FreeBSD 4.x y versiones

superiores, y está formado por dos módulos:

-El Demonio del Balanceador de Carga llamado Loadd (para distribuir la carga sobre todos

los servidores)

-El Demonio VRRP llamado Vrrpd (para la redundancia)

En HUT, todas las conexiones son transparentes para el usuario. Si un servidor deja de

prestar servicio, otro toma su lugar y responde a sus conexiones. Así, se pueden dar de baja

todos los puntos de fallo de la red o de la arquitectura del sistema sin que ello afecte a la

prestación del servicio.

El proyecto pretende construir un sistema de clustering a gran escala y está desarrollado

bajo licencia OpenSource.

Vrrpd es la implementación VRRP para FreeBSD 4.x y superiores. Este protocolo permite

crear backups de los servidores estratégicos con un sistema de IP redundante, al estilo de

los clusters activo/pasivo como los que permiten otros sistemas Linux como Heartbeat.

ACADE (LVS) - 89

Actualmente, este proyecto se encuentra en sus primeras fases de desarrollo, si bien su

código ya permite implementar las siguientes características:

HUT se puede montar usando las siguientes arquitecturas:

- NAT

- Direct Routing

- IP Tunneling

HUT implementa los siguientes algoritmos de scheduling:

- Round Robbin Scheduling

- Weighted Round-Robbin Scheduling

- Least-Connection Scheduling

- Least-Load Scheduling

El software HUT está siendo desarrollado por Sebastien Petit un estudiante de ingeniería

especializado en sistema UNÍX y redes Francés.

Para más información:

<http://www.bsdshell.net/hut_project.html>

<http://www.bsdshell.net/hut_hdpage1.html> (documentación en francés)


ACADE (LVS) - 91

7. Cluster activo/pasivo con LVS Una forma de ofrecer alta disponibilidad para un servicio de red, es redundando el servidor

que presta el mismo. De manera que si falla este servidor principal (activo) entre en acción

un servidor de respaldo (pasivo).

7.1 Heartbeat

Heartbeat permite implementar un cluster de alta disponibilidad IP de tipo activo/pasivo.

Heartbeat es, por lo tanto, un software destinado a mantener servicios en alta

disponibilidad bajo Linux, con el objetivo de que estén disponibles ininterrumpidamente.

Para ello, se requiere ejecutar heartbeat simultáneamente en un mínimo de dos máquinas.

La primera máquina, llamada master, es la que ofrece normalmente el servicio. La segunda

máquina, llamada esclava, es la que suplanta a la master en el caso de que, por algún

motivo, esta deje de funcionar y consecuentemente de prestar sus servicios. Tal y como se

explica en la documentación que acompaña a heartbeat, existe la posibilidad de montar

clusters activo/pasivo de más de dos máquinas, si bien no es lo más frecuente dado la

complejidad que suponen este tipo de arquitecturas.

Internet

ServidorMaster

ServidorEsclavo

(de reserva)

Paquetes Heartbeat(Latidos)

Figura 16: Monitorización mediante latidos.

92 - Capítulo 7: Cluster activo / pasivo con LVS

Heartbeat basa su funcionamiento en el envío y recepción de “latidos”, que son las señales

enviadas por los demonios heartbeat que corren en ambas máquinas. La diferencia

entre master y esclavo radica en que el master es quien tiene la prioridad para ofrecer el

servicio. El esclavo pasará a ofrecer el servicio sólo cuando deje de escuchar los latidos del

master por un periodo predeterminado de tiempo, ya que entonces supondrá que éste ha

dejado de funcionar. Tan pronto como el esclavo vuelva a escuchar los latidos del master,

detendrá los servicios que estaba ofreciendo para que el master le tome el relevo y vuelva a

servirlos.

Las máquinas master y esclava deben de estar comunicadas mediante al menos una

interfaz. Heartbeat soporta actualmente las siguientes interfaces: puerto serie (RS-232) y

tarjetas Ethernet. Puede darse el caso de que un error en el enlace o interfaz de una de las

máquinas imposibilite la llegada de latidos a la otra. De esta manera, la máquina que

permanecía a la escucha interpretará erróneamente que el servicio ofrecido por su

homóloga ha caído, e intentará acto seguido lanzar dicho servicio cuando realmente éste no

ha dejado de prestarse en ningún momento. Para minimizar el riesgo de que puedan

producirse este tipo de situaciones, es recomendable el uso de conexiones redundantes,

como por ejemplo, doblar la conexión serie o añadir una conexión cruzada mediante

tarjetas Ethernet adicionales.

Los latidos o paquetes heartbeat pueden ser autenticados mediante MD5 ó SHA1.

Actualmente heartbeat implementa los siguientes tipos de “latidos”:

- Bidirectional Serial Rings (puerto serie)

- UDP/IP broadcast (ethernet, etc.)

- UDP/IP multicast (ethernet, etc.)

- “ping” especiales heartbeat para routers, etc.

ACADE (LVS) - 93

A continuación se muestra la captura de un paquete heartbeat (latido): >>> t=status st=active src=director2 seq=5f hg=61 ts=3dfdb278 ld=0.04 0.10 0.04 2/28 251 ttl=3 auth=2 c968bd9b <<<

El significado de cada uno de los campos sería el siguiente:

Tipo de mensage (t): status Nuevo estado (st): active Generador del paquete (src): director2 Número de secuencia (seq): 5f Heartbeat generation numbre (hg): 61 Marca de tiempo (ts): 3dfdb278 Carga media (ld): 0.04 0.10 0.04 2/28 251 Time to live (ttl): 3 Cadena de autentificación (auth): 2 c968bd9b

Heartbeat es el encargado de lanzar y de detener el servicio que se quiere prestar en alta

disponibilidad. El servicio que lanza heartbeat se presta a través de la misma IP en ambas

máquinas. Puesto que no pueden existir dos direcciones IP iguales en el mismo segmento

de red, se utiliza una dirección IP virtual (VIP). En Linux es posible que una misma

interfaz de red soporte simultáneamente más de una dirección de red mediante el uso de un

alias para la IP. Las máquinas master y esclava tienen cada una de ellas su propia IP.

Heartbeat lanza el servicio que ha de prestarse en alta disponibilidad y activa la VIP en esa

misma tarjeta mediante un alias cuando detecta la ausencia de latidos. Del mismo modo,

cuando heartbeat ha de detener el servicio, desactiva la VIP y detiene el servicio. El hecho

de crear un alias en lugar de configurar una IP estática permite poder acceder a la máquina

para su mantenimiento, aunque esta no se encuentre ofreciendo el servicio de alta

disponibilidad. Crear un alias para configurar la IP virtual, evita además que se deba

actualizar la tabla de rutado del kernel, para añadir el gateway por defecto, cada vez que se

activa la VIP. IPaddr es el script integrante del software heartbeat encargado de activar

y desactivar los alias en el dispositivo de red. IPaddr utiliza parte del código fake de

Horms (7.2).


Takeover es el proceso mediante el cual una máquina se adueña de la IP de otra que ha

dejado de estar activa. Sólo puede considerase efectuado con éxito, si la máquina que deja

de dar el servicio desactiva la IP de su interfaz y posteriormente, la máquina que toma el

relevo, activa dicha IP en la suya. Además, es necesario forzar al resto de máquinas de la

red a que actualicen sus tablas ARP, o de lo contrario encapsularán los paquetes con la

MAC de la máquina a la que se pretende suplantar. Dado que esa máquina ha dejado de

funcionar, los paquetes no alcanzarán su destino. Puesto que la asignación IP con MAC ha

cambiado, es necesario que todas las máquinas (incluido el router) actualicen su caché

ARP. La actualización de las tablas se consigue mediante el envío de peticiones y

respuestas ARP “innecesarias” (gratuitous ARP). Este proceso lo lleva a cabo el código

IPaddr, el cual es ejecutado por heartbeat cuando se produce un fallo en la máquina que

presta el servicio (faliover), o bien cuando el master vuelve a estar activo (failback)

después de un periodo de tiempo en el que fue reemplazado por el esclavo. Para ello,

S D

C isco 2500 SE RIE S

A B C D E F G HS EL EC TE D

ON -LIN E

Caché ARP (router)IP

192.168.3.150MAC

00:20:18:28:04:e9

(servidor2 VIP pública)eth0: 192.168.3.150

MAC:00:20:18:29:3e:d1

MAC00:20:18:29:3e:d1

CISC O YST E MSS

Figura 17: Takeover mediante el envío de gratuitous ARP.

IPaddr invoca a send_arp (send_arp.c) cinco veces para enviar paquetes broadcast

ARP. El objetivo es forzar a los dispositivos directamente conectados en la misma red a

que actualicen las entradas de la VIP en la caché ARP con la nueva MAC. Finalmente,

IPaddr activa o desactiva el alias al dispositivo de red, normalmente eth0:0, con la

dirección IP que presta el servicio.

ACADE (LVS) - 95

Las siguientes capturas, ayudarán a entender de que manera IPaddr consigue cambiar las

caches ARP del resto de máquinas de la red. A continuación se muestra el tráfico generado

por IPaddr durante proceso de takeover:

No. Time Source Destination Protocol Info 1 0.000000 CIS_29:3e:d1 Broadcast ARP Who has 192.168.3.150? Tell 192.168.3.150 2 2 118674.846614 CIS_29:3e:d1 Broadcast ARP 192.168.3.150 is at 00:20:18:29:3e:d1 3 2.039875 CIS_29:3e:d1 Broadcast ARP Who has 192.168.3.150? Tell 192.168.3.150 4 118676.886692 CIS_29:3e:d1 Broadcast ARP 192.168.3.150 is at 00:20:18:29:3e:d1 5 4.069753 CIS_29:3e:d1 Broadcast ARP Who has 192.168.3.150? Tell 192.168.3.150 6 118678.916799 CIS_29:3e:d1 Broadcast ARP 192.168.3.150 is at 00:20:18:29:3e:d1 7 6.101866 CIS_29:3e:d1 Broadcast ARP Who has 192.168.3.150? Tell 192.168.3.150 8 118680.949137 CIS_29:3e:d1 Broadcast ARP 192.168.3.150 is at 00:20:18:29:3e:d1 9 8.138262 CIS_29:3e:d1 Broadcast ARP Who has 192.168.3.150? Tell 192.168.3.150 10 118682.985763 CIS_29:3e:d1 Broadcast ARP 192.168.3.150 is at 00:20:18:29:3e:d1

Como se aprecia en esta captura, la máquina que ejecuta IPaddr realiza 5 peticiones ARP

en las cuales, la máquina 192.168.3.150 solicita la MAC asociada a la IP

192.168.3.150, lo cual a priori parece absurdo. Como resultado de esta petición, la

dueña de la IP 192.168.3.150, se contesta a si misma con la MAC solicitada:

00:20:18:29:3e:d1. Dado que las peticiones ARP son broadcast a nivel MAC, todas

las máquinas actualizarán sus caches ARP al recibir la respuesta a la anterior solicitud

MAC. Así, lo que en un principio parecía “innecesario” se ve justificado a la vista de que

el resultado obtenido es el buscado: que todas las máquinas actualicen sus cachés ARP.

Véase en detalle la petición y respuesta ARP que envía IPaddr:

Frame 1 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: 00:20:18:29:3e:d1, Dst: ff:ff:ff:ff:ff:ff Address Resolution Protocol (request) 0000 ff ff ff ff ff ff 00 20 18 29 3e d1 08 06 00 01 ....... .)>..... 0010 08 00 06 04 00 01 00 20 18 29 3e d1 c0 a8 03 96 ....... .)>..... 0020 ff ff ff ff ff ff c0 a8 03 96 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 ............

Si se decodifica esta petición, se observa que, a nivel de capa de enlace, se encapsula con

un broadcast MAC y por lo tanto, el paquete llega a todas las máquinas de la red.


Frame 1 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: 00:20:18:29:3e:d1, Dst: ff:ff:ff:ff:ff:ff Address Resolution Protocol (request) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (0x0001) Sender MAC address: 00:20:18:29:3e:d1 (CIS_29:3e:d1) Sender IP address: 192.168.3.150 (192.168.3.150) Target MAC address: ff:ff:ff:ff:ff:ff (Broadcast) Target IP address: 192.168.3.150 (192.168.3.150)

La respuesta a esta petición también la hace la máquina 192.168.3.150 (que se

responde a su propia petición).

Frame 2 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: 00:20:18:29:3e:d1, Dst: ff:ff:ff:ff:ff:ff Address Resolution Protocol (reply) 0000 ff ff ff ff ff ff 00 20 18 29 3e d1 08 06 00 01 ....... .)>..... 0010 08 00 06 04 00 02 00 20 18 29 3e d1 c0 a8 03 96 ....... .)>..... 0020 ff ff ff ff ff ff c0 a8 03 96 00 00 00 00 00 00 ................ 0030 00 00 00 00 00 00 00 00 00 00 00 00 ............

Frame 2 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: 00:20:18:29:3e:d1, Dst: ff:ff:ff:ff:ff:ff Address Resolution Protocol (reply) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (0x0002) Sender MAC address: 00:20:18:29:3e:d1 (CIS_29:3e:d1) Sender IP address: 192.168.3.150 (192.168.3.150) Target MAC address: ff:ff:ff:ff:ff:ff (Broadcast) Target IP address: 192.168.3.150 (192.168.3.150)

Como esta respuesta broadcast tiene como destino MAC a todas las máquinas, se consigue

que estas actualicen sus tablas ARP con la dirección MAC de la nueva máquina propietaria

de la IP 192.168.3.150.

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 testea 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 (6.7) para gestionar el LVS. Para más información

sobre este programa véase (7.3).

ACADE (LVS) - 97

Datos del sortware Heartbeat Nombre: Heartbeat Última versión: 0.4.9.2 2002/10/07 Sitio web: http://www.linux-ha.org Autores: Alan Robertson <[email protected]>

Volker Wiegand <[email protected]> Rudy Pawul <[email protected]> Mitja Sarp <[email protected]> Guenther Thomsen <[email protected]> Jacob Rief <[email protected]> Luis Claudio R. Gonçalves <[email protected]> Marcelo Tosatti <[email protected]> Horms <[email protected]> Eric Ayers <[email protected]>

Tom Vogt <[email protected]> (udp code) yuri volobuev <[email protected]>(send_arp.c)

7.2 Fake

Fake es un script que permite activar servidores de backup en un entorno LAN cuando es

requerido. En particular, ha sido diseñado para servidores Mail, Web y servidores Proxy.

Fake permite apropiarse de la dirección IP de otra máquina que esté en la misma LAN.

Para hacerlo, activa una interfaz adicional y hace uso de ARP spoofing. Mediante esta

técnica convence al resto de maquinas de la red de que el servidor de backup, es ahora el

servidor fallido. Esta interfaz adicional puede ser otra interfaz física o bien un alias IP.

Fake es fácil de configurar y se ha diseñado para permitir ser invocado de forma

automática por sistemas como Mon que permiten monitorizar la disponibilidad de un

servidor, también es utilizado por Heartbeat como parte integrante de si mismo. Fake

pude, por otro lado, ser utilizado junto a mecanismos de balanceo de carga como Linux

Virtual Server (LVS),

Datos del programa

Nombre: Fake

Autor: Horms <[email protected]> aka. Simon Horman

Sitio web: <http://www.vergenet.net/linux/fake/>


7.3 Linux Director Daemon Ldirectord Linux Director Daemon (ldirectord) es un demonio programado en Perl, que permite

monitorizar los servicios ofrecidos por los nodos de una granja de servidores reales

balanceados mediante LVS, y añadir o borrar entradas en la tabla de sesiones del kernel del

Servidor Virtual de Linux (LVS), como resultado de la monitorización. De esta manera,

ldirectord permite actualizar dinámicamente las tablas que definen el comportamiento del

balanceador de carga IPVS. Si uno de los realservers 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 realserver.

Funcionamiento

Ldirectord está especialmente diseñado para poder ser llamado desde el programa

Heratbeat, si bien también es posible hacerlo desde la línea de comandos. Ldirectord se

puede configurar para monitorizar los servicios, http, https y ftp de los servidores reales.

Cuando ldirectord es llamado desde heartbeat, lee la información contenida en su archivo

de configuración, especificado en /etc/ha.d/haresources.

director1 IPaddr::192.168.3.150/24 ldirectord::configuration

En este ejemplo, el archivo utilizado se llama configuration y deberá estar ubicado

en /etc/ha.d/conf/. Mediante este archivo se configuran los servicios que ldirectord

ha de monitorizar y configurar en el balanceador, usando llamadas a ipvsadm, en el caso

de que la monitorización sea exitosa.

ACADE (LVS) - 99

Un ejemplo de archivo de configuración podría tener el siguiente aspecto.

# Archivo de configuracion del ldirectord arrancado por heartbeat # checktimeout = 6 checkinterval = 2 virtual = 192.168.3.150:80 real = 192.168.10.101:80 masq 5 real = 192.168.10.102:80 masq 5 service = http scheduler = rr checktype = negotiate request = "articulos.php?id_articulo=PPP2300" receive = "Pintura Plastica Pantone 2300" virtual = 192.168.3.150:21 real = 192.168.10.101:21 masq 5 real = 192.168.10.102:21 masq 5 service = ftp scheduler = rr login = "anonymous" passwd = "[email protected]" persistent = 600 protocol=tcp

Para el servicio http, ldirectord permite monitorizar mediante simples pruebas de

conectividad, checktype = connect o bien mediante pruebas de contenido

checktype = negotiate. En este último tipo de pruebas, se envía una petición:

request = "articulos.php?id_articulo=PPP2300”, y se mira la

respuesta obtenida, receive = "Pintura Plastica Pantone 2300", si el

resultado obtenido es el indicado en recive, se considera que el servicio está

funcionando correctamente. Esto permite monitorizar algo más que el contenido web, ya

que si el valor esperado “Pintura Plastica Pantone 2300” se obtiene tras una

consulta a una base de datos, se comprueba implícitamente el correcto funcionamiento de

la base de datos utilizada por la aplicación web.

La monitorización en el caso del servicio ftp es similar, pero en esta ocasión, en lugar de

realizar un petición y esperar una determinada respuesta, se obtiene el servicio enviando el

correspondiente USER y PASS requerido por el servicio ftp de los servidores reales.

Si el resultado de las monitorizaciones es el esperado, ldirectord añade los servidores

reales especificados en la directiva real para cada uno de los servicios configurados en

el balanceador especificados en la directiva virtual.


Datos del programa

Autors: Jacob Rief <[email protected]>

Horms <[email protected]>, <[email protected]>

Skliarouk Peter <[email protected]>

Sitio Web: <http://www.vergenet.net/linux/ldirectord/>

<http://www.ultramonkey.org> (Horms)

<http://www.linux-ha.org> (Heartbeat)

Descarga:

<http://www.ultramonkey.org/download/>

<http://www.linux-ha.org/download/heartbeat-ldirectord-x.x.x.x-x.i386.rpm>

7.4 Sercice Monitoring Daemon, Mon

Mon es un administrador de tareas y un manejador de alertas de propósito general,

utilizado para monitorizar la disponibilidad de servicios y para disparar alertas en caso de

detección de fallos. Mon fue diseñado para ser abierto y extensible, en el sentido de que

acoge facilidades de monitorización arbitrarias y métodos de alerta vía una interfaz común,

las cuales son implementadas fácilmente con programas en C, shellscript, capturadores

SNMP y capturadores (paquetes UDP) mon especiales.

Mon ve la monitorización de recursos como dos tareas separadas: el examen de una

condición y la ejecución de una acción en ante un fallo. Mon fue diseñado para

implementar las tareas de prueba y de ejecución de acciones mediante programas

separados y con autonomía propia. Mon es esencialmente un programador que ejecuta los

monitores (cada uno prueba una condición específica) y pone en funcionamiento las alertas

apropiadas si éste fallase. La decisión de invocar a una alerta está gobernada por una

lógica, la cual ofrece varias características y dependencias que son configuradas por el

usuario.

Los monitores y las alertas no son una parte del núcleo del servidor mon, incluso aunque la

distribución venga con algunos de ellos, ya programados, para facilitar la programación de

monitores propios. Esto significa que si un servicio nuevo necesita ser monitorizado, o si

ACADE (LVS) - 101

una nueva señal de alerta es necesaria, el servidor mon no precisará ser cambiado, lo que

implica que mon sea fácilmente extensible.

Mon se compone de un servidor (mon), un cliente (moncmd) y un cliente web/text

(monshow).

mon: Monitoriza la disponibilidad de servicios, envía alarmas al detectar fallos.

moncmd: Envía comandos al demonio servidor mon y muestra los resultados.

monshow: Interface web.

Datos del programa

Autor: Jim Trocki <[email protected]>

Sitio Web: <http://www.kernel.org/software/mon/>

Descarga: <ftp://ftp.kernel.org/pub/software/admin/mon/>


ACADE (LVS) - 103

8. Software de servidor

Implementar una arquitectura de alta disponibilidad basada en balanceadores de carga

LVS, implica el disponer de servidores reales. Lo servidores reales son los encargados de

prestar los servicios de red que balancea el software LVS. En este capítulo se describen las

características principales del software libre más destacable, disponible actualmente para

prestar servicios web (Apache), bases de datos (MySQL), FTP (ProFTPD) y lenguajes de

programación de servicios web (PHP).

8.1 Apache

El servidor Apache HTTP es un proyecto de la Apache Software Fundation, para

desarrollar y mantener un servidor HTTP de código abierto para sistemas operativos

modernos como UNIX o Windows. El objetivo de este proyecto es proveer un servidor

seguro, eficiente y extensible que proporcione servicios HTTP en sintonía con los actuales

estándares de HTTP. Apache es el servidor web más popular de Internet desde abril del

1996. Como características principales del mismo destacan:

- Soporte de los últimos protocolos incluyendo HTTP/1.1 [9]

- Es altamente configurable y extensible mediante módulos externos.

- Puede personalizarse mediante la programación de módulos personalizados

utilizando la API de la que dispone.

- Se distribuye junto a su código fuente y dispone de una licencia no restrictiva.

- Funciona sobre plataformas Windows NT/9x, Netware, OS/2 y la mayoría de

sistemas UNIX.

- Está en desarrollo constante y abierto a nuevas ideas, reporte de errores etc.

Actualmente se mantienen es desarrollo dos ramas de este servidor, la 1.3 y la 2.0. Los

desarrolladores trabajaron durante más de dos años antes de liberar la primera versión beta

de Apache 2.0 en abril de 2001. Una de las principales mejoras de la versión 2.0 es que se

104 - Capítulo 8: Software de servidor

ha añadido soporte multi-threading para aumentar el rendimiento del proceso que sirve las

peticiones, por lo que fue necesario rescribir totalmente el código.

La versión 1.3 es actualmente la más utilizada en entornos de producción si bien la

segunda versión del servidor está llamada a sustituir definitivamente a la primera. Por el

momento, ambas versiones gozan de pleno soporte y siguen siendo periódicamente

actualizadas por parte de sus desarrolladores.

8.2 PHP

La mejor descripción de lo que es PHP sea quizás la aparecida en el prefacio del manual de

PHP [10], disponible en su sitio web.

“PHP, acrónimo de ‘PHP: Hypertext Preprocesor’, es un lenguaje ‘Open Source’

interpretado de alto nivel, especialmente pensado para desarrollos web y el cual puede ser

embebido en páginas HTML. La mayoría de su sintaxis es similar a C, Java y Perl y es

fácil de aprender. La meta de este lenguaje es permitir escribir a los creadores de páginas

web, páginas dinámicas de una manera rápida y fácil, aunque se pueda hacer mucho más

con PHP.”

A diferencia de otros lenguajes como JavaScript, que se ejecuta en el cliente, PHP se

ejecuta en el servidor y envía el resultado de esta ejecución al cliente junto con el resto del

código HTML. El código PHP está embebido dentro del código HTML que se envía

directamente al cliente. Así, mediante unas etiquetas especiales de inicio y final, se puede

ir insertando código PHP. El navegador del cliente recibirá el código HTML y el resultado,

si lo hay, producido tras la ejecución del código PHP.

PHP permite realizar fácilmente las mismas tareas que pueda realizar un script CGI, como

procesar la información de formularios, generar páginas con contenidos dinámicos, o

mandar y recibir cookies etc.

ACADE (LVS) - 105

PHP puede ser ejecutado en la mayoría de los sistemas operativos. Así, existen versiones

para Linux, Unix (incluido HP-UX, Solaris, FreeBSD y OpenBSD), Microsoft Windows y

Mac OS X. También es capaz de operar con los servidores web más importantes,

incluyendo Apache, Microsoft Internet Information Server, Personal Web Server, iPlanet

(ahora Sun[tm] ONE Web Server), Oreilly Website Pro server, Caudium, Xitami,

OmniHTTPd y muchos otros.

PHP no sólo genera código HTML. Es posible crear código XHTM, XML, crear imágenes,

archivos PDF, y películas Flash.

PHP es capaz de operar con multitud de diferentes tipos de bases de datos. El acceso a

bases de datos es realmente sencillo mediante PHP. Éste puede operar directamente con las

siguientes bases de datos: Adabas D, dBase, Empress, FilePro(sólo-lectura), Hyperwave,

IBM DB2, Informix, Ingres, InterBase, FrontBase, MSQL, Direct MS-SQL, MySQL,

ODBC, Oracle (OCI7 y OCI8), Ovrimos, PostgreSQL, Solid, Sysbase, Unix dbm y

Velocid. También es posible trabajar con cualquier otra base de datos que soporte el

estándar DBX u ODBC (The Open Database Connection Standard).

PHP permite comunicarse con otros servicios que utilicen los protocolos LDAP, IMAP,

SNMP, NNTP, POP3, HTTP, COM (en Windows) y otros. Es capaz de utilizar objetos

Java y la extensión de CORBA para acceder a objetos remotos.

Para el proceso de texto, dispone de características como las expresiones regulares POSIX

Extended, Perl o el parseador de documentos XML. Además dispone de interesantes

funciones para el comercio electrónico, entre las que destacan Cybercash, CyberMUT,

VeriSign Payflow Pro y CCVS.

8.3 MySQL Database Server

Según sus creadores, MySQL es la base de datos de código abierto más popular del

mundo, diseñada para ser veloz, poderosa y precisa en misiones críticas y de gran

capacidad de carga.

106 - Capítulo 8: Software de servidor

MySQL es un sistema de gestión de bases de datos relacionales, que sigue los estándares

ANSI SQL y ODBC SQL, y usa la implementación de expresiones regulares de Henry

Spencer que cumplen con POSIX 1003.2.

Por otra parte, MySQL dispone de capacidades para la replicación de bases de datos. Para

ello, pueden seleccionarse dos tipos de modos: master fijo y master variable.

En el modo master fijo, uno de los servidores del cluster centraliza el proceso de escritura

en la base de datos e informa periódicamente a los demás esclavos de las actualizaciones.

Si el master sufre algún percance, todo el sistema se viene abajo. En este modo por tanto,

los esclavos únicamente permite realizar operaciones de lectura en su base de datos.

En el modo master variable, cualquier nodo del cluster puede convertirse en master en

caso de problemas, pero solamente de modo exclusivo, por lo que la escritura en la base de

datos continua siendo centralizada por un solo elemento.

8.4 ProFTPD

ProFTPD es un servidor de FTP escalable y de características avanzadas escrito desde cero

bajo las premisas de la simplicidad, seguridad y facilidad de configuración. ProFTPD se

utiliza en algunos de los mayores sitios de Internet. Entre sus características principales

destacan, la simplicidad de la sintaxis de programación, similar a la de Apache y la

posibilidad de utilizar módulos. Incluye soporte para múltiples servidores FTP virtuales,

FTP anónimo, y visibilidad de directorios basada en permisos.

ACADE (LVS) - 107

Parte 3: Cluster Acade (LVS). Descripción, funcionamiento y

pruebas efectuadas

9. Cluster Acade (LVS)

En esta parte de la memoria, se realiza una descripción funcional de la arquitectura de

clustering de alta disponibilidad y escalabilidad, implementada para la realización de la

segunda parte del trabajo. La arquitectura ha sido bautizada con el nombre de cluster

Acade. El “Manual Acade” anexado (anexo V), describe los pasos para montar la solución

aquí descrita.

Figura 18: Cluster Acade en acción.

108 - Capítulo 9: Cluster Acade (LVS)

9.1 ¿Qué es el cluster Acade (LVS)?

El cluster Acade implementa la arquitectura mínima necesaria para evaluar las capacidades

de alta disponibilidad y escalabilidad que ofrece una solución de clustering basada en

software libre LVS-NAT.

9.2 Componentes software utilizados (LVS+Heartbeat+ldirectord)

Los clusters de alta disponibilidad de IP (activo/pasivo) permiten garantizar la alta

disponibilidad de un servicio de red. Por otra parte, los clusters basados en balanceadores

de carga proporcionan arquitecturas altamente escalables y manejables. Heartbeat y Linux

Virtual Server (LVS) permiten crear clusters de alta disponibilidad de IP y balanceadores

de carga respectivamente. Acade utiliza aspectos de la filosofía en la que se basan los

clusters de alta disponibilidad de IP, aprovechando también la alta escalabilidad que

ofrecen los balanceadores de carga.

Como resultado se obtiene una solución que ofrece alta disponibilidad, escalabilidad y

manejabilidad en los servicios ofertados. Acade se sirve de ldirectord 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 Acade utilizan el servidor Apache junto con

PHP y la base de datos MySQL para servir contenido web dinámico. También se ha

experimentado satisfactoriamente con el servicio FTP (ProFTP) lo que ha permitido

evaluar las capacidades para garantizar la persistencia en aquellos servicios que la

requieren.

El (anexo VIII) incluye todo el software utilizado para implementar el cluster Acade. La

programación del sitio web ofrecido por Acade ha sido desarrollada íntegramente en PHP,

JavaScript y MySQL (anexo IV). Se trata de la sección de documentación y eventos de la

Asociación de Soporte Al Software Líbre (ASSL) <http://assl.ath.cx>. El código fuente de

la misma está disponible en el CD-ROM del (anexo VI).

ACADE (LVS) - 109

9.3 Servicios ofrecidos

Los servicios ofrecidos por el cluster Acade son dos: Servicio web y FTP. El primero de

ellos, consiste en un sitio web dinámico que accede a una base de datos, el segundo ofrece

un servidor de FTP anónimo. El sitio web albergado por el cluster ha sido desarrollado,

paralelamente a este proyecto, para la ASSL. Actualmente forma parte del sitio web de

dicha asociación, conformando la sección de documentación y eventos de la misma.

9.4 Topología Física del cluster Acade

Se compone de 4 máquinas. Dos balanceadores de carga (director1 y director2) y

dos servidores reales (rserver1 y rserver2). Estas cuatro máquinas están conectadas

entre si mediante una red Ethernet conmutada. Los balanceadores carga disponen de una

segunda interfaz que les conecta con la red exterior compartida. Además, los directors

están interconectados entre si mediante un enlace serie.



O N -LIN E


O N - LIN E

eth0:0 VIP: 192.168.3.150eth0 IP: 192.168.3.155eth0 MAC: 00:20:18:28:04:e9

eth0:0 VIP: 192.168.3.150eth0 IP: 192.168.3.156eth0 MAC: 00:20:18:29:3e:d1

eth1:0 VIP: 192.168.10.100eth1 IP: 192.168.10.2eth1 MAC: 00:e0:29:25:4e:aa

eth1:0 VIP: 192.168.10.100eth1 IP: 192.168.10.1eth1 MAC: 00:e0:29:25:4d:4c

eth0 IP: 192.168.10.102eth0 MAC: 00:e0:29:25:46:57

eth0 IP: 192.168.10.101eth0 MAC: 00:e0:29:25:4e:9a

eth0 IP: 192.168.3.157eth0 MAC: 00:e0:98:33:6a:b8

eth0 IP: 192.168.3.158eth0 MAC: 00:06:5B:31:4B:74

director2director1

rserver1 rserver2

client1 client2

Topología Física del Cluster Acade

Figura 19: Cluster Acade.

9.5 Topología lógica del cluster Acade

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 directors a

ambas, actuando de este modo como pasarelas.

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. Estas direcciones son idénticas para ambos directors, pero nunca están activas

simultáneamente en los dos. La gestión dinámica de las VIPs es tarea heartbeat, si bien el

encargado de ejecutar esta tarea es IPaddr. La principal ventaja de esta topología es la de

permitir el uso de cualquier sistema operativo en los servidores reales.

ACADE (LVS) - 111

9.6 Funcionamiento e interrelación de los diferentes elementos software

de Acade.

El cluster Acade es un cluster activo/pasivo de servidores virtuales Linux (balanceadores

de carga) que ofrecen los servicios que corren en los servidores reales. Acade 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 cualquier momento, el balanceador de carga de reserva puede cambiar su rol y

pasar a ser el balanceador 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 la utilización 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.

A continuación, se enumeran todos los elementos software a los que se ha recurrido para

implementar la arquitectura Acade (figura 21), el papel que realiza cada uno de ellos en el

escenario Acade y que relación se establece entre todos ellos.

9.6.1 Software utilizado en los balanceadores de carga.

A continuación, se explica el papel que desarrollan los diferentes elementos software

utilizados en los balanceadores de carga director1 y director2 del cluster Acade.

Sistema operativo (Slackware 8.1)

El balanceador de carga utilizado, IPVS está programado para formar parte integrante del

kernel Linux. Ello implica la utilización de un sistema operativo que incorpore dicho

kernel, por lo que se ha optado por el sistema operativo GNU, que actualmente se basa en

él. La distribución elegida ha sido Linux Slackware 8.1 dado que es la que posee un mayor

conocimiento por parte de sus autores.


- Scripts de inicialización del sistema

El archivo principal para la puesta a punto de los dispositivos de red y desde el que se

lanzan las aplicaciones es el /etc/rc.d/rc.local, el cual presenta el siguiente

aspecto:

#!/bin/sh # # /etc/rc.d/rc.local: Local system initialization script. # # Put any local setup commands in here: # Logs del hertbeat y de ldirectord en la shell tail -f /var/log/messages >/dev/tty12 & tail -f /var/log/ha-log > /dev/tty8 & tail -f /var/log/ha-debug > /dev/tty9 & tail -f /var/log/ldirectord.log > /dev/tty10 & # Configuración de los dispositivos de red /sbin/ifconfig eth0 192.168.3.156 /sbin/ifconfig eth1 192.168.10.2 /sbin/ifconfig lo 127.0.0.1 /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo /sbin/route add default gw 192.168.3.1 eth0 # Cargamos el demonio de sincronización de la tabla de sesiones de LVS /sbin/ipvsadm --start-daemon backup # cargamos el modulo para poder hacer ls en ftp con LVS NAT /sbin/modprobe ip_vs_ftp # Iniciamos el programa q mantiene el servicio de alta disp. (LVS) /etc/init.d/heartbeat start

Este archivo es utilizado para que el sistema, al arrancar, tenga los diferentes dispositivos

de red de acuerdo a la topología Acade. Desde aquí también se lanza el demonio de

sincronización de la tabla de sesiones de IPVS y se carga el módulo ip_vs_ftp que

garantiza la persistencia de las sesiones FTP. Finalmente, se lanza el programa Heartbeat

encargado de realizar el resto de configuraciones en la máquina si así se requiere.

ACADE (LVS) - 113

Balanceador de carga (IPVS)

- Descripción

El parche IPVS para el kernel Linux, le dota de las características necesarias para que se

convierta en un balanceador de carga de capa 4. Los balanceadores de carga del cluster

Acade se implementan mediante un Kernel estandard Linux 2.4.19 parcheado con la

versión correspondiente del código IPVS.

- Funcionamiento

IPVS crea dos tablas en el kernel de Linux. La primera de ellas es la tabla de servicios y

servidores reales, contiene información acerca de los servicios (protocolo/puerto) que

balanceará IPVS. La segunda, es la tabla de conexiones activas o sesiones, en la que se

introduce una entrada para cada una de las conexiones que el cluster está balanceado hacia

un servidor real.

Cada vez que llega un paquete, se mira si corresponde con alguno de los servicios descritos

en la primera tabla. Si es así, se mira entonces si dicho paquete corresponde con alguna de

las entradas de la segunda tabla (conexiones ya establecidas), de ser así, este paquete se

reenvía al servidor que indica dicha entrada. En caso contrario, el scheduler selecciona un

servidor real para este paquete, de entre los que figuran en la primera tabla, refleja esta

conexión en la segunda y rescribe la cabecera IP del paquete para enviarlo al servidor real

elegido.

En la arquitectura Acade, las reglas que definen el contenido de la tabla de servicios y

servidores reales, se crean dinámicamente mediante ipvsadm, el demonio ldirectord. Dado

que ldirectord monitoriza constantemente el estado de los servicios de los servidores

reales, el balanceador sólo reenviará paquetes a un servidor real cuando éste se encuentre

disponible.

Dado que IPVS funciona a nivel de kernel de Linux, entra en funcionamiento en el mismo

momento en que se arranca el sistema sin que sea necesario lanzarlo, si bien, no se

configuran sus servicios hasta que Heartbeat realice las acciones oportunas para hacerlo.


Interface para administrar el balanceador de carga (Ipvsadm)

- Descripción

Ipvsadm es el administrador del balanceador de carga IPVS, y permite configurar los

servicios y servidores reales que configuran al balanceador. Gracias a esta herramienta, es

posible determinar qué servicios ha de ofrecer el balanceador de carga, así como

especificar qué servidores reales los están ofreciendo. Ipvsadm también permite lanzar el

demonio de sincronización de conexiones, el cual posibilita al balanceador de reserva,

mantener actualizada la tabla de conexiones activas, pese a no estar balanceando tráfico en

ese momento. De esta forma y llegado el momento, podrá sustituir al balanceador activo y

hacerse cargo de las conexiones ya establecidas en la otra máquina, con lo que de esta

manera se evita que éstas se pierdan con el cambio de balanceador.

- Funcionamiento

En una arquitectura LVS estática, se configurarían los servicios y servidores estáticos,

mediante un script de inicialización. Este script realizaría llamadas a ipvsadm con los

parámetros necesarios para la configuración del balanceador. De esta manera, no se

contempla la posibilidad de que uno o varios servidores reales puedan dejar de funcionar,

ya sea por fallo del mismo o por detención voluntaria por parte de los administradores del

cluster. Dado que la arquitectura Acade busca la alta disponibilidad, escalabilidad y

manejabilidad de los servicios ofrecidos, se hacen necesarios una serie de demonios,

programas y scripts que permitan la configuración dinámica y automática del cluster en

función del estado del resto de nodos que lo componen.

Así, ipvsadm es utilizado por el demonio de monitorización de servidores reales

(ldirectord) para configurar y mantener constantemente actualizada la configuración del

balanceador de carga (IPVS). Por otro lado, se ha creado el script ipvsyncd, que es

ejecutado por heartbeat y que mediante llamadas a ipvsadm lanza y configura el

demonio de sincronización de conexiones, el cual permite que un balanceador pueda

suplantar al otro sin que ello suponga el que se pierdan las conexiones ya establecidas.

ACADE (LVS) - 115

Solución IP Failover (Heartbeat)

- Descripción

Heartbeat es junto al código IPVS, pieza fundamental de la arquitectura Acade. Heartbeat

permite ofrecer servicios en alta disponibilidad. El servicio ofrecido en este caso no es otro

que LVS. Heartbeat es el encargado de velar de que en todo momento exista un

balanceador de carga activo en el cluster, monitorizando constantemente la salud del

balanceador de carga remoto. Para esta tarea, utiliza el envío y recepción de latidos. Si

heartbeat deja de recibir estos latidos, interpreta que el balanceador de carga remoto a

dejado de prestar sus servicios y lanza una serie de programas para reactivarlos en la

máquina en la que se ejecuta.

- Funcionamiento

El envío y recepción de latidos se realiza en la arquitectura Acade a través del puerto serie

de los balanceadores de carga (/dev/ttyS0).

Heartbeat es el encargado de levantar y configurar las interfaces de red, para ello se sirve

del código IPaddr. IPAddr configura las interfaces de red del nuevo balanceador de

carga con la VIP y la DIP. De esta manera se adueña de la IP que ofrece los servicios

virtuales. Heartbeat fuerza entonces, también mediante IPaadr, al resto de máquinas del

cluster a que actualicen sus caches ARP (gratouitous ARP) para que actualicen la MAC de

la VIP.


A B C D E F G HS ELE CT EDO N-L INE

S D

Ci s co 2 500S ER IE S

Caché ARP (rserver2)IP

192.168.10.100M AC

00:e0:29:25:4d:4c

Caché ARP (rserver1)IP

192.168.10.100M AC

00:e0:29:25:4d:4c

A B C D E F G HS ELE CT EDO N-L INE

Caché ARP (router)IP

192.168.3.150M AC

00:20:18:28:04:e9

(director1 V IP pública)eth0: 192.168.3.150

MA C: 00:20:18:28:04:e9

(director2 V IP pública)eth0: 192.168.3.150

MA C: 00:20:18:29:3e:d1

(director2 V IP interior)eth1: 192.168.10.100

MA C: 00:e0:29:25:4e:aa

(director1 V IP interior)eth1: 192.168.10.100

MAC: 00:e0:29:25:4d:4c

MA C00:20:18:29:3e:d1

MAC00:e0:29:25:4e:aa

MA C00:e0:29:25:4e:aa

C I S C O Y S T E M SS

Figura 20: Takeover en Acade.

Heartbeat también lanza el demonio ldirectord, que configura la tabla del kernel del

balanceador de carga IPVS, estableciendo los servidores y servicios con los que trabajará

el balanceador carga. Ldirectord además monitorizará el estado de los servidores reales y

mantendrá actualizada la tabla de servicios constantemente, evitando de este modo el envío

de paquetes a un servidor que no se encuentre disponible.

Heartbeat es además utilizado en Acade para ejecutar el script ipvsyncd, creado para

esta arquitectura, y que cambia la configuración del demonio de sincronización de

conexiones. Este demonio es configurado como master o como backup en función del

estado activo/pasivo del balanceador de carga, de manera que envíe mensajes multicast

ACADE (LVS) - 117

periódicamente al demonio remoto, o bien reciba estos mensajes y actualice la tabla de

conexiones del kernel con la información que estos contienen, que no es otra que las

conexiones establecidas en el otro balanceador de carga.

Configuración dinámica de interfaces (IPaddr)

- Descripción

IPaddr será el encargado de levantar configurar y activar las interfaces de red del

balanceador de carga cuando heartbeat así se lo ordene. Además, mediante el envío de

gratuitous ARP (7.1), fuerza al resto de máquinas a actualizar sus caches ARP.

- Funcionamiento

En la arquitectura Acade, el método de reenvío utilizado por los balanceadores de carga es

LVS-NAT. Para ello, se utilizan dos tarjetas de red en cada servidor (eth0 y eth1). La IP

virtual VIP se asigna al dispositivo eth0 mediante un alias a este (eth0:0). Del mismo

modo, la IP por la que se reenviarán los paquetes hacia los servidores reales también es

flotante. En la red interna, IPaddr también mantiene una IP flotante que se activa

levantando un alias al dispositivo eth1 (eth1:0).

Sistema de monitorización de servidores (Ldirectord)

- Descripción

Ldirectord es un script en Perl que permite configurar y monitorizar los servicios y

servidores con los que trabajará el balanceador de carga, con lo que es posible configurar y

mantener siempre actualizada la tabla que define el comportamiento del balanceador de

carga.

- Funcionamiento

Ldirectord es también lanzado por Heartbeat y realiza dos funciones. En primer lugar,

configura los servicios que ha de prestar el balanceador de carga. Para ello, realiza las

llamadas a ipvsadm necesarias, en función de lo que se especifica en su archivo de

configuración (anexo III). En segundo lugar, monitoriza constantemente los servicios

ofrecidos por los servidores reales. En Acade, éste se ha configurado para comprobar el

estado de los servicios HTTP y FTP de los servidores reales. Para determinar el correcto

funcionamiento de estos servicios, este programa envía peticiones periódicas a los puertos


en los que corren los servicios web y ftp. Si ldirectord recibe una respuesta satisfactoria a

estas peticiones, mantiene ese servidor en la tabla de servidores del kernel, en caso

contrario borra ese servidor real de la tabla. De esta manera, ldirectord permite monitorizar

la disponibilidad de los servicios de los servidores reales.

Control del demonio de sincronización de conexiones (Script IPVSyncd)

- Descripción

IPVSyncd (anexo III) es un script que cambia el rol del demonio de sincronización de

conexiones de IPVS del modo master a esclavo y viceversa, cuando Heartbeat así se lo

indica.

- Funcionamiento

IPVSyncd ha sido escrito para Acade para que actué como intermediario entre Heartbeat y

el demonio de sincronización de conexiones de IPVS. El script es lanzado por Heartbeat

con el parámetro de entrada start o stop para que decida que tipo de llamada debe de

efectuar a ipvsadm, para que el demonio quede configurado como master o como backup

según sea necesario. Las llamadas a ipvsadm constan de dos pasos. Primero se detiene el

demonio para posteriormente lanzarlo en modo master o esclavo. Así, el demonio del

balanceador activo será siempre configurado como master y el del balanceador de reserva

como backup. Todo el proceso se basa en la capacidad que tiene heartbeat para determinar

el estado de los directors. De este modo, nunca hay activos dos masters o dos esclavos

simultáneamente.

El demonio de sincronización de conexiones master, envía con cierta periodicidad las

actualizaciones en forma de paquete multicast, que contienen las nuevas conexiones.

En el cambio de rol, sólo se perderán aquellas nuevas conexiones que se reciben entre el

envío del último paquete de actualización por parte del antiguo master, hasta que el

director que le releva asume sus funciones. Cuando el director que originalmente tiene la

prioridad para ser master vuelve a iniciarse en sus tareas, primero debe de configurarse en

modo esclavo para recibir la tabla de conexiones. Después, cuando heartbeat entre en

funcionamiento, el director secundario dejará de ser master para pasar a ser esclavo al

mismo tiempo que el director principal pasará de esclavo a master.

ACADE (LVS) - 119

KE

RN

EL+

IPVS

pat

ch

hea

rtbe

atIP

add

r(f

ake)

ipv

sadm

ldire

ctor

d

scri

ptIP

VSY

NC

Apa

che

(htt

pd)

Pro

FTP

MyS

QL

MO

D_P

HP

rser

ver1

dire

ctor

1(m

aste

r)

SER

IAL

/dev

/ttyS

0et

h0:

0et

h0

Tab

la d

ese

rvic

ios

yse

rvid

ores

Tab

la d

eco

nexi

ones

Con

nect

ions

sync

(M

aste

r)da

emon

Con

teni

doW

eb

Fot

os

Doc

s

Cód

igo

PH

P

Bas

e de

dato

s

Apac

he(h

ttpd

)P

roFT

P

MyS

QL

MO

D_P

HP

rser

ver2

Con

teni

doW

eb

Fot

os

Doc

s

Cód

igo

PH

P

Bas

e de

dato

s

KER

NE

L+

IPV

S p

atch

hea

rtb

eat

IPad

dr

(fak

e)

ipvs

adm

ldire

ctor

d

scri

ptIP

VSY

NC

dire

ctor

2(b

acku

p)

SER

IAL

/dev

/ttyS

0et

h0:0

Tab

la d

ese

rvic

ios

yse

rvid

ores

Tab

la d

eco

nexi

ones

Con

nect

ions

sync

(M

aste

r)da

emon

eth1

eth1

eth

1:0

eth

0et

h0

paq

uete

s he

artb

eat (

latid

os)

paq

uete

s m

ultic

ast

(sin

cron

izac

ión

de c

onex

ione

s)

petic

ione

s ht

tp y

ftp

para

lam

onito

riza

ción

de

los

serv

idor

es r

eale

s

com

unic

ació

n en

tre

proc

esos

inte

rnos

activ

ació

n de

inte

rfac

es

com

unic

ació

n en

tre

proc

esos

rem

otos

Esq

uem

a S

oftw

are

AC

AD

E (

LVS

)

Figura 21: Esquema software Acade (LVS).


9.6.2 Software utilizado 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 Acade.

Sistema operativo (Slackware 8.1)

Pese a que LVS-NAT permite utilizar, en los servidores reales, cualquier sistema operativo

capaz de ejecutar la pila TCP/IP, se ha optado por utilizar un sistema operativo libre GNU,

si bien, en un principio se valoró la posibilidad de utilizar sistemas FreeBSD en los

servidores reales, finalmente se opto por Slackware por razones de homogeneidad.

- Scripts de inicialización del sistema

En los servidores reales, la red se configura normalmente desde el archivo

/etc/rc.d/rc.inet1, por otro lado, el archivo etc/rc.d/rc.local es utilizado

para lanzar la base de datos MySQL. El script /etc/rc.d/rc.httpd es llamado desde

el script /etc/rc.d/rc.M para lanzar el servidor web Apache. El servicio de ftp es

lanzado por el demonio inetd.

Sistema software para servir la aplicación web (Apache + PHP + MySQL)

En el cluster Acade, el contenido web es servido por el servidor Apache junto con el

modulo PHP de éste, y la base de datos utilizada es MySQL. En el anexo está disponible el

código PHP (anexo VI) para el sitio web así como el código (anexo IV) que define la base

de datos MySQL. También está disponible en el Manual Acade (anexo V) el proceso

detallado para la instalación y configuración y puesta en marcha de estos tres componentes.

Sitio web (Sección de documentación y eventos de la ASSL)

El contenido web que sirve Acade está formado por documentos, fotos y los datos

almacenados en la base de datos documentacion. El código PHP, es el encargado de

ofrecer todo este contenido de una forma clara y sencilla al usuario de esta web.

ACADE (LVS) - 121

Servidor FTP (ProFTPD)

A fin de probar la capacidad de ofrecer servicios que requieren de persistencia, se opto por

configurar los servidores reales con un servidor de FTP. Posteriormente, se configuraron

los balanceadores de carga para permitir ofrecerlo adecuadamente. El sistema de

monitorización ldirectord que corre en los directors, también fue configurado para que

realizara la monitorización del correcto funcionamiento de ProFTPD. Esta monitorización

consiste en “logearse” en el servicio y bajarse un archivo predeterminado. Posteriormente,

se buscan una serie de palabras clave en dicho archivo.

9.7 Pruebas realizadas

El cluster Acade implementado en este proyecto, ofrece servicio web y ftp a los clientes,

los cuales acceden a ellos, de la misma forma que lo harían si estos 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 es consciente de que estos están siendo

prestados a través de un balanceador de carga. Un cliente que acceda al servicio web

disponible en la dirección IP virtual 192.168.3.150, verá algo similar a esto:

Figura 22: Ejemplo de acceso al servicio web del cluster Acade.


Del mismo modo, si un cliente accede al servicio de ftp ofrecido en esa misma dirección,

tendrá un acceso normal a dicho servicio, sin ser consciente de si su petición está siendo

reenviada persistentemente a un servidor real o no.

Figura 23: Ejemplo de acceso al servicio ftp via web del cluster Acade.

A continuación, se exponen las pruebas realizadas al cluster, el cumplimiento de las cuales

permiten que los servicios sean mostrados correctamente al cliente.

9.7.1 Balanceo de carga.

Cuando el cliente obtiene en su navegador el contenido mostrado en la figura 22, 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

ACADE (LVS) - 123

observa que se han realizado dos conexiones TCP a servidores reales distintos, como

muestra la siguiente tabla de sesiones:

root@director1:/etc/ha.d/conf# ipvsadm -lnc IPVS connection entries pro expire state source virtual destination TCP 14:56 ESTABLISHED 192.168.3.157:1075 192.168.3.150:80 192.168.10.101:80 TCP 14:56 ESTABLISHED 192.168.3.157:1074 192.168.3.150:80 192.168.10.102:80

Lo cual demuestra que se están balanceado las peticiones realizadas por los clientes.

9.7.2 Persistencia de sesión

Determinados servicios como el ftp, requieren utilizar dos puertos del servidor para ser

prestados. En el primero se establece el canal de control y el segundo es utilizado para la

transferencia de los archivos. Cuando el cliente se baja un archivo del cluster Acade, es

necesario que el balanceador reenvíe persistentemente las conexiones del cliente hacia el

mismo servidor real. En un cluster basado únicamente en la dirección IP origen del cliente,

todas las conexiones, sean del servicio que sean, se reenvían al mismo servidor real. El

balanceador de carga LVS, sin embargo, utiliza un método de balanceo basado en

Persistent Port Connection (PPC) (3.8.2), y además, gracias al modulo ip_vs_ftp es

capaz de implementar el método de conexiones concurrentes (3.8.2), lo cual le permite

discernir entre las conexiones a diferentes servicios realizadas por un mismo cliente, de

manera que asegure la persistencia para el servicio ftp y sin embargo, se balanceen las

peticiones a otros servicios.

La siguiente captura, muestra el contenido de la tabla de conexiones cuando un mismo

cliente está utilizando los servicios web y ftp del cluster Acade. Se observa como las

conexiones pertenecientes a los puertos del ftp, puertos 20 y 21 del servidor, se reenvían

persistentemente a la dirección 192.168.10.102, en cambio las conexiones realizadas

al servicio http (puerto 80) son balanceadas de acuerdo al algoritmo de scheduling round

robin.


root@director1:/etc/ha.d/conf# ipvsadm -lnc IPVS connection entries pro expire state source virtual destination TCP 08:59 NONE 192.168.3.157:0 192.168.3.150:0 192.168.10.102:0 TCP 01:40 TIME_WAIT 192.168.3.157:1087 192.168.3.150:20 192.168.10.102:20 TCP 01:28 TIME_WAIT 192.168.3.157:1086 192.168.3.150:20 192.168.10.102:20 TCP 14:40 ESTABLISHED 192.168.3.157:1085 192.168.3.150:21 192.168.10.102:21 TCP 14:56 ESTABLISHED 192.168.3.157:1089 192.168.3.150:80 192.168.10.101:80 TCP 14:56 ESTABLISHED 192.168.3.157:1088 192.168.3.150:80 192.168.10.102:80

9.7.3 Monitorización de contenidos

La monitorización de contenidos realizada por el cluster Acade, permite garantizar la alta

disponibilidad de los servidores reales, de manera que si el sistema encuentra algún

problema con los servicios ofrecidos por los servidores reales, se dejarán de reenviar

nuevas peticiones hacia dichos servidores.

En condiciones normales, la tabla que muestra los servicios configurados en el balanceador

de carga activo, mostrará los siguientes servicios y servidores:

root@director1:~# ipvsadm IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP virtualip.acade.net:ftp rr persistent 600 -> rserver2.acade.net:ftp Masq 5 0 0 -> rserver1.acade.net:ftp Masq 5 0 0 TCP virtualip.acade.net:http rr -> rserver2.acade.net:http Masq 5 0 0 -> rserver1.acade.net:http Masq 5 0 0

Para que las páginas web que sirve Acade se muestren correctamente al cliente, es

necesario que la base de datos MySQL funcione adecuadamente, de lo contrario las

páginas se mostrarán parcialmente y con errores. El sistema de monitorización basado en

Ldirectord de Acade, es capaz de detectar un mal funcionamiento de la base de datos, ya

que realiza peticiones regulares al demonio httpd de los servidores reales. Entre los datos

obtenidos como respuesta a estas peticiones, el sistema de monitorización espera encontrar

datos que se obtienen tras una consulta a la base de datos MySQL.

ACADE (LVS) - 125

La siguiente prueba, muestra como tras detener el demonio de la MySQL en el servidor

real, el balanceador es reconfigurado automáticamente para que las nuevas peticiones de

conexión ya no se reenvíen a dicho servidor.

Prueba

Se detiene el demonio de la MySQL en el servidor real 2:

root@rserver2:~#mysqladmin -u root –p shutdown

Enter password:

030112 04:38:07 mysqld ended

El balanceador de carga es reconfigurado de manera que ya no envíe nuevas peticiones

hacia el servidor real 2:

root@director1:~# ipvsadm IP Virtual Server version 1.0.6 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP virtualip.acade.net:ftp rr persistent 600 -> rserver2.acade.net:ftp Masq 5 0 0 -> rserver1.acade.net:ftp Masq 5 0 0 TCP virtualip.acade.net:http rr -> rserver1.acade.net:http Masq 5 0 0

Si se vuelve a lanzar la base de datos MySQL (safe_mysql) en el servidor real

rserver2, el balanceador de carga vuelve a reconfigurarse para volverle a reenviar

peticiones. Entre otras cosas, esto permite realizar actualizaciones de software en uno de

los servidores reales sin tener por ello que dejar de prestar los servicios Acade.

9.7.4 Alta disponibilidad del balanceador de carga.

De nada sirve disponer de alta disponibilidad en cuanto a servidores reales, si el

balanceador supone un único punto vital para todo el sistema. Es por ello que Acade

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


del balanceador de carga de reserva (director2), reflejan como se realiza el proceso de

takeover cuando se produce un fallo en el balanceador de carga primario (director1).

ha-log

heartbeat: 2003/01/17_17:33:09 WARN: node director1: is dead

heartbeat: 2003/01/17_17:33:09 info: Link director1:/dev/ttyS0 dead.

heartbeat: 2003/01/17_17:33:09 info: Running /etc/ha.d/rc.d/status status

heartbeat: 2003/01/17_17:33:09 info: Running /etc/ha.d/rc.d/ifstat ifstat

heartbeat: 2003/01/17_17:33:09 info: Taking over resource group IPaddr::192.168.3.150/24

heartbeat: 2003/01/17_17:33:10 info: Acquiring resource group: director1 IPaddr::192.168.3.150/24 ldirectord::configuration

heartbeat: 2003/01/17_17:33:10 info: Running /etc/ha.d/resource.d/IPaddr 192.168.3.150/24 start

heartbeat: 2003/01/17_17:33:10 info: ifconfig eth0:0 192.168.3.150 netmask 255.255.255.0 broadcast 192.168.3.255

heartbeat: 2003/01/17_17:33:11 info: Sending Gratuitous Arp for 192.168.3.150 on eth0:0 [eth0]

heartbeat: 2003/01/17_17:33:11 info: Running /etc/ha.d/resource.d/ldirectord configuration start

heartbeat: 2003/01/17_17:33:14 info: Taking over resource group IPaddr::192.168.10.100/24

heartbeat: 2003/01/17_17:33:15 info: Acquiring resource group: director1 IPaddr::192.168.10.100/24 ipvsyncd

heartbeat: 2003/01/17_17:33:15 info: Running /etc/ha.d/resource.d/IPaddr 192.168.10.100/24 start

heartbeat: 2003/01/17_17:33:16 info: ifconfig eth1:0 192.168.10.100 netmask 255.255.255.0 broadcast 192.168.10.255

heartbeat: 2003/01/17_17:33:16 info: Sending Gratuitous Arp for 192.168.10.100 on eth1:0 [eth1]

heartbeat: 2003/01/17_17:33:16 info: Running /etc/ha.d/resource.d/ipvsyncd start

heartbeat: 2003/01/17_17:33:17 info: mach_down takeover complete.

ha-debug

heartbeat: 2003/01/17_17:33:10 debug: Starting /etc/ha.d/resource.d/IPaddr 192.168.3.150/24 start

heartbeat: 2003/01/17_17:33:11 debug: /etc/ha.d/resource.d/IPaddr 192.168.3.150/24 start done. RC=0

heartbeat: 2003/01/17_17:33:11 debug: Starting /etc/ha.d/resource.d/ldirectord configuration start

heartbeat: 2003/01/17_17:33:14 debug: /etc/ha.d/resource.d/ldirectord configuration start done. RC=0

heartbeat: 2003/01/17_17:33:15 debug: Starting /etc/ha.d/resource.d/IPaddr 192.168.10.100/24 start

heartbeat: 2003/01/17_17:33:16 debug: /etc/ha.d/resource.d/IPaddr 192.168.10.100/24 start done. RC=0

heartbeat: 2003/01/17_17:33:16 debug: Starting /etc/ha.d/resource.d/ipvsyncd start

heartbeat: 2003/01/17_17:33:17 debug: /etc/ha.d/resource.d/ipvsyncd start done. RC=0

ldirectord.log

[Fri Jan 17 17:33:14 2003|configuration] Starting Linux Director Daemon

[Fri Jan 17 17:33:14 2003|configuration] Adding virtual server: 192.168.3.150:80

[Fri Jan 17 17:33:14 2003|configuration] Adding virtual server: 192.168.3.150:21

[Fri Jan 17 17:33:16 2003|configuration] Adding real server: 192.168.10.101:80 (1 x 192.168.3.150:80)




ACADE (LVS) - 127

messages

Jan 17 17:33:09 director2 heartbeat[152]: info: Link director1:/dev/ttyS0 dead.

Jan 17 17:33:09 director2 heartbeat: info: Running /etc/ha.d/rc.d/status status

Jan 17 17:33:09 director2 heartbeat: info: Running /etc/ha.d/rc.d/ifstat ifstat

Jan 17 17:33:09 director2 heartbeat: info: Taking over resource group IPaddr::192.168.3.150/24

Jan 17 17:33:10 director2 heartbeat: info: Acquiring resource group: director1 IPaddr::192.168.3.150/24

ldirectord::configuration

Jan 17 17:33:10 director2 heartbeat: info: Running /etc/ha.d/resource.d/IPaddr 192.168.3.150/24 start

Jan 17 17:33:10 director2 heartbeat: info: ifconfig eth0:0 192.168.3.150 netmask 255.255.255.0 broadcast

192.168.3.255

Jan 17 17:33:11 director2 heartbeat: info: Sending Gratuitous Arp for 192.168.3.150 on eth0:0 [eth0]

Jan 17 17:33:11 director2 heartbeat: info: Running /etc/ha.d/resource.d/ldirectord configuration start

Jan 17 17:33:14 director2 heartbeat: info: Taking over resource group IPaddr::192.168.10.100/24

Jan 17 17:33:15 director2 heartbeat: info: Acquiring resource group: director1 IPaddr::192.168.10.100/24

ipvsyncd

Jan 17 17:33:15 director2 heartbeat: info: Running /etc/ha.d/resource.d/IPaddr 192.168.10.100/24 start

Jan 17 17:33:16 director2 heartbeat: info: ifconfig eth1:0 192.168.10.100 netmask 255.255.255.0 broadcast

192.168.10.255

Jan 17 17:33:16 director2 heartbeat: info: Sending Gratuitous Arp for 192.168.10.100 on eth1:0 [eth1]

Jan 17 17:33:16 director2 heartbeat: info: Running /etc/ha.d/resource.d/ipvsyncd start

Jan 17 17:33:16 director2 kernel: IPVS: stopping sync thread 15332 ...

Jan 17 17:33:16 director2 kernel: IPVS: sync thread stopped!

Jan 17 17:33:16 director2 kernel: IPVS: sync thread started.

Jan 17 17:33:17 director2 heartbeat: info: mach_down takeover complete.

Migrado de conexiones

Los balanceadores de carga del cluster se han configurado de manera que informen en todo

momento al balanceador remoto del estado de su tabla de sesiones (hash table). Al tener

los dos balanceadores el mismo contenido en sus tablas, son mutuamente capaces de

hacerse cargo de las conexiones que pueda tener establecidas el otro balanceador, en caso

de producirse un fallo. Además de constatar, que ambos balanceadores disponen en todo

momento de las mismas entradas en las tablas de sesión, es posible realizar una prueba que

demuestre su correcto funcionamiento en caso de fallida. La prueba puede consistir en

descargarse un archivo vía ftp, que sea lo suficientemente largo como para dar tiempo a

detener el balanceador de carga que tiene esa conexión establecida. Si todo el proceso

descrito anteriormente se ha llevado a cabo convenientemente, la conexión ftp debe migrar


al nuevo balanceador de carga, y por tanto continuándose la descarga del archivo sin

mayores problemas. Lo único que ha de notar el cliente en este proceso, es una pequeña

pausa en la descarga cuando el primer balanceador se viene abajo. Esta prueba ha sido

llevada a cabo con éxito satisfactoriamente.

ACADE (LVS) - 129

10. Conclusiones y valoraciones

Para la consecución de los objetivos iniciales de ACADE, sus autores se han visto en la

necesidad de incrementar sus conocimientos en sistemas operativos así como en la de

ganar soltura en labores de configuración y mantenimiento de servidores. No sólo fue

necesario saber implementar soluciones que resolvieran los objetivos planteados al iniciar

el proyecto, utilizando para ello software libre, sino que también hubo que encontrar algún

método para documentar debidamente el proceso de instalación y documentación. En este

sentido, cabe resaltar la creación del manual ACADE, que recoge el proceso completo de

descarga, instalación y configuración de todo el software usado para implementar el cluster

Acade.

En el campo del Networking, ha sido imprescindible afianzar e incrementar los

conocimientos en redes IP: Asignación de direcciones, direcciones IP virtuales, tablas de

rutado, técnicas como el NAT, ARP spoofing (7.2) o el envío de gratuitous ARP(7.1),

profundizando consecuentemente en el conocimiento de la pila TCP/IP de Linux.

A nivel teórico, se han estudiado técnicas avanzadas de enrutado directo (capa 2) como el

Direct Routing (6.3.2), utilizado en soluciones avanzadas de IBM, para soportar cargas

elevadas de tráfico.

Casi toda la información utilizada para desarrollar ACADE está en inglés. Bien sea

documentación web, manuales, artículos, foros de discusión, etc. En ocasiones, estos textos

tienen además la particularidad de no siempre utilizar un lenguaje demasiado académico o

estándar, sino que más bien son comentarios, a veces en jerga, de desarrolladores y

usuarios experimentados.

En el campo del hardware, ha sido necesario revisar todas las máquinas que componen el

cluster ya que no estaban inicialmente en óptimas condiciones.

Se optó por el trabajo en equipo, actitud muy valorada en cualquier empresa.

130 - Capítulo 10: Conclusiones y valoraciones

Se han conseguido y ampliado gran parte de los objetivos iniciales, aunque queda por

resolver un aspecto muy importante: la escritura remota por parte de los clientes en la base

de datos del cluster, no obstante se han planteado posibles soluciones a éste y otros

problemas.

10.1 Limitaciones y aspectos por desarrollar en Acade

10.1.1 Aspectos por desarrollar: LVS-DR y LVS-Tun

Este proyecto ha priorizado la consecución de una solución de alta disponibilidad

(Heartbeat) que el hecho exprimir al máximo las posibilidades del balanceador de carga,

que por otra parte hubiera requerido de una infraestructura hardaware más compleja. Es

por ello que, aun han quedado por explorar las capacidades de los métodos de reenvío

Direct Routing y las capacidades como balanceador de carga global de LVS.

10.1.2 Limitaciones de este modelo: Bases de Datos

Las aplicaciones transaccionales, en las cuales los clientes del cluster han de poder escribir

en la base de datos, representan actualmente la principal limitación del modelo Acade.

Al igual que el contenido web, las bases de datos que corren independientemente en cada

servidor real, han de mantener su contenido sincronizado. Mientras los clientes del cluster

sean sólo de lectura, el administrador podrá actualizar el contenido de las bases de datos

regularmente y mediante esta sencilla operación (ejecutar un script periódicamente, por

ejemplo), los clientes podrán acceder a aplicaciones web que no requieran realizar una

transacción de información entre el cliente y la base de datos del servidor. Para facilitar las

tareas de sincronización del contenido web, de cada uno de los servidores reales puede

recurrir a sistemas de archivos distribuidos como NFS, GFS CODA, Intermezzo... o bien

utilizar herramientas de sincronización como rsync <http://rsync.samba.org/>.

ACADE (LVS) - 131

Si cada servidor real dispone de su propia base de datos y el cliente realiza una operación

transaccional con el cluster, entonces la información que suba el cliente, irá a parar a un

solo servidor real, por lo cual, las bases de datos de los otros servidores no serán

actualizadas y consecuentemente, los clientes obtendrán una información inconsistente al

acceder al cluster. Esta información, dependerá del servidor real al que se conecten.

El proyecto The Linux Scalable Database (LSD)

<http://sourceforge.net/projects/lsdproject/> está trabajando en un código que permita

escribir en todas las bases de datos de los diferentes servidores reales a través de un agente

intermediario. Lamentablemente, como otros programas utilizados en el cluster, este

código está aun en fase experimental. A nivel funcional, es posible conseguir unos

resultados similares a los que permitirá el LSD project mediante las capacidades de

MySQL Replication.

Para abordar este problema, es posible hacer que todos los servidores reales utilicen la

misma base de datos, pero esta solución tiene dos inconvenientes: por una parte se

balancea el servicio web pero no el acceso a la base de datos, y por otra, se introduce un

único elemento vital para el correcto funcionamiento del sistema, lo cual va en contra de la

filosofía que aborda el problema de la alta disponibilidad mediante el balanceo de carga y

la redundancia de los sistemas.

A fin de solventar este problema, se estudiaron multitud de posibles soluciones basadas en

MySQL replication, descritas en el apartado 9.29.1 del LVS-HOWTO [7], y en la

utilización de sistemas de archivos distribuidos si bien, ninguna de ellas resolvía

completamente el problema. Otra forma de abordar el problema pasaría por utilizar Paralel

Databases como ORACLE Open Parallel Server (OPS) [11].

10.2 Conclusión Final

Una infraestructura como el cluster Acade 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

132 - Capítulo 10: Conclusiones y valoraciones

aplicaciones finales. Por ello, el telemático no puede quedarse sólo en el tratamiento del

tráfico originado, sino que debe entender también el funcionamiento interno de los

sistemas finales que lo generan, si lo que se pretende es resolver los problemas que plantea

poder ofrecer alta disponibilidad y escalabilidad mediante la redundancia de los sistemas

que han de trabajar, aparentemente como uno solo, en una solución cliente/servidor virtual.

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 a

resolver que no se daban en el arquitectura cliente/servidor tradicional.

Por otra parte, el modelo de ingeniería en el cual se cimenta el software libre, que ha

permitido desarrollar todas la aplicaciones necesarias para construir el cluster Acade,

demuestra su viabilidad y madurez para implementar soluciones que respondan a

problemas reales. Como muestra de ello, véase la lista de sitios web que actualmente

utilizan solucione basadas en el balanceador de carga del proyecto LVS (anexo I).

ANEXO I

ANEXO I Listado de sitios web que implementan soluciones basadas en LVS

El siguiente cuadro está extraídos del site de LVS <http://www.linuxvirtualserver.org>, en

el se recoge un listado de diferentes sitios web y proyectos que han sido implementados

con el servidor virtual linux (LVS)

Site Description LVS Notes

linux.com The Linux Portal LVS web cluster

sourceforge.net The largest open source development site

LVS (load balancing HTTP, HTTPS, FTP, SSH, CVS)

themes.org The largest interface/themes site for the X Window System LVS web cluster

wwwcache.ja.net UK National JANET Web Cache Service 40 Squid cache servers in three LVS clusters, ~900GB content shipped/day. for more information

www.zope.org The leading Open Source web application server web cluster, for more information

masks.org Online mask museum A LVS cluster of four Pentium and Pentium II class computers. More information

TuxFamily.org Free hosting for free software like sourceforge and savannah

using LVS/heartbeat (2 load balancers failover and 8 real servers) for all the hosting services

www.care2.com Largest web site community of people who care about the environment

6+ web servers and a single load balancer by Jeremy Brand. more information

valinux.com VA Linux Systems, Inc. LVS web cluster

www.real.com Real Networks, Inc. LVS media cluster (>20 nodes)

www.netwalk.com A full service Internet Access and Presence Provider LVS web hosting cluster

www.greenheck.com Leading manufacturer of air movement and control equipment

LVS web cluster (5 node). Cliff Baeseman provides two pictures (1, 2) of the cluster

map.net An ICP that allows you to explore the Internet in the same way you explore a map

LVS web cluster (6 nodes) by Brian Edmonds

anandtech.com a big hardware review site two primary-backup load balancers and eleven web servers, more information

www.tiscover.com The 3rd largest Portal Site in Austria with more than 500,000 visits per day LVS web cluster

www.cycosmos.com An virtual community website in United Kingdom and Germany LVS web cluster

http://linux.com/

http://sourceforge.net/

http://themes.org/

http://wwwcache.ja.net/

http://www.squid-cache.org/

http://marc.theaimsgroup.com/?l=linux-virtual-server&m=97939428525557&w=2

http://www.zope.org/

http://www.zope.org/About

http://www.masks.org/

http://devel.masks.org/

http://devel.masks.org/

http://tuxfamily.org/

http://sourceforge.net/

http://savannah.gnu.org/

http://www.care2.com/

http://www.care2.com/help/general/vision.html

http://www.care2.com/help/general/vision.html

http://www.jeremybrand.com/Jeremy/Brand/Jeremy_Brand.html

http://www.linuxvirtualserver.org/deployment/care2.com.html

http://www.linuxvirtualserver.org/deployment/care2.com.html

http://valinux.com/

http://www.real.com/

http://www.netwalk.com/

http://www.greenheck.com/

mailto:[email protected]


http://www.linuxvirtualserver.org/deployment/greenheck_1.jpg

http://www.linuxvirtualserver.org/deployment/greenheck_2.jpg

http://map.net/



http://anandtech.com/

http://anandtech.com/showdoc.html?i=1456

http://anandtech.com/showdoc.html?i=1456

http://www.tiscover.com/

http://www.cycosmos.com/

ANEXO I

www.mybiz.com mybiz provides customer service and marketing tools that enable small businesses to build stronger and more profitable customer relationships.

LVS cluster handling just about every public service, mainly web, plus back-end clusters for in-house daemons. managed by tc lewis

Undergraduate Compute Cluster

Undergraduate Students in the Electronics and Computer Science Department at the University of Southampton (England) use it for compilation, and running software remotely

It consists of 3 dual processor real servers and balances telnet and ssh connections. More information

datingfaces.com Online dating site A LVS cluster with 2 directors (VS/DR) and 10 real servers handles about 1.6-2 million hits per day. More information

www.chez.com perso.respublica.fr perso.libertysurf.fr perso.libertysurf.se perso.libertysurf.co.uk perso.skyrock.com perso.worldonline.fr perso.infonie.fr

Tiscali Group's massive web hosting services

4 LVS directors: 1 for chez.com (+ 1 for fail over) and 1 for the 7 other domains (+ 1 for fail over), load balancing ~80+50Mb/s of HTTP and FTP

serve.com Large shared hosting environment LVS web cluster with live fail-over

noguska.com Noguska web site and other web hostings

1 Director, 2 Realserver LVS-NAT cluster. It serves noguska.com and about 7 other domains. More information

yescall.com One of the largest yellowpage site in Korea

1 director/load balancer(single Pentium3 SuseLinux 7.3) and 4+ FreeBSD 4.X web server cover about 12mil. hits/day static HTTP traffic by Direct Routing. Setup by SangSeok Park. (under consideration to increase director and realserver for performance and high-availability)

astro.com Astrodienst Homepage 1 LVS director running in VS/NAT mode with four real servers. Setup by Alois Treindl.

www.songn.com Music potal Site with soribada(famous mp3 p2p in Korea) in Korea

One LVS director running in VS/DR mode with 6+ nodes of Windows 2000 servers, setup by Wonyoung Choi.

www.prideindustries.com PRIDE Industries - Creating jobs for people with disabilities. We host several websites which compliment the services we provide to our customers.

Two Directors running LVS-NAT and Keepalived driving three Realservers. Everything is Linux and we are using FWMARKs for persistence port groupings. Setup by Richard L. Allbery.

http://www.mybiz.com/


https://www.ecs.soton.ac.uk/ug/cluster.shtml

https://www.ecs.soton.ac.uk/ug/cluster.shtml

http://datingfaces.com/

http://www.linuxbofh.com/pictures/sonic/

http://www.chez.com/

http://perso.respublica.fr/

http://perso.libertysurf.fr/

http://perso.libertysurf.se/

http://perso.libertysurf.co.uk/

http://perso.skyrock.com/

http://perso.worldonline.fr/

http://perso.infonie.fr/

http://www.serve.com/

http://www.noguska.com/

http://www.noguska.com/info/nogha.txt

http://www.noguska.com/info/nogha.txt

http://www.yescall.com/


http://www.astro.com/


http://www.songn.com/



http://www.prideindustries.com/


ANEXO II

ANEXO II Anexo 2 Manual de ipvsadm

IPVSADM(8) Linux Administrator's Guide IPVSADM(8) NAME ipvsadm - Linux Virtual Server administration SYNOPSIS ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask] ipvsadm -D -t|u|f service-address ipvsadm -C ipvsadm -R ipvsadm -S [-n] ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] ipvsadm -d -t|u|f service-address -r server-address ipvsadm -L|l [options] ipvsadm -Z [-t|u|f service-address] ipvsadm --set tcp tcpfin udp ipvsadm --start-daemon state [--mcast-interface interface] ipvsadm --stop-daemon ipvsadm -h DESCRIPTION Ipvsadm(8) is used to set up, maintain or inspect the virtual server table in the Linux kernel. The Linux Virtual Server can be used to build scalable network services based on a cluster of two or more nodes. The active node of the cluster redirects service requests to a collection of server hosts that will actually perform the services. Supported features include two protocols (TCP and UDP), three packet-forwarding methods (NAT, tunneling, and direct routing), and eight load balancing algorithms (round robin, weighted round robin, least-connection, weighted least-connection, locality-based least-connection, locality-based least-connection with replication, destination-hashing, and source-hashing). The command has two basic formats for execution: ipvsadm COMMAND [protocol] service-address [scheduling-method] [persistence options] ipvsadm command [protocol] service-address server-address [packet-forwarding-method] [weight options] The first format manipulates a virtual service and the algorithm for assigning service requests to real servers. Optionally, a persistent timeout and network mask for the granularity of a persistent service may be specified. The second format manipulates a real server that is associated with an existing virtual service. When specifying a real server, the packet-forwarding method and the weight of the real server, relative to other real servers for the vir-

ANEXO II

tual service, may be specified, otherwise defaults will be used. COMMANDS ipvsadm(8) recognises the commands described below. Upper- case commands maintain virtual services. Lower-case commands maintain real servers that are associated with a virtual service. -A, --add-service Add a virtual service. A service address is uniquely defined by a triplet: IP address, port number, and protocol. Alternatively, a virtual service may be defined by a firewall-mark. -E, --edit-service Edit a virtual service. -D, --delete-service Delete a virtual service, along with any associated real servers. -C, --clear Clear the virtual server table. -R, --restore Restore Linux Virtual Server rules from stdin. Each line read from stdin will be treated as the command line options to a separate invocation of ipvsadm. Lines read from stdin can optionally begin with "ipvsadm". This option is useful to avoid execut- ing a large number or ipvsadm commands when con- structing an extensive routing table. lines 47-90/485 19% -S, --save Dump the Linux Virtual Server rules to stdout in a format that can be read by -R|--restore. -a, --add-server Add a real server to a virtual service. -e, --edit-server Edit a real server in a virtual service. -d, --delete-server Remove a real server from a virtual service. -L, -l, --list List the virtual server table if no argument is specified. If a service-address is selected, list this service only. If the -c option is selected, then display the connection table. The exact output is affected by the other arguments given. -Z, --zero Zero the packet, byte and rate counters in a service or all services. --set tcp tcpfin udp

ANEXO II

Change the timeout values used for IPVS connections. This command always takes 3 parameters, representing the timeout values (in seconds) for TCP sessions, TCP sessions after receiving a FIN packet, and UDP packets, respectively. A timeout value 0 means that the current timeout value of the corresponding entry is preserved. --start-daemon state Start the connection synchronization daemon. The state is to indicate that the daemon is started as master or backup. The connection synchronization daemon is implemented inside the Linux kernel. The master daemon running at the primary load balancer multicasts changes of connections periodically, and the backup daemon running at the backup load balancers receives multicast message and creates corresponding connections. Then, in case the primary load balancer fails, a backup load balancer will takeover, and it has state of almost all connections, so that almost all established connections can continue to access the service. --stop-daemon Stop the connection synchronization daemon. -h, --help Display a description of the command syntax. PARAMETERS The commands above accept or require zero or more of the following parameters. -t, --tcp-service service-address Use TCP service. The service-address is of the form host[:port]. Host may be one of a plain IP address or a hostname. Port may be either a plain port number or the service name of port. The Port may be omitted, in which case zero will be used. A Port of zero is only valid if the service is persistent as the -p|--persistent option, in which case it is a wild-card port, that is connections will be accepted to any port. -u, --udp-service service-address Use UDP service. See the -t|--tcp-service for the description of the service-address. -f, --fwmark-service integer Use a firewall-mark, an integer value greater than zero, to denote a virtual service instead of an address, port and protocol (UDP or TCP). The mark- ing of packets with a firewall-mark is configured using the -m|--mark option to iptables(8). It can be used to build a virtual service assoicated with the same real servers, covering multiple IP addresss, port and protocol tripplets. Using firewall-mark virtual services provides a convenient method of grouping together different IP

ANEXO II

addresses, ports and protocols into a single virtual service. This is useful for both simplifying configuration if a large number of virtual services are required and grouping persistence across what would otherwise be multiple virtual services. -s, --scheduler scheduling-method scheduling-method Algorithm for allocating TCP connections and UDP datagrams to real servers. Scheduling algorithms are implemented as kernel modules. Six are shipped with the Linux Virtual Server: rr - Robin Robin: distribute jobs equally amongst the available real servers. wrr - Weighted Round Robin: assign jobs to real servers proportionally to there real servers' weight. Servers with higher weights receive new jobs first and get more jobs than servers with lower weights. Servers with equal weights get an equal distribution of new jobs. lc - Least-Connection: assign more jobs to real servers with fewer active jobs. wlc - Weighted Least-Connection: assign more jobs to servers with fewer jobs and relative to the real servers' weight. This is the default. lblc - Locality-Based Least-Connection: assign jobs destined for the same IP address to the same server if the server is not overloaded and available; otherwise assign jobs to servers with fewer jobs, and keep it for future assignment. lblcr - Locality-Based Least-Connection with Repli- cation: assign jobs destined for the same IP address to the least-connection node in the server set for the IP address. If all the node in the server set are over loaded, it picks up a node with fewer jobs in the cluster and adds it in the sever set for the target. If the server set has not been modified for the specified time, the most loaded node is removed from the server set, in order to avoid high degree of replication. dh - Destination Hashing: assign jobs to servers through looking up a statically assigned hash table by their destination IP addresses. sh - Source Hashing: assign jobs to servers through looking up a statically assigned hash table by their source IP addresses. -p, --persistent [timeout] Specify that a virtual service is persistent. If this option is specified, multiple requests from a client are redirected to the same real server selected for the first request. Optionally, the

ANEXO II

timeout of persistent sessions may be specified given in seconds, otherwise the default of 300 seconds will be used. This option may be used in conjunction with protocols such as SSL or FTP where it is important that clients consistently connect with the same real server. Note: If a virtual service is to handle FTP connections then persistence must be set for the virtual service if Direct Routing or Tunnelling is used as the forwarding mechanism. If Masquerading is used in conjunction with an FTP service than persistence is not necessary, but the ip_vs_ftp kernel module must be used. This module may be manually inserted into the kernel using insmod(8). -M, --netmask netmask Specify the granularity with which clients are grouped for persistent virtual services. The source address of the request is masked with this netmask to direct all clients from a network to the same real server. The default is 255.255.255.255, that is, the persistence granularity is per client host. Less specific netmasks may be used to resolve problems with non-persistent cache clusters on the client side. -r, --real-server server-address Real server that an associated request for service may be assigned to. The server-address is the host address of a real server, and may plus port. Host can be either a plain IP address or a hostname. Port can be either a plain port number or the service name of port. In the case of the masquerading method, the host address is usually an RFC 1918 private IP address, and the port can be different from that of the associated service. With the tunneling and direct routing methods, port must be equal to that of the service address. For normal services, the port specified in the service address will be used if port is not specified. For fwmark services, port may be ommitted, in which case the destination port on the real server will be the destination port of the request sent to the virtual service. [packet-forwarding-method] -g, --gatewaying Use gatewaying (direct routing). This is the default. -i, --ipip Use ipip encapsulation (tunneling). -m, --masquerading Use masquerading (network access translation, or NAT). Note: Regardless of the packet-forwarding mechanism specified, real servers for addresses for which there are interfaces on the local node will be use the local forwarding method, then packets

ANEXO II

for the servers will be passed to upper layer on the local node. This cannot be specified by ipvsadm, rather it set by the kernel as real servers are added or modified. -w, --weight weight Weight is an integer specifying the capacity of a server relative to the others in the pool. The valid values of weight are 0 through to 65535. The default is 1. Quiescent servers are specified with a weight of zero. A quiescent server will receive no new jobs but still serve the existing jobs, for all scheduling algorithms distributed with the Linux Virtual Server. Setting a quiescent server may be useful if the server is overloaded or needs to be taken out of service for maintenance. --mcast-interface interface Specify the multicast interface that the sync master daemon sends outgoing multicasts through, or the sync backup daemon listens to for multicasts. -c, --connection Connection output. The list command with this option will list current IPVS connections. --timeout Timeout output. The list command with this option will display the timeout values (in seconds) for TCP sessions, TCP sessions after receiving a FIN packet, and UDP packets. --daemon Daemon information output. The list command with this option will display the daemon status and its multicast interface. --stats Output of statistics information. The statistics information of services and its servers will be displayed, when the services are listed. --rate Output of rate information. The rate information (such as connections/second, bytes/second and packets/second) of services and its servers will be displayed, when the services are listed. -n, --numeric Numeric output. IP addresses and port numbers will be printed in numeric format rather than as as host names and services respectively, which is the default. EXAMPLE 1 - Simple Virtual Service The following commands configure a Linux Director to distribute incoming requests addressed to port 80 on 207.175.44.110 equally to port 80 on five real servers. The forwarding method used in this example is NAT, with each of the real servers being masqueraded by the Linux lines 311-354/485 73%

ANEXO II

Director. ipvsadm -A -t 207.175.44.110:80 -s rr ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.1:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.2:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.3:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.4:80 -m ipvsadm -a -t 207.175.44.110:80 -r 192.168.10.5:80 -m Alternatively, this could be achieved in a single ipvsadm command. echo " -A -t 207.175.44.110:80 -s rr -a -t 207.175.44.110:80 -r 192.168.10.1:80 -m -a -t 207.175.44.110:80 -r 192.168.10.2:80 -m -a -t 207.175.44.110:80 -r 192.168.10.3:80 -m -a -t 207.175.44.110:80 -r 192.168.10.4:80 -m -a -t 207.175.44.110:80 -r 192.168.10.5:80 -m " | ipvsadm -R As masquerading is used as the forwarding mechanism in this example, the default route of the real servers must be set to the linux director, which will need to be configured to forward and masquerade packets. This can be achieved using the following commands: echo "1" > /proc/sys/net/ipv4/ip_forward EXAMPLE 2 - Firewall-Mark Virtual Service The following commands configure a Linux Director to distribute incoming requests addressed to any port on 207.175.44.110 or 207.175.44.111 equally to the corresponding port on five real servers. As per the previous example, the forwarding method used in this example is NAT, with each of the real servers being masqueraded by the Linux Director. ipvsadm -A -f 1 -s rr ipvsadm -a -f 1 -r 192.168.10.1:0 -m ipvsadm -a -f 1 -r 192.168.10.2:0 -m ipvsadm -a -f 1 -r 192.168.10.3:0 -m ipvsadm -a -f 1 -r 192.168.10.4:0 -m ipvsadm -a -f 1 -r 192.168.10.5:0 -m As masquerading is used as the forwarding mechanism in this example, the default route of the real servers must be set to the linux director, which will need to be configured to forward and masquerade packets. The real server should also be configured to mark incoming packets addressed to any port on 207.175.44.110 and 207.175.44.111 with firewall-mark 1. If FTP traffic is to be handled by this virtual service, then the ip_vs_ftp kernel module needs to be inserted into the kernel. These operations can be achieved using the following commands: echo "1" > /proc/sys/net/ipv4/ip_forward modprobe ip_tables iptables -A PREROUTING -t mangle -d 207.175.44.110/31 -j MARK --set-mark 1

ANEXO II

modprobe ip_vs_ftp NOTES The Linux Virtual Server implements three defense strategies against some types of denial of service (DoS) attacks. The Linux Director creates an entry for each connection in order to keep its state, and each entry occu- pies 128 bytes effective memory. LVS's vulnerability to a DoS attack lies in the potential to increase the number entries as much as possible until the linux director runs out of memory. The three defense strategies against the attack are: Randomly drop some entries in the table. Drop 1/rate packets before forwarding them. And use secure tcp state transition table and short timeouts. The strategies are controlled by sysctl variables and corresponding entries in the /proc filesystem: /proc/sys/net/ipv4/vs/drop_entry /proc/sys/net/ipv4/vs/drop_packet /proc/sys/net/ipv4/vs/secure_tcp Valid values for each variable are 0 through to 3. The default value is 0, which disables the respective defense strategy. 1 and 2 are automatic modes - when there is no enough available memory, the respective strategy will be enabled and the variable is automatically set to 2, otherwise the strategy is disabled and the variable is set to 1. A value of 3 denotes that the respective strategy is always enabled. The available memory threshold and secure enabled and the variable is automatically set to 2, otherwise the strategy is disabled and the variable is set to 1. A value of 3 denotes that the respective strategy is always enabled. The available memory threshold and secure TCP timeouts can be tuned using the sysctl variables and corresponding entries in the /proc filesystem: /proc/sys/net/ipv4/vs/amemthresh /proc/sys/net/ipv4/vs/timeout_* FILES /proc/net/ip_vs /proc/net/ip_vs_app /proc/net/ip_vs_conn /proc/net/ip_vs_stats /proc/sys/net/ipv4/vs/am_droprate /proc/sys/net/ipv4/vs/amemthresh /proc/sys/net/ipv4/vs/drop_entry /proc/sys/net/ipv4/vs/drop_packet /proc/sys/net/ipv4/vs/secure_tcp /proc/sys/net/ipv4/vs/timeout_close /proc/sys/net/ipv4/vs/timeout_closewait /proc/sys/net/ipv4/vs/timeout_established /proc/sys/net/ipv4/vs/timeout_finwait /proc/sys/net/ipv4/vs/timeout_icmp /proc/sys/net/ipv4/vs/timeout_lastack /proc/sys/net/ipv4/vs/timeout_listen /proc/sys/net/ipv4/vs/timeout_synack /proc/sys/net/ipv4/vs/timeout_synrecv /proc/sys/net/ipv4/vs/timeout_synsent /proc/sys/net/ipv4/vs/timeout_timewait

ANEXO II

/proc/sys/net/ipv4/vs/timeout_udp SEE ALSO iptables(8), insmod(8), modprobe(8) AUTHORS ipvsadm - Wensong Zhang <[email protected]> Peter Kese <[email protected]> man page - Mike Wangsmo <[email protected]> Wensong Zhang <[email protected]> Horms <[email protected]> LVS Administration 11th April 2002 IPVSADM(8)

ANEXO II

ANEXO III

ANEXO III Archivos y scripts de configuración principales de los LVS del cluster Acade

Este anexo recoge los archivos de configuración de los programas más importantes del

cluster Acade.

Linux Director Daemon (ldirectord)

/etc/ha.d/conf/configuration # Archivo de configuracion del ldirectord arrancado por heartbeat # checktimeout = 6 checkinterval = 2 virtual = 192.168.3.150:80 real = 192.168.10.101:80 masq 5 real = 192.168.10.102:80 masq 5 service = http scheduler = rr checktype = negotiate request = "ficha_evento.php?id_evento=00000001" receive = "Joan Carles" virtual = 192.168.3.150:21 real = 192.168.10.101:21 masq 5 real = 192.168.10.102:21 masq 5 service = ftp scheduler = rr login = "anonymous" passwd = "[email protected]" persistent = 600 protocol=tcp

Heartbeat

/etc/ha.d/haresources

director1 IPaddr::192.168.3.150/24 ldirectord::configuration

director1 IPaddr::192.168.10.100/24 ipvsyncd

ANEXO III

/etc/ha.d/ha.cf debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 5 serial /dev/ttyS0 baud 9600 node director1 node director2

/etc/ha.d/authkeys

auth 2 2 crc Script IPVSyncd

#!/bin/sh # # Controlador del estado del demonio de sincronización de conexiones # # ACADE (LVS) # case "$1" in 'start') /sbin/ipvsadm --stop-daemon /sbin/ipvsadm --start-daemon master;; 'stop') /sbin/ipvsadm --stop-daemon /sbin/ipvsadm --start-daemon backup;; *) echo "Se debe de usar: $0 start|stop" ;; esac Archivo de inicialización del sistema

/etc/rc.d/rc.local

#!/bin/sh # # /etc/rc.d/rc.local: Local system initialization script.

ANEXO III

# # Put any local setup commands in here: tail -f /var/log/messages >/dev/tty12 & tail -f /var/log/ha-log > /dev/tty8 & tail -f /var/log/ha-debug > /dev/tty9 & tail -f /var/log/ldirectord.log > /dev/tty10 & /sbin/ifconfig eth0 192.168.3.155 /sbin/ifconfig eth1 192.168.10.1 /sbin/ifconfig lo 127.0.0.1 /sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo #/sbin/route add 192.168.3.150 eth0 /sbin/route add default gw 192.168.3.1 eth0 /sbin/ipvsadm --start-daemon backup # cargamos el modulo para poder hacer ls en ftp con LVS NAT /sbin/modprobe ip_vs_ftp /etc/init.d/heartbeat start

ANEXO III

ANEXO IV

ANEXO IV Esquema y código SQL de la base de datos documentacion

El código que define las tablas de la base de datos documentacion utilizada para el sitio

web es el siguiente.

-- MySQL dump 8.22 -- -- Host: localhost Database: documentacion --------------------------------------------------------- -- Server version 3.23.51 -- -- Table structure for table 'admin' -- CREATE TABLE admin ( id_admin tinyint(8) unsigned zerofill NOT NULL auto_increment, login char(8) NOT NULL default '', password char(16) NOT NULL default '', PRIMARY KEY (id_admin) ) TYPE=MyISAM; -- -- Table structure for table 'album' -- CREATE TABLE album ( id_evento tinyint(8) unsigned zerofill NOT NULL default '00000000', id_foto tinyint(8) unsigned zerofill NOT NULL auto_increment, fichero char(128) default NULL, alto char(4) default NULL, ancho char(4) default NULL, PRIMARY KEY (id_evento,id_foto), KEY id_ (id_evento,id_foto) ) TYPE=MyISAM; -- -- Table structure for table 'autores' -- CREATE TABLE autores ( id_doc tinyint(8) unsigned zerofill NOT NULL default '00000000', id_colaborador tinyint(8) unsigned zerofill NOT NULL default '00000000', PRIMARY KEY (id_doc,id_colaborador), KEY id_doc (id_doc,id_colaborador) ) TYPE=MyISAM; -- -- Table structure for table 'bibliografia' -- CREATE TABLE bibliografia (

ANEXO IV

id_doc tinyint(8) unsigned zerofill NOT NULL default '00000000', id_evento tinyint(8) unsigned zerofill NOT NULL default '00000000', PRIMARY KEY (id_doc,id_evento), KEY id_doc (id_doc,id_evento) ) TYPE=MyISAM; -- -- Table structure for table 'colaboradores' -- CREATE TABLE colaboradores ( id_colaborador tinyint(8) unsigned zerofill NOT NULL auto_increment, nombre char(40) NOT NULL default '', datos char(100) NOT NULL default '', PRIMARY KEY (id_colaborador) ) TYPE=MyISAM; -- -- Table structure for table 'docs' -- CREATE TABLE docs ( id_doc tinyint(8) unsigned zerofill NOT NULL auto_increment, titulo varchar(128) default NULL, tema varchar(30) default NULL, nivel varchar(8) default NULL, descripcion text, fecha date default NULL, archivo_txt varchar(128) NOT NULL default 'txt-no-disponible', archivo_html varchar(128) NOT NULL default 'html-no-disponible', archivo_pdf varchar(128) NOT NULL default 'pdf-no-disponible', archivo_tar_gz varchar(128) NOT NULL default 'tar_gz-no-disponible', link_a_archivo varchar(255) NOT NULL default 'NO', PRIMARY KEY (id_doc) ) TYPE=MyISAM; -- -- Table structure for table 'eventos' -- CREATE TABLE eventos ( id_evento tinyint(8) unsigned zerofill NOT NULL auto_increment, tipo varchar(35) NOT NULL default '', titulo varchar(128) NOT NULL default '', fecha datetime NOT NULL default '0000-00-00 00:00:00', descripcion text, cronica varchar(255) default NULL, localizacion varchar(75) default 'EUPMT', PRIMARY KEY (id_evento), KEY id_charla (id_evento) ) TYPE=MyISAM; -- -- Table structure for table 'ponentes' -- CREATE TABLE ponentes ( id_evento tinyint(8) unsigned zerofill NOT NULL default '00000000',

ANEXO IV

id_colaborador tinyint(8) unsigned zerofill NOT NULL default '00000000', PRIMARY KEY (id_evento,id_colaborador), KEY id_charla (id_evento,id_colaborador) ) TYPE=MyISAM; -- -- Table structure for table 'temas_doc' -- CREATE TABLE temas_doc ( id_tema tinyint(8) unsigned zerofill NOT NULL default '00000000', tema char(25) NOT NULL default '', PRIMARY KEY (id_tema), KEY id_evento (id_tema) ) TYPE=MyISAM; -- -- Table structure for table 'tipo_evento' -- CREATE TABLE tipo_evento ( id_tipo tinyint(8) unsigned zerofill NOT NULL default '00000000', tipo char(35) NOT NULL default '', PRIMARY KEY (id_tipo), KEY id_evento (id_tipo) ) TYPE=MyISAM;

ANEXO IV

docs

PK

id_d

oc

titul

ote

ma

nive

lde

scrip

cion

fech

aar

chiv

o_tx

tar

chiv

o_ht

ml

arch

ivo_

pdf

arch

ivo_

tar_

gzlin

k_a_

arch

ivo

even

tos

PK

id_e

vent

o

tipo

titul

ofe

cha

desc

ripci

óncr

ónic

alo

caliz

acio

n

cola

bora

dore

s

PK

id_c

olab

orad

or

nom

bre

dato

s

albu

m

PK

id_e

vent

oP

Kid

_fot

o

id_a

lbum

fiche

roal

toan

cho

adm

in

PK

id_a

dmin

logi

npa

ssw

ord

id_t

ema

tem

ate

mas

_doc

id_t

ipo

tipo

tipo_

eve

nto

auto

res

id_d

ocid

_col

abor

ador

bibl

iogr

afia

id_d

ocid

_eve

nto

pone

ntes

id_e

vent

oid

_col

abor

ado

r

Bas

e de

Dat

os D

ocum

enta

ción

(Sec

ción

de

Doc

umen

taci

ón y

Eve

ntos

de

la A

SS

L)

ANEXO V

Anexo V Manual Acade (LVS) Este manual recoge los pasos a seguir para la instalación y configuración del cluster Acade, empezando por el sistema operativo, continuando con el software del balanceador y finalizando por el software de los servidores. El contenido del manual está basado en documentos de trabajo propios (trabajo de campo). Arquitectura a montar


O N - LIN E


O N - LIN E

eth0:0 VIP: 192.168.3.150eth0 IP: 192.168.3.155eth0 MAC: 00:20:18:28:04:e9

eth0:0 VIP: 192.168.3.150eth0 IP: 192.168.3.156eth0 MAC: 00:20:18:29:3e:d1

eth1:0 VIP: 192.168.10.100eth1 IP: 192.168.10.2eth1 MAC: 00:e0:29:25:4e:aa

eth1:0 VIP: 192.168.10.100eth1 IP: 192.168.10.1eth1 MAC: 00:e0:29:25:4d:4c

eth0 IP: 192.168.10.102eth0 MAC: 00:e0:29:25:46:57

eth0 IP: 192.168.10.101eth0 MAC: 00:e0:29:25:4e:9a

eth0 IP: 192.168.3.157eth0 MAC: 00:e0:98:33:6a:b8

eth0 IP: 192.168.3.158eth0 MAC: 00:06:5B:31:4B:74

director2director1

rserver1 rserver2

client1 client2

Topología Física del Cluster Acade

Sistema Operativo

protopkg Compilar y parchear el kernel (con código ipvs)

Software del Balanceador

heartbeat ldirectord ipvsadmin

Software de los Servidores Reales

apache php mysql

ANEXO V

protopkg

Descripción Cómo crear un paquete para Slackware con protopkg 2.0 ¿Qué es un paquete y que aporta? La característica principal de los sistemas operativos OpenSource es la de que cualquiera puede tener acceso total al código fuente tanto de los programas que componen el sistema operativo como al de las aplicaciones que corren sobre él. El problema se presenta a medida que se van instalando nuevas aplicaciones al sistema, ya que va creciendo el numero de archivos que se van guardando en multitud de directorios así como el número de nuevos directorios que se van creando. El código fuente no acostumbra a ir solo, es decir, junto a él se adjunta toda la documentación necesaria tanto para su instalación, manejo como funcionamiento. También se adjunta un changelog, que es un fichero que contiene las diferencias del programa respecto a versiones anteriores. Generalmente se muestran las cuentas de e-mail de contacto con sus creadores, e incluso puede que también se adjunte información para su desarrollo. Generalmente todos los programas añaden su página al manual del sistema. Si se encapsula toda este conjunto de archivos en un paquete se obtienen algunas ventajas, la principal de ellas es la compacticidad y la de que se ha creado un paquete siguiendo el formato por defecto de la distribución, con lo que las facilidades para el mantenimiento del paquete instalado estarán garantizadas. El sistema tiene una lista con todo el software que se ha instalado usando el sistema de paquetes, por lo que es resulta muy fácil conocer todo el software instalado así como desinstalarlo “limpiamente”, ya que en la desinstalación se borran todos y sólo los archivos del programa que se instaló. Procedimiento - Primero se crea en /var/spool/prototypes un directorio para cada paquete que se quiera instalar, con el nombre genérico del programa a instalar facilitando así su identificación. Éste directorio contiene el tarball .tar.gz del paquete a crear. - Dentro del nuevo directorio creado, se edita un nuevo archivo llamado prototype, que no es más que un shellscript que le indica a protopkg los pasos que ha de realizar para generar el paquete. Algunas de las directivas importantes del archivo prototype son: VERSION [Aquí se especifica la versión del programa que se va a instalar.] BUILD [Indica el número de veces que se ha ejecutado el script para generar el paquete] ARCH [Indica la arquitectura del microprocesador. /bin/arch para indicarle

automáticamente la arquitectura para la que el kernel fue compilado.] PROGNAME [nombre del programa] - Finalmente, con todas estas variables se genera automáticamente el nombre del paquete de la siguiente manera: PKGNAME="$PROGNAME-$VERSION-$ARCH-$BUILD"

ANEXO V

DESC [Es la descripción de lo que hace el paquete. Éste mensaje aparecerá en pantalla al utilizar el "installpkg".

IGNOREPATH [En esta variable iremos añadiendo los PATHS en dónde NO hay que mirar los

cambios que no se incluirán en la orden 'find' como pueden ser /dev, /proc....] MANTAINER [Los nombres y e-milios de los que mantienen el paquete.] SOURCE [Especifica el sitio web de dónde se baja el paquete.] Una vez crado el paquete .tgz se mueve a /var/spool/packages

Compliar y parchear el kernel Descripción Proceso a seguir para compilar un kernel de Linux genuino bajo una distribución Slackware. Descarga Una versión genuina y actualizada del kernel se puede obtener en: ftp.kernel.org www.kernel.org Se descarga el package que más interese se guarda en /usr/src por ejemplo: kernel-2.4.19.tar.gz para descomprimirlo: #tar -zxvf kernel-2.4.19.tar.gz Procedimiento Se crea el link simbólico linux que apunta al nuevo directorio generado en donde se guardarán las fuentes del kernel: #ln -s kernel-2.4.19 linux Dentro del directorio se ejecuta: #cd /usr/src/linux #make menuconfig Una vez seleccionadas las opciones de los diferentes menús, se guarda la configuración con un nombre alternativo: config.director y antes de salir se guardan los cambios hechos en el fichero por defecto. #make dep #make clean #make bzImage #make modules #make modules_install Una forma más compacta de hacer lo mismo es:

ANEXO V

#make dep && make clean && make bzImage && make modules && make modules_install Si el proceso finaliza con éxito, se nos habrá generado una imagen del nuevo kernel en: /usr/src/linux/arch/i386/boot/bzImage Ahora se copia o se mueve la imagen al directorio que por convenio se utiliza para albergar las imágenes del kernel y se le cambia el nombre: #cp bzImage /boot/vmlinuz-director-2.4.19 Después se crea un link simbólico a la nueva imagen para no tener que modificar el lilo: #ln -s vmlinuz-director-4.4.19 vmlinuz Y se compila el lilo nuevamente con: #lilo

heartbeat Descripción Explicación del proceso de instalación y configuración de heartbeat. También se explica el proceso seguido para generar el paquete .tgz para slackware a partir del fichero tarball .tar.gz utilizando para ello protopkg. Introducción Descripción y funcionamiento: Heartbeat es el subsistema que dota de alta disponibilidad a Linux. En ocasiones, tenemos la necesidad de ofrecer un servicio de red ininterrumpidamente y deseamos que esté disponible aun en el caso de que el hardware que soporta dicho servicio no esté funcionando. En otras ocasiones, podemos tener la necesidad de realizar cambios en la máquina que está ofreciendo un servicio sin querer cortarlo. Por ejemplo, para actualizaciones de software, parcheos de seguridad para hacer frente a nuevas vulnerabilidades, cambios en el hardware, etc. Una posible solución para hacer frente a estos requisitos es la de utilizar dos máquinas ofreciendo el mismo servicio, si bien sólo una de las dos máquinas lo ofrece mientras la otra está encendida por si tuviera que suplantar a la primera. En Linux, disponemos de una aplicación llamada 'heartbeat', la cual nos permite realizar estas funciones. Heartbeat funciona de la siguiente manera: Cada una de las máquinas ejecuta el programa heartbeat, el cual escucha y envía 'latidos' a su proceso homónimo en la otra máquina. De esta manera, el programa heartbeat que también se encuentra en la máquina suplente sabe que debe de entrar en acción, levantando los servicios, cuando la máquina principal deja de enviar sus latidos. La ausencia de latidos indica la no disponibilidad del servicio para el cual heartbeat fue configurado. Cuando la maquina principal vuelve a estar en condiciones de volver a lanzar los servicios de red, la maquina secundaria se da cuenta de ello. Entonces detiene los servicios de red que estaba ofreciendo e informa a la maquina principal de que puede relanzar sus servicios. La maquina secundaria vuelve a quedar a la espera de ser requerida nuevamente.

ANEXO V

Heartbeat esta diseñado para ejecutar una serie de scripts cuando es inicializado y otra serie de scripts cuando es detenido. - Obteniendo el tarball y creando el paquete Protopkg es una herramienta creada por David Cantrell utilizada para automatizar el proceso de creación de paquetes para slackware. Esta aplicación utiliza un archivo de configuración llamado prototype que no es mas que un shell-scrpt que se ejecuta secuencialmente y contiene las ordenes necesarias para compilar el source y generar la lista de ficheros instalados en el sistema. Esta lista es importante para posteriormente borrar, actualizar el paquete instalado. De hecho, esta es la esencia y el porque de un sistema de paquetes. Creamos el directorio /var/spool/prototypes. Este directorio será el que contenga los archivos prototype que nos permitan generar cada uno de los paquetes q vayamos necesitando. Asi creamos el directorio /var/spool/prototypes/heartbeat y descargaremos aquí el tarball de hertbeat wget -c www.linux-ha.org/download/heartbeat-0.4.9.tar.gz Antes de proceder con la creación del paquete, hemos de cumplir los siguientes requisitos para la correcta creación del mismo. -Tener instalados en nuestra maquina: lynx, ucd-snmp NOTA: Nos podemos bajar el paquete ucd-snmp compilado para slackware desde el ftp de la assl ftp://ftp.assl.cx -Es posible que aparezca algún problema con el grupo pop, si esto es así para poder compilar con éxito será necesario eliminar este grupo o bien cambiar su GID ya que este es requerido en el proceso de creación del paquete. Antes de eliminarlo es muy recomendable comprobar con un find que el grupo pop no esta siendo utilizado por ninguna aplicación. #find / -group pop 2>/dev/null #find / -user pop 2>/dev/null Si estas dos búsquedas no obtienen un resultado, nos podemos cargar o renombrar en ID de estos usuarios o grupos, actualizando convenientemente el fichero /etc/passwd con un #vipw. otra forma patillera de hacerlo es editar a mano el /etc/groups y el /etc/passwd y rebotar la maquina... mmm seguro q existe una manera mas académica de hacer esto. (nota: 2>/dev/null es para evitar mensajes de error "tontos" mientras hacemos el find) Ahoa, deberemos crear el fichero /var/spool/prototypes/heartbeat/prototype # heartbeat prototype VERSION=0.4.9.2 BUILD=2 ARCH=`/bin/arch` PROGNAME="heartbeat" PKGNAME="$PROGNAME-$VERSION-$ARCH-$BUILD" DESC="\ Heartbeat es un componente de la solucion \ Linux Virtual Server (LVS).Éste permite el \ chequeo periodico de los nodos que componen \ la arquitectura LVS. \"

ANEXO V

IGNOREPATH="/dev:/proc:/home:/root:/var:/tmp:/export:/mnt:/floppy:/cdrom" STRIPBIN=n STRIPLIB=n SETATTR=y MAINTAINER="Marcos Martínez <[email protected]> Gabriel Bergés <gabb@me nta.net>" SOURCE="www.linux-ha.org/download/$PROGNAME/$VERSION/$PROGNAME-$VERSION-source.t ar.gz" LOCATION="http://www.linux-ha.org" compile() { tar zxvfp $CWD/$PROGNAME-$VERSION.tar.gz cd $PROGNAME-$VERSION } install() { mkdir -p /usr/doc/$PROGNAME-$VERSION cp -R doc/ /usr/doc/$PROGNAME-$VERSION make install } attributes() { echo "No attributes..." } special() { echo "No special..." } subpacks() { echo "No subpacks..." } para generar el paquete basta ya solo picar el siguiente comando: #protopkg -vcd NOTA: Si lo tenemos, nos podemos bajar el paquete del programa protopkg compilado para slackware desde el ftp de la assl ftp://ftp.asslath.cx - Configuración de hertbeat Antes de nada deberemos disponer de un cable serie null-modem para interconectar los dos dierctors por el puerto serie RS-232. Para comprobar el correcto funcionamiento de ambos puertos serie basta con picar estos comandos: en un director : # cat < /dev/ttyS0 y en el otro:

ANEXO V

# echo Hola > /dev/ttyS0 Si el echo que enviamos desde una maquina aparece en el otro nuestros puertos serie funcionan correctamente. Configuración Para poder iniciar heartbeat correctamente, será necesario editar 3 archivos que son: /etc/ha.d/ha.cf debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 5 serial /dev/ttyS0 baud 9600 node director1 node director2 /etc/ha.d/haresources director1 IPaddr::192.168.3.150/24 ldirectord::configuration director1 IPaddr::192.168.10.100/24 ipvsyncd (esta linea solo si tenemos dicho script ver anexo III) /etc/ha.d/authkeys auth 2 2 crc Directorios /etc/ha.d -> ha.cf (configuración de heartbeat) -> haresources -> authkeys /etc/init.d heartbeat (explicar como se tira y eso start|stop|status...) /etc/ha.d/resource.d (contiene scripts necesarios para el funcionamiento de heartbeat y es en donde buscara los scripts de inicio no estándares (httpd, seria estándar)) /etc/rc.d/rc.local (archivo desde el que se lanza heartbeat al arrancar si la distribución Linux no tiene el sistema de arranque de System V. - Factores a tener en cuenta 1) Cómo heartbeat selecciona la interface de red: Cómo se ha explicado con anterioridad, el archivo /etc/ha.d/haresources especifica en primer lugar cual de las dos m quinas es la principal (las dos maquinas deben de tener este archivo idéntico ya que han de saber en todo momento cual es la maquina destinada como principal y cual como secundaria). En segundo lugar, especifica la IP que ha de soportar el servicio de red de alta disponibilidad. Por último, especifica cuales han de ser estos servicios.

ANEXO V

Nótese que en ningún momento se este indicando a heartbeat por que‚ interfaz de red se han de ofrecer los servicios de alta disponibilidad. Es decir, se le dice que IP es la que ha de dar estos servicios pero no la interfaz que ha de ser configurada con esa IP. En el caso de que la maquina disponga de mas de una tarjeta de red, heartbeat recurre a la tabla de enrutado del sistema para decidir que interfaz de red se hará cargo. Por ejemplo, uno podría pensar que si el servicio de alta disponibilidad se ha de dar por la 192.168.3.155, añadir esta entrada a la tabla de rutado con: #route add 192.168.3.0 eth0 sería suficiente para que heartbeat supiera que la IP 192.168.3.155 ha de ser levantada utilizando la interfaz eth0. Craso error! Ya que la entrada correcta sería: #route add 192.168.3.155 eth0 ya que el script /etc/ha.d/resources.d/IPaddr no sabe de mascaras de red y solo busca en la tabla de enrutado la IP que se especifico en /etc/ha.d/haresources. 2) En cuanto al archivo /etc/ha.d/authkeys... ‚ste esta incorrectamente especificado en el Getting Started with Linux-HA (GSLHA) (heartbeat) as¡ como en otra documentación, por lo menos en la configuracion que hace referencia a crc. El archivo 'authkeys' debería de quedar así: # authkeys auth 2 2 crc Con 1's no funciona !!!!!!!!!!! 3) Pese a que en el documento GSLHA se advierte que no se debe de realizar ninguna configuración en la IP de la interfaz externa, esto ha de ser correctamente interpretado. Se refiere a que no se ha de asignar una IP a ese interfaz, si bien esta interfaz deberá se mostrada la hacer 'ifconfig' ya que de lo contrario no estará configurada. Eso es asi porque heartbeat no levanta o no configura las interfaces, sino que simplemente crea un alias de la interfaz que hemos configurado. Con: #ifconfig 0.0.0.0 eth0 Configuramos la interfaz eth0 sin asignarle una IP. Es decir si hacemos #ifconfig eth0 saldrá como activa, si bien no nos mostrara una IP asociada a dicha interface. De esta manera, cuando lanzemos hertbeat se creara un alias a eth0 con la IP que ha de ofrecer el servicio de alta disponibilidad. Así si hacemos #ifconfig tras lanzar heartbeat, se nos mostrara: eth0 .........(sin ip asignada) ..... ....

ANEXO V

eth0:0 IP 192.168.3.155 (lo cual indica que la eth0 esta escuchando todos los puerto (:0) en la IP 192.168.3.155) PATH=" .......... :/etc/init.d" Añadimos ésta entrada ya que el archivo shellcript del "heartbeat" se encuentra ahí. - Archivos de configuración que hay que editar # /etc/ha.c/ha.cf debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 10 serial /dev/ttyS0 baud 9600 node director1 node director2 # /etc/ha.d/haresources director1 IPaddr::192.168.3.155/24 prueba-ha El formato de haresources es el siguiente: director1: Aquí le indicamos cual es la m quina dominante (de mayor prioridad). Ipaddr::192.168.3.155/24: Se podría omitir Ipaddr y poner directamente la IP, pero esto añadiría una máscara 255.255.255.255. Dado que queremos que la mascara sea de clase C, debemos hacerlo de la forma indicada en el archivo. Ipaddr es el script encargado de asignar la interface a la IP que le pasamos. Este script se encuentra en: /etc/ha.d/resource.d # /etc/ha.d/authkeys auth 2 2 crc Renombramos el /etc/rc.d/rc.inet1 para que no sea ejecutado al arrancar. Pasaremos toda la configuración al /etc/rc.d/rc.local # /etc/rc.d/rc.local #!/bin/sh # # /etc/rc.d/rc.local: Local system initialization script. # # Put any local setup commands in here: tail -f /var/log/messages >/dev/tty12 & tail -f /var/log/ha-log >/dev/tty5 & tail -f /var/log/ha-debug >/dev/tty6 & /sbin/ifconfig eth0 127.0.0.3 # Configuramos la eth1 con una IP distinta para cada realserver # dado que el heartbeat no la toca para nada. /sbin/ifconfig eth1 192.168.10.2 /sbin/route add 192.168.3.155 eth0 /etc/init.d/heartbeat start

ANEXO V

- Comandos útiles Para comprobar el correcto funcionamiento de hertbeat y detectar con facilidad posibles errores, pueden ser útiles los siguientes comandos: #tail -f /var/log/ha-debug (en una consola) y #tail -f /var/log/ha-log (en otra consola) de esta manera podremos ver los mensajes que esta lanzando la ejecución de heartbeat. otros comandos #heartbeat [start| stop | status]

ldirector Descripción Instalación y configuración de ldirectord ¿Qué es ldirectord? Ldirector es un programa que permite monitorizar los servicios balanceados por IPVS, y en función de la misma cambiar la configuración del balanceador de forma dinámica. Ldirectord permite monitorizar servicios como ftp, http y https. En función de los servicios que deseemos monitorizar requeriremos de más o menos librerías adicionales. Ldirectord está programado en Perl, por lo cual es necesario en primer lugar tener instalado el mismo en el sistema. Pre-requisitos para la instlación del ldirectord Según el archivo "README" de la documentación interna del heartbeat-0.4.9.2.tar.gz, pues se requieren las librerías allí especificadas antes de proceder a compilar la aplicación. La mayoría de librerías requeridas están disponibles en el sitio: http://search.cpan.org Las descargamos y generamos los prototypes y posteriormente los packages por este orden. También se deben de instalar uno a uno después de la compilación para evitar los problemas de dependencias. http://search.cpan.org #wget http://www.cpan.org/authors/id/G/GA/GAAS/MIME-Base64-2.12.tar.gz (Sólo requiere perl 5.002 ó posteriores) #wget http://www.cpan.org/authors/id/G/GA/GAAS/URI-1.22.tar.gz #wget http://www.cpan.org/authors/id/S/SB/SBURKE/HTML-Tagset-3.03.tar.gz #wget http://www.cpan.org/authors/id/S/SB/SBURKE/HTML-Parser-3.26.tar.gz #wget http://www.cpan.org/authors/id/ ................................Digest MD5

ANEXO V

#wget http://www.cpan.org/authors/id/G/GB/GBARR/libnet-1.12.tar.gz #wget http://www.cpan.org/authors/id/G/GA/GAAS/libwww-perl-5.65.tar.gz Descarga de la versión actualizada Pese a que la versión que acompaña a heartbeat no es la más actualizada. La última versión suele estar en www.ultramonkey.org . Se peden producir fallos si utilizamos una versión que crea reglas no compatibles con la versión de ipvsadm que tengamos en nuestra máquina. Ldirectord se puede lanzar desde la línea de comandos o bien utilizando para ello el programa heartbeat. Si lo hacemos de la primera forma, el ejecutable es: /usr/sbin/ldirectord. Si lo que deseamos es que ldirectord sea lanzado por heartbeat, como en nuestro caso, deberemos crear un link simbólico en /etc/ha.d/resource.d/ldirectord que apunte al programa real situado en /usr/sbin/directord. #ln -s /usr/sbin/ldirectord /etc/ha.d/resource.d/ldirectord a) Sobre el script en perl: /usr/sbin/ldirectord Hay que comentar las funciones que chequean los servicios que no queremos monitorizar, para dejarlas inactivas, para que al arrancar el perl no nos de errores.

check_https check_ftp

Como se ha comentado antes, algunas versiones de este programa crean reglas que pueden no ser compatibles con la versión de IPVS con la que hemos parcheado el kernel. Ipvsadm cambia el significado del comando –R y pasa a utilizar –r para añadir servidores reales. Si nos encontramos con este fallo y no queremos volver a compilarlo todo, es posible cambiar las –R por –r en el código fuente de ldirectord. Esta tarea se puede hacer muy rápidamente si utilizamos el editor vim. Bastará con utilizar la orden siguiente desde el modo de comandos del vim: #vim /usr/sbin/ldirectord :1,1694s/-R/-r/g con esto hemos cambiado todas las -R por -r Archivos de configuración de ldirectord /etc/ha.d/conf/configuration # Archivo de configuracion del ldirectord arrancado por heartbeat # checktimeout = 6 checkinterval = 2 virtual = 192.168.3.150:80 real = 192.168.10.101:80 masq 5 real = 192.168.10.102:80 masq 5 service = http scheduler = rr checktype = negotiate request = "index.html(la web que solicito)" receive = "pepito grillo (la cadena que espero)" virtual = 192.168.3.150:21 real = 192.168.10.101:21 masq 5 real = 192.168.10.102:21 masq 5

ANEXO V

service = ftp scheduler = rr login = "anonymous" passwd = "[email protected]" persistent = 600 protocol=tcp Este archivo permite configurar el balanceador de carga con los servicios http y ftp. Notas adicionales En el archivo de configuración del ldirecord no se deben de dejar líneas en blanco después de la sección virtual. Configuración de los realservers echo "1" > (también hay que poner esto en los directors para activar el forwarding) Ojo con estos archivos pq a veces pueden dar problemas! /etc/hosts /etc/resolf.conf Arrancadar ldirectord vía heartbeat # /etc/ha.d/haresources director1 IPaddr::192.168.3.150/24 ldirectord::configuration director1 IPaddr::192.168.10.100/24 Configuración básica de ldirector probar esto antes de intentar otras más complejas # /etc/ha.d/conf/configuration checktimeout = 6 checkinterval = 2 virtual = 192.168.3.150:80 real = 192.168.10.101:80 masq 5 real = 192.168.10.102:80 masq 10 service = http scheduler = rr request = "index.html" receive = "Real" Nota: No dejar ninguna línea en blanco después de la sección virtual.

ANEXO V

lpvs Descripción Este documento describe el proceso de configuración del ipvsadm. Tabla de contenidos: - Obtención de las fuentes del ipvsadm. Creación del paquete ipvsadm.tgz para Slackware. - Configuración Configuración de prueba (balanceador de carga simple) - Configuración de prueba (balanceador de carga simple) Seguimos el esquema indicado en ACADE-NAT-IPconfig.(a determinar), pero con un solo director, en este caso, el director1 a solas. En primer lugar bastara con editar el siguiente archivo en los directors rc.lvs_nat, que configura el director1 para capacitarlo para redirigir las peticiones de telnet a los rserver1 y rserver2. #!/bin/sh # Script de configuración (basado en el del mini-howto) # # Activamos ip_forward cat /proc/sys/net/ipv4/ip_forward echo "1" > /proc/sys/net/ipv4/ip_forward # El director es el gateway de los realserver # desactivamos la redireccion ICMP echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects cat /proc/sys/net/ipv4/conf/all/send_redirects echo "0" > /proc/sys/net/ipv4/conf/default/send_redirects cat /proc/sys/net/ipv4/conf/default/send_redirects echo "0" > /proc/sys/net/ipv4/conf/eth0/send_redirects cat /proc/sys/net/ipv4/conf/eth0/send_redirects # Setup VIP /sbin/ifconfig eth0 192.168.3.155 broadcast 192.168.3.255 netmask 255.255.255.0 # Setup eth1 /sbin/ifconfig eth1 192.168.10.1 broadcast 192.168.10.255 netmask 255.255.255.0 # Set default gateway /sbin/route add default gw 192.168.3.1 netmask 0.0.0.0 metric 1 # Clear ipvsadm tables /sbin/ipvsadm -C # Instalamos los servicios LVS con ipvsadm # Añade el servicio telnet a la VIP con Round Robin como politica de reenvio

ANEXO V

/sbin/ipvsadm -A -t 192.168.3.155:telnet -s rr # Primer realserver # reenvia peticiones telnet al realserver 192.168.10.101 utilizando # LVS-NAT (-m), con espera=1 /sbin/ipvsadm -a -t 192.168.3.155:telnet -r 192.168.10.101:telnet -m -w 1 ping -c 1 192.168.10.101 # Second realserver # reenvia peticiones telnet al realserver 192.168.10.102 utilizando # LVS-NAT (-m), con espera=1 /sbin/ipvsadm -a -t 192.168.3.155:telnet -r 192.168.10.102:telnet -m -w 1 ping -c 1 192.168.10.102 # Listamos la table ipvsadm del kernel echo "Estado actual de la tabla ipvsadm del kernel" /sbin/ipvsadm Después de editar dicho script le dan permisos de ejecución. #chmod 755 rc.lvs_nat Antes de ejecutar el script, hay que desactivar las interfaces de red si estan up, con los comandos: #ifconfig eth0 down #ifconfig eth1 down Posteriormente ejecutamos el script. #./rc.lvs_nat Ahora deberemos ejecutar este otro scipt en cada uno de los realservers. #!/bin/sh # Asignamos el gateway correcto para vs-nat /sbin/route add default gw 192.168.10.1 # mostramos la tabla de rutado /bin/netstat -rn # comprobamos si el gateway es alcanzable ping -c 1 192.168.10.1 # deshabilita el reenvío de paquetes echo "0" > /proc/sys/net/ipv4/ip_forward cat /proc/sys/net/ipv4/ip_forward

ANEXO V

Apache Descripción El servidor Apache HTTP es un proyecto de la Apache Software Fundation, para desarrollar y mantener un servidor HTTP de código abierto para sistemas operativos modernos como UNIX o Windows. El objetivo de este proyecto es proveer un servidor seguro, eficiente y extensible que proporcione servicios HTTP en sintonía con los actuales estándares de HTTP. Apache es el servidor web más popular de Internet desde abril del 1996. Lanzando el servicio Al instalar el apache como paquete se nos crea el archivo /etc/rc.d/rc.http el cual es invocado por los archivos de inicio y detención del sistema. De esta manera, en función del parámetro que se le pasa al script este lanzará el servicio con el típico apachectl start o lo detendrá con un apachectl stop. Así, el archivo de inicio del sistema /etc/rc.d/rc.M mira si existe el archivo rc.httpd y si es así lo ejecuta pasándole como parámetro start. Del mismo modo, si nos vemos en la necesidad de parar el servicio, podremos hacerlo con apachectl stop. Lo podemos volver a lanzar con apachectl start y si lo que queremos es reiniciarlo para hacer efectivo un cambio en el archivo de configuración lo podemos hacer de una sola vez con apachectl restart. Configuración básica Los archivos de configuración de Apache se encuentran en el directorio /etc/apache. El archivo de configuración del demonio del apache httpd es /etc/apache/httpd.conf. Para configurar el apache es necesario editar este archivo y descomentar la línea que hace referencia a la IP y el puerto por el cual ha de recibir las peticiones http. Listen 192.168.10.102:80 Si una vez descomentada la línea anterior el apache no se lanza correctamente con un apachectl start lo más probable es que sea porque la configuración de la red de nuestra máquina no está del todo terminada. Si no tenemos acceso a un DNS y el archivo /etc/hosts no contiene una entrada capaz de resolver nuestra propia IP, el apache no funcionará. Basta entonces con añadir a este archivo una línea como esta: 192.168.10.102 rserver1.acade.net rserver1 Así, aunque no podamos acceder a un DNS, la máquina es capaz de resolver el nombre asociado a la IP en la que ha de correr el httpd, ya que, antes de ir a consultar un DNS externo, el sistema consulta siempre antes de archivo /etc/hosts, motivo por el cual conviene siempre tener dicho archivo al día. En principio esto es suficiente para probar que el httpd funciona. Si no tocamos nada más del archivo de configuración de Apache, este servirá por defecto una web que nos indica que la instalación se ha realizado con éxito. El contenido de esta página está en /var/www/htdocs, pero podemos hacer que por defecto sirva otro contenido mediante la siguiente directiva: DocumentRoot "/var/www/htdocs"

ANEXO V

si en lugar de /var/www/htdocs ponemos la ruta al directorio que contenga las paginas que deseamos servir. Otra opción es redireccionar el directorio anterior mediante un link simbólico que apunte al lugar que contiene las páginas que queremos servir. Configuración avanzada (Virtual Hosting) Apache soporta virtual hosting, es decir, la posibilidad de alojar más de un sitio web en una misma máquina. Para ello deberemos comentar la directiva "Listen" del archivo de configuración de apache /etc/apache/httpd.conf. Y añadir una entrada "VirtualHost" para cada sitio web que deseamos ofrecer. De esta forma, cuando Apache reciba una petición de servicio http será capaz de discernir qué contenido a de ser servido como respuesta a esa petición. En primer lugar, deberemos especificar mediante la directiva: NameVirtualHost xxx.xxx.xxx.xxx la dirección IP por la que haremos virtual host. Posteriormente, añadiremos tantas entradas de virtual host como webs diferentes deseemos servir por la IP especificada en NameVirtualHost. <VirtualHost xxx.xxx.xxx.xxx> ServerAdmin [email protected] DocumentRoot /acade/sites/assl ServerName assl.acade.net ErrorLog logs/assl-error_log Customlog logs/assl-access_log common </VirtualHost> <VirtualHost xxx.xxx.xxx.xxx> ServerAdmin ... DocumentRoot /acade/sites/prueba ServerName prueba.acade.net ... </VirtualHost> Las directivas DocumentRoot y ServerName son las que le dicen a apache qué ha de mostrar y cuando. Así, si el cliente teclea en su navegador http://assl.acade.net, Apache le mostrará la pagina por defecto alojada en el directorio /acade/sites/assl. Si por el contrario el cliente pica en su navegador http://prueba.acade.net, Apache le servirá la pagina por defecto que se encuentre en /acade/sites/prueba. Es importante resaltar que los archivos /logs/assl-error_log y /logs/assl-access_log han de existir en nuestra máquina, de lo contrario apache no arrancará. Estos archivos se buscan en /usr/logs a no ser que especifiquemos la ruta completa al archivo. Por defecto, Apache mostrará la pagina index.html del directorio especificado en DocumentRoot para la URL indicada por ServerName, ahora bien, es posible hacer que Apache busque otra página para servir por defecto. Basta con añadir el nombre de la página que deseamos que se muestre por defecto utilizando para ello la directiva DirectoryIndex de la siguiente manera: <IfModule mod.dir.c>

DirectoryIndex index.html index.htm index.php index.php3 index.php4 </IfModule> De esta manera apache buscará por este orden la página que ha de ser servida.

ANEXO V

Por último, es necesario decirle a Apache que cargue los módulos de PHP para poder servir páginas programadas en PHP. Para ello, basta con introducir lo siguiente al final del archivo de configuración /etc/apache/httpd.conf: Include /etc/apache/mod_php.conf Include /etc/apache/mod_ssl.conf De esta manera Apache cargará los módulos externos necesarios para poder servir páginas PHP. Bibliografía Documentación Oficial Apache 1.3, en inglés: http://httpd.apache.org/doc

PHP Descripción PHP, acrónimo de “PHP: Hypertext Preprocesor”, es un lenguaje “Open Source” interpretado de alto nivel, especialmente pensado para desarrollos web y el cual puede ser embebido en páginas HTML. La mayoría de su sintaxis es similar a C, Java y Perl y es fácil de aprender. La meta de este lenguaje es permitir escribir a los creadores de páginas web, páginas dinámicas de una manera rápida y fácil, aunque se pueda hacer mucho más con PHP. Instalación y configuración Al instalar el paquete de PHP se crean en /etc/apache los archivos de configuración de PHP php.ini y mod_php.conf. El primero de ellos deberá contener las siguientes entradas: LoadModule php4_module libexec/libphp4.so AddModule mod_php4.c AddType application/x-httpd-php.php El segundo archivo php.ini configura PHP. Para que pueda ejecutar correctamente la web que hemos programado a modo de ejemplo, es necesario activar las siguientes directivas de este archivo. register_globals = On register_argc_argv = On Bibliografía Manual de PHP: http://www.php.net/manual/es

ANEXO V

MySQL Descripción Este documento explica los pasos a seguir para instalar y configurar una MySQL en los servidores reales. También se documenta la opción de MySQL replication. Instalando el software Utilizaremos los paquetes correspondientes a Apache, PHP y MySQL que trae nuestra distribución que son: apache-1.3.26-i386-1.tgz php-4.2.1-i386-1.tgz mysql-3.23.51-i386-1.tgz Los instalaremos de esta manera: root@rserver1:/#mount /dev/cdrom root@rserver1:/#installpkg /mnt/cdrom/slackware/n/apache-1.3-26-i386-1.tgz root@rserver1:/#installpkg /mnt/cdrom/slackware/n/php-4.2.1-i386-1.tgz root@rserver1:/#installpkg /mnt/cdrom/slackware/ap/mysql-3.23.51-i386-1.tgz Configurando MySQL Tras instalar el paquete de MySQL, deberemos hacer lo siguiente: root@rserver1:/#mysql_isnstall_db Esto crea los archivos necesarios para poder ejecutar mysql. Este script coloca estos archivos en /usr/lib/mysql/mysql/ pero para que mysql los pueda leer al arrancar, es necesario cambiar el propietario de dichos archivos y del directorio que los contiene. Así, deberemos asegurarnos de que el propietario de estos directorios y archivos: /usr/lib/mysql /usr/lib/mysql/mysql /usr/lib/mysql/mysql/* es el usuario mysql y están en el grupo mysql. Podemos lograr esto así: root@rserver1:/var/lib/#chown mysql:mysql mysql root@rserver1:/var/lib/mysql/#chown mysql:mysql mysql root@rserver1:/var/lib/mysql/mysql/#chown mysql:mysql * Ahora ya estamos en condiciones de lanzar el demonio mysqld. root@rserver1:/safe_mysqld & Si el demonio arranca sin problemas podemos añadir la siguiente línea en el archivo /etc/rc.d/rc.local: /usr/bin/safe_mysqld &

ANEXO V

Eso hará que el demonio de la mysql sea lanzado de forma automática cada vez que arranca el sistema. Los pasos siguientes, una vez tenemos el demonio corriendo en nuestro sistema, serán los de asignar un password al usuario root, crear las bases de datos y los usuarios que vamos a necesitar. - Para asignar el password al usuario root: root@rserver1:/#mysqladmin -u root password "mi_password" - Para crear una base de datos: root@rserver1:/#mysqladmin -u root -pmi_password create mi_base_de_datos - Para borrar una base de datos: root@rserver1:/#mysqladmin -u root -pmi_password drop mi_base_de_datos Las consultas al demonio mysqld, se realizan mediante el cliente mysql. Es muy importante crear más usuarios para acceder a nuestras bases de datos, ya que el usuario root tiene permisos en todas las tablas, además de permiso para crear tablas en todas las bases de datos. Lo normal es crear un usuario diferente con acceso únicamente a aquellas bases de datos que sea necesario, además este podrá realizar sólo el tipo de consultas que nosotros queramos, por ejemplo "SELECT", "INSERT" y "UPDATE" de manera que no se le permita crear (CERATE) o borrar (DROP) tablas de la base de datos o tabla a la que le hemos dado acceso. - Crear un usuario nuevo. Primero ejecutaremos el cliente mysql: root@rserver1:/#mysql -u root -pmi_password Esto me da el prompt de la consola cliente del demonio mysqld. Mediante este cliente, podremos realizar consultas al demonio de la MySQL. En este ejemplo las consultas que introduzca en la consola cliente de MySQL serán como usuario root. Una ves estamos ante la consola cliente de MySQL utilizamos el siguiente comando para crear un usuario: mysql>GRANT select,insert,update ON documentacion.* TO epito@localhost IDENTIFIED BY 'password_para_pepito'; Esto crea un usuario nuevo llamado "pepito". Este usuario tiene permisos para realizar consultas tipo SELECT, INSERT y UPDATE. Le hemos dado permiso para consultar todas las tablas de la base de datos "documentacion" (documentacion.*) y su password de acceso será "password_para_pepito". Así, ahora podemos ejecutar el cliente de MySQL como el usuario "pepito", lo haremos así: root@rserver1:/mysql -u pepito -ppassword_para_pepito mysql>use documentacion; o bien de una sola vez: root@rserver1:/mysql -u pepito -ppassword_para_pepito documentacion mysql>

ANEXO V

NOTA: Es importante no dejar espacios en blanco entre el parámetro "-p" y el password, de lo contrario no nada de lo anteriormente explicado funcionará. Comandos y consultas básicas - Comandos: Además de la orden "use" para utilizar una base de datos diferentes, nos serán útiles los siguientes comandos: ? Muestra una lista con los comandos MySQL. use <db_name>; Cambia la base de datos acutal status; Muestra información relativa a MySQL: Versión del servidor, bases de

datos actual, usuario logeado, versión del servidor, uptime, consultas realizadas etc, etc.

- Consultas básicas: mysql>SHOW tables; Muestra las tablas de la base de datos acutal. mysql>DROP table <db_name>; Elimina una tabla si tenemos permiso para ello. Para crear una tabla en la base de datos: mysql>CREATE TABLE <nombre_tabla> ( campo_1 tinyint(8) unsigned zerofill NOT NULL auto_increment, campo_2 char(50) NOT NULL default 'valor_por_defecto', campo_n ..., PRIMARY KEY (campo_1) ) TYPE=MyISAM; Para insertar un dato en la tabla creada: INSERT INTO <nombre_tabla> VALUES (00000001,'dato_campo_2','dato_campo_n'); Con una consulta así: SELECT campo_1, campo_2 FROM nombre_tabla; Obtendremos retorna los campos campo_1 y campo_2 de la tabla nombre_tabla. Una consulta así: SELECT campo_1 FROM nombre_tabla WHERE campo_2='verde'; Retorna el campo_1 de todas los registros de la tabla cuyo campo_2 vale verde. Herramientas Útiles Hemos visto como utilizar mysqladmin, safe_mysql y mysql para crear bases de datos, lanzar el demonio mysqld y realizar consultas a MySQL. A continuación, describimos algunos ejemplos de otros comandos que nos pueden resultar muy útiles: root#rserver1:/#mysql -u root -pmi_password documentacion < backup_bd.sql Este comando es muy útil para cargar los datos que definen la base de datos documentacion. Es decir, el archivo backup_bd.sql contiene todas las consultas necesarias para crear las tablas

ANEXO V

de la base de datos documentacion. Además, también contiene las consultas INSERT que nutren la base de datos. Seguramente, te estarás preguntando de dónde demonios sacamos el archivo backup_db.sql? Pues bien, tenemos dos opciones: o bien lo picamos a mano, probablemente tendrás que hacerlo la primera vez ;oP ), o bien lo generamos con la utilidad mysqldump que trae MySQL. Así: root@rserver1:/#mysqldump -u root -pmi_password documentacion > backup_bd.sql vuelca todas las consultas que crean y nutren la base de datos al archivo backup_bd.sql. MySQL Replication Configuración para MySQL Replication con master fijo. En el master creamos el usuario replicador con los siguientes comandos: Para logearnos en la base de datos como root: #mysql -u root -ppof.rulez Y una vez dentro generamos el usuario con permisos totales de tipo FILE. mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY 'pof.rulez'; En el master debemos de editar el siguiente archivo de configuración. # /etc/my.cnf [mysqld] log-bin server-id=1 Para cada slave también editamos un archivo de configuración. La única diferencia será el valor de server-id, que no puede repetirse en ningún servidor. En master-user le indicamos al slave con qué cliente debe de logearse al master. # /etc/my.cnf [mysqld] server-id=2 master-host=rserver1 master-user=repl master-password=pof.rulez master-connect-retry=10 Nota: El puerto por defecto es el 3306. Algunos archivos importantes a tener en cuenta son: /var/run/mysql/mysql.sock= Dónde residen los sockets que posibilitan la connexion entre ambos servidores. /var/lib/mysql/rserver1.err Log que informa de la disponibilidad del master para aceptar connexiones. /var/lib/mysql/rserver2.err Log que informa de si el slave se ha podido conectar al master con éxito. /var/lib/mysql/master.info Archivo que genera el slave a partir del my.cnf. Nosotros lo borramos cada vez que hacemos algún cambio en my.cnf y rebotamos posteriormente el servicio.

ANEXO V

Puede encontrarse la lista completa de todas las opciones de configuración para los my.cnf en el apartado 4.10 del manual de MySQL. Documentación MySQL Manual http://www.mysql.com/documentation/index.html

ANEXO VII

Anexo VII Análisis empírico del funcionamiento del dispositivo lo:0 frente a peticiones ARP en kernels Linux 2.4.x Escenario del experimento: Configuración rserver1: eth0: 192.168.1.1 255.255.255.0 lo: 127.0.0.1 255.0.0.0 lo:0 192.168.1.110 255.255.255.255 Configuración rserver2: eth0: 192.168.1.2 255.255.255.0 lo: 127.0.0.1 255.0.0.0 Las caches arp de las dos máquinas están vacias.

Hacemos ping desde el rserver2 a la 192.168.1.110 que esta en el alias al loopback

lo:0 del servidor real 1.

Captura de la interface eth0 del rserver2: 10:01:00.287617 arp who-has 192.168.1.110 tell 192.168.1.2 10:01:00.287945 arp reply 192.168.1.110 is-at 0:e0:29:25:4e:9a 10:01:00.288051 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:00.288339 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:01.299715 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:01.299998 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:02.299709 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:02.299962 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:03.299705 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:03.299955 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:04.299706 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:04.299971 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:05.285115 arp who-has 192.168.1.2 tell 192.168.1.1 10:01:05.285319 arp reply 192.168.1.2 is-at 0:e0:29:25:46:57 10:01:05.299704 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:05.299962 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:06.299713 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:06.299964 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:07.299705 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:07.299958 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:08.299700 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:08.299943 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:09.299709 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:09.299967 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:10.299696 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:10.299944 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:11.299710 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:11.299959 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:12.299699 192.168.1.2 > 192.168.1.110: icmp: echo request (DF)

ANEXO VII

10:01:12.299944 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:13.299703 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:13.299953 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:14.299706 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:14.299953 192.168.1.110 > 192.168.1.2: icmp: echo reply 10:01:15.299702 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 10:01:15.299952 192.168.1.110 > 192.168.1.2: icmp: echo reply Captura de la interface lo del loopback del rserver2: 10:00:49.992113 localhost.blackjack > localhost.domain: 58561+ A? rserver1. (26) (DF) 10:00:49.992284 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:00:49.992839 localhost.blackjack > localhost.domain: 58561+ A? rserver1. (26) (DF) 10:00:49.992990 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:00.002677 localhost.blackjack > localhost.domain: 58562+ A? rserver1. (26) (DF) 10:01:00.002846 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:00.003406 localhost.blackjack > localhost.domain: 58562+ A? rserver1. (26) (DF) 10:01:00.003560 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:00.297400 localhost.blackjack > localhost.domain: 2756+[|domain] (DF) 10:01:00.297568 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:00.298366 localhost.blackjack > localhost.domain: 2756+[|domain] (DF) 10:01:00.298524 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:00.300767 localhost.blackjack > localhost.domain: 2757+[|domain] (DF) 10:01:00.300991 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:00.301516 localhost.blackjack > localhost.domain: 2757+[|domain] (DF) 10:01:00.301674 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:05.287364 localhost.blackjack > localhost.domain: 2758+[|domain] (DF) 10:01:05.287534 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:05.288060 localhost.blackjack > localhost.domain: 2758+[|domain] (DF) 10:01:05.288213 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:10.012061 localhost.blackjack > localhost.domain: 58563+ A? rserver1. (26) (DF) 10:01:10.012230 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:10.012809 localhost.blackjack > localhost.domain: 58563+ A? rserver1. (26) (DF) 10:01:10.012961 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:20.022044 localhost.blackjack > localhost.domain: 58564+ A? rserver1. (26) (DF) 10:01:20.022212 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:20.022758 localhost.blackjack > localhost.domain: 58564+ A? rserver1. (26) (DF) 10:01:20.022912 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:30.032052 localhost.blackjack > localhost.domain: 58565+ A? rserver1. (26) (DF) 10:01:30.032227 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:30.032777 localhost.blackjack > localhost.domain: 58565+ A? rserver1. (26) (DF) 10:01:30.032929 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:40.042047 localhost.blackjack > localhost.domain: 58566+ A? rserver1. (26) (DF) 10:01:40.042214 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 10:01:40.042753 localhost.blackjack > localhost.domain: 58566+ A? rserver1. (26) (DF) 10:01:40.042904 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0]

ANEXO VII

Captura de la interface eth0 del rserver1: 17:31:33.348856 arp who-has 192.168.1.110 tell 192.168.1.2 17:31:33.349021 arp reply 192.168.1.110 is-at 0:e0:29:25:4e:9a 17:31:33.349268 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:33.349412 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:34.360939 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:34.361044 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:35.360908 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:35.360988 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:36.360877 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:36.360959 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:37.360859 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:37.360951 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:38.346082 arp who-has 192.168.1.2 tell 192.168.1.1 17:31:38.346425 arp reply 192.168.1.2 is-at 0:e0:29:25:46:57 17:31:38.360833 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:38.360921 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:39.360821 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:39.360899 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:40.360791 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:40.360871 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:41.360760 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:41.360839 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:42.360752 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:42.360838 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:43.360712 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:43.360792 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:44.360705 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:44.360785 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:45.360671 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:45.360749 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:46.360653 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:46.360732 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:47.360634 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:47.360712 192.168.1.110 > 192.168.1.2: icmp: echo reply 17:31:48.360607 192.168.1.2 > 192.168.1.110: icmp: echo request (DF) 17:31:48.360689 192.168.1.110 > 192.168.1.2: icmp: echo reply

ANEXO VII

Captura de la interface lo del rserver1: 17:31:33.354609 localhost.blackjack > localhost.domain: 12559+ PTR? 110.1.168.192.in-addr.arpa. (44) (DF) 17:31:33.354738 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 17:31:33.355162 localhost.blackjack > localhost.domain: 12559+ PTR? 110.1.168.192.in-addr.arpa. (44) (DF) 17:31:33.355246 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 17:31:33.356460 localhost.blackjack > localhost.domain: 12560+ PTR? 2.1.168.192.in-addr.arpa. (42) (DF) 17:31:33.356553 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 17:31:33.356810 localhost.blackjack > localhost.domain: 12560+ PTR? 2.1.168.192.in-addr.arpa. (42) (DF) 17:31:33.356891 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 17:31:38.347297 localhost.blackjack > localhost.domain: 12561+ PTR? 1.1.168.192.in-addr.arpa. (42) (DF) 17:31:38.347406 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] 17:31:38.347670 localhost.blackjack > localhost.domain: 12561+ PTR? 1.1.168.192.in-addr.arpa. (42) (DF) 17:31:38.347748 localhost > localhost: icmp: localhost udp port domain unreachable [tos 0xc0] Captura de la interface lo:0 del rserver1: 17:31:33.354609 127.0.0.1.blackjack > 127.0.0.1.domain: 12559+ PTR? 110.1.168.192.in-addr.arpa. (44) (DF) 17:31:33.354738 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port domain unreachable [tos 0xc0] 17:31:33.355162 127.0.0.1.blackjack > 127.0.0.1.domain: 12559+ PTR? 110.1.168.192.in-addr.arpa. (44) (DF) 17:31:33.355246 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port domain unreachable [tos 0xc0] 17:31:33.356460 127.0.0.1.blackjack > 127.0.0.1.domain: 12560+ PTR? 2.1.168.192.in-addr.arpa. (42) (DF) 17:31:33.356553 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port domain unreachable [tos 0xc0] 17:31:33.356810 127.0.0.1.blackjack > 127.0.0.1.domain: 12560+ PTR? 2.1.168.192.in-addr.arpa. (42) (DF) 17:31:33.356891 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port domain unreachable [tos 0xc0] 17:31:38.347297 127.0.0.1.blackjack > 127.0.0.1.domain: 12561+ PTR? 1.1.168.192.in-addr.arpa. (42) (DF) 17:31:38.347406 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port domain unreachable [tos 0xc0] 17:31:38.347670 127.0.0.1.blackjack > 127.0.0.1.domain: 12561+ PTR? 1.1.168.192.in-addr.arpa. (42) (DF) 17:31:38.347748 127.0.0.1 > 127.0.0.1: icmp: 127.0.0.1 udp port domain unreachable [tos 0xc0]

Bibliografía

Bibliografía

[0] Chandra Kopparapu, Load Balancing Servers, Firewalls, and Caches, Published by

John Wiley & Sons, Inc. 2002

[1] P. Srisuresh, M. Holdrege, IP Network Address Translator (NAT) Terminology and

Considerations, RFC 2663 Agosto 1999

[2] K. Egevang, P. Francis, The IP Network Address Translator (NAT), RFC 1631

Mayo 1994

[3] P. Srisuresh, K. Egevang, Traditional IP Network Address Translator (Traditional

NAT), RFC 3022 Enero 2001

[4] H. Schulzrinne, A. Rao, R. Lanphier, Real Time Streaming Protocol (RTSP), RFC

2326 Abril 1998

[5] http://www.iana.org/assignments/port-numbers, IANA Port Numbers, última

modificación 2003-01-17

[6] S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson,

M. Shand, A. Lindem, Virtual Router Redundancy Protocol , RFC 2338 Abril 1998

[7] Joseph Mack, LVS-HOWTO Install, testing and running of a Linux Virtual Server

with 2.2.x and 2.4.x kernels, Septiembre 2002

[8] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, Address

Allocation for Private Internets, RFC 1918 Febrero 1996

[9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,

Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616 Junio 1999

Bibliografía

[10] http://www.php.net/manual/es , Stig Sæther Bakken, Alexander Aulbach, Egon Schmid, Jim Winstead, Lars Torben Wilson, Rasmus Lerdorf, Andrei Zmievski, Jouni Ahto, Manual de PHP, Enero de 2003

[11] http://otn.oracle.com/products/oracle8/htdocs/xpsf3twp.htm, An Oracle Technical

White Paper, Oracle® Parallel Server, Junio 1997

http://otn.oracle.com/products/oracle8/htdocs/xpsf3twp.htm

Agradecimientos: La realización de este proyecto ha sido posible gracias a la colaboración de muchas personas, entre las que destacan: Joan Carles Núñez (Lmann) e Iván Belmonte (ttyp0) de la Asociación de Soporte al Software Libre (ASSL) por su inestimable ayuda, así como a Pau Oliva (pof) por sus sabias orientaciones. De otro modo, no queremos olvidarnos del apoyo de nuestros familiares y amigos, especialmente de Elisenda Fernández, Valeria, Juan Carlos Moreno, Miguel Ángel Moreno, Pilar Formiga, Txus, Laia y muchos otros. Gracias a Pere Manzanos y a Léonard Janer por tutelar este proyecto. En último lugar, pero no por ello menos importante, nuestro agradecimiento a: Vinton G. Cerf, Richard M. Stallman, Linus Torvalds y al resto de miembros de “la comunidad”, sin cuyo trabajo este proyecto no hubiera podido existir.

Documents

Arquitecturas de Clustering de Alta Disponibilidad y Escalabilidad … · 2005-02-27 · Prefacio Prefacio Estructura y contenido de la memoria La memoria del proyecto ACADE (LVS)