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

Sistemas DistribuidosSistemas Distribuidos

I.T. Informática de SistemasCurso 2002-2003

SistemasConcurrentes

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


Sistemas Distribuidos

• El concepto de sistema distribuido se opone al desistema 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 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


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

datoscontrol

datoscontrolcapa i

capa i-1



• 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 enviesend sin bloqueo, con copia del mensaje en buffer

internosend 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:

kernel

cliente servidor

kernel

1

2

3

4kernel

cliente servidor

kernel

1

2 (respuesta)

3


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



• 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



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



• 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



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



• 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



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

0 1 2 3 40

1

2

3

4

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:

A

B

C

D

0 1

23


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

• La sincronización de relojes es muy importante!

máquina queejecuta el compilador

máquina queejecuta el editor

tiempo delreloj local

tiempo delreloj local

2144 2145 2146 2147

2142 2143 2144 2145

output.o creado

output.c creado



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

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



• 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



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

T0

T1

máquina emisora servidor de tiempo

I, tiempo de procesamiento de la petición

tiemp

o

solicitud



• 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

0

1 2

8 812

12

0

1 2

OK

OK

OK

(Entra en R.C)

0

1 2

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:

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


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_TRANSACTIONEND_TRANSACTIONABORT_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;BEGIN_TRANSACTION

x=x+1;y=y+2;x=y*y;

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

x=0/1

Bitácora

x=0/1

Bitácora

y=0/2

x=0/1

Bitácora

y=0/2

x=1/4



• 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

0 1 2 01

2

1

2

0(0,2,3)(0,4,6)

(0,5,7)

(0,8,0)

Máquina 0 Máquina 1 Máquina 2

• Ejemplo:


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 2: 2 Ksoldados general 3: x,y,z Ksoldados general 4: 4 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



• 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



• 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


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



• 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

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

Documents

Transcript of Sistemas Distribuidos I.T. Informática de Sistemas Curso 2002-2003.