Sistemas Distribuidos

1
Sistemas Distribuidos

• I.T. Informática de Sistemas
• Curso 2002-2003

2
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

3
Sistemas Distribuidos

• El concepto de sistema distribuido se opone al
  desistema centralizado ? el basado en una sola
  CPUmemoriadisco, con uno o varios puestos de
  trabajo.
• Varias CPUs desacopladas (unidas por una red)

4
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

5
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.

6
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.

7
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

8
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

9
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

10
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

11
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

12
Software

• Sistemas software débilmente acoplados en
  hardware débilmente acoplado gt 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

13
Software

• Sistemas software fuertemente acoplados en
  hardware débilmente acoplado gt 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

14
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

15
Aspectos de diseño

• Transparencia

Transparencia de localización Los recursos tienen nombres que no denotan la máquina en la que están
Transparencia de migración Los recursos deben poder moverse de una posición a otra sin tener que cambiar sus nombres
Transparencia de réplica Se debe poder mantener copias de los recursos sin que lo noten los usuarios
Transparencia de concurrencia Varios usarios deben poder compartir recursos sin problemas
Transparencia de paralelismo Los programas deberían aprovechar el paralelismo sin intervención de los usuarios
16
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

17
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?

18
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

19
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

20

• Comunicación en los ss.dd.

21
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

22
Comunicación en los ss.dd.

• 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

23
Comunicación en los ss.dd.

• 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 controldatos de una capa viaja en
  los datos de la capa superior

capa i
capa i-1
24
Comunicación en los ss.dd.

• 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

25
Comunicación en los ss.dd.

• 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

26
Comunicación en los ss.dd.

• 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

27
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

28
El modelo cliente-servidor

• 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

29
El modelo cliente-servidor

• 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

30
El modelo cliente-servidor

• 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

31
El modelo cliente-servidor

• 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
servidor
cliente
servidor
2 (respuesta)
3
3
4
kernel
kernel
kernel
kernel
2
32
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

33
Llamada a procedimiento remoto (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

34
Llamada a procedimiento remoto (RPC)

• countread(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

35
Llamada a procedimiento remoto (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

36
Llamada a procedimiento remoto (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 nameMAX_PATH, out char
  bufBUF_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

37
Llamada a procedimiento remoto (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

38
Llamada a procedimiento remoto (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

39
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

40
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

41
Comunicación en grupo

• 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)

42
Comunicación en grupo

• 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
2
4
5
43
Comunicación en grupo

• 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

44
Comunicación en grupo

• 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

B
0
1
A
D
C
3
2
45

• Sincronización en los ss.dd.

46
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

47
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?

48
Sincronización de relojes

• Pensemos en el programa make en un entorno
  distribuido de dos máquinas
• La sincronización de relojes es muy importante!

2144
2145
2146
2147
tiempo del reloj local
máquina que ejecuta el compilador
output.o creado
2142
2143
2144
2145
máquina que ejecuta el editor
tiempo del reloj local
output.c creado
49
Sincronización de relojes

• 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

50
Sincronización de relojes

• 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

51
Sincronización de relojes lógicos

• Lamport definió la relación ocurre antes de
• La expresión a-gtb 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-gtb 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-gtb es
  verdadero

52
Sincronización de relojes lógicos

• 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-gtb entonces C(a)ltC(b)
• El tiempo de reloj C siempre debe ir hacia
  delante, nunca puede ser decreciente

53
Sincronización de relojes lógicos

• Un caso de tres procesos, cada uno con su propio
  reloj
• Con los mensajes C y D no se cumplen
  las reglas anteriores!

0
6
12
18
24
30
36
42
48
54
60
0
8
16
24
32
40
48
56
64
72
80
0
10
20
30
40
50
60
70
80
90
100
A
B
C
D
54
Sincronización de relojes lógicos

• Solución propuesta por Lamport puesto que C sale
  en 60 debe llegar en 61 o posterior, ...

0
6
12
18
24
30
36
42
48
70
76
0
8
16
24
32
40
48
61
69
77
85
0
10
20
30
40
50
60
70
80
90
100
A
B
C
D
55
Sincronización de relojes lógicos

• 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

56
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
solicitud
I, tiempo de procesamiento de la petición
tiempo
T1
57
Sincronización de relojes físicos

• 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

58
Sincronización de relojes físicos

• 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

59
Sincronización de relojes físicos

• 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 T0iR y termina
  en T0(i1)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

60
Sincronización de relojes físicos

• 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?

61
Sincronización de relojes físicos

• 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
• GTiempoActual-TiempoMáximodeVidadeMensaje

62
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

63
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

64
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

65
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

66
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
OK
OK
12
OK
8
8
1
2
1
2
1
2
OK
12
(Entra en R.C)
67
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

68
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 k1 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

69
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)

70
Exclusión mutua

• Comparación de los tres algoritmos
• M Mensajes necesarios para q un proceso entre y
  salga de una R.C

Algoritmo M Retraso antes de entrar en RC Problema
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
71
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

72
Elección de coordinador

• 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

73
Elección de 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)

74
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

75
Transacciones atómicas

• 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

76
Transacciones atómicas

• 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

77
Transacciones atómicas

• 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

78
Transacciones atómicas

• 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

79
Transacciones atómicas

• 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
• x0
• y0
• BEGIN_TRANSACTION
• xx1
• yy2
• xyy
• END_TRANSACTION
• 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

80
Transacciones atómicas

• 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

81
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

82
Control de concurrencia

• 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

83
Control de concurrencia

• 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

84
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

85
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

86
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

87
Bloqueos en SS.DD

• Ejemplo

(0,8,0)
(0,4,6)
0
1
1
(0,2,3)
0
1
0
2
(0,5,7)
2
2
Máquina 0
Máquina 2
Máquina 1
88
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

89

• Tolerancia a fallos

90
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,...

91
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

92
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

93
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

94
Tolerancia a fallos

• Si los componentes fallan de manera silenciosa,
  bastan k1 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 2k1 componentes para lograr la tolerancia
  a k fallos

95
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

96
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

97
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

98
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
• gt Incluso si los procesadores no fallan
  (comandantes), el acuerdo entre dos procesos no
  es posible si existe una comunicación no confiable

99
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

100
Tolerancia a fallos

• Lamport y colaboradores diseñaron un algoritmo
  recursivo que resuelve este problema bajo ciertas
  condiciones
• Veamos cómo funciona para n4 y m1 (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 2 2 Ksoldados
• general 3 x,y,z Ksoldados
• general 4 4 Ksoldados

101
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)

102
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)
• gt El general 3 es un traidor!

103
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 2m1
  procesadores que funcionen de manera correcta
• Si por ejemplo hubiésemos tenido n3 y m1 (dos
  generales leales y un traidor) no hubiésemos
  podido llegar a un acuerdo

104

• Sistemas distribuidos de archivos

105
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

106
Sistemas distribuidos de archivos

• 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
  gt 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

107
Sistemas distribuidos de archivos

• 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

108
Sistemas distribuidos de archivos

• 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

109
Sistemas distribuidos de archivos

• 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

110
Sistemas distribuidos de archivos

• 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

111
Sistemas distribuidos de archivos

• 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

112
Sistemas distribuidos de archivos

• 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.

113
Sistemas distribuidos de archivos

• 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

114
Sistemas distribuidos de archivos

• 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

115
Sistemas distribuidos de archivos

• 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

116
Sistemas distribuidos de archivos

• 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