Subsecciones

- Introducción
- 3.1.1 Procesos y Scheduling
  - 3.1.1.1 Utilidad de migrar procesos
  - 3.1.1.2 Política de localización
  - 3.1.1.3 Política de migración
  - 3.1.1.4 Política de ubicación
  - 3.1.1.5 Parte de los procesos a migrar
  - 3.1.1.6 Mecanismos de migración
- 3.1.2 Compartición de recursos
  - Problemas
- 3.1.3 Comunicación entre procesos
- 3.1.4 La importancia de los sistemas de ficheros
- 3.1.5 Entrada salida

# 3.1 SISTEMAS OPERATIVOS

## Introducción

Los ordenadores se están convirtiendo en una plataforma cada vez más abierta y los sistemas operativos tienen que dar los servicios necesarios para que esto pueda gestionarse de manera adecuada. Dando un breve repaso a la historia de los sistemas operativos puede verse que cada vez tienen más posibilidades de comunicación.

Cuando se construyeron las primeras redes de computadores se vio la potencia que tenían estos sistemas y se desarrolló el paradigma cliente/servidor. Se crearon los sistemas operativos de red con servicios como NFS o FTP para acceder a sistemas de ficheros de otros ordenadores. `Xwindow` para entorno gráfico, `lpd` para poder imprimir remotamente además de un conjunto de herramientas que permitían el acceso a recursos compartidos.

En los aurales de la informática el sistema operativo ni siquiera existía: se programaba directamente el hardware. Se vio que era muy pesado y se programó una capa de abstracción que evitaba al programa tener que tener un conocimiento total del hardware: el sistema operativo. Se descubrió también que con un solo proceso se desperdiciaba tiempo de procesador y como tales dispositivos eran carísimos se empezaron a inventar mecanismos que evitasen que el programa esperase bloqueado por ejemplo las operaciones de entrada/salida. Se llegó a la multiprogramación en el ambicioso MULTICS y el posterior UNIX. Estos dos sistemas se desarrollaron a finales de los años 60 y se basaban en el MIT Compatible Timesharing System realizado en 1958.

En los años 70 se añadieron las primeras capacidades de interconexión:

- Xerox inventó la red Ethernet
- IBM la Token Ring
- y surgió UNIX BSD 4.2

Este sistema operativo fue ampliamente usado porque integraba capacidades de comunicación: implementaba TCP/IP y tenía capacidades de intercomunicación entre procesos.

Un sistema operativo distribuido puede acceder a cualquier recurso transparentemente y tiene grandes ventajas sobre un sistema operativo de red. Pero es muy difícil de implementar y algunos de sus aspectos necesitan que se modifique seriamente el núcleo del sistema operativo, por ejemplo para conseguir memoria distribuida transparente a los procesos. También se tiene que tener en cuenta que ahora la máquina sobre la que corre todo el sistema es el sistema distribuido (un conjunto de nodos) por lo que tareas como planificación de procesos (scheduling) o los hilos ( threads) y señales entre procesos toman una nueva dimensión de complejidad. Por todo esto aún no existe ningún sistema distribuido con todas las características de transparencia necesarias para considerarlo eficiente.

A partir de ahora no hablaremos de computadores, ordenadores ni PC. Cualquier dispositivo que se pueda conectar a nuestro sistema y donde se pueda desarrollar un trabajo útil para el sistema se referenciará como nodo. El sistema operativo tiene que controlar todos estos nodos y permitir que se comuniquen eficientemente.

Aunque tras leer este capítulo el lector podrá intuir esta idea, queremos hacer notar que un sistema distribuido se puede ver como el siguiente nivel de abstracción sobre los sistemas operativos actuales. Como hemos visto la tendencia es a dar más servicios de red y más concurrencia. Si pusiéramos otra capa por encima que aunara ambos, esta capa sería el sistema operativo distribuido. Esta capa debe cumplir los criterios de transparencia que veremos en el próximo apartado.

Podemos comprender esto mejor haciendo una analogía con el SMP: cuando sólo existe un procesador todos los procesos se ejecutan en él, tienen acceso a los recursos para los que tengan permisos, se usa la memoria a la que puede acceder el procesador, etc. Cuando hay varios procesadores todos ellos están corriendo procesos (si hay suficientes para todos) y los procesos migran entre procesadores.

En un sistema multiprocesador al igual que un sistema multicomputador hay una penalización si el proceso tiene que correr en un elemento de proceso (procesador o nodo) distinto al anterior: en multiprocesador por la contaminación de cache y TLB; en multicomputador por la latencia de la migración y pérdidas de cache. En un sistema multicomputador se persigue la misma transparencia que un sistema operativo con soporte multiprocesador, esto es, que no se deje ver a las aplicaciones que realmente están funcionando en varios procesadores.

En este capítulo además se tratarán las zonas de un sistema operativo que se ven más afectadas para conseguirlo. Éstas son:

- Scheduling.

  El scheduling de los procesos ahora puede ser realizado por cada nodo de manera individual, o mediante algún mecanismo que implemente el cluster de manera conjunta entre todos los nodos.

- Deadlocks.

  Las técnicas usadas hasta ahora en un nodo local no se pueden generalizar de una forma eficiente en el sistema distribuido.

- Manejo de memoria.

  Hay que disponer de memoria distribuida: poder alojar y desalojar memoria de otros nodos de una forma transparente a las aplicaciones.

- Intercomunicación de procesos.

  Los procesos podrían estar ubicados en cualquier nodo del sistema. Se deben proveer de los mecanismos necesarios para permitir esta intercomunicación de tipo señales, memoria distribuida por el cluster u otros.

- Sistemas de ficheros.

  Pretenden que todo el sistema distribuido tenga la misma raíz para que no sea necesario explicitar en qué nodo se encuentra la información.

- Entrada/salida.

  Tendría que ser posible acceder a todos los recursos de entrada/salida globalmente, sin tener que indicar explícitamente a que nodo están estos recursos conectados.

## 3.1.1 Procesos y Scheduling

### 3.1.1.1 Utilidad de migrar procesos

La migración de un proceso consiste en mover el proceso desdel nodo donde se está ejecutando a un nuevo entorno. Aunque no se suela emplear en este caso, se podría hablar de migración cuando un proceso se mueve de procesador. Aquí consideraremos migración cuando un proceso se mueve de un nodo a otro.

En un sistema de tipo cluster lo que se pretende, como se verá en el capítulo Clusters, es compartir aquellos dispositivos (a partir de ahora serán los recursos) conectados a cualquiera de los nodos. Uno de los recursos que más se desearía compartir, aparte del almacenamiento de datos, es el procesador de cada nodo. Para compartir el procesador entre varios nodos lo más lógico es permitir que las unidades atómicas de ejecución del sistema operativo (procesos, con PID propio) sean capaces de ocupar en cualquier momento cualesquiera de los nodos que conforman el cluster.

En un sistema multiusuario de tiempo compartido la elección de qué proceso se ejecuta en un intervalo de tiempo determinado la hace un segmento de código que recibe el nombre de scheduler, el planificador de procesos. Una vez que el scheduler se encarga de localizar un proceso con las características adecuadas para comenzar su ejecución, es otra sección de código llamada dispatcher la que se encarga de substituir el contexto de ejecución en el que se encuentre el procesador, por el contexto del proceso que queremos correr. Las cosas se pueden complicar cuando tratamos de ver este esquema en un multicomputador. En un cluster, se pueden tener varios esquemas de actuación.

- Scheduling conjunto. En el cual todos los nodos del cluster hacen la elección de los procesos que se ejecutaran en el cluster y quizá incluso en cada nodo. Esto requiere una actuación conjunta de todos los nodos, lo que implica que el scheduling podría ser:
  - Centralizado: una o varias máquinas trabajando para efectuar las tareas de scheduler y organizar el resto del cluster. Es sencillo de implementar, pero tiene más inconvenientes que ventajas, aparte que los inconvenientes son de mucho peso y muy obvios.
  - Distribuido: requieren un modelo matemático adecuado y una implementación más complicada.

- Scheduling individual: cada nodo actúa de la manera comentada en sistemas individuales, pero añade la acción de migrar procesos a otros nodos, de manera que se optimice tiempo de ejecución global en el cluster. Para esto, los nodos comparan la carga de otros nodos y deciden cúal de los procesos que tienen en la cola de espera para ser ejecutados es el óptimo para ser enviado a otro nodo.

Conforme se avance en este manual se verá cuál puede convenir más para cada caso. Otra de las políticas que puede variar del scheduling en un ordenador individual a un cluster es la de diseminación de la información de los nodos. A la hora de elegir sobre qué nodo migrar un proceso, tanto en el scheduling conjunto como en el individual, se debe conocer la información de los nodos para balancear convenientemente el sistema. Esta diseminación puede estar basada en:

- Información global.
- Información parcial.

De estos dos, el primero no es muy escalable, pero probablemente sea más adecuado en ciertas condiciones. Lo más habitual es que un cluster deje las decisiones sobre cuándo ejecutar cada proceso a cada nodo particular, por tanto la principal novedad en un sistema distribuido es que hay que permitir que los procesos se ejecuten en cualquier computador no necesariamente en el que se crearon. Y transparentemente a los mismos procesos. Este ha sido un tema estudiado numerosas veces, con todo tipo de conclusiones, seguramente la más sorprendente es la de Tanenbaum3.1. Se equivocó (una vez más) porque openMosix ha conseguido la migración en la práctica. Esta migración de procesos tiene varias ventajas, como son:

- Compartición de carga: los procesos se trasladarán a la máquina con menos carga para evitar que haya sistemas sobrecargados. También se tiene en cuenta cuándo se está acabando la memoria de la máquina. En definitiva los procesos van donde tengan más recursos. En el caso óptimo se tendría la potencia de todas las máquinas sumadas, pues con un balanceo perfecto podrían tenerse a todos los nodos trabajando a máximo rendimiento, aunque el trabajo original se produjese en un nodo solo.

  Por supuesto este este es el caso ideal y no se puede dar en la realidad pues siempre se necesita potencia de cálculo para enviar y recibir los procesos así como para tomar las decisiones (overhead).

- Rendimiento de las comunicaciones: los procesos que necesitan entrada/salida en un nodo se desplazan a éste para evitar traer todos los datos a través de la red. Otra variante es mantener a todos los procesos que interactúan fuertemente entre ellos en una misma máquina.

Las principales decisiones que se deben tomar en un sistema distribuido para hacer esta migración eficiente las podemos englobar en tres políticas distintas:

- Políticas de localización
- Políticas de migración
- Políticas de ubicación

A parte de estas políticas también hay que hacer otras consideraciones que no tienen que ver con las decisiones que se toman sino cómo van a ser implementadas en la práctica, estas son:

- Parte del proceso a migrar
- Mecanismos de migración

### 3.1.1.2 Política de localización

Cubre las decisiones referentes a desde dónde se lanzaran los procesos.

Este tipo de planteamiento sólo se efectúa en los sistemas SSI de los que se hablará más tarde, ya que necesita un acoplamiento muy fuerte entre los nodos del cluster. Un ejemplo puede ser el requerimiento de un cluster que dependiendo del usuario o grupo de usuario elija un nodo preferente donde ejecutarse por defecto. En openMosix no se hace uso de esta política, ya que el sistema no está tan acoplado como para hacer que otro nodo arranque un programa.

### 3.1.1.3 Política de migración

La política de migración plantea las decisiones que hay que hacer para responder a preguntas, a saber:

- ¿cuándo se inicia la migración?
- ¿quién inicia la migración?

Para saber cuándo se debe realizar una migración nuestro nodo debe estar en contacto con los demás nodos y recolectar información sobre su estado y así, y teniendo en cuenta otros parámetros como la carga de la red, se debe hacer una decisión lo más inteligente posible y decidir si es momento de migrar y qué es lo que se migra.

Las causas que hacen que se quiera realizar la migración van a depender del objetivo del servicio de la migración. Así si el objetivo es maximizar el tiempo usado de procesador, lo que hará que un proceso migre es el requerimiento de procesador en su nodo local, así gracias a la información que ha recogido de los demás nodos decidirá si los merece la pena migrar o en cambio los demás nodos están sobrecargados también.

La migración podría estar controlada por un organismo central que tuviera toda la información de todos los nodos actualizada y se dedicase a decidir como colocar los procesos de los distintos nodos para mejorar el rendimiento. Esta solución aparte de ser poco escalable, pues se sobrecargan mucho la red de las comunicaciones y uno de los equipos, es demasiado centralizada ya que si este sistema falla se dejarán de migrar los procesos.

El otro mecanismo es una toma de decisiones distribuida: cada nodo tomará sus propias decisiones usando su política de migración. Dentro de esta aproximación hay dos entidades que pueden decidir cuando migrar un proceso: el propio proceso o el kernel del sistema operativo.

- Si el proceso es quien va a decidirlo hay el problema de que él tiene que ser consciente de la existencia de un sistema distribuido.
- En cambio si es el kernel quien decide, la función de migración y la existencia de un sistema distribuido pueden ser transparentes al proceso.

Esta última es la política que usa openMosix.

### 3.1.1.4 Política de ubicación

Encontrar el mejor nodo donde mandar un proceso que está sobrecargando el nodo de ejecución no es una estrategia fácil de implementar. Entran en juego una gran amplia gama de algoritmos generalmente basados en las funcionalidades o recursos a compartir del cluster, y dependiendo de cuáles sean estos, se implantarán unas medidas u otras. El problema no es nuevo y puede ser tratado como un problema de optimización normal y corriente, pero con una severa limitación. A pesar de ser un problema de optimización se debe tener en cuenta que este código va a ser código de kernel, por lo tanto y suponiendo que está bien programado, el tiempo de ejecución del algoritmo es crucial para el rendimiento global del sistema. ¿De qué sirve optimizar un problema de ubicación de un proceso que va a tardar tres segundos en ejecutarse, si dedicamos uno a decidir donde colocarlo de manera óptima y además sin dejar interactuar al usuario?

Este problema penaliza a ciertos algoritmos de optimización de nueva generación como las redes neuronales, o los algoritmos genéticos y beneficia a estimaciones estadísticas.

### 3.1.1.5 Parte de los procesos a migrar

Una vez se sabe cuándo, de dónde y hacia dónde migrará el proceso, falta saber qué parte del proceso se va a migrar. Hay dos aproximaciones:

1. Migrar todo el proceso.

   Implica destruirlo en el sistema de origen y crearlo en el sistema de destino. Se debe mover la imagen del proceso que consta de, por lo menos, el bloque de control del proceso (a nivel del kernel del sistema operativo). Además, debe actualizarse cualquier enlace entre éste y otros procesos, como los de paso de mensajes y señales (responsabilidad del sistema operativo). La transferencia del proceso de una máquina a otra es invisible al proceso que emigra y a sus asociados en la comunicación.

   El movimiento del bloque de control del proceso es sencillo. Desde el punto de vista del rendimiento, la dificultad estriba en el espacio de direcciones del proceso y en los recursos que tenga asignados. Considérese primero el espacio de direcciones y supóngase que se está utilizando un esquema de memoria virtual (segmentación y/o paginación). Pueden sugerirse dos estrategias:

   - Transferir todo el espacio de direcciones en el momento de la migración. No hace falta dejar rastro del proceso en el sistema anterior. Sin embargo si el espacio de direcciones es muy grande y si es probable que el proceso no necesite la mayor parte, este procedimiento puede ser costoso.
   - Transferir sólo aquella parte del espacio de direcciones que reside en memoria principal. Cualquier bloque adicional del espacio de direcciones virtuales será transferido sólo bajo demanda. Esto minimiza la cantidad de datos que se transfieren. Sin embargo, se necesita que la máquina de origen siga involucrada en la vida del proceso, pues mantiene parte de su espacio de direcciones, nótese que este sistema no tiene nada que ver con el anterior, pues el sistema de origen es un mero almacenador de información.

     También es una estrategia obligada cuando lo que se migran son hilos en vez de procesos y no migramos todos los hilos de una vez. Esto está implementado en el sistema operativo Emerald3.2 y otras generalizaciones de este a nivel de usuario.

2. Migrar una parte del proceso.

   En este sistema:

   - el contexto del nivel de usuario del proceso es llamado remote: contiene el código del programa, la pila, los datos, el mapeo de la memoria y los registros del proceso. El remote encapsula el proceso cuando éste está corriendo en el nivel de usuario.
   - El contexto del kernel es llamado deputy: contiene la descripción de los recursos a los cuales el proceso está unido, y la pila del kernel para la ejecución del código del sistema cuando lo pida el proceso.

     Mantiene la parte del contexto del sistema que depende del lugar por lo que se mantiene en el nodo donde se generó el proceso.

   Como en Linux la interfície entre el contexto del usuario y el contexto del kernel está bien definida, es posible interceptar cada interacción entre estos contextos y enviar esta interacción a través de la red. Esto está implementado en el nivel de enlace con un canal especial de comunicación para la interacción.

   El tiempo de migración tiene una componente fija que es crear el nuevo proceso en el nodo al que se haya decidido migrar; y una componente lineal proporcional al número de páginas de memoria que se vayan a transferir. Para minimizar la sobrecarga de esta migración, de todas las páginas que tiene mapeadas el proceso sólo se van a enviar las tablas de páginas y las páginas en las que se haya escrito.

   OpenMosix consigue transparencia de localización gracias a que las llamadas dependientes al nodo nativo que realiza el proceso que ha migrado se envían a través de la red al deputy. Así openMosix intercepta todas las llamadas al sistema, comprueba si son independientes o no, si lo son las ejecuta de forma local (en el nodo remoto) sino la llamada se emitirá al nodo de origen y la ejecutará el deputy. Éste devolverá el resultado de vuelta al lugar remoto donde se continua ejecutando el código de usuario.

### 3.1.1.6 Mecanismos de migración

Normalmente las políticas de ubicación y localización no suelen influir en estos mecanismo pues en general, una vez que el proceso migra no importa donde migre. Si se ha decidido que los mismos procesos son quienes lo deciden todo (automigración) se llega a un mecanismo de migración que es el usado en el sistema operativo AIX de IBM. Para este caso el procedimiento que se sigue cuando un proceso decide migrarse es:

1. Se selecciona la máquina destino y envía un mensaje de tarea remota. El mensaje lleva una parte de la imagen del proceso y de información de archivos abiertos.

2. En el nodo receptor, un proceso servidor crea un hijo y le cede esta información.

3. El nuevo proceso extrae los datos, los argumentos, la información del entorno y de la pila que necesita hasta completar su operación.

4. Se indica con una señal al proceso originario que la migración ha terminado. Este proceso envía un mensaje final para terminar la operación al nuevo proceso y se destruye.

Si en cambio es otro proceso el que comienza la migración en vez de ser el propio proceso tenemos el sistema que se usa en Sprite: se siguen los mismos pasos que en AIX pero ahora el proceso que maneja la operación lo primero que hace es suspender el proceso que va a migrar para hacerlo en un estado de no ejecución. Si el proceso que decide no está en cada máquina sino que hay solamente uno que hace decisiones globales, hay una toma de decisiones centralizada. En este caso se suelen usar unas instrucciones especiales desde esa máquina a las máquinas origen y destino de la migración, aunque básicamente se sigue el patrón expuesto del sistema AIX.

También puede ocurrir que se necesite un consenso de un proceso en la máquina origen y otro proceso en la máquina destino, este enfoque tiene la ventaja de que realmente se asegura que la máquina destino va a tener recursos suficientes, esto se consigue así:

1. El proceso controlador de la máquina origen (después de las decisiones oportunas) le indica al proceso controlador de la máquina destino que le va a enviar un proceso, este proceso le responde afirmativamente si está preparado para recibir un proceso.

2. Ahora el proceso controlador de la máquina origen puede hacer dos cosas: ceder el control al núcleo para que haga la migración o pedir al núcleo estadísticas del proceso y se las envía al proceso controlador destino (el núcleo hace lo mismo si toma el control).

3. El proceso controlador de la máquina destino, o su kernel, toman esa información (el proceso se la enviaría al kernel) y deciden si hay suficientes recursos en el sistema para el nuevo proceso. Si lo hubiera el núcleo reserva los recursos necesarios para el proceso y lo notifica al proceso controlador que notifica al proceso controlador de la máquina origen que proceda con la migración.

## 3.1.2 Compartición de recursos

### Problemas

Para entender como compartir recursos en un sistema distribuido se plantean nuevos problemas respecto a compartirlos en un sólo sistema. Véase con un ejemplo: supónganse dos instancias del mismo proceso que comparten memoria y acceden a una misma variable `contador` contenida en esta e inicializada con valor 5. Luego se incrementa `contador`. Lo que se espera es:

Tabla: Sistemas Operativos. Compartición de recursos (1)

Instancia 1 | Instancia 2
lee(contador) |
suma(contador,1) |
escribe(contador) |
| lee(contador)
| suma(contador,1)
| escribe(contador)

Si esto ocurriera así la primera instancia del programa pondría el contador a 6, entonces la segunda instancia del programa, leyendo ese valor, escribiría el valor 7.

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

Tabla: Sistemas Operativos. Compartición de recursos (2)

Instancia 1 | Instancia 2
lee(contador) |
a nade(contador,1) | lee(contador)
escribe(contador) | a nade(contador,1)
| escribe(contador)

El programa parece fallar de forma aleatoria, puesto que no podemos garantizar cuál será su ejecución real.

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.

## 3.1.3 Comunicación entre procesos

En un cluster existe un nuevo problema: al mover un proceso a otro nodo, ese proceso debe seguir pudiendo comunicarse con los demás procesos sin problemas, por lo que es necesario enviar las señales que antes eran locales al nodo a través de la red.

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.

## 3.1.4 La importancia de los sistemas de ficheros

Los sistemas de ficheros son necesarios en nuestros sistemas para mantener la información y compartirla entre usuarios y programas. Un fichero no es más que una abstracción del dispositivo de almacenaje permanente.

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.

Para comprender mejor el problema vamos a ver cuatro sistemas de ficheros que desde el más simple a otros más complejos han intentado solucionar estos problemas hasta cierto grado. Estos sistemas de ficheros son:

- 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.

A continucación se enumeran sus propiedades básicas y se hará una pequeña comparación entre ellos. La elección de estos sistemas de ficheros entre los muchos que existen no es casual: NFS es bien conocido y aunque existen otros sistemas similares y más avanzados (como AFS, Coda o Intermezzo que como NFS dependen de un servidor central) sus características avanzadas (cache en los clientes de AFS y la adaptación al ancho de banda, reintegración de una comunicación perdida y múltiples peticiones RPC de Coda, simpleza y distinción kernel/programa de usuario de Intermezzo) hacen que sea más complejo comprender las características que se quiere destacar en esta comparativa.

- 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 clientes3.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 NFS3.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ón3.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 Postmark3.7 benchmark que simula grandes cargas al sistema de ficheros, sobre GNU/Linux 2.2.16 y dos PCs Pentium 550 MHz3.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

El modo que no necesita servidor central es llamado modo simétrico, los discos contienen datos y metadatos, que son controlados por cada máquina al ser accedidos, estos accesos son sincronizados gracias a locks globales, que se apoyan en la ayuda del hardware tanto por parte de SCSI (DMEP) como por parte del switch (DLM). Esto hace esta alternativa aún más cara. En la figura 3.3 se muestra un gráfico con una configuración típica de este sistema. Se puede ver que la Network Storage Pool no tiene procesadores, pues está directamente conectada a la red, gracias a fibra óptica y SCSI. La Storage Area Network típicamente es un switch de alta velocidad).

Figura: Sistemas operativos. SAN

Entre las características que este sistema de ficheros se encuentra que no hay un solo punto de fallo, si un cliente falla, o si incluso muchos clientes quedasen inutilizables, el sistema de ficheros estaría todavía ahíaccesible a todos los clientes que aún estuvieran funcionando. Gracias a que los discos están compartidos por todos los clientes todos los datos a los que los clientes que dieron error estaban accediendo están todavía a disposición de los clientes que estén funcionando.

- 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)

Aunque de todos estos puntos solo el último sea negativo es una razón bastante fuerte y relega al uso de este sistema para empresas con gran presupuesto que no quieran usar un servidor centralizado.

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).

## 3.1.5 Entrada salida

En un sistema tradicional, la entrada/salida es local al nodo en el que se produce, pero desde la aparición de las redes se han venido aprovechando éstas para acceder a determinados recursos de entrada/salida colocados en un ordenador distante.

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.