SISTEMAS OPERATIVOS II

Sistemas Distribuidos

SISTEMAS

B E R T H A TA C U R I
BTACURI@UPS.EDU.EC

ANDREA PLAZA C
APLAZA@UPS.EDU.EC
 1. Estructura de sistemas distribuidos
2. Sistemas de archivos distribuidos (DFS)

Sistemas Distribuidos
 1. Coordinación distribuida
2. Sistemas operativos de red
3. Sistemas operativos distribuidos
4. Servicios remotos
5. Robustez
6. Aspectos de diseño

1. Estructura de sistemas distribuidos

 Coordinación Distribuida
•Los sistemas distribuidos se constituyen a través de la
conexión de un grupo de varias computadoras.
•Los ordenadores están físicamente separados, cada uno
contiene su software y su hardware individual, pero tienen en
común una red de comunicaciones que conecta a todos ellos a
la vez.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Ordenación de sucesos
◦ La relación sucedió-antes
◦ Se consideran solo procesos secuenciales, todos los sucesos que se
ejecutan en un mismo proceso están totalmente ordenados
◦ Ley de causalidad, un mensaje solo puede recibirse después de enviarse
◦ Se puede definir la relación sucedió-antes (denotada por ) como sigue:
◦ Si A y B son sucesos del mismo proceso, y A se ejecutó antes que B, entonces A
B
◦ Si A es el suceso de que un proceso envía un mensaje y B es el suceso de que
otro proceso recibe ese mensaje, entonces A  B
◦ Si A  B y B  C entonces A  C
◦ Si dos sucesos A y B, no están relacionados por la relación  (es decir A
no ocurrió antes que B y B no ocurrió antes que A), se dice que ambos
sucesos se ejecutaron de forma concurrente

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Ordenación de sucesos
◦ La relación sucedió-antes
◦ p1q2
◦ r0q4
◦ q3r4
◦ p1q4
(ya que p1q2 y q2q4)

◦ Algunos procesos concurrentes del sistema son:

◦ q0 y p2
◦ r0 y q3
◦ r0 y p3
◦ q3 y p3

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Ordenación de sucesos
◦ Implementación
◦ Para determinar que un suceso A ocurrió antes que un suceso B se
necesita un reloj común o un conjunto de relojes perfectamente
sincronizados.
◦ En un sistema distribuido no se cuenta con ninguna de estas cosas, se
define la relación sucedió-antes sin usar relojes físicos.
◦ Se asocia a cada suceso del sistema una marca de tiempo. Ahora se puede
definir el requisito de ordenación global: para cada par de sucesos A y B,
si AB, entonces la marca de tiempo de A es menor que la de B

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Ordenación de sucesos
◦ Implementación
◦ ¿Cómo se hace cumplir el requisito de ordenación global en un sistema
distribuido?
◦ Se define dentro de cada proceso Pi un reloj lógico RLi
◦ Este reloj puede ser un simple contador que se incrementa entre cualesquier
dos sucesos consecutivos que se ejecutan dentro de un proceso
◦ Si un suceso A ocurre antes que el suceso B en el proceso Pi entonces:
◦ RLi(A) < RLi(B)
◦ El esquema no asegura que se satisfaga el requisito de ordenación global entre
procesos, porque se puede tener una situación en la que los procesadores y
relojes no sean homogéneos y unos más rápidos que otros y unos mas lentos
que otros
◦ Para resolver esta dificultad es necesario que un proceso adelante su reloj
lógico cuando reciba un mensaje cuya marca de tiempo sea mayor que el valor
actual de su reloj lógico.
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Mutua exclusión
◦ Se presentan varios algoritmos para implementar la mutua exclusión en un
entorno distribuido. Se supone que el sistema consiste en n procesos cada
uno de los cuales reside en un procesador distinto.
◦ Estrategia centralizada
◦ Se escoge uno de los procesos del sistema para que coordine el ingreso en la
sección crítica.
◦ Cada proceso envía un mensaje solicitar al coordinador, cuando el proceso reciba
un mensaje responder del coordinador podrá ingresar en su sección crítica.
Después de salir de su sección crítica el proceso envía un mensaje liberar al
coordinador y continuará con su ejecución.
◦ Al recibir un mensaje solicitar el coordinador verifica si algún otro proceso está en
su sección crítica. Si ningún proceso está, el coordinador devuelve de inmediato un
mensaje responder caso contrario la solicitud se encola, hasta que reciba un
mensaje liberar y tome uno de los mensajes de solicitud de la cola y enviará un
mensaje responder al proceso solicitante.
◦ Si el proceso coordinador falla, un proceso nuevo deberá tomar su lugar.
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Mutua exclusión
◦ Estrategia totalmente distribuida
◦ Si se quiere distribuir la toma de decisiones en todo el sistema, la solución es mucho
más complicada. El algoritmo se basa en el esquema de ordenación de sucesos.
◦ Cuando un proceso quiere entrar en su sección crítica, genera una nueva marca de
tiempo MT y envía el mensaje solicitar(Pi,TS) a todos los demás procesos del sistema
(incluido él mismo)
◦ Los procesos pueden contestar de inmediato (responder a Pi) o diferir la contestación
◦ Si el proceso Pi está en su sección crítica, diferirá su respuesta a Pj
◦ Si el proceso Pi no quiere ingresar en su sección crítica, enviará una respuesta de inmediato a
Pj
◦ Si el proceso Pi desea ingresar en su sección crítica pero todavía no lo ha hecho, compara la
marca de tiempo de su propia solicitud con la marca de tiempo de TS de la solicitud hecha por
el proceso Pj que ha llegado. Si es mayor que TS enviará una respuesta de inmediato a Pj (Pj
preguntó primero); si no, diferirá su respuesta.
◦ Un proceso que ha recibido un mensaje responder de todos los demás procesos del
sistema, podrá ingresar en su sección crítica, encolando las solicitudes que lleguen y
difiriéndolas. Después de salir de su sección crítica, el proceso envía mensajes
responder a todas sus solicitudes diferidas.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Mutua exclusión
◦ Estrategia totalmente distribuida
◦ Este algoritmo exhibe el siguiente comportamiento deseable:
◦ Se logra la mutua exclusión
◦ Se asegura que no habrá bloqueos mutuos
◦ Se asegura que no habrá inanición, ya que el ingreso se planifica según la ordenación por
marca de tiempo
◦ El esquema requiere la participación de todos los procesos , tiene consecuencias
indeseables:
◦ Los procesos necesitan conocer la identidad de todos los demás procesos que participan
en el algoritmo de mutua exclusión
◦ El proceso debe recibir los nombres de todos
◦ El nombre de un nuevo proceso debe distribuirse a todos
◦ Si uno de los procesos falla, todo el esquema se viene abajo. Se puede resolver este
inconveniente vigilando continuamente los procesos
◦ Los procesos que no han ingresado en su sección crítica deben hacer pausas frecuentes
para asegurar a otros procesos que tienen intención de ingresar en la sección crítica

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Mutua exclusión
◦ Estrategia de paso de testigo
◦ Otro método es hacer circular un testigo entre los procesos del sistema.
Un testigo es un tipo especial de mensaje.
◦ La posesión del testigo faculta al poseedor para ingresar en la sección
crítica
◦ Se supone que los procesos del sistema están organizados lógicamente en
una estructura anular. La red física no necesita ser un anillo.
◦ Una vez que el proceso sale de su sección crítica, se vuelve a pasar el
testigo. Si el proceso recibe el testigo y no desea ingresar en su sección
crítica pasará el testigo a su vecino.
◦ Hay que considerar dos tipos de fallos:
◦ Si se pierde el testigo, se debe convocar a una elección para generar un nuevo
testigo
◦ Si un proceso falla, se debe establecer un nuevo anillo lógico
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Atomicidad
◦ Todas las operaciones asociadas a la transacción se ejecutan hasta
terminar o bien ninguna se lleva a cabo.
◦ En un sistema distribuido se complica la tarea de asegurar la propiedad de
atomicidad. El fallo de un sitio o el enlace de comunicación podría dar
lugar a cálculos erróneos.
◦ La función del coordinador de transacciones de un sistema distribuido es
asegurar que la ejecución de las diversas transacciones en el sistema
conserve la atomicidad. El coordinador es responsable de:
◦ Iniciar la ejecución de la transacción
◦ Dividir la transacción en varias subtransacciones y distribuirlas a los sitios
apropiados para su ejecución
◦ Coordinar el término de la transacción, con el resultado de que la transacción se
confirma en todos los sitios o se aborta en todos los sitios

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Atomicidad
◦ El protocolo de confirmación de dos fases
◦ Asegurar la atomicidad de la transacción, con este objeto el coordinador de
transacciones de T debe ejecutar un protocolo de confirmación
◦ Sea T una transacción iniciada en el sitio Si, y sea Ci el coordinador de transacciones
de Si. Cuando T termina su ejecución, Ci inicia el protocolo
◦ Fase 1:
◦ Ci añade el registro <preparar T> a la bitácora y escribe el registro en almacenamiento
estable
◦ Envía un mensaje preparar T a todos los sitios en donde T se ejecutó
◦ El administrador de transacciones del sitio determina si está dispuesto o no a confirmar su
porción de T
◦ SI  añade un registro <listo T> a la bitácora y responde con un mensaje listo T, escribe
todos los registros de bitácora correspondiente en almacenamiento estable
◦ NO  añade un registro <no T> a la bitácora y responde con un mensaje abortar T

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Atomicidad
◦ El protocolo de confirmación de dos fases
◦ Fase 2:
◦ Cuando Ci recibe respuestas al mensaje preparar T de todos los sitios, o cuando ha
transcurrido un intervalo de tiempo previamente especificado desde que se envió el
mensaje, se puede determinar si la transacción T se puede confirmar o abortar.
◦ La transacción T se puede confirmar si Ci recibió un mensaje listo T de todos los sitios
participantes. Si no, la transacción debe abortarse
◦ Dependiendo del veredicto se agrega un registro <confirmar T> o uno <abortar T> a la
bitácora y se escribe en almacenamiento estable
◦ Después el coordinador envía un mensaje confirmar T o abortar T a todos los sitios
participantes

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Atomicidad
◦ Manejo de fallos en 2PC
◦ Una desventaja es que un fallo del coordinador puede dar pie a bloqueo porque la
decisión de confirmar o abortar T se tendría que posponer hasta que Ci se
recupere.
◦ Fallo de un sitio participante
◦ Cuando un sitio participante Sk se recupera de un fallo, debe examinar su bitácora para
determinar el destino de las transacciones que se estaban ejecutando
◦ La bitácora tiene un registro <confirmar T>. En este caso el sitio ejecuta rehacer(T)
◦ La bitácora tiene un registro <abortar T>. En este caso el sitio ejecuta deshacer(T)
◦ La bitácora tiene un registro <listo T>. En este caso el sitio debe preguntar a Ci cuál fue el
destino de T. Si Ci está activo notificará a Sk si T se confirmó o abortó. En el primero
caso, Sk ejecutará rehacer(T); en el segundo caso ejecutará deshacer(T). Si Ci no está
activo, Sk deberá intentar averiguar el destino de T consultando otros sitios del sistema.
◦ La bitácora no contiene registros de control relativos a T. La ausencia de registros de
control implica que Sk falló antes de responder al mensaje preparar T de Ci. Se descarta
la posibilidad de haber enviado algún mensaje, Ci deberá abortar T, por lo tanto debe
ejecutar deshacer(T).
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Atomicidad
◦ Manejo de fallos en 2PC
◦ Fallo del coordinador
◦ Si el coordinador falla a la mitad de la ejecución del protocolo de confirmación para la
transacción T, los sitios participantes deben decidir el destino de T.
◦ En otros casos los sitios no pueden decidir si confirmar o abortar T, por lo que es necesario
que dichos sitios esperen la recuperación del coordinador que falló.
Si un sitio activo contiene un registro <confirmar T> en su bitácora, T deberá confirmarse
Si un sitio activo contiene un registro <abortar T> en su bitácora, T deberá abortarse
Si algún sitio activo no contiene un registro <listo T> en su bitácora, el coordinador que
falló no puede haber decidido confirmar T. En lugar de esperar a que Ci se recupere es
preferible abortar T
Si no se da ninguno de los casos anteriores, todos los sitios tienen un registro <listo T> en
sus bitácoras, pero no registros de control adicionales, es imposible determinar si se tomó
o no una decisión, por lo tanto esperar a que el coordinador se recupere.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Atomicidad
◦ Manejo de fallos en 2PC
◦ Fallo de la red
◦ Cuando un enlace falla, ninguno de los mensajes que se encaminan llegan a su destino
intacto. Desde el punto de vista de los sitios conectados, parece que los demás sitios han
fallado. Los esquemas anteriores se aplican a este caso.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Control de concurrencia
◦ La función del administrador de transacciones de un sistema de base de
datos distribuido es gestionar la ejecución de las transacciones o
subtransacciones que acceden a datos almacenados en un sitio local.
◦ Cada una de estas transacciones puede ser local o parte de una transacción
global

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Control de concurrencia
◦ Protocolos de cerraduras
◦ Los protocolos de cerraduras (semáforos) se pueden usar en un entorno
distribuido. Hay que incorporar la forma de implementar el administrador de
cerraduras.
◦ Unos protocolos permiten replicación de los datos otros no. Existen modos de
cerradura compartido y exclusivo.
◦ Esquema no replicado
◦ Cada sitio mantiene un administrador de cerraduras local para gestionar las solicitudes de
poner y quitar cerraduras a los datos que se almacenan en ese sitio
◦ Cuando una transacción desea asegurar el dato Q en el sitio Si, envía un mensaje al
administrador de cerraduras del sitio Si solicitando una cerradura en un modo dado.
◦ Si el dato Q ya tiene puesta una cerradura en un modo incompatible la solicitud se diferirá
hasta que pueda satisfacerse
◦ El esquema tiene una implementación sencilla, requiere dos transferencias de mensajes
para gestionar las solicitudes de cerradura y una para manejar las solicitudes de quitar
cerraduras
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Control de concurrencia
◦ Protocolos de cerraduras
◦ Estrategia de coordinador único
◦ El sistema mantiene un solo administrador de cerraduras que reside en un solo sitio escogido,
digamos Si
◦ Todas las solicitudes de poner y quitar cerraduras se envían al sitio Si. El administrador
determina si se puede otorgar de inmediato la cerradura, si es así envía el mensaje
correspondiente al sitio en el que se inició la solicitud; si no la solicitud se difiere hasta que
pueda satisfacerse
◦ La transacción puede leer el dato de cualquiera de los sitios en los que reside una réplica. En el
caso de una escritura, todos los sitios en los que reside una réplica deben intervenir
◦ El esquema tiene ventajas:
◦ Implementación sencilla
◦ El manejo de bloqueos mutuos es sencillo
◦ Las desventajas del esquema son:
◦ Cuello de botella
◦ Vulnerabilidad
◦ Se puede lograr un término medio entre ventajas y desventajas empleando la estrategia de
múltiples coordinadores

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Control de concurrencia
◦ Protocolos de cerraduras
◦ Protocolo predispuesto
◦ Similar al protocolo de mayoría. Difiere en que las cerraduras compartidas reciben un
tratamiento más favorable que las exclusivas.
◦ El sistema mantiene un administrador de cerraduras en cada sitio
◦ Cada administrador gestiona las cerraduras de todos los datos almacenados en ese sitio
◦ Las cerraduras compartidas y exclusivas se manejan de diferente manera:
◦ Cerraduras compartidas  la transacción pide una cerradura al administrador de
cerraduras de un sitio que contiene una réplica de Q
◦ Cerraduras exclusivas  la transacción solicita una cerradura al administrador de
cerraduras de cada uno de los sitios que contienen una réplica de Q
◦ Existe un gasto extra

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Control de concurrencia
◦ Protocolos de cerraduras
◦ Copia primaria
◦ Si existe replicación de los datos, se podría escoger una de las réplicas como copia
primaria. Así para cada dato Q, la copia primaria de Q debe residir en un solo sitio que se
llama sitio primario de Q
◦ Si una transacción necesita poner una cerradura al dato Q la solicita en el sitio primario de
Q
◦ La copia primaria permite manejar control de concurrencia de datos replicados de forma
similar a como se hace con datos no replicados.
◦ Tiene una implementación sencilla
◦ Desventaja  si el sitio primario de Q falla, entonces el dato Q estará inaccesible aunque
otros contengan una réplica

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Manejo de bloqueos mutuos
◦ Una situación de bloqueo mutuo es no deseable en el sistema.
Para eso existe:
◦ Prevención de bloqueos mutuos
◦ Existe la estrategia de ordenación por marca de tiempo con
expropiación de recursos
◦ Detección de bloqueos mutuos
◦ Existe el grafo de espera global, generado a partir de todos los grafos de
espera locales

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Manejo de bloqueos mutuos
◦ Prevención de bloqueos mutuos
◦ Se puede usar la prevención por ordenación de recursos con solo definir
una ordenación global entre los recursos del sistema. Asignar a los recursos
números únicos y un proceso puede solicitar con este número, solo si no
está ocupando un recurso cuyo número es mayor que i.
◦ Se puede utilizar también el algoritmo del banquero, designando a uno de
los procesos como banquero. Este esquema se puede implementar pero
requiere demasiado gasto extra
◦ Existe un nuevo esquema de prevención: ordenación por marca de tiempo
con expropiación de recursos
◦ Para controlar la expropiación se asigna un número de prioridad único a cada
proceso. Estos números sirven para decidir si un proceso Pi debe esperar a un Pj.
◦ Ventaja: Este esquema previene los bloqueos mutuos porque no puede haber
ciclos
◦ Desventaja: Puede haber inanición, procesos con prioridad muy baja se revierten
siempre
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Manejo de bloqueos mutuos
◦ Detección de bloqueos mutuos
◦ El algoritmo de prevención podría expropiar recursos aún si no ha ocurrido un bloqueo
mutuo. Para evitar expropiaciones innecesarias se usa un algoritmo de detección
◦ Se construye un grafo de espera que describe el estado de asignación de recursos. Se
supone que hay un solo recurso de cada tipo, con lo que un ciclo representa un bloqueo
mutuo.
◦ El problema en un entorno distribuido es cómo mantener el grafo de espera.
◦ Se requiere que cada sitio mantenga su grafo de espera local. Los nodos del grafo corresponden a
todos los procesos (locales y no locales) que actualmente tienen o están solicitando recursos
locales de ese sitio.
◦ Los grafos se construyen de la forma acostumbrada
◦ Si un proceso Pi del sitio A necesita un recurso que está en poder del proceso Pj del sitio B, Pi
envía un mensaje de solicitud al sitio B. La arista Pi  Pj se inserta en el grafo de espera local del
sitio B
◦ El hecho de que no haya ciclos en ninguno de los grafos de espera locales no implica que
no haya bloqueos mutuos
◦ Existen varios métodos para organizar los grafos de espera en un sistema distribuido:
◦ Estrategia centralizada
◦ Estrategia totalmente distribuida
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Manejo de bloqueos mutuos
◦ Detección de bloqueos mutuos

◦ .

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Manejo de bloqueos mutuos
◦ Detección de bloqueos mutuos
◦ Estrategia centralizada
◦ Se construye un grafo de espera global como la unión de todos los grafos de
espera locales y se mantiene en un solo proceso el coordinador de detección de
bloqueos mutuos.
◦ Hay tres opciones distintas para la construcción del grafo
◦ Cada vez que se inserta o se elimina una arista en uno de los grafos de espera
locales
◦ Periódicamente, cuando ha ocurrido cierto número de cambios en un grafo de
espera
◦ Cada vez que el coordinador necesita invocar el algoritmo de detección de
ciclos

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Manejo de bloqueos mutuos
◦ Detección de bloqueos mutuos
◦ Estrategia totalmente distribuida
◦ Todos los controles comparten igualmente la responsabilidad de detectar bloqueos mutuos
◦ Cada sitio construye un grafo de espera local que representa una parte del grafo total, dependiendo del
comportamiento dinámico del sistema.
◦ La idea es que si existe un bloqueo mutuo, aparecerá un ciclo en (por lo menos) uno de los grafos
parciales

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Algoritmos de elección
◦ Muchos algoritmos distribuidos utilizan un proceso coordinador que
desempeña funciones que los demás procesos del sistema necesitan
◦ Si el proceso coordinador falla, el sistema sólo podrá continuar
funcionando si reinicia una nueva copia en algún otro sitio.
◦ Determinan dónde debe reiniciarse una nueva copia del coordinador
◦ El coordinador es siempre el proceso que tiene el número de prioridad más
alto. Así cuando un coordinador falle, el algoritmo elegirá el proceso activo
cuyo número de prioridad sea el mas alto
Algunos algoritmos son:
Algoritmo del grandullón
Algoritmo del anillo

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida - investigación
Algoritmos de elección
◦ Algoritmo del grandulón
◦ El proceso Pi envía un mensaje de elección a todos los procesos que tienen prioridad mas alta
◦ Si Pi no recibe respuesta dentro de un tiempo T, se autoelige como coordinador y comunica
◦ Si Pi recibe una respuesta a su primer mensaje, inicia un intervalo de espera para recibir un
mensaje que le informa que un proceso con prioridad mayor ha sido elegido.
◦ Si no se envía un mensaje se entiende que el proceso que tenía el número mas alto falló y se
debe reiniciar el algoritmo.
◦ Si Pi no es el coordinador entonces en cualquier momento durante su ejecución Pi podría recibir
uno de los dos mensajes siguientes del proceso Pj
◦ Pj es el nuevo coordinador (j>i). El proceso Pi registra esta información
◦ Pj inició una elección (j<i). El proceso Pi envía una respuesta a Pj e inicia su propio algoritmo de elección
◦ El proceso que completa su algoritmo tiene el número más alto y se elige como coordinador,
habiendo enviado su número a todos los procesos activos que tienen números más bajos
◦ Cuando un proceso que falla se recupera inicia la ejecución del mismo algoritmo
◦ Si no hay procesos activos con números mas altos el proceso recuperado obliga a todos los
procesos con números mas bajos a dejarlo convertirse en el coordinador aunque ya haya un
coordinador activo. Es por esto que el algoritmo se denomina del grandullón.
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Algoritmos de elección
◦ Algoritmo del anillo
◦ Supone que los enlaces son unidireccionales y que los procesos envían sus
mensajes a su vecino de la derecha
◦ La principal estructura que se emplea es la lista activa que tiene los números de
prioridad de todos los procesos activos en el sistema
◦ Funciona así:
◦ Si el proceso Pi detecta que el coordinador falló, crea una nueva lista activa vacía. Luego
envía un mensaje elegir(i) a su vecino de la derecha y añade el número i a su lista activa
◦ Si Pi recibe un mensaje elegir(j) del proceso de la izquierda, deberá responder de una de
tres maneras:
◦ Si es el primer mensaje elegir que ha recibido o enviado, Pi crea una nueva lista activa con
los números i, j. Pi envía el mensaje elegir(i) seguido del mensaje elegir(j)
◦ Si i<>j (es decir el mensaje recibido no contiene el número de Pi), Pi añade j a su lista
activa y reenvía el mensaje a su vecino de la derecha
◦ Si i=j (es decir Pi recibe el mensaje elegir(i) la lista activa de Pi ya contiene los números de
todos los procesos activos del sistema. El proceso Pi puede determinar cuál es el número
más grande de la lista activa
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Coordinación Distribuida
Acuerdos
◦ Para que un sistema sea confiable es necesario un mecanismo que
permita a un conjunto de procesos ponerse de acuerdo en un valor
común
◦ Pueden existir algunas causas por las que no se cumpla el acuerdo
◦ El medio de comunicación podría tener fallos
◦ Los procesos mismos podrían fallar y tener un comportamiento impredecible
◦ Problema de los generales bizantinos Comunicaciones no confiables
◦ Para detectar fallos se usa un esquema de tiempo límite
◦ Procesos con fallos
◦ Existe un algoritmos con dos rondas de intercambio de información:
◦ Cada proceso envía su valor privado a los otros procesos
◦ Cada proceso envía la información que obtuvo en la primera ronda a todos los demás
procesos.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Sistemas operativos de red
•Proporciona un entorno en el que los usuarios pueden acceder a los recursos
remotos ya sea iniciando una sesión o transfiriendo datos desde la máquina remota.

•Inicio de sesión remoto

• Los usuarios inician una sesión en un computador remoto
• Internet ofrece recurso telnet
• Debe existir una cuenta válida en la máquina

•Transferencia remota de archivos

• Otro mecanismo es la de transferir archivos de una máquina a otra
• Internet ofrece FTP (File Transfer Protocol)
• Debe existir una cuenta, también los comandos get, put,

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Sistemas operativos distribuidos
Presentan las siguientes ventajas [Sánchez, 1995]:
•Facilitan la implementación de sistemas distribuidos.
•Proveen abstracciones de los recursos en un sistema distribuido, por
ejemplo: canales de comunicación y procesos en lugar de redes y
procesadores.
•En los sistemas abiertos no existe una clara división entre el sistema
operativo distribuido y las aplicaciones que se ejecutan en él.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Sistemas operativos distribuidos
• Los usuarios acceden a recursos remotos del mismo modo como lo hacen a los locales
• Migración de datos
• Dos estrategias: a) transferir todo el archivo; y b) transferir aquellas porciones del
archivo necesarias
• No solo hay que transferir, es necesario a veces efectuar diversas traducciones si no son
compatibles
• Migración de cómputos
• Podría ser más eficiente transferir el cómputo en lugar de traer los datos
• RPC  llamada a procedimiento remoto
• Migración de procesos
• Extensión lógica de la migración de cómputos, un proceso no siempre se ejecuta donde
se inició
• Se puede ejecutar en varios sitios por las siguientes razones:
• Balanceo de carga
• Agilización del cómputo
• Preferencias de hardware
• Preferencias de software
• Acceso a datos

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Servicios remotos
•Un usuario necesita acceder a datos en algún otro sitio
•Un servidor remoto atiende la solicitud y finalmente transfiere los datos de
vuelta al usuario
•Servicio remoto
• Las solicitudes se traducen en mensajes para los servidores y las respuestas del
servidor se empacan como mensajes y se envían de vuelta a los usuarios

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Servicios remotos
Llamadas a procedimiento remoto
• RPC  Llamada a procedimientos remotos

• Se utiliza un esquema de comunicación basado en mensajes para proporcionar un servicio remoto

• La comunicación remota se la logra a través de un puerto, que no es mas que un número que se incluye al
principio de un paquete de mensaje

• Llamadas a procedimientos locales fallan en circunstancias extremas, las RPC pueden fallar, duplicarse,
ejecutarse más de una vez. Para ello los sistemas anexan a cada mensaje una marca de tiempo

• Otro aspecto importante es la comunicación entre el servidor y el cliente

• ¿Cómo averigua un cliente los números de puerto del servidor?
• La vinculación se decide con antelación: direcciones de puerto fijas
• La vinculación es dinámica mediante un mecanismo de encuentro (demonio de encuentros), gasto extra
pero es más flexible

• El esquema de llamadas a procedimientos remotos es útil para implementar un sistema de archivos distribuido

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Servicios remotos
Hilos
• Los sistemas distribuidos a menudo utilizan tanto hilos como llamadas a procedimientos remotos

• Los hilos pueden servir para enviar y recibir mensajes mientras otras operaciones dentro de la tarea
continúan asincrónicamente

• Recepción implícita: un hilo que ha llevado a cabo un trabajo desaparece, el núcleo crea un nuevo
hilo para atender las solicitudes entrantes

• Hilos desplegables: hilos que se crean cuando se necesita responder a una nueva RPC, mas eficiente
cuesta menos iniciar un nuevo que restaurar uno ya existente

• Los hilos no se bloquean por lo que no hay que guardar ni restaurar su contexto

Existen hilos en el servidor ST (Server Thread) y en el cliente CT (Client Thread). Un ST exporta su

interfaz al núcleo, en la interfaz se definen procedimientos, parámetros, etc., un CT que importa
recibirá un identificador único que usará después para efectuar la llamada.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Robustez
• Un sistema distribuido puede sufrir varios tipos de fallos de hardware: enlace, sitio, pérdida de
un mensaje.
• Para que el sistema sea robusto, debe ser capaz de detectar uno de estos fallos, reconfigurar de
modo que se pueda continuar y recuperarse cuando un sitio o enlace se repare
• Detección de fallos
• Para detectar se utiliza un procedimiento de saludo: “estoy activo”
• Existe un tiempo límite para determinar si hubo un fallo o no
• Puede haber ocurrido una de estas situaciones:
• El sitio está inactivo El enlace directo falló
• El camino alternativo falló El mensaje se perdió

• Reconfiguración
• Ante la detección de una falla en un enlace o en un sitio, se debe notificar a todas las
máquinas para que eviten enviar mensajes a dicha máquina o utilizar ese enlace
• Ante la presencia de un fallo, los sitios deben iniciar un procedimiento que permita al
sistema reconfigurarse y continuar
• Recuperación después de un fallo
• Cuando se repara el enlace o sitio que falló, es preciso integrarlo en el sistema sin
interrupciones
• Se debe notificar de esto a todos los sitios participantes
1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Aspectos de diseño
• Un reto que se ha enfrentado es hacer que la multiplicidad de procesadores y dispositivos de
almacenamiento sea transparente para los usuarios. Los usuarios del sistema deben percibirlo
como centralizado

• La interfaz con el usuario no debe distinguir entre recursos locales y remotos

• Otro aspecto es la movilidad de los usuarios, pueden ingresar en cualquier máquina y no

obligarlos a usar una máquina específica

• Tolerancia a fallos, un sistema deberá seguir funcionando aunque en forma degradada pese a
alguna descompostura de dispositivos

• Debe tener capacidad para adaptarse a un aumento en la carga de servicio, los recursos deberán
alcanzar un estado saturado en un tiempo más largo  escalabilidad

• La tolerancia a fallos y escalabilidad están relacionadas entre sí. Una ventaja de los sistemas
distribuidos es su potencial para tolerar fallas y aumentar su escala, gracias a la multiplicidad de
recursos.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 1. Antecedentes
2. Nombres y transparencia
3. Acceso a archivos remotos
4. Servicios con y sin estado
5. Replicación de archivos
6. Ejemplos de sistemas

2. Sistemas de Archivos Distribuidos (DFS)

 Antecedentes
•El propósito de un DFS (Distributed File System) es apoyar el mismo tipo de
compartimento cuando los archivos están dispersos físicamente entre los diversos
sitios de un sistema distribuido
•Para entender un DFS es necesario definir
• Servicio es una entidad de software que se ejecuta en una o más máquinas y
realiza una función a favor de clientes que no conoce
• Servidor es el software de servicio que se ejecuta en una sola máquina
• Cliente es un proceso que puede invocar un servicio empleando un conjunto de
operaciones que constituyen su interfaz de cliente.

•Una interfaz de cliente para un servicio de archivos consta de un conjunto de

operaciones primitivas como crear, eliminar, leer, escribir en un archivo
•Un DFS es un sistema de archivos cuyos clientes, servidores, dispositivos de
almacenamiento están dispersos entre las máquinas de un sistema distribuido

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Antecedentes
•Se puede implementar un DFS como parte de un sistema operativo distribuido o bien
con una capa de software cuya tarea es gestionar la comunicación entre sistemas
operativos y sistemas de archivos convencionales La multiplicidad y dispersión de sus
servidores y dispositivos de almacenamiento debe ser transparente, corresponde a
un DFS localizar los archivos y encargarse del transporte de los datos

•El desempeño está en el tiempo que toma satisfacer diversas solicitudes de

servicio. En un DFS un acceso remoto tiene el gasto adicional de una estructura
distribuida, tiempo para presentar la solicitud a un servidor, tiempo para devolver la
respuesta al cliente a través de la red.

•Unidad componente es el conjunto de archivos mas pequeño que se puede

almacenar en una sola máquina con independencia de las demás unidades. Todos los
archivos que pertenecen a la misma unidad componente deben residir en el mismo
lugar.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Nombres y transparencia
•Los nombres establecen una correspondencia entre objetos lógicos y
físicos
•En un DFS transparente se agrega una nueva dimensión a la abstracción:
la de ocultar en qué lugar de la red se encuentra el archivo.
•Estructuras de nombres
• Transparencia de ubicación: el nombre de un archivo no da indicio de la
posición física de almacenamiento del archivo
• Independencia de ubicación: no es necesario modificar el nombre de un
archivo si la posición física de almacenamiento del archivo cambia
• Los archivos tienen diferentes nombres en los diferentes niveles
(nombres textuales en el nivel de usuario, identificadores numéricos en
el nivel del sistema)

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Nombres y transparencia
Esquema de nombres
• Hay tres tipos principales de esquemas en un DFS
• El enfoque más sencillo los archivos se nombran con alguna combinación
del nombre de su anfitrión y su nombre local, lo que garantiza un nombre
único en el nivel del sistema. Este nombre no es transparente ni
independiente respecto a la ubicación
• El segundo enfoque cuenta con un mecanismo para ligar directorios
remotos a directorios locales y así dar la apariencia de un árbol de
directorios coherente. Hay necesidad de montar los directorios remotos.
• Una sola estructura de nombres global abarca todos los archivos del
sistema

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Acceso a archivos remotos
•Cuando se hace una solicitud de acceso a un archivo remoto se emplea
un mecanismo de servicio remoto en el que las solicitudes se entregan
al servidor, éste realiza los accesos y los resultados se envían al usuario.
•Este servicio remoto se implementa con llamadas a procedimientos
remotos RPC
•Para asegurar que un mecanismo de servicio remoto tenga un
desempeño razonable, se puede usar cachés. En los sistemas de
archivos convencionales el motivo de usar cachés es reducir la E/S de
disco, mientras que en los DFS es reducir el tráfico de red como la E/S
de disco.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Acceso a archivos remotos
Esquema de uso de caché básico
• Si los datos que se necesitan no están ya en caché, se trae una copia desde el
sistema del servidor hasta el del cliente
• La idea es conservar los bloques de disco de acceso reciente en un caché a fin de
poder manejar localmente accesos repetidos a la misma información sin tráfico
de red adicional
• Se usa una política de reemplazo para mantener limitado el tamaño
• Si una copia en caché se modifica es preciso reflejar los cambios en la copia
maestra para preservar la semántica de consistencia
• El problema de implementar cachés es la consistencia
• Si se incrementa la unidad de colocación aumenta la tasa de aciertos pero
también el costo de no acertar, porque cada no acierto requiere la transferencia
de mas datos y aumenta la posibilidad de problemas de consistencia

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Acceso a archivos remotos
Comparación del uso de cachés y el servicio remoto
• Un número sustancial de los accesos remotos se puede atender desde el
caché local cuando se usan cachés. Esto permite atender los accesos
remotos casi con la misma rapidez que los locales
• El gasto extra de la red cuando se transmiten volúmenes grandes de datos
es menor cuando se transmite una serie de respuestas a solicitudes
específicas como en el método de servicio remoto.
• Las rutinas de acceso a disco en el servidor se pueden optimizar mejor si se
sabe que siempre se solicitarán segmentos grandes y contiguos de datos en
lugar de bloques de disco aleatorias
• El problema de la consistencia del caché es la principal desventaja del uso
de cachés
• Para que resulte provechoso los cachés, la ejecución debe realizarse en
máquinas que tengan discos locales o bien memorias principales grandes,
caso contrario debe efectuarse empleando servicio remoto

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Servicio con y sin estado
•Hay dos enfoques respecto a la información en el lado del servidor: o bien el servidor
sigue la pista a cada archivo que está siendo accedido por un cliente o simplemente
proporciona los bloques sin enterarse de cómo se usarán.
•En algunos entornos solo puede usarse servicios con estado. Si el servidor emplea el
método de verificación de caché iniciado por el servidor, no podrá ofrecer servicio
sin estado, ya que debe mantener un registro de cuáles archivos colocan en caché
cuáles clientes.
•Servicio de archivos con estado
• El servidor conoce exactamente paso a paso toda la operación con el archivo, guarda
en su memoria y proporciona al cliente un identificador de conexión, con esto se
accede y trabaja en memoria lo que ahora accesos a disco

•Servicio de archivos sin estado

• Cada solicitud es autosuficiente, el servidor no necesita mantener una tabla de
archivos abiertos en memoria. El costo de implementar esto es que los mensajes de
solicitud son mas largos y el procesamiento de las solicitudes es más lento ya que no
hay información en el núcleo.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Replicación de archivos
•La replicación de archivos en diferentes máquinas es una redundancia
útil para mejorar la disponibilidad y también puede mejorar el
desempeño
•El requisito básico de un esquema de replicación es que las réplicas del
mismo archivo residan en máquinas independientes en cuanto a los
fallos
•Es deseable ocultar a los usuarios los detalles de la replicación
•La existencia de réplicas debe ser invisible para los niveles superiores, no
obstante las réplicas se deben distinguir entre si con nombres de bajo
nivel distintos.
•El principal problema relacionado con las réplicas es su actualización,
hay que conservar la semántica de consistencia.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos

 Ejemplos
NFS (Network File System)
• Diseñado por la compañía Sun Microsystems en 1985 con el propósito de ejecutarse en
una red local (LAN).
• El sistema NFS está dividido al menos en dos partes principales: un servidor y uno o más
clientes.
• Los clientes acceden de forma remota a los datos que se encuentran almacenados en el
servidor.

AFS (Andrew File System)

• Se trata de un sistema de ficheros distribuido que permite a distintas estaciones que
cooperan, compartir ficheros en red.
• Implementa Kerberos como mecanismo de autenticación.
• Para el control de acceso usa listas en directorios para usuarios y grupos.

1 2 3 4 5 6 1 2 3 4 5 6

1. Estructura de Sistemas Distribuidos 2. Sistemas de archivos distribuidos