Comparativa de Clusters SSI

INGENIERO EN INFORMÁTICA
SISTEMAS INFORMÁTICOS
COMPARATIVA DE CLUSTERS SSI
Autores:
Dávila Quintana Sergio
Pila Rodríguez Ruben
Director:
Cortizo Perez Jose Carlos
Villaviciosa de Odón, Junio de 2007

Agradecimientos
No debemos dejar pasar esta oportunidad sin agradecer a todas aquellas personas que en
mayor o menor medida han ayudado a que este proyecto se desarrollase:
• Muchas gracias a nuestros padres, ya que, en todo momento son los únicos que
han estado siempre ahí, sin reservas y para lo que sea.
• Gracias a nuestras chabalas (¡sólo a dos!) que han estado siempre en los
momentos buenos y malos y que tanto nos han apoyado.
• A todos nuestros amigos por hacernos llegar, estén donde estén, su fe y apoyo.
• José Carlos Cortizo, por aportar la experiencia en Proyectos de esta índole, por
ser el cofundador de esta idea y por ser capaz de resolver todas y cada una de las
preguntas tan variadas, a cualquier hora y en cualquier lugar. Realmente eres un
todoterreno.
• José María Gómez Hidalgo, por dar un toque de profesionalidad durante las
fases del proyecto, que esperamos que halla quedado reflejada en éste.
• A todos nuestros compañeros de clase, por el clima agradable que hemos creado
entre todos durante estos años, y que siempre hacen de una carrera universitaria
algo más agradable.
• A todos nuestros profesores, por transmitirnos sus conocimientos de la manera

que mejor saben.
• A todas las personas que han colaborado de forma anónima para que este
proyecto saliese adelante.
A todos vosotros, muchas gracias...
Sergio y Rubén
2
3
INDICE
INTRODUCCIÓN...........................................................................................................................................10
OBJETIVO DEL PROYECTO .............................................................................................................................10
AIM OF THE PROJECT ....................................................................................................................................11
CAPITULO I ...................................................................................................................................................13
1. CLUSTER...........................................................................................................................................14
1.1 ¿Qué es un cluster?...................................................................................................................14
1.2 Características de un cluster ....................................................................................................16
1.2.1 Esquema y otras características ..........................................................................................................17
1.3 Clasificación según el servicio prioritario ..............................................................................21
1.4 Introducción a las diferentes clases de Clusters .....................................................................23
1.4.1 Clusters HP: alto rendimiento.............................................................................................................23
1.4.1.1 La misión...................................................................................................................................23
1.4.1.2 Problemas que solucionan........................................................................................................23
1.4.1.3 Técnicas que utilizan ................................................................................................................23
1.4.2 Clusters HA: alta disponibilidad.........................................................................................................24
1.4.2.1 La misión...................................................................................................................................24
1.4.2.2 Problemas que solucionan........................................................................................................24
1.4.2.3 Técnicas que utilizan ................................................................................................................25
1.4.3 Clusters HR: alta confiabilidad...........................................................................................................25
2. CLASES DE CLUSTERS ....................................................................................................................27
2.1 Clusters HA ..............................................................................................................................27
2.1.1 Introducción .........................................................................................................................................27
2.1.2 El interés comercial .............................................................................................................................27
2.1.3 Conceptos importantes ........................................................................................................................28
2.1.3.1 Servicio RAS ............................................................................................................................29
2.1.3.2 Técnicas para proveer de disponibilidad.................................................................................30
2.1.3.3 Soluciones libres.......................................................................................................................34
2.1.4 LVS (Linux Virtual Server) ................................................................................................................37
2.1.4.1 Introducción ..............................................................................................................................37
2.1.4.2 Métodos de balanceo IP ...........................................................................................................40
2.1.4.3 Aspectos Técnicos ....................................................................................................................43
2.1.4.4 ¿Y la alta disponibilidad?.........................................................................................................51
2.1.4.5 Conclusiones.............................................................................................................................57
2.2 Clusters HP ...............................................................................................................................58
2.2.1 Conceptos importantes: migración y balanceo ..................................................................................58
2.2.2 Beowulf ................................................................................................................................................64
2.2.3 OpenMosix...........................................................................................................................................64
2.2.4 TOP 500 ...............................................................................................................................................65
2.3 Requrimientos y planteamientos .............................................................................................66
2.3.1 Requerimientos hardware....................................................................................................................66
2.3.2 Líneas básicas en la configuración del hardware ..............................................................................66
2.3.3 Planteamientos del cluster...................................................................................................................66
3. PASO DE MENSAJES......................................................................................................................68
3.1 Introducción ..............................................................................................................................68
3.2 PVM ..........................................................................................................................................70
3.3 MPI............................................................................................................................................74
4. TEORÍA DE LA SUPERCOMPUTACIÓN ....................................................................................75
4.1 Visión histórica.........................................................................................................................75
4.2 Problemas que se pueden resolver con sistemas paralelo......................................................77
4.3 Soluciones actuales que se dan a dichos problemas...............................................................80
CAPITULO II..................................................................................................................................................82
5. SISTEMAS OPERATIVOS ..............................................................................................................83
5.1 Introducción ..............................................................................................................................83
5.2 Historia......................................................................................................................................83
5.3 ¿Que es un Sistema Operativo?...............................................................................................87
5.4 Funciones ..................................................................................................................................87
5.5 Tipos de sistemas operativos por su estructura ......................................................................87
5.6 Tipos de sistemas operativos por sus servicios ......................................................................88
5.7 Características...........................................................................................................................89
4
6. DEBIAN GNU/LINUX .....................................................................................................................90
6.1 Introducción ..............................................................................................................................90
6.1.1 ¿Qué es GNU/Linux? ..........................................................................................................................91
6.1.2 ¿Qué es Debian? ..................................................................................................................................92
6.1.3 ¿Qué es Debian GNU/Linux? .............................................................................................................93
6.1.4 Sobre copyrights y licencias de software ...........................................................................................94
6.2 Requisitos del sistema..............................................................................................................96
6.2.1 Requisitos de memoria y espacio en disco.........................................................................................96
7. INSTALACIÓN DE DEBIAN..........................................................................................................97
7.1 Iniciar el proceso de instalación ..............................................................................................97
7.2 Elección del Idioma..................................................................................................................97
7.3 Notas de la versión ...................................................................................................................97
7.4 Menú principal de instalación de Debian GNU/Linux ..........................................................97
7.5 Configurar el teclado................................................................................................................98
7.6 Dar formato y activar una partición de intercambio ..............................................................98
7.7 Iniciar una partición de Linux .................................................................................................98
7.8 Instalar el núcleo y los módulos ..............................................................................................98
7.9 Configurar los controladores de dispositivos .........................................................................99
7.10 Configurar la red ......................................................................................................................99
7.11 Instalar el sistema base...........................................................................................................100
7.12 Reiniciar el sistema ................................................................................................................101
8. ESPECIFICACIÓN DE REQUISITOS..........................................................................................102
8.1 Requisitos funcionales ...........................................................................................................102
8.2 Requisitos no funcionales ......................................................................................................102
8.3 Restricciones...........................................................................................................................103
9. PROBLEMAS DE INSTALACIÓN DEL CLUSTER SSI...........................................................104
9.1 Problemas de Sistemas...........................................................................................................104
9.1.1 Ubuntu Server ....................................................................................................................................104
9.1.2 Debian Linux 3.1 Sarge (Kernel 2.4) ..............................................................................................105
9.2 Problemas con el hardware ....................................................................................................108
9.2.1 Características del hardware .............................................................................................................108
9.2.2 Incorrecto funcionamiento físico del hardware ...............................................................................108
CAPITULO III ..............................................................................................................................................110
10. OPENMOSIX ..............................................................................................................................111
10.1 Introducción a Mosix .............................................................................................................111
10.2 Introducción a OpenMosix ....................................................................................................112
10.3 ¿Qué es OpenMosix? .............................................................................................................113
10.4 ¿Por qué se ha elegido OpenMosix? .....................................................................................114
10.5 Características.........................................................................................................................115
10.5.1 ¿Cuáles son las desventajas de OpenMosix? ...................................................................................115
10.5.2 ¿Cuáles son las ventajas de OpenMosix?.........................................................................................115
10.5.3 ¿Se puede solucionar el problema de la memoria compartida?......................................................115
10.5.4 Subsistemas de openMosix ...............................................................................................................115
10.5.4.1 Mosix File System (MFS)......................................................................................................115
10.5.4.2 Migración de procesos ...........................................................................................................116
10.5.4.3 Direct File System Access (DFSA).......................................................................................116
10.5.4.4 Memory ushering....................................................................................................................116
10.5.5 El algoritmo de migración.................................................................................................................116
10.5.5.1 El nodo raíz .............................................................................................................................117
10.5.5.2 El mecanismo de migrado......................................................................................................117
10.5.5.3 ¿Cuándo podrá migrar un proceso?.......................................................................................117
10.5.5.4 La comunicación entre las dos áreas .....................................................................................118
10.6 Instalación de un cluster openMosix.....................................................................................120
10.6.1 Descargando las fuentes del kernel ..................................................................................................120
10.6.2 Pasos previos para recompilar el nuevo kernel................................................................................120
10.6.3 Descargando el parche de openMosix..............................................................................................120
10.6.4 Configurando kernel para compilarlo...............................................................................................121
10.6.5 Opciones del kernel de openMosix ..................................................................................................121
10.6.6 Nuestra configuración del kernel......................................................................................................123
10.7 Administración del cluster .....................................................................................................124
10.7.1 Administración básica .......................................................................................................................124
10.7.2 Las herramientas de área de usuario.................................................................................................124
5
10.7.3 Problemas...........................................................................................................................................127
11. OPENMOSIXVIEW ...................................................................................................................129
11.1 Introducción ............................................................................................................................129
11.2 Instalación ...............................................................................................................................130
11.2.1 Instalación de los paquetes RPM......................................................................................................130
11.2.2 Instalación de las fuentes ..................................................................................................................130
11.2.3 Script de configuración automático..................................................................................................130
11.2.4 Compilación Manual .........................................................................................................................130
12. TESTS Y BENCHMARKS CON OPENMOSIX.....................................................................132
12.1 OpenMosix Stress Test ..........................................................................................................132
12.1.1 Descripción del Test Stress ...............................................................................................................132
12.1.2 Instalación ..........................................................................................................................................133
12.1.3 Analisis de los resultados ..................................................................................................................133
12.1.3.1 Realización de las pruebas con cluster (3 nodos).................................................................133
12.1.3.2 Realización de las pruebas sin cluster (1 nodo)....................................................................142
12.2 Test de OpenMosixview ........................................................................................................147
12.2.1 Aplicación Principal ..........................................................................................................................147
12.2.2 openMosixview por linea de comandos...........................................................................................149
12.3 openMosixprocs .....................................................................................................................149
12.4 openMosixanlyzer ..................................................................................................................150
12.5 openMosixmigmom ...............................................................................................................152
13. TEST DE CISILIA......................................................................................................................153
13.1 Introducción ............................................................................................................................154
13.2 Instalación ...............................................................................................................................154
13.2.1 ¿Cómo conseguir cisilia? ..................................................................................................................155
13.2.2 ¿Cómo instalar cisilia? ......................................................................................................................155
13.3 Ejecución del test....................................................................................................................155
CAPITULO IV ..............................................................................................................................................160
14. OPENSSI .....................................................................................................................................161
14.1 Introducción a SSI ..................................................................................................................161
14.2 ¿Qué es OpenSSI? ..................................................................................................................163
14.3 ¿Por qué se ha elegido OpenSSI?..........................................................................................164
14.5 Limitaciones ...........................................................................................................................165
14.6 Instalación de un cluster OpenSSI ........................................................................................166
15. OPENSSI WEBVIEW ................................................................................................................175
15.1 Introducción ............................................................................................................................175
15.2 Instalación ...............................................................................................................................176
15.3 Requisitos................................................................................................................................177
15.4 Vista gráfica de la aplicación.................................................................................................178
16. TESTS Y BENCHMARKS CON OPENSSI ............................................................................181
16.1 OpenSSI Test Stress...............................................................................................................181
16.1.1 Descripción del Test Stress ...............................................................................................................181
16.1.2 Instalación ..........................................................................................................................................182
16.1.3 Analisis de los resultados ..................................................................................................................183
16.1.3.1 Realización de las pruebas con cluster(3 nodos) ..................................................................183
16.1.3.2 Realización de las pruebas con cluster(1 nodo)....................................................................191
CAPITULO V ................................................................................................................................................199
17. COMPARATIVA........................................................................................................................200
18. CONCLUSIONES ......................................................................................................................209
REFERENCIAS ............................................................................................................................................214
WEBS..........................................................................................................................................................214
LIBROS ......................................................................................................................................................215
OTROS .......................................................................................................................................................216
APÉNDICE I..................................................................................................................................................216
EL API DE OPENMOSIX ..............................................................................................................................217
APENDICE II ................................................................................................................................................220
6
CONFIGURACIÓN DEL KERNEL ....................................................................................................................221
APENDICE III ..............................................................................................................................................256
MANUAL DE CISILIA ....................................................................................................................................256
APENDICE IV...............................................................................................................................................258
DESCRIPCIÓN DEL CLUSTER CLOUTSER.....................................................................................................258
INDICE ILUSTRACIONES
7
Figura 1: Clusters HA. Redundancia ........................................................................... 31
Figura 2 Clusters HP. Comunicaciones en PVM ......................................................... 72
Figura 3 Bulbos y conexiones 1 .................................................................................. 84
Figura 4 Bulbos y conexiones 2 .................................................................................. 84
Figura 5 Procesamiento por lotes ................................................................................ 85
Figura 6 Circuitos Integrados I.................................................................................... 85
Figura 7 Circuitos Integrados II .................................................................................. 85
Figura 8 Sistema Operativo......................................................................................... 88
Figura 9 Gráfica Comparativa Debian Ubuntu .......................................................... 106
Figura 10 openMosixview Aplicación Principal........................................................ 148
Figura 11 openMosixprocs........................................................................................ 150
Figura 12 openMosixAnalyzer I muestra la carga computacional en cada nodo del
cluster. .............................................................................................................. 151
Figura 13 openMosixAnalyzer II estadísticas sobre la carga de cada no del cluster. .. 152
Figura 14 openMosixmigmom muestra las migraciones entre los diferentes nodos del
cluster. .............................................................................................................. 153
Figura 15 Cisilia Sin Contraseñas ............................................................................. 156
Figura 16 Cisilia Contraseña 4 dígitos....................................................................... 156
Figura 17 Cisilia Contraseña 6 dígitos....................................................................... 157
Figura 18 Cisilia Contraseña del Administrados y otra de 8 dígitos ........................... 157
Figura 19 OpenSSI Segundo nodo añdido y cargado al cluster .................................. 172
Figura 20 OpenSSI vista general del cluster .............................................................. 174
Figura 21 OpenSSI Características del nodo 2........................................................... 175
Figura 22 openSSI webview cluster map................................................................... 179
Figura 23 openSSI webview node 3 .......................................................................... 179
Figura 24 openSSI webView overview cluster .......................................................... 180
Figura 25 openSSI webView stats............................................................................. 181
Figura 26 openSSI web View overview Node 1 ........................................................ 181
Figura 27 StressTest 1 Nodo ..................................................................................... 201
Figura 28 StressTest OpenMosix 3 Nodos................................................................. 202
Figura 29 StressTest OpenSSI 3 Nodos..................................................................... 203
Figura 30 Benchmark Distkeygen ............................................................................ 205
Figura 31 Benchmark Portfolio................................................................................ 206
Figura 32 Benchmark Eatmen................................................................................... 206
Figura 33 Benchmark Forkit .................................................................................... 207
Figura 34 Benchmark Timewaster............................................................................. 207
Figura 35 Benchmark oM Stest................................................................................. 208
INDICE TABLAS
8
Tabla 1 Clusters HP. Aspectos de implementación...................................................... 60
Tabla 2 Características mínimas de hardware en Ubuntu........................................... 105
Tabla 3 Dependencias en Ubuntu.............................................................................. 105
Tabla 4 Parámetros de mosctl con más detalle........................................................... 126
Tabla 5 Parámetros adicionales para mosrun............................................................. 126
Tabla 6 Linea de Comandos en openMosixview ....................................................... 149
Tabla 7 Stress-Test OpenMosix – 1 Nodo ................................................................. 200
Tabla 8 Stress-Test OpenMosix – 3 Nodos................................................................ 202
Tabla 9 Stress-Test OpenSSI – 3 Nodos.................................................................... 203
Tabla 10 Stress Test OpenMosix 3 Nodos VS. 1 Nodo.............................................. 204
Tabla 11 Stress Test OpenSSI 3 Nodos VS. 1 Nodo.................................................. 204
Tabla 12 Stress Test OpenMosix 3 Nodos VS. OpenSSI 3 Nodos ............................. 204
Tabla 13 Eficiencia OpenMosix VS. OpenSSI VS.Sin Cluster .................................. 205
Tabla 14 El API de openMosix: /proc/hpc/remote/.................................................... 218
Tabla 15 El API de openMosix: /proc/hpc/admin/..................................................... 218
Tabla 16 El API de openMosix: /proc/hpc/decay/...................................................... 219
Tabla 17 El API de openMosix: /proc/hpc/info/ ........................................................ 219
Tabla 18 El API de openMosix: /proc/PID/............................................................... 220
9
INTRODUCCIÓN
Objetivo del proyecto
Nuestro principal objetivo es medir la eficiencia y el comportamiento de

diferentes clusters sobre unas mismas computadoras, de este modo, podremos establecer
una comparativa entre ellos y llegar a una conclusión.
Como objetivo secundario se ha planteado el comparar el rendimiento entre un

cluster con diferentes nodos (ordenadores) y un ordenador independiente a dicho cluster.
Podremos por tanto apreciar el rendimiento que se obtiene o bien se pierde en
determinados casos utilizando dicho cluster. El ordenador servidor de cada uno de
nuestros clusters será el mismo que realizará las pruebas independientemente de dicho
cluster. A su vez es el ordenador más potente.
Un cluster SSI (Single System Image) es un sistema compuesto por la unión de

diversas maquinas con la característica distintiva de ofrecer al usuario la imagen de ser
una única máquina. Para el manejo de este cluster SSI, instalaremos un sistema
operativo con el que se puede trabajar con clusters de tipo SSI (Linux Debian o un
familiar), trabajaremos con middleware, software que actúa entre el sistema operativo y
las aplicaciones para proporcionar al cluster una interfaz, herramientas de optimización,
mantenimiento del sistema y diferente software que siga el estándar de pruebas
(benchmarking) elegido.
Dichas pruebas que tienen en común ambos clusters son benchmarks estándar de
la Industria de Computación de Altas Prestaciones (HPC, High Performance Group)
que miden tanto el comportamiento como las prestaciones del cluster bajo situaciones
de cálculo intensivo y/o masivo.
Numerosos clusters en la breve historia de los mismos han sido creados con
fines de seguridad, de modo que además de usar un estándar de benchmark común a
ambos clusters para poder establecer una comparativa, realizaremos sobre openMosix
diferentes pruebas desencriptadoras de claves con diferentes dígitos a descifrar. Dichas
claves serán código que tanto Linux como Windows u otros sistemas operativos ocultan
premeditadamente al usuario. Dichas pruebas, nos acercaran a pruebas más prácticas
que hoy por hoy en su proporción se ejecutan sobre distintos clusters, es decir, pruebas
supercomputacionales que a su vez resultarán un valioso elemento en cuanto a medición
tanto de las prestaciones como del rendimiento del mismo.
Dentro de los diversos middleware que existen se comenzará con la instalación

de OpenMosix por ser el más utilizado y toda una referencia en el mundo de clusters
SSI. Por tanto también será la referencia base. Se desarrollarán también una serie de
pruebas (benchmarks) para correrlos sobre un cluster que a su vez es administrado
mediante OpenMosix de forma que se puedan extraer datos objetivos sobre
características importantes en un cluster SSI tales como el tiempo de migración de
procesos entre máquinas, la carga de red, o el tiempo de cálculo computacional.
Posteriormente se instalará, otro sistema de gestión de clusters SSI, llamado OpenSSI,
al que también se le pasarán los mismos benchmarks para poder establecer la
comparativa tanto a nivel teórico como práctico.
10
Aim of the Project
Our main objective is to measure the efficiency and the different behavior of
clusters on same computers, in this way, we will be able to establish a comparative one
among them and to reach a conclusion.
As secondary target has considered comparing the yield between cluster with
different nodes (computers) and an independent computer. We will be able therefore to
appreciate the yield that is obtained or lost in certain cases using this of cluster. The
server of ours clusters will be he himself who will independently make the tests of this
cluster. It is the most powerful computer as well.
Cluster SSI (Single Image System) it is a system made up of the union of diverse
machines with the distinguishing characteristic to offer to the user the image of being an
only machine. For the handling of this cluster SSI, we will install an operating system
with which it is possible to be worked with clusters of type SSI (Linux Debian or a
relative), we will work with middleware, software that acts between the operating
system and the applications to provide when cluster an interface, tools of optimization,
maintenance of the system and different software that the standard of tests follows
(benchmarking) chosen.
These tests that have in common both clusters are benchmarks standard of the
Industry of Computation of High Benefits (HPC, High Group Performance) that
measure so much the behavior as the benefits of cluster under situations of intensive
and/or massive calculation.
Clusters has been created with security aims, so that besides to use a standard of
benchmark common to both clusters to be able to establish a comparative one, we will
make on openMosix different desencriptadoras tests from keys with different digits to
decipher. Key happiness will be code that as much Linux as Windows or other
operating systems hides to the user very premeditadedly. These tests approached to us
more practical tests that at the present time in his proportion they are executed on
different clusters.
Within diverse middleware that exists it will begin with the installation of
OpenMosix for being the most used and a reference in the world of clusters SSI.
Therefore also it will be the reference bases. A series of tests (benchmarks) to run them
on cluster that will also be developed it is administered as well by means of OpenMosix
so that objective data can be extracted on important characteristics in cluster SSI such as
the time of migration of processes between machines, the load of network, or the time
of computational calculation. Later one will install, another system of management of
clusters SSI, called OpenSSI, to which also they will go such benchmarks to him to be
able to establish the comparative one at theoric level as much as practice.
11
12
CAPITULO I
"El hombre todavía puede apagar el ordenador. Sin embargo, tendremos que esforzarnos
mucho para conservar este privilegio."
WEIZEMBAUM, J.
- Sociólogo norteamericano experto en ordenadores
13
1. CLUSTER
1.1 ¿Qué es un cluster?
Aunque parezca sencillo de responder no lo es en absoluto. Podría incluirse
alguna definición de algún libro, pero el problema es que ni los expertos en clusters ni la
gente que los implementa se ponen de acuerdo en qué es aquello en lo que trabajan.
Un cluster se puede entender como:
Un conjunto de máquinas unidas por una red de comunicación trabajando por

un servicio conjunto. Según el servicio puede ser dar alta disponibilidad, alto
rendimiento, etc...
Realmente el cambio de ambiente es mínimo, desde luego a nadie se le ocurriría

definir cluster en base al contenido de los programas que se ejecuten y de hecho es
posible que los juegos tengan más capacidades de procesamiento distribuido que los
propios programas, entonces ¿qué es un cluster?
Hay definiciones que distinguen entre cluster de máquinas SMP y clusters

formados por nodos monoprocesadores. Hay arquitecturas clusters que se denominan
constelaciones y se caracterizan por que cada nodo contiene más procesadores que el
número de nodos. A pesar de todo, las constelaciones siguen siendo clusters de
componentes o nodos aventajados y caros. De hecho entre las máquinas que aparecen en
el top500 existen unos pocos clusters que pertenecen a organizaciones que no son
gigantes de la informática, lo cual indica el precio que pueden llegar a tener estos
sistemas.
Por poner unos ejemplos de la disparidad de opiniones que existen, se adjuntan

las definiciones que dan ciertas autoridades de esta materia:
Un cluster consiste en un conjunto de máquinas y un servidor de cluster

dedicado, para realizar los relativamente infrecuentes accesos a los recursos de otros
procesos, se accede al servidor de cluster de cada grupo del libro Operating System
Concepts de Silberschatz Galvin.
Un cluster es la variación de bajo precio de un multiprocesador masivamente

paralelo (miles de procesadores, memoria distribuida, red de baja latencia), con las
siguientes diferencias: cada nodo es una máquina quizás sin algo del hardware
(monitor, teclado, mouse, etc.), el nodo podría ser SMP. Los nodos se conectan por una
red de bajo precio como Ethernet o ATM aunque en clusters comerciales se pueden
usar tecnologías de red propias. El interfaz de red no está muy acoplado al bus I/O.
Todos los nodos tienen disco local.
Cada nodo tiene un sistema operativo UNIX con una capa de software para
soportar todas las características del cluster del libro Scalable Parallel Computing de
Kai Hwang y Khiwei Xu.
14
Es una clase de arquitectura de computador paralelo que se basa en unir
máquinas independientes cooperativas integradas por medio de redes de interconexión
para proveer un sistema coordinado, capaz de procesar una carga del autor Dr.
Thomas Sterling.
15
1.2 Características de un cluster
Si no hay acuerdo sobre lo que es un cluster poco podrá acertarse en sus
características. En este apartado se explican los requisitos que deben cumplir un
conjunto de computadoras para ser consideradas cluster, tal y como se conocen hasta el
momento.
Para crear un cluster se necesitan al menos dos nodos. Una de las características
principales de estas arquitecturas es que exista un medio de comunicación (red) donde
los procesos puedan migrar para computarse en diferentes estaciones paralelamente. Un
solo nodo no cumple este requerimiento por su condición de aislamiento para poder
compartir información. Las arquitecturas con varios procesadores en placa tampoco son
consideradas clusters, bien sean máquinas SMP o mainframes, debido a que el bus de
comunicación no suele ser de red, sino interno.
Por esta razón se deduce la primera característica de un cluster:
- Un cluster consta de 2 o más nodos.
Los nodos necesitan estar conectados para llevar a cabo su misión. Por tanto:
- Los nodos de un cluster están conectados entre sí por, al menos, un canal de

comunicación.
Por ahora se ha referenciado a las características físicas de un cluster, que son

las características sobre las que más consenso hay. Pero existen más problemas
sobre las características del programario de control que se ejecuta, pues es el
software el que finalmente dotará al conjunto de máquinas de capacidad para
migrar procesos, balancear la carga en cada nodo, etc.
- Los clusters necesitan software de control especializado.
El problema también se plantea por los distintos tipos de clusters, cada uno de
ellos requiere un modelado y diseño del software distinto.
Como es obvio las características del cluster son completamente dependientes

del software, por lo que no se tratarán las funcionalidades del software sino el
modelo general de software que compone un cluster.
Para empezar, parte de este software se debe dedicar a la comunicación entre los
nodos. Existen varios tipos de software que pueden conformar un cluster:
• Software a nivel de aplicación.
Este tipo de software se sitúa a nivel de aplicación, se utilizan

generalmente bibliotecas de carácter general que permiten la
abstracción de un nodo a un sistema conjunto, permitiendo crear
aplicaciones en un entorno distribuido de manera lo más abstracta
posible. Este tipo de software suele generar elementos de proceso del
16
tipo rutinas, procesos o tareas, que se ejecutan en cada nodo del
cluster y se comunican entre sí a través de la red.
• Software a nivel de sistema.
Este tipo de software se sitúa a nivel de sistema, suele estar

implementado como parte del sistema operativo de cada nodo, o ser
la totalidad de éste.
Es más crítico y complejo, por otro lado suele resolver problemas de

carácter más general que los anteriores y su eficiencia, por norma
general, es mayor.
A pesar de esta división existen casos en los cuales se hace uso de un conjunto
de piezas de software de cada tipo para conformar un sistema cluster completo. Son
implementaciones híbridas donde un cluster puede tener implementado a nivel de kernel
parte del sistema y otra parte estar preparada a nivel de usuario.
1.2.1 Esquema y otras características
Las características básicas de un cluster de carácter general podrían resumirse en

el siguiente esquema:
1. Un cluster consta de 2 o más nodos conectados entre sí, por un canal de

comunicación funcional.
2. En cada nodo es imprescindible un elemento de proceso, memoria y un interfaz
para comunicarse con la red del cluster.
3. Los clústeres necesitan software especializado. Este software y las máquinas
conforman el cluster. El software puede ser:
1. aplicación
2. sistema
4. Se define acoplamiento de un cluster como nivel de colaboración que une los
elementos del cluster. De este modo se categorizan en:
1. Acoplamiento fuerte
2. Acoplamiento medio o moderado
3. Acoplamiento débil
5. Todos los elementos del cluster trabajan para cumplir una funcionalidad
conjunta, sea esta la que sea. Es la funcionalidad la que caracteriza el sistema.
Muchos libros dan otra serie de características necesarias (Scalable Parallel

Computing de Kai Hwang y Zhiwei Xu)
En general la catalogación de los clusters se hace en base a tres factores de

diseño bastante ortogonales entre sí:
• Control
• Acoplamiento
• Homogeneidad
Control de un cluster
17
El factor de control del cluster contiene un parámetro de control que implica el
modelo de gestión que propone el cluster. Este modelo de gestión hace referencia a la
manera de configurar el cluster y es dependiente del modelo de conexionado o
colaboración que surgen entre los nodos. Puede ser de dos tipos:
• Control centralizado
Se hace uso de un nodo maestro desde el cual se puede configurar el

comportamiento de todo el sistema. Este nodo es un punto crítico del sistema
aunque es una ventaja para una mejor gestión del cluster.
• Control descentralizado
En un modelo distribuido donde cada nodo debe administrarse y gestionarse.

También pueden ser gestionados mediante aplicaciones de más alto nivel de manera
centralizada, pero la mayoría de la gestión que hace el nodo local es leer archivos de
configuración de su propio nodo.
Es propio de sistemas distribuidos, como ventaja presenta más tolerancia a fallos,

como sistema global, y como desventajas que la gestión y administración de los
equipos requiere más tiempo.
Acoplamiento de un cluster
Dependiendo del tipo de software, el sistema puede estar más o menos acoplado.
Se entiende por acoplamiento del software a la integración que tengan todos los
elementos software que existan en cada nodo. Gran parte de la integración del sistema
la produce la comunicación entre los nodos, y es por esta razón por la que se define el
acoplamiento; otra parte es la que implica cómo de crítico es el software y su capacidad
de recuperación ante fallos.
Aquí hay que hacer un pequeño inciso para destacar que todo esto depende de si
el sistema es centralizado o distribuido. En cualquier caso, el acoplamiento del software
es una medida subjetiva basada en la integración de un sistema cluster a nivel general.
Se distingue entre 3 tipos de acoplamiento:
• Acoplamiento fuerte.
El software que entra en este grupo es software cuyos elementos se

interrelacionan mucho unos con otros y posibilitan la mayoría de las funcionalidades del
cluster de manera altamente cooperativa. El caso de acoplamiento más fuerte que se
puede dar es que solamente haya una imagen del kernel del sistema operativo,
distribuida entre un conjunto de nodos que la compartirán. Por supuesto algo
fundamental es poder acceder a todas las partes de este sistema operativo,
estrechamente relacionadas entre sí y distribuidas entre los nodos.
18
Este caso, una sola imagen del kernel del sistema operativo, es el que se
considera como más acoplado, de hecho no está catalogado como cluster, sino como
sistema operativo distribuido.
Otro ejemplo son los cluster SSI, en estos clusters todos los nodos ven una
misma imagen del sistema, pero todos los nodos tienen su propio sistema operativo,
aunque estos sistemas están estrechamente relacionados para dar la sensación a las
aplicaciones que todos los nodos son idénticos y se acceda de una manera homogénea a
los recursos del sistema total.
Si arranca o ejecuta una aplicación, ésta verá un sistema homogéneo, por lo tanto
los kernels tienen que conocer los recursos de otros nodos para presentarle al sistema
local los recursos que encontraría si estuviera en otro nodo. Por supuesto se necesita un
sistema de nombres único, manejado de sistema distribuida o centralizada y un mapeo
de los recursos físicos a este sistema de nombres.
• Acoplamiento medio.
A este grupo pertenece un software que no necesita un conocimiento tan

exhaustivo de todos los recursos de otros nodos, pero que sigue usando el software de
otros nodos para aplicaciones de muy bajo nivel. Como ejemplo Linux-HA.
• Acoplamiento débil.
Generalmente se basan en aplicaciones construidas por bibliotecas preparadas

para aplicaciones distribuidas. Es el caso de por ejemplo PVM, MPI o CORBA que hay
dotarles de una estructura superior que utilice las capacidades del cluster para que éste
funcione.
Homogeneidad de un cluster
• Homogéneos
Cluster que está formado por equipos con la misma arquitectura. Todos los
nodos tienen una arquitectura y recursos similares, de manera que no existen
muchas diferencias entre cada nodo.
• Heterogéneos
Cluster que está formado por nodos con distinciones que pueden estar en los
siguientes puntos.
o Tiempos de acceso distintos

o Arquitectura distinta
o Sistema operativo distinto
o Rendimiento de los procesadores o recursos sobre una misma
arquitectura distintos
19
El uso de arquitecturas distintas, o distintos sistemas operativos, impone que
exista una biblioteca que haga de interfaz, e incluso una sintaxis de notación
abstracta del tipo ASN.1 o XDR en la capa de presentación que utilice la interfaz
de comunicación de nuestro sistema distribuido o cluster. Esto hace que este tipo
de clusters se consideren implementados a nivel de aplicación.
Existen otros muchos factores de diseño que limitan el comportamiento y

modelado de un cluster. La imposibilidad de llegar a clusters que paralelicen cualquier
proceso se basa en que la mayoría de las aplicaciones hacen uso, en mayor o menor
medida, de algoritmos secuenciales no paralelizables.
20
1.3 Clasificación según el servicio prioritario
Generalmente el diseño de un cluster se realiza para solucionar problemas de
tipo:
• Mejora de rendimiento
• Abaratamiento del coste
• Distribución de factores de riesgo del sistema
• Escalabilidad
Por regla general la proporción coste/capacidad de cálculo aumenta de forma

exponencial. El modelo de los clusters permite que la mejora de rendimiento sea
evidente respecto a grandes mainframes a un precio realmente asequible. Lo que explica
a su vez el segundo punto, acerca del coste de los clusters, que permite relaciones
rendimiento precio que se acercan a un margen lineal dependiendo del cluster
implementado.
Por otro lado esta la distribución de riesgos. La mayoría de los usuarios tienen
sus servicios, aplicaciones, bases de datos o recursos en un solo ordenador, o
dependientes de un solo ordenador. Otro paso más adelante es replicar la base de datos
sobre sistemas de archivos distribuidos de manera que estos no se pierdan por que los
datos son un recurso importante. Actualmente el mercado de la informática exige no
solo que los datos pueden ser o no críticos, sino que los servicios estén activos
constantemente. Esto exige, medios y técnicas que permitan que el tiempo en el que una
máquina esté inactiva sea el menor posible. La distribución de factores de riesgo a lo
largo de un cluster (o la distribución de funcionalidades en casos más generales) permite
de una forma única obtener la funcionalidad de una manera más confiable: si una
máquina cae otras podrán dar el servicio.
Por último está el factor de escalabilidad, del cual se habló en el tema de

introducción. Cuanto más escalable es un sistema menos costará mejorar el rendimiento,
lo cual abarata el coste, y en el caso de que el cluster lo implemente distribuye más el
riesgo de caída de un sistema.
En cualquier caso, todas estas características dan pie a los tipos de clusters que
se van a ver.
Alto rendimiento (HP, high performance)
Los clusters de alto rendimiento han sido creados para compartir el recurso más
valioso de un ordenador, es decir, el tiempo de proceso. Cualquier operación que
necesite altos tiempos de CPU puede ser utilizada en un cluster de alto rendimiento,
siempre que se encuentre un algoritmo que sea paralelizable.
Existen clusters que pueden ser denominados de alto rendimiento tanto a nivel
de sistema como a nivel de aplicación. A nivel de sistema tenemos openMosix, mientras
que a nivel de aplicación se encuentran otros como MPI, PVM, Beowulf y otros muchos.
En cualquier caso, estos clusters hacen uso de la capacidad de procesamiento que
pueden tener varias máquinas.
21
Alta disponibilidad (HA, high availability)
Los clusters de alta disponibilidad son bastante ortogonales en lo que se refieren

a funcionalidad a un cluster de alto rendimiento. Los clusters de alta disponibilidad
pretenden dar servicios de cualquier tipo, todos los días de la semana y a todas las horas
del dia, son clusters donde la principal funcionalidad es estar controlando y actuando
para que un servicio o varios se encuentren activos durante el máximo periodo de
tiempo posible. En estos casos se puede comprobar como la monitorización de otros es
parte de la colaboración entre los nodos del cluster.
Alta confiabilidad (HR, high reliability)
Por ultimo, están los clusters de alta confiabilidad. Estos clusters tratan de
aportar la máxima confiabilidad en un entorno, en la cual se necesite saber que el
sistema se va a comportar de una manera determinada. Puede tratarse por ejemplo de
sistemas de respuesta a tiempo real.
Pueden existir otras catalogaciones en lo que se refiere a tipos de clusters, en

este caso, solamente se han considerado las tres con mayor nivel de aceptación, si bien
existe alguno de ellos que puede ser considerar o como cluster de varios tipos a la vez.
22
1.4 Introducción a las diferentes clases de Clusters
1.4.1 Clusters HP: alto rendimiento
Se harán distinciones entre los que se implementan a nivel de sistema operativo

y los que se implementan a nivel de librerías, y se explicarán qué tipo de problemas
resuelven ambos.
1.4.1.1 La misión
La misión o el objetivo de este tipo de clusters es, como su propio nombre indica
mejorar el rendimiento en la obtención de la solución de un problema, en términos bien
del tiempo de respuesta bien de su precisión.
Dentro de esta definición no se engloba ningún tipo de problema en concreto.

Esto supone que cualquier cluster que haga que el rendimiento del sistema aumente
respecto al de uno de los nodos individuales puede ser considerado cluster HP.
1.4.1.2 Problemas que solucionan
Generalmente estos problemas de cómputo suelen estar ligados a:
• Cálculos matemáticos
• Renderizaciones de gráficos
• Compilación de programas
• Compresión de datos
• Descifrado de códigos
• Rendimiento del sistema operativo, (incluyendo en él, el rendimiento de los
recursos de cada nodo)
Existen otros muchos problemas más que se pueden solucionar con clusters HP,
donde cada uno aplica de una manera u otra las técnicas necesarias para habilitar la
paralelización del problema, su distribución entre los nodos y obtención del resultado.
1.4.1.3 Técnicas que utilizan
Las técnicas utilizadas dependen de a qué nivel trabaje el cluster.
Los clusters implementados a nivel de aplicación no suelen implementar

balanceo de carga. Suelen basar todo su funcionamiento en una política de localización
que sitúa las tareas en los diferentes nodos del cluster, y las comunica mediante las
librerías abstractas. Resuelven problemas de cualquier tipo de los que se han visto en el
apartado anterior, pero se deben diseñar y codificar aplicaciones propias para cada tipo
para poderlas utilizar en estos clusters.
Por otro lado están los sistemas de alto rendimiento implementados a nivel de
sistema. Estos clusters basan todo su funcionamiento en comunicación y colaboración
de los nodos a nivel de sistema operativo, lo que implica generalmente que son clusters
de nodos de la misma arquitectura, con ventajas en lo que se refiere al factor de
23
acoplamiento, y que basan su funcionamiento en la compartición de recursos a cualquier
nivel, balanceo de la carga de manera dinámica, funciones de planificación especiales y
otros tantos factores que componen el sistema. Se intentan acercar a sistemas SSI, el
problema está en que para obtener un sistema SSI hay que ceder en el apartado de
compatibilidad con los sistemas actuales, por lo cual se suele llegar a un factor de
compromiso.
Entre las limitaciones que existen actualmente está la incapacidad de balancear

la carga dinámica de las librerías PVM o la incapacidad de openMosix de migrar
procesos que hacen uso de memoria compartida. Una técnica que obtiene mayor ventaja
es cruzar ambos sistemas: PVM + openMosix. Se obtiene un sistema con un factor de
acoplamiento elevado que presta las ventajas de uno y otro, con una pequeña limitación
por desventajas de cada uno.
1.4.2 Clusters HA: alta disponibilidad
Son otro tipo de clusters completamente distintos a los anteriores. Son los más
solicitados por las empresas ya que están destinados a mejorar los servicios que éstas
ofrecen cara a los clientes en las redes a las que pertenecen, tanto en redes locales como
en redes como Internet. En este apartado se darán las claves que explican tanto el diseño
de estos clusters así como algún factor de implementación.
1.4.2.1 La misión
Los clusters de alta disponibilidad han sido diseñados para la máxima

disponibilidad sobre los servicios que presenta el cluster. Este tipo de clusters son la
competencia que abarata los sistemas redundantes, de manera que ofrecen una serie de
servicios durante el mayor tiempo posible. Para poder dar estos servicios los clusters de
este tipo se implementan en base a tres factores.
• Fiabilidad
• Disponibilidad
• Dotación de servicio
Mediante estos tres tipos de actuaciones y los mecanismos que lo implementan

se asegura que un servicio esté el máximo tiempo disponible y que éste funcione de una
manera fiable. Respecto al tercer punto, se refiere a la dotación de uno de estos clusters
de un servicio que provea a clientes externos.
1.4.2.2 Problemas que solucionan
La mayoría de estos problemas están ligados a la necesidad de dar servicio

continuado de cualquier tipo a una serie de clientes de manera ininterrumpida. En una
construcción real se suelen producir fallos inesperados en las máquinas, estos fallos
provocan la aparición de dos eventos en el tiempo: el tiempo en el que el servicio está
inactivo y el tiempo de reparación del problema.
Entre los problemas que solucionan se encuentran:
24
• Sistemas de información redundante
• Sistemas tolerantes a fallos
• Balanceo de carga entre varios servidores
• Balanceo de conexiones entre varios servidores
En general todos estos problemas se ligan en dos fuentes de necesidad de las

empresas u organizaciones.
• Tener un servicio disponible

• Ahorrar económicamente todo lo que sea posible
El servicio puede ser diverso. Desde un sistema de ficheros distribuidos de

carácter muy barato, hasta grandes clusters de balanceo de carga y conexiones para los
grandes portales de Internet. Cualquier funcionalidad requerida en un entorno de red
puede ser colocada en un cluster e implementar mecanismos para hacer que esta
obtenga la mayor disponibilidad posible.
1.4.2.3 Técnicas que utilizan
Como se ha visto en el apartado anterior los servicios y el funcionamiento de los

mismos suelen ser de carácter bastante distinto, en cualquier caso, se suelen proponer
sistemas desde SSI que plantean serias dudas en lo que se refiere a localización de un
servidor, hasta balanceo de carga o de conexiones. También suelen contener secciones
de código que realizan monitorización de carga o monitorización de servicios para
activar las acciones necesarias para cuando estos caigan.
Se basan en principios muy simples que pueden ser desarrollados hasta crear
sistemas complejos especializados para cada entorno particular. En cualquier caso, las
técnicas de estos sistemas suelen basarse en excluir del sistema aquellos puntos críticos
que pueden producir un fallo y por tanto la pérdida de disponibilidad de un servicio.
Para esto se suelen implementar desde enlaces de red redundantes hasta disponer de N
máquinas para hacer una misma tarea de manera que si caen N-1 máquinas el servicio
permanece activo sin pérdida de rendimiento.
La explicación de estas técnicas ha sido muy somera, se darán con más detalle
en el capítulo perteneciente a clusters HA.
1.4.3 Clusters HR: alta confiabilidad
Este tipo de clusters son los más difíciles de implementar. No se basan

solamente en conceder servicios de alta disponibilidad, sino en ofrecer un entorno de
sistema altamente confiable. Esto implica muchísima sobrecarga en el sistema, son
también clusters muy acoplados.
Dar a un cluster SSI capacidad de alta confiabilidad implica gastar recursos

necesarios para evitar que aplicaciones caigan. Aquí hay que hacer de nuevo un inciso.
En los clusters de alta disponibilidad generalmente una vez que el servicio ha

caído éste se relanza, y no existe manera de conservar el estado del servidor anterior,
25
más que mediante puntos de parada o checkpoints, pero que en conexiones en tiempo
real no suelen ser suficientes. Por otro lado, los clusters confiables tratan de mantener el
estado de las aplicaciones, no simplemente de utilizar el último checkpoint del sistema y
relanzar el servicio.
Generalmente este tipo de clusters suele ser utilizado para entornos de tipo
empresarial y esta funcionalidad solamente puede ser efectuada por hardware
especializado. Por el momento no existe ninguno de estos clusters implementados como
software. Esto se debe a limitaciones de la latencia de la red, así como a la complejidad
de mantener los estados.
Se hacen necesarias características de cluster SSI, tener un único reloj de sistema

conjunto y otras más. Dada la naturaleza asíncrona actual en el campo de los clusters,
este tipo de clusters aún será difícil de implementar hasta que no se abaraten las técnicas
de comunicación.
26
2. CLASES DE CLUSTERS
2.1 Clusters HA
2.1.1 Introducción
Los clusters HA están diseñados especialmente para dar un servicio de alta

disponibilidad. Esto tiene muchas aplicaciones en el mundo actual donde existen gran
cantidad de servicios informáticos que debe funcionar 24x7x365. Estos clústeres son
una alternativa real a otros sistemas usados tradicionalmente para estas tareas de
hardware redundante que son mucho más caros, por ejemplo los ordenadores Tandem.
2.1.2 El interés comercial
Desde ya hace unos años Heartbeat está en las distribuciones SuSE, Conectiva y
Mandrake; incluso Mission Critical Linux se ha interesado en él. Todo esto es así
porque el mercado de clusters HA es un mercado con muchos potenciales clientes y, lo
que es quizás más importante, para los intereses comerciales de muchas empresas.
Piénsese como ejemplo una empresa de grandes almacenes que tiene

ordenadores carísimos validando las operaciones de tarjeta de crédito. Estos
ordenadores no deben cancelar el servicio nunca porque si lo hicieran todo el sistema de
tarjetas de créditos se vendría abajo, con lo que se podrían ocasionar grandes pérdidas
económicas.
Por todo esto se desarrollan proyectos que intentan conseguir esta disponibilidad
pero no gracias a un soporte hardware carísimo, sino usando clusters. Las empresas que
necesitan alta disponibilidad suelen pagar a la empresa que le ofrece este servicio aun
cuando los programas sean de libre distribución, quieren unas garantías. Esto está
haciendo que muchas empresas estén colaborando en proyectos libres de HA, cosa que
no deja de ir en pro de la mejora del software en cuestión.
Las enormes diferencias entre el precio del hardware de las soluciones

tradicionales y estas nuevas soluciones hacen que las empresas tengan un buen margen
de beneficio dando un servicio de soporte.
Es bastante obvio por qué estos clusters están más solicitados que los de alto
rendimiento (HP): la mayoría de las empresas se pueden permitir en cierto modo
máquinas potentes que les solucionen las necesidades de cómputo, o simplemente
contar con el tiempo suficiente para que sus actuales equipos procesen toda la
información que necesitan. En la mayoría de los casos el tiempo no es un factor crítico y
por tanto la velocidad o la capacidad de cómputo de las máquinas no es importante. Por
otro lado, que se repliquen sistemas de archivos para que estén disponibles, o bases de
datos, o servicios necesarios para mantener la gestión de la empresa en funcionamiento,
o servicios de comunicación entre departamentos en la empresa y otros servicios, son
realmente críticos para las empresas en todos y cada uno de los días en los que estas
están funcionando (e incluso cuando no están funcionando).
27
2.1.3 Conceptos importantes
Un buen cluster HA necesita proveer fiabilidad, disponibilidad y servicio RAS.

Por tanto debe existir una forma de saber cuándo un servicio ha caído y cuándo vuelve a
funcionar.
Esto se puede conseguir de dos maneras, por hardware y por software. No se van
a tratar aquí los mecanismos que existen para conseguir alta disponibilidad por
hardware, pues están más allá de los objetivos de este proyecto. Basta decir que
construir estos ordenadores es muy caro pues necesitan gran cantidad de hardware
redundante que esté ejecutando paralelamente en todo momento las mismas operaciones
que el hardware principal (por ejemplo una colección de placas base) y un sistema para
pasar el control o la información del hardware con errores a hardware que se ejecute
correctamente.
Los clusters HA solucionan el problema de la disponibilidad con una buena capa

de software. Por supuesto mejor cuanto más ayuda se tenga del hardware: UPS, redes
ópticas, etc. Pero la idea tras estos sistemas es no tener que gastarse millones de euros
en un sistema que no puede ser actualizado ni escalado. Con una inversión mucho
menor y con software diseñado específicamente se puede conseguir alta disponibilidad.
Para conseguir la alta disponibilidad en un cluster los nodos tienen que saber
cuándo ocurre un error para hacer una o varias de las siguientes acciones:
• Intentar recuperar los datos del nodo que ha fallado.
Cuando un nodo cae hay que recuperar de los discos duros compartidos la
información de los nodos para poder seguir con el trabajo. Generalmente hay
scripts de recuperación para intentar recuperarse del fallo.
• Continuar con el trabajo que desempeñaba el nodo caído.
Aquí no se intenta recuperar del fallo sino que cuando se descubre que ocurrió
un fallo otro nodo pasa a desempeñar el puesto del nodo que falló.
Esta es la opción que toma por ejemplo Heartbeat: permite que 2 ordenadores
mantengan una comunicación por un cable serie o Ethernet, cuando un
ordenador cae el ordenador que no recibe respuesta ejecuta las órdenes
adecuadas para ocupar su lugar.
Las ventajas de escalabilidad y economía de los clusters tienen sus desventajas.

Una de ellas es la seguridad. Cuando se diseña un cluster se busca que haya ciertas
facilidades de comunicación entre las estaciones y en clusters de alta disponibilidad el
traspaso de información puede ser muy importante.
Recordando el ejemplo anterior de las tarjetas de crédito, se ha visto que se

podría crear un cluster de alta disponibilidad que costara varias veces menos que el
ordenador centralizado. El problema podría sobrevenir cuando ese cluster se encargara
de hacer operaciones con los números de las tarjetas de crédito y transacciones
monetarias de la empresa. Las facilidades de comunicación podrían ocasionar un
28
gravísimo problema de seguridad. Un agente malicioso podría hacer creer al cluster que
uno de los nodos ha caído, entonces podría aprovechar el traspaso de la información de
los nodos para conseguir los números de varias tarjetas de crédito.
Este es uno de los motivos por los que, en según qué entornos, estos sistemas no
se hayan implantado.
2.1.3.1 Servicio RAS
En el diseño de sistemas de alta disponibilidad es necesario obtener la suma de

los tres términos que conforman el acrónimo RAS.
• Reliability.
El sistema debe ser confiable en el sentido de que éste actúe realmente como se
ha programado. Por un lado está el problema de coordinar el sistema cuando éste
está distribuido entre nodos, por otro lado hay el problema de que todo el
software que integra el sistema funcione entre sí de manera confiable.
En general se trata de que el sistema pueda operar sin ningún tipo de caída o
fallo de servicio.
• Availability.
Es lógicamente la base de este tipo de clusters. La disponibilidad indica el

porcentaje de tiempo que el sistema esta disponible en su funcionalidad hacia los
usuarios.
• Serviceability.
Referido a cómo de fácil es controlar los servicios del sistema y qué servicios se
proveen, incluyendo todos los componentes del sistema.
La disponibilidad es el que prima por encima de los anteriores. La disponibilidad

de un sistema es dependiente de varios factores. Por un lado el tiempo que el sistema
está funcionando sin problemas, por otro lado el tiempo en el que el sistema esta
fallando y por último el tiempo que se tarda en reparar o restaurar el sistema.
Para medir todos estos factores son necesarios fallos. Existen dos tipos de fallos:
los fallos que provocan los administradores (para ver o medir los tiempos de
recuperación y tiempos de caídas) y los fallos no provocados, que son los que
demuestran que los tiempos de reparación suelen ser mucho más grandes de los que se
estimó en los fallos provocados.
La naturaleza de los fallos puede afectar de manera diferente al sistema:

pudiéndolo ralentizar, inutilizar o para algunos servicios.
29
2.1.3.2 Técnicas para proveer de disponibilidad
Cualquier técnica deberá, por definición, intentar que tanto el tiempo de fallo del
sistema como el tiempo de reparación del mismo sean lo más pequeños posibles.
Las que tratan de reducir el tiempo de reparación se componen a base de scripts

o programas que detectan el fallo del sistema y tratan de recuperarlo sin necesidad de un
técnico especializado. En general son técnicas de automatización de tareas basadas en
sistemas expertos (SE). Al reducir el tiempo de recuperación, el sistema puede no
solamente funcionar activamente sin fallos durante más tiempo, sino que también se
aumenta su confiabilidad.
Técnicas basadas en redundancia
Por un lado hay las técnicas basadas en reducir el tiempo de fallo o caída de
funcionamiento, estas técnicas se basan principalmente en efectuar algún tipo de
redundancia sobre los dispositivos críticos. Saber cuáles son estos dispositivos suele ser
cuestión de conocimiento acerca del sistema y de sentido común.
Las técnicas basadas en la redundancia de recursos críticos permiten que cuando

se presenta la caída de uno de estos recursos, otro tome la funcionalidad. Una vez esto
sucede el recurso maestro puede ser reparado mientras que el recurso backup toma el
control. Entre los tipos de redundancia que pueden presentar los sistemas hay:
• Redundancia aislada.
Es la redundancia más conocida donde existen 2 copias para dar una

funcionalidad o servicio. Por un lado hay la copia maestro y por otro lado la
copia esclavo. Cuando cae el servicio o recurso la copia redundante pasa a ser la
utilizada, de esta manera el tiempo de caída es mínimo o inexistente.
Los recursos pueden ser de cualquier tipo: procesadores, fuentes de alimentación,

raids de discos, redes, imágenes de sistemas operativos...
Las ventajas son cuantiosas: para empezar no existen puntos críticos de fallo en
el sistema, es decir, el sistema al completo no es tomado como un sistema con
puntos de fallos que bajen la confiabilidad del mismo. Los componentes que han
fallado pueden ser reparados sin que esto cause sobre el sistema una parada.
Por último, cada componente del sistema puede comprobar de manera periódica
si se ha producido algún tipo de fallo en los sistemas de backup, de modo que se
compruebe que éstos están siempre funcionales. Otra opción es que además de
comprobar, presenten habilidades para localizar fallos en sistemas y los intenten
recuperar de manera automatizada.
• N-Redundancia.
Es igual que el anterior pero se tiene N equipos para ofrecer un mismo servicio,
con lo cual presenta más tolerancia a fallos.
30
Así por ejemplo para dotar de sistema redundante a una red como la que muestra
el esquema A de la figura debería haber el doble de recursos necesarios para construirla,
e implementarlos como en el sistema B.
Figura 1: Clusters HA. Redundancia
En este caso se replicaron:
• LAN
• LAN para los servidores
• Los servidores
• El bus SCSI de acceso a discos duros
• Discos duros
Como se puede ver la replicación proporciona rutas alternativas, discos

alternativos y en general recursos alternativos, y es aplicada sobre todos aquellos
recursos que se consideren críticos en una red.
Otro apartado a la hora de considerar la instalación de dispositivos redundantes

es la configuración o el modelo de funcionamiento de los mismos. Depende de como se
haya implementado el software y como se haya dispuesto el hardware y define el modo
de comportamiento de la redundancia. Esta redundancia puede ser del tipo:
1. Hot Standby.
Este tipo de configuración es la que se ha visto hasta ahora. En cuanto el

nodo maestro cae existe un nodo backup que toma el control de sus operaciones.
Hasta ahora no se ha tenido en cuenta un punto importante: el doble gasto en
recursos que en un principio y si las cosas van bien se están desperdiciando.
El servidor de backup simplemente monitoriza sus conexiones, la normal

y la redundante en el caso de que esta exista, para asegurar que cuando el nodo
31
maestro caiga tome correctamente el control de las operaciones. Exceptuando
estas operaciones, el nodo backup no hace nada.
2. Toma de cargos mutua.
La toma de cargos mutua es una configuración que soluciona la

desventaja del apartado anterior. Mientras el nodo principal se ocupa de proveer
de servicio, el nodo de backup hace las mismas operaciones que en apartado
anterior y además puede efectuar otro tipo de operaciones. De este modo, la
capacidad de este nodo se está aprovechando más que en el anterior y el costo
del sistema se ve recompensado con un equipo más que se utiliza para efectuar
trabajo útil. El problema está cuando el nodo maestro cae. En este caso, el
comportamiento del backup puede tomar dos vías.
o la primera es mantener sus actuales trabajos y tomar los trabajos que el

maestro ha dejado sin hacer. Esta manera de comportarse presenta una
bajada de rendimiento del sistema crítico, pero hace que este esté
disponible. Depende del tipo de trabajo que se presente sobre el backup
que ahora ha pasado a ser maestro el considerar la prioridad de que
trabajos son más críticos.
o la segunda opción es dejar estos trabajos postergados hasta que el
antiguo maestro sea reparado (lo cual puede ser hecho por el nodo de
backup, es decir el nuevo maestro) y cuando éste tome las tareas de
backup, que continúe con el trabajo que en un principio estaba
efectuando él antes de tomar el control.
Esta es una solución mucho más elegante y más difícil de implementar.

Presenta mejor rendimiento coste que la anterior.
3. Tolerante a fallos.
Los sistemas redundantes a fallos se basan en la N-Redundancia. Si se

tienen N equipos y caen N-1 el sistema sigue en funcionamiento. Este sistema se
puede cruzar con la toma de cargos mutua para no perder rendimiento ni elevar
el costo del sistema, sin embargo configurar un sistema de este tipo es bastante
complejo a medida que aumenta N.
Técnicas basadas en reparación
Por otro lado están las técnicas basadas en reducir el tiempo de reparación. Este
tipo de técnicas se componen a base de scripts o programas que detectan donde fallo el
sistema y tratan de recuperarlo sin necesidad de un técnico especializado. En general
son técnicas de automatización de tareas basadas en sistemas expertos.
Al reducir el tiempo de recuperación, el sistema puede no solamente funcionar

activamente sin fallos más tiempo, sino que también se aumenta la confiabilidad. Se
pueden separar en dos tipos de acciones que realizan que pueden ser independientes o
dependientes entre si:
32
• Diagnóstico.
La parte de diagnosis simplemente trata de conocer las posibles causas que han
provocado el error y principalmente localizar el error.
Una técnica muy utilizada en este campo es una especie de piggybacking

aplicada a los pulsos o latidos entre ambos nodos. En esta técnica, se envía junto
con el latido o pulso, la suficiente información como para prever cual será el
estado de los componentes en próximos tiempos o incluso actualmente, lo cual
es una ventaja a la hora de saber en todo momento el estado del sistema. La
implementación Heartbeat de Linux-HA hace una implementación muy
coherente y correcta de esta técnica.
• Reparación.
Son técnicas mediante las cuales a través de sistemas expertos o

cualquier otro tipo de actuación, el sistema caído puede llegar a ser restaurado
desde una copia del sistema. En la mayoría de los casos basa su funcionamiento
en puntos de comprobación o checkpoints que se efectúan sobre el sistema cada
cierto tiempo, de manera que el servidor caído es restaurado al último
checkpoint existente. Los puntos críticos de este apartado son:
o aislar los componentes que fallan y sustituirlos o repararlos. Los

componentes que fallan pueden ser localizados mediante programas que
implementen sistemas de comprobación o sistemas expertos.
o recuperación mediante puntos de comprobación o puntos de restauración.
o acoplamiento al cluster actual tomando las acciones que tenía el nodo
backup e informando al nodo maestro de que ya existe un nuevo backup
en el sistema.
Los puntos de comprobación son importantes ya que introducen un factor

de sobrecarga en el sistema y al mismo tiempo son un factor crítico a la hora de
efectuar restauraciones del mismo. Un sistema al máximo confiable debería
guardar el estado de todos los programas que está corriendo y comunicárselos a
su backup en tiempo real para que de este modo la caída de uno guardase el
estado del complementario. Serían sistemas simétricos.
Este tipo de sistemas solamente son implementados en hardware, ya que

exigen medios de comunicación muy rápidos (aparte de la sobrecarga al
procesador que genera estar controlando este tipo de labores). Los clusters
implementan a un nivel mucho menos eficiente este tipo de checkpoints, y la
eficiencia depende generalmente de la capacidad de los procesadores y de la
capacidad de la red que une maestro y backups. Debido a esto los clusters
solamente guardan configuraciones y servicios activos, pero no el estado de
conexiones y demás componentes que harían que un usuario externo observase
la caída del sistema de modo realmente transparente, como si este no existiese.
Esta es una de las grandes diferencias entre entornos de alta

disponibilidad y entornos de alta confiabilidad, de los cuales no se ha visto
ninguno implementado debido a que la tecnología actual los hace inviables.
33
Existen varias maneras de efectuar el punto de comprobación. Por
ejemplo en los sistemas implementados a nivel de kernel o sistema, el sistema
operativo se encarga de efectuar este de manera completamente transparente al
usuario o administrador. En los sistemas a nivel de aplicación son generalmente
las bibliotecas de funciones las que proveen de estas características.
Otro factor a tener en cuenta acerca de los checkpoints, que marca el

rendimiento del sistema, es su intervalo. Éste debe ser óptimo: no crear
congestión y permitir copias de restauración lo suficientemente actuales como
para que los servicios cuenten con la máxima disponibilidad. En ocasiones,
cuando el checkpoint es muy grande puede provocar congestiones. En cualquier
caso, el principal problema de un checkpoint es la información que necesita para
hacer la colaboración eficiente, y esto como hemos visto depende siempre del
tipo de sistemas.
Como última característica de los checkpoints, hacer una pequeña

mención en los sistemas con más de un nodo de redundancia, en los cuales se
pueden imaginar dos modos lógicos de hacer los checkpoints:
Como checkpoints aislados, donde cada nodo se encarga de hacer los

checkpoints de otro nodo al que replica cada intervalo de tiempo o por una
política propia del sistema (puede caer en el denominado efecto domino, en el
cual se guardan copias de sistema que no corresponden con el estado actual de
los nodos).
Frente a los checkpoints en grupo o checkpoints organizados, en los

cuales todos los nodos se ponen de acuerdo para hacer un sistema de checkpoints
efectivo. A cambio requiere más dificultad de implementación, y quizá
sobrecarga del sistema.
2.1.3.3 Soluciones libres
Linux-HA
Este es el mayor proyecto de software libre de clusters HA que existe, parte de

este proyecto es Heartbeat y trabajan conjuntamente con el grupo encargado de LVS.
Han desarrollado varias aplicaciones comerciales sobre este proyecto y se está

utilizando en varios servicios con éxito. Como parte de los objetivos que se persiguen se
encuentran:
• Servicios de membership.
Estos servicios permiten añadir y quitar miembros a un cluster. El

problema es que la llegada de un miembro a un cluster orientado a estados puede
hacer cambiar de estado a todo el cluster (esto suele ser lo que ocurre en este
tipo de clusters) con lo que se envían demasiados paquetes de sobrecarga
demasiado a menudo por tanto ante esto se plantean soluciones como clusteres
jerárquicos. Es la solución que dentro de Linux-HA ha sido apoyada por Stephen
Tweedie.
34
• Servicios de comunicación.
Comunicar información crítica de forma que una caída en un sistema no

haga que se pierda la información y a la vez enviar la información de una forma
suficientemente segura para evitar posibles ataques externos. Como se ha visto
esto es especialmente importante en clusters HA.
• Manejo del cluster.
Una serie de servicios que hagan sencillo el manejo del cluster en general
y de los nodos y procesos en particular. Al igual que un sistema operativo
provee de servicios para administrarlo, un cluster también debe proveer de
instrucciones para gestionar su funcionamiento.
• Monitorización de los recursos.
Este punto está muy unido al anterior. Para que el administrador detecte
prematuramente posibles fallos y pueda ver qué ocurre en el cluster necesita
algunas facilidades de monitorización. Por supuesto estos dos puntos no son
exclusivos de los clustersHA ni del proyecto Linux-HA sino que son necesarios
en todos los clusters.
• Replicación y/o compartición de datos.
Para conseguir que los datos que estuviera modificando uno de los nodos
no se pierda cuando caiga se puede replicar la información y/o mantenerla en
lugares compartidos por todos los nodos con lo que cualquier nodo podría
continuar con los datos compartidos.
Para conseguir tener unos discos compartidos se necesita un hardware

caro como es SCSI y fibra óptica.
La replicación de información no necesita un hardware caro (solamente

una red tan rápida como el coste permita) pero se necesita mantener un
equilibrio entre los periodos de actualización de las copias y el uso de la red. Un
cluster HA no suele necesitar demasiado ancho de banda por lo que se puede
dedicar gran parte para este uso.
HeartBeat
Esta tecnología implementa heartbeats, cuya traducción directa sería latidos de

corazón. Funciona enviando periódicamente un paquete que si no llegara indicaría que
un servidor no está disponible, por lo tanto se sabe que el servidor ha caído y se toman
las medidas necesarias.
Dichos latidos se pueden enviar por una línea serie, por UDP o por PPP/UDP.
De hecho los desarrolladores de Heartbeat recomiendan el uso de puertos serie por
varias razones, entre las que destacan que están aislados de las tarjetas de red.
35
También incluye toma de una dirección IP y una modelo de recursos incluyendo
grupos de recursos. Soporta múltiples direcciones IP y un modelo servidor
primario/secundario. Por ahora ya se ha probado útil para varias aplicaciones
incluyendo servidores DNS, servidores proxy de cache, servidores web y servidores
directores de LVS. El proyecto LVS recomienda HeartBeat para aumentar la
disponibilidad de su solución, pero no es parte de LVS.
En Linux-HA Heartbeat es un servicio de bajo nivel. Cuando un ordenador se

une al cluster se considera que el ordenador se ha unido al canal de comunicaciones (por
lo tanto late) y cuando sale que ha dejado el canal de comunicaciones.
Cuando un ordenador deja de latir y se considera muerto se hace una transición

en el cluster. La mayoría de los mensajes de manejo del cluster que no son heartbeats se
realizan durante estas transiciones.
Los mensajes de Heartbeat se envían por todas las líneas de comunicación a la

vez, así si una línea de apoyo cae, se avisará de ese problema antes de que la línea
principal caiga y no haya una línea secundaria para continuar el servicio.
Heartbeat también se preocupa por la seguridad permitiendo firmar los paquetes

CRC de 32 bits, MD5 y SHA1. Esto puede evitar el desastre que podría provocarse si
un nodo no miembro se enmascarase como nodo miembro del cluster. Hay varias
operaciones de mantenimiento de seguridad que necesitan ser efectuadas en ese tiempo,
como pueden ser cambio de claves y de protocolos de autentificación. Heartbeat está
preparado para esos cambios disponiendo de ficheros para la configuración.
Heartbeat tiene el problema que si no se dispone de una línea dedicada, aunque

ésta sea una línea serie, al tener un tráfico que aunque pequeño es constante, suele dar
muchas colisiones con otros tráficos que puedan ir por la misma red. Por ejemplo
openMosix y Heartbeat en una misma red que no tenga gran ancho de banda no
funcionan bien, sobre todo si hay bastantes nodos, pues los heartbeats se envían de
cualquier nodo a cualquier nodo, por lo que podrían llegar a ser un tráfico voluminoso.
Ldirectord.
Pensado especialmente para ser usado junto con LVS, utiliza Heartbeat.
Monitoriza que los servidores reales sigan funcionando periódicamente enviando una
petición a una url conocida y comprobando que la respuesta contenga una cadena
concreta. Si un servidor real falla entonces el servidor es quitado del conjunto de
servidores reales y será reinsertado cuando vuelva a funcionar correctamente. Si todos
los servidores fallan se insertará un servidor de fallos, que será quitado una vez que los
servidores vuelvan a funcionar.
Típicamente este servidor de fallos es el propio host desde el que se realiza el

monitoraje.
36
LVS.
Sobre este proyecto se dedica la siguiente subsección, por tanto de momento

basta decir que éste es seguramente el proyecto más implantado y uno de los pilares
sobre los que se apoyan las soluciones comerciales.
2.1.4 LVS (Linux Virtual Server)

2.1.4.1 Introducción
LVS es un proyecto que incluye los programas y documentación necesaria parar

montar un cluster de servidores bajo GNU/Linux. El proyecto LVS es utilizado
principalmente para aumentar rendimiento y escalabilidad de servicios ofrecidos sobre
la red, es ampliamente utilizado por grandes sites como SouceForge.net o Linux.com.
La principal idea es proveer de un mecanismo de migración de sockets. El

mecanismo se basa en utilizar una máquina servidora a la que se dirigen las peticiones
de los usuarios clientes. El interfaz público (en Internet) de esta máquina normalmente
tiene asociada una dirección conocida como VIP. El cometido de esta primera
computadora es direccionar dichas peticiones a otros servidores reales mediante varias
técnicas, de este modo los usuarios clientes ven un único servidor. No obstante éste
opera con varias máquinas para conceder un servicio único al exterior.
A todo el conjunto de nodos que conforman el servicio y se comportan como si

fuese un único servidor se le denomina Servidor Virtual. El cluster está formado por dos
tipos de máquinas:
• por un lado están los nodos o servidores reales, que corren con los servicios
habituales que estos suelen proveer,
• por otro lado están los nodos directores, de los cuales uno de ellos será el
principal y el resto estarán preparados para hacer de refuerzo de éste (mediante
técnicas o protocolos como heartbeat) para cuando caiga. Estas técnicas no son
propias de LVS, como ya puede saberse a partir de las secciones anteriores.
En general se puede considerar LVS como una suma de herramientas que

permiten efectuar la función ya especificada. Para conseguirlo se requiere:
• el código de ipvs, un parche al kernel para el nodo director

• el programa ipvsadm, encargado de configurar las tablas internas y algoritmos
del kernel del nodo director
Ambos constituyen el código principal del proyecto LVS, pero se requieren otras
muchas herramientas como ipchains, iptables o Netfilter (dependiendo de la versión del
núcleo utilizada), Ldirectord, Heartbeat, Piranha, MON, LVS-gui, etc.
El Servidor Virtual requiere de la configuración de todos estos servicios y

herramientas para un funcionamiento adecuado, y no solamente del código de LVS. Es
más, dentro del tipo de programas que conforman el Servidor Virtual no hay que olvidar
los programas o demonios servidores habituales que proveerán realmente de servicio a
los clientes finales (HTTPD, FTPD, SMTP, etc.).
37
El funcionamiento de LVS es una aproximación a resolver el problema de la
escalabilidad y el alto rendimiento muy elegante puesto que permite que cliente y
servidor trabajen de la manera transparente permitiendo que el balanceo se lleve a cabo
por el director. Comparado con métodos como el ofrecido por RR-DNS es mucho
menos intrusivo y más confiable en su servicio.
Existen otras técnicas para ofrecer mayor escalabilidad y rendimiento en

servicios de Internet. La alternativa RR-DNS es uno de los métodos más utilizados
actualmente ya que permite independencia en arquitectura o sistema utilizado en el
servidor Se basa en un algoritmo Round Robin en el servidor DNS, de manera que
cuando un cliente solicita la dirección IP de un servidor ésta le es concedida según el
algoritmo. Así por ejemplo si existen 4 máquinas servidoras que proporcionan el mismo
servicio, a la primera conexión entrante que solicite el servicio se le asignará la
dirección IP del primer servidor, a la segunda conexión la IP del segundo servidor y a la
quinta conexión la IP del primero otra vez.
Uno de los defectos que tiene este método es que si uno de los servidores cae los
clientes que asociaban el dominio a esa dirección IP lo seguirán haciendo, obteniendo
un fallo en sus peticiones.
El servicio RR-DNS puede ser utilizado complementariamente a LVS, es decir,

se utilizar RR-DNS para solicitar la IP de un Servidor Virtual LVS. Otra alternativa es
el uso de clientes no transparentes, clientes que utilicen algún algoritmo para decidir que
servidor utilizan en cada petición o sesión, lógicamente estos métodos son muy poco
utilizados. Esto puede conseguirse mediante applets Java, por ejemplo.
Otras alternativas más conocidas son los proxys inversos, esta alternativa supone
el mismo funcionamiento de un proxy, pero en el caso de los servidores. El proxy recibe
las peticiones y gestiona una nueva conexión con uno de los servidores reales mediante
algún tipo de algoritmo de balanceo, el servidor responde al proxy y este envía las
peticiones de nuevo al cliente. Esta alternativa es muy utilizada, aunque presente menos
índice de escalabilidad y más sobrecarga en los equipos que RR-DNS o LVS. El proxy
acaba por resultar un cuello de botella ya que éste abre 2 conexiones TCP por cada
conexión que se realiza al proxy, esta solución a nivel de aplicación se puede realizar
mediante programas como SWEB.
Por último, están las alternativas propietarias de empresas como CISCO, IBM,
COMPAQ y demás empresas que tienen bastante código tanto a nivel de aplicación,
kernel y hardware específico para este tipo de tareas.
A pesar de que el director LVS se comporta como un conmutador (switch) de

nivel 4 no actúa como un proxy inverso. El modo de actuar es bien distinto. El nodo
director utiliza un kernel especial parcheado que permite el balanceo de carga de los
servicios mediante varios métodos de planificación, además es configurable mediante
un programa en zona de usuario que permite pasarle los parámetros al kernel acerca de
como debe balancear conexiones. El director se comporta como un conmutador de nivel
4 en la arquitectura OSI, balancea conexiones o datagramas según se le haya exigido en
su algoritmo de balanceo.
38
El efecto de solicitar una petición sobre el Servidor Virtual LVS es el siguiente:
1. el cliente solicita un servicio o conexión a la dirección del Servidor Virtual LVS

(llamada VIP) que posee la interfaz pública del nodo director
2. el nodo director se encarga de balancear la conexión según el algoritmo
programado, hacia el servidor real dentro de la batería de servidores
3. el servidor contesta al cliente con su respuesta y la envía hacia él.
De esta manera se puede ver que tanto cliente como servidor real trabajan de
manera transparente en lo que se refiere al nodo director.
La diferencia con un Reverse Proxy estriba en que LVS no requiere de la vuelta

de las peticiones al director, ya que éstas pueden ser enviadas directamente al cliente, lo
que evita que el director se convierta en un cuello de botella en el sistema, como ocurre
en el caso de los proxys inversos.
LVS puede solucionar muy satisfactoriamente casos de adaptabilidad a

requerimientos o escalabilidad, redundancia, alta fiabilidad y mayor crecimiento de los
servicios ofrecidos. Por todo esto se puede considerar dentro de los clusters de Alta
Fiabilidad (HA).
Realmente LVS no es un cluster propiamente dicho. Un cluster se suele entender

en base a una serie de máquinas que actúan de manera conjunta mediante relaciones
entre ellas para resolver un problema (generalmente de cómputo). LVS no es un cluster
en este sentido puesto que cada servidor es independiente y solamente está relacionado
con los otros mediante un sistema de almacenamiento común, los servidores solamente
se relacionan con el nodo director para proveer de un servicio.
En cualquier caso y generalizando el concepto de cluster, LVS utiliza varias

máquinas para aumentar el rendimiento y la fiabilidad de un servicio, es decir un
problema, y como tal se puede considerar como un cluster. La idea de migrar sockets no
tiene una solución general inmediata, MOSIX la solucionaba prohibiendo a los procesos
servidores de cada máquina que migrasen a otros nodos, impidiendo un balanceo
perfecto del sistema. El que un proceso que tiene un socket migre conlleva un problema
de difícil resolución. LVS proporciona un sistema bastante adaptable para migrar
sockets, por lo que es un sistema ideal y complementario a otros.
El nodo director se comporta como un router al que se le han añadido en el

kernel tablas de encaminamiento para reenviar paquetes a los servidores reales para los
servicios que se hayan configurado en el cluster LVS.
Existen tres maneras de efectuar el reenvío o encaminamiento en LVS: VS-NAT,

VS-DR, VS-TUN.
• VS-NAT hace uso de NAT dinámico para efectuar transacciones entre servidor
real y cliente.
39
• VS-DR o VS-Direct routing hace uso de direcciones virtuales mediante alias en
dispositivos Ethernet para reenviar a la dirección Virtual del director (VIP) a
cada servidor real.
• VS-TUN hace uso de ip-tunneling para reenviar los paquetes a los servidores
reales, esto implica que el sistema operativo deba poder manejar la
desencapsulación de estos paquetes especiales.
2.1.4.2 Métodos de balanceo IP
En esta sección se describirán las técnicas descritas anteriormente con las que
LVS balancea los paquetes TCP/IP o UDP/IP hacia los servidores reales. Estas tres
técnicas son bien distintas y permiten configurar LVS de una manera específica para
cada solución que se quiera implementar. La elección de una u otra técnica depende
principalmente del servicio que se quiera proveer, los conocimientos que se posean de
los sistemas, el sistema operativo de los servidores, los recursos económicos que se
estén dispuestos a gastar y consideraciones sobre el rendimiento.
VS-NAT
Es el caso más sencillo de configurar de todos y el que menor rendimiento tiene

respecto a los otros dos.
VS-NAT hace uso de NAT para modificar direcciones, existen tanto la

implementación para las versiones de kernel 2.2 como para las 2.4. Ambas
implementaciones dan soporte SMP para LVS en el nodo director (que es el que tiene el
kernel modificado), lo que permite una tasa de manejo de paquetes muy alta para
clusters que proveen de mucho servicio.
VS-NAT se compone de un director que corre el kernel parcheado con LVS

(ipvs) y de una batería de servidores que pueden correr con cualquier sistema operativo
y cualquier tipo de servicio. El nodo director se encarga de recibir las peticiones de los
clientes por su VIP mediante el algoritmo de balanceo elegido se reenvían los paquetes
a el servidor real de manera que el servidor responde a la petición y los encamina al
nodo director, el cual cambia las direcciones de la cabecera de los paquetes IP del
servidor, para que el cliente los acepte sin problemas. Como se puede ver, el mecanismo
es muy parecido por no decir igual que el de un Proxy inverso, excepto por que el
redireccionamiento se hace a nivel de kernel.
Primero el director reenvía sus paquetes mediante el código ipvs, modificando

los paquetes que se recibieron del cliente mediante el cambio de la dirección destino
hacia los servidores reales y luego vuelve a hacer el cambio inverso mediante NAT
dinámico a los paquetes que envían los servidores.
VS-NAT tiene el mismo problema que los proxys inversos: el nodo director
llega a ser un cuello de botella en cuanto las exigencias por parte de los clientes se
hacen muy altas, o el número de servidores internos a la red crece por encima de los 20.
Es por esto que este tipo de configuración es la menos utilizada de las tres.
VS-TUN
40
Este método es más utilizado que el anterior, se basa en redirigir los paquetes IP
del nodo director al destino mediante técnicas de IP-tunneling, esto requiere que tanto el
nodo director (que debe correr bajo Linux y por tanto puede ser compilado con IP-
tunneling) como el servidor real puedan encapsular y desencapsular paquetes especiales.
Para esto es necesario que la pila IP del sistema operativo lo soporte, y no todos los
sistemas operativos lo soportan, en general la mayoría de Unix que existen en el
mercado si lo soportan, por lo que en un principio no debe ser un grave inconveniente
para la elección de este método como base de LVS.
El funcionamiento mediante este método de balanceo es el siguiente:
• el cliente hace la petición a la VIP del director

• el director elige mediante el algoritmo de balanceo cual será el servidor real que
atienda la petición
• el servidor encapsula el paquete (que le llegó por la interfaz asignada a la VIP)
en otro paquete IP con destino el servidor real
El servidor real atiende la petición de servicio y la responde, poniendo como

dirección de los paquetes IP generados por este la dirección propia por la que llegó el
servicio, es decir la VIP. Los envía directamente al cliente, sin tener que pasar los
paquetes por el nodo director de nuevo. De esta manera se evita el problema de cuello
de botella en el director.
Este mecanismo de redirección permite que los servidores reales puedan

encontrar se no en una red local, como sucede en el caso de los dos anteriores, sino
dispersos en otras redes a las cuales se pueda acceder desde el director, esto supone el
poder distribuir los servicios no solo como método de incrementar el rendimiento, sino
como distribución geográfica de los servidores, lo cual puede ser una ventaja para
ciertos sistemas, o una desventaja para otros.
La desventaja de esta técnica está en que tanto el director como el servidor

tienen que poder crear interfaces de tipo tunneling, y como consecuencia de hacer IP-
tunneling siempre estará implícito un tiempo de procesador ocupado en encapsular o
desencapsular los paquetes, que si bien en algunos sistemas puede ser insignificantes, en
otros puede ser decisivo para la elección de otro método de balanceo.
VS-DR
VS-DR se basa en una tecnología de red local (en un único segmento) y en un

cambio de direcciones IP-MAC para proporcionar el método de reenvío de los paquetes.
Al igual que VS-TUN no requiere reenviar los paquetes al nodo director, por lo
que no presenta en él un cuello de botella. Es quizá el más utilizado de los tres, por ser
el que mayor rendimiento obtiene, pero al igual que el resto, presenta una serie de
desventajas en su uso y configuración.
El funcionamiento de VS-DR es similar al de VS-TUN en el sentido de que

ambos utilizan la dirección VIP no solamente en el nodo director (donde esta la
dirección VIP real a la que acceden los clientes) sino también en los nodos servidores.
En este caso, los servidores poseen dos direcciones asociadas al nodo, una es la IP real
41
asociada a la tarjeta Ethernet, la otra es una dirección loopback especial configurada con
la dirección VIP, es conveniente dejar la interfaz loopback que tiene la dirección
127.0.0.1 sin modificar, por lo cual se debe hacer un alias de esta interfaz pero con la
dirección conocida como VIP.
De este modo los clientes hacen la petición a la VIP del director, éste ejecuta el
algoritmo de elección del servidor, solicitando mediante ARP la dirección del servidor
al que pretende enviar para conocer la dirección MAC asociada a esta IP. Una vez que
la conoce envía un los paquetes del cliente, sin ser modificados, en una trama Ethernet
con destino la dirección del servidor real. Éste recibe la petición y comprueba que
pertenezca a alguna de las direcciones que él posee, como hemos configurado la VIP en
un interfaz loopback, la petición se efectuará sin problemas.
Este método requiere en ciertas ocasiones que el servidor acepte las peticiones
asociadas al interfaz declarado como lo0:1, es decir el de loopback, en el caso de ser una
máquina Linux.
Esto implica generalmente que el servidor pueda ser configurado para ello, por
ejemplo en el caso de apache (uno de los servidores más utilizados de HTTP), en el
fichero de configuración /etc/httpd.conf se debe especificar en una linea como
Listen dir_VIP : PORT_VIP
para que el servidor acepte las peticiones provenientes de esta interfaz. Esto puede
resultar un inconveniente en ciertos servidores.
A pesar de ser el más utilizado por ser el que más alto rendimiento ofrece, está
limitado en cuestión de escalabilidad debido a que la red sobre la que funciona está
limitada a un único segmento ethernet por motivos de direccionamiento mediante ARP.
Por otro lado no se necesita tiempo de encapsulación o desencapsulación de ningún tipo
y tampoco ningún factor de redirección hacia el nodo servidor. El encaminamiento de
los servidores reales al cliente se puede hacer mediante otra conexión a red de alta
velocidad de manera que el ancho de banda este garantizado.
Características generales de las técnicas de balanceo
Una vez vistos los tres mecanismos principales de las técnicas de balanceo se
darán algunas consideraciones de carácter general acerca de las mismas.
Casi todas las implementaciones de LVS se suelen hacer con el cluster de

servidores colocado en una red de área local, excepto las del tipo VS-TUN. Si
disponemos de una conexión con el cliente de alto ancho de banda estaremos utilizando,
en el peor de los casos, VS-NAT, y habrá más de 20 servidores reales en la red privada
de 10 Mbps. Probablemente la red acabe congestionada con mucha asiduidad,
provocando respuestas mucho peores de las que podría dar un servidor único, más caro.
Por otro lado está el factor de carga de los equipos. Cada servicio proporcionado
por el servidor virtual puede tener como servidores reales destino un subconjunto de la
batería de servidores. Esto implica que cada nodo debe ser convenientemente
42
administrado y elegido con recursos y características correctas antes de la puesta en
funcionamiento del LVS.
En el caso del nodo director sucede lo mismo, éste debe ser conveniente elegido
para su cometido, el parche LVS no inhabilita el funcionamiento SMP del kernel de
Linux por lo que puede ser elegida una máquina de este tipo para hacer las funciones de
nodo director. El funcionamiento de LVS se basa principalmente en engañar al cliente
acerca de quién le está sirviendo. Así el cliente aceptará todos los paquetes que le
vengan con la dirección VIP y determinados números de secuencia y asentimiento (en el
caso de los TCP) con lo que solamente hay que elegir entre los diferentes mecanismos
para poder llevar a cabo este cambio de direcciones: NAT, tunneling o mediante
encaminamiento directo.
Otra de las desventajas que conlleva la instalación de un sistema LVS es la

formación y el conocimiento con el que deben contar los diseñadores de la red y de cada
sistema que intervienen en un sistema LVS. Al estar formado el sistema por un grupo
heterogéneo de elementos, en la mayoría de los casos con una relación de dependencia
bastante fuerte, es necesario conocer extensivamente cada uno de los sistemas
individuales, para que ninguno de ellos falle o baje su rendimiento. Por ejemplo es
necesario saber el como hacer masquerading en el nodo director, como evitar ICMP
Redirects en el director, como evitar los problemas ARP (se verá más tarde), como
hacer auditorías a la red y gestionarla para ver donde tiene el sistema sus cuellos de
botella y un largo etcetera de problemas potenciales que hacen que la puesta en marcha
de uno de estos sistemas en entornos de producción sea más difícil de lo que en un
principio pueda parecer.
2.1.4.3 Aspectos Técnicos
La instalación de LVS requiere el conocimiento de cada uno de los elementos

que requieren para su funcionamiento correcto (que no son pocos). La instalación o
puesta en marcha se puede separar en:
• Diseño de la red. Direcciones, topología, servicios y arquitectura del sistema

global.
• Preparación y configuración de los nodos directores, puesto que puede haber
más de un nodo director haciendo backup.
• Preparación y configuración de los nodos que actuarán como servidores reales.
• Configuración de los elementos de encaminamiento (enrutadores) y seguridad
(firewalls).
• Configuración de la parte que proveerá al sistema de alta fiabilidad y
redundancia.
• Configuración de un sistema de almacenamiento compartido.
Se podrían añadir otros tantos puntos para cada sistema específico. Pero para un
sistema general en producción, los imprescindibles son los ya enunciados.
Apartado de Red
El diseño y elección de la topología de red es bastante crítica en la implantación

del sistema ya que puede convertirse en uno de los cuellos de botella.
43
Generalmente los nodos servidores se encuentran en una red privada Ethernet a
la que pertenecen tanto la batería de servidores como los nodos que actúen como
director en el sistema. Hay que tener en cuenta que por esta red pasaran:
• las peticiones y respuestas de los clientes en el peor de los casos (VS-NAT),

• los paquetes de monitorización,
• paquetes de sistema de manejo y gestión del cluster, etc...
Es decir, una carga alta dependiendo del sistema elegido.
Lo ideal sería utilizar tecnologías rápidas pero baratas como FastEthernet (100
Mbps) y separar en tantas redes como sea necesario para tener los mínimos cuellos de
botella posibles y la máxima escalabilidad (en vista al futuro).
Esto probablemente implica separar por un lado la red por la que se efectúan
todos los intercambios de petición entre el nodo director y los servidores reales, una red
específica para el sistema de almacenamiento elegido y excepto en el caso de VS-NAT
una red (o varias dependiendo del ancho de banda requerido para proveer servicio) para
la salida de las respuestas de los servidores reales. Aun quedarían los paquetes de
monitorización o redes destinadas a openMosix o similares.
Por último se podría utilizar una red más barata entre el nodo director y su nodo
de backup, en el caso de utilizar Heartbeat.
Esta trama de redes no es necesaria en todos los sistemas, bastaría medir la

congestión en la red para poder ver que servicios se deben separar de los otros para
evitar las congestiones en cualquiera de los casos.
En lo referente al direccionamiento, generalmente solamente el nodo director

debe tener una dirección pública, mientras que el resto de los nodos servidores suelen
tener direcciones privadas reservadas. El mecanismo de direccionamiento utilizado en
Ethernet provoca un problema que se tratará más tarde. En el caso de los servicios
proporcionados. En la mayoría de los casos no interviene ningún factor externo en la
configuración salvo casos como el explicado en el apartado anterior en el que se
configura un servicio para un determinado interfaz de la máquina servidora. El único
problema que plantean los servicios en un cluster del tipo LVS es el problema de la
persistencia.
Se entiende por conexiones persistentes dos tipos de conexiones:
• una es del tipo de los servidores HTTP, en los cuales intervienen los tiempos de
establecimiento de conexión activa, el tiempo de transferencia real y el tiempo
de aproximadamente 15 segundos (aunque es muy variable) hasta que se cierra
la conexión con el cliente.
El manejo de esta persistencia es realmente sencillo.
• otro tipo de persistencia es la debida a dependencias entre varios sockets, como

es el caso de servicios como FTP o el paso de HTTP a HTTPS en una
transacción o compra vía Internet. Dichas conexiones son más difíciles de
44
analizar, ya que dependiendo del servicio se establecerán factores de
dependencia entre unos puertos u otros.
LVS resuelve el problema de la persistencia de manera explícita, es decir, de la manera

que el administrador le obligue a hacerlo.
En cualquier caso la configuración, diseño y elección de red dependen de los

servicios, situación geográfica, coste y topología. También dependen de la seguridad del
sistema. LVS tiene un apartado especial para poder hacer balanceo sobre firewalls, de
manera que los firewalls que ejecutan las mismas reglas pueden actuar en paralelo,
utilizando de este modo máquinas más baratas para dicha tarea. A parte de este servicio,
en un entorno de producción será necesario aislar la red completamente del exterior
mediante las reglas adecuadas en los firewalls. La utilización de los nodos diskless,
proporciona como se verá más tarde, un mecanismo más sólido para la construcción de
nodos.
Por último se deben considerar todos aquellos factores relativos a la seguridad

en redes que se puedan aplicar en servidores normales, de los que se encuentra amplia
bibliografía.
Consideración respecto al tipo de encaminamiento elegido.
En lo que se refiere al rendimiento de cada tipo de encaminamiento es obvio que

hay que separarlo en dos, por un lado VS-NAT y por otro VS-TUN y VS-DR.
VS-NAT se basa en el NAT tradicional, esto implica que cada paquete ya sea de
conexión o de cualquier otro tipo que entra por parte del router o cliente es evaluado de
la forma antes descrita y reenviado al servidor real. La cabecera IP es modificada con
los valores fuente del nodo director, el servidor procesa la petición y da su respuesta al
nodo director, que otra vez hace NAT al paquete colocando como destino el nodo
cliente, y se vuelve a enviar al router por defecto del director.
Este mecanismo exige no solamente el balanceo de las conexiones por parte del
kernel, sino un continuo cambio de direcciones a nivel IP de todos los paquetes que
pasan por el director, así como la evaluación de los mismos, lo que hace que el
rendimiento de este método se vea limitado a la capacidad de proceso que posea el nodo
director. Por tanto es muy fácil dimensionar mal las capacidades del director o de la red
y hacer que la salida a través del director se convierta en un cuello de botella. En el caso
de el VS-NAT existe una opción en el kernel para optimizar el reenvió de paquetes para
que este sea más rápido, que consiste en no comprobar ni checksums ni nada, solamente
reenviar.
En el caso de VS-DR o VS-TUN el rendimiento no cae tanto sobre el director.

No obstante éste sigue siendo un punto crítico, pero las soluciones actuales en lo que se
refiere a capacidad de proceso nos sobran para gestionar cantidades considerables. El
mayor problema de estos dos tipos es el diseño de la red interior, para que esta no se
congestione y por supuesto el problema ARP enunciado en el apartado anterior.
En ambos métodos, las respuestas de los servidores reales se envían

directamente a los clientes a través de un enrutador que puede ser (o no) diferente del
45
que envío la petición inicial al director. En el caso de VS-DR se exige, por el modo del
algoritmo que todos los servidores reales pertenezcan al mismo tramo de una LAN, esta
es la forma más común en entornos de producción de configurar LVS, ya que permite el
mejor rendimiento y menos carga de la red de los tres.
El problema ARP
Otra consideración que afecta no solamente a la red sino a la configuración del

sistema en general es el problema ARP. Como se ha visto hasta ahora la técnica de
balanceo más utilizada es VS-DR, esta técnica ya ha estado descrita.
Para configurar LVS se puede hacer mediante tunneling o mediante DR, en

cualquier caso habrá que añadir direcciones virtuales extras a la configuración de los
servidores reales, asícomo a la del nodo director. Para esto se deberán compilar los
núcleos de las máquinas con las opciones de ip aliasing en el apartado Networking.
Cuando un cliente quiere realizar una conexión con el director lanza un paquete
ARP (o en su defecto lo manda el router, en cualquier caso el problema es el mismo)
para saber cual es la dirección MAC del director. Éste hace el reenvió dependiendo del
algoritmo de planificación y al mismo tiempo guarda en su tabla el estado de la
conexión que se ha realizado.
El servidor contesta y se reenvía la respuesta hacia el cliente. Pero ¿qué sucede

si en lugar de contestar la máquina que hace las veces de director contesta una de las
que esta haciendo de servidor? En este caso al lanzar el paquete ARP pidiendo Who has
VIP tell cliente/router? en lugar de contestar el director contesta una de las máquinas
que hace de servidor real. De esta manera la conexión se establece pasando por encima
del LVS en una especie de bypass, sin tener en cuenta al nodo director, que no guarda
los estados ni la conexión.
De hecho hasta aquí no se produce ningún error con respecto a el servicio

realizado, ya que el servidor procede a la entrega de la respuesta, el problema esta en el
caso de que la tabla ARP del router o cliente se borre y vuelva a pedir ARP Who has
VIP tell cliente/router concediéndose la MAC de otro servidor o incluso del nodo
director, que no tiene ni idea de como lleva la conexión en ese momento ya que el no la
estaba sirviendo. Como se puede ver es un problema inherente a la manera en la que
hemos configurado nuestra solución que podría ser resuelto poniendo más de una tarjeta
de red al director u otras soluciones. En cualquier caso, la red se comporta normalmente
de manera aleatoria en la concesión de la MAC.
En cualquier caso la solución a este problema esta en conseguir que el director

conteste a los paquetes ARP Who has VIP tell cliente/router, que son solicitados por el
router o cliente.
Existen varias soluciones, desde parches para el kernel hasta un ifconfig -arp,
pasando por meter una tarjeta de red más en el director o incluso modificando la tabla
ARP del router para que no solicite ARP dinámicamente sino lo especificado.
46
Por ejemplo en /etc/ethers o directamente cambiando la tabla ARP de manera
que todos los paquetes IP del router para la dirección VIP queden asociados al director.
Cualquier solución es válida.
Al mismo tiempo exige un conocimiento bastante profundo del problema para

los diseñadores de la red, ya que cada solución aportar unas ventajas y alguna
desventaja. Generalmente se suelen utilizar dos opciones: añadir nueva tarjeta al
director o adaptar el kernel de los clientes para que ellos no respondan a las peticiones
ARP de alguna de sus interfaces, accediendo a /proc/sys/net/ipv4/lo/hidden o similar
respecto al interfaz al que hemos asociado la VIP.
Hay que tener en cuenta que la especificación de -arp en el ifconfig se deshecha

en kernels superiores al 2.0.* y exige el otro tipo de soluciones. Otra solución que se
propone es modificar la tabla ARP que se encuentra en el cliente o router que hace el
Who has VIP tell router, pero esto crea alguna complicación a la hora de tener que
controlar la caída del nodo director de backup en el caso de que exista (caso muy
probable) y la toma de sus funciones, ya que la MAC del nodo director actual cambia y
por tanto debe cambiar la tabla MAC-IP configurada en el router.
Configuración y elementos que componen el nodo o nodos directores
El nodo director es uno de los puntos más críticos del sistema, por eso debe ser
bien elegido y configurado para las tareas que debe hacer. Suele tener algún mecanismo
de alta fiabilidad con un servidor replica que toma las funciones del nodo director
cuando este cae de manera casi transparente al sistema. La puesta a punto del nodo
director (dejando a un lado el nodo réplica) esta formada por la configuración de varias
de las herramientas de las que explicamos antes.
Lo primero es encontrar el código de lvs, este código se puede encontrar en la

pagina oficial LinuxVirtualServer.
El paquete a descargar depende del kernel que se utilice, de esta manera se

pueden elegir dos tipos de kernel donde instalarlo: la serie antigua (2.2) y la nueva (2.4).
La manera de configurarlos es distinta.
El paquete LVS contiene más programas necesarios para la instalación de LVS y

algunas herramientas de ayuda como el script configure del que hablaremos más tarde.
El kernel del director debe ser parcheado, con el código de LVS una vez puesto el
parche al kernel y compilado, se ejecuta y se configura mediante un programa en zona
de usuario llamado ipvsadm que permite especificar el comportamiento del director.
Antes de seguir avanzando con la instalación del kernel es necesario conocer, al

menos por encima, el funcionamiento del núcleo que vamos a utilizar. Ver figura.
El núcleo del nodo director será el que se encargue de establecer, mediante un

algoritmo de balanceo, quien será el servidor real de cierta conexión. Este algoritmo se
encuentra como código del núcleo y es elegido antes de compilar el kernel ya sea como
modulo o como código interno al kernel.
47
El director hace lo siguiente:
• las conexiones que se reciben del cliente (al interfaz que tiene la dirección
virtual) son insertadas en el núcleo de decisiones de LVS,
• este núcleo se encarga de hacer la planificación mediante un mecanismo
programado (algoritmo de balanceo)
• luego se insertan dichas conexiones en una tabla hash o tabla de dispersión.
Todos los paquetes pertenecientes a conexiones realizadas son comprobados en

su tabla hash para ver qué servidor real estaba gestionando la transacción y poder enviar
los paquetes a dicho servidor. Cada entrada en la tabla hash ocupa 128 bytes y el
número máximo de conexiones que el director puede realizar se puede configurar antes
de la compilación del kernel, lo cual implica un estudio previo de las conexiones que se
estima que se podría realizar al director para poder adecuar este a las necesidades del
sistema, proveerlo de suficiente memoria para que no haya problemas con el número de
conexiones.
Mediante la elección de las técnicas de balanceo ya vistas el núcleo se encarga

de formar los paquetes IP que se enviarán a los nodos servidores.
En la zona de usuario se ejecuta el programa ipvsadm. Este programa viene

dentro del paquete ipvs, debe ser compilado para cada versión específica del parche de
kernel ipvs. El programa se encarga mediante la función setsockopt() de configurar el
modo de funcionamiento del sistema, y mediante el sistema de ficheros /proc se encarga
de leer las configuraciones que este tiene en cada momento.
Existen seis algoritmos para la elección del funcionamiento del nodo director. El
algoritmo se selecciona en el kernel antes de la compilación, en el campo IPVS dentro
de Networking options. Se pueden compilar como módulos o internos al kernel, se
deben compilar todos los algoritmos que más tarde se utilizarán a la hora de encaminar
a los servidores reales mediante la configuración de ipvsadm.
Se pueden distinguir dos familias de algoritmos, la dinámica y la estática. Los

algoritmos a su vez se pueden separar en 3 tipos y sus derivados para pesos constantes.
• Round Robin y Round Robin con peso.

• Número de conexiones y número de conexiones con peso.
• Algoritmos basados en número de conexiones y localidad al nodo.
• Algoritmos relativos a cache-proxy (squid) y algoritmos relativos a fwmark
(firewalls).
Los dos últimos juegos de algoritmos no serán enunciados, pero sirven para
balancear carga entre squid y también para balancear entre varios firewalls. Para más
información ver la documentación del kernel parcheado o el HOWTO de LVS.
El algoritmo de Round Robin es el habitual en el mundo de la informática. Es un

algoritmo estático y su ampliación a Round Robin con peso solamente implica que a los
nodos más potentes se les asigna más cantidad de trabajo que a los menos potentes. En
cualquier caso, Round Robin no es un algoritmo óptimo para balancear la carga cuando
hay un elevado número de conexiones.
48
El algoritmo RR es semejante al utilizado en RR-DNS, pero en el caso de LVS
la granularidad es mucho menor ya que se balancea por conexión. Un ejemplo del
algoritmo de Round Robin con peso, podría ser el caso de tener 3 servidores:
Como se puede ver las conexiones son balanceadas de manera alterna siguiendo
un algoritmo sencillo de decremento del peso y nodo que lleva más tiempo sin ser
utilizado. Esta es una manera muy sencilla de balancear la carga pero generalmente
implicará que el balanceo no sea perfecto (en el caso de que el número de conexiones
sea muy alto).
El algoritmo por número de conexiones (o least connections) y wheigthed least-

connection responde a un algoritmo dinámico. Se basa en enviar las nuevas conexiones
al nodo que tenga menos conexiones abiertas, esto requiere saber en todo momento
cuantas conexiones abiertas tiene cada nodo, pero supone una ventaja en el
comportamiento del sistema cuando el número de conexiones es elevado.
El algoritmo, que es sensible a los pesos, actúa dependiendo de los pesos que
cada nodo tiene asignados en el director y se balancea según el número de conexiones
abiertas. Este grupo de algoritmos balancea mejor la carga en lineas generales pero
requiere un nodo director más potente para llevar el conteo del número de conexiones
de cada nodo.
El algoritmo contador de conexiones con peso sería el siguiente.
Existe una batería de servidores para un determinado servicio con N servidores, a

cada uno se le asigna un peso (i=1...N) y número de conexiones activas (i=1...N).
El número total de conexiones S no es más que la suma de las conexiones

activas de cada nodo. De este modo la siguiente conexión para el servicio sera para el
nodo j que cumpla:
(i= 1..N)
El único inconveniente es que el kernel no puede realizar esta operación, ya que

no dispone de los números en coma flotante de forma que esta expresión debe ser
cambiada a algo como de manera que la comparación pueda ser evaluada por el
kernel. Lo más importante a tener en cuenta es que las conexiones con las que se trabaja
son conexiones activas. Existen otros dos algoritmos más basados en el algoritmo least-
connection que mejoran este en algunas situaciones, estos dos algoritmos se basan en la
localidad de las conexiones, e intentan que el mismo cliente vaya, en caso de que el
balanceo de la carga lo permita, al mismo nodo servidor que fue en otras conexiones
realizadas por este cliente.
Una vez vistos los fundamentos teóricos para ver como debe compilarse el
kernel puede pasarse a la instalación y compilación del mismo. Respecto a este punto se
da por sentado que el administrador sabe aplicar parches al kernel y compilarlos de
manera correcta.
49
Para empezar hay que obtener las fuentes del parche del kernel, el programa
ipvsadm y el script configure.
Habrá que parchear el kernel (las versión de las fuentes del kernel deben
coincidir con la versión de LVS), mediante el comando cat parche | patch -p1 o
patch -p1 parche . Luego se deberán compilar con las opciones descritas
anteriormente (para más información mini-Howto-LVS) y preparar el parche para las
máquinas que vayan a actuar como director.
El nodo director puede ser una máquina sin discos que cargue su kernel a través
de la red mediante TFTP (ver la sección referente a Nodos sin discos) para luego
componer su directorio raíz mediante NFSroot. La opción de utilizar un diskette (o lilo)
para ejecutar el kernel es la más utilizada.
Luego habrá que compilar e instalar las fuentes del programa ipvsadm y el
sistema estará preparado.
A partir de aquí pueden hacerse dos tipos de configuraciones
• la primera exige un conocimiento del sistema LVS más profundo, ya que todos
los parámetros se configuraran de manera manual mediante la orden ipvsadm
• la otra es utilizar el script en perl (para lo cual se debe tener instalado perl) para
que configure los servidores y el director.
El programa ipvsadm servirá para especificar
• servicios y servidores que conoce y gestiona el director

• pesos de cada servidor respecto al servicio ofrecido
• algoritmo de gestión (de scheduling)
• añadir servicios y servidores
• quitar servicios
• también existen un par de programas al tipo de ipchains que permiten guardar
configuraciones
Para configuraciones iniciales o sistemas complejos el script escrito en perl está

preparado para varios sistemas operativos del tipo Unix, por lo que puede evitar más de
un dolor de cabeza al configurar nuestro sistema. Este script configure obtiene la
información de un fichero de texto (las fuentes contienen ejemplos de varios de estos
ficheros) y genera otros archivos. Entre estos archivos están el script de inicialización de
LVS preparado para ser incluido en la sección de comienzo rc.d, que configura desde
las IP de las máquinas que se le pasaron hasta la tabla de rutas, pasando por los
interfaces que no deben hacer ARP.
También incluye los programas y archivos de configuración necesarios para

luego utilizar en el programa de monitorización MON. Es una ayuda cómoda para los
que no quieran tener que configurar a mano de manera extensiva su LVS4.14.
50
Para utilizar configure simplemente hay que seguir los pasos que se ven en uno
de los ficheros de configuración por defecto que viene en la versión que se se haya
obtenido, configurar los parámetros del sistema y ejecutar perl configure fich_de
configuración. Al estar el script en perl son necesarios que los módulos necesarios para
ejecutarlo. La salida del programa será un script del tipo rc.d que puede ejecutarse en
los servidores reales y en el director (el script sabrá donde se ejecuta).
Otro factor a tener en cuenta a la hora de configurar servicios mediante ipvsadm

son las conexiones persistentes. Hay que atender este tipo de conexiones en casos como
una sesión HTTPS, en protocolos del tipo multipuerto como FTP (en los cuales los
puertos 20 y 21 corresponden al mismo servicio) o sitios comerciales, donde un cliente
debe cambiar del puerto 80 de HTTP al 443 para enviar por HTTPS sus datos bancarios.
Este problema requiere de configuraciones específicas en el director para que los

servicios sean balanceados al mismo nodo, saltándose el algoritmo de balanceo. El caso
de las conexiones persistentes es otro de los casos (junto con el de ARP) que dificulta la
configuración de los servicios, pero al mismo tiempo es impensable un sitio en Internet
que no vaya a proveer conexiones seguras a través de HTTPS o que simplemente tenga
un FTP. En cualquier caso, la orden ipvsadm permite configurar este tipo de conexiones
persistentes de manera bastante cómoda.
2.1.4.4 ¿Y la alta disponibilidad?
Llegados a este punto, tenemos nuestro servidor LVS funcionando, pero ¿qué
sucede en el caso de que uno de los servidores o directores falle? ¿Cómo se comporta el
sistema?
De la manera que lo tenemos configurado hasta este punto, un fallo en cualquier

a de los nodos sería fatídico en el sistema. En el caso de que el fallo estuviese en uno de
los nodos servidores, el nodo director intentaría reenviar los paquetes del cliente al
servidor, de manera que obtendría fallo después de un tiempo, al estar el nodo o servicio
caído.
En el caso del servidor el problema sería aún mayor, ya que produciría la pérdida
total del servicio. La intención de cualquier sitio en Internet no es sólo proveer a sus
usuarios de servicio durante algún tiempo, el servicio debe estar funcionando en lo que
se denomina en el argot técnico-empresarial 24x7, es decir 24 horas al dia 7 días a la
semana. Es aquí donde el proyecto LVS deja de manos de otras soluciones el proveer de
alta fiabilidad al sistema. En un principio se recomienda utilizar ciertas herramientas
con las que se han configurado varios sistemas como pueden ser:
• Piranha
• LVS-GUI + Heartbeat + Ldirectord
• MON + Heartbeat
Pero sirve cualquier otra opción que nos provea de algún método de mantener
los servicios proporcionados en alto ante el mayor número de eventos catastróficos.
51
Nosotros hemos decidido utilizar MON y heartbeat para nuestro sistema, como
ejemplo de configuración para cluster de alta fiabilidad HA, en este apartado
explicaremos cómo hemos configurado MON y qué es este programa.
Para monitorizar los servidores reales, configuramos MON de la manera que se

explicará en el nodo o nodos servidores, de manera que se éste continuamente
monitorizando servidores o servicios, para controlar en todo momento el estado del
cluster. Para asegurar la continuidad de un nodo servidor en el sistema se puede utilizar
también MON, pero es mejor utilizar Heartbeat para hacer la replica de este servidor, y
en caso de estar en un entorno de producción utilizar conexiones Ethernet y serial para
asegurarnos de que la comunicación entre los directores es continua.
Para controlar la caída de los servidores reales podemos pensar en un principio

como solución de aproximación, un programa que haga pings cada cierto intervalo a los
servidores y compruebe si éstos están en la red. Este programa lanzaría la ejecución de
la orden ipvsadm con los parámetros adecuados para quitar o introducir al servidor en la
tabla del nodo director. Otra opción es utilizar el protocolo y sistema de gestión de redes
SNMP para comprobar en cada momento mediante peticiones snmpget, sobre la MIB de
los agentes (en este caso los servidores) si estos proveen de los recursos necesarios a la
red, por ejemplo espacio de disco duro, un proceso servidor, o incluso la carga y
funcionamiento de las interfaces. Este sistema es en un principio el más adecuado para
la gestión de nuestro cluster, pero tiene ciertas desventajas que evitan que sea utilizado.
Entre estas desventajas se pueden contar:
• Inseguridad en la que esta actualmente SNMP.
Hasta que no exista implementación en Linux de SNMPv3, ya que el mecanismo

de autenticación es algo obsoleto y se necesita de un alto nivel de seguridad para
poder correr SNMP en una red privada sin riesgos.
• Complejidad y carga.
SNMP permitiría una gestión a niveles muy complejos. Mediante scripts

podríamos comprobar a intervalos regulares el estado de los parámetros de la
MIB sobre cada servidor, lo que implicaría un modelo de monitorización
complejo y adaptable en el sentido de que podríamos requerir mayor cantidad de
información que en cualquiera de los otros métodos, pero implicaría mucha más
carga en la red.
Probablemente la solución está en añadir una nueva red para el apartado de

monitorización.
• Mayor conocimiento y estudio del sistema.
Lo que supone encarecer el tiempo de creación de este y abaratar luego su

mantenimiento.
Existen más puntos a tener en cuenta a la hora de elegir SNMP como método de
monitorización. En cualquier caso, el uso de traps de SNMP nos permitiría de manera
cómoda establecer mecanismos suficientes como para que el sistema estuviese
52
funcionand o de manera correcta sin ningún problema. Hasta el momento a nadie se ha
puesto a diseñar una MIB especial para LVS en los que se pueda manejar los nodos
directores de manera remota o incluso la monitorización de los nodos servidores, este
sistema en el caso de ser implantado, sería de suma utilidad a la hora de realizar la
gestión del cluster de una manera cómoda y sencilla desde otras estaciones y con
programas como el HP-OPENVIEW o similares.
El método de utilizar scripts para monitorizar y actuar sobre el sistema es el

punto opuesto a la opción SNMP. Tiene como desventajas, que es más lento de
desarrollar y cada nueva acción de monitorización puede tener consecuencias
colaterales en el sistema, por lo que en muchos casos es necesario realizar un estudio de
cómo será la monitorización y comprobar que todos los componentes sean ortogonales
entre sí. Como ventaja de este sistema es que es tan adaptable como lo queramos hacer,
lo podemos programar en C, C++, Perl o shell scripts si nos apetece, y tan adecuado a
nuestro sistema como lo necesitemos, esto es una ventaja y un inconveniente a su vez,
ya que será difícil reutilizar el código de un sistema a otro, teniendo por tanto un ciclo
de implementación en varios sistemas mucho más largo.
MON
El método que utilizaremos en este caso, es el que provee un paquete que

incluye varios programas llamado MON. Este paquete está hecho prácticamente en perl,
por lo que deberemos bajar no sólo el paquete MON sino todos los módulos de perl que
se requieran para correr el programa.
La solución, MON, es una solución intermedia entre la mastodóntica SNMP y la

casera SCRIPT. Es configurable, requiere poco tiempo de puesta a punto, y además
también aporta tanta adaptabilidad a nuestras exigencias como nosotros queramos. Este
paquete fue escrito por un administrador de sistemas de Transmeta llamado Jim Trocki,
la compañía donde trabaja Linus Torvalds, y está prácticamente incluido en la totalidad
de las distribuciones que conozco.
MON es un agente de tipo general para monitorizar tanto servicios como

servidores y lanzar alertas que pueden ser fácilmente implementadas en C, perl o
cualquier otro lenguaje. MON lee de un fichero de configuración su forma de actuación,
dicho fichero tiene una forma similar en funcionamiento a SNMP, es una manera muy
adaptable de monitorizar cualquier sistema.
En dicho fichero de configuración podemos encontrar las siguientes secciones:
• La primera es la sección hostgroups, que aporta los grupos a los que se realizara
la monitorización.
• La segunda es la sección de vistas, que se compone de una o más vistas sobre los
grupos de trabajo que contiene las especificaciones de la monitorización y la
actuación que se hará acorde con cada evento. En las zonas de vistas se pueden
separar en:
o El servicio a monitorizar, pueden contenerse uno o más servicios en cada
vista, de manera que se especifica en ellos.
o El intervalo de resolución en el que se realizaran los sondeos de las
monitoriza ciones.
53
o Las traps, interrupciones o señales que se utilizarán.
o El programa monitor que se utilizará para cada servicio.
o La dependencia entre servicios y el comportamiento en caso de
dependencias
o El campo periodo que especifica entre qué fechas se realizará la
monitorización y de qué manera se procederá en caso de ciertos eventos.
Este campo posee a su vez otros campos como pueden ser
 Periodo real
 Programa de alerta o control de eventos
 Varios parámetros para el funcionamiento y control de las alertas
Una vez explicada la estructura del fichero de configuración, pasaremos a

explicar cuál es el método de funcionamiento de MON.
MON como ya hemos dicho se compone de un agente planificador que

solamente se encarga de interpretar el fichero de configuración y realizar
periódicamente y en las horas señaladas las llamadas oportunas a los programas de
monitorizaci ón y alerta sobre los nodos perteneciente a un conjunto hostgroup. De esta
manera, el programa monitor puede ser implementado por un programador, de manera
que este es independiente de MON, mientras que acepte los parámetros que MON le
envía y las variables de entorno que adquiere al ser hijo de este.
El programa monitor es llamado periódicamente para cada nodo perteneciente a

un grupo de host o host particulares pertenecientes a dicha vista, hace su monitorización
específica y da un código en la llamada exit(). Este código debe ser interpretado por la
sección de alertas, de manera que se proceda a la ejecución necesaria para el manejo del
evento en el caso de que el código de salida del monitor sea el que decide de que
manera se controla el evento.
De esta manera, lo único que debe crear el programador son los programas
monitor y alerta, donde el programa monitor se encargará de monitorizar los eventos de
los que depende nuestro sistema, ya sean estos adquisición en una tarjeta de adquisición
de datos como control de un puerto ttyS X como el control de acceso a un

servidor de un determinado servicio. Además programado mediante el lenguaje que
resulte más cómodo al programador, lo que facilita la tarea.
Por otro lado el programa de alerta debe atender a dos tipos de parámetros y
variables de entorno pasados por MON. El primer tipo son los códigos de retorno del
programa monitor que deberá entender a la perfección para poder ejecutar el manejo del
evento que detectase el monitor. El segundo son los parámetros que proporciona MON
para el control de caída o puesta a punto de un servicio.
El paquete MON lleva incorporado unos cuantos programas monitores y alertas

que se guardan dentro de /usr/lib/mon/, estos programas por defecto suelen bastar para
llevar a cabo la monitorización que nosotros necesitamos. Entre estos programas se
encuentran los siguientes monitorizadores:
54
monitor de FTP, comprueba el estado para poder acceder a un servidor FTPD
ftp.monitor
mediante la cuenta que le proporcionemos como parámetro en el fichero de
configuración.
http.monitor monitor HTTP, igual que el anterior pero para www.
telnet.monitor idem que los anteriores.
smtp.monitor idem para este otro protocolo.
dialin.monitor entradas de llamadas en el modem.
snmp.monitor compatible con SNMP, para comprobar el acceso a un agente.
Y muchos otros monitores que permiten monitorizar en general servicios de red

mediante programas conocidos como ping, o peticiones a determinada pagina del
servidor o a determinado recurso. De esta manera podemos ver el carácter adaptable que
posee este tipo de configuración.
Además de los monitores se encuentran los scripts o programas de alerta que

funcionan de la misma manera que los monitores, son llamados por MON con
determinados parámetros de manera que se actúa acorde con el evento que generó la
alerta, subsanando algún problema, guardando en los log que lo provocó, solucionando
en la manera de lo posible dicho problema e informando mediante algún método al
administrador del sistema, acerca del evento que produjo la llamada. Existen más
programas externos que controlan el funcionamiento de MON como son, monshow y
mon-cgi, estos permiten ver y controlar desde línea de órdenes o desde un navegador
mediante el acceso a una WEB el estado y funcionamiento de MON. En nuestro caso no
los hemos probado, ya que la solución que buscábamos no dependía ni requería de este
CGI.
Una vez explicado el funcionamiento de MON, debemos explicar qué servicios

debemos monitorizar, de qué manera los podemos monitorizar y que medidas debemos
tomar ante determinados eventos. Nuestra intención es explicar este apartado utilizando
como ejemplo el caso de estudio aportado arriba, de manera que se pueda comprobar
como es el funcionamiento de MON y qué factores son importantes a la hora de
configurar un sistema de monitorización de este tipo.
Factores que intervienen en la configuración de MON
Para empezar debemos hacer un estudio de ciertos factores que nos pueden
interesar y que pueden afectar a nuestro sistema como son.
1. Servicios que poseemos en nuestro cluster.
2. Máquinas dentro del cluster. Es necesario para controlar la resolución de la

monitorización, y que la carga de esta no sea demasiado alta.
3. Comportamiento ante caídas.
55
El apartado de servicios es necesario conocerlo a fondo. Es muy sencillo decir
que se necesita un servicio de HTTP, otro de FTP y otro de squid, pero saber los
temporizadores de cierre de conexión de dichos servicios no es tan fácil, en cambio
seguramente estemos interesados en poder disponer de una monitorización sobre estos
servícios.
Pongamos el ejemplo de un servicio de telnet sobre el que se activa algún tipo de

envoltura como TCP wrapper, o kerberos. Este telnet tardará algo más en terminar la
configuración de la sesión telnet y por tanto el tiempo de establecimiento sera algo más
alto. De esta manera cuando un script que intente comprobar el estado de un servidor
telnetd y éste tarde más de lo que esperaba (aunque sea tan solamente un segundo), se
mandará la alerta apropiada quitando el servicio del LVS, aunque dicho servicio
funcione y por tanto se dispondrá de una máquina menos dentro cluster con la que hacer
el balanceo. También puede ser necesaria hacer una previsión de cuándo se deben
realizar más monitorizaciones sobre un servicio, o las horas a las que no son necesarias
hacerlas. Hay que recordar que MON es un programa que corre en el nodo director, y al
ser este un punto crítico del sistema es conveniente mantenerlo lo más descargado
posible para que se dedique a lo que realmente debe hacer, balancear conexiones y
proporcionar servicios.
El apartado de las máquinas que contiene el cluster es necesario para establecer

la tasa o intervalo de monitorización. Este intervalo afectará en dos aspectos. El primero
es la carga del nodo director donde se ejecuta MON, al estar continuamente lanzando
programas monitores y de alerta, el nodo consume recursos como son memoria y CPU,
por lo que puede ser un factor importante a tener en cuenta en caso de haber instalado
un nodo director inadecuado en requerimientos para dicha labor.
Por otro lado está la carga sobre la red sobre la que tanto estamos hablando a lo
largo de todo el proyecto. Mantener la red lo menos congestionada posible es cuestión
de cuidar este tipo de apartados y de tener un diseño de red previo adaptado a las
necesidades que se preveen para nuestro sistema.
Por último hemos de definir cual será el comportamiento ante caídas.

Generalmente en nuestro caso, el comportamiento suele ser algo como, quitar la entrada
del nodo director DIRECCIÓN-SERVICIO-PESO, para que dicho nodo no sea tenido
en cuenta en las siguientes decisiones del nodo director.
Avisar al administrador mediante cualquier método o recurso, enviando

mensajes al móvil o mails a la cuenta del administrador o dando pitidos incesantes para
que alguien trate de solucionar el problema lo antes posible. Intentar solucionar el
problema desde el nodo director suele requerir de sistemas expertos que evalúen las
probabilidades de la causa que provocó la caída e intente solucionarse. Registrar los
eventos que sucedieron de manera que se sepa cuales fueron las causas de caída del
servicio en cualquier momento.
Se pueden monitorizar en un LVS cualquier tipo de servicios o recursos, desde

la accesibilidad a un nodo con fping.monitor hasta el espacio que queda libre en el
sistema de almacenamiento distribuido NFS. De manera general, se suele monitorizar
como mínimo el acceso a los servidores y el acceso a los servicios.
56
La utilización del acceso a los servicios es más conveniente que el acceso a
caída de un servidor, pero implica más carga de red, por lo que depende, qué método
será elegido monitor del sistema. Los programas monitores de un servicio, suelen ser
programas que hacen una petición al servicio de carácter general (como pedir la
información de versión o página principal de un servidor HTTP), esto conlleva mucha
más carga en la red y en el sistema general que un fping destinado a un grupo de hosts,
pero por el contrario, si imaginamos una situación muy usual como es la de tener una
máquina con varios servicios activados no es difícil entender que puede caer un servicio,
y seguir funcionando el otro, y por lo tanto fping dará una monitorización errónea
respecto a lo que en un principio requeríamos para el sistema.
2.1.4.5 Conclusiones
El servicio ofrecido por la conjunción de LVS, MON y Heartbeat puede llegar a

ser tan potente como otras aplicaciones o configuraciones propietarias que existen en el
mercado a un precio mucho mayor. Uno de los problemas que no hemos comentado que
tiene LVS de momento es que al caer el nodo director y retomar su trabajo el nodo de
backup mediante heartbeat como veremos en el apartado de heartbeat, el contenido de la
tabla hash, así como las conexiones y toda la información del nodo director se pierden,
esto produce en los clientes que tenían una conexión en curso, la pérdida de dicha
conexión.
En un principio y dependiendo de qué servicios puede ser más o menos drástico.

La gente del proyecto LVS esta trabajando en mejorar este comportamiento, y se espera
que dada la facilidad y adaptabilidad con la que pretende dotar Alan Robertson el
proyecto heartbeat, cubrir este problema sea más simple.
57
2.2 Clusters HP
2.2.1 Conceptos importantes: migración y balanceo
Los clusters HP están dedicados a dar el mayor rendimiento computacional

posible y existen multitud de formas de implementarlos.
Ha llevado años implementarlos, por tanto a lo largo de la historia ha habido

todo tipo de ideas para intentar hacerlos lo más eficientes posible. En este documento se
estudian unas cuantas de estas implementaciones (PVM, MPI, Beowulf) y se ahondará
en una de ellas: openMosix.
La primera división en las implementaciones puede ser la división entre las
• soluciones que funcionan a nivel de aplicación y

• soluciones que funcionan a nivel de kernel.
Las que funcionan a nivel de aplicación suelen tomar forma de librería. Se tienen
que realizar los programas para que aprovechen esta librería por lo tanto cualquier
programa ya existente para que pueda ser usado en un cluster y mejore su rendimiento
tiene que ser reescrito al menos parcialmente.
Esto tiene bastantes inconvenientes: muchas de las aplicaciones que necesitan

grandes tiempos de cómputo se realizaron hace décadas en lenguaje Fortran. Este
lenguaje aparte de estar relegado hoy en día a aplicaciones matemáticas o físicas, puede
llegar a ser bastante difícil de comprender; por lo tanto es bastante difícil migrarlo al
nuevo entorno distribuido.
Por otro lado una de las ventajas que tienen los clusters HP con respecto a los
supercomputadores es que son bastante más económicos. Pero si el dinero que se ahorra
en el hardware hay que invertirlo en cambiar los programas esta solución no aporta
beneficios que justifiquen tal migración de equipos. Además hay que tener en cuenta
que la mayor parte de las instituciones o instalaciones domésticas no tienen dinero para
invertir en ese software, pero que sí disponen de ordenadores en una red (universidades
por ejemplo).
La segunda opción es que el software que se encarga del HP se encuentre en el

kernel del sistema operativo. En este caso no se necesitan cambiar las aplicaciones de
usuario, sino que éstas usan las llamadas estándar del kernel por lo tanto el kernel
internamente es el que se encarga de distribuir el trabajo de forma transparente a dicha
aplicación. Esto tiene la ventaja de que no hace falta hacer un desembolso en cambiar
las aplicaciones que lo necesitan y que cualquier aplicación puede ser distribuida. Por
supuesto un factor que siempre habrá que tener en cuenta es la propia programación de
la aplicación.
Por otro lado esta aproximación también tiene varios inconvenientes: el kernel se
vuelve mucho más complejo y es más propenso a fallos. También hay que tener en
cuenta que estas soluciones son específicas de un kernel, por lo que si las aplicaciones
no están pensadas para ese sistema operativo habría que portarlas. Si los sistemas
operativos tienen las mismas llamadas al sistema, siguiendo un estándar POSIX, no
58
habría grandes problemas. Otros sistemas operativos propietarios que no cumplen estos
estándares no pueden disponer de estas ventajas.
Una forma de conseguir HP es migrando procesos, dividiendo las aplicaciones

grandes en procesos y ejecutando cada proceso en un nodo distinto. Lo que se quiere
conseguir es el máximo uso de los recursos en todo momento, especialmente los
procesadores. Para conseguirlo hay dos aproximaciones:
• Asignar estáticamente cada proceso a un nodo en particular.
En esta aproximación es importantísima la política de localización. Se

elige estáticamente el nodo donde el proceso vivirá toda su vida. Por tanto es
muy importante elegir correctamente estos nodos. Muchas veces esta solución
necesita un administrador que decida dónde debe ir cada proceso. El caso más
simple es tener todos los nodos con la misma potencia de cálculo y dividir el
único programa al que se quiera dedicar los recursos en un número de procesos
igual al número de nodos de los que se disponen. Asíse asignaría cada proceso a
uno de los nodos. Hay que tener en cuenta que esta configuración es lejana a la
normal y que ya que un fallo en el algoritmo de elección de nodo puede
infrautilizar mucho de los recursos la configuración manual es normal en estos
algoritmos. Esto no es tan malo como pueda parecer a primera vista porque es
también muy corriente en estos casos que una vez hecha la configuración inicial,
los procesos estén ejecutándose durante años si es necesario.
• Asignar dinámicamente procesos a los nodos.
Los procesos una vez iniciados en un nodo pueden migrar a otro nodo
dinámicamente. En estos casos aunque es importante la política de localización
para minimizar el gasto de recursos, también es importantísima la política de
migración. Por supuesto también se pueden ubicar los procesos manualmente,
con la ventaja de que se pueden ubicar en cualquier momento durante la vida del
proceso. Si la política de migración es correcta y los procesos tienen una vida
larga y se ha dividido correctamente la aplicación, debería haber al comienzo de
la ejecución de los procesos un periodo de reordenación de los procesos, con
varias migraciones, una vez el sistema llegara a una condición estable, no
deberían producirse apenas migraciones hasta que los procesos finalizaran. Igual
que ocurre en el caso anterior, esta configuración es lejana a la habitual, pero al
contrario del caso anterior, aquíno es necesaria la configuración manual (si el
algoritmo de migración es suficientemente bueno). Cuando se desbalancea el
sistema éste se encarga de que se vuelva a balancear, de tal forma de que se
aprovechen los recursos al máximo.
Sobre el balanceo ya se ha hablado en la sección anterior, como se puede

comprender el correcto balanceo es muy complejo, se puede balancear con respecto a
una variable (por ejemplo el procesador), pero hacerlo con respecto a todo el sistema en
conjunto es algo demasiado complejo y el tiempo de cómputo para hacer las elecciones
correctas sería muy grande. Por tanto estos algoritmos intentan tener un fundamento
matemático fuerte que intenta minimizar el tiempo de cómputo. Muchos de estos
sistemas usan fundamentos estadísticos, como por ejemplo openMosix.
59
Como ya se verá con más detalle, openMosix intenta maximizar el uso de todos
los recursos. Intentar solamente balancear respecto al procesador puede dar lugar a
decisiones bastante malas, porque se pueden enviar muchos procesos que no hagan
mucho uso del procesador a uno de los nodos, si estos procesos están haciendo
entrada/salida y son procesos grandes, es muy posible que el nodo empiece a hacer
trashing pues se quedará sin memoria, con lo que los procesos no podrán ejecutar su
función.
En el cuadro se aprecian las posibles formas que existen para clusters. Se

muestra este cuadro para que se pueda comprender la cantidad de decisiones que se
tienen que hacer cuando se implementa un cluster de este tipo y asíse comprenderá
mejor por qué hay tantas implementaciones y tan dispares.
Tema Problemas que genera

Sin requisa de procesos Mayor latencia para procesos de alta prioridad
Con requisa de procesos Sobrecarga, implementación compleja
Balanceo estático Mal balanceo de carga
Balanceo dinámico Sobrecarga, implementación compleja
Nivel de aplicación Sobrecarga, falta de información
Nivel de kernel Dificultad de implementación
Nodos dedicados Infrautilización de recursos
Nodos comparten espacio Se necesita una política eficiente de localización
Nodos comparten tiempo Sobrecarga cambio de contexto
Scheduling independiente Pérdida de rendimiento
Scheduling de grupo Implementación compleja
Con carga externa, quedarse Pérdida de rendimiento en trabajos locales
Ante carga externa, migrar Sobrecarga de migración, límites de migración
Tabla 1 Clusters HP. Aspectos de implementación
Ya se ha explicado el balanceo estático frente a balanceo dinámico y el nivel de

aplicación frente al nivel de sistema que serán conceptos que se necesite en las próximas
secciones, ahora se va a explicar las demás características.
Requisa se refiere a poder parar el proceso y coger sus recursos (básicamente los
registros del procesador y memoria). La requisa de los procesos puede existir o no. Con
requisa no queremos decir hacer requisa de los procesos para migrarlos después, sino
simplemente poder hacer requisa de un proceso en cualquier momento. Cuando un
sistema es multitarea normalmente se implementa algún sistema de requisa para poder
parar procesos y hacer que otros procesos tomen el procesador para dar la sensación al
usuario de que todos los procesos se están ejecutando concurrentemente.
60
Si no se implementa requisa, un proceso de baja prioridad puede tomar el
procesador y otro proceso de alta prioridad no podrá tomarlo hasta que el proceso de
baja prioridad lo ceda a otros procesos. Este esquema puede ser injusto con las
prioridades y un error en un programa, puede llegar a dejar sin funcionar la máquina
pues nunca devolvería el control, pero tampoco haría ningún trabajo útil. Además para
sistemas que necesitan tiempo real, simplemente es inaceptable que procesos de baja
prioridad estén dejando a los procesos de tiempo real sin tiempo de procesador y quizás
con esta latencia extra se esté haciendo que el sistema no pueda cumplir sus operaciones
en tiempo real, haciendo que el sistema sea inútil. Hoy en día la requisa se implementa
al menos a un nivel elemental en casi todos los sistemas que necesiten hacer funcionar
más de un proceso (por no decir todos). Algunos sistemas lo que hacen es no esperar a
que cumpla un temporizador y realizar la requisa sino a esperar que el proceso haga
alguna llamada al sistema para aprovechar, tomar el procesador y cederlo a otro proceso.
Esta aproximación sigue teniendo el problema de que si un proceso maligno o mal
programado no hace llamadas a sistema porque haya quedado en un bucle, nunca se
ejecutará nada en ese ambiente.
Si se implementa la requisa hay que tener en cuenta que la implementación más

simple que se puede dar (que es la que usan buena parte de los sistemas) necesita un
temporizador que marque cuando se acabó el tiempo del proceso y requisar ese proceso
para asignar a otro proceso. Esto impone una sobre carga pues hay que tratar una
interrupción, actualizar unas variables para saber cuanto tiempo lleva un proceso
trabajando.
Hay una implementación más compleja que trata de que siempre que haya un
proceso de una prioridad mayor al que se está ejecutando se quite el procesador al
proceso y se dé el procesador al proceso con mayor prioridad. Estos suelen ser sistemas
en tiempo real que también (ya que se ponen) pueden tener otras exigencias como unos
tiempos mínimos de latencia para ciertos procesos. Para conseguir esto, el kernel no
solamente tiene que requisar procesos de baja prioridad en favor de los procesos de
tiempo real sino que tiene que ser capaz de requisar su propio código. Esto suele
significar que casi cualquier porción del código del kernel se puede ejecutar entre dos
instrucciones de este mismo código. Esto presenta muchísimos problemas a la hora de
programar, hay que tener mucho más cuidado con evitar condiciones de carrera dentro
del propio kernel que antes por ser código no requisable no se podían dar. Por tanto
implementar requisa, puede hacer que un sistema sea tiempo real pero complica
tremendamente el núcleo del sistema.
Las siguientes tres líneas en el cuadro tratan sobre los recursos del cluster, estos
son los nodos. Existen tres modos en los que se puede dedicar los nodos del cluster,
estos modos son:
• Modo dedicado.
En este modo que es el más simple de todos, solamente un trabajo está siendo
ejecutado en el cluster en un tiempo dado, y como mucho un proceso de este
trabajo que se está ejecutando es asignado a un nodo en cualquier momento en el
que se siga ejecutando el trabajo. Este trabajo no liberará el cluster hasta que
acabe completamente aunque solamente quede un proceso ejecutándose en un
único nodo. Todos los recursos se dedican a este trabajo, como se puede
61
comprender fácilmente esta forma de uso de un cluster puede llevar a una
pérdida importante de potencia sobre todo si no todos los nodos acaban el
trabajo al mismo tiempo.
• Modo de división en el espacio.
En este modo, varios trabajos pueden estar ejecutándose en particiones disjuntas

del cluster que no son más que grupos de nodos. Otra vez como mucho un
proceso puede estar asignado a un cluster en un momento dado. Las particiones
están dedicadas a un trabajo, la interconexión y el sistema de entrada/salida
pueden estar compartidos por todos los trabajos, consiguiendo un mejor
aprovechamiento de los recursos. Los grupos de nodos son estáticos y los
programas necesitan un número específico de nodos para poder ejecutarse, esto
lleva a dos conclusiones:
1. Puede existir trabajos para los que no haya una división lo

suficientemente grande por lo que non podrían ser ejecutados
2. Puede tener un trabajo que solamente aproveche alguno de los nodos
desperdiciando una división de gran cantidad de nodos. Para evitar este
segundo punto se tienen que usar técnicas para elegir inteligentemente
los nodos donde se ejecuten los trabajos, intentando minimizar el número
de nodos ociosos.
También puede ocurrir que un trabajo muy largo tome los recursos del cluster
evitando que otros trabajos más rápidos acaben, esto consigue aumentar la
latencia.
• Modo de división en el tiempo.
En cada nodo pueden estar ejecutándose varios procesos a la vez por lo que se
solucionan los problemas anteriores. Este es el modo más usado normalmente
puesto que no tiene tantas restricciones como el otro y se puede intentar hacer un
equilibrado de carga eligiendo correctamente los procesos.
Los dos siguientes puntos de la tabla tratan sobre scheduling, esta planifiación
solo se da cuando el modo que se ha elegido es el modo de división en el tiempo.
Hay dos tipos de scheduling en cuanto a clusters se refiere:
• Scheduling independiente.
Es el caso más sencillo y más implementado, se usa un sistema operativo en

cada nodo del cluster para hacer scheduling de los distintos procesos en un nodo
tradicional, esto también es llamado scheduling local. Sin embargo, el
rendimiento de los trabajos paralelos que esté llevando a cabo el cluster puede
verse degradado en gran medida.
Cuando uno de los procesos del trabajo paralelo quiera hacer cualquier tipo de
interacción con otro proceso por ejemplo sincronizarse con él, este proceso
puede que no esté ejecutándose en esos momentos y puede que aún se tarde un
62
tiempo (dependiente normalmente de su prioridad) hasta que se le ejecute por
otro cuanto de tiempo. Esto quiere decir que el primer proceso tendrá que
esperar y cuando el segundo proceso esté listo para interactuar quizás el primer
proceso esté en swap y tenga que esperar a ser elegido otra vez para funcionar.
• Scheduling de grupo.
En este tipo se hace scheduling sobre todos los procesos del trabajo a la vez.
Cuando uno de los procesos está activo, todos los procesos están activos.
Estudios han demostrado que este tipo de scheduling puede aumentar el
rendimiento en uno o dos puntos de magnitud. Los nodos del cluster no están
perféctamente sincronizados. De hecho, la mayoría de los clusters son sistemas
asíncronos, que no usan el mismo reloj.
Cuando se dice, a todos los procesos se le hace scheduling a la vez, no quiere

decir que sea exáctamene a la vez. Según ese mismo estudio, según aumenta la
diferencia entre que se elige para ejecutarse el primer proceso y el último, se
pierda rendimiento (se tarda más en acabar el trabajo). Para conseguir buenos
rendimientos se tiene que o bien, permitir a los procesos funcionar por mucho
tiempo de forma continuada o bien que la diferencia entre que un proceso se
ejecuta y el último que se ejecuta es muy pequeña.
Pero como se puede comprender, hacer scheduling en un cluster grande, siendo

el scheduling una operación crítica y que tiene que estar optimizada al máximo
es una operación bastante compleja de lograr, además se necesita la información
de los nodos para poder tomar buenas decisiones, lo que acaba necesitando redes
rápidas.
Las dos últimas filas tratan de que deben hacer los procesos cuando se
encuentran que en su nodo local hay otros procesos que provienen de otros nodos. Estos
pueden venir por alguna política de migración o porque se esté ejecutando el scheduler
de grupo del que hemos hablado en el punto anterior. Los trabajos locales podrían tener
prioridad sobre trabajos externos, por ejemplo los procesos de usuario interactivos
donde no queremos que se degrade el rendimiento deben mantener mayor prioridad.
Hay dos formas de tratar esta situación:
• El trabajo externo migra: si el proceso migra, existe el coste de migración pero

el proceso puede ir a un nodo donde se ejecute de forma más eficiente.
• El trabajo externo se mantiene en el cluster: si el proceso se mantiene en el nodo
donde se encuentra se evita la sobrecarga que conlleva la migración, para no
afectar a los procesos de ese nodo se les da muy poca prioridad o por ejemplo se
hace un grupo de procesos especial que son los extenso que disponen de menos
CPU. El problema es que seguramente se ralenticen los procesos tanto locales
como los externos, sobre todo si es un proceso que necesita frecuentar
sincronizaciones, comunicación y acceso a Entrada/Salida.
Con unas buenas decisiones en este apartado se puede solucionar los problemas
expuestos.
63
2.2.2 Beowulf
El proyecto Beowulf fue iniciado por Donald Becker (también famoso por crear
numerosos drivers para tarjetas de red en Linux) en 1994 para la NASA. Este proyecto
se basa en usar PVM y MPI, añadiendo algún programa más que se usan para
monitorizar, realizar benchmarks y facilitar el manejo del cluster.
Entre las posibilidades que integra este proyecto se encuentra la posibilidad de

que algunos equipos no necesiten discos duros, por eso se consideran que no son un
cluster de estaciones de trabajo, sino que dicen que pueden introducir nodos
heterogéneos. Esta posibilidad la da otro programa y Beowulf lo añade a su distribución.
Beowulf puede verse como un empaquetado de PVM/MPI junto con más

software para facilitar el día a día del cluster pero no aporta realmente nada nuevo con
respecto a tecnología.
2.2.3 OpenMosix
OpenMosix es un software para conseguir clustering en GNU/Linux, migrando

los procesos de forma dinámica con requisa. Consiste en unos algoritmos de
compartición de recursos adaptativos a nivel de kernel, que están enfocados a conseguir
alto rendimiento, escalabilidad con baja sobrecarga y un cluster fácil de utilizar. La idea
es que los procesos colaboren de forma que parezca que están en un mismo nodo.
Los algoritmos de openMosix son dinámicos lo que contrasta y es una fuerte

ventaja frente a los algoritmos estáticos de PVM/MPI, responden a las variaciones en el
uso de los recursos entre los nodos migrando procesos de un nodo a otro, con requisa y
de forma transparente para el proceso, para balancear la carga y para evitar falta de
memoria en un nodo.
Las fuentes de openMosix han sido desarrolladas 7 veces para distintas versiones
de Unix y BSD, nosotros en este proyecto siempre hablaremos de la séptima
implementación que es la que se está llevando a cabo para Linux.
OpenMosix, al contrario que PVM/MPI, no necesita una adaptación de la

aplicación ni siquiera que el usuario sepa nada sobre el cluster. Como se ha visto, para
tomar ventaja con PVM/MPI hay que programar con sus librerías, por tanto hay que
rehacer todo el código que haya (para aprovechar el cluster).
En la sección de PVM ya se han explicado las desventajas que tenía esta

aproximación. Por otro lado openMosix puede balancear una única aplicación si esta
está dividida en procesos lo que ocurre en gran número de aplicaciones hoy en día. Y
también puede balancear las aplicaciones entre sí, lo que balancea openMosix son
procesos, es la mínima unidad de balanceo. Cuando un nodo está muy cargado por sus
procesos y otro no, se migran procesos del primer nodo al segundo. Con lo que
openMosix se puede usar con todo el software actual si bien la división en procesos
ayuda al balanceo gran cantidad del software de gran carga ya dispone de esta división.
64
El usuario en PVM/MPI tiene que crear la máquina virtual decidiendo qué nodos
del cluster usar para correr sus aplicaciones cada vez que las arranca y se debe conocer
bastante bien la topología y características del cluster en general. Sin embargo en
openMosix una vez que el administrador del sistema que es quien realmente conoce el
sistema, lo ha instalado, cada usuario puede ejecutar sus aplicaciones y seguramente no
descubra que se está balanceando la carga, simplemente verá que sus aplicaciones
acabaron en un tiempo record.
PVM/MPI usa una adaptación inicial fija de los procesos a unos ciertos nodos, a
veces considerando la carga pero ignorando la disponibilidad de otros recursos como
puedan ser la memoria libre y la sobrecarga en dispositivos E/S.
En la práctica el problema de alojar recursos es mucho más complejo de lo que

parece a primera vista y de como lo consideran estos proyectos, puesto que hay muchas
clases de recursos (CPU, memoria, E/S, intercomunicación de procesos, etc.) donde
cada tipo es usado de una forma distinta e impredecible. Si hay usuarios en el sistema,
existe aún más complejidad y dificultad de prever que va a ocurrir, por lo que ya que
alojar los procesos de forma estática es tan complejo que seguramente lleve a que se
desperdicien recursos, lo mejor es una asignación dinámica de estos recursos.
Además estos paquetes funcionan a nivel de usuario, como si fueran

aplicaciones corrientes, lo que les hacen incapaces de responder a las fluctuaciones de la
carga o de otros recursos o de adaptar la carga entre los distintos nodos que participan
en el cluster. En cambio openMosix funciona a nivel de kernel por tanto puede
conseguir toda la información que necesite para decidir cómo está de cargado un
sistema y qué pasos se deben seguir para aumentar el rendimiento, además puede
realizar más funciones que cualquier aplicación a nivel de usuario, por ejemplo puede
migrar procesos, lo que necesita una modificación de las estructuras del kernel.
2.2.4 TOP 500
Este ranking indica cuáles son los 500 computadores más potentes del mundo.
Se incluyen MPPs, constelaciones, clusters y máquinas vectoriales. Vamos a destacar
algunos de los resultados del Top de supercomputadores en diferentes épocas.
A fecha de junio de 2001 la lista demostraba claramente como estaban

avanzando los supercomputadores, algunos datos curiosos fueron:
• El número 1 del top era ASCI White de IBM que llega a 7,2 TeraFlops/s.
• 12 de los sistemas tenían más de 1 TFlop/s, el más pequeño deltop ten alcanzaba
1.18TFlop/s.
• El rendimiento total era de 108.8 TFlop/s, comparado con 88.8 TFlop/s del año
anterior.
• El número 500 pasó de tener 55.1 TFlop/s a 67.8 TFlop/s.
Esta lista hace una división de clusters entre clusters tradicionales y

constelaciones. De los cluster que cuyos nodos no son SMP podía verse que los dos
primeros estaban en los puestos 30 y 31 y eran IBM.
65
2.3 Requrimientos y planteamientos
2.3.1 Requerimientos hardware
Para la instalación básica de un cluster necesitaremos al menos dos

computadoras conectadas en red. Podremos conectarlas mediante un cable cruzado entre
las respectivas tarjetas de red, con un hub o con un switch.
Evidentemente cuanto más rápida sea la conexión entre máquinas, más eficaz
será nuestro sistema global.
Actualmente Fast Ethernet es un estándar, permitiendo múltiples puertos en una

máquina. Gigabit Ethernet es más cara y no es recomendable probar con ella sin antes
haberse asegurado un correcto funcionamiento con Fast Ethernet y comprobar que
realmente se necesita este extra en la velocidad de transferencia de datos entre nodos.
Siempre podremos hacer funcionar varias tarjetas Fast en cada nodo para
asignarles luego la misma dirección (IP) y de esta forma poder obtener múltiples en la
velocidad.
El resto del hardware necesario dependerá de las decisiones que se hayan hecho
con el sistema de ficheros (en red o no), la instalación de monitores gráficos en todos o
solo algunos nodos, etc.
Algunas disposiciones hardware especiales pueden encontrarse en la sección

Nodos sin discos del capítulo Tutoriales para casos especiales.
2.3.2 Líneas básicas en la configuración del hardware
Para poder configurar un gran cluster (refiriéndose al número de nodos) hay que
pensar en ciertos aspectos, como por ejemplo dónde situar las máquinas. Tenerlas en
medio de una oficina puede resultar incómodo en muchos aspectos. La mejor opción
sería raquearlas.
El acondicionamiento de la sala donde deba situarse el cluster también es

importante para evitar sobrecalentamientos y demás incomodidades a la hora de trabajar
con él.
En todo caso hay que asegurarse de poder tener siempre un fácil acceso a los
nodos.
2.3.3 Planteamientos del cluster
Para configurar tu cluster openMosix en un pool de nodos, o conjunto de

estaciones de trabajo, tendremos diferentes opciones, cada una con sus ventajas e
inconvenientes.
66
En una single-pool todos los servidores y estaciones de trabajo son utilizadas
como un cluster único: cada máquina forma parte del cluster y puede migrar procesos
hacia cada uno de los otros nodos existentes.
Esta configuración hace que tu propia máquina forme parte del pool.
En un entorno llamado server-pool los servidores son parte del cluster mientras
que las estaciones de trabajo no lo son. Si quisiéramos ejecutar aplicaciones en el cluster
necesitaremos entrar en él de forma específica. De este modo las estaciones de trabajo
permanecerán libres de procesos remotos que les pudieran llegar.
Existe una tercera alternativa llamada adaptive-pool, donde los servidores son
compartidos mientras que las estaciones de trabajo podrán entrar y salir del cluster.
Podemos imaginar que las estaciones deban ser usadas durante un cierto intervalo de
tiempo diario, y que fuera de este horario puedan ser aprovechadas para las tareas del
cluster.
67
3. PASO DE MENSAJES
3.1 Introducción
Tanto PVM como MPI se basan en el concepto de paso de mensajes. Los
mensajes son pasados entre los procesos para conseguir que se ejecuten de manera
colaborativa y de forma sincronizada. Se ha elegido mensajes pues se puede
implementar de forma más o menos efectiva en un cluster, los mensajes se pueden
enviar en forma de paquete IP y el ordenador destino desempaqueta el mensaje y decide
a que proceso va dirigido. Una vez hecho esto, envía la información al proceso en
cuestión. MPI en particular se necesita conocer de forma básica los mecanismos de paso
de mensajes. Hay tres mecanismos básicos de paso de mensajes:
• Paso de mensajes síncrono.
Cuando un proceso P ejecuta un envío síncrono a un proceso Q, tiene que

esperar hasta que el proceso Q ejecuta el correspondiente recibo de información
síncrono. Ambos procesos no volverán del envío o el recibo hasta que el
mensaje está a la vez enviado y recibido.
Cuando el enviar y recibir acaban, el mensaje original puede ser inmediatamente

sobrescrito por el nuevo mensaje de vuelta y éste puede ser inmediatamente
leído por el proceso que envió originariamente el mensaje. No se necesita un
buffer extra en el mismo buffer donde se encuentra el mensaje de ida, se escribe
el mensaje de vuelta.
• Enviar/Recibir bloqueante.
Un envío bloqueante es ejecutado cuando un proceso lo alcanza sin esperar el

recibo correspondiente. Esta llamada bloquea hasta que el mensaje es
efectivamente enviado, lo que significa que el mensaje (el buffer donde se
encuentra el mensaje) puede ser reescrito sin problemas. Cuando la operación de
enviar ha acabado no es necesario que se haya ejecutado una operación de
recibir. Sólo sabemos que el mensaje fue enviado, puede haber sido recibido o
puede estar en un buffer del nodo que lo envía, o en un buffer de algún lugar de
la red de comunicaciones o puede que esté en el buffer del nodo receptor.
Un recibo bloqueante es ejecutado cuando un proceso lo alcanza, sin esperar a su

correspondiente envío. Sin embargo no puede acabar sin recibir un mensaje.
Quizás el sistema esté proveyendo un buffer temporal para los mensajes.
• Envío/recibo no bloqueante.
Un envío no bloqueante es ejecutado cuando un proceso lo alcanza, sin esperar

al recibo. Puede acabar inmediatamente tras notificar al sistema que debe enviar
el mensaje. Los datos del mensaje no están necesariamente fuera del buffer del
mensaje, por lo que es posible incurrir en error si se sobreescriben los datos.
68
Un recibo no bloqueante es ejecutado cuando un proceso lo alcanza, sin esperar
el envío. Puede volver inmediatamente tras notificar al sistema que hay un
mensaje que se debe recibir. El mensaje puede que no haya llegado aún, puede
estar todavía en transito o puede no haber sido enviado aún.
69
3.2 PVM
PVM es un conjunto de herramientas y librerías que emulan un entorno de
propósito general compuesto de nodos interconectados de distintas arquitecturas. El
objetivo es conseguir que ese conjunto de nodos pueda ser usado de forma colaborativa
para el procesamiento paralelo.
El modelo en el que se basa PVM es dividir las aplicaciones en distintas tareas

(igual que ocurre con openMosix). Son los procesos los que se dividen por las máquinas
para aprovechar todos los recursos. Cada tarea es responsable de una parte de la carga
que conlleva esa aplicacion. PVM soporta tanto paralelismo en datos, como funcional o
una mezcla de ambos.
PVM permite que las tareas se comuniquen y sincronicen con las demás tareas
de la máquina virtual, enviando y recibiendo mensajes, muchas tareas de una aplicación
puedan cooperar para resolver un problema en paralelo. Cada tarea puede enviar un
mensaje a cualquiera de las otras tareas, sin límite de tamaño ni de número de mensajes.
El sistema PVM se compone de dos partes. La primera es un demonio, llamado

pvmd que residen en todas los nodos que forman parte de la máquina virtual. Cuando un
usuario quiere ejecutar una aplicación PVM, primero crea una máquina virtual para
arrancar PVM. Entonces se puede ejecutar la aplicación PVM en cualquiera de los
nodos. Muchos usuarios pueden configurar varias máquinas virtuales aunque se
mezclen unas con las otras y se pueden ejecutar varias aplicaciones PVM
simultáneamente. Cada demonio es responsable de todas las aplicaciones que se
ejecutan en su nodo.
Asíel control está totalmente distribuido excepto por un demonio maestro, que es
el primero que se ejecuto a mano por el usuario, los demás nodos fueron iniciados por el
maestro y son esclavos. En todo momento siempre hay un pvmd maestro. Por tanto la
máquina virtual mínima es de un miembro, el maestro.
La segunda parte del sistema es la librería de PVM. Contiene un repertorio de

primitivas que son necesarias para la cooperación entre los procesos o threads de una
aplicación. Esta librería contiene rutinas para inicialización y terminación de tareas,
envío y recepción de mensajes, coordinar y sincronizar tareas, broadcast, modificar la
máquina virtual.
Cuando un usuario define un conjunto de nodos, PVM abstrae toda la

complejidad que tenga el sistema y toda esa complejidad se ve como un gran
computador de memoria distribuida llamada máquina virtual. Esta máquina virtual es
creada por el usuario cuando se comienza la operación. Es un conjunto de nodos
elegidos por el usuario. En cualquier momento durante la operación puede elegir nuevos
nodos para la máquina virtual. Esto puede ser de gran ayuda para mejorar la tolerancia a
fallos pues se tiene unos cuantos nodos de reserva (PVM no tiene migración) para si
alguno de los nodos fallara. O si se ve que un conjunto de nodos de una determinada red
están fallando se pueden habilitar nodos de otra red para solucionarlo. Para conseguir
abstraer toda la complejidad de las diferentes configuraciones, soporta la
heterogeneidad de un sistema a tres niveles:
70
• Aplicaciones: las subtareas pueden estar hechas para aprovechar las
arquitecturas sobre la que funcionan. Por tanto como se puede elegir en que
conjunto de nodos se ejecutarán unas tareas específicas, podemos hacer nuestras
aplicaciones con la arquitectura al máximo por lo que se puede optimizar y hacer
que funcionen aplicaciones hechas para arquitecturas específicas con PVM.
• Máquinas: nodos con distintos formatos de datos están soportados, incluyendo
arquitecturas secuenciales, vectoriales, SMP. Abstrae little endian y big endian.
• Redes: la máquina virtual puede ser interconectada gracias a distintas
tecnologías de red. Para PVM, bajo él existe una red punto a punto, no fiable y
no secuencial. Esto abstrae cualquier tecnología de red. Utiliza UDP y
implementa toda la confiabilidad y todas las demás operaciones como broadcast
en la propia librería PVM.
Tiene un conjunto de interfaces que está basado en la observación de las

necesidades de la mayoría de las aplicaciones, que están escritas en C y Fortran. Los
enlaces para C y C++ para la librería PVM están implementados como funciones,
siguiendo las reglas usadas por la mayoría de los sistemas que usan C, incluyendo los
sistemas operativos tipo UNIX. Los enlaces para Fortran están implementados como
subrutinas más que funciones.
Todas las tareas están identificadas con un único identificador de tarea TID
(Task IDentifier). Los mensajes son enviados y recibidos por TIDs. Son únicos en toda
la máquina virtual y están determinados por el pvmd local y no se pueden elegir por el
usuario. Varias funciones devuelven estos TIDs (pvm_mytid(), pvm_parent(), etc.) para
permitir que las aplicaciones de los usuarios conozcan datos de las otras tareas. Existen
grupos nombrados por los usuarios, que son agrupaciones lógicas de tareas. Cuando una
tarea se une al grupo, a ésta se le asigna un único número dentro de ese grupo. Estos
números empiezan en 0 y hasta el número de tareas que disponga el grupo. Cualquier
tarea puede unirse o dejar cualquier grupo en cualquier momento sin tener que informar
a ninguna otra tarea del grupo. Los grupos se pueden superponer y las tareas pueden
enviar mensajes multicast a grupos de los que no son miembro.
Cuando una tarea se quiere comunicar con otra ocurren una serie de cosas, los
datos que la tarea ha enviado con una operación send, son transferidos a su demonio
local quien decodifica el nodo de destino y transfiere los datos al demonio destino. Este
demonio decodifica la tarea destino y le entrega los datos. Este protocolo necesita 3
transferencias de datos de las cuales solamente una es sobre la red. También se puede
elegir una política de encaminado directo (dependiente de los recursos disponibles). En
esta política tras la primera comunicación entre dos tareas los datos sobre el camino a
seguir por los datos son guardados en una caché local. Las siguientes llamadas son
hechas directamente gracias a esta información. De esta manera las transferencias se
reducen a una transferencia sobre la red. Para comunicar entre sé los demonios pvmd se
usa UDP pues es mucho más sencillo, sólo consume un descriptor de fichero, y con un
simple socket UDP se puede comunicar a todos los demás demonios. Además es muy
sencillo colocar temporizadores sobre UDP para detectar fallos de nodo, pvmd o red. La
comunicación entre las tareas y los pvmd es mediante TCP puesto que se necesita tener
la seguridad de que los datos llegarán. En el caso de que sólo se haga una trasferencia
ésta es TCP por lo que hay que establecer la conexión primero por lo que realmente
tampoco es tan beneficioso. En la siguiente figura se puede observar como los distintos
métodos de comunicación de PVM.
71
Figura 2 Clusters HP. Comunicaciones en PVM
Cada nodo tiene una estructura llamada host table. Esta tabla tiene una entrada
(host descriptor) por cada nodo de la máquina virtual. El descriptor del nodo mantiene la
información de la configuración del host, las colas de paquetes y los buffer de mensajes.
Inicialmente la tabla sólo tiene la entrada del nodo maestro. Cuando un nuevo esclavo
es incluido a la máquina virtual, la tabla del nodo maestro es actualizada para añadir al
nuevo esclavo. Entonces esta nueva información es enviada por broadcast a todos los
nodos que pertenezcan a la máquina virtual. De esta manera se actualizan todas las
tablas y se mantienen consistentes.
Las aplicaciones pueden ver el hardware como una colección de elementos de

proceso virtuales sin atributos o pueden intentar explotar las capacidades de máquinas
específicas, intentando posicionar ciertas tareas en los nodos más apropiados para
ejecutarlas.
Hemos querido dar un rápido repaso a PVM para poder decir qué es lo que no
nos gusta de su aproximación y porque pensamos que openMosix es superior. Sabemos
que la explicación que hemos dado está lejos de mostrar todo el universo de PVM pero
pensamos que puede dar una idea de cómo funciona.
PVM no tiene requisa de procesos dinámico, esto quiere decir que una vez que
un proceso empieza en una determinada máquina seguirá en ella hasta que se muera.
Esto tiene graves inconvenientes como explicamos en las características de asignar
estáticnte un proceso a un nodo en concreto. Hay que tener en cuenta que las cargas
suelen variar y que, a no ser que todos los procesos que se estén ejecutando sean muy
homogéneos entre sí, se está descompensando el cluster. Por lo tanto tenemos unos
nodos más cargados que otros y seguramente unos nodos terminen su ejecución antes
que otros, con lo que se podrían tener nodos muy cargados mientras otros nodos están
libres. Esto lleva a una pérdida de rendimiento general.
Otro problema de PVM es que está implementado a nivel de usuario, esto no es

malo de por sí pero teniendo en cuenta el tipo de operaciones que lleva, sílo es puesto
que son operaciones de bastante bajo nivel como puedan ser paso de mensajes entre
aplicaciones y la capa sobre UDP. Esto añade complejidad y latencia a las
72
comunicaciones que se tienen que producir sobre las comunicaciones del kernel. Por lo
que es una capa de software extra que carga bastante.
Se necesita un conocimiento amplio del sistema, tanto los programadores como

los administradores tienen que conocer el sistema para sacar el máximo rendimiento de
él. No existe un programa que se ejecute de forma ideal en cualquier arquitectura ni
configuración de cluster. Por lo tanto para paralelizar correcta y eficazmente se necesita
que los programadores y administradores conozcan a fondo el sistema.
El paralelismo es explícito, esto quiere decir que se programa de forma especial

para poder usar las características especiales de PVM. Los programas deben ser
reescritos. Si a esto se unimos que, como se necesita que los desarrolladores estén bien
formados por lo explicado en el punto anterior y que conozcan además PVM, se puede
decir que migrar una aplicación a un sistema PVM no es nada económico.
73
3.3 MPI
MPI es una especificación estándar para una librería de funciones de paso de
mensajes. MPI fue desarrollado por el MPI Forum, un consorcio de vendedores de
ordenadores paralelos, escritores de librerías y especialistas en aplicaciones.
Consigue portabilidad proveyendo una librería de paso de mensajes estándar

independiente de la plataforma y de dominio público. La especificación de esta librería
está en una forma independiente del lenguaje y proporciona funciones para ser usadas
con C y Fortran. Abstrae los sistemas operativos y el hardware. Hay implementaciones
MPI en casi todas las máquinas y sistemas operativos. Esto significa que un programa
paralelo escrito en C o Fortran usando MPI para el paso de mensajes, puede funcionar
sin cambios en una gran variedad de hardware y sistemas operativos. Por estas razones
MPI ha ganado gran aceptación dentro el mundillo de la computación paralela.
MPI tiene que ser implementado sobre un entorno que se preocupe del manejo
de los procesos y la E/S por ejemplo, puesto que MPI sólo se ocupa de la capa de
comunicación por paso de mensajes. Necesita un ambiente de programación paralelo
nativo.
Todos los procesos son creados cuando se carga el programa paralelo y están
vivos hasta que el programa termina. Hay un grupo de procesos por defecto que consiste
en todos esos procesos, identificado por MPI_COMM_WORLD.
Los procesos MPI son procesos como se han considerado tradicionalmente, del
tipo pesados, cada proceso tiene su propio espacio de direcciones, por lo que otros
procesos no pueden acceder directamente al las variables del espacio de direcciones de
otro proceso. La intercomunicación de procesos se hace vía paso de mensajes.
Las desventajas de MPI son las mismas que se han citado en PVM, realmente
son desventajas del modelo de paso de mensajes y de la implementación en espacio de
usuario. Además aunque es un estándar y debería tener un API estándar, cada una de las
implementaciones varía, no en las llamadas sino en el número de llamadas
implementadas (MPI tiene unas 200 llamadas). Esto hace que en la práctica los
diseñadores del sistema y los programadores tengan que conocer el sistema particular de
MPI para sacar el máximo rendimiento. Además como sólo especifica el método de
paso de mensajes, el resto del entorno puede ser totalmente distinto en cada
implementación con lo que otra vez se impide esa portabilidad que teóricamente tiene.
Existen implementaciones fuera del estándar que son tolerantes a fallos, no son
versiones demasiado populares porque causan mucha sobrecarga.
74
4. TEORÍA DE LA SUPERCOMPUTACIÓN
4.1 Visión histórica
En lo que se refiere a la capacidad de procesamiento, existen varias alternativas
para el futuro. Actualmente la capacidad de integración y el abaratamiento de las
tecnologías permiten que casi cualquier empresa pueda contar con una capacidad de
cómputo antes inimaginable para las tareas que necesita. Se prevé que la capacidad de
integración llegue a un techo tecnológico, en el cual se necesite un nuevo paradigma
para poder seguir incrementando la capacidad de procesamiento de las máquinas. Uno
de esos paradigmas es el procesamiento paralelo.
Por procesamiento paralelo se entiende la capacidad de utilizar varios elementos

de proceso para ejecutar diferentes partes del mismo programa simultáneamente.
La resolución de problemas mediante procesamiento paralelo no es nueva, está

basada en el viejo y conocido método de divide y vencerás utilizado para resolver
problemas de carácter computacional.
Una analogía para explicar las ventajas y límites de este método es la siguiente:
se ha decidido ordenar una biblioteca mediante el criterio tipo y autor. Una solución
sería separar todos los libros por su tipo en pilas y luego que una sola persona ordenara
cada uno de esas pilas por el nombre de su autor. En la resolución paralela del problema
se añadiría una segunda persona, de manera que cada persona catalogase según el tipo la
mitad de la biblioteca, tardándose la mitad de tiempo en esta fase, y luego que cada uno
fuese colocando las pilas de los tipos por autor. La solución paralela obtiene como
ventaja, en este caso, la reducción del tiempo a la mitad para solucionar el problema.
¿Qué sucedería si se añadiesen más personas dedicadas a catalogar la biblioteca? En un
principio, cuantas más personas trabajen en el proceso, antes acabará éste, es decir,
existe una relación lineal entre el tiempo de resolución del problema y el número de
personas que trabajan en la ordenación de la biblioteca. Pero por otro lado, parece
estúpido contratar a 200 personas para colocar una biblioteca de 200 libros.
Esta analogía muestra las ventajas que puede tener la resolución de un problema
mediante el procesamiento paralelo, pero también muestra los límites en la resolución.
Relativo al mundo de la tecnología y al campo de los procesadores en general, se
descubrió que las arquitecturas paralelas podían solventar de manera más rápida cierto
tipo de problemas. Desde 1955 personas como Gene Amdahl han investigado en el
campo de arquitecturas paralelas obteniendo aquellos parámetros que optimizaban las
arquitecturas así como aquellos que hacían que la relación coste-rendimiento aumentase.
Empresas como IBM, DEC y desde luego muchas otras organizaciones como el MIT, se
llevan interesando en la computación paralela desde las décadas de los 50-60, y de
hecho siguen investigando y obteniendo resultados en la actualidad, hasta el punto en
que prácticamente todos los ordenadores que existen actualmente en el mercado
explotan de una u otra manera soluciones paralelas.
En la década de los 80, la compartición de recursos mediante redes de

computadores hizo posible un nuevo planteamiento para aprovechar no solo recursos
como capacidad de almacenamiento o capacidad de impresión, sino para utilizar ciclos
75
de CPU de otras máquinas conectadas a la red (los llamados multicomputadores). En los
70 y a primeros de los 80, personas como Bruce J.Nelson de Xerox expusieron trabajos
teóricos de cómo se podía utilizar mediante software esta capacidad de procesamiento
paralelo que hasta ahora estaba relegada principalmente al hardware, limitándose el
software a aprovecharlo mediante técnicas de programación explícita. En 1985, Intel
produjo el primer iPSC/1. Este multicomputador era una combinación de muchos 80286
conectados en una topología hipercubo a través de controladoras ethernet, mostrando
que era real y posible utilizar este tipo de redes para explotar los sistemas paralelos.
En la década de los 90, el uso de las redes de computadores se extendió de

manera exagerada en comparación a otros campos como el de sistemas operativos o el
de arquitectura de computadores.
Otro concepto importante que no se debe confundir con el de paralelo es el

término concurrente. Edger Dijstra en 1965 describió el problema de las regiones
críticas en las arquitecturas paralelas y como solucionarlo mediante semáforos
(solucionado en 1968), pero fue en 1975 cuando introdujo el concepto de concurrencia,
basándose en sus trabajos anteriores. Actualmente la implementación de concurrencia la
realizan muchos lenguajes de programación.
Si por paralelismo se entienden procesos que se ejecutan en varios elementos de

proceso para llegar la resolución conjunta de un problema, por concurrencia se entiende
procesos que se ejecutan de manera independiente en un mismo procesador, para la
resolución de uno o varios problemas (multitarea). Un ejemplo de concurrencia lo
tenemos en prácticamente todos los sistemas operativos que se utilizan en la actualidad,
puesto que comparten el mismo procesador para prestar un único servicio al usuario.
Otro ejemplo sería la utilización de un programa concurrente en el cual dos

procesos solucionen un problema único. El uso de concurrencia y de paralelismos
conlleva principalmente un problema de comunicación entre los elementos de proceso o
los procesos entre sí para que la resolución de un problema mediante estos paradigmas
sea viable.
76
4.2 Problemas que se pueden resolver con sistemas paralelo
Se pueden distinguir dos épocas en las cuales los problemas que han provocado
la aparición de sistemas paralelos y distribuidos han sido diferentes:
• Por un lado las décadas de los 60-70-80, en las cuales el máximo problema era
optimizar la capacidad de procesamiento, y de esta manera aumentar el
rendimiento de las máquinas y la producción de éstas.
• Por otro lado, desde la década de los 90 hasta la actualidad, donde los problemas
han aumentado: a los que existían en las décadas anteriores se han sumado los
provocados por la red Internet y el fenómeno de la nueva economía.
Este último punto es sencillo de entender: la nueva economía está formada por
comercios a imagen y semejanza de los de la tradicional, pero con las ventajas aportadas
por el mundo de las máquinas. Son nuevas tiendas y negocios que funcionan 24 horas al
día 7 días a la semana, que no necesitan de personal, excepto técnico, para su puesta en
marcha y al que se accede a través de Internet. Con este nuevo tipo de negocio, muchas
empresas hacen inversiones en equipo y personal técnico, para ofrecer a nivel mundial
soluciones que de otra manera podrían ser inviables por precio, tiempo u organización.
Las empresas exigen a estas nuevas tecnologías, lo mismo que han exigido siempre a las
antiguas:
• Máximo rendimiento, mínimo coste. Intentando hacer lo imposible por que las
inversiones realizadas sean amortizadas sin desperdiciar ningún recurso.
• Máximo aprovechamiento de los recursos existentes.
• Disponibilidad máxima. En en un negocio tradicional si uno de los trabajadores
se pone enfermo, se intenta cubrir esta vacante con otro trabajador que satisfaga
el trabajo. Con las nuevas tecnologías sucede lo mismo, se han creado infinidad
de soluciones para evitar cierres de negocios temporales mediante UPS (para las
caídas de luz), fuentes redundantes, equipos redundantes y otras muchas técnicas
dedicadas a cubrir por completo el término alta disponibilidad.
• Confiabilidad máxima. Sabiendo que el sistema se va a comportar de la manera
que se espera de él.
• Adaptación a los cambios. Tanto en forma de carga para el sistema como en
forma de nuevo planteamiento del negocio. El sistema debe ser flexible y
escalable.
Este último punto es importante por motivos claramente económicos (no solo a
nivel de empresa) y supone un gran reto en el diseño de sistemas para que estos puedan
adaptarse de manera eficiente a nuevas exigencias. Hablamos de un término muy
importante que se utilizará a lo largo de todo el documento, la escalabilidad. Véase en
un ejemplo. Una empresa quiere poner un negocio en Internet, contratan un asesor
técnico que les explica que para lo que ellos quieren hacer necesitarán una capacidad de
proceso equivalente al número máximo de clientes potenciales que creen que sus
productos pueden acaparar en el mercado. La empresa compra los ordenadores que
poseen dicha capacidad de proceso, sabiendo que éstos cumplirán con las expectativas
iniciales planteadas, de manera que todos los recursos invertidos estarán siendo
utilizados de manera continua.
77
Pasado un tiempo de continua prosperidad empresarial, la empresa se da cuenta
de que el sistema se quedó pequeño para el volumen de ventas, vuelven a contactar con
el asesor técnico y este les explica que la única opción es comprar un segundo sistema,
esta vez el doble de potente (y varias veces más costoso).
La empresa decide negarse porque la inversión realizada en el primer equipo aún

está por amortizarse, además del gasto inútil que habrían realizado en el primer equipo,
que en un principio quedaría inoperativo después del cambio.
He aquí que la competencia decide invertir en otro sistema más potente y mejor
diseñado (no necesariamente más caro), con lo que da mejor servicio a los clientes y en
poco tiempo provoca la quiebra de la primera. Ésta pues decide intentar dedicarse a otro
sector, en el cual necesitará nuevas tecnologías. Llaman a otro asesor técnico (esta vez
mucho más listo que el anterior), que les explica como podrían reutilizar componentes
del anterior sistema ahorrándose la inversión inicial para el nuevo proyecto.
Este ejemplo, algo drástico, refleja la realidad de muchas empresas que han
quebrado por su popularidad y por su incapacidad de crecimiento. En cualquier caso, no
es más que un ejemplo para introducir un concepto de escalabilidad. Ilustra la ventajas
de sistemas fácilmente escalables como pueden ser cluster con respecto a otros, no tan
fácilmente escalables, como pueden ser mainframes y otros supercomputadores
vectoriales.
La definición de escalabilidad más apropiada a los términos que se referirá en

este documento es: un sistema se dice escalable si es capaz de escalar, es decir, de
incrementar sus recursos y rendimiento a las necesidades solicitadas de manera efectiva
o, en el caso de scale down, reducir costes.
Aunque la mayoría de las veces se habla de escalar hacia arriba, es decir de

hacer el sistema más grande, no es siempre necesario. Muchas veces interesa hacer el
sistema más pequeño pudiendo reutilizar los componentes excluidos. Que un sistema
sea escalable implica:
1. Funcionalidad y rendimiento. Si un sistema escala, mejora su rendimiento, de

manera que de forma ideal, al aumentar en N el número de elementos de proceso
del sistema éste debe aumentar en N el rendimiento.
2. Escalabilidad en coste. De lo anterior se deduce que idealmente el coste de la
escalabilidad de 1 a N en un sistema lleve un coste de N por el coste de un
procesador. La escalabilidad perfecta es lineal, si una potencia 10 veces superior
nos cuesta 15 veces más, el sistema no está escalando bien.
3. Compatibilidad de componentes. De manera que la inclusión o exclusión de
componentes en el sistema no suponga la inutilización, infrautilización o coste
adicional en los componentes.
Con todo esto queda patente que tener un alto factor de escalabilidad es un
requisito interesante para cualquier sistema.
También es importante hacer notar que los sistemas distribuidos (y otros

sistemas paralelos) son, por ahora, los sistemas que más se acercan a la escalabilidad
lineal. En el ejemplo anterior (supercomputador, mainframe) realmente un equipo el
78
doble de potente no vale el doble sino varias veces más; en cambio en sistemas
distribuidos al doble de precio se consigue mejor relación. Esta relación de precios
puede verse en los precios de microprocesadores: costar el doble no significa el doble de
potencia, sino que los precios siguen una curva exponencial según aumentan sus
prestaciones.
79
4.3 Soluciones actuales que se dan a dichos problemas
Respecto a la evolución de los sistemas y con objeto de obtener mayor capacidad
de procesamiento, el paralelismo a todos los niveles ha sido una de las soluciones más
utilizadas, de hecho en la actualidad, la práctica totalidad de los ordenadores y
microprocesadores explotan de una manera u otra tecnologías paralelas, ya sea en
multiprocesadores, en multicomputadores o en procesadores independientes MMX en
los procesadores Intel, 3DNow! en los AMD, Altivec en la arquitectura PPC, entre otras.
Respecto a los requisitos de alta disponibilidad que requieren las soluciones

actuales se proponen soluciones como UPS, generadores redundantes, hardware
redundante, soluciones software de alta disponibilidad como la tecnología HA-Linux u
otros clusters de este tipo de otras compañías como Piranha de RedHat, Va-Linux,
Compaq, Sun... prácticamente todas las grandes marcas de ordenadores han sacado su
sistema cluster específico al mercado.
Otra solución existente es el balanceo de carga. Este tipo de cluster es muy

utilizado en conjunción con los de alta disponibilidad, sobre todo en las conexiones de
servidores a Internet, de manera que varios servidores dan un único servicio de manera
transparente a sus usuarios.
Otro balanceo distinto, relativo a los clusters de alto rendimiento y a la

migración de procesos, es el ofrecido por los llamados multicomputadores, o los
sistemas distribuidos. En general estos son los sistemas que se acercan más al concepto
de sistema operativo distribuido del que se hablará más adelante. Clusters o sistemas de
este tipo son openMosix, Beowulf y otros en el mundo del software libre y otros tantos
en el del software propietario. A otra escala existen los paquetes software que permiten
construir grids con todo el tratamiento de certificados y permisos de usuario necesarios.
Estos sistemas no se tratarán en este manual.
Como se puede ver existen una infinidad de soluciones distintas para cada
sección de problema concreto, no obstante no existe un sistema de carácter general que
resuelva todos los problemas planteados debido a las dispares finalidades con que se
diseñan.
80
81
CAPITULO ii
GARCÍA, OSCAR
“Si la explicación del universo parte del sistema binario, quiere decir que dios es un
programador y el universo un sistema operativo”
82
5. SISTEMAS OPERATIVOS
5.1 Introducción
Combinan aspectos referentes a distintas áreas relacionadas con los
computadores: lenguajes, hardware, estructuras de datos, algoritmos, etc. Actúan como
coordinadores entre los usuarios y los programas resolviendo posibles conflictos. Hacen
que los computadores parezcan ser más de lo que son en realidad. Son sistemas software
grandes y complejos, por lo tanto es necesario abordarlos de una forma estructurada.
Las ideas utilizadas son aplicables a otras parcelas del software.
5.2 Historia
Para tratar de comprender los requisitos de un Sistema Operativo y el significado

de las principales características de un Sistema Operativo contemporáneo, es útil
considerar como han ido evolucionando éstos con el tiempo.
En los 40's, se introducen los programas bit a bit, por medio de interruptores
mecánicos y después se introdujo el lenguaje máquina que trabajaba por tarjetas
perforadas.
Con las primeras computadoras, desde finales de los años 40 hasta la mitad de
los años 50, el programador interactuaba de manera directa con el hardware de la
computadora, no existía realmente un Sistema Operativo; las primeras computadoras
utilizaban bulbos, la entrada de datos y los programas se realizaban a través del lenguaje
máquina (bits) o a través de interruptores.
Durante los años 50's y 60's.- A principio de los 50's, la compañía General's
Motors implanto el primer sistema operativo para su IBM 170. Empiezan a surgir las
tarjetas perforadas las cuales permiten que los usuarios (que en ese tiempo eran
programadores, diseñadores, capturistas, etc.), se encarguen de modificar sus programas.
Establecían o apartaban tiempo, metían o introducían sus programas, corregían y
depuraban sus programas en su tiempo. A esto se le llamaba trabajo en serie. Todo esto
se traducía en pérdida de tiempo y tiempos de programas excesivos.
En los años 60's y 70's se genera el circuito integrado, se organizan los trabajos y
se generan los procesos Batch (por lotes), lo cual consiste en determinar los trabajos
comunes y realizarlos todos juntos de una sola vez. En esta época surgen las unidades
de cinta y el cargador de programas, el cual se considera como el primer tipo de Sistema
Operativo.
En los 80's, inició el auge de la INTERNET en los Estados Unidos de América.

A finales de los años 80's comienza el gran auge y evolución de los Sistemas Operativos.
Se descubre el concepto de multiprogramación que consiste en tener cargados en
memoria a varios trabajos al mismo tiempo, tema principal de los Sistemas Operativos
actuales.
83
Los 90's y el futuro, entramos a la era de la computación distribuida y del
multiprocesamiento a través de múltiples redes de computadoras, aprovechando el ciclo
del procesador.
Se tendrá una configuración dinámica con un reconocimiento inmediato de
dispositivos y software que se añada o elimine de las redes a través de procesos de
registro y localizadores.
La conectividad se facilita gracias a estándares y protocolos de sistemas abiertos

por organizaciones como la Org. Intern. de normas, fundación de software abierto, todo
estará mas controlado por los protocolos de comunicación OSI y por la red de servicios
digital ISDN.
Se ha desarrollado otra versión, la cual se ha hecho en base a etapas o

generaciones:
1a. Etapa (1945-1955) : Bulbos y conexiones.
Figura 3 Bulbos y conexiones 1
Figura 4 Bulbos y conexiones 2
Después de los infructuosos esfuerzos de Babbage, hubo poco progreso en la

construcción de las computadoras digitales, hasta la Segunda Guerra Mundial. A mitad
de la década de los 40's, Howard Aiken (Harvard), John Von Newman (Instituto de
Estudios Avanzados, Princeton), J. Prespe R. Eckert y Williams Mauchley (Universidad
de Pennsylvania), así como Conrad Zuse (Alemania), entre otros lograron construir
máquinas de cálculo mediante bulbos. Estas máquinas eran enormes y llenaban cuartos
completos con decenas de miles de bulbos, pero eran mucho más lentas que la
computadora casera más económica en nuestros días.
Toda la programación se llevaba a cabo en lenguaje de máquina absoluto y con

frecuencia se utilizaban conexiones para controlar las funciones básicas de la máquina.
Los lenguajes de programación eran desconocidos (incluso el lenguaje ensamblador).
No se oía de los Sistemas Operativos el modo usual de operación consistía en que el
programador reservaba cierto período en una hoja de reservación pegada a la pared, iba
al cuarto de la máquina, insertaba su conexión a la computadora y pasaba unas horas
esperando que ninguno de los 20,000 o más bulbos se quemara durante la ejecución. La
84
inmensa mayoría de los problemas eran cálculos numéricos directos, por ejemplo, el
cálculo de valores para tablas de senos y cosenos.
A principio de la década de los 50's la rutina mejoro un poco con la introducción

de las tarjetas perforadas. Fue entonces posible escribir los programas y leerlas en vez
de insertar conexiones, por lo demás el proceso era el mismo.
2a. Etapa. (1955-1965) : Transistores y Sistemas de Procesamiento por lotes.
Figura 5 Procesamiento por lotes
La introducción del transistor a mediados de los años 50's modificó en forma

radical el panorama. Las computadoras se volvieron confiables de forma que podían
fabricarse y venderse a clientes, con la esperanza de que ellas continuaran funcionando
lo suficiente como para realizar un trabajo en forma.
Dado el alto costo del equipo, no debe sorprender el hecho de que las personas
buscaron en forma por demás rápidas vías para reducir el tiempo invertido. La solución
que, por lo general se adoptó, fue la del sistema de procesamiento por lotes.
3ra Etapa (1965-1980) : Circuitos integrados y multiprogramación.
Figura 6 Circuitos Integrados I
Figura 7 Circuitos Integrados II
La 360 de IBM fue la primera línea principal de computadoras que utilizó los
circuitos integrados, lo que proporcionó una gran ventaja en el precio y desempeño con
respecto a las máquinas de la segunda generación, construidas a partir de transistores
individuales. Se trabajo con un sistema operativo enorme y extraordinariamente
complejo. A pesar de su enorme tamaño y sus problemas el sistema operativo de la línea
IBM 360 y los sistemas operativos similares de esta generación producidos por otros
fabricantes de computadoras realmente pudieron satisfacer, en forma razonable a la
85
mayoría de sus clientes. También popularizaron varias técnicas fundamentales, ausentes
de los sistemas operativos de la segunda generación, de las cuales la más importante era
la de multiprogramación.
Otra característica era la capacidad de leer trabajos de las tarjetas al disco, tan
pronto como llegara al cuarto de cómputo. Así, siempre que concluyera un trabajo el
sistema operativo podía cargar un nuevo trabajo del disco en la partición que quedara
desocupada y ejecutarlo.
4ta Etapa (1980-Actualidad): Computadoras personales.
Un interesante desarrollo que comenzó a llevarse a cabo a mediados de la década

de los ochenta ha sido el crecimiento de las redes de computadoras personales, con
sistemas operativos de red y sistemas operativos distribuidos.
En los sistemas operativos de red, los usuarios están conscientes de la existencia

de varias computadoras y pueden conectarse con máquinas remotas y copiar archivos de
una máquina a otra. Cada máquina ejecuta su propio sistema operativo local y tiene su
propio usuario.
Por el contrario, un sistema operativo distribuido es aquél que aparece ante sus
usuarios como un sistema tradicional de un solo procesador, aun cuando esté compuesto
por varios procesadores. En un sistema distribuido verdadero, los usuarios no deben ser
conscientes del lugar donde su programa se ejecute o de lugar donde se encuentren sus
archivos; eso debe ser manejado en forma automática y eficaz por el sistema operativo.
86
5.3 ¿Que es un Sistema Operativo?
Un SO es un conjunto de programas que por medio de abstracciones ponen el

hardware del ordenador, de modo seguro, a disposición del usuario.
H. Deitel: un SO es un programa que actúa como interfaz entre el usuario de un

ordenador y el HW del mismo, ofreciendo el entorno necesario para que el usuario
pueda ejecutar programas.
Katzan: conjunto de programas y datos que ayudan a crear otros programas y a

controlar su ejecución.
Madnik y Donovan: conjunto de programas que gestionan los recursos del sistema,
optimizan su uso y resuelven conflictos.
5.4 Funciones
Un Sistema Operativo es un administrador de recursos y una interfaz con los
programas, los usuarios y el HW.
Sus funciones son:

• Compartir el hardware entre usuarios
• Facilitar la entrada salida
• Planificar recursos entre usuarios
• Definir la “interfaz de usuario”
• Permitir a los usuarios compartir los datos
• Recuperarse de los errores
Los recursos claves que un SO administra son:

• los procesadores y los dispositivos de E/S
• el almacenamiento y los datos
5.5 Tipos de sistemas operativos por su estructura

a) Monolíticos
• Todos los componentes en un solo programa
• Un solo espacio de direcciones
• Un solo flujo de control (no hay concurrencia interna)
• El sistema operativo se ejecuta en modo privilegiado; las aplicaciones en modo
usuario (restringido)
• Ejemplos: MS-DOS, UNIX
• Son complicados de modificar
b) A capas
• Jerarquía de capas, cada una con una interfaz clara y que sólo usa los servicios
de la capa inferior
• Ejemplos THE (Dijkstra 1968), OS/2 (Deitel, 1994)
c) Máquinas virtuales
87
• Se proporciona un modelo de una máquina sobre la que se pueden ejecutar
programas
• Esta máquina se puede replicar por tiempo compartido
• Se pueden ejecutar sistemas operativos completos sobre la máquina virtual
• Ejemplos:
o JVM (Java virtual machine)
o VM-Ware (emula un PC sobre Windows o Linux)
o RT-Linux
d) Modelo cliente-servidor
• Se mueven parte de los servicios del sistema operativo a una capa superior:
servidores
• Los programas de aplicación son clientes
• Se comunican a través de un micro-núcleo (privilegiado)
Figura 8 Sistema Operativo

Los sistemas cliente-servidor
• Son más flexibles
• Pero menos eficientes
• Ejemplo: Minix (Tanenbaum 1998), Mach (Accetta, 1986)
• Windows NT/2000/XP es mezcla de un sistema monolítico (por eficiencia) y cliente-
servidor (por flexibilidad).
5.6 Tipos de sistemas operativos por sus servicios

Por el número de usuarios
• sistemas empotrados:
o sin usuarios directos
o forman parte de un sistema mayor
o ejemplo: controlador de un televisor)
• sistemas monousuario:
o un solo usuario ejemplo: Windows 98
• sistemas multiusuario
o muchos usuarios
o presenta protección entre usuarios
o ejemplos: Unix, Windows XP profesional
Por el nivel de protección (se protegen datos de una aplicación y del sistema operativo
frente a otras aplicaciones)
• protegidos (Unix, Windows XP profesional)
• semi-protegidos (Windows 98)
• no protegidos (Windows 3.1)
88
Por la capacidad de concurrencia
• monoproceso y monotarea: un solo programa con un solo flujo de control (MS-
DOS)
• multitarea: capaz de ejecutar un sólo programa, pero varias de sus partes a la vez
(MaRTE OS)
• multiproceso: capaz de ejecutar varios programas a la vez
5.7 Características
En general, se puede decir que un Sistema Operativo tiene las siguientes

características:
• Conveniencia. Un Sistema Operativo hace más conveniente el uso de una

computadora.
• Eficiencia. Un Sistema Operativo permite que los recursos de la computadora se
usen de la manera más eficiente posible.
• Habilidad para evolucionar. Un Sistema Operativo deberá construirse de manera
que permita el desarrollo, prueba o introducción efectiva de nuevas funciones
del sistema sin interferir con el servicio.
• Encargado de administrar el hardware. El Sistema Operativo se encarga de
manejar de una mejor manera los recursos de la computadora en cuanto a
hardware se refiere, esto es, asignar a cada proceso una parte del procesador para
poder compartir los recursos.
• Relacionar dispositivos (gestionar a través del kernel). El Sistema Operativo se
debe encargar de comunicar a los dispositivos periféricos, cuando el usuario así
lo requiera.
• Organizar datos para acceso rápido y seguro.
• Manejar las comunicaciones en red. El Sistema Operativo permite al usuario
manejar con alta facilidad todo lo referente a la instalación y uso de las redes de
computadoras.
• Procesamiento por bytes de flujo a través del bus de datos.
• Facilitar las entradas y salidas. Un Sistema Operativo debe hacerle fácil al
usuario el acceso y manejo de los dispositivos de Entrada/Salida de la
computadora.
• Técnicas de recuperación de errores.
• Evita que otros usuarios interfieran. El Sistema Operativo evita que los usuarios
se bloqueen entre ellos, informándoles si esa aplicación esta siendo ocupada por
otro usuario.
• Generación de estadísticas.
• Permite que se puedan compartir el hardware y los datos entre los usuarios.
El software de aplicación son programas que se utilizan para diseñar, tal como el
procesador de palabras, lenguajes de programación, hojas de cálculo, etc.
El software de base sirve para interactuar el usuario con la máquina, son un

conjunto de programas que facilitan el ambiente plataforma, y permite el diseño del
mismo.
El Software de base está compuesto por:
89
• Cargadores.
• Compiladores.
• Ensambladores.
• Macros.
6. DEBIAN GNU/LINUX
6.1 Introducción
90
6.1.1 ¿Qué es GNU/Linux?
Linux es un sistema operativo: un conjunto de programas que le permiten

interactuar con su ordenador y ejecutar otros programas.
Un sistema operativo consiste en varios programas fundamentales que necesita

el ordenador para poder comunicar y recibir instrucciones de los usuarios; tales como
leer y escribir datos en el disco duro, cintas, e impresoras; controlar el uso de la
memoria; y ejecutar otros programas. La parte más importante de un sistema operativo
es el núcleo. En un sistema GNU/Linux, Linux es el núcleo. El resto del sistema
consiste en otros programas, muchos de los cuales fueron escritos por o para el proyecto
GNU. Dado que el núcleo de Linux en sí mismo no forma un sistema operativo
funcional, preferimos utilizar el término “GNU/Linux” para referirnos a los sistemas
que la mayor parte de las personas llaman de manera informal “Linux”.
Linux está modelado como un sistema operativo tipo Unix. Desde sus
comienzos, Linux se diseñó para que fuera un sistema multi tarea y multi usuario. Estos
hechos son suficientes para diferenciar a Linux de otros sistemas operativos más
conocidos. Sin embargo, Linux es más diferente de lo que pueda imaginar. Nadie es
dueño de Linux, a diferencia de otros sistemas operativos. Gran parte de su desarrollo lo
realizan voluntarios de forma altruista.
En 1984 comenzó el desarrollo de lo que más tarde sería GNU/Linux cuando la

Free Software Foundation (Fundación de software libre, N. del t.) comenzó a desarrollar
un sistema operativo libre de tipo Unix, llamado GNU.
El proyecto GNU ha desarrollado un conjunto de herramientas de software libre

para ser utilizados por Unix™ y sistemas operativos tipo Unix como Linux. Estas
herramientas permiten a los usuarios desarrollar tareas que van desde las mundanas
(como copiar o eliminar ficheros del sistema) a las arcanas (como escribir y compilar
programas o hacer edición sofisticada en una gran variedad de formatos de documento).
Aunque hay muchos grupos e individuos que han contribuido a Linux, la Free
Software Foundation ha sido quien más ha contribuido. No sólo creó la mayor parte de
las herramientas que se utilizan en Linux sino también la filosofía y comunidad que
hizo que Linux fuera posible.
El núcleo Linux apareció por primera vez en 1991, cuando un estudiante de

informática finlandés llamado Linus Torvalds anunció en el grupo de noticias de
USENET comp.os.minix, una primera versión de un núcleo de reemplazo para Minix.
Para más referencias consulte la página de historia de Linux en Linux Internacional.
Linus Torvalds sigue coordinando el trabajo de varios cientos de desarrolladores

con la ayuda de algunas personas de confianza. Se puede encontrar un excelente
resumen semanal de las discusiones en la lista de correo linux-kernel en Kernel Traffic. Se
puede encontrar más información sobre la lista de correo linux-kernel en el documento
PUF de la lista de correo «linux-kernel».
91
Los usuarios de Linux tienen una gran libertad al elegir sus programas. Por
ejemplo, un usuario de Linux puede elegir entre docenas de distintos intérpretes de línea
de órdenes y entre distintos entornos de escritorio. Tantas opciones confunden a veces a
los usuarios de otros sistemas operativos que no están acostumbrados a poder modificar
el intérprete de línea de órdenes o el entorno de escritorio.
Es menos probable que un sistema Linux se colapse, además tiene mejor

capacidad para ejecutar múltiples programas al mismo tiempo y es más seguro que
muchos otros sistemas operativos. Debido a estas ventajas, Linux es el sistema
operativo que ha experimentado mayor crecimiento en el mercado de los servidores.
Últimamente, Linux está empezando a ser popular entre los usuarios domésticos y en
empresas.
6.1.2 ¿Qué es Debian?
Debian es una organización formada totalmente por voluntarios dedicada a

desarrollar software libre y promocionar los ideales de la Free Software Foundation. El
Proyecto Debian comenzó en 1993, cuando Ian Murdock hizo una invitación a todos los
desarrolladores de software a contribuir a una distribución completamente coherente
basada en el, entonces relativamente nuevo, núcleo Linux. Ese grupo relativamente
pequeño de entusiastas, al principio patrocinados por la Free Software Foundation e
influenciados por la filosofía GNU, ha crecido a lo largo de los años hasta convertirse
en una organización de alrededor de 900 desarrolladores Debian.
Los desarrolladores Debian están involucrados en una gran variedad de tareas,

incluyendo la administración del Web y FTP, diseño gráfico, análisis legal de licencias
de software, escribir documentación y, por supuesto, mantener paquetes de software.
Con el interés de comunicar nuestra filosofía y atraer desarrolladores que crean en

los principios que Debian protege, el Proyecto Debian ha publicado un número de
documentos que contienen nuestros valores y sirven como guías de lo que significa ser
un desarrollador Debian:
• El Contrato Social de Debian es una afirmación del compromiso de Debian con

la comunidad de Software Libre. Cualquiera que esté de acuerdo en acogerse al
Contrato Social puede convertirse en desarrollador. Cualquier desarrollador
puede introducir software nuevo en Debian — siempre que éste cumpla nuestro
criterio de software libre, y cumpla con nuestros estándares de calidad.
• El documento Directrices de Software Libre de Debian (DFSG) es un informe
claro y conciso de los criterios de Debian sobre el software libre. La DFSG es de
gran influencia en el movimiento del software libre, y proporciona las bases de
la Definición de Open Source.
• Las Normas de Debian son una especificación extensiva de los estándares de
calidad del Proyecto Debian.
Los desarrolladores de Debian también están involucrados en otros proyectos;

algunos específicos de Debian, otros en los que está involucrado parte o toda la
comunidad Linux. Algunos ejemplos incluyen:
92
• El Linux Standard Base (LSB). El LSB es un proyecto que pretende estandarizar
el sistema básico de GNU/Linux, lo que permitiría a terceros desarrolladores de
software y hardware desarrollar fácilmente programas y controladores de
dispositivos para Linux en general, más que para una distribución de
GNU/Linux en particular.
• El Estándar para la jerarquía del sistema de ficheros (FHS) es un esfuerzo para
estandarizar la distribución del sistema de ficheros de Linux. El FHS permitirá a
desarrolladores de software concentrar sus esfuerzos en diseñar programas, sin
tener que preocuparse sobre cómo se instalará su paquete en diferentes
distribuciones de GNU/Linux.
• Debian Jr. es nuestro proyecto interno, orientado a asegurarnos de que Debian
tiene algo que ofrecer a nuestros usuarios más jóvenes.
6.1.3 ¿Qué es Debian GNU/Linux?
La combinación de la filosofía y metodología de Debian, las herramientas GNU,

el núcleo Linux, y otro software libre importante, forman una distribución de software
única llamada Debian GNU/Linux. Esta distribución está formada por un gran número
de paquetes. Cada paquete en la distribución contiene ejecutables, scripts,
documentación e información de configuración, y tiene un encargado, quien es el
principal responsable de mantener el paquete actualizado, hacer un seguimiento de los
informes de fallo y comunicarse con los autores principales del programa empaquetado.
La atención que pone Debian a los detalles, permite producir una distribución de
alta calidad, estable y escalable. La instalación puede configurarse fácilmente para
cumplir diversas funciones, desde cortafuegos reducidos al mínimo, a estaciones de
trabajo científicas o servidores de red de alto rendimiento.
Debian es especialmente popular entre los usuarios avanzados debido a su

excelencia técnica y a sus comités siempre atentos a las necesidades y expectativas de la
comunidad Linux. Debian también introdujo muchas características a Linux, que ahora
son comunes.
Por ejemplo, Debian fue la primera distribución de Linux en incluir un sistema

de gestión de paquetes para una fácil instalación y desinstalación del software. Además,
también fue la primera que podía actualizarse sin necesidad de reinstalarla.
Debian continúa siendo líder en el desarrollo de Linux. Su proceso de desarrollo

es un claro ejemplo de lo bien que puede funcionar el modelo «Open Source»; incluso
para tareas tan complejas, como construir y mantener todo un sistema operativo.
Lo que más distingue a Debian de otras distribuciones GNU/Linux es su sistema

de gestión de paquetes. Estas herramientas otorgan al administrador de un sistema
Debian total control sobre los paquetes instalados, incluyendo la capacidad de instalar
un sólo paquete o actualizar el sistema operativo por completo. También es posible
proteger paquetes individualmente de forma que no se actualicen. También puede
indicar al sistema de gestión de paquetes qué programas ha compilado usted mismo y
qué dependencias cumplen.
93
Para proteger su sistema contra “caballos de Troya” y otros programas
malévolos, los servidores de Debian verifican que los paquetes provienen de sus
auténticos encargados. Los desarrolladores de Debian también ponen gran cuidado en
configurarlos de forma segura. Se publican parches muy rápidamente si se descubren
problemas de seguridad en los paquetes ya distribuidos. Usando el sencillo sistema de
actualización de Debian, puede descargar e instalar parches de seguridad
automáticamente a través de Internet.
El método principal, y el mejor, para obtener soporte para su sistema Debian

GNU/Linux y comunicarse con los desarrolladores de Debian, es a través de las diversas
listas de correo mantenidas por el proyecto Debian (existen más de 160 al momento de
escribir este documento). La manera más fácil de suscribirse a una de estas listas es
visitar la página de subscripción a las listas de correo de Debian y rellenar el formulario
que allí encontrará.
6.1.4 Sobre copyrights y licencias de software
Seguramente ha leído las licencias que acompañan a la mayoría del software

comercial — generalmente afirman que sólo puede usar una copia del software en un
único equipo. La licencia del sistema Debian GNU/Linux no es como éstas. Le
animamos a que instale copias de nuestro sistema en cualquier equipo de su colegio o de
su centro de trabajo. ¡Preste su medio de instalación a sus amigos y ayúdeles a instalarlo
en sus ordenadores! Incluso puede hacer miles de copias y venderlas — aunque con
algunas restricciones. Esto es posible gracias a que Debian está basado en software libre.
Software libre no quiere decir que éste carezca de copyright, ni tampoco que el
CD que compre con este software se deba distribuir sin costes. Software libre, en parte,
significa que las licencias de los programas individuales no requieren de ningún pago
por el derecho de distribución o uso de los mismos. También significa que cualquiera
puede extender, adaptar y modificar este software, así como distribuir los resultados de
su propio trabajo.
Nota
El proyecto Debian, como concesión pragmática a sus usuarios, ha decidido

dejar disponibles algunos paquetes que no cumplen nuestro criterio de libertad. Sin
embargo, estos paquetes no son parte de la distribución oficial, y sólo están disponibles
en las secciones contrib ó non-free dentro de las réplicas de Debian o bien en CD-ROMs
de terceros; consulte PUF de Debian, en la sección “Repositorios FTP de Debian”, para
más información acerca de la disposición y el contenido de los archivos.
La mayoría de los programas en el sistema están bajo la Licencia Pública

General de GNU, más comúnmente conocida como la “GPL”. La licencia GPL requiere
que el código fuente de los programas esté disponible siempre que se distribuya alguna
copia de los binarios del programa; esta condición de la licencia, asegura que cualquier
usuario pueda modificar el programa. Por esta misma razón, el código fuente de todos
los programas está disponible en el sistema Debian.
94
En Debian se usan una gran cantidad de declaraciones sobre derechos de autor y
licencias de programas. Puede encontrar el copyright de cada paquete instalado en su
sistema, revisando el fichero /usr/share/doc/nombre-paquete/copyright .
Para más información acerca de las licencias y como Debian determina si el

software es suficientemente libre para ser incluido en la distribución principal, revise las
Directrices de software libre de Debian (DFSG).
La parte más importante, legalmente hablando, es que el software viene sin

ninguna garantía. Los programadores que han creado este software lo han hecho
únicamente para el beneficio de la comunidad. No se da ninguna garantía en cuanto a la
conveniencia del software para ningún propósito específico. Sin embargo, puesto que el
software es libre, le animamos a modificar ese software para satisfacer sus necesidades
— y para gozar de las ventajas de los cambios realizados por otros, que de esta manera
han extendido el software.
95
6.2 Requisitos del sistema
6.2.1 Requisitos de memoria y espacio en disco
Debe tener al menos 12MB de memoria y 110MB de espacio en disco. Para un

sistema mínimo basado en consola (todos los paquetes estándar), precisa de 250 MB. Si
quiere instalar una cantidad de software razonable, incluyendo el sistema de ventanas X,
y algunos programas y bibliotecas de desarrollo, necesitará al menos 400 MB. Para una
instalación más o menos completa precisará de 800 MB. Para instalar todo lo disponible
en Debian, necesitará alrededor de 2 GB. Verdaderamente, instalar todo no significa
exactamente esto, pues hay algunos paquetes que son incompatibles con otros.
96
7. INSTALACIÓN DE DEBIAN
7.1 Iniciar el proceso de instalación

Para iniciar el proceso de instalación necesita arrancar la computadora con el
primer CD de instalación de Debian. Para hacer esto inserte el CD1 de Debian y reinicie
su computadora (ya debe haber configurado su BIOS).Entonces aparecerá en su pantalla:
Welcome to Debian GNU/Linux 3.0!
En esta pantalla se le explica que puede oprimir la tecla {F3} para conocer los
parámetros de arranque o {F1} para leer la ayuda general del sistema. También se le
pide que mantenga este disco a mano aún después de la instalación ya que le puede
servir como disco de rescate. Además se le recuerda que debería respaldar su
información. En la parte inferior de esta misma pantalla encontrará el prompt:
boot:_
En este prompt es donde puede teclear los parámetros con los que desea arrancar.
Puede teclear "bf24" (sin las comillas claro) y luego pulsar {Enter} para iniciar el
sistema de instalación con el Kernel Linux 2.4, el más moderno. En caso de que falle el
sistema con este Kernel, tendrá que usar el sistema de instalación estándar, es decir, sin
ningún parámetro.
7.2 Elección del Idioma

Lo primero que verá del sistema de instalación es el menú "Choose The
Language" el cual nos presenta varios idiomas a elegir. Antes de continuar asegúrese de
elegir la opción:
es - Elija esta opción y pulse enter para continuar en español
7.3 Notas de la versión

Después verá una pantalla con información acerca de la versión que está por
instalar y acerca de los desarrolladores o programadores del proyecto Debian. Solo
presione enter.
7.4 Menú principal de instalación de Debian GNU/Linux

Ahora se desplegará el menú principal del sistema de instalación, donde se
presentan todos los pasos ordenados para instalar Debian. Cada vez que Usted cumpla
con un paso el sistema comprobará lo que se ha hecho y ofrecerá como primera opción
la más recomendable con el título "Siguiente", después dos alternativas y abajo todas las
opciones posibles. Esto quiere decir que generalmente lo que tendrá que hacer es elegir
la primera opción y presionar la tecla enter.
97
7.5 Configurar el teclado
Debe seleccionar en este menú el tipo de teclado que posee. Debe estar
seleccionada ya la mejor opción que es: "qwerty/es : Español". Sino está seleccionada,
elíjala y presione enter, para regresar al menú principal en el cual podrá observar que se
agregó el paso "Anterior" a la lista de pasos por si desea repetir el último paso realizado,
recuerde que abajo están todos los pasos posibles. Pero el que nos interesa es el
"Siguiente".
7.6 Dar formato y activar una partición de intercambio

En el menú principal del sistema de instalación verá que la siguiente opción es:
dar formato y activar una partición de intercambio. Este paso es necesario ya que
aunque hemos creado ya la partición de intercambio, aun no está formateada ni ha sido
asignada o activada para funcionar como partición de intercambio. Presione enter para
continuar.
Ahora el sistema le preguntará si desea buscar bloques defectuosos. Es poco

probable que su disco tenga bloques defectuosos ya que las computadoras modernas
tienen controladores de disco que evitan esto, además buscar bloques defectuosos puede
tomar mucho tiempo por lo que la opción predeterminada es, no hacer esta búsqueda.
Solo oprima enter con la opción "No" seleccionada.Y el sistema insistiendo en
protegerle de Usted mismo le preguntará ¿Está seguro? solo presione enter para
continuar.
7.7 Iniciar una partición de Linux

En este paso le daremos formato a nuestra partición Linux. Si inició el sistema
de instalación con el Kernel Linux 2.4 (bf24) aparecerá una pantalla pidiéndole que
seleccione el tipo de sistema de ficheros, lo mejor es seleccionar Ext3 ya que ofrece
funcionalidades modernas y mantiene la compatibilidad. Pero si no arrancó el sistema
de instalación con el parámetro "bf24" entonces no podrá elegir y se usará el sistema
Ext2.
De nuevo aparecerá la pregunta acerca de los bloques defectuosos, ya sabe que

hacer "enter". Y si esta seguro que quiere continuar, presione otra vez enter. Para que
pueda ver como se crea el sistema de ficheros.
Después de que se termine de dar formato a la partición el sistema de instalación

le preguntará si desea montar esta partición como sistema de ficheros raíz, debe estar
seleccionada la opción "Sí" de ser así presione enter.
7.8 Instalar el núcleo y los módulos

El siguiente paso es instalar el núcleo Linux y sus módulos en su computadora,
al presionar enter se le avisará que se encontró un CD-ROM que los contiene ¿que
sorpresa verdad? Este mensaje en realidad aparece porque el sistema de instalación de
Debian fue diseñado para ser flexible y poder encontrar diferentes medios para instalar
98
el software en su computadora pero lo más común es el CD-ROM así que continuemos.
Asegúrese de que este seleccionada la opción "Sí" y presione enter.
7.9 Configurar los controladores de dispositivos

En este paso podrá activar y configurar controladores para su hardware. Primero
aparecerá una pantalla explicando que muchos controladores esenciales ya han sido
configurados de manera automática por lo que no necesita activarlos de manera manual,
presione enter para que aparezca un menú donde podrá seleccionar la categoría en la
que se puede encontrar el controlador que necesita instalar.
Los controladores en realidad son módulos del Kernel (núcleo) que se cargarán
al arrancar su máquina con Linux. Para encontrar estos módulos primero tendrá que
seleccionar una categoría y pulsar enter, para instalar un modulo selecciónelo y presione
enter, esto hará que el sistema le pregunte si desea instalarlo, si reponde sí, le pedirá los
argumentos necesarios (quizás IRQs, DMAs ú otros), afortunadamente la mayoría de
los módulos se autoconfiguran por lo que puede dejar el campo de los argumentos en
blanco y presionar enter en "Ok". Si el módulo se instala con éxito verá el mensaje
"Instalación correcta." Notará que los módulos instalados presentan el signo "+" y los
no instalados el signo "-". Para salir de la categoría en la que se encuentra seleccione la
opción "Salir" del menú de módulos.
Por ejemplo, si tiene una grabadora de CDs en el puerto ide necesitará el modulo
ide-scsi para que esta funcione bajo Linux. Haga lo siguiente: Seleccione la categoría
"kernel/drivers/scsi" y pulse enter, seleccione el módulo "ide-scsi" y pulse enter, verá
una pantalla con la pregunta ¿Instalar el módulo en el kernel? Seleccione "Yes" y pulse
enter, aparecerá una pantalla pidiéndole los argumentos de la línea de comandos, ahora
debe escribir append "hdc=ide-scsi" seleccionar "Ok" y presionar enter, a menos que su
grabadora se encuentre en hdb ú otro en cuyo caso remplazaría el hdc por el dispositivo
adecuado, recuerde la nomenclatura de dispositivos ide que se describe en la sección de
particionamiento de disco de este documento. Después de completar los pasos
necesarios debería ver el mensaje Instalación correcta.
No es buena idea instalar módulos que no va a necesitar ya que esto consume

recursos de su computadora y puede volver lento su sistema. De todos modos después
de terminar la instalación puede cambiar los módulos con el programa "modconf".
Para continuar con el proceso de instalación de Debian seleccione "Salir

finalizado" del menú de categorías.
7.10 Configurar la red

Si su computadora se conecta a Internet a través de una red local ó por medio de
un proveedor de banda ancha, necesitará algunos datos para completar este paso. Si se
conecta a Internet vía telefónica con modem, tendrá oportunidad de configurar su
conexión a Internet después de instalar el sistema base. Aunque no tenga banda ancha ni
su computadora esté conectada a una red, de todos modos, tendrá que completar este
paso ya que Linux está diseñado para trabajar en red y necesita que se especifiquen
algunos parámetros.
99
Primero debe elegir el nombre del sistema o hostname. Este nombre es el que se
le da a su máquina en la red, tal vez debería consultar con el administrador de la red que
nombre debería tener su máquina. Si la computadora no forma parte de una red puede
poner cualquier nombre que le guste. No debe usar guiones bajos ni signos de
puntuación, no escriba ningún nombre de dominio. Si tiene poca imaginación o no le
encuentra uso a esto puede dejar el nombre predeterminado "debian".
Después se le pregunta si hay un servidor DHCP o BOOTP, estos servidores

asignan IPs automáticamente a su máquina sin tener que asignarlos Usted mismo,
consulte con su proveedor de Internet ó su administrador de red si existe un servidor
DHCP, en cuyo caso debe responder "Sí" en la pantalla de "Configuración automática
de la red" de lo contrario seleccione "No" y presione enter.
Si no hay un servidor DHCP, necesita ahora asignar una dirección IP a su

computadora, pregúntele a su proveedor de Internet ó al administrador de la red. Si no
tiene red deje el predeterminado 192.168.1.1, seleccione "Aceptar" y presione enter.
De nuevo consulte con su proveedor ó su administrador de red para la máscara

de red ó si no tiene banda ancha ó red deje el predeterminado 255.255.255.0 y presione
enter sobre "Aceptar".
Pregunte a su proveedor ó administrador de la red ahora por el gateway ó

pasarela, si no está en red ó banda ancha borre el predeterminado y deje el campo en
blanco, seleccione "Aceptar" y pulse enter.
Necesita ahora el nombre de dominio (ejemplo: nombre.com), es posible que no

tenga un nombre de dominio, de ser así deje el campo en blanco y continúe, pulsando
enter en "Aceptar"
Ahora debe saber los IPs de los servidores de nombres de dominio (DNS)
separados por espacios, puede escribir hasta tres, si no tiene red ó banda ancha deje el
campo en blanco.
7.11 Instalar el sistema base

A continuación instalaremos el sistema base, es decir los programas esenciales
para que funcione Debian GNU/Linux en su computadora. Se le presentará una pantalla
pidiéndole que elija el medio para instalar el sistema. Lo más común es seleccionar
"cdrom"
No se desconcierte cuanto vea el mensaje "Por favor, inserte el CD-ROM"

simplemente presione enter, a menos que por algún motivo haya retirado el CD de la
unidad, en cuyo caso insértelo y presione enter para continuar.
Hay otro mensaje innecesario para el método de instalación vía CD, el cual le
pide que elija el directorio que usará para instalar el sistema base. Solo debe aparecer
una ruta "/instmnt" por lo tanto pulse enter sobre ella para que se instalen los paquetes
del sistema base.
100
7.12 Reiniciar el sistema
Ahora debe reiniciar su computadora para configurarla e instalar más paquetes.
Antes de reiniciar verá un mensaje que le pide que retire el CD-ROM y el floppy de la
computadora para evitar que esta arranque con ellos y no con el disco duro donde
instalamos Debian. Retírelos y presione enter sobre "Sí".
101
8. ESPECIFICACIÓN DE REQUISITOS
8.1 Requisitos funcionales
• Montaje de los nodos:
A partir de esta función se pondrán en funcionamiento de 4 maquinas bajo un
solo teclado, un solo ratón y una sola pantalla.
• Montaje de la red
Mediante unos dispositivos de red como el router y cables de red se montara una
red de ordenadores, los cuales estarán interconectados.
• Administración del cluster
Gestionar el sistema, estableciendo comunicación exitosa entre los diferentes

nodos y manteniendo el mismo para su correcto funcionamiento, pudiendo
realizar en todo momento todas las operaciones básicas propias de un cluster.
• Realización de pruebas
Se completará un análisis, diseño y especificación de pruebas.
• Obtención de estadísticas
Como que la idea principal del proyecto es la realización de una comparativa, la

obtención de estadísticas según las pruebas a realizar, es una de las
funcionalidades con efecto visual de las más importantes.
• Escalabilidad
El sistema debe ser capaz de dar servicio a un número reducido de nodos en un

contexto simple.
8.2 Requisitos no funcionales

• Estandarización de los datos
Se ajustarán todos los datos a una norma común para que todos los datos tengan
un mismo formato.
• Eficiencia en la ejecución
Los resultados obtenidos en la ejecución de las pruebas serán los más eficaces.
• Tratamiento de errores
Los errores serán valorados, solucionados y documentados para una correcta

valoración de la comparativa.
• Tiempo de respuesta
102
Es un requisito no funcional que será un punto importante en la comparativa de
cluster SSI.
8.3 Restricciones
Nuestra aproximación al desarrollo de la comparativa de cluster SSI es
incorporar los mecanismos para expresar las restricciones de tiempo en los modelos de
coordinación, ya que pensamos que estos son un aspecto más de la interacción de los
componentes (al igual que los aspectos de comunicación y sincronización) y que puede
ser tratado en el ámbito de estos modelos.
103
9. PROBLEMAS DE INSTALACIÓN DEL
CLUSTER SSI
9.1 Problemas de Sistemas

Éste es un ejemplo de algunas configuraciones estándares para un sistema.
Servidor típico
Éste es un perfil de servidor pequeño, útil para un servidor limitado que tiene
pocas utilidades para el usuario de consola. Incluye un servidor FTP, un servidor
Web, DNS, NIS y POP. Para esto le bastarán con 50MB de espacio en disco, y a
partir de ahí necesitará añadir espacio para los datos que desee servir.
Acceso telefónico
Una máquina típica de escritorio, incluyendo el sistema X window, aplicaciones
gráficas, sonido, editores, etc. El tamaño necesario para esta configuración es de
500MB.
Consola de trabajo
Una máquina más simplificada, sin sistema X window ni aplicaciones X.
Aconsejable para un portátil u ordenador móvil. El tamaño será alrededor de
140MB.
Programador
Una instalación de escritorio con paquetes de desarrollo, como Perl, C, C++, etc.
El tamaño estará en torno a 475 MB. Si añade X11 y algunos paquetes
adicionales para otros usos, deberá planear unos 800MB para este tipo de
máquina.
Recuerde que estos tamaños no incluyen todo el resto de información que se

suele usar, como ficheros de usuarios, correo y datos. Siempre es mejor ser generoso
cuando evalúa el espacio necesario para sus propios ficheros y datos. En especial, la
partición /var de Debian contiene una gran cantidad de información de estado. Los
ficheros de dpkg (con información de todos los paquetes instalados) pueden consumir
fácilmente unos 20MB; con los registros y el resto deberá reservar al menos 50 MB para
/var.
9.1.1 Ubuntu Server
Una vez que tenga toda la información del hardware de su equipo compruebe
que éste le permitirá soportar el tipo de instalación que desea.
En función de sus necesidades puede conseguir trabajar con menos de lo

recomendado en la tabla siguiente. Sin embargo, la mayoría de los usuarios se arriesgan
a que el sistema no cumpla sus expectativas si ignora estas sugerencias. Se recomienda
una máquina de al menos 132-MHz para los servidores.
104
Las características mínimas de hardware bajo Ubuntu son:
Instalación RAM Disco Duro

Sin escritorio 16 Megabytes (MB) 450 Megabytes (MB)
Con escritorio 64 Megabytes (MB) 1 Gigabytes (GB)
Servidor 128 Megabytes (MB) 4 Gigabytes (GB)
Tabla 2 Características mínimas de hardware en Ubuntu
La instalación y características de un servidor Ubuntu son:
Dependencias: Sí
Métodos de arranque para la instalación: Disquetes
Métodos de instalación: CD, disco duro, NFS, FTP
Sistema de inicio: Sys V init
Dificultad de instalación: Medio
Herramientas gráficas de instalación: Sí
Utilidad de instalación: Dselect
Utilidad de mantenimiento de paquetes: Dselect/dpkg

Tabla 3 Dependencias en Ubuntu
Por tanto la viabilidad para instalar un servidor Ubuntu fue muy ajustada, debido
a los requisitos mínimos y recomendables descritos anteriormente. Aún así hubo un
intento de instalación del servidor Ubuntu, ya que como se puede apreciar en la tabla
anterior la instalación no requiere demasiado tiempo. Dicha instalación se completo con
éxito, aunque abandonamos la idea de seguir con un servidor con este sistema operativo
debido a los problemas de arranque y memoria y que posteriormente tendríamos.
9.1.2 Debian Linux 3.1 Sarge (Kernel 2.4)
Una vez descartada la opción de tener un servidor Ubuntu, a priori, la opción

más lógica sería intentar la instalación de un servidor con la misma arquitectura, es
decir, un servidor Debian.
Debian es por decirlo coloquialmente el “padre” de Ubuntu, comparten

arquitectura, muchos de sus módulos y la gran mayoría de sus comandos, básicos a la
hora de administrar un servidor. Tiene un sistema de gestión de aplicaciones propio
muy bueno y no adopta cambios hasta que estos han sido probados suficientemente.
También existe multitud de documentación para solucionar problemas y además es una
distribución que sigue el espíritu de los sistemas GNU, tratando de incluir solamente
aquellas aplicaciones que sean libres para tener un sistema completamente libre, por ello
existen multitud de nuevas distribuciones que se basan en ella para salir al mercado tal y
como es Ubuntu.
105
Instalación RAM Disco Duro
Sin escritorio 8 Megabytes (MB) 320 Megabytes (MB)
Con escritorio 16 Megabytes (MB) 1 Gigabytes (GB)
Servidor 32 Megabytes (MB) 2 Gigabytes (GB)
Tabla 4 Características mínimas de hardware recomendado
¿Por qué entonces en un principio elegimos Ubuntu? Principalmente porque es
el sistema operativo basado en Unix que ambos utilizábamos periódicamente y porque
la instalación y administración era relativamente menos complicada y podríamos
obtener mismos resultados en un tiempo menor (no tendríamos apenas que incrementar
la línea de aprendizaje), por el contrario tenían la desventaja de tener un menor
conocimiento del sistema y por tanto una menor eficiencia del mismo.
Instalando el servidor Debian entonces obtendríamos una mayor capacidad de

abstracción del sistema, es decir, sabríamos en todo momento que está haciendo y
porqué lo hace, por tanto apenas hay automatización, es decir, no se auto ejecutan cosas
de forma “ciega” al gestor del servidor y por último a pesar de ser una dificultad
añadida, nos proporcionaría un menor uso de las características de nuestro hardware,
algo como veremos en nuestro siguiente apartado, muy crítico para nosotros (ya que
sólo se instala o ejecuta lo que nosotros hagamos “a mano”).
Esta gráfica muestra la evolución, la tendencia de uso de una distribución u otra,

que, a pesar de tener tantas cosas en común difieren tanto en comportamiento:
debian ubuntu
Figura 9 Gráfica Comparativa Debian Ubuntu
Siendo cada letra mayúscula A, B, C, D, E, F distintas actualizaciones de la

distribución Ubuntu.
Debido a la documentación obtenida en la fase del anteproyecto, descubrimos

que no debemos instalar la última versión del núcleo (kernel) de Debian, ya que
posteriormente, tendríamos problemas con los distintos Clusters (no sólo OpenMosix),
106
debido a que la última versión del kernel , la versión 2.6, no soporta una de las
características principales de todo Cluster: el balanceo de carga.
Aunque posteriormente decidimos instalar el kernel 2.6 tal y como explicamos

en el apartado siguiente debido a dificultades de hardware, los kernels que usaremos
para todo el proyecto serán unos núcleos parcheados de la versión 2.4 de Debian Sarge.
107
9.2 Problemas con el hardware
Una de nuestras características crítica en el proyecto es el hardware. El hardware
proporcionado no necesariamente funcionaba, o no necesariamente era compatible con
la arquitectura del servidor. De modo que inicialmente tuvimos que “reconstruir” cada
nodo con distintas piezas para su posterior correcto funcionamiento.
Los distintos problemas con el hardware se pueden clasificar en:
• Características del hardware.
• Incorrecto funcionamiento físico del hardware
9.2.1 Características del hardware
Tal y como describimos brevemente en el apartado anterior, tuvimos serias

dificultades a la hora de elegir un servidor que corriera perfectamente y sin dificultades
con nuestro hardware. La propia limitación de hardware limitaba aún más a este, es
decir, si por poner un ejemplo no tuviéramos suficiente disco duro como para instalar un
servidor u otro, podríamos proceder a ignorar dicho inconveniente instalando un
servidor desde ‘live cd’, pero debido a la escasa RAM dicho servidor nunca arrancaría
tal y como y como comprobamos intentando la instalación de la distribución KNNOPIX
Live CD.
Por tanto la elección de nuestro servidor se quedo reducida a distribuciones o

bien minimalistas, es decir, ‘mini-distribuciones’ con una gran pendiente en lo que a
línea de aprendizaje se refiere o bien distribuciones con plena capacidad y rendimiento
pero con una gran dificultad de instalación. Elegimos la segunda opción, ya uno de los
requisitos de todo Cluster es probar su eficiencia.
El rango de posibilidades lo llegamos a reducir a Gentoo Server o Debian Server,

nos decantamos por el segundo debido a sus mínimas restricciones de hardware, ya que
prácticamente pedía las mismas características que una distribución minimalista.
9.2.2 Incorrecto funcionamiento físico del hardware
Inicialmente probamos el funcionamiento de las piezas viendo el sistema “como

un todo”, es decir, sin comprobarlas una por una, y las que no funcionaron se
descartaron y fueron sustituidas. A continuación probamos la compatibilidad de dicho
hardware con la arquitectura del servidor, de igual manera descartamos todas las piezas
inservibles, teniendo el gran problema de desechar casi todas las tarjetas de red.
Los distintos problemas de funcionamiento han sido básicamente con

dispositivos DVD, con distintas ranuras PCI (dos en concreto) de dos placas distintas y
dos tarjetas de red, que unido a las tarjetas de red ya de por sí incompatibles, nos hizo
perder mucho tiempo, hasta que pudimos comprobar que el error en la administración
del servidor no era humano sino físico he inherente al hardware.
108
109
CAPITULO III
“OpenMosix y el mundo de la programación libre avanzan a pasos agigantados. Es un mundo donde el

sol nunca se pone y donde nadie entiende de fronteras, razas ni religiones. Lo que cuenta es el código.
Y llega en gran cantidad, y de gran calidad”
BAR, MOSHE
-Fundador y principal desarrollador de openMosix
110
10. OPENMOSIX
10.1 Introducción a Mosix
MOSIX es una extensión del kernel de Linux que permite ejecutar aplicaciones
“normales” (no paralelizadas) en un Cluster. Una de las posibilidades de MOSIX es la
“migración de procesos”, que permite migrar procesos de nodo en nodo. Si por ejemplo,
cierto proceso está dominando la carga de un nodo, este será movido a otro que tiene
más recursos.
Una de las características de MOSIX es que, a diferencia de otros clusters, no es

necesario modificar las aplicaciones ni tampoco utilizar librerías especiales. De hecho,
tampoco es necesario asignar “a mano” los procesos a los diferentes nodos que
componen el cluster.
La idea es que después de la creación de un nuevo proceso (fork), MOSIX

intenta asignarlo al mejor nodo disponible en ese entonces. MOSIX estará
constantemente manejando los procesos, y si fuera necesario, migrará un proceso entre
los nodos para maximizar el rendimiento promedio.
MOSIX realiza todo esto automáticamente, bajo el concepto de “fork and

forget” al igual que en un sistema SMP.
MOSIX funciona silenciosamente. Sus operaciones son transparentes para las

aplicaciones. Los usuarios no necesitan saber dónde se están ejecutando los procesos,
tampoco necesitan preocuparse de lo que están haciendo otros usuarios.
Como MOSIX está implementado en el kernel de Linux, sus operaciones son

totalmente transparentes para las aplicaciones. Esto permite definir distintos tipos de
clusters, incluso un cluster con diferentes CPU’s o velocidades LAN.
Otra característica de MOSIX, es que sus algoritmos son descentralizados - esto

significa que cada nodo puede ser el maestro de los procesos creados localmente, y un
servidor de los procesos remotos que migraron desde otros nodos. Esto permite agregar
o remover nodos desde el cluster en cualquier momento.
111
10.2 Introducción a OpenMosix
Algunos rumores hablaban que MOSIX venía de Moshe Unix. Inicialmente

Mosix empezó siendo una aplicación para BSD/OS 3.0.
Moshe Barak estuvo ligado al proyecto Mosix, en la Universidad Hebrea de

Jerusalén, durante bastantes años. Era el co-administrador del proyecto y el principal
administrador de los asuntos comerciales de Mosix company.
A principios de 1999 Mosix M06 fue lanzado para el kernel de Linux 2.2.1.
Entre finales de 2001 e inicios de 2002 nacía openMosix, la versión de código abierto,
de forma separada. OpenMosix en principio tenía que ser una ampliación a lo que años
atrás ya se podía encontrar en www.mosix.org, respetando todo el trabajo llevado a cabo
por el Prof. Barak y su equipo.
Tras algunas diferencias de opinión sobre el futuro comercial de Mosix, Moshe

Bar empezó un nuevo proyecto de clustering alzando la empresa Qlusters, Inc. en la que
el profesor A. Barak decidió no participar ya que no quería poner Mosix bajo licencia
GPL. Como había una significativa base de usuarios clientes de la tecnología Mosix
(unas 1000 instalaciones a lo ancho del planeta) Moshe Bar decidió continuar el
desarrollo de Mosix pero bajo otro nombre, openMosix, totalmente bajo licencia GPL2.
OpenMosix es un parche (patch) para el kernel de Linux que proporciona

compatibilidad completa con el estandar de Linux para plataformas IA32. Actualmente
se está trabajando para portarlo a IA64.
El algoritmo interno de balanceo de carga se encarga de forma transparente de

migrar procesos entre los nodos del cluster. La principal ventaja es una mejor
compartición de recursos entre nodos, asíı como un mejor aprovechamiento de los
mismos.
Gracias a openMosix el cluster escoge por síı mismo la utilización óptima de los
recursos que son necesarios en cada momento, y de forma automática. Esta
característica de migración transparente hace que el cluster funcione a todos los efectos
como un gran sistema SMP (Symmetric Multi Processing) con varios procesadores
disponibles. Esta característica se denomina SSI (Single System Image).
La estabilidad de openMosix ha sido ampliamente probada aunque todavía se

está trabajando en diversas líneas para aumentar su eficiencia. OpenMosix está
respaldado y siendo desarrollado por personas muy competentes y respetadas en el
mundo del open source, trabajando juntas en todo el mundo.
112
10.3 ¿Qué es OpenMosix?
OpenMosix es un parche para el Kernel de Linux que dota en la máquina en la
que se corre de la capacidad de trabajar como un nodo del cluster. Su misión es
convertir una red de ordenadores en un cluster. El algoritmo interno de balanceo de
carga se ocupa de migrar automáticamente y de forma transparente al usuario los
procesos entre los demás nodos del cluster, lo cual proporciona una compartición
óptima de la carga entre los distintos nodos.
Esta migración se realiza de acuerdo a la velocidad de CPU de cada nodo, a su

carga de procesos actual y a la conexión de red que lo une a los demás nodos, ya que
aunque todos deben utilizar el protocolo TCP/IP para comunicarse entre ellos, no todos
tienen que estar conectados en la misma subred, ni utilizar los mismos medios físicos de
unión (ethernet, PPP, etc...).
OpenMosix también permite al administrador del cluster puede realizar la

migración de procesos de forma manual gracias a las herramientas que de software que
acompañas al cluster (Userland tools o Userspace tools). Asimismo, los nodos pueden
añadirse o quitarse de la red sin que los procesos en ejecución se vean afectados.
Debido a que OpenMosix forma parte del kernel, ya que se añade al código
fuente de éste antes de compilarlo, es totalmente compatible con Linux, sus programas y
sus ficheros. No es posible distinguir entre una máquina normal y corriente ejecutando
Linux y una máquina utilizando Linux como nodo de un cluster OpenMosix. El sistema
de migración de procesos hace trabajar al conjunto de nodos como un enorme sistema
de procesadores (o multiprocesadores en el caso de que se trate de cores ó procesadores
dual o quad en cada máquina).
OpenMosix utiliza un sistema de ficheros llamado oMFS (OpenMosix File

System) que, al contrario que el sistema de ficheros NFS, proporciona cache, "time
stamp" y consistencia de enlace.
113
10.4 ¿Por qué se ha elegido OpenMosix?
Dentro de las diversas opciones disponibles se ha elegido openMosix debido a
que corre en GNU/LINUX, es un proyecto con licencia GPL y es uno de los más
utilizados en la actualidad, además de ser el que cuenta con mayor documentación, tanto
en cantidad como en calidad en Internet.
Originalmente deriva del proyecto MOSIX. Debido a las diferencias de

opiniones entre los desarrolladores del proyecto a la hora de liberar el código bajo una
licencia no libre, los que optaron por liberarlo bajo licencia GPL se separaron del
proyecto original para continuar un desarrollo paralelo, dando lugar a OpenMosix.
Numerosas mejoras fueron añadidas al proyecto, como su acomodación a la

estructura de Linux, un código y un algoritmo de migración de procesos más limpio, un
método de balanceo de carga más eficiente, menores latencias en el kernel, soporte para
más arquitecturas (incluidas algunas de 64 bits) y, sobre todo, muchísima
documentación.
114
10.5.1 ¿Cuáles son las desventajas de OpenMosix?
Entre sus desventajas más notables se encuentran:
• Es dependiente del kernel y, por tanto, de la versión de éste que se esté utilizando.
• No migra procesos que utilicen memoria compartida
• No migra procesos que utilicen múltiples “threads”
• No migra procesos únicos, como son la mayoría de los programas que utilizamos
diariamente
10.5.2 ¿Cuáles son las ventajas de OpenMosix?
Entre sus ventajas más notables se encuentran:
• No se requieren paquetes extra.

• No son necesarias modificaciones en el código.
• Licencia GNU GPL.
10.5.3 ¿Se puede solucionar el problema de la memoria compartida?
Si, para ello existe Migshm. Migshm es un parche para hacer que funciones la
memoria compartida de forma distribuida (DSM – Distributed Shared Memory). Con
ello se consigue que puedan migrar los procesos que utilicen memoria compartida.
Para conseguirlo se utilizan las llamadas al sistema: shmget(), shmat(), shmdt() y

shmctl(). Los threads creados a partir de la llamada al sistema clone() también pueden
ser migrados aplicando este parche. Hemos decidido no aplicar este parche porque no
existe una versión que corresponda con la versión de OpenMosix que utilizada y porque
está en una fase muy experimental (alpha), por lo que el rendimiento total del cluster
puede verse perjudicado y los resultados de los benchmarks y pruebas pueden verse
alterado.
10.5.4 Subsistemas de openMosix

En la actualidad de pueden dividir los parches de openMosix dentro del kernel
en cuatro grandes subsistemas.
10.5.4.1 Mosix File System (MFS)
El primer y mayor subsistema (en cuanto a líneas de código) es MFS que te

permite un acceso a sistemas de ficheros (FS) remotos (i.e. de cualquier otro nodo) si
está localmente montado.
El sistema de ficheros de tu nodo y de los demás podrán ser montados en el

directorio /mfs y de esta forma se podrá, por ejemplo, acceder al directorio /home del
nodo 3 dentro del directorio /mfs/3/home desde cualquier nodo del cluster.
115
10.5.4.2 Migración de procesos
Con openMosix se puede lanzar un proceso en una computadora y ver si se

ejecuta en otra, en el seno del cluster. Cada proceso tiene su único nodo raíz (UHN,
unique home node) que se corresponde con el que lo ha generado.
El concepto de migración significa que un proceso se divide en dos partes: la

parte del usuario y la del sistema. La parte, o área, de usuario será movida al nodo
remoto mientras el área de sistema espera en la raíz.
OpenMosix se encargará de establecer la comunicación entre estos 2 procesos.
10.5.4.3 Direct File System Access (DFSA)
OpenMosix proporciona MFS con la opción DFSA que permite acceso a todos
los sistemas de ficheros, tanto locales como remotos.
10.5.4.4 Memory ushering
Este subsistema se encarga de migrar las tareas que superan la memoria

disponible en el nodo en el que se ejecutan. Las tareas que superan dicho límite se
migran forzosamente a un nodo destino de entre los nodos del cluster que tengan
suficiente memoria como para ejecutar el proceso sin necesidad de hacer swap a disco,
ahorrando así la gran pérdida de rendimiento que esto supone.
El subsistema de memory ushering es un subsistema independiente del

subsistema de equilibrado de carga, y por ello se le considera por separado.
10.5.5 El algoritmo de migración
De entre las propiedades compartidas entre Mosix y openMosix podemos

destacar el mecanismo de migración, en el que puede migrar-se cualquiera proceso a
cualquier nodo del cluster de forma completamente transparente al proceso migrado. La
migración también puede ser automática: el algoritmo que lo implementa tiene una
complejidad computacional del orden de O(n), siendo n el número de nodos del cluster.
Para implementarlo openMosix utiliza el modelo fork-and-forget, desarrollado

en un principio dentro de Mosix para máquinas PDP11/45 empleadas en las fuerzas
aéreas norteamericanas.
La idea de este modelo es que la distribución de tareas en el cluster la determina

openMosix de forma dinámica, conforme se van creando tareas. Cuando un nodo está
demasiado cargado, y las tareas que se están ejecutando puedan migrar a cualquier otro
nodo del cluster. Así desde que se ejecuta una tarea hasta que ésta muere, podrá migrar
de un nodo a otro, sin que el proceso sufra mayores cambios.
Se podrá pensar que el comportamiento de un cluster openMosix es como una

máquina NUMA, aunque estos clusters son mucho más baratos.
116
10.5.5.1 El nodo raíz
Cada proceso ejecutado en el cluster tiene un único nodo raíz, como se ha visto.
El nodo raíz es el nodo en el cual se lanza originalmente el proceso y donde éste
empieza a ejecutarse.
Desde el punto de vista del espacio de procesos de las máquinas del cluster, cada
proceso (con su correspondiente PID) parece ejecutarse en su nodo raíz. El nodo de
ejecución puede ser el nodo raíz u otro diferente, hecho que da lugar a que el proceso no
use un PID del nodo de ejecución, sino que el proceso migrado se ejecutará en éste
como una hebra del kernel.
La interacción con un proceso, por ejemplo enviarle señales desde cualquier otro
proceso migrado, se puede realizar exclusivamente desde el nodo raíz.
El usuario que ejecuta un proceso en el cluster ha accedido al cluster desde el

nodo raíz del proceso (puesto que ha logrado en él). El propietario del proceso en
cuestión tendrá control en todo momento del mismo como si se ejecutara localmente.
Por otra parte la migración y el retorno al nodo raíz de un proceso se puede realizar
tanto desde el nodo raíz como desde el nodo dónde se ejecuta el proceso. Esta tarea la
puede llevar a término el administrador de cualquiera de los dos sistemas.
10.5.5.2 El mecanismo de migrado
La migración de procesos en openMosix es completamente transparente. Esto

significa que al proceso migrado no se le avisa de que ya no se ejecuta en su nodo de
origen. Es más, este proceso migrado seguirá ejecutándose como si siguiera en el nodo
origen: si escribiera o leyera al disco, lo haría en el nodo origen, hecho que supone leer
o grabar remotamente en este nodo.
10.5.5.3 ¿Cuándo podrá migrar un proceso?
Desgraciadamente, no todos los procesos pueden migrar en cualquiera

circunstancia. El mecanismo de migración de procesos puede operar sobre cualquier
tarea de un nodo sobre el que se cumplen algunas condiciones predeterminadas. Éstas
son:
• el proceso no puede ejecutarse en modo de emulación VM86
• el proceso no puede ejecutar instrucciones en ensamblador propias de la
máquina donde se lanza y que no tiene la máquina destino (en un cluster
heterogéneo)
• el proceso no puede mapear memoria de un dispositivo a la RAM, ni acceder
directamente a los registros de un dispositivo
• el proceso no puede usar segmentos de memoria compartida
Cumpliendo todas estas condiciones el proceso puede migrar y ejecutarse

migrado. No obstante, como podemos sospechar, openMosix no adivina nada.
OpenMosix no sabe a priori si alguno de los procesos que pueden migrar tendrán
algunos de estos problemas. Por esto en un principio openMosix migra todos los
procesos que puedan hacerlo si por el momento cumplen todas las condiciones, y en
117
caso de que algún proceso deje de cumplirlas, lo devuelve de nuevo a su nodo ra´ız para
que se ejecute en él mientras no pueda migrar de nuevo.
Todo esto significa que mientras el proceso esté en modo de emulación VM86,
mapee memoria de un dispositivo RAM, acceda a un registro o tenga
reservado/bloqueado un puntero a un segmento de memoria compartida, el proceso se
ejecutará en el nodo raíz, y cuando acabe la condición que lo bloquea volverá a migrar.
Con el uso de instrucciones asociadas a procesadores no compatibles entre ellos,

openMosix tiene un comportamiento diferente: solo permitirá migrar a los procesadores
que tengan la misma arquitectura.
10.5.5.4 La comunicación entre las dos áreas
Un aspecto importante en el que se puede tener interés es en cómo se realiza la

comunicación entre el área de usuario y el área de kernel. En algún momento, el proceso
migrado puede necesitar hacer alguna llamada al sistema. Esta llamada se captura y se
evalúa si puede ser ejecutada al nodo al que la tarea ha migrado, o si necesita ser
lanzada en el nodo raíz del proceso migrado. Si la llamada puede ser lanzada al nodo
dónde la tarea migrada se ejecuta, los accesos al kernel se hacen de forma local, es decir,
que se atiende en el nodo dónde la tarea se ejecuta sin ninguna carga adicional a la red.
Por desgracia, las llamadas más comunes son las que se han de ejecutar
forzosamente al nodo raíz, puesto que hablan con el hardware. Es el caso, por ejemplo,
de una lectura o una escritura a disco. En este caso el subsistema de openMosix del
nodo dónde se ejecuta la tarea contacta con el subsistema de openMosix del nodo raíz.
Para enviarle la petición, así como todos los parámetros y los datos del nodo raíz que
necesitará procesar. El nodo raíz procesará la llamada y enviará de vuelta al nodo dónde
se está ejecutando realmente el proceso migrado:
• el valor del éxito/fracaso de la llamada

• aquello que necesite saber para actualizar sus segmentos de datos, de pila y
de heap.
• el estado en el que estaría si se estuviera ejecutando el proceso al nodo raíz
Esta comunicación también puede ser generada por el nodo raíz. Es el caso, por
ejemplo, del envío de una señal. El subsistema de openMosix del nodo raíz contacta con
el subsistema de openMosix del nodo dónde el proceso migrado se ejecuta, y el avisa
que ha ocurrido un evento asíncrono. El subsistema de openMosix del nodo dónde el
proceso migrado se ejecuta parará el proceso migrado y el nodo raíz podrá empezar a
atender el código del área del kernel que correspondería a la señal asíncrona.
Finalmente, una vez realizada toda la operativa necesaria del área del kernel, el
subsistema de openMosix del nodo raíz del proceso envía al nodo donde está
ejecutándose realmente el proceso migrado el aviso detallado de la llamada, y todo
aquello que el proceso necesita saber (anteriormente enumerado) cuando recibió la señal,
y el proceso migrado finalmente recuperará el control. Por todo esto el proceso migrado
es como sí estuviera al nodo raíz y hubiera recibido la señal de éste. Tenemos un
escenario muy simple donde el proceso se suspende esperando un recurso. Recordemos
que la suspensión esperando un recurso se produce únicamente en área de kernel.
118
Cuando se pide una página de disco o se espera un paquete de red se resuelto
como en el primero caso comentado, es decir, como un llamada al kernel.
Este mecanismo de comunicación entre áreas es el que asegura que la migración

sea completamente transparente tanto para el proceso que migra como para los procesos
que cohabiten con el nodo raíz que el proceso no necesite ser reescrito para poder
migrar, ni sea necesario conocer la topología del cluster para escribir una aplicación
paralela. No obstante, en el caso de llamadas al kernel que tengan que ser enviadas
forzosamente al nodo raíz, tendremos una sobrecarga adicional a la red debida a la
transmisión constante de las llamadas al kernel y la recepción de sus valores de vuelta.
Destacamos especialmente esta sobrecarga en el acceso a sockets y el acceso a disco
duro, que son las dos operaciones más importantes que se habrán de ejecutar en el nodo
raíz y suponen una sobrecarga al proceso de comunicación entre la área de usuario
migrada y la área de kernel del proceso migrado.
119
10.6 Instalación de un cluster openMosix
10.6.1 Descargando las fuentes del kernel
Desde la página oficial del kernel de Linux www.kernel.org nos descargamos la

versión 2.4.26, hay que notar que el parche de openMosix trabaja sobre una misma
versión del kernel, es decir, si obtenemos el parche 2.4.22 trabajaremos con el kernel
2.4.22, en nuestro caso usaremos el parche 2.4.26 y su respectiva versión del kernel la
2.4.26.
Hay que también resaltar que todos las versiones a partir de de la versión 2.4.26
a día de hoy no tienen migración de procesos, por tanto elegimos la última con todas las
características de openMosix disponibles.
Descargarnos las fuentes desde: http://www.kernel.org/pub/linux/kernel/v2.4/
En esta página descargamos el paquete linux2.4.26.tar.bz2.
10.6.2 Pasos previos para recompilar el nuevo kernel
Una vez descargado el .tar.bz2 de nuestro kernel, usamos el siguiente comando

para descomprimirlo:
# tar xjvf linux2.4.26.tar.bz2
Hecho lo anterior se crea la carpeta linux2.4.26, en la que tenemos todos los

archivos necesarios para compilar el nuevo kernel. Luego copiamos la carpeta
linux2.4.26 (en donde la hayamos descargado) a /usr/src/ y nos vamos a ese directorio:
# cp -r linux2.4.26/usr/src/
# cd /usr/src/
Creamos un enlace simbólico /usr/src/linux2.4.26 a /usr/src/linuxom, esto es

para no tener que estar escribiendo usr/src/linux2.4.26, y de ahora en adelante solo
teclearemos usr/src/linuxom:
# ln -s /usr/src/linux2.4.26/usr/src/linuxom
10.6.3 Descargando el parche de openMosix
El parche de openMosix nos descargamos desde su página oficial:
http://sourceforge.net/projects/openmosix/
Copiar openMosix a la ruta donde esta la carpeta /usr/src/linuxom/, y

descomprimirlo:
# cp openMosix2.4.261.bz2 /usr/src/linuxom
120
# cd /usr/src/linuxom
# bzip2 -d openMosix2.4.261.bz2
Aplicamos el parche de openMosix:
# patch p1 < openMosix2.4.261
Tras aplicar el parche, entramos al directorio linuxom (enlace simbólico que

creamos anteriormente).
# cd linuxom
Dentro de esta carpeta tenemos una serie de archivos que son los necesarios para
recompilar el kernel.
10.6.4 Configurando kernel para compilarlo
Existen varios métodos de configuración, como son make menuconfig (usa

ncurses), make xconfig (trabaja con el servidor X), make gconfig (usuarios de Gnome),
make oldconfig (carga las opciones actuales del kernel instalado). Aquí se usará make
menuconfig:
# make menuconfig
Al ejecutar el comando anterior aparecerá la pantalla de configuración del kernel

con una opción más que es openMosix.
10.6.5 Opciones del kernel de openMosix
 openMosix process migration support

es la opción principal y la que si debe estar en yes, si no está activada esta
opción no trabajará el cluster. Con esta opción se activa el soporte para la
migración de procesos.
 Support clusters with a complex network topology

Si activamos esta opción estamos diciendo a nuestro cluster que en nuestra red
trabajamos con routers y puede ser una red compleja (si se usan varios
encaminadores para llegar a varios destinos de toda la red). Si solo usamos una
hub en la red entonces es preferible desactivarla para que el cluster tenga un
buen desempeño.
 Maximum networktopology complexity to support (210):

Esta opción se activa siempre y cuando esté activada la opción anterior, caso
contrario aparecerá como oculta. Si se da el caso de tener una red compleja
tenemos que colocar el nivel de complejidad de los ordenadores más lejanos(es
el número de routers que existen entre los ordenadores más uno).
 Stricter security on openMosix ports
121
Con esta opción openmosix chequea los paquetes enviados y recibidos por los
nodos del cluster. Hemos decidido dejar en no está opción para que nuestro
cluster tenga un buen rendimiento y no consuma muchos recursos del sistema.
 Level of processidentity disclosure (03)

Para obtener información de la tarea que se ejecuta en el nodo remoto. Basta con
dejar 1 para sólo enviar el PID.
 Poll/Select exceptions on pipes

Esta opción es una mera adaptación para soportar procesos no estandarizados
por Posix ya que en Unix, un proceso que escriba en un pipe, en principio, no es
interrumpido si otro proceso abre el mismo pipe para leer o ya lo tenía abierto y
lo cierra. Mientras que en Posix, un proceso escritor en un pipe puede recibir una
excepción cuando otro proceso abra un pipe para leer dicho pipe, y puede recibir
también una excepción si el pipe se queda sin lectores.
 Disable OOM Killer

Nos permite inhabilitar el OOM Killer, y evitar los problemas que causa este, si
no estamos seguros de esta opción es recomendable inhabilitar el OOM Killer.
Luego de configurar el kernel de acuerdo a las características de nuestro equipo

y con las opciones de openMosix guardamos la configuración y ejecutamos lo siguiente:
Buscando las dependencias del kernel:
# make Dep.
Limpiamos el kernel de restos de compilaciones anteriores:
# make clean
Compilamos el kernel:
# make bzImage
Compilar los módulos:
# make modules
Instalamos los módulos:
# make modules_install
Finalmente ejecutamos
# make install
Con este comando se añadirá la nueva imagen del kernel al GRUB si tener que
estar editando manualmente, otra manera de añadir la imagen al GRUB es siguiendo
estos pasos:
122
Copiamos el nuevo kernel en el directorio /boot
# cp arch/i386/boot/bzImage /boot/vmlinux2.4.26openmosix
Configuramos el Gestor de arranque:
Si usamos GRUB como gestor de arranque editamos el archivo /boot/grub/menu.lst y

añadimos la nueva imagen del kernel compilado:
title Debian Sarge (2.4.26openmosix1)

root (hd0,6)
kernel /vmlinuz2.4.26openmosix1 ro root=LABEL=/ hdc=idescsi hdd=idescsi
Nota: Si después de reiniciar el kernel obtenemos un kernel panic con el mensaje que
no se ha encontrado el sistema de ficheros de root, es porque en la línea donde va
“root=...” no está especificada la partición primaria. La solución es editar el archivo y
borrar lo que va después del igual de root para añadir la partición, Ejemplo:
kernel /vmlinuz2.4.26openmosix1
ro root=/dev/hda1
10.6.6 Nuestra configuración del kernel
Véase el Apéndice II.
123
10.7 Administración del cluster
El mantenimiento de un sistema resulta incluso más delicado y costoso (en

tiempo) que su correcta instalación. En este punto se tomará contacto con todas las
herramientas con las que cuenta openMosix para poder gestionar tu sistema.
10.7.1 Administración básica
OpenMosix proporciona como principal ventaja la migración de procesos hacia

aplicaciones HPC. El administrador puede configurar el cluster utilizando las
herramientas de área de usuario de openMosix (openMosix-user-space-tools8) o
editando la interfaz que se encuentra en /proc/hpc y que será descrita con más detalle
seguidamente.
10.7.2 Las herramientas de área de usuario
Estas herramientas permitirán un fácil manejo del cluster openMosix. Seguidamente se

enumeran con todos sus parámetros.
• migrate [PID] [openMosix ID] envia una petición de migrado del proceso
identificado con el ID, al nodo que indiquemos..
• mon es un monitor de los daemons (demonios) basado en el terminal y da
información relevante sobre el estado actual que puede ser visualizada en diagramas
de barras.
• mosctl es la principal utilidad para la configuración de openMosix.
Su sintaxis es:
mosctl [stay|nostay]
[block|noblock]
[quiet|noquiet]
[nomfs|mfs]
[expel|bring]
[gettune|getyard|getdecay]
• mosct whois [openMosix_ID|IP-address|hostname]

• mosct [getload|getspeed|status|isup|getmem|getfree|getutil] [openMosix_ID]
• mosctl setyard [Processor-Type|openMosix_ID||this]
• mosctlsetspeed interger-value
• mosctlsetdecay interval [slow fast]
Mar 21 20:41:49 localhost omdiscd[1290]: Unable to determine address of default

interface. This may happen because there is no default route configured. Without a
default route, an interface must be: Network is unreachable
Mar 21 20:41:49 localhost omdiscd[1290]: Unable to initialize network. Exiting.
Un ejemplo de buena configuración podría ser la siguiente:
[root@localhost log]# route -n
124
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.0.0.99 0.0.0.0 UG 0 0 0 eth0
La importancia de poder automatizar el reconocimiento de nuevos nodos

conectados al sistema ha facilitado que se llegue a la simplicidad con la que se ha
contado actualmente para iniciar dicha detección, con el comando omdiscd. Ahora
echando un vistazo a los logfiles se tendrá que ver algo parecido a:
Mar 22 10:00:49 cloutser0 kernel: openMosix configuration changed: This is

openMosix #2780 of 3 configured)
Mar 22 10:00:49 clout0 kernel: openMosix #2780 is at IP address 172.26.0.8
Mar 22 10:00:49 ser 0 kernel: openMosix #2638 is at IP address 172.26.0.9
Mar 22 10:00:49 cloutser 0 kernel: openMosix #2646 is at IP address 172.26.0.10
Tendremos el cluster listo para ser utilizado.
omdiscd tiene otras opciones entre las que cuentan poder ejecutarse como un
demonio (por defecto) o en background (segundo plano) donde la salida será la pantalla
(la salida estándar), con el comando omdiscd -n. La interfície, como ya se ha indicado,
debe ser especificada con la opción -i. Ahora se va a ver brevemente la herramienta
showmap. Esta utilidad mostrará el nuevo mapa.
Stay desactiva la migración automática

Nostay migración automática (defecto)
Lstay local processes should stay
Nolstay los procesos locales podrán migrar
Block bloquea la llegada de otros procesos
Noblock permite la llegada de procesos
Quiet desactiva la posibilidad de dar información sobre la carga del nodo
Noquiet activa la posibilidad de dar información sobre la carga del nodo
Nomfs desactiva MFS
Mfs activa MFS
Expel envía fuera del nodo los procesos que han llegado previamente
Bring traerá todos los procesos migrados hacia su nodo raíz
Gettune muestra el parámetro de overhead
Getyard muestra la utilización actual de Yardstick
Getdecay muestra el estado del parámetro decay
Whois nos muestra el openMosix-ID, la dirección IP y los nombres de host del
cluster
Getload muestra la carga (openMosix-)
Getspeed muestra la velocidad (openMosix-)
125
Status muestra el estado y la configuración actual
Isup nos informa de si un nodo está funcionando o no (ping openMosix)
Getmem muestra la memoria lógica libre
Getfree muestra la memoria física libre
Getutil muestra la utilización del nodo
Setyard establece un nuevo valor para Yardstick
Setspeed establece un nuevo valor para la velocidad (openMosix-)
Setdecay establece un nuevo valor para el intervalo del decay
Tabla 5 Parámetros de mosctl con más detalle
Con mosrun ejecutaremos un comando especialmente configurado en un nodo

establecido.
Su sintaxis:
• mosrun [-h|openMosix ID| list of openMosix IDs] command [arguments]
El comando mosrun puede ser ejecutado con diversas opciones. Para evitar
complicaciones innecesarias viene con ciertas pre-configuraciones para ejecutar las
tareas con configuraciones especiales de openMosix.
Nomig runs a command which process(es) won’t migrate

Runhome ejecuta un comando bloqueado en el nodo raíz
Runon ejecutaría un comando el cuál será directamente migrado y bloqueado a
cierto nodo
Cpujob informa a openMosix que el proceso está ligado a la CPU
Iojob informa a openMosix que el proceso está ligado a la E/S
Nodecay ejecuta un comando e informa al cluster de no refrescar las estadísticas
de carga
Slowdecay ejecuta un comando con intervalo de decay grande para acumular en las
estadísticas
Fastdecay ejecuta un comando con intervalo de decay pequeño para acumular en
las estadísticas
Tabla 6 Parámetros adicionales para mosrun
• setpe es una utilidad de configuración manual del nodo sintaxis:

setpe -w -f [hpc_map]
setpe -r [-f [hpc_map]]
setpe -off
-w lee la configuración de openMosix desde un fichero (normalmente
/etc/hpc.map).
-r escribe la configuración actual de openMosix en un fichero (normalmente
/etc/hpc.map).
-off desactiva la configuración actual del cluster.
126
• tune es una utilidad de calibración y optimización de openMosix (para más
información recurra a las páginas man de tune).
[root@cloutser0 root]# showmap

My Node-Id: 0x0adc
Base Node-Id Address Count
------------ ---------------- -----
0x0adc 172.26.0.8
0x0a4e 172.26.0.9
0x0a56 172.26.0.10
Existen otras muchas utilidades que pueden ser útiles para la detección
automática de nodos, como un mecanismo de routing para clusters con más de una red
de conexión.
10.7.3 Problemas
Algunas veces la auto-detección no funcionará tal como podríamos esperar, por

ejemplo cuando un nodo debería ser detectado y no ve el tráfico multicast (tráfico
generado de un nodo a todos) que se lleva a cabo en la red.
Esto ocurre con algunas tarjetas PCMCIA. Una solución posible sería poner la
interfície en modo promiscuo, tal como se detalla seguidamente:
Mar 22 20:45:58 localhost kernel: openMosix configuration changed:This is

openMosix #98 (of 1 configured)
Mar 22 20:45:58 localhost kernel: openMosix #98 is at IP address 10.0.0.98
Mar 22 20:45:58 localhost omdiscd[1627]: Notified kernel to activate
openMosix Mar 22 20:45:58 localhost kernel: Received an unauthorized
information request from 10.0.0.99
Algo que se podría probar es forzar manualmente nuestro NIC a modo

promíscuo y/o multicast, así:
ifconfig ethx promisc

o
ifconfig ethx multicast
Podremos ejecutar igualmente
tcpdump -i eth0 ether multicast
Si se muestra simulated es que seguramente se ha olvidado de poner el

comentario a la linea
#define ALPHA, sería:

Mar 22 22:14:43 inspon omdiscd[1422]: Simulated notification to activate
openMosix
[root@inspon root]# showmap
127
My Node-Id: 0x0063
Base Node-Id Address Count
------------ ---------------- -----
0x0063 10.0.0.99 1
[root@inspon root]# /etc/init.d/openmosix status
OpenMosix is currently disabled
[root@inspon root]#
128
11. OPENMOSIXVIEW
11.1 Introducción
OpenMosixview es la siguiente versión de MosixView. Es una interfaz gráfica
(GUI) libre para la administración y mantenimiento de un cluster openMosix que
podemos bajarnos de la web del proyecto9. La suite openMosixview contiene 6
aplicaciones altamente eficaces y útiles tanto para la administración como para el
monitoraje de nuestro cluster.
• openMosixview la principal aplicación de monitoraje y administración

• openMosixprocs una aplicación para la administración de procesos
• openMosixcollector acumula la información del cluster proporcionada por
los daemons
• openMosixanalyzer para el análisis de la información colectada por
openMosixcollector
• openMosixhistory un historial de procesos del cluster
• 3dmosmon un visor para monitoraje de datos en 3D
Todos los componentes son accesibles desde la ventana de la aplicación

principal. Los comandos openMosix más comunes podrán ser ejecutados con unos
pocos clicks de ratón.
129
11.2 Instalación
Requerimientos:
• tener instaladas las librerías QT >= 2.3.0
• derechos de root!
• rlogin y rsh (o ssh) en todos los nodos del cluster y sin contraseñas
• las herramientas de usuario de openMosix (mosctl, migrate, runon, iojob,
cpujob...)
Los paquetes RPM tienen como directorio de instalación la ruta:

/usr/local/openMosixview.
11.2.1 Instalación de los paquetes RPM
Tendremos que bajarnos la última versión de los paquetes RPM de

openMosixview. Luego ejecutaremos el comando (suponiendo la versión 1.2) :
rpm -i openMosixview-1.2.rpm
Esto nos instalará los ficheros binarios en el directorio /usr/bin.

Para desinstalarlo ejecutaremos: rpm -e openMosixview.
11.2.2 Instalación de las fuentes
Bajaremos la última versión de openMosixview y descomprimiremos y

desempaquetaremos el paquete:
• gunzip openMosixview-1.5.tar.gz
• tar -xvf openMosixview-1.5.tar
11.2.3 Script de configuración automático
Sólo será necesario entrar al directorio openMosixview y ejecutar:
• ./setup [directorio de instalación qt 2.3.x]
11.2.4 Compilación Manual
Será necesario situar la variable QTDIR hacia el directorio de la distribución QT,

por ejemplo:
• export QTDIR=/usr/lib/qt-2.3.0 (para bash)
o
• setenv QTDIR /usr/lib/qt-2.3.0 (para csh)
Tras lo anterior tendríamos que ejecutar con éxito la configuración:
130
• ./configure
• make
Luego tendremos que hacer lo mismo en los subdirectorios de openMosixcollector,

open-Mosixanalyzer, openMosixhistory and openMosixviewprocs.
Copiaremos todos los binarios a /usr/bin

• cp openMosixview/openMosixview /usr/bin
• cp openMosixviewproc/openMosixviewprocs/mosixviewprocs /usr/bin
• cp openMosixcollector/openMosixcollector/openMosixcollector /usr/bin
• cp openMosixanalyzer/openMosixanalyzer/openMosixanalyzer /usr/bin
• cp openMosixhistory/openMosixhistory/openMosixhistory /usr/bin
Y el script de iniciación de openMosixcollector en tu directorio de iniciación,

por ejemplo:
• cp openMosixcollector/openMosixcollector.init
/etc/init.d/openMosixcollector
o
• cp openMosixcollector/openMosixcollector.init
/etc/rc.d/init.d/openMosixcollector
Ahora tendremos que copiar los binarios de openMosixprocs de cada nodo del
cluster al directorio: /usr/bin/openMosixprocs
• rcp openMosixprocs/openMosixprocs tu nodo:/usr/bin/openMosixprocs
Y ahora ya podremos ejecutar openMosixview con el comando openMosixview .
131
12. TESTS Y BENCHMARKS CON
OPENMOSIX
12.1 OpenMosix Stress Test
12.1.1 Descripción del Test Stress
Stress-Test es un Benchmarks Estándar de la Industria de computación de altas

prestaciones (HPC, High Performance Group) que mide las prestaciones del cluster o
de los diferentes ordenadores dedicados al cálculo intensivo.
Este stress-test está hecho para evaluar un cluster openMosix. Realizará
muchísimas evaluaciones a sus aplicaciones y a su kernel, para testear la estabilidad y
otras cuestiones relacionadas con openMosix (por ejemplo migración de procesos y
mfs). Durante este test el cluster se verá sobrecargado, es por eso que debería detener
cualquier otra aplicación que tenga corriendo antes de iniciarlo. Al finalizar se generará
un reporte detallado acerca de cada componente que ha sido evaluado.
Consta de 7 partes:
• DISTKEYGEN: Se encarga de generar 4000 pares de llaves RSA de 1024

bits utilizando todos los nodos del cluster.
• PORTFOLIO: Programa en PERL que simula conjuntos de acciones

distintos para un periodo de tiempo determinado.
• EATMEN: Calcula funciones sinusoidales y raíces cuadradas un millón de

veces mientras escribe en un archivo el valor del contador del bucle. Se
ejecuta tantas veces como nodos haya en el cluster.
• FORKIT: Similar a EATMEN con la excepción de que utiliza la llamada al

sistema "fork()" para crear múltiples procesos(3 veces el número de nodos
del cluster) y no escribe en ningún archivo.
• MFSTEST: Programa que se encarga de chequear el oMFS mediante la

creación de un archivo de 10 MB y la copia hacia y desde todos los nodos.
• MOVING: Mueve el script de arranque de todos los test

(start_openMosix_test.sh) a cada nodo del cluster una vez por minuto
durante su ejecución.
• TIMEWASTER: Realiza determinados cálculos numéricos.
132
12.1.2 Instalación
Descargar el paquete de pruebas Stress-Test para openmosix. Abres una consola

y te colocas en la raíz de donde te lo hayas descargado, por ejemplo: home/user/Desktop:
• gunzip ontest.tar.gz
• tar -xvf omtest.gz
Después cd /home/user/Desktop/omtest y ejecute:
• ./compile_tests.sh
Esto instalará los módulos y compilará los archivos necesarios. Necesitará

privilegios de administrador para ello (rot). Pudiendo luego correr el openMosix stress-
test como simple usuario (quizás deba ahora borrar los archivos temporales de la
ejecución como administrador de /tmp porque no tendrá permiso de sobrescribirlos
luego como simple usuario. Puede ejecutar el test con el siguiente comando:
• ./start_openMosix_test.sh
Usando un paquete RPM, se instalará con el siguiente comando:
• rpm -ihv omtest.rpm
Ahora puede iniciar el openMosix Stress-test con el siguiente comando:
• start_openMosix_test.sh
( el paquete RPM será instalado en /usr/local/omtest)
12.1.3 Analisis de los resultados
12.1.3.1 Realización de las pruebas con cluster (3 nodos)
Fecha de la prueba:
Sun May 9 13:40:58 CEST 2004 i686 GNU/Linux
En que nodo empieza el benchmark y cuantos nodos contiene el cluster:
test was started on node : 8

cluster contains 3 nodes
Tiempo en realizar cada prueba:
Timing from the application test
starting distkeygen at Thu Apr 26 20:18:45 EDT 2007

finished distkeygen at Thu Apr 26 20:24:57 EDT 2007
133
~ 6 minutos 12 segundos
starting portfolio at Thu Apr 26 20:24:57 EDT 2007

finished portfolio at Thu Apr 26 20:25:58 EDT 2007
~ 1 minuto 1 segundo
starting eatmem at Thu Apr 26 20:25:58 EDT 2007

finished eatmem at Thu Apr 26 20:27:19 EDT 2007
~ 1 minuto 22 segundos
starting forkit at Thu Apr 26 20:27:19 EDT 2007

finished forkit at Thu Apr 26 20:29:48 EDT 2007
starting timewaster at Thu Apr 26 20:29:48 EDT 2007

finished timewaster at Thu Apr 26 20:35:34 EDT 2007
starting oMFStest at Thu Apr 26 20:35:34 EDT 2007

finished oMFStest at Thu Apr 26 20:36:42 EDT 2007
output from the (local) kernel tests
running kernel+syscall on the local kernel

Versión de nuestro Sistema Operativo, kernel y diferentes programas utilizados.
/etc/issue:
Debian GNU/Linux testing/unstable \n \l
Gnu C gcc (GCC) 3.3.3 (Debian 20040429) Copyright (C) 2003 Free Software
Foundation, Inc. This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Gnu make 3.80

util-linux 2.12
mount 2.12a
modutils 2.4.26
e2fsprogs 1.35
pcmcia-cs 3.2.5
PPP 2.4.2
isdn4k-utils 3.3
134
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.1
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0.91
Modulos cargados, compilados y utilizados en el benchmark.
Modules Loaded
ext3 agpgart ds yenta_socket

jbd i810_audio pcmcia_core
ntfs ac97_codec fan button battery
autofs4 soundcore b44
af_packet serial rtc
nls_iso8859-1 mousedev cloop
nls_cp437 hid input sbp2
ohci1394 ieee1394 usb-storage
usb-uhci usbcore ataraid
ide-cd ide-scsi ac
Usando el comando free –m reports, uso de las distintos tipos de memoria:
free -m reports:
total used free shared buffers cached

Mem: 1006 535 471 0 8 369
-/+ buffers/cache: 157 848
Swap: 494 0 494
Características del ordenador servidor del cluster (quién empieza l operaciones).
/proc/cpuinfo
processor :0
vendor_id : GenuineIntel
cpu family :6
model :9
model name : Intel(R) Pentium(R) M processor 1500MHz
stepping :5
cpu MHz : 1498.752
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
135
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts
acpi mmx fxsr sse sse2 tm pbe tm2 est
bogomips : 2988.44
Salida para openMosix del Stress-Test con cluster de tres nodos:
the results will be saved in : /tmp/openMosix-stress-test-report-0704262008.txt
oMFS is mounted at /mfs and will be tested

migrated 18809 to node 10
my PID is 20116
~ mi identificador de proceso
start moving.sh on myself

running migrate-loop on process 20116
output from distkeygen test
~ migra el proceso 20116 al nodo 8


~ migra el proceso 20116 al nodo 10. Proceso migrado a tres nodos distintos,
dependiendo del balanceo de carga que el cluster otorgue a cada nodo, tendran una
carga mayor o menos, pero independientemente de esto los tres estan trabajando en
este momento sobre el mismo proceso.

CHILD: I'm finished here! 20197
~proceso migrado (hijo) acabado y muerto, pasa a ser zombi (es un proceso que ha
completado su ejecución pero aún tiene una entrada en la tabla de procesos,
permitiendo al proceso que le ha creado leer el estado de su salida).

136
PARENT: About to quit!
~proceso padre acabado, no es zombi.
output from portfolio test

started portfolio 1. time
output from eatmem test
starting an eatmem instance
output from forkit test
started forkit 1. time
starting 3 forkit instances
Proc 3 started.
~divide el proceso en varios, mediante el comando unix fork, actualmente tres

instancias.
Proc 0 started.
Proc 2 started.
Proc 1 started.
Proc 3 started.
Proc 2 started.
Proc 0 started.
Proc 1 started.
Proc 1 started.
Proc 2 started.
137
Proc 3 started.
Proc 0 started.
Proc 2 started.
Proc 1 started.
Proc 0 started.
Proc 3 started.
Proc 1 started.
Proc 2 started.
Proc 0 started.
Proc 3 started.
Proc 2 started.
Proc 0 started.
Proc 1 started.
Proc 3 started.
Proc 2 started.
Proc 1 started.
Proc 0 started.
Proc 3 started.
Proc 2 started.
Proc 1 started.
Proc 3 started.
138
Proc 0 started.
Proc 0 started.
Proc 2 started.
Proc 3 started.
Proc 0 started.
Proc 2 started.
Proc 1 started.
Proc 1 started.
Proc 3 started.
output from timewaster test
starting 3 timewaster processes 1. time
starting timewaster 0
finished successfully
139
140
output from oMFS test
cp /tmp/testfile.zero from here to node 10
cp /tmp/testfile.zero from mfs-node 10 to local
nodes equal! do not cp
cp /tmp/testfile.zero from mfs-node 8 to mfs-node 10
141
delete /mfs/10/tmp/testfile.zero
finished ok
12.1.3.2 Realización de las pruebas sin cluster (1 nodo)
Fecha de la prueba:



~ 2 minutos

~ 1 minuto 16 segundo.

~ 2 minutos 18 segundos.

starting oMFStest at Thu Apr 26 21:12:50 EDT 2007

finished oMFStest at Thu Apr 26 21:14:51 EDT 2007
142
/etc/issue:
PARTICULAR PURPOSE.
Gnu make 3.80

util-linux 2.12
mount 2.12a
modutils 2.4.26
e2fsprogs 1.35
pcmcia-cs 3.2.5
PPP 2.4.2
isdn4k-utils 3.3
Procps 3.2.1
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0.91
Modules Loaded

ide-cd ide-scsi ac
free -m reports:
143
Mem: 1006 535 471 0 8 369
Swap: 494 0 494
/proc/cpuinfo
processor :0
cpu family :6
model :9
stepping :5
cpu MHz : 1498.752
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
bogomips : 2988.44
Salida para Stress-Test con cluster de un nodo:
the results will be saved in : /tmp/ stress-test-report-0704262008.txt
oMFS is mounted at /mfs and will be tested

my PID is 23744
~mi identificador

~migra el proceso al nodo 8, en realidad el sistema ve que existe un cluster con un solo
nodo, es decir, migra procesos a ese nodo, pero al existir un único nodo para todo el
trabajo el reaparto de carga no es real.

144


Proc 1 started.
Proc 0 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
145
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 1 started.
Proc 0 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 1 started.
Proc 0 started.
146
output from oMFS test
finished ok
12.2 Test de OpenMosixview
12.2.1 Aplicación Principal
147
La explicación de este monitor la vamos a realizar mediante las capturaciones de
pantalla que hemos ido observando a lo largo de la realización del proyecto.
Ésta es la apariencia del programa con los tres nodos operativos:
Figura 10 openMosixview Aplicación Principal
En la primera columna vemos el identificador de cada nodo sobre color verde,

esto significa que el nodo está funcionando correctamente, si hubiera algún problema en
la detección del nodo o se encontrara apagado el ordenador, el color de fondo sería rojo.
A continuación nos encontramos con una segunda columna en la que vemos las ips
asignadas a cada uno de los ordenadores del cluster.
Los deslizadores nos permiten modificar la velocidad del nodo y en la siguiente

columna vemos la carga que soporta cada uno de los nodos. Si hacemos click en uno de
los botones con la ip de un nodo podemos visualizar o modificar las opciones "mosctl"
del nodo elegido. Modificando las barras de desplazamiento podemos cambiar la
velocidad de un nodo, un proceso migrará más fácilmente a un nodo con mayor
velocidad que a otro con menos velocidad. Al modificar estas barras no estamos
cambiando la velocidad física/real del procesador sino que cambiamos la velocidad que
openMosix "cree" que tiene el nodo con lo que podemos limitar el uso de CPU de un
nodo específico.
En la parte superior podemos ver una barra con el nombre de load balancing
efficiency, se trata de la eficiencia de balanceo que conseguimos con la configuración
actual de los nodos del cluster, cuando la configuración es buena conseguimos
eficiencias cercanas al 100%. En la parte superior de la ventana del openmosixview
tenemos un menú que nos permite guardar la configuración actual del cluster y lanzar
una aplicación para comprobar las estadísticas del uso de CPU de cada nodo o del
migrado de procesos. Estas aplicaciones las explicamos brevemente a continuación:
• openMosixprocs: Lista los procesos que tenemos actualmente en el cluster y

nos permite ver el número de veces que ha migrado.
148
• openMosixCollector: Se trata de un demonio que se encarga de guardar los
logs del cluster junto con información sobre los nodos. Esta información
será posteriormente utilizada por el openMosixanalyzer para generar las
estadísticas.
• openMosixanalyzer: Se trata de una aplicación que nos muestra gráficos

sobre el uso de CPU y gráficos sobre la carga de cada nodo y el total. Si
hiciéramos click sucesivamente en los botones del menú nos mostraría el uso
de memoria y la lista de procesos que se están ejecutando.
12.2.2 openMosixview por linea de comandos
Podremos especificar los argumentos a los que antes podíamos acceder

gráficamente a través de comandos en el lineedit-widget en la parte superior de la
ventana, tal como se muestra a continuación.
no migration iniciar un proceso local que no migrará

run home iniciar un proceso local
run on iniciar un trabajo en el nodo que
elijamos con ”nodo-chooser”
cpu job iniciar un proceso cpu-intensivo en el
nodo (nodo-chooser)
io job iniciar un proceso IO-intensivo en el
nodo (nodo-chooser)
no decay iniciar un proceso sin decay (nodo-
chooser)
slow decay iniciar un proceso con decay lento
(nodo-chooser)
fast decay iniciar un proceso con decay rápido
(nodo-chooser)
parallel iniciar un proceso paralelo en todos o
algunos nodos (special nodo-chooser)
Tabla 7 Linea de Comandos en openMosixview
12.3 openMosixprocs
149
La lista de procesos da una idea de lo que se está ejecutando y donde. La
segunda columna informa del ID del nodo donde se está ejecutando la tarea. Con un
doble clic sobre cualquier proceso invocaremos la ventana para administrar su
migración.
Un ’0’ significa ’local’, los demás valores significan ’remoto’. Los procesos
migrados están marcados con un icono verde y a los procesos que no pueden migrar se
les añade un una llave. Hay también varias opciones para migrar el proceso remoto:
enviarle las señales SIGSTOP y SIGCONT o simplemente cambiarle la prioridad, con
el comando “nice” por ejemplo. Si hacemos clic en el botón “manage procs from
remote” invocaremos a una ventana emergente (llamada remote-procs windows) que
nos mostrará el proceso actualmente migrado hacia ese nodo.
Figura 11 openMosixprocs
12.4 openMosixanlyzer
150
La siguiente figura nos muestra de forma gráfica la carga en el
openMosixanalyzer. Con el openMosixanalyzer tendremos un historial continuo de
nuestro cluster. Los historiales generados por openMosixcollector se mostrarán ahora de
forma gráfica, además de continua, lo que nos permitirá ver la evolución del
rendimiento y demás parámetros de nuestro cluster a través del tiempo.
openMosixanalyzer puede analizar los historiales a tiempo real (datos generados a
tiempo real) y evidentemente también puede abrir antiguos backups con el menú File.
Los historiales serán guardados en /tmp/openMosixcollector/* (y los backups los

tendremos en /tmp/openMosixcollector[date]/*) y sólo tendremos que abrir el historial
principal del cluster para visualizar antiguos historiales de informaciones de carga. (el
campo [date] en los ficheros de backup se refiere a la fecha en que han sido guardados)
La hora de inicio del backup podemos verla en la parte superior. Si utilizamos

openMosixanalyzer para tratar historiales a tiempo real tendremos que activar el check
refresh para que se actualice automáticamente.
Las líneas que indican la carga son normalmente de color negro. Si la carga se
incrementa a >75 las líneas se volverán rojas. Estos valores se obtienen desde los
ficheros /proc/hpc/nodes/[openMosix ID]/*.
El botón Find-out de cada nodo calcula diversos valores para las estadísticas. Si
lo clicamos abriremos una nueva ventana en la cual veremos las medias de la carga y
memoria y algunas informaciones adicionales (estáticas y dinámicas) sobre el nodo en
concreto.
Figura 12 openMosixAnalyzer I muestra la carga computacional en cada nodo del cluster.

A continuación podemos observar las estadísticas sobre todos los nodos del
cluster, la imagen superior es la estadística del servidor del cluster y las inferiores de los
otros dos nodos. Si hay checkpoints escritos en el historial (generado por
151
openMosixcollector) podremos verlos traducidos como líneas azules verticales. Esto
permite comparar valores de carga a posteriori de forma fácil.
Figura 13 openMosixAnalyzer II estadísticas sobre la carga de cada no del cluster.
12.5 openMosixmigmom
152
Se trata de un monitor para observar las migraciones dentro del cluster
openMosix. La siguiente imagen es un ejemplo de lo que hemos visto al ejecutar esta
aplicación:
Podemos ver mediante esta capturación que cada uno de los nodos está
representado por un círculo. Los puntos negros son los procesos que se están ejecutando
localmente (en este caso el nodo 8 tendría muchos procesos locales), los puntos verdes
son los procesos que hemos migrado (los nodos 9 y 10 habrían obtenido procesos del
nodo 8). Las líneas discontinuas nos indican el origen del proceso. Para realizar el
proceso de migrado tan solo tenemos que hacer clic sobre uno de los punto y arrastrar el
proceso hasta el ordenador que queremos que lo ejecute.
Figura 14 openMosixmigmom muestra las migraciones entre los diferentes nodos del cluster.
13. TEST DE CISILIA
153
13.1 Introducción
La ruptura de contraseñas mediante fuerza bruta (ir probando una a una hasta dar
con la adecuada) requiere contar con velocidades de procesamiento muy elevadas. Esto
puede lograrse, o bien contando con una supercomputadora o bien conectando muchas
computadoras de bajo costo, uniendo sus capacidades de procesamiento formando un
cluster.
Cisilia es un sistema de obtención de contraseñas en paralelo, ejecutable sobre

plataformas Linux, puramente escrita en lenguaje C. Obtiene contraseñas de sistemas
Windows NT/2000/XP o Samba mediante el cálculo de hashes DES/MD4 por fuerza
bruta en paralelo. Por ese motivo está programado como sistema multiproceso con la
capacidad de ejecutarse tanto en sistemas multiprocesador (SMP) como en clusters de
PC´s del tipo "balanceo de carga". Dicha ejecución en paralelo se realiza a través de la
función fork() [BUSCAR O ELIMINAR].
Cisilia asigna dinámicamente los espacios discretos de contraseñas que va a

calcular cada subproceso y crea los "n" subprocesos hijos. Si cisilia se ejecuta en un
cluster del tipo "balanceo de carga", los diferentes subprocesos son migrados
automáticamente a los diferentes nodos aumentando así la velocidad total de cálculo.
Esto se debe a que cumple con las condiciones que OpenMosix establece para
que un sistema de esta naturaleza pueda ejecutarse en paralelo sin problemas.
13.2 Instalación
154
13.2.1 ¿Cómo conseguir cisilia?
En la siguiente página web se podrá encontrar la última versión, en formato

tar.gz, para poder descargarla.
• http://www.citefa.gov.ar/si6/cisiliaDescargas.htm
13.2.2 ¿Cómo instalar cisilia?
A continuación se verán los pasos a seguir para una correcta instalación. En

realidad es muy sencillo, son sólo tres pasos:
* descomprimir el paquete cisilia-version.tar.gz, esto se realiza con el comando tar, un

ejemplo sería
tar -xzvf cisilia-0.7.3.tar.gz
* al descomprimir se creará un directorio con el nombre cisilia-version, entonces

siguiendo el ejemplo se debe ejecutar
cd cisilia-version
./configure
* y finalmente;
/make
/make install
13.3 Ejecución del test
155
A continuación se muestra la ejecución de cisilia en cuatro benchmarks
realizados según la clave que se quiera descifrar. Obtendremos las contraseñas archivo
pwfileXdigitos, siendo la X el número de digitos de la clave y con 4 procesos hijos.
Ejecución de cisilia para un archivo de contraseñas sin claves:
• La linea de comando que se debe ejecutar es la siguiente:
./cisilia –l crack_file –n 4 /home/Desktop/pwfilessinclaves
o – l: agrega las contraseñas obtenidas a archivo_diccionario durante la

ejecución.
o - n: define el número de subprocesos de fuerza bruta. El número
predeterminado es 1.
o /home/Desktop/pwfilessinclaves. Ruta en la que se encuentra el archivo
con las contraseñas.
Figura 15 Cisilia Sin Contraseñas
Se puede observar el tiempo que ha utilizado el cluster para resolver el problema,

este tiempo es de 227 milésimas, tiempo más bien insignificante, los dos nodos del
cluster vienen definidos por Invitado y Clouter.
Ejecución de cisilia para un archivo de contraseñas con una clave de 4 digitos:
./cisilia –l crack_file –n 4 /home/Desktop/ pwfile4digitos

ejecución.
o /home/Desktop/pwfile4digitos. Ruta en la que se encuentra el archivo
Figura 16 Cisilia Contraseña 4 dígitos
El tiempo que ha utilizado el cluster para resolver la clave “abcd”, es de 235

milésimas, que otra vez vuelve a ser un tiempo más bien insignificante, a pesar de que
156
esta vez el archivo contiene una clave, los dos nodos del cluster vienen definidos por
Invitado y Clouter.

ejecución.
Figura 17 Cisilia Contraseña 6 dígitos
El tiempo que ha utilizado el cluster para resolver la clave “cSfRgH”, es de 5

minutos, 1 segundo y 387 milésimas, es destacable que diferencie entre mayúsculas y
minúsculas y que el tiempo estimado sea tan poco para una clave de 6 dígitos, los dos
nodos del cluster vienen definidos por Invitado y Clouter.

ejecución.
Figura 18 Cisilia Contraseña del Administrador y otra de 8 dígitos
El tiempo que ha utilizado el cluster para resolver la clave “cSfRgHsw”, es de 5

horas, 47 minutos, 32 segundo y 802 milésimas y para clave del administrador
“wuachuwua”es de 7 horas, 11 minutos, 46 segundo y 651 milésimas, en este caso
157
considera también la diferencia entre mayúsculas y minúsculas pero al incrementar el
tamaño de la clave el tiempo que estima en averiguarla es mucho mayor, se puede ver la
diferencia entre las dos claves siendo la segunda de un dígito más, los dos nodos del
cluster vienen definidos por Invitado y Clouter.
158
159
CAPITULO IV
STALLMAN, RICHARD
- “El software libre se convertirá en pocos años en un fenomeno comparable con lo que
fue Internet a mediados de los 90“
160
14. OPENSSI
14.1 Introducción a SSI
La meta del software SSI es proporcionar un ambiente escalable, disponible y

manejable del servidor del cluster. La idea es que un conjunto de máquinas (cluster)
simule un comportamiento de una única maquina muy potente.
El modelo del sistema de archivos es absolutamente SSI, teniendo un sistema de

archivos principal y una visibilidad automática de todos los sistemas de archivos en
todos los nodos. Están soportados por el sistema los dispositivos remotos de acceso y
cada nodo tiene su propio sistema de dispositivos (vía devfs); el espacio swap no es
particularmente SSI, puesto que cada nodo tiene su propio espacio swap.
Todos los procesos del cluster tienen pids únicos y el control de cada proceso es
totalmente SSI. Las sesiones y los grupos del proceso pueden ser distribuidos, al igual
que los pares del padre-hijo. En cuanto a los usuarios, los administradores y los
procesos tienen visibilidad completa y tienen acceso a todos los procesos en todos los
nodos, como si de una única máquina grande se tratara. El proceso se puede lanzar en
otros nodos de diferentes maneras y puede incluso migrar de nodo a nodo mientras que
estos están funcionando, con /proc se muestra todos los procesos en todos los nodos
pero el non-process de /proc muestra toda la información local (e.g. cpuinfo, meminfo,
etc.).
El modelo de red está dividido en dos partes, en la primera, cada nodo tiene una
o más direcciones, una de éstas se utiliza como comunicación del núcleo-a-núcleo para
apoyar el SSI, esta dirección se puede también utilizar para el MPI o para la
comunicación del uso del nodo. En la segunda parte, para simular que las maquinas del
cluster parezcan una sola, existe el CVIP o cluster alias, en caso de que el nodo
principal del cluster se desconecte dará error.
En el software SSI existen dos formas de balanceo de carga: según las

conexiones de red entrantes, que balancean su carga usando capacidad de HA-LVS y
según los procesos, que cuya carga se balancea de forma nivelada por el subsistema,
dicha nivelación de la carga se realiza en tiempo de ejecución.
Toda la comunicación entre procesos (IPC) se realiza gracias a un espacio de

nombres para los semáforos, mensaje de cola y memoria compartida, que se pueden
utilizar en cualquier nodo.
En este sistema no existen nuevos comandos, la idea que es que sólo los
comandos estándares del sistema sean los más utilizados, entre ellos se encuentra el
comando para ver la calidad de nodo del cluster, existen otros que son utilizados para
lanzar procesos a otros nodos del cluster (onnode, onall, ayuna, emigra), para saber los
procesos que están realizándose en cada nodo exite el comando “where_pid”. También
existen un par de comandos para controlar la nivelación de la carga (loads, loadlevel) y
un comando para arrancar otros programas en un modo de “localview” (vista local).
161
La programación en un SSI no necesita ninguna llamada específica, sin embargo,
libcluster.so y cluster.h hacen algunas de las funciones específicas de un cluster. En
libcluster.so existe el rexec (), el rfork () y migrate (), éste último se utiliza como una
llamada que migra un proceso a otros nodos, aunque también existen llamadas para
comprobar la calidad de miembro del cluster, consiguiendo la información sobre todos
los nodos del cluster y para conseguir una historia de la calidad del miembro del cluster.
162
14.2 ¿Qué es OpenSSI?
OpenSSI apareció en los inicios del siglo XXI, más exactamente en el 2001, esta
basado en los proyectos Non-Stop Cluster de UnixWare (referencia) y Locus
(referencia). Bruce Walker, director del proyecto y principal desarrollador de openSSI,
dejó bien claro que el propósito era crear una plataforma para poder integrar tecnologías
de clusters, con código abierto.
La última versión de OpenSSI tiene integrados varios archivos del sistema y

manejo de sistemas de disco en código abierto, como por ejemplo GFS, OpenGFS,
Lustre, OCFS, DRBD, también integra un mecanismo de bloqueo distribuido
(OpenDLM) y una política para conseguir la nivelación de carga, siendo esta una
característica importante heredada de Mosix.
OpenSSI permite balancear la carga de un cluster dinámicamente, mediante el

uso de migración de procesos, otra característica también heredada de Mosix. El
módulo de migración de procesos en OpenSSI utiliza un mecanismo de acceso al
recurso remoto manteniendo los recursos de acceso del sistema bloqueados para que
estos no puedan ser migrados. Este mecanismo se usa principalmente en IPC (interfaz
de la tarjeta de red), CFS (sistema de archivos del cluster) y también para algunas
llamadas al sistema.
163
14.3 ¿Por qué se ha elegido OpenSSI?
A la hora de realizar la comparativa, nos fijamos como meta que fuera lo más
detallada, precisa y significativa posible. De esta manera elegimos openMosix y
también su antagonista y principal rival: OpenSSI.
OpenMosix, tuvo en su momento una gran ventaja sobre todos los sistemas de
clustering de su época (años ochenta) fue ni más ni menos que el primero de todos los
modernos sistemas de clustering. Pero, OpenSSI, a diferencia del resto de los sistemas
adaptados al sistema operativo más usado en computación (Unix/Linux) planta cara a
OpenMosix en números, estadísticas y también en uso en supercomputación. Es por
tanto esa rivalidad entre OpenMosix y OpenSSI, la interesante de analizar con cada
actualización, nuevas funcionalidades o simplemente con los distintos comportamientos
y distintas maneras de trabajar de cada uno.
Sabemos ya que OpenMosix es el sistema de clustering más conocido y usado,

sin embargo, aunque es difícil luchar contra un sistema plenamente acogido,
desarrollado y mejorado por muchísima gente de diferente índole, OpenSSI, con cada
actualización de Kernel nueva va ganando más adeptos y haciendose un hueco entre el
mundo de la supercomputación.
164
A continuación se muestran las características más importantes de OpenSSI:
• Manejo y administración del dominio de forma sencilla.

• Sistema de archivos de la raíz generado a través del cluster de forma sencilla.
• Copia sencilla de archivos binarios, librerías y administradores (como una
contraseña).
• Se puede manejar los procesos por todo el cluster de manera sencilla según su PID.
• El nombre del cluster está disponible para todos los objetos del IPC.
• Contiene un dispositivo de acceso al cluster
• Nombrado de entidades consistente a lo largo de los nodos.
• Los archivos de acceso a todos los nodos son completos y públicos.
• La tecnología del sistema de archivos del cluster la tiene integrada y le provee
flexibilidad y elección.
• Las interfaces del núcleo permitirán otra tecnología que esté desarrollada en código
abierto.
• Está disponible un sistema de archivos del cluster con un failover público.
• El nombre y la dirección del cluster será altamente disponible, pudiéndose acceder a
el siempre.
• La migración de procesos se puede realizar de forma completa incluyendo las
llamadas al sistema.
• El balanceo de carga de un proceso se realiza en tiempo de ejecución.
• Incluye un conjunto de características de disponibilidad.
o Monitorización y reinicio del proceso.
o Servicio automático de failover.
o Sistema de archivos automáticos del failover.
o Dirección IP del cluster, majeno de la conexión y la habilidad de perder el
nodo inicio sin matar a los procesos que están corriendo.
o Garantía y un API para los miembros que usan una infraestructura de un
Cluster bajo Linux.
o Un API para migrar los procesos según los métodos: rexec() y fork()
o Nodos que no necesitan discos gracias al arranque por red.
14.5 Limitaciones
165
En OpenSSI hay que tener en cuenta ciertas limitaciones para que funcione
correctamente, a continuación se muestra un listado de las limitaciones que se deben
cumplir:
• Miembros del cluster: El número máximo de nodos en un cluster es de 125.

• El sistema de archivos de un cluster (CFS): Tamaño máximo de ficheros, número
máximo de ficheros, direcciones y sistemas de archivo físicos inherentes.
• UID/GID: 16-bit en OpenSSI-1.2. 32-bit en OpenSSI-1.9.
• Tipos de dispositivos principales: 255 en OpenSSI-1.2. 4095 en OpenSSI-1.9.
• Tipos de dispositivos secundarios: Número máximo de puntos de montaje por tipo
de sistema de archivos. 8-bit in OpenSSI-1.2. 20-bit in OpenSSI-1.9.
• IPC: Máximo número de semáforos compartidos.
• Sockets: Máximo número de sockets.
• Procesos: Máximo número de procesos. 32,000 en OpenSSI-1.2 y 1
billion(americano) en OpenSSI-1.9.
• PTY: Máximo número de pty´s.
• HA-LVS: Máximo número de conexiones, de directorios, de CVIP. Igual que el
original LVS, millones de conexiones.
• DRBB-SSI: Máximo tamaño del volumen por dispositivo de drbd, máximo de
dispositivos drbd. Igual que el original DRBD.
14.6 Instalación de un cluster OpenSSI
166
Estas son las instrucciones para instalar OpenSSI bajo Debian, es necesario
cumplir al menos estos requisitos, 20MB de memoria RAM y 100MB de espacio en
disco, siendo éstos los de hardware mínimos, puesto que es un sistema basado en
consola. Se necesita tener como mínimo dos ordenadores que serán los nodos y se
conectaran entre ellos mediante una red privada.
En esta configuración el primer nodo que se ha configurado, será el nodo raíz del
sistema de archivos y estará compartido con el resto de los nodos mediante la red
privada que se ha mencionado anteriormente.
Instalación del software de OpenSSI
OpenSSI se ha instalado mediante un apt-get bajo Debian, siguiendo los siguientes

pasos:
1. Se añade las siguientes direcciones web al archivo situado en: /etc/apt/sources.list
deb http://deb.openssi.org/v1 ./
deb-src http://deb.openssi.org/v1 ./
2. Se añade las siguientes direcciones web al archivo situado en: /etc/apt/preferences
Package: *
Pin: origin deb.openssi.org
Pin-Priority: 1001
3. A continuación se ejecuta las siguientes instrucciones:
# apt-get update
# apt-get dist-upgrade
Estas instrucciones sirven para descargar algunas novedades de OpenSSI, puesto

que necesita una nueva versión para alguna de sus utilidades.
4. Es necesario añadir la lista de controladores en el fichero modules que se encuentra

en la siguiente carpeta: /etc/mkinitrd/. Generalmente mkinitrd configura el fichero
modules pero si no es así se tendrá que añadir a dicho fichero:
# insmod ext3
# modprobe ext3
Estas líneas debería funcionar para cualquiera que usara nuestra versión de kernel
Debian si no es así seguramente le de un kernel-panic.
5. Ejecutar la siguiente instrución:
167
# apt-get install openssi
Dicha instrución instalará openssi y creará el primer nodo, al que se le llamará el

nodo de inicio del cluster. Mientras se crea el primer nodo, como parte de la
instalación se usará la instrución
ssi-create
Dicha instrucción mostrará un listado de preguntas relacionadas con la

instalación del cluster que son las siguientes:
1. Introduzca un número de nodo entre 1 y 125.
Cada nodo debe poseer un único numero de nodo, el primer nodo o nodo de
inicio normalmente suele ser el número 1, puesto que lo asigna de manera
predefinida, este numero otorga al nodo una dirección física dentro del
cluster, por lo que si es el segundo nodo que se introduce se debe elegir un
numero diferente a 1 en este caso.
2. Selecciona una Interfaz de la Tarjeta de Red para interconectar el cluster.
En este caso se debe introducir una dirección IP y una mascara de red, en el

caso de que la tarjeta de red no haya sido configurada se debe reiniciar en
otra consola.
Para una mejor seguridad a la hora de conectar el nodo, la interfaz de la

tarjeta de red debe ser conectada a una red privada. Ésta debe tener un
chipset que soporte PXE o Etherboot.
3. Seleccionar (P)XE o (E)therboot como un protocolo de arranque para la

red para este nodo.
PXE es un estándar de Intel para el arranque de la red, y muchos de los

interfaces de las tarjetas de red profesionales tiene la implementación de
PXE preinstalada en ellos. El PXE puede habilitarse en la configuración de
la BIOS al arranque del nodo. En el caso de que el interfaz de la tarjeta de
red no tenga PXE, existe la posibilidad de usar mediante el proyecto de
código abierto Etherboot, el cual permite generar un disco duro o una
imagen de memoria ROM, para varios interfaces de tarjetas de red.
OpenSSI incluye una versión integrada del Servidor Linux Virtual ("LVS"),
que permite configurar un cluster mediante una IP Virtual ("CVIP"). Este
CVIP está disponible y puede ser configurado para moverlo a otro nodo en
caso de algun fallo.
4. Introduzca el nombre del cluster.
En este caso se introduce un nombre para el cluster. El nombre del host se

asignara de forma predefinida como nombre del cluster por este nodo.
168
5. Seleccionar que se desea cuando se habilita el sistema de archivos raiz en
caso de fallo.
El sistema de archivos raíz debe ser instalado en un disco compartido cuando

se responda que SI a esta pregunta. En el caso de que la respuesta sea NO,
entonces cada vez que se añada un nuevo nodo, preguntará si el nodo está
conectado físicamente al sistema de archivos raíz y si se debería configurar
como fallo del nodo raíz.
6. Se instalará un simple mecanismo de sincronización del cluster. En algún

momento el nodo cuando arranque, se sincronizará con el nodo de inicio
(nodo que siempre estará funcionando). Aún así se puede arrancar la
sincronización y se forzará la sincronización de todos los nodos con el
nodo de inicio mediante el siguiente comando:
ssi-timessync
Este comando sincroniza todos los nodos con una diferencia de un segundo o
dos con cada nodo. Si se quiere una precision mayor entones se debe
configurar el NTP, Protocolo de Tiempo de Red ("NTP") a través del cluster.
7. El balanceo de carga de un proceso automático será instalado como parte

de OpenSSI. Para habilitar el balance de carga se deberá hacer acceder al
archivo situado en la siguiente dirección /cloutser/etc/loadlevellist. El
programa “bash-ll” tiene que estar en el archivo anterior por defecto.
Entonces para permitir el balanceo de carga para cada programa que esté
funcionando mediante consola, se ejecutará un programa en la consola según
lo siguiente: “/bin/bash-ll”.
# ln /bin/bash /bin/bash-ll
8. Para arrancar openssi mediante ventanas X. Escribir:
startx
9. Reiniciar el primer nodo del cluster.
Añadir nuevos nodos
Los nodos en un cluster OpenSSI son arrancados usando el método de arranque bajo red.
Este método evita el costoso trabajo de instalar una distribución en cada nodo que se
desea incluir en el cluster. Para el arranque de red de un nuevo nodo, primero se debe
seleccionar una de las interfaces de la tarjeta de red, para la red del cluster, donde el
chip del nodo debe soportar PXE o Etherboot.
1. Si el nodo que se desea incorporar al cluster no soporta PXE, se debe descargar

la imagen Etherboot correspondiente, en la siguiente dirección web se podrá
descargar la del nodo en cuestión.
http://rom-o-matic.net/5.2.4/
169
A continuación se debe elegir el chip apropiado del nodo. En la pestaña
Configuración se debe seleccionar 0 y en Floppy Bootable ROM Image se
selecciona “Single”.
2. Si el nodo que se desea meter en el cluster no tiene un controlador de red de los

de la lista anterior, entonces se deberá introducir de forma manual el nombre del
controlador, en el siguiente archivo: /etc/mkinitrd/modules, estando localizado
en el nodo de inicio. Después se reiniciará el disco que incluye el archivo con el
controlador y las imagenes de arranque. A continuación se muestran los
comandos que se debe utilizar en este punto explicativo.
# mkinitrd -o <init RD image file> <kernel-version>
# ssi-ksync
Nota:
initrd y el nucleo de openssi serán instalados durante la instalación de openssi

en la siguiente ruta /boot del nodo de inicio. Para el arranque de PXE, se
realizará de forma manual siguiendo los pasos que vienen a continuación.
# apt-get install syslinux
# cp /usr/lib/syslinux/pxelinux.0 /tftpboot
Se ha observado que el tftpd-hpa o el atftpd trabajan major con etherboot o PXE.

Por lo que es recomendado instalar tftp-hpa o atftpd. La entrada para ``tftp'' en
el archivo /etc/inetd.conf deberia tener como directorio raiz ``/tftpboot”, este
paso siempre se debe comprobar de segundas puesto que en el caso de que no
sea correcto entonces tftp-hpa cogera un valor por defecto y después se tendra
que modificar el siguiente archivo /etc/inetd.conf. Si se instala atftpd, después se
puede reconfigurar usando el siguiente comando:
``dpkg-reconfigure atftpd``
En el directorio que se esta hablando será donde esté el núcleo y las imagenes
initrd estarán disponibles para otros nodos siempre y cuando se utilice el
método del arranque de red. A continuación se muestra un ejemplo:
Ex: tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd -

s /tftpboot
Si el tftp-hpa aparece como usado, entonces cambiar a 'nobody' en 'root' como

en el ejemplo anterior.
3. Conectar la interfaz de la tarjeta de red seleccionada a la red del cluster, despues

insertar el disquete de Etherboot y reiniciar el ordenador. A continuación
mostrará la dirección del interfaz de la tarjeta de red entonces se debe esperar a
que el servidor DHCP responda.
170
4. En el primer nodo, o en cualquier nodo que esté en el cluster, se debe ejecutar:
ssi-addnode
La consecuencia de ejecutar el siguiente comando será la aparición de un listado

de preguntas para configurar el nuevo nodo.
1. Introduzca un número de nodo entre 1 y 125.
2. Introduzca la MAC del nodo que se desea añadir al cluster
3. Selecciona una Interfaz de la Tarjeta de Red para interconectar el cluster.
En este caso se debe introducir una dirección IP.
4. Seleccionar (P)XE o (E)therboot como una protocolo de arranque para

la red para este nodo.
PXE es un estándar de Intel para el arranque de la red, y muchos de los

interfaces de las tarjetas de red profesionales tiene la implementación de
PXE preinstalada en ellos. El PXE puede habilitarse en la configuración
de la BIOS al arranque del nodo. En el caso de que el interfaz de la
tarjeta de red no tenga PXE, existe la posibilidad de usar mediante el
proyecto de código abierto Etherboot, el cual permite generar un disco
duro o una imagen de memoria ROM, para varios interfaces de tarjetas
de red.
5. Introduzca el nombre del cluster.
En este caso se introduce un nombre para el cluster. El nombre del host

se asignara de forma predefinida como nombre del cluster por este nodo,
pero en este caso se le asigna “cloutser”.
6. Seleccionar que se desea cuando se habilita el sistema de archivos raíz en

caso de fallo.
El sistema de archivos raíz debe ser instalado en un disco compartido

cuando se responda que SI ha esta pregunta, en el caso de que la
respuesta sea NO, entonces cada vez que se añada un nuevo nodo,
preguntará si el nodo está conectado físicamente al sistema de archivos
raíz y si se debería configurar como fallo del nodo raíz.
7. Guardar la configuración realizada.
8. El programa admite el nuevo nodo en el cluster y se lo comunica al nodo

de inicio mediante el siguiente mensaje: “nodeup”, se puede confirmar
que este nodo pertenece al cluster mediante el siguiente comando:
171
# cluster -v
Figura 19 OpenSSI Segundo nodo añdido y cargado al cluster
En el caso de que el nuevo nodo, no se conecte al servidor mediante

DHCP, se pueden reiniciar esta conexión manualmente, desde el nodo de
inicio del cluster, donde está corriendo el servidor, ejecutando el
siguiente comando:
# invoke-rc.d dhcp restart
NOTA: Se ha observado que algunas veces que la conexión al servidor

mediante tftp no se puede realizar, entonces es recomendable que se
reinicie la inetd, desde el nodo inicio del cluster, asi de esta manera el
nodo que se desea conectar podría obtener la dirección IP. El comando
que se debe utilizar en este caso es el siguiente:
# invoke-rc.d inetd restart
9. En el siguiente paso, se indica como se debe configurar el hardware del

nuevo nodo, incluyendo a su vez el espacio de memoria compartida, el
dispositivo de arranque local, (parte opcional, en el caso que la
configuración del nodo raiz falle) y una interfaz de la tarjeta de red
externa.
a. Configurar el nuevo nodo con uno o más dispositivos

compartidos, mediante el fdisk (o herramienta similar) y mkswap:
# onnode <node_number> fdisk /dev/hda (device name)
partition disk
# onnode <node_number> mkswap /dev/hda3 (device partition na

me)
172
Añadir el nombre del dispositivo al archivo /etc/fstab.
Se reiniciará el nodo de forma automática o manualmente se

activará dicho dispositivo mediante el comando swapon
# onnode <node_number> swapon <swap_device>
b. Si se tiene permiso al failover de la raiz, se debe configurar un

dispositivo local de arranque en el nodo, éste debe tener el mismo
nombre que el dispositivo del nodo de inicio, hay que recordar
que el dispositivo de arranque del nodo de inicio está en la
primera partición de éste (ejemplo /dev/hda1 or /dev/sda1). De
todas formas la cofiguración de este dispostivo es opcional.
Despues de haber creado la partición con el fdisk, hay que

formatearla con un archivo de sistemas de Linux, como ext3:
# onnode <node_number> mkfs.ext3 /dev/hda1
A continuación arrancar mediante:
ssi-chnode
Seleccionar el nuevo nodo, introducir el nombre del dispositivo

de arranque local y:
ssi-chnode
copiará los archivos que sean necesarios.
Al final se necesita instalar el GRUB de arranque en el nuevo nodo

mediante las siguientes instrucciones.
# onnode <node_number> grub --device-

map=/boot/grub/device.map
grub> root (hd0,0)
grub> setup (hd0)
grub> quit
10. Repetir todos estos pasos cuando se quiera añadir un nuevo nodo al
cluster.
Errores conocidos y soluciones
173
1. Mientras se crea la imagen initrd como parte de la instalación de openssi, se
pueden observar los siguientes mensajes
cpio: ./dev/cciss: No such file or directory
cpio: ./dev/ide: No such file or directory
cpio: ./dev/mapper: No such file or directory
cpio: ./dev/md: No such file or directory
cpio: ./dev/scsi: No such file or directory
Estos mensajes no significa ningún error, sino que intenta acceder a estos
archivos y que no los encuentra, pero no implica que todo esté correctamente y
como resultado final OpenSSI se haya instalado con éxito.
Estas son algunas de las capturas que se han obtenido a lo largo de todo el proceso:
En la imagen siguiente se puede observar el estado del cluster, compuesto por

dos nodos, “clout” y “ser” y los procesos que se están realizando en cada uno de ellos,
el tiempo que llevan ejecutándose, el consumo de CPU que tienen sobre el nodo raíz,
que en este caso es “clout”.
Figura 20 OpenSSI vista general del cluster
En esta otra imagen se obtiene las características generales y técnicas del nodo2
del cluster.
174
Figura 21 OpenSSI Características del nodo 2
15. OPENSSI WEBVIEW
15.1 Introducción
La herramienta openSSI webView destaca por ser sencilla y de fácil uso para un
sistema de cluster SSI. Su objetivo es proporcionar una descripción rápida del estado
del cluster, representando funciones gráficas sobre los nodos del cluster. Permite que el
administrador del cluster maneje el uso del cluster, pueda visualizar la carga de cada
uno y su estado en cada momento que se desee. En cuanto a los procesos el
administrador del cluster puede migrarlos a diferentes nodos del cluster.
Las características de esta herramienta de openSSI son las siguientes:
• Supervisión del sistema
o Descripción de estado del cluster

o Detalles de todos los nodos, incluyendo la información del hardware y su
estado.
175
o Herramientas gráficas RRD para mostrar por pantalla los valores de cada
nodo del sistema.
o Vista gráfica general del sistema y los valores del cluster en cada
momento.
• Manejo de procesos
o Lista de procesos e información que se incluye en el cluster.

o Habilidad de migrar procesos de los usuarios.
• Características del sistema

o Alta velocidad para el acceso de datos de la caché.
o Scripts de PHP para mostrar los datos.
15.2 Instalación
A continuación de muestran los pasos para una correcta instalación de openSSI

webview:
o Extraer la distribución de la siguiente dirección e instalar en el directorio

/home/Desktop/openssi-webview/
http://sourceforge.net/projects/openssi-webview/
$ cd /home/Desktop/openssi-webview/
$ tar xfvj openssi-webview-0.1.tar.bz2
o Colocar los permisos correctos en sobre el directorio de “graphs”, para cuando

se genere el gráfico y sobre “config.php” para poder permitir modificar y
guardar las propiedades de la interfaz web.
$ cd /home/Desktop/openssi-webview/
$ chown -R www-data graphs
$ chown www-data config.php
176
El usuario que se ha introducido es “www-data” puesto que para Debian es el
más recomendado.
o En el directorio /etc, existe un fichero llamado crontab que se debe modificar,

aunque también existe la posibilidad de crear uno nuevo en /etc/cron.d/, a
continuación se muestra la linea que se ha introducido.
*/5 * * * * www-data [ -d /home/Desktop/openssi-webview/ ] && (cd

/home/Desktop/openssi-webview/ && ./graphs/update_all.sh )
o Se ha configurado un servidor web, en este caso Apache, para poder visualizar

los contenidos de la siguiente manera:
Alias /openssi-webview /usr/share/openssi-webview
o Al finalizar se ha escrito lo siguiente en una ventana del explorador de internet
http://localhost/openssi-webview
15.3 Requisitos
• Específicos
o PHP >= 4.1.0

o RRDTool para mostrar los gráficos
• Generales:
o Un servidor web en este caso Apache

o openSSI
o Un cron daemon
o Un explorador web
• Opcional:
177
o php-rrdtool puede mejorar el funcionamiento en la creación de los
gráficos
o sudo; permite la migración de los procesos
15.4 Vista gráfica de la aplicación
En la siguiente imagen de ésta aplicación, se muestra una vista general o global

del cluster, lo que se llama “cluster map” o archivo de configuración cluster.map,
muestra información tal como ip de cada nodos, número de nodos, recursos opcupados.
Haciendo click sobre un nodo se puede ver sus características (Véase Figura 23).
178
Figura 22 openSSI webview cluster map
Esta imagen es la descripción de algunas de las características de un nodo

seleccionado. Algunas de las características mostradas son el estado del nodo
(encendido o apagado), primer y último proceso migrado.
Figura 23 openSSI webview node 3
Para una vista donde nos muestra la carga que esta soportando cada nodo, está la opción
“overview”, que se puede seleccionar en el panel de la izquierda. En esta imagen se
puede observar como el nodo 1, el principal, el más potente puede soportar la mayor
carga posible, mientras que el nodo 2 y 3 la carga que pueden soportar es menor en el
nodo 2, pero aún menor en el nodo 3.
179
Figura 24 openSSI webView overview cluster
La siguiente imagen muestra una vista general de todas las opciones que se
pueden utilizar para la administración del cluster, siendo cada una de las opciones un
gráfico:
CPU usage: indica el consumo de la CPU. Las medidas de la gráfica son: tiempo
(parte inferior) y porcentaje de carga (parte izquierda).
Load average: muestra una gráfica con la carga que tiene el cluster o nodo,
según la selección que se haga para ver. Las medidas son tiempo (parte inferior) y
MegaHerzios (parte izquierda).
Memory usage: muestra una gráfica con la memoria que se está utilizando según
los procesos que se estén utilizando. Las medidas de la gráfica son: tiempo (parte
inferior) y Mbytes (parte izquierda).
Swap usage: muestra una gráfica con la memoria que tiene compartida el nodo o
el cluster, según selección. Las medidas de la gráfica son tiempo (parte inferior) y gigas
usado de RAM (parte izquierda)
Processes: muestra un listado de todos los procesos que se estan ejecutando en el

nodo o en el cluster indicando cúal en cada nodo, según la selección.
Network traffic:
180
Figura 25 openSSI webView stats
Figura 26 openSSI web View overview Node 1
16. TESTS Y BENCHMARKS CON OPENSSI
16.1 OpenSSI Test Stress
16.1.1 Descripción del Test Stress
Stress-Test es un Benchmarks Estándar de la Industria de computación de altas

prestaciones (HPC, High Performance Group) que mide las prestaciones del cluster o
de los diferentes ordenadores dedicados al cálculo intensivo.
181
Se realizará muchísimas evaluaciones a sus aplicaciones y a su kernel, para
testear la estabilidad y otras cuestiones relacionadas con OpenSSI (por ejemplo
migración de procesos y mfs). Durante este test el cluster se verá sobrecargado, es por
eso que debería detener cualquier otra aplicación que tenga corriendo antes de iniciarlo.
Al finalizar se generará un reporte detallado acerca de cada componente que ha sido
evaluado.
Consta de 7 partes:
• DISTKEYGEN: Se encarga de generar 4000 pares de llaves RSA de 1024

bits utilizando todos los nodos del cluster.
• PORTFOLIO: Programa en PERL que simula conjuntos de acciones

distintos para un periodo de tiempo determinado.
• EATMEN: Calcula funciones sinusoidales y raíces cuadradas un millón de

veces mientras escribe en un archivo el valor del contador del bucle. Se
ejecuta tantas veces como nodos haya en el cluster.
• FORKIT: Similar a EATMEN con la excepción de que utiliza la llamada al

sistema "fork()" para crear múltiples procesos(3 veces el número de nodos
del cluster) y no escribe en ningún archivo.
• SSIFSTEST: Programa que se encarga de chequear el oSSIFS mediante la

creación de un archivo de 10 MB y la copia hacia y desde todos los nodos.
• MOVING: Mueve el script de arranque de todos los test

(start_openSSI_test.sh) a cada nodo del cluster una vez por minuto durante
su ejecución.
• TIMEWASTER: Realiza determinados cálculos numéricos.
16.1.2 Instalación
Descargar el paquete de pruebas Stress-Test para OpenSSI. A continuación te

ubicas en el directorio raíz donde se ha descargado el paquete, por ejemplo en el
escritorio: home/user/Desktop:
• gunzip ossitest.tar.gz
• tar -xvf ossitest.gz
Después cd /home/user/Desktop/ossitest y ejecute:
182
• ./compile_tests.sh
Esto instalará los módulos y compilará los archivos necesarios. Necesitará

privilegios de administrador para ello (root). Pudiendo luego correr el OpenSSI stress-
test como simple usuario (quizás deba ahora borrar los archivos temporales de la
ejecución como administrador de /tmp porque no tendrá permiso de sobrescribirlos
luego como simple usuario. Puede ejecutar el test con el siguiente comando:
• ./start_openSSI_test.sh
Usando un paquete RPM, se instalará con el siguiente comando:
• rpm -ihv omtest.rpm
Ahora puede iniciar el openSSI Stress-test con el siguiente comando:
• start_openSSI_test.sh
( el paquete RPM será instalado en /usr/local/omtest)
16.1.3 Analisis de los resultados
16.1.3.1 Realización de las pruebas con cluster(3 nodos)
Fecha de la prueba:
Thu May 17 17:39:05 CEST 2004 i686 GNU/Linux

starting distkeygen at Thu May 17 17:39:05 EDT 2007

finished distkeygen at Thu May 17 17:45:04 EDT 2007
starting portfolio at Thu May 17 17:45:04 EDT 2007

finished portfolio at Thu May 17 17:46:07 EDT 2007
starting eatmem at Thu May 17 17:46:07 EDT 2007

finished eatmem at Thu May 17 17:47:56 EDT 2007
183
starting forkit at Thu May 17 17:47:56 EDT 2007

finished forkit at Thu May 17 17:50:17 EDT 2007
starting timewaster at Thu May 17 17:50:17 EDT 2007

finished timewaster at Thu May 17 17:56:33 EDT 2007
starting oSSIStest at Thu May 17 17:56:33 EDT 2007

finished oSSIStest at Thu May 17 17:57:43 EDT 2007

/etc/issue:
PARTICULAR PURPOSE.
Gnu make 3.80

util-linux 2.12
mount 2.12a
modutils 2.4.26
e2fsprogs 1.35
pcmcia-cs 3.2.5
PPP 2.4.2
isdn4k-utils 3.3
Procps 3.2.1
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0.91
184
Modules Loaded

ide-cd ide-scsi ac
free -m reports:

Mem: 1006 535 471 0 8 369
Swap: 494 0 494
/proc/cpuinfo
processor :0
cpu family :6
model :9
stepping :5
cpu MHz : 1498.752
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
bogomips : 2988.44
Salida para openSSI del Stress-Test con cluster de tres nodos:
the results will be saved in : /tmp/openSSI-stress-test-report-0572346011.txt
185
oSSIS is mounted at /mfs and will be tested
my PID is 13567
~ mi identificador de proceso



~ migra el proceso 13567 al nodo 10. Proceso migrado a tres nodos distintos,
dependiendo del balanceo de carga que el cluster otorgue a cada nodo, tendran una
carga mayor o menos, pero independientemente de esto los tres estan trabajando en
este momento sobre el mismo proceso.



186
Proc 3 started.
~divide el proceso en varios, mediante el comando unix fork, actualmente tres

instancias.
Proc 0 started.
Proc 3 started.
Proc 2 started.
Proc 1 started.
Proc 3 started.
Proc 2 started.
Proc 1 started.
Proc 1 started.
Proc 2 started.
Proc 3 started.
Proc 0 started.
Proc 2 started.
Proc 1 started.
187
Proc 0 started.
Proc 3 started.
Proc 1 started.
Proc 2 started.
Proc 0 started.
Proc 3 started.
Proc 2 started.
Proc 0 started.
Proc 1 started.
Proc 3 started.
Proc 2 started.
Proc 1 started.
Proc 0 started.
Proc 3 started.
Proc 2 started.
Proc 1 started.
Proc 3 started.
Proc 0 started.
Proc 0 started.
Proc 2 started.
Proc 3 started.
188
Proc 0 started.
Proc 2 started.
Proc 1 started.
Proc 1 started.
Proc 3 started.
189
190
output from oSSIFS test
cp /tmp/testfile.zero from ssi-node 10 to local
cp /tmp/testfile.zero from ssifs-node 8 to local
cp /tmp/testfile.zero from ssifs-node 8 to mfs-node 10
cp /tmp/testfile.zero from ssi-node 8 to local
delete /ssifs/10/tmp/testfile.zero
finished ok
16.1.3.2 Realización de las pruebas con cluster(1 nodo)
191
Fecha de la prueba:



~ 2 minutos

~ 1 minuto 16 segundo.


starting oSSIFStest at Thu Apr 26 21:12:50 EDT 2007

finished oSSIFStest at Thu Apr 26 21:14:51 EDT 2007

/etc/issue:
192
PARTICULAR PURPOSE.
Gnu make 3.80

util-linux 2.12
mount 2.12a
modutils 2.4.26
e2fsprogs 1.35
pcmcia-cs 3.2.5
PPP 2.4.2
isdn4k-utils 3.3
Procps 3.2.1
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.0.91
Modules Loaded

ide-cd ide-scsi ac
free -m reports:

Mem: 1006 535 471 0 8 369
Swap: 494 0 494
/proc/cpuinfo
193
processor :0
cpu family :6
model :9
stepping :5
cpu MHz : 1498.752
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
bogomips : 2988.44
Salida para Stress-Test con cluster de un nodo:
the results will be saved in : /tmp/stress-test-report-0704262008.txt
oSSIFS is mounted at /mfs and will be tested

my PID is 23744
~mi identificador

~migra el proceso al nodo 8, en realidad el sistema ve que existe un cluster con un solo
nodo, es decir, migra procesos a ese nodo, pero al existir un único nodo para todo el
trabajo el reaparto de carga no es real.

194


Proc 1 started.
Proc 0 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
195
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 1 started.
Proc 0 started.
Proc 0 started.
Proc 1 started.
Proc 0 started.
Proc 1 started.
Proc 1 started.
Proc 0 started.
196
output from oSSIFS test
finished ok
197
198
CAPITULO V
SEGUNDA LEY DE GILB SOBRE LA FIABILIDAD
-“Cualquier sistema que dependa de la precisión humana, es impreciso”
199
17. COMPARATIVA
A continuación mostraremos tanto las tablas ocho, nueve y diez que muestran el
tiempo obtenido realizando las seis pruebas descritas en los apartados 12.1.1 y 16.1.1, a
saber distkeygen, portfolio, eatmen, forkit, timewaster y oMFStest ó oSSIFStest en un
ordenador individual, un cluster de tres nodos con OpenMosix y otro cluster con tres
nodos con OpenSSI respectivamente.
También una gráfica asociada a cada tabla que mostrará gráficamente los
resultados obtenidos en tiempo (minutos/segundos) en los diversos benchamarks. Hay
que hacer notar que los resultados obtenidos se denotan mediante número de minutos
una coma y número de segundos, siendo como es lógico el número máximo de
segundos sesenta en vez de cien.
Stress-Test – 1 Nodo
distkeygen 13 minutos 28 segundos
portfolio 2 minutos 00 segundos
eatmem 1 minutos 31 segundos
Forkit 2 minutos 30 segundos
timewaster 10 minutos 06 segundos
oMFStest/oSSIFSTest 2 minutos 01 segundos
Tabla 8 Stress-Test OpenMosix – 1 Nodo
Cabe señalar que tanto distkeygen como timewaster son pruebas

computacionales con gran carga para las CPUs, es decir, son cálculos númericos
intensivos en los que se nota la gran diferencia entre un cluster y un ordenador
individual, aunque como en este caso, el ordenador individual sea el más potente o
posea mejores recursos que el resto.
200
StressTest - 1 Nodo
14
12
10
10,06
8 2,01
Tiempo
0 oMFStest/oSSIFSTest
(minutos)
6 timewaster
2,30
forkit
4 1,31
0 eatmen
13,28 2,00
2 0 portfolio
0 distkeygen
distkeygen portfolio eatmen forkit timewaster oMFStest/oSSIFSTest
Figura 27 StressTest 1 Nodo
Todas las operaciones realizadas mediante el ordenador más potente, desde el

cálculo de funciones y/o cálculos numéricos hasta la creación de múltiples procesos,
copias de ficheros o cualquier otra funcionalidad de cualquier índole se realiza con
mayor ineficacia que si lo realizara cualquier cluster OpenMosix u OpenSSI, aunque
hay una excepción.
Tanto el cálculo de funciones sinusoidales y raíces cuadradas ejecutadas tantas

veces como nodos haya en el cluster (eatmen) lo realiza más lentamente que
OpenMosix aunque con tiempos muy próximos y más rápidamente que OpenSSI, ya
que este al poseer más nodos comparado con un ordenador individual (uno nodo) realiza
muchas más operaciones. Queda patente con estos tiempos algunos aspectos en los que
201
entraremos mucho más en detalle en el apartado de conclusiones como con el balanceo
y reparto de carga entre OpenMosix y OpenSSI.
A su vez se puede apreciar como OpenSSI es más rápido en todas aquellas

pruebas que requieren migrar procesos a nodos hijos ó multiples procesos simúltaneos
en cada nodo hijo, mientras que OpenMosix, realiza más eficientemente cálculos
númericos o reparto de carga exacto que no migraciones.
Stress-Test OpenMosix – 3 Nodos

forkit 2 minutos 29 segundos
oMFStest 1 minutos 08 segundos
Tabla 9 Stress-Test OpenMosix – 3 Nodos
StressTest OM - 3 Nodos
5
5,46
4 1,08
Tiempo
0 oMFStest
(minutos)
3 2,29
timewaster
forkit
2 6,12 1,22
0 eatmen
1,01
1 0 portfolio
0 distkeygen
distkeygen portfolio eatmen forkit timewaster oMFStest
Figura 28 StressTest OpenMosix 3 Nodos
202
Stress-Test OpenSSI – 3 Nodos
forkit 2 minutos 21 segundos
oSSIFStest 1 minutos 01 segundos
Tabla 10 Stress-Test OpenSSI – 3 Nodos
StressTest OSSI - 3 Nodos
6,26
5
4
Tiempo 1,1
0 oSSIFStest
(minutos)
2,21
3 timeaster
5,59 0 forkit
1,49
2
0 eatmen
1,03
1 0
portfolio
0 distkeygen
distkeygen portfolio eatmen forkit timeaster oSSIFStest
Figura 29 StressTest OpenSSI 3 Nodos
203
Las tablas once, doce y trece comparan información de las distintas pruebas con
los distintos clusters, cabiendo reseñar que el campo ‘TiempoOM’ implica el tiempo
tardado con un cluster bajo OpenMosix, a su vez, ‘TiempoOSSI’ indica el tiempo
tardado en realizar la prueba en un cluster OpenSSI. ‘Tiempo1’ por tanto indica el
tiempo que ha tardado en realizar la prueba un único ordenador.
Los ‘TDiferenciaOM’, ‘TDiferenciaOSSI’ y ‘TDiferencia1’ indican la diferencia

en minutos y segundos exactos comparando los tiempos absolutos obtenidos por un
cluster OpenMosix, un cluster OpenSSI y un ordenador individual, respectivamente.
Se denota con un ‘+’ si ha tardado más tiempo en realizar la prueba o bien con
un ‘-’ si ha realizado por el contrario menor tiempo.
Stress-Test OM – 3 Nodos Stress-Test – 1 Nodo

Pruebas TiempoOM TDiferenciaOM Tiempo1 TDiferencia1
(minutos/segundos)
distkeygen 6,12 -7,16 13,28 +7,16
portfolio 1,01 -0,59 2,00 +0,59
eatmen 1,22 -0,09 1,31 +0,09
forkit 2,29 -0,01 2,30 +0,01
timewaster 5,46 -4,18 10,06 +4,18
oMFStest 1,08 -0,53 2,01 +0,53
Tabla 11 Stress Test OpenMosix 3 Nodos VS. 1 Nodo
Stress-Test OSSI – 3 Nodos Stress-Test – 1 Nodo

Pruebas TiempoOSSI TDiferenciaOSSI Tiempo1 TDiferencia1
(minutos/segundos)
distkeygen 5,59 -7,29 13,28 +7,29
portfolio 1,03 -0,57 2,00 +0,57
eatmen 1,49 +0,18 1,31 -0,18
Forkit 2,21 -0,09 2,30 +0,09
timewaster 6,26 -4,32 10,06 +4,32
oSSIFStest 1,01 -1,00 2,01 +1,00
Tabla 12 Stress Test OpenSSI 3 Nodos VS. 1 Nodo
Stress-Test OM – 3 Nodos Stress-Test OSSI – 3 Nodos

Pruebas TiempoOM TDiferenciaOM TiempoOSSI TDiferenciaOSSI
(minutos/segundos)
distkeygen 6,12 +0,13 5,59 -0,13
Portfolio 1,01 -0,02 1,03 +0,02
Eatmen 1,22 -0,27 1,49 +0,27
Forkit 2,29 +0,08 2,21 -0,08
timewaster 5,46 -0,40 6,26 +0,40
oMFStest/oSSIFStest 1,08 +0,07 1,01 -0,07
Tabla 13 Stress Test OpenMosix 3 Nodos VS. OpenSSI 3 Nodos
204
Eficiencia (%) OpenMosix OpenSSI Sin Cluster
distkeygen 91,33% 100,00% 39,83%
portfolio 100,00% 98,05% 50,05%
Eatmen 100,00% 81,87% 93,12%
forkit 96,50% 100,00% 96,06%
timewaster 100,00% 87,22% 54,27%
oMFStest/oSSIFStest 93,51% 100,00% 50,24%
Tabla 14 Eficiencia OpenMosix VS. OpenSSI VS.Sin Cluster
Esta tabla índica en porcentajes la eficiencia de realizar cualquiera de las

pruebas seleccionadas por los distintos tipos de clusters o por un ordenador individual.
La unidad de medida es por tanto el porcentaje, que suele ser, la unidad de medida en
pruebas de eficiencia. Aquellos que tengan un cien por cien en una determinada prueba,
habrá obtenido el mejor tiempo en dicho benchmark.
A continuación representaremos gráficamente la eficiencia de OpenMosix,

OpenSSI y un ordenador individual para cada una de las pruebas descritas.
Benchamark Distkeygen
39,83%
91,33%
100,00%
OpenMosix OpenSSI Sin Cluster
Figura 30 Benchmark Distkeygen
205
Benchmark Portfolio
50,05%
100,00%
98,05%
Figura 31 Benchmark Portfolio
Benchmark Eatmen
93,12% 100,00%
81,87%
Figura 32 Benchmark Eatmen
206
Benchamark Forkit
96,06% 96,50%
100,00%
Figura 33 Benchmark Forkit
Benchmark Timewaster
54,27%
100,00%
87,22%
Figura 34 Benchmark Timewaster
207
Benchamark oMFStest/oSSIMFStest
50,24%
93,51%
100,00%
Figura 35 Benchmark oM Stest
208
18. CONCLUSIONES
Aunque OpenMosix y OpenSSI tienen en común el balanceo de procesos
mediante la migración de procesos, sus características y la estrategia de cada uno es
bastante diferente. Los dos sistemas de gestión de clusters reivindican una imagen del
sistema única (Single System Image), pero en cada caso de una manera diferente.
OpenSSI agrega los recursos de todos los nodos generando una imagen del
sistema grande y única. OpenMosix no hace esto, por tanto, de la misma manera, puesto
que OpenMosix tiene un nodo raíz, donde los procesos pueden ser migrados de este
nodo a otros y de otros a éste, pero todos estos procesos sólo pueden ser vistos en el
nodo root o raíz.
Para conseguir el objetivo en OpenMosix, se parte de mantener los procesos del

nodo raíz ocultos al resto de los nodos, mientras que todas las llamadas del sistema
realizadas por el nodo raíz al proceso migrado, se hacen bajo éste. Con el tiempo los
desarrolladores de OpenMosix, se dieron cuenta que era interesante que algunas de estas
llamadas pudieran ser realizadas por otros nodos del cluster.
Sin embargo, ya que las llamadas siempre vuelven al nodo raíz, la finalización
de este nodo, tendría como consecuencia la finalización de todos los procesos
comenzados por el mismo. Se puede decir que la estrategia de OpenSSI era que todas
las llamadas fueran ejecutadas sobre el nodo en el cuál esté corriendo el proceso. Esto
significa que las migraciones en de proceso en OpenSSI no sólo se realizan por parte del
nodo raíz.
En OpenMosix los procesos migrados obtienen un nuevo PID en sus hosts y la

visibilidad de los procesos es limitada, sólo desde el nodo raíz se tiene acceso a ellos, en
cambio en OpenSSI todos los objetos forman el cluster y estos pueden ser visibles y
accesibles desde cualquier nodo. Consecuentemente se crea un objeto en los nodos
donde están corriendo los procesos, mientras que OpenMosix crea todos los objetos en
el nodo raíz y los procesos comienzan a correr en el mismísimo nodo raíz que podrá ser
compartido a otros objetos de otros nodos, excepto los objetos de memoria compartida,
mientras que OpenSSI permite completamente la lectura/escritura de memoria
compartida a través de los nodos.
OpenMosix no tiene ningún API y ninguna infraestructura para la alta

disponibilidad. OpenSSI asegura que todos los miembros siempre están de acuerdo
sobre los nodos que están corriendo y a través del API, se puede ver un historial
constante de lo que está ocurriendo en el cluster, como por ejemplo la migración de los
procesos a los otros nodos, existe un API en OpenSSI para la información, la historia y
notificaciones de acontecimiento de los miembros. Actualmente para la última versión
del kernel (2.6) OpenMosix tiene previsto realizar dicho API con dicho historial y
seguimiento de miembros.
Existen varios componentes de alta disponibilidad instalados e integrados en el

sistema base de OpenSSI, uno de ellos es la capacidad del sistema de archivos (CFS) de
un cluster, siendo altamente disponible y transparente a la hora de comunicar el fallo de
algún nodo, cuando no se aprecia actividad en dicho sistema de archivos,
209
HA-LVS integrado en OpenSSI proporciona una dirección IP para el cluster,
pero a su vez también provee el equilibrio de carga de todas las conexiones entrantes
TCP/IP. Los servicios rc-type pueden de forma trivial reiniciar un nodo despues de
producirse un fallo, a pesar de que OpenSSI incluye un monitor de proceso y subsistema
de reinicio, por lo que OpenSSI puede ser usado para proveer un archivo de servicio, el
HA-NFS.
Las capacidades de los archivos del sistema de OpenSSI y OpenMosix, son
bastante diferentes, de hecho OpenMosix a través de sus MFS, provee un acceso a los
archivos remotos y usa un esquema para el nombre del nodo principal. Los MFS de
OpenMosix no tienen la capacidad de fallo.
OpenSSI está diseñado para soportar diferentes tecnologías de los archivos de

sistema del cluster, para eso está HA-CFS, el cual es un cliente-servidor transparente,
que almacena dichos archivos de sistema del cluster, soporta los archivos mapeados
compartidos de lectura/escritura y puede fallar por un nodo que falle. En cambio en
cuanto al esquema para el nombre del nodo principal en OpenSSI no existe ninguna
limitación.
Uno de los grandes éxitos del diseño de OpenSSI fue crear una plataforma para
poder llegar a integrar en un futuro tecnologías para un cluster mediante código abierto.
El balance de carga es un punto en común que tienen OpenSSI y OpenMosix, de

hecho el algoritmo que calcula la carga en OpenMosix fue adaptado para OpenSSI. En
OpenSSI se soporta la migración de procesos gracias a los segmentos de memoria
compartida, de forma individual, llamados threads (hilos) o de forma grupal como una
acción atómica.
En cuanto al balance de carga y al proceso de migración, en OpenSSI, se realiza

en tiempo de ejecución, éste es menos costoso puesto que no existen datos de proceso
para migrar auque con respecto a su homólogo puede que tenga depende de en que
peores resultados. En el tiempo de ejecución los nodos se envian mensajes entre si,
siendo esta una forma de compartir la información de todo el cluster. Mientras que
OpenMosix tiene la capacidad de realizar todo el proceso de balanceo de carga en
memoria, en cambio en OpenSSI no se ha permitido esta característica.
Como es evidente los objetivos de OpenSSI alcanzan bastante más que sólo el
compartimiento de memoria de la CPU que realiza OpenMosix. El objetivo principal de
OpenSSI es tener una solución completa de un cluster, es decir, la disponibilidad,
escalabilidad, la posibilidad de gestión y la usabilidad, de dicho cluster, así como ser la
plataforma donde se puedan integrar tecnologías con código abierto para un cluster.
La posibilidad de gestión es un problema clave del cluster que se observa en un

sistema SSI, en cambio en OpenSSI en gran parte de éste se reduce gracias al manejo de
todos los nodos como una sola maquina. El nodo raíz al estar compartido es de gran
ayuda para solucionar el problema, unido a la visibilidad y acceso de todos los recursos
de todos los nodos a todos los nodos.
A continuación se muestran las diferencias más importantes entre OpenSSI y

OpenMosix.
210
- OpenSSI tiene un manejo único y un dominio administrativo, mientras
que OpenMosix no.
- OpenSSI tiene un único sistema de archivos en el nodo principal del

cluster, mientras que OpenMosix no.
- OpenSSI tiene un único PID por proceso y un manejo de todos los

procesos del cluster, mientras que en OpenMosix no.
- OpenSSI tiene el nombre para todo el cluster, tiene una transparencia en

todo el cluster de todos los objetos del IPC, mientras que OpenMosix
no.
- OpenSSI tiene un dispositivo de acceso a todo el cluster y un único

nombre pty, mientras que en OpenMosix puede tener sólo un
dispositivo de acceso a todo el cluster.
- OpenSSI es consistente al nombrar los archivos a través de todos los

nodos, como un “único sitio”, mientras que OpenMosix tiene nombre
paradigma para nombrar a la máquina principal.
- OpenSSI tiene un acceso al archivo de forma transparente y totalmente

coherente a través de todos los nodos, mientras que OpenMosix tiene
un modelo de acceso al archivo limitado.
- OpenSSI tiene integrado las mejores tecnologías para el sistema de

archivos de un cluster, tiene flexibilidad y elección para decidir en que
arrancar OpenSSI.
- OpenSSI tiene un sistema de archivos del cluster sumamente disponible,

a su vez en caso de un fallo general es transparente al cluster, mientras
que OpenMosix no.
- OpenSSI proporciona un nombre y una única dirección para el cluster.
- OpenSSI y OpenMosix tratan la migración de procesos de forma

diferente, OpenSSI envía los procesos de nodo a nodo mediante una
función, mientras que en OpenMosix, cada proceso tiene que pasar
obligatoriamente por el nodo principal.
- OpenSSI realiza el balanceo de carga en tiempo de ejecución mientras

que OpenMosix no, teniendo el último menos errores de balanceo y
mayor eficiencia.
- OpenSSI tiene una variedad de características de alta disponibilidad e

incluye una supervisión de cada proceso, que OpenMosix no tiene.
- OpenSSI tiene un API para rexec () rfork () y emigrate(), mientras

OpenMosix sólo tiene la migración de proceso;
211
- OpenSSI tiene un número máximo de nodos, 125, mientras que
OpenMosix permite llegar a la cifra de 650 nodos simultáneos.
- OpenSSI tiene un tamaño máximo de ficheros, direcciones y sistemas

de archivos físicos inherentes, por el contrario OpenMosix no tiene
ninguna restricción de este tipo.
- OpenSSI debido su compartición y transparencia con todos los nodos

realiza las operaciones computaciones de un poco más “pesado” aún
mejorando notablemente la eficiencia, OpenMosix por el contrario con
su particular sistema de nodo raíz obtiene mejores resultados en este
ámbito.
- OpenSSI en referencia a la creación y copia de archivos dinámica

puede ser en algunos casos muy poco eficiente debido a la copia
redundante de un mismo fichero, teniendo de este modo que ejercer un
control de congestión que hace ralentizar la tarea, por el contrario
OpenMosix únicamente ha de ejercer un control de flujo (también
OpenSSI) no de congestión.
- OpenSSI posee un número máximo de dispositivos princpales de 4095

unidades mientras que OpenMosix casi le duplica en número llegando
hasta las 7915 unidades.
- OpenSSI como OpenMosix pueden ejercer un control de flujo, pero el

segundo tiene la ventaja de poder contar con un número máximo de
sockets operativos simultáneamente, permitiendo de este modo
solucionar la lentitud de flujo más rápidamente.
- OpenSSI puede realizar, también debido a su número máximo de nodos

y dispositivos primarios y secundarios, la mitad de procesos que
OpenMosix, cerca de un billón de procesos en su versión americana.
- OpenSSI tiene y este quizás es su gran handicap de cara al futuro un

número reducido de conexiones, semáforos y PTYs, permitiendo que en
el campo de la supercomputación, OpenMosix obtenga en muchos
ámbitos mejores resultados.
Tanto OpenMosix como OpenSSI se desarrollaron a principios de los años 80, la

tecnología OpenSSI se comenzó a desarrollar en UCLA, sin embargo OpenMosix fue
adaptado a Linux varios años antes de que el código de OpenSSI fuese adaptado
ganando en este aspecto varios años de ventaja a OpenSSI.
212
213
REFERENCIAS
WEBS
[1] Web Oficial de Debian y documentación sobre el Sistema Operativo
<http://debian.org>
[2] Web oficial del proyecto Cisilia

<http://www.citefa.gov.ar/SitioSI6_ES/si6.htm>
[3] Web oficial del proyecto OpenMosix. Documentación extraída del F.A.Q
(Frecently Asked Questions) y del HowTo oficiales
<http://www.openmosix.org>
[4] Monitor para el cluster openmosixview y documentación sobre el mismo

<http://www.openmosixview.org>
[5] Informaci sobre los clusters OpenSSI

<http://wiki.openssi.org/go/Team >
[6] Manual en castellano sobre clustering en OpenMosix

<http://es.tldp.org/Manuales-LuCAS/manual-openMosix-
ES/howTo_openMosixES_html/>
[7] Benchmark HPC y documentación sobre el mismo

<http://as.nasa.gov/Software/NPB/>
[8] Documentación sobre los clusters OpenSSI

<http://openssi.org>
[9] Monitor para el cluster openSSI webview y documentación sobre el mismo de

<http://wiki.openssi.org/go/OpenSSI_webView>
[10] Documentación diversa sobre clustering

<http://www.hispacluster.org/>
214
[11] Información sobre los diversos programas que funcionan en clusters
OpenMosix
<http://howto.ipng.be/openMosixWiki/index.php/work%20smoothly>
[12] Proyecto sobre clusters de alta disponibilidad en Linux

<http://www.linux-ha.org>
[13] Proyecto MOSIX

<http://mosix.org>
[14] Proyecto Linux sobre la alta disponibilidad

<http://www.ha-Linux.org>
[15] Proyecto Beowulf

<http://www.beowulf.org/index.html>
[16] Máquina Virtual Pararela (PVM)

<http://www.csm.ornl.gop/pvm/>
[17] Interfaz de Paso de Mensajes

<http://www.mpi-forum.org>
[18] Web de de descarga y mantemiento de distintos proyectos de software libre

<http://www.sourceforge.net>
LIBROS
[19] Gropp, W., Lusk, E., Sterling, T., Hall, J., “Beowulf Cluster Computing with
Linux, Second Edition” The MIT Press, 2003
[20] Bookman, C., “Linux Clustering: Building and Maintaining Linux Clusters ”,
New Riders, 2002
[20] Vrenios, A., “Linux Cluster Architecture”, Sams, 2002
[21] Lucke, R. W., “Building CLustered Linux Systems”, Hewlett-Packard

Professional Books, 2004
215
[22] Sloan J. D., “High Performance Linux Clusters: With OSCAR, Rocks,
OpenMosix, and MPI ”, O’Reilly Media, 2004
[23] Lottiaux, R., Gallard, P., Vallée, G., Morin, C. “OpenMosix, OpenSSI and
Kerrighed: A Comparative Study ” Technical Report, IRISA/INRIA Rennes
[24] Santo Orcero, David, "Los clusters SSI," Todo Linux, no. 23, pp. 57–60, 2002.
[25] Santo Orcero, David, "El algoritmo de migración de OpenMosix," Todo Linux,
no. 23, 2002.
[26] Santo Orcero, David, "El equilibrado automático de carga en OpenMosix,"

Todo Linux, no. 24, 2002.
[27] Santo Orcero, David, "Las herramientas de área de usuario de OpenMosix,"

Todo Linux, no. 25, 2002.
[28] Loir Amar, Ammon Barak, y Ammon Silo. Acceso a Sistemas de acceso
directo a Mosix y métodos de soporte escalable del cluster. “Cluster
Computing,” 7(2):pag141-150, 2004
OTROS
Hemos utilizado el buscador Google y las páginas MAN de ayuda de cada
programa para conocer a fondo los argumentos y opciones utilizados, así como su
funcionamiento. También hemos hecho uso de listas de correo (la lista oficial de
OpenMosix y OpenSSI), que trataban sobre el tema.
APÉNDICE I
216
El API de OpenMosix
El API de openMosix es la manera mediante la cual los programadores pueden

controlar el comportamiento de un cluster. Sirve como herramienta de diagnóstico para
monitorizar los aspectos más íntimos del procedimiento que se lleva a cabo en el seno
del nodo y, por extensión, del cluster. De esta interfaz se obtienen los datos para
mosmon por ejemplo, para monitorizar la carga -load- o las relaciones de memoria libre
y ocupada.
No hará falta ser un experto para poder comprender esta interfaz, puesto que es
de una simplicidad sorprendente: lo justo para poder saber en cualquier momento,
cualquier aspecto relativo a la algorítmica que controla el cluster: migración, balanceo,
etc.
De esta manera se aconseja al lector ver como se opera en este directorio para
buscar las razones de migración, por ejemplo, o qué procesos no locales se están
ejecutando en su nodo -aspectos que hasta ahora habían permanecido ocultos al ser
invisibles al comando ps-. Se pueden llegar a solucionar problemas o simplemente
comprender mejor a openMosix.
En este apartado se describirá el API de openMosix, al que se puede acceder

como a un conjunto de ficheros y escribir o leer de ellos dependiendo de su utilización.
Todos los ficheros se encuentran en /proc/hpc/. Dentro de este directorio se encuentran
los siguientes subdirectorios:
• admin: variables que controlan la administración del nodo.

• decay: control de estadísticas.
• info: información de variables relativas al nodo.
• nodes: información del estado y carga de cada uno de los nodos del cluster. Las
variables son las mismas que para el nodo local, en info.
• remote: ruta que sirve para migrar procesos hacia otros nodos.
Fichero W/R Función Valor de activación

Block W bloqueo para la llegada de procesos 1
Bring W devuelve los procesos migrados 1
Config R/W configuración del sistema -
decayinterval W/R intervalo de control estadístico -
dfsalinks W activación de rutas DFSA ruta
Expel W expele procesos ajenos, activa block 1
fastdecay W tasa de decaída estadística rápida defecto: 926
gateway R Número de gateways en red defecto: 0
Lstay W/R no migrarán procesos locales 1
mfscosts W/R costes de MFS ?
217
mfskill W esconde árboles complejos a MFS ruta
mospe R/W identificador de nodo (nodo ID) /etc/openmosixmap
nomfs R/W deshabilita la opción de MFS 1
overhead R/W sobrecargas sobre nodos y red -
Quiet R/W el nodo deja de diseminar información a otros 1
slowdecay R/W procesos con tasa de caída lenta defecto: 976
Speed R/W Velocidad del nodo valor
Sspeed R/W Velocidad estandar, par areferencia 10000
Stay R/W los procesos no migrarán 1
Versión R Versión de openMosix funcionando variable
Tabla 15 El API de openMosix: /proc/hpc/remote/

Clear W resetea valor estadísticos del nodo 1
cpujob W advierte que el proceso es cpu-intensivo 1
Exec W protege de execve la política de decay 1
execonce W como el anterior, pero solo para el primer execve 1
Fase W estadísticas de decaimiento rápidas 1
inherit W heredadas de un proceso a sus hijos 1
Iojob W proceso io-intensivo 1
Own R factor de decay que utilizaría el proceso -
Show W estadísticas de decaimiento lentas 1
Tabla 16 El API de openMosix: /proc/hpc/admin/

Load R carga del nodo variable
Mem R memoria utilizada por el sistema variable
rmem R memoria del sistema en bruto variable
speed R velocidad del nodo o procesador del nodo variable
status R estado del nodo variable
tmem R memoria total del sistema -utilizada y sin utilizar- variable
Util R factor de unificación del sistema variable
218
Cpus R número de procesadores del sistema variable
Tabla 17 El API de openMosix: /proc/hpc/decay/

From R nodo de procedencia nodo ID
Goto W obligación de migrar hacia ese nodo nodo ID
Statu R estadísticas de memoria -
Stats R estadísticas de procesador -
Tabla 18 El API de openMosix: /proc/hpc/info/
En los cuadros se ha hablado de estadísticas referentes tanto a memoria com a

procesador. Éstas contienen la siguiente información:
ESTADÍSTICAS DE MEMORIA
• tamaño total
• tamaño residente
• memoria compartida
• páginas de texto
• páginas de librerías
• páginas de datos
• páginas sucias
ESTADÍSTICAS DE PROCESADOR
• tiempo de usuario en el nodo
• tiempo de los descendientes, no se muestra
• nice -prioridad UNIX- del proceso
• vsize, tamaño virtual
• rss, número de páginas residentes
• nswap, número de páginas en swap
• cnswap, páginas en swap de los descendientes.
Por otro lado existe en /proc/PID/ una estructura ampliada relativa a la

información para cada proceso. Entre esta información -propia de linux- ahora podrán
encontrarse aspectos relacionados con openMosix, como muestra el cuadro.
Fichero Función
cantmove Motivo por el que no ha migrado el proceso
219
goto nodo al que se desea migrar el proceso
lock bloqueo del proceso en este nodo
migrate obliga al proceso a migrar
nmigs número de veces totales que el proceso ha migrado
sigmig el solicita una señal tras migrar
where nodo destino
Tabla 19 El API de openMosix: /proc/PID/
APENDICE II
220
Configuración del kernel
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# openMosix
#
CONFIG_MOSIX=y
# CONFIG_MOSIX_TOPOLOGY is not set
CONFIG_MOSIX_SECUREPORTS=y
CONFIG_MOSIX_DISCLOSURE=3
CONFIG_MOSIX_FS=y
CONFIG_MOSIX_DFSA=y
CONFIG_MOSIX_PIPE_EXCEPTIONS=y
# CONFIG_MOSIX_NO_OOM is not set
CONFIG_MOSIX_EXT_LOCALTIME=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
CONFIG_M386=y
# CONFIG_M486 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_CMPXCHG is not set
# CONFIG_X86_XADD is not set
CONFIG_X86_L1_CACHE_SHIFT=4
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
221
CONFIG_X86_PPRO_FENCE=y
# CONFIG_X86_F00F_WORKS_OK is not set
CONFIG_X86_MCE=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
# CONFIG_HIGHIO is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_NR_CPUS=32
# CONFIG_X86_NUMA is not set
# CONFIG_X86_TSC_DISABLE is not set
#
# General setup
#
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_EISA=y
CONFIG_MCA=y
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
CONFIG_TCIC=y
CONFIG_I82092=y
CONFIG_I82365=y
#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_SHPC=m
# CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
CONFIG_SYSVIPC=y
222
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
# CONFIG_OOM_KILLER is not set
CONFIG_PM=y
CONFIG_APM=m
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
#
# ACPI Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_MMCONFIG=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SYSTEM=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_DEBUG is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=m
CONFIG_MTD_CONCAT=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_CMDLINE_PARTS=m
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
223
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
# CONFIG_MTD_OBSOLETE_CHIPS is not set
# CONFIG_MTD_AMDSTD is not set
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set
#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_START=8000000
CONFIG_MTD_PHYSMAP_LEN=4000000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
CONFIG_MTD_PNC2000=m
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_SBC_GXX=m
CONFIG_MTD_ELAN_104NC=m
CONFIG_MTD_DILNETPC=m
CONFIG_MTD_DILNETPC_BOOTSIZE=80000
# CONFIG_MTD_MIXMEM is not set
# CONFIG_MTD_OCTAGON is not set
# CONFIG_MTD_VMAX is not set
CONFIG_MTD_SCx200_DOCFLASH=m
CONFIG_MTD_L440GX=m
CONFIG_MTD_AMD76XROM=m
CONFIG_MTD_ICH2ROM=m
CONFIG_MTD_NETtel=m
CONFIG_MTD_SCB2_FLASH=m
CONFIG_MTD_PCI=m
CONFIG_MTD_PCMCIA=m
#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
CONFIG_MTD_PMC551_BUGFIX=y
# CONFIG_MTD_PMC551_DEBUG is not set
CONFIG_MTD_SLRAM=m
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLKMTD=m
#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC1000=m
224
CONFIG_MTD_DOCPROBE=m
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
# CONFIG_MTD_DOCPROBE_HIGH is not set
# CONFIG_MTD_DOCPROBE_55AA is not set
#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_IDS=m
#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_IP22 is not set
CONFIG_PARPORT_OTHER=y
CONFIG_PARPORT_1284=y
#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_PS2=m
CONFIG_BLK_DEV_XD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
225
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_CISS_MONITOR_THREAD=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_LVM=m
#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_TOS is not set
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
226
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
227
CONFIG_IP_NF_COMPAT_IPFWADM=m
#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_KHTTPD=m
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
228
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
CONFIG_ATM_CLIP_NO_ICMP=y
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_VLAN_8021Q=m
#
#
#
CONFIG_IPX=m
CONFIG_IPX_INTERN=y
CONFIG_ATALK=m
#
# Appletalk devices
#
CONFIG_DEV_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_DECNET=m
CONFIG_DECNET_SIOCGIFCONF=y
CONFIG_DECNET_ROUTER=y
CONFIG_DECNET_ROUTE_FWMARK=y
CONFIG_BRIDGE=m
CONFIG_X25=m
CONFIG_LAPB=m
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
CONFIG_ECONET=m
CONFIG_ECONET_AUNUDP=y
CONFIG_ECONET_NATIVE=y
CONFIG_WAN_ROUTER=m
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_IPSEC_NAT_TRAVERSAL=y
#
# Telephony Support
#
CONFIG_PHONE=m
229
CONFIG_PHONE_IXJ=m
CONFIG_PHONE_IXJ_PCMCIA=m
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=m
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_ISAPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_PCI_AUTO is not set
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_PCI_WIP=y
CONFIG_BLK_DEV_ADMA100=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_AMD74XX_OVERRIDE is not set
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_BLK_DEV_NS87415=y
CONFIG_BLK_DEV_OPTI621=y
230
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_SC1200=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
CONFIG_BLK_DEV_TRM290=y
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
# CONFIG_IDEDMA_AUTO is not set
CONFIG_IDEDMA_IVB=y
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_BLK_DEV_ATARAID=m
CONFIG_BLK_DEV_ATARAID_PDC=m
CONFIG_BLK_DEV_ATARAID_HPT=m
CONFIG_BLK_DEV_ATARAID_MEDLEY=m
CONFIG_BLK_DEV_ATARAID_SII=m
#
# SCSI support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
231
CONFIG_AIC7XXX_PROBE_EISA_VL=y
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC79XX=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_BUILD_FIRMWARE is not set
CONFIG_AIC79XX_ENABLE_RD_STRM=y
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
# CONFIG_AIC7XXX_OLD_TCQ_ON_BY_DEFAULT is not set
CONFIG_AIC7XXX_OLD_CMDS_PER_DEVICE=8
# CONFIG_AIC7XXX_OLD_PROC_STATS is not set
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_AM53C974=m
CONFIG_SCSI_MEGARAID=m
CONFIG_SCSI_MEGARAID2=m
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_SVW=y
CONFIG_SCSI_SATA_PROMISE=y
CONFIG_SCSI_SATA_SX4=y
CONFIG_SCSI_SATA_SIL=y
CONFIG_SCSI_SATA_SIS=y
CONFIG_SCSI_SATA_VIA=y
CONFIG_SCSI_SATA_VITESSE=y
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_CPQFCTS=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
# CONFIG_SCSI_EATA_TAGGED_QUEUE is not set
# CONFIG_SCSI_EATA_LINKED_COMMANDS is not set
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_EATA_DMA=m
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_FD_MCS=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_G_NCR5380_PORT=y
# CONFIG_SCSI_G_NCR5380_MEM is not set
CONFIG_SCSI_IBMMCA=m
CONFIG_IBMMCA_SCSI_ORDER_STANDARD=y
# CONFIG_IBMMCA_SCSI_DEV_RESET is not set
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
CONFIG_SCSI_IZIP_EPP16=y
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_NCR_D700=m
232
CONFIG_53C700_IO_MAPPED=y
CONFIG_SCSI_NCR53C7xx=m
CONFIG_SCSI_NCR53C7xx_sync=y
CONFIG_SCSI_NCR53C7xx_FAST=y
CONFIG_SCSI_NCR53C7xx_DISCONNECT=y
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX=m
CONFIG_SCSI_SYM53C8XX=m
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX_PQS_PDS=y
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
CONFIG_SCSI_MCA_53C9X=m
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PCI2000=m
CONFIG_SCSI_PCI2220I=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_SIM710=m
CONFIG_SCSI_SYM53C416=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DC390T_NOGENSUPP is not set
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
# CONFIG_SCSI_U14_34F_LINKED_COMMANDS is not set
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_DEBUG=m
#
# PCMCIA SCSI adapter support
#
CONFIG_SCSI_PCMCIA=y
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m
#
# Fusion MPT device support
#
CONFIG_FUSION=m
# CONFIG_FUSION_BOOT is not set
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_ISENSE=m
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m
CONFIG_NET_FC=y
233
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
CONFIG_IEEE1394=m
#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_LAN=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_ARCNET_COM20020_ISA=m
CONFIG_ARCNET_COM20020_PCI=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
CONFIG_NET_SB1000=m
234
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
CONFIG_HAPPYMEAL=m
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_ELMC=m
CONFIG_ELMC_II=m
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRAMCA=m
CONFIG_ULTRA=m
CONFIG_ULTRA32=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI5010=m
CONFIG_NI52=m
CONFIG_NI65=m
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
CONFIG_SKMC=m
CONFIG_NE2_MCA=m
CONFIG_IBMLANA=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_B44=m
CONFIG_CS89x0=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
CONFIG_DE4X5=m
CONFIG_DGRS=m
CONFIG_DM9102=m
235
CONFIG_EEPRO100=m
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=m
CONFIG_LNE390=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_FORCEDETH=m
CONFIG_NE3210=m
CONFIG_ES3210=m
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_WINBOND_840=m
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
# CONFIG_MYRI_SBUS is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_SK98LIN=m
CONFIG_TIGON3=m
CONFIG_FDDI=y
CONFIG_DEFXX=m
CONFIG_SKFP=m
CONFIG_HIPPI=y
CONFIG_ROADRUNNER=m
# CONFIG_ROADRUNNER_LARGE_RINGS is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
236
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_STRIP=m
CONFIG_WAVELAN=m
CONFIG_ARLAN=m
CONFIG_AIRONET4500=m
CONFIG_AIRONET4500_NONCS=m
CONFIG_AIRONET4500_PNP=y
CONFIG_AIRONET4500_PCI=y
CONFIG_AIRONET4500_ISA=y
CONFIG_AIRONET4500_I365=y
CONFIG_AIRONET4500_PROC=m
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_PCI_HERMES=m
#
# Wireless Pcmcia cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_NET_WIRELESS=y
#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMTR=m
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_TMSISA=m
CONFIG_ABYSS=m
CONFIG_MADGEMC=m
CONFIG_SMCTR=m
CONFIG_NET_FC=y
CONFIG_IPHASE5526=m
CONFIG_RCPCI=m
CONFIG_SHAPER=m
#
# Wan interfaces
#
CONFIG_WAN=y
CONFIG_HOSTESS_SV11=m
CONFIG_COSA=m
# CONFIG_COMX is not set
CONFIG_DSCC4=m
CONFIG_DSCC4_PCISYNC=y
# CONFIG_DSCC4_PCI_RST is not set
237
CONFIG_LANMEDIA=m
CONFIG_ATI_XX20=m
CONFIG_SEALEVEL_4021=m
CONFIG_SYNCLINK_SYNCPPP=m
CONFIG_HDLC=m
CONFIG_HDLC_RAW=y
CONFIG_HDLC_RAW_ETH=y
CONFIG_HDLC_CISCO=y
CONFIG_HDLC_FR=y
CONFIG_HDLC_PPP=y
CONFIG_HDLC_X25=y
CONFIG_PCI200SYN=m
CONFIG_PC300=m
CONFIG_PC300_MLPPP=y
CONFIG_FARSYNC=m
CONFIG_N2=m
CONFIG_C101=m
CONFIG_DLCI=m
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
CONFIG_SDLA=m
CONFIG_WAN_ROUTER_DRIVERS=y
CONFIG_VENDOR_SANGOMA=m
CONFIG_WANPIPE_CHDLC=y
CONFIG_WANPIPE_FR=y
CONFIG_WANPIPE_X25=y
CONFIG_WANPIPE_PPP=y
CONFIG_WANPIPE_MULTPPP=y
CONFIG_CYCLADES_SYNC=m
CONFIG_CYCLOMX_X25=y
CONFIG_LAPBETHER=m
CONFIG_X25_ASY=m
CONFIG_SBNI=m
CONFIG_SBNI_MULTILINE=y
#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_AXNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_ARCNET_COM20020_CS=m
CONFIG_PCMCIA_IBMTR=m
CONFIG_PCMCIA_XIRCOM=m
CONFIG_PCMCIA_XIRTULIP=m
CONFIG_NET_PCMCIA_RADIO=y
CONFIG_PCMCIA_RAYCS=m
CONFIG_PCMCIA_NETWAVE=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_AIRONET4500_CS=m
#
# ATM drivers
#
CONFIG_ATM_TCP=m
238
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
CONFIG_ATM_ENI_TUNE_BURST=y
# CONFIG_ATM_ENI_BURST_TX_16W is not set
CONFIG_ATM_ENI_BURST_TX_8W=y
# CONFIG_ATM_ENI_BURST_RX_16W is not set
# CONFIG_ATM_ENI_BURST_RX_8W is not set
CONFIG_ATM_ENI_BURST_RX_4W=y
CONFIG_ATM_ENI_BURST_RX_2W=y
CONFIG_ATM_FIRESTREAM=m
CONFIG_ATM_ZATM=m
# CONFIG_ATM_ZATM_DEBUG is not set
# CONFIG_ATM_ZATM_EXACT_TS is not set
CONFIG_ATM_NICSTAR=m
CONFIG_ATM_NICSTAR_USE_SUNI=y
CONFIG_ATM_NICSTAR_USE_IDT77105=y
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
# CONFIG_ATM_IDT77252_RCV_ALL is not set
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
CONFIG_ATM_IA=m
# CONFIG_ATM_IA_DEBUG is not set
CONFIG_ATM_FORE200E_MAYBE=m
CONFIG_ATM_FORE200E_PCA=y
CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y
CONFIG_ATM_FORE200E_USE_TASKLET=y
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_FORE200E=m
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
#
# Amateur Radio support
#
CONFIG_HAMRADIO=y
#
# Packet Radio protocols
#
CONFIG_AX25=m
CONFIG_AX25_DAMA_SLAVE=y
CONFIG_NETROM=m
CONFIG_ROSE=m
#
# AX.25 network device drivers
#
#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
239
CONFIG_BPQETHER=m
CONFIG_DMASCC=m
CONFIG_SCC=m
CONFIG_SCC_DELAY=y
CONFIG_SCC_TRXECHO=y
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_BAYCOM_EPP=m
CONFIG_SOUNDMODEM=m
CONFIG_SOUNDMODEM_SBC=y
CONFIG_SOUNDMODEM_WSS=y
CONFIG_SOUNDMODEM_AFSK1200=y
CONFIG_SOUNDMODEM_AFSK2400_7=y
CONFIG_SOUNDMODEM_AFSK2400_8=y
CONFIG_SOUNDMODEM_AFSK2666=y
CONFIG_SOUNDMODEM_HAPN4800=y
CONFIG_SOUNDMODEM_PSK4800=y
CONFIG_SOUNDMODEM_FSK9600=y
CONFIG_YAM=m
#
# IrDA (infrared) support
#
CONFIG_IRDA=m
#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set
#
# Infrared-port device drivers
#
#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m
CONFIG_IRPORT_SIR=m
#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MCP2120_DONGLE=m
240
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m
CONFIG_MA600_DONGLE=m
#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
# CONFIG_TOSHIBA_OLD is not set
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_IRCC_FIR=m
#
# ISDN subsystem
#
CONFIG_ISDN=m
CONFIG_ISDN_BOOL=y
CONFIG_ISDN_PPP=y
CONFIG_IPPP_FILTER=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
CONFIG_ISDN_X25=y
#
# ISDN feature submodules
#
CONFIG_ISDN_DRV_LOOP=m
CONFIG_ISDN_DIVERSION=m
#
# low-level hardware drivers
#
#
# Passive ISDN cards
#
CONFIG_ISDN_DRV_HISAX=m
CONFIG_ISDN_HISAX=y
#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
# CONFIG_HISAX_NO_SENDCOMPLETE is not set
# CONFIG_HISAX_NO_LLC is not set
# CONFIG_HISAX_NO_KEYPAD is not set
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8
#
# HiSax supported cards
241
#
CONFIG_HISAX_16_0=y
CONFIG_HISAX_16_3=y
CONFIG_HISAX_AVM_A1=y
CONFIG_HISAX_IX1MICROR2=y
CONFIG_HISAX_ASUSCOM=y
CONFIG_HISAX_TELEINT=y
CONFIG_HISAX_HFCS=y
CONFIG_HISAX_SPORTSTER=y
CONFIG_HISAX_MIC=y
CONFIG_HISAX_ISURF=y
CONFIG_HISAX_HSTSAPHIR=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
CONFIG_HISAX_DIEHLDIVA=y
CONFIG_HISAX_SEDLBAUER=y
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
# CONFIG_HISAX_DEBUG is not set
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_ST5481=m
CONFIG_HISAX_FRITZ_PCIPNP=m
CONFIG_USB_AUERISDN=m
#
# Active ISDN cards
#
CONFIG_ISDN_DRV_ICN=m
CONFIG_ISDN_DRV_PCBIT=m
CONFIG_ISDN_DRV_SC=m
CONFIG_ISDN_DRV_ACT2000=m
CONFIG_ISDN_DRV_EICON=y
CONFIG_ISDN_DRV_EICON_DIVAS=m
CONFIG_ISDN_DRV_EICON_OLD=m
CONFIG_ISDN_DRV_EICON_PCI=y
CONFIG_ISDN_DRV_EICON_ISA=y
CONFIG_ISDN_DRV_TPAM=m
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m
CONFIG_ISDN_DRV_AVMB1_B1ISA=m
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
CONFIG_ISDN_DRV_AVMB1_T1ISA=m
242
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
CONFIG_CD_NO_IDESCSI=y
CONFIG_AZTCD=m
CONFIG_GSCD=m
CONFIG_SBPCD=m
CONFIG_MCD=m
CONFIG_MCD_IRQ=11
CONFIG_MCD_BASE=300
CONFIG_MCDX=m
CONFIG_OPTCD=m
CONFIG_CM206=m
CONFIG_SJCD=m
CONFIG_ISP16_CDI=m
CONFIG_CDU31A=m
CONFIG_CDU535=m
#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_UINPUT=m
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=m
# CONFIG_SERIAL_EXTENDED is not set
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=m
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
CONFIG_DIGIEPCA=m
CONFIG_ESPSERIAL=m
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_ISI=m
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_N_HDLC=m
CONFIG_RISCOM8=m
CONFIG_SPECIALIX=m
# CONFIG_SPECIALIX_RTSCTS is not set
CONFIG_SX=m
243
CONFIG_RIO=m
CONFIG_RIO_OLDPCI=y
CONFIG_STALDRV=y
CONFIG_STALLION=m
CONFIG_ISTALLION=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
# CONFIG_SCx200_I2C is not set
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m
#
# Mice
#
CONFIG_BUSMOUSE=m
CONFIG_ATIXL_BUSMOUSE=m
CONFIG_LOGIBUSMOUSE=m
CONFIG_MS_BUSMOUSE=m
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_82C710_MOUSE=m
CONFIG_PC110_PAD=m
CONFIG_MK712_MOUSE=m
#
# Joysticks
#
CONFIG_INPUT_GAMEPORT=m
CONFIG_INPUT_NS558=m
CONFIG_INPUT_LIGHTNING=m
CONFIG_INPUT_PCIGAME=m
CONFIG_INPUT_CS461X=m
CONFIG_INPUT_EMU10K1=m
CONFIG_INPUT_SERIO=m
CONFIG_INPUT_SERPORT=m
#
# Joysticks
#
CONFIG_INPUT_ANALOG=m
CONFIG_INPUT_A3D=m
CONFIG_INPUT_ADI=m
CONFIG_INPUT_COBRA=m
CONFIG_INPUT_GF2K=m
CONFIG_INPUT_GRIP=m
244
CONFIG_INPUT_INTERACT=m
CONFIG_INPUT_TMDC=m
CONFIG_INPUT_SIDEWINDER=m
CONFIG_INPUT_IFORCE_USB=m
CONFIG_INPUT_IFORCE_232=m
CONFIG_INPUT_WARRIOR=m
CONFIG_INPUT_MAGELLAN=m
CONFIG_INPUT_SPACEORB=m
CONFIG_INPUT_SPACEBALL=m
CONFIG_INPUT_STINGER=m
CONFIG_INPUT_DB9=m
CONFIG_INPUT_GAMECON=m
CONFIG_INPUT_TURBOGRAFX=m
CONFIG_QIC02_TAPE=m
# CONFIG_QIC02_DYNCONF is not set
#
# Edit configuration parameters in ./include/linux/tpqic02.h!
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_SCx200 is not set
# CONFIG_SCx200_GPIO is not set
CONFIG_AMD_RNG=m
CONFIG_INTEL_RNG=m
CONFIG_HW_RANDOM=m
CONFIG_AMD_PM768=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_DTLK=m
CONFIG_R3964=m
CONFIG_APPLICOM=m
CONFIG_SONYPI=m
#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240
#
# The compressor will be built as a module only!
#
CONFIG_ZFT_COMPRESSOR=m
CONFIG_FT_NR_BUFFERS=3
CONFIG_FT_PROC_FS=y
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set
245
# Hardware configuration
#
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=m
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD_K8=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_ATI=y
#
# Direct Rendering Manager (XFree86 DRI support)
#
CONFIG_DRM=y
# CONFIG_DRM_OLD is not set
#
# DRM 4.1 drivers
#
CONFIG_DRM_NEW=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_GAMMA=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I810_XFREE_41=y
CONFIG_DRM_I830=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
#
# PCMCIA character devices
#
CONFIG_PCMCIA_SERIAL_CS=m
CONFIG_SYNCLINK_CS=m
CONFIG_MWAVE=m
CONFIG_OBMOUSE=m
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
CONFIG_I2C_PARPORT=m
246
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZR36120=m
CONFIG_VIDEO_MEYE=m
#
# Radio Adapters
#
CONFIG_RADIO_CADET=m
CONFIG_RADIO_RTRACK=m
CONFIG_RADIO_RTRACK2=m
CONFIG_RADIO_AZTECH=m
CONFIG_RADIO_GEMTEK=m
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_RADIO_MIROPCM20=m
CONFIG_RADIO_MIROPCM20_RDS=m
CONFIG_RADIO_SF16FMI=m
CONFIG_RADIO_SF16FMR2=m
CONFIG_RADIO_TERRATEC=m
CONFIG_RADIO_TRUST=m
CONFIG_RADIO_TYPHOON=m
CONFIG_RADIO_TYPHOON_PROC_FS=y
CONFIG_RADIO_ZOLTRIX=m
#
# File systems
#
CONFIG_QUOTA=y
CONFIG_QFMT_V2=m
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_ADFS_FS=m
CONFIG_ADFS_FS_RW=y
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EXT3_FS=m
CONFIG_JBD=m
247
CONFIG_JBD_DEBUG=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=y
CONFIG_EFS_FS=m
CONFIG_JFFS_FS=m
CONFIG_JFFS_FS_VERBOSE=0
# CONFIG_JFFS_PROC_FS is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_JFS_FS=m
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_MINIX_FS=m
CONFIG_VXFS_FS=m
CONFIG_NTFS_FS=m
CONFIG_NTFS_RW=y
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
CONFIG_QNX4FS_FS=m
CONFIG_QNX4FS_RW=y
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_RW=y
CONFIG_UFS_FS=m
CONFIG_UFS_FS_WRITE=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_RT=y
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set
#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_INTERMEZZO_FS=m
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
248
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_SMB_UNIX=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_ZISOFS_FS=y
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
CONFIG_SGI_PARTITION=y
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
# CONFIG_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_ISO8859_8=m
249
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m
#
# Frame-buffer support
#
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_RIVA=m
CONFIG_FB_CLGEN=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
CONFIG_FB_PM2_PCI=y
CONFIG_FB_PM3=m
CONFIG_FB_CYBER2000=m
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=m
CONFIG_FB_HGA=m
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_PROC=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_RADEON=m
CONFIG_FB_ATY128=m
CONFIG_FB_INTEL=m
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_3DFX=m
250
CONFIG_FB_VOODOO1=m
CONFIG_FB_TRIDENT=m
CONFIG_FB_IT8181=m
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FBCON_ADVANCED is not set
CONFIG_FBCON_MFB=m
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_VGA_PLANES=m
CONFIG_FBCON_HGA=m
# CONFIG_FBCON_FONTWIDTH8_ONLY is not set
# CONFIG_FBCON_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Sound
#
CONFIG_SOUND=m
CONFIG_SOUND_ALI5455=m
CONFIG_SOUND_ALI5455_CODECSPDIFOUT_PCMOUTSHARE=y
CONFIG_SOUND_ALI5455_CODECSPDIFOUT_CODECINDEPENDENTDMA=y
CONFIG_SOUND_ALI5455_CONTROLLERSPDIFOUT_PCMOUTSHARE=y
CONFIG_SOUND_ALI5455_CONTROLLERSPDIFOUT_CONTROLLERINDEPENDENTDMA=y
CONFIG_SOUND_BT878=m
CONFIG_SOUND_CMPCI=m
CONFIG_SOUND_CMPCI_FM=y
CONFIG_SOUND_CMPCI_FMIO=388
CONFIG_SOUND_CMPCI_FMIO=388
CONFIG_SOUND_CMPCI_MIDI=y
CONFIG_SOUND_CMPCI_MPUIO=330
CONFIG_SOUND_CMPCI_JOYSTICK=y
CONFIG_SOUND_CMPCI_CM8738=y
# CONFIG_SOUND_CMPCI_SPDIFINVERSE is not set
CONFIG_SOUND_CMPCI_SPDIFLOOP=y
CONFIG_SOUND_CMPCI_SPEAKERS=2
CONFIG_SOUND_EMU10K1=m
CONFIG_MIDI_EMU10K1=y
CONFIG_SOUND_FUSION=m
CONFIG_SOUND_CS4281=m
CONFIG_SOUND_ES1370=m
CONFIG_SOUND_ES1371=m
CONFIG_SOUND_ESSSOLO1=m
CONFIG_SOUND_MAESTRO=m
CONFIG_SOUND_MAESTRO3=m
CONFIG_SOUND_FORTE=m
CONFIG_SOUND_ICH=m
CONFIG_SOUND_RME96XX=m
CONFIG_SOUND_SONICVIBES=m
CONFIG_SOUND_TRIDENT=m
CONFIG_SOUND_MSNDCLAS=m
# CONFIG_MSNDCLAS_HAVE_BOOT is not set
CONFIG_MSNDCLAS_INIT_FILE="/etc/sound/msndinit.bin"
CONFIG_MSNDCLAS_PERM_FILE="/etc/sound/msndperm.bin"
CONFIG_SOUND_MSNDPIN=m
# CONFIG_MSNDPIN_HAVE_BOOT is not set
CONFIG_MSNDPIN_INIT_FILE="/etc/sound/pndspini.bin"
CONFIG_MSNDPIN_PERM_FILE="/etc/sound/pndsperm.bin"
CONFIG_SOUND_VIA82CXXX=m
251
CONFIG_MIDI_VIA82CXXX=y
CONFIG_SOUND_OSS=m
# CONFIG_SOUND_TRACEINIT is not set
# CONFIG_SOUND_DMAP is not set
CONFIG_SOUND_AD1816=m
CONFIG_SOUND_SGALAXY=m
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_ACI_MIXER=m
CONFIG_SOUND_CS4232=m
CONFIG_SOUND_SSCAPE=m
CONFIG_SOUND_GUS=m
CONFIG_SOUND_GUS16=y
CONFIG_SOUND_GUSMAX=y
CONFIG_SOUND_VMIDI=m
CONFIG_SOUND_TRIX=m
CONFIG_SOUND_MSS=m
CONFIG_SOUND_MPU401=m
CONFIG_SOUND_NM256=m
CONFIG_SOUND_MAD16=m
CONFIG_MAD16_OLDCARD=y
CONFIG_SOUND_PAS=m
# CONFIG_PAS_JOYSTICK is not set
CONFIG_SOUND_PSS=m
CONFIG_PSS_MIXER=y
# CONFIG_PSS_HAVE_BOOT is not set
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
CONFIG_SOUND_KAHLUA=m
CONFIG_SOUND_WAVEFRONT=m
CONFIG_SOUND_MAUI=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_OPL3SA1=m
CONFIG_SOUND_OPL3SA2=m
CONFIG_SOUND_YMFPCI=m
CONFIG_SOUND_YMFPCI_LEGACY=y
CONFIG_SOUND_UART6850=m
CONFIG_SOUND_AEDSP16=m
CONFIG_SC6600=y
CONFIG_SC6600_JOY=y
CONFIG_SC6600_CDROM=4
CONFIG_SC6600_CDROMBASE=0
CONFIG_AEDSP16_SBPRO=y
CONFIG_AEDSP16_MPU401=y
CONFIG_SOUND_TVMIXER=m
CONFIG_SOUND_WM97XX=m
#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
252
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m
CONFIG_USB_SL811HS_ALT=m
CONFIG_USB_SL811HS=m
#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m
CONFIG_USB_EMI26=m
#
# USB Bluetooth can only be used with disabled Bluetooth subsystem
#
CONFIG_USB_MIDI=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
#
# USB Imaging devices
#
CONFIG_USB_DC2XX=m
CONFIG_USB_MDC800=m
CONFIG_USB_SCANNER=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m
#
# USB Multimedia devices
#
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_OV511=m
CONFIG_USB_PWC=m
253
CONFIG_USB_SE401=m
CONFIG_USB_STV680=m
CONFIG_USB_W9968CF=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_DABUSB=m
#
# USB Network adaptors
#
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_KAWETH=m
CONFIG_USB_CATC=m
CONFIG_USB_CDCETHER=m
CONFIG_USB_USBNET=m
#
# USB port drivers
#
CONFIG_USB_USS720=m
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_DEBUG is not set
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m
254
# USB Miscellaneous drivers
#
CONFIG_USB_RIO500=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_TIGL=m
CONFIG_USB_BRLVGER=m
CONFIG_USB_LCD=m
CONFIG_USB_SPEEDTOUCH=m
#
# Support for USB gadgets
#
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_NET2280=y
# CONFIG_USB_GADGET_GOKU is not set
# CONFIG_USB_GADGET_CONTROLLER is not set
CONFIG_USB_NET2280=m
CONFIG_USB_GADGET_CONTROLLER=m
CONFIG_USB_GADGET_DUALSPEED=y
#
# USB Gadget Drivers
#
CONFIG_USB_ZERO=m
CONFIG_USB_ETH=m
CONFIG_USB_ETH_RNDIS=y
CONFIG_USB_FILE_STORAGE=m
CONFIG_USB_FILE_STORAGE_TEST=y
#
# Bluetooth support
#
CONFIG_BLUEZ=m
CONFIG_BLUEZ_L2CAP=m
CONFIG_BLUEZ_SCO=m
CONFIG_BLUEZ_RFCOMM=m
CONFIG_BLUEZ_RFCOMM_TTY=y
CONFIG_BLUEZ_BNEP=m
CONFIG_BLUEZ_BNEP_MC_FILTER=y
CONFIG_BLUEZ_BNEP_PROTO_FILTER=y
CONFIG_BLUEZ_CMTP=m
#
# Bluetooth device drivers
#
CONFIG_BLUEZ_HCIUSB=m
CONFIG_BLUEZ_HCIUSB_SCO=y
CONFIG_BLUEZ_HCIUART=m
CONFIG_BLUEZ_HCIUART_H4=y
CONFIG_BLUEZ_HCIUART_BCSP=y
CONFIG_BLUEZ_HCIUART_BCSP_TXCRC=y
CONFIG_BLUEZ_HCIBFUSB=m
CONFIG_BLUEZ_HCIDTL1=m
CONFIG_BLUEZ_HCIBT3C=m
CONFIG_BLUEZ_HCIBLUECARD=m
CONFIG_BLUEZ_HCIBTUART=m
CONFIG_BLUEZ_HCIVHCI=m
#
# Kernel hacking
#
255
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_LOG_BUF_SHIFT=0
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_TEST=m
#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_FW_LOADER=m
APENDICE III
Manual de cisilia
256
NOMBRE
cisilia - Sistema de obtención de contraseñas multiproceso
SINOPSIS
cisilia [OPCIONES] archivo_contraseñas
ESQUEMA MULTIPROCESO
La ejecución en paralelo se realiza a través de fork().
Se generan los siguientes procesos:
1 proceso padre que crea todos los subprocesos y controla la administración, las
comunicaciones y la sincronización.
1 subproceso diccionario (sólo si se selecciona la opción -d).
n subprocesos de fuerza bruta (seleccionados con la opción -n).
OPCIONES
-a, --alfa=archivo_alfabeto
carga un alfabeto desde archivo_alfabeto. (Ver la sección ARCHIVOS para
más información sobre el formato del archivo de alfabeto). El alfabeto
predeterminado es [A-Z] si la macro ALFABETO_NUMERICO es cero, si no
es [A-Z;0-9].
-d, --dict=archivo_diccionario
carcga un diccionario desde archivo_diccionario. (Ver la sección ARCHIVOS
para más información sobre el formato del archivo de diccionario).
-h, --help
imprime un mensaje de ayuda y termina el programa.
-l, --log=archivo_registro
agrega las contraseñas obtenidas a archivo_diccionario durante la ejecucuón.
-n, --proc=num
define el número de subprocesos de fuerza bruta. El número predeterminado es
1.
-p, --port=num
define el puerto de escucha TCP/UDP . El puerto predeterminado es 6666. Si
num es cero, se selecciona un puerto libre al azar.
257
-v, --version
imprime la versión y termina el programa.
-V, --verbose
hace que cisilia imprime mensajes de su progreso en stderr que puede ser de
ayuda para la depuración.
-x, --frontend=host:port
fuerza a cisilia a conectarse a un front-end ubicado en host:port. (El objetivo de
este parámetro es que sea utilizado sólo por el front-end).
ARCHIVOS
archivo_contraseñas
un archivo que contenga varias líneas como la siguiente:
nombre_de_usuario:id_del_usuario:Hash_LanManager:NT/Hash_MD4
Las líneas que comienzan con un '#' (sólo en la primer columna) serán ignoradas
(por ejemplo el archivo de contraseñas de Samba, smbpasswd).
archivo_alfabeto
es válido cualquier archivo de texto, se utilizan todos los caracteres imprimibles,
en orden de aparición, sin repeticiones.
archivo_diccionario
una lista de palabras de cualquier longitud. Actualmente se leen sólo los
primeros 14 caracteres de cada línea.
APENDICE IV
Descripción del Cluster Cloutser
258
El prototipo del Cluster Cloutser es un producto basado en sistemas de Imagen
Única provisto por las extensiones del Kernel de LINUX que provee OpenMosix y
OpenSSI. A pesar de que esta sección no pretende ser una guía de instalación de
sistemas OpenMosix o OpenSSI, en ella se enumeran los puntos principales para la
implementación de ambos sistemas y, particularmente, los que tienen que ver con el
funcionamiento de éstos sistemas en un mismo Cluster. Como ya se mencionó en la
sección introductoria de éste trabajo, se instaló una plataforma que permite a sus
usuarios obtener el mejor rendimiento y desempeño de sus recursos computacionales. Se
tomaron en cuenta dos escenarios típicos de uso para la plataforma:
1) aplicaciones de tipo secuencial, realizando tareas de cálculo paramétrico y que

pueden ser distribuidas a lo largo de los nodos del Cluster gracias al sistema de migración
de procesos que ofrece OpenMosix y OpenSSI, sin requerir de modificación alguna en su
código para tal fin;
2) aplicaciones paralelas usando librerías de paso de mensaje, específicamente

MPI.
Los nodos del Cluster Cloutser tienen la siguiente configuración básica:
Dos portátiles:
- Procesador Intel P4 de 1.6 GHz, 1Gbyte de memoria RAM, Disco Duro de

80GB@7200
RPM, 2 NICs Fast Ethernet.
- Procesador Intel P4 de 2 GHz, 1Gbyte de memoria RAM, Disco Duro de

100GB@7200
RPM, 2 NICs Fast Ethernet.
Un sobremesa:
- AMD Burton 2.21 Ghz 1,00GB de RAM @ 400 MHz GeForce FX 5800 256 MBs
Los nodos están interconectados a través de dos unidades Switch Fast Ethernet de 16
puertos, uno para cada canal. El proceso de instalación de un Cluster LINUX requiere de
cierto nivel de conocimiento sobre administración de sistemas y redes. Parte de la
información necesaria para la correcta instalación del sistema operativo, así como la
configuración de librerías básicas para el Cluster, como MPI o PVM y las extensiones
del kernel de OpenMosix y OpenSSI se encuentran en sus manuales de instalación.
259

Comparativa de Clusters SSI

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Comparativa de Clusters SSI

Încărcat de

Drepturi de autor:

Formate disponibile

INGENIERO EN INFORMÁTICA

COMPARATIVA DE CLUSTERS SSI

Villaviciosa de Odón, Junio de 2007

• A todos nuestros profesores, por transmitirnos sus conocimientos de la manera

A todos vosotros, muchas gracias...

Nuestro principal objetivo es medir la eficiencia y el comportamiento de

Como objetivo secundario se ha planteado el comparar el rendimiento entre un

Un cluster SSI (Single System Image) es un sistema compuesto por la unión de

Dentro de los diversos middleware que existen se comenzará con la instalación

Un cluster se puede entender como:

Un conjunto de máquinas unidas por una red de comunicación trabajando por

Realmente el cambio de ambiente es mínimo, desde luego a nadie se le ocurriría

Hay definiciones que distinguen entre cluster de máquinas SMP y clusters

Por poner unos ejemplos de la disparidad de opiniones que existen, se adjuntan

Un cluster consiste en un conjunto de máquinas y un servidor de cluster

Un cluster es la variación de bajo precio de un multiprocesador masivamente

Por esta razón se deduce la primera característica de un cluster:

- Un cluster consta de 2 o más nodos.

- Los nodos de un cluster están conectados entre sí por, al menos, un canal de

Por ahora se ha referenciado a las características físicas de un cluster, que son

- Los clusters necesitan software de control especializado.

Como es obvio las características del cluster son completamente dependientes

• Software a nivel de aplicación.

Este tipo de software se sitúa a nivel de aplicación, se utilizan

• Software a nivel de sistema.

Este tipo de software se sitúa a nivel de sistema, suele estar

Es más crítico y complejo, por otro lado suele resolver problemas de

1.2.1 Esquema y otras características

Las características básicas de un cluster de carácter general podrían resumirse en

1. Un cluster consta de 2 o más nodos conectados entre sí, por un canal de

Muchos libros dan otra serie de características necesarias (Scalable Parallel

En general la catalogación de los clusters se hace en base a tres factores de

Se hace uso de un nodo maestro desde el cual se puede configurar el

En un modelo distribuido donde cada nodo debe administrarse y gestionarse.

Es propio de sistemas distribuidos, como ventaja presenta más tolerancia a fallos,

Se distingue entre 3 tipos de acoplamiento:

El software que entra en este grupo es software cuyos elementos se

A este grupo pertenece un software que no necesita un conocimiento tan

Generalmente se basan en aplicaciones construidas por bibliotecas preparadas

o Tiempos de acceso distintos

Existen otros muchos factores de diseño que limitan el comportamiento y

Por regla general la proporción coste/capacidad de cálculo aumenta de forma

Por último está el factor de escalabilidad, del cual se habló en el tema de

Alto rendimiento (HP, high performance)

Los clusters de alta disponibilidad son bastante ortogonales en lo que se refieren

Alta confiabilidad (HR, high reliability)

Pueden existir otras catalogaciones en lo que se refiere a tipos de clusters, en

Se harán distinciones entre los que se implementan a nivel de sistema operativo

Dentro de esta definición no se engloba ningún tipo de problema en concreto.

1.4.1.2 Problemas que solucionan

Generalmente estos problemas de cómputo suelen estar ligados a:

1.4.1.3 Técnicas que utilizan

Las técnicas utilizadas dependen de a qué nivel trabaje el cluster.

Los clusters implementados a nivel de aplicación no suelen implementar

Entre las limitaciones que existen actualmente está la incapacidad de balancear

1.4.2 Clusters HA: alta disponibilidad

Los clusters de alta disponibilidad han sido diseñados para la máxima

Mediante estos tres tipos de actuaciones y los mecanismos que lo implementan

1.4.2.2 Problemas que solucionan

La mayoría de estos problemas están ligados a la necesidad de dar servicio

Entre los problemas que solucionan se encuentran:

En general todos estos problemas se ligan en dos fuentes de necesidad de las

• Tener un servicio disponible

El servicio puede ser diverso. Desde un sistema de ficheros distribuidos de