Scon 9 SSDD

Sistemas Distribuidos
I.T. Informática de Sistemas

Curso 2002-2003
Bibliografía
• Sistemas Operativos Distribuidos

 A. S. Tanenbaum, Prentice Hall, 1995
• Principles of Concurrent and Distributed
Programming
 M. Ben-Ari. Prentice Hall, 1990
 Capítulos 11,12 y 13
• Sistemas Distribuidos. Conceptos y Diseño
 G. Coulouris, J. Dollimore, T. Kindberg, Addison
Wesley, 2001
SistemasConcurrentes
Sistemas Distribuidos
• El concepto de sistema distribuido se opone al

de
sistema centralizado  el basado en una sola
CPU+memoria+disco, con uno o varios puestos
de trabajo.
• Varias CPUs desacopladas (unidas por una red)
Definición de sistema distribuido
• Definición para empezar:
“Un sistema distribuido es una colección de

computadoras independientes que aparecen
ante los usuarios del sistema como una única
computadora”
Ventajas de los ss.dd.
• Prestaciones relativas: Resulta más rentable

aumentar la potencia del sistema CPU
comprando más ordenadores, que comprando
una CPU más potente.
• Velocidad: Un solo procesador no puede
alcanzar tanta velocidad como queramos
(existen límites físicos)
• Escalabilidad: Si se desea más potencia, en
un s.d. basta con comprar más
microprocesadores. Además, los equipos
antiguos pueden seguir dando servicio.
Ventajas de los ss.dd.
• Aplicaciones distribuidas: Muchas

aplicaciones sólo se conciben como distribuidas
(correo electrónico, sistemas de información en
Internet, trabajo corporativo, bancos, etc.)
• Fiabilidad: Si una sola máquina se viene abajo,
el sistema en conjunto puede continuar dando
servicio.
Más ventajas
• Compartición de recursos (discos, CPUs,

impresoras...)
• Compartición de información
• Facilidad de comunicación interpersonal
• Flexibilidad de uso:
 todos los servicios están disponibles desde cualquier
puesto
 la ejecución puede realizarse en otras máquinas que
estén menos cargadas
Características problemáticas de
un s.distr.
• Fallos independientes pueden afectar a otras

partes
• Comunicación no fiable: fallos en la red
• Comunicación insegura
• Comunicación costosa: ahora no tanto
• Heterogeneidad de los nodos
Inconvenientes
• Actualmente no hay software para gestionar

apropiadamente un sistema distribuido
• La probabilidad de fallos en partes del
sistema es mayor
• Hay más problemas de seguridad
• Hay más problemas de administración
• Nuestro sistema local puede verse afectado
por fallos en máquinas de otros lugares
Hardware
• Podemos dividir las computadoras paralelas y

distribuidas en:
 Multiprocesadores (memoria compartida)
 Multicomputadoras (memoria privada)
• A su vez podemos subdividir ambas según el soporte
físico de comunicación:
 Bus o backplane (p.ej. LANs)
 Conmutadores (p.ej. transputer)
• Podemos distinguir entre sistemas débilmente acoplados
y sistemas fuertemente acoplados, según sea el retraso
de transmisión de mensajes y la tasa de transferencia
de datos
Software
• El hardware es importante, pero en los sistemas

distribuidos es software lo es aún más
• En ss.dd. el software es más complejo que el
hardware. Todavía se investiga
• El software también puede ser:
 débilmente acoplado: menor interacción entre
módulos o componentes. Ej. ajedrez en red
 fuertemente acoplado: mayor interacción. Ej. Quake
en red
Software
• Sistemas software débilmente acoplados en hardware

débilmente acoplado => sistemas operativos de red
• Ejemplo más común: equipos conectados a través de
una red local
• Al principio había utilidades primitivas como rlogin o rcp
• Luego aparecieron servidores de archivos, compartición
de impresoras, etc.
• De no ser por estos servicios de compartición al usuario
le parecería que el sistema consta de varias
computadoras totalmente independientes
Software
• Sistemas software fuertemente acoplados en hardware

débilmente acoplado: => sistemas realmente
distribuidos
• Objetivo: crear la imagen de un único sistema
• para quién?
 para el usuario
 para el programador (más difícil de lograr)
• Su diseño y construcción presenta numerosos problemas
y dificultades
Software
• Middleware: se aplica al software que provee una

abstracción de programación que permite soslayar la
heterogeneidad de los sistemas operativos y redes
empleadas
• Se crean para facilitar la creación de aplicaciones
distribuidas
• Ejemplos: Sun RPC, Java RMI y CORBA
• CORBA, por ejemplo, proporciona invocación sobre
objetos remotos, sin que el programador sepa cómo y
por dónde se realiza la comunicación necesaria para
realizarla
Aspectos de diseño
• Transparencia
Transparencia de Los recursos tienen nombres que no
localización denotan la máquina en la que están
Transparencia de Los recursos deben poder moverse de
migración una posición a otra sin tener que
cambiar sus nombres
Transparencia de Se debe poder mantener copias de los
réplica recursos sin que lo noten los usuarios
Transparencia de Varios usarios deben poder compartir
concurrencia recursos sin problemas
Transparencia de Los programas deberían aprovechar el
paralelismo paralelismo sin intervención de los
usuarios
Aspectos de diseño
• Flexibilidad: en ss.dd. interesa la máxima

flexibilidad
• Los sistemas operativos pueden ser:
 monolíticos: poco flexibles
 de micronúcleo: hay un kernel muy simple y servidor
de sistema de ficheros, de procesos, etc. Más flexible
Aspectos de diseño
• Confiabilidad: si alguna máquina falla, alguna otra máquina se

encargue del trabajo
• En teoría la confiabilidad total del sistema debería ser el OR de la
confiabilidad de los distintos componentes
• En la práctica esto no suele ser así:
“un s.d. es aquel del cual no puedo obtener un trabajo debido a
que cierta máquina de la cual nueca he oído se ha roto”, Leslie
Lamport
• Disponibilidad: la fracción de tiempo en que se puede utilizar el

sistema
• Tolerancia a fallos: ¿cómo de bien tolera el sistema los fallos? Si un
servidor falla y se rearranca ¿se recupera el sistema fácilmente?
Aspectos de diseño
• Eficiencia: además de transparente, flexible y

confiable, un s.d. debe ser rápido y eficiente
• A este respecto, en los s.d. es muy importante
la velocidad de la red utilizada
• Los cálculos pueden ser de grano fino (p.ej
sumar dos números) o de grano grueso
• Para cálculos de grano fino no compensa que se
realicen en otras máquinas, porque se tarda
más en la comunicación que en el cálculo
Aspectos de diseño
• Escalabilidad: hay que evitar:

 los componentes centralizados: p.ej. un
supercomputador servidor central
 tablas –bases de datos- centralizadas
 algoritmos centralizados: hay que intentar que:
 ninguna máquina tenga información global acerca del
estado del sistema
 las máquinas tomen decisiones solo en base a la
información local
 no se confíe en un reloj global
Comunicación en los ss.dd.
• La diferencia más importante entre un s.d y un sistema

con un solo procesador es la comunicación entre
procesos
• En un sistema con un procesador, la comunicación entre
procesos supone de manera implícita la existencia de
memoria compartida
• Incluso la forma más básica de sincronización, el
semáforo, supone la existencia de una variable
compartida (la propia variable del semáforo)
• En los ss.dd. no contamos con esa memoria compartida,
hemos de replantear la comunicación de procesos desde
cero
• Debido a la ausencia de memoria compartida, la

comunicación en los ss.dd. se basa en la
transferencia de mensajes a través de la red
• Las redes se suelen estudiar en base al modelo
de referencia para interconexión de
sistemas abiertos (OSI)
• El modelo OSI divide en 7 capas los diferentes
elementos y servicios que intervienen en las
comunicaciones
• Cada capa utiliza servicios (funciones) de la capa inferior

y ofrece servicios a la capa superior
• Cada paquete enviado por una capa se compone de
control + datos
• El conjunto control+datos de una capa viaja en los
datos de la capa superior
capa i control datos
capa i-1 control datos
• Capas OSI que nos interesan:
 Capa física: se encarga de la transmisión de bits por un canal

físico de comunicación (sea análogico o digital)
 Capa de enlace: implementa control de errores para compensar
los que se producen en el medio físico
 Capa de red: se encarga de encaminar la información del nodo
origen al nodo destino, a través de redes y subredes
 Capa de transporte: divide los datos a enviar en paquetes y se
asegura de que todos llegen correctamente al destino
• Tipo de conexión:
 circuito virtual u orientado a conexión: al conectar se

realiza una búsqueda de un camino libre entre origen
y destino. Se mantiene el camino en toda la conexión
 no orientado a conexión: no se fija un camino. Cada
paquete podrá ir por cualquier sitio. No se garantiza
la recepción secuencial
• El modelo OSI fue bosquejado en los 70. Las redes de modo de

transferencia asíncrono (ATM) son de reciente aparición
• Las compañías telefónicas se dieron cuenta de que el tráfico de voz
requería bajo ancho de banda pero constante, mientras el tráfico de
datos requería alto ancho de banda pero solo en determinados
momentos
• ATM se basa en la transferencia de bloques de tamaño fijo (celdas)
sobre circuitos virtuales.
• Al iniciar la comunicación se configuran los conmutadores en la red
para formar un circuito virtual que se mantiene en toda la
comunicación
• El uso de celdas de tamaño pequeño y fijo facilita la conmutación
• La red ATM integraba voz, televisión y datos, reemplazando lo que
antes eran redes separadas
El modelo cliente-servidor
• Existen procesos servidores, que proporcionan

cierto recurso o servicio, y procesos clientes que
hacen solicitudes a los servidores
• El servidor recibe peticiones y envía respuestas
• Direccionamiento: ¿cuál es la dirección del

servidor que debe usar el cliente?
• Posibilidades:
 máquina.proceso
 el proceso servidor elige una dirección al azar, el
cliente debe emitir un paquete especial de
localización
 usar un servidor de nombres; el cliente interroga
primero al servidor de nombres
• Las primitivas de envío y recepción podrán ser:

 con bloqueo o síncronas
 sin bloqueo o asíncronas. ¿cómo saber que ya se
puede volver a usar el buffer de envío?
 send con bloqueo hasta que el mensaje se envie
 send sin bloqueo, con copia del mensaje en buffer interno
 send sin bloqueo, con interrupción que señaliza que ya se
puede usar el buffer
• Una primitiva típica es receive(addr,&m)

• ¿qué pasa si el emisor envía la petición antes de
que el servidor pueda hacer el receive?
probablemente la petición se pierda!
• Podríamos usar primitiva con almacenamiento
en buffer: un buzón
• El buzón se activa nada más arrancar el
servidor. El receive obtiene las peticiones del
buzón o bien se bloquea
• Si las primitivas son fiables no hay ningún problema,

pero en la práctica pueden no serlo
• Una posible solución es que el usuario se encargue de
resolver el problema
• Pero el S.O puede usar reconocimientos
automáticamente:
1 1
cliente 3 servidor cliente 2 (respuesta) servidor
4 3
kernel kernel kernel kernel
2
Llamada a procedimiento remoto
(RPC)
• El modelo cliente-servidor asigna dos primitivas, send y

receive, que debemos necesariamente usar para la E/S.
A partir de ahí, todo debe construirlo el usuario
• La llamada a procedimiento remoto se ideó para facilitar
la comunicación entre máquinas
• Un procedimiento en la máquina A llama a un
procedimiento en la máquina B
• A se bloquea hasta que el procedimiento de B termine
• El programador no se preocupa de los mensajes
enviados entre A y B; la llamada a procedimiento
remoto debe ser lo más parecida posible a una llamada
local
(RPC)
• Dificultades para implementar RPC:

 las máquinas utilizan espacios de direcciones
distintos, ¿punteros?, ¿variables globales?
 la transferencia de parámetros y resultados, ¿son los
tipos iguales en ambas máquinas? big endian/litte
endian, ASCII/EBCDIC
 fallo de alguna de las máquinas
(RPC)
count=read(fd, buf, nbytes);
• La llamada read ejecuta una rutina especial de biblioteca

(stub) que bloquea al cliente y mete los parámetros en
mensajes que envia a la máquina remota
• El stub de la máquina remota desempaqueta el mensaje
y ejecuta una llamada read local
• La respuesta es devuelta en mensajes que
desempaqueta el stub emisor y devuelve al que hizo la
llamada, desbloqueándolo
(RPC)
• La transferencia de parámetros se realiza

codificando/decodificando a un formato de tipos
prefijado
• La transferencia de punteros puede hacerse por
copia de zonas de memoria, pero en ciertos
casos es mucho más difícil
(RPC)
• ¿cómo especifica el cliente la dirección del servidor?

• mediante la conexión dinámica
• se emplea una especificación de un servidor: nombre, versión y
servicios que proporciona
specification of file_server, version 3.1:

long read(in char name[MAX_PATH], out char buf[BUF_SIZE,
in long bytes, in long position);
...
• La especificación es usada por los stubs cliente y servidor. Cuando

un programa (cliente o servidor) va a hacer uso de alguno de los
servicios de esta especificación el correspondiente stub se linka con
él
(RPC)
• El servidor envía un mensaje a un programa llamado

conector para darle a conocer –exportar- su nombre,
versión y dirección (IP, p.ej.)
• Cuando el cliente llama a un procedimiento remoto por
primera vez, envía un mensaje al conector, solicitando la
importación de la versión 3.1 de la interfaz file_server
• Si no está el servidor, o no tiene esa versión, la llamada
del cliente fracasa
• En caso contrario, se envía al cliente la dirección en la
que podrá conectar con el servidor
(RPC)
• Fallos que se pueden dar:

 El cliente no puede localizar al servidor
 Se pierde el mensaje de solicitud del cliente al
servidor
 Se pierde el mensaje de respuesta del servidor al
cliente
 El servidor falla antes de recibir una solicitud
 El cliente falla después de enviar una solicitud
Comunicación en grupo
• La comunicación es entre un grupo de procesos

• Cuando un emisor envía, el mensaje lo reciben todos los
miembros de un grupo
• Los grupos se entienden como dinámicos, se pueden
crear y destruir grupos. Un proceso puede ser miembro
de varios grupos, se puede unir a uno y dejar otro
• Algunas redes permiten diferentes tipos de
broadcasting, lo que facilita la implementación de
comunicación en grupo
• Los grupos pueden ser:

 abiertos: no-miembros pueden enviar al grupo
 cerrados: solo los miembros pueden enviar al grupo
• Los miembros del grupo pueden ser iguales, o bien
existe un miembro coordinador o líder
• De existir, los envíos se hacen al coordinador, que decide
a qué miembro reenviar
• Atomicidad: cuando se envía un mensaje a un grupo,
llega a todos los miembros o no llega a ninguno
• La atomicidad es una propiedad deseable
• ¿cómo asegurar la atomicidad?

• La única forma de garantizar que cada miembro reciba
el mensaje es pedirle que devuelva un reconocimiento al
recibirlo
• pero ¿y si aun así falla alguna máquina?
• Una solución:
 El emisor envía un mensaje a todos los miembros. Se activan
cronómetros y se reenvía el mensaje en los casos necesarios
 Cuando un miembro recibe el mensaje, si lo ha visto ya lo
descarta. Si no, lo envía a todos los miembros del grupo
(usando también cronómetros y retransmisiones)
• Otra propiedad deseable es la del ordenamiento de

mensajes
• Supongamos 5 miembros. Los miembros 0,1,3 y 4
pertenecen a un mismo grupo
• A la misma vez, los miembros 0 y 4 desean enviar un
mensaje al grupo. Podrían enviarlos en este orden:
1
0 3
0 1 2 3 4
4 2
5
• ¿cómo reciben los mensajes los miembros 1 y 3?

• El miembro 1 recibe los mensajes en este orden:
 mensaje de 0
 mensaje de 4
• El miembro 3 recibe los mensajes en este orden:
 mensaje de 4
 mensaje de 0
• No se cumple el ordenamiento de mensajes!
• Esto puede ser fatal: imaginemos que fueran
operaciones sobre un base de datos replicada en los
miembros 1 y 3
• Aunque se cumpla el ordenamiento de mensajes hay

situaciones problemáticas
• Supongamos dos grupos solapados. A y D quieren
enviar a la vez un mensaje a sus compañeros de grupo:
0 B 1
A D
3 2
C
Sincronización en los ss.dd.
Sincronización en los ss.dd
• En un sistema con un procesador, la sincronización entre

procesos usa herramientas como semáforos, monitores,
etc.
• esas facilidades suponen de manera implícita la
existencia de memoria compartida
• En los ss.dd. no contamos con esa memoria compartida,
hemos de buscar otras técnicas
• Incluso el simple hecho de determinar si el evento A
ocurrió antes que el evento B requerirá reflexión
cuidadosa
Sincronización de relojes
• En un sistema centralizado, el tiempo no tiene

ambigüedades
• Si el proceso A pide la hora, y un poco después
el proceso B también la pide, el valor obtenido
por B es siempre mayor o igual que el obtenido
por A
• En un s.d. no es tan sencillo. ¿qué implica el
carecer de un reloj global?
• Pensemos en el programa make en un entorno

distribuido de dos máquinas
máquina que 2144 2145 2146 2147 tiempo del

ejecuta el compilador reloj local
output.o creado
2142 2143 2144 2145

máquina que
ejecuta el editor tiempo del
output.c creado reloj local
• La sincronización de relojes es muy importante!
• ¿se pueden sincronizar los relojes en un sistema

distribuido?
• Lamport demostró que sí: lo que importa no es una
sincronización del tiempo absoluto, sino que el orden de
los eventos sea el mismo en todas las máquinas
• En el ejemplo del make lo que importa no es la hora en
que se crean output.o y ouput.c, sino el orden en que
fueron creados
• Por otro lado, si dos procesos no interactuan, no es
necesario que sus relojes estén sincronizados
• Tipos de relojes:
 relojes lógicos: las máquinas tienen el mismo valor
de reloj, aunque marquen una hora distinta de la real
 relojes físicos: las máquinas tienen el mismo valor de
reloj, y éste no debe desvíarse de la hora real más
alla de cierta magnitud
Sincronización de relojes lógicos
• Lamport definió la relación “ocurre antes de”

• La expresión a->b se lee “a ocurre antes de b” e
indica que todos los procesos coinciden en que
primero ocurre a y después b
• se cumple:
 Si a y b son dos eventos en el mismo proceso y a
ocurre antes que b, entonces a->b es verdadero
 Si a es el evento del envío de un mensaje por un
proceso y b es el evento de la recepción del mensaje
por otro proceso, entonces a->b es verdadero
• ¿de qué forma podemos sincronizar relojes

lógicos?
• Necesitamos una forma de asociar a cada
evento a un valor de tiempo C(a) en el que
todos los procesos estén de acuerdo
• Los valores de tiempo deben tener la propiedad
de que si a->b entonces C(a)<C(b)
• El tiempo de reloj C siempre debe ir hacia
delante, nunca puede ser decreciente
• Un caso de tres procesos, cada uno con su propio reloj
0 0 0
6 A 8 10
12 16 20
18 24 B 30
24 32 40
30 40 50
36 48 C 60 Con los mensajes C y D
42 56 70 no se cumplen las reglas
48 D 64 80 anteriores!
54 72 90
60 80 100
• Solución propuesta por Lamport: puesto que C sale en

60 debe llegar en 61 o posterior, ...
0 0 0
6 A 8 10
12 16 20
18 24 B 30
24 32 40
30 40 50
36 48 C 60
42 61 70
48 D 69 80
70 77 90
76 85 100 SistemasConcurrentes
• En ciertas situaciones existe un requisito

adicional: dos eventos no ocurren exactamente
al mismo tiempo
• Para lograr esto podemos usar el tiempo en que
ocurre el evento, seguido por el número del
proceso después del signo decimal
• P.ej. si ocurren los eventos 1 y 2 ambos en el
tiempo 40, entonces el primero se convierte en
40.1 y el segundo en 40.2
Sincronización de relojes físicos
• Algoritmo de Cristian: supongamos un conjunto de

máquinas. Una de ellas tiene acceso a una fuente fiable
de la hora (la llamaremos servidor de tiempo)
máquina emisora servidor de tiempo

T0
tiempo
I, tiempo de procesamiento de
la petición
T1
• Para la máquina emisora, una buena estimación

de la hora sería
(T1-T0)/2
• Y si conocemos el valor de I:
(T1-T0-I)/2
• Se hacen varias medidas y se toma la media
• Algoritmo de Berkeley: en el algoritmo de Cristian, el

servidor de tiempo es pasivo. En el UNIX de Berkeley se
emplean servidores de tiempo activos
• El servidor de tiempo realiza un muestreo periódico de
todas las máquinas para preguntarles el tiempo
• Con base en estas respuestas, calcula el tiempo
promedio y le indica a las máquinas que avancen o
retrasen su reloj la cantidad que sea necesaria
• Algoritmos con promedio: los dos métodos anteriores tienen la

desventaja de ser centralizados. En este caso dividimos el tiempo
en intervalos de resincronización
• El i-ésimo intervalo comienza en T0+iR y termina en T0+(i+1)R,
donde T0 es un momento ya acordado en el pasado y R es una cte.
• Al comienzo de cada intervalo cada máquina transmite el tiempo
actual de su reloj. Puesto que los relojes de las diversas máquinas
ni funcionan exactamente a la misma velocidad, estas transmisiones
no ocurrirán en forma simultánea
• Tras transmitir su hora, una máquina arranca un cronómetro local
para reunir las demás transmisiones que lleguen en un cierto
intervalo S
• A partir de ellas calcula un nuevo tiempo, p.ej. con la media
• Ejemplo de uso de relojes sincronizados: entrega de

cómo máximo un mensaje
• El problema consiste en evitar que un servidor reciba
mensajes duplicados
• El método tradicional es que cada mensaje tenga un nº
de mensaje y que el servidor guarde los nºs de
mensajes recibidos
• Si recibe un mensaje con un nº que ya ha visto, lo
descarta
• Pero, ¿qué pasa si el servidor falla y pierde la tabla de
los nºs recibidos?, ¿por cuánto tiempo se deben
conservar los nºs de los mensajes recibidos?
• La solución haciendo uso del tiempo sincronizado

consiste en añadir a cada mensaje una marca de tiempo
• Para cada conexión, el servidor registra en una tabla la
marca de tiempo más reciente que haya visto
• Si la marca de un mensaje recibido es anterior a la
guardada, el mensaje se descarta por duplicado
• Se pueden eliminar las marcas anteriores que sean
anteriores a:
G=TiempoActual-TiempoMáximodeVidadeMensaje
Exclusión mutua
• Algoritmo centralizado: La forma más directa de lograrla es

similar a la forma en que se hace en un sistema uniprocesador
• Se elige uno de los procesos en la red como coordinador
• Cuando un proceso quiere entrar en una sección crítica, envía un
mensaje de solicitud al proceso coordinador
• El coordinador decide y responde afirmativamente (OK) o
negativamente (no respondiendo o con un mensaje de “permiso
denegado)
• El coordinador tiene una cola FIFO de las peticiones, por lo que no
hay inanición
• Problemas:
 el coordinador podría fallar y con él todo el sistema
 en sistemas grandes el coordinador es un cuello de botella
Exclusión mutua
• Algoritmo de Ricart-Agrawala: El tener un

coordinador central que pueda fallar puede ser
inaceptable
• Supongamos que todos los relojes del sistema están
sincronizados (p.ej usando el algoritmo de Lamport), de
forma que para cualquier par de eventos debe quedar
claro cuál ocurrió primero
• Cuando un proceso quiere entrar en una región crítica
construye un mensaje con el nombre de ésta, su
número de proceso y la hora actual
• Envía el mensaje a todos los demás procesos
Exclusión mutua
• Cuando un proceso recibe un mensaje de solicitud de

otro proceso:
 Si el receptor no está en la región crítica y no desea entrar en
ella, envía un mensaje OK al emisor
 Si el receptor ya está en la región crítica, no responde, sino que
guarda la solicitud en una lista
 Si el receptor desea entrar en la región crítica, pero no lo ha
logrado todavía, compara la marca de tiempo del mensaje
recibido con la marca que él usó en sus mensajes de solicitud:
 Si el mensaje recibido tiene marca menor, el receptor envía de
regreso un mensaje OK
 Si no, el receptor guarda la solicitud en una lista y no envía nada
Exclusión mutua
• Nótese que cuando un proceso envía una

solicitud, para poder entrar en una región crítica
debe esperar a que TODOS los demás procesos
le respondan con un mensaje OK
• Cuando sale de la región crítica envía mensajes
OK a todos los procesos en su lista y la vacía
Exclusión mutua
• Ejemplo: dos procesos, 0 y 2, quieren entrar en

la región crítica a la vez
(Entra en R.C)
0 0 0
8 12 OK OK OK
8
1 2 1 2 1 2
12 OK
(Entra en R.C)
Exclusión mutua
• Problemas del algoritmo:

 El tráfico de mensajes es mayor que en algoritmo
centralizado
 El algoritmo centralizado tenía un único punto de
fallo, pero éste tiene n puntos de fallo !
 Si se pierde una respuesta el emisor quedará esperando y
no podrá entrar en la sección crítica. Se puede mejorar
haciendo que en vez de no responder se envíe el mensaje de
“permiso denegado”
 Redundancia: todos los procesos participan en todas
las solicitudes de entrada a una región crítica
Exclusión mutua
• Algoritmo de paso de fichas:

• Tenemos una red de bus (Ethernet), pero creamos por
software un anillo
• La posición en el anillo se puede definir p.ej con el
orden de las direcciones de red
• Al principio se le da al proceso 0 del anillo una ficha. La
ficha circula por todo el anillo: el proceso k la pasa al
proceso k+1 en el anillo mediante un mensaje
• Un proceso puede entrar en la región crítica solo cuando
tenga la ficha. Al salir de la R.C pasa la ficha
• No se permite entrar en una segunda R.C con la misma
ficha
Exclusión mutua
• El algoritmo del paso de fichas es correcto y no

puede existir la inanición
• Problemas:
 Si la ficha se pierde es difícil detectar la pérdida,
puesto que la cantidad de tiempo entre apariciones
sucesivas de la ficha en la red no está acotada
(porque un proceso puede retenerla todo el tiempo
que pase en la R.C)
Exclusión mutua
• Comparación de los tres algoritmos:
Algoritmo M Retraso antes de Problema

entrar en RC
Centralizado 3 3 Fallo del

coordinador
Distribuido 2(n-1) 2(n-1) Fallo de cualq.
proceso
Paso de fichas 0 a n-1 0 a n-1 Ficha perdida
M= Mensajes necesarios para q un proceso entre y salga de una R.C
Elección de coordinador
• Muchos algoritmos distribuidos necesitan que un

proceso actúe como coordinador, iniciador, secuenciador
o que desempeñe de alguna forma un papel especial
• En el algoritmo de exclusión mutua centralizado, por
ejemplo
• A continuación analizaremos dos algoritmos para
elección de coordinador
• Se suele designar como coordinador al proceso con
dirección de red mayor
• Algoritmo del grandullón: Un proceso P realiza una elección

(cuando detecta que el coordinador ha fallado) de la siguiente
manera
• P envía un mensaje ELECCION a los demás procesos con un
número mayor
• Si nadie responde, P gana la elección y se convierte en el
coordinador
• Si uno de los procesos con número mayor responde, toma el
control. Envía un mensaje OK al emisor para indicar que está vivo y
que tomará el control
• El receptor realiza entonces una elección, si no lo está haciendo ya
• Si un proceso que antes estaba inactivo se activa, realiza una
elección. Si ocurre que es el proceso en ejecución con número
máximo, se convertirá en el nuevo coordinador
• Algoritmo de anillo: se forma un anillo lógico con los procesos,

de forma que cada proceso conoce quién es su sucesor
• Cuando un proceso detecta que el coordinador no funciona,
construye un mensaje ELECCION con su propio número de proceso
y envía el mensaje a su sucesor. Si éste está inactivo, se lo envía al
siguiente
• En cada paso, el emisor añade su propio nº de proceso a la lista en
el mensaje
• En cierto momento, el mensaje regresa al proceso que lo envió. Ese
proceso reconoce ese evento cuando recibe un mensaje de entrada
con su propio nº de proceso
• En ese momento, el mensaje recibido cambia a tipo COORDINADOR
y se hace circular de nuevo, para informar a los demás de quién es
el nuevo coordinador (el miembro de la lista con el nº máximo)
Transacciones atómicas
• Necesitamos una operación de mayor nivel, de mayor capacidad

• Tal abstracción existe y se utiliza mucho en sistemas distribuidos: la
transacción atómica
• Supongamos que queremos viajar de Las Palmas a Bata (ciudad de
Guinea Ecuatorial)
• Iremos a la agencia de viajes para intentar reservar un billete a
Madrid. Lo conseguimos
• Luego intentaremos reservar un billete de Madrid a Malabo, (en
fecha posterior al del primer viaje, naturalmente). Lo conseguimos
• Intentamos ahora buscar un vuelo de Malabo a Bata. Pero resulta
que no hay disponibles
• En ese caso deberíamos ser capaces de deshacer lo hecho, las dos
reservas anteriores
• O SE HACE TODO O NO SE HACE NADA
• Ejemplo en el ámbito informático: supongamos un

banco al que podemos conectarnos por Internet, con la
intención de retirar dinero de nuestra cuenta para
transferirlo a otra:
Retirar(cantidad, cuenta1)
Ingresar(cantidad, cuenta)
• Si la conexión telefónica falla después de la primera

operación pero antes de la segunda ?
• El problema debe resolverse haciendo que ambas
acciones constituyan una transacción atómica: o se
hacen ambas o no se hace ninguna
• Podemos tener tres tipos de almacenamiento:

 Memoria RAM: se borra al fallar la energía o en un fallo de la máquina
 Disco: sobrevive a fallos anteriores pero podría fallar la cabeza lectora
del disco
 Almacenamiento estable: diseñado para sobrevivir a todo (excepto tal
vez a un 11-S)
• El almacenamiento estable se puede lograr con un par de discos

• Cuando se quiere escribir se escribe primero en el disco 1 y luego
en el disco 2
• Si el sistema falla tras escribir en la unidad 1, tras recuperar
podemos comprobar que ambos discos son inconsistentes.
Hacemos entonces que el 2 copie lo distinto en el 1, pues el 1 es
siempre el que se modifica primero
• Cuando se detecte error (p.ej. por CRC) en un sector de uno de los
discos, se repara con la información del otro
• Trabajaremos con estas primitivas de transacción:
BEGIN_TRANSACTION
END_TRANSACTION
ABORT_TRANSACTION
• En medio de una transacción se podrán realizar diversas

operaciones, según la aplicación
• Las transacciones deberán ser todo o nada y además
deben ejecutarse en exclusión mutua unas con otras
• ¿cómo implementar las transacciones atómicas?

• espacio de trabajo privado: consiste en mantener
una copia de los objetos o memoria que se quiera
modificar
• Por ejemplo, si la transacción implica acceso a un
directorio particular, mantenemos una copia
• Intentamos llevar a cabo la transacción en la copia
• Si nada falla al final modificamos el original
• Si no, descartamos la copia
• Otra forma de implementarlas es la bitácora

• La bitácora es una lista de los cambios que se van realizando sobre cada
objeto implicado en la transacción
• En la lista se incluye el estado anterior y posterior del objeto
x=0;
y=0; Bitácora Bitácora Bitácora
BEGIN_TRANSACTION x=0/1 x=0/1
x=0/1
x=x+1;
y=y+2; y=0/2 y=0/2
x=y*y;
END_TRANSACTION x=1/4
• Podemos hacer los cambios en los objetos reales, pues con la bitácora
tenemos información para deshacer: partimos del final hacia atrás
• La bitácora se almacenaría en almacenamiento estable
• Protocolo de compromiso de dos fases:

• Uno de los procesos actúa como coordinador
• El coordinador envia un mensaje de preparado a los demás
procesos
• Y recibe mensajes de los otros procesos indicando si están
dispuestos a comprometerse
• Cuando el coordinador ha recibido todas las respuestas decide si se
lleva a cabo la transacción o no
• Si uno o más procesos no se comprometen (o no responden) la
transaccion se aborta
• Si el coordinador decide que se lleva a cabo la transacción, envía un
mensaje notificándolo a los demás procesos
Control de concurrencia
• Un algoritmo para control de concurrencia en SS.DD se

basa en el uso de la cerradura
• P.ej. al acceder a un archivo, se activa una cerradura de
acceso
• La cerradura puede ser de lectura/escritura
• La cerradura puede ser a todo el fichero o a ciertos
registros (granularidad de la cerradura)
• La cerradura más usada es la de dos fases: primero se
va intentando adquirir todas las cerraduras necesarias, y
solo entonces se accede
• Si no se pudiera acceder a una de las cerraduras, se
liberan las ya obtenidas
• Otra opción es el control optimista de la

concurrencia
• La idea es no hacer nada
• Se supone que van a producirse pocos
conflictos, en la práctica los conflictos son raros,
por lo que suele funcionar bien
• Pero hay que detectar los conflictos. Si se
producen hay que deshacer lo hecho
• Otro método se basa en las marcas de tiempo

• Se asocia a cada inicio de transacción
(BEGIN_TRANSACTION) una marca de tiempo
• Cuando las transacciones son breves y espaciadas en el
tiempo entonces no habrá problema
• A veces el orden es incorrecto (se detecta que una
transición iniciada posteriormente a la transacción activa
ha intentado entrar en el archivo, tenido acceso a éste y
ha realizado un compromiso)
• En ese caso la transición activa se aborta
Bloqueos en SS.DD
• Los bloqueos en los ss.dd. son similares a los que

ocurren en un sistema uniprocesador
• Pero son más difíciles de detectar y corregir
• Aproximaciones posibles:
 El algoritmo del avestruz (ignorar el problema)
 Detección (permitir que ocurran bloqueos, detectarlos e intentar
recuperarse)
 Prevención (imponer restricciones para que podamos asegurar
que no se van a dar bloqueos)
 Evitarlos (que los procesos hagan una cuidadosa asignación de
recursos para que no se den bloqueos)
• Estudiaremos a continuación solo la detección y la
prevención
Bloqueos en SS.DD
• detección centralizada de bloqueos:

• cada máquina mantiene su gráfica de recursos y
procesos
• Un coordinador recibe (mediante mensajes) esa
información. Con la visión global, toma las
decisiones
• Cuando el coordinado detecta un ciclo, elimina
los procesos para romper el bloqueo
Bloqueos en SS.DD
• detección distribuida de bloqueos (algoritmo de Chandy-

Misra-Haas):
• Cuando un proceso debe esperar por un recurso, construye un
mensaje especial de exploración, que envía al proceso o procesos
que retienen el recurso
• El mensaje consta de tres números: el proceso que espera, el
proceso que envía el mensaje y el proceso al cual se envía
• Al llegar el mensaje, el receptor comprueba si él también espera a
algunos procesos. En ese caso el mensaje se actualiza, conservando
el primer campo pero pero reemplazando el segundo por su propio
número de proceso y el tercero por el nº del proceso al cual espera
• El mensaje se reenvía entonces al proceso por el cual espera
• Si un mensaje regresa al emisor original (el proceso enumerado en
el primer campo) es que hay un ciclo y el sistema está bloqueado
Bloqueos en SS.DD
• Ejemplo:
(0,8,0)
(0,4,6)
(0,2,3) 1 1 0
0 1 2 0 (0,5,7)
2 2
Máquina 0 Máquina 1 Máquina 2
Bloqueos en SS.DD
• Prevención distribuida de bloqueos:

• Suponemos que existe un s.d. con tiempo global y
transacciones atómicas
• Asociamos a cada transacción una marca de tiempo
global al momento de su inicio
• Cuando un proceso está a punto de bloquearse en
espera de un recurso que está usando otro proceso, se
comprueba cuál de ellos tiene la marca de tiempo mayor
• Si el proceso que tiene el quiere el recurso es más joven
podemos entonces optar por hacerlo esperar
Tolerancia a fallos
Tolerancia a fallos
• Un sistema falla cuando no cumple su

especificación
• Los fallos de un sistema pueden estar en un
fallo en algún componente. Los fallos de
componentes pueden ser:
 fallos transitorios: una erupción solar que inutiliza un
momento un satélite??
 fallos intermitentes: mal contacto en un cable,...
 fallos permanentes: circuito quemado, error
software,...
Tolerancia a fallos
• Los fallos del sistema pueden ser:

 fallos silenciosos: el sistema deja de funcionar o se puede
detectar que el sistema ha dejado de funcionar correctamente
 fallos bizantinos: no se detecta, el sistema sigue funcionando
pero produce resultados incorrectos
• Desde el punto de vista de la t.a.f, los sistemas pueden
ser:
 síncronos: si se puede asegurar que el sistema responde a un
mensaje dentro de un tiempo finito conocido
 asíncronos: si no
• Los sistemas más problemáticos son pues los que tienen
fallos bizantinos y los que son asíncronos
Tolerancia a fallos
• El método más usado en tolerancia a fallos es el empleo

de redundancia
• La redundancia puede ser:
 de información: p.ej. añadiendo bits con código de Hamming
que permita recuperar errores
 de tiempo: se realiza una acción, y en caso necesario, se repite
en el tiempo. P.ej. la transacción atómica. La redundancia en el
tiempo es muy útil en fallos intermitentes y transitorios
 física: se agregan equipos o procesadores adicionales. Se puede
hacer de dos formas:
 réplica activa
 respaldo primario
Tolerancia a fallos
• Tolerancia a fallos mediante réplica activa: todos los

procesadores se usan todo el tiempo como servidores,
funcionando en paralelo, ocultando los fallos
• La réplica activa se utiliza en:
 biología: los mamíferos tenemos dos ojos, oídos, etc.
 aviación: los 747 tienen 4 motores pero pueden volar con 3
 deporte: varios árbitros
• Se dice que un sistema es tolerante a k fallos si puede
superar fallos en k componentes y seguir cumpliendo
sus especificaciones
Tolerancia a fallos
• Si los componentes fallan de manera silenciosa,

bastan k+1 de ellos para proporcionar la
tolerancia a k fallos
• Si los componentes tienen fallos bizantinos,
continuan su ejecución al fallar y dan respuestas
aleatorias o erróneas, por lo que se necesitan al
menos 2k+1 componentes para lograr la
tolerancia a k fallos
Tolerancia a fallos
• Tolerancia a fallos mediante respaldo primario: en todo instante es

un servidor primario el que realiza todo el trabajo. Si el primario
falla, el de respaldo comienza a funcionar, todo ello de forma
transparente a los programas de aplicación
• De este esquema también hay numerosos ejemplos en la vida real:
 gobierno: ej. vicepresidente
 aviación: ej. copilotos
 generadores diesel en los hospitales
• Ventaja con respecto a la réplica activa: la operación normal es más
sencilla, funciona solo un servidor en vez de varios en paralelo
• Desventaja: trabaja mal en presencia de fallos bizantinos, en los
que el primario afirma erróneamente que funciona de manera
perfecta
Tolerancia a fallos
• Acuerdos en sistemas defectuosos: en

ss.dd. es muy importante lograr acuerdos sobre
algo (elección de coordinador, si completar una
transacción o no). ¿cómo llegar a acuerdos
cuando hay fallos?
• Supongamos que tenemos procesadores
perfectos pero una línea de comunicación que
puede fallar
• Ese caso podemos estudiarlo teóricamente con
el problema de los dos ejércitos
Tolerancia a fallos
• Problema de los dos ejércitos:

• El ejército rojo tiene 5000 soldados, acampados en un valle
• Dos ejércitos azules, cada uno con 3000 efectivos, acampan en las
colinas circundantes al valle
• Si los dos ejércitos azules logran llegar a un acuerdo de ataque
simultáneo, derrotarán al ejército rojo
• Si solo lo intenta uno de los ejércitos azules, saldrá derrotado
• Supongamos que el comandante del ejército 1 envía un mensaje al
comandante del ejército 2. El mensaje dice “Tengo un plan,
ataquemos mañana al amanecer”
• El mensajero logra pasar, y el comandante del ejército 2 le devuelve
una nota que dice “Espléndido, ataquemos pues mañana al
amanecer”
• El mensajero regresa a salvo y el comandante 1 prepara entonces a
sus tropas
Tolerancia a fallos
• Pero más tarde el comandante 1 se pone a pensar y se

da cuenta de que el comandante 2 no sabe si el
mensajeró regresó a salvo, y al dudar podría no
atreverse a atacar
• Así que el comandante 1 vuelve a enviar un mensaje
• Ocurre lo mismo
• No importa el nº de reconocimientos enviados, el
comandante 1 y el comandante 2 nunca llegarán a un
acuerdo
• => Incluso si los procesadores no fallan (comandantes),
el acuerdo entre dos procesos no es posible si existe
una comunicación no confiable
Tolerancia a fallos
• Supongamos ahora que la comunicación es perfecta pero los

procesadores no lo son
• Ese caso podemos estudiarlo teóricamente con el problema de los
generales bizantinos
• El ejército rojo sigue acampando en el valle, pero n generales
azules comandan ejércitos en las colinas cercanas
• La comunicación es perfecta (p.ej línea telefónica), pero m de los n
generales son traidores (fallan). Dan información incorrecta o
contradictoria
• Ahora supongamos que cada general conoce el nº de soldados de
que dispone. Definiremos el acuerdo como sigue: los generales
intercambian la información del nº de soldados que tienen. Al final
del algoritmo cada general debe tener un vector de longitud n. Si el
general i es leal, entonces el elemento i es su cantidad de efectivos;
en caso contrario está indefinido
Tolerancia a fallos
• Lamport y colaboradores diseñaron un algoritmo recursivo que

resuelve este problema bajo ciertas condiciones
• Veamos cómo funciona para n=4 y m=1 (tres generales leales y
uno traidor). Con estos parámetros el algoritmo opera en 4 pasos
• En el paso uno, cada general envía un mensaje a los demás con la
información de sus tropas
• Los generales leales dicen la verdad, mientras que el traidor puede
decir a cada uno de los demás una mentira diferente. Sea el
general 3 el traidor. Informan así:
 general 1: 1 Ksoldados
 general 3: x,y,z Ksoldados
Tolerancia a fallos
• En el paso 2, los resultados recibidos de los otros se reunen en forma de

vectores:
1. (1,2,x,4)
2. (1,2,y,4)
3. (1,2,3,4)
4. (1,2,z,4)
• En el paso 3, cada general pasa su vector a los demás
• En este paso el general 3 vuelve a mentir, ideando 12 nuevos valores a-l:
gral.1 gral.2 gral.4

(1,2,y,4) (1,2,x,4) (1,2,x,4)
(a,b,c,d) (e,f,g,h) (1,2,y,4)
(1,2,z,4) (1,2,z,4) (i,j,k,l)
Tolerancia a fallos
• Por último, en el paso 4 cada general examina su i-

ésimo elemento de cada uno de los vectores que ha
recibido
• Si cualquier valor tiene una mayoría, este valor se coloca
en el vector resultado. Si ningún valor tiene mayoría, el
elemento correspondiente del vector resultado se marca
como INCOGNITA
• Vemos que en este caso obtenemos como vector
resultado:
(1,2,INCOGNITA,4)
• => El general 3 es un traidor!
Tolerancia a fallos
• Lamport y colaboradores demostraron que en

un sistema con m procesadores que pueden
fallar, el acuerdo solo se logra si se dispone de
2m+1 procesadores que funcionen de manera
correcta
• Si por ejemplo hubiésemos tenido n=3 y m=1
(dos generales leales y un traidor) no
hubiésemos podido llegar a un acuerdo
Sistemas distribuidos de
archivos
Sistemas distribuidos de archivos
• Un servicio de archivos es una especificación de un

conjunto de servicios que el sistema de archivos ofrece
a sus clientes: primitivas disponibles, parámetros, etc.
• Un servidor de archivos es un proceso que se ejecuta en
alguna máquina y ayuda a implementar el servicio de
archivos
• Un sistema puede tener uno o varios servidores de
archivos, pero los clientes no deben conocer el nº de
servidores, su posición o función
• Los clientes solo tienen que llamar a los procedimientos
del servicio de archivos, el trabajo necesario se lleva a
cabo de alguna manera y se obtienen los resultados
pedidos
• Una forma de evitar los problemas de actualización de
copias del archivo y duplicación es la de imponer que los
archivos sean inmutables => solo se permiten las
operaciones CREATE y READ
• Los servicios de archivos se pueden dividir en:
 modelo de carga/descarga: solo se proporciona la lectura de un
archivo y la escritura del mismo. La lectura transfiere todo el
archivo de uno de los servidores de archivos al cliente. La
escritura transfieren el archivo completo en sentido contrario
 modelo de acceso remoto: el servicio de archivos proporciona
un gran nº de operaciones (abrir, cerrar, leer, escribir, moverse
por el archivo...)
• El modelo de carga/descarga es conceptualmente simple
pero muchas veces el traslado del archivo completo es
absurdo SistemasConcurrentes
• Las posibilidades de un sistema jerárquico de archivos

(ej. UNIX) son difíciles de implementar en un sistema
distribuido
• El montaje de un sistema de archivos remoto en un
sistema local hace que una misma ruta no signifique lo
mismo en ambas máquinas
• La transparencia respecto a la posición significa
que la ruta de acceso no sugiere la posición del archivo.
Una ruta servidor1/dir1/x indica que x está en el
servidor 1 pero no indica la posición del servidor, que
podría estar en cualquier máquina. El archivo puede
moverse en la red sin que la ruta tenga que cambiarse
• Un sistema donde los archivos se pueden

desplazar sin que cambien sus nombres tiene
independencia con respecto a la posición
• Un s.d. que incluya los nombres de la máquina
o el servidor en los nombres de las rutas de
acceso no es independiente con respecto a la
posición. Tampoco lo es uno que usa el montaje
remoto
• Lo ideal es tener un espacio de nombres que
tenga la misma apariencia en todas las
máquinas
• La mayoría de los s.d. de archivos usan nombres de

dos niveles: un nombre ASCII para el usuario y un
nombre interno en algún código más manejable por la
máquina
• Cuando se accede a un archivo se hace la traducción del
nombre ASCII al nombre interno
• Una posibilidad es que un nombre ASCII tenga
asociados varios nombres binarios. De esta forma se
puede intentar acceder primero al primer nombre
binario, si no se puede, al segundo, etc.; esto
proporciona cierto grado de tolerancia a fallos
• Con respecto a la compartición de archivos, la
semántica de archivos UNIX asegura que un READ
que se hace después de un WRITE obtiene el valor
escrito
• En un s.d la semántica UNIX es difícil de lograr. si hay
varios servidores lo normal es permitir a los clientes que
puedan mantener una copia local de los archivos
• Pero entonces un cliente puede modificar un archivo y
poco después otro cliente lee el archivo del servidor,
obtiendo una copia ya obsoleta
• Una forma de solucionar esto es imponer la semántica
de sesión: los cambios que hace un cliente sobre un
archivo solo serán visibles a todo el mundo en el
momento de cerrarlo
• Otra forma es emplear las transacciones atómicas para
acceder al archivo SistemasConcurrentes
• A la hora de implementar un sistema distribuido de

archivos es importante tener en cuenta ciertas
características del acceso a archivos en general:
 La mayoría de los archivos accedidos son pequeños (menos de
10K), por lo que podría añadirse al sistema la posibilidad la
transferencia de archivos completos en vez de bloques
 La mayoría de los archivos tienen tiempos de vida cortos (ej.
compilador que crea archivos temporales), por lo que podría ser
buena idea crear el archivo en el cliente y mantenerlo ahí hasta
su eliminación
 Es poco usual compartir archivos, lo que da una oportunidad de
emplear caché en los clientes
• Los servidores pueden ser con o sin estado

• Un servidor con estado mantiene información del estado
y los accesos de los clientes. Cuando un cliente abre un
archivo el servidor suele insertar una entrada en una
tabla donde asocia a cada cliente los descriptores de
archivos que tiene abiertos, punteros de acceso, etc.
• En un servidor sin estado, cuando un cliente envía una
solicitud a un servidor, éste la lleva a cabo, envía la
respuesta y elimina de sus tablas internas toda la
información relativa a los clientes. Cada solicitud debe
estar autocontenida, debe contener el nombre del
archivo y la posición dentro de éste.
• Ventajas de los servidores sin estado:

 Tolerancia a fallos (pensar en falla del servidor que pierde las
tablas)
 No se desperdicia espacio del servidor en tablas
 No existe límite para el nº de archivos abiertos (si se usan
tablas en el servidor, éstas podrían llenarse cuando el nº de
clientes con archivos abiertos es alto)
 No hay problemas en el servidor si un cliente falla
• Ventajas de los servidores con estado:
 Los mensajes de solicitud son más cortos
 En general, mayor eficiencia
• En un sistema cliente-servidor, cada uno con su

memoria principal y disco, hay cuatro lugares posibles
donde almacenar los archivos:
 Disco del servidor
 Memoria principal del servidor
 Disco del cliente
 Memoria principal del cliente
• El primer lugar a considerar para almacenar los archivos
es naturalmente el disco del servidor: hay mucho
espacio y los archivos serán accesibles a todos los
clientes
• Se puede lograr una mayor eficiencia si los archivos

usados más recientemente se almacenan también en la
memoria principal del servidor (caché)
• Esto elimina muchas transferencias entre el disco del
servidor y la memoria del servidor, aunque aún debe
hacer transferencias a través de la red entre el cliente y
el servidor
• La utilización de caché en el cliente eliminaría muchos
accesos de red
• En la práctica solo se usa caché en la memoria principal
de los clientes
• Al usar caché en la memoria principal del cliente hay

tres opciones:
 la caché esté dentro del propio proceso
 la caché sea mantenida por el núcleo
 la caché sea mantenida por un proceso de usuario encargado
específicamente de administrar caché
• El mantener la caché en el núcleo es interesante para
los casos de archivos intermedios que utilizan varios
procesos (p.ej. uno que termina produciendo un archivo
de salida que usa otro como entrada)
• En cualquier caso, el uso de caché en el cliente solo
tiene sentido si tenemos CPU rápidas y red lenta
• El uso de caché introduce problemas de

inconsistencia
• Una posible solución es la escritura a través
de caché: cuando se modifica una entrada de
la caché, el nuevo valor se envía también de
inmediato al servidor. Así, cuando otro proceso
lee el archivo obtiene el valor más reciente
• La escritura a través de caché funciona, pero no
reduce el tráfico de escritura (para el caso de la
escritura es como si no tuviéramos caché)
• Otra posibilidad es usar escritura retrasada: mandar las

modificaciones en la caché al servidor solo cada cierto tiempo, p.ej.
cada 30 segundos
• La escritura retrasada aumenta la eficiencia, pero sigue
manteniendo problemas de inconsistencias temporales
• La escritura al cierre corresponde a la semántica de sesión vista
anteriormente
• El control centralizado se refiere a que el servidor de archivo
recibe todas las solicitudes de clientes y decide si otorgarlas o no,
según los accesos que ya se estén llevando sobre los archivos
• En resumen, la caché en el servidor no afecta a la consistencia del
sistema de archivos, desde el punto de vista de los clientes. El
caché en el cliente puede ofrecer mejor rendimiento pero a costa
de mayor complejidad para evitar inconsistencias
• Algunos s.d proporcionan la réplica de archivos como

servicio: Se dispone de varias copias de algunos
archivos, donde cada copia está en un servidor de
archivos independiente
• Ventajas de la réplica de archivos:
 Aumentar la confiabilidad al disponer de copias adicionales de
los archivos. Si un servidor falla totalmente no se pierden los
datos
 Permitir el acceso al archivo aunque falle un servidor de
archivos. El lema es: el espectáculo debe continuar
 Repartir la carga de trabajo entre los servidores
• En la réplica explícita es el programador el que tiene

que hacer las réplicas de los archivos. P.ej usando el
comando cp
• En la réplica retrasada el servidor crea réplicas de sus
archivos en otros servidores, de forma automática y
transparente al programador
• En la réplica mediante grupo se hace uso de la
comunicación en grupo. Todas las llamadas WRITE al
sistema se transmiten de forma inmediata a todos los
servidores a la vez
• En cuanto a la actualización de las réplicas, el

protocolo de réplica de la copia primaria se
basa en usar un servidor primario, todos los
demás son secundarios. Si hay que actualizar un
archivo duplicado, el cambio se envía al servidor
primario, que realiza los cambios en forma local
y después envía comandos a los secundarios
para ordenarles la misma modificación
• El problema de la réplica de la copia primaria es
que puede fallar el servidor primario
• El método de voto de Gifford es más robusto que la

réplica de la copia primaria
• La idea fundamental es exigir a los clientes que soliciten
y adquieran el permiso de varios servidores antes de
leer o escribir un archivo replicado
• Para leer un archivo del que existen N réplicas, un
cliente necesita conformar un quórum de lectura (una
colección arbitraria de Nr servidores o más)
• Para modificar un archivo, un cliente necesita un
quórum de escritura de al menos Nw servidores
• Los valores Nr y Nw deben cumplir la restricción
Nr+Nw>N
• El nº de versión se utiliza para identificar la versión del
archivo
• Si p.ej tenemos 12 servidores y Nr=3 y Nw=10.

El más reciente quórum de escritura tenía 10
servidores. Esos 10 servidores tienen pues la
nueva versión del archivo. Cualquier quórum de
lectura posterior con tres servidores debe
contener al menos un miembro de este conjunto
(se cumple Nr+Nw>N)
• Cuando el cliente analiza los números de versión
de los archivos, sabrá cuál es el más reciente de
ellos y lo tomará
• Como ejemplo de s.d de archivos veremos el sistema de

archivo de red de Sun Microsystems, conocido como
NFS
• NFS permite que sistemas UNIX (y MS_DOS) accedan a
un sistema de archivos común
• En la mayoría de los casos, los clientes y servidores
están en la misma LAN, pero esto no es necesario.
Puede usarse redes de área amplia
• Cada servidor NFS exporta uno o más de sus directorios
para que puedan ser accedidos por clientes remotos
• Los clientes pueden acceder a directorios remotos

exportados mediante el montaje
• Cuando un cliente monta un directorio (y sus
subdirectorios) remoto, el directorio se vuelve parte de
su jerarquía de directorios local
• Si dos o más clientes montan el mismo directorio al
mismo tiempo pueden comunicarse compartiendo
archivos en sus directorios comunes
• NFS implementa sus servicios definiendo un protocolo
común: una especificación de un conjunto de servicios,
parámetros, etc., que entienden los servidores y deben
usar los clientes
• NFS tiene un servicio de montaje. Un cliente puede

envíar una ruta de acceso a un servidor y solicitar que
se monte ese directorio en alguna parte de su jerarquía
de directorios
• Si la ruta es válida y el directorio es exportado por el
servidor, éste envía un handle al cliente
• El handle contiene campos que identifican de manera
única al tipo de sistema de archivo, el disco, el nodo-i
del directorio e información de seguridad
• Las llamadas posteriores para la lectura y escritura de
archivos en el directorio montado utilizan el handle
• NFS también proporciona servicios para el acceso a

directorios y archivos. La mayor parte de las llamadas al
sistema UNIX para este fin son soportadas por NFS,
excepto OPEN y CLOSE
• OPEN y CLOSE no se implementan porque no es
necesario abrir un archivo antes de leerlo, ni cerrarlo al
terminar
• En vez de esto, para leer un archivo, un cliente envía al
servidor un mensaje solicitud con el nombre completo
de archivo, y el servidor regresa un handle, que es una
estructura que lo identifica unívocamente
• Una posterior llamada READ usará el handle devuelto
• Por tanto, en NFS, los servidores son sin estado
• Puede extraerse unos principios generales que

deberían seguir los diseñadores de sistemas de
distribuidos de archivos
• En primer lugar, deberían usarse los clientes
siempre que fuera posible, en vez de los
servidores
• Se debería usar caché lo más posible
• Se debería explotar las propiedades de uso de
ciertos archivos. P.ej. los temporales, que
suponene hasta un tercio de todas las
referencias a archivos

Scon 9 SSDD

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Scon 9 SSDD

Transféré par

Droits d'auteur :

Formats disponibles

Sistemas Distribuidos

I.T. Informática de Sistemas

• Sistemas Operativos Distribuidos

• El concepto de sistema distribuido se opone al

• Definición para empezar:

“Un sistema distribuido es una colección de

• Prestaciones relativas: Resulta más rentable

• Aplicaciones distribuidas: Muchas

• Compartición de recursos (discos, CPUs,

• Fallos independientes pueden afectar a otras

• Actualmente no hay software para gestionar

• Podemos dividir las computadoras paralelas y

• El hardware es importante, pero en los sistemas

• Sistemas software débilmente acoplados en hardware

• Sistemas software fuertemente acoplados en hardware

• Middleware: se aplica al software que provee una

• Flexibilidad: en ss.dd. interesa la máxima

• Confiabilidad: si alguna máquina falla, alguna otra máquina se

• Disponibilidad: la fracción de tiempo en que se puede utilizar el

• Eficiencia: además de transparente, flexible y

• Escalabilidad: hay que evitar:

• La diferencia más importante entre un s.d y un sistema

• Debido a la ausencia de memoria compartida, la

• Cada capa utiliza servicios (funciones) de la capa inferior

capa i control datos

capa i-1 control datos

• Capas OSI que nos interesan:

 Capa física: se encarga de la transmisión de bits por un canal

 circuito virtual u orientado a conexión: al conectar se

• El modelo OSI fue bosquejado en los 70. Las redes de modo de

• Existen procesos servidores, que proporcionan

• Direccionamiento: ¿cuál es la dirección del

• Las primitivas de envío y recepción podrán ser:

• Una primitiva típica es receive(addr,&m)

• Si las primitivas son fiables no hay ningún problema,

• El modelo cliente-servidor asigna dos primitivas, send y

• Dificultades para implementar RPC:

count=read(fd, buf, nbytes);

• La llamada read ejecuta una rutina especial de biblioteca

• La transferencia de parámetros se realiza

• ¿cómo especifica el cliente la dirección del servidor?

specification of file_server, version 3.1:

• La especificación es usada por los stubs cliente y servidor. Cuando

• El servidor envía un mensaje a un programa llamado

• Fallos que se pueden dar:

• La comunicación es entre un grupo de procesos

• Los grupos pueden ser:

• ¿cómo asegurar la atomicidad?

• Otra propiedad deseable es la del ordenamiento de

• ¿cómo reciben los mensajes los miembros 1 y 3?

• Aunque se cumpla el ordenamiento de mensajes hay

• En un sistema con un procesador, la sincronización entre

• En un sistema centralizado, el tiempo no tiene

• Pensemos en el programa make en un entorno

máquina que 2144 2145 2146 2147 tiempo del

2142 2143 2144 2145

• La sincronización de relojes es muy importante!

• ¿se pueden sincronizar los relojes en un sistema

• Lamport definió la relación “ocurre antes de”

• ¿de qué forma podemos sincronizar relojes

• Un caso de tres procesos, cada uno con su propio reloj

• Solución propuesta por Lamport: puesto que C sale en

• En ciertas situaciones existe un requisito