El manual para el clustering con openMosix - Sistemas distribuidos (I)

Concepto de sistema distribuido y sistema operativo distribuido

Un sistema operativo distribuido es el encargado de cumplir lo anterior. Hay un particionado y cooperación entre todos los componentes, ninguno sobrevive solo, el propio kernel está distribuido por las máquinas. El hardware no da ninguna facilidad, es el software el que determina que un sistema sea distribuido o no. El usuario no sabe dónde se están ejecutando los procesos ni dónde están los recursos. Llevar a la práctica la idea de un kernel global distribuido es muy difícil, pues podría haber inconsistencias de datos en el kernel, además se necesita al menos el kernel mínimo para enviar y recibir información y un mecanismo robusto de comunicación y eficiente para evitar latencias demasiado elevadas.

Lo que se han desarrollado hasta ahora son los llamados sistemas operativos en red. En estos sistemas cada máquina tiene su propio kernel. Los sistemas están conectados por una red y se puede hacer remote login en ellos, en todo momento el usuario sabe donde se encuentran todos los recursos (ficheros, procesos, etc.). No es un sistema distribuido por lo que no tiene las ventajas que se verán en el siguiente apartado.

Actualmente se está caminando desde los sistemas operativos en red a los sistemas distribuidos, aunque aún no se han cumplido los objetivos de un sistema distribuido completamente tenemos ya algunos avances. Por ejemplo ya hay grandes avances en sistemas de ficheros para conseguir que exista un solo directorio raíz al igual que la existencia de una ubicación automática por parte del sistema de los ficheros. Se puede implementar un balanceo de la capacidad y redundancia en los datos para minimizar el impacto de posibles caídas de nodos.

Un cluster openMosix ya implementa una migración de procesos, que a ojos del usuario es transparente. El cluster se usa como un gran computador donde se ejecutan los procesos en todos sus nodos. La ubicación de los procesos la elige el sistema operativo o el usuario, en un intento de balancear la carga.

Necesidad de sistemas distribuidos

1. Economía: la relación precio-rendimiento es mayor que en los sistemas centralizados sobretodo cuando lo que se busca son altas prestaciones.

2. Velocidad: llega un momento en el que no se puede encontrar un sistema centralizado suficientemente potente, con los sistemas distribuidos siempre se podrá encontrar un sistema más potente uniendo más nodos. Se han hecho comparativas y los sistemas distribuidos especializados en cómputo han ganado a los mayores mainframes.

3. Distribución de máquinas: podemos tener unas máquinas inherentemente distribuidas por el tipo de trabajo que realizan.

4. Alta disponibilidad: cuando una máquina falla no tiene que caer todo el sistema sino que este se recupera de las caídas y sigue funcionando con quizás algo menos de velocidad.

5. Escalabilidad: puede empezarse un cluster con unas pocas máquinas y según la carga aumenta, añadir más nodos. No hace falta tirar las máquinas antiguas ni inversiones iniciales elevadas para tener máquinas suficientemente potentes.

   Figura: Sistemas distribuidos. Escalabilidad de servicios en una empresa

6. Comunicación: los ordenadores necesariamente estarán comunicados, para el correcto y eficaz funcionamiento del cluster se crean unas nuevas funcionalidades avanzadas de comunicación. Estas nuevas primitivas de comunicación pueden ser usadas por los programas y por los usuarios para mejorar sus comunicaciones con otras máquinas.

7. Sistema de ficheros con raíz única: este sistema de ficheros hace que la administración sea más sencilla (no hay que administrar varios discos independientemente) y deja a cargo del sistema varias de las tareas.

8. Capacidad de comunicación de procesos y de intercambio de datos universal: permite enviar señales a cualquier proceso del cluster, asimismo permite trabajar conjuntamente con cualquier proceso e intercambiar datos. Por lo tanto será posible tener todos los procesos trabajando en un mismo trabajo.

Desventajas: el problema de la transparencia

• 4.- Alta disponibilidad: podemos conseguir alta disponibilidad pues al tener varios nodos independientes, hay muchas menos posibilidades de que caigan todos a la vez. Pero esto por sí sólo no nos da alta disponibilidad. Tenemos que implantar los mecanismos necesarios para que cuando una máquina caiga, se sigan dando todos los servicios.

  Normalmente se apuesta por la replicación de información. Si tenemos 3 servidores de ficheros, sirviendo los mismos ficheros, si uno de ellos cae podemos seguir obteniendo el servicio de alguno de los otros servidores (en el peor de los casis el servicio quizás se ralentice).

  Este caso además ilustra otro problema que es la necesidad de actualizar todas las réplicas de un servicio: si un nodo escribe en uno de los servidores éste debe mandar los nuevos datos a los otros servidores para mantenerlos todos coherentes. De otro modo al caer uno de estos servidores perderíamos toda la información que hubiéramos ido grabando en este servidor y no en el resto.

  También se tiene que disponer de los mecanismos adecuados para que el nodo que ve el fallo del servidor busque los servidores alternativos en busca de la información que necesita. Además también se debe disponer de los mecanismos necesarios para que los nodos que han caído, cuando vuelvan a conectarse al cluster puedan continuar con su trabajo normalmente.

• 5.- Escalabilidad: el problema es que más nodos suele implicar más comunicación, por lo que tenemos que diseñar un sistema lo más escalable posible. Por ejemplo elegir una comunicación todos con todos aunque tenga ciertas ventajas no es una solución en absoluto escalable pues cada nuevo nodo tiene que comunicarse con todos los demás, lo que hace que incluir un nodo no sea lineal.

  Una solución para este problema son los clusters jerárquicos propuestos por Stephen Tweedie: clusters divididos en niveles. Un cluster como lo conocemos es un cluster de primer nivel, los nodos forman una lista de miembros. Hay un nodo privilegiado llamado líder. Para hacer clústeres más grandes se juntan todos los líderes en un metacluster. Se crean entonces dos listas, una de ellas contiene todos los nodos llamada subcluster membership y la otra contiene únicamente los líderes llamada metacluster membership. Si se cambia de líder se cambia también en el metacluster. Así podemos agrupar líderes de metaclusters en un cluster de tercer nivel, etc.

  Esta disposición evita transiciones de todo el cluster, pues si hace falta añadir un nodo y crear una transición en el cluster sólo involucramos a los nodos de esa rama. Cuando el cluster necesite recuperación habrá nodos que participen y otros que no.

• 6.- Comunicación: un cluster tiene más necesidades de comunicación que los sistemas normales por lo tanto tenemos que crear nuevos métodos de comunicación lo más eficientes posibles. Un ejemplo de esto es Heartbeat.

• 7.-Sistemas de ficheros con raíz única: tenemos que independizar los sistemas de ficheros distintos de cada uno de los nodos para crear un sistema de ficheros general. Tenemos una fácil analogía con LVM, la cual abstrae al usuario de las particiones del disco duro y le hace ver un único volumen lógico.

  Entre los problemas que nos encontramos en los sistemas de sabor UNIX se encuentran por ejemplo cómo manejar los directorios /proc y /dev. Hacer un solo directorio con ellos significaría en /proc tener PIDs independientes para cada nodo, algo que no es tan complicado de conseguir y que tiene beneficios como que cada nodo sabe a ciencia cierta y sin ningún retardo cual es el siguiente PID que tiene que asignar.

  Pero además incluye otra información como /proc/cpuinfo, /proc/meminfo, etc. que es específica del nodo y que o se modifican esos ficheros para poner la información de todos los nodos en ellos (lo cual rompería la compatibilidad con algunas aplicaciones de usuario) o poner la información en directorios distintos que tuvieran como nombre el número del nodo (lo que traería la duda de qué información colocar en /proc). Aún peor es el caso de /dev pues aquí están los dispositivos de cada nodo. Cuando los dispositivos de un nodo son totalmente distintos a los de otro no hay ningún problema (incluso poder acceder al dispositivo de otro nodo por este fichero sería perfecto) pero si todos los nodos tuvieran por ejemplo un disco duro IDE conectado en el primer slot como maestro con 3 particiones, tendríamos repetidos en cada nodo hda1, hda2 y hda3; por lo tanto tendremos que tener un nuevo esquema para nombrar los dispositivos.

• 8.-Capacidad de comunicación de procesos y de intercambio de datos universal: para conseguir este objetivo necesitamos una forma de distinguir unívocamente cada proceso del cluster. La forma más sencilla es dando a cada proceso un PID único, que llamaremos CPID (cluster process ID). Este CPID podría estar formado por el número de nodo y el número de proceso dentro de ese nodo. Una vez podemos direccionar con que proceso queremos comunicarnos, para enviar señales necesitaremos un sencillo mecanismo de comunicación y seguramente el mismo sistema operativo en el otro extremo que entienda las señales. Para compartir datos, podemos enviarlos por la red o podemos crear memoria compartida a lo largo del cluster. Sobre como crear esta memoria compartida hablaremos en el capítulo de sistemas operativos.

1. Transparencia de acceso.

   Implica tener que mantener el viejo sistema para el nuevo cluster, por ejemplo mantener un árbol de directorios usual para manejar todos los dispositivos de almacenamiento del cluster. No tenemos que romper las APIs para introducir las nuevas funcionalidades.

2. Transparencia de localización.

   A nivel más bajo tenemos que implantar una forma de conocer donde se encuentran los recursos, tradicionalmente se han usado servidores centralizados que lo sabían todo, ahora ya se va consiguie ndo que esta información se distribuya por la red.

3. Transparencia de concurrencia.

   Esto que no es excesivamente complicado en un sistema local, se ha convertido en un quebradero de cabeza en un sistema distribuido. Se han desarrollado varios métodos para conseguirlo. El mayor problema es la desincronización de los relojes pues es muy complejo que todos los relojes hardware lleven exactamente la misma temporización por tanto algunos ordenadores ven los acontecimientos como futuros o pasados respecto a otros ordenadores. Este tema se tratará con más profundidad en el capítulo de sistemas operativos.

4. Transparencia de replicación.

   Básicamente el problema es que el sistema sepa que esas réplicas están ahíy mantenerlas coherentes y sincronizadas. También tiene que activar los mecanismos necesarios cuando ocurra un error en un nodo.

5. Transparencia de fallos.

   Aunque haya fallos el sistema seguirá funcionando. Las aplicaciones y los usuarios no sabrán nada de estos fallos o intentarán ser mínimamente afectados, como mucho, el sistema funcionará más lentamente. Este punto está muy relacionado con la transparencia de replicación.

6. Transparencia de migración.

   Tenemos que solucionar problemas sobre las decisione s que tomamos para migrar un proceso, hay que tener en cuenta las políticas de migración, ubicación, etc. Además tenemos que ver otros aspectos prácticos como si al nodo que vamos encontraremos los recursos que necesitamos, etc. La aplicación no tiene que saber que fue migrada.

7. Transparencia para los usuarios.

   Implica una buena capa de software que de una apariencia similar a capas inferiores distintas.

8. Transparencia para programas.

   La más compleja. Implica que los programas no tienen porque usar llamadas al sistema nuevas para tener ventaja del cluster. Mosix hace esto muy inteligentemente tomando la natural división en procesos de los programas para migrarlos de forma transparentemente.