Si tienes al alcance varias computadoras los resultados serán los mismos ya que no podrás interactuar con más de una de ellas al mismo tiempo. Desafortunadamente cuando realmente necesites potencia computacional (como por ejemplo para comprimir un fichero Ogg Vorbis, o para una gran compilación) no podrás disponer de la potencia conjunta que te proporcionarían todas ellas como un todo.
La idea que se esconde en el trasfondo del clustering es precisamente poder contar con todos los recursos que puedan brindarte el conjunto de computadoras de que puedas disponer para poder aprovechar aquellos que permanecen sin usar, basicamente en otras computadoras.
La unidad básica de un cluster es una computadora simple, también denominada nodo. Los clusters pueden crecer en tamaño (o mejor dicho, pueden escalar) añadiendo más máquinas.
Un cluster como un todo puede ser más potente que la más veloz de las máquinas con las que cuenta, factor que estará ligado irremediablemente a la velocidad de conexión con la que hemos construido las comunicaciones entre nodos.
Además, el sistema operativo del cluster puede hacer un mejor uso del hardware disponible en respuesta al cambio de condiciones. Esto produce un reto a un cluster heterogéneo (compuesto por máquinas de diferente arquitectura) tal como iremos viendo paso a paso.
Los clusters Fail-over consisten en dos o más computadoras conectadas en red con una conexión heartbeat separada entre ellas. La conexión heartbeat entre las computadoras es usualmente utilizada para monitorear cuál de todos los servicios está en uso, así como la sustitución de una máquina por otra cuando uno de sus servicios haya caído.
El concepto en los Load-balancing se basa en que cuando haya una petición entrante al servidor web, el cluster verifica cuál de las máquinas disponibles posee mayores recursos libres, para luego asignarle el trabajo pertinente.
Actualmente un cluster load-balancing es también fail-over con el extra del balanceo de la carga y a menudo con mayor número de nodos.
La última variación en el clustering son los High Performance Computing.
Estas máquinas han estado configuradas especialmente para centros de datos que requieren una potencia de computación extrema.
Los clusters Beowulf han sido diseñados específicamente para estas tareas de tipo masivo, teniendo en contrapartida otras limitaciones que no lo hacen tan accesible para el usuario como un openMosix.
Pero muchos colectivos no pueden afrontar el costo económico que supone adquirir una máquina de estas características, y aquí es donde toma la máxima importancia la idea de poder disponer de esa potencia de cálculo, pero a un precio muy inferior.
El concepto de cluster nació cuando los pioneros de la supercomputación intentaban difundir diferentes procesos entre varias computadoras, para luego poder recoger los resultados que dichos procesos debían producir. Con un hardware más barato y fácil de conseguir se pudo perfilar que podrían conseguirse resultados muy parecidos a los obtenidos con aquellas máquinas mucho más costosas, como se ha venido probando desde entonces.
Las máquinas de tipo NUMA (Non-Uniform Memory Access) tienen acceso compartido a la memoria donde pueden ejecutar su código de programa. En el kernel de Linux hay ya implementado NUMA, que hace variar el número de accesos a las diferentes regiones de memoria.
PVM / MPI son herramientas que han estado ampliamente utilizadas y son muy conocidas por la gente que entiende de supercomputación basada en GNU/Linux.
MPI es el estándar abierto de bibliotecas de paso de mensajes. MPICH es una de las implementaciones más usadas de MPI, tras MPICH se puede encontrar LAM, otra implementación basada en MPI también con bibliotecas de código abierto.
PVM (Parallel Virtual Machine) es un primo de MPI que también es ampliamente usado para funcionar en entornos Beowulf.
PVM habita en el espacio de usuario y tiene la ventaja que no hacen falta modificaciones en el kernel de Linux, basicamente cada usuario con derechos suficientes puede ejecutar PVM.
Announcing MO6 for BSD/OS 3.0 Oren Laadan (orenl@cs.huji.ac.il) Tue, 9 Sep 1997 19:50:12 +0300 (IDT) Hi: We are pleased to announce the availability of MO6 Version 3.0 Release 1.04 (beta-4) - compatible with BSD/OS 3.0, patch level K300-001 through M300-029. MO6 is a 6 processor version of the MOSIX multicomputer enhancements of BSD/OS for a PC Cluster. If you have 2 to 6 PC's connected by a LAN, you can experience truly multi-computing environment by using the MO6 enhancements. The MO6 Distribution -------------------- MO6 is available either in "source" or "binary" distribution. It is installed as a patch to BSD/OS, using an interactive installation script. MO6 is available at http://www.cnds.jhu.edu/mirrors/mosix/ or at our site: http://www.cs.huji.ac.il/mosix/ Main highlights of the current release: -------------------------------------- - Memory ushering (depletion prevention) by process migration. - Improved installation procedure. - Enhanced migration control. - Improved administration tools. - More user utilities. - More documentation and new man pages. - Dynamic configurations. Please send feedback and comments to mosix@cs.huji.ac.il. -------------------
La plataforma GNU/Linux para el desarrollo de posteriores versiones fue elegida en la séptima reencarnación, en 1999.
A principios de 1999 Mosix M06 fue lanzado para el kernel de Linux 2.2.1.
Entre finales de 2001 e inicios de 2002 nacía openMosix, la versión de código abierto, de forma separada.
Moshe Bar estuvo ligado al proyecto Mosix, en la Universidad Hebrea de Jerusalem, durante bastantes años. Era el co-administrador del proyecto y el principal administrador de los asuntos comerciales de Mosix company.
Tras algunas diferencias de opinión sobre el futuro comercial de Mosix, Moshe Bar empezó un nuevo proyecto de clustering alzando la empresa Qlusters, Inc. en la que el profesor A. Barak5.1 decidió no participar ya que no quería poner Mosix bajo licencia GPL.
Como había una significativa base de usuarios clientes de la tecnologia Mosix (unas 1000 instalaciones a lo ancho del planeta) Moshe Bar decidió continuar el desarrollo de Mosix pero bajo otro nombre, openMosix, totalmente bajo licencia GPL2.
openMosix es un parche (patch) para el kernel de linux que proporciona compatibilidad completa con el estardard de Linux para plataformas IA32. Actualmente se está trabajando para portarlo a IA64.
El algoritmo interno de balanceo de carga migra, transparentemente para el usuario, los procesos entre los nodos del cluster. La principal ventaja es una mejor compartición de recursos entre nodos, así como un mejor aprovechamiento de los mismos.
El cluster escoge por sí mismo la utilización óptima de los recursos que son necesarios en cada momento, y de forma automática.
Esta característica de migración transparente hace que el cluster funcione a todos los efectos como un gran sistema SMP (Symmetric Multi Processing) con varios procesadores disponibles. Su estabilidad ha sido ampliamente probada aunque todavía se está trabajando en diversas líneas para aumentar su eficiencia.
openMosix está respaldado y siendo desarrollado por personas muy competentes y respetadas en el mundo del open source, trabajando juntas en todo el mundo.
El punto fuerte de este proyecto es que intenta crear un estándar en el entorno del clustering para todo tipo de aplicaciones HPC.
openMosix tiene una página web5.2con un árbol CVS5.3y un par de listas de correo para los desarrolladores y para los usuarios.
Asume también que te encuentras convirtiendo ficheros de música desde tus CDs de audio a Ogg Vorbis para tu uso privado, cosa que resulta ser legal en tu país.
Tu compañero de habitación se encuentra trabajando en un proyecto de C++ que según dice podrá traer la paz mundial, pero en este justo momento está en el servicio cantando cosas ininteligibles, y evidentemente su computadora está a la espera de ser intervenida de nuevo.
Resulta que cuando inicias un programa de compresión, como puede ser bladeenc para convertir un preludio de Bach desde el fichero .wav al .ogg, las rutinas de openMosix en tu máquina comparan la carga de procesos en tu máquina y en la de tu compañero y deciden que es mejor migrar las tareas de compresión ya que el otro nodo es más potente debido a que el chico disponía de más medios económicos para poderse permitir una computadora más potente, a la vez que en ese momento permanece ociosa ya que no se encuentra frente a ella.
Así pues lo que normalemte en tu pentium233 tardaría varios minutos te das cuenta que ha terminado en pocos segundos.
Lo que ha ocurrido es que gran parte de la tarea ha sido ejecutada en el AMD AthlonXP de tu compañero, de forma transparente a ti.
Minutos después te encuentras escribiendo y tu compañero de habitación vuelve del servicio. Éste reanuda sus pruebas de compilación utilizando pmake, una versión del make optimizada para arquitecturas paralelas. Te das cuenta que openMosix está migrando hacia tu máquina algunos subprocesos con el fin de equilibrar la carga.
Esta configuración se llama single-pool: todas las computadoras están dispuestas como un único cluster. La ventaja o desventaja de esta disposición es que tu computadora es parte del pool: tus procesos serán ejecutados, al menos en parte, en otras computadoras, pudiendo atentar contra tu privacidad de datos. Evidentemente las tareas de los demás también podrán ser ejecutadas en la tuya.