Felix Ortigosa Martinez PDF

UNIVERSIDAD DE COLIMA
FACULTAD DE TELEMTICA
MAESTRA EN CIENCIAS, REA TELEMTICA
IMPLEMENTACIN DE UN SERVIDOR WEB VIRTUAL
BALANCEADOR DE CARGA BASADO EN LINUX.
TESIS
Que para obtener el grado de
Maestro en Ciencias, rea Telemtica
Presenta:
Ing. Flix Ortigosa Martnez
Asesor :
M en C. Juan Antonio Guerrero Ibez
Colima, Col. Agosto de 2004.
DEDICADO A :
A Dios por todo lo que me ha dado.........
Mi esposa y mi beb,
ya
Mis hermanos, Mi Madre y Mi Abuela.
Por su apoyo y comprensin.
AGRADECIMIENTOS
A mis maestros de la Facultad de Telemtica por su apoyo incondicional.
A mi asesor por su paciencia.
A mis compaeros de trabajo la CGIC, Jess Muiz, Justino Pineda, Lilia Sierra,
Jess Cuevas, Arturo Gonzlez, Ma. Luisa Velasco, Martha Cernas, Dylva
Snchez, Ma del Refugio, por comprensin.
A mis amigos de la maestra que juntos hemos llegado a tener una preparacin.
A los dems compaeros de los centros de investigacin por su paciencia.
Y alguna otra persona que alguna vez me impulso a terminar este documento.
NDICE
Resumen ........................................................................................................... I
Abstract ................................................................................................................. II
Objetivo ................................................................................................................. III
Alcance ................................................................................................................. IV
Captulo I. Tecnologa Clusters ............................................................................. 7
1.1.
Esquemas de procesamiento en paralelo ................................................ 9

1.1.1. Mquinas SMP .............................................................................. 10
1.1.2. Mquinas UMA .............................................................................. 10
1.1.3. Mquinas NUMA ........................................................................... 10
1.1.4. Mquinas SIMD ............................................................................. 11
1.1.5. Mquinas MIMD ............................................................................ 11
1.2.
SMP en contra de otras Arquitecturas .................................................... 11
1.3.
Estilos de clster ..................................................................................... 12

1.3.1. Clster Homogneos .................................................................... 13
1.3.2. Clster Heterogneos ................................................................... 13
1.4.
Configuracin de un Clster ..................................................................... 14
1.5.
Arquitecturas de Clster .......................................................................... 15
1.6.
Caractersticas del Clster ...................................................................... 18
1.7.
Disponibilidad del Clster ........................................................................ 18
1.8.
Escalabilidad del Clster ......................................................................... 21
1.9.
Rendimiento del Clster .......................................................................... 23
1.10.
Clustering ................................................................................................ 23
1.11.
Servidores balanceadores de carga (SLB) .............................................. 25

1.11.1. Flexibilidad ..................................................................................26
1.11.2. Alta disponibilidad .......................................................................26
1.11.3. Escalabilidad .............................................................................. 27
1.11.4. Componentes de servidores balanceadores de carga ................ 27
1.11.4.1. Vips - IP virtual ..................................... 27
1.11.4.2. Servidores ......................................................................28

1.11.4.3. Grupos ........................................................................... 28
1.11.4.4. Nivel de acceso de Usuario ............................................ 28
1.11.5. Redundancia .............................................................................. 28
1.11.5.1. Roles de redundancia .................................................... 29
1.11.5.2. Escenario Redundancia Activo-en espera ......................29
1.11.5.3. Escenario Redundancia Activo-activo ............................ 31
1.11.5.4. Protocolo de redundancia virtual de enrutador (VRRP).. 33
1.11.5.5. Cable fuera de fallos ....................................................... 34
1.11.5.6. Estado fuera de fallos .................................................... 34
1.11.5.7. Persistencia ................................................................... 35
1.11.5.8. Verificacin de servicios ................................................ 35
1.11.5.9. Algoritmos de balanceo de carga ................................... 35
Captulo II. Plataformas de Desarrollo ................................................................. 36
2.1.
Sistema Operativo Windows 2000 ........................................................... 36

2.1.1. Terminologa de Clster ................................................................ 37
2.1.2. Clster de Servidores .................................................................... 38
2.1.3. Servidores Virtuales ...................................................................... 40
2.1.4. Grupos de Recursos ............ 42
2.1.5. Arquitectura del Servicio de Clster Server ......... 42
2.1.6. Cuatro soluciones clster ........ 43
2.2.
Sistema Operativo LINUX .................. 45

2.2.1. Clster Beowulf, pionero de los clusters ....................................... 46
2.2.1.1. Evolucin de la Arquitectura del Sistema Beowulf ........ 46
2.2.2. MOSIX ........................................................................................... 48
2.2.2.1. Tipos de configuracin de un Clster Mosix ..................... 49
2.2.3. Software de Programacin para el Clster .................................... 50
2.2.3.1. PVM .................................................................................. 50
2.2.3.2. MPI ....................................................................................56
2.2.4. Servidor Avanzado de Red Hat ..................................................... 60

2.2.4.1. Soporte de la Aplicacin ................................................... 61
Captulo III. Software LVS Linux Virtual Server ................................. 63
3.1.
Configuracin Tpica de FOS ................................................................... 63
3.2.
LVS Linux Virtual Server ............................................................. 65

3.2.1 Funcionamiento de LVS ................................................................ 66
3.2.2 Modos de Distribucin de Carga ................................................... 67
3.2.2.1. Modo DNS Round Robin ............................................... 67
3.2.2.2. Modo de Balanceo de Carga ............................................ 68
3.2.3. Tipos de Balanceo de carga en LVS ............................................. 69
3.2.3.1. Balanceo por NAT (VS-NAT) ............................................ 69
3.2.3.2. Balanceado por encapsulado IP (VS-Tun) ....................... 72
3.2.3.3. Balanceado por enrutamiento directo (VS-DR) ................ 76
3.2.4. Alta Disponibilidad en LVS ............................................................ 78
3.2.5. Configuracin Tpica de LVS (Linux Virtual Server) ...................... 81.
Captulo IV. Implementacin.. 86
4.1.
Esquema de la Implementacin ............................................................... 95
4.2.
Instalacin ................................................................................................ 96
4.3.
Configuracin ........................................................................................... 112
Captulo V. Conclusiones ...................................................................................... 124
Anexos .................................................................................................................. 137

Glosario ................................................................................................................. 151
Bibliografa ............................................................................................................ 169
INDICE DE FIGURAS Y TABLAS

Figura 1.1. Arquitectura SMP ................................................................................ 14
Figura 1.2. Configuracin bsica de un clster ..................................................... 17
Figura 1.3. Arquitectura de disco compartido ....................................................... 18
Figura 1.4. Arquitectura de disco cero compartir .................................................. 18
Figura 1.5. Un escenario clustering ...................................................................... 26
Figura 1.6. Esquema SLB simplificado ................................................................. 27
Figura 1.7. Escenario Redundancia, Activo-en espera ......................................... 32
Figura 1.8. Escenario Fuera de fallos, Activo-en espera ...................................... 32
Figura 1.9. Escenario Redundancia, Activo-Activo ............................................... 33
Figura 1.10. Escenario Variacin de Redundancia, Activo-Activo ........................ 34
Figura 1.11. Escenario Fuera de fallos Recuperable, Activo-Activo ..................... 34
Figura 2.1. Cluster de servidores de dos nodos que ejecuta windows 2000
advanced Server Windows NT Server 4.0 edicin empresarial ....... 40
Figura 2.2. Cluster de servidores de cuatro nodos que ejecuta windows
2000 Datacenter Server ....................................................................... 41
Figura 2.3. Vista fsica de los servidores virtuales en el servicio de

cluster server 42
Figura 2.4. Vista del cliente de los servidores virtuales del servicio
de cluster server .. 43
Figura 3.1. Esquema general de un LVS Linux Virtual Server .......................... 66
Figura 3.2. Configuracin de un LVS: VS-NAT ..................................................... 70
Figura 3.3. Imagen LVS: LVS-NAT, esquema fsico ............................................. 71
Figura 3.4. Imagen LVS: Encapsulado IP ............................................................ 73
Figura 3.5. Imagen LVS: VS-Tunneling ................................................................ 74
Figura 3.6. Imagen LVS: VS-Direct Routing ......................................................... 77
Figura 3.7. Imagen LVS: Alta Disponibilidad ........................................................ 79
Figura 3.8. Configuracin Bsica de un Clster LVS ............................................ 82
Figura 3.9. Configuracin Compleja de un Clster LVS ....................................... 84
Figura 4.1. Esquema Bsico de Clster LVS .. 88

Figura 4.2. Diagrama de Componentes de un LVS Clster de Red Hat 91
Figura 4.3. Diagrama del Clster Balanceo de Carga Alta Disponibilidad .........96
Figura 5.1. Grfica de los valores de acceso a las ligas ....................................... 133
Tabla 1. Relacin de fallas en contra de la frecuencia ....................................... 22

Tabla 2 Tecnologas de cluster compatibles con las distintas versiones
de sistemas operativos .......... 43
Tabla 3. Prestaciones ofrecidas por las distintas tecnologas de clster .... 44
Tabla 4. Mtodos de direccionamiento ............................................................... 78
Tabla 5. Tipos de Balanceo de Carga ....... 89
Tabla 6. Descripcin de los Parmetros Globales del Clster ............................ 91
Tabla 7. Descripcin de los Parmetros para el Servidor Virtual ....................... 92
Tabla 8. Descripcin de los Parmetros para los Servidores Reales ................. 93
Tabla 9. Herramientas de sincronizacin y monitoreo .... 94
Tabla 10. Tiempos de Respuesta de los Sitios WEB...........................................132
RESUMEN
En la actualidad una tecnologa predominante y necesaria es el Internet, el

cual es usado principalmente para el envo y consulta de informacin mediante un
navegador o explorador que nos facilita estas tareas, lo que conocemos como World
Wide Web (WWW) Web. Y para la disposicin de la informacin es elemental que
los sistemas de informacin trabajen al 100 %, pero al usuario no le interesa mucho
este aspecto ya que lo que l necesita es consultar la informacin de uno u otro
modo. El usuario no se da cuenta que publicar o tener la informacin disponible tiene
un costo econmico y de tiempo de procesamiento muy grande.
Una solucin viable para que esto no llegara a interrumpir el proceso de envo
y recepcin de informacin sin tener necesidad de una inversin mayor es la
tecnologa
clustering.
sta
tecnologa
se
puede
comprender
cuando
nos
cuestionamos cunto tiempo necesita tener su sistema funcionando?. Es decir,

qu tanto tiempo queremos que nuestra informacin est disponible. La tecnologa
clustering, se refiere al hardware con lo cual se construir lo que podemos describir
como clster.
En el presente trabajo, se analiza esta tecnologa con la construccin de un

clster y una implementacin real llamada LVS (Linux Virtual Server), con lo cual se
demostrar que con pocos recursos econmicos o ya existentes como puede ser un
equipo obsoleto o un equipo de bajo costo se soluciona el problema de
disponibilidad, escalabilidad y eficiencia que engloba un trmino llamado Alta
Disponibilidad dentro de la WWW.
ABSTRACT
At the present time a predominant and necessary technology is the Internet,

which is used mainly for the transference and consultation of information by means of
a navigator or explorer who facilitates these tasks to us, which we all know like World
Wide Web (WWW) or Web. In order to access the information, it is necessary that the
information systems be working to 100%. The user is not interested in this fact,
because he/she is interested in accessing the information in one way or another. The
user does not realize that in order to publish or to have the information available it is
needed a high cost and large processing time.
A feasible solution where the high cost and large processing time would not
interrupt the transference and reception of information without having necessity of a
high investment is the clustering technology. This technology may be understood
when we question ourselves: how much time do you need to have your system
working? Meaning, how much time do we want that our information be available?
Cluster technology aims the hardware which is commonly referred as cluster.
In the present work we will develop a cluster technology with the construction
of a cluster and using a real implementation called LVS (Linux Virtual Server). The
objective of this work is to demonstrate that with few or existing economic resources
(i.e. obsolete or low-cost equipment) we can solve the problem of availability,
scalability, and efficiency that includes a term called High Availability on the WWW.
II
OBJETIVO
El objetivo principal de la presente tesis es implementar con Tecnologa

Clster un servidor balanceador de carga tipo LVS haciendo uso de software libre y
equipo de cmputo de limitadas caractersticas.
III
JUSTIFICACIN
Para implementar un servidor Web eficiente que funcione 24x7 los 365 das
del ao, se necesita considerar varios puntos importantes como: computadoras con
buenas caractersticas, un lugar adecuado donde se deben instalarse las
computadoras, una unidad de respaldo de energa, y personal idneo para el
mantenimiento del servidor
Esto nos lleva a pensar que tan caro es poner un servidor y si realmente es
justificable la inversin inicial, porque debemos de comprar una computadora con las
ltimas caractersticas como: son la velocidad de respuesta, almacenamiento
primario, capacidad de presentar informacin en pantalla, entre otras cosas. Pero
esto ya no es problema con la tecnologa llamada clustering que implica construir un
servidor con equipo homogneo y no homogneo que cumpla con las mismas
funciones que una sola maquina. El equipo homogneo y no homogneo puede ser
de diferentes caractersticas.
De aqu es importante demostrar los pros y contras de cmo se construye un

cluster o un servidor balanceador de carga de Alto Rendimiento.
IV
ALCANCE
El desarrollo del presente trabajo es dar a conocer cmo es un clster LVS o

de alta disponibilidad.
Por qu conocer esta Tecnologa?
El internet es una tecnologa elemental para cualquier empresa. En aos

anteriores una empresa que necesitaba hacer un proceso administrativo para realizar
una venta, un pedido e incluso reportes para la toma de decisiones, tardaba varios
das, si la empresa es demasiado grande o fuera de la ciudad la tendencia es
implementar sistemas de informacin en una Intranet, o una WAN o Internet, para
despus emigrar a un Sitio WEB que ayude a agilizar estos trmites.
Pero la implementacin de este tipo de sistemas de informacin no es tan

sencilla, ya que deben de considerarse varios puntos importantes como son: equipo
que se utilizar, lugar donde se instalar, proveedor de Internet, desarrolladores del
sitio ( programadores, diseadores, entre otros), as tambin debe de considerarse el
mantenimiento del sitio, entre otros puntos. Pero un aspecto importantes es el
tecnolgico o hardware donde se instalar el sistema de informacin, que incluye:
computadoras,
impresoras,
unidades
de
respaldo
de
energa
(no-breaks),
concentradores o switches, instalacin elctrica.
Desde el punto de vista tecnolgico, debemos de analizar que tan moderno

debe ser nuestro equipo de cmputo para que los costos de adquisicin del mismo,
no se incrementen tanto. Al implementar un sistema de informacin en el sistema,
para tener ahorro de tiempo en la publicacin de datos, puede ser ms eficiente si la
informacin se publicara en un sitio WEB para estar disponible en Internet.
Esto tiene un costo elevado de la tecnologa si se instala un moderno equipo

de cmputo para la implementacin del sitio WEB.
Pero si las empresas no desean invertir mucho, y si desean tener lo ms

nuevo en vanguardia de Internet, aqu es donde la tecnologa clustering se vuelve
una buena alternativa.
Este tipo de idea es lo que se conoce como clustering1
http://www.microsoft.com/spain/msdn/estudiantes/computadores/disponibilidad/default.asp
VI
Captulo I Tecnologa Clster
CAPTULO I. TECNOLOGA CLSTER
Cundo falla un sistema empresarial o de misin crtica y los datos ya no

estn disponibles, ya no es una cuestin de "se cae la red", sino de "se caen los
negocios!". Ciertas personas, consideran este tipo de ambiente de TI (Tecnologas
de Informacin) bajo fuerte presin como "cmputo con riesgo empresarial". sta es
una situacin que ningn administrador puede tratar a la ligera y en la actualidad
llama mucho la atencin, sobre todo cuando prcticamente todos los negocios
dependen por completo de sus sistemas de TI.
En el mundo del cmputo empresarial de la actualidad, los administradores de

SI
(Sistemas
de
Informacin),
enfrentan
desafos
en
muchos
frentes
simultneamente, este abarca la empresa en un 90 % . Lo que antes se consideraba

un servicio o una aplicacin que era "deseable tener ahora es fundamental para la
operacin diaria de una empresa. Estas aplicaciones empresariales importantes
cubren desde cualquier oficina hasta el centro de datos, al mismo tiempo que son
externos a la empresa, y todas requieren soluciones de cmputo que estn
disponibles, confiables, escalables y flexibles en un esquema 24 x 7 x 365 en
funcionamiento.
Un poco ms de 35 % de estas aplicaciones se ejecutan 24 horas al da y
deben estar constantemente disponibles en un 99.9 o 100 por ciento. La
conformacin de clusters ha demostrado su enorme capacidad como herramienta
para enfrentar estos retos. El clster es un conjunto de computadoras,
que
contienen un mismo Sistema Operativo, y que estn conectadas entre s por un tipo
de Red o cualquier otro dispositivo para un uso especfico con una aplicacin o
software a fin. Los clusters tienen tres atributos primarios: disponibilidad,
escalabilidad, y facilidad de administracin.
La computacin en paralelo de alto rendimiento (HCP, High Paralel

Performance), se logra al dividir una tarea enorme y compleja entre varios
procesadores. Durante la segunda guerra mundial, antes de la invencin de la
computadora electrnica, se utiliz una tcnica similar para realizar grandes clculos
asociados con el diseo de la bomba atmica en el Proyecto Manhattan1 (1980).
Para reducir enormemente el tiempo de solucin de un problema matemtico grande,
cada parte del problema era resuelto por una persona distinta. A stas personas se
les llamaba computadoras. En la actualidad las computadoras electrnicas pueden
trabajar en armona para resolver problemas cientficos que no se soaba resolver
hace ms de una dcada.
El procesamiento en paralelo se refiere, al concepto de acelerar el tiempo de

ejecucin de un programa subdividindolo en fragmentos mltiples que pueden ser
ejecutados simultneamente, cada uno en su propio procesador. Un programa que
est siendo ejecutado en N procesadores puede correr N veces ms rpido que si
corriera en un solo procesador.
Como el enfoque de la tecnologa clusters2 es relativamente novedosa, el
significado del trmino clster no tiene todava una aceptacin ni una metodologa
bien desarrollada. El propsito del clster es el de agrupar elementos que tengan
caractersticas iguales o similares, establecen clasificaciones de la informacin, los
cuales permiten un fcil acceso a la misma y facilitan la toma de decisiones
estratgicas de los usuarios. Dentro de lo que es clster debemos tener en cuenta
algunos conceptos como son multiprocesamiento y sincronizacin.
Multiprocesamiento. Es la idea del programa control de una computadora, que

se llama Sistema Operativo, este puede soportar cargar,
descargar y tareas de
manera mltiple, independiente control simultneo de tareas.
http://www.angelfire.com/sc/energianuclear/bombaatomica.html
David HM Spector, July 2000

8
Si el sistema operativo puede soportar mltiples tareas de control soporta

cada tarea de control o proceso en una independiente, se puede describir como un
sistema operativo que soporta multiprocesamiento.
Sincronizacin. Es el proceso de poner procesos diferentes en sincrona. Por

ejemplo: simulacin del tiempo, donde pueden haber 1,000 procesos, cada uno
calculando un aspecto diferente de un fenmeno de tiempo local. El algn punto los
resultados de estos clculos se deben unir para permitir que un resultado mas
grande sea creado. Sincronizacin es el proceso que ocurre cuando la combinacin
de los resultados de un proceso puede ocurrir.
1.1. Esquemas de Procesamiento en Paralelo
El rea del procesamiento en paralelo ha sido una rea activa de investigacin

por muchos aos. Esto ha generado el incremento para crear computadoras
efectivas paralelas, y todas ellas, incluyendo linux clster paralelo, tiene diferentes
niveles de efectividad para diferentes tipos de problemas. Algunos de los mejores
mtodos conocidos son:
SMP,
Symmetric Multiprocessor - Mutlprocesamiento Simtrico.
UMA,
Uniform Memory Access - Acceso a Memoria Uniforme.
NUMA, Non-Uniform Memory Access - Acceso a Memoria No Uniforme.

SIMD,
Single Intruction Mltiple Data - Instruccin Simple de Datos Mltiple.
MIMD,
Mltiple Instruction Mltiple Data - Instruccin Mltiple de Datos

Mltiple, Clster Linux son una instancia de este Mtodo.
Estas representan los nombres ms comunes dados para diferentes tipos de

sistemas de computacin paralela. Algunos de estos son subcategoras de otros
tipos. A continuacin se explica cada una de estas arquitecturas.
1.1.1. Maquinas SMP
Las computadoras de Multiprocesador Simtricos tienen ms de un

procesador, y cada CPU tiene acceso al sistema de memoria y todos los dispositivos
adjuntos y perifricos en la mquina. Estos sistemas usualmente tienen un CPU
maestro al tiempo de inicio, y entonces el sistema operativo inicia el segundo CPU y
maneja el acceso para los recursos que estn compartido entre todos los
procesadores. Las mquinas SMP dejan a los programadores escribir ambos, tales
como multiprocesamientos y aplicaciones mutlhilos3.
1.1.2. Mquinas UMA
Estas son mquinas donde cada procesador tiene una prioridad de igual
acceso a la memoria principal, sin el arbitraje desde un procesador maestro. Esto es
usualmente acoplado por un tipo de switch.
1.1.3. Mquinas NUMA
Estn son como las mquinas UMA, los procesos no tienen restriccin al
acceso a memoria; sin embargo al contrario de las UMA no todas las partes de los
sistemas de memoria NUMA, tienen el mismo desempeo. Usualmente esto es por
que las NUMA tienen una memoria local rpida para cada CPUs y entonces un
largo, y sistema de memoria compartida lento.
Aplicaciones multihilos son como aplicaciones multitareas [multitasking aplcation] dentro de una mismo aplicacion. En trminos
de implementacin, un hilo es una funcin que corre concurrentemente con el hilo principal. Puedes correr varias instancias de
la misma funcin o puedes correr varias funciones simultneamente dependiendo de tus requerimientos.
10
1.1.4. Mquinas SIMD
Estas mquinas son nicas. Ellas estn en una clase que contienen muchos
procesadores (usualmente cientos o miles) donde el mismo programa baja las
instrucciones, es ejecutado en cada uno de los procesadores. Cada procesador sta
trabajando en una porcin de datos nica.
Las mquinas SIMD usualmente requieren memoria muy especializada y una

arquitectura de voz en orden para ser efectiva. Una de las mas famosas en est
categora SIMD fue la Conexin, construida por Thinking Machines Corp.
1.1.5. Mquinas MIMD
Por ltimo, pero no menos significativas son las MIMD. Como el nombre
implica, operan con mltiples datos e instrucciones. En esencia, las mquinas
paralelas de este tipo son mquinas individuales que por algn mecanismo
usualmente
algn
software
librera,
cooperan
para
resolver
un
problema
computacional.
Los clster son por definicin mquinas de instruccin mltiple y de datos

mltiple MIMD
1.2. SMP en contra de otras arquitecturas
Algunas personas consideran SMP (Symetric MultiProcesor) como una

arquitectura de clster muy bsica tipo compartir todo, en donde mltiples
procesadores comparten la misma memoria, sistema operativo, y otros componentes
comunes (como la red de datos y la potencia), todo en un paquete comn.
11
En trminos de la cadena de alimentacin de arquitectura de servidores, SMP

reside entre la de uniprocesador (en la parte inferior) y la de procesadores paralelos
(en lo ms alto). De hecho, implementa muchas de las ventajas de estas otras dos
arquitecturas.
En trminos del uniprocesador, la SMP presenta una visin de
memoria global y nica a las aplicaciones, y en cuanto al procesador paralelo, la

SMP coloca mltiples procesadores para trabajar en paralelo.
Existe tambin una extensin de la arquitectura SMP llamada ccNUMA

(Acceso no uniforme a la memoria, con cach coherente) ver figura 1.1.
Figura 1.1. Arquitectura SMP.
En la actualidad lo ofrecen Data General, Sequent, Convex/HP y otros, y es

una adaptacin de la arquitectura SMP que elimina muchos de los atascos y
limitaciones de canal que amenazan la escalabilidad de SMP ms all de los cuatro a
ocho procesadores que se encuentran hoy en da.
1.3. Estilos de clster
As como hay muchos tipos de computadoras para las diferentes aplicaciones,

hay tambin muchos tipos de clusters que pueden usarse para diferentes
aplicaciones. Uno de los ms comunes el clster Beowulf originalmente diseado en
la NASA era, en esencia, una red simple de estaciones de trabajo conectada por un
cable Ethernet a travs de un Hub o concentrador.
12
Desde ese primer clster,
muchas implementaciones de clusters han
experimentado con una variedad de configuraciones y han construido diferentes tipos

de clusters, cada uno con diferentes aplicaciones.
Una de las primeras cosas que se debe pensar cuando se est diseando un
clster es si ser un clster homogneo o heterogneo. Esto significa que tiene que
decidir si va a estar trabajando con mquinas o CPUs del mismo tipo o si va a tener
una variedad de mquinas. Las mquinas pueden ser nuevas, equipo obsoleto o
equipos con pocas caractersticas de hardware.
1.3.1. Clusters homogneos
Si se tienen muchos sistemas idnticos, estar construyendo un clster

homogneo. Esto significa que estar poniendo un clster en donde cada nodo es
exactamente el mismo, desde la tarjeta madre y la memoria, a las unidades de disco
y las tarjetas de red.
Los clusters homogneos son muy fciles de trabajar porque no importa de

qu manera se decida conectarlos entre s, todos sus nodos son intercambiables, y
usted puede estar seguro que todo su software trabajar de la misma manera en
todos ellos.
1.3.2. Clusters heterogneos
Los clusters heterogneos entran en dos formas generales. El primero, y ms

comn, son los clusters heterogneos hechos de diferentes tipos de computadoras.
Por ejemplo, una SUN SPARC Station IPXS, unas mquinas Intel 486, y una DEC
Alpha. No importa cual es el hardware real, excepto que hay diferentes tecnologas y
modelos. Un clster hecho de tales mquinas tendr varios detalles muy importantes
que se tendrn presentes al usar y programar el clster.
13
Otro tipo de clasificacin puede ser en base a factores diversos. Derivados de

las causas por las cuales surge el clster, existen dos tipos de clster en trminos
aplicativos:
Clusters de alto rendimiento (HPC clusters), cuya utilizacin primordial se

enfoca a aplicaciones cientficas e ingeniera donde se necesitan miles de
millones de operaciones de punto flotante (flops) .
Clusters de alta disponibilidad (HA clusters), cuyo objetivo principal es

mantener el nivel de servicio, la disponibilidad del sistema.
Adems de las anteriores, existe una clase hbrida, cuyo objetivo es mantener
alta disponibilidad y usar adicionalmente el sistema de forma paralela para obtener
un alto rendimiento. Hay diversos ejemplos de aplicaciones de clusters : a) en el
mbito cientfico para la solucin de diversos problemas, y b) en la parte comercial
para mantener sistemas de misin crtica.
1.4. Configuracin de un Clster
Hay tambin cualquier nmero de maneras para conectar un clster de

mquinas. La configuracin ms simple es la de propsito general, metodologa
usada para construir un buen sistema de cmputo paralelo. La realidad es
complicada y es la mejor para aplicaciones complejas, las cuales requieren
comparacin de datos compartidos y estratgias de comunicacin como simulacin
de tiempo.
Una de las configuraciones ms utilizada es NOW (Networks of Workstations,

Red de Estaciones de Trabajo).
14
Esta es la configuracin ms sencilla de un clster. Como se muestra en la

figura 1.2
Figura 1.2. Configuracin Bsica de un Clster
La diferencia entre una NOW y una red de computadoras, es que la red es

usada por mquinas individuales o estaciones de trabajo con un solo fin, y la Now es
usada por software clustering, como PVM o MPI, que deja a esta LAN para ser usada
efectivamente como un procesador en paralelo.
1.5. Arquitecturas de clster
Actualmente se usan dos arquitecturas principales para la conformacin de

clusters. La principal diferencia entre ellas es el modo en que los nodos tienen
acceso a los discos del clster. Una arquitectura se denomina de disco compartido o
modelo de datos compartidos (ver figura 1.3) y la otra se conoce como cero compartir
o modelo de particin de datos (ver figura 1.4).
15
Figura 1.3. Arquitectura de disco compartido.
Figura 1.4. Arquitectura de disco cero compartir.
1. Modelo de disco compartido. En este modelo el software que se ejecuta en

cualquier sistema en el clster puede tener acceso a cualquier recurso (por
ejemplo, un disco) conectado a algn sistema en el clster. Si dos sistemas
necesitan ver los mismos datos, estos ltimos se pueden leer dos veces desde
el disco o copiarse de un sistema a otro.
16
Como en un sistema SMP, la aplicacin debe sincronizar y serializar su

acceso a datos compartidos. Generalmente, se utiliza un administrador de
bloqueos distribuidos (DLM) para ayudar con sta sincronizacin. DLM es un
servicio proporcionado y destinado a las aplicaciones que rastrean referencias
para recursos a travs del clster.
Si ms de un sistema intenta hacer referencia a un solo recurso, DLM

reconocer y resolver el conflicto potencial. Sin embargo, la coordinacin
DLM puede provocar un trfico de mensaje adicional y reducir el rendimiento
debido al acceso serializado, asociado con los sistemas adicionales. Un
enfoque para reducir estos problemas es el modelo de software de "nada
compartido".
2. Modelo de nada compartido. En este modelo de software cada sistema

dentro del clster es propietario de un subgrupo de recursos del clster. Slo
un sistema puede poseer y accede a la vez a un recurso en particular, aunque
en caso de falla otro sistema determinado dinmicamente puede apropiarse
del recurso.
Adems, las solicitudes de los clientes
se enrutan
automticamente al sistema de quien pertenece el recurso.
Si la solicitud del cliente requiere acceso a los recursos que pertenecen a

diversos sistemas, se selecciona un sistema para alojar la solicitud.
El
sistema host analiza la solicitud del cliente y enva la subsolicitud a los

sistemas adecuados. Cada sistema ejecuta una subsolicitud y regresa slo a
la respuesta requerida al sistema host, el que confirma una respuesta final y la
enva al cliente. Cabe destacar que una solicitud de un sistema nico en el
sistema host describe una funcin de alto nivel (como la recuperacin de
registros de datos mltiples) que genera una gran cantidad de actividad en el
sistema (como lecturas de discos mltiples), y el trfico asociado no aparece
en la interconexin del clster hasta que se encuentran los datos finales
deseados.
17
Al utilizar una aplicacin que se distribuye en diversos sistemas en clster

(como una base de datos), el rendimiento general del sistema no se ve limitado
debido a las restricciones de hardware de una computadora.
Los modelos de "disco compartido" y de "nada compartido" se pueden

soportar dentro del mismo clster. Algunos tipos de software pueden explotar ms
fcilmente las capacidades de clster a travs del modelo de "disco compartido".
Este software incluye aplicaciones y servicios que requieren slo un acceso

moderado comparado (y de lectura intensiva) a los datos, as como aplicaciones o
cargas de trabajo que son difciles de dividir. Las aplicaciones que requieren ser
actualizadas al mximo deben utilizar el soporte de "nada compartido" del clster.
1.6. Caractersticas del clster
A lo largo de los aos, la comunidad en cmputo o desarrolladores de

sistemas operativos se han esforzado por aumentar la disponibilidad, fiabilidad y
escalabilidad de sus soluciones para servidores, razn por la cual han entrado en la
tecnologa de los clster, que ha demostrado ser una manera para la consecucin de
dichos objetivos, y la ha integrado en sus sistemas operativos. Los clster permiten
aumentar la disponibilidad, escalabilidad y fiabilidad de mltiples niveles de red.
1.7. Disponibilidad del Clster
La disponibilidad es la proporcin de tiempo en la que un sistema puede

usarse para realizar trabajo productivo. Su objetivo es mantener todos los recursos
informticos, las aplicaciones y los servicios preparados para el usuario, otro enfoque
podra ser la disponibilidad, la cual se define como el tiempo que un sistema es
capaz de proporcionar servicio a sus usuarios (esto es, tiempo disponible).
18
Se expresa como un porcentaje que representa la proporcin del tiempo que

un sistema es capaz de proporcionar servicio aceptable contra el tiempo total durante
el cual se espera que el sistema se encuentre en operacin.
En un clster ideal, la disponibilidad debera incorporar al menos tres

funciones: recuperacin automtica o manual para todos los recursos del clster;
balance automtico de carga a travs del clster del trabajo a realizar desde las
aplicaciones que han fallado y, por ltimo, un sistema de archivos.
En muchos sentidos, la ltima prueba para la funcionalidad de un clster es el

grado en el que se automatizan estas tres funciones. En otras palabras, el ndice de
implicacin de un administrador de sistemas cuando se produce un fallo.
Una medida ms comn que afecta a la mayora de los administradores es el

tiempo fuera de servicio. El tiempo fuera de servicio es la proporcin entre el tiempo
para reparar una falla grave del sistema en contra del tiempo promedio transcurrido
antes de que ocurran dichas fallas.
En Estados Unidos, el tiempo fuera de servicio le cuesta a los negocios

establecidos ms de 4 millones de dlares por ao, un costo promedio por falla que
va de cientos de miles a millones de dlares, dependiendo del tipo de negocio. No
es costoso slo en trminos de ganancias perdidas, sino porque disminuye la
productividad del trabajador, incrementa la insatisfaccin de los clientes, y eleva los
costos de soporte tcnico.
Adems, las causas de estas fallas graves varan tanto como el costo y la
mayora se relaciona con el hardware. La disponibilidad se ha convertido en el factor
nico ms importante, no slo en trminos de elegir cul arquitectura de cmputo
usar para una aplicacin particular, sino de dnde deben concentrarse las
inversiones de tecnologas de informacin ms significativas y la atencin de la
administracin.
19
La tabla 1 muestra la relacin entre la causa de la falla en contra de la

frecuencia con la que ocurre.
Tabla 1. Relacin de fallas en contra de la frecuencia.
Tipo de Falla
Causa
Frecuencia
Almacenamiento
Hardware
25 por ciento
CPU
Hardware
25 por ciento
Aplicacin o SO
Software
25 por ciento
Red
Hardware
20 por ciento
Operador
Humana
5 por ciento
Fuente : Windows NT Microsoft Clster, 1999.
La fiabilidad, que a menudo se utiliza de forma intercambiable con el concepto

de disponibilidad, mide los atributos de los componentes individuales. Para sistemas
que tienen una disponibilidad del 99 por ciento, el 1 por ciento de falta de
disponibilidad podra parecer aceptable. Sin embargo, la realidad muestra que ese 1
por ciento del tiempo representa 90 horas o aproximadamente tres das al ao.
La disponibilidad y la fiabilidad son dos conceptos que, si bien se encuentran

ntimamente relacionados, difieren ligeramente. La disponibilidad es la calidad de
estar presente, listo para su uso, a mano, accesible; mientras que la fiabilidad es la
probabilidad de un funcionamiento correcto. Pero hasta el ms fiable de los equipos
acaba fallando. Los fabricantes de hardware intentan anticiparse a los fallos
aplicando la redundancia en reas clave como son las unidades de disco, las fuentes
de alimentacin, las controladoras de red y los ventiladores, pero dicha redundancia
no protege a los usuarios de los fallos de las aplicaciones. De poco servir, por lo
tanto, que un servidor sea fiable si el software que se ejecuta en dicho servidor falla,
ya que el resultado no ser otro que la ausencia de disponibilidad. sa es la razn de
que un solo equipo no pueda ofrecer los niveles de escalabilidad, disponibilidad y
fiabilidad necesarios que s ofrece un clster.
20
1.8. Escalabilidad del Clster
La escalabilidad es un punto clave en el ambiente completo de tecnologas

de informacin cuando se considera una cantidad de usuarios que flucta
constantemente, impulsada tanto por requerimientos de temporada como por una
demanda controlada por eventos, que deben ser atendidos con eficiencia.
Las
disminuciones del rendimiento del sistema no son menos problemticas que las fallas
severas para los usuarios y los administradores y deben corregirse sin detener el
funcionamiento.
La escalabilidad se define como la capacidad de un sistema para incrementar

su potencia de cmputo mediante la adicin de procesadores o nodos (clusters)
adicionales. La adicin de estos procesadores o nodos de cmputo normalmente es
una funcin no lineal debido a la carga adicional en el sistema asociada con este
proceso.
La escalabilidad es la capacidad de un equipo para hacer frente a volmenes

de trabajo cada vez mayores sin, por ello, dejar de prestar un nivel de rendimiento
aceptable. Existen dos tipos de escalabilidad: la escalabilidad del hardware (tambin
denominada escalamiento vertical) y la escalabilidad del software (tambin
denominada escalamiento horizontal). La escalabilidad del hardware se basa en la
utilizacin de un gran equipo cuya capacidad se aumenta a medida que lo exige la
carga de trabajo existente. La escalabilidad del software se basa, en cambio, en la
utilizacin de un clster compuesto de varios equipos de mediana potencia que
funcionan en tndem de forma muy parecida a como lo hacen las unidades de un
RAID (Redundant Array of Inexpensive Disks o Array redundante de discos de bajo
costo. El trmino RAC (Redundant Array of Computers o array redundante de
equipos) se refiere a los clusters de escalamiento horizontal. Del mismo modo que se
aaden discos a un array RAID para aumentar su rendimiento, se pueden aadir
nodos a un clster para aumentar tambin su rendimiento.
21
Un clster de escalabilidad es aquel que para poder mostrar sus beneficios

requiere el desarrollo anterior de aplicaciones. De esta forma, muchos clusters
deberan gozar del nombre de clusters de escalabilidad.
Un clster de escalabilidad permite a las aplicaciones de mltiples nodos

coordinar el acceso a los datos compartidos del disco. Esencialmente, la alta
disponibilidad y la capacidad de hacer escalar las aplicaciones a travs de nodos de
clusters pueden ampliar significativamente el rendimiento de las aplicaciones.
Las tecnologas que hacen posible la existencia de estos clusters de

escalabilidad incluyen la capacidad de servicio de disco especializado: un gestor de
cierre distribuido y, generalmente, una interconexin de baja latencia y muy elevada
velocidad que soporta toda la carga de mensajes asociada a una interconexin
clster de alto rendimiento.
En trminos de conformacin de clusters, la arquitectura de cero compartir,

proporciona l ms alto grado de escalabilidad lineal disponible, en comparacin con
una arquitectura equivalente y la arquitectura de disco compartido, explicada mas
adelante. El administrador de candados distribuido (DLM) o algoritmo de control de
concurrencia, requerido por los sistemas de disco compartido para controlar mltiples
accesos al mismo archivo, aade cierto grado de carga general adicional al sistema,
lo que provoca una pequea prdida de linealidad en la escalabilidad. Se pueden
encontrar altos grados de escalabilidad en los mainframe y servidores actuales UNIX
SMP/NUMA, pero apenas comienza a emerger en el mundo de los servidores
estndar de alto volumen (SHV).
La escalabilidad es una cuestin que no slo afecta la decisin de s usar o no

clusters, sino tambin cules tipos de configuracin de procesadores usar como
nodos de clster.
22
La escalabilidad travs de multiproceso simtrico (SMP) incluye todos los

elementos de la arquitectura de un sistema, incluyendo el sistema operativo, el
hardware y el software de aplicaciones.
Ampliando SMP a travs de configuraciones clster ha demostrado ser la

mejor alternativa al eventual cuello de botella en el que incurre la escalabilidad SMP
al alcanzar las limitaciones fsicas del bus y de la velocidad de la memoria. La
agrupacin de sistemas SMP para obtener escalabilidad empezar a ser una
solucin eficaz y, eventualmente, un requisito para la mayora de los fabricantes intel
que deseen hacerse un hueco en el rea de los servidores corporativos.
1.9. Rendimiento del Clster
La tecnologa de clusters de rendimiento no solo ofrece E/S paralela de alto

rendimiento, sino que tambin aade los beneficios de una funcionalidad ms rica,
capacidades de escalabilidad ms rpidas y una mayor sencillez en la gestin de
clusters.
La posesin de amplias caractersticas que hacen que el clster parezca un

nico sistema para usuarios, aplicaciones y administradores de sistemas; la
capacidad de crear grandes configuraciones y una solucin de gestin de sistemas
simplificada.
1.10. Clustering
El clustering ofrece una solucin para los mismos problemas que los
Servidores Balanceadores de Carga (Server Load Balancing, SLB) abordan, es decir
alta disponibilidad y escalabilidad pero el clustering lo hace de manera diferente,
clustering esta altamente involucrado en un software de protocolo ejecutndose en
varios servidores que se concentran en compartir y tomar la carga, como se muestra
en la figura 1.5.
23
Figura 1.5. Un escenario clustering
En lugar de sentarse en frente de varios servidores y manipulando paquetes

de red como un dispositivo de red, clustering implica un grupo de servidores que
aceptan trfico y dividen tareas entre ellos mismos. Esto implica una firme
integracin del software del servidor.
Esto es llamado Balanceo de carga, y mientras la nomenclatura es

tcnicamente correcta, el clustering se desempea mejor en una aplicacin en los
clusters, dejando el balanceo de carga en otro nivel dentro de la red basada en
aspectos tecnologicos.
Con clustering, hay una firme integracin entre los servidores del clster, con
el software que decide cuales servidores harn que tareas y algoritmos que
determinan la carga de trabajo y que servidor hace que tarea.
24
1.11. SERVIDORES BALANCEADORES DE CARGA, SLB4
Un servidor balanceador de carga (SLB) se define como un proceso y

tecnologa que distribuye el trfico del sitio entre varios servidores usando un
dispositivo de red. Este dispositivo intercepta el trfico destinado para un sitio y
redirecciona ese trfico a varios servidores. El proceso de balanceo de carga es
completamente transparente para el usuario final. A continuacin la figura nos
muestra una esquema de SLB simplificado.
Figura 1.6. Esquema SLB simplificado
Como lo define Tony Bourke en su libro Server Load Balancing, Oreilly, Agosto 2001
25
Un balanceador de carga realiza la siguiente funciones:
Intercepta el trfico de la red destinado para un sitio.
Fracciona el trfico en peticiones individuales y decide cual servidor recibe

la peticin.
Mantiene un monitoreo en los servidores disponibles, asegurndose que

ellos estn respondiendo al trfico. Si ellos no estn funcionando, son
sacados de la rotacin.
Provee redundancia empleando ms de una unidad en un escenario a

prueba de fallos.
Ofrece distribucin de contenidos, haciendo cosas como leyendo urls,

interceptando cookies, y analizando cdigo xml.
SLB tiene 3 beneficios principales que son: flexibilidad, alta disponibilidad y

escalabilidad.
1.11.1. Flexibilidad
El SLB permite agregar y remover servidores a un sitio en cualquier momento,

y el efecto es inmediato, esto deja que para el mantenimiento de cualquier mquina,
aun durante horas pico o demasiado trafico esto tenga un impacto muy pequeo o
nulo al sitio al momento de eliminar una mquina. Un balanceador de carga puede
tambin dirigir el trfico inteligentemente usando cookies, anlisis de url, algoritmos
estticos, dinmicos, y muchas cosas mas.
1.11.2. Alta disponibilidad.
SLB puede verificar el estado de los servidores disponibles, toma cualquiera

de los servidores que no respondan fuera de la rotacin, y los pone en rotacin
cuando estn funcionando otra vez. Esto es automtico, no requiriendo intervencin
por el administrador.
26
Tambin los balanceadores de carga usualmente vienen en una configuracin

redundante, empleando mas de una unidad en caso de que cualquier unidad falle.
1.11.3. Escalabilidad
Desde que el SLB distribuye la carga entre muchos servidores, todo lo que es
necesario para incrementar el poder de servicio de un sitio es agregar mas
servidores. Esto puede ser muy econmico, desde servidores muy pequeos y
tamao medio, pueden ser mucho menos caro que un poco de servidores de alto
desempeo. Tambin cuando un sitio incrementa su carga, los servidores pueden
ser dados de alta inmediatamente para manejar el incremento del trafico.
1.11.4. Componentes de Servidores Balanceadores de Carga
Un balanceador de carga es un dispositivo que distribuye la carga entre varias

mquinas. Como se discuti anteriormente, esto tiene el efecto de hacer que varias
mquinas parezcan como una. Existen varios componentes de SLB, como a
continuacin se describen
1.11.4.1. VIPS IP Virtual
Virtual IP es la instancia balanceadora de carga donde el mundo seala a sus

browsers (examinadores) para llegar a un sitio. Un VIP tiene una direccin IP, que
debe ser disponible pblicamente para poder ser usada, usualmente un nmero de
puerto TCP o UDP est asociado con el VIP, como un puerto TCP 80 para el trfico
de WEB.
Un VIP tendr al menos un servidor real asignado para el, el cual distribuir el
trfico. Usualmente hay mltiples servidores reales, y el VIP extender el trfico entre
ellos usando mtodos y algoritmos mtricos.
27
1.11.4.2. Servidores
Un servidor en un dispositivo corriendo un servicio que comparte la carga

entre otros servicios. Un servidor tpicamente hace referencia en un servidor HTTP,
aunque otro o incluso mltiples servicios sern tambin relevantes, un servidor tiene
una direccin IP y usualmente un puerto TCP/UDP asociado con l y no tiene que
ser pblicamente direccionable.
1.11.4.3. Grupos
Mientras que el trmino grupo es a menudo usado por los vendedores para
indicar varios conceptos diferentes, este documento se refiere a un grupo de
servidores que estn siendo balanceados de carga. E trmino comunidad (farm) o
comunidad de servidores (server-farm) tambin se aplica para este concepto.
1.11.4.4. Nivel de acceso de usuario
Un nivel de acceso a usuario se refiere a la cantidad de control que un usuario

en particular tiene cuando accesa a un balanceador de carga, diversos vendedores
se refieren no slo a sus niveles de acceso, sino que la mayora emplea varios
mtodos de nivel de acceso. El mas popular es el estilo de usuario Cisco y permite
cuentas de superusuario. Otro mtodo popular es el mtodo Unix del tipo de acceso
de nivel de usuario.
1.11.5. REDUNDANCIA
Redundancia como un concepto es simple, si uno de los dispositivos falla, otro

tomar su lugar y funcin, con un impacto muy pequeo o nulo en sus operaciones
como un hoyo. Casi todos los productos de balanceadores de carga en el mercado
tienen esta caracterstica.
28
Existen varias maneras para lograr esta caracterstica. Tpicamente dos

dispositivos son implementados, un protocolo es usado por un dispositivo para
verificar el estado de su compaero. en algunos escenarios, ambos dispositivos son
activados y aceptan trfico, mientras en otros, solo un dispositivo es usado mientras
el otro espera en caso de falla.
1.11.5.1. Roles de redundancia
En redundancia, hay a menudo una relacin activo-en-espera. Una unidad

conocida como la unidad activa, acepta algunas funciones, mientras que la otra, la de
espera (stanby), espera para aceptar estas funciones, esto es tambin llamado
relacin maestro/esclavo.
En ciertos escenarios, ambas unidades pueden ser maestros de algunas estas

funciones y esclavos de otras, para distribuir la carga, en otros casos ambos son
maestros de todas las funciones, compartindolas entre los dos, esto se conoce
como redundancia activa-activa.
1.11.5.2. Escenario Redundancia, Activo-en espera
El escenario redundancia activo-en-espera es el ms fcil de entender e

implementar. un dispositivo toma el trfico mientras el otro espera en caso de falla.
Como se muestra a continuacin en la figura 1.7.
29
Figura 1.7. Escenario Redundancia, Activo-en espera.
Si la segunda unidad fallara, el otro dispositivo tiene alguna manera de

determinar esa falla y toma el trfico pasante como se muestra en la figura 1.8:
Figura 1.8. Escenario Fuera de Fallos, Activo-en espera.
30
1.11.5.3. Escenario Redundancia, Activo-Activo
Existen diferentes variaciones de un escenario activo-activo, en todos los

casos, sin embargo ambas unidades aceptan trfico. En caso de que uno de los
dispositivos fallara, el otro toma las funciones de la unidad fallida. En una variacin,
las VIP son distribuidas entre los dos balanceadores de carga para compartir el
trfico entrante. VIP1 va hacia el balanceador de carga A y el VIP2 para el
balanceador B como muestra la figura 1.9.
Figura 1.9. Escenario Redundancia, Activo-Activo.
En otra variacin, ambos VIP responden en ambos balanceadores de carga,

con un protocolo engaando la restriccin que dos balanceadores no pueden tener la
misma direccin IP como se muestra a continuacin en la figura 1.10:
31
Figura 1.10. Escenario Variacin de Redundancia, Activo-Activo.
Como en todos los escenarios activo-activo, si un balanceador de carga falla

el VIP continuar para responder en el que falta. La otra unidad toma todas las
funciones como se muestra a continuacin en la figura 1.11:
Figura 1.11. Escenario Fuera de Fallos Recuperable, Activo-Activo.
32
1.11.5.4. Protocolo Virtual de Redundancia del Enrutador (VRRP)
Quizs el protocolo ms comn de redundancia es el protocolo virtual de

redundancia del enrutador (VRRP). Este es un estndar abierto, y los dispositivos
que estn exigiendo soporte VRRP conforman las especificaciones puestas en el
RFC 23385.
Cada unidad en parejas enva paquetes para ver si el otro dispositivo

responde, si la unidades enviadas no reciben una respuesta de su compaero,
entonces la unidad asume que su compaero est inhabilitado y comienza a tomar el
control sobre las funciones de cualquiera.
Mientras que no es necesario conocer los trabajos internos de el protocolo

VRRP, algunos detalles podran ser de utilidad. VRRP usa el puerto 1985 y enva
paquetes para la direccin de difusin 225.0.0.2. Estos detalles son tiles cuando se
trata con algn tipo de filtrado-ip o dispositivos firewalls.
VRRP requiere que las dos unidades sean capaces de comunicarse entre si,
si las dos unidades se aislaran, cada una asumira que la otra unidad est apagada y
toma el estado de maestro, esta circunstancia puede causar serios problemas en la
red por los conflictos de direccin IP y otros problemas de red que ocurren cuando
las dos unidades piensan que ambas unidades estn activas en un escenario activoen-espera.
http://www.faqs.org/rfcs/rfc2338.html
33
1.11.5.5. Cable fuera de fallos
Otro mtodo para detectar unidades en estado de fallos, entre un par de

dispositivos esta provisto por un cable fuera de fallos. Este mtodo usa un protocolo
de verificacin de pulsos, "heartbeat", que funciona en una lnea serial entre un par
de balanceadores de carga.
Si este cable fuera de fallos est desconectado, causa que ambas unidades
crean que ellas son las nicas unidades disponibles, y cada uno toma el estado de
maestro. Esto, como con el escenario VRRP, puede causar serios problemas en la
red.
El Spaning Tree Protocol (STP6) es un protocolo para la capa 2 del modelo
OSI (Open System Interconexin Interconexin de Sistemas Abiertos)7, esto evita
entrar en un ciclo. STP pone una prioridad para un puerto dado, y cuando las
mltiples rutas existen para el trfico, solo el puerto de prioridad alta se deja activo,
con el resto apagado administrativamente.
1.11.5.6. Estado fuera de fallos
Uno de los problemas que un escenario presenta es cuando un dispositivo

falla, todas las conexiones activas TCP son reiniciadas y la informacin del nmero
de secuencia TCP se pierde, con resultados de error en la red desplegados en el
navegador. Si se emplea alguna forma de persistencia, esa informacin ser
reiniciada tambin. Algunos vendedores han empleado una caracterstica conocida
como estado fuera de fallos, que deja la sesin y la informacin persistente en
ambas unidades tanto en la activa y la de espera. Si la unidad activa falla, entonces
la unidad en espera tendr toda la informacin y el servicio estar sin interrupciones
si se hace correctamente, y el usuario final no notar nada.
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm
34
1.11.5.7. Persistencia
Persistencia es el acto de dejar que el trfico de un usuario especifico vaya al

mismo servidor que fue inicialmente solicitado, mientras el dispositivo SLB quiz
tenga varias mquinas para elegir, siempre mantendr el trafico de un usuario en
particular dirigindose al mismo servidor. Esto es especialmente importante en una
aplicacin tienda-web, donde un usuario llena su carrito de compras, y la informacin
puede solo ser almacenada en una mquina en particular. Estas son varias maneras
de implementar persistencia, con sus ventajas y desventajas.
1.11.5.8. Verificacin de servicios
Una de las tareas de un dispositivo SLB es reconocer cuando un servidor o

servicio no est funcionando y tomar ese servidor fuera de rotacin. Tambin
conocido como comprobacin de estado esto puede ser realizado de numerosas
maneras, puede ser algo tan simple como un ping, una verificacin de puerto, o
incluso una revisin de contenido, en el cual el servidor web es solicitado para una
respuesta
especifica.
Un
dispositivo
SLB
continuamente
ejecutar
estas
verificaciones de servicio, usualmente en intervalos definidos por el usuario.
1.11.5.9. Algoritmos de balanceo de carga
Dependiendo de sus necesidades especificas, existen varios mtodos de

distribucin de trfico entre un grupo de servidores usando una medida dada estos
son algoritmos matemticos programados en un dispositivo SLB. Estos pueden
ejecutar un inicio y en conjuncin con cualquiera de los mtodos persistentes,
tambin estos son asignados a VIPs individuales.
http://www.iso.org/iso/en/ISOOnline.frontpage
35
Captulo II Plataformas de Desarrollo
CAPTULO II. PLATAFORMAS DE DESARROLLO
Hay un gran nmero de maneras de configurar un clster de computadoras.

Los ms simples son las metodologas de uso general para hacer un sistema sencillo
de computacin en paralelo; los muy complicados son mejores para aplicaciones
muy complejas que requieren compartir datos complicados y estrategias de
comunicacin. En este capitulo se mencionaran las dos plataformas o sistemas
operativos en donde podemos construir o configurar un clster.
2.1. Sistema Operativo Windows 20001.
El Servicio de clster server, que se dise originalmente para el sistema

operativo windows NT server 4.0, se ha adaptado y mejorado para el sistema
operativo windows 2000 Server. El servicio de clster server permite la conexin de
varios servidores clusters, con lo que se proporciona alta disponibilidad y fcil
administracin de los datos y programas que se ejecutan en el clster. El servicio de
clster server proporciona tres ventajas principales de la tecnologa de clster:
Disponibilidad mejorada al permitir que los servicios y aplicaciones del clster

de servidores continen en servicio aunque se produzca un error en un
componente de hardware o de software, o durante el tiempo necesario para
tareas de mantenimiento.
Aumento de la escalabilidad al admitir servidores que se pueden expandir si

se agregan varios procesadores.
Administracin mejorada al permitir que los administradores gestionen los

dispositivos y recursos de todo el clster como si estuvieran administrando un
nico equipo.
http://www.microsoft.com/NTServer/Support/faqs/clustering_faq.asp#basics
36
El servicio de clster server es una de las dos tecnologas de clster

complementarias para windows que constituyen una extensin de los sistemas
operativos bsicos windows 2000 y windows NT. La otra tecnologa de clster,
equilibrio de la carga en la red, complementa al servicio de clster server al
proporcionar compatibilidad con clusters de gran disponibilidad y escalabilidad para
aplicaciones y servicios de cliente, por ejemplo sitios de Internet o de intranet,
aplicaciones basadas en web y los servicios de terminal server de microsoft.
2.1.1. Terminologa de Clusters
El servicio de clster server es el nombre que recibe en windows 2000 la

tecnologa de microsoft que se llam originalmente microsoft clustering server
(MSCS) en windows NT server 4.0, edicin empresarial. Al hacer referencia a los
componentes que forman un clster, cada equipo individual se denomina nodo o
sistema. servicio de clster server hace referencia al conjunto de componentes clave
de cada nodo que realiza la actividad especfica de clster y los recursos son los
componentes de hardware y software del clster que administra el servicio de clster
server. Se dice que un recurso est conectado cuando est disponible y
proporcionando servicio al clster.
Entre los recursos se incluyen los dispositivos de hardware fsicos, como

unidades de disco y tarjetas de red, o los elementos lgicos como direcciones de
protocolo de internet (IP), aplicaciones completas y bases de datos de aplicaciones.
Un grupo de recursos es un conjunto de recursos administrado por el servicio de
clster server como una nica unidad lgica.
Contiene todos los elementos que necesitan un servidor de aplicaciones y un
cliente especfico para poder utilizar la aplicacin correctamente. Cuando una
operacin del servicio de clster server se lleva a cabo en un grupo de recursos, la
operacin afecta a todos los recursos incluidos en el grupo.
37
2.1.2. Clusters de Servidores
El modelo utilizado para disear el servicio de clster server se bas en un

modelo compartir nada de arquitectura de clster, este modelo sera un tema aparte
de cmo configurar la informacin del clster.
El servicio de clster server admite conexiones SCSI basadas en PCI

estndar, incluso SCSI sobre canal de fibra y bus SCSI con mltiples sistemas de
inicio.
Las conexiones de canal de fibra son dispositivos SCSI, simplemente

albergadas en un bus de canal de fibra en lugar de un bus SCSI. Conceptualmente,
la tecnologa canal de fibra encapsula los comandos SCSI en los comandos de canal
de fibra y SCSI de los que depende el servicio de clster server, como reservar /
liberar y reinicializacin del bus. Estos comandos funcionan igual que el SCSI
estndar.
En la figura 2.1 se muestran los componentes de un clster de servidores de

dos nodos que puede constar de dos servidores en los que se ejecutan windows
2000 advanced server o windows NT server 4.0 edicin empresarial con conexiones
de dispositivos de almacenamiento compartidas mediante SCSI o SCSI sobre un
canal de fibra.
38
Figura 2.1. Clster de servidores de dos nodos que ejecuta Windows 2000 Advanced Server
Windows NT Server 4.0 edicin empresarial
Windows 2000 datacenter server admite clusters de cuatro nodos y

conexiones de dispositivo que utilizan conmutadores de canal de fibra . La figura 2.2
muestra los componentes de un clster de cuatro nodos.
Figura 2.2. Clster de servidores de cuatro nodos que ejecuta Windows 2000 Datacenter Server}
39
2.1.3. Servidores Virtuales
Las aplicaciones y servicios que se ejecutan en un nodo del clster de

servidores se exponen a los usuarios y estaciones de trabajo como servidores
virtuales. Ante los usuarios y los clientes, la conexin a una aplicacin o servicio que
se est ejecutando en un clster de servidores parece ser un proceso idntico a la
conexin a un nico servidor fsico. De hecho, la conexin se efecta con un servidor
virtual, que puede estar alojado en cualquier nodo del clster.
Las aplicaciones que se ejecutan en todos los nodos de un clster se

representan y administran en el servicio de clster server como un nico servidor
virtual. Como se ilustra en la figura 2.3, en un clster pueden estar alojados mltiples
servidores virtuales que representan a varias aplicaciones.
Figura 2.3. Vista fsica de los servidores virtuales en el Servicio de Cluster Server
Las conexiones del cliente de la aplicacin con el servidor virtual en una red
TCP/IP se realizan mediante una sesin del cliente que slo conoce la direccin IP
publicada por el servicio de clster server como direccin del servidor virtual. El
servicio de clster server administra la direccin IP como un recurso perteneciente a
un grupo de recursos de aplicaciones. La vista que tiene el cliente del servidor virtual
se muestra en la figura 2.4:
40
Figura 2.4. Vista del cliente de los servidores virtuales del Servicio de Cluster Server
Si se produce un error en la aplicacin o en el servidor, el servicio de clster

server mueve todo el grupo de recursos a otro nodo del clster. En caso de error, el
cliente detectar un error en su sesin con la aplicacin y tratar de volver a
conectarse exactamente igual que en la conexin original.
Como el servicio de clster server simplemente vuelve a asignar la direccin

IP del servidor virtual a otro nodo del clster que siga funcionando, la sesin del
cliente puede restablecer la conexin con la aplicacin sin necesidad de saber que
ahora la aplicacin est alojada en otro nodo del clster.
Es importante observar que, aunque as se obtiene una alta disponibilidad de

la aplicacin o el servicio, se pierde toda la informacin relativa a la sesin original.
Es decir, el servicio de clster server permite una alta disponibilidad pero no
proporciona tolerancia a los errores de la aplicacin. Para que se produzca la
tolerancia a errores, la aplicacin debe utilizar la lgica de transacciones para
garantizar que los datos del cliente se confirman en la base de datos del servidor
mediante semntica tolerante a errores.
41
2.1.4. Grupos de recursos
Los servidores virtuales del servicio de clster server son grupos de recursos.
Un grupo de recursos slo puede pertenecer a un nodo en un momento dado y cada
uno de los recursos del grupo debe encontrarse en el nodo al que pertenece el grupo
en ese momento. En cualquier momento determinado, los distintos recursos del
mismo grupo no pueden pertenecer a diferentes servidores del clster.
Cada grupo tiene asociada una poltica para todo el clster que especifica el
servidor preferido para ejecutar el grupo y el servidor al que se debe mover el grupo
en caso de error. Cada grupo tiene tambin un nombre de servicio de red y una
direccin propia que los clientes de red utilizan para enlazarse con los servicios que
ofrece el grupo de recursos. En caso de error, los grupos de recursos se pueden
migrar tras error o mover como unidades atmicas desde el nodo en el que se ha
producido el error a otro que est disponible en el clster.
2.1.5. Arquitectura del Servicio de Cluster Server
El servicio de clster server est diseado como un conjunto de componentes

independiente y aislado que funciona con el sistema operativo. Con este diseo se
evita introducir complejas dependencias de programacin del sistema de
procesamiento entre el servicio de clster server y el sistema operativo. No obstante,
fue necesario hacer ciertos cambios en el sistema operativo bsico para habilitar las
caractersticas de los clusters. Entre estos cambios se incluyen los siguientes:
Compatibilidad con la creacin y eliminacin dinmicas de nombres y

direcciones de red.
Modificacin del sistema de archivos para poder cerrar los archivos abiertos
mientras se desmontan las unidades de disco.
Modificacin del subsistema de E/S para habilitar el uso compartido de discos

y conjuntos de volmenes entre mltiples nodos.
42
Aparte de los cambios anteriores y otras pequeas modificaciones, las

capacidades de clster del servicio de clster server se basan en los fundamentos
existentes de los sistemas operativos Windows 2000 y Windows NT.
2.1.6. Cuatro soluciones de clster de windows

Microsoft ha desarrollado cuatro soluciones bsicas de clster: Microsoft
Cluster Services (MSCS), Network Load Balancing (NLB), Component Load
Balancing (CLB) y Application Center 2000 (AppCenter). Estas soluciones se
comercializan en forma de tres productos: MSCS, NLB y AppCenter. CLB forma
parte de AppCenter y slo se puede adquirir junto con este producto. NLB se puede
utilizar tanto en unin de AppCenter como por separado. Tanto Windows 2000
Advanced Server (W2000 AS) como Windows 2000 Datacenter Server (Datacenter)
incluyen MSCS y NLB, pero no AppCenter, que debe adquirirse por separado.
TABLA 2. Tecnologas de clster compatibles con las distintas versiones de sistemas

operativos.
MSCS
NLB
CLB
AppCenter
No disponible
No disponible
Compatible (requiere
AppCenter)
Compatible (precisa un
repartidor de carga IP de
una tercera marca)
W2000 AS
Incluido (mximo 2
nodos)
Incluido
Compatible (requiere
AppCenter)
Compatible (utiliza NLB)
Datacenter
Incluido (mximo 4
nodos)
Incluido
Compatible (require
AppCenter)
Compatible (utiliza NLB)
No disponible
Compatible (denominado
WLBS)
No disponible
No disponible
Compatible (mximo 2
nodos)
Compatible (denominado
WLBS)
No disponible
No disponible
W2000 Server
NT Server 4.0
NT Server 4.0, Enterprise
Edition
La Tabla 2. muestra cules de estas cuatro tecnologas se encuentran disponibles en

los distintos productos de las familias Windows 2000 Server (W2000 Server) y
Windows NT Server 4.0. Como es lgico, ninguna de estas tecnologas se pueden
utilizar con Windows 2000 Professional (W2000 Pro) ni con Windows NT Workstation
4.0.
43
La Tabla 3 muestra, por su parte, algunas de las caractersticas que presentan

estas tecnologas de clster..
TABLA 3. Prestaciones ofrecidas por las distintas tecnologas de clster.

MSCS
NLB
CLB
AppCenter
Funcin
Failover y failback de
aplicaciones
Reparto de carga del

trfico IP
Reparto de carga de
objetos COM+
Creacin y administracin
de granjas web
Ventajas
Disponibilidad y
administrabilidad
Disponibilidad y
escalabilidad
Disponibilidad y
escalabilidad
Disponibilidad,
escalabilidad y
administrabilidad
Nmero mximo de
nodos por clster
2 para W2000 AS
32
4 para Datacenter
16
16
Almacenamiento
compartido
Nada compartido
Nada compartido
Nada compartido
Stateful
Stateless (admite
conexiones stateful en
caso necesario)
Stateless
Stateless
Es necesario modificar
la aplicacin del servidor?
No
No
No
Es necesario disponer
de hardware
especializado?
No
No
No
Es autnoma?
No (requiere appCenter)
Tipo de clster
Informacin sobre el
estado
44
2.2. Sistema Operativo Linux

Linux es un sistema operativo, compatible con Unix2 en algunos aspectos. Dos
caractersticas muy peculiares lo diferencian del resto de los sistemas que podemos
encontrar en el mercado, la primera, es que es libre, esto significa que no tenemos
que pagar ningn tipo de licencia a ninguna casa desarrolladora de software por el
uso del mismo, la segunda, es que el sistema viene acompaado del cdigo fuente.
El sistema lo forman el ncleo del sistema (Kernel) mas un gran nmero de
programas / libreras que hacen posible su utilizacin.
Linux se distribuye bajo la GNU Public License3, por lo tanto, el cdigo fuente
tiene que estar siempre accesible. El sistema ha sido diseado y programado por
una multitud de programadores alrededor del mundo. El ncleo del sistema sigue en
continuo desarrollo bajo la coordinacin de Linus Torvalds4, la persona de la que
parti la idea de este proyecto, a principios de la dcada de los noventa.
Da a da, ms programas y aplicaciones estn disponibles para este sistema,

y la calidad de los mismos aumenta de versin a versin. La gran mayora de los
mismos vienen acompaados del cdigo fuente y se distribuyen gratuitamente bajo
los trminos de licencia de la GNU Public License.
En los ltimos tiempos, ciertas casas de software comercial han empezado a

distribuir sus productos para Linux y la presencia del mismo en empresas aumenta
rpidamente por la excelente relacin calidad-precio que se consigue con Linux.
Las computadoras que en un principio se puede utilizar Linux son 386, 486.
pentium, pentium pro, pentium II, amiga y atari, tambin existen versiones para su
utilizacin en otras maquinas como alpha, ARM, MIPS, powerPC y SPARC.
http://vertigo.hsrl.rutgers.edu/ug/unix_history.html
http://www.gnu.org/home.html
4
http://hackers.com.mx/cultura/hall/torvals/
3
45
2.2.1. Cluster BEOWULF 5 , Pionero de los clusters
En el verano de 1994 Thomas Sterling y Don Becker, trabajando en CESDIS

(Center of Excellence in Space Data and Information Sciencies) bajo el patrocinio del
Proyecto de la Tierra y Ciencias del Espacio (ESS), construyeron un clster de
computadoras que consista en 16 procesadores DX4 conectadas por un canal
Ethernet a 10Mbps. Ellos llamaron a su mquina Beowulf. La mquina fue un xito
inmediato y su idea de proporcionar sistemas basados en COTS (equipos de
sobremesa) para satisfacer requisitos de cmputo especficos se propag
rpidamente a travs de la NASA y en las comunidades acadmicas y de
Investigacin. El esfuerzo del desarrollo para sta primera mquina creci
rpidamente en lo que ahora llamamos el proyecto de Beowulf.
2.2.1.1. Evolucin de la Arquitectura del Sistema Beowulf
Los Beowulf se distinguen de otros sistemas de clusters, en que no imponen

una arquitectura del sistema.
Los componentes primarios del sistema que manejan la arquitectura se

pueden descomponer en el procesador, memoria, red de trabajo y sistema de
almacenamiento secundario. Pero el procesador y la red de trabajo han tenido el
impacto ms visible en los cambios de la arquitectura Beowulf.
El poder de procesamiento fue un factor dominante en el desempeo inicial de

los sistemas Beowulf. La aparicin sucesiva de generaciones de hardware, hicieron
que el procesador disminuyera su impacto en el funcionamiento total del sistema. El
ancho de banda de memoria ahora ha reemplazado el rol del procesador como un
cuello de botella del funcionamiento. La red de trabajo siempre ha sido un factor
limitante desde los primeros das.
http://www.beowulf.org/
46
Sin embargo, la red de trabajo todava impone un lmite estricto en el

escalamiento de los sistemas Beowulf. Una vez que se mueve entre los 100 y 200
nodos, la red de trabajo fcilmente se satura.
La disponibilidad de compra de la Ethernet de 1 Gbps eliminar este

problema, y permitir escalar a un gran nmero de nodos para aplicaciones que
puedan incorporar mucho paralelismo.
Otro componente dominante para remitir compatibilidad, es el software del

sistema usado en Beowulf. Con la madurez y la robustez de Linux, el software GNU y
de la estandarizacin de envo de mensajes va PVM (Parallel Virtual Machine)6 y
MPI ( The Message Passing Interface Standard ) 7, los programadores ahora tienen
una garanta que los programas que escriban corrern en un futuro en un clster
Beowulf sin importar quien hace los procesadores o las redes de trabajo.
El primer Beowulf fue construido para tratar un requisito de cmputo

determinado de la comunidad de ESS. Se construy para el investigador con
experiencia en programacin paralela.
Muchos de estos investigadores han pasado aos luchando con los

vendedores de MPP, y administradores de sistemas sobre la informacin detallada
del funcionamiento y luchando con las herramientas subdesarrolladas y nuevos
modelos de programacin.
Ms all del programador de un sistema en paralelo, el clster Beowulf ha sido

construido y usado por programadores con poca o nula experiencia en programacin
paralela. De hecho, el clster Beowulf provee, con recursos limitados, una excelente
plataforma para ensear cursos de programacin paralela y provee un costo efectivo
de cmputo a sus cientficos computacionales.
6
7
http://csep1.phy.ornl.gov/CSEP/PVM/PVM.html
http://www-unix.mcs.anl.gov/mpi/
47
En la taxonoma de las computadoras paralelas, el clster Beowulf cae en

alguna parte entre MPP (Procesadores Masivamente Paralelos, como nCube, CM5,
Convex SPP, Cray T3D, Cray T3E, etc.) y NOWs (Network of Workstation - Red de
Estaciones de Trabajo). El proyecto Beowulf se beneficia del desarrollo de ambas
clases de arquitectura.
2.2.2. MOSIX
Mosix es una herramienta desarrollada para sistemas tipo UNIX, cuya

caracterstica resaltante es el uso de algoritmos compartidos, los cuales estn
diseados para responder al instante a las variaciones en los recursos disponibles,
realizando el balanceo efectivo de la carga en el cluster mediante la migracin
automtica de procesos o programas de un nodo a otro en forma sencilla y
transparente.
El uso de Mosix en un cluster de PC's hace que ste trabaje de manera tal,
que los nodos funcionan como partes de un solo computador. El principal objetivo de
esta herramienta es distribuir la carga generada por aplicaciones secuenciales o
paralelizadas.
Una aproximacin de balanceo de carga es realizada por los usuarios a la

hora de asignar los diferentes procesos de un trabajo paralelo a cada nodo, habiendo
hecho una revisin previa de forma manual del estado de dichos nodos.
Los paquetes utilizados generalmente para tal labor son PVM y MPI. Este tipo
de software, dispone de herramientas para la asignacin inicial de procesos a cada
nodo, sin considerar la carga existente en los mismos ni la disponibilidad de la
memoria libre de cada uno. Estos paquetes corren a nivel de usuario como
aplicaciones ordinarias, es decir son incapaces de activar otros recursos o de
distribuir la carga de trabajo en el cluster dinmicamente.
48
La mayora de las veces es el propio usuario el responsable del manejo de los

recursos en los nodos y de la ejecucin manual de la distribucin o migracin de
programas. A diferencia de estos paquetes, Mosix realiza la localizacin automtica
de los recursos globales disponibles y ejecuta la migracin dinmica `òn line'' de
procesos o programas para asegurar el aprovechamiento al mximo de cada nodo.
2.2.2.1. Tipos de configuracin de un Clster Mosix
Para configurar un clster MOSIX como una comunidad de Servidores o un

conjunto de estaciones de trabajo existen diferentes maneras de configurar como se
menciona a continuacin :
o Single-pool. Todos los servidores y estaciones de trabajo son usados como

un solo clster. Aqu se instala el mismo mosix.map, parte elemental del
clster mosix, en todas las computadoras, con el mismo IP addresses para
todas las computadoras. La ventaja de este tipo es que las estaciones de
trabajo son parte de la comunidad del clster
o Server-pool. Los servidores son compartidos mientras que las estaciones de

trabajo no son parte del Clster. Aqu se instala el mismo mosix.map en todos
los servidores, con el mismo IP addresses solo en los servidores. La
desventaja de este tipo es que los procesos remotos no pueden ser movidos a
la estacin de trabajo, necesita entrar a uno de los servidores para usar el
clster.
o Adaptive-pool. Los servidores son compartidos mientras las estaciones de

trabajo entran o dejan el clster. Aqu se instala el mismo mosix.map en todas
las computadoras, con el mismo IP addresses para todos los servidores y
estaciones de trabajo, entonces se usa un simple script, para decidir si MOSIX
debe ser desactivado o activado. La ventaja de este tipo es que el proceso
remoto puede ser usado cuando no se este usando la estacin de trabajo.
49
2.2.3. Software de programacin para el clster.
Otro punto importante que debemos saber es que los cluster manejan dos
sistemas de programacin paralela que son PVM (Parallel Virtual Machine)8 y MPI (
The Message Passing Interface Standard)9, por medio de la estandarizacin de
envo de mensajes.
2.2.3.1. Parallel Virtual Machine PVM
El proyecto PVM comenz en el verano de 1989 en el Oak Ridge National

Laboratory. El prototipo del sistema PVM 1.0 fue construido por Vaidy Sunderam y
Al Geist; esta versin fue usada internamente en el laboratorio y no fue liberada al
pblico. La versin 2 de PVM fue escrita en la Universidad de Tennessee y liberada
en marzo de 1991. Durante los siguientes aos, PVM comenz a ser usado para
muchas aplicaciones cientficas. Despus de una serie de cambios (PVM 2.1-2.4), y
la retroalimentacin de los usuarios, se dio lugar a una reescritura completa del
cdigo. Finalmente, la versin 3 fue concluida en febrero de 1993.
PVM provee una estructura unificada dentro de la cual los programas en

paralelo pueden ser desarrollados en forma eficiente y directa utilizando hardware ya
adquirido anteriormente. PVM permite que una coleccin de sistemas de cmputo
heterogneos pueda ser vista como una sencilla mquina virtual paralela.
PVM
maneja transparentemente el ruteo de todos los mensajes, conversin de datos y

calendarizacin de tareas a travs de una red de arquitecturas incompatibles.
PVM est diseado para unir recursos de cmputo y proveer a los usuarios de
una plataforma paralela para ejecutar sus aplicaciones, independientemente del
8
8
http://csep1.phy.ornl.gov/CSEP/PVM/PVM.html
http://www-unix.mcs.anl.gov/mpi/
50
nmero de computadoras distintas que utilicen y de dnde se encuentren

localizadas.
Cuando PVM est instalado correctamente, es capaz de enlazar los recursos

combinados de plataformas conectadas en red, tpicamente heterogneas, para
proporcionar altos niveles de desempeo y funcionalidad.
El modelo computacional de PVM es simple y adems muy general.
La
interface de programacin es deliberadamente directa por lo que permite que

estructuras simples del programa sean implementadas de una manera intuitiva. El
usuario escribe su aplicacin como una coleccin de tareas cooperativas. Las tareas
tienen acceso a los recursos de PVM a travs de una biblioteca de rutinas de interfaz
estndar. Estas rutinas permiten la inicializacin y terminacin de tareas a travs de
la red, as como la comunicacin y sincronizacin entre tareas. Las primitivas de
envo de mensajes de PVM estn orientadas a operaciones heterogneas incluyendo
constructores fuertemente representados para la transmisin y almacenamiento
temporal.
Los constructores de comunicacin incluyen aquellos para envo y
recepcin de estructura de datos, as como primitivas de alto nivel tales como

emisin, barreras de sincronizacin y sumas globales.
En PVM las tareas pueden poseer un control arbitrario y estructuras

dependientes. En otras palabras, en algn punto en la ejecucin de una aplicacin
concurrente, alguna tarea puede iniciar o detener otras tareas o agregar o eliminar
computadoras de la mquina virtual.
Algunos procesos pueden comunicarse y/o
sincronizarse con cualquier otro. Algn control especfico y estructura dependiente

puede ser implementada bajo PVM mediante el uso apropiado de constructores del
mismo y declaraciones de control de flujo del lenguaje de la mquina anfitrin.
PVM es un conjunto integrado de herramientas de software y bibliotecas que

emulan una estructura concurrente de propsito general, flexible y heterogneo en
51
computadoras con distintas arquitecturas interconectadas a travs de una red de

comunicacin.
El principal objetivo de PVM es el permitir a tal coleccin de computadoras ser

usada cooperativamente en cmputos concurrentes o paralelos.
Algunos de los
principios en los cuales est fundamentado PVM son los siguientes:
Conjunto de hosts configurado por el usuario: Las tareas de las aplicaciones

se ejecutan en un conjunto de mquinas que son seleccionadas por el usuario
para una ejecucin dada de PVM. Tanto mquinas con un solo CPU, como
multiprocesadores (incluyendo computadoras de memoria compartida y de
memoria distribuida) pueden ser parte del conjunto de hosts.
El conjunto
puede ser alterado ya sea agregando o quitando mquinas durante la

ejecucin (lo cual es una caracterstica importante para la tolerancia a fallas).
Acceso transparente al hardware: Las aplicaciones pueden elegir explotar las

capacidades de una mquina en especfico en el conjunto, colocando ciertas
tareas en las computadoras ms apropiadas, es decir, se puede indicar a PVM
si existe, por ejemplo, un multiprocesador para que se ejecuten en este la
mayora de las tareas.
Cmputo basado en procesos: La unidad de paralelismo en PVM es una tarea

(algunas veces, pero no siempre, un proceso Unix). El mapeo de proceso a
procesador no es implicado o forzado por PVM; en particular, mltiples tareas
pueden ejecutarse en un solo procesador.
Modelo explcito de envo de mensajes: Existen colecciones de tareas, cada

una realizando una parte de la carga de trabajo de una aplicacin, utilizando
descomposicin de datos, descomposicin funcional o descomposicin
hbrida, cooperando mediante el envo y recepcin explcitos de mensajes. El
tamao del mensaje est limitado slo por la cantidad de memoria disponible.
52
Soporte de heterogeneidad: PVM soporta heterogeneidad en trminos de

mquinas, redes y aplicaciones. Haciendo nfasis en el envo de mensajes,
PVM permite a los mensajes contener ms de un tipo de datos y ser
intercambiados entre mquinas teniendo distintas representaciones de datos.
Soporte a multiprocesadores: PVM utiliza las facilidades nativas de envo de

mensajes en multiprocesadores para tomar ventaja del hardware local.
Algunas veces los vendedores proporcionan su propio PVM optimizado para
sus sistemas, el cual puede comunicarse con la versin publica de PVM.
PVM est compuesto de dos partes.
La primera es un demonio llamado
pvmd3 (en el caso de la versin 3.3.x) y algunas veces abreviado pvmd, el cual
reside en todas las computadoras haciendo que la mquina virtual funcione (Un
ejemplo de un programa demonio es el programa mail que se ejecuta en background
y maneja todos los correos electrnicos que llegan y los que salen en una
computadora). pvmd3 est diseado de tal forma que cualquier usuario con una
cuenta vlida y sin necesidad de tener privilegios de superusuario, pueda instalarlo
en una mquina. Cuando un usuario desea ejecutar una aplicacin de PVM, primero
crea una mquina virtual inicializando PVM.
La aplicacin de PVM puede entonces ser inicializada desde un prompt de

Unix de alguno de los hosts. Cada usuario puede ejecutar muchas aplicaciones de
PVM simultneamente.
La segunda parte del sistema es una biblioteca de rutinas de interface de

PVM.
Contiene un repertorio, funcionalmente completo, de primitivas que son
necesarias para la interaccin entre tareas de una aplicacin.
Esta biblioteca
contiene rutinas utilizadas por el usuario para envo de mensajes, generacin de

procesos, coordinacin de tareas y modificacin de la mquina virtual.
53
El modelo computacional de PVM se fundamenta en la nocin de que una

aplicacin consiste de muchas tareas. Cada tarea es responsable de una parte de la
carga de trabajo del clculo de la aplicacin.
De manera nativa, PVM soporta los siguientes lenguajes: C, C++ y Fortran.

Las interfaces de estos lenguajes han sido incluidas debido a que se ha observado
que la mayora de las aplicaciones en el mbito cientfico son escritas en C y Fortran,
con una tendencia hacia la experimentacin con lenguajes y metodologas basados
en objetos. Ms sin embargo, existen otros lenguajes y utileras disponibles que
trabajan directamente con PVM. Tal es el caso de Fortran 90, PERL, tcl/tk, entre
otros. La condicin para que un lenguaje o utilera pueda trabajar con PVM es que
sta sea capaz de enlazarse con C.
Los enlaces de C y C++ para la biblioteca de interfaz de usuario son

implementados como funciones, siguiendo la convencin general de la mayora de
los sistemas de C, incluyendo Unix. Las aplicaciones escritas en C y C++ tienen
acceso a las funciones de la biblioteca de PVM enlazndose con el archivo de
biblioteca libpvm3.a, el cual es parte de la distribucin estndar. Los enlaces con
Fortran son implementados como subrutinas mas que como funciones.
Este enfoque fue tomado porque algunos compiladores en las arquitecturas

soportadas por PVM podran no ser contables en las interfaces de funciones de
Fortran con las funciones de C. La interface de Fortran con PVM est implementada
como fragmentos de biblioteca que en cambio invocan las rutinas correspondientes
de C, despus de moldear y/o desreferenciar los argumentos apropiadamente.
As, las aplicaciones de Fortran requieren enlazarse con la biblioteca

libfpvm3.a, as como tambin con la biblioteca de C.
Todas las tareas en PVM son conocidas por un identificador de tarea de tipo
entero (TID). Los mensajes son enviados y recibidos mediante estos tids.
54
Debido a que los tids deben ser nicos a travs de toda la mquina virtual, son
generados por el pvmd local y no son elegidos por el usuario. PVM tambin codifica
informacin dentro de cada tid.
Se espera que el usuario trate los tids como
identificadores enteros opacos. PVM tiene muchas rutinas que devuelven valores de
TID, as que las aplicaciones del usuario pueden identificar a otras tareas en el
sistema.
Existen aplicaciones donde es muy natural pensar en un grupo de tareas. Hay

casos en los que al usuario le gustara identificar sus tareas mediante los nmeros 0
- (p -1) donde p es el nmero de tareas.
PVM incluye el concepto de grupos
nombrados por el usuario. Cuando una tarea se une a un grupo, se le asigna un

nmero de "instancia", nico en ese grupo. Los nmeros de instancia inician en 0 y
se van incrementando. Manteniendo la filosofa de PVM, las funciones de grupo son
diseadas para ser muy generales y transparentes al usuario.
Por ejemplo, alguna tarea puede unirse o dejar un grupo en cualquier

momento sin tener que informar a alguna otra tarea del grupo afectado. Las tareas
tambin pueden emitir mensajes a grupos, a los cuales no pertenecen. Para usar
alguna de las funciones de grupo, un programa deber ser ligado con libgpvm3.a.
El paradigma general para la programacin de aplicaciones con PVM es como

sigue: Un usuario escribe uno o ms programas secuenciales en C, C++ o Fortran
77 que contienen llamadas a la biblioteca de PVM. Cada programa corresponde a
una tarea. Estos programas son compilados para cada arquitectura en el conjunto
de hosts, y los archivos objeto resultantes son colocados en un lugar accesible para
las mquinas en el conjunto de hosts.
Para ejecutar una aplicacin, un usuario inicia una copia de una tarea
(usualmente el "amo" o la tarea "inicializadora") escribiendo en la lnea de rdenes de
la mquina donde se encuentra tal tarea.
55
Este proceso subsecuentemente inicia otras tareas de PVM, resultando

eventualmente en una coleccin de tareas activas que entonces calculan localmente
e intercambiar mensajes con algunas otras para resolver el problema. Como ya se
ha mencionado, las tareas interactan a travs del explcito envo de mensajes,
identificndose con cada una de las otras mediante un TID opaco y asignado por el
sistema.
2.2.3.2. The Message Passing Interface Standard, MPI
MPI es el ambiente estndar de programacin en el modelo de intercambio de

mensajes. Este ambiente es el producto de una serie de encuentros sostenidos
entre noviembre de 1992 y enero de 1994 por el Comit MPI. Este comit est
constituido por miembros de aproximadamente 40 instituciones, incluyendo la
mayora de los fabricantes de mquinas paralelas, as como universidades y
laboratorios gubernamentales alrededor del mundo involucrados en el cmputo
paralelo.
MPI se ha convertido en uno de los ambientes de intercambio de mensajes

ms utilizados para la programacin de aplicaciones paralelas, tanto en mquinas
que contienen muchos procesadores como en conjuntos de estaciones de trabajo
conectadas en red.
El principal objetivo del desarrollo de MPI fue la creacin de un estndar. Este

proceso se inici con el Taller sobre Estndares para Intercambio de Mensajes en
Ambientes de Memoria Distribuida, patrocinado por el Centro para la Investigacin en
Cmputo Paralelo, en Williamsburg, Virginia, en abril de 1992.
En el diseo de MPI se ha optado por tomar los aspectos ms importantes de

varios ambientes de intercambio de mensajes en lugar de escoger, uno de stos y
adoptarlo como el estndar, de modo que MPI ha sido influenciado por los siguientes
ambientes:
56
o Intel NX/2
o Express
o Vertex
o Parmacs
o P4
Otras contribuciones han provenido de
o Zipcode
o Chm
o PVM
o Chameleon
o PICL
Algunas de las razones de la popularidad de MPI son:
Existen varias implementaciones gratuitas disponibles, como son MPICH

(Laboratorio Nacional de Argonne), LAM (Centro de Sper cmputo de Ohio Universidad de Notre Dame) y CHIMP (Centro de Cmputo Paralelo de
Edimburgo), entre otras.
Es posible realizar comunicaciones completamente asncronas, lo que permite

traslapar operaciones de clculo con operaciones de comunicacin.
Los grupos de procesos son slidos y eficientes; stos son creados a partir de
operaciones colectivas y la informacin de los miembros que conforman un
grupo es accesible a todos los miembros del mismo.
57
Maneja eficientemente los buffers de los mensajes; stos ltimos son

enviados y recibidos por medio de estructuras de datos definidas por el
usuario y no usando estructuras definidas internamente por las bibliotecas de
comunicacin.
Permite la programacin eficiente tanto de mquinas paralelas como de

grupos de estaciones de trabajo conectadas en red.
Es totalmente porttil. El cdigo de un programa MPI puede ser compilado y

ejecutado en cualquier arquitectura sin necesidad de modificacin alguna.
Es un estndar. Un programa escrito en una implementacin dada del MPI

debe funcionar bajo cualquier otra implementacin sin ninguna modificacin.
Est formalmente especificado.
Existe un documento oficial que contiene
todas las caractersticas que debe contener una implementacin estndar.
En el MPI se han incluido los siguientes aspectos importantes, deseables en

todo ambiente de cmputo paralelo:
Comunicaciones punto a punto. El envo y recepcin de mensajes entre dos

procesos representan las operaciones bsicas del modelo de intercambio de
mensajes. Mediante estas operaciones los procesos que intervienen en un
programa paralelo pueden intercambiar informacin y sincronizarse.
Operaciones colectivas. En las operaciones colectivas interviene un conjunto

de procesos.
Estas operaciones incluyen recoleccin y difusin de datos,
operaciones lgico aritmticas usando datos distribuidos entre varios

procesos, etc.
58
Grupos de procesos.
definicin
de
La formacin de grupos de procesos permite la
contextos
de
comunicacin
indica
cuales
procesos
intervendrn en una operacin colectiva.
Contextos de comunicacin.
Los contextos de comunicacin permiten la
creacin de canales a travs de los cuales puede trasmitirse informacin.

Entre otras cosas, estos canales son tiles para definir diferentes espacios de
comunicacin, lo cual es til en la programacin de bibliotecas.
Formacin de topologas.
topologa determinada.
Un grupo de procesos puede asociarse a una

Mediante estas topologas pueden programarse
esquemas de comunicacin ms eficientes.
Enlaces con los lenguajes Fortran 77 y C. La biblioteca MPI puede ser

utilizada en programas escritos en C o Fortran 77.
En el MPI NO se han incluido ninguno de los siguientes aspectos:
Operaciones de memoria compartida.
Operaciones que requieren soporte no estandarizado del sistema operativo.
Herramientas de construccin de programas.
Facilidades de depuracin.
Soporte explcito de hebras.
Manejo de tareas.
I/O.
Red Hat tiene un software propio llamado Red Hat Advanced Server, Servidor
Avanzado de Red Hat.
59
2.2.4. Servidor Avanzado de Red Hat - Red Hat Advanced Server
En mayo 2002 Red Hat Inc., introduce su ltimo diseo de Linux liberado para
usarse ambientes empresariales Red Hat Server avanzado V2.1. Red Hat Linux
Server avanzado extiende significativamente las capacidades proporcionadas por los
anteriores productos de Red Hat Linux Sserver alta disponibilidad.
Red Hat Server Avanzado V2.1 esta basado en los productos Red Hat Linux y
profesional v7.2. Este fue diseado explcitamente para el mercado computacional
empresarial para superior desarrollo aplicaciones soporte para la aplicacin,
desempeo, disponibilidad y escalabilidad.
Los siguientes prrafos describen
algunas de las caractersticas que desarrollan estos beneficios.
Como se mencion en la introduccin, una caracterstica principal del Server

Avanzado es la introduccin de dos caractersticas complementarias altamente
disponibles:
Red Hat administrador del clster, proporciona una alta disponibilidad de uso a
travs de una tecnologa fuera de fallos(failover). El administrador del clster est
basado en una tecnologa kimberlite10
de cdigo abierto (Open Source) con
significativos mejoramientos en la distribucin de Red Hat.
La caracterstica de balanceo de carga (Piraa) del IP (Internet Protocol)

proporcionado en las anteriores ediciones del servidor de alta disponibilidad de Red
Hat Linux. El balanceo de la carga de IP se basa en tecnologa de fuente abierta del
Servidor Virtual Linux (LVS, por sus siglas en ingls) con significativos mejoramientos
tambin en la distribucin de Red Hat.
El administrador de clster y el balanceo de carga del IP son automticamente

instalados como parte del proceso de instalacin estndar del servidor avanzado.
10
http://oss.missioncriticallinux.com/projects/kimberlite/
60
Una vez que la instalacin del servidor avanzado finaliza estos pueden ser
configurados y desarrollados rpidamente
2.2.4.1. Soporte de la aplicacin
Cuando se disea una configuracin de alta disponibilidad, la primera tarea es

identificar si las aplicaciones de los clientes sern apoyados por el sistema planeado.
El administrador del clster proporciona una infraestructura de fuera de fallos
(failover) para las aplicaciones que fallan en varias categoras:
Usos genricos, sin modificar. La mayora de las aplicaciones pueden ser

usadas en el ambiente del administrador del clster Esto se aplica a cualquier
aplicacin que pueda tolerar algunos segundos del tiempo de inactividad.
Bases de datos. El administrador del clster es la manera ideal de entregar

las bases de datos altamente disponibles, incluyendo oracle 8i/9i, db2, Mysql y
base de datos de Red Hat.
Archivos heterogneos de servidor. El administrador del clster trae alta

disponibilidad para archivar ambientes de la particin tales como NFS y
SMB/CIFS (usando samba).
Aplicaciones comerciales mainstream. El administrador del clster puede ser

utilizado con aplicaciones tales como SAP, Servidor de aplicaciones y Tuxedo.
Internet, y aplicaciones de cdigo abierto. El administrador del clster soporta

completamente el Internet ms popular y aplicaciones de cdigo abierto (Ej.
Apache).
Mensajera. Usando aplicaciones tales como sendmail y domin.
61
Una caracterstica crtica del administrador del clster es que las aplicaciones
no tienen que ser modificadas antes de que estas puedan ser desplegados en un
sistema de clster. En la mayora de los casos las aplicaciones no estn incluso
enterados que ellos funcionan en un clster se convierten en aplicaciones de alta
disponibilidad automticamente. El servidor avanzado tiene muchas nuevas
caractersticas para los ambientes de la empresa, tambin algunas aplicaciones que
no son convenientes para desarrollar, en el administrador del clster las
configuraciones pueden todava beneficiar desde otras capacidades del clster
avanzado. Los ejemplos seran los usos en tiempo real que tienen requisitos bajos
del estado latente (menos que algunos segundos) y capacidad limitada del buffering
en sus dispositivos del grupo de datos, o las aplicaciones que proporcionan su propia
infraestructura clustering, tal como aplicaciones reales de clster de oracle (RAC) o
las configuraciones del servidor clster de veritas.
62
Captulo III Software LVS Linux Virtual Server
CAPTULO III. SOFTWARE LVS LINUX VIRTUAL SERVER
En la actualidad es posible crear soluciones que puedan resistir muchas fallas

comunes de hardware y software y todava proveer el servicio a los consumidores de
la Web. Dentro de estas soluciones estn 2 tipos de tecnologas FOS y LVS.
La tecnologa de Servicio Fuera de Fallos. (FOS FailOver Services, por sus

siglas en ingles), es usado para crear un par de sistemas basados en Linux que
proveen
los
servicios
usados
por
los
consumidores,
tambin
como
una
implementacin de un sistema de respaldo que automticamente toma el control a la

primer seal de problemas.
La tecnologa Linux Virtual Server ( LVS Linux Virtual Server, por sus siglas en
ingles). LVS puede ser usada para crear un par sistemas basados en Linux que
actan cada uno como respaldo. De los dos sistemas basados en Linux que
actualmente proveen sus servicios, el LVS monitorea y balancea la carga de una red
de sistemas (que pueden ser o no sistemas Linux) haciendo posible un extenso
arreglo de desempeo y opciones de capacidad.
3.1. Configuracin Tpica de FOS
El clster Server Red Hat de alta disponibilidad basado en FOS consiste de

dos sistemas Linux. Cada sistema puede ser creado para soportar la carga completa
anticipada para todos los servicios. Esto es necesario por que en cualquier tiempo
solamente un sistema Linux (nodo activo) proveen los servicios para los
consumidores.
63
Durante la configuracin inicial de un Clster FOS, un sistema esta definido

como el nodo primario, y el otro como el nodo de respaldo. Esta distincin est hecha
para determinar cual sistema puede ser declarado activo, ambos sistemas se buscan
en el estado activado al mismo tiempo. En tal caso, el nodo primario ganar.
El nodo activo responde a las peticiones de servicio a travs de una direccin

virtual IP (VIP). La direccin virtual (VIP) es una direccin IP que es distinta desde los
nodos activos con sus direcciones IP normales.
El otro sistema (el nodo inactivo) no esta corriendo los servicios; en lugar de
eso monitorea los servicios en el nodo activo, y se asegura que el nodo activo este
funcionando. Si el nodo inactivo detecta un problema con el nodo activo o los
servicios activos se inicializa un FailOver .
Durante el FailOver se realizan las siguientes actividades:
El nodo activo detiene todos los servicios (si todava est funcionando y
tiene conectividad de la red).
El nodo inactivo inicia todos los servicios.
El nodo activo deshabilita el uso de las direcciones IP virtuales (si todava

est funcionando y tienen conectividad de la red).
El nodo inactivo es ahora el nodo activo y habilita el uso de las direcciones

VIP.
Este es un breve esquema de la Configuracin FOS del cual es muy extensa al igual
que la configuracin LVS, lo cual no es tema de esta tesis y nos enfocaremos en
LVS.
La tecnologa que se va a implementar es la LVS, comparada con FOS que se

sera un sistema de respaldo, en todo caso sera una implementacin de alta
64
disponibilidad, y no un balanceador de carga motivo de esta tesis, otro aspecto es

como se comporta un balanceador de carga, entender su funcionamiento es sencillo
pero es tan sencillo como se describe la instalacin y la configuracin ?
3.2. LVS - Linux Virtual Server1
El proyecto Linux Virtual Server provee la informacin y todos los programas

necesarios para montar un servidor virtual fcilmente escalable sobre un clster de
mquinas Linux. De cara al usuario final solamente habr un servidor, anque de
puertas adentro lo que tendremos ser un clster que servir las peticiones que le
lleguen como si se tratara de una nica mquina. Linux Virtual Server se basa
nicamente en PCs corriendo Linux con su software, tanto para los servidores como
para los equipos que realicen funciones de balanceadores de carga (el punto de
entrada al clster que redirigir el trfico hacia cada uno de los servidores reales). Es
decir, no se necesita ningn enrutador/cortafuegos/balanceador hardware, ni ningn
software propietario de terceras personas. Todo el software de Linux Virtual Server
est disponible bajo la licencia GNU General Public License (GPL).
El software de Linux Virtual Server se est utilizando en la actualidad en

entornos
de
produccin
(http://www.linux.com),
como
las
el
portal
web
del
de
portal
de
desarrollo
Linux
Linux.COM
SourceForge
(http://www.sourcefoge.net), la web del integrador de servidores Linux VA Linux

Systems, Inc. (http://www.valinux.com), la web de la empresa de vdeo y multimedia
para la red Real Networks, Inc., (http://www.rela.com), o la web dedicada al anlisis y
comentarios de hardware AnandTech (http://anandtech.com).
http://www.linuxvirtualserver.org/
65
3.2.1 Funcionamiento de un LVS
La figura 3.1 muestra un esquema general una red de clster LVS.
Figura 3.1. Esquema general de un LVS Linux Virtual Server.
El usuario se conecta a travs de Internet a la direccin pblica de nuestro

clster, que est asignada al balanceador de carga. Este equipo est conectado a
travs de una LAN (ser lo ms comn) o una WAN con el resto de equipos del
clster: los servidores reales, servidores de archivos, cortafuegos y se encargar de
dirigir cada una de las peticiones al servidor que se encuentre en mejor condicin
para atenderla (menor carga). Segn la configuracin por la que optemos, la
respuesta ser enviada por el servidor real directamente al cliente (si cada servidor
tiene acceso directo a Internet), o ser de nuevo redirigida a travs del balanceador
de carga.
66
La escalabilidad se obtiene fcilmente aadiendo ms equipos a la LAN,

aumentando as el nmero de servidores reales en el clster. La alta disponibilidad,
por su parte, tambin, ya que al tener varios servidores, cuando uno falle el resto
asumirn la carga del cado (salvo casos especiales, como el balanceador de carga,
que se tratarn de forma distinta).
3.2.2. Modo de Distribucin de carga
Existen varias formas para montar un clster y distribuir la carga entre los
equipos. En el punto anterior se explic cmo se lleva a cabo en LVS, pero se
explican todas las opciones:
3.2.2.1. Modo DNS Round Robin
El mtodo ms sencillo es mediante un DNS round-robin: Cuando en un

servidor de DNS definimos varias IPs para un mismo dominio, el servidor nos
devolver cada vez una IP distinta, en principio sin ningn criterio en especial que
generalmente se utiliza una cola round-robin para ir sirviendo las peticiones. De esta
forma se consigue distribuir la carga entre los servidores reales de una forma
pseudo-aleatoria, segn vayan llegando peticiones. El problema con este mtodo es
que no se tiene en cuenta la carga real de cada servidor, y es posible que todas las
peticiones pesadas vayan a parar siempre a la misma mquina que acabara por
saturarse, mientras que las dems estaran sirviendo peticiones triviales. Otro
problema es que como los clientes suelen mantener una cach de los dominios ya
resueltos a travs del DNS, una vez que un cliente haya contactado con uno de los
servidores reales, siempre (hasta que expire su cach) se dirigir al mismo servidor.
Este es otro punto por el que se puede llegar a sobrecargar un servidor mientras que
el resto estn libres. Adems, si en algn momento fallara un servidor y su IP est
todava en la cach de algn cliente, ste seguira envindole las peticiones que, por
supuesto, fallaran.
67
3.2.2.2. Modo de Balanceo de Carga
Una solucin mejor es utilizar un balanceador de carga para distribuir las

conexiones entre los servidores. Con esta solucin se puede aumentar la sensacin
de unidad del clster, ya que de cara al usuario nicamente habr una direccin IP
a la que se dirijan todas las peticiones, en lugar de varias. La granularidad de la
distribucin se puede hacer por conexin (cada peticin de un cliente se redirige al
servidor que est en mejor posicin para servirlo) o por sesiones (se almacena en
una tabla a qu servidor se enva a cada cliente y se le manda siempre al mismo).
Cuando algn servidor falla, es ms fcil enmascarar el error, ya que nicamente
habr que proveer al balanceador de carga de los mecanismos necesarios para
detectar el fallo de un servidor y eliminarlo de su lista, de forma que no le redirija
ninguna peticin. Por este mismo motivo, la administracin del clster se simplifica ya
que se pueden sacar servidores del clster en cualquier momento para realizar
tareas de mantenimiento, sin que ello provoque errores en los clientes.
El balanceo de carga se puede hacer a dos niveles: a nivel de conexin IP, o a

nivel de protocolo. En este segundo caso, el balanceador sera una especie de proxy
que programaramos para recibir conexiones en un determinado puerto, tal vez
inspeccionar los paquetes para ver si se trata del protocolo correcto o extraer algn
tipo de dato del protocolo e incluso poder filtrar peticiones incorrectas, y redireccionar
la conexin hacia uno de los servidores. El problema de esta aproximacin es que al
tener que analizar el protocolo en todas las conexiones entrantes, el programa
balanceador es bastante complejo y podra llegar a convertirse en un cuello de
botella en la entrada al clster (se estima que, dependiendo de la potencia de los
equipos, el nmero de servidores reales que se pueden servir sin problemas de
congestin estara en el rango de 4 a 6). Entre este tipo de balanceadores contamos
con Reverse-Proxy y WEB.
68
La otra opcin, el balanceado a nivel de conexin IP, es mucho ms eficiente

ya que el proceso a realizar es tambin mucho ms sencillo: Cuando llega una
peticin al balanceador no se analiza a ningn nivel mayor que el de TCP/IP, lo justo
para aceptar la conexin y redirigirla a uno de los servidores.
Con esta aproximacin los servidores reales que se pueden tener detrs del
balanceador pueden oscilar entre 25 y hasta 100, como siempre, segn la potencia
de los equipos. El balanceador de Linux Virtual Server funciona a este nivel.
3.2.3. Tipos de balanceado de carga en LVS
LVS permite realizar el reenvo de paquetes a los servidores reales de tres

formas. A continuacin se analiza en qu consiste cada una, con sus pros y sus
contras:
3.2.3.1. Balanceado por NAT (VS-NAT)
Este tipo de balanceado aprovecha la posibilidad del Kernel de Linux de

funcionar como un enrutador con NAT (Network Address Translation), que no es ni
ms ni menos que la posibilidad de modificar las direcciones de origen/destino de los
paquetes TCP/IP que lo atraviesen: la nica direccin real del clster ser la del
balanceador; cuando le llegue un paquete modificar la direccin de destino para que
llegue a uno de los servidores y la de origen para que le sea devuelto a l, y lo
reenviar a la red privada; cuando el servidor real lo procese, se lo enva al
balanceador (que es el nico punto de salida para todos los equipos del clster hacia
Internet) y ste deshace el cambio de direcciones: pone como direccin de origen
del paquete con la respuesta la suya, y como direccin de destino la del cliente que
origin la peticin.
En la figura 3.2, se puede ver grficamente todo el proceso.
69
Figura 3.2. Configuracin de un LVS: VS-NAT
Cada punto es:
1. El cliente realiza una peticin de servicio, a la IP pblica del clster (la del
balanceador de carga).
2. El balanceador planifica a qu servidor real va a enviar la peticin, reescribe
las cabeceras de las tramas TCP/IP y se las enva al servidor.
3. El servidor recibe la peticin, la procesa, genera la respuesta y se la enva al
balanceador de carga.
4. El balanceador reescribe de nuevo las cabeceras de las tramas TCP/IP con la
respuesta del servidor, y se las enva de vuelta al cliente.
5. La respuesta llega al cliente, como si la hubiera generado la IP pblica del
clster.
70
Visto de una forma ms fsica, el montaje del clster se muestra en la figura 3.3:
Figura 3.3. Imagen LVS: VS-NAT, esquema fsico.
La nica IP pblica del clster sera la 202.103.106.5, que sera la IP que

asociaramos en el servidor de DNS al dominio de nuestro clster y a la que iran
dirigidas todas las peticiones de los clientes. El resto de direcciones son de la red
privada.
El mayor punto a favor de sta tcnica es que los servidores que compongan
el clster pueden ejecutar cualquier Sistema Operativo que soporte TCP/IP, ya que
toda la manipulacin de direcciones y gestin del clster se realiza en el
balanceador, sin ser necesario modificar en ningn modo el resto de servidores.
Adems, slo se necesita una IP real (la que asignaremos al balanceador). El

resto de servidores pueden tener IPs privadas de una red local.
71
La desventaja de este mtodo es la misma que se tiene con los balanceadores

a nivel de protocolo que se menciono anteriormente: el balanceador se puede llegar
a convertir en un cuello de botella, ya que todo el trfico de entrada y salida al clster
pasa por l (debe tener suficiente ancho de banda de entrada y salida para
soportarlo) y adems tiene que reescribir todos los paquetes TCP/IP. El nmero de
servidores reales hasta el que podamos escalar depender, por tanto, del ancho de
banda de las conexiones con el balanceador y de su potencia de clculo para
reescribir las tramas. De todas formas, un servidor actual de clase alta no debera
tener problemas para tratar con 20 o tal vez ms servidores: Suponiendo que el
tamao medio de un paquete TCP/IP es de 536 bytes y que el tiempo empleado en
reescribirlo por las rutinas NAT del Kernel est en torno a los 60us (depender del
equipo, por supuesto), el ancho de banda total que podr soportar el balanceador
est en torno a las 8.9 Mbytes/s. Suponiendo que cada servidor pueda manejar flujos
de 400Kbytes/s, el balanceador ser capaz de enrutar el trfico de hasta 22
servidores.
Una posible solucin es emplear una tcnica hbrida entre NAT y la solucin
clsica del DNS: tener varios clusters no muy grandes con un balanceador NAT cada
uno, y a su vez, en el DNS, poner todas las IPs de los balanceadores con el mismo
nombre de dominio. As la carga se repartir entre cada uno de los clusters.
3.2.3.2. Balanceado por encapsulado IP (VS-Tun)
Este mtodo permite escalar hasta un mayor nmero de servidores, 100 o

ms, pero todos ellos debern ser capaces de tratar el encapsulado IP (IP tunneling).
El encapsulado IP consiste en hacer viajar una trama TCP/IP, con sus direcciones de
origen y destino, dentro de otra trama con direcciones distintas para, una vez que la
trama ms externa llegue a su camino, desencapsular la trama original y reenrutarla
desde all. Es una forma de utilizar un enrutamiento alternativo de una red A otra red
B, forzando un rodeo por la red C. El problema de esta tcnica es que no todos los
sistemas operativos la soportan.
72
De una forma muy genrica, el encapsulado se muestra en la figura 3.4:
Figura 3.4. Imagen LVS: Encapsulado IP
Utilizando este mtodo de balanceado todos los servidores necesitan tener

configurada en alguna interfaz (aunque sea virtual) la IP pblica del servidor, y
adems necesitarn IPs pblicas si se quiere distribuir los equipos en una WAN. El
punto de entrada al clster, de nuevo, es la del balanceador de carga, pero una vez
que el trfico llega a los servidores reales stos direccionan directamente las
respuestas hacia los clientes sin necesidad de pasar de nuevo por el balanceador.
Por otra parte, al realizar la comunicacin entre el balanceador y los

servidores por medio de encapsulado IP, es posible distribuir los servidores reales a
lo largo de una red de rea amplia en lugar de tenerlos todos en un mismo segmento
de red local.
73
El esquema de LVS con encapsulado IP se muestra en la figura 3.5:
Figura 3.5. Imagen LVS: VS-Tunneling
El balanceador recibe todas las conexiones de entrada al clster, y decide a

qu servidor envirselas. Para hacer esto, utiliza el encapsulado IP para enviar cada
trama que recibe a la IP del servidor que vaya a encargarse de ella. Cuando el
servidor elegido recibe el paquete, lo desencapsula y al tener configurada la IP
pblica del clster como propia, acepta la trama original y se encarga de servir la
peticin que contuviera.
Con esta tcnica se evita que el balanceador sea un cuello de botella

haciendo que slo los paquetes de entrada al clster pasen a travs de l, mientras
que los de salida los enviar cada servidor real directamente a su destino.
74
Si se analiza el flujo de datos que genera un servidor corriente, por ejemplo un

servidor web, veremos que el trfico en direccin cliente-servidor es mucho menor
que al contrario: en efecto, las peticiones de los clientes contienen pocos ms datos
que un mndame esta pgina, mndame esta otra o he recibido bien la pgina,
mientras que el trfico del servidor al cliente contiene la pgina web, todas las
imgenes, animaciones, ficheros de datos, entre otros.
De esta forma, limitando el trfico que pasa por el balanceador a nicamente

el de entrada, con un balanceador equipado con una tarjeta de red de 100Mbps
tenemos suficiente para todo un clster que genere 1Gbps de datos.
La mayor desventaja de este mtodo es que todos los servidores deben

entender el encapsulado IP. Los autores de LVS nicamente han probado este
mtodo con servidores Linux. Es probable que en otros sistemas que tambin
soporten encapsulado IP funcione, pero no se ha probado.
Por otra parte, con este mtodo todos los servidores del clster necesitan
tener IPs pblicas, lo que puede ser un punto negativo por el coste asociado a la
adquisicin de IPs pblicas, aunque como contrapartida positiva esto posibilita que
estn dispersos en una red de rea amplia. Al poder separar geogrficamente los
servidores aadimos un punto ms a la alta disponibilidad del clster, ya que ante un
fallo general en la localizacin de un clster centralizado, se inutilizara todo el
clster, mientras que si los equipos estn dispersos esto es ms difcil que ocurra
(tendra que haber problemas en TODAS las localizaciones de los equipos).
75
3.2.3.3. Balanceado por enrutamiento directo (VS-DR)
Este tercer mtodo requiere que todos los servidores tengan una IP real, que
se encuentren en el mismo segmento fsico de red que el balanceador, y adems
que todos los servidores del clster (incluido el balanceador) compartan la IP pblica
del clster. En el lado positivo, es el que menos sobrecarga impone al equipo
balanceador, ya que ni tiene que reescribir los paquetes (caso NAT) ni encapsularlos
(caso encapsulamiento IP).
Adems, el balanceador no es un cuello de botella, ya que al igual que en el

caso anterior, nicamente pasar a travs de l el trfico en direccin de los clientes
al clster, mientras que el trfico de salida lo dirigirn directamente los servidores a
cada cliente.
Como se mencion, todos los equipos tendrn configurado un interfaz con la

IP pblica del clster: El balanceador, como siempre, la tendr en su acceso a
Internet y ser el punto de entrada al clster; el resto de equipos estarn conectados
al balanceador en la misma red fsica y en la interfaz conectado a esta red tendrn
configurada la IP pblica del clster, pero configurando la interfaz para que no
responda a comandos ARP para no interferir con otros protocolos (todos los equipos
responderan por la misma IP con distintas MACs). Cuando llega una peticin al
balanceador ste decide a qu servidor envirsela, y redirige el paquete a nivel de
enlace (p.ej. Ethernet) a la direccin MAC del servidor elegido, en lugar de modificar
o encapsular el paquete TCP/IP. Cuando llega al servidor con la MAC de destino y se
analiza hasta el nivel de red (TCP/IP), como el servidor tambin tiene configurada la
IP pblica del clster, acepta sin ms el paquete y genera la respuesta, que enviar
directamente al cliente:
76
El esquema de LVS de Balanceado por enrutamiento directo (VS-DR) se muestra en

la figura 3.6:
Figura 3.6. Imagen LVS: VS-Direct Routing
Los problemas de este mtodo es que no todos los Sistemas permiten

configurar una IP o un dispositivo de modo que no responda a los comandos ARP, y
que todos los servidores deben estar en el mismo segmento fsico de red para poder
encaminar las tramas a nivel de enlace segn las direcciones MAC, perdiendo as la
posibilidad de dispersar geogrficamente el clster que se tena en el mtodo
anterior.
En la tabla 4 se resumen las caractersticas principales de los tres mtodos de

direccionamiento que puede utilizar el balanceador de carga de Linux Virtual Server:
77
NAT
Encapsulamiento IP
necesita
Enrutamiento Directo
Servidor
cualquiera
Red de servidores
red privada
LAN/WAN
LAN
Escalabilidad
baja (10~20)
alta
alta
balanceador
enrutadorr
enrutador
Salida
hacia
Internet
encapsulamiento
dispositivo no-ARP
Tabla 4. Mtodos de Direccionamiento
3.2.4. Alta disponibilidad en LVS
La alta disponibilidad dentro del proyecto Linux Virtual Server se consigue

utilizando algunas de las tcnicas vistas en la tabla anterior. Vamos a ver un par de
ejemplos tal y como se ilustran en la documentacin de LVS2:
En la figura 3.7 se puede ver de forma esquemtica cmo se montara el

clster, y el lugar que ocupara cada uno de los servidores y programas:
Del sitio de internet http://www.linuxvirtualserver.org

78
Figura 3.7. Imagen del clster LVS: Alta disponibilidad
El clster se divide horizontalmente en tres partes:
En la primera lnea tenemos el distribuidor de carga. Para que esta mquina

no se convierta en un punto de fallo (SPF), se duplica con otra mquina igual de
respaldo que en principio estar inactiva.
79
Ambas mquinas monitorizarn su funcionamiento y el de la otra con Mon3,

es un recurso de propsito general que monitorea el sistema que puede ser usado
para monitorear la disponibilidad de la red y nodos del servidor, y Heartbeat4, cdigo
que sirve para detectar la comunicacin entre 2 nodos a travs de una lnea serie y
UDP, cuando la de respaldo detecte algn problema con el Server principal, utilizar
Fake5, el cul es un cdigo que fue diseado para cambiar a un Servidor de respaldo
en una LAN con todos los servicios de Mail, Web y Servicios de Proxy durante el
periodo de que ambos servidores, para suplantar su identidad, obteniendo as la
direccin IP de entrada al clster y tomando el control de la distribucin de la carga.
En la segunda lnea tenemos los servidores reales. La alta disponibilidad se

consigue instalando varios servidores y monitorizndolos en el distribuidor de carga,
tanto a nivel de mquina con el fping.monitor como de servicios (http.monitor,
ftp.monitor, etc.) para sacarlos del clster mediante la alarma programada para
cada servicio monitorizado en el momento que alguno falle.
En la tercera lnea tenemos el sistema de archivos distribuido CODA6. Se
puede montar varios servidores en la celda CODA para asegurar su disponibilidad
ante cualquier cada. Adems, se puede configurar la cach local de los servidores
para asegurar que siempre tengan ah los archivos de ms comn acceso, para que
ante una cada de la red interna puedan seguir sirvindolos.
Adems de todo esto, tambin se debe tener en cuenta cuando se instale una
infraestructura de red redundante, con varios enrutadores de salida, varias redes
internas para interconectar todos los equipos, y varias tarjetas de red en cada
servidor para poder salir por una u otra si alguna llega a fallar.
http://www.kernel.org/software/mon/
http://www.linux-ha.org/
5
http://www.vergenet.net/linux/fake/
6
http://www.coda.cs.cmu.edu/
4
80
3.2.5. Configuracin Tpica de LVS (Linux Virtual Server)
En muchas maneras un clster LVS puede pensarse como un clster FOS con
una simple diferencia, en lugar de solamente proveer los servicios, el nodo activo de
un enrutador de clster LVS requiere de uno o ms servidores que proveen servicios.
Estos servidores adicionales llamados servidores reales son balanceadores de carga
por el nodo activo, en trminos de LVS, el enrutador activo.
Como en un clster FOS, hay dos sistemas que comparten la responsabilidad

de asegurar que uno de los dos sistemas est activo, mientras que el otro ( enrutador
inactivo) est en estado de espera para iniciar una peticin de fuera de fallos. Como
siempre ah es donde terminan las similitudes.
Por que la responsabilidad principal del enrutador activo es aceptar peticiones

de servicios y dirigirlas al servidor real apropiado, es necesario para un enrutador
activo mantener el seguimiento del estado de los servidores reales y para determinar
cual servidor real debe recibir la siguiente peticin de servicio. Por lo tanto el
enrutador activo monitorea todos los servicios en cada servidor real. En el evento de
que el servicio falla en un servidor real dado, el enrutador activo detendr las
peticiones de servicio hasta que el servicio se vuelva estable otra vez.
Adems el enrutador activo puede opcionalmente usar una de muchas tareas

para determinar cual servidor real es mas capaz de llevar a cabo el siguiente
servicio. Las tareas mtricas disponibles son:
Round Robin Vuelta Robin
Least Connections Minimas Conexiones
Weighted round robin Vuelta Mejorada Robin
Weighted least connections Minimas conexiones Mejorado
81
Como siempre por ahora lo ms importante es que el enrutador activo puede

tomar en cuenta la actividad de los servidores reales y opcionalmente un factor
asignado arbitrariamente cuando se mandan las peticiones de servicio. Esto significa
que es posible crear un grupo de servidores reales usando una variedad de
configuraciones hardware y tener el enrutador activo en cada servidor real.
Figura 3.8. Configuracin Bsica de un Clster LVS.
La figura 3.8, muestra una configuracin de un tpico clster LVS de Red Hat
Server de alta disponibilidad con tres servidores reales proporcionando el servicio
Web. En esta configuracin, los servidores reales estn conectados a un segmento
privado de red dedicado. Los enrutadores tienen dos interfaces o tarjetas de red
Una interfase de red pblica
Una interfase de red privada.

82
Las peticiones de servicio dirigidas a la direccin del VIP del clster son
recibidas por un enrutador activo en una interfase, y entonces pasan al servidor real
mas apropiado a travs de otra interfase. De esta manera los enrutadores son
tambin capaces de actuar la parte de firewalls; pasando solamente los servicios
validos para la red privada de los servidores reales.
Un clster LVS puede usar uno de los tres diferentes mtodos de trfico de
enrutamiento para los servidores reales.
Network Address Translation (NAT), que permite una arquitectura de LAN

privada.
Direct routing, que permite LAN basados en direccionamiento.
Tunneling (IP encapsulation), que hace posible la distribucin de servidores

reales a nivel WAN.
En la figura 3.8 se muestra una tpica configuracin LVS con enrutamiento

NAT. El enrutamiento basado en NAT hace posible que se operen servidores reales
en un ambiente protegido, esto adiciona una sobrecarga adicional en el enrutador,
as como debe traducir las direcciones de todo el trfico para y desde cada servidor
real. En prctica esto limita el tamao de un clster LVS de direccionamiento NAT, a
aproximadamente de 10 o 20 servidores reales.
Esta sobrecarga no est presente cuando usan direccionamiento tuneling o

directo, por que en estas tcnicas los servidores reales responden directamente a los
sistemas requeridos. Con el direccionamiento tunneling hay un poco mas sobre el
limite que con el enrutamiento directo, pero esto es mnimo especialmente cuando se
compara con el enrutamiento basado en NAT.
Un aspecto interesante de un clster basado en LVS es que los servidores

reales no tienen que correr un sistema operativo en particular.
83
Desde las tcnicas de direccionamiento usadas por LVS todas son basadas
en un estandar de caractersticas de TCP/IP, cualquier plataforma que soporte un
arreglo de TCP/IP puede ser parte de un clster LVS.
Una configuracin LVS ms compleja.
Figura 3.9. Configuracin Compleja de un Clster LVS.
La figura 3.9 muestra una configuracin de LVS ms compleja, para

desarrollar un LVS. Esta configuracin muestra una posible aproximacin para
desarrollar clster comprendidos con gran nmero de sistemas.
La aproximacin tomada por esta configuracin es para compartir una simple

red de servidores reales entre mltiples mquinas de direccionamiento.
84
Por que cada enrutador activo es responsable de dirigir las peticiones para
una direccin VIP nica, esta configuracin normalmente presentar la apariencia de
mltiples clster. Como siempre el DNS de Round Robin puede ser usado para
resolver un simple hostname para una de las direcciones de VIP manejadas por unos
de los enrutadores activos. Por lo tanto cada peticin de servicio ser dirigida a cada
enrutador activo en turno, efectivamente extender l trfico a travs de todos los
enrutadores activos.
85
Captulo IV Implementacin del Clster
CAPTULO IV. IMPLEMENTACIN DEL CLSTER
Despus de explicar que es un LVS clster, entre otras cosas ahora se llega al
punto de implementacin el cual se har uso de la versin LVS de Red Hat. Las
capacidades que el clster LVS de Red Hat soportan son :
Construccin de Servidores Virtuales de Direccin IP Flotante (VIPs) donde

las peticiones para el servicio en cuestin son solicitadas desde direcciones
pblicas de internet.
Direccionamiento de peticiones de servicio desde servidores virtuales para

una comunidad de servidores reales.
Balanceador de Carga
Redireccionamiento de paquetes
Conexiones persistentes.
Antes de empezar a realizar una implementacin o prueba de un clster de

computadoras con sistema operativo Red Hat 6.2, se debe de analizar la forma de
cmo se debe construir el clster.
Uno de los primeros puntos es seleccionar el mtodo de ruteo. Existen 3 tipos

de enrutamiento como se mencion en el capitulo 3, el ms optimo para la
implementacin es el enrutamiento NAT. Este tipo de enrutamiento usa lo se conoce
como enmascaramiento de direcciones (IP_MASQUERADE1), el cual es muy til
para el clster, es una funcin que redirecciona los paquetes de entrada y salida de
las peticiones de informacin, esta debe estar instalada en el sistema operativo del
clster principal.
http://www.redhat.com/mirrors/LDP/HOWTO/IP-Masquerade-HOWTO/ipmasq-intro1.0.html
86
El enrutador NAT de direccin IP es el default usado por cada servidor real en

una red privada para comunicarse con el enrutador activo. Como la direccin virtual
del servidor, esto es una direccin IP flotante. El enrutador NAT puede tener un alias
para el dispositivo conectando los enrutadores LVS en la red de los servidores
reales, o asociados con un dispositivo separado en cada enrutador.
As como la direccin virtual del servidor, las direcciones NAT son habilitadas
solo en el enrutador activo. Si el enrutador activo falla, el enrutador de respaldo
habilita el servidor virtual y las direcciones NAT durante la falla de la direccin IP
flotante.
En la figura 4.1 siguiente se muestra la topologa de un clster LVS

implementado con enrutamiento NAT, la direccin del servidor virtual y direccin
pblica se habilitan en el dispositivo eth0 y la direccin IP del enrutador NAT en el
dispositivo eth1.
Figura 4.1. Esquema bsico de Clster LVS.
87
Cuando el servidor real procesa una peticin, ste regresa la respuesta

directamente para la peticin del cliente en lugar del enrutador activo. As el
enrutador activo procesa solamente peticiones de entrada. Una ventaja adicional del
redireccionamiento es que el servidor real puede ser geogrficamente distribuido.
Cuando un servidor real procesa una peticin, este retorna paquetes para el
enrutador activo o principal, y la direccin de el servidor real en los paquetes es
reemplazada por la direccin del servidor virtual. De esta manera la red privada de
los servidores reales esta enmascarada desde la peticin de los clientes.
El enrutamiento NAT es fcil y flexible de implementar. Los servidores reales
pueden ser de cualquier tipo de mquina corriendo cualquier sistema operativo o
servidor WEB, o cualquier combinacin. La desventaja de este, es que despus de
veinte servidores reales, el enrutamiento LVS tiene muchos procesos de salida, y
muchas peticiones de entrada, el trfico en la red se incrementa y el tiempo de
respuesta empieza a ser mas grande y esto puede ser un cuello de botella.
Otro punto a considerar son los mtodos de balanceo de carga. Sin importar el
mtodo de enrutamiento, el kernel redirecciona las peticiones de los servicios desde
las direcciones del servidor virtual para el servidor real.
Por ejemplo, un peticin de direccin TCP para el puerto 80 en el servidor

virtual 1.2.3.1 puede ser direccionado para el puerto 80 en el servidor real
192.168.1.2. El mapeo actual de las tareas para los servidores reales en la tabla
IPVS est basado en el algoritmo de balanceo de carga en uso.
La tabla 5 muestra los mtodos de balanceo de carga soportados por Red Hat.
88
Tipo
Descripcin
round robin ( rr)
Distribuye tareas iguales en los servidores

reales.
Distribuye mas trabajos para los servidores
reales con menos conexiones activas.
Distribuye mas tareas para los servidores
con gran capacidad. Est capacidad
indicada por el usuario asigna el peso, con el
cual esta ajustado para subir o bajar
dinmicamente leyendo la informacin
Distribuye mas tareas para los servidores
con menos conexiones activas relativas para
su capacidad.
least-connections ( lc)
weighted round robin ( wrr )
weighted least-connections ( wlc )
Tabla 5. Tipos de balanceo de Carga.
Otro aspecto importante son los componentes del clster LVS desarrollados
por Red Hat : pulse, lvs, nanny y lvs.cf.
El pulse o pulso es el que controla los procesos que inician los otros servicios
cuando se necesita. Este se inicia en el enrutador LVS, en el archivo por lotes
/etc/rc.d/init.d/pulse, al iniciar la mquina. Mediante pulse, el cual implementa un
simple pulso, el enrutador LVS inactivo determina el estado del enrutador activo y
para iniciar un evento de fuera de fallos (FOS).
El demonio lvs funciona en los enrutadores LVS. Este demonio lee la

configuracin del archivo /etc/lvs.cf y llama a ipvsadm para construir y mantener la
tabla de enrutamiento IPVS situada en el kernel del S.O.
El demonio de monitoreo nanny funciona en el enrutador activo LVS. Mediante

este servicio, el enrutador activo determina el estado de cada servidor real y
monitorea que este trabajando adecuadamente. Un proceso separado funciona para
un servicio definido en cada servidor real.
89
El ipvsadm es una herramienta para actualizar la tabla de enrutamiento IPVS

en el kernel. El servicio lvs inicia y administra un clster, llamando ipvsadm para
agregar, cambiar o borrar entradas en la tabla de enrutamiento IPVS en el kernel.
Adems existen otras aplicaciones que complementan los componentes del

clster como son :
La Interfase Web para monitorear, configurar y administrar un LVS clster.

Normalmente esta interfaz se usa para mantener el archivo /etc/lvs.cf , reiniciar los
servicios y monitorear el clster LVS.
El send_arp manda seales ARP en multidifusin en la red cuando la direccin

del servidor virtual cambia desde un nodo a otro.
El diagrama de la figura 4.2 muestra los componentes trabajando juntos en un

clster LVS.
Figura 4.2. Diagrama Componentes de un LVS Clster de Red Hat.
90
El archivo lvs.cf contiene la configuracin del clster LVS. Directa o

indirectamente todos los demonios del clster toman la configuracin de este archivo.
Este archivo contiene tres secciones: parmetros globales, parmetros por

servidor virtual y parmetros por servidores reales.
Los parmetros globales se describen en la tabla 6 :

Parmetro
Descripcion
primary = n.n.n.n
Es la direccin IP de el adaptador que

conecta al enrutador LVS primario con las
redes pblicas
Es la direccin de el adaptador que conecta
al enrutador LVS de respaldo con las redes
publicas
El nmero de puerto usado para el servicio
heartbeat en los enrutadores LVS primario
y de respaldo
Es el nmero de segundos del servicio de
monitoreo heartbeats()
Es el nmero de segundos que espera
antes declarar una respuesta de error del
enrutador e iniciar una falla fuera de fallos.
Es el comando que se usa para sincronizar
la configuracin de archivos en el enrutador
primario y de respaldo.
Es el mtodo de enrutamiento que se usa
cuando los enrutadores LVS se conectan a
los servidores reales.
Es la direccin IP flotante y dispositivo del
enrutador NAT. Esta direccin IP puede ser
el enrutador por default usado por cada
servidor real para comunicarse con el
enrutador activo. La direccin IP tiene un
alias en el dispositivo
conectando los
enrutadores LVS con la red privada de
servidores reales. El dispositivo puede ser
el mismo en ambos enrutadores LVS.
Es el tipo de clster el servicio que se
puede utilizar que puede ser Fail Over
Server o Linux Virtual Server.
backup = n.n.n.n
hearbeat_port = n
keepalive = n
deadtime = n
rsh_command = [ rsh | ssh ]
network = [ nat | direct | tunnel ]
nat_router = n.n.n.n ehtn:n
service = [ lvs | fos ]
Tabla 6. Descripcin de los Parmetros Globales del Clster

91
Los parmetros para el servidor virtual se describen en la tabla 7 :
Parmetro
Descripcin
virtual xxx
Es el nmero de identificador nico para

el servidor virtual
{
Inicia el bloque servidor virtual.
address = n.n.n.n
Es la direccin IP del servidor virtual :
una direccin IP flotante que puede ser
asociada con un nombre de dominio
calificado.
active = [ 0 | 1 }
Habilita ( 1 ) o deshabillita (0) el servidor
load monitor = [ uptime | rup | ruptime ] Por default es uptime, pero podemos
seleccionar la herramienta que puede
ser usada por el enrutador activo con el
monitor que trabaja en el servidor real.
Si seleccionamos uptime, la herramienta
que especificamos en el parmetro
rsh_command es usado para entrar en
los servidores reales. Esta herramienta
puede ser habilitada tambin en los
servidores reales
timeout = n
Es el nmero de segundos, por default
10, que un servidor real necesita
transcurrir antes que determine que esta
fuera de servicio y sea removidad desde
la tabla de enrutamiento.
reentry = n
Es el nmero de segundos, por default
180, que un servidor real restaurado se
debe mantener vivo antes de ser
agregado a la tabla de enrutamiento.
port = nnn
Es el puerto de entrada para este
servidor virtual : Tpicamente, el puerto
80 es usado para el protocolo http y el
puerto 21 para el protocolo ftp. Sin
embargo cualquier puerto vlido puede
ser usado.
Continua.....
92
Parmetro
Descripcin
persistent = nnn
Si
se
especifica,
esta
habilita
persistencia y define el tiempo fuera en
segundos de una conexin persistente.
Persistencia puede causar mltiples
peticiones desde un cliente y para ser
redireccionado para el mismo servidor
cada peticin. El valor de tiempo fuera
de
una
sesin
persistente
es
especificado en segundos. El valor por
default es 300 segundos. Esta opcin se
usa para resolver problemas con
cookies, SSL or FTP con enrutamiento
tunneling o direct
Si la persistencia esta habilitada, este
parmetro permite un granularidad que
los clientes son agrupados. La direccin
fuente
de
la
peticiones
estn
enmascaradas con esta mascara.
Selecciona el algoritmo de por default
wlc, para distribuir tareas desde este
servidor virtual hacia los servidores
virtuales. Las opciones son descritas en
la tabla de mtodos de balanceo de
carga.
Cierra el bloque de servidor virtual.
pmask = nnn.nnn.nnn.nnn
Scheduler = [ wlc | lc | wrr | rr ]
Tabla 7. Descripcin de los Parmetros para el Servidor Virtual.
Los parmetros para servidores reales se describen en la tabla 8 :
Parmetro
Descripcin
server xxx
{
address = n.n.n.n
Es el nombre nico para el servidor real.

Inicia el bloque servidor real
Es la direccin IP de el servidor real en la
red privada.
Habilita (1) o deshabilita (0) el servidor real.
Es un entero, por default 1, que especifica
a este servidor la capacidad relativa de
procesamiento de otro servidor real.
Cierra el bloque de servidor real.
active = [ 0 | 1 ]
weight = n
Tabla 8. Descripcin de los Parmetros para los Servidores Reales.

93
Para la tabla anterior se debe de repetir una por cada servidor real que se
instale en el clster.
Para el enlace del clster con las otras mquinas existen las herramientas de
monitoreo, ruptime, uptime y up, y las de sincronizacin rsh, ssh,. Estas pueden ser
combinadas de la siguiente manera, una herramienta de sincronizacin y otra de
monitoreo pero no todas a la vez.
La tabla 9 explica la funcin de cada herramienta.
Herramienta
rsh
Ssh
Uptime
Ruptime
Rup
Hacer
Crea un archivo .rhosts con
permisos 600 en el directorio inicial
del administrador (root) en la
mquina destino. Se debe de poner
una lnea en el archivo nombrando
un host y usuario. Por ejemplo
rsh server1.ucol.mx root
Este
protocolo
habilita
la
autentificacin basada en RSA
usando .ssh/authorized_keys, e
iniciar el servicio sshd, deshabilitar
todas la conexiones remotas via
otros mtodos.
En cada servidor real, se habilita con
cualquier
comando
de
sincronizacin rsh o ssh.
Iniciar cada enrutador LVS y
servidor real el servicio rwhod
siempre que reinicie la mquina.
Iniciar cada enrutador LVS y
servidor real el servicio rstatd
siempre que reinicie la mquina.
Tabla 9. Herramientas de sincronizacin y monitoreo
Despus de haber descrito las partes elementales y el contenido del archivo

lvs.cf del clster, se proceder a explicar el proceso de instalacin.
94
4.2. Esquema de la implementacin
Para comprobar el objetivo de est tesis se llevo a cabo la implementacin de

un clster. El modelo que se emple para la construccin del clster, es el llamado
Balanceo de Carga Alta Disponibilidad, esto se refiere a tener una mquina
principal que acta como maestro o director principal del clster y balancear la carga
o el trfico de la red usando el software LVS, con un mnimo de requerimientos de
hardware, cuando redirecciona los paquetes usando enrutamiento NAT, las
direcciones privadas pueden ser usadas para reducir el nmero de direcciones IP
externas enrutables requeridas coma la direccin retornada por el servidor real a
travs del director principal.
Cuando se recibe una peticin el director principal toma una decisin a cual
servidor real enviar la peticin, todos los paquetes de esta conexin se
direccionarn al mismo servidor real para asegurar la integridad de la conexin entre
el usuario y el servidor real.
Para ver la eficiencia del clster se monto el sitio de la coordinacin general de

investigacin cientfica el cual tambin se encuentra en la pagina principal de la
Universidad de Colima.
El diagrama empleado para el clster se muestra en la figura 4.3.
95
Red Exterior / Internet
eth0:1 148.213.22.200
eth0:1 148.213.22.200
Router Principales
R = Router
Linux,
Direccionador
Trfico.
eth0 148.213.22.201
R1
R2
eth0- 148.213.22.202
S = Servidores
con servicio
http
eth1:1 192.168.1.254
eth1:1 192.168.1.254
eth1 192.168.1.2
eth1 192.168.1.1
Servidores Reales
Servidores Reales
Red interna / Intranet

Clase C / 192.168.1.0-254
S1
S2
S3
S4
S5
192.168.1.3
192.168.1.4
192.168.1.5
192.168.1.6
192.168.1.7
gw - 192.168.1.254
Figura 4.3. Diagrama del Clster Balanceo de Carga Alta disponibilidad
4.3. Instalacin
Ahora se tiene que buscar el hardware para construir el clster. De todas las
mquinas que se encontraban sin usar se recopil hardware para adecuar las
computadoras en un punto ptimo de funcionamiento. Se logr armar los CPUs de la
siguiente manera :
3 mquinas Venturis de Digital a 486 Mhz con 20 megas de RAM, disco duros
mximo de 1 gigabyte (estas mquinas no soportan discos duros mas
grandes) tarjetas de red a 10 megabits, sern utilizadas como nodos o
servidores reales
96
1 mquina Pentium a 150 Mhz con 64 megas RAM, un disco duro de 1.2
gigabytes de capacidad, 1 tarjeta de red a 10 megabits, de igual manera como
nodo o servidor real.
1 mquina Pentium a 200 Mhz con 128 megas de RAM, un disco duro 1.6
gigabytes de capacidad, tarjetas de red a 10 megabits, de igual manera como
nodo o servidor real.
1 mquina Pentium a 233 Mhz con 128 megas de RAM, un disco duro 2.0
gigabytes de capacidad, 2 tarjetas de red a 10 megabits cada una, seran
utilizadas como el enrutador principal.
1 mquina AMD K6 con 128 megas de RAM, un disco duro 1.6 gigabytes, 2
tarjetas de red a 10 megabits cada una, seran utilizadas como el enrutador de
respaldo principal.
1 concentrador 3com de 8 puertos velocidad a 10 Mbps.
Cable utp categora 5, Conectores arj 45 y pinzas para hacer los conectores.
Despus de configurar bien el hardware de las mquinas, y conectarlas segn

el diagrama presentado en la figura 4.3, y verificar su conectividad, se continuo con
la instalacin del sistema operativo base para un funcionamiento elemental en todas
las mquinas nodos o servidores reales. A cada mquina se le instal la versin de
Red Hat 6.2 con los mnimos requerimientos para que no ocupara mucho espacio del
disco duro y tener espacio necesario para las funciones del LVS.
En las mquinas venturis-486 no se necesita el entorno grfico debido a que

esas mquinas solamente tendrn los servicios de http, necesarios para el clster.
97
Algunos servicios que no son necesarios sern desinstalados para no tener paquetes
o servicios sin usarse.
Los servicios son :
Gpm
Servicio para la deteccin del Mouse.
Pcmcia
Servicio para los slots de laptop.
Lpd
Servicio de impresin
Xfs
Servicio de fuentes del modo grfico
telnet
protocolo para conectarse con otra mquinas, debido a que

se usar rsh o ssh.
En los enrutadores o nodos principales se instalar el S.O. en modo grfico, y

algunas utileras para un mejor funcionamiento y mantenimiento del clster.
En todas las mquinas se tiene que actualizar el S.O. para que el sistema
pueda tener un mejor desempeo con las actualizaciones instaladas. Los archivos
para la actualizacin se encuentran disponibles en el sitio de Red Hat seccin
actualizaciones. Los archivos en su mayora son con extensin rpm para una
actualizacin rpida.
Los archivos listados estn en el anexo 1.
Para la instalacin se utiliz el comando rpm de la siguiente forma:
rpm Uvh archivo_a_actualizar.rpm
En la mayora de los archivos no necesitan dependencias con otros,

solamente se actualizarn los mas indispensables.
98
Despus se ejecuta un archivo bash para mayor facilidad en la actualizacin

de los archivos y evitar teclear un comando por cada archivo que seria un proceso
muy largo, sumando el tiempo de la mquina y en ambas mquinas principal y de
respaldo. El archivo bash se presenta en el anexo 2.
Uno de los archivos mas importantes es el kernel o ncleo del sistema, ste
contiene mdulos necesarios para ejecutar el S.O. Las nuevas versiones del kernel
vienen con versiones actualizadas de los mdulos o caractersticas mejoradas en
comparacin de las anteriores. Con este archivo se debe de tener cuidado puesto
que si la instalacin o actualizacin no se hace correctamente el sistema puede
quedar inestable o inhabilitado para funcionar correctamente, por lo cual se tendra
que reinstalar otra vez.
La actualizacin del kernel no es necesario que sea en todas las mquinas

pero si en los enrutadores principal y de respaldo.
Se tienen dos opciones para esto, la primera es compilar el kernel para que
tenga las nuevas caractersticas o solamente instalar con la configuracin elemental
sin compilar.
Con la opcin 1.
Para compilar el kernel, se deben tener los fuentes del kernel que a
continuacin se describiran :
99
1. kernel-2.2.16-22.i386.rpm.
2. kernel-BOOT-2.2.16-22.i386.rpm.
3. kernel-source-2.2.16-22.i386.rpm.
4. kernel-headers-2.2.16-22.i386.rpm.
5. kernel-utils-2.2.16-22.i386.rpm.
6. kernel-ibcs-2.2.16-22.i386.rpm.
7. kernel-smp-2.2.16-22.i386.rpm.
8. kernel-pcmcia-cs-2.2.16-22.i386.rpm
9. kernel-doc-2.2.16-22.i386.rpm.
Este archivo contiene los fuentes

con la configuracin bsica.
Realiza el proceso para instalar
la nueva versin
Contiene los fuentes para
compilar con nuevos mdulos.
Contiene archivos para la
compilacin del kernel
Contiene archivos necesarios
para el kernel
Libreras para el Kernel
Estos son necesarios para
compilar el kernel o instalar la
nueva versin. Solo es necesario
cuando se tiene 2 procesadores
o
una
mquina
de
multiprocesamiento
Contiene los fuente para el
modulo de laptop de tarjeta
PCMCIA.
Contiene los fuentes para la
ayuda del kernel.
De estos archivos solo se necesitaran los primeros seis los dems son
irrelevantes. Despus ejecutamos los siguiente comandos..
rpm ihv kernel-headers-2.2.16-22.i386.rpm

rpm ihv kernel-utils-2.2.16-22.i386.rpm
rpm ihv kernel-ibcs-2.2.16-22.i386.rpm
rpm ihv kernel-source-2.2.16-22.i386.rpm
Despus de instalar los archivos fuentes y de dependencia, solo se necesitan

ejecutar algunos comando para compilar el kernel. Dentro del directorio donde se
instalaron los archivos para la nueva versin del kernel, /usr/src/linux-nueva_version/,
se teclea el siguiente comando :
100
make menuconfig
Este comando muestra el men de configuracin del kernel, desde aqu se da

soporte al hardware, protocolos etc., esta configuracin es compilada en una imagen
con la se inicio el sistema.
Pulsando "Enter"
Pulsando "Y"
Pulsando "M"
Pulsando "N"
Pulsando "?"
[*] <*>
[]<>
[M] <M>
Entramos en el men o submens.

Incluimos lo que seleccionemos como parte
del nuevo kernel.
Lo incluiremos como mdulo, esto es, se
compilar aparte y se cargara si queremos o
no y no ocupar espacio en el kernel.
Lo excluiremos del kernel.
Se nos mostrara informacin sobre el men u
opcin (se aconseja utilizarlo si no se sabe
que hace esa opcin)
Indica que la opcin ser compilada como
parte del kernel.
Indica que la opcin no esta incluida en el
kernel.
Indica que la opcin esta cargada como
mdulo.
Se deben elegir los mdulos que se instalarn, dejando atrs aquello que no
sea tan importante, a continuacin se almacena la configuracin en un archivo, y se
procede a compilar de nuevo el kernel con los comandos siguientes:
101
1. make dep
Con esto configuramos las dependencias del

kernel.
2. make clean
Para limpiar las "impurezas".
3. make bzImage
Esto crear una imagen del kernel compilada y

comprimida con bzip2, por lo cual obviamente
necesita
tener
instalado
bzip2,
en
/usr/src/linux/arch/i386/boot, en caso de
nuestra arquitectura sea 80x86. En caso
contrario en lugar de i386 estara en otro
directorio especifico para la arquitectura.
4. make modules
Con esto compilamos la nueva configuracin

seleccionada como modulos.
5. make modules_install
Y finalmente con esto otro instalaremos los

diversos modulos.
Si se desea poner todos los comandos en una sola lnea, se teclea lo siguiente:
make dep && make clean && make bzImage && make modules && make
modules_install
de esta manera se compila el nuevo kernel con los modulos agregados

correctamente, en caso de que las cosas no sean correctas se puede volver al
principio, haciendo una limpieza de la configuracin actual, basta con usar el
comando siguiente:
make mrproper
Al finalizar se tiene el nuevo kernel compilado, ahora solo falta instalarlo en la

seccin de boot o LILO (LInux LOader2).
http://www.dirac.org/linux/lilo/lilo.html
102
Opcin 2
Regresando a la opcin 2 el cual nos dice instalar el kernel con la

configuracin bsica es mas sencillo solo ejecutamos el comando.
rpm ihv kernel-2.2.16-22.i386.rpm.

rpm ihv kernel-BOOT-2.2.16-22.i386.rpm
Con esto se tiene instalado el nuevo kernel, pero no es muy recomendable

ejecutar el comando 2 ya que si algo no sale bien el sistema queda inhablitado. Este
comando agrega el nuevo kernel al LILO.
En ambas opciones 1 y 2, se tiene que instalar el LILO. Para configurar LILO e

iniciar con el nuevo kernel, necesitamos actualizar el archivo /etc/lilo.conf y ejecutar
el comando /sbin/lilo.
El archivo lilo.conf se muestra a continuacin:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux
image=/boot/vmlinuz- 2.2.14-5.0
label=linux
read-only
root=/dev/hda5
103
Para agregar el nuevo kernel en el LILO, se copia la seccin existente a partir

de image, en otra seccin nueva y se modifica el boot con el nuevo kernel. Tambin
se renombra la etiqueta de linux a linux-old. Se tiene que tener en cuenta que no se
esta actualizando ( eliminar la versin anterior y dejar la nueva) solamente se instalo
la nueva versin por si falla la instalacin del nuevo kernel se pueda entrar al sistema
con la versin antigua, el archivo /etc/lilo.conf quedara as:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux
image=/boot/vmlinuz- 2.2.16-22
label=linux
read-only
root=/dev/hda5
image=/boot/vmlinuz- 2.2.14-5.0
label=linux-old
read-only
root=/dev/hda5
ahora solo se ejecut el comando /sbin/lilo, para actualizar los cambios.
104
El siguiente paso es verificar si el nuevo kernel funciona o tiene incluido el

modulo de ip_masquerade e ip_vs, para que el clster funcione con el
direccionamiento o el enmascaramiento de los servidores virtuales, para esto
debemos verificar la versin del kernel por que en algunos ya viene incluido con el
comando siguiente se puede conocer la versin del kernel:
uname a
nos regresa la versin del kernel. (Linux 2.2.16-22 #1 Tue Aug

22 16:16:55 EDT 2000 i586 unknow )
por que en otras versiones del kernel 2.4.x es diferente la verificacin,
Dentro del directorio /proc/sys/net/ipv4/ con el comando ls se tendrn que listar

los archivos incluidos en el kernel estticamente o dinmicamente como sigue:
ip_always_defrag
ip_dynaddr
ip_forward
ip_masq_debug
ip_masq_udp_dloose
de igual manera en el directorio /proc/net los siguientes archivos:
ip_fwchains
ip_fwnames
ip_masquerade
app
icq
mfw
portfw
tcp
udp/
105
Si en caso de no tener los archivos listados anteriormente, en la mquina se

tendr que compilar el kernel con esta opcion (ip-masquerade) como lo describe Red
Hat en su seccin de cmo Masquerade IP3. Despus se debe verificar si el kernel
tiene la seccin de ip_vs, manejo de direcciones virtuales con el comando siguiente:
grep ip_vs_init /boot/System.map
este comando nos desplegar un mensaje como el que sigue :
c023b4d8 T ip_vs_init
En caso de que no regrese algo similar se tendr que aplicar un parche y
recompilar el kernel como lo describe el sitio de LinuxVirtualServer4.
Otra manera es verificar si existen los archivos para el manejo de direcciones

virtuales, en el directorio de modulos del kernel, /lib/modules/2.2.16-22/ipv4/ , con el
comando ls, los archivos son :
ip_vs_wrr.o
ip_vs_lc.o
ip_vs_rr.o
ip_vs_wlc.o
Pero como desde un principio se identific que el kernel no contiene los

archivos para trabajar con direcciones virtuales ip, se tendr que aplicar el parche y
recompilar para tener esta caracterstica.
Como primer paso se tendr que descargar el archivo o parche del sitio del
LinuxVirtualServer para agregar las funciones, los archivos y las opciones de
configuracin al men de configuracin del kernel que tenemos instalada.
3
http://www.redhat.com/mirrors/LDP/HOWTO/IP-Masquerade-HOWTO/
106
El archivo a descargar es segn la versin del kernel instalado, ipvs-0.9.152.2.16.tar.gz. Despus de descargar el archivo, se optar por descomprimir el parche
con los siguientes comandos:
gunzip ipvs-0.9.15-2.2.16.tar.gz
tar xvf ipvs-0.9.15-2.2.16.tar
Esto nos generara un directorio ipvs-0.9.15-2.2.16 que tendremos que mover

al directorio del kernel /usr/src/linux-2.2.16/ con el siguiente comando :
mv ipvs-0.9.15-2.2.16 /usr/src/linux-2.2.16/
y despus dentro del directorio, y se teclea el siguiente comando :
cat ipvs-0.9.15-2.2.16 /ipvs-0.9.15-2.2.16.patch | patch -p1
Ahora se recompilar el kernel con el comando make menuconfig, se

despliega el menu de configuracin y se desplaza a la seccion Code maturity level
options - y lo habilitamos como modulo esttico como se muestra a continuacin:
[*] Prompt for development and/or incomplete code/drivers
despus se desplaza a la seccin Networking options ---> y se habilitan los mdulos

de IPVS, como estticos y dinmicos como se muestra a continuacin :
http://www.linuxvirtualserver.org/index.html
107
[*] Network firewalls

....
[*] IP: firewalling
....
[*] IP: masquerading
....
[*] IP: masquerading virtual server support
(12) IP masquerading table size (the Nth power of 2)
<M> IPVS: round-robin scheduling
<M > IPVS: weighted round-robin scheduling
<M > IPVS: least-connection scheduling
<M > IPVS: weighted least-connection scheduling
....
[*] IP: aliasing support
Ahora se sale del men para empezar a compilar el kernel y nos preguntar si
guardamos los cambios que se hicieron, le decimos que si yes para que guarde la
configuracin del nuevo kernel. Y se contina con la compilacin del nuevo kernel
como se describi anteriormente. Como observacin solamente omitiremos el ltimo
paso de instalar el lilo por que lo nico que va a cambiar es el kernel pero no la
versin, este paso se realiza cuando se cambia de versin no cuando se modifica.
Ahora solo se debe reiniciar la mquina.
Despus de reiniciar la mquina con la versin modificada se verifica que los

archivos de IPVS se encuentren como se describi en la seccin anterior.
Un paso intermedio recomendable que es instalar un protocolo de seguridad

llamado SSH (Secure Shell)5 para que el sistema sea seguro en cuanto la
transferencia de datos entre las mquinas.
A cada mquina se le tendr que instalar el protocolo de seguridad SSH para

un mejor funcionamiento de seguridad. Debido a la capacidad de cada mquina ser
el tiempo de instalacin del protocolo, sin contar el tiempo de configuracin de los
servicios elementales.
5
http://www.openssh.com/
108
Para la instalacin del Protocolo SSH se instalarn las versiones 1.2 y 2.2
respectivamente, para la instalacin se ejecutarn los scripts :
./configure
make
make install
en cada versin, por lo tanto sern 6 comandos en total, considerando la velocidad

de cada mquina que tardar en compilar una versin, se tendr mucho tiempo libre.
Despus de instalar y esperar un tiempo razonable y verificar que la

comunicacin entre las mquinas con el protocolo SSH, funcione correctamente,
continuamos con la implementacin.
Ahora como ya se tienen habilitados en el kernel soporte para ip_vs y

ip_masquerade se tiene que instalar el software propio de Red Hat que se llama
Piranha que viene complementado con una interfaz grfica que nos ayudar en la
configuracin del clster mediante un navegador aunque esto se puede hacer en
modo texto editanto el archivo de configuracin del clster (/etc/lvs.cf) que se
describir mas adelante. Los archivos siguientes son los recomendados por Red Hat
para el funcionamiento del clster.
ipvsadm-1.1-2.i386.rpm
rpm-4.0-6x.i386.rpm
piranha-0.4.12-1.i386.rpm
piranha-docs-0.4.12-1.i386.rpm
piraa-gui-0.4.12-1.i386.rpm
Paquete para la administracin del

LVS
Paquete para un mejor
funcionamiento del LVS. Esta es una
actualizacin del paquete que se
instalar al inicio que es la versin 3.2.
Paquete para la administracin del
clster.
Documentacin del paquete
Paquete necesario para administrar
en modo grafico.
109
Para la mayora de los paquetes se usar el manejador de Red Hat rpm6. Con
los siguiente comandos
rpm U archivo
Sirve para actualizar el paquete.
rpm i archivo
Sirve para la instalacin del paquete.
Los comando son los siguientes:
rpm ihv piranha-0.4.12-1.i386.rpm

rpm ihv piranha-docs-0.4.12-1.i386.rpm
rpm ihv piraa-gui-0.4.12-1.i386.rpm
rpm Uvh rpm-4.0-6x.i386.rpm
rpm rebuilddb
Esto nos instalar el programa propio de Red Hat pero tendremos que habilitar
un pequeo parche el cual consiste en sustituir el programa ipvsadm de Red Hat por
uno general propuesto en el sitio de LinuxVirtualServer7., que es una utilidad para
administrar los servicios de IP de los servidores virtuales, este archivo de igual
manera se tiene que descargarlo del sitio.
El archivo es ipvsadm-1.12.tar.gz, de acuerdo a la versin del kernel instalada,

como se hizo anteriormente se descomprime el archivo con los comando gunzip y tar
xvf, esto nos generara un directorio ipvsadm-1.12 en el cual debemos acceder a el y
teclear los comandos :
make
make install
http://www.rpm.org/
110
Esto instalar la aplicacin ipvsadm que se manejar mas adelante. Cabe

mencionar que Red Hat tiene su propio archivo ipvsadm que se instala con el
software piranha, (ipvsadm-1.1-2.i386.rpm), pero tiene ciertos problemas con el
manejo de los servicios del clster r, por eso la instalacin de este archivo se hace
por separado.
Ahora se hace una liga simblica desde donde encuentra el archivo a donde
es buscado por el software piranha, este archivo lo instala por default en el directorio
/usr/sbin/ipvsadm, el cual debemos borrar o mover de ese directorio, pero la nueva
versin que se instal ipvsadm-1.12 lo instala en el directorio /sbin/ipvsadm, con el
siguiente comando :
ln -sf /sbin/ipvsadm /usr/sbin/ipvsadm
As se tendr la nueva versin instalada del Sitio LinuxVirtualServer, como si

fuera una versin de Red Hat. Despus de tener instalado el software necesario para
trabajar con un clster, se procede a la configuracin del clster.
Un punto importante que se debe mencionar es que Red Hat crea su software
para una versin especifica, es este caso trabajamos con la versin 6.2.
http://www.linuxvirtualserver.org/index.html
111
4.4. Configuracin
Se debe identificar las mquinas previamente instaladas, cuales son los

enrutadores y cuales son los servidores reales. Para configurar los servidores reales
que tengan una IP de clase C 192.168.1.3 hasta 192.168.1.7 respectivamente con el
comando ifconfig de la siguiente manera :
Ifconfig eth0 192.168.1.3 255.255.255.0
Se repite este comando en cada mquina que funcionar como servidor real
variando el ultimo digito. En cuanto a los enrutadores principales se ejecuta el mismo
comando con el digito 1 y 2 respectivamente. Tambin en los mismos enrutadores se
debe establecer las direcciones pblicas que nos darn salida a internet, con el
comando ifconfig .
Ifconfig eth1 148.213.22.201 255.255.255.0

Ifconfig eth1 148.213.22.202 255.255.255.0
Previamente a estas mquinas se les instalaron 2 tarjetas de red, identificando

cual es la tarjeta 1 como eth0 y la 2 como eth1. Mencionando que la direccin 201 es
para el router principal y 202 para el router de respaldo. Tambin debemos de
agregar nuestro IP flotante o virtual a la tarjeta de red con el comando siguiente:
Ifconfig eth0:0 148.213.22.200
Ahora se verificara que los servicios de red establecidos, tomaron las

direcciones IP correctamente mediante el reinicio del servicio de red, con el comando
siguiente :
/etc/rc.d/init.d/network restart.
112
Despus se debe asignar la configuracin del enrutador de salida de la red

privada en el enrutador principal, y los servidores reales con el comando siguiente:
route add default gw 192.168.1.254
Despus en cada servidor real se debe indicar que su enrutador o direccin de

salida es la 192.168.1.254 en el siguiente archivo:
/etc/sysconfig/networks
NETWORKING=yes
HOSTNAME="server5.cgic.ucol.mx"
GATEWAY="192.168.1.254"
GATEWAYDEV="eth0"
FORWARD_IPV4="yes"
Se reinicia el servicio de red en cada servidor con el comando siguiente :
/etc/rc.d/init.d/network restart
Se verifica lo que se hizo en el enrutador principal y los nodos asi :
ping 192.168.1.254
Este nos retornara un mensaje de respuesta correcto o incorrecto.
Un punto que se tiene que considerar es la comunicacin entre el clster y los

servidores reales, el clster no enva parmetros al momento de hacer una peticin,
por lo que tenemos que habilitar el acceso remoto del administrador (root) en todas
las maquinas, por medio de una terminal, de la siguiente manera, en el archivo
/etc/pam.d/login quitar la linea siguiente
113
auth
required
/lib/security/pam_security.so
Este paso se tiene que hacer en todos los servidores reales para habilitar el
accesos remoto pero cuidado por que esto puede ser peligroso, debemos de habilitar
un firewall para que no tener intrusos en la red interna.
Otra manera de habilitar el acceso remoto en los nodos como administrador o

root es realizar los siguientes pasos :
Ejecutar el script localizado /usr/sbin/piranha-passwd, instalado con el

software de piranha, para establecer un password al login de piranha para la
Interface Web piranha.
Editar el archivo /etc/hosts y agregar entradas para cada uno de los servidores
reales y los enrutadores
Editar el archivo /etc/hosts.allow y habilitar el acceso a los servicios

apropiados para todos los nodos del clster.
Editar el archivo /root/.rhosts y agregar entradas para cada uno de los nodos
del clster tambin la cuenta de administrador root, puede ser usada con rsh y
rcp.
Ahora se puede probar la conexin entre las mquinas con el nombre, y tambien
probar los diferentes comandos ping, rsh, ssh, rcp respectivamente, de la siguiente
manera.
ping server1
rsh server1
ssh server1
rcp archivo server1:/tmp/archivo
114
Si alguno de los comandos no funciona se debe investigar el motivo y

habilitarlos para que funcionen correctamente, considerando que los comandos de
sincronizacin funcionen correctamente rsh o ssh.
El siguiente paso es configurar el servidor apache editando el archivo

/etc/httpd/conf/httpd.conf y poniendo el nombre del servidor en el rengln de
ServerName, ademas verificamos en este mismo archivo si las entradas de piranha y
php estan presentes en la secciones de <Directory> y <Modules>, de la siguiente
manera:
<Directory /home/httpd/html/piranha>
Option All
AllowOverride All
</Directory>
LoadModule php3_module
modules/libphp3.so
AddModule mod_php3.c
.
.
<IfModule mod_php3.c>
AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps
</IfModule>
Otro modificacin en el mismo archivo es la seccin Servidor Virtual donde

ponemos la direccin IP de la mquina y el directorio donde queda habilitado el sitio
de la siguiente manera:
115
NameVirtualHost 148.213.22.200
<VirtualHost _default_:*>
DocumentRoot /home/httpd/html/
</VirtualHost>
despus reiniciamos el servicio de apache de la siguiente manera:
/etc/rc.d/init.d/apache restart
Ahora el servicio de apache est configurado, se puede probar si funciona en

nuestro browser poniendo en la lnea de url, http://localhost/piranha/ en el enrutador
principal del clster y el de respaldo, suponiendo que el login es piranha y el
password es el que se habilito en pasos anteriores. Esta configuracin servir mas
adelante para configurar el clster grficamente.
Para habilitar el redireccionamiento de paquetes editamos el archivo

/etc/sysctl.conf en cada enrutador LVS, que contiene las siguientes lneas:
net.ipv4.ip_forward = 0
net.ipv4.ip_always_defrag = 0
y lo cambiamos a 1 o podemos escrbir en la linea de comandos lo siguiente :
echo 1 > /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/ip_always_defrag
Verificamos si el paquete de ipchains est instalado, el cual ayudara al

enmascaramiento de direcciones desde los servidores reales a las direcciones IP
pblicas, con el comando siguiente :
116
rpm q ipchains
Si regresa un listado bingo! est instalado, de lo contrario hay que instalarlo

desde el disco de instalacin en el directorio /mnt/cdrom/RedHat/RPMS con el
comando:
rpm ihv ipchains
Ahora solo queda activar las reglas de ipchains con los siguientes comandos :
ipchains -A forward -s 192.168.1.0/24 -j MASQ

ipchains -A input -j REDIRECT 80 -d 192.168.1.0/24 80 -p tcp
Con el primer comando agregamos una nueva regla (-A) para reenviar desde
la fuente (-s), con la regla MASQ (-j), con el segundo agregamos una entrada (-A)
con la regla REDIRECT (-j) hacia el destino (d)
con el protocolo (-p), estos
comandos se deben poner en el archivo /etc/rc.d/rc.local para que la mquina los

ejecute cuando est se reinicie.
Ahora en los servidores reales se deben habilitar los servicios que se usaran
en el clster como http y ftp, puertos 80 y 21 respectivamente, con el comando para
reiniciar los servicios en el directorio /etc/rc.d/init.d/http restart y /etc/rc.d/init.d/ftp
restart,
Regresando a los enrutadores principales, aqu se debe agregar las reglas

para la herramienta de configuracin de piranha ipvsadm con los siguientes
comandos :
117
ipvsadm -A -t 148.213.22.200:80 -s rr
ipvsadm -a -t 148.213.22.200:http -r 192.168.1.3:http -m -w 1
ipvsadm -a -t 148.213.22.200:80 -r 127.0.0.1
ipvsadm save
Con estos comandos le decimos a la herramienta que tenemos 5 servidores

reales, con un algoritmo de tarea de Round Robin, en el servicio de http.
Otro punto a considerar es activar los servicios de rwhod, rstatd y pulse en

todas las mquinas con los comandos siguientes:
chkconfig --level 345 rwhod on

chkconfig --level 345 rstatd on
chkconfig --level 345 pulse on
/etc/rc.d/init.d/rwhod restart
/etc/rc.d/init.d/rstatd restar
/etc/rc.d/init.d/pulse restar
Solo queda presentar el archivo lvs.cf como qued configurado para que
funcione el clster, tomando como base el mostrado por Red Hat y poniendo las
configuraciones que se explicaron anteriormente :
118
# Inicio del Archivo /etc/lvs.cf
primary = 148.213.22.201
service = lvs
rsh_command = rsh
backup_active = 0
backup = 148.213.22.202
heartbeat = 1
heartbeat_port = 539
keepalive = 6
deadtime = 18
network = nat
nat_router = 192.168.1.254 eth1:1
virtual cluster {
active = 1
address = 148.213.22.200 eth0:1
port = 80
send = "GET / HTTP/1.0\r\n\r\n"
expect = "HTTP"
load_monitor = ruptime
scheduler = wlc
protocol = tcp
timeout = 6
reentry = 15
server server1 {
address = 192.168.1.3
active = 1
weight = 1000
}
119
server server2 {
address = 192.168.1.4
active = 1
weight = 1000
}
server server3 {
address = 192.168.1.5
active = 1
weight = 1000
}
server server4 {
address = 192.168.1.6
active = 1
weight = 1000
}
server server5 {
address = 192.168.1.7
active = 1
weight = 1000
}
server localhost {
address = 127.0.0.1
active = 1
weight = 1
}
}
120
Ahora el clster funciona correctamente pero con una limitante, su sistema de

archivos, esto es en cada maquina tiene su propio espacio y despliega su propia
informacin del directorio /home/httpd/html/ y no una general para todo el clster,
para solucionar esto existen varios sistemas de archivos NFS, samba y CODA, que
nos ayuda a que un directorio compartido sea comn para todas las maquinas.
De los sistemas de archivos el mas general y optimo para nuestra aplicacin

es samba por que no necesita muchos archivos de configuracin y tipos de particin
como lo exige CODA, y tampoco habilitar muchos servicios de red, como lo exige
NFS, samba al igual que piranha solo necesita 3 archivos, uno para el cliente, otro
para el servidor y uno comn para ambos. Y su configuracin es fcil de entender.
Para la instalacin de samba en el cliente, los servidores reales, solo se

necesitan instalar 2 archivos rpm, con los siguientes comandos :
rpm ihv samba-common-2.0.6-9.i386.rpm

rpm ihv samba-client-2.0.6-9.i386.rpm
Para la instalacin de samba en el enrutador principal, al igual que el cliente 2

archivos rpm, que se ejecutan los siguientes comandos:
rpm ihv samba-2.0.6-9.i386.rpm

rpm ihv samba-common-2.0.6-9.i386.rpm
En el enrutador tenemos que editar el archivo /etc/smb.conf especificar cual

va ser el grupo de trabajo y el directorio a compartir en este caso /home/httpd/html/.
121
# workgroup = NT-Domain-Name or Workgroup-Name

workgroup = CGIC
.....
[html]
comment = Public Stuff
path = /home/httpd/html/.
public = yes
writable = yes
Otro punto importante es la sincronizacin de los usuarios y el password del

S.O. con samba, en el mismo archivo de configuracin eliminamos el ; (punto y
coma) para habilitarlo de la siguiente forma :
# You may wish to use password encryption. Please read

# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
encrypt passwords = yes
; smb passwd file = /etc/smbpasswd
Tambien se debe agregar un usuario de samba en el archivo /etc/smbusers, y

otro usuario al sistema principal con el comando adduser usuario, ademas
necesitamos darle un password al usuario de samba mediante el comando
smbpasswd usuario, y al usuario del sistema passwd usuario, usando clster en
ambos casos y como password.
Despus se debe reiniciar el servicio de samba mediante el comando :
/etc/rc.d/init.d/smb restart
122
Ahora se tiene funcionando el servicio de samba en servidor, queda solo

desde el cliente montar el directorio compartido por el servidor principal mediante el
comando:
smbmount //routerr1/cluster /home/httpd/html -o username=cluster,password=cluster
Si el comando manda un error se debe verificar en el servidor la configuracin,

de lo contrario con el comando df se visualizara si el directorio compartido por el
servidor est en la mquina cliente. Los pasos para instalar el cliente se deben
ejecutar en cada servidor.
Tambien en el servidor podemos ver las maquinas conectadas al directorio

compartido con el comando smbstatus.
Bien es todo el sistema de archivos est instalado y todos los servidores

funcionan desplegando una sola informacin.
123
Captulo V Conclusiones
CAPTULO V. CONCLUSIONES
Parece sencillo llegar a este punto en el cual un clster de balanceo de carga

funciona en forma correcta y mas elemental, pero esta implementacin da una idea
de cmo funciona, como se construye y el material que se necesita para su
construccin.
Dentro de los puntos relevantes a mencionar son :
1. No es fcil construir un cluster debido a que los manuales no tienen todos

los puntos a seguir para la construccin los cules omiten muchos pasos.
2. Antes de construir algo se tiene que leer lo suficiente para poder empezar
con una idea de cmo se construye.
3. El cluster necesita un hardware idneo, como pueden ser las tarjetas de

red y el concentrador de mayor velocidad u otro tipo de conexin, para
mejorar velocidad de respuesta y transferencia del cluster, otro tipo de
dispositivo son los discos duros, la memoria RAM, entre otras cosas.
4. La unidad de respaldo de energa, No break, es importante debido a que

una falla de energa externa puede desconfigurar el cluster, cuando se
apaguen las computadoras y funcione al 50% debido al fallo de corriente.
5. La manera de distribuir las peticiones es eficiente entre las otras mquinas

del cluster.
124
Ahora se mostrarn los pasos cuando un usuario navega por el cluster, el sitio
publicado o de prueba. Esto con ayuda del software piranha, la imgenes
siguientes nos muestran estos pasos :
B
C
Figura 5.1 Estado del cluster sin ninguna peticin.
Existe un programa para visualizar el estado del clster como mencionamos

en los captulos anteriores llamado Piranha. Con este programa nos damos cuenta si
el clster est funcionando y como est distribuyendo la carga de las peticiones y ver
las conexiones activas. En la figura 5.1 inciso A se muestra el nmero de mquinas o
servidores reales que se encuentran funcionando en el cluster, y sus direcciones IP
internas, en el inciso B muestra que los servidores reales no tienen ninguna peticin
lo cual significa que el cluster est inactivo, en el inciso C vemos los procesos LVS
que son los componentes de cluster ipvsadm, nanny y pulse, el clster tiene un
tiempo de espera para responder a las peticiones y si no encuentra ninguna se pone
es un estado de inactivo.
125
Para probar como funciona el programa piranha se puede abrir un navegador

y solicitando una peticin al cluster de una pgina del sitio de prueba nos daremos
cuenta, como se comporta esta peticin. La figura 5.2 muestra la pgina cuando se
hace una peticin al clster de una pgina html en un directorio especifico.
Figura 5.2. Solicitud de peticin al cluster desde un navegador.
La figura 5.3, muestra el estado del cluster cuando ha detectado una peticin.
126
Figura 5.3. Estado del cluster detectando una peticin.
Despus de que el cluster detecta la peticin abre una conexin activa que
identifica a donde va a enviar las peticiones a distribuir y enviarlas a la mquina
fuente desde donde se hizo la peticin como muestra la figura 5.4. Esto agiliza ms
el direccionamiento y enmascaramiento del servicio Web de los servidores reales en
el clster, y el usuario que no lo detecta.
127
Figura 5.4. Estado del cluster con una peticin activa y una peticin.
Ya identificando la conexin, el cluster puede enviar ms rpido las peticiones

a la mquina fuente debido a que identifica la peticin fuente, esta conexin puede
hacer muchas peticiones no importa la cantidad, la figura 5.5 muestra el estado de
clster al identificar las n peticiones de una conexin activa.
128
Figura 5.5. Estado del cluster con muchas peticiones distribuidas en las maquinas y una conexin activa.
Tambin el cluster tiene un tiempo de espera para las peticiones, si no

encuentra una peticin de una conexin activa pierde la conexin y espera otra
solicitud, para no perder tiempo, y queda libre para la siguiente solicitud como lo
muestra la figura 5.6.
129
Figura 5.6. Estado del cluster con muchas peticiones y ninguna conexin activa.
La figura 5.7 muestra cuando una conexin activa deja de hacer

peticiones al cluster, el cluster pone el estado de inactiva a esa conexin.
130
Figura 5.7. Estado del cluster con una peticin activa.
De esta manera identificamos como el cluster balancea las peticiones en las

otras mquinas.
Tambin otra prueba es el tiempo de respuesta que tiene el sitio de la

coordinacin general de investigacin cientfica en el portal de la universidad de
colima, y el tiempo de respuesta del cluster con el sitio de prueba.
Para eso se ingres a una liga o url dentro del clster y se midi la respuesta,
a continuacin en la tabla 10 se muestran los tiempos y en la figura 5.1 se muestra la
grfica de los valores.
131
Cluster
Liga o URL
Sitio U de C
Tiempo en
Tiempo del
Tiempo en
Tiempo del
Segundos
Botn
Segundos
Botn
Regresar
Pagina principal del Cluster
2:01
Sitio CGIC
Regresar
0:03:01
Reload 0:03:90
Informacin General de CGIC
0:04:79
0:02:19..
0:01:10
0:01:92
Misin y Visin de CGIC
0:01:16
0:03:81
0:01:00
0:02:31
Verano Investigacin de CGIC
0:01:09
0:03:62
0:01:01
0:02:35
Centro de Investigacin CUIDA
Excedido > 1:00
0:04:12
0:01:34
0:02:44
Reload 0:18:19
IUIJ
0:02:57
0:03:05
0:01:56
0:02:68
CUIS
0:01:54
0:04:03
0:01:44
0:02:66
CEAO
0:01:79
00:03:22
0:01:31
0:02:47
CUIB
0:01:72
0:03:16
0:01:19
0:02:60
Dentro del Sitio CUIB
0:01:32
0:01:10
Profesores
0:02:76
0:01:31
reas de estudio
0:01:71
0:01:02
Investigadores Nivel III
0:01:01
0:02:59
0:01:19
0:02:79
Nivel I
0:00:94
0:02:03
0:01:03
0:02:39
Investigadores U de C Biologa
0:01:10
0:02:94
0:01:00
0:02:35
0:01:22
0:03:38
0:01:19
0:02:25
Investigadors rea 1
0:02:03
0:03:47
0:01:00
0:02:31
rea 6
0:02:29
0:03:04
0:01:03
0:02:19
Proyectos 2000
0:01:22
0:03:69
0:01:09
0:02:32
Proyectos 2004
Excedido > 1:00
0:03:38
0:01:50
0:02:41
0:01:37
0:03:34
0:01:10
0:02:50
0:08:79
0:04:06
0:14:82
0:03:66
y Qumica
Sociales
Econmico
administrativas
Reload 0:00:97
Proyectos FRABA Historia
FRABA Conv 05
Tabla 10. Tiempos de acceso a las paginas del sitio
132
133
En el sitio cluster tarda en ocasiones mas de un minuto al hacer la conexin

por primera vez, pero una vez conectado se comporta muy rpido, algunas otras
veces el cluster no identifica a que servidor real hacer la peticin y debido a eso su
tiempo se excede del minuto y se tiene que volver a solicitar la peticin, un reload,
para que retorne la peticin de manera normal menos de 5 segundos.
Como se puede observar el sitio cluster, no es muy lento en su tiempo de

respuesta un aproximado del 20 al 30 por ciento mas lento que el sitio web de la
Universidad de Colima, considerando que el clster son varias mquinas con
microprocesadores pequeos 486 y Pentium I a 150 Mhz, la memoria no excede en
30 Megas y la velocidad de su red interna y de salida es a 10 Mbps, comparada con
la mquina donde se almacena el sitio Web de la Universidad de Colima una Sun
con un microprocesador a 1.5 GHz, su memoria RAM de 1 Ghz, y la velocidad de red
es a 100 Mbps, que es una mquina muy rpida, y nos damos cuenta que una sola
mquina con caractersticas mnimas nunca alcanzar la eficiencia de una mquina
grande pero al unir todas en conjunto podra expresarse que si, que es lo que
estamos buscando implementar con este documento.
Claro que si se instalar a una mejor versin del software S.O., mayor
cantidad de equipos hardware y mejor velocidad interna y de salida a 100 Mbps, se
tendra un mejor clster.
Aqu se documenta lo que es un clster, desde su historia hasta lo que es una

derivacin, un Servidor Virtual, viendo las distintas derivaciones que puede tener, las
distintas plataformas que pueden utilizar, y la aplicacin que pueden tener en
general. Dentro de lo que es Servidor Virtual se describieron los tipos de balanceo de
carga, los modos de distribucin, su funcionamiento, la alta disponibilidad, la
redundancia que puede tener el cluster.
134
En la implementacin no es fcil, se debe leer mucho para entender el

funcionamiento bsico antes de empezar. Y la configuracin se realiz ms rpido
cuando se comprendi el concepto original, agrupar para tener un mejor nivel de
eficiencia.
El clster es una alternativa para sitios donde no se puede obtener el

financiamiento necesario para la compra de equipos.
135
136
Comparacin de los Accesos

ACCESO AL CLUSTER
REGRESAR
ACCESO AL SITIO PRINP U. DE C.
REGRESAR
2.500
1.500
1.000
0.500
Pginas Accesadas
Figura 5.1. Grfica de los valores de acceso a las ligas.
FRABA Conv
05
Proyectos 2000
Investigadors
rea 1
Investigadores
U de C
Investigadores
Nivel III
Profesores
CUIB
CUIS
Verano
Investigacin
Informacin
General de
0.000
Pagina
principal del
Tiempo en segundos
2.000
Anexos
ANEXOS
ANEXOS 1. Listado de Archivo a actualizar descargados del sitio de Red Hat.
SysVinit-2.78-5.i386.rpm
VFlib2-2.25.1-11.6x.i386.rpm
Vflib2-VFjfm-2.25.1-11.6x.i386.rpm
VFlib2-devel-2.25.1-11.6x.i386.rpm
WindowMaker-0.61.1-2.3.i386.rpm
XFree86-100dpi-fonts-3.3.629.i386.rpm
XFree86-3.3.6-29.i386.rpm
XFree86-3DLabs-3.3.6-29.i386.rpm
XFree86-75dpi-fonts-3.3.6-
XFree86-8514-3.3.6-29.i386.rpm
29.i386.rpm
XFree86-AGX-3.3.6-29.i386.rpm
XFree86-FBDev-3.3.6-29.i386.rpm
XFree86-I128-3.3.6-29.i386.rpm
XFree86-Mach32-3.3.6-29.i386.rpm
XFree86-Mono-3.3.6-29.i386.rpm
XFree86-P9000-3.3.6-29.i386.rpm
XFree86-S3-3.3.6-29.i386.rpm
XFree86-S3V-3.3.6-29.i386.rpm
XFree86-SVGA-3.3.6-29.i386.rpm
XFree86-VGA16-3.3.6-29.i386.rpm
XFree86-W32-3.3.6-29.i386.rpm
XFree86-XF86Setup-3.3.629.i386.rpm
XFree86-Xnest-3.3.6-29.i386.rpm
XFree86-Xvfb-3.3.6-29.i386.rpm
XFree86-cyrillic-fonts-3.3.6-
XFree86-devel-3.3.6-29.i386.rpm
29.i386.rpm
XFree86-doc-3.3.6-29.i386.rpm
XFree86-libs-3.3.6-29.i386.rpm
XFree86-xfs-3.3.6-29.i386.rpm
apache-1.3.27-1.6.2.i386.rpm
apache-devel-1.3.27-1.6.2.i386.rpm
apache-manual-1.3.27-1.6.2.i386.rpm
arpwatch-2.1a11-11.6.2.2.i386.rpm
at-3.1.8-22.2.i386.rpm
auth_ldap-1.4.0-3.i386.rpm
bash-1.14.7-23.6x.i386.rpm
bind-9.2.1-0.6x.3.i386.rpm
bind-devel-9.2.1-0.6x.3.i386.rpm
bind-utils-9.2.1-0.6x.3.i386.rpm
cvs-1.11.1p1-8.6.i386.rpm
137
Anexos
db3-3.1.17-4.6x.i386.rpm
db3-devel-3.1.17-4.6x.i386.rpm
db3-utils-3.1.17-4.6x.i386.rpm
diffutils-2.7-22.6x.i386.rpm
dump-0.4b19-5.6x.1.i386.rpm
dump-static-0.4b19-5.6x.1.i386.rpm
ed-0.2-19.6x.i386.rpm
elm-2.5.5-0.62.i386.rpm
emacs-20.7-1.i386.rpm
emacs-X11-20.7-1.i386.rpm
emacs-el-20.7-1.i386.rpm
emacs-leim-20.7-1.i386.rpm
emacs-nox-20.7-1.i386.rpm
enscript-1.6.1-16.1.i386.rpm
esound-0.2.20-0.i386.rpm
esound-devel-0.2.20-0.i386.rpm
fetchmail-5.9.0-21.6.2.i386.rpm
fetchmailconf-5.9.0-21.6.2.i386.rpm
file-3.39-8.6x.i386.rpm
fileutils-4.0-21.1.i386.rpm
gdm-2.0beta2-26.i386.rpm
gftp-2.0.8-1.i386.rpm
ghostscript-6.51-16.1.6x.1.i386.rpm
glibc-2.1.3-29.i386.rpm
glibc-devel-2.1.3-29.i386.rpm
glibc-profile-2.1.3-29.i386.rpm
gnorpm-0.95.1-6.6x.i386.rpm
gnupg-1.0.6-0.6.x.i386.rpm
gnuplot-3.7.1-5.i386.rpm
gpm-1.19.3-0.6.x.i386.rpm
gpm-devel-1.19.3-0.6.x.i386.rpm
gv-3.5.8-18.6x.i386.rpm
imap-2001a-1.62.0.i386.rpm
imap-devel-2001a-1.62.0.i386.rpm
imlib-1.9.13-3.6.x.i386.rpm
imlib-cfgeditor-1.9.13-3.6.x.i386.rpm
imlib-devel-1.9.13-3.6.x.i386.rpm
inetd-0.16-7.i386.rpm
ipmasqadm-0.4.2-2.src.rpm
iputils-20001010-1.6x.i386.rpm
ipvs-0.9.15-2.2.16
ipvs-0.9.15-2.2.16.tar
ipvs-1.0.8-2.2.19.tar
ipvsadm-1.15-1.src.rpm
ircii-4.4M-1.i386.rpm
ispell-3.1.20-27.i386.rpm
ispell-catalan-3.1.20-27.i386.rpm
ispell-czech-3.1.20-27.i386.rpm
ispell-danish-3.1.20-27.i386.rpm
ispell-dicts-3.1.20-27.i386.rpm
ispell-dutch-3.1.20-27.i386.rpm
ispell-esperanto-3.1.20-27.i386.rpm
ispell-french-3.1.20-27.i386.rpm
ispell-german-3.1.20-27.i386.rpm
ispell-greek-3.1.20-27.i386.rpm
ispell-italian-3.1.20-27.i386.rpm
ispell-norwegian-3.1.20-27.i386.rpm
ispell-polish-3.1.20-27.i386.rpm
ispell-portuguese-3.1.20-
ispell-russian-3.1.20-27.i386.rpm
138
Anexos
27.i386.rpm
ispell-spanish-3.1.20-27.i386.rpm
ispell-swedish-3.1.20-27.i386.rpm
joe-2.8-43.62.i386.rpm
kernel-2.2.16-22.i386.rpm
kernel-BOOT-2.2.16-6.2.3.i386.rpm
kernel-doc-2.2.16-22.i386.rpm
kernel-headers-2.2.16-22.i386.rpm
kernel-ibcs-2.2.16-22.i386.rpm
kernel-pcmcia-cs-2.2.16-
kernel-smp-2.2.16-22.i386.rpm
22.i386.rpm
kernel-source-2.2.16-22.i386.rpm
kernel-utils-2.2.16-22.i386.rpm
krb5-configs-1.1.1-40.i386.rpm
krb5-devel-1.1.1-40.i386.rpm
krb5-libs-1.1.1-40.i386.rpm
krb5-server-1.1.1-40.i386.rpm
krb5-workstation-1.1.1-40.i386.rpm
libpcap-0.6.2-11.6.2.2.i386.rpm
libpng-1.0.14-0.6x.4.i386.rpm
libpng-devel-1.0.14-0.6x.4.i386.rpm
libtiff-3.5.5-2.i386.rpm
libtiff-devel-3.5.5-2.i386.rpm
lista
logrotate-3.5.2-0.6.i386.rpm
losetup-2.10r-0.6.x.i386.rpm
lpr-0.50.5-1.i386.rpm
lynx-2.8.3-2.1.i386.rpm
mailx-8.1.1-16.i386.rpm
man-1.5i2-0.6x.5.i386.rpm
mgetty-1.1.25-4.6.i386.rpm
mgetty-sendfax-1.1.25-4.6.i386.rpm
mgetty-viewfax-1.1.25-4.6.i386.rpm
mgetty-voice-1.1.25-4.6.i386.rpm
minicom-1.83.1-1.0.6x.i386.rpm
mktemp-1.5-2.1.6x.i386.rpm
mod_perl-1.23-3.i386.rpm
modutils-2.3.21-0.6.2.i386.rpm
mount-2.10r-0.6.x.i386.rpm
mutt-1.2.5.1-0.6.i386.rpm
ncurses-5.0-12.i386.rpm
ncurses-devel-5.0-12.i386.rpm
netscape-common-4.770.6.2.i386.rpm
netscape-communicator-4.77-
netscape-navigator-4.77-
0.6.2.i386.rpm
0.6.2.i386.rpm
nfs-utils-0.3.1-0.6.x.1.i386.rpm
nscd-2.1.3-29.i386.rpm
nss_ldap-189-3.6.i386.rpm
openldap-1.2.13-2.i386.rpm
openldap-clients-1.2.13-2.i386.rpm
openldap-devel-1.2.13-2.i386.rpm
openldap-servers-1.2.13-2.i386.rpm
openssl-0.9.5a-33.i386.rpm
139
Anexos
openssl-devel-0.9.5a-33.i386.rpm
openssl-perl-0.9.5a-33.i386.rpm
openssl-python-0.9.5a-33.i386.rpm
pam-0.72-20.6.x.i386.rpm
perl-5.00503-12.i386.rpm
php-3.0.18-8.i386.rpm
php-imap-3.0.18-8.i386.rpm
php-ldap-3.0.18-8.i386.rpm
php-manual-3.0.18-8.i386.rpm
php-pgsql-3.0.18-8.i386.rpm
pine-4.44-1.62.1.i386.rpm
piranha-0.4.14-1.i386.rpm
piranha-docs-0.4.14-1.i386.rpm
piranha-gui-0.4.14-1.i386.rpm
popt-1.6.2-6x.i386.rpm
postgresql-6.5.3-7.3.i386.rpm
postgresql-devel-6.5.3-7.3.i386.rpm
postgresql-jdbc-6.5.3-7.3.i386.rpm
postgresql-odbc-6.5.3-7.3.i386.rpm
postgresql-perl-6.5.3-7.3.i386.rpm
postgresql-python-6.5.3-
postgresql-server-6.5.3-7.3.i386.rpm
7.3.i386.rpm
postgresql-tcl-6.5.3-7.3.i386.rpm
postgresql-test-6.5.3-7.3.i386.rpm
procmail-3.21-0.62.i386.rpm
pxe-0.1-31.100.6.2.i386.rpm
python-1.5.2-43.62.i386.rpm
python-devel-1.5.2-43.62.i386.rpm
python-docs-1.5.2-43.62.i386.rpm
python-popt-0.8.8-6.x.1.i386.rpm
python-tools-1.5.2-43.62.i386.rpm
python-xmlrpc-1.5.1-6.x.7.i386.rpm
rc.firewall-2.2.txt
rhn_register-2.8.27-1.6.2.i386.rpm
rhn_register-gnome-2.8.27-
rhs-printfilters-1.63-4.rh6.2.i386.rpm
1.6.2.i386.rpm
rmt-0.4b19-5.6x.1.i386.rpm
rpm-4.0.2-6x.i386.rpm
rpm-build-4.0.2-6x.i386.rpm
rpm-devel-4.0.2-6x.i386.rpm
rpm-python-4.0.2-6x.i386.rpm
rsync-2.4.6-3.6.i386.rpm
rxvt-2.7.8-3.6.2.1.i386.rpm
samba-2.0.10-1.62.i386.rpm
samba-client-2.0.10-1.62.i386.rpm
samba-common-2.0.10-1.62.i386.rpm
sendmail-8.11.6-1.62.3.i386.rpm
sendmail-cf-8.11.6-1.62.3.i386.rpm
sendmail-doc-8.11.6-
sgml-tools-1.0.9-6.2.i386.rpm
1.62.3.i386.rpm
sharutils-4.2.1-2.6.x.i386.rpm
slocate-2.4-0.6.x.i386.rpm
slrn-0.9.6.4-0.6.i386.rpm
slrn-pull-0.9.6.4-0.6.i386.rpm
140
Anexos
squid-2.4.STABLE6-6.6.2.i386.rpm
sysklogd-1.3.31-17.i386.rpm
tar-1.13.25-1.6.i386.rpm
tcpdump-3.6.2-11.6.2.2.i386.rpm
tcsh-6.10-0.6.x.i386.rpm
telnet-0.17.6x-18.i386.rpm
telnet-server-0.17.6x-18.i386.rpm
tetex-1.0.6-11.3.i386.rpm
tetex-afm-1.0.6-11.3.i386.rpm
tetex-doc-1.0.6-11.1.i386.rpm
tetex-dvilj-1.0.6-11.3.i386.rpm
tetex-dvips-1.0.6-11.3.i386.rpm
tetex-fonts-1.0.6-11.3.i386.rpm
tetex-latex-1.0.6-11.3.i386.rpm
tetex-xdvi-1.0.6-11.3.i386.rpm
textutils-2.0e-6.i386.rpm
tkinter-1.5.2-43.62.i386.rpm
tmpwatch-2.8-0.6.x.i386.rpm
traceroute-1.4a5-24.6x.i386.rpm
transfig-3.2.3-2.i386.rpm
ucd-snmp-4.2.3-1.6.x.3.i386.rpm
ucd-snmp-devel-4.2.31.6.x.3.i386.rpm
ucd-snmp-utils-4.2.3-
umb-scheme-3.2-12.i386.rpm
1.6.x.3.i386.rpm
unzip-5.50-1.62.i386.rpm
up2date-2.8.39-1.6.2.i386.rpm
up2date-gnome-2.8.39-
usermode-1.37-1.6.i386.rpm
1.6.2.i386.rpm
util-linux-2.10f-7.6.2.i386.rpm
uucp-1.06.1-33.6.2.i386.rpm
vim-X11-6.1-18.6x.3.i386.rpm
vim-common-6.1-18.6x.3.i386.rpm
vim-enhanced-6.1-18.6x.3.i386.rpm
vim-minimal-6.1-18.6x.3.i386.rpm
vixie-cron-3.0.1-40.1.i386.rpm
wget-1.8.2-4.6x.i386.rpm
wu-ftpd-2.6.1-0.6x.21.i386.rpm
xchat-1.8.9-1.62.0.i386.rpm
xloadimage-4.1-19.6.i386.rpm
xntp3-5.93-15.i386.rpm
xpdf-0.92-1.62.0.i386.rpm
ypbind-1.7-0.6.x.i386.rpm
Ypserv-1.3.9-3.6x.i386.rpm
zlib-1.1.3-25.6.i386.rpm
zlib-devel-1.1.3-25.6.i386.rpm
141
Anexos
ANEXOS 2.
A continuacin presentamos un archivo bash que instala automticamente las
actualizaciones.
rpm -Uvh db3-3.1.17-4.6x.i386.rpm \

db3-devel-3.1.17-4.6x.i386.rpm \
db3-utils-3.1.17-4.6x.i386.rpm
rpm -Uvh rpm-4.0.2-6x.i386.rpm \
rpm-build-4.0.2-6x.i386.rpm \
rpm-devel-4.0.2-6x.i386.rpm \
rpm-python-4.0.2-6x.i386.rpm
rpm -Uvh SysVinit-2.78-5.i386.rpm
rpm -Uvh XFree86-100dpi-fonts-3.3.6-29.i386.rpm \
XFree86-3.3.6-29.i386.rpm \
XFree86-3DLabs-3.3.6-29.i386.rpm \
XFree86-75dpi-fonts-3.3.6-29.i386.rpm \
XFree86-8514-3.3.6-29.i386.rpm \
XFree86-AGX-3.3.6-29.i386.rpm \
XFree86-FBDev-3.3.6-29.i386.rpm \
XFree86-I128-3.3.6-29.i386.rpm \
XFree86-Mach32-3.3.6-29.i386.rpm \
XFree86-Mach64-3.3.6-29.i386.rpm \
XFree86-Mach8-3.3.6-29.i386.rpm \
XFree86-Mono-3.3.6-29.i386.rpm \
XFree86-P9000-3.3.6-29.i386.rpm \
XFree86-S3-3.3.6-29.i386.rpm \
XFree86-S3V-3.3.6-29.i386.rpm \
XFree86-SVGA-3.3.6-29.i386.rpm \
XFree86-VGA16-3.3.6-29.i386.rpm \
XFree86-W32-3.3.6-29.i386.rpm \
XFree86-XF86Setup-3.3.6-29.i386.rpm \
142
Anexos
XFree86-Xnest-3.3.6-29.i386.rpm \
XFree86-Xvfb-3.3.6-29.i386.rpm \
XFree86-cyrillic-fonts-3.3.6-29.i386.rpm \
XFree86-devel-3.3.6-29.i386.rpm \
XFree86-doc-3.3.6-29.i386.rpm \
XFree86-libs-3.3.6-29.i386.rpm \
XFree86-xfs-3.3.6-29.i386.rpm \
at-3.1.8-22.2.i386.rpm \
bash-1.14.7-23.6x.i386.rpm \
cvs-1.11.1p1-8.6.i386.rpm \
diffutils-2.7-22.6x.i386.rpm \
dump-0.4b19-5.6x.1.i386.rpm \
dump-static-0.4b19-5.6x.1.i386.rpm \
ed-0.2-19.6x.i386.rpm \
emacs-20.7-1.i386.rpm \
emacs-X11-20.7-1.i386.rpm \
emacs-el-20.7-1.i386.rpm \
emacs-leim-20.7-1.i386.rpm \
emacs-nox-20.7-1.i386.rpm \
enscript-1.6.1-16.1.i386.rpm \
file-3.39-8.6x.i386.rpm \
fileutils-4.0-21.1.i386.rpm \
gdm-2.0beta2-26.i386.rpm \
gftp-2.0.8-1.i386.rpm \
glibc-2.1.3-29.i386.rpm \
glibc-devel-2.1.3-29.i386.rpm \
glibc-profile-2.1.3-29.i386.rpm \
gnupg-1.0.6-0.6.x.i386.rpm \
gnuplot-3.7.1-5.i386.rpm \
gv-3.5.8-18.6x.i386.rpm \
inetd-0.16-7.i386.rpm \
143
Anexos
iputils-20001010-1.6x.i386.rpm \
joe-2.8-43.62.i386.rpm \
krb5-configs-1.1.1-40.i386.rpm \
krb5-libs-1.1.1-40.i386.rpm \
krb5-devel-1.1.1-40.i386.rpm \
krb5-workstation-1.1.1-40.i386.rpm
rpm -Uvh libpcap-0.6.2-11.6.2.2.i386.rpm \
libpng-1.0.14-0.6x.4.i386.rpm \
libpng-devel-1.0.14-0.6x.4.i386.rpm \
libtiff-devel-3.5.5-2.i386.rpm \
libtiff-3.5.5-2.i386.rpm \
logrotate-3.5.2-0.6.i386.rpm \
losetup-2.10r-0.6.x.i386.rpm \
lpr-0.50.5-1.i386.rpm \
lynx-2.8.3-2.1.i386.rpm \
mailx-8.1.1-16.i386.rpm \
mgetty-1.1.25-4.6.i386.rpm \
minicom-1.83.1-1.0.6x.i386.rpm \
mktemp-1.5-2.1.6x.i386.rpm \
mod_perl-1.23-3.i386.rpm \
modutils-2.3.21-0.6.2.i386.rpm \
mount-2.10r-0.6.x.i386.rpm \
ncurses-5.0-12.i386.rpm \
ncurses-devel-5.0-12.i386.rpm \
nfs-utils-0.3.1-0.6.x.1.i386.rpm \
nscd-2.1.3-29.i386.rpm \
openldap-1.2.13-2.i386.rpm \
openldap-clients-1.2.13-2.i386.rpm \
openldap-devel-1.2.13-2.i386.rpm \
openldap-servers-1.2.13-2.i386.rpm \
openssl-0.9.5a-33.i386.rpm \
144
Anexos
openssl-devel-0.9.5a-33.i386.rpm \
openssl-perl-0.9.5a-33.i386.rpm \
openssl-python-0.9.5a-33.i386.rpm \
pam-0.72-20.6.x.i386.rpm \
perl-5.00503-12.i386.rpm \
php-3.0.18-8.i386.rpm \
php-imap-3.0.18-8.i386.rpm \
php-ldap-3.0.18-8.i386.rpm \
php-manual-3.0.18-8.i386.rpm
rpm -Uvh pine-4.44-1.62.1.i386.rpm \
piranha-0.4.14-1.i386.rpm \
piranha-docs-0.4.14-1.i386.rpm \
piranha-gui-0.4.14-1.i386.rpm \
popt-1.6.2-6x.i386.rpm \
procmail-3.21-0.62.i386.rpm \
pxe-0.1-31.100.6.2.i386.rpm \
rhs-printfilters-1.63-4.rh6.2.i386.rpm \
rmt-0.4b19-5.6x.1.i386.rpm \
rsync-2.4.6-3.6.i386.rpm \
rxvt-2.7.8-3.6.2.1.i386.rpm \
sendmail-8.11.6-1.62.3.i386.rpm \
sendmail-cf-8.11.6-1.62.3.i386.rpm \
sendmail-doc-8.11.6-1.62.3.i386.rpm \
sgml-tools-1.0.9-6.2.i386.rpm \
sharutils-4.2.1-2.6.x.i386.rpm \
slocate-2.4-0.6.x.i386.rpm \
slrn-0.9.6.4-0.6.i386.rpm \
slrn-pull-0.9.6.4-0.6.i386.rpm \
sysklogd-1.3.31-17.i386.rpm \
tar-1.13.25-1.6.i386.rpm \
tcpdump-3.6.2-11.6.2.2.i386.rpm \
145
Anexos
tcsh-6.10-0.6.x.i386.rpm \
textutils-2.0e-6.i386.rpm \
tmpwatch-2.8-0.6.x.i386.rpm \
traceroute-1.4a5-24.6x.i386.rpm \
transfig-3.2.3-2.i386.rpm \
ucd-snmp-4.2.3-1.6.x.3.i386.rpm \
ucd-snmp-devel-4.2.3-1.6.x.3.i386.rpm \
ucd-snmp-utils-4.2.3-1.6.x.3.i386.rpm \
umb-scheme-3.2-12.i386.rpm \
unzip-5.50-1.62.i386.rpm \
usermode-1.37-1.6.i386.rpm \
util-linux-2.10f-7.6.2.i386.rpm \
uucp-1.06.1-33.6.2.i386.rpm \
vim-X11-6.1-18.6x.3.i386.rpm \
vim-common-6.1-18.6x.3.i386.rpm \
vim-enhanced-6.1-18.6x.3.i386.rpm \
vim-minimal-6.1-18.6x.3.i386.rpm \
vixie-cron-3.0.1-40.1.i386.rpm \
wget-1.8.2-4.6x.i386.rpm \
wu-ftpd-2.6.1-0.6x.21.i386.rpm \
xloadimage-4.1-19.6.i386.rpm \
xntp3-5.93-15.i386.rpm \
xpdf-0.92-1.62.0.i386.rpm \
ypbind-1.7-0.6.x.i386.rpm \
ypserv-1.3.9-3.6x.i386.rpm \
zlib-1.1.3-25.6.i386.rpm \
zlib-devel-1.1.3-25.6.i386.rpm
rpm -Uvh --nodeps tkinter-1.5.2-43.62.i386.rpm
rpm -Uvh auth_ldap-1.4.0-3.i386.rpm \
fetchmail-5.9.0-21.6.2.i386.rpm \
fetchmailconf-5.9.0-21.6.2.i386.rpm \
146
Anexos
gnorpm-0.95.1-6.6x.i386.rpm \
gpm-1.19.3-0.6.x.i386.rpm \
gpm-devel-1.19.3-0.6.x.i386.rpm \
imap-2001a-1.62.0.i386.rpm \
imap-devel-2001a-1.62.0.i386.rpm \
man-1.5i2-0.6x.5.i386.rpm \
python-1.5.2-43.62.i386.rpm \
python-devel-1.5.2-43.62.i386.rpm \
python-docs-1.5.2-43.62.i386.rpm \
python-popt-0.8.8-6.x.1.i386.rpm \
python-tools-1.5.2-43.62.i386.rpm \
python-xmlrpc-1.5.1-6.x.7.i386.rpm \
rhn_register-2.8.27-1.6.2.i386.rpm \
rhn_register-gnome-2.8.27-1.6.2.i386.rpm \
up2date-2.8.39-1.6.2.i386.rpm \
up2date-gnome-2.8.39-1.6.2.i386.rpm
147
Anexos
ANEXOS 3. Archivos de configuracin adicionales
Archivo hosts.allow
ALL:
148.213.22.
ALL:
148.213.5.
ALL:
192.168.1.
in.rshd:
192.168.1.
in.sshd:
192.168.1.
in.rlogind:
192.168.1.
Archivo .rhosts en el directorio /root
routerr1 root
routerr2 root
server1 root
server2 root
server3 root
server4 root
server5 root
Archivo /etc/pam.d/rsh
auth
required
/lib/security/pam_rhosts_auth.so
#auth
required
/lib/security/pam_nologin.so
account
required
/lib/security/pam_pwdb.so
session
required
148
Anexos
Archivo /etc/pam.d/login
#%PAM-1.0
auth
required
/lib/security/pam_pwdb.so shadow nullok
auth
required
/lib/security/pam_nologin.so
account
required
password
required
/lib/security/pam_cracklib.so
password
required
/lib/security/pam_pwdb.so nullok use_authtok md5 shadow
session
required
session
optional
/lib/security/pam_console.so
149
Anexos
150
Glosario
GLOSARIO
Alias Alias Apodo. Nombre usualmente corto y fcil de recordar que se utiliza en
lugar de otro nombre ms largo y difcil de recordar. En los programas de correo
electrnico de Internet se utiliza a menudo para designar a los destinatarios ms
habituales. Ver tambin: "e-mail ".
Apache. Servidor HTTP de dominio pblico basado en el sistema operativo Linux.

Apache fue desarrollado en 1995 y es actualmente uno de los servidores HTTP ms
utilizados en la red. Ver tambin: "Free Software ", "HTTP ", "Linux, LINUX ".
Bash Interprete de comandos. Es el shell por defecto en la mayora de las

distribuciones de GNU/Linux. Se encarga de interpretar las ordenes para su proceso
por el kernel.
Boot. Trmino utilizado para indicar el encendido de su computadora.
Capa - Layer. Distintos niveles de estructura de paquete o de enlace utilizados en

los protocolos.
Cliente Client. Un sistema o proceso que solicita a otro sistema o proceso que le
preste un servicio. Una estacin de trabajo que solicita el contenido de un fichero a
un servidor de ficheros es un cliente de este servidor. Ver tambin: "Modelo ClienteServido", "Servidor".
151
Glosario
Cookies - Cookie. Conjunto de caracteres que se almacenan en el disco duro o en

la memoria temporal del ordenador de un usuario cuando accede a las pginas de
determinados sitios web. Se utilizan para que el servidor accedido pueda conocer las
preferencias del usuario al volver ste a conectarse. Dado que pueden ser un peligro
para la intimidad de los usuarios, stos deben saber que los navegadores permiten
desactivar los (o las?) cuquis. Ver tambin: "browser ", "privacy ", "visit ", "web
server ", "website ".
Cliente - Client. Es una computadora que utiliza los servicios de otra computadora
denominada servidor. Cuando Ud. esta utilizando Internet para descargar un archivo
de informacin en su computadora, su maquina est actuando como cliente.
Conmutacin de Paquetes - Packet Switching. Paradigma de comunicaciones

mediante el cual cada paquete de un mensaje recorre una ruta entre sistemas
anfitriones (hosts), sin que esa ruta (path) est previamente definida. Ver tambin:
"host", "packet ".
Demonio daemon. Proceso que acta de forma autnoma, corriendo en un

segundo plano, a la espera de algn suceso que lo active. Aplicacin UNIX la cual
est permanentemente en estado de alerta en un servidor Internet con el fin de
realizar determinadas tareas como, por ejemplo, enviar un mensaje de correo
electrnico o servir una pgina web
152
Glosario
Direccin Address. En Internet Es aquello de la serie de caracteres, numricos o

alfanumricos, que identifican un determinado recurso de forma nica y permiten
acceder a l. En la red existen varios tipos de direccin de uso comn: direccin de
correo electrnico (e-mail address), IP (direccin internet) y direccin hardware o
direccin MAC (hardware address o MAC address). Ver tambin: "email address ",
"Internet address ", "IP address ".
Direccin IP - IP address. Nmero compuesto por 32 dgitos binarios que identifica

a todo emisor o receptor de informacin en Internet. Ver tambin: "CIDR", "Internet ",
"TCP/IP ".
Enrutador / Direccionador - Router. Elemento que determina la trayectoria o

transferencia ms eficiente de datos entre dos segmentos de la red. Opera mediante
el uso de tablas y protocolos de enrutamiento
Ethernet. Tipo de red de rea local desarrollada en forma conjunta por Xerox, Intel y
Digital Equipment. Se apoya en la topologa de bus, tiene ancho de banda de10
Mbps de forma que presenta una elevada velocidad de transmisin; y se ha
convertido en un estndar de red corporativa.
FTP Protocolo de Transferencia de Archivos / File Transfer Protocol. Siglas en

ingles de "Protocolo de Transferencia de archivos" Es una de las maneras de
transferir datos desde una computadora a otra a travs de la red. Protocolo que
permite a un usuario de un sistema acceder a, y transferir desde, otro sistema de una
red. FTP es tambin habitualmente el nombre del programa que el usuario invoca
para ejecutar el protocolo. Ver tambin: "anonymous FTP ".
153
Glosario
Firewall - Cortafuegos. Sistema que se coloca entre una red local e Internet. La
regla bsica es asegurar que todas las comunicaciones entre dicha red e Internet se
realicen conforme a las polticas de seguridad de la organizacin que lo instala.
Adems, estos sistemas suelen incorporar elementos de privacidad, autentificacin,
etc. Dispositivo que se coloca entre una red local e Internet y cuyo objetivo es
asegurar que todas las comunicaciones entre los usuarios de dicha red e Internet se
realicen conforme a las normas de seguridad de la organizacin que lo instala. Ver
tambin: "Internet ", "LAN ".
Frame Cuadro Marco. Posibilidad que ofrece el lenguaje HTML de dividir una
pgina web en varias zonas, cada una de las cuales puede tener un contenido
independiente de las dems; cada una de esas zonas es asimismo un frame.[Fuente:
RFCALVO].Un frame es tambin la capa de enlace de datos (datalink) que contiene
la informacin de cabecera y cola que requiere un determinada red de
comunicaciones. Ver tambin: "datagram ", "HTML ", "packet ", "page ", "tag ".
Gateway Pasarela. Hoy se utiliza el trmino "router" (direccionador, encaminador,

enrutador) en lugar de la definicin original de "gateway". Una pasarela es un
programa o dispositivo de comunicaciones que transfiere datos entre redes que
tienen funciones similares pero implantaciones diferentes.
HTTP. Siglas en ingles para Hypertext transfer protocol. Es el mtodo utilizado para
transferir documentos desde la computadora server hacia los navegadores.
Comnmente se ven estas siglas al comienzo de las URLs o direcciones de Internet.
Host anfitrin albergar hospedar. Ver :"host system"

154
Glosario
Host System - Sistema Anfitrin - Sistema Principal. Ordenador que, mediante la

utilizacin de los protocolos TCP/IP, permite a los usuarios comunicarse con otros
sistemas anfitriones de una red. Los usuarios se comunican utilizando programas de
aplicacin, tales como el correo electrnico, Telnet, WWW y FTP. La acepcin verbal
(to host) describe el hecho de almacenar algn tipo de informacin en un servidor
ajeno. Ver tambin: "host address ", "host name ", "host number ", "TCP/IP ".
Host Address - Direccin de Sistema Anfitrin. Es la direccin Internet de un

sistema anfitrin. Puede ser un nombre o una serie de nmeros. Ver tambin: "host",
"Internet address ".
Host Name - Nombre de Sistema Anfitrin. Nombre dado a un sistema anfitrin.

Por ejemplo ati.es. Ver tambin: "FQDN ", "host".
Host Number - Nmero de Sistema Anfitrin. Identificacin numrica dada a una

mquina anfitriona. Por ejemplo 194.140.128.71. Ver tambin: "domain ", "host".
Interfaz - Interface. Zona de contacto o conexin entre dos componentes de

"hardware"; entre dos aplicaciones; o entre un usuario y una aplicacin. Apariencia
externa de una aplicacin informtica.
Interfaz de Usuario Basada en Web (WUI). Interfaz grfica de usuario con la

apariencia tpica de una pgina web.
Interfaz Grfica de Usuario (GUI). Componente de una aplicacin informtica que

el usuario visualiza y a travs de la cual opera con ella. Est formada por ventanas,
botones, mens e iconos, entre otros elementos.
155
Glosario
Interfaz para Programas de Aplicacin (API). Conjunto de convenciones de

programacin que definen cmo se solicita un servicio desde un programa.
Internet. Sistema que aglutina las redes de datos de todo mundo, uniendo miles de
ellas mediante el protocolo TCP/IP. El mayor conjunto que existe de informacin,
personas, ordenadores y software funcionando de forma cooperativa. La i mayscula
la diferencia de una internet convencional, que simplemente une varias redes. Al ser
nica se la conoce tambin simplemente por "la red". Conjunto de redes conectadas
entre s, que utilizan El protocolo TCP/IP para comunicarse.
Internet Explorer (IE). Programa navegador o visualizador del WWW el cual est
gratuitamente disponible gratuitamente. La versin 3 de este programa soporta Java
y controles Active X.
Internet2 - Proyecto que trata de crear una nueva Internet de mayores y mejores
prestaciones en el mbito de las universidades norteamericanas. Fue lanzado en
1996 por un grupo de dichas universidades con la colaboracin del Gobierno Federal
y de importantes empresas del sector de la Informtica y las Telecomunicaciones
ISO - International Organization for Standardization (Organizacin Internacional

para la Normalizacin) Organizacin de carcter voluntario fundada en 1946 que es
responsable de la creacin de estndares internacionales en muchas reas,
incluyendo la informtica y las comunicaciones. Est formada por las organizaciones
de normalizacin de sus pases miembro. Organizacin que ha definido un conjunto
de protocolos diferentes, llamados protocolos ISO; y es responsable de la creacin
de estndares internacionales en muchas reas, incluyendo la informtica, las
ecolgicas y las comunicaciones. Est formada por las organizaciones de
normalizacin de sus 89 pases miembros.
156
Glosario
Intranet: Red privada dentro de una empresa que utiliza el mismo software y
protocolos empleados en la Internet global, pero que slo es de uso interno. (VER
tambin: Internet, Red).
Intranet. Red propia de una organizacin, diseada y desarrollada siguiendo los

protocolos propios de Internet, en particular el protocolo TCP/IP. Puede tratarse de
una red aislada, es decir no conectada a Internet. Ver tambin: "Extranet ", "internet
", "TCP/IP ".
Kernel Ncleo. Componente central de un sistema operativo. Es el encargado de

asignar los recursos fsicos del sistema a los dems procesos que componen el
sistema operativo.
LILO / LInux Loader Cargador Linux. Programa usado para arrancar Linux y
como administrador de arranque para otros sistemas operativos
LAN - (Local Area Network) - (Red de Area Local). Red de computadoras ubicadas
en El mismo ambiente, piso o edificio. (Ver tambin: Red).
LINUX: Versin de libre distribucin del sistema operativo UNIX; fue desarrollada por
Linus Torvald
Link - Enlace/Enlazar, Vnculo/Vincular. Apuntadores hipertexto que sirven para

saltar de una informacin a otra, o de un servidor a otro, cuando se navega por
Internet o bien la accin de realizar dicho salto.
157
Glosario
Login. Nombre de usuario utilizado para obtener acceso a una computadora o a una
red. A diferencia del password, login no es secreto, ya que generalmente es conocido
por quien posibilita el acceso mediante este recurso. (Ver tambin: password)
Log Files Archivo de Registro. Registro de todos los hits que un servidor ha
recibido en un perodo de tiempo dado el cual puede ser utilizado por auditores
externos para registrar el uso del sitio.
Mbps - Megabits por segundo. Unidad de medida de la capacidad de transmisin

por una lnea de telecomunicacin. Cada megabit est formado por un milln de bits.
Multidifusin - Broadcast. Trmino utilizado originariamente en el mundo de la

radio y de la televisin para indicar que sus emisiones las puede recibir cualquiera
que sintonice una emisora. Hoy en Internet se emite tambin radio y televisin en
modo broadcast, y la misma WWW es un medio de este misma naturaleza. Ver
tambin: "multicast ", "Real Audio ", "unicast ", "WWW ". Mtodo de difusin de
informacin en vivo que permite que sta pueda ser recibida por mltiples nodos de
la red y, por lo tanto, por mltiples usuarios.
Modelo Cliente-Servidor - Client-Server Model. Modelo de comunicacin entre

ordenadores conectados a una red en el cual hay uno, llamado cliente, que satisface
las peticiones realizadas por otro llamado servidor. Ver tambin: "Cliente", "Servidor".
NAT. Network Address Translation. Traduccin de Direcciones de Red
158
Glosario
Navegador Browser Visualizador. Aplicacin para visualizar todo tipo de

informacin y navegar por el espacio Internet. En su forma ms bsica son
aplicaciones hipertexto que facilitan la navegacin por los servidores de informacin
Internet;
cuentan
con
funcionalidades
plenamente
multimedia
permiten
indistintamente la navegacin por servidores WWW, FTP, Gopher, el acceso a

grupos de noticias, la gestin del correo electrnico, etc. Ver tambin: "Internet
Explorer ", "Mosaic ", "Netscape Navigator ". Programa utilizado para acceder y
recorrer sitios de la WWW. (Ver tambin: WWW, Mosaic). Software que le permite a
Ud. acceder a la informacin en Internet, mediante una computadora. EL Netscape
Navigator y el Internet Explorer son ejemplos de navegadores que utilizan una
interfase grfica para buscar, ver y manejar informacin.
Nodo: Una computadora conectada a la red. (Ver tambin: red, Internet, LAN).
Cualquier computadora conectada a una red.
Navegar Surfing. Es la utilizacin de un navegador para buscar material

interesante en Internet, mediante herramientas de bsqueda e hipervnculos.
OSI - Interconexin de Sistemas Abiertos. Protocolo en el que se apoya Internet

debido a que establece la manera como se realiza la comunicacin entre dos
computadoras a travs de siete capas Fsica, Datos, Red, Transporte, Sesin,
Presentacin y Aplicacin.
Off line. Lo opuesto a on line, fuera de conexin.
On line. En lnea o en tiempo real. Procesamiento de datos en el momento en que se

desarrolla una accin (como obtencin de seales, comunicacin por mdem, etc.).
Significa que un programa adquiere y/o calcula datos y muestra los resultados en
forma simultnea en valores numricos y/o grficos y/o sonidos.
159
Glosario
Operador del Sistema. Persona responsable del funcionamiento de un sistema o de

una red, comnmente denominado Sysop.
Password: Palabra clave utilizada para obtener acceso a una computadora o a una
red. Un password generalmente contiene una combinacin de nmeros y letras que
no tienen ninguna lgica. (Ver tambin: Login).
Protocolo Protocol. Reglas que gobiernan como las computadoras se comunican

entre ellas. Es la letra p en http, tcp/ip y en otras importantes convenciones.
Paquete Packet. La unidad de datos que se enva a travs de una red. En Internet
la informacin transmitida es dividida en paquetes que se reagrupan para ser
recibidos en su destino. Ver tambin: "datagram ", "frame ", "packet loss", "packet
switching ".
Prdida de Paquetes Packet Loss. Prdida de alguna de las unidades de

informacin, o paquetes, que componen un mensaje transmitido a travs de Internet.
Ver tambin: "packet ".
Page Pgina. Fichero (o archivo) que constituye una unidad significativa de

informacin accesible en la WWW a travs de un programa navegador. Su contenido
puede ir desde un texto corto a un voluminoso conjunto de textos, grficos estticos
o en movimiento, sonido, etc. El trmino pgina web se utiliza a veces, a mi entender
de forma incorrecta, para designar el contenido global de un sitio web, cuando en ese
caso debera decirse pginas web o sitio web. Ver tambin: "home page ", "personal
page ", "website ", "WWW ".
160
Glosario
PHP - Herramientas para Pginas Iniciales Personales (Personal Home Page

Tools). Lenguaje de programacin tipo script para entornos Web utilizado sobre todo
en servidores Linux para personalizar la informacin que se enva a los usuarios que
acceden a un sitio web. Es un programa de software libre con unas funciones muy
semejantes a las de ASP y JSP. Ver tambin: "ASP ", "JSP ",
PING - Buscador de Paquetes de Internet (Packet INternet Groper). Programa

que se utiliza para comprobar si un destino est disponible. El trmino se utiliza
tambin coloquialmente: "Haz un ping al host X a ver si funciona". Sin lugar a dudas
en una red el comando que ms se puede llegar a utilizar es ping. Este comando se
utiliza para comprobar si una determinada interfaz de red, de nuestra computadora o
de otra, se encuentra activa. Su funcin ms habitual es simplemente verificar si una
mquina est encendida. Lo que se est haciendo en realidad es mandar paquetes
del tipo `ècho request'', y para los que se devuelven son del tipo `ècho reply''.
Protocolo. Descripcin formal de formatos de mensaje y de reglas que dos

ordenadores deben seguir para intercambiar dichos mensajes. Un protocolo puede
describir detalles de bajo nivel de las interfaces mquina a mquina o intercambios
de alto nivel entre programas de asignacin de recursos.
Protocolo de Control de Transmisin (TCP). Forma de comunicacin bsica de

Internet la cual hace posible que cualquier tipo de informacin (mensajes, grficos o
audio) viaje en forma de paquetes sin que estos se pierdan y siguiendo cualquier ruta
posible.
Protocolo de Datagramas de Usuario (UDP). Protocolo que no pide confirmacin

de la validez de los paquetes enviados por la computadora emisora. Este protocolo
es actualmente usado para la transmisin de sonido y vdeo a travs de Internet. El
UDP est diseado para satisfacer necesidades concretas de ancho de banda y
como no reenva los datos perdidos, es ideal para el trfico de voz digitalizada debido
161
Glosario
a que un paquete perdido no afecta la calidad del sonido. Entre las aplicaciones que
utilizan este protocolo encontramos a Real Audio.
Protocolo de Tiempo Real (RTP). Protocolo utilizado para la transmisin de

informacin en tiempo real, como por ejemplo audio y vdeo en una videoconferencia.
Protocolo de Transferencia de Hipertexto (HTTP). Protocolo utilizado en la WWW

para transmitir las pginas de informacin entre el programa navegador y el servidor.
Se destaca que el HTTP seguro es un protocolo HTTP mejorado con funciones de
seguridad con clave simtrica.
Protocolo de Transmisin de Archivos (FTP). Mtodo de transferencia de archivos

por Internet utilizado para descargar archivos pblicos de una computadora remota a
un local. A veces es necesario introducir una contrasea la cual puede ser la palabra
guest (husped), o su direccin de correo electrnico. Est asociado con los
servidores FTP y directorios (normalmente pblicos) de archivos de todo tipo.
Protocolo Internet (IP). Conjunto de reglas que regulan la transmisin de paquetes de

datos a travs de Internet. La versin actual es IPv4 mientras que en el proyecto
Internet2 se intenta implementar la versin 6 (IPv6), la cual permitira mejores
prestaciones dentro del concepto QoS (Quality of Service). Hace referencia a un
"nmero IP", el cual comprende una serie de nmeros especficos divididos en cuatro
grupos de valores entre 0 y 255, los cuales se asignan a cada mquina que est
conectada a la Red. Un DNS convierte los nmeros IP a nombres comunes.
Protocolo Internet - IP (Internet Protocol). Conjunto de reglas que regulan la

transmisin de paquetes de datos a travs de Internet. La versin actual es IPv4
mientras que en el proyecto Internet2 se intenta implementar la versin 6 (IPv6), que
permitira mejores prestaciones dentro del concepto QoS (Quality of Service). Ver
tambin: "CIDR", "Internet2 ", "IPv6 ", "packet ", "protocol ", "QoS ", "TCP/IP ".
162
Glosario
Puerto. Nmero que aparece tras un nombre de dominio en una URL. Dicho nmero
va precedido del signo (dos puntos). Canal de entrada/salida de una computadora.
Protocolo de Internet: - IP / Internet Protocol. Nmero nico que consta de 4

partes separadas por puntos. Cada computadora conectada a Internet tiene un nico
nmero de IP. Si la maquina ni tiene un IP fijo, no est en realidad en Internet, sino
que pide "prestado" un IP a un servidor cada vez que se conecta a la Red
(usualmente va mdem). (Ver tambin: Dominio, Internet, TCP/IP).
Red: Se tiene una red cada vez que se conectan dos o ms computadoras de
manera que pueden compartir recursos. Al conectar dos o ms redes en conjunto, se
obtiene una Internet.(Ver tambin: Internet, Intranet).
Reboot. Reiniciar. Trmino utilizado para indicar el reinicio de su computadora

mediante el botn de reinicio ubicado en el panel frontal o bien mediante una
combinacin de teclas.
Red Network. Al menos dos computadoras que se encuentran enlazadas mediante

un cable, un modem u otro dispositivo y que tienen la habilidad de intercambiar
datos, archivos y otros recursos. Una red de ordenadores es un sistema de
comunicacin de datos que conecta entre s sistemas informticos situados en
lugares
ms
menos
prximos.
Puede
estar
compuesta
por
diferentes
combinaciones de diversos tipos de redes.
Root Raz. Dcese del directorio inicial de un sistema de ficheros. En entornos Unix
se refiere tambin al usuario principal. Ver tambin: "directory ", "file ".
163
Glosario
Router Encaminador Direccionador Enrutador. Dispositivo que distribuye

trfico entre redes. La decisin sobre a donde enviar los datos se realiza en base a
informacin de nivel de red y tablas de direccionamiento. Ver tambin: "gateway ".
Computadora de uso especfico que maneja la conexin dos o ms redes. Los
routers pasan todo el tiempo buscando las direcciones de destino de los paquetes
con informacin y deciden cul es el mejor camino para enviarlos. (Ver tambin:
Red).
RFC. Serie de documentos iniciada en 1967 la cual describe el conjunto de

protocolos de Internet y experimentos similares. No todos los RFC (en realidad muy
pocos de ellos) describen estndares de Internet pero todos los estndares Internet
estn escritos en formato RFC. La serie de documentos RFC es inusual en cuanto
los protocolos que describen son elaborados por la comunidad Internet que
desarrolla e investiga, en contraste con los protocolos revisados y estandarizados
formalmente que son promovidos por organizaciones como CCITT y ANSI.
RSYNC. Herramienta de sincronizacin de ficheros, que permite que un cliente y un

servidor se mantengan sincronizados sin enviar los ficheros modificados y sin que
sea necesario mantener un histrico o log de cambios.
SO - Sistema Operativo . Programa o conjunto de programas que permiten

administrar los recursos de hardware y software de una computadora.
Servidor Server. Es una computadora que provee servicios a otras computadoras

denominadas clientes.
Sitio Web Web Site. Es la ubicacin donde la informacin de la web es agrupada y

puesta a disposicin de los usuarios de Internet.
164
Glosario
Script Guin Script. Conjunto de caracteres formado por mandatos y secuencias

de tecleo, que se utiliza muy a menudo en Internet para automatizar tareas muy
habituales como, por ejemplo, la conexin a la red (login)[Fuente: RFCALVO].
tunneling (tunelado) En Internet, este trmino se aplica al uso de la Red como parte
de una red privada segura. El tnel es un conducto especfico por el que viajan los
mensajes o ficheros de una determinada empresa. Ver tambin: "VPN ". Secuencia
de comandos que se le dan a un mdem con el propsito de configurarlo (velocidad,
compresin de datos, etc) o para realizar tareas especficas (llamar al proveedor,
colgar, etc). A veces es necesario modificar un script o cadena de inicio la cual
establece las condiciones iniciales del mdem (por ejemplo cambiar ATDT que
establece una lnea telefnica por tonos a ATDP que indica una lnea telefnico por
pulsos, etc.).
Servidor Web Web Server. Computadora dedicada a gestionar el uso de la red

por otras computadoras llamadas clientes la cual contiene archivos y recursos que
pueden ser accedidos desde otras computadoras o terminales.
Sesin Remota Remote Session. Uso de los recursos de una computadora desde
una terminal la cual no se encuentra cercana a dicha computadora.
TCP/IP -(Transmission Control Protocol/Internet Protocol). Familia de protocolos

que hacen posible la interconexin y trfico de red en Internet. A ella pertenecen por
ejemplo: FTP, SMTP, NNTP, etc.. Los dos protocolos ms importantes son los que
dan nombre a la familia IP y TCP
Thread. Serie de mensajes relacionados entre s en un grupo de noticias.
Trfico. Nmero de personas que visitan un sitio web.
165
Glosario
Tunneling. Trmino que se aplica al uso de la Red como parte de una red privada
segura. Transporte de paquetes Multicast a travs de dispositivos y Routers unicast.
Los paquetes multicast se encuentran encapsulados como paquetes normales de
esta manera pueden viajar por Internet a travs de dispositivos que solo soportan
protocolos unicast.
URL: (Uniform Resource Locator). Direccin de algn recurso de Internet que

forma
parte
de
la
WWW.Ver
tambin:
navegador,
WWW).
Sistema
de
direccionamiento estndar de archivos y funciones de Internet, especialmente en el

WWW. El URL est conformado por a) El protocolo de servicio (http://); b) El nombre
de la computadora (www.mercadeoelectronico.com); y c) El directorio y el archivo
referido.
URL/URI
Uniform
Resource
Locator /
Universal
Resource
Identifier
(Localizador Uniforme de Recursos/Identificador Universal de Recursos) Sistema

unificado de identificacin de recursos en la red (el URI todava no est implantado).
Las direcciones se componen de protocolo, FQDN y direccin local del documento
dentro del servidor. Este tipo de direcciones permite identificar objetos WWW,
Gopher, FTP, News,... Ejemplos de URL son: <http://www.anaya.es> o <ftp://ftp.ati.>
Ver tambin: "FQDN ".
Upload Cargar Subir Subirse Actualizar. En Internet, proceso de transferir

informacin desde un ordenador personal a un servidor de informacin. Ver tambin:
"download ", "web server ". [Fuente: RFCALVO].
User ID - ID de Usuario / Identificacin de Usuario. Conjunto de caracteres

alfanumricos que sirven para identificar a un usuario para su acceso a la red.
Ejemplo: rfcalvo
166
Glosario
User name / Username - Nombre de Usuario. Por contraposicin a UserID suele

ser un nombre intelegible que identifica al usuario de un sistema o red Ver tambin:
"User ID ".
Unidad de Paquete. Pequeo programa situado entre la tarjeta de red y el programa

de TCP de manera que proporciona un interfaz estndar que los programas pueden
usar como si se tratase de una unidad de disco.
Unidad Mxima de Recepcin (MRU). Se refiere al mximo tamao del paquete de

datos para algunos protocolos de Internet.
Unidad Mxima de Transmisin (MTU). Mximo tamao del paquete de datos en

protocolos IP como el SLIP.
Virtual. Segn el DRAE es algo que tiene existencia aparente y no real. Es un

trmino de frecuente utilizacin en el mundo de las tecnologas de la informacin y
de las comunicaciones para designar dispositivos o funciones simulados. Ver
tambin: "virtual circuit ", "VPN ".
WAN: (Wide Area Network), Red de Area Amplia. Una red de computadoras de
gran tamao, dispersa por un pas o incluso por todo el planeta.
WWW: (World Wide Web). Conjunto de recursos que pueden accederse utilizando
un Navegador, mediante el protocolo HTTP. (Ver tambin: HTTP, URL). WWW.
Siglas de World Wide Web. La WWW provee una manera de enlazar las
computadoras en Internet a travs del cdigo html y usando hipervnculos que le
permiten avanzar de un sitio a otro en la Web.
167
Glosario
Web Server - Servidor Web. Mquina conectada a la red en la que estn

almacenadas fsicamente las pginas que componen un sitio web. Dcese tambin
del programa que sirve dichas pginas. Ver tambin: "page ", "website ".
168
Bibliografia
BIBLIOGRAFA
David H.M. Spector. (2000). Building LINUX CLUSTER. Estados Unidos. Ed OReilly.
David Pitts, Bill Ball. (1999). Red Hat Linux Unleashed. Third Edition. Estados
Unidos. Ed. SAMS.
Gerald Carter with Richard Sharpe Samba Team Members. (1999). Samba in 24
Hours. Estados Unidos. Ed. SAMS.
Gerhard Mourani. (2001). Seguring & Optimizing LINUX, The Ultimate Solution.
Estados Unidos Ed. OpenNA.
John D. Blair Samba Team. (1998). Samba integrating UNIX with Windows. Seattle.
Ed. Specialized Systems Consultans
Tony Bourke. (2002). Server Load Balancing. Estados Unidos. Ed. OReilly.
Ligas relacionadas
http://aggregate.org/PPLINUX/19980105/pphowto-3.html
http://www.fisica.uson.mx/carlos/LinuxClusters/
http://www.bisente.com/documentos/clustering/memoria.html
http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html
http://www.tldp.org/HOWTO/Beowulf-HOWTO.html
http://www.tldp.org/HOWTO/Cluster-HOWTO.html
http://www.tldp.org/HOWTO/SMP-HOWTO.html
http://www.fysik.dtu.dk/CAMP/cluster-howto.html
http://www.redhat.com/docs/manuals/advserver/RHLAS-2.1-Manual/install-guide/s1introduction-configurations.html
http://www.redhat.com/docs/manuals/haserver/RHHAS-1.0-Manual/
169
Bibliografia
http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/custom-guide/kernelbootloader.html
http://www.cacr.caltech.edu/beowulf/tutorial/building.html
http://www.runlevelzero.net/greg/warewulf/
http://www.cecalc.ula.ve/documentacion/tutoriales/beowulf/
http://www.mosix.com/
http://www.dirac.org/linux/lilo/lilo.html
http://www.frikis.org/staticpages/index.php?page=kernel
http://www.linuxhq.com/kernel/index.html
Ligas relacionas con LVS

http://www.redhat.com/docs/manuals/haserver/RHHAS-1.0-Manual/ch-lvs.html
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/clustersuite/index.html
http://mail1.cula.net/cluster/index.html
http://www.linuxvirtualserver.org/
http://lvs.idk.com.pl/Joseph.Mack/HOWTO/LVS-HOWTO.introduction.html
http://www.austintek.com/LVS/LVS-HOWTO/mini-HOWTO/LVS-mini-HOWTO.html
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/index.html
http://www.linuxvirtualserver.org/Joseph.Mack/performance/single_realserver_perfor
mance.html
http://webmaster.bankhacker.com/hardware/linux-cluster-web-internet-server.phtml
http://www.redhat.com/support/wpapers/redhat/piranha/index.html#toc
Ligas relacionadas con computo PARALELO

http://hidra.iqfr.csic.es/
http://ulises.umh.es/cc/novedades/cluster_linux.html
Ligas relacionadas con Windows cluster

http://www.eu.microsoft.com/spain/technet/implantacion/default.asp
170
Bibliografia
http://www.windowstimag.com/atrasados/2001/50_feb01/articulos/especial_columna.
htm
Ligas relacionadas con IPMASQUERADE

http://www.redhat.com/mirrors/LDP/HOWTO/IP-Masquerade-HOWTO/ipmasqintro1.0.html
http://www.insflug.org/COMOs/IP-Masquerade-Como/IP-Masquerade-Como2.html#ss2.1
http://www.redhat.com/mirrors/LDP/LDP/LG/issue43/silva.ip_masq.html
http://www.ssi.bg/~ja/
Ligas relacionadas con Coda

http://www.undersec.com/staff/balrog/UN-lvscoda/UN-lvs-coda.html
http://www.coda.cs.cmu.edu/
Ligas relacionadas con Apache

http://www.apache.org/
http://httpd.apache.org/docs-2.1/mod/mod_unique_id.html
http://httpd.apache.org/docs-2.0/misc/rewriteguide.html
http://search.apache.org/
Ligas relacionadas con el Glosario

http://www.redhat.com/mirrors/LDP/LDP/Linux-Dictionary/html/a.html
http://www.torrealday.com.ar/glosario.html#0-9
http://www.ati.es/novatica/glosario/glosario_internet.html#glosa
http://glosario.panamacom.com/
http://www.tugurium.com/gti/
171

Felix Ortigosa Martinez PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Felix Ortigosa Martinez PDF

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE COLIMA

A mis maestros de la Facultad de Telemtica por su apoyo incondicional.

A mi asesor por su paciencia.

A los dems compaeros de los centros de investigacin por su paciencia.

Captulo I. Tecnologa Clusters ............................................................................. 7

Esquemas de procesamiento en paralelo ................................................ 9

SMP en contra de otras Arquitecturas .................................................... 11

Estilos de clster ..................................................................................... 12

Configuracin de un Clster ..................................................................... 14

Arquitecturas de Clster .......................................................................... 15

Caractersticas del Clster ...................................................................... 18

Disponibilidad del Clster ........................................................................ 18

Escalabilidad del Clster ......................................................................... 21

Rendimiento del Clster .......................................................................... 23

Servidores balanceadores de carga (SLB) .............................................. 25

1.11.4.2. Servidores ......................................................................28

Captulo II. Plataformas de Desarrollo ................................................................. 36

Sistema Operativo Windows 2000 ........................................................... 36

Sistema Operativo LINUX .................. 45

2.2.4. Servidor Avanzado de Red Hat ..................................................... 60

Captulo III. Software LVS Linux Virtual Server ................................. 63

Configuracin Tpica de FOS ................................................................... 63

LVS Linux Virtual Server ............................................................. 65

Captulo IV. Implementacin.. 86

Esquema de la Implementacin ............................................................... 95

Configuracin ........................................................................................... 112

Captulo V. Conclusiones ...................................................................................... 124

Anexos .................................................................................................................. 137

INDICE DE FIGURAS Y TABLAS

Figura 2.3. Vista fsica de los servidores virtuales en el servicio de

Figura 4.1. Esquema Bsico de Clster LVS .. 88

Tabla 1. Relacin de fallas en contra de la frecuencia ....................................... 22

En la actualidad una tecnologa predominante y necesaria es el Internet, el

cuestionamos cunto tiempo necesita tener su sistema funcionando?. Es decir,

En el presente trabajo, se analiza esta tecnologa con la construccin de un

At the present time a predominant and necessary technology is the Internet,

El objetivo principal de la presente tesis es implementar con Tecnologa

De aqu es importante demostrar los pros y contras de cmo se construye un

El desarrollo del presente trabajo es dar a conocer cmo es un clster LVS o

Por qu conocer esta Tecnologa?

El internet es una tecnologa elemental para cualquier empresa. En aos

Pero la implementacin de este tipo de sistemas de informacin no es tan

concentradores o switches, instalacin elctrica.

Desde el punto de vista tecnolgico, debemos de analizar que tan moderno

Esto tiene un costo elevado de la tecnologa si se instala un moderno equipo

Pero si las empresas no desean invertir mucho, y si desean tener lo ms

Captulo I Tecnologa Clster

CAPTULO I. TECNOLOGA CLSTER

Cundo falla un sistema empresarial o de misin crtica y los datos ya no

En el mundo del cmputo empresarial de la actualidad, los administradores de

simultneamente, este abarca la empresa en un 90 % . Lo que antes se consideraba

Captulo I Tecnologa Clster

La computacin en paralelo de alto rendimiento (HCP, High Paralel

El procesamiento en paralelo se refiere, al concepto de acelerar el tiempo de

Multiprocesamiento. Es la idea del programa control de una computadora, que

manera mltiple, independiente control simultneo de tareas.

David HM Spector, July 2000

Captulo I Tecnologa Clster

Si el sistema operativo puede soportar mltiples tareas de control soporta

Sincronizacin. Es el proceso de poner procesos diferentes en sincrona. Por

1.1. Esquemas de Procesamiento en Paralelo

El rea del procesamiento en paralelo ha sido una rea activa de investigacin

Symmetric Multiprocessor - Mutlprocesamiento Simtrico.