El manual para el clustering con openMosix - Sistemas operativos (II)

Compartición de recursos

Problemas

Sin usar los mecanismos necesarios que controlen la ejecución, ésta es una de las trazas de lo que podría ocurrir:

Esto es lo que se llama una condición de carrera y desde que GNU/Linux funciona en máquinas SMP (a partir de la versión 2.0 ) se ha convertido en un tema principal en su implementación. Por supuesto no es un problema único de este sistema operativo sino que atañe a cualquiera con soporte multitarea. La solución pasa por encontrar estos puntos y protegerlos por ejemplo con semáforos, para que sólo uno de los procesos pueda entrar a la vez a la región crítica.

Esta es seguramente la situación más sencilla: compartición de una variable en memoria. Para aprender como solucionar éstas y otras situaciones de conflicto se recomienda al lector consultar los autores de la bibliografía.

Comunicación entre procesos

En los clusters donde los procesos tienen consciencia de si estan siendo ejecutados locales o remotos, cada nodo tiene las primitivas de comunicación necesarias para enviar toda la comunicación a través de la red. En clusters donde solo el kernel puede conocer este estado de los procesos, estas primitivas se hacen innecesarias pues la transparencia suple esta capa. Éste es el caso de openMosix.

Hay mecanismos de comunicación más problemáticos que otros. Las señales no lo son demasiado pues se pueden encapsular en un paquete qué se envíe a través de la red. Aquí se hace necesario que el sistema sepa en todo momento el nodo dónde está el proceso con el que quiere comunicar.

Otros mecanismos de comunicación entre procesos son más complejos de implementar. Por ejemplo la memoria compartida: se necesita tener memoria distribuida y poder/saber compartirla. Los sockets también son candidatos difíciles a migrar por la relación que tienen los servidores con el nodo.

La importancia de los sistemas de ficheros

El sistema de ficheros tradicional tiene como funciones la organización, almacenaje, recuperación, protección, nombrado y compartición de ficheros. Para conseguir nombrar los ficheros se usan los directorios, que no son más que un fichero de un tipo especial que provee una relación entre los nombre que ven los usuarios y un formato interno del sistema de ficheros.

Un sistema de ficheros distribuido es tan importante para un sistema distribuido como para uno tradicional: debe mantener las funciones del sistema de ficheros tradicional, por lo tanto los programas deben ser capaces de acceder a ficheros remotos sin copiarlos a sus discos duros locales. También proveer acceso a ficheros en los nodos que no tengan disco duro. Normalmente el sistema de ficheros distribuido es una de las primeras funcionalidades que se intentan implementar y es de las más utilizadas por lo que su buena funcionalidad y rendimiento son críticas. Se pueden diseñar los sistemas de ficheros para que cumplan los criterios de transparencia, esto es:

• Transparencia de acceso: los programas no tienen por qué saber como están distribuidos los ficheros. Se deben usar las mismas instrucciones para acceder a los fichero locales o remotos por lo tanto los programas escritos para usar ficheros locales podrán usar ficheros remotos sin ninguna modificación.

• Transparencia de localización: los programas deben ver un espacio de nombres de ficheros uniforme, los ficheros o grupos de ficheros podrían ser cambiados de lugar sin que cambien su path ni sus nombres. El programa podrá ser ejecutado en cualquier nodo y verá el mismo espacio de nombres.

• Transparencia de concurrencia: los cambios a un fichero ocasionados por un cliente no deberían interferir con las operaciones de otros clientes que estén simultáneamente accediendo o cambiando el mismo fichero.

• Transparencia a fallos: se debe conseguir una operación correcta tanto si falla el cliente como el servidor, haya perdida de mensajes o interrupciones temporales.

• Transparencia de réplica: un fichero podría estar representado por varias copias de sus contenidos en lugares diferentes. Esto tiene varias ventajas, permite a muchos servidores compartir la carga si un número de clientes están accediendo al mismo conjunto de ficheros aumentando la escalabilidad, permite tener copias en cache, más cercanas al lugar donde se están utilizando, aumentando el rendimiento y permitiendo a los clientes seguir accediendo a los ficheros aunque alguno de los servidores haya tenido algún error aumentando la tolerancia a fallos.

• Transparencia de migración: de todo lo anterior se concluye que un proceso o un fichero puede migrar en el sistema sin tener que preocuparse por un nuevo path relativo.

• NFS, Network File System.

• MFS, Mosix File System. Necesario en openMosix para proveer de acceso directo al FS y mantener consistencias de cache.

• GFS. Es un sistema de ficheros para discos compartidos.

• NFS

  Es uno de los primeros sistemas de archivos de red, fue creado por Sun basado en otra obra de la misma casa, RPC y parte en XDR para que pudiese implementarse en sistemas hetereogéneos. El modelo NFS cumple varias de las transparencias mencionadas anteriormente de manera parcial. A este modelo se le han puesto muchas pegas desde su creación, tanto a su eficiencia como a su protocolo, como a la seguridad de las máquinas servidoras de NFS.

  El modelo de NFS es simple: máquinas servidoras que exportan directorios y máquinas clientes^3.3 que montan este directorio dentro de su árbol de directorio y al que se accederá de manera remota.

  De esta manera el cliente hace una llamada a mount especificando el servidor de NFS al que quiere acceder, el directorio a importar del servidor y el punto de anclaje dentro de su árbol de directorios donde desea importar el directorio remoto. Mediante el protocolo utilizado por NFS^3.4 el cliente solicita al servidor el directorio exportable (el servidor en ningún momento sabe nada acerca de dónde esta montado el sistema en el cliente), el servidor en caso de que sea posible la operación, concede a el cliente un handler o manejador del archivo, dicho manejador contiene campos que identifican a este directorio exportado de forma única por un i-node, de manera que las llamadas a lectura o escritura utilizan esta información para localizar el archivo.

  Una vez montado el directorio remoto, se accede a él como si se tratase del sistema de archivos propio, es por esto que en muchos casos los clientes montan directorios NFS en el momento de arranque ya sea mediante scripts rc o mediante opciones en el fichero /etc/fstab. De hecho existen opciones de automount para montar el directorio cuando se tenga acceso al servidor y no antes, para evitar errores o tiempos de espera innecesarios en la secuencia de arranque.

  NFS soporta la mayoría de las llamadas a sistema habituales sobre los sistemas de ficheros locales así como el sistema de permisos habituales en los sistemas UNIX. Las llamadas open y close no están implementadas debido al diseño de NFS. El servidor NFS no guarda en ningún momento el estado de las conexiones establecidas a sus archivos ^3.5, en lugar de la función open o close tiene una función lookup que no copia información en partes internas del sistema. Esto supone la desventaja de no tener un sistema de bloqueo en el propio NFS, aunque esto se ha subsanado con el demonio rpc.lockd lo que implicaba que podían darse situaciones en las cuales varios clientes estuviesen produciendo inconsistencias en los archivos remotos. Por otro lado, el no tener el estado de las conexiones, implica que si el cliente cae, no se produce ninguna alteración en los servidores.

  Figura: Sistemas operativos. NFS

  
  
  La implementación de NFS de manera general es la siguiente. Se efectúa una llamada al sistema del tipo open(), read(), close() después de analizar la llamada, el sistema pasa ésta al VFS que se encarga de gestionar los archivos abiertos mediante tablas de v-nodes. Estos v-nodes apuntan a archivos de varios tipos, locales, remotos, de varios sistemas de archivos, y especifican a su vez que operaciones deben hacer en cada caso.

  De esta manera para el caso de NFS, VFS guarda en el v-node un apuntador al nodo remoto en el sistema servidor,que define a la ruta del directorio compartido y a partir de este todos son marcados como v-nodes que apuntan a r-nodes o nodos remotos.

  En el caso de una llamada open() a un archivo que se encuentra en parte de la jerarquía donde está un directorio importado de un servidor NFS, al hacer la llamada, en algún momento de la comprobación de la ruta en el VFS, se llegara al v-node del archivo y se verá que este corresponde a una conexión NFS, procediendo a la solicitud de dicho archivo mediante opciones de lectura, se ejecuta el código especificad o por VFS para las opciones de lectura de NFS.

  En cuanto al manejo de las caches que se suelen implementar en los clientes depende de cada caso específico. Se suelen utilizar paquetes de 8KB en las transferencias de los archivos, de modo que para las operaciones de lectura y escritura se espera a que estos 8KB estén llenos antes de enviar nada, salvo en el caso de que se cierre el archivo. Cada implementación establece un mecanismo simple de timeouts para las caches de los clientes de modo que se evite un poco el trafico de la red.

  La cache no es consistente, los ficheros pequeños se llaman en una cache distinta a esos 8KB y cuando un cliente accede a un fichero al que accedió poco tiempo atrás y aún se mantiene en esas caches, se accede a esas caches en vez de la versión del servidor. Esto hace que en el caso de ficheros que no hayan sido actualizados se gane el tiempo que se tarda en llegar hasta el servidor y se ahorre tráfico en la red. El problema es que produce inconsistencias en la memoria cache puesto que si otro ordenador modificó esos ficheros, nuestro ordenador no va a ver los datos modificados sino que leerá la copia local.

  Esto puede crear muchos problemas y es uno de los puntos que más se le discute a NFS, este problema es el que ha llevado a desarrollar MFS pues se necesitaba un sistema que mantuviera consistencia de caches.

• MFS.

  Este es el sistema de ficheros que se desarrolló para openMosix en espera de alguno mejor para poder hacer uso de una de sus técnicas de balanceo, DFSA. Este sistema funciona sobre los sistemas de ficheros locales y permite el acceso desde los demás nodos.

  Cuando se instala, se dispone de un nuevo directorio que tendrá varios subdirectorios con los números de los nodos, en cada uno de esos subdirectorios se tiene todo sistema de ficheros del nodo en cuestión^3.6. Esto hace que este sistema de ficheros sea genérico pues /usr/src/linux/ podría estar montado sobre cualquier sistema de ficheros; y escalable, pues cada nodo puede ser potencialmente servidor y cliente.

  A diferencia de NFS provee una consistencia de cache entre procesos que están ejecutándose en nodos diferentes, esto se consigue manteniendo una sola cache en el servidor. Las caches de GNU/Linux de disco y directorio son sólo usadas en el servidor y no en los clientes. Así se mantiene simple y escalable a cualquier número de procesos.

  El problema es una pérdida de rendimiento por la eliminación de las caches, sobre todo con tamaños de bloques pequeños. La interacción entre el cliente y el servidor suele ser a nivel de llamadas del sistema lo que suele ser bueno para la mayoría de las operaciones de entrada/salida complejas y grandes.

  Este sistema cumple con los criterios de transparencia de acceso, no cumple con los demás. Tiene transparencia de acceso pues se puede acceder a estos ficheros con las mismas operaciones que a los ficheros locales. Los datos del cuadro 3.3 son del Postmark^3.7 benchmark que simula grandes cargas al sistema de ficheros, sobre GNU/Linux 2.2.16 y dos PCs Pentium 550 MHz^3.8:
  

  Tabla: Sistemas Operativos. MFS

  Método de acceso 64 512 1K 2K 4K 8K 16K Local 102.6 102.1 100.0 102.2 100.2 100.2 101.0 MFS con DFSA 104.8 104.0 103.9 104.0 104.9 105.5 104.4 MFS sin DFSA 1711.0 169.1 158.0 161.3 156.0 159.5 157.5 NFS 184.3 169.1 158.0 161.3 156.0 159.5 157.5

  
  

• GFS:

  Se basa en que las nuevas tecnologías de redes (como fibra óptica) permiten a muchas máquinas compartir los dispositivos de almacenamiento. Los sistemas de ficheros para acceder a los ficheros de estos dispositivos se llaman sistemas de ficheros de dispositivos compartidos. Contrastan con los sistemas de ficheros distribuidos tradicionales donde el servidor controla los dispositivos (físicamente unidos a él). El sistema parece ser local a cada nodo y GFS sincroniza los acceso a los ficheros a través del cluster. Existen dos modos de funcionamiento, uno con un servidor central (asimétrico) y otro sin él (simétrico).

  En el modo que necesita servidor central, éste tiene el control sobre los metadatos (que es un directorio donde están situados fechas de actualización, permisos, etc.), los discos duros compartidos solamente contienen los datos. Por tanto todo pasa por el servidor, que es quien provee la sincronización entre clientes, pues estos hacen las peticiones de modificación de metadata al servidor (abrir, cerrar, borrar, etc.) y leen los datos de los discos duros compartidos, es similar a un sistema de ficheros distribuido corriente. En la figura 3.2 se muestra una configuración típica de este sistema:

Figura: Sistemas operativos. GFS con servidor central

Figura: Sistemas operativos. SAN

• Cada cliente puede acceder a cualquier parte de los datos (cualquier disco), por lo tanto se facilita la migración de procesos pues ya no hay que tener en cuenta si llevar con el proceso los ficheros abiertos o no y no hay que dejar en el nodo origen información sobre ficheros abiertos.

• Usando técnicas de LVM (Logic Volume Management) se pueden unir varios de los discos duros en uno solo, simplificando el control de los dispositivos de almacenamiento y reduciendo la complejidad de la administración.

• Aumenta la escalabilidad en capacidad, conectividad y ancho de banda con respecto a otros sistemas como NFS que están basados en servidores centrales.

• Es un sistema de ficheros journaled, un espacio journaled para cada cliente para evitar que sea tan ineficiente, además se envía la información por grupos y se intenta mejorar el I/O clustering, y tiene capacidad de una recuperación rápida de los fallos de los clientes, gracias a los distintos espacios journaled, sólo los tiene que reparar secuencialmente , no importa que caigan gran número de nodos. No se pierde información.

• Requiere hardware muy caro, fibra óptica, switch/hub de alta velocidad, SCSI (normalmente RAID SCSI)

Este sistema de ficheros cumple todas las transparencias explicadas al principio de la lección, en el caso de haber un servidor central este es el que no cumple los criterios de transparencia pero en la parte de los clientes si los cumple pues no saben dónde están los ficheros (transparencia de acceso), se podrían cambiar de disco duro sin problema (transparencia de localización), si un nodo falla el sistema se recupera (transparencia a fallos), varios clientes pueden acceder al mismo fichero (transparencia de concurrencia) y se mantienen caches en los clientes (transparencia de réplica).

Entrada salida

Por ejemplo es típico en las empresas comprar una única impresora cara para obtener la mejor calidad posible y dejar que esa impresora sea accedida desde cualquier ordenador de la intranet de la empresa, aunque esto significa el desplazamiento físico de los empleados. Puede ser un ahorro considerable a instalar una impresora en cada uno de los ordenadores.

El problema es que para este ejemplo se ha desarrollado una solución específica que necesita un demonio escuchando peticiones en un determinado puerto. Desarrollar una solución general es mucho más complejo y quizás incluso no deseable. Para que cualquier nodo pueda acceder a cualquier recurso de entrada/salida, primero se necesita una sincronización que como ya se ha visto en una sección anterior de este capítulo puede llegar a ser complejo. Pero también se necesita conocer los recursos de entrada/salida de los que se dispone, una forma de nombrarlos de forma única a través del cluster, etc.

Para el caso concreto de migración de procesos el acceso a entrada/salida puede evitar que un proceso en concreto migre, o más convenientemente los procesos deberían migrar al nodo donde estén realizando toda su entrada/salida para evitar que todos los datos a los que están accediendo tengan que viajar por la red. Así por ejemplo un proceso en openMosix que esté muy vinculado al hardware de entrada/salida no migrará nunca (Xwindow, lpd, etc.). Los sockets como caso especial de entrada/salida también plantean muchos problemas porque hay servicios que están escuchando un determinado puerto en un determinado ordenador para los que migrar sería catastrófico pues no se encontrarían los servicios disponibles para los ordenadores que accedieran a ese nodo en busca del servicio.