UNIVERSIDAD DON .SOSCO FACULTAD DE INGENIERÍA ESCUELA DE ELECTRÓNICA DISEÑO DE UN CLUSTER DE ALTO RENDIMIENTO PARA LA UNIVERSIDAD DON SOSCO TRABAJO DE GRADUACIÓN PRESENTADO POR AGUILAR GARCIA MARCO TULIO RAFAEL ERNESTO ALFARO SANDOVAL PARA OPTAR AL GRADO DE Ingeniero en Electrónica Asesor: ING. JULIO ADALSERTO RIVERA PINEDA Marzo de 2007 San Salvador - El Salvador - Centro América UNIVERSIDAD DON SOSCO FACUL TAO DE INGENIERÍA ESCUELA DE ELECTRÓNICA AUTORIDADES: RECTOR ING. FEDERICO MIGUEL HUGUET RIVERA VICERRECTOR ACADÉMICO PBRO. VÍCTOR MANUEL BERMÚDEZ YANEZ, sdb SECRETARIO GENERAL LIC. MARIO RAFAEL OLMOS DECANO DE LA FACULTAD DE INGENIERÍA ING. ERNESTO GODOFREDO GIRÓN DIRECTOR DE ESCUELA DE ELECTRÓNICA ING. OSCAR GIOVANNI DURÁN VIZCARRA ASESOR DEL TRABAJO DE GRADUACIÓN ING. JULIO ADALBERTO RIVERA PINEDA JURADO EVALUADOR ING. JUAN CARLOS CRUZ DADA ING. ANGEL SORIANO ING. CARLOS BRAN UNIVERSIDAD DON BOSCO FACULTAD DE INGENIERÍA ESCUELA DE ELECTRÓNICA JURADO EVALUADOR DEL TRABAJO DE GRADUACIÓN ~__,-'-'i!l-:.., ~ua Carlos Cruz Dada JURADO ASESOR INDICE DE CONTENIDOS CAPITULO 1 CLUSTERS ........................................................................................... 3 1 NOCIONES GENERALES ................................................................................... 3 1.1 El concepto de cluster .................................................................................. 3 1.1.2 Características esenciales de un cluster ................................................... 3 1.1.3 Acoplamiento del cluster ........................................................................... 5 1.1.4 Control del Cluster .................................................................................... 7 Homogeneidad de un cluster ............................................................................. 7 1.6 Clasificaciones generales de los clusters segun el servicio ......................... 8 1.1. 7 Clusters HP: alto rendimiento ................................................................... 9 1.1.7.1 La misión ............................................................................................ 9 1.1.7.2 Problemas que solucionan .................................................................. 9 1.1.7.3 Técnicas que utilizan ......................................................................... 9 1.1.8 Clusters HA: alta disponibilidad .............................................................. 1 O 1.1.8.1 La misión .......................................................................................... 1 O 1.1.8.2 Problemas que solucionan ................................................................ 1 O 1.1.8.3 Técnicas que utilizan ........................................................................ 11 1.2 CLUSTERS HA ............................................................................................... 11 1.2.1 Introducción ............................................................................................ 11 1.2.2 El interés comercial.. .............................................................................. 12 1.2.3 Conceptos importantes ............................................................................ 12 1.2.3.1 Servicio RAS ..................................................................................... 13 1.2.3.2 Técnicas para proveer de disponibilidad .......................................... 14 1.3 CLUSTERS HP ............................................................................................... 19 1.3.1 Clusters HP: alto rendimiento ................................................................. 19 1.3.1.1 Migración y balanceo de carga en un cluster de alto rendimiento .. 20 1.3.2 PVM y MPI. .............................................................................................. 21 1.3.2.1 PVM .................................................................................................. 22 1.3.2.2 MPI. .................................................................................................. 22 1.3.3 Beowulf .................................................................................................. 23 1.3.4 openMosix .............................................................................................. 23 CAPITULO ............................................................................................................... 24 2.1 OPENMOSIX .................................................................................................. 24 2.1.1 Una muy breve introducción al clustering con openmosix ..................... 24 2.1.1.1 HPC, Fail-over y Load-balancing ...................................................... 25 2.1.1.2 Mainframes y supercomputadoras vs. clusters ................................ 26 2.1.2 Una aproximación histórica .................................................................... 26 2.1.2.1 Desarrollo histórico .......................................................................... 26 2.1.2.2 openMosix no es MOSIX ................................................................... 27 2.1.2.3 openMosix en acción: un ejemplo ..................................................... 27 2.2 CARACTERÍSTICAS DE OPENMOSIX ........................................................... 28 2.2.1 Pros de openMosix .................................................................................. 28 2.2.2 Contras de openMosix ............................................................................. 28 2.2.3 Subsistemas de openMosix ..................................................................... 29 2.2.4 El algoritmo de migración ....................................................................... 29 2.3 INSTALACIÓN DE UN CLUSTER OPENMOSIX ............................................ 32 1 2.3.1 Instalación del kernel de openMosix ....................................................... 33 2.3.2 Instalación de las herramientas de área de usuario .............................. .41 2.3.3 Configurando la topología del cluster .................................................... .43 2.3.4 Las herramientas de área de usuario ...................................................... 51 2.3.5 Optimizando el cluster ............................................................................ 62 CAPITULO 3 ............................................................................................................. 68 3.1 OpenMosix internamente ............................................................................... 68 3.1.1 Aspectos generales de openMosix .......................................................... 68 3.1.2 Detalles de openMosix ............................................................................ 69 3.1.3 Mecanismo de migración de procesos PPM ............................................ 71 3.1.4 Los algoritmos para la compartición adaptativa de recursos ................. 72 3.1.5 La implementación .................................................................................. 74 CAPITULO 4 ............................................................................................................. 75 4.1 IMPLEMENTACION DEL CLUSTER OPENMOSIX DE LA UNIVERSIDAD DON BOSC0 ..................................................................................................................... 75 4.1.1 DRISTIBUCION GNU/Linux de la Universidad Don Bosco, "UDB Cluster GNU/Linux" .............................................................................................................. 76 4.1.2 Nodo Monitor: ................................................................................................. 77 4.1.2.1 Nagios .......................................................................................................... 77 4.1.2.2 Cacti. ............................................................................................................ 80 4. Bonding : .............................................................................................................. 81 4.2 Prueba de desempeño del Cluster ..................................................................... 86 4.2.1 Recopilarcion de traps. 4.2.2 Prueba de estaor del motor; CONCLUSIONES ..................................................................................................... 93 2 CAPITULO 1 CLUSTERS. 1 NOCIONES GENERALES 1.1 El concepto de 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 podemos entenderlo como: Un conjunto de máquinas interconectadas y comunicadas trabajando por un servicio conjunto. 1.1.2 Características esenciales de un cluster En este punto explicaremos los requisitos que se deben cumplir para que un conjunto de computadoras interconectadas puedan ser consideradas un cluster. Para crear un cluster se necesitan al menos dos nodos. Debe de existir un medio de comunicación (network) donde los procesos puedan migrar para procesarse en diferentes estaciones paralelamente. Un único nodo no cumple este requerimiento. Las arquitecturas con varios procesadores no 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 tanto esta es una característica de un cluster: Un cluster consta de 2 o más nodos. Como los nodos necesitan estar interconectados entonces podemos decir: Los nodos de un cluster están conectados entre sí por al menos un canal de comunicación. Los cluster se pueden caracterizar por el middleware utilizado, pues es este el que finalmente dotará al conjunto de máquinas la capacidad para migrar procesos, balancear la carga en cada nodo, etc. 3 Los clusters necesitan middleware especializado. Las características del cluster son completamente dependientes del middleware, trataremos el modelo general de middleware que compone un cluster. Para empezar, parte de este middleware se debe dedicar a la comunicación entre los nodos. Existen varios tipos de middleware que pueden conformar un cluster: • middleware a nivel de aplicación. Este tipo de middleware 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 la manera más abstracta posible. Este tipo de software suele generar elementos de proceso como rutinas, procesos o tareas, que se ejecutan en cada nodo del cluster y se comunican entre sí a través de la red. • middleware a nivel de sistema. Este tipo de middleware se sitúa a nivel de sistema operativo, suele implementarse como parte del sistema operativo de cada nodo. 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, es por eso que decidimos utilizar middleware a nivel de sistema operativo para el presente trabajo de graduación. Cluster a Nivel de Sistema. so ENTORNO ADECUADO PARA EJECUTAR APLICACIONES : so so so :-~- nodo nodo nodo nodo -- ----1""-- -~ RED DE INTERCONEXION INTERCO NEXION DE NUCLEOS DEL SO Figura 1.1, Cluster a nivel de sistema. Cluster a nivel de aplicación. 4 APUCAClON GBIRAOA ESPECIAL BfRliDlECA llllt 681ERA tillSTER so so so NDOD ttoDD HOIID 1 1 1 Figura 1.2, Cluster a nivel de aplicación. 1.1.3 Acoplamiento del cluster Dependiendo del tipo de middleware utilizado el cluster presentara cierto grado de acoplamiento. Se entiende por acoplamiento del middleware a la integración que tengan todos los elementos de middleware 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 cuan crítico es el middleware y su capacidad de recuperación ante fallos. Es necesario 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 middleware es una medida subjetiva basada en la integración de un cluster a nivel general. Existen 3 tipos de acoplamiento de middleware: • middleware fuertemente acoplado. • Middleware medianamente acoplado. • Middleware débilmente acoplado. Middleware fuertemente acoplado. El middleware que entra en este grupo posee elementos que 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. Este caso es el que se considera como más acoplado, de hecho no está catalogado como cluster, sino como sistema operativo distribuido. como Plan 9 la versión Unix II de los laboratorios Bell, desarrollada por los mismos creadores del lenguaje C y el Primer Unix. 5 Otro ejemplo son los cluster SSI (de imagen única), 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, para el sistema distribuido centralizado y un mapeo de los recursos físicos a este sistema de nombres. Middleware medianamente acoplado. 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 tenemos a openMosix y Linux-HA, (OpenMosix será la tecnología a utilizar para el presente trabajo de graduación). Un cluster openMosix necesita que todos los kernels sean de la misma versión. Por otro lado no está tan acoplado como el caso anterior: no necesita un sistema de nombres común en todos los nodos, y su capacidad de dividir los procesos en una parte local y otra remota, consigue que por un lado se necesite el software del otro nodo, en cual se encuentra la parte del fichero que falta en el nodo local, y por otro este tipo de acoplamiento no necesita un SSI para realizar otras tareas. Middleware débilmente acoplado. Generalmente se basan en aplicaciones construidas por bibliotecas preparadas para aplicaciones distribuidas. Es el caso de por ejemplo PVM y MPI. Éstos por sí mismos no funcionan en modo alguno con las características que antes se han descrito, y hay que dotarles de una estructura superior que utilice las capacidades del cluster para que éste funcione. Ver referencia 1. Resumen de características generales de un Cluster. Las características básicas de un cluster de carácter general podrían resumirse en el siguiente esquema: l. Un cluster consta de dos o más nodos. 2. Los nodos deben estar interconectados por un canal de comunicación funcional. 3. Es necesario middleware especializado . . El middleware puede ser: 1. aplicación 2. sistema 4. Se define acoplamiento de un cluster como nivel de colaboración del middleware que une los elementos del cluster. De este modo se clasifican en: 6 1. middleware fuertemente acoplado. 2. Middleware medianamente acoplado. 3. Middleware débilmente acoplado. 4. 5. Los nodos con integran el cluster trabajan para cumplir una funcionalidad conjunta. Funcionalidad por la cual se caracteriza el sistema completo. 1.1.4 Control del Cluster Este parámetro de control hace referencia al modelo de administración que propone el cluster. Este modelo de administració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 central (master) desde el cual se puede configurar el comportamiento de todo el sistema. Esto hace más vulnerable al sistema respecto a la tolerancia a fallos, pero proporciona una ventaja debido a que se utiliza administración sencilla y minimista del cluster, de tal forma que se aprovechan al máximo los recursos, cono este tipo de gestión se hace posible utilizar estaciones de trabajo sin disco. • Control descentralizado: Es un modelo mas distribuido, como los Grids de los cuales ya han sido tratados en el presente documento, cada nodo debe administrarse y gestionarse individualmente. Se pueden administrar mediante aplicaciones de más alto nivel de manera centralizada, pero la mayoría de la administración que hace el nodo local es obtenida a través de los archivos de configuración de su propio nodo. Una ventaja es que presenta más tolerancia a fallos, pero requiere de una administración que demanda mayor cantidad de tiempo. 1.1. 5 Homogeneidad de un cluster La homogeneidad del cluster hace referencia a la homogeneidad de los equipos y recursos que conforman a éste. Los clusters heterogéneos son más difíciles de conseguir ya que se necesitan notaciones abstractas de transferencias e interfaces especiales entre los nodos para que éstas se entiendan, por otro lado los clusters homogéneos obtienen más beneficios de estos sistemas y pueden ser implementados directamente a nivel de sistema. • Clusters Homogéneos: formados por equipos de la misma arquitectura. Todos los nodos tienen una arquitectura y recursos similares, de manera que no existen muchas diferencias entre cada nodo. • Clusters heterogéneos: formados por nodos con distinciones que pueden estar en diversos tópicos: Tiempos de acceso distintos, Arquitecturas diferente, Sistema Operativo diferente, Rendimiento de los procesadores o recursos sobre una misma arquitectura distintos. El uso de arquitecturas distintas, o distintos sistemas operativos, trae como consecuencia la existencia de una biblioteca que sirva de interfaz. Por lo tanto este tipo de clusters serán implementados a nivel de aplicación y por lo tanto no podrán ser tan acoplados como los clusters homogéneos. 7 La imposibilidad de construir 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. 1.1.6 Clasificaciones generales de los clusters segun el servicio. A continuación presentaremos una clasificación de los clusters según el tipo de servicio que estos brinden. Alto rendimiento. Los clusters de alto rendimiento han sido creados para compartir, 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, ya sea que posean middleware a nivel de sistema o a nivel de aplicación. A nivel de sistema operativo tenemos a openMosix, mientras que a nivel de aplicación se encuentran otros como MPI, PVM, Beowulf. En cualquier caso, estos clusters hacen uso de la capacidad de procesamiento que pueden tener varias máquinas. Alta disponibilidad. Los clusters de alta disponibilidad cumplen una función muy distinta a la de un cluster de alto rendimiento. Estos 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. Pueden existir otras catalogaciones en lo que se refiere a tipos de clusters, en nuestro caso, solamente hemos considerado las dos que más clusters implementados engloban. 1.1. 7 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.1. 7.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. 8 1.1.7.2 Problemas que solucionan Generalmente estos problemas de computo 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.1. 7.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 acoplamiento, y que basan su funcionamiento en compartimento 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.1.8 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 9 é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.1.8.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 cliente externos. 1.1.8.2 Problemas que solucionan La mayoría de estos problema están ligados a la necesidad de dar serv1c10 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: • 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 y implementar mecanismos para hacer que esta obtenga la mayor disponibilidad posible. 1.1.8.3 Técnicas que utilizan Como se ha visto en el apartado anterior los servicios y el funcionamiento de los 10 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.2 CLUSTERS HA 1. 2 .1 Introducción Los clusters HA están diseñados especialmente para dar un serv1c10 de alta disponibilidad. Esto tiene muchas aplicaciones en el mundo actual donde existen gran cantidad de servicios informáticos que debe funcionar 24 horas, 7 días a la semana, 365 días al año. Estos clusteres son una alternativa real a otros sistemas usados tradicionalmente para estas tareas de hardware redundante que son mucho más caros. 1.2.2 El interés comercial Imagínese 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 11 cuestión. Existen distribuciones de linux comerciales que traen software especifico para brindar alta disponibilidad, tal como heartbeat, en Suse y Redhat. 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 interdepartamental 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). 1.2.3 Conceptos importantes Un buen cluster HA necesita proveer fiabilidad, disponibilidad y serv1c10 RAS (explicado más adelante). 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 (el enfoque principal de este trabajo es un cluster de alto rendimiento). 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 dolares 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. 12 Cuando un nodo cae hay que recuperar de los discos duros compartidos por los nodos la información 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 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. 1.2.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 . • Se:rviceability. 13 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. 1.2.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 recuperar lo 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. i.-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 14 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 la anterior pero se tienen N equipos para ofrecer un mismo servicio, con lo cual presenta más tolerancia a fallos. 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. SISTEMA :B r-ad A red B 15 Figura 3.3: 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 cuando 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 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. • 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 16 de que trabajos son más críticos. . 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 aumentamos la confiabilidad. Se pueden separar en dos tipos de acciones que realizan que pueden ser independientes o dependientes entre si: • 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 piggyhacking 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 17 checkpoint existente. Los puntos críticos de este apartado son: • 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. • recuperación mediante puntos de comprobación o puntos de restauración. . 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. 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: 18 . 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. Ver referencia 2. 1.3 CLUSTERS HP 1.3.1 Clusters HP: alto rendimiento En este apartado realizaremos distinciones entre los clusters 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. 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 del tiempo de respuesta. No existe ningún tipo de problema en concreto. Cualquier cluster que haga que el rendimiento del sistema aumente respecto al de uno de los nodos individuales puede ser considerado cluster de alto rendimiento. Un Cluster de alto rendimiento puede brindar menores tiempos de proceso a problemas tales como: • Cálculos matemáticos • Renderizaciones de gráficos • Compilación de programas • Compresión de datos • Descifrado de códigos • Rendimiento del sistema operativo, Las técnicas utilizadas dependen del nivel al que 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 19 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 acoplamiento, y que basan su funcionamiento en compartir recursos, 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 de imagen única (SSI). 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, esto sino se utiliza el parche experimental de migración de memoria del grupo MAASK de la India. 1.3.1.1 Migración y balanceo de carga e n un cluster de alto rendimiento Los clusters de alto rendimiento están dedicados a dar el mayor rendimiento computacional posible y existen multitud de formas de implementarlos. En este documento se estudian unas cuantas de estas implementaciones (PVM, MPI, Beowulf) y se ahondará en una de ellas openMosix debido a que será el middleware a utilizar para el cluster que se implementara. 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 de alto rendimiento 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 (La universidad Don Basca por ejemplo). La segunda opción es que el middleware que se encarga del alto rendimiento 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 20 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 habría grandes problemas. Otros sistemas operativos propietarios que no cumplen estos estándares no pueden disponer de estas ventajas. Una forma de conseguir alto rendimiento es migrando procesos, dividiendo las aplicaciones grandes en procesos y ejecutando cada proceso en un nodo distinto. Muchos de estos sistemas usan fundamentos estadísticos para la migración y balanceo de carga de los procesos, como por ejemplo openMosix. 1.3.2 PVM y MPI (Ver referencia 3 y 4) PVM y MPI utilizan el paso de mensajes. Los mensajes son pasados entre los procesos para conseguir que se ejecuten de manera colaborativa y de forma sincronizada. 1.3.2.1 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 aplicación. 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 pueden 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. 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. 1.3.2.2 MPI MPI es una especificación estándar para una librería de funciones de paso de 21 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. 1.3.3 Beowulf El proyecto Beowulf fue iniciado por Donald Becker en 1994 para la NASA conocido hacker del kernel Linux. 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. 22 1.3.4 openMosix OpenMosix es un software para conseguir clustering en GNU/Linux, migrando los procesos de forma dinámica. Consiste en unos algoritmos de compartimiento 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. Los fuentes de openMosix han sido desarrollados 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. 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 23 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. (Ver referencia 5) CAPITULO 2 (OPENMOSIX) 2.1 OPENMOSIX 2.1.1 Una muy breve introducción al clustering • con openmos1x. La mayor parte del tiempo su computadora permanece ociosa. Si el usuario ejecuta un programa de monitorización del sistema como xload o top, usted verá probablemente que la lectura de la carga de su procesador permanece generalmente por debajo del 10%. Si tiene al alcance varias computadoras los resultados serán los mismos ya que no podrás interactuar con más de una de ellas al mismo tiempo. Desafortunadamente cuando realmente necesite potencia computacional (como por ejemplo para comprimir un fichero, o para una gran compilación) no podrá disponer de la potencia conjunta que te proporcionarían todas ellas como un todo. La idea que se esconde en el trasfondo del clustering es precisamente poder contar con todos los recursos que puedan brindarle el conjunto de computadoras de que pueda disponer para poder aprovechar aquellos que permanecen sin usar, básicamente en otras computadoras. La unidad básica de un cluster es una computadora simple, también denominada nodo. Los clusters pueden crecer en tamaño (o mejor dicho, pueden escalar) añadiendo más máquinas. Un cluster como un todo puede ser más potente que la más veloz de las máquinas con las que cuenta, factor que estará ligado irremediablemente a la velocidad de conexión con la que hemos construido las comunicaciones entre nodos. Además, el sistema operativo del cluster puede hacer un mejor uso del hardware disponible en respuesta al cambio de condiciones. Esto produce un reto a un cluster heterogéneo (compuesto por máquinas de diferente arquitectura) tal como se presentará al lector gradualmente. 2 .1.1.1 HPC, Fail-over y Load-balancing Básicamente existen tres tipos de clusters: Fail-over, Load-halancing y HIGH Performance Computing. 24 Los clusters Fail-over consisten en dos o más computadoras conectadas en red con una conexión heartbeat separada entre ellas. La conexión heartbeat entre las computadoras es usualmente utilizada para monitorear cuál de todos los servicios está en uso, así como la sustitución de una máquina por otra cuando uno de sus servicios haya caído. El concepto en los Load-balancing se basa en que cuando haya una petición entrante al servidor web, el cluster verifica cuál de las máquinas disponibles posee mayores recursos libres, para luego asignarle el trabajo pertinente. Actualmente un cluster load-balancing es también fail-over con el extra del balanceo de la carga y a menudo con mayor número de nodos. La última variación en el clustering son los High Perlormance Computing. Estas máquinas han estado configuradas especialmente para centros de datos que requieren una potencia de computación extrema. Los clusters Beowulf han sido diseñados específicamente para estas tareas de tipo masivo, teniendo en contrapartida otras limitaciones que no lo hacen tan accesible para el usuario como un openMosix. 2.1.1.2 Mainframes y supercomputadoras vs. clusters Tradicionalmente los mainframes y las supercomputadoras han estado construidas solamente por unos fabricantes muy concretos y para un colectivo elitista que necesitaba gran potencia de cálculo, como pueden ser empresas o universidades. Pero muchos colectivos no pueden afrontar el costo económico que supone adquirir una máquina de estas características, y aquí es donde toma la máxima importancia la idea de poder disponer de esa potencia de cálculo, pero a un precio muy inferior. El concepto de cluster nació cuando los pioneros de la supercomputación intentaban difundir diferentes procesos entre varias computadoras, para luego poder recoger los resultados que dichos procesos debían producir. Con un hardware más barato y fácil de conseguir se pudo perfilar que podrían conseguirse resultados muy parecidos a los obtenidos con aquellas máquinas mucho más costosas, como se ha venido probando desde entonces. 2.1.1.3 Modelos de clusters NUMA, PVM y MPI Hay diferentes formas de hacer procesamiento paralelo, entre las más conocidas y usadas podemos destacar NUMA, PVM y MPI. Las máquinas de tipo NUMA (Non-Uniform Memory Access) tienen acceso compartido a la memoria donde pueden ejecutar su código de programa. En el kernel de Linux hay ya implementado NUMA, que hace variar el número de accesos a las diferentes regiones de memoria. PVM / MPI son herramientas que han estado ampliamente utilizadas y son muy conocidas por la gente que entiende de supercomputación basada en GNU/Linux. 25 MPI es el estándar abierto de bibliotecas de paso de mensajes. MPICH es una de las implementaciones más usadas de MPI, tras MPICH se puede encontrar LAM, otra implementación basada en MPI también con bibliotecas de código abierto. PVM (Parallel Virtual Machine) es un primo de MPI que también es ampliamente usado para funcionar en entornos Beowulf. PVM habita en el espacio de usuario y tiene la ventaja que no hacen falta modificaciones en el kernel de Linux, básicamente cada usuario con derechos suficientes puede ejecutar PVM. 2.1.2 Una aproximación histórica 2.1.2.1 Desarrollo histórico Inicialmente Mosix empezó siendo una aplicación para BSD/OS 3.0. La plataforma GNU/Linux para el desarrollo de posteriores versiones fue elegida en la séptima generación, en 1999. 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. 2.1.2.2 openMosix no es MOSIX 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. o rg, respetando todo el trabajo llevado a cabo por el Prof. Barak y su equipo. Moshe Bar estuvo ligado al proyecto Mosix, en la Universidad Hebrea de Jerusalem, durante bastantes años. Era el co-administrador del proyecto y el principal administrador de los asuntos comerciales de Mosix company. Tras algunas diferencias de opinión sobre el futuro comercial de Mosix, Moshe Bar empezó un nuevo proyecto de clustering alzando la empresa Qlusters, !ne. 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 estardard de Linux para plataformas IA32. Actualmente se está trabajando para portarlo a IA64. El algoritmo interno de balanceo de carga migra, transparentemente para el usuario, los 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. 26 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. Su estabilidad 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. El punto fuerte de este proyecto es que intenta crear un estándar en el entorno del clustering para todo tipo de aplicaciones HPC. openMosix tiene una página web (www.openmosix.org) con un árbol CVS y un par de listas de correo para los desarrolladores y para los usuarios. 2.1.2.3 openMosix en acción: un ejemplo Los clusters openMosix pueden adoptar varias formas. Para demostrarlo intente imaginar que comparte el piso de estudiante con un tipo que estudia ciencias de la computación. Imagine también que tiene las computadoras conectadas en red para formar un cluster openMosix. Asume también que se encuentra convirtiendo ficheros de música desde sus CDs de audio a Ogg Vorbis para su uso privado, cosa que resulta ser legal en su país. Su compañero de habitación se encuentra trabajando en un proyecto de C++, pero en este justo momento esta ocupado en otras tareas, y evidentemente su computadora está a la espera de ser intervenida de nuevo. Resulta que cuando inicia un programa de compresión, como puede ser bladeenc para convertir un preludio de Bach desde el fichero . wav al .ogg, las rutinas de openMosix en tu máquina comparan la carga de procesos en su máquina y en la de su compañero y deciden que es mejor migrar las tareas de compresión ya que el otro nodo es más potente, a la vez que en ese momento permanece ociosa ya que no se encuentra frente a ella. Así pues lo que normalmente en un pentium233 tardaría varios minutos se da cuenta que ha terminado en pocos segundos. Lo que ha ocurrido es que gran parte de la tarea ha sido ejecutada en el AMD AthlonXP de su compañero, de forma transparente a usted. Minutos después se encuentra escribiendo y su compañero de habitación vuelve a su computadora. Éste reanuda sus pruebas de compilación utilizando pmake, una versión del ma ke optimizada para arquitecturas paralelas. Se da cuenta que openMosix está migrando hacia su máquina algunos subprocesos con el fin de equilibrar la carga. Esta configuración se llama single-pool: todas las computadoras están dispuestas como un único cluster. La ventaja o desventaja de esta disposición es que su computadora es parte del pool: sus procesos serán ejecutados, al menos en parte, en otras computadoras, pudiendo atentar contra su privacidad de datos. 27 Evidentemente las tareas de los demás también podrán ser ejecutadas en la suya. 2.2 CARACTERÍSTICAS DE OPENMOSIX 2.2.1 Pros de openMosix • No se requieren paquetes extra . No son necesarias modificaciones en el código de las aplicaciones. 2.2.2 Contras de openMosix • Es dependiente del kernel • No migra todos los procesos siempre, tiene limitaciones de funcionamiento • Problemas con memoria compartida (si no se usa el parche migshm) Además los procesos con múltiples threads no ganan demasiada eficiencia. Tampoco se obtendrá mucha mejora cuando se ejecute un solo proceso, como por ejemplo el navegador. 2.2.3 Subsistemas de openMosix Actualmente podemos dividir los parches de openMosix dentro del kernel en dos grandes subsistemas, veámoslos. 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 el raíz. openMosix se encargará de establecer la comunicación entre estos 2 procesos. Memory ushering Este subsistema se encarga de migrar las tareas que superan la memoria 28 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. 2.2.4 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 migrarse cualquier 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 PDPl 1/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. Podríamos pensar que el comportamiento de un cluster openMosix es como una máquina NUMA, aunque estos clusters son mucho más baratos. 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 logado 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 retomo 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 29 sistemas. 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. iCuá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 (a menos que se use el parche migshm) Cumpliendo todas estas condiciones el proceso puede migrar y ejecutarse migrado. No obstante, como podemos sospechar, openMosix no adivina nada. openMosix no sabe a 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 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. La comunicación entre las dos áreas Un aspecto importante en el que podemos tener interés es en cómo se realiza la comunicación entre el área de usuario y el área de kernel. 30 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 el operativa necesaria de la á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. 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 nos 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 31 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. 2.3 INSTALACIÓN DE UN CLUSTER OPENMOSIX La construcción de un cluster openMosix se compone de varios pasos. 1. el primero es compilar e instalar un kernel con soporte openMosix y aplicarle el parche migshm si se quiere migrar procesos que trabajen con memoria compartida; 2. el segundo, compilar e instalar las herramientas de área de usuario. 3. El tercer paso es configurar los demonios del sistema para que cada máquina del cluster siga el comportamiento que esperamos, 4. y el cuarto paso es crear el fichero del mapa del cluster. Este cuarto paso sólo es necesario si no usamos la herramienta de autodetección de nodos. 2.3.1 Instalación del kernel de openMosix El primer paso para instalar el kernel de openMosix es descargar el tarball. No es conveniente usar la versión del kernel del CVS, ya que suele no ser muy estable. Puede descargarse el tarball del parche del kernel de openMosix de la dirección en SourceForge. http :// openmosix.sourceforge .net/ Una vez descargado el parche del kernel openMosix habrá que descomprimirlo: gunzip openMosix-2.4.26-2.gz Descargar el parche migshm Migshm es un parche DSM para openmosix. DSM quiere decir Distrubución de memoria compartida. Este habilita la migración de procesos que usan memoria compartida en openmosix, como ejemplo apache. (Ver referencia 6) Actualmente, una de las principales limitaciones de openMosix es que las aplicaciones que usan memoria compartida y multihilo no son migrables en el cluster. Migshm cubre esta necesidad. Migshm habilita la migración de procesos usando memoria compartida SYSV a través de las llamadas al sistema shmget(), shmat(), y shmctl(). Hilos creados 32 utilizando clone() pueden ser migrados también por migshm. http ://opensource. codito. com/migshm/ Descomprimimos migshm: gunzip migshm-2.4.26-2.patch.gz Después de descargar el parche openMosix, habrá que descargar el kernel de Linux. Un posible sitio para descargarlo es http://www.kernel.org. Hay que descargar el kernel correspondiente a la versión del parche que hemos descargado. Esto quiere decir que un parche 2.4.X-Y valdrá para el kernel 2.4.X. Por ejemplo, el parche 2.4.26-2 sólo puede ser aplicado sobre el kernel 2.4.26. Una vez descargado el kernel de Linux lo descomprimimos: tar -zxf linux-2.4.26.tar.gz Movemos el directorio donde hemos descomprimido el kernel a linux-openmosix: mv linux-2.4.26 linux-openmosix y aplicamos el parche de openMosix: patch -p0 openMosix-2.4.26-2 patch -p0 migshm-2.4.26-2.patch Entramos en el directorio del kernel de Linux: cd linux-openmosix Y lanzamos el menú de configuración del kernel: make menuconfig para la configuración a través de menús con ncurses. Para obtener mayor información relacionada al kernel Linux ver referencia: 7 33 Opciones del kernel de openMosix ( con migshm) El siguiente paso para configurar el kernel de openMosix es entrar en la opción openMosix -la primera opción del menú principal de la pantalla de configuración del kernel-. Allí encontraremos un menú con todas las opciones propias de openMosix. Estas opciones son: openMosix process migration support: Esta opción permite activar el soporte a la migración de procesos en openMosix. Esto incluye tanto la migración forzada por el administrador como la migración transparente automática de procesos, el algoritmo de equilibrado de carga y el Memory Ushering. Si no activamos esta opción, no tenemos openMosix. Support clusters with a complex network topology: Las máquinas que pertenecen al cluster openMosix pueden pertenecer a la misma red (segmento), estando conectadas por un hub o por un switch. En este caso, en openMosix consideramos que la topología de la red es simple, lo que permite realizar algunas modificaciones en los algoritmos de calculo de la función de coste del algoritmo de equilibrado de carga que hacen muchísimo más eficiente su cálculo. También mejora la eficiencia del algoritmo de colecta automática de información del cluster. Si tenemos todas las máquinas del cluster conectadas a través de hubs o switchs -es decir, que un paquete openMosix nunca necesitará pasar por un router- podemos aumentar sensiblemente el rendimiento de nuestro cluster desactivando esta opción. Maximum network-topology complexity to support (2-10): Si activamos la opción anterior, aparecerá esta opción. En esta opción se nos pregunta cuantos niveles de complejidad hay entre las dos máquinas más lejanas del cluster, entendiendo por niveles de complejidad el número de routers intermedios más uno. Si ponemos un número más alto de la cuenta, no tendremos todo el rendimiento que podríamos tener en nuestro cluster. Si ponemos un número más bajo de la cuenta, no podrán verse entre sí las máquinas que tengan más routers intermedios que los indicados en este parámetro menos uno. Stricter security on openMosix ports: Esta opción permite un chequeo adicional sobre los paquetes recibidos en el puerto de openMosix, y unas comprobaciones adicionales del remitente. Aunque esto suponga una pequeña pérdida de rendimiento, permite evitar que mediante el envío de paquetes quebrantados se pueda colgar un nodo del cluster. De hecho, hasta hace poco tiempo se podía colgar un nodo del antiguo proyecto Mosix sólo haciéndole un escaneo de puertos UDP. Salvo que tengamos mucha seguridad en lo que estamos haciendo, debemos activar esta opción de compilación. 34 Level of process-identity disclosure (0-3): Este parámetro indica la información que va a tener el nodo de ejecución real de la tarea sobre el proceso remoto que está ejecutando. Aquí debemos destacar que esta información siempre estará disponible en el nodo raíz -en el nodo en el que se originó la tarea-; limitamos la información sólo en el nodo en el que se ejecuta la tarea si este es distinto del nodo raíz. Este es un parámetro de compromiso: valores más bajos aseguran mayor privacidad, a cambio de complicar la administración. Valores más altos hacen más cómoda la administración del cluster y su uso, pero en algunos escenarios pueden violar la política de privacidad del departamento o de la empresa. Un O significa que el nodo remoto que ejecuta el proceso migrado no tiene ninguna información relativa al proceso migrado que se ejecuta en dicho nodo. Este modo paranoico hace la administración del cluster realmente complicada, y no hay ninguna razón objetiva para recomendarlo. Un 1 significa que el nodo remoto que ejecuta el proceso migrado tiene como única información el PID del proceso. Este es un modo paranoico, pero que permite al menos al administrador del cluster saber con un poco de más comodidad qué es lo que está pasando en caso de problemas. Es un nodo útil cuando usamos máquinas no dedicadas que estén en los despachos de los usuarios del cluster, y no queremos protestas entre los usuarios del cluster sobre quién está haciendo más uso del cluster. Un 2 significa que el nodo remoto que ejecuta el proceso migrado conoce PID , el usuario propietario y el grupo propietario del proceso. Este es un modo útil en clusters dedicados y no dedicados cuando sabemos que no va a haber discusiones entre los usuarios porque alguien use los recursos del cluster más de la cuenta. Es una buena opción si tenemos nodos no dedicados en despachos de usuarios donde cualquier usuario no tiene cuentas en las máquinas de los otros, para asegurar una cantidad razonable de privacidad. Un 3 significa que en el nodo remoto que ejecuta el proceso migrado se tiene exactamente la misma información de los procesos migrados que de los procesos locales. Esto significa que para la información de los procesos el sistema se comporta realmente como un sistema SSI. Este modo es recomendable en los escenarios donde todos los usuarios tienen cuentas en todas las máquinas del cluster, con lo que mantener la privacidad del espacio de procesos ya es de por si imposible, y bloquear esta información solo complica el uso y la administración del cluster. Este es el escenario más habitual de uso de un cluster, por lo que en caso 35 de dudas es mejor que usemos este nivel de privacidad. De cualquier forma, cualquier proceso puede variar su nivel particular de privacidad grabando desde el propio proceso su nuevo nivel de privacidad en el archivo /proc/self/disclosure. Poll/Select exceptions on pipes: Esta opción es interesante, aunque separa a openMosix de una semántica SSI pura. 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. Activando esta opción nos separamos de 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. Activamos el lanzamiento de la excepción de lectura del pipe con la llamada al kernel ioctl(pipefd, TCSBRK, 1), y activamos la señal de que el último lector ha cerrado el pipe con ioctl(pipefd, TCSBRK, 2). Por último, podemos tener una estimación aproximada de la cantidad de información que los procesos lectores han pedido leer de un pipe en particular con la llamada al sistema ioctl(pipefd, TIOCGWJNSZ, O). Esta llamada no da un valor exacto, y puede equivocarse -pensemos que nos da apenas una estimación a la baja-. Por lo tanto, en caso de equivocación de la llamada, suele ser porque el proceso lector lee más de lo estimado. Aunque activemos esta opción, por defecto, el envío de estas excepciones está desactivado para todos los procesos, y cada proceso que quiera usar estas excepciones debe activar su posibilidad con ioctl. En principio no activamos esta opción, salvo que queramos usarla para nuestros propios programas. Disable OOM Killer (NEW): Las últimas versiones del kernel de Linux incluyen una característica bastante discutida: el OOM Killer. Esta opción nos permite inhabilitar el OOM Killer, y evitar los problemas que este suele causar. En caso de duda, es recomendable habilitar esta opción -es decir, inhabilitar el OOM Killer-. Enable extension localtime: Esta caracteristica permite ejecutar time(2 ) localmente, usando time() desde el nodo de ejecución, este necesita tener una buena sincronización en los nodos del cluster. Shared memory migration support: (parche migshm) Soporte para migración de tareas con memoria compartida 36 flush() support for consistency Aplicaciones que no necesitan la sincronización y son satisfechos así por consistencia débil, pueden mantener esta política remotamente. El programador puede mover explícitamente los cambios a la región compartida a cualquier propietario remoto de la región compartida, en cualquier momento durante la ejecución de programa, llamando la llamada del sistema del "flush()". Así, aun si las aplicaciones no utilizan semáforos, ellos puede alcanzar consistencia usando la llamada del flush(). Kernel Debug Messages Mensajes de depuración del kernel con migshm Por último, no debemos olvidar que todos los nodos del cluster deben tener el mismo tamaño máximo de memoria, o si no las tareas no migrarán. Para ello, entramos en la opción Processor type and features, y en la opción High Memory Support asignamos el mismo valor a todos los nodos del cluster. Después de esto, nuestro kernel estará listo para poder usar openMosix. Ahora seleccionamos las opciones adicionales del kernel que coincidan con nuestro hardware y el uso que le queramos dar a nuestro Linux, grabamos la configuración y hacemos: Proceso de compilación del kernel: make dep lo que calcula las dependencias entre partes del kernel -qué se compila y qué no se compila, entre otras cosas-. Después limpiamos el kernel de restos de compilaciones anteriores, que pudieran tener una configuración distinta: make clean Compilamos el kernel: make bzlmage Compilamos los módulos: make modules Instalamos los módulos: make modules install 37 y ahora copiamos el nuevo kernel en el directorio /boot: cp arch/i386/boot/bzimage /boot/kernelopenMosix por último, creamos una entrada en lilo.confpara el nuevo kernel; por ejemplo: image=/boot/kernelopenMosix label=om root=/dev/hdal initrd=/boot/initrd.img append=" devfs=mount" read-only donde /dev/hdal es el dispositivo de bloques donde encontramos el directorio raíz de Linux; en nuestro sistema puede cambiar. Compilamos la tabla del LILO con el comando: lilo y listo. Ya tenemos un kernel listo para poder usarlo en un nodo openMosix. Si se usa Grub en lugar de lilo, entonces se procede a editar el archivo /boot/grub/grub.conf o /boot/grub/menu.lst y se agregan las siguientes lineas: title GNU/Linux kernel /boot/kernel-openmosix donde kernel-openmosix es el nombre de la imagen del kernel creada anteriormente. OpenMosix en las distribuciones GNU/Linux mas populares: Debian GNU/Linux. Debian GNU/Linux inició su andadura de la mano de Ian Murdock en 1993. Debian es un proyecto totalmente no-comercial; posiblemente el más puro de los ideales que iniciaron el movimiento del software libre. Cientos de desarrolladores voluntarios de alrededor del mundo contribuyen al proyecto, que es bien dirigido y estricto, asegurando la calidad de una distribución conocida como Debian.En cualquier momento del proceso de desarrollo existen tres ramas en el directorio principal: "estable", "en pruebas" e "inestable" (también conocida como "sid") . Cuando aparece una nueva versión de un paquete, se sitúa en la rama inestable para las primeras pruebas, si las pasa, el paquete se mueve a la rama de pruebas, donde se realiza un riguroso proceso de pruebas que dura muchos meses. Esta 38 rama solo es declarada estable tras una muy intensa fase de pruebas. Como resultado de esto, la distribución es posiblemente la más estable y confiable, aunque no la más actualizada. Mientras que la rama estable es perfecta para servidores con funciones críticas, muchos usuarios prefieren usar las ramas de pruebas o inestable, más actualizadas, en sus ordenadores personales. Debían es también famosa por su reputación de ser dificil de instalar, a menos que el usuario tenga un profundo conocimiento del hardware de la computadora. Compensando este fallo está "apt-get" un instalador de paquetes Debian. Muchos usuarios de Debian hacen bromas sobre que su instalador es tan malo por que solo lo han de usar una vez, tan pronto como Debian está en funcionamiento, todas las actualizaciones, de cualquier tipo pueden realizarse mediante la herramienta apt­ get. Debian GNU/Linux posee otra ventaja adicional haciendo referencia a openmosix, en su ultima versión 3.1 (sarge) facilmente puede estar funcionando con un kernel Linux 2.4 o con un kernel Linux 2.6, lo cual brinda una gran versatilidad, una vez que openmosix 2.6 sea estable, la migración desde 2.4 es sencilla. Debian trabaja con runlevels al estilo System-V, y posee un runlevel especifico solo para la inicialización del sistema, cada tarea que se encuentre en dicho runlevel posee una prioridad, de tal forma que el usuario puede decidir que servicios se ejecutaran primero, servicios tales como udev, devfs, etc ... o bien el usuario los puede quitar facilmente. El sistema udev solo funciona con kernels 2.6, por lo tanto es necesario eliminarlo del runlevel de iniciación, para asi evitar conflictos con openmosix 2.4, que no utiliza el sistema udev para los dispositivos . Por lo tanto podemos decir que Debian GNU/Linux es un candidato excelente para ejectutar openMosix. Gentoo 2005.1 Gentoo Linux fué creada por Daniel Robbins, un conocido desarrollador de Stampede Linux y FreeBSD. Fue el contacto del autor con FreeBSD y su función de autobuild llamada "ports" lo que le inspiró a incorporar los "ports" en Gentoo bajo el nombre de "portage". Un informe detallado de los principios de Gen too se puede encontrar en esta trilogía llamada Creando la distribución. La primera versión estable de Gentoo fue anunciada en Marzo del 2002. Gentoo Linux es una distribución basada en código fuente. Mientras que los sistemas de instalación proveen de varios niveles de paquetes pre-compilados, para obtener un sistema Linux básico funcionando, el objetivo de Gentoo es compilar todos los paquetes de código en la máquina del usuario. La principal ventaja de esto es que todo el software se encuentra altamente optimizado para la arquitectura de tu computadora. También, actualizar el software instalado a una nueva versión es tan fácil como teclear un comando, y los paquetes, mantenidos en un repositorio central, se 39 mantienen bastante actualizados. Gentoo es un universo de opciones, y configuraciones, aunque requiere un poco mas de conocimiento por parte del administrador, comparándola con las distribuciones mas conocidas. Gentoo posee un esquema de runlevels distinto al de Debian, Fedora, Suse. Gentoo al igual que Debian permite la potencia al usuario de decidir que servicios se ejecutan en el arranque del sistema, al momento del boot, de tal forma que Gentoo 2005.1 con kernel 2.6 por defecto, facilmente es configurable a un kernel 2.4 sin afectar la integridad del sistema, es decir es fácil evitar que udev se ejecute al inicio y otros servicios propios de la rama 2.6 del kernel Linux. Por lo tanto concluimos que Gentoo es una buena distribución para la ejecución de OpenMosix. Fedora Core 4 A diferencia de Debian y Gentoo, con runlevels altalmente configurables, que brindan al usuario el control sobre ellos, Fedora es muy diferente. Pues no utiliza un runlevel para los scripts de iniciación, a diferencia esta distribución utiliza un complejo script bash, /etc/sysinit, no diseñado para ser configurado por el usuario, por lo tanto es muy complejo deshacerse del udev. Fedora ademas posee gcc 4.0 en Fedora 4, el cual no puede compilar kernels 2.4, aunque se pudiesen compilar en otra maquina con un gcc 3.5 que si compila kernels 2.4. El problema radica en que los kernels 2.6 utilizan otro sistema para la carga de modulas del kernel y quitarlos acarrea un grave problema de dependencias. Ocurre otro grave problema de dependencias si se desinstala gcc 4.0. Por lo tanto Fedora 4 no es una distribución adecuada para trabajar con openmosix 2.4. Suse 9.3 Suse 9.3 al igual que Fedora vienen siendo una distribución bastante elaborada, y poco versátil, Suse 9.3 no trae soporte por defecto, para compilar kernels de la rama 2.4 de Linux, existen símbolos (instrucciones) no soportados,