Barrapunto

Según lo que he leído un cluster es una agrupación de varios ordenadores que realizan una tarea o tareas concretas.
Si tienes un programa que tarda en ejecutarse, digamos, 250 días, con un cluster (y las herramientas de programación-administración adecuadas, por supuesto) podrías repartir el trabajo entre varios ordenadores. Así si tienes 250 ordenadores, en teoría, el programa podría tardar en ejecutarse poco más de ¡¡1 día!!.
Cómo se realiza todo ésto es bastante/muy complejo: se debe compilar el programa específicamente para el cluster, el programa ha de ser "paralelizable" (divisible en tareas más pequeñas).
Ejemplos de cluster para linux: MOSIX (www.mosix.org) y el primero: Beowulf (www.beowulf.org)

Mmmmm, una buena pregunta. Un cluster es una agrupación de ordenadores dedicados a resolver un problema común. Los hay de muchos tipos, dependiendo de la finalidad y la tecnología empleada, pero en general se basan en una premisa muy simple: encontrar una persona capaz de levantar 200 Kg es muy difícil, encontrar 10 que puedan levantar 25 Kg cada uno es más sencillo :)

Una primera distinción sería:

1. Cluster de alta disponibilidad, por ejemplo un conjunto de servidores web.
2. Cluster de alto rendimiento, por ejemplo uno dedicado a generar los frames de una película.

En cuanto a la tecnología empleada, algunos ejemplos típicos podrían ser:

1. Beowulf.- Conjunto de ordenadores normales trabajando en común empleando algún tipo de librería "paralela", por ejemplo PVM o MPI
2. MOSIX.- El ejemplo del que sale esta noticia
3. Hay una solución propietaria de Turbolinux de la que ahora mismo no recuerdo el nombre, pero que permite paralelizar cierto tipo de cálculos sin tener que modificar los programas.
4. Sistemas inherentemente paralelos, por ejemplo las redes neuronales.

En realidad hay muchos otros, dependiendo de infinidad de parámetros: que si tecnología de conexión normal (Ethernet) o especial (Myranet), que si usando placas duales o simples, que si alpha o intel, que si ... un montón :)

Los clusters son una forma de obtener potencia de cálculo incrementalmente (si me hace falta un poco más compro 16 máquinas nuevas y ya está). La otra alternativa sería usar grandes máquinas tipo IBM S/390, que exigen un altísimo desembolso inicial pero que escalan mejor.

En general, la parte más delicada de un cluster suele ser la parte de comunicaciones, que es donde se utiliza gran parte del dinero total de la inversión, y es que a partir de un número elevado de nodos, las redes TCP/IP sobre Ethernet presentan algunos problemillas.

Para terminar decirte que los clusters son una de las áreas de más futuro en Linux por las increibles ventajas de coste, fiabilidad, posibilidad de adaptación y alto número de plataformas en las que corre. Un buen número de clusters se encuentran entre los ordenadores más potentes del mundo.

Por supuesto que quedan cosas importantes por hacer, como hacer de verdad un sistema de fail-over con almacenamiento compartido (en plan TruCluster 5 de Tru64 Unix). También hay que mejorar el soporte SMP, y no vendría nada de mal COMENTAR los fuentes del kernel... que si te pones a recorrerlo verás que hay coas que quedan "en el aire". Y bueno, dentro del soporte SMP estaría bien que hubiera un buen interfaz para asignar un(os) proceso(s) a determinado(s) CPU(s)

Seguro que me dejo algo, pero es que tengo que irme a la Feria :-)

Saludetes....

No quiero quitarles la razon ni a pepes ni a jnebrera, pero en mi humilde opinion, no han descrito bien el concepto de cluster.

pepes dice: una agrupación de varios ordenadores que realizan una tarea o tareas concretas

Pero creo que la definicion no esta completa. Lo que el esta describiendo es "computacion distribuida", muy diferente, aunque similar en algunos puntos, a los clusters.

jnebrera dice: Un cluster es una agrupación de ordenadores dedicados a resolver un problema común

Me sigue pareciendo un poco floja, Asi que voy a dar la mia, que no por ser mia es mas correcta que las demas ;)

Un custer es, fisicamente, un conjunto de ordenadores que, a nivel logico, actuan como uno solo.

Por ejemplo, una "granja" de servidores web no es un cluster. Para ese tipo de aplicaciones se usan soluciones de balanza de carga, que pueden ser Round Robin DNS, NAT... Windows 2000 viene con un sistema de balance de carga basado en NAT. En estos sistemas, cada ordenador de la granja es una unidad fisica independiente y cada uno tiene su IP/IPs.

En soluciones cluster, cada ordenador no es una unidad fisica independiente, puesto que cada miembro del cluster esta conectado a una unidad de almacenamiento de datos comun a todos ellos. Ademas de eso, tienen algun sistema de comunicacion interna, como por ejemplo, se pueden conectar entre ellos por una red ethernet. Cada miembro del cluster tiene una IP para la comunicacion interna, pero el cluster en si mismo solo tiene una IP externa por la que es accesible.

Por otro lado, en sistemas de balanza de carga como el Round Robin DNS, si el servidor que nos ha sido asignado deja de responder, perderemos la conexion con ese servidor y no podemos reconectar hasta que vuelva a estar operativo. En otros sistemas de balanza de carga en los que se usa NAT, automaticamente seremos "trasladados" a otro maquina, pero perderemos la session que teniamos establecida. En un sistema cluster esto no pasa.

Generalmente, los cluster se usan para sistemas de alta disponibilidad, como pueden ser las bases de datos bancarias, servidor X, Windows NT/2000 Terminal Service... donde el fallo de uno de los nodos nos permite continuar nuestro trabajo como si nada hubiera pasado.

Por otro lado, siempre he leido sobre sistemas cluster de 2, 4 y 8 nodos. No se si habra de mas, pero lo que si estoy seguro es que tienen que ser dificiles de implementar. Hotmail cuenta con una granja de 4000 servidores, y Google creo que anda por los 5000. No se cual es la configuracion actual de Google, pero se que Hotmail cuenta con 12 clusters de 4 nodos cada uno para servir paginas web, y despues tienen otros 3000 servidores que es donde almacenan los correos de los usuarios. En este caso, primero usan un sistema de balanza de carga por Round Robin DNS hacia los 12 clusters, y gracias a estos clusters garantian que si uno de los servidores se cae, los usuarios puedn seguir trabajando sin problemas, cosa que no ocurriria si solo usaran Round Robin DNS.

Para finalizar, y ya que lo preguntaban, Windows NT 4.0 tiene una solucion cluster de hasta 4 nodos que no viene "de serie", Windows 2000 Server no tiene solucion cluster, Windows 2000 Advanced Server viene con una solucion cluster de 2 nodos, y la version Data Center viene con una solucion cluster de hasta 8 nodos.

¿ Qué le falta al núcleo de Linux ?. En tres palabras: que funcione mejor. Porque la realidad es esa, se ha avanzado mucho en poco tiempo, pero aún estamos lejos de un sistema operativo a la altura de los UNIX comerciales más potentes.

Por ejemplo, el manejo de la memoria virtual, básico en cualquier UNIX, está dando la lata mucho más de lo que nos gustaría (incluyendo el algoritmo de matar procesos en situaciones de falta de memoria, OOM). El planificador también necesita un repaso (la máquina queda completamente lenta de respuesta cuando la carga de proceso aumenta), haciendo imposible la corrección manual del sistema por parte del administrador.

Las prestaciones de Linux funcionando como router tampoco están a la altura de otros UNIX (hasta donde yo sé, aunque hay parches por ahí que mejoran mucho la cosa, no son estándares). Como ya han dicho, el SMP podría estar más optimizado de lo que está.

Tambien puede echarse de menos la implantación en el núcleo de políticas de seguridad y limitación de recursos para procesos/usuarios y la mejora del acceso a disco en modo raw. De momento en Linux no existe una implementación definitiva y aceptada de ACL (salvo el reciente XFS), sólo existen parches que aún están por terminar.

Falta también soporte para hardware insertable en caliente, un gestor de volúmenes sólido y profundamente testeado. Hasta el propio MOSIX aún tiene camino que recorrer, como por ejemplo los sockets migrables (para que sea interesante usar Apache sobre MOSIX, así como cualquier otro proceso limitado por comunicaciones).

Finalmente, pero no menos importante, falta documentar BIEN y en PROFUNDIDAD el núcleo, tanto el código como las interfaces (p.e. /proc, parámetros de arranque del núcleo, capacidades y opciones de cada driver disponible, etc.). Más que nada para poder sacar el máximo partido del sistema y para que nuestros hijos puedan seguir mejorando el núcleo sin tener que imaginarse qué pensaba A. Cox o L. Torvalds allá por el año 2001.

Y no es que Linux ahora mismo me desagrade, todo lo contrario, pero hay que dejar claro que queda aún mucho por hacer (de hecho, los UNIX comerciales llevan hasta 30 años evolucionando, 20 más que Linux, y eso se nota). Si queremos disfrutar de un buen sistema operativo en el futuro no podemos seguir pensando que ya está todo hecho, porque aún muchos SO nos llevan ventaja. Así que todos a colaborar en la medida de nuestras posibilidades, a ver si para el 2003 tenemos un sistema equivalente a los UNIX grandes.

Dejando de lado los clusters de alta disponibilidad, por ejemplo para aplicaciones Web (suelen ser sistemas de balanceo de carga IP), como el que usan en Slashdot , en el mundo Linux de la computación científica, existe desde 1994 el proyecto Beowulf , de la NASA. Este consiste en la implementación de sistemas de paralelización (PVM, MPI ) para C y Fortran en Linux y el soporte para tarjetas de red útiles en la construcción de clusters.
Aquí se puede encontrar la guia del superordenador en casa :-), sobre como utilizar PVM y el software de raytracing POVRAY.

MOSIX se parece más a un sistema de balanceo de cargas entre los nodos (los ordenadores) que forman el cluster. Así, no es necesario paralelizar los programas, con lo que tenemos la impresión de utilizar un mainframe de Sun o SGI, cuando en realidad estamos ante 10 Athlon a 1GHz.
Hay un artículo en byte.com sobre como montar un cluster MOSIX.

Hola a tod@s

En julio pasado terminé la ingeniería técnica en Informática de Sistemas en la Universidad Antonio de Nebrija. Mi proyecto se tituló "Tecnologías y Tendencias Hardware en Sistemas Paralelos". En un principio hace un repaso a las necesidades informáticas de los distintos campos industriales, pasando después a exponer varios ejemplos utilizables en cada paso. La parte realmente útil es la 3ª, donde se pasea por todo el state-of-the-art de este mundo y se exponen las diferentes soluciones existentes.

No es ninguna maravilla, pero tal vez a alguien le pueda ser de utilidad. Lo podéis encontrar en ftp://yolanda.undersec.com/pub/proyecto/ , en formatos dvi, ps y pdf.

Saludos

Pope - pope@netsearch-ezine.com - pope@undersec.com

Algunas "puntualizaciones":
Por ejemplo, el manejo de la memoria virtual, básico en cualquier UNIX, está dando la lata mucho más de lo que nos gustaría (incluyendo el algoritmo de matar procesos en situaciones de falta de memoria, OOM). Cierto, por esa razón se está utilizando la nueva VM, cuando se hayan solucionado muchos de los errores que comentas, Alan Cox tiene previsto "ajustar" la memoria virtual.
Tambien puede echarse de menos la implantación en el núcleo de políticas de seguridad y limitación de recursos para procesos/usuarios . Supongo que habrás leído una nueva implementación de seguridad (aún en fase de pruebas, lejos del kernel estándar) basada en unos módulos que se introducen para fijar la política de seguridad.
Falta también soporte para hardware insertable en caliente . Supongo que te refieres a "hotplug". A día de hoy está implementado el soporte USB y PCMCIA como "hotplug" (¿¿alguno más??), supongo que _no_ te refieres sólo a estos.
No dudo que Linux será grande, o como el lema de GNU/Debian ... "el sistema operativo universal".
Saludos de un "usuarius vulgaris"

>> Supongo que te refieres a "hotplug". A día de hoy está implementado el soporte USB y PCMCIA como "hotplug" (¿¿alguno más??), supongo que _no_ te refieres sólo a estos.

Me da en la nariz que no se refiere sólo a estos hotplug. Que yo sepa, y que conste que no conozco el tema en profundidad, aparte de los dos ya comentados, existen algunos más (aunque no necesariamente en Linux). Por ejemplo: dispositivos PCI, discos duros y lo más alucinante, el procesador (lógicamente en una placa dual o superior :) En general se les conoce más como hotswap que como hotplug ya que se trata de sustituir un dispositivo más que de engancharle uno nuevo.

> En soluciones cluster, cada ordenador no es una unidad fisica independiente, puesto que cada miembro del cluster esta conectado a una unidad de almacenamiento de datos comun a todos ellos. Ademas de eso, tienen algun sistema de comunicacion interna, como por ejemplo, se pueden conectar entre ellos por una red ethernet. Cada miembro del cluster tiene una IP para la comunicacion interna, pero el cluster en si mismo solo tiene una IP externa por la que es accesible.

En realidad, como norma general, sólo se puede acceder a uno de los nodos del cluster, que tiene una dirección IP externa. El resto tienen direcciones IP internas y muy poca seguridad entre ellos. Es el bastión exterior el que debe velar por la seguridad del acceso o todo se irá al garete. No veo muy clara la diferencia con respecto al punto anterior, que también suele depender de un servidor de base de datos, pero da igual, creo que se trata más de una diferencia formal que real.

> En un sistema cluster esto no pasa.

No estoy de acuerdo. Dada la forma habitual en la que se implementan los clusters de cálculo, todos los nodos dependen de un nodo maestro que es el que reparte las responsabilidades de cálculo. Si éste casca, casca todo el cluster. Si el cluster está bien hecho, si falla un nodo normal se debe poder repartir su trabajo entre el resto de nodos sin demasiados problemas. Igualmente, si falla el nodo que sirve de almacen de datos, lo más probable es que falle todo el sistema.

> Generalmente, los cluster se usan para sistemas de alta disponibilidad

Tampoco estoy de acuerdo. Tradicionalmente los clusters se han usado en soluciones de alto rendimiento, no de alta disponibilidad. La diferencia es clara, en los primeros pretendemos que siempre quede al menos 1 equipo que nos responda, en los segundos pretendemos obtener la máxima potencia de CPU posible. El ejemplo clásico de los clusters es el Beowulf que es una solución de alto rendimiento. Además, si te fijas bien, casi todos los clusters están en centros de investigación científica y no en bancos o compañías de seguros.

> Por otro lado, siempre he leido sobre sistemas cluster de 2, 4 y 8 nodos

????????. Esos son muy pocos nodos. Un cluster normalito en investigación científica tendría un mínimo de 16 nodos y suelen llegar fácilmente a 32 e incluso 64. Lo cierto es que a partir de 64 nodos la cosa se complica un poco, tal y como comentaba en mi anterior post por los problemas que tiene TCP/IP sobre Ethernet. En esos casos se utilizan tecnologías especiales (Myranet) o topologías muy complejas. De todas formas, hay clusters dedicados a cálculo científico de más de 512 nodos y no estoy hablando de clusters de alta disponibilidad que siempre es más sencillo escalar. La compañía Celera (Genoma Humano) tenía un cluster inmenso pero no es público. Cada grupo tenía de 64 a 128 nodos y tenían bastantes de éstos, aunque no todos trabajaban de forma coordinada.

Hace ya algún tiempo unos amigotes reunimos nuestros ordenadores para hacer un cluster para POVRay. Usamos un mísero HUB Ethernet 10 de 8 bocas y claro el rendimiento fue pésimo pero la experiencia muy divertida. Entre los nodos había desde un Athlon 700 con 256 MB RAM a un mísero 486 66 con 24 MB de RAM. Montar un cluster para POVRay es casi trivial, sobre todo si no te dedicas a optimizar cada nodo, usar nodos sin disco duro y cosas de esas. Se, por ejemplo, que en la ESI de Sevilla un proyecto de fin de carrera de un alumno de Industriales ha consistido en montar un cluster de 16 nodos duales para uno de los departamentos.

En cuanto a si Windows tiene soporte para clusters, SIIII. No se los detalles exactos porque no lo uso, pero tanto NT como 2000 seguro que lo tienen. Lo que ocurre es que realmente Linux se ha impuesto a Windows en este tema (al menos para clusters serios de más de 16 nodos). Una razón, y sólo digo una, sería el precio. Ambos windows requieren de versiones especiales de su software y seguro que no son nada baratas. Cualquier Linux, con los paquetes y