Subsecciones

4.1 CLUSTERS. NOCIONES GENERALES

4.1.1 ¿Qué se entiende por 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.

Muy vagamente un cluster podemos entenderlo como:



Un conjunto de máquinas unidas por una red de comunicación trabajando por un objetivo conjunto. Según el tipo puede ser dar alta disponibilidad, alto rendimiento etc...



Por supuesto esta definición no es estricta, de hecho uno de los problemas que tiene es que es demasiado vaga porque por ejemplo dos consolas de videojuegos conectadas para jugar en red ¿se considera cluster? Pero si en vez de estar jugando se está usando el kit de Linux haciendo procesamiento paralelo, ¿entonces sí se podría considerar cluster?

Realmente el cambio de ambiente es mínimo, desde luego a nadie se le ocurriría definir cluster en base al contenido de los programas que se ejecuten y de hecho es posible que los juegos tengan más capacidades de procesamiento distribuido que los programas que queremos que funcionen en paralelo, entonces, ¿qué es un cluster?

Hay definiciones que distinguen entre cluster de máquinas SMP y clusters formados por nodos monoprocesadores. Hay arquitecturas clusters que se denominan constelación4.1 y se caracterizan por que cada nodo contiene más procesadores que número de nodos. A pesar de todo, las constelaciones siguen siendo clusters de componentes o nodos aventajados y caros. Dentro del top 500 de máquinas más potentes del mundo se encuentran unas 160 máquinas, lo que conforma aproximadamente el 32% de las máquinas considerad as más potentes del mundo. De hecho entre las máquinas que aparecen en esta listas del top500 existen unos pocos clusters que pertenecen a organizaciones que no son gigantes de la informática, lo cual indica el precio que pueden llegar a tener estas máquinas.

Por poner unos ejemplos de la disparidad de opiniones que existen se adjuntan las definiciones que dan ciertas autoridades de esta materia:



``Un cluster consiste en un conjunto de máquinas y un servidor de cluster dedicado, para realizar los relativamente infrecuentes accesos a los recursos de otros procesos, se accede al servidor de cluster de cada grupo'' del libro Operating System Concepts de Silberschatz Galvin.



``Un cluster es la variación de bajo precio de un multiprocesador masivamente paralelo (miles de procesadores, memoria distribuida, red de baja latencia), con las siguientes diferencias: cada nodo es una máquina quizás sin algo del hardware (monitor, teclado, mouse, etc.), el nodo podría ser SMP o PC. Los nodos se conectan por una red de bajo precio como Ethernet o ATM aunque en clusters comerciales se pueden usar tecnologías de red propias. El interfaz de red no está muy acoplado al bus I/O. Todos los nodos tienen disco local.

Cada nodo tiene un sistema operativo UNIX con una capa de software para soportar todas las características del cluster'' del libro Scalable Parallel Computing de Kai Hwang y Khiwei Xu.



``Es una clase de arquitectura de computador paralelo que se basa en unir máquinas independientes cooperativas integradas por medio de redes de intercone xión, para proveer un sistema coordinado, capaz de procesar una carga'' del autor Dr Thomas Sterling.



Como se puede apreciar cada una de las definiciones difiere de las demás llegando incluso a contradecirse.

4.1.2 Características de un cluster

Si no hay acuerdo sobre lo que es un cluster poco podrá acertarse en sus características. En este apartado se explican los requisitos que deben cumplir un conjunto de computadoras para ser consideradas cluster, tal y como se conocen hasta el momento.

Para crear un cluster se necesitan al menos dos nodos. Una de las características principales de estas arquitecturas es que exista un medio de comunicación (red) donde los procesos puedan migrar para computarse en diferentes estaciones paralelamente. Un solo nodo no cumple este requerimiento por su condición de aislamiento para pdoer compartir información. Las arqutecturas con varios procesadores en placa tampoco son consideradas clusters, bien sean máquinas SMP o mainframes debido a que el bus de comunicación no suele ser de red, sino interno.

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



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



Como hemos visto los nodos necesitan estar conectados para llevar a cabo su misión, de nada nos sirven 10 ordenadores que no se pueden traspasar información. Por tanto la segunda característica queda como:



ii.- Los nodos de un clsuter están conectados entre sí por un canal de comunicación funcional.



Por ahora hemos hablado de las características físicas de un cluster, que son las características sobre las que más consenso hay. Pero existen más problemas sobre las características del programario que se ejecuta sobre los mismos, pues es el software el que finalmente dotará al conjunto de máquinas de capacidad para migrar procesos, balancear la carga en cada nodo, etc. Otra de las características (evidente) es :



iii.- Los clusteres necesitan software especializado.



El problema también se plantea por los distintos tipos de clusters, cada uno de ellos requiere un modelado y diseño del software distinto. Se dan casos de programas que efectúan el trabajo de un cluster, pero que por el contrario son consideradas como aplicaciones individuales sin ningún tipo de conexión, que se comportan de manera organizada por eventos de cada nodo, como podría ser un sistema realizado a base de llamadas rexec solicitadas a cada nodo. Como es obvio la funcionalidad las características del cluster son completament e dependientes del software, por lo que no entraremos en las funcionalidades del software de momento, sino, en el modelo general de software que compone un cluster.

Para empezar, parte de este software se debe dedicar a la comunicación entre los nodos. Existen varios tipos de software que pueden conformar un cluster:

A pesar de la categorización de este software, existen casos en los cuales se hace uso de un conjunto de piezas de software de cada tipo para conformar un sistema cluster completo. Es decir, un cluster puede tener implementado a nivel de kernel parte del sistema y otra parte estar preparada a nivel de usuario.
Figura: Clusters. Cluster a nivel de sistema y nivel de aplicación
Image clusters

4.1.2.1 Acoplamiento de un cluster

Dependiendo del tipo de software, el sistema puede estar más acoplado o menos acoplado.

Se entiende por acoplamiento del software a la integración que tengan todos los elementos software que existan en cada nodo. Gran parte de la integración del sistema la produce la comunicación entre los nodos, y es por esta razón por la que se define el acoplamiento; otra parte es la que implica cómo de crítico es el software y su capacidad de recuperación ante fallos. Aquí hay que hacer un pequeño inciso para decir que todo esto depende de si el sistema es centralizado o distribuido. En cualquier caso, el acoplamiento del software es una medida subjetiva basada en la integración de un sistema cluster a nivel general.

Se distingue entre 3 tipos de acoplamiento:

Tras algunos ejemplos explicativos de estos tipos de acoplamiento quedará más clara la idea.



Acoplamiento fuerte.



El software que entra en este grupo es software cuyos elementos se interrelacionan mucho unos con otros, y hacen la mayoría de las funcionalidades del cluster de manera altamente cooperativa. El caso de acoplamiento más fuerte que se puede dar es que solamente haya una imagen del kernel del sistema operativo, distribuida entre un conjunto de nodos que la compartirán. Por supuesto algo fundamental es poder acceder a todas las partes de este sistema operativo, que están estrechamente relacionadas entre sí y distribuidas entre los nodos.

Este caso es el que se considera como más acoplado, de hecho no está catalogado como cluster, sino como sistema operativo distribuido.

Otro ejemplo son los cluster SSI, en estos clusters todos los nodos ven una misma imagen del sistema, pero todos los nodos tienen su propio sistema operativo, aunque estos sistemas están estrechamente relacionados para dar la sensación a las aplicaciones que todos los nodos son idénticos y se acceda de una manera homogénea a los recursos del sistema total. Si arranca o ejecuta una aplicación, ésta verá un sistema homogéneo, por lo tanto los kernels tienen que conocer los recursos de otros nodos para presentarle al sistema local los recursos que encontraría si estuviera en otro nodo. Por supuesto se necesita un sistema de nombres único, manejado de sistema distribuida o centralizada y un mapeo de los recursos físicos a este sistema de nombres.



Acoplamiento medio.



A este grupo pertenece un software que no necesita un conocimiento tan exhaustivo de todos los recursos de otros nodos, pero que sigue usando el software de otros nodos para aplicaciones de muy bajo nivel. Como ejemplos hay openMosix y Linux-HA.

Un cluster openMosix necesita que todos los kernels sean del mismo sistema operativo y que usen un parche compatible con los parches anteriores. Esto da una idea de lo acoplado que está el software de openMosix. 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 aproximación de dividir los procesos en una parte local y otra remota consigue que por un lado se necesite el software del otro nodo donde está la parte del fichero que falta en el nodo local y por otro que no se necesite un SSI para hacer otras tareas, por tanto se considera que está a un nivel inferior a SSI.



Acoplamiento débil.



Son los casos en los que los programas se dividen en diversos nodos y por tanto se necesitan pero que no están a un nivel tan bajo. Generalmente se basan en aplicaciones construidas por bibliotecas preparadas para aplicaciones distribuidas, agrupadas en un conjunto de aplicaciones específicos que generan el cluster en sí. Es el software que tiene mayor número de ejemplos, como PVM, MPI, CORBA, RPC, etc. los cuales por sí mismos no funcionan en modo alguno con las características que antes se han descrito (como Beowulf) y hay que dotarles de una estructura superior que utilice las capacidades del cluster para que éste funcione; a diferencia de los clusters de acoplamiento más fuertes que se encargan de actuar de la manera más independiente de los programas que permita su implementación.



Definición de acoplamiento.



A menudo el nivel de acoplamiento se confunde las características que posee el cluster, ya que dependiendo de este acoplamiento se considera cluster a un sistema y no a otro.

Lo habitual es que a medida que el acoplamiento de un sistema decrezca deje de ser tomado en cuenta como cluster. El problema está en que no existe un límite inferior de acoplamiento definido, lo cual causa mucha confusión. Por ejemplo, ¿cómo se podría catalogar el software del proyecto SETI de la NASA? Probablemente esté catalogado por muchos como cluster de alto rendimiento (cuya definición se verá más adelante) mientras que otros lo considere una mera aplicación con algo de comunicación.

Las conclusiones sobre este concepto que se proponen son las cuatro siguientes:

  1. El concepto de acoplamiento debe ser definido en todos los clusters. Esto implica que a pesar de la diferencia de funcionalidad entre unos y otros, solamente entrarán en la categoría de clusters, aquellos cuyo software pueda definir de una forma única y clara su nivel de acoplamiento.
  2. Para comparar el nivel de acoplamiento de dos clusters es necesario que:
    1. El intervalo de tiempo de las siguientes medidas en ambos clusters sean iguales.
    2. El sistema hardware que lo compone sea igual o al menos no imponga ninguna limitación o cuello de botella en las funcionalidades del cluster.
    Se consideran estos dos factores necesarios para poder medir el acoplamiento del cluster de una manera simple, aunque habrán que tenerse en cuenta más factores para llegar a una conclusión general acerca del acoplamiento de los clusters.

    El acoplamiento de un sistema de tipo cluster se basa principalmente en las colaboraciones que existen entre los elementos de proceso, es decir, a más colaborativa, más acoplado. Aun así, seguimos estando en el mismo problema de cómo definir de manera no abstracta la colaboración. Por ejemplo ¿una aplicación GNOME que utiliza CORBA puede llegar a ser tan acoplada como openMosix en el caso de que el número de colaboraciones sea mayor?

    Son preguntas que exigen las necesidades tenidas en cuenta hasta este punto para su respuesta.

    De esta manera para poder hacer nuestra comparación de cual de los dos es más colaborativo y por lo tanto más acoplado entre openMosix y CORBA, necesitaremos compararlos en un mismo intervalo de tiempo y con el mismo sistema, o con las menores limitaciones o cuellos de botella para sus funcionalidades. Para hacernos una idea de como es el acoplamiento necesitamos definir otro concepto que explique la colaboración entre cada nodo. Definimos valor neto de la colaboración como:

    $ Colaboraci\acute{o}n_{neta}=Num_{colaboraciones}*Calidad_{media}$

    Entendiéndose por número de colaboraciones, no el número de las veces que se comunicó cada nodo, sino el número de las veces que los nodos se comunicaron para poder colaborar. Por calidad media debemos entender la calidad o eficiencia media obtenida de cada una de las colaboraciones durante un intervalo de tiempo. De esta manera, obtenemos que para comparar el acoplamiento de dos clusters solamente tenemos que hacer uso de una relación entre la colaboración neta de cada uno de ellos, en el caso de que esta sea mayor que 1, el cluster más acoplado es el de la parte superior de la comparación y en el caso contrario el de la parte inferior de la comparación.

    $ Diferencia_{acoplamiento}=\frac{Colaboraci\acute{o}n_{neta}1}{Colaboraci\acute{o}n_{neta}2}$

    Como se ve en el resultado de esa formula, lo único que se puede comparar son las diferencias entre un sistema y otro. Ya veremos en el siguiente punto cómo esto se asevera, el dato de colaboración neta no es un dato válido para definir el acoplamiento. Intentar saber el acoplamiento absoluto de un sistema es muy complejo, en cambio es más sencillo compararlo con otros sistemas. Lo que se necesitaría para conseguir valores absolutos es un sistema de referencia, pero como veremos en el siguiente punto esta fórmula se complica mucho si los sistemas que se comparan no son idénticos por lo que solamente se podría comparar el acoplamiento en ese mismo sistema si se pretende unos valores correctos.

    Si utilizamos esta conclusión en un ejemplo tendríamos el siguiente resultado: un sistema openMosix de N nodos envía información de cada nodo cada segundo, mientras que el sistema CORBA lo hace cada 0.1 segundos, sin embargo, el sistema CORBA hace uso de librerías especiales que introducen cabeceras al sistema para la migración de objetos, es más, se hace uso de RPC, y por consiguiente de XDR lo cual hace que la eficiencia de cada colaboración sea muy pequeña, mientras que el sistema openMosix, pasa datos entre PC's de una misma arquitectura (lo cual lo exime de una sintaxis de notación abstracta) y además los pasa como estructuras, es decir sin cabeceras, limitando su tamaño bastante respecto al de CORBA, no solo eso, sino que el paquete UDP que llega a un nodo openMosix, se procesa de manera más rápida al no pasar por todas las interfaces a través de las cuales pasan los paquetes CORBA, es decir, la eficiencia de openMosix en sus colaboraciones es muy superior a la de CORBA, con lo que obtendrí amos que el más acoplado es openMosix.

    De la misma manera, el ejemplo de las dos parejas que solucionan el mismo problema en un tiempo dado, tenemos que ambos han obtenido una colaboración neta igual, cosa que en el caso de nuestro grupo de trabajo respecto al de Linus y Alan sería imposible, debido a que la eficiencia o profundidad de sus correos es mucho más efectiva que nuestras indagaciones acerca de hasta que punto afecta una tarjeta de vídeo en un cluster de renderizado, por ejemplo.

    Esto es así porque estamos suponiendo que de todo lo que estamos hablando, gran parte no es carga colaborativa útil sino que son cabecera y datos superfluos que no añaden nada a la colaboración neta.

    Figura: Clusters. Valor neto de colaboraciones
    Image valor_neto
    Como vemos en la figura 4.2, S1 se actualiza cada 4 tiempos pero cada vez que se actualiza su contenido neto de colaboración crece bastante, en cambio S2 está esforzándose continuamente y añadiendo un poco a su contenido neto de colaboración pero como su calidad media es tan baja no puede llegar a alcanzar a S1.

    El número de colaboraciones es bastante fácil de medir, ya que solamente hay que contar el número de veces que se comunican para colaborar en un tiempo dado, por otro lado, la eficiencia de las comunicaciones solamente incluye aquella parte de la comunicación que se utilizó realmente de manera necesaria para colaborar, es más, la medida de la eficiencia, vuelve a ser un tanto abstracta debido a que para resolver un problema concreto en un cluster, se pueden utilizar varios algoritmos, y cada uno de ellos requerir que se comparta cierta información a la que llamamos colaboración, que permite que migren los procesos o se comuniquen eficazmente entre sí. En general, cuanta más información significativa para una colaboración se envíe en paquete más pequeños (sin sobrecarga dedicada a tareas no colaborat ivas), más eficaz es la colaboración. Para elaborar la comparación de todo el sistema, hemos estado pensando continuamente en un sistema base de openMosix y otro de CORBA. El problema es que CORBA necesita una aplicación para tener significado mientras que openMosix no, es por esto por lo que llegamos al tercer punto de nuestras conclusiones.

    Hemos elegido estos dos casos porque como ya explicamos al inicio del tema openMosix es especialmente eficiente en sus colaboraciones mientras que CORBA tiene gran cantidad de sobrecarga en sus colaboraciones.

  3. La comparación de clusters entre nivel de aplicación y nivel de sistema requiere una aplicación corriendo encima de ambos, esto implica introducir factores externos que complican nuestra anterior ecuación.

    Un cluster a nivel de sistema es un cluster por sí mismo, en el sentido de que a pesar de que son las aplicaciones las que obtienen la funcionalidad real del sistema, el sistema en sí mismo es autodependiente, genera una valor neto de colaboración sin hacer uso de ninguna aplicación. Por el contrario, los clusters formados a nivel de aplicación, no existen hasta que se ha lanzado esta en todos los nodos, o puede que una lo lance y comience el evento que lanza todas las aplicaciones en los nodos, pero en cualquier caso, el cluster al completo depende completamente de la existenci a de librerías, como puede ser PVM, en el caso de que las librerías sean compartidas, o como poco de una compilación especial.

    Además, el programa va a depender del sistema operativo en sí, por lo cual el número de dependencias es mayor.

    En cualquier caso, el sistema a nivel de aplicación requiere una aplicación para conformar el cluster, lo que hace que comparación formulada en el apartado anterior no sea correcta ya que se introduce un factor externo.

    1. Se requiere aplicación por encima de cluster de aplicación, con lo que ponemos una aplicación en el cluster de sistema para poder comparar.

    2. La situación ideal son dos aplicaciones que no hagan nada, pero dependiendo de las librerías que utilice el cluster a nivel de aplicación, estas no tienen por que generar comunicación con lo cual es una situación utópica.

    3. Visto que las dos aplicaciones tienen que tener funcionalidad y por lo tanto algoritmo, cada aplicación puede utilizar distintos algoritmos, lo que no implica si el cluster es más o menos acoplado, sino la eficiencia del algoritmo.
    El problema de introducir factores externos complica la fórmula, y no la hace válida.

    Para llegar a una especie de aproximación de medida necesitarí amos dos aplicaciones que siempre que las características del sistema lo permitan utilicen el mismo algoritmo de la misma forma, mediante las mismas técnicas y mismos recursos. En este caso, la comparación sería efectiva, en caso contrario, que suele ser el más habitual debido a los factores de implementación que afectan a cada sistema, la comparación debe hacerse de la manera más objetiva posible haciendo una media de los valores obtenidos con distintas técnicas.

  4. Cuando en la comparación de los sistemas clusters se introducen más valores de los cuales depende su acoplamiento, la ecuación formulada anteriormente cambia como se ha visto en el apartado anterior. Estos factores externos al software no lo son al sistema global que conforma el cluster, por esto, la medida anterior solamente refleja cómo de acoplado está un software de cluster (que muchos denominarían como el cluster en símismo o el sistema basal del cluster). Cuando hablamos de un cluster, nos referimos a nodos, con memoria, procesador, interfaz de red, red de comunicación, buses internos, tarjetas gráficas, etc. Todas estas características conforman el cluster completo. Puede ser que la funcionalidad del cluster no dependa de todas ellas a la vez, de hecho, dependiendo de la funcionalidad del cluster asísera la necesidad de los recursos que lo componen, el caso es que todos estos recursos necesarios, terminan siendo factores críticos en el cluster, en la ejecución de su funcionalidad y en la manera de colaborar de este sistema.

    Pongamos el ejemplo anterior de CORBA y openMosix. Hemos aprendido que necesitamos un programa encima de los dos para poder compararlos, supongamos que dicho programa es el programa utópico del cual hablábamos en el apartado anterior para introducir menos factores al caso, pero base que esta vez el cluster CORBA, se ejecuta en una red con un ancho de banda y velocidad mayor que la de openMosix, aunque los nodos sean los mismos. En este caso, la comparación del acoplamiento de ambos sistemas depende de la red, y puede hacer que en el mismo intervalo de tiempo una cluster CORBA sea más acoplado que un cluster openMosix4.2. Para considerar estos factores tenemos que:

    1. Considerar la funcionalidad de ambos sistemas, ésta debe ser la misma o similar.
    2. Establecer que factores afectan a dicha funcionalidad.
    3. Generalmente se deben incluir entre estos factores por causas obvias los siguientes apartados:
      1. Red de comunicación
      2. Procesadores
      3. Memorias
    Puede haber muchos otros factores que afecten como, dispositivos de almacenamien to o tarjetas gráficas en el caso de compilación y renderizado. En cualquier caso se deben introducir todos aquellos factores que puedan ser considerados cuellos de botella para el sistema. De esta manera la ecuación de comparación del acoplamiento de software del cluster puede ser substituida por la siguiente.

    $ Acoplamiento=\frac{\frac{C_{neta}1}{E_{neta}1}}{\frac{C_{neta}2}{E_{neta}2}}$ donde

    De esta manera tenemos que, si los factores externos, es decir el sistema entero que conforma el cluster se idealiza o si son de características similares, estos se anulan quedando la ecuación enunciada en el apartado número 2, lo cual es del todo correcto. Por otro lado, nos permite comparar clusters implementados sobre distintos sistemas. Por ejemplo, en un caso de dos clusters similares cuya cantidad de colaboración neta es igual, están conformados por las mismas máquinas, y cuya única limitación consiste en la utilización de la red, tenemos que la colaboración neta es igual y por tanto se puede anular, y que solamente depende del factor de limitación, es decir, si el sistema 1 utiliza una red de 10 Mbps y el 2 una de 100 Mbps y ambos clusters acaban en un intervalo de tiempo igual de efectuar la funcionalidad para la que sirven (que es la misma) trabajando al 100% ambos dos, tenemos que:

    $ Acoplamiento=\frac{\frac{C_{neta}}{10}}{\frac{C_{neta}}{100}}=10$

    De lo cual obtenemos que el cluster que tiene mayor limitación de red, ha hecho un mayor esfuerzo colaborativo para llegar al mismo resultado, y que por lo tanto está más acoplado que el segundo sistema.

    Como se puede ver en este ejemplo, las limitaciones, no solo pueden ser de la red, en el caso de procesadores, el problema sería muy similar, es decir dos sistemas de los cuales, uno de ellos utiliza procesadores de 1 GHz mientras que el segundo los utiliza de 100 MHz, el sistema de 1 GHz utiliza un 7% mientras que el segundo utiliza un 89% de su tiempo dedicado a esta funcionalidad, esto implica que en un intervalo de 1 segundo, el primer cluster ha utilizado 70 millones de ciclos en obtener la funcionalidad que genera el cluster mientras que el segundo utilizo 89 Millones de ciclos, al hacer la comparativa obtendremos que a pesar de que el sistema de 1GHz acabe antes, al utilizar el segundo sistema más tiempo de sus recursos para obtener la funcionalidad, se considerara éste más acoplado. Lo mismo sucede cuando en lugar de ciclos medimos rendimiento eficaz de algoritmos, en este caso también se puede ver como los clusters implementados a nivel de sistema gastan más instrucciones para colaborar que los sistemas cluster a nivel de aplicación que tienen que utilizar funciones interfaces de librerías, traducciones de código y demás acciones que tienen por fin la abstracción del sistema, pero que tienen como inconveniente la inclusión de código inútil para la colaboración, pero necesario para la misma es decir código no eficiente.

    Hasta ahora solamente hemos introducido factores aislados, pero, no tenemos más que ir añadiendo factores relacionados con cada una de las limitaciones que conforman nuestros sistemas para poder ir realizando las comparaciones adecuadas. Por otro lado, cada factor limitativo debe ser incorporado en numerador y denominador, es decir en ambos sistemas, ya que aunque solamente sean escalares, pertenecen a factores asociados a una limitación especifica.

    Estos valores no se pueden comparar directamente y se tiene que intentar compensar los valores con lo que realmente se están usando. Por ejemplo, en clusters de compilación, es bastante importante la latencia y velocidad del disco duro, por lo que se le tiene que dar más peso. En cambio, en otro tipo de cluster quizás ni siquiera la mayoría de los nodos dispongan de disco duro por lo que no es un factor que afecte.

4.1.2.2 Otras características

Las características básicas de un cluster de carácter general que se han desarrollado podrían resumirse en el siguiente esquema:
  1. Un cluster consta de 2 o más nodos conectados entre sípor un canal de comunicac ión funcional.

  2. Cada nodo únicamente necesita un elemento de proceso, memoria y un interfaz para comunicarse con la red del cluster.

  3. Los clusteres necesitan software especializado. Este software y las máquinas conforman el cluster. El software puede ser:
    1. aplicación
    2. sistema

  4. Se define acoplamiento de un cluster como nivel de colaboración que une los elementos del cluster. De este modo se categorizan en:
    1. Acoplamiento fuerte
    2. Acoplamiento medio o moderado
    3. Acoplamiento débil

  5. Todos los elementos del cluster trabajan para cumplir una funcionalidad conjunta, sea esta la que sea. Es la funcionalidad la que caracteriza el sistema.
Muchos libros dan otra serie de características necesarias, por ejemplo el Scalable Parallel Computing de Kai Hwang y Zhiwei Xu incluye entre estas características las siguientes: Ambas sobre un sistema aislado, pero bajo nuestro criterio y pruebas, hemos comprobado cómo dependiendo de los programas que se ejecuten sobre un cluster, en ciertas ocasiones, este obtiene peor rendimiento. Es más, dependiendo de la funcionalidad del sistema, puede que el factor de disponibilidad no afecte hasta un cierto punto. Otra de las características que se requiere generalmente de un cluster es que presente un entorno de trabajo confiable. Cualquiera de estas características dan pie a una clasificación de los clusters.

En general la catalogación de los clusters se hace en base a cuatro factores de diseño bastante ortogonales entre sí.

De estos factores en este tema ya se ha visto el que quizás es más importante, el de acoplamiento.

Por otro lado está el factor de control del cluster. El parámetro de control implica el modelo de gestión que propone el cluster. Este modelo de gestión hace referencia a la manera de configurar el cluster y es dependiente del modelo de conexionado o colaboración que surgen entre los nodos. Puede ser de dos tipos:

Por otro lado, el factor de gestión o control de un cluster es importante a la hora de monitorizar su comportamiento ya que estos sistemas deben estar bien controlados para ver que realmente hacen su trabajo correctamente.

En lo que se refiere a homogeneidad de un cluster cabe decir que Tanenbaum no llevaba razón, a pesar de que sus conclusiones después de haber creado el sistema Amoeba, se ha demostrado que es posible crear sistemas de una sola imagen o hetereogéneos con una implementación práctica. En cualquier caso, hay que entender por homogeneidad del cluster a la homogeneidad de los equipos y recursos que conforman a éste, los clusters hetereogé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.

Existen otros muchos factores de diseño que limitan el comportamiento y modelado de un cluster. Estos factores tienden hacia unas características de cluster ideal, al cual aun quedan unos pocos años para poder llegar. El problema para llegar a estos clusters se basa en que la mayoría de las aplicaciones existentes hacen uso de algoritmos secuenciales no paralelizables, pero a medida que los programadores vayan adaptando sus programas a este tipo de sistemas, el número y la existencia de los clusters se irá incrementando.

Entre estos factores de diseño que implementan algunos clusters, están entre otros:

Como se puede comprobar, todos estos detalles de implementación, se tienen en cuenta en partes anteriores de este tema, por lo cual no se hará especial hincapié en ninguna de ellas. En cualquier caso ya se ha dicho que hacer un sistema SSI, que es uno de los sistemas cluster más acoplados, es una tarea bastante complicada. No solamente por problemas conceptuales, sino por problemas serios a la hora de implementarlo.

Las metas que se proponen en un cluster SSI son proveer simultáneamente de:

Los cluster SSI no solamente se van pareciendo cada vez más a clusters del tipo HA, sino que también se encargan de balancear la carga a varios niveles y obtener mejoras de rendimiento del sistema.

4.1.3 Clasificción según el servicio prioritario

En este apartado se explican los conceptos necesarios para poder definir las características que implementan cada uno de estos sistemas. Generalmente el diseño de un cluster se realiza para solucionar problemas de: El punto inicial ha sido explicado en muchas ocasiones anteriormente. El coste para doblar las prestaciones de un equipo no suele ser habitualmente a costa de pagar el doble, sino unas cuatro veces más. El modelo de los clusters permite que la mejora de rendimiento sea evidente respecto a grandes mainframes a un precio realmente asequible. Lo que explica a su vez el segundo punto, acerca del coste de los cluster, que permite relaciones rendimiento precio que se acercan a un margen lineal dependiendo del cluster implementado.



Por otro lado esta la distribución de riesgos. La mayoría de las empresas o usuarios, tiene sus servicios, aplicaciones, bases de datos o recursos en un solo ordenador, o dependientes de un solo ordenador. Otro paso más adelante de las empresas, es colocar sus bases de datos replicadas sobre sistemas de archivos distribuidos de manera que estos no se pierdan por que los datos son un recurso importante. Actualmente el mercado de la informática exige no solo que los datos sean críticos (como lo han sido desde hace unos años ) sino que el tiempo de disponibilidad, de los servicios, estén activos constantemente. Esto, junto con la sabida incapacidad que tienen los sistemas de dejar de funcionar accidentalmente, exigen medios y técnicas que permitan que el tiempo en el que una máquina deje de funcionar sea lo menor posible, o el mismo caso con un servicio. La distribución de factores de riesgo a lo largo de un cluster o la distribución de funcionalidad (en casos más generales) a lo largo de un cluster nos permite de una forma única, obtener la funcionalidad de una manera más confiable, ya que si una máquina cae, otras pueden hacer el servicio, o funcionalidad por esta.



Por último está el factor de escalabilidad, del cual se habló en el tema de introducción. La escalabilidad interviene en todos los puntos anteriores. Cuanto más escalable es un sistema, menos cuesta mejorar el rendimiento, lo cual abarata el coste, y en el caso de que el cluster lo implemente distribuye más el riesgo de caída de un sistema.



En cualquier caso, todas estas características dan pie a los tipos de clusters que se van a ver.

Los clusters de alto rendimiento han sido creados para compartir el recurso más valioso de un ordenador, es decir, el tiempo de proceso, generalmente se utilizan en ambientes científicos, o en grandes empresas donde se utilizan para la compilación o renderización. Cualquier operación que necesite altos tiempos de CPU y millones de operaciones puede ser utilizada en un cluster de alto rendimiento, siempre que se encuentre un algoritmo que sea paralelizable. Existen clusters que pueden ser denominados de alto rendimiento tanto a nivel de sistema como a nivel de aplicacion. A nivel de sistema tenemos openMosix, mientras que a nivel de aplicación se encuentran otros como MPI, PVM, Beowulf y otros muchos. En cualquier caso, estos clusters hacen uso de la capacidad de procesamiento que pueden tener varias máquinas.

Los clusters de alta disponibilidad, son bastante ortogonales en lo que se refieren a funcionalidad a un cluster de alto rendimiento. Los clusters de alta disponibilidad pretenden dar servicios 24*7, de cualquier tipo, son clusters donde la principal funcionalidad es estar controlando y actuando para que un servicio o varios se encuentren activos durante el máximo periodo de tiempo posible. En estos casos se puede comprobar como la monitorización de otros es parte de la colaboración entre los nodos del cluster.

Por ultimo, están los clusters de alta confiabilidad. Estos clusters tratan de aportar la máxima confiabilidad en un entorno, en la cual se necesite saber que el sistema se va a comportar de una manera determinada. Hay varias diferencias de concepto entre este tipo de cluster y el cluster de alta disponibilidad, no es tan sencillo como decir que un cluster de alta confiabilidad que hace que un servicio sea confiable, es igual que un cluster de alta disponibilidad.



Pueden existir otras catalogaciones en lo que se refiere a tipos de clusters, en nuestro caso, solamente hemos considerado las tres que más clusters implementados engloban, si bien existe alguno de ellos que puede ser considerad o como cluster de varios tipos a la vez.

4.1.4 HP (alto rendimiento)

En este apartado, se va a dar una visión general de qué son y qué problemas resuelven los clusters denominados HP o AR (de 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 dos. También se hará algún tipo de apunte acerca de las limitaciones que tienen los sistemas que conocemos para resolver estos problemas.

4.1.4.1 La misión

La misión o el objetivo de este tipo de clusters es como su propio nombre indica:

El objetivo será mejorar el rendimiento en la obtención de la solución de un problema.

Dentro de esta definición no englobamos ningún tipo de problema en especial. Esto supone que cualquier cluster que haga que el rendimiento del sistema general aumente respecto al de uno de los nodos individuales puede ser considerado cluster de alto rendimiento. Generalmente, los problemas que se le plantean a un ordenador, suelen ser de carácter computacional, por esto, este tipo de clusters suele ser denominado clusters de alto rendimiento de cómputo, pero ésto no implica que solucione otros problemas. Se podría definir estos sistemas como sistemas distribuidos (en cada nodo) en los cuales se resuelve de manera distribuida un problema de computo.

4.1.4.2 Problemas que solucionan

Generalmente estos problemas de computo suelen estar ligados a: Existen otros muchos problemas más que se pueden solucionar con clusters de alto rendimiento, 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.

4.1.4.3 Técnicas que utilizan

Las técnicas utilizadas dependen de a qué nivel trabaje el cluster. En un principio hemos dicho que lo podemos dividir en clusters de tipos distintos. Los clusters implementados a nivel de aplicacion, 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 dentro de 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 compartición de recursos a cualquier nivel, balanceo de la carga de manera dinámica, funciones de scheduling especiales y otros tantos factores que componen el sistema. Se intentan acercar al sistema SSI, el problema esta 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 vamos a poner como ejemplos que existen actualmente, esta la incapacidad de balancear la carga dinámica de las librerías PVM o MPI, frente a 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 y openMosix, obteniendo un sistema con un factor de acoplamiento elevado que nos permite las ventajas de uno y otro, con una pequeña limitación por desventajas de cada uno, pero que da un resultado excelente en clusters de alto rendimiento hechos a medida para aplicaciones que requieran alto tiempo de computo.

4.1.5 HA (alta disponibilidad)

Son otro tipo de clusters completamente distintos a los anteriores. Son más solicitados por las empresas ya que están destinados a mejorar los servicios que estas 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. Se ha dedicado un tema entero a este apartado, por lo cual no será muy extenso.

4.1.5.1 La misión

Los clusters de alta disponibilidad han sido diseñados para la máxima disponibil idad 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. De hay el denominado 24*7. Para poder dar estos servicios, los clusters de este tipo se implementan en base a tres factores. 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 este funcione de una manera confiable. Respecto al tercer punto, se refiere a la dotación de uno de estos clusters de un servicio que provea a cliente externos.

4.1.5.2 Problemas que solucionan

La mayoría de estos problema están ligados a la necesidad de dar servicio continuado de cualquier tipo a una serie de clientes de manera ininterrumpida. A esta funcionalidad se suele oponer la ley del caos en una de sus vertientes informáticas. Se suelen producir fallos inesperados en las máquinas, estos fallos provocan la aparición de dos eventos en el tiempo, uno es el tiempo en el que el servicio está inactivo y el otro es el tiempo de reparación del problema. Ambos tiempos no tienen por que estar relacionados, aunque a menudo si lo estén.

Entre los problemas que solucionan se encuentran:

En general todos estos problemas se ligan en dos fuentes de necesidad de las empresas u organizaciones. 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.

4.1.5.3 Técnicas que utilizan

Son muy diversas, como hemos visto en el apartado anterior ya que los servicios y el funcionamiento de los mismos suelen ser de carácter bastante distinto, en cualquier caso, se suelen proponer sistemas desde SSI que plantean serias dudas en lo que se refiere a localización de un servidor, hasta balanceo de carga o de conexiones, también suelen contener secciones de código que realizan monitorización de carga o monitorización de servicios para activar las acciones necesarias para cuando estos caigan.

Se basan en principios muy simples que pueden ser desarrollados hasta crear sistemas complejos especializados para cada entorno particular. En cualquier caso, las técnicas de estos sistemas suelen basarse en excluir del sistema aquellos puntos críticos que pueden producir un fallo y por tanto la pérdida de disponibilidad de un servicio, para esto se suelen implementar desde enlaces de red redundantes hasta disponer de N máquinas para hacer una misma tarea de manera que si caen N-1 máquinas el servicio permanece activo sin pérdida de rendimiento.

La explicación de estas técnicas ha sido muy somera, se darán más detalle en el tema perteneciente a clusters HA.

4.1.6 HR (alta confiabilidad)

Este tipo de clusters son los más difíciles de implementar, generalmente se basan en no solamente conceder servicios de alta disponibilidad, sino en ofrecer un entorno de sistema altamente confiable. Esto implica en símismo muchísima sobrecarga en el sistema, son también clusters muy acoplados.

Dar a un cluster SSI capacidad de alta confiabilidad implica gastar recursos necesarios para evitar que aplicaciones caigan. Aquí hay que hacer de nuevo un inciso.

En los clusters de alta disponibilidad generalmente una vez que el servicio ha caído éste se relanza, y no existe manera de conservar el estado del servidor anterior, más que mediante puntos de parada o checkpoints, pero que en conexiones en tiempo real no suelen ser suficientes. Por otro lado, los clusters confiables tratan de mantener el estado de las aplicaciones, no simplemente de utilizar el ultimo checkpoint del sistema y relanzar el servicio.



Generalmente este tipo de clusters suele ser utilizado para entornos de tipo empresarial y esta funcionalidad solamente puede ser efectuada por hardware especializado. No existe ninguno de estos clusters implementados como software de manera eficiente en tiempo real. Esto se debe a limitaciones de la latencia de la red, asícomo a la complejidad de mantener los estados. Estos clusters deberían ser una mezcla de clusters de alto rendimiento y alta disponibilidad mejorados. Necesitarían características de cluster SSI, tener un único reloj de sistema conjunto y otras acciones más. Dada la naturaleza asíncrona actual en el campo de los clusters, este tipo de clusters aún será difícil de implementar hasta que no se abaraten las técnicas de comunicación utilizadas en entornos que actualmente consideramos inalcanzables para la mayoría de las organizaciones o con no suficiente coste/rendimiento.


miKeL a.k.a.mc2 2003-09-28