Notasdistribuidos

Sistemas Operativos Distribuidos
MC Hilda Castillo Zacatelco

BUAP

1. Introduccin
De 1945 a 1985, las computadoras eran grandes y caras. Sin embargo a
mitad de la dcada de los 80s, dos avances tecnolgicos comenzaron a
cambiar esta situacin:
1. Desarrollo de poderosos microprocesadores.
2. Invencin de redes de rea local de alta velocidad (LAN) y redes
WAN.
Un sistema distribuido consiste de una coleccin de computadoras
autnomas 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 diseado deben percibir
una sola computadora y no un sistema implementado por muchas
computadoras en diferentes lugares.
Definicin. Un sistema distribuido es una coleccin de computadoras
independientes que aparecen ante los usuarios del sistema como una nica
computadora.
Esta definicin tiene dos aspectos:
1. El hardware: las mquinas son autnomas.
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 aerolnea
- Fbrica 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
Economa. Los microprocesadores ofrecen mejor proporcin
precio/rendimiento que los mainframes, pues se pueden reunir un
gran nmero de CPUs baratos en un mismo sistema y dado el
avance tecnolgico de estos, se puede dar un mejor rendimiento
que un solo mainframe.
Velocidad. Un sistema distribuido puede tener mayor poder de
cmputo que un mainframe.
Distribucin inherente. Algunas aplicaciones utilizan mquinas
que estn separadas a cierta distancia. Por ejemplo, trabajo
cooperativo apoyado por computadora, juegos cooperativos
apoyados por computadora.
Confiabilidad. Si una mquina se descompone, el sistema puede
sobrevivir como un todo.
Crecimiento por incrementos. Se puede aadir poder de cmputo
en pequeos 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 comn.
Dispositivos compartidos. Permiten que varios usuarios
compartan perifricos caros como scanners o impresoras a color.
Comunicacin. Facilita la comunicacin de persona a persona;
por ejemplo, mediante correo electrnico, FAX, chats, foros, etc.
Flexibilidad. Difunde la carga de trabajo entre las mquinas
disponibles en la forma ms eficaz en cuanto a costos.
Adems de las ventajas anteriores, podemos sumar dos ms en forma
general:

BUAP
Sistema de ficheros con raz nica. Este sistema de ficheros hace que
la administracin sea ms sencilla (no hay que administrar varios
discos independientemente) y deja a cargo del sistema varias de las
tareas.
Capacidad de comunicacin de procesos y de intercambio de datos
universal. Permite enviar seales 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 creacin. La Economa, la Velocidad y la Distribucin de
mquinas no tienen problemas de implantacin 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 mquina
caiga, se sigan dando todos los servicios. Esto nos lleva a la necesidad
de actualizar todas las rplicas de un servicio. Tambin 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
informacin que necesita. Adems tambin 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 nmero de nodos aumentan las
comunicaciones, por lo tanto se debe disear un sistema lo ms
escalable posible. Por ejemplo elegir una comunicacin todos contra
todos no es una solucin escalable.
Comunicacin. Estos sistemas tienen ms necesidad de
comunicacin que los sistemas normales, por lo tanto tenemos que
crear nuevos mtodos de comunicacin lo ms eficientes posibles.
Sistemas de ficheros con raz 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 cmo manejar los directorios /proa y /dev; los PIDs deberan
ser independientes para cada nodo, pero adems se incluye
informacin como /proa/cpuinfo, /proa/meminfo, etc. Entonces
debera 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 disear un nuevo
esquema para nombrar los dispositivos.
Capacidad de comunicacin de procesos y de intercambio de
datos universal. Para conseguir este objetivo necesitamos una forma
de distinguir unvocamente cada proceso del conjunto de
computadoras.
Redes. La red se puede saturar o causar otro problemas.
Seguridad. Como los datos son fciles de compartir entonces tambin
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
transmisin de los datos (nmero de bits por segundo que se pueden
transferir) es alta.
Sistema dbilmente acoplado. El retraso es grande y la tasa de
transmisin es baja.
Los sistemas fuertemente acoplados tienden a utilizarse ms como
sistemas paralelos.
Los sistemas dbilmente acoplados tienden a utilizarse como sistemas
distribuidos.
Clasificacin de Flynn (1972).

BUAP
Considera dos caractersticas el nmero de flujos de instrucciones y el

nmero 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 categoras de computadoras paralelas. Estos modelos
fsicos 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
perifricos 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 perifricos tambin
se comparten en la misma forma. Se les denomina sistemas
fuertemente acoplados. Para coordinar los eventos paralelos, la
sincronizacin e intercomunicacin entre procesos se utilizan
variables en la memoria comn.
Cuando todos los procesadores tienen igual acceso a todos los
perifricos el sistema se denomina simtrico (MP).
En un multiprocesador asimtrico 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 cdigo bajo la
supervisin del procesador maestro.
(Ejemplo Sequent S-81)
El modelo NUMA
La memoria est fisicamente distribuida entre todos los procesadores,
se llaman memorias locales. Es ms rpido acceder un dato en la
memoria local, para acceder informacin en una memoria remota
existe una demora debida a la red de interconexin(BBN TC-2000
Butterfly).
Adems 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 ms rpido es acceder a memoria local
- un poco ms lento es acceder la memoria global
- y por ltimo el ms 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 jerarquas de memoria en cada nodo procesador. Todas las
caches forman un espacio de direccionamiento global. El acceso a una
cache remota se facilita a travs de los directorios distribuidos de
cache los cuales en ciertas arquitecturas pueden estructurarse en forma
jerrquica.
Una de las mayores desventajas que poseen estos multiprocesadores
es la falta de escalabilidad debido a la centralizacin de la memoria
compartida.

BUAP
Multicomputadoras
Consisten de mltiples computadoras llamadas a menudo nodos
interconectados por una red de paso de mensajes. Cada nodo es un
sistema autnomo con su procesador, su memoria y a veces
perifricos de E/S.
La red de paso de mensajes provee un mecanismo de
comunicacin punto a punto. Todas las memorias locales con privadas
y son solo accesibles por el conjunto de procesadores locales del
nodo, por esta razn se las denomina mquinas NORMA (no remote
memory access).
El rango de transferencia de datos es similar a B-ISDN , utiizan

ATM como tcnica de switcheo
Con B-ISDN y ATM, se pueden trabajar sistemas distribuidos en
redes WAN.
Protocolo
Conjunto de reglas y formatos usados para la comunicacin entre
procesos para desempear una tarea.
Un protocolo tiene dos partes importantes:
1. Una especificacin de la secuencia de mensajes que debe ser
intercambiado
2. Una especificacin 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 ms 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 dbilmente acoplado. Permite que las mquinas y los
usuarios en un sistema distribuido sean independientes entre s en
lo fundamental, pero que interacten cuando sea necesario.
Software fuertemente acoplado. Las mquinas interactan 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, pases o continentes
Es necesario el ruteo de paquetes
El tiempo de transmisin 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 dbilmente acoplado en hardware dbilmente acoplado. Por
ejemplo una red de estaciones de trabajo conectadas mediante una
LAN.
Cada usuario tiene una estacin 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 estacin de trabajo, entonces su mquina se convierte en
terminal de otra mquina. Esto no es muy conveniente.

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 jerrquico de archivos (directorio raz,
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 mquina tiene un alto grado de
autonoma y existen pocos requisitos a lo largo de todo el sistema, se
llama sistema operativo de red.
Sistemas realmente destribuidos

Software fuertemente acoplado en
dbilmente 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 mquinas enlazadas mediante una
red pero que actan como un uniprocesador virtual.
Conclusin. Los usuarios no deben darse cuenta de la existencia
de varios CPU en el sistema.
Caractersticas de los sistemas distribuidos

Algunas de las caractersticas de los Sistemas Distribuidos son:
Recursos compartidos. Discos, impresoras, archivos, bases de
datos y otros objetos.
Manejador de recursos. Denota un mdulo de software que
maneja un conjunto de recursos de un tipo particular. Incluye
provisin 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 comunicacin se puede emplear alguno de los
siguientes modelos.
Modelo cliente-servidor. El ms comunmente usado. Los
servidores actan 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 comunicacin 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 aadidos sin interrumpir o
duplicar los servicios existentes.
La publicacin de documentos acerca del sistema es la clave de
esta caracterstica.
Los sistemas que son diseados para soportar recursos
compartidos que pueden ser expansibles en hardware y software son
llamados sistemas distribuidos abiertos.
Caractersticas de los sistemas distribuidos abiertos.
- Sus interfaces son publicadas
- Estn provistos de un mecanismo de comunicacin entre
procesos uniforme e interfaces pblicas para acceso a recursos
compartidos.
- Puede ser construido con hardware y software heterogneo.
Esquema global de proteccin
Concurrencia. Ejecucin 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 administracin de procesos
La misma apariencia del sistema de archivos en todas partes
Sistema de archivos global
Cada ncleo debe controlar sus propios recursos locales.

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 ejecucin. El despachador utiliza exclusin
mutua mediante semforos, monitores, etc., para evitar que dos CPU
elijan el mismo proceso para su ejecucin.
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 diseo
Flexibilidad
Transparencia.
Existen dos tipos de estructuras de los sistemas distribuidos.

- Los que utilizan ncleo monoltico en cada mquina, es decir, cada
mquina debe ejecutar un ncleo tradicional que proporcione la
mayora de los servicios.
- Los que utilizan un microncleo, es decir, el ncleo 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 diseo ms importantes

dentro de los sistemas distribuidos, pero tambin uno de los ms
complejos.
La transparencia puede darse en dos niveles:
Hacia los usuarios
Hacia los programas
Es ms fcil lograr la transparencia dirigida a los usuarios
mediante una interfaz con comandos que aunque se ejecuten en otra
mquina o hagan uso de varias mquinas, los usuarios no se dan
cuenta; que lograr la transparencia para los programas, pues para
accesar a archivos remotos por ejemplo deben establecer una
conexin, y esto ya no es transparente.
Existen distintos tipos de transparencia en un sistema distribuido.
Transparencia de localizacin. Los usuarios no pueden indicar la
localizacin de los recursos.
Transparencia de migracin.Los recursos se pueden mover a voluntad
sin cambiar sus nombres.
Transparencia de rplica. Los usuarios no pueden indicar el nmero
de copias existentes.
Transparencia de concurrencia. Varios usuarios pueden compartir
recursos de manera automtica.
La mayora de los sistemas distribuidos diseados a partir de cero

utilizan microncleo y servidores. El microncleo proporciona cuatro
servicios mnimos.
1. Un mecanismo de comunicacin entre procesos
2. Cierta administracin de la memoria
3. Una cantidad limitada de planificacin y administracin de
procesos de bajo nivel
4. Entrada/Salida de bajo nivel
Todos los dems servicios se implantan a manera de servidores a
nivel de usuario. Debido a esto es fcil implantar, depurar, e instalar o
modificar cierto servicios; esto no puede hacerse en un ncleo
monoltico. Esto es lo que da flexibilidad al microncleo.
Ventaja del ncleo monoltico. Rendimiento (es ms rpido), aunque
en la prctica esta ventaja ya no existe. (Sprite- ncleo monoltico,
Amoeba-microncleo)

BUAP
Confiabilidad
Escalabilidad
Este aspecto fue uno de los objetivos originales en la construccin de

sistemas distribuidos, la idea es que si alguna mquina falla, alguna
otra mquina se encargue del trabajo. Pero llevar a cabo esto en la
prctica es muy difcil.
Existen varios aspectos dentro de la confiabilidad.
La disponibilidad, se refiere a la fraccin de tiempo en que se
puede usar el sistema. Esta se mejora si en el diseo no se
exige el funcionamiento simultneo de un nmero sustancia
de componentes crticos 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 mtodos 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 caractersticas, que los distingue de los algoritmos
centralizados:
- Ninguna mquina tiene la informacin completa acerca del estado
del sistema
- Las mquinas toman decisiones solo con base en la informacin
local.
- La falla de una mquina no arruina el algoritmo
- No existe una hiptesis implcita de la existencia de una regla
global.
Desempeo
Otros temas bsicos de diseo son:
El mayor problema del desempeo en un sistema distribuido se da en

las comunicaciones, ya que estas son lentas, la lentitud se da ms en el
manejo de protocolo que en la transmisin fsica real.
Una posible solucin es verificar el tamao de grano. Si un
trabajo implica gran nmero de pequeos clculos que interacta
mucho, se dice que el trabajo exhibe un paralelismo de grano fino; si
el trabajo implica grandes clculos y la interaccin es poca, se dice
que exhibe un paralelismo de grano grueso.
Tambin es importante verificar si habr ganancia en la ejecucin
de un trabajo de forma remota, ya que habr trabajos pequeos que no
deben ser ejecutados remotamente, sino de manera local.
Tambin entra en juego la tolerancia a fallas, pues si un nodo falla
y estaba ejecutando un trabajo, otro nodo debe continuar con la
ejecucin del trabajo.
Nombres. Los procesos deben saber los nombres de los recursos

para accesarlos. Un nombre es resuelto cuando es trasladado a una
forma tal que puede ser usado para invocar una accin sobre el
recurso. En un sistema distribuido un nombre resuelto es
generalmente un identificador de comunicacin.
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 diseado 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.

BUAP
Comunicacin
Mantenimiento de la consistencia
Los componentes de un sistema distribuido estn separados lgica

y fsicamente, as que deben comunicarse para interactuar. La
comunicacin entre un par de procesos involucra:
- Transferencia de datos
- Sincronizacin en la recepcin y transmisin.
La programacin bsica utiliza primitivas de programacin que
desempean acciones de paso de mensajes.
El mecanismo de paso de mensajes puede ser:
Sncrono o con bloqueo. El transmisor espera despus de transmitir un
mensaje hasta que el receptor ha desempeado una operacin de
recepcin.
Asincrono o sin bloqueo. El proceso receptor se bloquea cuando
ningn mensaje esta actualmente disponible. El proceso transmisor se
bloquea si no existe mensaje a transmitir.
Mecanismos de comunicacin que utilizan paso de mensajes: canales,
sockets y puertos.
Modelos de comunicacin ms usados en sistemas distribuidos:
cliente-servidor, comunicacin en grupo para grupos de procesos
cooperativos.
Los problemas de consistencia surgen de la separacin de recursos de

procesamiento y concurrencia en sistemas distribuidos.
- Consistencia en la actualizacin
- Consistencia en la replicacin
- Consistencia en el cach
- Consistencia en las fallas
- Consistencia en el reloj
- Consistencia en la interfaz de usuario
Asignacin de la carga de trabajo

En un sistema distribuido existe un modelo bsico 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 dinmicamente a las tareas de
usuarios.
b) Uso de estaciones de trabajo vacas. Las tareas son
asignadas a estaciones de trabajo vacas o bajoutilizadas.
En sistemas distribuidos es comn que los servidores sean
computadoras multiprocesadores con memoria compartida.
Requerimientos de usuario
Los diseadores 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 distribucin en la
programacin de aplicaciones paralelas, interfaces de
programacin.
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 diseado especficamente
para sistemas distribuidos
- Emular un ambiente distribuido
Reconfigurabilidad

BUAP
El diseo de la escalabilidad de un sistema distribuido es

importante
Cambios a corto plazo en condiciones de tiempo de ejecucin
Evolucin a mediano y a corto plazo en tiempo de ejecucin
Calidad de servicio
-
Network File System, es como su nombre lo indica un sistema de archivos

distribuido a lo largo de una red de mquinas, con el objetivo de tener un
nmero arbitrario de usuarios compartiendo un sistema de archivos comn,
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.
Desempeo
Confiabilidad y disponibilidad
Seguridad
2. El sistema de archivos de red (NFS) de Sun.
NFS que fue diseado 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
soporta sistemas heterogneos; por ejemplo, clientes de MS-DOS que
utilizan servidores UNIX. Ni siquiera es necesario que todas las mquinas
utilicen el mismo hardware.
Tres aspectos de NFS son de inters: la arquitectura, el protocolo
y la implantacin.
Arquitectura de NFS.

BUAP
NFS posee dos tipos distintos de mquinas, 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 mquinas que operan como NFS Servidor, se encargan de
publicar sus directorios y responder a las peticiones de los NFS Cliente.
En la mayora de los casos, todos los clientes y servidores estn 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 mquinas diferentes, sin embargo, NFS permite que cada mquina sea
cliente y servidor al mismo tiempo.
Cada servidor NFS exporta uno o ms de sus directorios para su
acceso por parte de los clientes remotos. Cuando se dispone de un
directorio, tambin 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 automtica 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
jerarqua de directorios. Si as lo desea, un cliente sin disco puede montar
un sistema de archivos remoto en su directorio raz, 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 jerarqua local de
directorios, lo que produce un sistema de archivos parcialmente local y
parcialmente remoto.
As, la caracterstica bsica de la arquitectura de NFS es que los
servidores exportan directorios y los clientes los montan de manera
remota. Si dos o ms clientes montan el mismo directorio al mismo
tiempo, se pueden comunicar compartiendo archivos en sus directorios
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 slo estn ah, en la jerarqua de
directorios de varias mquinas 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 mquina 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
heterogneo, 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 anloga, 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 jerarqua 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 vlida 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 nmero de inodo del directorio, e
informacin de seguridad. Las llamadas posteriores para la lectura y
escritura de archivos en el directorio montado utilizan el identificador del
archivo.
10

BUAP
Otra alternativa a la versin de UNIX de Sun soporta tambin el

automontaje. Esta caracterstica 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
enva 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 esttico
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
slo se necesita que uno de ellos est activo) y se puede mejorar el
desempeo (al elegir el primero que responda, que supuestamente tiene la
menor carga).
NFS no da soporte para la rplica de archivos o directorios, el usuario
debe lograr que todos los sistemas de archivos sean iguales. En
consecuencia, el automontaje se utiliza con ms 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. Adems, tambin pueden tener
acceso a los atributos de un archivo, como el modo, tamao y tiempo de su
ltima modificacin.
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 enva al servidor un mensaje con el nombre del archivo,
una solicitud para buscarlo y regresar un identificador de archivo, que es
una estructura de identificacin del archivo. La llamada READ contiene al
identificador de archivo que se desea leer, el ajuste para determinar el
punto de inicio de la lectura y el nmero 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 despus se recupera, no se pierde informacin
acerca de los archivos abiertos, puesto que no hay ninguno. Un servidor
como ste, que no conserva informacin 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 posicin 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 rpidamente, se pierden todas las
conexiones abiertas, y fallan los programas cliente. NFS no tiene esta
caracterstica.
El mtodo NFS dificulta el hecho de lograr la semntica 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 cules son los archivos estn abiertos. Por lo tanto, NFS
necesita un mecanismo independiente adicional para controlar los
bloqueos.
NFS utiliza el mecanismo de proteccin de UNIX, con los bits rwx
para el propietario, grupo y dems personas. En un principio, cada mensaje
de solicitud slo contena 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 aos
de experiencia han demostrado que tal hiptesis era un tanto ingenua.
Actualmente, se puede utilizar la criptografa de claves pblicas 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 autenticacin, as como la dems
informacin, son mantenidas por el NIS (servicio de informacin de la
red). NIS se conoca antes como el directorio de pginas amarillas (yellow
pages). Su funcin es la de guardar parejas (clave, valor). Cuando se
proporciona una clave, regresa el valor correspondiente. No slo controla
las claves de cifrado, sino tambin la asociacin de los nombres de usuario
con las contraseas (cifradas), as como la asociacin de los nombres de
las mquinas con las direcciones de la red, y otros elementos.
Los servidores de informacin 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
11

BUAP
modificaciones deben ser realizadas nicamente en el maestro, que

entonces las propaga a los esclavos. Existe un breve intervalo despus de
una actualizacin en el que la base de datos es inconsistente.
Implantacin de NFS
La capa superior es la capa de llamadas al sistema, la cual controla las
llamadas como OPEN, READ y CLOSE. Despus de analizar la llamada y
verificar sus parmetros, 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, anloga 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 informacin
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 informacin 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
mquina donde se localiza dicho directorio. Entonces, entra en contacto
con la mquina 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 ncleo.
El ncleo construye entonces un vnodo para el directorio remoto y
pide el cdigo del cliente NFS para crear un rnodo (inodo remoto) en sus
tablas internas, con el fin de mantener el identificador del archivo. El
vnodo apunta al rnodo. As, cada vnodo de la capa VFS contendr en
ltima instancia una referencia a un rnodo en el cdigo 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 anlisis del

nombre de la ruta de acceso, el ncleo 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 cdigo del cliente NFS que abra el archivo. El cdigo 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
enva un asa de archivo para el acceso a un archivo, verifica el
identificador y, si ste es vlida, sa utiliza. El proceso de validacin puede
incluir una clave de autenticacin 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. Despus de que la capa VFS del cliente ha
obtenido el bloque de 8K que necesitaba, emite en forma automtica una
solicitud del siguiente bloque, por lo que lo recibir rpidamente. Esta
caracterstica se conoce como lectura adelantada y mejora en forma
considerable el rendimiento.
Se sigue una poltica anloga para la escritura. Sin embargo, al cerrar
un archivo, todos sus datos se envan al servidor de manera inmediata.
Otra de las tcnicas 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
12

BUAP
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 trfico en la red.
Pero puede suceder que el cach no sea coherente.
Debido a la severidad potencial de este problema, la implantacin de
NFS hace varias cosas para mitigarlo. Una de ellas es que a cada bloque
cach se le asocia un cronmetro. 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. Adems, al abrir un archivo con cach, se enva un mensaje al
servidor para revisar la hora de la ltima modificacin. Si la ltima
modificacin 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 cronmetro del cach expira cada 30 segundos y todos los
bloques sucios (es decir, modificados) en el cach se envan al servidor.
An as, NFS ha recibido amplias crticas por no implantar de manera
adecuada la semntica apropiada de UNIX. Una escritura a un archivo de
un cliente podra o no ser vista cuando otro cliente lea el archivo, segn la
sincronizacin. Adems, al crear un archivo, esta accin podra 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 semntica del acceso a los archivos no est por
completo bien definida y la ejecucin de un conjunto de programas que
cooperen entre s podra producir diversos resultados, segn la
sincronizacin. Adems, lo nico con lo que trata NFS es con el sistema de
archivos. No hace referencia a otros aspectos, como la ejecucin de un
proceso. A pesar de todo, NFS es popular y tiene un uso muy extendido.
Ventajas de NFS
Reduccin 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.
Reduccin de Tareas de Administracin, debida a

centralizacin 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 Comunicacin 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 mquina de la red que este utlizando.
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 rpidos, 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 parmetros de
autenticacin, para dar dar seguridad a la informacion
transportada en la red.
la
Caractersticas Bsicas de NFS
Los servidores NFS no mantienen el estado de ninguno de sus

clientes, esto impulsa dos cualidades para NFS como lo son la
disminucin del tiempo de reestablecimiento de los servidores al
13

BUAP
momento de fallar. Asi como tambin impulsa a una gran

escalabilidad en el nmero de clientes a los cuales puede servir.
NFS realiza sus comunicaciones a travs 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 peticin ejecutada por
los clientes, de tal manera le asegura a los clientes que su peticin
fue atendida, de no recibir ningun ack, los clientes reenvian su
peticin.
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-ejecucin de las mismas.
NFS esta contruido sobre RPC (Remote Procedure Call).
NFS utiliza la permisologa 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 mquinas 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 mltiples
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.
Demonios involucrados en NFS.
14

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 estn 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
Opciones
ser
accesados
concurrentemente.
Corre tanto en el servidor
como en el cliente.
-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 especifca el tiempo
que tienen los clientes
para reclamar el bloqueo
Statd
portmap
de los archivos despus

que el servido arranca.
-t fija el nmero de
segundo a esperar antes
de retransmitir una
peticin de bloqueo a
otro servidor remoto.
nthreads # de hilos a
levantar para atender las
peticiones concurrentes.
Funciona en cooperacin 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 basndose en la
informacin del lockd.
Tambien se encarga de avisar
a los servidores en caso que
ocurra una cada de un
cliente que posea un archivo
bloqueado.
Es el demonio que permite a
los clientes NFS, descubrir
cual puerto esta siendo usado
por el servidor NFS para
prestar el servicio.
Recomendaciones de Seguridad.
15

BUAP
Debera estar configurado para dar acceso solo a ciertos clientes,

por lo que se debera configurar para utilizar autentificacin de
usuarios.
De ser posible deberan solo exportarse sistemas de archivos de

solo lectura.
Limitar el nmero 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 mquina sea tanto servidor como cliente NFS.
No permitir login a usuarios desde otras maquinas Servidores

NFS.
olo
Es "hablado" por el montd,

se
utiliza
para
la
negociacin 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 jerrquica 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.
Descripcin
Este es el protocolo que CREATE: Crea o Trunca un

acta despus que la fase de archivo
dentro
de
un
montaje
ha
concluido. directorio.
Permite
sistema
montado.
Protocolos Involucrados en el NFS
Nombre del
Protoc
NFS
NULL: no hace nada.

MNT: Retorna un asa de
archivo de la raz del
directorio
exportado,
tambin 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.
manipular
el LINK: Crea un enlace.
de
archivos
LOOKUP: Busca un archivo
en un directorio.
Peticiones Comprendidas
16

BUAP
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.
recursos y de hardware con respecto a uno o varios procesos, este se divide

en 5 capas:
Nivel 1. Gestin de Memoria: que proporciona las facilidades de bajo nivel
para la gestin de memoria secundaria necesaria para la ejecucin
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. Informacin o Aplicacin o Intrprete de Lenguajes: Facilita la
comunicacin 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 manipulacin de archivos con
nombre, va asignando espacio y acceso de datos en memoria.
READ: Lee un archivo.
El ncleo y los procesos
WRITE: Escribe en un
archivo
Todas las operaciones en las que participan procesos son

controladas por la parte del sistema operativo denominada ncleo (nucleus,
core o kernel, en ingls). El ncleo normalmente representa slo una
pequea parte de lo que por lo general se piensa que es todo el sistema
operativo, pero es tal vez el cdigo que ms se utiliza. Por esta razn, el
ncleo reside por lo regular en la memoria principal, mientras que otras
partes del sistema operativo son cargadas en la memoria principal slo
cuando se necesitan.
3. Ncleo
El Kernel consiste en la parte principal del cdigo del sistema operativo, el
cual se encargan de controlar y administrar los servicios y peticiones de
17

BUAP
Los ncleos se disean para realizar el mnimo posible de

procesamiento en cada interrupcin y dejar que el resto lo realice el
proceso apropiado del sistema, que puede operar mientras el ncleo se
habilita para atender otras interrupciones.
Resumen de las Funciones del Ncleo

El ncleo de un sistema operativo normalmente contiene el cdigo
necesario para realizar las siguientes funciones:
Manejo de interrupciones.
Creacin y destruccin de procesos.
Cambio de estado de los procesos.
Despacho.
Suspensin y reanudacin de procesos.
Sincronizacin de procesos.
Comunicacin entre procesos.
Manipulacin de los bloques de control de procesos.
Apoyo para las actividades de entrada/salida.
Apoyo para asignacin y liberacin 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 funcin del tamao y de las funcionalidades que posea el
kernel podemos clasificarlo. Realmente, y pese a seguidores
incondicionales en un modelo u otro, existe una tendencia bsica a reducir
el tamao del ncleo proporcionando menos funcionalidades, que son
desplazadas a mdulos que se cargan en tiempo de ejecucin.
En funcin a esta idea tenemos tres tipos fundamentales de
kernel:
Kernel monoltico
Todas las funcionalidades posibles estn integradas en el sistema.
Se trata de un programa de tamao considerable que deberemos recompilar
al completo cada vez que queramos aadir una nueva posibilidad. Esta es
la estructura original de Linux. Por tratarse de una tcnica clsica y
desfasada el creador de Linux fue muy criticado.
Kernel modular (Ncleo Colectivo): En esta estructura se tiene
una coleccin de procesos que son ampliamente independientes unos de
otros. Los servicios del Sistema Operativo ( Administracin de memoria
distribuida, sistemas de archivos distribuidos, sincronizacin distribuida,
procesos RPC, administracin de tiempos, etc.) son implementados como
procesos independientes. El ncleo del Sistema Operativo ( Comnmente
llamado Microkernel ) soporta la interaccin entre los procesos que
proveen los servicios al Sistema Operativo, tambin provee los servicios
tpicamente esenciales para cada computadora tal como la administracin
de tareas. El microkernel se ejecuta en todas las computadoras del sistema,
mientras que los otros procesos pueden o no correr segn se requiera.
Se trata de la tendencia actual de desarrollo. Sin embargo no tiene
sentido que el ncleo de un sistema operativo englobe toda la parafernalia
para comunicarse con todas las posibles de tarjetas de vdeo o de sonido.
En otros sistemas operativos esto se soluciona con unos ficheros
proporcionados por el fabricante llamados drivers. En Linux se cre un
18

BUAP
interfaz adecuado para posibilitar el desarrollo de mdulos que cumplieran

esas funcionalidades. Esos mdulos pueden ser compilados por separado y
aadidos al kernel en tiempo de ejecucin.
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
comunicacin como memoria compartida, tuberas 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
posicin 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 combinacin del
paralelismo con la ejecucin secuencial y el bloqueo de las llamadas al
sistema.
Aspectos del diseo de paquetes de hilos

Paquete de hilos. Un conjunto de primitivas relacionadas con los hilos.
Manejo de hilos
Se tienen dos alternativas:
- Hilos estticos. Se elige el nmero de hilos al escribir el
programa o durante su compilacin. Cada uno de ellos tiene
asociada una pila fija.
- Hilos dinmicos. Se permite la creacin y destruccin de los hilos
durante la ejecucin.
Los hilos pueden concluir de dos maneras:
- Pueder terminar por s mismos al finalizar su trabajo.
- Pueden ser eliminados desde el exterior.
Una tcnica dentro de los paquetes de hilos para el manejo de exclusin
mutua es el mtex, que es cierto tipo de semforo binario. Un mtex solo
tiene dos estados: cerrado, mediante la operacin LOCK (si un hilo intenta
cerrar un mtex ya cerrado, se bloquea); y no cerrado, para liberar un

mtex se utiliza la operacin UNLOCK (cuando UNLOCK elimina la
cerradura de un mtex y uno o ms hilos esperan ese mtex, se libera solo
uno de ellos. El resto continua en espera.
Otra operacin que se tiene en ciertos casos es TRYLOCK, que
intenta cerrar un mtex. Si el mtex no esta cerrado, TRYLOCK regresa
un cdigo de estado que indica el xito. En caso contrario, TRYLOCK no
bloquea el hilo, sino que regresa un cdigo de error.
Otra caracterstica de sincronizacin a veces disponible en los
paquetes de hilos es la variable de condicin. Por lo general se asocia una
variable de condicin a un mtex cuando ste se crea. La diferencia entre
un mtex y una variable de condicin, es que el primero se utiliza para una
cerradura a corto plazo, principalmente para proteger la entrada a regiones
crticas. Las variables de condicin 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 operacin correspondiente al valor de errno, suponga que
el siguiente hilo en despacharse tambin 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 parmetro
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.
Planificacin
Se pueden utilizar los algoritmos de prioridad, roun robin, lotera, etc.
19

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).
Implantacin de un paquete de hilos

Existen dos mtodos:
En el espacio de usuario
En el espacio de ncleo
Implantacin de los hilos en el espacio de usuario
El ncleo no sabe de la existencia de los hilos.
Ventajas
1. El sistema operativo no debe soportar hilos. Por ejemplo UNIX
2. La planificacin y cambio de estado la realiza un Sistema de
Tiempo de Ejecucin a nivel de usuario.
3. Se permite que cada proceso tenga su algoritmo de planificacin
adaptado.
4. Los hilos en este espacio tienen mejor escalabilidad, puesto que
los hilos del ncleo requieren algn espacio para sus tablas y su
pila en el ncleo, lo cual puede ser un problema si existe un
nmero muy grande de hilos.
Desventajas
1. La implantacin de las llamadas al sistema con bloqueo. Por
ejemplo la lectura a un pipe vaco. Se puede permitir el bloqueo a
un hilo pero que no afecte a los dems. Con las llamadas al
sistema con bloqueo esto no se puede lograr. Una posible
solucin sera modificar tales llamadas al sistema, pero cambiar el
sistema operativo no es atractivo. Adems 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 requerira 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
cdigo que se coloca junto a la llamada al sistema para hacer la
verificacin recibe el nombre de jacket. Este mtodo requiere
escribir parte de la biblioteca de llamadas.
Bloqueo de las llamadas al sistema en el fallo de pginas. Si un
hilo causa un fallo de pginas, el ncleo que desconoce la
existencia de los hilos, bloquear todo el proceso hasta que la
pgina necesaria sea incluida aunque se puedan correr otros hilos.
Si un hilo comienza su ejecucin, ningn 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 planificacin round
robin.
Sincronizacin. 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 rpida y el
costo del semforo 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.
Implantacin de hilos en el ncleo

El ncleo sabe de los hilos y como manejarlos. Este contiene una tabla con
una entrada por cada hilo, con los registros, estado, prioridades y dems
informacin 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 ncleo ejecuta otro hilo del mismo proceso o de otro proceso. Pero el
programador esperara 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
ncleo no se afectan sino que se ocupan cuando se crea otro hilo. Esto
implica un ahorro.
Los hilos del ncleo no requieren nuevas llamadas al sistema sin
bloqueo, no conducen a bloqueos cuando se utiliza la espera ocupada.
20

BUAP
Si un hilo de un proceso provoca un fallo de pgina, el ncleo

puede ejecutar otro hilo mientras que espera que la pgina requerida sea
traida del disco.
Los hilos en el espacio del usuario o del ncleo tienen asociados
otros problemas. Muchos procedimientos no son reentrantes, por ejemplo
cuando ambos hilos utilizan la variable errno o algn bufer esttico. Esto
sucede porque estos procedimientos no fueron escritos para hilos sino para
un solo proceso.
Una solucin sera escribir toda la biblioteca. Otra solucin
consiste en proporcionar a cada quien su jacket que cierre un semforo
mutex global al iniciar el procedimiento. De hecho la biblioteca se
convierte en un enorme monitor.
Las seales tambin presentan dificultades.
Modelos de Sistemas
El modelo de estacin 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 ms bajo
Fcil mantenimiento y respaldo. Al cambiar de versin de
software o instalar uno nuevo, solo se tiene que instalar en pocos
servidores.
Son silenciosas (no tienen ventiladores )
Proporcionan simetra y flexibilidad. Un usuario puede entrar a
cualquier estacin de trabajo y entrar al sistema.
Desventajas
Se debe contar con uno o ms servidores de archivos equipados

con discos enormes y rpidos 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 paginacin y archivos temporales, los cuales se eliminan al
finalizar la sesin. 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 nmero de discos duros.
2. Para paginacin, archivos temporales y binarios del sistema, tales
como compiladores, editores de texto, controladores de correo
electrnico, etc. Este esquema reduce an ms la carga sobre la
red. Su desventaja es el alto costo y la complejidad adicional para
actualizar los binarios.
3. Para paginacin, 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 despus
regresar los archivos modificados al final de la sesin. 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 prdida de transparencia y es ms parecido a
un sistema operativo de red
Otros problemas relacionados con este modelo son los siguientes:
Si los circuitos siguen abaratndose pronto ser posible
proporcionar a cada usuario varios CPU, pero seran demasiados en un
solo lugar; adems surgira otro problema, la asignacin de recursos sera
ineficiente ya que algunos usuarios recibiran recursos que no necesitan
mientras que otros usuarios si los necesitan.
Uso de estaciones de trabajo inactivas
21

BUAP
El problema en el modelo de estaciones de trabajo es que existen WS

inactivas o subutilizadas. La primera solucin a este problema fue
proporcionar el comando rsh (UNIX Berkeley), con este comando se
puede ejecutar en una mquina remota un comando.
Para llevar a cabo la ejecucin remota de un comando en una
mquina inactiva mediante rsh se debe tener un registro acerca de cul WS
esta inactiva. Adems el proceso que se ejecuta en una mquina remota
seguir ejecutndose aunque llegue un usuario, quien debe aceptar el
desempeo menor de su sistema o buscar otra mquina.
Problemas clave a solucionar con respecto al tema de las estaciones de
trabajo inactivas
1. Cmo encontrar una estacin de trabajo inactiva?
2. Cmo lograr que un proceso remoto se ejecute en forma
transparente?
3. Qu ocurre si regresa el poseedor de la mquina?
1. La estacin de trabajo esta inactiva cuando nadie toca el ratn o el
teclado durante varios minutos y no se ejecuta algn proceso iniciado por
el usuario.
Los algoritmos para localizar una WS inactiva se pueden dividir
en dos categoras:
a) Controlados por el servidor
b) Controlador por el cliente
En el primer caso cuando una WS esta inactiva anuncia su
disponibilidad registrndose en un archivo o base de datos, da su nombre,
direccin 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 enve un mensaje en toda la
red. Las dems WS registran el mensaje en su propio registro. As la
bsqueda tiene menor costo y mayor redundancia. La desventaja es pedir a
todas las mquinas que se encarguen de mantener el registro. Puede haber
condiciones de competencia si dos usuarios descubren una misma mquina
como inactiva.
Para solucionar este problema, se enva un mensaje a la mquina

inactiva para detectar su estado, si an esta libre, la mquina inactiva se
elimina del registro. Entonces quien hizo la llamada puede enviar su
ambiente e iniciar el proceso remoto.
En el segundo mtodo, controlado por el cliente. La mquina 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 mquina con la
menor carga llega primero y se selecciona.
2.Ahora hay que ejecutar el programa. El desplazamiento de cdigo es
fcil. Se debe configurar el proceso remoto de modo que vea el mismo
ambiente que tendra en el caso local y llevar a cabo el cmputo de la
misma forma que en el caso local.
Necesita la misma visin del sistema de archivos, el mismo
directorio de trabajo, mismas variables de ambiente.
Problemas al ejecutar un proceso en otra mquina.

Las llamadas al sistema dnde dirigirlas? a la mquina
origen o a la mquina remota? Por ejemplo, la lectura de teclado y
escritura a pantalla son funciones que deben dirigir la solicitud a la
mquina origen; pero las llamadas que tienen que ver con prioridades
o tamao de memoria deben dirigir su solicitud a la mquina remota.
Llamadas al sistema relacionadas con el tiempo
Seguimiento del ratn
Escritura en dispositivos de hardware
3.Si el poseedor de la mquina regresa no hacer nada, fcil pero destruye

la idea de ws personales.
Otra posibilidad es eliminar el proceso intruso, advirtindole
primero para que tenga tiempo de cerrar archivos, escribir los bferes
editados en un disco, etc. Sino sale despus de unos segundos el proceso es
terminado.
22

BUAP
Otro mtodo es hacer que el proceso emigre a otra mquina, ya

sea a la mquina origen o a alguna otra estacin de trabajo inactiva. Esto
es un proceso complejo.
El proceso debe dejar la mquina 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
mquinas, los cuales se pueden ejecutar de forma dinmica a los usuarios
segn la demanda. A cada usuario se le da una terminal grfica de alta
rendimiento, como las terminales X, incluso se pueden utilizar terminales
ascii.
Ventajas
Precio
Elimina la asociacin entre el nmero de usuarios y el de ws
Facilita el crecimiento por incrementos
De hecho se convierte el poder de cmputo en ws inactivas, a las
que se puede tener acceso de manera dinmica. Aqu no existe el concepto
de propiedad.
El principal argumento para la centralizacin del poder de
cmputo como pila de procesadores proviene de la teora de colas.
Los sistemas de colas son tiles, puesto que es posible modelarlos
de forma analtica.
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 operacin estable debemos
tener > . Si el servidor procesa menos solicitudes que las que los
usuarios generan, la cola crecer sin lmite.
El promedio de tiempo entre la emisin de una solicitud y la
obtencin de una respuesta completa est relacionado con y mediante
la frmula
T=1/( - )
1)
Si tenemos n computadoras, T estar dado en cada computadora

como en 1). Ahora si reemplazamos estos n pequeos recursos por uno
grande que sea n veces ms 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 desempeo, aunque este en contra de
los propios sistemas distribuidos.
Sin embargo el tiempo promedio de respuesta no lo es todo.
Tambin esta el costo, la confiabilidad y la tolerancia a fallas. Una
variacin en el tiempo de respuesta tambin puede influir.
Adems en muchos trabajos la pila no es n veces mejor, pues no
todos los trabajos se pueden ejecutar en paralelo.
An as, el modelo de pila de procesadores es una forma ms
limpia de obtener poder de cmputo adicional que la bsqueda de
estaciones inactivas. Ningn procesador pertenece a alguien, no hay
mquina 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 hbrido
Se puede establecer una mediacin al proporcionar a cada usuario una ws
personal y adems tener una pila de procesadores. Esto es ms caro.
Para procesos interactivos sera mejor utilizar ws. Para procesos
que requieren un gran poder de procesamiento y no son interactivos es ms
adecuado una pila de procesadores.
Asignacin de procesadores
Las estrategias de asignacin de procesadores se pueden dividir en dos
categoras amplias:
-No migratorios. Cuando un proceso es creado, se decide donde colocarlo.
Una vez colocado en una mquina, el proceso permanecer ah hasta que
termine su ejecucin.
-Migratorios. Un proceso se puede trasladar aunque haya iniciado su
ejecucin. Este tipo de categoras permiten un mejor balance de carga.
23

BUAP
Un algoritmo que asigne procesos a procesadores, tiene como meta

optimizar algn aspecto, por ejemplo los siguientes:
-Maximizar el uso de CPU
-Minimizar el tiempo de respuesta
Aspectos del diseo de algoritmos de asignacin de procesadores
Las principales decisiones que deben tomar los diseadores se pueden
resumir en cinco aspectos:
1. Algoritmos deterministas vs. Heursticos
2. Algoritmos centralizados vs. Distribuidos
3. Algoritmos ptimos vs. Subptimos
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 aproximacin razonable.
Cuando la carga del sistema es completamente impredecible se
utilizan tcnicas heursticas.
Tener toda la informacin en un solo lugar permite tomar una mejor
decisin, pero es menos robusta y coloca una carga pesada en la mquina
central. Son preferibles los descentralizados, pero carecen de alternaticas
adecuadas.
Encontrar la mejor asignacin, la mas ptima es ms caro, pues hay
que recolectar ms informacin y procesarla ms. En la prctica se buscan
soluciones subptimas, heurticas y distribuidas.
Otro aspecto llamado poltica de transferencia, tambin es importante,
tiene que ver con ejecutar un proceso en la mquina local o transferirlo,
esta decisin depende de la carga de la mquina. Una escuela dice que la
decisin se debe tomar con respecto a la informacin de la mquina local,
si esta sobrecargada (esta por sobre una marca) entonces hay que migrar el
proceso, sino el proceso se debe ejecutar en la mquina local. Otra escuela
dice que es mejor recolectar toda la informacin del sistema para decidir
donde ejecutar el proceso.
El ltimo aspecto tiene que ver con lo que se llama poltica de
localizacin, decidir dnde enviarlo una vez que se ha decidido migrar el
proceso. En el caso de los algoritmos iniciados por el emisor, es el emisor
(la mquina local que necesita colocar su proceso en otra mquina) quien
envia solicitudes a las dems mquinas 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 dems mquinas a ver quien necesita
ayuda.
Aspectos de la implantacin de algoritmos de asignacin de
procesadores
Medicin de la carga
- Los algoritmos suponen que cada mquina conoce su
carga.
- Algunos algoritmos cuentan el nmero de procesos para
determinar su carga.
- Una mejora al criterio anterior es contar solo los
procesos en ejecucin o listos.
- Otra forma de medir la carga es determinar la fraccin
de tiempo que el CPU esta ocupado.
Costo excesivo
- Muchos algoritmos tericos 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 desempeo un poco
mejor que otros, pero son ms 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 mquina, sta se sobrecargar, por
lo tanto hay que desplazar el proceso a otro lugar.
1. Se elige una mquina al azar y se enva el proceso, si la
mquina esta subcargada entonces aceptar el proceso,
24

BUAP
en caso contrario se repite la operacin hasta que alguien

acepte el proceso o se exceda un contador de tiempo.
2. Se elige una mquina al azar y se le pregunta si esta
subcargada, si su respuesta es afirmativa entonces la
mquina origen le enva el proceso, sino se repite la
operacin con otra mquina elegida al azar y as hasta
encontrar una mquina adecuada o se exceda el nmero
de pruebas, en cuyo caso permanecer en el sitio de su
creacin.
3. Se analizan k mquinas para determinar sus cargas
exactas. El proceso se enva a la mquina con la carga
ms pequea.
El mejor algoritmos es el 3, sin embargo el algoritmo 2 tiene
un desempeo casi igual al 3, pero es ms sencillo.
La conclusin a la que lleg Eager fue: Si el uso de un
algoritmo sencillo proporciona casi la misma ganancia que
uno ms caro y ms complejo, es mejor utilizar el ms
sencillo.
Estabilidad
- El sistema nunca esta en equilibrio por la actualizacin
constante de las tablas de las mquinas, as una mquina
podra pensar que otra esta actualizada sin que sea as.
Ejemplo de algoritmos de asignacin de procesadores

Un algoritmo determinista segn la teora de grficas
Para sistemas que constan de procesos con requerimientos conocidos de
CPU y memoria, adems de una matriz conocida con el trico promedio
entre cada pareja de procesos. Si el nmero de CPU es menor que el
nmero de procesos, habr que asignar varios procesos al mismo CPU. La
idea es llevar a cabo esta asignacin de forma que se minimice el trfico
en la red.
Sea la la siguiente grfica de procesos, los arcos indican el nivel de
comunicacin entre los procesos.
Una posible asignacin es la siguiente:
CPU1
CPU2
CPU3
3
A
2
6
2
1
F
2
E
4
4
30 unidades
Otra posible asignacin es:

CPU1
CPU2
3
A
2
6
1
F
2
E
4
4
CPU3
28 unidades
Podemos observar que la segunda asignacin es la mejor.

Un algoritmo centralizado
Arriba-abajo (Mutka y Livny, 1987) es centralizado. Usa una tabla de uso,
con una entrada por cada estacin de trabajo personal.
Si un proceso se ejecuta en otra mquina, la mquina origen
acumula puntos de penalizacin cada segundo. Si tiene solicitudes
pendientes no satisfechas, los puntos de penalizacin se restan de su
entrada en la tabla de usos. Si no existen solicitudes pendientes y ningn
procesador esta en uso, la entrada de la tabla de usos se desplaza un cierto
nmero de puntos hacia el cero.
Si la puntuacin asociada a una estacin de trabajo en la tabla de
usos es positiva, indica que la estacin de trabajo es un usuario de los
recursos del sistema. Si tiene una puntuacin 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.
25
2

BUAP
La desventaja de este algoritmo es que si casi todas las ws estn

sobrecargadas entonces se enviarn pruebas de forma constante en vano.
La red se sobrecargar cuando ms trabajo existe.
Un algoritmo jerquico
Para este tipo de algoritmo es necesario una gran cantidad de
procesadores, los cuales se agrupan por jerarquas, en un primer nivel (el
nivel ms alto) un grupo de procesadores forman el comit de
coordinadores, en el siguiente nivel estn los jefes de departamento. Los
niveles pueden ser n, todo depender del nmero de procesadores. En el
ltimo nivel estn 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 envan 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 operacin hasta llegar
a los trabajadores. Se sealan a los procesadores elegidos para realizar la
tarea como ocupados y se informa de regreso en el rbol.
Comit de
Coordinadores
Un algoritmo heurstico 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
mquina 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.
Este algoritmo crea trfico en la red cuando las ws estn
subcargadas (desempleadas), pero es mejor en este momento y crear
trfico cuando el sistema esta sobrecargado.
Una posible modificacin 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 mquinas que estn crnicamente
subcargadas o sobrecargadas.
coordinadores
Un algoritmo de remates
Jefes de departamento
Trabajadores
Un algoritmo heurstico distribuido iniciado por el emisor

Este algoritmo es el segundo algoritmo de Eager mencionado en pginas
anteriores.
Este algoritmo fue creado por Ferguson

En este caso se crea una comunidad econmica 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, tamao 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
renen todas las ofertas y eligen una. Se informa a los ganadores y
perdedores.
Planificacin en Sistemas Distribuidos
26

BUAP
Cada mquina se puede planificar de forma independiente, pero si existen

procesos que interactan 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 ejecutarn 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 ejecucin 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
comunicacin no se esta llevando a cabo de forma eficiente, y se pierde
tiempo de cmputo.
Ousterhout (1982) propuso algoritmos basados en un concepto llamado
coplanificacin, el cual toma en cuenta los patrones de comunicacin entre
los procesos durante la planificacin para garantizar que todos los
miembros de un grupo se ejecuten al mismo tiempo.
Tolerancia de fallas
Fallas de componentes
Una falla es un desperfecto, causado por un error de diseo, de
fabricacin, de programacin, fsico, tiempo, condiciones ambientales, etc.
Las fallas se clasifican en:
-Transitorias. Ocurren una vez y despus desaparecen.
-Intermitente. Desaparece y reaparece.
-Permanente. Continua existiendo hasta reparar el componente con el
desperfecto.
El objetivo del diseo y construccin de sistemas tolerantes a fallas
consisten en garantizar que el sistema contine funcionando de manera
correcta como un todo, incluso en la presencia de fallas.
Fallas del sistema
Se pueden distinguir dos tipos de fallas del procesador:
1.
2.
Fallas silentes. Un procesador que fallas solo se detiene y no

responde a las entradas subsecuentes ni produce ms entradas
(tambin se llaman fallas de detencin).
Fallas bizantinas. Un procesador que falla contina su ejecucin,
proporcionando respuestas incorrectas a las preguntas, y
posiblemente trabajando de manera maliciosa junto con otros
procesadores que han fallado, para dar la impresin de que todos
funcionan de manera correcta aunque no sea as.
Sistemas sncronos vs. Asncronos

En el contexto de la investigacin relativa a la tolerancia a fallas, un
sistema que tiene la propiedad de responder siempre a un mensaje dentro
de un lmite finito conocido, es sncrono. Un sistema que no tiene esta
propiedad es asncrono.
Uso de redundancia
El mtodo general para la tolerancia de fallas consisten en el uso de
redundancia. Existen tres tipos posibles:
Redundacia de la informacin. Se agregan bits para poder
recuperar los bits revueltos.
Redundacia del tiempo. Se realiza una accin y en caso necesario
se vuelve a realizar. Este tipo de redundacia es de utilidad cuando
las fallas son transitorias o intermitentes.
Redundancia fsica. Se trata de agregar equipo adicional.
Formas de organizar procesadores
1. Rplica activa
2. Respaldo primario
Tolerancia de fallas mediante rplica activa (mtodo de la mquina 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.
Tolerancia de fallas mediante respaldo primario
1.Solicitud
Cliente
6.Respuesta
2.Realiza el
trabajo
Primario
3.Actualiza
Respaldo
5.Reconocimiento
4.Realiza el
trabajo
27

BUAP
Acuerdos en sistemas defectuosos

-El problema de los dos ejrcitos
-El problema de los generales bizantinos
4. Comunicacin en los sistemas distribuidos

La diferencia ms importante entre un sistema distribuido y un sistema con
un procesador es la comunicacin 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 comunicacin entre procesos debe respetar reglas llamadas
protocolos.
Protocolos con capas
Para que dos procesos logren la comunicacin se deben poner de acuerdo
en varios aspectos como, cuntos voltios hay que utilizar para sealar un
bit 0 y un bit 1; cmo detectar el fin de un mensaje, etc.
Para facilitar este trabajo la organizacin internacional de
estndares (internacional standards organization- ISO) ha desarrollado un
modelo de referencia llamado el modelo de referencia para interconexin
de sistemas abiertos, lo cual se abrevia como ISO OSI o el modelo OSI.
El modelo OSI est diseado para permitir la comunicacin de los
sistemas abiertos. Un sistema abierto es aquel preparado para comunicarse
con cualquier otro sistema abierto mediante estndares que gobiernan el
formato, contenido y significado de los mensaje enviados y recibidos.
Un protocolo es un acuerdo entre las partes acerca de cmo debe

desarrollarse la comunicacin.
El modelo OSI maneja dos tipos generales de protocolos
(conexiones).
1. Protocolos orientados a la conexin. Antes de intercambiar datos,
el emisor y el receptor deben establecer en forma explcita una
conexin y tal vez el protocolo.
2. Protocolos son conexin. No es necesaria una negociacin previa.
En el modelo OSI, la comunicacin se divide en 7 niveles o capas. Cada
capa se maneja de forma independiente y se encarga de un aspecto
especfico. 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 dems.
En el modelo OSI cuando se va a enviar un mensaje, este pasa por
todas las capas comenzando en la de Aplicacin. Cada capa le coloca un
encabezado al frente o al final, al llegar el mensaje al otro lado, cada capa
lo va desmenuzando, quitndole el encabezado que le corresponde; la capa
que recibe el mensaje es la capa fsica.
Capas
Fisica, Enlace de Datos, Red, Transporte, Sesin, Presentacin,
Aplicacin
La coleccin de protocolos utilizados en un sistema particular se
llama una serie de protocolos o pila de protocolos.
Capa fsica
Su propsito es transportar el flujo de bits de una mquina a otra. El
protocolo de la capa fsica se encarga de la estandarizacin de las
interfaces elctricas, mecnicas y de sealizacin. Maneja elementos como
la intensidad de la seal 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.
28

BUAP
Uno de los mecanismos en la deteccin de errores es asignar

nmeros secuenciales a las tramas y a cada trama colocarle una suma de
verificacin, sino esta correcta la suma de verificacin 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 ms corta no siempre es la mejor, lo importante
es la cantidad de retraso, y esto complica los algoritmos de ruteo.
La capa de red maneja dos protocolos: X.25 (orientado a la conexin) y el
IP (sin conexin).
Capa de transporte
La tarea de la capa de transporte es proporcionar conexiones confiables y
econmicas. Las conexiones confiables (orientadas a la conexin) 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 ms utilizados en esta capa son: TCP (transmisin
control protocol- protocolo para el control de transmisiones), orientado a la
conexin y UDP (universal datagrama protocol- protocolo datagrama
universal) que es un protocolo sin conexin.
Capa de sesin
Esta es en esencia una versin mejorada de la capa de transporte.
Proporciona el control del dilogo, facilidades en la sincronizacin, la
posibilidad de establecer conexiones llamadas sesiones y la posibilidad de
transferir datos sobre las sesiones en forma ordenada.
En la prctica rara vez las aplicaciones soportan esta capa.
Capa de presentacin
Esta capa trata los problemas relacionados con la representacin y el
significado de los datos.
Capa de aplicacin
Es una coleccin de varios protocolos para actividades comunes, como el

correo electrnico, la transferencia de archivos y la conexin entre
terminales remotas a las computadoras en una red. Esta capa contiene los
programas de usuario.
Protocolos utilizados: X.400 para correo electrnico, X.500 para
el servidor de directorios.
ATM Redes con modo de transferencia asncrona
Naci a finales de los 80s debido a la necesidad de enviar adems de datos
a travs de la red, tambin enviar voz.
Para esto se eligi una forma hbrida con bloques de tamao fijo
sobre circuitos virtuales, para ambos tipos de trfico. Este esquema es
llamado modo de transferencia asncrona (ATM- Asynchronous Transfer
Mode), el cual se ha convertido en un estndar internacional.
El modelo ATM consiste en que un emisor establece primero una
conexin con l o los receptores. En el establecimiento de la conexin, se
determina una ruta desde el origen hasta el destino y se guarda la
informacin del ruteo en los conmutadores a lo largo del camino. Con esta
conexin se pueden enviar paquetes, pero el hardware los separa en
pequeas unidades de tamao fijo llamadas celdas, las cuales siguen todas
la misma ruta. Cuando ya no se necesita la conexin, sta se libera y se
purga la informacin de ruteo de los conmutadores.
Ventajas
Se pueden enviar datos, voz, televisin, 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 (multitransmisin)
La multitransmisin se puede controlar de manera eficaz.
Celdas de tamao fijo y no de tamao variable como los actuales
ATM tiene su propio protocolo de jerarquas.
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
29

BUAP
Los problemas son que este tipo de redes es ms caro, y al utilizarlas

implicara 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 cooperacin, llamados
servidores, que ofrezcan servicios a los usuarios, llamados clientes. Las
mquinas de los clientes y servidores ejecutan el mismo microncleo
(generalmente) y ambos se ejecutan como procesos de usuario.
Este modelo se basa usualmente en un protocolo
solicitud/respuesta sencillo y sin conexin. El cliente es quien solicita al
servidor algn servicio, y el servidor es quien atiende la solicitud y regresa
los datos solicitados o un cdigo de error si algo fall.
Ventajas
Sencillez. El cliente enva un mensaje y obtiene respuesta.
Eficiencia. La pila del protocolo es ms corta y por tanto ms
eficiente. No es necesario implantar capas como la de sesin o red y
transporte, ya que este trabajo lo hace el hardware.
Se reducen los servicios de comunicacin. Solo necesitamos las
llamadas send (enviar) y receive (recibir).
Direccionamiento
Para que un proceso enve un mensaje a otro proceso que esta en otra
mquina, es necesario que el primer proceso sepa donde esta el otro
proceso (su direccin).
El primer acercamiento para resolver el problema de cmo
identificar un proceso, es asociarle a cada mquina una direccin, aunque
esto implicara que cada mquina solo puede ejecutar un proceso. Para
resolver esta limitante, entonces se podran dar identificadores a los
procesos y no a las mquinas, pero ahora surge el problema de cmo
identificar dos procesos. Un esquema comn consiste en utilizar nombre
con dos partes, una para especificar la mquina y la otra para especificar el
proceso.
Sin embargo este tipo de direccionamiento no es bueno, ya que

cada usuario debe conocer la direccin del servidor y esto ya no es
transparente. Si el servidor falla y su direccin 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 nmero es muy
pequea y el mtodo puede utilizarse en sistemas extensos. Cmo sabe el
ncleo emisor a qu mquina enviar el mensaje? En una LAN que soporte
transmisiones, el emisor puede transmitir un paquete especial de
localizacin con la direccin del proceso destino. Todas las mquinas de la
red lo recibiran y los ncleos verificarn si la direccin es la suya, en este
caso, regresa un mensaje aqu estoy con su direccin en la red. El ncleo
emisor utiliza entonces esa direccin y la captura, para evitar el envo de
otra transmisin la prxima vez que necesite al servidor.
Este ltimo esquema tiene un problema: la carga adicional en el
sistema. Esto se evita utilizando una mquina adicional para la asociacin
a alto nivel de los nombres de los servicios con las direcciones de las
mquinas. As se utilizan nombres de procesos y no nmeros. Cada vez
que se ejecute un cliente, primero va al servidor de nombres, y pide el
nmero de la mquina donde se localiza algn servidor. As las direcciones
se ocultan. Este mtodo tiene la desventaja de utilizar un componente
centralizado.
Primitivas con bloqueo vs. Sin bloqueo
La forma de comunicacin 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 (sncronas). 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 transmisin de los mensajes.
Primitivas sin bloqueo (asncronas). Tanto send como receive no tiene
bloqueo. En el caso de send, esta primitiva coloca el mensaje en el buffer
30

BUAP
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
ncleo copie el mensaje a un buffer interno del ncleo 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 ncleo. Esto puede reducir el desempeo
del sistema.
La segunda solucin es interrumpir al emisor cuando el mensaje
ha sido enviado y hacerle saber que ya puede usar nuevamente el buffer de
mensajes. Este mtodo es eficiente, pero es muy difcil escribir los
programas en forma correcta y es casi imposible depurarlos cuando estn
incorrectos.
En el caso de un receive sin bloqueo, ste solo avisa al ncleo de
la localizacin del buffer y regresa el control inmediatamente. Para hacer
que ste espere se utilizara un wait.
En las primitivas sncronas 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 direccin especfica. 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 ncleo del servidor la
direccin que utiliza el servidor y la posicin donde colocar el mensaje
que est por llegar; entonces si primero llega un mensaje, el servidor no
sabr de quin es y dnde 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 esperarn un
tiempo y luego se rendirn.
3. Que el ncleo receptor mantenga pendientes los mensajes. Si no
ocurre un receive en un determinado tiempo, el mensaje es
descartado.
4. Utilizar un buzn donde almacenar los mensajes. Un proceso que
va a recibir mensajes pide al ncleo que le sea creado un buzn,
en donde le depositarn los mensajes y l los ir leyendo. A esta
tcnica 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 enva un mensaje, a pesar de utilizar primitivas con
bloqueo, no existe garanta de que el mensaje haya sido entregado. El
mensaje pudo haberse perdido.
Existen tres enfoques de este problema:
1. Volver a definir la semntica 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 comunicacin
confiable se deja en manos del usuario.
2. El ncleo de la mquina receptora enva un reconocimiento al
ncleo de la mquina emisora. El reconocimiento va de ncleo a
ncleo, as ni el cliente ni el servidor se dan cuenta de esto. El
ncleo entonces liberar al proceso cuando reciba el
reconocimiento.
3. Aprovechar el hecho de que en la comunicacin cliente-servidor
se realiza de la siguiente manera: el cliente le enva un mensaje de
solicitud al servidor y el servidor le da una respuesta al cliente.
Entonces no hay mensaje de reconocimiento por parte del ncleo
31

BUAP
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 ncleo
emisor puede enviar la solicitud nuevamente.
En este mtodo no existe reconocimiento para la respuesta, esta
omisin puede ocasionar problemas si el servicio solicitado por el cliente
requiere cmputo extenso, porque el servidor no se enterara si el cliente
recibi o no la respuesta.
Para solucionar esto se enva reconocimiento de la respuesta en
base a un cronmetro, si la respuesta lleg rpido, 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 ejecucin de un procedimiento
en la mquina A que no est en A, sino en B.
Operacin bsica de RPC.
De manera convencional, cuando un procedimiento es invocado,
la direccin que tiene el registro apuntador a la prxima instruccin (IP) es
almacenada en la pila, y el registro apuntador ser cargado con la direccin
del procedimiento invocado, cuando el procedimiento invocado termina,
entonces el registro IP es cargado con la direccin que esta en el tope de la
pila y sigue la ejecucin del programa.
En la mayora de los casos es necesario enviar parmetros de
entrada y obtener parmetro de salida. Los lenguajes de programacin
como C, utilizan dos tipos de paso de parmetros: por valor o por
referencia.
En un paso de parmetros 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 parmetro por referencia, lo que se pasa es
la direccin, y es posible realizar modificaciones sobre esta variable.
Existe otra forma de pasar parmetros que no maneja el lenguaje
C, este mecanismo se llama copia/restauracin. Quien recibe la llamada
copia la variable en la pila, como en la llamada por valor, y entonces copia

de regreso la variable despus de la llamada, escribiendo sobre el valor
original.
El objetivo de un RPC es que se parezca lo ms 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
parmetros, especificando si son parmetros de entrada o de salida, su
versin, su identificador nico y su asa. Un proceso llamado conector es
quien recibe la interfaz y realiza el registro.
El conector adems de realizar el registro de un servidor, puede
darlo de baja y buscar algn servidor.
La versin 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 mtodo de exportacin e importacin 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, adems un proceso puede tener un tiempo de vida corto y
el tiempo entre importar y exportar interfaces puede ser significativo.
Semntica de RPC en presencia de fallas
El objetivo es ocultar la comunicacin, 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
RPCs.
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 despus de enviar la solicitud
El cliente no puede localizar al servidor
32

BUAP
Debido a que el servidor cambi de direccin 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
vlido, habr confusin acerca de si fue error o el resultado de alguna
operacin.
Otro mecanismo que no tiene la desventaja anterior es que el error
provoque una excepcin. Por ejemplo se podran utilizar seales. Pero no
todos los lenguajes tienen excepciones y/o seales. Adems el uso de estos
mecanismos, destruyen la transparencia.
Prdida de mensajes de respuesta
Se puede utilizar un cronmetro, si no llega respuesta en un periodo
razonable, se enva 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 ms difcitl de
enfrentar.
Algunas operaciones se pueden repetir muchas veces sin efectos
colaterales y sin causar daos. A esta propiedad se le llama idempotencia.
Pero existen operaciones que no son idempotentes, por ejemplo retirar
dinero de un cajero automtico.
Una posible solucin es asociar un nmero secuencial a cada
solicitud. Entonces el ncleo del servidor debe mantener un registro del
nmero secuencial ms reciente, as podr notar la diferencia entre una
solicitud original y las retransmisiones. Como proteccin adicional se
podra 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 despus de responder
-El servidor falla antes de responder
Existen tres escuelas en torno a lo que se debe hacer en este caso:
1. Semntica 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 ms veces.
2.
3.
Semntica a lo ms una vez. Se da por vencido inmediatamente e

informa de la falla. La RPC se realiza a lo ms una vez o ni una
sola vez.
No garantiza nada.
Fallas del cliente

Cuando un cliente falla despus de enviar una solicitud sin que haya
recibido respuesta, existir una labor de cmputo de la cual nadie espera
respuesta. A esta labor de cmputo no deseada se le llama hurfano.
Problemas que puede provocar un hurfano.
- desperdiciar ciclos de cpu
- bloquear archivos o capturar recursos valiosos
- crear confusin (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 hurfanos?
Nelson (1981) hizo un estudio acerca de este problema y propuso lo
siguiente:
1. Exterminacin. 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 hurfano.
Desventaja. Gasto en la escritura y disco.
Si hay ms hurfanos es muy probable que no se puedan localizar
No es un buen mtodo.
2. Reencarnacin. Se divide el tiempo en pocas. Cuando el cliente
arranca de nuevo enva un mensaje a todas las mquinas que
declaran el inicio de una poca. Se eliminan los cmputos
remotos que estn fuera de poca.
3. Reencarnacin sutil. Utiliza tambin pocas, pero el que est
ejecutando el RPC verifica si existe el dueo de la RPC cuando le
llega un mensaje de cierta poca, si no existe elimina la
operacin.
4. Expiracin. 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.
33

BUAP
En la prctica ninguno es recomendable. La eliminacin de un

hurfano puede traer consecuencias imprescindibles.
Protocolos RPC
Orientado a la conexin
Ventaja. Comunicacin fcil
Desventaja: Prdida de desempeo
Sin conexin
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 diseado
-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 adems ambos
realizan una suma de verificacin.
-Lo anterior hace que se pierda el desempeo.
Alternativa
-Utilizar un protocolo especializado para RPC, el cual debe ser
diseado e implantado por el programador.
Con respecto a la longitud del paquete y el mensaje, sale ms 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 lmite de
Ethernet es de 1536 bytes)
Reconocimientos
1) Protocolo detenerse y esperar. Enva un paquete y
espera reconocimiento. Los paquetes son enviados uno a
uno.
2) Protocolo de chorro. El cliente enva 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 daa 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 enve el paquete 1. A esto se le llama
repeticin selectiva.
Comunicacin en grupo
Para RPC la comunicacin 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 coleccin de procesos que actan juntos en cierto sistema
o alguna forma determinada por el usuario.
La propiedad fundamental de un grupo es que cuando se enva un mensaje
al propio grupo, todos los miembros de este lo reciben. A este tipo de
comunicacin se le llama uno-muchos (la de cliente-servidor es una
comunicacin puntual).
Los grupos son dinmicos, 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 implantacin de comunicacin en grupo depende del hardware en gran
medida.
- Multitrasmisin. Cuando se enva un mensaje a un
grupo, ste se recibe automticamente en todas las
mquinas que escuchan esa direccin. Cada grupo
escucha una direccin de multitransmisin.
- Transmisin simple. Los procesos deben ser concientes
acerca de a cul 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.
- Unitransmisin. El mensaje es enviado a cada proceso
uno a uno, es decir, si el grupo tiene n miembros, se
envan n paquetes.
Grupos cerrados vs. Grupos abiertos
34

BUAP
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 compaeros vs. Grupos jerrquicos
Otra forma de clasificar a los grupos es en grupos de compaeros y grupos
jerrquicos. En un grupo de compaeros todos los procesos son iguales, la
ventaja es que si uno falla los dems pueden seguir trabajando. La
desventaja es que al tomar una decisin se debe votar, esto implica mayor
retraso y costo.
En el caso de un grupo jerrquico 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.
Membresa del grupo
Para manejar la creacin y eliminacin 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 quines lo forman.
La desventaja es que si el servidor falla, se pierde informacin acerca de
grupos y tal vez deban ser reconstruidos los grupos totalmente.
Otro mtodo es manejar la membresa de grupo en forma distribuida. En
un grupo abierto un extrao 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 darn cuenta al tratar de comunicarse con l, entonces sino
responde, lo eliminan de su grupo.
35

Notasdistribuidos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Notasdistribuidos

Cargado por

Copyright:

Formatos disponibles

Sistemas Operativos Distribuidos

MC Hilda Castillo Zacatelco

Sistemas Operativos Distribuidos

Sistemas Operativos Distribuidos

Sistemas de ficheros con raz nica. Tenemos que independizar los

1.1 Conceptos de Hardware

Clasificacin de Flynn (1972).

Sistemas Operativos Distribuidos

Considera dos caractersticas el nmero de flujos de instrucciones y el

Multiprocesadores de memoria compartida.

ejecutivo o maestro ejecuta el sistema operativo y maneja la E/S. Los

Sistemas Operativos Distribuidos

El rango de transferencia de datos es similar a B-ISDN , utiizan

1.2 Conceptos de Software

Las redes de computadoras pueden ser divididas en dos clases:

En un sistema distribuido el software es ms importantes que el

Redes de rea local (LAN)

Sistemas operativos de redes

Sistemas Operativos Distribuidos

Una mejora es tener un sistema de archivos global accesible desde

Sistemas realmente destribuidos

Caractersticas de los sistemas distribuidos

Los usuarios de recursos se comunican con el manejador de

Mecanismo de comunicacin global entre procesos

Openness(Abierto). En un sistema distribuido el

Sistemas Operativos Distribuidos

Sistemas de Multiprocesador con tiempo compartido

Transparencia de paralelismo. Las actividades pueden ocurrir en

1.3 Aspectos del diseo

Existen dos tipos de estructuras de los sistemas distribuidos.

La transparencia es uno de los aspectos de diseo ms importantes

La mayora de los sistemas distribuidos diseados a partir de cero

Sistemas Operativos Distribuidos

Este aspecto fue uno de los objetivos originales en la construccin de

El objetivo es que los mtodos actuales puedan escalarse hacia

Otros temas bsicos de diseo son:

El mayor problema del desempeo en un sistema distribuido se da en

Nombres. Los procesos deben saber los nombres de los recursos

Sistemas Operativos Distribuidos

Los componentes de un sistema distribuido estn separados lgica

Los problemas de consistencia surgen de la separacin de recursos de

Asignacin de la carga de trabajo

Sistemas Operativos Distribuidos

El diseo de la escalabilidad de un sistema distribuido es

Network File System, es como su nombre lo indica un sistema de archivos

2. El sistema de archivos de red (NFS) de Sun.

Sistemas Operativos Distribuidos

NFS utiliza llamadas a procedimientos remotos o RPC (Remote

Sistemas Operativos Distribuidos

Otra alternativa a la versin de UNIX de Sun soporta tambin el

Sistemas Operativos Distribuidos

modificaciones deben ser realizadas nicamente en el maestro, que

Al abrir un archivo remoto, en cierto momento durante el anlisis del

Sistemas Operativos Distribuidos

Reduccin de requerimento de espacio de Almacenamiento en

Reduccin de Tareas de Administracin, debida a

Puede ser utilizado como complemento a NIS.

Facilita el trabajo con archivo remotos ya que no es necesarios

Ayuda a mantener la consistencia de los archivos entre las

Puede utilizarse para la Comunicacin entre Usuarios y/o

Con el uso de NFS se pueden configurar los home directories de

Usuarios y aplicaciones pueden acceder a archivos remotos como

NFS utiliza RPC sobre el protocolo XDR (eXternal Data