Sistemas Operativos Distribuidos 1. Introducción

Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Sistemas Operativos Distribuidos
1. Introducción
De 1945 a 1985, las computadoras eran grandes y caras. Sin embargo a
mitad de la década de los 80’s, dos avances tecnológicos comenzaron a
cambiar esta situación:
1. Desarrollo de poderosos microprocesadores.
2. Invención de redes de área local de alta velocidad (LAN) y redes
WAN.
Un sistema distribuido consiste de una colección de computadoras
autónomas conectadas mediante una red y equipadas con software de
sistemas distribuidos. El software de un sistema distribuido habilita a las
computadoras para coordinar sus actividades y compartir los recursos del
sistema.
Los usuarios de un sistema distribuido bien diseñado deben percibir
una sola computadora y no un sistema implementado por muchas
computadoras en diferentes lugares.
Definición. Un sistema distribuido es una colección de computadoras
independientes que aparecen ante los usuarios del sistema como una única
computadora.
Esta definición tiene dos aspectos:
1. El hardware: las máquinas son autónomas.
2. El software: los usuarios piensan que el sistema es como una
única computadora.
Aplicaciones:
- Una red de computadoras con una pila de procesadores
- Una aerolínea
- Fábrica de robots
- Un banco con sucursales
- Internet
- Multimedia y conferencias
Sistema operativos distribuidos
- Amoeba
- Mach
- Chorus
- Clouds
- Plan9
- Mosix
- OpenMosix
Ventajas de los sistemas distribuidos con respecto de los
centralizados
 Economía. Los microprocesadores ofrecen mejor proporción
precio/rendimiento que los mainframes, pues se pueden reunir un
gran número de CPU’s baratos en un mismo sistema y dado el
avance tecnológico de estos, se puede dar un mejor rendimiento
que un solo mainframe.
 Velocidad. Un sistema distribuido puede tener mayor poder de
cómputo que un mainframe.
 Distribución inherente. Algunas aplicaciones utilizan máquinas
que están separadas a cierta distancia. Por ejemplo, trabajo
cooperativo apoyado por computadora, juegos cooperativos
apoyados por computadora.
 Confiabilidad. Si una máquina se descompone, el sistema puede
sobrevivir como un todo.
 Crecimiento por incrementos. Se puede añadir poder de cómputo
en pequeños incrementos.
Ventajas de los sistemas distribuidos con respecto a las computadoras
personales aisladas.
 Datos compartidos. Permiten que varios usuarios tengan acceso a
una base de datos común.
 Dispositivos compartidos. Permiten que varios usuarios
compartan periféricos caros como scanners o impresoras a color.
 Comunicación. Facilita la comunicación de persona a persona;
por ejemplo, mediante correo electrónico, FAX, chats, foros, etc.
 Flexibilidad. Difunde la carga de trabajo entre las máquinas
disponibles en la forma más eficaz en cuanto a costos.
Además de las ventajas anteriores, podemos sumar dos más en forma
general:
1
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Sistema de ficheros con raíz única. Este sistema de ficheros hace que
la administración sea más sencilla (no hay que administrar varios
discos independientemente) y deja a cargo del sistema varias de las
tareas.
Capacidad de comunicación de procesos y de intercambio de datos
universal. Permite enviar señales a cualquier proceso del conjunto de
computadoras, asimismo permite trabajar conjuntamente con
cualquier proceso e intercambiar datos. Por lo tanto será posible tener
todos los procesos trabajando en un mismo trabajo.
Desventajas de los Sistemas Distribuidos
La principal desventaja de estos sistemas es la complejidad que
implica su creación. La Economía, la Velocidad y la Distribución de
máquinas no tienen problemas de implantación porque son inherentes
a los sistemas distribuidos.
Confiabilidad (alta disponibilidad). Se puede conseguir alta
disponibilidad pues al tener varios nodos independientes, hay menos
posibilidades de que caigan todos a la vez. Para esto hay que
implantar los mecanismos necesarios para que cuando una máquina
caiga, se sigan dando todos los servicios. Esto nos lleva a la necesidad
de actualizar todas las réplicas de un servicio. También se tiene que
disponer de los mecanismos adecuados para que el nodo que ve el
fallo del servidor busque los servidores alternativos en busca de la
información que necesita. Además también se debe disponer de los
mecanismos necesarios para que los nodos que han caido, cuando
vuelvan a conectarse puedan continuar con su trabajo normalmente.
Escalabilidad. Al incrementarse el número de nodos aumentan las
comunicaciones, por lo tanto se debe diseñar un sistema lo más
escalable posible. Por ejemplo elegir una comunicación todos contra
todos no es una solución escalable.
Comunicación. Estos sistemas tienen más necesidad de
comunicación que los sistemas normales, por lo tanto tenemos que
crear nuevos métodos de comunicación lo más eficientes posibles.
Sistemas de ficheros con raíz única. Tenemos que independizar los
sistemas de ficheros distintos de cada uno de los nodos para crear un
sistema de ficheros general.
Un problema que nos encontramos en sistemas tipo UNIX es por
ejemplo cómo manejar los directorios /proa y /dev; los PID’s deberían
ser independientes para cada nodo, pero además se incluye
información como /proa/cpuinfo, /proa/meminfo, etc. Entonces
debería crearse un directorio para cada nodo para evitar problemas de
compatibilidad. En el caso de /dev, no hay problema si todos los
dispositivos son distintos, en caso contrario se debe diseñar un nuevo
esquema para nombrar los dispositivos.
Capacidad de comunicación de procesos y de intercambio de
datos universal. Para conseguir este objetivo necesitamos una forma
de distinguir unívocamente cada proceso del conjunto de
computadoras.
Redes. La red se puede saturar o causar otro problemas.
Seguridad. Como los datos son fáciles de compartir entonces también
se puede tener acceso a datos con los que no se tiene nada que ver.
1.1 Conceptos de Hardware
Sistemas fuertemente acopladas. El retraso que se experimenta el
enviar un mensaje de una computadora a otra es corto y la tasa de
transmisión de los datos (número de bits por segundo que se pueden
transferir) es alta.
Sistema débilmente acoplado. El retraso es grande y la tasa de
transmisión es baja.
Los sistemas fuertemente acoplados tienden a utilizarse más como
sistemas paralelos.
Los sistemas débilmente acoplados tienden a utilizarse como sistemas
distribuidos.
Clasificación de Flynn (1972).
2
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Considera dos características el número de flujos de instrucciones y el
número de flujos de datos.
SISD (single instruction, single data) Computadoras personales.
SIMD (single instruction, multiple data)
MISD (multiple instruction, single data)
MIMD (multiple instruction, multiple data) Todos los sistemas
distribuidos son MIMD.
Las computadoras MIMD se divide en Multprocesadores y
Multicomputadoras.
Multiprocesadores.
Existen dos categorías de computadoras paralelas. Estos modelos
físicos se diferencian en el hecho de tener memoria compartida o
distribuida.
Multiprocesadores de memoria compartida.
Existen tres modelos que se diferencian en como la memoria y los
periféricos se comparten o distribuyen.
- UMA (uniform memory access)
- NUMA (no uniform memory access)
- COMA (cache-only memory access)
El modelo UMA
La memoria se comparte uniformemente entre los procesadores.
Todos tienen igual tiempo de acceso a todas las palabras de memoria.
Cada memoria puede tener una caché privada. Los periféricos también
se comparten en la misma forma. Se les denomina sistemas
fuertemente acoplados. Para coordinar los eventos paralelos, la
sincronización e intercomunicación entre procesos se utilizan
variables en la memoria común.
Cuando todos los procesadores tienen igual acceso a todos los
periféricos el sistema se denomina simétrico (MP).
En un multiprocesador asimétrico solo uno o un subconjunto de
los procesadores tienen la capacidad ejecutiva. El procesador
ejecutivo o maestro ejecuta el sistema operativo y maneja la E/S. Los
otros procesadores no pueden manejar las E/S y se los llama attached
processors (APs). Los procesadores attached ejecutan código bajo la
supervisión del procesador maestro.
(Ejemplo Sequent S-81)
El modelo NUMA
La memoria está fisicamente distribuida entre todos los procesadores,
se llaman memorias locales. Es más rápido acceder un dato en la
memoria local, para acceder información en una memoria remota
existe una demora debida a la red de interconexión(BBN TC-2000
Butterfly).
Además de estas memorias distribuidas se puede agregar memoria
globalmente accesible por todos los procesadores. En este caso existen
tres patrones de acceso a memoria:
- el más rápido es acceder a memoria local
- un poco más lento es acceder la memoria global
- y por último el más lento de todos es acceder la memoria remota de
otro procesador
(ejemplo Cedar de la universidad de Illinois)
El modelo COMA
El modelo COMA utiliza solo memoria de tipo caché (ej. KSR-1 de
Kendall Square Research). Son un caso particular de la NUMA en el
cual la memoria distribuida se convierte en memorias caché. No
existen jerarquías de memoria en cada nodo procesador. Todas las
caches forman un espacio de direccionamiento global. El acceso a una
cache remota se facilita a través de los directorios distribuidos de
cache los cuales en ciertas arquitecturas pueden estructurarse en forma
jerárquica.
Una de las mayores desventajas que poseen estos multiprocesadores
es la falta de escalabilidad debido a la centralización de la memoria
compartida.
3
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Multicomputadoras
Consisten de múltiples computadoras llamadas a menudo nodos
interconectados por una red de paso de mensajes. Cada nodo es un
sistema autónomo con su procesador, su memoria y a veces
periféricos de E/S.
La red de paso de mensajes provee un mecanismo de
comunicación punto a punto. Todas las memorias locales con privadas
y son solo accesibles por el conjunto de procesadores locales del
nodo, por esta razón se las denomina máquinas NORMA (no remote
memory access).
El rango de transferencia de datos es similar a B-ISDN , utiizan
ATM como técnica de switcheo
Con B-ISDN y ATM, se pueden trabajar sistemas distribuidos en
redes WAN.
Protocolo
Conjunto de reglas y formatos usados para la comunicación entre
procesos para desempeñar una tarea.
Un protocolo tiene dos partes importantes:
1. Una especificación de la secuencia de mensajes que debe ser
intercambiado
2. Una especificación del formato de datos de los mensajes
Tipos de red
1.2 Conceptos de Software
Las redes de computadoras pueden ser divididas en dos clases:
En un sistema distribuido el software es más importantes que el
hardware, pues la imagen y la forma d pensar de los usuarios la
determina el software del sistema operativo.
Es posible distinguir dos tipos de sistemas operativos para
multiprocesadores o multicomputadoras:
 Software débilmente acoplado. Permite que las máquinas y los
usuarios en un sistema distribuido sean independientes entre sí en
lo fundamental, pero que interactúen cuando sea necesario.
 Software fuertemente acoplado. Las máquinas interactúan entre sí
(y los usuarios) para llevar a cabo las tareas en forma conjunta.
Redes de área local (LAN)
Mensajes de alta velocidad
Los nodos se encuentran repartidos en un solo edificio o campus.
Son apropiadas para sistemas distribuidos aunque algunas
aplicaciones multimedia necesitan un mayor ancho de banda
Redes de área amplia (WAN)
Mensajes a baja velocidad
Las computadoras se encuentran separadas a grandes distancias
Las computadoras que con interconectadas por una WAN son
llamadas computadoras host, estas pueden estar ubicadas en diferentes
ciudades, países o continentes
Es necesario el ruteo de paquetes
El tiempo de transmisión depende de la ruta
Una tercera clase son las redes de área metropolitana (MAN)
Utilizan cable de fibra óptica
Los nodos se encuentran ubicados en una misma ciudad, y se
transmite video, voz y otros datos a una distancia de alrededor de
50km
Sistemas operativos de redes
Software débilmente acoplado en hardware débilmente acoplado. Por
ejemplo una red de estaciones de trabajo conectadas mediante una
LAN.
Cada usuario tiene una estación de trabajo para uso exclusivo y
los comandos se ejecutan normalmente de manera local. Aunque
existen comandos que permiten que un usuario se conecte de forma
remota a otra estación de trabajo, entonces su máquina se convierte en
terminal de otra máquina. Esto no es muy conveniente.
4
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Una mejora es tener un sistema de archivos global accesible desde
todas las estaciones de trabajo (compartido), utilizando los llamados
servidores de archivos.
Estos utilizan un sistema jerárquico de archivos (directorio raíz,
subdirectorio y archivos). Las estaciones de trabajo pueden importar o
montar estos sistemas de archivos. Por lo tanto cada cliente tiene un
punto de vista distinto del sistema de archivos.
El sistema en el que cada máquina tiene un alto grado de
autonomía y existen pocos requisitos a lo largo de todo el sistema, se
llama sistema operativo de red.
Sistemas realmente destribuidos
Software fuertemente acoplado en
débilmente acoplado (multicomputadoras).
hardware
Objetivos:
 Hacer creer a los usuarios que toda la red de computadoras es
un sistema de tiempo compartido, a esta propiedad algunos
autores le llaman la imagen de único sistema
Algunos otros autores dicen que un sistema distribuido es aquel
que se ejecuta en un conjunto de máquinas enlazadas mediante una
red pero que actúan como un uniprocesador virtual.
Conclusión. Los usuarios no deben darse cuenta de la existencia
de varios CPU en el sistema.
Características de los sistemas distribuidos
Algunas de las características de los Sistemas Distribuidos son:
 Recursos compartidos. Discos, impresoras, archivos, bases de
datos y otros objetos.
 Manejador de recursos. Denota un módulo de software que
maneja un conjunto de recursos de un tipo particular. Incluye
provisión de nombres, maneja direcciones y coordina los accesos
concurrentes.
Los usuarios de recursos se comunican con el manejador de
recursos para accesar los recursos compartidos del sistema.
Para realizar la comunicación se puede emplear alguno de los
siguientes modelos.
Modelo cliente-servidor. El más comunmente usado. Los
servidores actúan como manejadores de recursos.
Modelo basado en objetos. Cada recurso compartido es un objeto,
los cuales pueden ser movidos de cualquier lugar en la red sin cambiar
sus identidades.
 Mecanismo de comunicación global entre procesos

“Openness”(Abierto). En un sistema distribuido el
“openness” es determinado por el grado en el cual nuevos
servicios de recursos pueden ser añadidos sin interrumpir o
duplicar los servicios existentes.
La publicación de documentos acerca del sistema es la clave de
esta característica.
Los sistemas que son diseñados para soportar recursos
compartidos que pueden ser expansibles en hardware y software son
llamados sistemas distribuidos abiertos.
Características de los sistemas distribuidos abiertos.
- Sus interfaces son publicadas
- Están provistos de un mecanismo de comunicación entre
procesos uniforme e interfaces públicas para acceso a recursos
compartidos.
- Puede ser construido con hardware y software heterogéneo.
 Esquema global de protección
 Concurrencia. Ejecución de varios procesos al mismo tiempo.
 Escalabilidad. Un sistema distribuido debe operar efectiva y
eficientemente a diferentes escalas. El sistema y las aplicaciones del
software no deben cambiar cuando la escala del sistema se incrementa
(memoria, procesadores, canales de E/S)
 Misma administración de procesos
 La misma apariencia del sistema de archivos en todas partes
 Sistema de archivos global
 Cada núcleo debe controlar sus propios recursos locales.
5
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Sistemas de Multiprocesador con tiempo compartido
Es software y hardware fuertemente acoplado. Por ejemplo los
multiprocesadores que operan como un sistema de tiempo compartido,
estos utilizan una cola de ejecución. El despachador utiliza exclusión
mutua mediante semáforos, monitores, etc., para evitar que dos CPU
elijan el mismo proceso para su ejecución.
Transparencia de paralelismo. Las actividades pueden ocurrir en
paralelo sin el conocimiento de los usuarios.
Transparencia en fallas. Si falla un nodo, el usuario no debe darse
cuenta y el sistema debe seguir trabajando.
Transparencia de escalamiento. Se pueden agregar nodos o software
y el sistema debe permanecer activo.
Transparencia de acceso. El acceso a los recursos debe realizarse de
la misma forma en cualquier lugar.
1.3 Aspectos del diseño
Flexibilidad
Transparencia.
Existen dos tipos de estructuras de los sistemas distribuidos.
- Los que utilizan núcleo monolítico en cada máquina, es decir, cada
máquina debe ejecutar un núcleo tradicional que proporcione la
mayoría de los servicios.
- Los que utilizan un micronúcleo, es decir, el núcleo proporciona lo
menos posible y el grueso de los servicios del sistema operativo se
obtienen a partir de servidores a nivel de usuario.
La transparencia es uno de los aspectos de diseño más importantes
dentro de los sistemas distribuidos, pero también uno de los más
complejos.
La transparencia puede darse en dos niveles:
 Hacia los usuarios
 Hacia los programas
Es más fácil lograr la transparencia dirigida a los usuarios
mediante una interfaz con comandos que aunque se ejecuten en otra
máquina o hagan uso de varias máquinas, los usuarios no se dan
cuenta; que lograr la transparencia para los programas, pues para
accesar a archivos remotos por ejemplo deben establecer una
conexión, y esto ya no es transparente.
Existen distintos tipos de transparencia en un sistema distribuido.
Transparencia de localización. Los usuarios no pueden indicar la
localización de los recursos.
Transparencia de migración.Los recursos se pueden mover a voluntad
sin cambiar sus nombres.
Transparencia de réplica. Los usuarios no pueden indicar el número
de copias existentes.
Transparencia de concurrencia. Varios usuarios pueden compartir
recursos de manera automática.
La mayoría de los sistemas distribuidos diseñados a partir de cero
utilizan micronúcleo y servidores. El micronúcleo proporciona cuatro
servicios mínimos.
1. Un mecanismo de comunicación entre procesos
2. Cierta administración de la memoria
3. Una cantidad limitada de planificación y administración de
procesos de bajo nivel
4. Entrada/Salida de bajo nivel
Todos los demás servicios se implantan a manera de servidores a
nivel de usuario. Debido a esto es fácil implantar, depurar, e instalar o
modificar cierto servicios; esto no puede hacerse en un núcleo
monolítico. Esto es lo que da flexibilidad al micronúcleo.
Ventaja del núcleo monolítico. Rendimiento (es más rápido), aunque
en la práctica esta ventaja ya no existe. (Sprite- núcleo monolítico,
Amoeba-micronúcleo)
6
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Confiabilidad
Este aspecto fue uno de los objetivos originales en la construcción de
sistemas distribuidos, la idea es que si alguna máquina falla, alguna
otra máquina se encargue del trabajo. Pero llevar a cabo esto en la
práctica es muy difícil.
Existen varios aspectos dentro de la confiabilidad.
 La disponibilidad, se refiere a la fracción de tiempo en que se
puede usar el sistema. Esta se mejora si en el diseño no se
exige el funcionamiento simultáneo de un número sustancia
de componentes críticos o mediante la redundancia en el
software y en el hardware.
 Seguridad. Los archivos y otros recursos deben ser
protegidos contra el uso no autorizado.
 Tolerancia a fallas. Que el sistema pueda recuperarse de las
fallas sin que el usuario se de cuenta.
El objetivo es que los métodos actuales puedan escalarse hacia
grandes sistemas. El principal problema son los cuellos de botella. Por
lo tanto hay que evitar componentes centralizados, tablas centralizadas
y algoritmos centralizados.
Se deben utilizar algoritmos descentralizados, los cuales tienen
las siguientes características, que los distingue de los algoritmos
centralizados:
- Ninguna máquina tiene la información completa acerca del estado
del sistema
- Las máquinas toman decisiones solo con base en la información
local.
- La falla de una máquina no arruina el algoritmo
- No existe una hipótesis implícita de la existencia de una regla
global.
Otros temas básicos de diseño son:
Nombres. Los procesos deben saber los nombres de los recursos
El mayor problema del desempeño en un sistema distribuido se da en
las comunicaciones, ya que estas son lentas, la lentitud se da más en el
manejo de protocolo que en la transmisión física real.
Una posible solución es verificar el tamaño de grano. Si un
trabajo implica gran número de pequeños cálculos que interactúa
mucho, se dice que el trabajo exhibe un paralelismo de grano fino; si
el trabajo implica grandes cálculos y la interacción es poca, se dice
que exhibe un paralelismo de grano grueso.
También es importante verificar si habrá ganancia en la ejecución
de un trabajo de forma remota, ya que habrá trabajos pequeños que no
deben ser ejecutados remotamente, sino de manera local.
También entra en juego la tolerancia a fallas, pues si un nodo falla
y estaba ejecutando un trabajo, otro nodo debe continuar con la
ejecución del trabajo.
para accesarlos. Un nombre es resuelto cuando es trasladado a una
forma tal que puede ser usado para invocar una acción sobre el
recurso. En un sistema distribuido un nombre resuelto es
generalmente un identificador de comunicación.
Nombre. Nombres que pueden ser interpretados por usuarios y
por programas
Identificador. Nombre que puede ser interpretado solo por
programas.
Se deben seleccionar nombres apropiados a cada tipo de recurso.
Todos los objetos son nombrados de manera uniforme y ocupan
un solo espacio de nombres.
Los nombres de los recursos deben poder ser resueltos.
El esquema de nombramiento puede ser diseñado para proteger
los recursos que ellos identifican de accesos no autorizados.
Todos los recursos manejados por un tipo de manejador de
recursos dado, deben tener nombre diferentes.
Escalabilidad
Comunicación
Desempeño
7
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Los componentes de un sistema distribuido están separados lógica
y físicamente, así que deben comunicarse para interactuar. La
comunicación entre un par de procesos involucra:
- Transferencia de datos
- Sincronización en la recepción y transmisión.
La programación básica utiliza primitivas de programación que
desempeñan acciones de paso de mensajes.
El mecanismo de paso de mensajes puede ser:
Síncrono o con bloqueo. El transmisor espera después de transmitir un
mensaje hasta que el receptor ha desempeñado una operación de
recepción.
Asincrono o sin bloqueo. El proceso receptor se bloquea cuando
ningún mensaje esta actualmente disponible. El proceso transmisor se
bloquea si no existe mensaje a transmitir.
Mecanismos de comunicación que utilizan paso de mensajes: canales,
sockets y puertos.
Modelos de comunicación más usados en sistemas distribuidos:
cliente-servidor, comunicación en grupo para grupos de procesos
cooperativos.
Asignación de la carga de trabajo
En un sistema distribuido existe un modelo básico llamado
“workstation-server”, pero no optimiza el uso de procesamiento y
memoria.
Dos modificaciones se han desarrollado:
a) Modelo de pila de procesadores. Los procesadores
pueden ser asignados dinámicamente a las tareas de
usuarios.
b) Uso de estaciones de trabajo vacías. Las tareas son
asignadas a estaciones de trabajo vacías o bajoutilizadas.
En sistemas distribuidos es común que los servidores sean
computadoras multiprocesadores con memoria compartida.
Los problemas de consistencia surgen de la separación de recursos de
procesamiento y concurrencia en sistemas distribuidos.
- Consistencia en la actualización
- Consistencia en la replicación
- Consistencia en el caché
- Consistencia en las fallas
- Consistencia en el reloj
- Consistencia en la interfaz de usuario
Requerimientos de usuario
Los diseñadores de sistemas deben considerar las necesidades de sus
usuarios potenciales
Funcionalidad
Lo que el sistema debe hacer para los usuarios
Un distribuido debe mejorar los servicios proporcionados por una
computadora aunado a uno o dos de los siguientes:
- El compartir recursos de red lleva al acceso de una variedad de
recursos
- Se pueden utilizar las ventajas de la distribución en la
programación de aplicaciones paralelas, interfaces de
programación.
Al migrar de un ambiente centralizado multiusuario o
monousuario a un distribuido se tienen tres opciones:
- Adaptarse a los sistemas operativos existentes
- Moverse totalmente a un nuevo SO diseñado específicamente
para sistemas distribuidos
- Emular un ambiente distribuido
Reconfigurabilidad
-
Mantenimiento de la consistencia
-
El diseño de la escalabilidad de un sistema distribuido es
importante
Cambios a corto plazo en condiciones de tiempo de ejecución
Evolución a mediano y a corto plazo en tiempo de ejecución
8
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Calidad de servicio
-
Desempeño
Confiabilidad y disponibilidad
Seguridad
soporta sistemas heterogéneos; por ejemplo, clientes de MS-DOS que
utilizan servidores UNIX. Ni siquiera es necesario que todas las máquinas
utilicen el mismo hardware.
Tres aspectos de NFS son de interés: la arquitectura, el protocolo
y la implantación.
Arquitectura de NFS.
2. El sistema de archivos de red (NFS) de Sun.
Network File System, es como su nombre lo indica un sistema de archivos
distribuido a lo largo de una red de máquinas, con el objetivo de tener un
número arbitrario de usuarios compartiendo un sistema de archivos común,
sin restricciones de sistemas operativos y hardware utilizado. NFS permite,
tanto a usuarios como a programas, acceder a archivos remotos ubicados
en maquinas remotas como si fueran locales.
NFS que fue diseñado e implantado por Sun en un principio para su uso en
las estaciones de trabajo UNIX. Ahora, otros fabricantes lo soportan, tanto
para UNIX como para otros sistemas operativos (incluido MS-DOS). NFS
NFS posee dos tipos distintos de máquinas, las que operan como NFS
Cliente y las que operan como NFS Servidor. Las NFS Cliente utiliza los
directorios remotos como si fueran parte de su sistema de archivo local.
Por su parte las máquinas que operan como NFS Servidor, se encargan de
publicar sus directorios y responder a las peticiones de los NFS Cliente.
En la mayoría de los casos, todos los clientes y servidores están en la
misma LAN, pero esto no es necesario. Es posible ejecutar NFS en una red
de área amplia. Se hablará de los clientes y servidores como si estuvieran
en máquinas diferentes, sin embargo, NFS permite que cada máquina sea
cliente y servidor al mismo tiempo.
Cada servidor NFS exporta uno o más de sus directorios para su
acceso por parte de los clientes remotos. Cuando se dispone de un
directorio, también de todos sus subdirectorios. La lista de directorios que
puede exportar un servidor se conserva en el archivo /etc/exports, de modo
que estos directorios se pueden exportar de manera automática al arrancar
el servidor.
Los clientes tienen acceso a los directorios exportados al montarlos.
Cuando un cliente monta un directorio (remoto), éste se vuelve parte de su
jerarquía de directorios. Si así lo desea, un cliente sin disco puede montar
un sistema de archivos remoto en su directorio raíz, lo que produce un
sistema de archivos por completo soportado en un servidor remoto. Las
estaciones de trabajo que sí tienen discos locales pueden montar
directorios remotos en el sitio que deseen de su jerarquía local de
directorios, lo que produce un sistema de archivos parcialmente local y
parcialmente remoto.
Así, la característica básica de la arquitectura de NFS es que los
servidores exportan directorios y los clientes los montan de manera
remota. Si dos o más clientes montan el mismo directorio al mismo
tiempo, se pueden comunicar compartiendo archivos en sus directorios
9
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
comunes. Un programa en un cliente puede crear un archivo, y un
programa en otro cliente puede leer el archivo. Una vez realizados los
montajes, no hay que hacer nada especial para lograr compartir los
archivos. Los archivos compartidos sólo están ahí, en la jerarquía de
directorios de varias máquinas y pueden leerse y escribir en ellos de la
manera usual. Esta sencillez es uno de los puntos fuertes de NFS.
NFS utiliza llamadas a procedimientos remotos o RPC (Remote
Procedure Calls), para la comunicacion entre los clientes y el servidor.
RPC permite que los clientes hagan llamadas de procedimientos a
procesos que aparentemente son locales, pero que en realidad estan
corriendo en una máquina remota. En el caso de NFS, el servidor que
recibe la llamada contiene recursos (especificamente archivos),
necesitados por los clientes que lo invocan.
Para asegurar la integridad del intercambio de datos entre el servidor y
los clientes, NFS emplea el mecanismo XDR (eXternal Data
Representation). Este mecanismo define un formato independiente de la
plataforma para realizar el intercambio de datos binarios.
Protocolos de NFS.
Puesto que uno de los objetivos de NFS es soportar un sistema
heterogéneo, con clientes y servidores que tal vez ejecuten diferentes
sistemas operativos con un hardware distinto, es esencial que la interfaz
entre los clientes y los servidores esté bien definida.
NFS logra este objetivo al definir dos protocolos cliente-servidor. Un
protocolo es un conjunto de solicitudes enviadas por los clientes a los
servidores, junto con las respuestas enviadas de regreso de los servidores a
los clientes. De manera análoga, los clientes pueden tratar a los servidores
como "cajas negras" que aceptan y procesan un conjunto especifico de
solicitudes. La forma en que lo hacen es asunto de ellos.
El primer protocolo NFS controla el anclaje. Un cliente puede enviar
un nombre de ruta de acceso a un servidor y solicitar que monte ese
directorio en alguna parte de su jerarquía de directorios. El lugar donde se
montará no está contenido en el mensaje, ya que el servidor no se preocupa
por dicho lugar. Si la ruta es válida y el directorio especificado ha sido
exportado, el servidor regresa un identificador de archivo al cliente. El asa
de archivo contiene campos que identifican de manera única al tipo de
sistema de archivo, el disco, el número de inodo del directorio, e
información de seguridad. Las llamadas posteriores para la lectura y
escritura de archivos en el directorio montado utilizan el identificador del
archivo.
Otra alternativa a la versión de UNIX de Sun soporta también el
automontaje. Esta característica permite asociar un conjunto de directorios
con un directorio local. Ninguno de los directorios remotos se monta (ni se
realiza el contacto con sus servidores) cuando arranca el cliente. En vez de
esto, la primera vez que se abre un archivo remoto, el sistema operativo
envía un mensaje a cada uno de los servidores. El primero en responder
gana, y se monta su directorio.
El automontaje tiene dos ventajas principales sobre el montaje estático
por medio del archivo /etc/rc. La primera es que si uno de los servidores
NFS llamados en /etc/rc no está sirviendo peticiones, es imposible
despertar al cliente, al menos no sin cierta dificultad, retraso y unos
cuantos mensajes de error. Si el usuario ni siquiera necesita ese servidor
por el momento, todo ese trabajo se desperdicia. En segundo lugar, al
permitir que el cliente intente comunicarse con un conjunto de servidores
en paralelo, se puede lograr cierto grado de tolerancia a fallos (puesto que
sólo se necesita que uno de ellos esté activo) y se puede mejorar el
desempeño (al elegir el primero que responda, que supuestamente tiene la
menor carga).
NFS no da soporte para la réplica de archivos o directorios, el usuario
debe lograr que todos los sistemas de archivos sean iguales. En
consecuencia, el automontaje se utiliza con más frecuencia para los
sistemas de archivos exclusivos para lectura que contienen binarios del
sistema y para otros archivos que rara vez cambian.
El segundo protocolo NFS es para el acceso a directorios y archivos.
Los clientes pueden enviar mensajes a los servidores para que manejen los
directorios y lean o escriban en archivos. Además, también pueden tener
acceso a los atributos de un archivo, como el modo, tamaño y tiempo de su
última modificación.
NFS omite las llamadas OPEN y CLOSE. No es necesario abrir un
archivo antes de leerlo, o cerrarlo al terminar. En vez de esto, para leer un
archivo, un cliente envía al servidor un mensaje con el nombre del archivo,
una solicitud para buscarlo y regresar un identificador de archivo, que es
una estructura de identificación del archivo. La llamada READ contiene al
10
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
identificador de archivo que se desea leer, el ajuste para determinar el
punto de inicio de la lectura y el número de bytes deseados. El servidor no
tiene que recordar lo relativo a las conexiones abiertas entre las llamadas a
él. Así, si un servidor falla y después se recupera, no se pierde información
acerca de los archivos abiertos, puesto que no hay ninguno. Un servidor
como éste, que no conserva información del estado de los archivos abiertos
se denomina sin estado.
Por el contrario, en el sistema V de UNIX, el sistema de archivos
remotos (RFS) requiere abrir un archivo antes de leerlo o escribir en él. El
servidor crea entonces una entrada de tabla con un registro del hecho de
que el archivo está abierto y la posición actual del lector, de modo que
cada solicitud no necesita un ajuste. La desventaja de este esquema es que
si un servidor falla y vuelve a arrancar rápidamente, se pierden todas las
conexiones abiertas, y fallan los programas cliente. NFS no tiene esta
característica.
El método NFS dificulta el hecho de lograr la semántica de archivo
propia de UNIX. Por ejemplo, en UNIX un archivo se puede abrir y
bloquear para que otros procesos no tengan acceso a él. Al cerrar el
archivo, se liberan los bloqueos. En un servidor sin estado como NFS, las
cerraduras no se pueden asociar con los archivos abiertos, puesto que el
servidor no sabe cuáles son los archivos están abiertos. Por lo tanto, NFS
necesita un mecanismo independiente adicional para controlar los
bloqueos.
NFS utiliza el mecanismo de protección de UNIX, con los bits rwx
para el propietario, grupo y demás personas. En un principio, cada mensaje
de solicitud sólo contenía los identificadores del usuario y del grupo de
quien realizó la llamada, lo que utilizaba el servidor NFS para validar el
acceso. De hecho, confiaba en que los clientes no mintieran. Varios años
de experiencia han demostrado que tal hipótesis era un tanto ingenua.
Actualmente, se puede utilizar la criptografía de claves públicas para
establecer una clave segura y validar al cliente y al servidor en cada
solicitud y respuesta. Los datos nunca se encriptan.
Todas las claves utilizadas para la autenticación, así como la demás
información, son mantenidas por el NIS (servicio de información de la
red). NIS se conocía antes como el directorio de páginas amarillas (yellow
pages). Su función es la de guardar parejas (clave, valor). Cuando se
proporciona una clave, regresa el valor correspondiente. No sólo controla
las claves de cifrado, sino también la asociación de los nombres de usuario
con las contraseñas (cifradas), así como la asociación de los nombres de
las máquinas con las direcciones de la red, y otros elementos.
Los servidores de información de la red se duplican mediante un
orden maestro/esclavo. Para leer sus datos, un proceso puede utilizar al
maestro o cualquiera de sus copias (esclavos). Sin embargo, todas las
modificaciones deben ser realizadas únicamente en el maestro, que
entonces las propaga a los esclavos. Existe un breve intervalo después de
una actualización en el que la base de datos es inconsistente.
Implantación de NFS
La capa superior es la capa de llamadas al sistema, la cual controla las
llamadas como OPEN, READ y CLOSE. Después de analizar la llamada y
verificar sus parámetros, llama a la segunda capa, la capa del sistema
virtual de archivos (VFS).
La tarea de la capa VFS es mantener una tabla con una entrada por
cada archivo abierto, análoga a la tabla de inodos para los archivos
abiertos en UNIX. En el UNIX ordinario, un inodo queda indicado de
manera única mediante una pareja (dispositivo, inodo). En vez de esto, la
capa VFS tiene una entrada, llamada vnodo (inodo virtual), para cada
archivo abierto. Los vnodos se utilizan para indicar si un archivo es local o
remoto. Para los archivos remotos, se dispone de suficiente información
para tener acceso a ellos.
Para ver la forma de utilizar los vnodos, sigamos una secuencia de
llamadas al sistema MOUNT, OPEN y READ. Para montar un sistema
remoto de archivos, el administrador del sistema llama al programa mount
con la información del directorio remoto, el directorio local donde será
montado y algunos otros datos adicionales. El programa mount analiza el
nombre del directorio remoto por montar y descubre el nombre de la
máquina donde se localiza dicho directorio. Entonces, entra en contacto
con la máquina en la que se localiza el directorio remoto. Si el directorio
existe y está disponible para su montaje remoto, el servidor regresa
entonces un identificador de archivo para el directorio. Por último, llama a
MOUNT para transferir el identificador del archivo al núcleo.
El núcleo construye entonces un vnodo para el directorio remoto y
pide el código del cliente NFS para crear un rnodo (inodo remoto) en sus
tablas internas, con el fin de mantener el identificador del archivo. El
11
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
vnodo apunta al rnodo. Así, cada vnodo de la capa VFS contendrá en
última instancia una referencia a un rnodo en el código del cliente NFS o
una referencia a un inodo en el sistema operativo local. Así, es posible ver
desde el vnodo si un archivo o directorio es local o remoto y, si es remoto,
encontrar su identificador de archivo.
Al abrir un archivo remoto, en cierto momento durante el análisis del
nombre de la ruta de acceso, el núcleo alcanza el directorio donde se desea
montar el sistema de archivos remoto. Ve que este directorio es remoto y
en el vnodo del directorio encuentra la referencia al rnodo. Le pide
entonces al código del cliente NFS que abra el archivo. El código del
cliente NFS busca en la parte restante del nombre de la ruta de acceso en el
servidor remoto asociado con el directorio montado y regresa un
identificador de archivo para él. Crea en sus tablas un rnodo para el
archivo remoto y regresa a la capa VFS, la cual coloca en sus tablas un
vnodo para el archivo que apunta al rnodo. De nuevo, vemos aquí que todo
archivo o directorio abierto tiene un vnodo que apunta a un rnodo o a un
inodo.
Quien hizo la llamada recibe un descriptor de archivo para el archivo
remoto. Este descriptor de archivo se asocia con el vnodo mediante las
tablas en la capa VFS. Observe que no se crean entradas en las tablas del
lado del servidor. Aunque el servidor está listo para proporcionar los
identificadores de archivo que le soliciten, no mantiene un registro de los
archivos que tienen identificadores activos y los que no. Cuando se le
envía un asa de archivo para el acceso a un archivo, verifica el
identificador y, si éste es válida, sa utiliza. El proceso de validación puede
incluir una clave de autenticación contenida en los encabezados RPC, si la
seguridad está activada.
Cuando el descriptor de archivo se utiliza en una llamada posterior al
sistema, por ejemplo, READ, la capa VFS localiza el vnodo
correspondiente y por medio de él determina si es local o remoto y el
inodo o rnodo que lo describe.
Por razones de eficiencia, las transferencias entre el cliente y el
servidor se realizan en bloques grandes, por lo general de 8192 bytes,
aunque se soliciten menos. Después de que la capa VFS del cliente ha
obtenido el bloque de 8K que necesitaba, emite en forma automática una
solicitud del siguiente bloque, por lo que lo recibirá rápidamente. Esta
característica se conoce como lectura adelantada y mejora en forma
considerable el rendimiento.
Se sigue una política análoga para la escritura. Sin embargo, al cerrar
un archivo, todos sus datos se envían al servidor de manera inmediata.
Otra de las técnicas que se utilizan para mejorar el rendimiento es el
ocultamiento, como en el UNIX ordinario. Los servidores ocultan los datos
para evitar el acceso al disco, pero esto es invisible para los clientes. Los
clientes mantienen dos caches, uno para los atributos de archivo (inodos) y
otro para los datos del archivo. Cuando se necesita un inodo o un bloque
del archivo, primero hay que verificar si esta solicitud se puede satisfacer
mediante el caché del cliente. En este caso, se evita el tráfico en la red.
Pero puede suceder que el caché no sea coherente.
Debido a la severidad potencial de este problema, la implantación de
NFS hace varias cosas para mitigarlo. Una de ellas es que a cada bloque
caché se le asocia un cronómetro. Cuando éste expira, la entrada se
descarta. Por lo general, el tiempo es de 3 segundos para los bloques de
datos y de 30 segundos para los bloques de directorio. Esto reduce un poco
el riesgo. Además, al abrir un archivo con caché, se envía un mensaje al
servidor para revisar la hora de la última modificación. Si la última
modificación ocurrió antes de capturar en el caché la copia local, se
descarta la copia del caché y se utiliza la nueva copia del servidor. Por
último, el cronómetro del caché expira cada 30 segundos y todos los
bloques sucios (es decir, modificados) en el caché se envían al servidor.
Aún así, NFS ha recibido amplias críticas por no implantar de manera
adecuada la semántica apropiada de UNIX. Una escritura a un archivo de
un cliente podría o no ser vista cuando otro cliente lea el archivo, según la
sincronización. Además, al crear un archivo, esta acción podría no ser
visible para el mundo exterior durante un periodo de 30 segundos. Existen
otros problemas similares.
Por medio de este ejemplo, vemos que aunque NFS tiene un sistema
compartido de archivos, como el sistema resultante es una especie de
UNIX parchado, la semántica del acceso a los archivos no está por
completo bien definida y la ejecución de un conjunto de programas que
cooperen entre sí podría producir diversos resultados, según la
sincronización. Además, lo único con lo que trata NFS es con el sistema de
archivos. No hace referencia a otros aspectos, como la ejecución de un
proceso. A pesar de todo, NFS es popular y tiene un uso muy extendido.
Ventajas de NFS
12
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP

Reducción de requerimento de espacio de Almacenamiento en
disco en las Estaciones de Trabajo. Incluso proveer espacio en
disco a estaciones que no posean uno propio.

Reducción de Tareas de Administración, debida a
centralización de archivos tanto comunes como no comunes.

Puede ser utilizado como complemento a NIS.

Facilita el trabajo con archivo remotos ya que no es necesarios
conocer los comandos remotos (ftp, rlogin, rsh, etc).

Ayuda a mantener la consistencia de los archivos entre las
diferentes estaciones de trabajo.

Puede utilizarse para la Comunicación entre Usuarios y/o
Programas.

Con el uso de NFS se pueden configurar los home directories de
los usuarios con lo que, una vez exportados en la red, cada
usuario puede utilizar su mismo “home directory”
independientemente de la máquina de la red que este utlizando.


NFS realiza sus comunicaciones a través del Protocolo UDP. Para
solventar las deficiencias inherentes de confiabilidad de UDP,
NFS implementa en sus servidores un mecanismo de
reconocimiento (acuse de recibo) a cada petición ejecutada por
los clientes, de tal manera le asegura a los clientes que su petición
fue atendida, de no recibir ningun “ack”, los clientes reenvian su
petición.

La mayoria de las peticiones son idempotentes, para lidiar con las
pocas peticiones no idempotentes y las posibles retransmitidas de
las mismas, los servidores mantienen en una memoria caché las
últimas peticiones no-idempotentes realizadas, con el objetivo de
eliminar la posible doble-ejecución de las mismas.

NFS esta contruido sobre RPC (Remote Procedure Call).

NFS utiliza la permisología de UNIX (ACL), por lo que para cada
peticion de un cliente NFS , el servidor NFS recibe el UID y el
GID del usuario.

Para evitar problemas de seguridad, NFS le da el UID de usuario
a cada usuario root de las máquinas cliente.

Existen dos tipos de Montaje de un direcitorio por parte de un
cliente, Hard y Soft, Con el primero de ellos el cliente va a
intentar montar el directorio cuantas veces sea necesario hasta
lograrlo, mientras que del modo Soft, lo intentara hasta que
suceda un timeuot establecido.

NFS es independiente de la plataforma de hardware y software
sobre la cual opera. Esto permite que sea portable a múltiples
Sistemas Operativos y plataformas de hardware, que van desde
computadores hasta mainframes.

NFS es flexible en cuanto a los protocolos de transporte, es decir,
que puede correr en multiples protocolos de transporte, en vez de
estar restringido a uno en especifico.
la
Usuarios y aplicaciones pueden acceder a archivos remotos como
si estos fuesen locales; por el hecho de utilizar RPC, los tiempos
de respuesta son tan rápidos, como si los archivos estuviesen
almacenados en discos locales.
NFS utiliza RPC sobre el protocolo XDR (eXternal Data
Representation), el cual asegura inviolabilidad en los datos
transportados. Ademas, RPC utiliza intercambio de parámetros de
autenticación, para dar dar seguridad a la informacion
transportada en la red.
Características Básicas de NFS


Los servidores NFS no mantienen el estado de ninguno de sus
clientes, esto impulsa dos cualidades para NFS como lo son la
disminución del tiempo de reestablecimiento de los servidores al
momento de fallar. Asi como también impulsa a una gran
escalabilidad en el número de clientes a los cuales puede servir.
Demonios involucrados en NFS.
13
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Nombre
mountd
nfsd
Lockd
Descripicion
Es un servidor de RPC que
responde a las peticiones de
montaje de sistemas de
archivos y a peticiones de
informacion de acceso. Lee
el archivo /etc/dfs/sharetab
para
determinar
que
sistemas de archivos están
exportados y quienes tienen
acceso a ellos.
Es el demonio central del
NFS, es quien se encarga de
atender
las
peticiones
efectuadas por los clientes
Se encarga del bloqueo de
archivos para asegurar así la
consistencia de los mismos
al
ser
accesados
concurrentemente.
Corre tanto en el servidor
como en el cliente.
Opciones
-v Modo detallado.
-r
rechaza
las
peticiones de nuevos
clientes.
-a levanta el demonio
con capacidad de
trabajar tanto con TCP
como UDP.
-c fija el # maximo de
conexiones TCP.
-l # maximo de
entradas para la cola
de conexiones TCP.
-p protocolo sobre el
cual se levantará el
demonio.
-t levanta el demonio
sobre el transporte
especificado.
nservers # de hilos
para atender peticiones
concurrentemente.
-g especifíca el tiempo
que tienen los clientes
para
reclamar
el
Statd
Funciona en cooperación
con lockd para recuperar el
estado de los archivos
bloqueados
cuando
el
servidor se cae.
Luego de levantarse de
nuevo, informa a los
clientes que se reestableció
el servicio basándose en la
información del lockd.
Tambien se encarga de
avisar a los servidores en
caso que ocurra una caída
de un cliente que posea un
archivo bloqueado.
portmap
Es el demonio que permite
a
los
clientes
NFS,
descubrir cual puerto esta
siendo usado por el servidor
NFS para prestar el
servicio.
bloqueo
de
los
archivos después que
el servido arranca.
-t fija el número de
segundo a esperar
antes de retransmitir
una
petición
de
bloqueo
a
otro
servidor remoto.
nthreads # de hilos a
levantar para atender
las
peticiones
concurrentes.
14
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Recomendaciones de Seguridad.
Protocolo

Debería estar configurado para dar acceso solo a ciertos clientes,
por lo que se debería configurar para utilizar autentificación de
usuarios.

De ser posible deberían solo exportarse sistemas de archivos de
solo lectura.

Limitar el número de sistemas de archivos que cada cliente
monta, mientras menos mejor.

Evitar exportar los ejecutables.

Evitar exportar directorios home.

No exportar directorios que tienen permiso de escritura para todo
el mundo (ACL).

Evitar que una máquina sea tanto servidor como cliente NFS.

No permitir login a usuarios desde otras maquinas Servidores
NFS.
Es "hablado" por el montd,
se
utiliza
para
la
negociación iniciada entre
el cliente y el servidor
NFS.
MOUNT
Comandos
Con este protocolo en
cliente puede conocer que
directorios
estan
exportados, así como
obtener el manejador de
archivos del sistema de
archivos
que
esta
montando.
mount Este comando permite a un cliente a montar un directorio remoto
dentro de la estructura jerárquica de su sistema de archivos. La estructura
general del Comando es: mount host_name:remote_dir local_dir.
unmount Este Comando permite a un usuario cliente desmontar un
directorios que no esten en uso, para ello es necesario especificar donde
esta montado el sistema de archivos. La estructura gerenal del Comando
es: unmount host_name:remote_dir.
Descripción
Este es el protocolo que
actúa después que la fase
de montaje ha concluido.
CREATE: Crea o Trunca un
archivo dentro de un
directorio.
Permite
manipular
el
sistema
de
archivos
montado.
LINK: Crea un enlace.
NFS
Protocolos Involucrados en el NFS
Nombre del
NULL: no hace nada.
MNT: Retorna un asa
de archivo de la raíz del
directorio
exportado,
también
avisa
al
mountd que un cliente
ha montado un sistema
de archivos.
DUMP: Retorna una
lista de sistemas de
archivos montados.
UMNT:
Retira
la
entrada de montaje de
un cliente para cierto
directorio de archivos
exportado.
UMNTALL:
Retira
todas las entradas de
montaje
para
ese
cliente.
EXPORT: Retorna la
lista de todos los
sistemas de archivos
exportados para ese
cliente.
Peticiones Comprendidas
LOOKUP: Busca un
15
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
archivo en un directorio.
MKDIR: Crea un directorio.
READDIR: Lee el
contenido de un directorio.
REMOVE: Borra un
archivo de un directorio.
RENAME: Renombra un
archivo de un directorio.
RMDIR: Elimina un
directorio.
SYMLINK: Crea un enlace
simbolico.
GETATTR: Retorna los
atributos de un archivo.
SETATTR: Establece los
atributos de un archivo.
READ: Lee un archivo.
WRITE: Escribe en un
archivo
3. Núcleo
El Kernel consiste en la parte principal del código del sistema operativo, el
cual se encargan de controlar y administrar los servicios y peticiones de
recursos y de hardware con respecto a uno o varios procesos, este se divide
en 5 capas:
Nivel 1. Gestión de Memoria: que proporciona las facilidades de bajo nivel
para la gestión de memoria secundaria necesaria para la ejecución
de procesos.
Nivel 2. Procesador: Se encarga de activar los cuantums de tiempo para
cada uno de los procesos, creando interrupciones de hardware
cuando no son respetadas.
Nivel 3. Entrada/Salida: Proporciona las facilidades para poder utilizar los
dispositivos de E/S requeridos por procesos.
Nivel 4. Información o Aplicación o Intérprete de Lenguajes: Facilita la
comunicación con los lenguajes y el sistema operativo para aceptar
las órdenes en cada una de las aplicaciones. Cuando se solicitan
ejecutando un programa el software de este nivel crea el ambiente
de trabajo e invoca a los procesos correspondientes.
Nivel 5. Control deArchivos: Proporciona la facilidad para el
almacenamiento a largo plazo y manipulación de archivos con
nombre, va asignando espacio y acceso de datos en memoria.
El núcleo y los procesos
Todas las operaciones en las que participan procesos son
controladas por la parte del sistema operativo denominada núcleo (nucleus,
core o kernel, en inglés). El núcleo normalmente representa sólo una
pequeña parte de lo que por lo general se piensa que es todo el sistema
operativo, pero es tal vez el código que más se utiliza. Por esta razón, el
núcleo reside por lo regular en la memoria principal, mientras que otras
16
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
partes del sistema operativo son cargadas en la memoria principal sólo
cuando se necesitan.
Los núcleos se diseñan para realizar “el mínimo” posible de
procesamiento en cada interrupción y dejar que el resto lo realice el
proceso apropiado del sistema, que puede operar mientras el núcleo se
habilita para atender otras interrupciones.
Resumen de las Funciones del Núcleo
El núcleo de un sistema operativo normalmente contiene el código
necesario para realizar las siguientes funciones:

Manejo de interrupciones.

Creación y destrucción de procesos.

Cambio de estado de los procesos.

Despacho.

Suspensión y reanudación de procesos.

Sincronización de procesos.

Comunicación entre procesos.

Manipulación de los bloques de control de procesos.

Apoyo para las actividades de entrada/salida.

Apoyo para asignación y liberación de memoria.

Apoyo para el sistema de archivos.

Apoyo para el mecanismo de llamada y retorno de un
procedimiento.

Apoyo para ciertas funciones de contabilidad del sistema.
Tipos de kernel
En función del tamaño y de las funcionalidades que posea el
kernel podemos clasificarlo. Realmente, y pese a seguidores
incondicionales en un modelo u otro, existe una tendencia básica a reducir
el tamaño del núcleo proporcionando menos funcionalidades, que son
desplazadas a módulos que se cargan en tiempo de ejecución.
En función a esta idea tenemos tres tipos fundamentales de
kernel:
Kernel monolítico
Todas las funcionalidades posibles están integradas en el sistema.
Se trata de un programa de tamaño considerable que deberemos recompilar
al completo cada vez que queramos añadir una nueva posibilidad. Esta es
la estructura original de Linux. Por tratarse de una técnica clásica y
desfasada el creador de Linux fue muy criticado.
Kernel modular (Núcleo Colectivo): En esta estructura se tiene
una colección de procesos que son ampliamente independientes unos de
otros. Los servicios del Sistema Operativo ( Administración de memoria
distribuida, sistemas de archivos distribuidos, sincronización distribuida,
procesos RPC, administración de tiempos, etc.) son implementados como
procesos independientes. El núcleo del Sistema Operativo ( Comúnmente
llamado Microkernel ) soporta la interacción entre los procesos que
proveen los servicios al Sistema Operativo, también provee los servicios
típicamente esenciales para cada computadora tal como la administración
de tareas. El microkernel se ejecuta en todas las computadoras del sistema,
mientras que los otros procesos pueden o no correr según se requiera.
Se trata de la tendencia actual de desarrollo. Sin embargo no tiene
sentido que el núcleo de un sistema operativo englobe toda la parafernalia
para comunicarse con todas las posibles de tarjetas de vídeo o de sonido.
En otros sistemas operativos esto se soluciona con unos ficheros
proporcionados por el fabricante llamados drivers. En Linux se creó un
17
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
interfaz adecuado para posibilitar el desarrollo de módulos que cumplieran
esas funcionalidades. Esos módulos pueden ser compilados por separado y
añadidos al kernel en tiempo de ejecución.
3.Procesos y procesadores en sistemas distribuidos
Los procesos no comparten el mismo espacio de direcciones y no tienen
nada que ver uno con otro. Para comunicarse utilizan primitivas de
comunicación como memoria compartida, tuberías y paso de mensajes.
En muchos sentidos los hilos son como miniprocesos. Cada hilo
tiene su contador del programa, su pila para llevar el registro de su
posición y se ejecutan en forma estrictamente secuencial. Los hilos
comparten el mismo CPU (a menos que haya varios CPU, en ese caso se
ejecutan en paralelo). Los hilos pueden crear hilos hijo y se pueden
bloquear. A diferencia de un proceso, un Hilo (proceso ligero) comparte el
espacio de direcciones con otros hilos por lo tanto comparten variables
globales.
Los hilos se inventaron para permitir la combinación del
paralelismo con la ejecución secuencial y el bloqueo de las llamadas al
sistema.
Aspectos del diseño de paquetes de hilos
Paquete de hilos. Un conjunto de primitivas relacionadas con los hilos.
 Manejo de hilos
Se tienen dos alternativas:
- Hilos estáticos. Se elige el número de hilos al escribir el
programa o durante su compilación. Cada uno de ellos tiene
asociada una pila fija.
- Hilos dinámicos. Se permite la creación y destrucción de los hilos
durante la ejecución.
Los hilos pueden concluir de dos maneras:
- Pueder terminar por sí mismos al finalizar su trabajo.
- Pueden ser eliminados desde el exterior.
Una técnica dentro de los paquetes de hilos para el manejo de exclusión
mutua es el mútex, que es cierto tipo de semáforo binario. Un mútex solo
tiene dos estados: cerrado, mediante la operación LOCK (si un hilo intenta
cerrar un mútex ya cerrado, se bloquea); y no cerrado, para liberar un
mútex se utiliza la operación UNLOCK (cuando UNLOCK elimina la
cerradura de un mútex y uno o más hilos esperan ese mútex, se libera solo
uno de ellos. El resto continua en espera.
Otra operación que se tiene en ciertos casos es TRYLOCK, que
intenta cerrar un mútex. Si el mútex no esta cerrado, TRYLOCK regresa
un código de estado que indica el éxito. En caso contrario, TRYLOCK no
bloquea el hilo, sino que regresa un código de error.
Otra característica de sincronización a veces disponible en los
paquetes de hilos es la variable de condición. Por lo general se asocia una
variable de condición a un mútex cuando éste se crea. La diferencia entre
un mútex y una variable de condición, es que el primero se utiliza para una
cerradura a corto plazo, principalmente para proteger la entrada a regiones
críticas. Las variables de condición se utilizan para una espera a largo
plazo hasta que un recurso esté disponible.
Un problema que presentan los hilos es el manejo de variables
globales que no son globales en todo el programa, por ejemplo la variable
errno. Si un hilo hizo una llamada al sistema y dejó en errno un valor
importante, puede ser que el despachador interrumpa a ese hilo antes de
llevar a cabo la operación correspondiente al valor de errno, suponga que
el siguiente hilo en despacharse también hace una llamada al sistema, la
cual modifica errno; por lo tanto, el primer hilo habrá perdido el valor que
obtuvo en errno, ya que ésta ha sido sobreescrita por otro hilo.
Las posibles soluciones a este problema son las siguientes:
Prohibir las variables globales
Asignar a cada hilo sus propias variables globales particulares.
Cada hilo tiene copia de la variable global. Una mejora a esto es
asignar un bloque de memoria a las variables globales y
transferirlo a cada procedimiento del hilo como un parámetro
adicional.
3. Introducir nuevos procedimientos de biblioteca para crear, dar
valores y leer estas variables globales a lo largo de todo un hilo.
1.
2.

Planificación
Se pueden utilizar los algoritmos de prioridad, roun robin, lotería, etc.
18
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
A menudo los paquetes de hilos proporcionan ciertas llamadas para
que el usuario pueda especificar el algoritmo de despacho y establecer las
prioridades (si es el caso).
Implantación de un paquete de hilos
Existen dos métodos:
 En el espacio de usuario
 En el espacio de núcleo
Implantación de los hilos en el espacio de usuario
El núcleo no sabe de la existencia de los hilos.
Ventajas
1. El sistema operativo no debe soportar hilos. Por ejemplo UNIX
2. La planificación y cambio de estado la realiza un Sistema de
Tiempo de Ejecución a nivel de usuario.
3. Se permite que cada proceso tenga su algoritmo de planificación
adaptado.
4. Los hilos en este espacio tienen mejor escalabilidad, puesto que
los hilos del núcleo requieren algún espacio para sus tablas y su
pila en el núcleo, lo cual puede ser un problema si existe un
número muy grande de hilos.
Desventajas
1. La implantación de las llamadas al sistema con bloqueo. Por
ejemplo la lectura a un pipe vacío. Se puede permitir el bloqueo a
un hilo pero que no afecte a los demás. Con las llamadas al
sistema con bloqueo esto no se puede lograr. Una posible
solución sería modificar tales llamadas al sistema, pero cambiar el
sistema operativo no es atractivo. Además uno de los objetivos de
tener un paquete de hilos a nivel de usuario es poder ejecutar los
sistemas operativos existentes. Un cambio de una llamada al
sistema requeriría muchos cambios a muchos programas de
usuario.
Otra alternativa es, revisar primero si una llamada al sistema se
bloqueará utilizando la llamada SELECT. Entonces la llamada al
2.
3.
4.
5.
sistema bloqueante es reemplazada por SELECT y luego la
llamada al sistema. SELECT verifica si la llamada es segura (no
se va a bloquear), si es así se lleva a cabo, sino no se ejecuta. El
código que se coloca junto a la llamada al sistema para hacer la
verificación recibe el nombre de jacket. Este método requiere
escribir parte de la biblioteca de llamadas.
Bloqueo de las llamadas al sistema en el fallo de páginas. Si un
hilo causa un fallo de páginas, el núcleo que desconoce la
existencia de los hilos, bloqueará todo el proceso hasta que la
página necesaria sea incluida aunque se puedan correr otros hilos.
Si un hilo comienza su ejecución, ningún otro hilo de ese proceso
puede ejecutarse, a menos que el primer hilo entregue en forma
voluntaria el CPU. Dentro de un proceso, no existen
interrupciones de reloj, lo que imposibilita la planificación round
robin.
Sincronización. Cuando un hilo realiza espera ocupada esperando
la respuesta de un hilo, necesita interrupciones de reloj. La espera
ocupada es atractiva cuando se espera una respuesta rápida y el
costo del semáforo es alto, pero se pueden dar bloqueos.
Los programadores desean los hilos en aplicaciones donde esto se
bloqueen a menudo, por ejemplo en un servidor de archivos.
Implantación de hilos en el núcleo
El núcleo sabe de los hilos y como manejarlos. Este contiene una tabla con
una entrada por cada hilo, con los registros, estado, prioridades y demás
información relativa al hilo.
Las llamadas que pueden bloquear un hilo se implantan como
llamadas al sistema, con un costo considerable. Cuando un hilo se bloquea
el núcleo ejecuta otro hilo del mismo proceso o de otro proceso. Pero el
programador esperaría que se ejecutara un hilo del mismo proceso.
Algunos sistemas reciclan sus hilos, cuando un hilo termina y se
destruye, se marca como no ejecutable, pero sus estructuras de datos en el
núcleo no se afectan sino que se ocupan cuando se crea otro hilo. Esto
implica un ahorro.
Los hilos del núcleo no requieren nuevas llamadas al sistema sin
bloqueo, no conducen a bloqueos cuando se utiliza la espera ocupada.
19
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Si un hilo de un proceso provoca un fallo de página, el núcleo
puede ejecutar otro hilo mientras que espera que la página requerida sea
traida del disco.
Los hilos en el espacio del usuario o del núcleo tienen asociados
otros problemas. Muchos procedimientos no son reentrantes, por ejemplo
cuando ambos hilos utilizan la variable errno o algún bufer estático. Esto
sucede porque estos procedimientos no fueron escritos para hilos sino para
un solo proceso.
Una solución sería escribir toda la biblioteca. Otra solución
consiste en proporcionar a cada quien su jacket que cierre un semáforo
mutex global al iniciar el procedimiento. De hecho la biblioteca se
convierte en un enorme monitor.
Las señales también presentan dificultades.
Modelos de Sistemas
El modelo de estación de trabajo
Este modelo consiste de estaciones de trabajo (WS) dispersas en un
edificio o campus y conectadas entre sí por medio de una LAN. Las WS de
trabajo pueden tener discos locales o no.
Estaciones de trabajo sin disco
Si las WS sw trabajo carecen de disco, el sistema de archivos
debe ser implantado en uno o varios servidores de archivos de red.
Ventajas
 Precio más bajo
 Fácil mantenimiento y respaldo. Al cambiar de versión de
software o instalar uno nuevo, solo se tiene que instalar en pocos
servidores.
 Son silenciosas (no tienen ventiladores )
 Proporcionan simetría y flexibilidad. Un usuario puede entrar a
cualquier estación de trabajo y entrar al sistema.
Desventajas


Se debe contar con uno o más servidores de archivos equipados
con discos enormes y rápidos a los cuales se tiene acceso
mediante una LAN.
Gra uso de la red que puede llevar a cuellos de botella.
Estaciones de trabajo con disco
Formas en las que se puede utilizar el disco:
1. Para paginación y archivos temporales, los cuales se eliminan al
finalizar la sesión. Su ventaja es reducir la carga de la red
comparado con el caso sin disco, y su desventaja es el alto costo
debido al gran número de discos duros.
2. Para paginación, archivos temporales y binarios del sistema, tales
como compiladores, editores de texto, controladores de correo
electrónico, etc. Este esquema reduce aún más la carga sobre la
red. Su desventaja es el alto costo y la complejidad adicional para
actualizar los binarios.
3. Para paginación, archivos temporales, binarios del sistema y
sistema de ocultamiento de archivos. Los usuarios pueden cargar
archivos desde los servidores de archivos hasta sus propios
discos, leerlos y escribir en ellos en forma local, y después
regresar los archivos modificados al final de la sesión. El objetivo
es mantener centralizado el almacenamiento a largo plazo, pero
reducir la carga en la red. Su principal desventaja es que puede
tener problemas de consistencia del caché.
4. Un sistema local de archivos completo. Su ventaja es la escasa
carga en la red y que elimina la necesidad de los servidores de
archivos. Pero hay pérdida de transparencia y es más parecido a
un sistema operativo de red
Otros problemas relacionados con este modelo son los siguientes:
Si los circuitos siguen abaratándose pronto será posible
proporcionar a cada usuario varios CPU, pero serían demasiados en un
solo lugar; además surgiría otro problema, la asignación de recursos sería
ineficiente ya que algunos usuarios recibirían recursos que no necesitan
mientras que otros usuarios si los necesitan.
Uso de estaciones de trabajo inactivas
20
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
El problema en el modelo de estaciones de trabajo es que existen WS
inactivas o subutilizadas. La primera solución a este problema fue
proporcionar el comando rsh (UNIX Berkeley), con este comando se
puede ejecutar en una máquina remota un comando.
Para llevar a cabo la ejecución remota de un comando en una
máquina inactiva mediante rsh se debe tener un registro acerca de cuál WS
esta inactiva. Además el proceso que se ejecuta en una máquina remota
seguirá ejecutándose aunque llegue un usuario, quien debe aceptar el
desempeño menor de su sistema o buscar otra máquina.
Problemas clave a solucionar con respecto al tema de las estaciones de
trabajo inactivas
1. ¿Cómo encontrar una estación de trabajo inactiva?
2. ¿Cómo lograr que un proceso remoto se ejecute en forma
transparente?
3. ¿Qué ocurre si regresa el poseedor de la máquina?
1. La estación de trabajo esta inactiva cuando nadie toca el ratón o el
teclado durante varios minutos y no se ejecuta algún proceso iniciado por
el usuario.
Los algoritmos para localizar una WS inactiva se pueden dividir
en dos categorías:
a) Controlados por el servidor
b) Controlador por el cliente
En el primer caso cuando una WS esta inactiva anuncia su
disponibilidad registrándose en un archivo o base de datos, da su nombre,
dirección de red y propiedades.
Cuando el usuario desea ejecutar un comando en una WS
inactiva, mediante un comando busca en el registro la WS adecuada (el
registro de WS inactivas esta centralizado con algunas copias).
Otra alternativa es que la WS inactiva envíe un mensaje en toda la
red. Las demás WS registran el mensaje en su propio registro. Así la
búsqueda tiene menor costo y mayor redundancia. La desventaja es pedir a
todas las máquinas que se encarguen de mantener el registro. Puede haber
condiciones de competencia si dos usuarios descubren una misma máquina
como inactiva.
Para solucionar este problema, se envía un mensaje a la máquina
inactiva para detectar su estado, si aún esta libre, la máquina inactiva se
elimina del registro. Entonces quien hizo la llamada puede enviar su
ambiente e iniciar el proceso remoto.
En el segundo método, controlado por el cliente. La máquina que
busca una WS(ws) inactiva transmite una solicitud donde indica el
programa que desea ejecutar, y los requerimientos de memoria,
procesador, etc. Al regresar la respuesta se elige a una ws inactiva.
Las ws inactivas retrasan sus respuestas, con un retraso
proporcional a la carga actual. Así, la respuesta de la máquina con la
menor carga llega primero y se selecciona.
2.Ahora hay que ejecutar el programa. El desplazamiento de código es
fácil. Se debe configurar el proceso remoto de modo que vea el mismo
ambiente que tendría en el caso local y llevar a cabo el cómputo de la
misma forma que en el caso local.
Necesita la misma visión del sistema de archivos, el mismo
directorio de trabajo, mismas variables de ambiente.




Problemas al ejecutar un proceso en otra máquina.
Las llamadas al sistema ¿dónde dirigirlas? ¿a la máquina origen o a la
máquina remota? Por ejemplo, la lectura de teclado y escritura a
pantalla son funciones que deben dirigir la solicitud a la máquina
origen; pero las llamadas que tienen que ver con prioridades o tamaño
de memoria deben dirigir su solicitud a la máquina remota.
Llamadas al sistema relacionadas con el tiempo
Seguimiento del ratón
Escritura en dispositivos de hardware
3.Si el poseedor de la máquina regresa no hacer nada, fácil pero destruye
la idea de ws personales.
Otra posibilidad es eliminar el proceso intruso, advirtiéndole
primero para que tenga tiempo de cerrar archivos, escribir los búferes
editados en un disco, etc. Sino sale después de unos segundos el proceso es
terminado.
Otro método es hacer que el proceso emigre a otra máquina, ya
sea a la máquina origen o a alguna otra estación de trabajo inactiva. Esto
es un proceso complejo.
21
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
El proceso debe dejar la máquina en el mismo estado exactamente
como la encontró.
El modelo de pila de procesadores
Se construye una pila de procesadores, repleta de CPU, en un cuarto de
máquinas, los cuales se pueden ejecutar de forma dinámica a los usuarios
según la demanda. A cada usuario se le da una terminal gráfica de alta
rendimiento, como las terminales X, incluso se pueden utilizar terminales
ascii.
Ventajas
 Precio
 Elimina la asociación entre el número de usuarios y el de ws
 Facilita el crecimiento por incrementos
De hecho se convierte el poder de cómputo en ws inactivas, a las
que se puede tener acceso de manera dinámica. Aquí no existe el concepto
de propiedad.
El principal argumento para la centralización del poder de
cómputo como pila de procesadores proviene de la teoría de colas.
Los sistemas de colas son útiles, puesto que es posible modelarlos
de forma analítica.
Sea  la tasa de entradas totales de solicitudes por segundo de
todos los usuarios combinados. Sea  la tasa de procesamiento de
solicitudes por parte del servidor. Para una operación estable debemos
tener  > . Si el servidor procesa menos solicitudes que las que los
usuarios generan, la cola crecerá sin límite.
El promedio de tiempo entre la emisión de una solicitud y la
obtención de una respuesta completa está relacionado con  y  mediante
la fórmula
T=1/( - )
1)
Si tenemos n computadoras, T estará dado en cada computadora
como en 1). Ahora si reemplazamos estos n pequeños recursos por uno
grande que sea n veces más poderoso, entonces tenemos,
T=1/(n - n) = T/n
Se reduce el tiempo promedio de respuesta n veces. Por esto una
pila de procesadores tiene un mejor desempeño, aunque este en contra de
los propios sistemas distribuidos.
Sin embargo el tiempo promedio de respuesta no lo es todo.
También esta el costo, la confiabilidad y la tolerancia a fallas. Una
variación en el tiempo de respuesta también puede influir.
Además en muchos trabajos la pila no es n veces mejor, pues no
todos los trabajos se pueden ejecutar en paralelo.
Aún así, el modelo de pila de procesadores es una forma más
limpia de obtener poder de cómputo adicional que la búsqueda de
estaciones inactivas. Ningún procesador pertenece a alguien, no hay
máquina origen, no hay peligro de que el poseedor regrese.
Seleccionar pila de procesadores o estaciones de trabajo inactivas
va a depender del trabajo que se desarrolle.
Modelo híbrido
Se puede establecer una mediación al proporcionar a cada usuario una ws
personal y además tener una pila de procesadores. Esto es más caro.
Para procesos interactivos sería mejor utilizar ws. Para procesos
que requieren un gran poder de procesamiento y no son interactivos es más
adecuado una pila de procesadores.
Asignación de procesadores
Las estrategias de asignación de procesadores se pueden dividir en dos
categorías amplias:
-No migratorios. Cuando un proceso es creado, se decide donde colocarlo.
Una vez colocado en una máquina, el proceso permanecerá ahí hasta que
termine su ejecución.
-Migratorios. Un proceso se puede trasladar aunque haya iniciado su
ejecución. Este tipo de categorías permiten un mejor balance de carga.
Un algoritmo que asigne procesos a procesadores, tiene como meta
optimizar algún aspecto, por ejemplo los siguientes:
-Maximizar el uso de CPU
-Minimizar el tiempo de respuesta
22
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Aspectos del diseño de algoritmos de asignación de procesadores
Las principales decisiones que deben tomar los diseñadores se pueden
resumir en cinco aspectos:
1. Algoritmos deterministas vs. Heurísticos
2. Algoritmos centralizados vs. Distribuidos
3. Algoritmos óptimos vs. Subóptimos
4. Algoritmos locales vs. Globales
5. Algoritmos iniciados por el emisor vs. Iniciados por el receptor
Los algoritmos deterministas son adecuados cuando se sabe de
antemano todo acerca del comportamiento de los procesos o por lo menos
una aproximación razonable.
Cuando la carga del sistema es completamente impredecible se
utilizan técnicas heurísticas.
Tener toda la información en un solo lugar permite tomar una mejor
decisión, pero es menos robusta y coloca una carga pesada en la máquina
central. Son preferibles los descentralizados, pero carecen de alternaticas
adecuadas.
Encontrar la mejor asignación, la mas óptima es más caro, pues hay
que recolectar más información y procesarla más. En la práctica se buscan
soluciones subóptimas, heuríticas y distribuidas.
Otro aspecto llamado política de transferencia, también es importante,
tiene que ver con ejecutar un proceso en la máquina local o transferirlo,
esta decisión depende de la carga de la máquina. Una escuela dice que la
decisión se debe tomar con respecto a la información de la máquina local,
si esta sobrecargada (esta por sobre una marca) entonces hay que migrar el
proceso, sino el proceso se debe ejecutar en la máquina local. Otra escuela
dice que es mejor recolectar toda la información del sistema para decidir
donde ejecutar el proceso.
El último aspecto tiene que ver con lo que se llama política de
localización, decidir dónde enviarlo una vez que se ha decidido migrar el
proceso. En el caso de los algoritmos iniciados por el emisor, es el emisor
(la máquina local que necesita colocar su proceso en otra máquina) quien
envia solicitudes a las demás máquinas en busca de ayuda y de un lugar
apropiado para su proceso. En el caso de los algoritmos iniciados por el
receptor, es el receptor quien decide que esta subcargada y que necesita
trabajo, así que enviar mensajes a las demás máquinas a ver quien necesita
ayuda.
Aspectos de la implantación de algoritmos de asignación de
procesadores



Medición de la carga
- Los algoritmos suponen que cada máquina conoce su
carga.
- Algunos algoritmos cuentan el número de procesos para
determinar su carga.
- Una mejora al criterio anterior es contar solo los
procesos en ejecución o listos.
- Otra forma de medir la carga es determinar la fracción
de tiempo que el CPU esta ocupado.
Costo excesivo
- Muchos algoritmos teóricos ignoran el costo de
recolectar medidas y desplazar los procesos de aquí para
allá.
- Al desplazar un proceso se debe verificar si hay
ganancia en hacerlo. Para esto hay que tomar en cuenta
el uso de memoria, tiempo de CPU y ancho de banda de
la red.
Complejidad
- Existen algortimos que tienen un desempeño un poco
mejor que otros, pero son más complejos.
- Eager realizó un estudio a este respecto, y para ello
trabajó con tres algoritmos. Se supone que al crear un
nuevo proceso en una máquina, ésta se sobrecargará, por
lo tanto hay que desplazar el proceso a otro lugar.
1. Se elige una máquina al azar y se envía el proceso, si la
máquina esta subcargada entonces aceptará el proceso,
en caso contrario se repite la operación hasta que alguien
acepte el proceso o se exceda un contador de tiempo.
2. Se elige una máquina al azar y se le pregunta si esta
subcargada, si su respuesta es afirmativa entonces la
máquina origen le envía el proceso, sino se repite la
operación con otra máquina elegida al azar y así hasta
23
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
encontrar una máquina adecuada o se exceda el número
de pruebas, en cuyo caso permanecerá en el sitio de su
creación.
3. Se analizan k máquinas para determinar sus cargas
exactas. El proceso se envía a la máquina con la carga
más pequeña.
El mejor algoritmos es el 3, sin embargo el algoritmo 2 tiene
un desempeño casi igual al 3, pero es más sencillo.
La conclusión a la que llegó Eager fue: “Si el uso de un
algoritmo sencillo proporciona casi la misma ganancia que
uno más caro y más complejo, es mejor utilizar el más
sencillo”.
Estabilidad
- El sistema nunca esta en equilibrio por la actualización
constante de las tablas de las máquinas, así una máquina
podría pensar que otra esta actualizada sin que sea así.

Ejemplo de algoritmos de asignación de procesadores
Un algoritmo determinista según la teoría de gráficas
Para sistemas que constan de procesos con requerimientos conocidos de
CPU y memoria, además de una matriz conocida con el tráico promedio
entre cada pareja de procesos. Si el número de CPU es menor que el
número de procesos, habrá que asignar varios procesos al mismo CPU. La
idea es llevar a cabo esta asignación de forma que se minimice el tráfico en
la red.
Sea la la siguiente gráfica de procesos, los arcos indican el nivel de
comunicación entre los procesos.
Una posible asignación es la siguiente:
CPU1
CPU2
CPU3
3
B
2
C
3
1
F
2
E
8
5
4
6
3
1
5
4
G
4
H
2
3
B
2
C
3
CPU3
D
A
1
F
2
2
E
8
5
4
6
3
1
28 unidades
5
4
G
4
H
2
I
Podemos observar que la segunda asignación es la mejor.
Un algoritmo centralizado
Arriba-abajo (Mutka y Livny, 1987) es centralizado. Usa una tabla de uso,
con una entrada por cada estación de trabajo personal.
Si un proceso se ejecuta en otra máquina, la máquina origen
acumula puntos de penalización cada segundo. Si tiene solicitudes
pendientes no satisfechas, los puntos de penalización se restan de su
entrada en la tabla de usos. Si no existen solicitudes pendientes y ningún
procesador esta en uso, la entrada de la tabla de usos se desplaza un cierto
número de puntos hacia el cero.
Si la puntuación asociada a una estación de trabajo en la tabla de
usos es positiva, indica que la estación de trabajo es un usuario de los
recursos del sistema. Si tiene una puntuación negativa indica que necesita
recursos, si es cero es neutra.
El objetivo de este algoritmo es asignar la capacidad de manera justa.
Su desventaja es que en sistemas grandes con muchos nodos crea cuellos
de botella.
Un algoritmo jeráquico
D
A
2
Otra posible asignación es:
CPU1
CPU2
30 unidades
Para este tipo de algoritmo es necesario una gran cantidad de procesadores,
los cuales se agrupan por jerarquías, en un primer nivel (el nivel más alto)
un grupo de procesadores forman el comité de coordinadores, en el
siguiente nivel están los jefes de departamento. Los niveles pueden ser n,
I
24
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
todo dependerá del número de procesadores. En el último nivel están los
trabajadores. Este algoritmo es utilizado en el sistema MICROS.
Cuando una tarea requiere de varios procesadores, entonces la
solicitud se hace a los jefes de departamento (o el nivel anterior al de los
trabajadores), si estos no la pueden resolver la envían a su jefe inmediato,
hasta alcanzar un nivel en donde se pueda resolver el problema. El
administrador divide la solicitud en partes y los esparce entre los
administradores por debajo de él, quienes repiten la operación hasta llegar
a los trabajadores. Se señalan a los procesadores elegidos para realizar la
tarea como ocupados y se informa de regreso en el árbol.
Este algoritmo crea tráfico en la red cuando las ws están
subcargadas (desempleadas), pero es mejor en este momento y crear
tráfico cuando el sistema esta sobrecargado.
Una posible modificación a este algoritmo es combinar el
algoritmo anterior y este. Si una ws esta sobrecargada deberá intentar
deshacerse de trabajo, y cuando este subcargada debe tratar de conseguir
trabajo.
Se puede manejar un historial de máquinas que estén crónicamente
subcargadas o sobrecargadas.
Un algoritmo de remates
Comité de
Coordinadores
coordinadores
Jefes de departamento
Trabajadores
Este algoritmo fue creado por Ferguson
En este caso se crea una comunidad económica en donde los
procesos compran tiempo de CPU para terminar su trabajo. Los
procesadores venden sus ciclos al mejor postor. El precio de un procesador
va de acuerdo a su velocidad, tamaño de memoria, hardware y a lo que
pagó el último cliente, incluso el tiempo de respuesta.
Cuando se desea iniciar un proceso hijo, verifica si alguien ofrece el
servicio que necesita y elije el mejor. Genera una oferta. Los procesadores
reúnen todas las ofertas y eligen una. Se informa a los ganadores y
perdedores.
Un algoritmo heurístico distribuido iniciado por el emisor
Planificación en Sistemas Distribuidos
Este algoritmo es el segundo algoritmo de Eager mencionado en páginas
anteriores.
La desventaja de este algoritmo es que si casi todas las ws están
sobrecargadas entonces se enviarán pruebas de forma constante en vano.
La red se sobrecargará cuando más trabajo existe.
Cada máquina se puede planificar de forma independiente, pero si existen
procesos que interactúan entre sí y que se ejecutan en diferentes
procesadores habrá problemas. Por ejemplo, supongamos que A y B son
procesos que van a comunicarse, lo mismo ocurre con C y D; supongamos
que A y C se ejecutarán en el procesador 1, y B y D en el procesador 2,
cuando A es despachado en el procesador 1 , D es despachado en el
procesador 2, como A neesita comunicarse con B entonces se interrumpe
su ejecución y lo mismo sucede con D en el procesador 2, en el procesador
1 se despacha ahora C y en el procesador 2 B; esto significa que la
comunicación no se esta llevando a cabo de forma eficiente, y se pierde
tiempo de cómputo.
Un algoritmo heurístico distribuido iniciado por el receptor
Este algoritmo es complementario al anterior.
Cuando un proceso termina, el sistema verifica si la ws donde
terminó el proceso tiene suficiente trabajo. En caso contrario, elige alguna
máquina al azar y le solicita trabajo. Si no encuentra trabajo en N pruebas,
el receptor deja de preguntar por cierto tiempo, e intenta de nuevo.
25
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Ousterhout (1982) propuso algoritmos basados en un concepto llamado
coplanificación, el cual toma en cuenta los patrones de comunicación entre
los procesos durante la planificación para garantizar que todos los
miembros de un grupo se ejecuten al mismo tiempo.
de un límite finito conocido, es síncrono. Un sistema que no tiene esta
propiedad es asíncrono.
Tolerancia de fallas
El objetivo del diseño y construcción de sistemas tolerantes a fallas
consisten en garantizar que el sistema continúe funcionando de manera
correcta como un todo, incluso en la presencia de fallas.
El método general para la tolerancia de fallas consisten en el uso de
redundancia. Existen tres tipos posibles:
 Redundacia de la información. Se agregan bits para poder
recuperar los bits revueltos.
 Redundacia del tiempo. Se realiza una acción y en caso necesario
se vuelve a realizar. Este tipo de redundacia es de utilidad cuando
las fallas son transitorias o intermitentes.
 Redundancia física. Se trata de agregar equipo adicional.
Formas de organizar procesadores
1. Réplica activa
2. Respaldo primario
Tolerancia de fallas mediante réplica activa (método de la máquina de
estados)
Las solicitudes deben ser recibidas y procesados en el mismo orden.
Un sistema es tolerante de ka fallas si puede sobrevivir a fallas de k
componentes, entonces son necesarios k+1 componentes.
Fallas del sistema
Tolerancia de fallas mediante respaldo primario
Fallas de componentes
Una falla es un desperfecto, causado por un error de diseño, de
fabricación, de programación, físico, tiempo, condiciones ambientales, etc.
Las fallas se clasifican en:
-Transitorias. Ocurren una vez y después desaparecen.
-Intermitente. Desaparece y reaparece.
-Permanente. Continua existiendo hasta reparar el componente con el
desperfecto.
Se pueden distinguir dos tipos de fallas del procesador:
1. Fallas silentes. Un procesador que fallas solo se detiene y no
responde a las entradas subsecuentes ni produce más entradas
(también se llaman fallas de detención).
2. Fallas bizantinas. Un procesador que falla continúa su ejecución,
proporcionando respuestas incorrectas a las preguntas, y
posiblemente trabajando de manera maliciosa junto con otros
procesadores que han fallado, para dar la impresión de que todos
funcionan de manera correcta aunque no sea así.
Sistemas síncronos vs. Asíncronos
En el contexto de la investigación relativa a la tolerancia a fallas, un
sistema que tiene la propiedad de responder siempre a un mensaje dentro
Uso de redundancia
2.Realiza el
trabajo
1.Solicitud
Cliente
3.Actualiza
Primario
6.Respuesta
Respaldo
4.Realiza el
trabajo
5.Reconocimiento
Acuerdos en sistemas defectuosos
-El problema de los dos ejércitos
-El problema de los generales bizantinos
26
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
4. Comunicación en los sistemas distribuidos
La diferencia más importante entre un sistema distribuido y un sistema con
un procesador es la comunicación entre procesos. En un sistema con un
procesador se supone la existencia de una memoria compartida, lo cual no
existe en un sistema distribuido.
La comunicación entre procesos debe respetar reglas llamadas
protocolos.
Protocolos con capas
Para que dos procesos logren la comunicación se deben poner de acuerdo
en varios aspectos como, cuántos voltios hay que utilizar para señalar un
bit 0 y un bit 1; cómo detectar el fin de un mensaje, etc.
Para facilitar este trabajo la organización internacional de
estándares (internacional standards organization- ISO) ha desarrollado un
modelo de referencia llamado el modelo de referencia para interconexión
de sistemas abiertos, lo cual se abrevia como ISO OSI o el modelo OSI.
El modelo OSI está diseñado para permitir la comunicación de los
sistemas abiertos. Un sistema abierto es aquel preparado para comunicarse
con cualquier otro sistema abierto mediante estándares que gobiernan el
formato, contenido y significado de los mensaje enviados y recibidos.
Un protocolo es un acuerdo entre las partes acerca de cómo debe
desarrollarse la comunicación.
El modelo OSI maneja dos tipos generales de protocolos
(conexiones).
1. Protocolos orientados a la conexión. Antes de intercambiar datos,
el emisor y el receptor deben establecer en forma explícita una
conexión y tal vez el protocolo.
2. Protocolos son conexión. No es necesaria una negociación previa.
En el modelo OSI, la comunicación se divide en 7 niveles o capas. Cada
capa se maneja de forma independiente y se encarga de un aspecto
específico. Cada capa proporciona una interfaz con la capa por encima de
ella. La interfaz es un conjunto de operaciones que juntas definen el
servicio que la capa está preparada para ofrecer a sus usuarios.
La ventaja de un protocolo por capaz es su independencia, ya que
una capa puede modificarse o mejorarse sin afectar a las demás.
En el modelo OSI cuando se va a enviar un mensaje, este pasa por
todas las capas comenzando en la de Aplicación. Cada capa le coloca un
encabezado al frente o al final, al llegar el mensaje al otro lado, cada capa
lo va desmenuzando, quitándole el encabezado que le corresponde; la capa
que recibe el mensaje es la capa física.
Capas
Fisica, Enlace de Datos, Red, Transporte, Sesión, Presentación,
Aplicación
La colección de protocolos utilizados en un sistema particular se
llama una serie de protocolos o pila de protocolos.
Capa física
Su propósito es transportar el flujo de bits de una máquina a otra. El
protocolo de la capa física se encarga de la estandarización de las
interfaces eléctricas, mecánicas y de señalización. Maneja elementos como
la intensidad de la señal de red, cables, enchufes, voltajes, distancias entre
cables.
Capa de enlace de datos
La tarea principal de esta capa es agrupar a los bits en unidades llamadas
marcos o tramas, y detectar y corregir errores.
Uno de los mecanismos en la detección de errores es asignar
números secuenciales a las tramas y a cada trama colocarle una suma de
verificación, sino esta correcta la suma de verificación a la hora de recibir
el marco, entonces el receptor le pide al transmisor que vuelva a transmitir
el marco x.
Capa de red
La tarea principal de la capa de red es elegir la mejor ruta (a esta actividad
se le llama ruteo), la ruta más corta no siempre es la mejor, lo importante
es la cantidad de retraso, y esto complica los algoritmos de ruteo.
27
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
La capa de red maneja dos protocolos: X.25 (orientado a la conexión) y el
IP (sin conexión).
Capa de transporte
La tarea de la capa de transporte es proporcionar conexiones confiables y
económicas. Las conexiones confiables (orientadas a la conexión) se
pueden construir por arriba de X.25 o IP.
En X.25 los paquetes llegan en orden, en IP no, entonces la capa
de transporte es la encargada de ponerlos en orden.
El protocolo de transporte oficial ISO tiene cinco variantes, TP0,
TP1, … , TP4.
Los protocolos más utilizados en esta capa son: TCP (transmisión
control protocol- protocolo para el control de transmisiones), orientado a la
conexión y UDP (universal datagrama protocol- protocolo datagrama
universal) que es un protocolo sin conexión.
Capa de sesión
Esta es en esencia una versión mejorada de la capa de transporte.
Proporciona el control del diálogo, facilidades en la sincronización, la
posibilidad de establecer conexiones llamadas sesiones y la posibilidad de
transferir datos sobre las sesiones en forma ordenada.
En la práctica rara vez las aplicaciones soportan esta capa.
Capa de presentación
Esta capa trata los problemas relacionados con la representación y el
significado de los datos.
Capa de aplicación
Es una colección de varios protocolos para actividades comunes, como el
correo electrónico, la transferencia de archivos y la conexión entre
terminales remotas a las computadoras en una red. Esta capa contiene los
programas de usuario.
Protocolos utilizados: X.400 para correo electrónico, X.500 para
el servidor de directorios.
ATM Redes con modo de transferencia asíncrona
Nació a finales de los 80’s debido a la necesidad de enviar además de
datos a través de la red, también enviar voz.
Para esto se eligió una forma híbrida con bloques de tamaño fijo
sobre circuitos virtuales, para ambos tipos de tráfico. Este esquema es
llamado modo de transferencia asíncrona (ATM- Asynchronous Transfer
Mode), el cual se ha convertido en un estándar internacional.
El modelo ATM consiste en que un emisor establece primero una
conexión con él o los receptores. En el establecimiento de la conexión, se
determina una ruta desde el origen hasta el destino y se guarda la
información del ruteo en los conmutadores a lo largo del camino. Con esta
conexión se pueden enviar paquetes, pero el hardware los separa en
pequeñas unidades de tamaño fijo llamadas celdas, las cuales siguen todas
la misma ruta. Cuando ya no se necesita la conexión, ésta se libera y se
purga la información de ruteo de los conmutadores.
Ventajas
 Se pueden enviar datos, voz, televisión, video, radio, etc.
 Se puede dar el servicio de videoconferencias.
 La red solo ve celdas sin saber lo que contienen, esto representa
un ahorro, pues se puede enviar lo que sea por un solo cable.
 Una celda puede ir a varios destinos (multitransmisión)
 La multitransmisión se puede controlar de manera eficaz.
 Celdas de tamaño fijo y no de tamaño variable como los actuales
ATM tiene su propio protocolo de jerarquías.
Algunas de las implicaciones de ATM en sistemas distribuidos son:
 Velocidad a 155Mb/seg, a 622 Mb/seg y potencialmente a
25Gb/seg
 Tiene mayor ancho de banda
Los problemas son que este tipo de redes es más caro, y al utilizarlas
implicaría crear nuevos protocolos y arquitecturas de sistemas.
El modelo cliente servidor
Un sistema distribuido basado en LAN no utiliza de modo alguno
los protocolos con capas; y si lo hacen, solo utilizan un subconjunto de
toda una pila de protocolos.
El modelo cliente-servidor se presenta con la idea de estructurar
el sistema operativo como un grupo de procesos en cooperación, llamados
servidores, que ofrezcan servicios a los usuarios, llamados clientes. Las
28
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
máquinas de los clientes y servidores ejecutan el mismo micronúcleo
(generalmente) y ambos se ejecutan como procesos de usuario.
Este modelo se basa usualmente en un protocolo
solicitud/respuesta sencillo y sin conexión. El cliente es quien solicita al
servidor algún servicio, y el servidor es quien atiende la solicitud y regresa
los datos solicitados o un código de error si algo falló.
Ventajas
 Sencillez. El cliente envía un mensaje y obtiene respuesta.
 Eficiencia. La pila del protocolo es más corta y por tanto más
eficiente. No es necesario implantar capas como la de sesión o red y
transporte, ya que este trabajo lo hace el hardware.
 Se reducen los servicios de comunicación. Solo necesitamos las
llamadas send (enviar) y receive (recibir).
Direccionamiento
Para que un proceso envíe un mensaje a otro proceso que esta en otra
máquina, es necesario que el primer proceso sepa donde esta el otro
proceso (su dirección).
El primer acercamiento para resolver el problema de cómo
identificar un proceso, es asociarle a cada máquina una dirección, aunque
esto implicaría que cada máquina solo puede ejecutar un proceso. Para
resolver esta limitante, entonces se podrían dar identificadores a los
procesos y no a las máquinas, pero ahora surge el problema de cómo
identificar dos procesos. Un esquema común consiste en utilizar nombre
con dos partes, una para especificar la máquina y la otra para especificar el
proceso.
Sin embargo este tipo de direccionamiento no es bueno, ya que
cada usuario debe conocer la dirección del servidor y esto ya no es
transparente. Si el servidor falla y su dirección cambia, entonces se deben
recompilar los programas que utilicen ese servidor.
Una alternativa es que cada proceso elija su identificador de un
gran espacio de direcciones dispersas, como el espacio de enteros de 64
bits. La posibilidad de que dos procesos elijan el mismo número es muy
pequeña y el método puede utilizarse en sistemas extensos. ¿Cómo sabe el
núcleo emisor a qué máquina enviar el mensaje? En una LAN que soporte
transmisiones, el emisor puede transmitir un paquete especial de
localización con la dirección del proceso destino. Todas las máquinas de la
red lo recibiran y los núcleos verificarán si la dirección es la suya, en este
caso, regresa un mensaje “aquí estoy” con su dirección en la red. El núcleo
emisor utiliza entonces esa dirección y la captura, para evitar el envío de
otra transmisión la próxima vez que necesite al servidor.
Este último esquema tiene un problema: la carga adicional en el
sistema. Esto se evita utilizando una máquina adicional para la asociación
a alto nivel de los nombres de los servicios con las direcciones de las
máquinas. Así se utilizan nombres de procesos y no números. Cada vez
que se ejecute un cliente, primero va al servidor de nombres, y pide el
número de la máquina donde se localiza algún servidor. Así las direcciones
se ocultan. Este método tiene la desventaja de utilizar un componente
centralizado.
Primitivas con bloqueo vs. Sin bloqueo
La forma de comunicación entre los procesos es el intercambio de
mensajes, para lo cual son necesarias ciertas primitivas como send para
enviar y receive para recibir.
Existen dos tipos de primitivas: con bloqueo o sin bloqueo.
Primitivas con bloqueo (síncronas). Al invocarse un send o un receive, el
control del proceso no regresas hasta que se haya enviado el mensaje o
hasta que se haya recibido un mensaje en el caso de receive, mientras tanto
el proceso queda bloqueado. En este caso la desventaja esta en que el CPU
esta inactivo durante la transmisión de los mensajes.
Primitivas sin bloqueo (asíncronas). Tanto send como receive no tiene
bloqueo. En el caso de send, esta primitiva coloca el mensaje en el buffer
de mensaje y regresa el control inmediatamente sin que el mensaje haya
sido enviado. El problema esta en saber cuando se puede volver a utilizar
el buffer de mensajes.
Existen dos soluciones a este problema. La primera es que el
núcleo copie el mensaje a un buffer interno del núcleo y luego permita el
proceso continuar. Así el proceso permanecerá bloqueado mientras se lleva
a cabo la copia. La desventaja es que cada mensaje debe ser copiado del
espacio del usuario al espacio del núcleo. Esto puede reducir el desempeño
del sistema.
29
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
La segunda solución es interrumpir al emisor cuando el mensaje
ha sido enviado y hacerle saber que ya puede usar nuevamente el buffer de
mensajes. Este método es eficiente, pero es muy difícil escribir los
programas en forma correcta y es casi imposible depurarlos cuando están
incorrectos.
En el caso de un receive sin bloqueo, éste solo avisa al núcleo de
la localización del buffer y regresa el control inmediatamente. Para hacer
que éste espere se utilizaría un wait.
En las primitivas síncronas puede suceder que un send o receive
se queden esperando por siempre, así que para evitarlo se utilizan los
llamados tiempos de espera, si en este tiempo nada llega, la llamada send
termina con un estado de error.
Primitivas almacenadas en buffer vs. No almacenadas
Las primitivas anteriores son primitivas no almacenadas, esto es, los
mensajes son enviados a una dirección específica. El proceso receptor se
bloquea mientras copia el mensaje a un buffer. Esto funciona bien mientras
el receptor este siempre listo para escuchar un mensaje. Pero cuando
primero se ejecuta send y luego receive hay problemas, puesto que la
llamada a receive es el mecanismo que indica al núcleo del servidor la
dirección que utiliza el servidor y la posición donde colocar el mensaje que
está por llegar; entonces si primero llega un mensaje, el servidor no sabrá
de quién es y dónde ponerlo.
Soluciones:
1. Confiar que se va a ejecutar siempre un receive antes de un send.
Mala idea.
2. Hacer que el transmisor realice varios intentos para enviar su
mensaje, pero si el servidor esta muy ocupado, otros esperarán un
tiempo y luego se rendirán.
3. Que el núcleo receptor mantenga pendientes los mensajes. Si no
ocurre un receive en un determinado tiempo, el mensaje es
descartado.
4. Utilizar un buzón donde almacenar los mensajes. Un proceso que
va a recibir mensajes pide al núcleo que le sea creado un buzón,
en donde le depositarán los mensajes y él los irá leyendo. A esta
técnica se le conoce como primitiva con almacenamiento en
buffers.
El problema con los buzones es que son finitos y se pueden llenar.
Soluciones:
1. Mantener pendientes los mensajes
2. Descartarlos
3. El cliente debe verificar primero si hay espacio, si existe entonces
enviar mensaje sino bloquearse.
Primitivas confiables vs. No confiables
Cuando el cliente envía un mensaje, a pesar de utilizar primitivas con
bloqueo, no existe garantía de que el mensaje haya sido entregado. El
mensaje pudo haberse perdido.
Existen tres enfoques de este problema:
1. Volver a definir la semántica de send para hacerla no confiable,
es decir, la primitiva no se encarga de verificar que su mensaje
haya sido entregado y toda la responsabilidad de comunicación
confiable se deja en manos del usuario.
2. El núcleo de la máquina receptora envía un reconocimiento al
núcleo de la máquina emisora. El reconocimiento va de núcleo a
núcleo, así ni el cliente ni el servidor se dan cuenta de esto. El
núcleo entonces liberará al proceso cuando reciba el
reconocimiento.
3. Aprovechar el hecho de que en la comunicación cliente-servidor
se realiza de la siguiente manera: el cliente le envía un mensaje de
solicitud al servidor y el servidor le da una respuesta al cliente.
Entonces no hay mensaje de reconocimiento por parte del núcleo
del servidor, sino que la respuesta del servidor funciona como
reconocimiento. Así, el emisor (cliente) permanece bloqueado
hasta que regresa la respuesta. Si se tarda demasiado, el núcleo
emisor puede enviar la solicitud nuevamente.
En este método no existe reconocimiento para la respuesta, esta
omisión puede ocasionar problemas si el servicio solicitado por el cliente
requiere cómputo extenso, porque el servidor no se enteraría si el cliente
recibió o no la respuesta.
30
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Para solucionar esto se envía reconocimiento de la respuesta en
base a un cronómetro, si la respuesta llegó rápido, no hay reconocimiento,
si tardó demasiado si hay reconocimiento.
Llamada a un procedimiento remoto (RPC- Remote
Procedure Call)
Birrel y Nelson abordaron este tema en 1984.
En este esquema el programador no se preocupa por la transferencia de
mensajes.
Mediante RPC se puede invocar la ejecución de un procedimiento
en la máquina A que no está en A, sino en B.
Operación básica de RPC.
De manera convencional, cuando un procedimiento es invocado,
la dirección que tiene el registro apuntador a la próxima instrucción (IP) es
almacenada en la pila, y el registro apuntador será cargado con la dirección
del procedimiento invocado, cuando el procedimiento invocado termina,
entonces el registro IP es cargado con la dirección que esta en el tope de la
pila y sigue la ejecución del programa.
En la mayoría de los casos es necesario enviar parámetros de
entrada y obtener parámetro de salida. Los lenguajes de programación
como C, utilizan dos tipos de paso de parámetros: por valor o por
referencia.
En un paso de parámetros por valor se pasa el valor de la variable
y no hay problema, puesto que no se modifica la variable.
En el caso del paso de parámetro por referencia, lo que se pasa es
la dirección, y es posible realizar modificaciones sobre esta variable.
Existe otra forma de pasar parámetros que no maneja el lenguaje
C, este mecanismo se llama copia/restauración. Quien recibe la llamada
copia la variable en la pila, como en la llamada por valor, y entonces copia
de regreso la variable después de la llamada, escribiendo sobre el valor
original.
El objetivo de un RPC es que se parezca lo más posible a una
llamada local (transparencia).
Cuando un servidor se ejecuta por primera vez, lo primero que
hace es exportar su interfaz, esto es, el nombre de los servicios y sus
parámetros, especificando si son parámetros de entrada o de salida, su
versión, su identificador único y su asa. Un proceso llamado conector es
quien recibe la interfaz y realiza el registro.
El conector además de realizar el registro de un servidor, puede
darlo de baja y buscar algún servidor.
La versión de un servicio es importante, pues indica si un servidor
ha sido actualizado o no. Así el conector contendrá las últimas versiones
de los servidores.
Este método de exportación e importación es altamente flexible.
Por ejemplo, puede manejar varios servidores que manejen la misma
interfaz. Pero tiene sus desventajas. El conector se puede convertir en un
cuello de botella, además un proceso puede tener un tiempo de vida corto y
el tiempo entre importar y exportar interfaces puede ser significativo.
Semántica de RPC en presencia de fallas
El objetivo es ocultar la comunicación, al hacer que las llamadas a
los procedimientos remotos se parezcan a los locales. Sin embargo, esto no
es tan sencillo.
Existen cinco clases distintas de fallas que pueden ocurrir en los
RPC’s.
1. El cliente no puede localizar al servidor
2. Se pierde el mensaje de solicitud del cliente al servidor
3. Se pierde el mensaje de respuesta del servidor al cliente
4. El servidor falla antes de recibir una solicitud
5. El cliente falla después de enviar la solicitud
El cliente no puede localizar al servidor
Debido a que el servidor cambió de dirección y el cliente no se actualizó
(tal vez preguntó antes de que se actualizara).
En UNIX se retorna -1 y una variable global errno, pero si -1 es un valor
válido, habrá confusión acerca de si fue error o el resultado de alguna
operación.
Otro mecanismo que no tiene la desventaja anterior es que el error
provoque una excepción. Por ejemplo se podrían utilizar señales. Pero no
todos los lenguajes tienen excepciones y/o señales. Además el uso de estos
mecanismos, destruyen la transparencia.
31
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Pérdida de mensajes de respuesta
Se puede utilizar un cronómetro, si no llega respuesta en un periodo
razonable, se envía la solicitud nuevamente. Pero qué se perdió, la
solicitud, la respuesta o el servidor es lento?
Si es la respuesta la que se perdió, entonces esto es más difícitl de
enfrentar.
Algunas operaciones se pueden repetir muchas veces sin efectos
colaterales y sin causar daños. A esta propiedad se le llama idempotencia.
Pero existen operaciones que no son idempotentes, por ejemplo retirar
dinero de un cajero automático.
Una posible solución es asociar un número secuencial a cada
solicitud. Entonces el núcleo del servidor debe mantener un registro del
número secuencial más reciente, así podrá notar la diferencia entre una
solicitud original y las retransmisiones. Como protección adicional se
podría colocar un bit en el encabezado del mensaje para distinguir las
solicitudes originales de las retransmisiones.
Fallas del servidor
Puede suceder que:
-El servidor falla después de responder
-El servidor falla antes de responder
Existen tres escuelas en torno a lo que se debe hacer en este caso:
1. Semántica al menos una vez. Seguir intentando hasta conseguir
una respuesta (el servidor puede volver a arrancar o se reconecta
un nuevo servidor). Garantiza que la RPC se realiza al menos una
vez o más veces.
2. Semántica a lo más una vez. Se da por vencido inmediatamente e
informa de la falla. La RPC se realiza a lo más una vez o ni una
sola vez.
3. No garantiza nada.
Fallas del cliente
Cuando un cliente falla después de enviar una solicitud sin que haya
recibido respuesta, existirá una labor de cómputo de la cual nadie espera
respuesta. A esta labor de cómputo no deseada se le llama huérfano.
Problemas que puede provocar un huérfano.
- desperdiciar ciclos de cpu
- bloquear archivos o capturar recursos valiosos
- crear confusión (si el cliente vuelve a arrancar y realiza
de nuevo la RPC, la respuesta puede ser inmediata y
entonces no sabrá lo que paso)
¿Qué hacer con los huérfanos?
Nelson (1981) hizo un estudio acerca de este problema y propuso lo
siguiente:
1. Exterminación. Antes de enviar la solicitud, el resguardo del
cliente crea un registro de lo que se va a hacer y lo almacena en
dusci. Al vo9lver a arrancar (el cliente) se verifica el contenido
del registro y se elimina al huérfano.
Desventaja. Gasto en la escritura y disco.
Si hay más huérfanos es muy probable que no se puedan localizar
No es un buen método.
2. Reencarnación. Se divide el tiempo en épocas. Cuando el cliente
arranca de nuevo envía un mensaje a todas las máquinas que
declaran el inicio de una época. Se eliminan los cómputos
remotos que estén fuera de época.
3. Reencarnación sutil. Utiliza también épocas, pero el que está
ejecutando el RPC verifica si existe el dueño de la RPC cuando le
llega un mensaje de cierta época, si no existe elimina la
operación.
4. Expiración. Se asigna a cada RPC una cantidad de tiempo, si no
puede terminar en ese tiempo pide otro quantum, sino entonces se
elimina el proceso.
En la práctica ninguno es recomendable. La eliminación de un
huérfano puede traer consecuencias imprescindibles.
Protocolos RPC
Orientado a la conexión
Ventaja. Comunicación fácil
Desventaja: Pérdida de desempeño
32
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
Sin conexión
En este caso se debe adaptar el protocolo para garantizar seguridad.
Algunos sistemas utilizan UDP o UDP integrado a IP.
Ventajas
-El protocolo ya ha sido diseñado
-Estos protocolos son utilizados en casi todos los sistemas UNIX.
UDP e IP son soportados por muchas redes existentes.
Desventajas
-Cada protocolo forma un paquete con varios campos y además ambos
realizan una suma de verificación.
-Lo anterior hace que se pierda el desempeño.
Alternativa
-Utilizar un protocolo especializado para RPC, el cual debe ser
diseñado e implantado por el programador.
Con respecto a la longitud del paquete y el mensaje, sale más caro
hacer 64 RPC de 1k que 1 RPC de 64k. Por lo tanto el protocolo debe
permitir las transmisiones largas (Sun Microsystems 8k, el límite de
Ethernet es de 1536 bytes)
Reconocimientos
1) Protocolo detenerse y esperar. Envía un paquete y
espera reconocimiento. Los paquetes son enviados uno a
uno.
2) Protocolo de chorro. El cliente envía todos los paquetes
tan pronto como pueda. Así el servidor reconoce todo el
mensaje al recibir todo el paquete, y no uno por uno.
Propiedades del protocolo detenerse y esperar
Si se daña o pierde un paquete, el cliente no puede recibir a tiempo un
reconocimiento, por lo que vuelve a transmitir el paquete defectuoso.
En el protocolo de chorro, si se pierde el paquete 1, pero el llega de
manera correcta, puede abandonar todo y esperar a que el cliente vuelva a
transmitir todo el mensaje o esperar con la esperanza de que 3 llegue bien
y luego pedirle al cliente que envíe el paquete 1. A esto se le llama
repetición selectiva.
Comunicación en grupo
Para RPC la comunicación solo es entre dos partes, el cliente y el servidor.
A veces existen casos donde es necesario que varios procesos se
comuniquen (por ejemplo, enviar un mensaje a todos los usuarios avisando
que el sistema será dado de baja temporalmente para darle
mantenimiento).
Un grupo es una colección de procesos que actúan juntos en cierto sistema
o alguna forma determinada por el usuario.
La propiedad fundamental de un grupo es que cuando se envía un mensaje
al propio grupo, todos los miembros de este lo reciben. A este tipo de
comunicación se le llama uno-muchos (la de cliente-servidor es una
comunicación puntual).
Los grupos son dinámicos, se pueden crear nuevos grupos y destruir
grupos anteriores. Un proceso puede unirse a un grupo o dejarlo. Un
proceso puede ser miembro de varios grupos a la vez.
La implantación de comunicación en grupo depende del hardware en gran
medida.
- Multitrasmisión. Cuando se envía un mensaje a un
grupo, éste se recibe automáticamente en todas las
máquinas que escuchan esa dirección. Cada grupo
escucha una dirección de multitransmisión.
- Transmisión simple. Los procesos deben ser concientes
acerca de a cuál grupo pertenecen, porque el mensaje lo
verifican todos y solo los miembros del grupo al cual va
dirigido el mensaje lo toman. La desventaja es que si un
proceso no pertenece al grupo entonces descarta el
mensaje, pero esto implica desperdicio de tiempo.
- Unitransmisión. El mensaje es enviado a cada proceso
uno a uno, es decir, si el grupo tiene n miembros, se
envían n paquetes.
Grupos cerrados vs. Grupos abiertos
Los procesos pueden clasificarse en grupos cerrados y grupos abiertos. En
un grupo cerrado, solo los miembros del grupo pueden enviar mensajes al
grupo. En un grupo abierto, cualquiera puede enviar mensajes al grupo.
Grupos de compañeros vs. Grupos jerárquicos
Otra forma de clasificar a los grupos es en grupos de compañeros y grupos
jerárquicos. En un grupo de compañeros todos los procesos son iguales, la
ventaja es que si uno falla los demás pueden seguir trabajando. La
desventaja es que al tomar una decisión se debe votar, esto implica mayor
retraso y costo.
33
Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco
BUAP
En el caso de un grupo jerárquico existe un jefe o coordinador, la ventaja
es que hay menos retraso y costo, la desventaja es que si falla el jefe, el
grupo hace un alto.
Membresía del grupo
Para manejar la creación y eliminación de grupos, así como permitir a los
procesos que se unan o dejen grupos se puede utilizar un servidor de
grupos. Este servidor debe mantener una base de datos acerca de qué
grupos existen y quiénes lo forman.
La desventaja es que si el servidor falla, se pierde información acerca de
grupos y tal vez deban ser reconstruidos los grupos totalmente.
Otro método es manejar la membresía de grupo en forma distribuida. En
un grupo abierto un extraño puede enviar un mensaje a todos los miembros
del grupo para anunciar su presencia. En un grupo cerrado es necesario
algo similar. Para salir del grupo se debe enviar mensaje de despedida a
todos.
Si un miembro falla, al no haber mensaje de despedida, los otros
miembros se darán cuenta al tratar de comunicarse con él, entonces sino
responde, lo eliminan de su grupo.
34