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

2

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

3

4

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

5

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

6

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.4 Características.........................................................................................................................165 14.5 Limitaciones ...........................................................................................................................165 14.6 Instalación de un cluster OpenSSI ........................................................................................166

15. OPENSSI WEBVIEW ................................................................................................................175 15.1 Introducción ............................................................................................................................175 15.2 Características.........................................................................................................................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

7

CONFIGURACIÓN DEL KERNEL....................................................................................................................221 APENDICE III ..............................................................................................................................................256

MANUAL DE CISILIA....................................................................................................................................256 APENDICE IV...............................................................................................................................................258

DESCRIPCIÓN DEL CLUSTER CLOUTSER.....................................................................................................258

INDICE ILUSTRACIONES

8

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

9

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

10

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.

11

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.

12

13

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

14

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.

15

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.

16

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

17

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

18

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.

19

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

20

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.

21

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.

22

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.

23

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

24

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:

25

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

26

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.

27

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

28

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

29

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.

30

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.

31

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

32

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:

33

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

34

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.

35

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

36

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.

37

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

38

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.

39

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.

40

• 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

41

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

42

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

43

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.

44

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

45

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

46

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.

47

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.

48

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.

49

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.

50

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.

51

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.

52

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

53

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.

54

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:

55

ftp.monitor monitor de FTP, comprueba el estado para poder acceder a un servidor FTPD 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.

56

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.

57

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.

58

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

59

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.

60

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.

61

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

62

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

63

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.

64

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.

65

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.

66

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.

67

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.

68

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.

69

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.

70

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:

71

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

72

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

73

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.

74

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.

75

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

76

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.

77

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.

78

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

79

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.

80

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.

81

82

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”

83

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.

84

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

85

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

86

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.

87

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

88

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

89

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:

90

• Cargadores. • Compiladores. • Ensambladores. • Macros.

6. DEBIAN GNU/LINUX 6.1 Introducción

91

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

92

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:

93

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

94

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.

95

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.

96

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.

97

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.

98

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

99

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.

100

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.

101

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í".

102

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

103

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.

104

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.

105

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.

106

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

107

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.

108

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.

109

110

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

111

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.

112

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.

113

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.

114

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.

115

10.5 Características

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.

116

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.

117

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

118

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.

119

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.

120

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

121

# 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

122

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:

123

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.

124

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

125

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

126

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˜no 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.

127

• 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

128

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

129

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.

130

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´on 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:

131

• ./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 .

132

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.

133

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

134

~ 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 ~ 2 minutos 29 segundos starting timewaster at Thu Apr 26 20:29:48 EDT 2007 finished timewaster at Thu Apr 26 20:35:34 EDT 2007 ~ 5 minutos 46 segundos starting oMFStest at Thu Apr 26 20:35:34 EDT 2007 finished oMFStest at Thu Apr 26 20:36:42 EDT 2007 ~ 1 minuto 8 segundos output from the (local) kernel tests running kernel+syscall on the local kernel output from the (local) kernel tests 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

135

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

136

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 migrated 20116 to node 10 output from distkeygen test migrated 18809 to node 8 migrated 20116 to node 8 ~ migra el proceso 20116 al nodo 8 migrated 18809 to node 9 migrated 20116 to node 9 ~ migra el proceso 20116 al nodo 9 migrated 18809 to node 10 migrated 20116 to node 10 ~ 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. migrated 18809 to node 8 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). migrated 20116 to node 8 CHILD: I'm finished here! 20198 migrated 18809 to node 9 CHILD: I'm finished here! 20196 migrated 20116 to node 9 CHILD: I'm finished here! 20194

137

PARENT: About to quit! ~proceso padre acabado, no es zombi. output from portfolio test started portfolio 1. time started portfolio 2. time started portfolio 3. time started portfolio 4. time started portfolio 5. time started portfolio 6. time started portfolio 7. time started portfolio 8. time started portfolio 9. time started portfolio 10. time output from eatmem test starting an eatmem instance starting an eatmem instance starting an eatmem instance output from forkit test started forkit 1. time starting 3 forkit instances Proc 3 started. started forkit 2. time migrated 18809 to node 10 starting 3 forkit instances ~divide el proceso en varios, mediante el comando unix fork, actualmente tres instancias. Proc 0 started. starting 3 forkit instances Proc 2 started. migrated 20116 to node 8 starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. started forkit 3. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances

138

Proc 3 started. starting 3 forkit instances Proc 0 started. started forkit 4. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 3 started. started forkit 5. time starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 0 started. migrated 18809 to node 8 starting 3 forkit instances Proc 3 started. started forkit 6. time migrated 20116 to node 9 starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. started forkit 7. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 3 started. started forkit 8. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. started forkit 9. time starting 3 forkit instances

139

Proc 0 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 3 started. started forkit 10. time migrated 18809 to node 9 starting 3 forkit instances Proc 0 started. migrated 20116 to node 10 starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. output from timewaster test starting 3 timewaster processes 1. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 2. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 18809 to node 10 migrated 20116 to node 8 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 3. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully migrated 18809 to node 8 finished successfully finished successfully starting 3 timewaster processes 4. time starting timewaster 0

140

starting timewaster 1 starting timewaster 2 migrated 20116 to node 9 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 5. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 18809 to node 9 finished successfully migrated 20116 to node 10 finished successfully finished successfully finished successfully starting 3 timewaster processes 6. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 7. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 18809 to node 10 migrated 20116 to node 8 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 8. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 9. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 18809 to node 8 migrated 20116 to node 9 finished successfully

141

finished successfully finished successfully finished successfully starting 3 timewaster processes 10. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully output from oMFS test migrated 18809 to node 9 cp /tmp/testfile.zero from here to node 10 cp /tmp/testfile.zero from mfs-node 10 to local nodes equal! do not cp nodes equal! do not cp cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from mfs-node 8 to local cp /tmp/testfile.zero from mfs-node 8 to mfs-node 10 cp /tmp/testfile.zero from mfs-node 10 to mfs-node 8 cp /tmp/testfile.zero from here to node 9 cp /tmp/testfile.zero from mfs-node 9 to local cp /tmp/testfile.zero from mfs-node 9 to mfs-node 10 cp /tmp/testfile.zero from mfs-node 10 to mfs-node 9 cp /tmp/testfile.zero from here to node 10 cp /tmp/testfile.zero from mfs-node 10 to local cp /tmp/testfile.zero from mfs-node 10 to mfs-node 8 cp /tmp/testfile.zero from mfs-node 8 to mfs-node 10 cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from mfs-node 8 to local nodes equal! do not cp nodes equal! do not cp cp /tmp/testfile.zero from here to node 9 cp /tmp/testfile.zero from mfs-node 9 to local cp /tmp/testfile.zero from mfs-node 9 to mfs-node 8 cp /tmp/testfile.zero from mfs-node 8 to mfs-node 9 cp /tmp/testfile.zero from here to node 10 cp /tmp/testfile.zero from mfs-node 10 to local cp /tmp/testfile.zero from mfs-node 10 to mfs-node 9 cp /tmp/testfile.zero from mfs-node 9 to mfs-node 10 cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from mfs-node 8 to local cp /tmp/testfile.zero from mfs-node 8 to mfs-node 9 cp /tmp/testfile.zero from mfs-node 9 to mfs-node 8 cp /tmp/testfile.zero from here to node 9 cp /tmp/testfile.zero from mfs-node 9 to local migrated 20116 to node 10 nodes equal! do not cp nodes equal! do not cp

142

delete /mfs/10/tmp/testfile.zero delete /mfs/8/tmp/testfile.zero delete /mfs/9/tmp/testfile.zero finished ok 12.1.3.2 Realización de las pruebas sin cluster (1 nodo)

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 1 nodes Tiempo en realizar cada prueba: Timing from the application test starting distkeygen at Thu Apr 26 20:43:42 EDT 2007 finished distkeygen at Thu Apr 26 20:57:10 EDT 2007 ~ 13 minutos 28 segundos starting portfolio at Thu Apr 26 20:57:10 EDT 2007 finished portfolio at Thu Apr 26 20:59:10 EDT 2007 ~ 2 minutos starting eatmem at Thu Apr 26 20:59:10 EDT 2007 finished eatmem at Thu Apr 26 21:00:26 EDT 2007 ~ 1 minuto 16 segundo. starting forkit at Thu Apr 26 21:00:26 EDT 2007 finished forkit at Thu Apr 26 21:02:44 EDT 2007 ~ 2 minutos 18 segundos. starting timewaster at Thu Apr 26 21:02:44 EDT 2007 finished timewaster at Thu Apr 26 21:12:50 EDT 2007 ~ 10 minutos 6 segundos. starting oMFStest at Thu Apr 26 21:12:50 EDT 2007 finished oMFStest at Thu Apr 26 21:14:51 EDT 2007 ~ 2 minutos 1 segundos output from the (local) kernel tests

143

running kernel+syscall on the local kernel output from the (local) kernel tests 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 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

144

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 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 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 start moving.sh on myself running migrate-loop on process 23744 migrated 23744 to node 8 ~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. output from distkeygen test migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8

145

migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 CHILD: I'm finished here! 23808 ~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). CHILD: I'm finished here! 23806 CHILD: I'm finished here! 23807 CHILD: I'm finished here! 23809 PARENT: About to quit! ~proceso padre acabado, no es zombi. output from portfolio test started portfolio 1. time started portfolio 2. time started portfolio 3. time started portfolio 4. time started portfolio 5. time started portfolio 6. time started portfolio 7. time started portfolio 8. time started portfolio 9. time started portfolio 10. time output from eatmem test starting an eatmem instance output from forkit test started forkit 1. time starting 1 forkit instances Proc 1 started. started forkit 2. time starting 1 forkit instances Proc 0 started. migrated 23744 to node 8 starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 3. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started.

146

started forkit 4. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 5. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 6. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 7. time starting 1 forkit instances Proc 1 started. started forkit 8. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 9. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 10. time migrated 23744 to node 8 starting 1 forkit instances Proc 1 started. output from timewaster test starting 1 forkit instances Proc 0 started. starting 1 timewaster processes 1. time starting timewaster 0 finished successfully starting 1 timewaster processes 2. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully finished successfully starting 1 timewaster processes 3. time starting timewaster 0 migrated 23744 to node 8 finished successfully

147

finished successfully starting 1 timewaster processes 4. time starting timewaster 0 migrated 23744 to node 8 finished successfully starting 1 timewaster processes 5. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully starting 1 timewaster processes 6. time starting timewaster 0 finished successfully finished successfully finished successfully starting 1 timewaster processes 7. time starting timewaster 0 migrated 23744 to node 8 finished successfully starting 1 timewaster processes 8. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully finished successfully starting 1 timewaster processes 9. time starting timewaster 0 migrated 23744 to node 8 finished successfully starting 1 timewaster processes 10. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully output from oMFS test finished successfully cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from mfs-node 8 to local nodes equal! do not cp nodes equal! do not cp delete /mfs/8/tmp/testfile.zero finished ok 12.2 Test de OpenMosixview 12.2.1 Aplicación Principal

148

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.

149

• 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´apido

(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

150

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˜nade 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

151

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

152

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

153

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

154

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

155

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

156

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:

• La linea de comando que se debe ejecutar es la siguiente:

./cisilia –l crack_file –n 4 /home/Desktop/ pwfile4digitos

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/pwfile4digitos. Ruta en la que se encuentra el archivo con las contraseñas.

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

157

esta vez el archivo contiene una clave, 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 6 digitos:

• La linea de comando que se debe ejecutar es la siguiente:

./cisilia –l crack_file –n 4 /home/Desktop/ pwfile6digitos

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/pwfile6digitos. Ruta en la que se encuentra el archivo con las contraseñas.

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 de cisilia para un archivo de contraseñas con una clave de 8 digitos:

• La linea de comando que se debe ejecutar es la siguiente:

./cisilia –l crack_file –n 4 /home/Desktop/ pwfile8digitos

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/pwfile8digitos. Ruta en la que se encuentra el archivo con las contraseñas.

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

158

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.

159

160

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“

161

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

162

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.

163

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.

164

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.

165

14.4 Características

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

166

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

167

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:

168

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

169

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/

170

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.

171

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:

172

# 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 name)

173

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

174

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.

175

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.

15.2 Características

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.

176

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

177

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:

178

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

179

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.

180

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:

181

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.

182

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:

183

• ./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 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 May 17 17:39:05 EDT 2007 finished distkeygen at Thu May 17 17:45:04 EDT 2007 ~ 5 minutos 59 segundos starting portfolio at Thu May 17 17:45:04 EDT 2007 finished portfolio at Thu May 17 17:46:07 EDT 2007 ~ 1 minuto 3 segundos starting eatmem at Thu May 17 17:46:07 EDT 2007 finished eatmem at Thu May 17 17:47:56 EDT 2007

184

~ 1 minuto 49 segundos starting forkit at Thu May 17 17:47:56 EDT 2007 finished forkit at Thu May 17 17:50:17 EDT 2007 ~ 2 minutos 21 segundos starting timewaster at Thu May 17 17:50:17 EDT 2007 finished timewaster at Thu May 17 17:56:33 EDT 2007 ~ 6 minutos 26 segundos starting oSSIStest at Thu May 17 17:56:33 EDT 2007 finished oSSIStest at Thu May 17 17:57:43 EDT 2007 ~ 1 minuto 10 segundos output from the (local) kernel tests running kernel+syscall on the local kernel output from the (local) kernel tests 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 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.

185

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 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 openSSI del Stress-Test con cluster de tres nodos: the results will be saved in : /tmp/openSSI-stress-test-report-0572346011.txt

186

oSSIS is mounted at /mfs and will be tested migrated 45636 to node 10 my PID is 13567 ~ mi identificador de proceso start moving.sh on myself running migrate-loop on process 13567 migrated 13567 to node 10 output from distkeygen test migrated 45636 to node 8 migrated 13567 to node 8 ~ migra el proceso 13567 al nodo 8 migrated 45636 to node 9 migrated 13567 to node 9 ~ migra el proceso 13567 al nodo 9 migrated 45636 to node 10 migrated 13567 to node 10 ~ 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. migrated 45636 to node 8 CHILD: I'm finished here! 13568 ~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). migrated 13567 to node 8 CHILD: I'm finished here! 13569 migrated 45636 to node 9 CHILD: I'm finished here! 13567 migrated 13567 to node 9 CHILD: I'm finished here! 13565 PARENT: About to quit! ~proceso padre acabado, no es zombi. output from portfolio test started portfolio 1. time started portfolio 2. time started portfolio 3. time

187

started portfolio 4. time started portfolio 5. time started portfolio 6. time started portfolio 7. time started portfolio 8. time started portfolio 9. time started portfolio 10. time output from eatmem test starting an eatmem instance starting an eatmem instance starting an eatmem instance output from forkit test started forkit 1. time starting 3 forkit instances Proc 3 started. started forkit 2. time migrated 45636 to node 10 starting 3 forkit instances ~divide el proceso en varios, mediante el comando unix fork, actualmente tres instancias. Proc 0 started. starting 3 forkit instances Proc 3 started. migrated 13567 to node 8 starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. started forkit 3. time starting 3 forkit instances Proc 3 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 3 started. starting 3 forkit instances Proc 0 started. started forkit 4. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started.

188

starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 3 started. started forkit 5. time starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 0 started. migrated 45636 to node 8 starting 3 forkit instances Proc 3 started. started forkit 6. time migrated 13567 to node 9 starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. started forkit 7. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 3 started. started forkit 8. time starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. started forkit 9. time starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 0 started. starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 3 started. started forkit 10. time

189

migrated 45636 to node 9 starting 3 forkit instances Proc 0 started. migrated 13567 to node 10 starting 3 forkit instances Proc 2 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 1 started. starting 3 forkit instances Proc 3 started. output from timewaster test starting 3 timewaster processes 1. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 2. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 45636 to node 10 migrated 13567 to node 8 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 3. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully migrated 45636 to node 8 finished successfully finished successfully starting 3 timewaster processes 4. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 13567 to node 9 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 5. time

190

starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 45636 to node 9 finished successfully migrated 13567 to node 10 finished successfully finished successfully finished successfully starting 3 timewaster processes 6. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 7. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 45636 to node 10 migrated 13567 to node 8 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 8. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 9. time starting timewaster 0 starting timewaster 1 starting timewaster 2 migrated 45636 to node 8 migrated 13567 to node 9 finished successfully finished successfully finished successfully finished successfully starting 3 timewaster processes 10. time starting timewaster 0 starting timewaster 1 starting timewaster 2 finished successfully

191

finished successfully finished successfully finished successfully output from oSSIFS test migrated 45636 to node 9 cp /tmp/testfile.zero from here to node 10 cp /tmp/testfile.zero from ssi-node 10 to local nodes equal! do not cp nodes equal! do not cp cp /tmp/testfile.zero from here to node 8 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 ssifs-node 10 to mfs-node 8 cp /tmp/testfile.zero from here to node 9 cp /tmp/testfile.zero from ssifs-node 9 to local cp /tmp/testfile.zero from ssifs-node 9 to mfs-node 10 cp /tmp/testfile.zero from ssifs-node 10 to mfs-node 9 cp /tmp/testfile.zero from here to node 10 cp /tmp/testfile.zero from ssifs-node 10 to local cp /tmp/testfile.zero from ssifs-node 10 to mfs-node 8 cp /tmp/testfile.zero from ssifs-node 8 to mfs-node 10 cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from ssi-node 8 to local nodes equal! do not cp nodes equal! do not cp cp /tmp/testfile.zero from here to node 9 cp /tmp/testfile.zero from ssifs-node 9 to local cp /tmp/testfile.zero from ssifs-node 9 to mfs-node 8 cp /tmp/testfile.zero from ssifs-node 8 to mfs-node 9 cp /tmp/testfile.zero from here to node 10 cp /tmp/testfile.zero from ssifs-node 10 to local cp /tmp/testfile.zero from ssifs-node 10 to mfs-node 9 cp /tmp/testfile.zero from ssifs-node 9 to mfs-node 10 cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from ssifs-node 8 to local cp /tmp/testfile.zero from ssifs-node 8 to mfs-node 9 cp /tmp/testfile.zero from ssifs-node 9 to mfs-node 8 cp /tmp/testfile.zero from here to node 9 cp /tmp/testfile.zero from ssifs-node 9 to local migrated 13567 to node 10 nodes equal! do not cp nodes equal! do not cp delete /ssifs/10/tmp/testfile.zero delete /ssifs/8/tmp/testfile.zero delete /ssifs/9/tmp/testfile.zero finished ok 16.1.3.2 Realización de las pruebas con cluster(1 nodo)

192

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 1 nodes Tiempo en realizar cada prueba: Timing from the application test starting distkeygen at Thu Apr 26 20:43:42 EDT 2007 finished distkeygen at Thu Apr 26 20:57:10 EDT 2007 ~ 13 minutos 28 segundos starting portfolio at Thu Apr 26 20:57:10 EDT 2007 finished portfolio at Thu Apr 26 20:59:10 EDT 2007 ~ 2 minutos starting eatmem at Thu Apr 26 20:59:10 EDT 2007 finished eatmem at Thu Apr 26 21:00:26 EDT 2007 ~ 1 minuto 16 segundo. starting forkit at Thu Apr 26 21:00:26 EDT 2007 finished forkit at Thu Apr 26 21:02:44 EDT 2007 ~ 2 minutos 18 segundos starting timewaster at Thu Apr 26 21:02:44 EDT 2007 finished timewaster at Thu Apr 26 21:12:50 EDT 2007 ~ 10 minutos 6 segundos. starting oSSIFStest at Thu Apr 26 21:12:50 EDT 2007 finished oSSIFStest at Thu Apr 26 21:14:51 EDT 2007 ~ 2 minutos 1 segundos output from the (local) kernel tests running kernel+syscall on the local kernel output from the (local) kernel tests Versión de nuestro Sistema Operativo, kernel y diferentes programas utilizados. /etc/issue:

193

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

194

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 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 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 start moving.sh on myself running migrate-loop on process 23744 migrated 23744 to node 8 ~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. output from distkeygen test migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 migrated 23744 to node 8 CHILD: I'm finished here! 23808

195

~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). CHILD: I'm finished here! 23806 CHILD: I'm finished here! 23807 CHILD: I'm finished here! 23809 PARENT: About to quit! ~proceso padre acabado, no es zombi. output from portfolio test started portfolio 1. time started portfolio 2. time started portfolio 3. time started portfolio 4. time started portfolio 5. time started portfolio 6. time started portfolio 7. time started portfolio 8. time started portfolio 9. time started portfolio 10. time output from eatmem test starting an eatmem instance output from forkit test started forkit 1. time starting 1 forkit instances Proc 1 started. started forkit 2. time starting 1 forkit instances Proc 0 started. migrated 23744 to node 8 starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 3. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 4. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 5. time starting 1 forkit instances Proc 0 started.

196

starting 1 forkit instances Proc 1 started. started forkit 6. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 7. time starting 1 forkit instances Proc 1 started. started forkit 8. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 9. time starting 1 forkit instances Proc 0 started. starting 1 forkit instances Proc 1 started. started forkit 10. time migrated 23744 to node 8 starting 1 forkit instances Proc 1 started. output from timewaster test starting 1 forkit instances Proc 0 started. starting 1 timewaster processes 1. time starting timewaster 0 finished successfully starting 1 timewaster processes 2. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully finished successfully starting 1 timewaster processes 3. time starting timewaster 0 migrated 23744 to node 8 finished successfully finished successfully starting 1 timewaster processes 4. time starting timewaster 0 migrated 23744 to node 8 finished successfully starting 1 timewaster processes 5. time starting timewaster 0 finished successfully

197

migrated 23744 to node 8 finished successfully starting 1 timewaster processes 6. time starting timewaster 0 finished successfully finished successfully finished successfully starting 1 timewaster processes 7. time starting timewaster 0 migrated 23744 to node 8 finished successfully starting 1 timewaster processes 8. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully finished successfully starting 1 timewaster processes 9. time starting timewaster 0 migrated 23744 to node 8 finished successfully starting 1 timewaster processes 10. time starting timewaster 0 finished successfully migrated 23744 to node 8 finished successfully output from oSSIFS test finished successfully cp /tmp/testfile.zero from here to node 8 cp /tmp/testfile.zero from ssifs-node 8 to local nodes equal! do not cp nodes equal! do not cp delete /ssifs/8/tmp/testfile.zero finished ok

198

199

CAPITULO V SEGUNDA LEY DE GILB SOBRE LA FIABILIDAD -“Cualquier sistema que dependa de la precisión humana, es impreciso”

200

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.

201

distkeygen

portfolio

eatmen

forkit

timewaster

oMFStest/oSSIFSTest02,01

10,06

2,30

0 1,31

02,0013,28

0

2

4

6

8

10

12

14

Tiempo

(minutos)

StressTest - 1 Nodo

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

202

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 distkeygen 6 minutos 12 segundos portfolio 1 minutos 01 segundos eatmem 1 minutos 22 segundos forkit 2 minutos 29 segundos timewaster 5 minutos 46 segundos oMFStest 1 minutos 08 segundos

Tabla 9 Stress-Test OpenMosix – 3 Nodos

distkeygen

portfolio

eatmen

forkit

timewaster

oMFStest0

1,08

5,46

2,29

01,22

01,01

6,12

0

1

2

3

4

5

6

7

Tiempo

(minutos)

StressTest OM - 3 Nodos

distkeygen portfolio eatmen forkit timewaster oMFStest

Figura 28 StressTest OpenMosix 3 Nodos

203

Stress-Test OpenSSI – 3 Nodos distkeygen 5 minutos 59 segundos portfolio 1 minutos 03 segundos eatmem 1 minutos 49 segundos forkit 2 minutos 21 segundos timewaster 6 minutos 26 segundos oSSIFStest 1 minutos 01 segundos

Tabla 10 Stress-Test OpenSSI – 3 Nodos

distkeygen

portfolio

eatmen

forkit

timeaster

oSSIFStest01,1

6,26

0

2,21

0

1,49

01,03

5,59

0

1

2

3

4

5

6

7

Tiempo

(minutos)

StressTest OSSI - 3 Nodos

distkeygen portfolio eatmen forkit timeaster oSSIFStest

Figura 29 StressTest OpenSSI 3 Nodos

204

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 (minutos/segundos)

TiempoOM TDiferenciaOM Tiempo1 TDiferencia1

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 (minutos/segundos)

TiempoOSSI TDiferenciaOSSI Tiempo1 TDiferencia1

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 (minutos/segundos)

TiempoOM TDiferenciaOM TiempoOSSI TDiferenciaOSSI

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

205

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

100,00%

91,33%

39,83%

OpenMosix OpenSSI Sin Cluster

Figura 30 Benchmark Distkeygen

206

Benchmark Portfolio

98,05%

100,00%

50,05%

OpenMosix OpenSSI Sin Cluster

Figura 31 Benchmark Portfolio

Benchmark Eatmen

100,00%

81,87%

93,12%

OpenMosix OpenSSI Sin Cluster

Figura 32 Benchmark Eatmen

207

Benchamark Forkit

96,50%

100,00%

96,06%

OpenMosix OpenSSI Sin Cluster

Figura 33 Benchmark Forkit

Benchmark Timewaster

100,00%

87,22%

54,27%

OpenMosix OpenSSI Sin Cluster

Figura 34 Benchmark Timewaster

208

Benchamark oMFStest/oSSIMFStest

93,51%

100,00%

50,24%

OpenMosix OpenSSI Sin Cluster

Figura 35 Benchmark oM Stest

209

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,

210

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.

211

- 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;

212

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

213

214

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/>

215

[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

216

[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

217

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 ?

218

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/

Fichero W/R Función Valor de activación

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/

Fichero W/R Función Valor de activación

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

219

Cpus R número de procesadores del sistema variable

Tabla 17 El API de openMosix: /proc/hpc/decay/

Fichero W/R Función Valor de activación

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

220

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

221

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_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 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

222

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

223

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

224

# # 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 CONFIG_MTD_DOC2000=m

225

CONFIG_MTD_DOC2001=m 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

226

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

227

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

228

CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_COMPAT_IPFWADM=m CONFIG_IP_NF_NAT_NEEDED=y # # 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

229

# 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

230

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

231

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

232

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

233

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

234

# # 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

235

# # 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

236

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

237

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

238

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

239

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_TX_4W=y CONFIG_ATM_ENI_BURST_TX_2W=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

240

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

241

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

242

# 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

243

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

244

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

245

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 #

246

# 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 #

247

# 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

248

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

249

# 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_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m

250

CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m 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

251

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_CFB24=y CONFIG_FBCON_CFB32=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

252

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_AD1889=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_AD1980=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 #

253

# 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

254

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 #

255

# 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 #

256

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_SHA256=m CONFIG_CRYPTO_SHA512=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

257

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.

258

-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

259

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.