Capítulo 15, 16, 17, 18

Captulo II: Sistemas Distribuidos
Estructura Estructura Sistemas
de redes de sistemas distribuidos
de archivos distribuidos distribuida
Coordinacin
Captulo II: Sistemas distribuidos

Estructura de redes
Captulo II: Estructura de redes
Antecedentes
Una tendencia reciente en los sistemas de computador es distribuir los clculos entre varios procesadores fsicos: multiprocesador y distribuido Un sistema distribuido es una coleccin de procesadores dbilmente acoplados que se conectan entre s por medio de una red de comunicaciones. Para un procesador sus propios recursos son locales, el resto de procesadores y recursos son remotos. Los procesadores y recursos de un sistema distribuido pueden variar en cuanto a su tamao, funcin. Reciben varios nombres distintos sitios, Servidor es un anfitrin que tiene un recurso que otro anfitrin (cliente) quiere usar Un sistema operativo distribuido proporciona a los usuarios acceso a los distintos recursos (hardware y software) que el sistema ofrece. Existen dos esquemas para proporcionar este servicio:
nodos, anfitriones, etc
Sistemas operativos de red los usuarios saben que hay varias mquinas y necesitan acceder a los recursos iniciando una sesin Sistemas operativos distribuidos los usuarios no saben que hay varias mquinas, acceden a los recursos remotos de la misma manera que a los locales
Captulo II: Estructura de redes
Motivacin
Un
Hay cuatro razones para construir sistemas distribuidos: Compartimiento de recursos Agilizacin de los clculos
Carga
usuario de un sitio podra usar los recursos con que otro sitio cuenta
Confiabilidad
Si
compartida un clculo se puede dividir en varios subclculos que se pueden ejecutar de forma concurrente en diferentes sitios un sitio de un sistema distribuido falla, es posible que los dems sitios puedan seguir funcionando. El fallo de uno de ellos no deber afectar a los dems
Comunicacin
Si
varios sitios estn conectados entre si a travs de una red de comunicaciones los usuarios de diferentes sitios tienen oportunidad de intercambiar informacin. Se transfieren mensajes en bajo nivel. La ventaja es que las funciones se pueden llevar a cabo a grandes distancias

Estructura de sistemas distribuidos
Captulo II: Estruct. Sist. Distrib.

Sistemas
Proporciona un entorno en el que los usuarios pueden acceder a los recursos remotos ya sea iniciando una sesin o transfiriendo datos desde la mquina remota. Inicio de sesin remoto
Los
operativos de red
Transferencia remota de archivos

Otro
usuarios inician una sesin en un computador remoto Internet ofrece recurso telnet Debe existir una cuenta vlida en la mquina
otra Internet ofrece FTP (File Transfer Protocol) Debe existir una cuenta, tambin los comandos get, put,
mecanismo es la de transferir archivos de una mquina a
Sistemas operativos distribuidos
Los usuarios acceden a recursos remotos del mismo modo como lo hacen a los locales Migracin de datos
Migracin de cmputos

Dos estrategias: a) transferir todo el archivo; y b) transferir aquellas porciones del archivo necesarias No solo hay que transferir, es necesario a veces efectuar diversas traducciones si no son compatibles Podra ser ms eficiente transferir el cmputo en lugar de traer los datos RPC llamada a procedimiento remoto
Migracin de procesos
Extensin lgica de la migracin de cmputos, un proceso no siempre se ejecuta donde se inici Se puede ejecutar en varios sitios por las siguientes razones:
Balanceo de carga Agilizacin del cmputo Preferencias de hardware Preferencias de software Acceso a datos

Servicios
remotos
Un usuario necesita acceder a datos en algn otro sitio Un servidor remoto atiende la solicitud y finalmente transfiere los datos de vuelta al usuario Servicio remoto
Las
solicitudes se traducen en mensajes para los servidores y las respuestas del servidor se empacan como mensajes y se envan de vuelta a los usuarios
Servicios remotos
RPC
Llamadas a procedimiento remoto
Llamada a procedimientos remotos Se utiliza un esquema de comunicacin basado en mensajes para proporcionar un servicio remoto La comunicacin remota se la logra a travs de un puerto, que no es mas que un nmero que se incluye al principio de un paquete de mensaje Llamadas a procedimientos locales fallan en circunstancias extremas, las RPC pueden fallar, duplicarse, ejecutarse ms de una vez. Para ello los sistemas anexan a cada mensaje una marca de tiempo Otro aspecto importante es la comunicacin entre el servidor y el cliente
Cmo averigua un cliente los nmeros de puerto del servidor? La vinculacin se decide con antelacin: direcciones de puerto fijas La vinculacin es dinmica mediante un mecanismo de encuentro (demonio de encuentros), gasto extra pero es ms flexible
El
esquema de llamadas a procedimientos remotos es til para implementar un sistema de archivos distribuido
Servicios remotos
Hilos

Los sistemas distribuidos a menudo utilizan tanto hilos como llamadas a procedimientos remotos Los hilos pueden servir para enviar y recibir mensajes mientras otras operaciones dentro de la tarea continan asincrnicamente Recepcin implcita: un hilo que ha llevado a cabo un trabajo desaparece, el ncleo crea un nuevo hilo para atender las solicitudes entrantes Hilos desplegables: hilos que se crean cuando se necesita responder a una nueva RPC, mas eficiente cuesta menos iniciar un nuevo que restaurar uno ya existente Los hilos no se bloquean por lo que no hay que guardar ni restaurar su contexto Existen hilos en el servidor ST (Server Thread) y en el cliente CT (Client Thread). Un ST exporta su interfaz al ncleo, en la interfaz se definen procedimientos, parmetros, etc., un CT que importa recibir un identificador nico que usar despus para efectuar la llamada.
Robustez
Un sistema distribuido puede sufrir varios tipos de fallos de hardware: enlace, sitio, prdida de un mensaje. Para que el sistema sea robusto, debe ser capaz de detectar uno de estos fallos, reconfigurar de modo que se pueda continuar y recuperarse cuando un sitio o enlace se repare Deteccin de fallos

Para detectar se utiliza un procedimiento de saludo: estoy activo Existe un tiempo lmite para determinar si hubo un fallo o no Puede haber ocurrido una de estas situaciones:
El sitio est inactivo El camino alternativo fall El enlace directo fall El mensaje se perdi
Reconfiguracin

Recuperacin despus de un fallo

Ante la deteccin de una falla en un enlace o en un sitio, se debe notificar a todas las mquinas para que eviten enviar mensajes a dicha mquina o utilizar ese enlace Ante la presencia de un fallo, los sitios deben iniciar un procedimiento que permita al sistema reconfigurarse y continuar Cuando se repara el enlace o sitio que fall, es preciso integrarlo en el sistema sin interrupciones Se debe notificar de esto a todos los sitios participantes
Aspectos de diseo
Un reto que se ha enfrentado es hacer que la multiplicidad de procesadores y dispositivos de almacenamiento sea transparente para los usuarios. Los usuarios del sistema deben percibirlo como centralizado La interfaz con el usuario no debe distinguir entre recursos locales y remotos Otro aspecto es la movilidad de los usuarios, pueden ingresar en cualquier mquina y no obligarlos a usar una mquina especfica Tolerancia a fallos, un sistema deber seguir funcionando aunque en forma degradada pese a alguna descompostura de dispositivos Debe tener capacidad para adaptarse a un aumento en la carga de servicio, los recursos debern alcanzar un estado saturado en un tiempo ms largo escalabilidad La tolerancia a fallos y escalabilidad estn relacionadas entre s. Una ventaja de los sistemas distribuidos es su potencial para tolerar fallas y aumentar su escala, gracias a la multiplicidad de recursos.

Sistemas de archivos distribuidos
Captulo II: Sist. Arch. Distrib.
Antecedentes
El propsito de un DFS (Distributed File System) es apoyar el mismo tipo de compartimento cuando los archivos estn dispersos fsicamente entre los diversos sitios de un sistema distribuido Para entender un DFS es necesario definir
Servicio
Una interfaz de cliente para un servicio de archivos consta de un conjunto de operaciones primitivas como crear, eliminar, leer, escribir en un archivo Un DFS es un sistema de archivos cuyos clientes, servidores, dispositivos de almacenamiento estn dispersos entre las mquinas de un sistema distribuido
es una entidad de software que se ejecuta en una o ms mquinas y realiza una funcin a favor de clientes que no conoce Servidor es el software de servicio que se ejecuta en una sola mquina Cliente es un proceso que puede invocar un servicio empleando un conjunto de operaciones que constituyen su interfaz de cliente.
Antecedentes
Se puede implementar un DFS como parte de un sistema operativo distribuido o bien con una capa de software cuya tarea es gestionar la comunicacin entre sistemas operativos y sistemas de archivos convencionales La multiplicidad y dispersin de sus servidores y dispositivos de almacenamiento debe ser transparente, corresponde a un DFS localizar los archivos y encargarse del transporte de los datos El desempeo est en el tiempo que toma satisfacer diversas solicitudes de servicio. En un DFS un acceso remoto tiene el gasto adicional de una estructura distribuida, tiempo para presentar la solicitud a un servidor, tiempo para devolver la respuesta al cliente a travs de la red. Unidad componente es el conjunto de archivos mas pequeo que se puede almacenar en una sola mquina con independencia de las dems unidades. Todos los archivos que pertenecen a la misma unidad componente deben residir en el mismo lugar.

Nombres
Los nombres establecen una correspondencia entre objetos lgicos y fsicos En un DFS transparente se agrega una nueva dimensin a la abstraccin: la de ocultar en qu lugar de la red se encuentra el archivo. Estructuras de nombres
Transparencia
y transparencia
la posicin fsica de almacenamiento del archivo Independencia de ubicacin: no es necesario modificar el nombre de un archivo si la posicin fsica de almacenamiento del archivo cambia Las dos definiciones son relativas al nivel de nombres del que ya hablamos, puesto que los archivos tienen diferentes nombres en los diferentes niveles (nombres textuales en el nivel de usuario, identificadores numricos en el nivel del sistema)
de ubicacin: el nombre de un archivo no da indicio de

Nombres
Hay
y transparencia
Esquema de nombres
tres tipos principales de esquemas en un DFS
El enfoque ms sencillo los archivos se nombran con alguna combinacin del nombre de su anfitrin y su nombre local, lo que garantiza un nombre nico en el nivel del sistema. Este nombre no es transparente ni independiente respecto a la ubicacin El segundo enfoque cuenta con un mecanismo para ligar directorios remotos a directorios locales y as dar la apariencia de un rbol de directorios coherente. Hay necesidad de montar los directorios remotos. Ahora existe la funcin automount que se lleva a cabo por demanda con base en una tabla de puntos de montaje y nombres de estructuras de archivos Una sola estructura de nombres global abarca todos los archivos del sistema
Nombres y transparencia
Tcnicas de implementacin
La implementacin de una estructura de nombres transparente requiere un mecanismo para transformar un nombre de archivo en la posicin correspondiente. A fin de mejorar la disponibilidad de la informacin de transformacin crucial se puede usar mtodos como la replicacin, colocacin en cachs locales o ambas. La independencia de la ubicacin implica que la transformacin cambia con el tiempo, por lo tanto replicar hace imposible una actualizacin sencilla pero consistente de esta informacin. Una tcnica para superar este obstculo es introducir identificadores de archivo independientes de la ubicacin Los nombres de archivo textuales se transforman en identificadores de archivo de mas bajo nivel que indican a cul unidad componente pertenecen. Se puede replicar y poner en cach sin perder su validez por la migracin de las unidades componentes. El precio inevitable es un segundo nivel de transformacin, que transforma unidades componentes en posiciones. Una forma de implementar estos identificadores de bajo nivel es usar nombres estructurados. Estos son cadenas de bits que por lo regular tienen dos partes: la primera identifica la unidad componente a la que el archivo pertenece, la segunda identifica el archivo especfico dentro de la unidad.
Acceso a archivos remotos
Cuando se hace una solicitud de acceso a un archivo remoto se emplea un mecanismo de servicio remoto en el que las solicitudes se entregan al servidor, ste realiza los accesos y los resultados se envan al usuario. Este servicio remoto se implementa con llamadas a procedimientos remotos RPC Para asegurar que un mecanismo de servicio remoto tenga un desempeo razonable, se puede usar cachs. En los sistemas de archivos convencionales el motivo de usar cachs es reducir la E/S de disco, mientras que en los DFS es reducir el trfico de red como la E/S de disco. Esquema de uso de cach bsico

Si los datos que se necesitan no estn ya en cach, se trae una copia desde el sistema del servidor hasta el del cliente La idea es conservar los bloques de disco de acceso reciente en un cach a fin de poder manejar localmente accesos repetidos a la misma informacin sin trfico de red adicional Se usa una poltica de reemplazo para mantener limitado el tamao Si una copia en cach se modifica es preciso reflejar los cambios en la copia maestra para preservar la semntica de consistencia El problema de implementar cachs es la consistencia Si se incrementa la unidad de colocacin aumenta la tasa de aciertos pero tambin el costo de no acertar, porque cada no acierto requiere la transferencia de mas datos y aumenta la posibilidad de problemas de consistencia

Ubicacin del cach

Dnde deben almacenarse los datos en cach Los cachs de disco tienen una ventaja clara respecto a los cachs de memoria principal: su confiabilidad Por otro lado los cachs en memoria principal tienen sus ventajas:
Las estaciones de trabajo no necesitan tener disco Se puede acceder ms rpidamente La tendencia de la tecnologa actual es hacia memorias ms grandes y econmicas Los cachs de servidor estarn en la memoria principal sin importar dnde estn los cachs de usuario
Poltica de actualizacin de cach
La poltica que se sigue para escribir los bloques modificados de vuelta en la copia maestra del servidor tiene un efecto crucial sobre el desempeo y la confiabilidad del sistema. La poltica ms sencilla es escribir los datos en el disco tan pronto como se colocan en cualquier cach. La ventaja de esta escritura a travs es su confiabilidad. Se pierde poca informacin cuando se cae un sistema cliente, el desempeo se hace deficiente. Una poltica alternativa es retardar las actualizaciones. Las modificaciones se escriben en el cach y mas adelante en el servidor. Los accesos son ms rpidos, pero este esquema de escritura retardada introduce problemas de confiabilidad. Otra variacin de la poltica de escritura retardada es que la actualizacin se lleve a cabo cuando el bloque est a punto de ser expulsado del cach del cliente. Un trmino medio entre esta alternativa y la poltica de escritura a travs es examinar el cach a intervalos regulares y escribir en el servidor los bloques que hayan sido modificados desde el ltimo examen Otra variacin ms de la escritura retardada es escribir al cerrar

Acceso
Un
a archivos remotos
Consistencia
mquina cliente enfrenta el problema de decidir si una copia de los datos que est en un cach local es congruente con la copia maestra. Hay dos estrategias para verificar la validez:
Estrategia iniciada por el cliente: el cliente inicia una verificacin de validez, se pone en contacto con el servidor y comprueba los datos. La frecuencia es el meollo de esta estrategia y determina la semntica de consistencia que se obtiene Estrategia iniciada por el servidor: el servidor registra para cada cliente los archivos que coloca en cach. Si el servidor detecta una posible inconsistencia debe reaccionar.

Un
Comparacin del uso de cachs y el servicio remoto
nmero sustancial de los accesos remotos se puede atender desde el cach local cuando se usan cachs. Esto permite atender los accesos remotos casi con la misma rapidez que los locales El gasto extra de la red cuando se transmiten volmenes grandes de datos es menor cuando se transmite una serie de respuestas a solicitudes especficas como en el mtodo de servicio remoto. Las rutinas de acceso a disco en el servidor se pueden optimar mejor si se sabe que siempre se solicitarn segmentos grandes y contiguos de datos en lugar de bloques de disco aleatorias El problema de la consistencia del cach es la principal desventaja del uso de cachs Para que resulte provechoso los cachs la ejecucin debe realizarse en mquinas que tengan discos locales o bien memorias principales grandes, caso contrario debe efectuarse empleando servicio remoto
Servicio con y sin estado
Hay dos enfoques respecto a la informacin en el lado del servidor: o bien el servidor sigue la pista a cada archivo que est siendo accedido por un cliente o simplemente proporciona los bloques sin enterarse de cmo se usarn. En algunos entornos solo puede usarse servicios con estado. Si el servidor emplea el mtodo de verificacin de cach iniciado por el servidor, no podr ofrecer servicio sin estado, ya que debe mantener un registro de cules archivos colocan en cach cules clientes. Servicio de archivos con estado
El
Servicio de archivos sin estado

Cada
servidor conoce exactamente paso a paso toda la operacin con el archivo, guarda en su memoria y proporciona al cliente un identificador de conexin, con esto se accede y trabaja en memoria lo que ahora accesos a disco solicitud es autosuficiente, el servidor no necesita mantener una tabla de archivos abiertos en memoria. El costo de implementar esto es que los mensajes de solicitud son mas largos y el procesamiento de las solicitudes es ms lento ya que no hay informacin en el ncleo.
Replicacin de archivos
La replicacin de archivos en diferentes mquinas es una redundancia til para mejorar la disponibilidad y tambin puede mejorar el desempeo El requisito bsico de un esquema de replicacin es que las rplicas del mismo archivo residan en mquinas independientes en cuanto a los fallos Es deseable ocultar a los usuarios los detalles de la replicacin La existencia de rplicas debe ser invisible para los niveles superiores, no obstante las rplicas se deben distinguir entre si con nombres de bajo nivel distintos. El principal problema relacionado con las rplicas es su actualizacin, hay que conservar la semntica de consistencia.

Coordinacin distribuida
Captulo II: Coordinacin distribuida

Ordenacin
de sucesos
En un sistema centralizado siempre es posible determinar el orden en que han ocurrido dos sucesos, ya que hay una memoria y un reloj comunes En un sistema distribuido no hay una memoria ni un reloj comn, por lo que a veces es imposible saber cul de dos sucesos ocurri primero La relacin sucedi-antes slo es una ordenacin parcial de los sucesos en los sistemas distribuidos.

Ordenacin
Se
La relacin sucedi-antes
de sucesos
consideran solo procesos secuenciales, todos los sucesos que se ejecutan en un mismo proceso estn totalmente ordenados Ley de causalidad, un mensaje solo puede recibirse despus de enviarse Se puede definir la relacin sucedi-antes (denotada por ) como sigue:
Si A y B son sucesos del mismo proceso, y A se ejecut antes que B, entonces A B Si A es el suceso de que un proceso enva un mensaje y B es el suceso de que otro proceso recibe ese mensaje, entonces A B Si A B y B C entonces A C
Puesto
que un suceso no puede ocurrir antes que l mismo, la relacin es una ordenacin parcial reflexiva. Si dos sucesos A y B, no estn relacionados por la relacin (es decir A no ocurri antes que B y B no ocurri antes que A), se dice que ambos sucesos se ejecutaron de forma concurrente

Ordenacin
p1q2
r0q4 q3r4 p1q4
de sucesos
La relacin sucedi-antes
(ya que p1q2 y q2q4)
Algunos procesos concurrentes del sistema son:

q0
y p2 r0 y q3 r0 y p3 q3 y p3
Ordenacin de sucesos
Implementacin
Para

determinar que un suceso A ocurri antes que un suceso B se necesita un reloj comn o un conjunto de relojes perfectamente sincronizados. En un sistema distribuido no se cuenta con ninguna de estas cosas, se define la relacin sucedi-antes sin usar relojes fsicos. Se asocia a cada suceso del sistema una marca de tiempo. Ahora se puede definir el requisito de ordenacin global: para cada par de sucesos A y B, si AB, entonces la marca de tiempo de A es menor que la de B Cmo se hace cumplir el requisito de ordenacin global en un sistema distribuido?
Se define dentro de cada proceso Pi un reloj lgico RLi Este reloj puede ser un simple contador que se incrementa entre cualesquier dos sucesos consecutivos que se ejecutan dentro de un proceso Si un suceso A ocurre antes que el suceso B en el proceso Pi entonces: RLi(A) < RLi(B) El esquema no asegura que se satisfaga el requisito de ordenacin global entre procesos, porque se puede tener una situacin en la que los procesadores y relojes no sean homogneos y unos ms rpidos que otros y unos mas lentos que otros Para resolver esta dificultad es necesario que un proceso adelante su reloj lgico cuando reciba un mensaje cuya marca de tiempo sea mayor que el valor actual de su reloj lgico.
Mutua exclusin
Se presentan varios algoritmos para implementar la mutua exclusin en un entorno distribuido. Se supone que el sistema consiste en n procesos cada uno de los cuales reside en un procesador distinto. Estrategia centralizada
Se
escoge uno de los procesos del sistema para que coordine el ingreso en la seccin crtica. Cada proceso enva un mensaje solicitar al coordinador, cuando el proceso reciba un mensaje responder del coordinador podr ingresar en su seccin crtica. Despus de salir de su seccin crtica el proceso enva un mensaje liberar al coordinador y continuar con su ejecucin. Al recibir un mensaje solicitar el coordinador verifica si algn otro proceso est en su seccin crtica. Si ningn proceso est, el coordinador devuelve de inmediato un mensaje responder caso contrario la solicitud se encola, hasta que reciba un mensaje liberar y tome uno de los mensajes de solicitud de la cola y enviar un mensaje responder al proceso solicitante. Si el proceso coordinador falla, un proceso nuevo deber tomar su lugar.
Mutua exclusin
Si
Estrategia totalmente distribuida
se quiere distribuir la toma de decisiones en todo el sistema, la solucin es mucho ms complicada. El algoritmo se basa en el esquema de ordenacin de sucesos. Cuando un proceso quiere entrar en su seccin crtica, genera una nueva marca de tiempo MT y enva el mensaje solicitar(Pi,TS) a todos los dems procesos del sistema (incluido l mismo) Los procesos pueden contestar de inmediato (responder a Pi) o diferir la contestacin
Si el proceso Pi est en su seccin crtica, diferir su respuesta a Pj Si el proceso Pi no quiere ingresar en su seccin crtica, enviar una respuesta de inmediato a Pj Si el proceso Pi desea ingresar en su seccin crtica pero todava no lo ha hecho, compara la marca de tiempo de su propia solicitud con la marca de tiempo de TS de la solicitud hecha por el proceso Pj que ha llegado. Si es mayor que TS enviar una respuesta de inmediato a Pj (Pj pregunt primero); si no, diferir su respuesta.
Un
proceso que ha recibido un mensaje responder de todos los dems procesos del sistema, podr ingresar en su seccin crtica, encolando las solicitudes que lleguen y difirindolas. Despus de salir de su seccin crtica, el proceso enva mensajes responder a todas sus solicitudes diferidas.
Mutua exclusin
Este
El
esquema requiere la participacin de todos los procesos , tiene consecuencias indeseables:
Se logra la mutua exclusin Se asegura que no habr bloqueos mutuos Se asegura que no habr inanicin, ya que el ingreso se planifica segn la ordenacin por marca de tiempo Los procesos necesitan conocer la identidad de todos los dems procesos que participan en el algoritmo de mutua exclusin El proceso debe recibir los nombres de todos El nombre de un nuevo proceso debe distribuirse a todos Si uno de los procesos falla, todo el esquema se viene abajo. Se puede resolver este inconveniente vigilando continuamente los procesos Los procesos que no han ingresado en su seccin crtica deben hacer pausas frecuentes para asegurar a otros procesos que tienen intencin de ingresar en la seccin crtica
algoritmo exhibe el siguiente comportamiento deseable:

Mutua
Estrategia de paso de testigo

Otro
exclusin
mtodo es hacer circular un testigo entre los procesos del sistema. Un testigo es un tipo especial de mensaje. La posesin del testigo faculta al poseedor para ingresar en la seccin crtica Se supone que los procesos del sistema estn organizados lgicamente en una estructura anular. La red fsica no necesita ser un anillo. Una vez que el proceso sale de su seccin crtica, se vuelve a pasar el testigo. Si el proceso recibe el testigo y no desea ingresar en su seccin crtica pasar el testigo a su vecino. Hay que considerar dos tipos de fallos:
Si se pierde el testigo, se debe convocar a una eleccin para generar un nuevo testigo Si un proceso falla, se debe establecer un nuevo anillo lgico
Atomicidad
Todas las operaciones asociadas a la transaccin se ejecutan hasta terminar o bien ninguna se lleva a cabo. En un sistema distribuido se complica la tarea de asegurar la propiedad de atomicidad. El fallo de un sitio o el enlace de comunicacin podra dar lugar a clculos erroneos. La funcin del coordinador de transacciones de un sistema distribuido es asegurar que la ejecucin de las diversas transacciones en el sistema conserve la atomicidad. El coordinador es responsable de:
Iniciar Dividir
la ejecucin de la transaccin la transaccin en varias subtransacciones y distribuirlas a los sitios apropiados para su ejecucin Coordinar el trmino de la transaccin, con el resultado de que la transaccin se confirma en todos los sitios o se aborta en todos los sitios
Atomicidad
El protocolo de confirmacin de dos fases
Asegurar
la atomicidad de la transaccin, con este objeto el coordinador de transacciones de T debe ejecutar un protocolo de confirmacin Sea T una transaccin iniciada en el sitio Si, y sea Ci el coordinador de transacciones de Si. Cuando T termina su ejecucin, Ci inicia el protocolo 2PC Fase 1:
Ci aade el registro <preparar T> a la bitcora y escribe el registro en almacenamiento estable Enva un mensaje preparar T a todos los sitios en donde T se ejecut El administrador de transacciones del sitio determina si est dispuesto o no a confirmar su porcin de T SI aade un registro <listo T> a la bitcora y responde con un mensaje listo T, escribe todos los registros de bitcora correspondiente en almacenamiento estable NO aade un registro <no T> a la bitcora y responde con un mensaje abortar T
Atomicidad
Fase
El protocolo de confirmacin de dos fases

Cuando Ci recibe respuestas al mensaje preparar T de todos los sitios, o cuando ha transcurrido un intervalo de tiempo previamente especificado desde que se envi el mensaje, se puede determinar si la transaccin T se puede confirmar o abortar. La transaccin T se puede confirmar si Ci recibi un mensaje listo T de todos los sitios participantes. Si no, la transaccin debe abortarse Dependiendo del veredicto se agrega un registro <confirmar T> o uno <abortar T> a la bitcora y se escribe en almacenamiento estable Despus el coordinador enva un mensaje confirmar T o abortar T a todos los sitios participantes
2:
Un
sitio en el que se ejecut T puede abortarla incondicionalmente en cualquier instante antes de enviar el mensaje listo T al coordinador. El mensaje listo T es una promesa que hace un sitio se seguir las rdenes del coordinador de confirmar o abortar
Atomicidad
Una
Manejo de fallos en 2PC
desventaja es que un fallo del coordinador puede dar pie a bloqueo porque la decisin de confirmar o abortar T se tendra que posponer hasta que Ci se recupere. Fallo de un sitio participante
Cuando un sitio participante Sk se recupera de un fallo, debe examinar su bitcora para determinar el destino de las transacciones que se estaban ejecutando La bitcora tiene un registro <confirmar T>. En este caso el sitio ejecuta rehacer(T) La bitcora tiene un registro <abortar T>. En este caso el sitio ejecuta deshacer(T) La bitcora tiene un registro <listo T>. En este caso el sitio debe preguntar a Ci cul fue el destino de T. Si Ci est activo notificar a Sk si T se confirm o abort. En el primero caso, Sk ejecutar rehacer(T); en el segundo caso ejecutar deshacer(T). Si Ci no est activo, Sk deber intentar averiguar el destino de T consultando otros sitios del sistema. La bitcora no contiene registros de control relativos a T. La ausencia de registros de control implica que Sk fall antes de responder al mensaje preparar T de Ci. Se descarta la posibilidad de haber enviado algn mensaje, Ci deber abortar T, por lo tanto debe ejecutar deshacer(T).
Atomicidad
Manejo de fallos en 2PC

Fallo del coordinador
Si el coordinador falla a la mitad de la ejecucin del protocolo de confirmacin para la transaccin T, los sitios participantes deben decidir el destino de T. En otros casos los sitios no pueden decidir si confirmar o abortar T, por lo que es necesario que dichos sitios esperen la recuperacin del coordinador que fall. Si un sitio activo contiene un registro <confirmar T> en su bitcora, T deber confirmarse Si un sitio activo contiene un registro <abortar T> en su bitcora, T deber abortarse Si algn sitio activo no contiene un registro <listo T> en su bitcora, el coordinador que fall no puede haber decidido confirmar T. En lugar de esperar a que Ci se recupere es preferible abortar T Si no se da ninguno de los casos anteriores, todos los sitios tienen un registro <listo T> en sus bitcoras, pero no registros de control adicionales, es imposible determinar si se tom o no una decisin, por lo tanto esperar a que el coordinador se recupere.
Cuando un enlace falla, ninguno de los mensajes que se encaminan llegan a su destino intacto. Desde el punto de vista de los sitios conectados, parece que los dems sitios han fallado. Los esquemas anteriores se aplican a este caso. Si fallan varios enlaces la red se podra dividir, se tienen dos posibilidades: El coordinador y sus participantes quedan en la misma particin, esto no afecta el protocolo de confirmacin El coordinador y sus participantes quedan en diferentes particiones, los mensajes se pierden y el caso se reduce a un fallo en el enlace.
Fallo de la red

Control
de concurrencia
La funcin del administrador de transacciones de un sistema de base de datos distribuido es gestionar la ejecucin de las transacciones o subtransacciones que acceden a datos almacenados en un sitio local. Cada una de estas transacciones puede ser local o parte de una transaccin global
Control de concurrencia
Protocolos de cerraduras
Los
protocolos de cerraduras (semforos) se pueden usar en un entorno distribuido. Hay que incorporar la forma de implementar el administrador de cerraduras. Unos protocolos permiten replicacin de los datos otros no. Existen modos de cerradura compartido y exclusivo. Esquema no replicado
Cada sitio mantiene un administrador de cerraduras local para gestionar las solicitudes de poner y quitar cerraduras a los datos que se almacenan en ese sitio Cuando una transaccin desea asegurar el dato Q en el sitio Si, enva un mensaje al administrador de cerraduras del sitio Si solicitando una cerradura en un modo dado. Si el dato Q ya tiene puesta una cerradura en un modo incompatible la solicitud se diferir hasta que pueda satisfacerse El esquema tiene una implementacin sencilla, requiere dos transferencias de mensajes para gestionar las solicitudes de cerradura y una para manejar las solicitudes de quitar cerraduras
Estrategia
El sistema mantiene un solo administrador de cerraduras que reside en un solo sitio escogido, digamos Si Todas las solicitudes de poner y quitar cerraduras se envan al sitio Si. El administrador determina si se puede otorgar de inmediato la cerradura, si es as enva el mensaje correspondiente al sitio en el que se inici la solicitud; si no la solicitud se difiere hasta que pueda satisfacerse La transaccin puede leer el dato de cualquiera de los sitios en los que reside una rplica. En el caso de una escritura, todos los sitios en los que reside una rplica deben intervenir El esquema tiene ventajas: Implementacin sencilla El manejo de bloqueos mutuos es sencillo Las desventajas del esquema son: Cuello de botella Vulnerabilidad Se puede lograr un trmino medio entre ventajas y desventajas empleando la estrategia de mltiples coordinadores
de coordinador nico
Protocolo
de mayora
Es una modificacin del esquema de datos no replicados El sistema mantiene un administrador de cerraduras en cada sitio y cada uno gestiona las cerraduras para todos los datos o rplicas de datos almacenados en ese sitio. Si una transaccin desea poner una cerradura al dato Q que est replicado en n sitios, enva una solicitud a ms de la mitad de los n sitios. Cada administrador determina si se puede conceder de inmediato La transaccin no opera con Q hasta que haya obtenido una cerradura para la mayora de las rplicas de Q Este esquema maneja los datos replicados en forma descentralizada, pero tiene desventajas: Implementacin Manejo de bloqueos mutuos
Protocolo predispuesto
Copia primaria
Similar al protocolo de mayora. Difiere en que las cerraduras compartidas reciben un tratamiento ms favorable que las exclusivas. El sistema mantiene un administrador de cerraduras en cada sitio Cada administrador gestiona las cerraduras de todos los datos almacenados en ese sitio Las cerraduras compartidas y exclusivas se manejan de diferente manera: Cerraduras compartidas la transaccin pide una cerradura al administrador de cerraduras de un sitio que contiene una rplica de Q Cerraduras exclusivas la transaccin solicita una cerradura al administrador de cerraduras de cada uno de los sitios que contienen una rplica de Q Existe un gasto extra Si existe replicacin de los datos, se podra escoger una de las rplicas como copia primaria. As para cada dato Q, la copia primaria de Q debe residir en un solo sitio que se llama sitio primario de Q Si una transaccin necesita poner una cerradura al dato Q la solicita en el sitio primario de Q La copia primaria permite manejar control de concurrencia de datos replicados de forma similar a como se hace con datos no replicados. Tiene una implementacin sencilla Desventaja si el sitio primario de Q falla, entonces el dato Q estar inaccesible aunque otros contengan una rplica

Manejo
de bloqueos mutuos
Una situacin de bloqueo mutuo es no deseable en el sistema. Para eso existe: Prevencin de bloqueos mutuos
Se
trataba de que una de las cuatro condiciones no se cumpla Existe la estrategia de ordenacin por marca de tiempo con expropiacin de recursos
Deteccin de bloqueos mutuos

Existe
el grafo de espera global, generado a partir de todos los grafos de espera locales

Manejo
Se
Prevencin de bloqueos mutuos
de bloqueos mutuos
puede usar la prevencin por ordenacin de recursos con solo definir una ordenacin global entre los recursos del sistema. Asignar a los recursos nmeros nicos y un proceso puede solicitar con este nmero, solo si no est ocupando un recurso cuyo nmero es mayor que i. Se puede utilizar tambin el algoritmo del banquero, designando a uno de los procesos como banquero. Este esquema se puede implementar pero requiere demasiado gasto extra Existe un nuevo esquema de prevencin: ordenacin por marca
de tiempo con expropiacin de recursos
Para controlar la expropiacin se asigna un nmero de prioridad nico a cada proceso. Estos nmeros sirven para decidir si un proceso Pi debe esperar a un Pj. Ventaja: Este esquema previene los bloqueos mutuos porque no puede haber ciclos Desventaja: Puede haber inanicin, procesos con prioridad muy baja se revierten siempre
Manejo de bloqueos mutuos

El algoritmo de prevencin podra expropiar recursos an si no ha ocurrido un bloqueo mutuo. Para evitar expropiaciones innecesarias se usa un algoritmo de deteccin Se construye un grafo de espera que describe el estado de asignacin de recursos. Se supone que hay un solo recurso de cada tipo, con lo que un ciclo representa un bloqueo mutuo. El problema en un entorno distribuido es cmo mantener el grafo de espera.
Los grafos se construyen de la forma acostumbrada
Se requiere que cada sitio mantenga su grafo de espera local. Los nodos del grafo corresponden a todos los procesos (locales y no locales) que actualmente tienen o estn solicitando recursos locales de ese sitio. Si un proceso Pi del sitio A necesita un recurso que est en poder del proceso Pj del sitio B, Pi enva un mensaje de solicitud al sitio B. La arista Pi Pj se inserta en el grafo de espera local del sitio B
El hecho de que no haya ciclos en ninguno de los grafos de espera locales no implica que no haya bloqueos mutuos Existen varios mtodos para organizar los grafos de espera en un sistema distribuido:
Estrategia centralizada Estrategia totalmente distribuida


Manejo

Estrategia
de bloqueos mutuos
centralizada
Se construye un grafo de espera global como la unin de todos los grafos de espera locales y se mantiene en un solo proceso el coordinador de deteccin de bloqueos mutuos. En vista del retardo por la comunicacin se debe distinguir: El grafo real describe el estado real pero desconocido del sistema en cualquier instante El grafo construido es una aproximacin generada por el coordinador durante la ejecucin de su algoritmo. Hay tres opciones distintas para la construccin del grafo Cada vez que se inserta o se elimina una arista en uno de los grafos de espera locales Peridicamente, cuando ha ocurrido cierto nmero de cambios en un grafo de espera Cada vez que el coordinador necesita invocar el algoritmo de deteccin de ciclos

Manejo
de bloqueos mutuos

Estrategia totalmente distribuida Todos los controles comparten igualmente la responsabilidad de detectar bloqueos mutuos Cada sitio construye un grafo de espera local que representa una parte del grafo total, dependiendo del comportamiento dinmico del sistema. La idea es que si existe un bloqueo mutuo, aparecer un ciclo en (por lo menos) uno de los grafos parciales Se presenta un algoritmo para la construccin de grafos de espera locales Un grafo de espera local en este esquema difiere de los que se describi antes en cuanto a que se aade un nodo extra Pex al grafo.

Existe una arista Pi Pex en el grafo si Pi est esperando un dato de otro sitio que est en poder de cualquier proceso. As mismo, existe una arista Pex Pj en el grafo si hay algn proceso en otro sitio que est esperando adquirir un recurso que actualmente est en poder de Pj en este sitio local Si un grafo de espera local tiene un ciclo en el que no interviene el nodo Pex, el sistema est en un estado de bloqueo mutuo. Si existe un ciclo en el que interviene Pex esto implica que hay la posibilidad de un bloqueo mutuo, se debe invocar un algoritmo distribuido de deteccin de bloqueos mutuos. Cuando un sitio descubre de la posibilidad de existencia de un bloqueo mutuo enva un mensaje al otro sitio de deteccin de bloqueos mutuos El resultado sera el mismo si el sitio S2 descubriera primero el ciclo en su grafo de espera local y enviara el mensaje de deteccin al sitio 1. En el peor de los casos ambos sitios descubrirn el ciclo mas o menos al mismo tiempo y se enviarn dos mensajes de deteccin: uno de S1 a S2 y otro de S2 a S1. Esta situacin da pie a una transferencia innecesaria de mensajes y a gasto extra en la actualizacin de los dos grafos de espera locales y la bsqueda de ciclos en ambos grafos. Se podra reducir el trfico de mensajes si se asigna un identificador nico a cada transaccin Pi, denotada por ID (Pi). Cuando el sitio Sk descubre que su grafo de espera contiene un ciclo en el que interviene el nodo Pex enva un mensaje de deteccin de bloqueos mutuos a otro sitio solo si: ID ( Pkn ) < ID (Pk1) de lo contrario Sk contina con su ejecucin normal y deja la responsabilidad de iniciar el algoritmo de deteccin de bloqueos mutuos a algn otro sitio
Algoritmos de eleccin
Muchos algoritmos distribuidos utilizan un proceso coordinador que desempea funciones que los dems procesos del sistema necesitan Si el proceso coordinador falla, el sistema slo podr continuar funcionando si reinicia una nueva copia en algn otro sitio. Determinan dnde debe reiniciarse una nueva copia del coordinador El coordinador es siempre el proceso que tiene el nmero de prioridad ms alto. As cuando un coordinador falle, el algoritmo elegir el proceso activo cuyo nmero de prioridad sea el mas alto Algunos algoritmos son:
Algoritmo
del grandulln Algoritmo del anillo

Algoritmo del grandulln
El proceso Pi enva un mensaje de eleccin a todos los procesos que tienen prioridad mas alta Si Pi no recibe respuesta dentro de un tiempo T, se autoelige como coordinador y comunica Si Pi recibe una respuesta a su primer mensaje, inicia un intervalo de espera para recibir un mensaje que le informa que un proceso con prioridad mayor ha sido elegido Si no se enva un mensaje se entiende que el proceso que tena el nmero mas alto fall y se debe reiniciar el algoritmo. Si Pi no es el coordinador entonces en cualquier momento durante su ejecucin Pi podra recibir uno de los dos mensajes siguientes del proceso Pj
Pj es el nuevo coordinador (j>i). El proceso Pi registra esta informacin Pj inici una eleccin (j<i). El proceso Pi enva una respuesta a Pj e inicia su propio algoritmo de eleccin
El proceso que completa su algoritmo tiene el nmero ms alto y se elige como coordinador, habiendo enviado su nmero a todos los procesos activos que tienen nmeros ms bajos Cuando un proceso que falla se recupera inicia la ejecucin del mismo algoritmo Si no hay procesos activos con nmeros mas altos el proceso recuperado obliga a todos los procesos con nmeros mas bajos a dejarlo convertirse en el coordinador aunque ya haya un coordinador activo. Es por esto que el algoritmo se denomina del
grandulln.
Algoritmo del anillo
Supone
que los enlaces son unidireccionales y que los procesos envan sus mensajes a su vecino de la derecha La principal estructura que se emplea es la lista activa que tiene los nmeros de prioridad de todos los procesos activos en el sistema Funciona as:
Si el proceso Pi detecta que el coordinador fall, crea una nueva lista activa vaca. Luego enva un mensaje elegir(i) a su vecino de la derecha y aade el nmero i a su lista activa Si Pi recibe un mensaje elegir(j) del proceso de la izquierda, deber responder de una de tres maneras: Si es el primer mensaje elegir que ha recibido o enviado, Pi crea una nueva lista activa con los nmeros i, j. Pi enva el mensaje elegir(i) seguido del mensaje elegir(j) Si i<>j (es decir el mensaje recibido no contiene el nmero de Pi), Pi aade j a su lista activa y reenva el mensaje a su vecino de la derecha Si i=j (es decir Pi recibe el mensaje elegir(i) la lista activa de Pi ya contiene los nmeros de todos los procesos activos del sistema. El proceso Pi puede determinar cul es el nmero ms grande de la lista activa
Acuerdos
Para que un sistema sea confiable es necesario un mecanismo que permita a un conjunto de procesos ponerse de acuerdo en un valor comn Pueden existir algunas causas por las que no se cumpla el acuerdo
El medio de comunicacin podra Los procesos mismos podran
Problema de los generales bizantinos Comunicaciones no confiables Procesos con fallos

Existe
Para
impredecible
tener fallos fallar y tener un comportamiento
detectar fallos se usa un esquema de tiempo lmite
Cada proceso enva su valor privado a los otros procesos Cada proceso enva la informacin que obtuvo en la primera ronda a todos los dems procesos.
un algoritmos con dos rondas de intercambio de informacin:
Cuestionarios
Captulo Captulo Captulo
16 17 18
1,2,3,4,5,6,7
1, 2, 3, 4, 5 1,2,3,4,6,7

Capítulo 15, 16, 17, 18

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Capítulo 15, 16, 17, 18

Hochgeladen von

Copyright:

Verfügbare Formate

Captulo II: Sistemas Distribuidos

Estructura Estructura Sistemas

de redes de sistemas distribuidos

de archivos distribuidos distribuida

Captulo II: Sistemas distribuidos

Captulo II: Estructura de redes

nodos, anfitriones, etc

Captulo II: Estructura de redes

Captulo II: Sistemas distribuidos

Captulo II: Estruct. Sist. Distrib.

Transferencia remota de archivos

mecanismo es la de transferir archivos de una mquina a

Captulo II: Estruct. Sist. Distrib.

Sistemas operativos distribuidos

Captulo II: Estruct. Sist. Distrib.

Captulo II: Estruct. Sist. Distrib.

Llamadas a procedimiento remoto

Captulo II: Estruct. Sist. Distrib.

Captulo II: Estruct. Sist. Distrib.

Recuperacin despus de un fallo

Captulo II: Estruct. Sist. Distrib.

Captulo II: Sistemas distribuidos

Captulo II: Sist. Arch. Distrib.

Captulo II: Sist. Arch. Distrib.

Captulo II: Sist. Arch. Distrib.

de ubicacin: el nombre de un archivo no da indicio de

Captulo II: Sist. Arch. Distrib.

Captulo II: Sist. Arch. Distrib.

Captulo II: Sist. Arch. Distrib.

Acceso a archivos remotos

Captulo II: Sist. Arch. Distrib.

Acceso a archivos remotos

Poltica de actualizacin de cach

Captulo II: Sist. Arch. Distrib.

Captulo II: Sist. Arch. Distrib.

Acceso a archivos remotos

Comparacin del uso de cachs y el servicio remoto

Captulo II: Sist. Arch. Distrib.

Servicio con y sin estado

Servicio de archivos sin estado

Captulo II: Sist. Arch. Distrib.

Captulo II: Sistemas distribuidos

Captulo II: Coordinacin distribuida

Captulo II: Coordinacin distribuida

Captulo II: Coordinacin distribuida

(ya que p1q2 y q2q4)

Algunos procesos concurrentes del sistema son:

Captulo II: Coordinacin distribuida

Captulo II: Coordinacin distribuida

Captulo II: Coordinacin distribuida

Estrategia totalmente distribuida

Captulo II: Coordinacin distribuida

Estrategia totalmente distribuida

esquema requiere la participacin de todos los procesos , tiene consecuencias indeseables:

algoritmo exhibe el siguiente comportamiento deseable:

Captulo II: Coordinacin distribuida

Estrategia de paso de testigo

Captulo II: Coordinacin distribuida

Captulo II: Coordinacin distribuida

Captulo II: Coordinacin distribuida

El protocolo de confirmacin de dos fases

Captulo II: Coordinacin distribuida

Manejo de fallos en 2PC