Subsecciones
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.
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:
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
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.
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.
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.
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:
- 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:
- Migrar una parte del proceso.
En este sistema:
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.
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:
- 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.
- En el nodo receptor, un proceso servidor crea un hijo y le cede esta información.
- El nuevo proceso extrae los datos, los argumentos, la información del entorno
y de la pila que necesita hasta completar su operación.
- 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í:
- 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.
- 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).
- 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.
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.
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.
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).
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.
miKeL a.k.a.mc2
2004-09-06