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.
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:
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:
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:
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:
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.
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.
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.
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.
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.
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:
donde
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.
En general la catalogación de los clusters se hace en base a cuatro factores de diseño bastante ortogonales entre sí.
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:
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.
Entre estos factores de diseño que implementan algunos clusters, están entre otros:
Las metas que se proponen en un cluster SSI son proveer simultáneamente de:
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.
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.
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.
Entre los problemas que solucionan se encuentran:
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.
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.