En un principio, los clusters son más indicados para realizar tareas que puedan descomponerse en muchas operaciones simples, y las grandes máquinas para taréas que necesiten cálculo intensivo. Para edición de video digital por ejemplo lo que prima es la velocidad de cálculo y la rapidez de intercambio de datos entre memoria y procesador, así como la velocidad de los discos. En este caso, lo que necesitamos es un procesador rápido (lo cual no significa muchos mhz, sino que sea capaz de realizar muchas operaciones por segundo, sea por velocidad de reloj, o, principalmente, por que es capaz de ejecutar varias intrucciones de código máquina en cada ciclo de reloj. Esta es la razón por la que muchas veces vemos máquinas mucho más caras y eficientes que un PC pero que funcionan a una fracción de su velocidad de reloj -un Sun Enterprise por ejemplo-) con un bus de datos (por donde se intercambian los datos entre procesador y RAM) lo más ancho posible y capaz de procesar las instrucciones en paralelo. Una máquina grande, con pocos procesadores pero muy potentes, y una cantidad descomunal de RAM -para evitar al máximo los accesos a disco- es lo que necesitamos. Un cluster de PC sería altamente ineficaz debido a la lentitud de las comunicaciones entre los procesadores de las distintas placas. Necesitamos un "fierro grande". Como servidor de archivos, la cosa cambia. Aquí lo que realmente importa es la velocidad de acceso a los archivos -notesé que digo a los archivos, no a los discos-. Si nuestro servidor tiene que servir - y valga la redundancia- una cantidad de archivos limitada pero sujetos a un acceso contínuo, lo importante es tener la cantidad de memoria suficiente para que estos archivos se carguen en un disco de RAM, y el disco duro simplemente haga de copia de respaldo. La forma más económica de conseguir esto es un cluster con varios pc de bajo coste, sin discos, arrancando todos a través de la red desde un servidor central que alojaría el sistema operativo y un par de discos en RAID 1, donde se guardarían físicamente los archivos. Con una buena SAI, y fuentes de alimentación redundantes, (y un software que hiciese un volcado a disco de los archivos en RAM cuando bajara la carga y cuando se activara la SAI) la volatilidad de los datos en RAM si surje algún problema de alimentación no sería problema. Por el contrario, si lo que tienes es accesos aleatorios a una gran cantidad de archivos, no vas a poder cargarlos todos en RAM, así que lo importante es disponer de una elevada velocidad de acceso y transferencia de datos desde el disco y la RAM: para ello lo mejor es un cluster de PC. La cantidad de RAM de cada equipo no es demasiado importante (dentro de unos límites, claro) ni la potencia del procesador, lo importante es tener discos rápidos y con los datos muy distribuidos, intentando evitar al máximo de esta forma que los accesos a disco se concentren en solo algunos discos mientras otros permanecen inactivos. Discos lo más pequeños y rápidos que encuentres, SCSI y en RAID 5 o RAID 0 y un buen sofware que reposicione los archivos en disco de forma que los más frecuentemente accedidos estén lo más repartidos posible (y si es posible, cargados en discos RAM) Pongamos un ejemplo, una web de noticias, por ejemplo de un periódico de tirada mediana (El pais, El Mundo, Clarin, etc). Páginas web que se generan dinámicamente, pero con una cantidad de procesameinto para cada petición bastante limitada, no se trata de hacer grandes cálculos sino simplemente de abrir una serie de archivos (plantilla de la página, articulo, publicidad, etc) e integrarlos en uno solo (la página web que llega a nuestro navegador) siendo la cantidad de datos que está sujeta a tráfico intensivo, bastante limitada (la edición del día, las ediciones anteriores ráramente son visitadas). Necesitamos pues, una máquina con una cantidad de ram importante, pero no exorbitada, para poder albergar el sistema operativo y las aplicaciones, así como un disco de ram donde se carguen los archivos de los contenidos que están sujetos a más tráfico (los del día, noticias importantes de días anteriores, la publicidad) y un proxy caché. 1 gb de ram podría ser suficiente o tal vez 2, pero dificilmente sería necesaria más. El procesador, habría de ser lo suficientemente potente para realizar los procesos de montaje de las páginas, teniendo en cuenta que, la velocidad de la conexión a internet es ridículamente lenta (en el caso de El País creo recordar que eran 32 mb/s -hablo de antes de hacerse de pago-) comparada con la cantidad de datos que es capaz de manejar cualquier ordenador medianamente potente a nivel de ram, y que es esta velocidad de conexión lo que marca el límite de la capacidad de proceso que vamos a necesitar. Así pues, un PC, con uno o dos procesadores y un par de GB de ram, sería más que suficiente... con el software apropiado. Un sistema operativo que consuma pocos recursos y que maneje eficentemente la RAM y las conexiones de red (por ejemplo Linux, o mejor, FreeBSD) un servidor web potente capaz de compilar los scripts que se ejecuten para el montaje de las páginas y dejarlos compilados en RAM para usos futuros (por ejemplo Apache con los correspondientes módulos y una buena configuración) una base datos ligera y rápida (MySQL) y un proxy caché eficiente (Squid) es todo lo que necesitamos. Dado que la velocidad máxima de envio de datos está limitada a 32 mb/s y, también importante, la velocidad a la que el cliente puede recibir los datos está limitada al de una conexión doméstica, las mayores ganancias las vamos a obtener en el lado del software, aligerando al máximo el contenido de las páginas, por ejemplo. Por otra parte, al margen de la velocidad de la red, de lo que se trata no es de tener un equipo capaz de realizar mucho trabajo, sino de hacer una cantidad de trabajo limitada pero hacerla bien: podemos elegir entre montar un sofware patatero en un gran equipo (ISS + ASP + SQL Server) o instalar una máquina medianamente competente y centrar nuestros esfuerzos en optimizar el software... si utilizamos software libre, podemos ajustar el software exáctamente a nuestras necesidades y obtener un rendimiento excelente con hardawre relativamente modesto. Nadie a dicho que lo segundo sea, ni más complicado, ni menos caro, dependerá de la competencia y experiencia de los administradores y desarrolladores. Veamos ahora algo más complicado, Google: páginas web que se generan dinámicamente, con una enorme cantidad de procesamiento detrás de cada una comparada con el volumen de datos que salen del servidor hacia los clientes. Aquí la velocidad de la conexion a Internet ya no es el factor que marca la velocidad de procesamiento que necesitamos. En primer lugar por que ya no estamos hablando de una conexión de 32 mb/s o similares, sino de una conexión múchisimo más rápida y en segundo lugar, por lo dicho anteriormente de la relación entre volumen de datos servido y cantidad de datos manejados para servirlos. El proceso requerido para devolver los resultados es complejo, requiere la búsqueda en varias bases de datos inmensas, la aplicación de algoritmos a esos resultados.... es un trabajo grande. Pero, todo ese proceso, se puede dividir en muchos subprocesos menores, que individualmente se pueden realizar de forma casi instantánea y, lo que es más importante, muchos de estos procesos no dependen del resultado de otros, por lo que se pueden realizar simultáneamente. Lo que hace Google es este caso es exactamente eso, desmenuzar todo el proceso en subprocesos simples y repartir el trabajo entre la mayor cantidad posible de PC. Para ello, la infrastructura de Google cuenta con varios centros de datos repartatidos desde todo el mundo (recibiremos la respuesta desde el más cercano a nosostros) y en cada uno de estos centros de datos, hay miles de PC -que ahora mismo son Pentium 3) formando un cluster (o varios clusteres, no lo recuerdo exactamente). Con ello se consigue no solamente el ahorrar en equipo, sino una redundancia total (si por ejemplo se quema un procesador, la perdida de velocidad de proceso sería de apenas 1/10.000 del total) . Ni siquiera usan discos SCSI o en RAID, sino simples discos IDE de bajo costo, no necesitan más puesto que el contenido de cada disco está duplicado en varios de ellos. En resumen ¿Que equipo es más potente? pues depende. Si lo tuyo es la edición de video, el cálculo de estructuras o algo que requiera a la vez un gran flujo de datos y una velocidad de cálculo enorme, con laaargos bucles de cálculo númerico y muchas taréas complejas que no pueden apenas dividirse en subtareas que puedan ejecutarse simultánea e independientemente, lo tuyo es un "fierro grande" gástate todo el dinero que puedas conseguir en un solo ordenador. Necesitas pocos procesadores pero muy potentes, muchísma ram y discos duros grandes y rápidos. Si lo que necesitas es simplemente servir archivos a una velocidad endiablada, lo tuyo es un cluster de PC con discos rápidos (cuanto más pequeños mejor, así la información está mejor repartida y no se sobrecargan equipos, con la capacidad de los discos actuales la cantidad de espacio de almacenamiento no es problema) y redundantes (lo ideal es RAID 5 se obtiene así redundancia y hasta un 80% de aprovechameinto del espacio) El punto flaco de los cluster, la velocidad de comunicación entre procesadores, está aquí enmascarada por la velocidad de acceso a los discos, así que no es relevante. Si lo que necesitas es manejar una enorme base de datos, un cluster con muchos PC, algunos de los cuales tendrían disco y otros no (otra vez, para la misma capacidad de almacenamiento, es más conveniente tener más discos pero más pequeños, y siempre que puedas RAID 5). Aquí lo importante es que la base de datos esté cargada en RAM y se acceda a los discos lo menos posible, pero también, una buena velocidad de proceso. Dependiendo del software, puede ser interesante el usar placas con doble procesador o no. A parte de estas dos arquitecturas, "fierro grande" y cluster también existen otras posibilidades, como es una de de varios ordenadores dedicados a la misma tarea pero independientes uno de otro, donde uno de los pc se encarga del balance de carga, es decir, asignar a los pc las tareas en funcion de su carga, si bien presenta algunas desventajas frete a los cluster en los que con el mismo hardware se pueden obtener mejores resultados.