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

Presentación del tema: "Sistemas Distribuidos I.T. Informática de Sistemas Curso 2002-2003."— Transcripción de la presentación:

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

2 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

3 SistemasConcurrentes Sistemas Distribuidos El concepto de sistema distribuido se opone al de sistema centralizado  el basado en una sola CPU+memoria+disco, con uno o varios puestos de trabajo. Varias CPUs desacopladas (unidas por una red)

4 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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

13 SistemasConcurrentes 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

14 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes Comunicación en los ss.dd.

21 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 control+datos de una capa viaja en los datos de la capa superior datoscontroldatoscontrol capa i capa i-1

24 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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: kernel clienteservidor kernel 1 2 3 4 clienteservidor kernel 1 2 (respuesta) 3

32 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes Llamada a procedimiento remoto (RPC) count=read(fd, buf, nbytes); La llamada read ejecuta una rutina especial de biblioteca (stub) que bloquea al cliente y mete los parámetros en mensajes que envia a la máquina remota El stub de la máquina remota desempaqueta el mensaje y ejecuta una llamada read local La respuesta es devuelta en mensajes que desempaqueta el stub emisor y devuelve al que hizo la llamada, desbloqueándolo

35 SistemasConcurrentes 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 SistemasConcurrentes 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 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

37 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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: 01234 0 1 2 3 4 5

43 SistemasConcurrentes 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 SistemasConcurrentes 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: A B C D 0 1 2 3

45 SistemasConcurrentes Sincronización en los ss.dd.

46 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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! máquina que ejecuta el compilador máquina que ejecuta el editor tiempo del reloj local tiempo del reloj local 2144 2145 2146 2147 2142 2143 2144 2145 output.o creado output.c creado

49 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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

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

53 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 tiempo solicitud

57 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 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

60 SistemasConcurrentes 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 SistemasConcurrentes 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: G=TiempoActual-TiempoMáximodeVidadeMensaje

62 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes Exclusión mutua Ejemplo: dos procesos, 0 y 2, quieren entrar en la región crítica a la vez 0 1 2 8 8 12 0 1 2 OK (Entra en R.C) 0 1 2 OK (Entra en R.C)

67 SistemasConcurrentes 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 SistemasConcurrentes 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

69 SistemasConcurrentes 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 SistemasConcurrentes Exclusión mutua Comparación de los tres algoritmos: M= Mensajes necesarios para q un proceso entre y salga de una R.C AlgoritmoMRetraso antes de entrar en RC Problema Centralizado33Fallo del coordinador Distribuido2(n-1) Fallo de cualq. proceso Paso de fichas0 a n-1 Ficha perdida

71 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 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

80 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes Bloqueos en SS.DD 0 1 2 0 1 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:

88 SistemasConcurrentes 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 SistemasConcurrentes Tolerancia a fallos

90 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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

95 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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

99 SistemasConcurrentes 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 SistemasConcurrentes 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

101 SistemasConcurrentes 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 SistemasConcurrentes 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!

103 SistemasConcurrentes 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

104 SistemasConcurrentes Sistemas distribuidos de archivos

105 SistemasConcurrentes 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 SistemasConcurrentes 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 => 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 SistemasConcurrentes 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 solo tiene sentido si tenemos CPU rápidas y red lenta

117 SistemasConcurrentes Sistemas distribuidos de archivos 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é)

118 SistemasConcurrentes Sistemas distribuidos de archivos 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

119 SistemasConcurrentes Sistemas distribuidos de archivos 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

120 SistemasConcurrentes Sistemas distribuidos de archivos 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

121 SistemasConcurrentes Sistemas distribuidos de archivos 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

122 SistemasConcurrentes Sistemas distribuidos de archivos 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

123 SistemasConcurrentes Sistemas distribuidos de archivos 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á

124 SistemasConcurrentes Sistemas distribuidos de archivos 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

125 SistemasConcurrentes Sistemas distribuidos de archivos 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

126 SistemasConcurrentes Sistemas distribuidos de archivos 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

127 SistemasConcurrentes Sistemas distribuidos de archivos 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

128 SistemasConcurrentes Sistemas distribuidos de archivos

129 SistemasConcurrentes Sistemas distribuidos de archivos 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

130 SistemasConcurrentes Sistemas distribuidos de archivos