Hoy en día se han puesto de moda los clusters, pero muchas veces no son la solución ideal. No es que los clusters sean una mala opción, es que muchas veces se utilizan en entornos donde no se deberían utilizar, por eso voy a hablar de otra tecnología que a veces puede venir bien.
Un cluster no es más que la unión de varios ordenadores para resolver una tarea. La filosofía detrás de esta idea es que se puede dividir la tarea que queremos ejecutar en tareas menores, cada ordenador del cluster procesará esa «sub-tarea» y cuando todos hayan acabado, se junta toda la información para obtener el resultado final. Esto se suele hacer en entornos científicos, entornos de diseño gráfico 3D, en bases de datos, … Como he dicho antes, los clusters se han puesto de moda y no siempre es la mejor solución, incluso se pasan por alto cosas muy importantes como:
- La conectividad: la conectividad entre los diferentes nodos es muy importante ya que los nodos van a enviarse información de uno a otro.
- Si esta conectividad tiene un ancho de banda pequeño y/o una latencia grande, la información tardará mucho en llegar. Mucha gente se fija sólo en el ancho de banda y se olvida por completo de la latencia … mal, el ancho de banda se puede arreglar, pero la latencia es para siempre.
- También hay que tener en cuenta que no vale con enchufar todos los nodos a un único switch ya que podemos encontrarnos que el ancho de banda no es el esperado. Esto se debe a que se pueden producir situaciones de bloqueo, es decir, el número de conexiones entrantes y salientes no es el mismo: unas conexiones (las que escasean) bloquean a las otras. Esto se debe a la topología que se utilice a la hora de diseñar/construir el cluster: fat-tree, hypercube, …
- No debemos utilizar una única red ya que por ella tiene que pasar mucha información: los propios datos, comandos de monitorización, peticiones al almacenamiento, … Si tenemos una única red, saturaremos dicha red con datos que posiblemente sean innecesarios. Es decir, el cuello de botella puede ser la propia red.
- El problema que se quiere resolver. Hay problemas que se pueden dividir en tareas menores independientes entre sí, pero hay otros casos en los que no es posible: procesos paralelizables (apilar cajas: una persona apila cajas a una velocidad y dos personas apilarán cajas al doble de velocidad), pero hay otros procesos que NO son paralelizables (una mujer tarde 9 meses en tener un hijo, pero 9 mujeres NO tardan un mes en tener un hijo). Sí, ya sé que no son ejemplos relacionados con la informática, pero son ejemplos que todo el mundo ha entendido ;)
- No nos debemos olvidar de la gestión del cluster: administrar 4 nodos es algo pesado, pues imaginaos si hay que administrar 4.000 nodos, cada uno con su sistema operativo, sus mensajes de log, …
Como vemos, montar y gestionar un cluster no es tan sencillo ni tan bonito como parece. Por eso os voy a hablar de otra tecnología menos utilizada que puede ser interesante: NUMA. UMA es una tecnología antigua en la que todos los procesadores comparten la misma memoria. El tiempo de acceso a la memoria es independiente de dónde se encuentre un procesador, lo mismo ocurre con los privilegios: todos los procesadores tienen el mismo «derecho» de acceder a una zona de memoria. Esta tecnología es la que conocemos todos y, en principio parece ser la correcta. Pero, hay casos en los que no todos los procesadores deberían tener el mismo «derecho» ya que a lo mejor uno está procesando más que otro y, o bien requiere una mayor velocidad o bien requiere una mayor cantidad de meoria en un determinado momento, pero otro procesador la tiene reservada. Obviamente, ni que decir tiene que como todos los procesadores además comparten el mismo bus … la escalabilidad es cuestionable.
Para solucionar esto y los casos que no resuelven los clusters, tenemos NUMA. En los sistemas con arquitectura NUMA, el tiempo de acceso y los «derechos» que tiene un procesador tiene sobre una zona de memoria dependen de dónde se encuentre el procesador y la memoria o, dicho para colegas, a qué distancia está el uno del otro. Ojo, no quiero decir distancia en metros de cables/buses sino en «hops».
En una arquitectura NUMA hay que distinguir una serie de elementos:
- memoria local: en la arquitectura NUMA nos encontramos que la memoria puede estar asociada a un procesador o no. Si hablamos de la memoria asociada a un procesador, hablamos de memoira local
- memoria remota: por eliminación, esta será la memoria no asociada a un procesador
- distancia: cuando hablamos de distancia, generalmente se hace referencia al número de hops que tiene que darse hasta llegar a un dispositivo, memoria o CPU. Cuantos más hops haya que dar … más remota será esa memoria (o dispositivo).
- nodo: este concepto ya es más complicado porque depende de cada fabricante. Podemos hablar, por norma general de nodo cuando nos referimos a un conjunto: CPU+RAM local.
Vamos a ver si lo podemos entender mejor lo ed la memoria. En un sistema UMA, toda la memoria es local ya que todos los procesadores pueden acceder a ella por igual gracias a un único bus.
En cambio, en una arquitectura NUMA, cada procesador tiene una cantidad de memoria asociada a él, cada procesador tiene un bus que le conecta con «su» memoria. Ya podemos ver la principal ventaja: no hay competición por la memoria por parte de los procesadores. Esta sería la memoria local. Además, puede haber una memoria global compartida a la que cualquier procesador puede tener acceso a ella sin distinciones, esta sería la memoria remota.
Vamos a complicar un poco más la definición de memoria remota, ¿puede un procesador pedirle a otro procesador que le deje su memoria? La respuesta es sí. Imaginémonos el procesador P1 con su memoria M1 que no está haciendo absolutamente nada. Además tenemos el procesador P2 y su memoria M2, este procesador está «asfixiado» con todo lo que tiene que hacer y tiene la memoria saturada. En este caso P2 puede pedirle a P1 permiso para usar la memoria M1. M1 sería memoria remota para P2.
La gran pregunta ahora es, ¿pero esto no es lo mismo que un cluster? No. La gran diferencia entre un cluster y un sistema NUMA es que en un sistema NUMA hay una única imagen de kernel ejecutándose (sólo hemos instalado un sistema operativo) mientras que en un cluster hay múltiples imágenes de kernel ejecutándose al mismo tiempo (hemos instalado varios sistemas operativos). O, lo que es lo mismo, en un cluster, cada nodo es una entidad propia que hay que gestionar mientras que en un sistema NUMA cada nodo es un componente de un único sistema que hay que gestionar.
La pregunta ahora es, ¿por qué/cuándo debería usar NUMA? Muy fácil: cuando quieras escalar de forma sencilla y rápida. Recordemos: escalar en un cluster no es fácil, debido principalmente a los problemas que nos supone la conectividad y la gestión del conjunto de ordenadores del cluster. En el caso de los sistemas NUMA, la complejidad de la gestión se ve reducida ya que sólo administramos un equipo, en cuanto a la conectividad, tampoco es un problema porque cada nodo tiene su memoria y en principio no utilizará la memoria remota. En caso de utilizar la memoria remota, la conectividad se hace internamente mediante buses de elevado ancho de banda y muy baja latencia.
¿Qué tiene que ver todo esto con Linux? Bueno, recordemos que NUMA es una arquitectura hardware y que necesita un sistema operativo. Luego la respuesta es que Linux sí tiene herramientas y código específico para correr en este tipo de arquitecturas. Esto, suponinedo que vamos a adquirir un sistema NUMA propietario porque también es posible montar uno «casero» con herramientas de software libre y/o distribuciones específicas como: DragonflyBSD, openSSI, Kerrighed, …
Muy importante, NUMA no es la solución a todos nuestros problemas, igual que no lo es un cluster. Hay cabida y necesidad para cada una de estas tecnologías y otras que no he mencionado ;) Y sí, trambién se puede montar un cluster con sistemas NUMA, es deicr, tener varias máquinas NUMA y montar un cluter con ellas :)
Bueno, espero haberos despertado la curiosidad por arquitecturas nuevas. Como siempre os dejo unos cuantos enlaces para que vayáis leyendo.
