Conceptos Avanzados SSOO by L Manuel Cruz

Sistema Operativo Orientado a Objetos y Clustering Unidad VII Sistemas Operativos Distribuidos

UVM Campus Hispano L. Manuel Cruz G.

Sistemas Operativos Distribuidos Orientados a Objetos. En un Sistema Operativo Distribuido Orientado a Objetos nos encontramos con un conjunto de objetos localizados en una serie de computadores y que se comunican entre sí (Figura 1). Los computadores no tendrán necesariamente que compartir el mismo tipo de arquitectura.

Figura 1. Arquitectura hardware de un Sistema Operativo Distribuido Orientado a Objetos.

Para que la comunicación entre objetos sea posible, e incluso sea eficiente, necesitamos resolver una serie de cuestiones que se introducen por el hecho de que los objetos no comparten el mismo espacio de direcciones, y que en algún caso ya aparecían en los entornos de objetos distribuidos de los sistemas operativos tradicionales. Entre otras, habrá que plantearse:

• Localización de objetos: los objetos tendrán que poder ser identificados dentro del sistema por algún nombre (identificador), y una vez se conoce el nombre de un objeto que se quiere utilizar, habrá de haber alguna manera de localizarlo dentro del sistema. • Comunicación entre objetos: suponiendo que hemos localizado un objeto, habrá que estudiar la forma en que el objeto cliente comunica al objeto servidor el método que desea invocar y los parámetros (si los hay) que acompañan a dicha invocación. De la misma forma, habrá que estudiar cómo el objeto servidor devuelve el resultado al cliente. • Integridad: hay que asegurar que un objeto se encuentra siempre en un estado válido antes de que se permita realizar una invocación sobre él. Si una operación sobre un objeto no se completa satisfactoriamente, el sistema se habrá de asegurar de que se deshagan los cambios realizados sobre el mismo. • Movilidad de los objetos: por razones que veremos más tarde, es interesante que los objetos puedan moverse por los distintos computadores del sistema. El hecho de que los objetos puedan moverse de un sitio a otro complicará de manera importante la solución de todas las cuestiones anteriores.

En las siguientes secciones se desarrollan los aspectos relativos a la localización, comunicación y movilidad de los objetos.

1. Localización de objetos. Es evidente que todos los objetos de un SODOO tienen que poder ser identificados unívocamente, y que un identificador debe permitir localizar un objeto, se encuentre donde se encuentre. La localización de un objeto debe ser transparente, de manera que siempre que se realice una invocación, el sistema determine en que computador se encuentra el objeto, con el fin de comunicarle la petición. Como hemos dicho anteriormente, los identificadores habrán de ser únicos, no podrán cambiar durante la vida del objeto y una vez que se han usado, no podrán utilizarse de nuevo. Finalmente, sería deseable que el mecanismo de localización fuese lo suficientemente flexible como para permitir a los objetos migrar de un computador a otro. Existen distintas posibilidades de identificar objetos. A continuación se presentan las más significativas: • Codificar la localización del objeto en el identificador: únicamente habrá que interpretar el identificador para saber dónde se encuentra el objeto. Es un esquema cuya implementación es relativamente sencilla, pero que tiene un grave inconveniente: no va a permitir la movilidad de los objetos, objetivo que nos habíamos marcado como básico en el apartado anterior. • Utilizar un servidor de nombres distribuido: en el sistema existirá un conjunto de objetos servidores de nombres, que cooperarán para mantener información actualizada acerca de la localización de todos los objetos del sistema. Nos podemos encontrar principalmente dos variantes de este modelo: en la primera, cada servidor de nombres guarda información completa de la localización de todos los objetos, de tal manera que es capaz de servir cualquier petición. En la segunda variante, cada servidor únicamente guarda información parcial; si una petición no puede ser servida por un servidor, se delega en otro para realizarla. El problema de este esquema es que al menos un servidor debe ser advertido cuando se crea un objeto o cuando se mueve uno ya existente. Otro problema no menos grave es que la información mantenida por estos servidores puede no ser consistente, debido a que las operaciones de actualización no son instantáneas. • Punteros de localización: se utilizan para indicar la nueva posición de un objeto que se ha movido. Siempre que se mueve un objeto de un computador a otro, se deja un puntero de localización en el computador original. Para poder localizar un objeto que se ha movido, únicamente habrá que ir siguiendo los punteros que ha dejado como rastro durante su movimiento. Un problema de los punteros de localización es que introducen información adicional a mantener por el sistema.

Además, este esquema no soluciona completamente el problema de encontrar objetos que se han movido desde el momento en que algunos punteros pueden no estar accesibles debido a fallos en los computadores.

2. Comunicación entre objetos. La comunicación entre objetos no es un problema exclusivo de la multiplicidad de computadores del sistema, sino que aparecía ya cuando los objetos se encontraban espacios de direcciones diferentes. La cuestión a resolver en este punto es, básicamente, de que forma el objeto cliente envía la información de una invocación a un método de un objeto servidor, y cómo se envían los resultados. Existen dos modelos básicos: • Paso de mensaje: cuando un cliente realiza una invocación a un objeto, los parámetros de la invocación se empaquetan en un mensaje de petición. El mensaje es enviado entonces al objeto invocado, el cual acepta el mensaje, desempaqueta los parámetros y realiza la operación especificada. Cuando finaliza la operación, los resultados se empaquetan en un mensaje de respuesta, que se envía al cliente. En el caso de que el sistema operativo ofrezca algún mecanismo de seguridad, habrá que introducir en el mensaje alguna información acerca del objeto que realiza la invocación. • Invocación directa: en este caso hay un único hilo de ejecución que va migrando de operación en operación y de objeto en objeto. Distinguimos el hecho de que los objetos cliente y servidor residan en el mismo o diferentes computadores. En el caso de que ambos objetos residan en el mismo computador, los pasos a realizar son los siguientes: 1. Guardar el estado actual del objeto que realiza la invocación en su espacio de pila. 2. Añadir los parámetros a la pila. 3. Cargar el objeto invocado en el contexto del objeto que invoca y realizar una llamada a procedimiento para ejecutar el método deseado. 4. Cuando la operación ha terminado, se devuelven los resultados al cliente y éste se restaura al estado en el que se encontraba antes de la invocación. Cuando los objetos cliente y servidor no residen en el mismo computador, se habrán de realizar los 3 pasos siguientes: 1.1. Se crea un mensaje que contenga los parámetros de la invocación y se envía al computador en el que reside el objeto servidor. 1.2. El computador que recibe este mensaje crea un objeto auxiliar que se ejecuta de parte del objeto original. 1.3 Cuando la operación termina, se crea un mensaje con los resultados y se devuelve al computador en el que reside el objeto original. Después se elimina el objeto auxiliar. El esquema de invocación remota debería ser menos costoso que el paso de mensaje en el caso de que los objetos residiesen en el mismo computador, pero en el caso de invocación remota tiene el grave inconveniente de la necesidad de crear y destruir objetos auxiliares.

Sea cual sea el esquema empleado, hay que tener en cuenta que se pueden producir fallos en la invocación. Distinguimos fundamentalmente dos tipos de fallos: Fallo de existencia y Fallo transitorio. Un fallo de existencia se define como aquel que ocurre antes de que comience la invocación. El más común es el debido a la no existencia del objeto invocado. Este tipo de fallos es relativamente fácil de detectar y manejar. Un fallo transitorio es aquel que ocurre durante la realización de la invocación, es decir, se produce después de la aceptación de la invocación por parte del objeto servidor y antes de que los cambios producidos en este se hayan podido hacer permanentes. Este tipo de fallos puede ser debido a un fallo en el objeto cliente, en el objeto servidor o en la red que une al cliente y al servidor. El sistema debería proporcionar mecanismos de detección y recuperación ante fallos transitorios, tanto para objetos clientes como para servidores. Si el fallo de la invocación no es detectado por el objeto cliente, éste puede quedar esperando indefinidamente. Por tanto, se habrá de habilitar un mecanismo de detección de fallos de invocación que permita iniciarse un procedimiento de recuperación. Si el fallo no es detectado por el objeto servidor, muy probablemente se estarán bloqueando recursos del sistema de forma innecesaria. El mecanismo de detección y recuperación de fallos habrá de encargarse de eliminar este tipo de objetos del sistema para liberar los recursos bloqueados.

3. Movilidad de los objetos. La movilidad de los objetos es una facilidad que permite relocalizar un objeto dinámicamente desde el computador (o procesador) en el que se está “ejecutando” a otro computador (procesador). Lógicamente, la unidad de movilidad habrá de ser el objeto . Ante la posibilidad de mover objetos surgen dos problemas principales: • Política de migración: habrá de especificar qué objetos se pueden mover, cuándo se tiene que tomar la decisión de mover un objeto y cuál será el destino del mismo. • Cómo mover el objeto: una vez decidido qué objeto, en qué momento y cuál será el destino del objeto, habrá que decidir de qué manera se va a realizar su movimiento. En cualquier caso no habrá ningún problema con la localización del objeto. Si se utiliza alguno de los esquemas descritos para la identificación de objetos, no tiene ninguna importancia la verdadera posición de éstos. La localización de los recursos que estaba utilizando el objeto tampoco introducirá ningún problema, ya que todos los recursos del sistema serán también objetos. Surgen inmediatamente dos ventajas de la movilidad:

• Mejora del rendimiento: los objetos que residan en procesadores muy cargados se podrán mover a procesadores que están soportando menos carga. Cuando la carga de un procesador excede cierto límite, el sistema intenta encontrar un procesador menos cargado al que mover alguno de los objetos activos. Normalmente se empieza la búsqueda en los procesadores más cercanos, de manera que se minimice la distancia de los objetos movidos con los objetos con los que interactúan. Una vez encontrado un nuevo procesador, habrá que decidir qué objetos se van a mover. La decisión podrá estar basada en el tamaño del objeto, el tiempo estimado de vida, el número de veces que ha sido movido ya, etc. Los objetos a mover se suspenderán, se moverán y, finalmente, se reactivarán. • Mejora de la disponibilidad: los objetos que interactúan de manera importante podrán ser ubicados en el mismo computador, de forma que se reduzca el costo de las comunicaciones entre computadores. Es evidente que los mensajes que tienen su origen y destino en el mismo computador se despacharán mucho antes que aquellos que deben utilizar la red para llegar a su destino. Pero no todo va a ser ventajas. Destacamos a continuación algunos introducidos por la movilidad de los objetos:

los

problemas

• Mover un objeto puede ser más costoso que dejarlo donde estaba. De alguna manera hay que poder medir el costo de mover un objeto antes de decidirse a moverlo. Será una función de la parte del sistema que se encarga de decidir qué objetos se pueden mover en un momento dado. • Las invocaciones a un objeto que se está moviendo habrán de ser aceptadas por el sistema y enviadas al objeto cuando éste se encuentre de nuevo en un estado estable. El sistema, por tanto, habrá de garantizar la transparencia en el movimiento de los objetos. • No se puede tener un objeto moviéndose continuamente por el sistema. Un objeto que se esté moviendo en todo momento tendrá pocas posibilidades de atender a peticiones de otros objetos. Hay que garantizar un mínimo de estabilidad a los objetos. • Hay que resolver el problema de la movilidad en sistemas heterogéneos. En el caso de un sistema heterogéneo, la movilidad de un objeto no significa únicamente salvar el estado de un objeto en el computador de origen y restaurarlo en el de destino, sino que se necesitará realizar una traducción de los datos. Para evitar disponer de traductores entre todos los pares de arquitecturas posibles, se utiliza lo que se denomina Representación Externa de los Datos (eXternal Data Representation), que sirve como paso intermedio para realizar la traducción de una arquitectura a otra.

Distribución en Oviedo31. Evidentemente Oviedo3 es un Sistema Operativo Distribuido Orientado a Objetos. Hemos visto diferentes aspectos en los que se basa la distribución, en esta sección vamos a describir las características concretas de este software de sistema operativo. Empecemos con la arquitectura hardware. Oviedo3 corre sobre una arquitectura distribuida formada por una serie de máquinas que están unidas por una red de comunicaciones. Todas las máquinas son iguales, lo cual no quiere decir que el hardware subyacente tenga que serlo. 1. Localización de objetos. Todos los objetos de Oviedo3 tienen un identificador único. En el momento en que se cree un objeto, la máquina en la que residirá inicialmente el objeto habrá de encargarse de asignarle un identificador nuevo que utilizará durante toda su existencia. La existencia de múltiples máquinas potencialmente generadoras de identificadores obliga a que cada una de ellas sólo pueda generar identificadores en un rango determinado, de manera que se evite el problema de la duplicidad. Una vez que un identificador ha sido asignado a un objeto, no podrá utilizarse más, de tal forma que habremos de garantizar que el rango de identificadores válidos sea suficientemente grande. Aparece aquí la necesidad de disponer de un objeto en el sistema que se encargue de generar identificadores para los objetos que se vayan creando, de tal forma que se garantice la no duplicación de los mismos. El esquema de localización de Oviedo3 es el de múltiples servidores de nombres (identificadores, en nuestro caso), el cual va a permitir la movilidad de los objetos. Un servidor de nombres no va a ser otra cosa que un objeto especializado en mantener correspondencias entre identificadores de objetos y su localización dentro del sistema. Los servicios básicos proporcionados por un servidor de nombres serán: registrar un objeto nuevo, localizar un objeto, variar la localización de un objeto registrado, eliminar la información de localización de un objeto registrado (Figura 2)

Figura 2. Localización de un objeto en Oviedo3

Una vez asignado un identificador a un objeto, lo primero que hay que hacer es registrarlo en un servidor de nombres, de manera que quede constancia de su existencia y su localización 1

Oviedo3 es un Sistema Orientado a Objetos en desarrollo por un grupo de profesores y alumnos de la Universidad de Oviedo.

inicial. Siempre que un objeto que registraba su localización registrar la nueva localización. dado, habrá que eliminar de localización.

se mueva de una máquina a otra, el servidor de nombres antigua habrá de ser advertido del cambio, y habrá que Finalmente, si un objeto deja de existir en un momento los servidores de nombres toda información relativa a su

La utilización de identificadores únicos para los objetos del sistema va a permitir que se implementen políticas de nombrado de más alto nivel, de manera que, por ejemplo, los objetos puedan ser referenciados por más de un nombre. En última instancia, la implementación de dichas políticas habrá de realizar una traducción del nombre simbólico del objeto al identificador, el cual referenciará unívocamente al objeto. 2. Comunicación entre objetos. Los objetos de Oviedo3 se comunicarán por paso de mensaje. Una vez localizado el objeto invocado, se construirá un mensaje con toda la información necesaria para que se pueda realizar la invocación: en el caso de Oviedo3, será preciso aportar el conjunto de parámetros y la información de seguridad del objeto cliente, de forma que sólo se lleve a cabo la petición en el caso de disponerse de los permisos necesarios. Finalizada la operación, los resultados se empaquetarán en un nuevo mensaje que se enviará de vuelta al objeto cliente (Figura 3).

Figura 3. Invocación de un método remoto. Los objetos de Oviedo3 tendrán que ser capaces de recuperarse ante fallos de invocación, ya sean estos fallos de existencia o transitorios. El fallo de existencia se detectará habitualmente en la fase de localización del objeto, de manera que no se enviará el mensaje en caso de que se produzca. Los fallos transitorios introducen una complejidad mayor para su detección, pero es preciso habilitar mecanismos de detección y recuperación para que no se estén bloqueando recursos del sistema. 3. Movilidad. Los objetos de Oviedo3 tienen la posibilidad de ver variada su localización. La política de migración de objetos estará basada en: • Carga del procesador. • Interacción con objetos remotos.

Esto quiere decir que en el caso de que se detecte una alta carga en un procesador o bien un alto grado de interactuación entre objetos locales y remotos, se lanzará un proceso de decisión en el que se estudiará qué objetos son susceptibles de ser movidos y con qué destino. Una vez elegidos los objetos a mover y el destino de cada uno de ellos, lo primero que habrá que hacer será suspenderlos (ponerlos en un estado de inactividad). A continuación, se informará al servidor de nombres de que el objeto va a ser movido y se enviará toda la información necesaria acerca de su estado a la máquina elegida, donde, se devolverán a su estado anterior (Figura 4).

Figura 4. Acciones para el movimiento de un objeto. En Oviedo3 no tendremos problemas derivados de la heterogeneidad del sistema, ya que la máquina que se ejecuta en todos los nodos de la red ofrecerá una capa idéntica a todos ellos. Ganamos, pues, eficiencia a la hora de mover objetos, ya que no va a ser necesaria ninguna conversión de tipos de datos sean cuales sean el origen y el destino de aquellos. 4. Interfaz con CORBA. Oviedo3 no puede ser un Sistema Operativo aislado del resto del mundo. Para permitir la interoperabilidad entre Oviedo3 y los sistemas operativos tradicionales habrá de implementarse un interfaz que permita dialogar a los objetos de Oviedo3 con los objetos definidos según otros modelos de objetos. En este momento, el modelo que ofrece la arquitectura más susceptible de ser asumida desde Oviedo3 es el modelo CORBA (aunque no se puede descartar en ningún momento interoperabilidad con otros, como COM). Oviedo3 deberá ser capaz, por tanto, de ofrecer una comunicación transparente a sus objetos para comunicarse con objetos CORBA, de manera que aseguramos así la compatibilidad de este sistema operativo con todo aquel software que esté de acuerdo a las exigencias del estándar de OMG.

Para hacer posible la interoperabilidad será preciso disponer de un Adaptador de Objetos (OA) que permita al ORB soportar objetos de Oviedo3. Dado que los objetos de Oviedo3 comparten un único modelo de objetos, será preciso un único OA para hacer posible la interoperabilidad.

Figura 5. Interfaz de CORBA con Oviedo3.

Conclusiones. El diseño de un Sistema Operativo Distribuido Orientado a Objetos no es una tarea trivial. En lo que se refiere a la parte de la distribución de los objetos a lo largo y ancho del sistema, se han presentado varias alternativas, de las cuales se ha elegido una serie de ellas que van a caracterizar el comportamiento del Sistema Operativo integrado en Oviedo3. El paso de la fase de diseño a la de implementación obligará, seguramente, a replantearse alguno de los términos de la distribución, de manera que se mejoren la eficiencia y la estabilidad del sistema.

Clustering El término cluster se aplica a los conjuntos o conglomerados de computadoras construidos mediante la utilización de componentes de hardware comunes y que se comportan como si fuesen una única computadora. Hoy en día juegan un papel importante en la solución de problemas de las ciencias, las ingenierías y del comercio moderno. La tecnología de clusters ha evolucionado en apoyo de actividades que van desde aplicaciones de supercómputo y software de misiones críticas, servidores Web y comercio electrónico, hasta bases de datos de alto rendimiento, entre otros usos. El cómputo con clusters surge como resultado de la convergencia de varias tendencias actuales que incluyen la disponibilidad de microprocesadores económicos de alto rendimiento y redes de alta velocidad, el desarrollo de herramientas de software para cómputo distribuido de alto rendimiento, así como la creciente necesidad de potencia computacional para aplicaciones que la requieran. Simplemente, cluster es un grupo de múltiples computadoras mediante una red de alta velocidad, de tal forma que el conjunto es visto como una única computadora, más potente que los comunes de escritorio. Los clusters son usualmente empleados para mejorar el rendimiento y/o la disponibilidad por encima de la que es provista por un solo computador típicamente siendo más económico que computadores individuales de rapidez y disponibilidad comparables. De un cluster se espera que presente combinaciones de los siguientes servicios: 1. 2. 3. 4.

Alto rendimiento Alta disponibilidad Equilibrio de carga Escalabilidad

La construcción de las computadoras del cluster es más fácil y económica debido a su flexibilidad: pueden tener todas las mismas configuraciones de hardware y sistema operativo (cluster homogéneo), diferente rendimiento pero con arquitecturas y sistemas operativos similares (cluster semi-homogéneo), o tener diferente hardware y sistema operativo (cluster heterogéneo), lo que hace más fácil y económica su construcción. Para que un cluster funcione como tal, no basta solo con conectar entre sí las computadoras, sino que es necesario proveer un sistema de manejo del cluster, el cual se encargue de interactuar con el usuario y los procesos que corren en él para optimizar el funcionamiento.

Historia El origen del término y del uso de este tipo de tecnología es desconocido pero se puede considerar que comenzó a finales de los años 50 y principios de los años 60. La historia de los primeros grupos de computadoras es más o menos directamente ligada a la historia de principios de las redes, como una de las principales motivaciones para el desarrollo de una red para enlazar los recursos de computación, de hecho la creación de un cluster de computadoras. Las redes de conmutación de paquetes fueron conceptualmente inventados por la corporación RAND en 1962. Utilizando el concepto de una red de conmutación de paquetes, el proyecto ARPANET logró crear en 1969 lo que fue posiblemente la primera red de computadoras básico basadas en el cluster de computadoras por cuatro tipos de centros informáticos (cada una de las cuales fue algo similar a un "cluster" pero no un "comodity cluster" como hoy en día lo entendemos). El proyecto ARPANET creció y se convirtió en lo que es ahora Internet - que se puede considerar como "la madre de todos los clusters" (como la unión de casi todos los recursos de cómputo, incluidos los clusters, que pasarían a ser conectados). El desarrollo de la construcción de PC por los clientes y grupos de investigación procedió a la par con la de las redes y el sistema operativo Unix desde principios de la década de los años 70, como TCP/IP y el proyecto de la Xerox PARC. El primer producto comercial de tipo cluster fue ARCnet, desarrollada en 1977 por Datapoint pero no obtuvo un éxito comercial y los clusteres no consiguieron tener éxito hasta que en 1984 VAXcluster produjeran el sistema operativo VAX/VMS. Otros dos principios comerciales de clusteres notables fueron el Tandem Himalaya (alrededor 1994 de con productos de alta disponibilidad) y el IBM S/390 Parallel Sysplex (también alrededor de 1994, principalmente para el uso empresarial). La historia de los clusters de computadoras estaría incompleta sin señalar el papel fundamental desempeñado por el desarrollo del software de Parallel Virtual Machine (PVM). Este software de fuente abierta basado en comunicaciones TCP/IP permitió la creación de un superordenador virtual - un cluster HPC - realizada desde cualquiera de los sistemas conectados vía TCP/IP. De forma libre los clusters heterogéneos han constituido la cima de este modelo logrando aumentar rápidamente en FLOPS globalmente y superando con creces la disponibilidad incluso de los más caros superordenadores. PVM y el empleo de las PC y redes de bajo costo llevó, en 1993, a un proyecto de la NASA para construir supercomputadoras de clusters.

En 1995, la invención de la "beowulf" -un estilo de cluster- una granja de computación diseñado en base a un producto básico de la red con el objetivo específico de "ser un superordenador" capaz de realizar cálculos paralelos HPC.

Beneficios de la Tecnología Cluster Las aplicaciones paralelas escalables requieren: -

buen rendimiento, baja latencia, comunicaciones que dispongan de gran ancho de banda, redes escalables y acceso rápido a archivos.

Un cluster puede satisfacer estos requerimientos usando los recursos que tiene asociados a él. Los clusters ofrecen las siguientes características a un costo relativamente bajo: 

Alto Rendimiento.



Alta Disponibilidad.



Alta Eficiencia.



Escalabilidad.

La tecnología cluster permite a las organizaciones incrementar su capacidad de procesamiento usando tecnología estándar, tanto en componentes de hardware como de software que pueden adquirirse a un costo relativamente bajo.

Clasificación de los Clusters El término cluster tiene diferentes connotaciones para diferentes grupos de personas. Los tipos de clusters, establecidos en base al uso que se dé a los clusters y los servicios que ofrecen, determinan el significado del término para el grupo que lo utiliza. Los clusters pueden clasificarse con base en sus características. Se pueden tener clusters: 1. De alto rendimiento (HPC – High Performance Clusters), 2. Clusters de alta disponibilidad (HA – High Availability) o 3. Clusters de alta eficiencia (HT – High Throughput). Alto rendimiento: Son clusters en los cuales se ejecutan tareas que requieren de gran capacidad computacional, grandes cantidades de memoria, o ambos a la vez. El llevar a cabo estas tareas puede comprometer los recursos del cluster por largos periodos de tiempo.

Alta disponibilidad: Son clusters cuyo objetivo de diseño es el de proveer disponibilidad y confiabilidad. Estos clusters tratan de brindar la máxima disponibilidad de los servicios que ofrecen. La confiabilidad se provee mediante software que detecta fallos y permite recuperarse frente a los mismos, mientras que en hardware se evita tener un único punto de fallos. Alta eficiencia: Son clusters cuyo objetivo de diseño es el ejecutar la mayor cantidad de tareas en el menor tiempo posible. Existe independencia de datos entre las tareas individuales. El retardo entre los nodos del cluster no es considerado un gran problema. Los clusters pueden también clasificar como: 1. Clusters de IT Comerciales (Alta disponibilidad, Alta eficiencia) y 2. Clusters Científicos (Alto rendimiento). A pesar de las discrepancias a nivel de requerimientos de las aplicaciones, muchas de las características de las arquitecturas de hardware y software, que están por debajo de las aplicaciones en todos estos clusters, son las mismas. Más aún, un cluster de determinado tipo, puede también presentar características de los otros.

Componentes de un Cluster En general, un cluster necesita de varios componentes de software y hardware para poder funcionar. A saber: 

Nodos



Sistemas Operativos



Conexiones de Red



Middleware



Protocolos de Comunicación y servicios



Aplicaciones



Ambientes de Programación Paralela

De manera Particular:

Middleware El middleware es un software que generalmente actúa entre el sistema operativo y las aplicaciones con la finalidad de proveer a un cluster lo siguiente:



Una interfaz única de acceso al sistema, denominada SSI (Single System Image), la cual genera la sensación al usuario de que utiliza un único ordenador muy potente;



Herramientas para la optimización y mantenimiento del sistema: migración de procesos, checkpoint-restart (congelar uno o varios procesos, mudarlos de servidor y continuar su funcionamiento en el nuevo host), balanceo de carga, tolerancia a fallos, etc.;



Escalabilidad: debe poder detectar automáticamente nuevos servidores conectados al cluster para proceder a su utilización.

Existen diversos tipos de middleware, como por ejemplo: MOSIX, OpenMOSIX, Cóndor, OpenSSI, etc. El middleware recibe los trabajos entrantes al cluster y los redistribuye de manera que el proceso se ejecute más rápido y el sistema no sufra sobrecargas en un servidor. Esto se realiza mediante políticas definidas en el sistema (automáticamente o por un administrador) que le indican dónde y cómo debe distribuir los procesos, por un sistema de monitorización, el cual controla la carga de cada CPU y la cantidad de procesos en él. El middleware también debe poder migrar procesos entre servidores con distintas finalidades: 



Balancear la carga: si un servidor está muy cargado de procesos y otro está ocioso, pueden transferirse procesos a este último para liberar de carga al primero y optimizar el funcionamiento; Mantenimiento de servidores: si hay procesos corriendo en un servidor que necesita mantenimiento o una actualización, es posible migrar los procesos a otro servidor y proceder a desconectar del cluster al primero; Priorización de trabajos: en caso de tener varios procesos corriendo en el cluster, pero uno de ellos de mayor importancia que los demás, puede migrarse este proceso a los servidores que posean más o mejores recursos para acelerar su procesamiento.

Sistemas Cluster Implementados

Beowulf Fue construido por Donald Becker y Thomas Sterling en 1994. Fue construido con 16 computadores personales con procesadores Intel DX4 de 200 MHz, que estaban conectados a través de un switch Ethernet. El rendimiento teórico era de 3.2 GFlops.

Berkeley NOW El sistema NOW de Berkeley estuvo conformado por 105 estaciones de trabajo Sun Ultra 170, conectadas a través de una red Myrinet. Cada estación de trabajo contenía un microprocesador Ultra1 de 167 MHz, caché de nivel 2 de 512 KB, 128 MB de memoria, dos 15

discos de 2.3 GB, tarjetas de red Ethernet y Myrinet. En abril de 1997, NOW logró un rendimiento de 10 GFlops.

Google Durante el año 2003, el cluster Google llegó a estar conformado por más de 15.000 computadores personales. En promedio, una consulta en Google lee cientos de megabytes y consume algunos billones de ciclos del CPU.

Cluster PS2] En el año 2004, en la Universidad de Illinois en Urbana-Champaign, Estados Unidos, se exploró el uso de consolas Play Station 2 (PS2) en cómputo científico y visualización de alta resolución. Se construyó un cluster conformado por 70 PS2; utilizando Sony Linux Kit (basado en Linux Kondora y Linux Red Hat) y MPI.

Cluster X En la lista “TOP 500” de noviembre de 2004 fue considerado el séptimo sistema más rápido del mundo; sin embargo, para julio de 2005 ocupa la posición catorce. Cluster X fue construido en el Tecnológico de Virginia en el 2003; su instalación fue realizada por estudiantes del Tecnológico. Está constituido por 2200 procesadores Apple G5 de 2.3 GHz. Utiliza dos redes: Infiniband 4x para las comunicaciones entre procesos y Gigabit Ethernet para la administración. Cluster X posee 4 Terabytes de memoria RAM y 176 Terabytes de disco duro, su rendimiento es de 12.25 TFlops. Se lo conoce también como Terascale.

Thunder Thunder fue construido por el Laboratorio Nacional Lawrence Livermore de la Universidad de California. Está conformado por 4096 procesadores Intel Itanium2 Tiger4 de 1.4GHz. Utiliza una red basada en tecnología Quadrics. Su rendimiento es de 19.94 TFlops. Se ubicó en la segunda posición del “TOP 500” durante junio de 2004, luego en la quinta posición en noviembre de 2004 y en la lista de julio de 2005 se ubicó en la séptima posición.

ASCI Q ASCI Q fue construido en el año 2002 por el Laboratorio Nacional Los Álamos, Estados Unidos. Está constituido por 8192 procesadores AlphaServer SC45 de 1.25 GHz. Su rendimiento es de 13.88 TFlops. Se ubicó en la segunda posición del “TOP 500” durante junio y noviembre de 2003, luego en la tercera posición en junio de 2004, en la sexta posición en noviembre de 2004 y en la duodécima posición en julio de 2005.