monografia de sistemas distribuidos
DESCRIPTION
sistemas distribuidoshistoria de los sistemas distribuidosevolución de los sistemas distribuidostipos de sistemas distribuidosclasespartesclasificacionesejemplosTRANSCRIPT
Sistemas Distribuidos
DEDICATORIA
A nuestros padres por darnos la mejor educación y enseñarme que todas las cosas hay que
valorarlas, trabajarlas y luchar para logra los objetivos de la vida. A nuiestras madres por todo su
amor y ternura que nos han brindado a lo largo de nuestra vida. A mis parientes por estar en
buenos y malos momentos de mi vida. A la Unversidad Privada San Pedro por enseñarnos que la
inteligencia es la fuente de un hombre prospero y que estudiar es un valor incalculable de la
vida. A nuestro profesor Omar Meca Rosales por enseñarme ha escuchar y comprender las cosas
de la vida y aprender que el mejor músculo del hombre es el cerebro.
Pagina 2
Sistemas Distribuidos
Sistemas
Distribuidos
Pagina 3
Sistemas Distribuidos
ÍNDICE DE LA TABLA DE CONTENIDO
-Dedicatoria---------------------------------------------------------------------------------02
-Titulo o portada --------------------------------------------------------------------------03
-Introducción ------------------------------------------------------------------------------ 10
-Glosario ------------------------------------------------------------------------------------ 11
-Objetivos ---------------------------------------------------------------------------------- 14
-CAPITULO 1: SISTEMAS DISTRIBUIDOS ---------------------------------- 15
1.1 Historia de los Sistemas Distribuidos -------------------------------------------- 16
1.2 Que es un Sistema Distribuido---------------------------------------------- ---------17
1.3 Objetivos ---------------------------------------------------------------------- -------- 21
1.4 Conceptos de Hardware ------------------------------------------------------------ 23
1.5 Conceptos de Software --------------------------------------------------------------26
1.6 Aspectos de Diseño ---------------------------------------------------------- ---------27
1.7 Componentes de los Sistemas Distribuidos---------------------------------------- 31
-CAPITULO 2: RECURSOS DE LOS SISTEMAS DISTRIBUIDOS --------34
2.1 Comunicación En Los Sistemas Distribuidos---------------------------------- 35
Pagina 4
Sistemas Distribuidos
2.1.1 Protocolo con capas -------------------------------------------------------- --------36
2.1.2 Redes con modo de transferencia ---------------------------------------- ------- -38
2.1.3 El modelo cliente-servidor----------------------------------------------- - --------41
Llamada de Procedimiento Remoto (RPC) ---------------------------------- --------45
2.2 Sincronización en los Sistemas Distribuidos ----------------------------------- 49
2.2.1 Sincronización de los relojes ------------------------------------------- --------49
2.2.2 Exclusión mutua--------------------------------------------------------------------- 53
2.2.3 Algoritmos de elección---------------------------------------------------- -------- 56
2.2.4 Transacciones atómicas------------------------------------------------------------- 57
2.2.5 Bloqueos en sistemas distribuidos ------------------------------------------------ 59
2.3 Procesos y procesadores en los Sistemas Distribuidos----------------------- --62
2.3.1 Hilos ------------------------------------------------------------------------------ -62
2.3.2 Modelos de sistemas -------------------------------------------------------------- 66
2.3.3 Asignación de procesadores ---------------------------------------------------- 69
2.3.4 Planificación en Sistemas distribuidos---------------------------------- -------- 72
2.3.5 Tolerancia de fallas ------------------------------------------------------------- 73
2.3.6 Sistemas distribuidos en tiempo real ---------------------------------- -------- 76
Pagina 5
Sistemas Distribuidos
2.4 Sistemas de archivos ------------------------------------------------------------ 80
2.4.1 Diseño de sistemas de archivos --------------------------------------------------- 81
2.4.2 Implantación de un sistema distribuido---------------------------------- -------- 83
2.4.3 Tendencias en los sistemas distribuidos de archivos -------------------------- 87
2.5 Memoria Distribuida ---------------------------------------------------------------- 89
2.5.1 Que es la memoria compartida ---------------------------------------------------- 90
2.5.2 Modelos de consistencia ---------------------------------------------------------- 92
2.5.3 Memoria compartida distribuida con bases a páginas ------------------------ 94
2.5.4 Memoria compartida distribuida con variables compartidas ---------------- 96
2.5.5 Memoria compartida distribuida basada en objetos ------------------------- 97
-UNIDAD 3: MODELOS DE SISTEMAS DISTRIBUIDOS -------------------- 100
3.1 AMOEBA
3.1.1 Introducción a la AMOEBA ---------------------------------------------------- 101
3.1.2 Objetos y posibilidades de AMOEBA ---------------------------------------- 102
3.1.3 Administración de procesos de memoria --------------------------------------- 103
3.1.4 Administración de memoria en AMOEBA ---------------------------------- 104
Pagina 6
Sistemas Distribuidos
3.1.5 Comunicación en AMOEBA --------------------------------------------------- 105
3.1.6 Los servidores de AMOEBA -------------------------------------------------- 107
3.2 CHORUS
3.2.1 Introducción a CHORUS -------------------------------------------------------- 108
3.2.2 Administración de procesos en CHORUS ------------------------------------- 113
3.2.3 Administración de memoria en CHORUS ------------------------------------- 120
3.2.4 Comunicación en CHORUS --------------------------------------------------- 121
-UNIDAD 4: PROYECTOS DE MODELAMIENTO -------------------------- 123
4.1 Metodología para la realización de proyectos basados en S.D ----------------- 124
-Conclusiones ------------------------------------------------------------------------------ 129
-Anexos---------------------------------------------------------------------------------------131
-Bibliografía ------------------------------------------------------------------------------ 148
Pagina 7
Sistemas Distribuidos
ÍNDICE DE LA TABLA DE IMAGENES
Sistemas distribuido historia (imagen 1 y 2) ----------------------------------------------132
Factores ventajas y desventajas de un sistema distribuido (imagen 3)-----------------133
Tolerancia a fallos de un sistema distribuidos (imagen 4)-------------------------------133
Hardware de un sistema distribuido (imagen 5)--------------------------------------------133
Desempeño y escalabilidad de un sistema distribuido (imagen 6)-----------------------134
Servicio de seguridad componentes de un sistema distribuido (imagen 7)-------------134
Modelo OSI (imagen 8)------------------------------------------------------------------------135
Redes con modo de transferencia (imagen 9)-----------------------------------------------135
Atm (imagen 10)--------------------------------------------------------------------------------136
Modelo cliente servidor (imagen 11)---------------------------------------------------------136
Solicitud y respuesta del modelo cliente servidor (imagen 12) -------------------------136
implantación del modelo cliente servidor (imagen 13 y 14)-------------------------------137
Lla nada de un procedim iento remoto (imagen 15)----------------------------------------138
Sincronización de relojes (imagen 16)--------------------------------------------------------138
Algoritmo para sincronizar relojes (imagen 17)---------------------------------------------138
Exclusión mutua (imagen 18)------------------------------------------------------------------139
Algoritmo de elección (imagen 19)-----------------------------------------------------------139
Bloqueos de sistemas (imagen 20)------------------------------------------------------------139
Implantación de paquetes de hilos (imagen 21) --------------------------------------------140
Modelos de asignación (imagen 22)----------------------------------------------------------140
Fallas comunes (imagen 23)-------------------------------------------------------------------140
Pagina 8
Sistemas Distribuidos
DTR (imagen 24)--------------------------------------------------------------------------------141
Servidores de archivos (imagen 25)-----------------------------------------------------------141
Protocolo de actualización (imagen 26)-------------------------------------------------------142
Memoria distribuida (imagen 27)--------------------------------------------------------------142
Memoria compartida (imagen 28)-------------------------------------------------------------142
Modelos de consistencia (imagen 29)---------------------------------------------------------143
Memoria compartida distribuida con bases de paginas (imagen 30)----------------------143
Memoria compartida distribuida con bases de objetos (imagen 31)-----------------------143
Objetos (imagen 32 y 33)------------------------------------------------------------------------144
Amoeba (imagen 34)-----------------------------------------------------------------------------145
Objetos y posibilidades (imagen 35)-----------------------------------------------------------145
Procesos (imagen 36)-----------------------------------------------------------------------------145
Funcionamiento RPC (imagen 37)-------------------------------------------------------------146
Servidor de archivos (imagen 38 y 39)--------------------------------------------------------146
Servidor de directorios (imagen 40)-----------------------------------------------------------147
Servidor de ejecución (imagen 41)-------------------------------------------------------------147
CHORUS (imagen 42)---------------------------------------------------------------------------147
Administración en memoria en CHORUS (imagen 43)-------------------------------------148
Comunicación en CHORUS (imagen 44)-----------------------------------------------------148
Pagina 9
Sistemas Distribuidos
INTRODUCCIÓN
El presente trabajo se refiere del tema Sistemas Distribuidos, que se puede definir como una
colección de computadoras separadas físicamente y conectadas entre sí por una red de
comunicaciones; cada máquina posee sus componentes de hardware y software que el
programador percibe como un solo sistema (no necesita saber qué cosas están en qué máquinas).
El programador accede a los componentes de software (objetos) remotos, de la misma manera
en que accedería a componentes locales, en un grupo de computadoras que usan un middleware
entre los que destacan (RPC) y SOAP para conseguir un objetivo.
La característica principal de los Sistemas Distribuidos es la compartición de recursos. La idea
de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los
sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus
usuarios.
Los objetivos principales que buscan los sistemas distribuidos son los siguientes:
Transparencia
Fiabilidad (disponibilidad y coherencia)
Rendimiento
Escalabilidad
Flexibilidad
Seguridad
Cada uno de los distintos modelos de sistemas distribuidos requiere diferentes facetas de estos
objetivos.
Pagina 10
Sistemas Distribuidos
GLOSARIO
Sistema
Es el conjunto de partes que se interrelacionan entre sí como el hardware, software y de recurso
humano que permiten almacenar y procesar la información dependiendo de la actividad a la que
este dedicado el sistema.
Estos elementos suele incluirse los elementos físicos, el software, entre otros relacionados. Suele
contener este término el software básico, tal como el sistema operativo, y los compiladores,
depuradores, enlazadores, entre otros.
Distribuido
En un término de informática la distribución es un nuevo modelo para resolver problemas de
computación masiva utilizando un gran número de computadoras estas organizadas en racimos
incrustados en una infraestructura de telecomunicaciones distribuida.
Modelo
Es una estructura de datos que permite hacer o realizar alguna actividad o acción
dependiendo el objetivo del modelo. Otro enfoque es pensar que un modelo permite describir
los elementos de la realidad que intervienen en un problema dado y la forma en que se
relacionan esos elementos entre sí.
Pagina 11
Sistemas Distribuidos
Minicomputadora
Es una computadora que tiene un circuito integrado que tiene la mayoría de las capacidades de
procesamiento de las grandes computadoras llamados microprocesadores, y como mínimo algún
tipo de memoria semiconductora.
Generalmente son computadoras que ocupan espacios físicos pequeños, comparadas a sus
predecesoras históricas, las mainframes y las minicomputadoras.
Microprocesador
Es el circuito integrado central y más complejo de un sistema informático, este circuito está
integrado por millones de componentes electrónicos que constituye la unidad central de
procesamiento de un PC catalogado binarias y accesos a memoria.
Este ejecuta instrucciones que se le dan a la computadora a muy bajo nivel haciendo operaciones
lógicas simples, como sumar, restar, multiplicar y dividir.
Operativo
Se trata de un dispositivo o un plan que lleva a cabo para desarrollar una acción y conseguir un
objetivo.
Proceso
Es una parte que puede entenderse informalmente como un programa en ejecución.
Formalmente un proceso es una unidad de actividad que se caracteriza por la ejecución de una
secuencia de instrucciones, un estado actual, y un conjunto de recursos del sistema asociados.
Pagina 12
Sistemas Distribuidos
Recurso
Ha sido aplicado en diversos ámbitos, en particular, con respecto a las ciencias de la
computación, que refiriéndose a estas es una fuente o suministro del cual se produce un
beneficio. Normalmente, los recursos son material u otros activos que son transformados para
producir beneficio y en el proceso pueden ser consumidos o no estar más disponibles.
Migración
Migración en la cuestión informática se denomina a todo desplazamiento de la de datos y/o
información que se produce de un lugar de origen a otro de destino y lleva consigo un cambio de
la residencia de almacenamiento.
Sincronización
Se describe como el ajuste temporal de eventos, se habla de sincronización cuando determinados
fenómenos ocurran en un orden predefinido o a la vez. Se utiliza para regresar a un estado
anterior conocido en caso de error durante la sesión. Aunque parezca innecesario (la capa de
transporte sólo recupera errores de comunicación) ocurren muchos errores a nivel de sesiones
entre usuarios (capas superiores).
Sistema Distribuido
Es una colección de computadoras conectadas en red, las cuales se comunican y coordinan entre
sí para lograr un objetivo. se establecen una o varias comunicaciones mediante el esquema
Cliente-Servidor.
Pagina 13
Sistemas Distribuidos
OBJETIVOS
Objetivo General:
El objetivo general de este trabajo es comprender el buen funcionamiento, la eficacia y la
fiabilidad de los sistemas distribuidos.
Objetivos Específicos:
Entender como está estructurado un Sistema Distribuido
Conocer que tipos de Sistemas Distribuidos que existen
Dar a entender las nuevas tecnologías y metodologías que trabajan junto a los sistemas
distribuidos.
Conocer proyectos de modelamiento basados en sistemas distribuidos.
Pagina 14
Sistemas Distribuidos
Capítulo 1: Sistemas
Distribuidos
Pagina 15
Sistemas Distribuidos
1.1 HISTORIA DE LOS SISTEMAS DISTRIBUIDOS
En el inicio de la era de la informática las computadoras eran grandes y caras. Debido a su
escasez y coste, éstas funcionaban de forma independiente entre ellas.
A partir de los años 70, surgen los primeros miniordenadores, que competirían con los grandes
ordenadores tanto por las prestaciones como por su precio, con lo que se extendió su uso. Los
grandes sistemas centralizados fueron dejando paso lentamente a sistemas mucho más
descentralizados, y formados por varios ordenadores o a sistemas multiprocesador. Pronto
surgieron nuevas necesidades de interconexión de los equipos, y se desarrollaron las redes de
área local (LAN), como Ethernet o Token ring.
ETAPAS
En los 40's, se introducen los programas bit a bit, por medio de interruptores mecánicos y
después se introdujo el lenguaje máquina que trabajaba por tarjetas perforadas.
Con las primeras computadoras, desde finales de los años 40 hasta la mitad de los años 50, el
programador interactuaba de manera directa con el hardware de la computadora, no existía
realmente un Sistema Operativo; las primeras computadoras utilizaban bulbos, la entrada de
datos y los programas se realizaban a través del lenguaje máquina (bits) o a través de
interruptores.
Durante los años 50's y 60's.- A principio de los 50's, la compañía General's Motors implanto
el primer sistema operativo para su IBM 170. Empiezan a surgir las tarjetas perforadas las cuales
permiten que los usuarios (que en ese tiempo eran programadores, diseñadores, capturistas, etc.),
Pagina 16
Sistemas Distribuidos
se encarguen de modificar sus programas. Establecían o apartaban tiempo, metían o introducían
sus programas, corregían y depuraban sus programas en su tiempo. A esto se le llamaba trabajo
en serie. Todo esto se traducía en pérdida de tiempo y tiempos de programas excesivos.
En los años 60's y 70's se genera el circuito integrado, se organizan los trabajos y se generan
los procesos Batch (por lotes), lo cual consiste en determinar los trabajos comunes y realizarlos
todos juntos de una sola vez. En esta época surgen las unidades de cinta y el cargador de
programas, el cual se considera como el primer tipo de Sistema Operativo.
En los 80's, inició el auge de la INTERNET en los Estados Unidos de América. A finales de
los años 80's comienza el gran auge y evolución de los Sistemas Operativos. Se descubre el
concepto de multiprogramación que consiste en tener cargados en memoria a varios trabajos al
mismo tiempo, tema principal de los Sistemas Operativos actuales.
En los 90's y en adelante, entramos a la era de la computación distribuida y del
multiprocesamiento a través de múltiples redes de computadoras, aprovechando el ciclo del
procesador (ver imagen 1 e imagen 2).
1.2 ¿QUÉ ES UN SISTEMA DISTRIBUIDO?
Un sistema distribuido se define como una colección de computadoras separadas físicamente y
conectadas entre sí por una red de comunicaciones; cada máquina posee sus componentes de
hardware y software que el programador percibe como un solo sistema (no necesita saber qué
cosas están en qué máquinas). El programador accede a los componentes de software (objetos)
remotos, de la misma manera en que accedería a componentes locales, en un grupo de
Pagina 17
Sistemas Distribuidos
computadoras que usan un middleware entre los que destacan (RPC) y SOAP para conseguir un
objetivo.
Los sistemas distribuidos deben ser muy confiables, ya que si un componente del sistema se
descompone otro componente debe ser capaz de reemplazarlo. Esto se denomina tolerancia a
fallos.
El tamaño de un sistema distribuido puede ser muy variado, ya sean decenas de hosts (red de
área local), centenas de hosts (red de área metropolitana), o miles, o millones de hosts (Internet);
esto se denomina escalabilidad.
Colección de elementos de cómputo autónomo que se encuentran físicamente separados y no
comparten una memoria común, se comunican entre sí a través del intercambio de mensajes
utilizando un medio de comunicación. Los sistemas autónomos pueden tener características no
homogéneas.
Características de los Sistemas Distribuidos.
1.-Cada elemento de cómputo tiene su propia memoria y su propio Sistema Operativo.
2.-Control de recursos locales y remotos.
3.- Sistemas Abiertos (Facilidades de cambio y crecimiento).
4.-Plataforma no standard (Unix, NT, Intel, RISC, Etc.).
5.-Medios de comunicación (Redes, Protocolos, Dispositivos, Etc.).
6.- Capacidad de Procesamiento en paralelo.
7.-Dispersión y parcialidad.
Pagina 18
Sistemas Distribuidos
Factores que han afectado el desarrollo de los Sistemas Distribuidos.
1.-Avances Tecnológicos.
2 .Nuevos requerimientos.
3.-Globalización.
4.-Aspectos Externos (Culturales, Políticos, Económicos).
5.-Integración.
Ventajas y Desventajas de los Sistemas Distribuidos.
Ventajas:
Procesadores más poderosos y a menos costos
Desarrollo de Estaciones con más capacidades
Las estaciones satisfacen las necesidades de los usuarios.
Uso de nuevas interfaces.
Avances en la Tecnología de Comunicaciones.
Disponibilidad de elementos de Comunicación.
Desarrollo de nuevas técnicas.
Compartición de Recursos.
Dispositivos (Hardware).
Programas (Software).
Eficiencia y Flexibilidad.
Pagina 19
Sistemas Distribuidos
Respuesta Rápida.
Ejecución Concurrente de procesos (En varias computadoras).
Empleo de técnicas de procesamiento distribuido.
Disponibilidad y Confiabilidad.
Sistema poco propenso a fallas (Si un componente no afecta a la disponibilidad del sistema).
Mayores servicios que elevan la funcionalidad (Monitoreo, Telecontrol, Correo Eléctrico,
Etc.).
Crecimiento Modular.
Es inherente al crecimiento.
Inclusión rápida de nuevos recursos.
Los recursos actuales no afectan.
Desventajas:
-Requerimientos de mayores controles de procesamiento.
-Velocidad de propagación de información (Muy lenta a veces).
-Servicios de replicación de datos y servicios con posibilidades de fallas.
-Mayores controles de acceso y proceso (Commit).
-Administración más compleja.
-Costos. (ver imagen 3)
Pagina 20
Sistemas Distribuidos
1.3 OBJETIVOS DE UN SISTEMA DISTRIBUIDO
-Transparencia.
El objetivo esencial de un sistema distribuido es proporcionar al usuario y a las aplicaciones una
visión de los recursos del sistema como gestionados por una sola máquina virtual. La
distribución física de los recursos es transparente.
Pueden describirse diferentes aspectos de la transparencia:
• De identificación. Los espacios de nombres de los recursos son independientes de la topología
de la red y de la propia distribución de los recursos. De esta forma, una aplicación puede
referirse a un recurso con un nombre independientemente de en qué nodo se ejecute.
-Escalabilidad.
Una de las características de los sistemas distribuidos es su modularidad, lo que le permite una
gran flexibilidad y posibilita su escalabilidad, definida como la capacidad del sistema para
crecer sin aumentar su complejidad ni disminuir su rendimiento. Uno de los objetivos del diseño
de un sistema distribuido es extender la escalabilidad a la integración de servicios.
- Complejidad/rendimiento.
El crecimiento de un sistema distribuido puede introducir cuellos de botella y latencias que
degradan su rendimiento. Además del incremento de los costes de comunicación por el aumento
de la distancia física entre los componentes del sistema, la complejidad estructural de los
algoritmos distribuidos es a menudo más que lineal con respecto al tamaño del sistema, como
iremos comprobando a lo largo del curso. Es necesario, por tanto, establecer compromisos entre
tamaño del sistema, rendimiento y complejidad.
Pagina 21
Sistemas Distribuidos
Fiabilidad y tolerancia a fallos.
La fiabilidad de un sistema puede definirse como su capacidad para realizar correctamente y en
todo momento las funciones para las que se ha diseñado. La fiabilidad se concreta en dos
aspectos:
• Disponibilidad. Es la fracción de tiempo que el sistema está operativo.
El principal parámetro para medir la disponibilidad es el tiempo medio entre fallos (MTBF),
pero hay que considerar también el tiempo de reparación. La disponibilidad se puede
incrementar de dos formas: (a) utilizando componentes de mayor calidad, y/o (b) con un diseño
basado en la replicación de componentes que permita al sistema seguir operando aun cuando
alguno(s) de ellos falle(n). Ambas alternativas incrementan el coste del sistema; sin embargo, en
el estado tecnológico actual, la replicación resulta, en general, menos costosa. Los sistemas
distribuidos proporcionan inherentemente la replicación de algunos recursos (por ejemplo,
unidades de proceso), mientras que otros normalmente compartidos (por ejemplo, un servidor de
ficheros) pueden replicarse para aumentar la disponibilidad.
. • Tolerancia a fallos. Aún con una alta disponibilidad, un fallo en un momento determinado
puede tener consecuencias desastrosas. Piénsese en sistemas de tiempo real críticos que
controlan dispositivos vitales (por ejemplo en medicina, centrales nucleares...). Es decir, aunque
la replicación aumenta la disponibilidad, no garantiza por sí sola la continuidad del servicio de
forma transparente. La tolerancia a fallos expresa la capacidad del sistema para seguir operando
correctamente ante el fallo de alguno de sus componentes, enmascarando el fallo al usuario o a
la aplicación. Por lo tanto, la tolerancia a fallos implica (1) detectar el fallo, y (2) continuar el
servicio, todo ello de forma transparente para la aplicación (transparencia de fallos).Sobre
Pagina 22
Sistemas Distribuidos
nuestro ejemplo cabe decir que, al carecer de replicación del servicio, NFS no proporciona
tolerancia a fallos. En cambio, se han propuesto otros sistemas de fichero que sí tienen la
tolerancia a fallos como objetivo de diseño, como es el caso de AFS. (ver imagen 4)
Consistencia.
La distribución de recursos introduce importantes beneficios. Por una parte, contribuye al
incremento del rendimiento a través del paralelismo y promoviendo el acceso a copias locales
del recurso (disminuyendo los costes de comunicación). Por otra, como se acaba de ver, la
replicación aumenta la disponibilidad, siendo la base para proporcionar tolerancia a fallos. No
obstante, distribuir recursos acarrea algunos problemas. Por una parte, la red de interconexión es
una nueva fuente de fallos. Además, la seguridad del sistema es más vulnerable ante accesos no
permitidos. Pero el problema de mayor complejidad es el de la gestión del estado global para
evitar situaciones de inconsistencia entre los componentes del sistema. Este es un aspecto
fundamental en el diseño del sistema distribuido, por lo que lo comentaremos a continuación:
El problema radica en la necesidad de mantener un estado global consistente en un sistema con
varios componentes.
1.4 CONCEPTOS DE HARDWARE
Se ha mencionado que en un sistema distribuido existen varias unidades centrales de procesos y
es necesario organizar las formas de interconectarlas para que puedan comunicarse entre sí.
Durante el transcurso de la evolución de los sistemas distribuidos, han surgido diferentes
propuestas para clasificar a las computadoras con varios CPU. Es probable que una de las
propuestas más aceptadas sea la de Flynn (1972) y en ella, Flynn propone dos características
Pagina 23
Sistemas Distribuidos
consideradas por el cómo esenciales: el número de flujos de instrucciones y el número de flujo
de datos. Se puede catalogar a los equipos de cómputo de acuerdo a lo anterior de la siguiente
forma:
Una computadora con un solo flujo de instrucciones y un flujo de datos (SISD, Single
Instruction Single Data). Dentro de esta categoría caen todas las computadoras tradicionales con
un solo procesador.
Computadoras con un flujo de instrucciones y varios flujos de datos (SIMD, Single
Instruction Multiple Data). En esta categoría se incluyen aquellas computadoras que pueden
instruir a varios procesadores para que, en paralelo, ejecuten instrucciones.
Computadoras con múltiples flujos de instrucciones y varios flujos de datos (MIMD, Multiple
Instruction Multiple Data). Esto significa un grupo de computadoras independientes, cada una
con su propio contador de programa y datos. En conjunto, un sistema distribuido recae en esta
clasificación.
Existe otra propuesta en las que los sistemas MIMD se subdividen en dos grupos:
Maquinas multiprocesadores. Existe un espacio de direcciones virtuales, compartido por
todos los CPU del sistema.
Computadoras multi computadoras. Cada máquina tiene su propia memoria en particular.
Asi mismo, cada una de las dos categorías anteriores puede clasificarse de acuerdo a la red de
comunicación con la que se interconectan los CPU, en las dos siguientes categorías.
Tecnología de bus, en la que existe una sola red, plano de base, cable o cualquier otro medio
que conecta a las computadoras.
Pagina 24
Sistemas Distribuidos
La tecnología de conmutador, cuenta con cables individuales que van de una maquina a otra y
utilizan diferentes patrones de cableado. Los mensajes van a través de los cables y se hace una
decisión de conmutación, para dirigir el mensaje a lo largo de la red.
A continuación se detallan cuatro categorías de sistemas de cómputo, incluyendo las dos
categorías de red para conexión.
1. Multiprocesadores con base en buses. Estos sistemas cuentan con un número de CPU,
conectados a un bus común, junto con un módulo de memoria, común para todos. El problema
que podría existir en este esquema, es que el bus puede sobrecargarse, disminuyendo el
rendimiento del sistema en general. Este problema se solucionaría instalando un cache en cada
CPU, de tal forma que los CPU actualicen la información del cache y de la memoria, al
momento de realizar escrituras.
2. Multiprocesadores con conmutador. Este esquema puede usarse en la construcción de
máquinas con más de 64 procesadores y conectarlos a una memoria común. Una solución, es
dividir la memoria en módulos y conectarlos a los CPU con un conmutador de cruceta, como se
muestra en la siguiente figura. Cada CPU y cada memoria cuentan con una conexión y en cada
intersección, existe un conmutador del punto de cruce electrónico, que el hardware puede abrir y
cerrar, asi que cuando un CPU desea tener acceso a un bloque de memoria en particular, cierra
momentáneamente al conmutador del punto de cruce. Un punto en contra del conmutador de
cruceta es que con n CPU y n memorias, se requieren n2 conmutadores en los puntos de cruce.
Se cree la red omega como una solución a este problema. Esta red contiene conmutadores 2 x 2,
cada uno de los cuales tienen dos entradas y dos salidas, y cada entrada se puede dirigir a
cualquier salida.
Pagina 25
Sistemas Distribuidos
3. Multicomputadoras con base en buses. La construcción de este sistema implica una
conexión directa entre el CPU y una memoria lógica, pero el problema que existe, es lograr que
los CPU se comuniquen. Un sistema de este tipo puede ser una LAN de velocidad desde los 10
hasta los 100 Mb/seg.
4. Multicomputadoras con conmutador. En esta categoría, se utilizan una retícula y un
hipercubo, como base de interconexión entre los CPU del sistema. (ver imagen 5)
1.5 CONCEPTOS DE SOFTWARE
En todo sistema de cómputo, el hardware resulta muy importante, pero el software lo es aún
más, pues el software representa la interfaz con los usuarios. Similarmente al hardware, los
sistemas operativos se clasifican en débilmente acoplados y fuertemente acoplados.
El software débilmente acoplado permite que las máquinas de un sistema distribuido
fundamentalmente sean independientes entre sí, pero que interactúen cuando sea necesario. A
continuación se describen tres tipos de software a utilizar en un sistema de multiprocesadores o
Multicomputadoras.
1. Software débilmente acoplado en hardware débilmente acoplado. El ejemplo más común
de este tipo es una LAN, en la que cada usuario cuenta con su propia estación de trabajo, con o
sin disco duro, además de contar con su propio sistema operativo. Para mejorar la comunicación
y la distribución de información, en este modelo se utilizan una o varias computadoras llamadas
servidores de archivos, que se encargan de resolver las solicitudes de escritura y lectura de
información por los usuarios, a quienes se les llama clientes.
Pagina 26
Sistemas Distribuidos
2. Software fuertemente acoplado en hardware débilmente acoplado
(Multicomputadoras). El principal objetivo de este tipo de sistema, es que para los usuarios,
toda la red de computadoras, funcione como un sólo sistema, en lugar de un conjunto de
máquinas interconectadas entre si. Los verdaderos sistemas distribuidos recaen en esta
clasificación.
3. Software fuertemente acoplado en hardware fuertemente acoplado. Aunque aquí existen
varias máquinas de propósito específico (como los servidores de bases de datos), los ejemplos
más comunes a mostrar son los sistemas de tiempo compartido con más de un CPU. Para la
ejecución de los procesos, se utiliza una cola de procesos listos para ejecución. La cola de
ejecución es una estructura de datos almacenada en la memoria compartida, y existe un
planificador para la asignación de cada proceso para uno de los CPU del sistema. El planificador
hace uso de monitores o semáforos para la lograr exclusión mutua necesaria, para que un mismo
proceso no sea asignado a más de un CPU.
1.6 ASPECTOS DEL DISEÑO
Los aspectos claves en el diseño de S. O. distribuidos son:
Transparencia
Un aspecto muy importante es la forma de lograr la imagen de un único sistema
Los usuarios deben percibir que la colección de máquinas conectadas es un sistema de tiempo
compartido de un solo procesador:
Pagina 27
Sistemas Distribuidos
Un sistema que logre este objetivo se dice que es transparente.
Desde el punto de vista de los usuarios, la transparencia se logra cuando:
Sus pedidos se satisfacen con ejecuciones en paralelo en distintas máquinas.
Se utilizan una variedad de servidores de archivos.
El usuario no necesita saberlo ni notarlo.
La transparencia desde el punto de vista de los programas significa diseñar la interfaz de
llamadas al sistema de modo que no sea visible la existencia de varios procesadores.
Flexibilidad.
Existen dos escuelas de pensamiento en cuanto a la estructura de los sistemas distribuidos.
Núcleo monolítico:
o Cada máquina debe ejecutar un núcleo tradicional que proporcione la mayoría de los
servicios.
Micronúcleo (microkernel):
o El núcleo debe proporcionar lo menos posible.
o El grueso de los servicios del S. O. se debe obtener a partir de los servidores al nivel usuario.
Confiabilidad
Un importante objetivo de los sistemas distribuidos es que si una máquina falla, alguna otra debe
encargarse del trabajo
Pagina 28
Sistemas Distribuidos
La confiabilidad global teórica del sistema podría ser el “or” booleano de la confiabilidad de los
componentes; ejemplo:
Se dispone de 5 servidores de archivos, cada uno con una probabilidad de 0,95 de funcionar
en un instante dado.
La probabilidad de falla simultánea de los 5 es (0,05)5 = 0,000006.
La probabilidad de que al menos uno esté disponible es 0,999994.
La confiabilidad práctica se ve disminuida ya que muchas veces se requiere que ciertos
servidores estén en servicio simultáneamente para que el todo funcione, debido a ello algunos
sistemas tienen una disponibilidad más relacionada con el “and” booleano de las componentes
que con el “or” booleano.
Desempeño
Cuando se ejecuta una aplicación en un sistema distribuido no debe parecer peor que su
ejecución en un único procesador, pero esto es difícil de lograr.
Algunas métricas del desempeño son:
Tiempo de respuesta.
Rendimiento (número de trabajos por hora).
Uso del sistema y cantidad consumida de la capacidad de la red.
El problema se complica por el hecho de que la comunicación entre equipos es lenta comparada
con:
La velocidad de proceso.
Pagina 29
Sistemas Distribuidos
La velocidad de la comunicación dentro de un mismo procesador.
Se requiere el uso de protocolos de comunicaciones en los extremos (procesadores) que
intervienen en la comunicación, con lo que se incrementa el consumo de ciclos de procesador.
Escalabilidad
La tendencia indica que el tamaño de los sistemas distribuidos es hacia cientos de miles y aun
decenas de millones de usuarios conectados.
Existen cuellos de botella potenciales que se debe intentar evitar en los sistemas distribuidos de
gran escala:
Componentes centralizados:
o Ej.: un solo servidor de correo para todos los usuarios.
Tablas centralizadas:
o Ej.: un único directorio telefónico en línea.
Algoritmos centralizados:
o Ej.: realización de un ruteo con base en la información completa.
Se deben utilizar algoritmos descentralizados con las siguientes características:
Ninguna máquina tiene la información completa acerca del estado del sistema.
Las máquinas toman decisiones solo en base a la información disponible de manera local.
El fallo de una máquina no arruina el algoritmo.
No existe una hipótesis implícita de la existencia de un reloj global.(ver imagen 6)
Pagina 30
Sistemas Distribuidos
1.7 COMPONENTES DE LOS SISTEMAS DISTRIBUIDOS
El desarrollo de un sistema distribuido complejo requiere el uso de las siguientes funciones y
servicios:
– Servicios de comunicación.
– Sistemas de ficheros y nombrado distribuido.
– Servicios de sincronización y coordinación.
– Memoria compartida distribuida.
– Gestión de procesos.
– Servicio de seguridad.
Estas funcionalidades se plasman en elementos concretos del sistema: componente
Servicios de Comunicación.
• Modelos de interacción:
– Cliente/servidor: (2-niveles, 3-niveles o n-niveles)
– Peer-to-peer: Equilibrio de roles.
– Intermediarios: Proxy, Dispacher, Caches,...
– Unicast vs Multicast
– Fiabilidad.
– Síncronos vs Asíncronos
– Tecnologías de comunicación:
– Paso de mensajes: Berkeley sockets.
– Llamada a procedimientos remotos: RPC.
Pagina 31
Sistemas Distribuidos
– Tecnologías de objetos distribuidos: CORBA, DCOM, EJB
Código móvil: Entornos de agentes
Sistemas de Ficheros Distribuidos.
Identificación, localización y acceso a elementos del entorno distribuido.
Comprende:
– Sistemas de ficheros distribuidos (SFD): NFS, AFS.
– Servicios de nombres: DNS, COS-Naming (CORBA).
– Servicios de directorio: X.500, LDAP, JNDI.
Servicios de Sincronización y Coordinación.
Comprende los conceptos de:
– Tiempo en entornos distribuidos: Sincronización de relojes y relojes lógicos.
– Concurrencia y Paralelismo: Exclusión mutua e interbloqueos.
– Algoritmos distribuidos: Elección de líder, coordinación,...
– Transacciones: Propiedades ACID, modelos de commit/rollback.
Afecta a otros servicios:
– Nombrado e identificación.
– Seguridad y fiabilidad.
– Comunicaciones
Pagina 32
Sistemas Distribuidos
Memoria Compartida Distribuida (DSM).
Hardware:
– Memoria físicamente compartida.
– Memoria distribuida (lógicamente compartida).
– Acceso uniforme vs acceso no uniforme.
Distributed Shared Memory:
– Basada en páginas.
– Basada en variables compartidas.
– Basada en objetos.
Gestión de Procesos
– Taxonomía de los procesos:
– Niveles de granularidad.
– Congelación de procesos (persistencia).
– Migración de procesos (estado/código).
Servicio de Seguridad
Tipología de los ataques:
– Privacidad y confidencialidad.
– Autenticación (spoofing).
– Denegación de servicio. (ver imagen 7)
Pagina 33
Sistemas Distribuidos
Capítulo 2: Recursos
De Los Sistemas
Distribuidos
Pagina 34
Sistemas Distribuidos
2.1 COMUNICACIÓN EN LOS SISTEMAS DISTRIBUIDOS
La diferencia más importante entre un sistema distribuido y un sistema de un único procesador
es la comunicación entre procesos.
En un sistema de un solo procesador la comunicación supone implícitamente la existencia de
la memoria compartida:
Ej.: problema de los productores y los consumidores, donde un proceso escribe en un buffer
compartido y otro proceso lee de él.
En un sistema distribuido no existe la memoria compartida y por ello toda la naturaleza de la
comunicación entre procesos debe replantearse.
Los procesos, para comunicarse, deben apegarse a reglas conocidas como protocolos.
Para los sistemas distribuidos en un área amplia, estos protocolos toman frecuentemente la
forma de varias capas y cada capa tiene sus propias metas y reglas.
Los mensajes se intercambian de diversas formas, existiendo muchas opciones de diseño al
respecto; una importante opción es la “llamada a un procedimiento remoto”. También es
importante considerar las posibilidades de comunicación entre grupos de procesos, no solo entre
dos procesos.
Pagina 35
Sistemas Distribuidos
2.1.1 PROTOCOLOS CON CAPAS
Debido a la ausencia de memoria compartida, toda la comunicación en los sistemas distribuidos
se basa en la transferencia de mensajes.
Cuando el proceso “A” quiere comunicarse con el proceso “B”:
Construye un mensaje en su propio espacio de direcciones.
Ejecuta una llamada al sistema para que el S. O. busque el mensaje y lo envíe a través de la
red hacia “B”.
Para evitar el caos, “A” y “B” deben coincidir en el significado de los bits que se envíen.
Los puntos de acuerdo necesarios incluyen lo siguiente:
¿Cuántos voltios hay que utilizar para un bit “0” y cuántos para un bit “1”?.
¿Cómo sabe el receptor cuál es el último bit del mensaje?
¿Cómo puede detectar si un mensaje ha sido dañado o perdido, y qué debe hacer si lo
descubre?
¿Qué longitud tienen los números, cadenas y otros elementos de datos y cuál es la forma en
que están representados?
La ISO (Organización Internacional de Estándares) desarrolló un modelo de referencia que
Identifica en forma clara los distintos niveles.
Estandariza los nombres de los niveles.
Señala cuál nivel debe realizar cuál trabajo.
Pagina 36
Sistemas Distribuidos
Este modelo se denomina “modelo de referencia para interconexión de sistemas abiertos” (ISO
OSI o modelo OSI) (ver imagen 8).
El “modelo OSI” está diseñado para permitir la comunicación de los sistemas abiertos:
Son aquellos preparados para comunicarse con cualquier otro sistema abierto mediante reglas
estándar:
o Establecen el formato, contenido y significado de los mensajes recibidos y enviados.
o Constituyen los protocolos, que son acuerdos en la forma en que debe desarrollarse la
comunicación.
El “modelo OSI” distingue entre dos tipos generales de protocolos:
Orientados hacia las conexiones:
o Antes de intercambiar los datos, el emisor y el receptor:
Establecen en forma explícita una conexión.
Probablemente negocien el protocolo a utilizar.
Al finalizar, deben terminar la conexión.
El teléfono es un sistema de comunicación orientado hacia la conexión.
Sin conexión:
o No es necesaria una configuración de antemano.
o El emisor transmite el primer mensaje cuando está listo.
o El depósito de una carta en un buzón es una comunicación sin conexión.
Pagina 37
Sistemas Distribuidos
Cada capa proporciona una interfaz con la otra capa por encima de ella; la interfaz consiste de
un conjunto de operaciones para definir el servicio que la capa está preparada para ofrecer a sus
usuarios.
El protocolo de la capa “n” utiliza la información de la capa “n”.
Cada protocolo de capa se puede cambiar independientemente de los demás:
Esto es de fundamental importancia.
Confiere gran flexibilidad.
La colección de protocolos utilizados en un sistema particular se llama una “suite de
protocolo” o “pila de protocolo”.
2.1.2 REDES CON MODO DE TRANSFERENCIA
Transmisión Asíncrona
Cada carácter se trata de manera independiente para fines de sincronización de reloj y de
carácter y el receptor se resincroniza al principio de cada carácter recibido. Cuando los datos que
se van a transmitir se generan a intervalos aleatorios, cuando el usuario se comunica con una
computadora, la tasa de transmisión al teclear es indeterminada, con intervalos de tiempo
aleatorio y posiblemente largos entre cada digitación sucesiva. Esto significa que la señal de la
línea de transmisión estará en el estado inactivo durante largos intervalos de tiempo entre
caracteres.
Pagina 38
Sistemas Distribuidos
Cada carácter o byte transmitido debe encapsularse entre un bit de inicio y uno o más bits de
paro adicionales. Como se puede apreciar en la siguiente figura el bit de inicio y el bit de paro
tiene diferente polaridad para que el receptor sepa en donde inicia y donde termina cada
carácter. (ver imagen 9)
ATM.
Tres letras - ATM - se repiten cada vez más en estos días en los ambientes Informáticos y de
Telecomunicaciones. La tecnología llamada Asynchronous Transfer Mode (ATM) Modo de
Transferencia Asíncrona es el corazón de los servicios digitales integrados que ofrecerán las
nuevas redes digitales de servicios integrados de Banda Ancha (B-ISDN), para muchos ya no
hay cuestionamientos; el llamado tráfico del "Cyber espacio", con su voluminoso y tumultuoso
crecimiento, impone a los operadores de redes públicas y privadas una voraz demanda de anchos
de banda mayores y flexibles con soluciones robustas.
El protocolo ATM consiste de tres niveles o capas básicas (Ver figura 10).
La primera capa llamada capa física (Physical Layer):
Define las interfaces físicas con los medios de transmisión y el protocolo de trama para la red
ATM es responsable de la correcta transmisión y recepción de los bits en el medio físico
apropiado. A diferencia de muchas tecnologías LAN como Ethernet, que especifica ciertos
medios de transmisión, (10 base T, 10 base 5, etc.) ATM es independiente del transporte físico.
Las celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network),
SDH (Synchronous Digital Hierarchy), T3/E3, TI/EI o aún en modems de 9600 bps. Hay dos
Pagina 39
Sistemas Distribuidos
subcapas en la capa física que separan el medio físico de transmisión y la extracción de los
datos:
La segunda capa es la capa ATM.
Ello define la estructura de la celda y cómo las celdas fluyen sobre las conexiones lógicas en
una red ATM, esta capa es independiente del servicio. El formato de una celda ATM es muy
simple. Consiste de 5 bytes de cabecera y 48 bytes para información.
Las celdas son transmitidas serialmente y se propagan en estricta secuencia numérica a través de
la red. El tamaño de la celda ha sido escogido como un compromiso entre una larga celda, que
es muy eficiente para transmitir largas tramas de datos y longitudes de celdas cortas que
minimizan el retardo de procesamiento de extremo a extremo, que son buenas para voz, vídeo y
protocolos sensibles al retardo.
La capa de adaptación de ATM.
La tercera capa es la ATM Adaptation Layer (AAL). La AAL juega un rol clave en el manejo de
múltiples tipos de tráfico para usar la red ATM, y es dependiente del servicio. Especificamente,
su trabajo es adaptar los servicios dados por la capa ATM a aquellos servicios que son
requeridos por las capas más altas, tales como emulación de circuitos, (circuit emulation), vídeo,
audio, frame relay, etc. La AAL recibe los datos de varias fuentes o aplicaciones y las convierte
en los segmentos de 48 bytes.
Pagina 40
Sistemas Distribuidos
La capa de Adaptación de ATM yace entre el ATM layer y las capas más altas que usan el
servicio ATM. Su propósito principal es resolver cualquier disparidad entre un servicio
requerido por el usuario y atender los servicios disponibles del ATM layer. La capa de
adaptación introduce la información en paquetes ATM y controla los errores de la transmisión.
2.1.3 EL MODELO CLIENTE SERVIDOR
El “modelo de la OSI” es una solución elegante y realmente aplicable en muchos casos, pero
tiene un problema:
La existencia de los encabezados genera un “costo” adicional de transmisión.
Cada envío de un mensaje genera:
o Proceso en media docena de capas.
o Preparación y agregado de encabezados en el camino hacia “abajo”.
o Eliminación y examen de encabezados en el camino hacia “arriba”.
Con enlaces del orden de decenas (o centenas) de miles de bits / segundo y cpu poderosas:
La carga de procesamiento de los protocolos no es significativa.
El factor limitante es la capacidad de las líneas.
Ej.: redes de área extendida (WAN).
Con enlaces del orden de millones de bits / segundo y computadoras personales:
La carga de procesamiento de los protocolos sí es frecuentemente significativa.
El factor limitante no es la capacidad de las líneas.
Pagina 41
Sistemas Distribuidos
Ej.: redes de área local (LAN).
La mayoría de los sistemas distribuidos basados en LAN no utilizan los protocolos de capas
completos, sí utilizan un subconjunto de toda una pila de protocolos.
El “modelo OSI” no dice nada acerca de la forma de estructurar al sistema distribuido.
El “modelo cliente - servidor” tiene como idea fundamental la estructuración del S. O. como:
Un grupo de procesos en cooperación, llamados servidores, que ofrecen servicios a los
usuarios.
Un grupo de procesos usuarios llamados clientes. (ver imagen 11)
El “modelo cliente - servidor” se basa en un “protocolo solicitud / respuesta”:
Es sencillo y sin conexión.
No es complejo y orientado a la conexión como OSI o TCP / IP.
El cliente envía un mensaje de solicitud al servidor pidiendo cierto servicio.
El servidor:
o Ejecuta el requerimiento.
o Regresa los datos solicitados o un código de error si no pudo ejecutarlo correctamente.
No se tiene que establecer una conexión sino hasta que ésta se utilice.
La pila del protocolo es más corta y por lo tanto más eficiente.
Si todas las máquinas fuesen idénticas solo se necesitarían tres niveles de protocolos.(ver
imagen 12 e imagen 13)
Pagina 42
Sistemas Distribuidos
Implantación del Modelo C – S.
Las principales opciones de diseño analizadas se resumen en:
Direccionamiento:
o Número de máquina.
o Direcciones ralas de procesos.
o Búsqueda de nombres en ASCII por medio del servidor.
Bloqueo:
o Primitivas con bloqueo.
o Sin bloqueo, con copia al núcleo.
o Sin bloqueo, con interrupciones.
Almacenamiento en buffers:
o No usar el almacenamiento en buffers, descartar los mensajes inesperados.
o Sin almacenamiento en buffers, mantenimiento temporal de los mensajes inesperados.
o Buzones.
Confiabilidad:
o No confiable.
o Solicitud - reconocimiento - respuesta - reconocimiento.
o Solicitud - respuesta - reconocimiento.
Existen 3 4 = 81 combinaciones, pero no todas son igual de buenas.
En el caso de mensajes compuestos por varios paquetes, el reconocimiento puede ser:
Por paquete individual:
Pagina 43
Sistemas Distribuidos
o Ante la pérdida de un paquete, solo retransmite ése paquete.
o Requiere más paquetes en la red.
Por mensaje completo:
o La recuperación es compleja ante la pérdida de un paquete.
o Requiere menos paquetes en la red.
Otro aspecto interesante de la implementación es el protocolo subyacente utilizado en la
comunicación c - s.
Los principales tipos de paquetes son los siguientes:
Req:
o Solicitud.
o De cliente a servidor.
o El cliente desea servicio.
Rep:
o Respuesta.
o De servidor a cliente.
o Respuesta del servidor al cliente.
Ack:
o Reconocimiento.
o De cualquiera de ellos a algún otro.
o El paquete anterior que ha llegado.
Aya:
o ¿Estás vivo?
Pagina 44
Sistemas Distribuidos
o De cliente a servidor.
o Verifica si el servidor se ha descompuesto.
Iaa:
o Estoy vivo.
o De servidor a cliente.
o El servidor no se ha descompuesto.
Ta:
o Intenta de nuevo.
o De servidor a clientes.
o El servidor no tiene espacio.
Au:
o Dirección desconocida.
o De servidor a cliente.
o Ningún proceso utiliza esta dirección.
Algunos ejemplos de intercambio de paquetes para la comunicación cliente – servidor. (ver
imagen 14)
2.1.4 LLAMADA DE UN PROCEDIMIENTO REMOTO
La Llamada a Procedimiento Remoto (RPC) es un protocolo que permite a un programa de
ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las
comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el
momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones,
estando éstas encapsuladas dentro de las RPC.
Pagina 45
Sistemas Distribuidos
Las RPC son muy utilizadas dentro de la comunicación cliente-servidor. Siendo el cliente el que
inicia el proceso solicitando al servidor que ejecute cierto procedimiento o función y enviando
éste de vuelta el resultado de dicha operación al cliente.
Hay distintos tipos de RPC, muchos de ellos estandarizados como pueden ser el RPC de Sun
denominado ONC RPC (RFC 1057), el RPC de OSF denominado DCE/RPC y el Modelo de
Objetos de Componentes Distribuidos de Microsoft DCOM, aunque ninguno de estos es
compatible entre sí. La mayoría de ellos utilizan un lenguaje de descripción de interfaz (IDL)
que define los métodos exportados por el servidor.
Hoy en día se está utilizando el XML como lenguaje para definir el IDL y el HTTP como
protocolo de red, dando lugar a lo que se conoce como servicios web. Ejemplos de éstos pueden
ser SOAP o XML-RPC.(ver imagen 15)
TIPOS DE SEMÁNTICA
Semántica tal-vez
Procedimiento remoto puede ejecutarse una vez o ninguna vez.
El cliente puede recibir una respuesta o ninguna.
Funcionamiento
1. El cliente envía una petición y se queda a la espera un tiempo determinado.
2. Si no llega la respuesta dentro del tiempo de espera, continúa su ejecución.
3. El cliente no tiene realimentación en caso de fallo (no sabe que pasó).
Pagina 46
Sistemas Distribuidos
Sólo admisible en aplicaciones donde se tolere la pérdida de peticiones y la recepción de
respuestas con retraso (fuera de orden).
Semántica al-menos-una-vez
Procedimiento remoto se ejecuta una o más veces.
El cliente puede recibir una o más respuestas.
Funcionamiento
1. El cliente envía una petición y queda a la espera un tiempo.
2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
3. El servidor no filtra peticiones duplicadas (el procedimiento remoto puede ejecutarse
repetidas veces).
4. El cliente puede recibir varias respuestas.
Sólo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles). Nota:
Una operación es idempotente si se puede ejecutar varias veces resultando el mismo efecto que
si se hubiera ejecutado sólo una. En ocasiones una operación no idempotente puede
implementarse como una secuencia de operaciones idempotentes. Admisible en aplicaciones
donde se tolere que se puedan repetir invocaciones sin afectar a su funcionamiento.
Semántica como-máximo-una-vez
El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse ninguna.
El cliente recibe una respuesta o una indicación de que no se ha ejecutado el procedimiento
remoto.
Pagina 47
Sistemas Distribuidos
Funcionamiento
1. El cliente envía la petición y queda a la espera un tiempo.
2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
3. El servidor filtra las peticiones duplicadas y guarda historial con las respuestas enviadas
(servidor con memoria). El procedimiento remoto sólo se ejecuta una vez.
4. El cliente sólo recibe una respuesta si la petición llegó y se ejecutó el procedimiento, si no
recibe informe del error.
Areas de Problemas en RPC.
La RPC mediante el modelo C - S se utiliza ampliamente como base de los S. O. distribuidos
Lo ideal es que la RPC sea transparente:
El programador no debe poder decir si los procedimientos de biblioteca
son locales o remotos.
El programador debe poder escribir procedimientos sin importar si serán ejecutados en forma
local o remota.
La introducción de RPC en un sistema que se ejecutaba antes en una única cpu no debe ir
acompañada de una serie de reglas que:
o Prohiban construcciones antes válidas.
o Exijan construcciones que antes eran opcionales.
La mayoría de los S. O. distribuidos no cumplen totalmente con estos criterios
de transparencia.
Pagina 48
Sistemas Distribuidos
2.2 SINCRONIZACIÓN EN LOS SISTEMAS DISTRIBUIDOS
Además de la comunicación, es fundamental la forma en que los procesos
Cooperan.
Se sincronizan entre sí.
Ejemplos:
Forma de implantar las regiones críticas.
Forma de asignar recursos en un sistema distribuido.
Los problemas relativos a las regiones críticas, exclusión mutua y la sincronización:
Generalmente se resuelven en sistemas de una sola cpu con métodos como los semáforos y
los monitores:
o Se basan en la memoria compartida.
o No son aplicables a sistemas distribuidos.
Otro problema de gran importancia es el tiempo y la forma de medirlo, ya que juega un
papel fundamental en algunos modelos de sincronización.
2.2.1 SINCRONIZACIÓN DE RELOJES
Generalmente los algoritmos distribuidos tienen las siguientes propiedades
La información relevante se distribuye entre varias máquinas.
Los procesos toman las decisiones solo con base en la información disponible en forma local.
Pagina 49
Sistemas Distribuidos
Debe evitarse un único punto de fallo en el sistema.
No existe un reloj común o alguna otra fuente precisa del tiempo global.
Los primeros tres puntos indican que es inaceptable reunir toda la información en un solo lugar
para su procesamiento, pero lograr la sincronización sin centralización requiere hacer las
cosas distintas al caso de los sistemas operativos tradicionales.
El último punto también es crucial:
En un sistema centralizado el tiempo no es ambiguo.
En un sistema distribuido no es trivial poner de acuerdo a todas las máquinas en la hora.
Se requiere un acuerdo global en el tiempo, pues la falta de sincronización en los relojes
puede ser drástica en procesos dependientes del tiempo.
La pregunta es si es posible sincronizar todos los relojes en un sistema distribuido.
Relojes Lógicos.
Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj
Es un cronómetro consistente en un cristal de cuarzo de precisión sometido a una tensión
eléctrica que:
Oscila con una frecuencia bien definida que depende de:
o Al forma en que se corte el cristal.
o El tipo de cristal.
o La magnitud de la tensión.
Pagina 50
Sistemas Distribuidos
A cada cristal se le asocian dos registros:
o Registro contador.
o Registro mantenedor.
Cada oscilación del cristal decrementa en “1” al contador.
Cuando el contador llega a “0”:
o Se genera una interrupción.
o El contador se vuelve a cargar mediante el registro mantenedor.
Se puede programar un cronómetro para que genere una interrupción “x” veces por segundo.
Cada interrupción se denomina marca de reloj.
Lamport utiliza la relación “ocurre antes de”:
o Si “c” sale en “60” debe llegar en “61” o en un tiempo posterior.
o Cada mensaje acarrea el tiempo de envío, de acuerdo con el reloj del emisor.
o Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se
envió el mensaje:
El receptor adelanta su reloj para que tenga una unidad más que el tiempo de envío.(ver
imagen 16)
Relojes Físicos.
El algoritmo de Lamport proporciona un orden de eventos sin ambigüedades, pero
Los valores de tiempo asignados a los eventos no tienen por qué ser cercanos a los tiempos
reales en los que ocurren.
En ciertos sistemas (ej.: sistemas de tiempo real ), es importante la hora real del reloj:
Pagina 51
Sistemas Distribuidos
o Se precisan relojes físicos externos (más de uno).
o Se deben sincronizar:
Con los relojes del mundo real.
Algoritmos Para la Sincronización de Relojes.
Si una máquina tiene un receptor de UTC, todas las máquinas deben sincronizarse con ella.
Si ninguna máquina tiene un receptor de UTC:
Cada máquina lleva el registro de su propio tiempo.
Se debe mantener el tiempo de todas las máquinas tan cercano como sea posible.
Se supone que cada máquina tiene un cronómetro que provoca una interrupción “h” veces por
segundo.
Cuando el cronómetro se detiene, el manejador de interrupciones añade “1” a un reloj en
software.
El reloj en software mantiene un registro del número de marcas (interrupciones) a partir de
cierta fecha acordada antes; al valor de este reloj se lo llama “C”.
Cuando el tiempo UTC es “t”, el valor del reloj en la máquina “p” es “Cp(t)”:
Lo ideal sería que “Cp(t)” = “t” para toda “p” y todo “t”:
o “dC/dt” debería ser “1”.
Lo real es que los cronómetros no realizan interrupciones exactamente “h” veces por
segundo:
Pagina 52
Sistemas Distribuidos
o Poseen un error relativo de aproximadamente 10-5 .
o El fabricante especifica una constante “ r ” llamada tasa máxima de alejamiento que acota el
error.
o El cronómetro funciona dentro de su especificación si existe una constante “ r ” y se cumple:
1 - r £dC / dt £ 1 + r.
Si dos relojes se alejan de UTC en la dirección opuesta:
En un instante Dt luego de la sincronización podrían estar tan alejados como: 2 rDt.
Para garantizar que no difieran más de d:
o Se deben volver a sincronizar (en software) al menos cada d / 2 r segundos.(ver imagen 17)
2.2.2 EXCLUSIÓN MUTUA
Cuando un proceso debe leer o actualizar ciertas estructuras de datos compartidas:
Primero ingresa a una región crítica para lograr la exclusión mutua y garantizar que ningún
otro proceso utilizará las estructuras de datos al mismo tiempo.
En sistemas monoprocesadores las regiones críticas se protegen con semáforos, monitores y
similares.
En sistemas distribuidos la cuestión es más compleja.
Un Algoritmo Centralizado
La forma más directa de lograr la exclusión mutua en un sistema distribuido es simular a la
forma en que se lleva a cabo en un sistema monoprocesador.
Pagina 53
Sistemas Distribuidos
Se elige un proceso coordinador.
Cuando un proceso desea ingresar a una región crítica:
Envía un mensaje de solicitud al coordinador:
o Indicando la región crítica.
o Solicitando permiso de acceso.
Si ningún otro proceso está en ese momento en esa región crítica:
o El coordinador envía una respuesta otorgando el permiso.
Cuando llega la respuesta el proceso solicitante entra a la región crítica.
La limitante es que el coordinador puede ser un cuello de botella y puede fallar y bloquear a los
procesos que esperan una respuesta de habilitación de acceso.
Un Algoritmo Distribuido
El objetivo es no tener un único punto de fallo (el coordinador central).
Un ej. es el algoritmo de Lamport mejorado por Ricart y Agrawala.
Se requiere un orden total de todos los eventos en el sistema para saber cuál ocurrió primero.
Cuando un proceso desea entrar a una región crítica:
Construye un mensaje con el nombre de la región crítica, su número de proceso y la hora
actual.
Envía el mensaje a todos los demás procesos y de manera conceptual a él mismo.
Se supone que cada mensaje tiene un reconocimiento.
Pagina 54
Sistemas Distribuidos
Otro problema es que:
Se utilizará una primitiva de comunicación en grupo o,
Cada proceso debe mantener la lista de miembros del grupo, incluyendo los procesos que
ingresan, los que salen y los que fallan.
Se complica para gran número de procesos.
Un importante problema adicional es que:
Todos los procesos participan en todas las decisiones referentes a las entradas en las regiones
críticas.
Se sobrecarga el sistema.
Una mejora consiste en permitir que un proceso entre a una región crítica con el permiso de una
mayoría simple de los demás procesos (en vez de todos):
Luego de que un proceso otorgó el permiso a otro para entrar a una región crítica, no puede
otorgar el mismo permiso a otro proceso hasta que el primero libere su permiso.
Un Algoritmo de Anillo de Fichas (Token Ring)
Los procesos se organizan por software formando un anillo lógico asignándose a cada proceso
una posición en el anillo.
Cada proceso sabe cuál es el siguiente luego de él.
Al inicializar el anillo se le da al proceso “0” una ficha (token) que circula en todo el anillo, que
se transfiere del proceso “k” al “k + 1” en mensajes puntuales.
Pagina 55
Sistemas Distribuidos
Cuando un proceso obtiene la ficha de su vecino verifica si intenta entrar a una región crítica:
En caso positivo:
o El proceso entra a la región crítica, hace el proceso necesario y sale de ella.
o Después de salir pasa la ficha a lo largo del anillo:
No se puede entrar a una segunda región crítica con la misma ficha (token o permiso).
En caso negativo:
o La vuelve a pasar. (ver imagen 18)
2.2.3 ALGORITMOS DE ELECCIÓN
Son los algoritmos para la elección de un proceso coordinador, iniciador, secuenciador, etc.
El objetivo de un algoritmo de elección es garantizar que iniciada una elección ésta concluya
con el acuerdo de todos los procesos con respecto a la identidad del nuevo coordinador.
El Algoritmo del Grandulón o de García-Molina.
Un proceso “P” inicia una elección cuando observa que el coordinador ya no responde a las
solicitudes.
“P” realiza una elección de la siguiente manera:
Envía un mensaje elección a los demás procesos con un número mayor.
Si nadie responde asume que gana la elección y se convierte en el nuevo coordinador.
Si un proceso con un número mayor responde, toma el control y el trabajo de “P” termina.
Pagina 56
Sistemas Distribuidos
Un proceso puede recibir en cualquier momento un mensaje elección de otros procesos con un
número menor:
Envía de regreso un mensaje o.k. al emisor para indicar que está vivo y que tomará el control.
Realiza una elección salvo que ya esté haciendo alguna.
En cierto momento todos los procesos han declinado ante uno de ellos, que será el nuevo
coordinador, que envía un mensaje coordinador a todos los procesos para anunciarlo.
Un Algoritmo de Anillo.
Se supone que los procesos tienen un orden físico o lógico, es decir que cada proceso conoce a
su sucesor.
Cuando algún proceso observa que el coordinador no funciona:
Construye un mensaje elección con su propio número de proceso.
Envía el mensaje a su sucesor.
Concluida la ronda de información el mensaje coordinador se elimina y continúan los
procesos.(ver imagen 19)
2.2.4 EL MODELO DE TRANSACCIÓN
Supondremos que:
El sistema consta de varios procesos independientes que pueden fallar aleatoriamente.
El software subyacente maneja transparentemente los errores de comunicación.
Pagina 57
Sistemas Distribuidos
Almacenamiento Estable
Se puede implantar con una pareja de discos comunes.
Cada bloque de la unidad 2 es una copia exacta (espejo) del bloque correspondiente en la unidad
Cuando se actualiza un bloque:
Primero se actualiza y verifica el bloque de la unidad 1.
Luego se actualiza y verifica el bloque de la unidad 2.
Si el sistema falla luego de actualizar la unidad 1 y antes de actualizar la unidad 2:
Luego de la recuperación se pueden comparar ambos discos bloque por bloque:
o Se puede actualizar la unidad 2 en función de la 1.
Si se detecta el deterioro espontáneo de un bloque, se lo regenera partiendo del bloque
correspondiente en la otra unidad.
Un esquema de este tipo es adecuado para las aplicaciones que requieren de un alto grado de
tolerancia de fallos, por ej. las transacciones atómicas.
Propiedades de las Transacciones
Las propiedades fundamentales son:
Serializacion:
o Las transacciones concurrentes no interfieren entre sí.
Atomicidad:
Pagina 58
Sistemas Distribuidos
o Para el mundo exterior, la transacción ocurre de manera indivisible.
Permanencia:
o Una vez comprometida una transacción, los cambios son permanentes.
2.2.5 BLOQUEOS EN SISTEMAS DISTRIBUIDOS
Son peores que los bloqueos en sistemas monoprocesador
Son más difíciles de evitar, prevenir, detectar y solucionar.
Toda la información relevante está dispersa en muchas máquinas.
Son especialmente críticos en sistemas de bases de datos distribuidos.
Las estrategias usuales para el manejo de los bloqueos son:
Algoritmo del avestruz:
o Ignorar el problema.
Detección:
o Permitir que ocurran los bloqueos, detectarlos e intentar recuperarse de ellos.
Prevención:
o Hacer que los bloqueos sean imposibles desde el punto de vista estructural.
Evitarlos:
o Evitar los bloqueos mediante la asignación cuidadosa de los recursos.
El algoritmo del avestruz merece las mismas consideraciones que en el caso de mono-
procesador.
Pagina 59
Sistemas Distribuidos
Detección Distribuida de Bloqueos
Cuando se detecta un bloqueo en un S. O. convencional se resuelve eliminando uno o más
procesos.
Cuando se detecta un bloqueo en un sistema basado en transacciones atómicas se
resuelve abortando una o más transacciones:
El sistema restaura el estado que tenía antes de iniciar la transacción.
La transacción puede volver a comenzar.
Las consecuencias de la eliminación de un proceso son mucho menos severas si se utilizan
las transacciones que en caso de que no se utilicen.
Detección Centralizada de Bloqueos
Cada máquina mantiene la gráfica de recursos de sus propios procesos y recursos.
Un coordinador central mantiene la gráfica de recursos de todo el sistema, que es la unión de
todas las gráficas individuales.
Cuando el coordinador detecta un ciclo elimina uno de los procesos para romper el bloqueo.
La información de control se debe transmitir explícitamente, existiendo las siguientes variantes:
Cada máquina informa cada actualización al coordinador.
Pagina 60
Sistemas Distribuidos
Cada máquina informa periódicamente las modificaciones desde la última actualización.
El coordinador requiere la información cuando la necesita.
Detección Distribuida de Bloqueos
Un algoritmo típico es el de Chandy-Misra-Haas.
Los procesos pueden solicitar varios recursos (por ejemplo cerraduras) al mismo tiempo, en vez
de uno cada vez.
Se permiten las solicitudes simultáneas de varios procesos:
Un proceso puede esperar a uno o más recursos simultáneamente.
Los recursos que espera un proceso pueden ser locales o remotos (de otra máquina).
Si el proceso “0” se bloquea debido al proceso “1”:
Se genera un mensaje de exploración que se envía al proceso (o procesos) que detienen los
recursos necesarios.
El mensaje consta de tres números:
o El proceso recién bloqueado, el proceso que envía el mensaje y el proceso al cual se envía.
Al llegar el mensaje el receptor verifica si él mismo espera a algunos procesos, en cuyo caso:
o El mensaje se actualiza:
Se conserva el primer campo.
Prevención Distribuida de Bloqueos
Pagina 61
Sistemas Distribuidos
La prevención consiste en el diseño cuidadoso del sistema para que los bloqueos sean
imposibles estructuralmente.
Entre las distintas técnicas se incluye:
Permitir a los procesos que solo conserven un recurso a la vez.
Exigir a los procesos que soliciten todos sus recursos desde un principio.
Hacer que todos los procesos liberen todos sus recursos cuando soliciten uno nuevo.
Probablemente conservan más recursos. (ver imagen 20)
2.3 PROCESOS Y PROCESADORES EN SISTEMAS DISTRIBUIDOS
2.3.1 HILOS
Muchos S. O. distribuidos soportan múltiples hilos de control dentro de un proceso que:
Comparten un único espacio de direcciones.
Se ejecutan quasi - paralelamente como si fueran procesos independientes.
Ej.: servidor de archivos que debe bloquearse ocasionalmente en espera de acceso al disco:
Si tiene varios hilos de control podría ejecutar un segundo hilo mientras el primero espera:
o El resultado sería mejor rendimiento y desempeño.
o No se logra esto con procesos servidores independientes puesto que deben compartir un
buffer caché común y deben estar en el mismo espacio de direcciones.
Pagina 62
Sistemas Distribuidos
En muchos sentidos los hilos son como mini procesos:
Los distintos hilos de un proceso comparten un espacio de direcciones, el conjunto de archivos
abiertos, los procesos hijos, cronómetros, señales, etc.
Los hilos pueden tener distintos estados: en ejecución, bloqueado, listo, terminado.
Uso de Hilos
Los hilos permiten la combinación del paralelismo con la ejecución secuencial y el bloqueo de
las llamadas al sistema
Consideramos el ejemplo del servidor de archivos con sus posibles organizaciones para muchos
hilos de ejecución.
Iniciamos con el modelo servidor / trabajador:
Un hilo, el servidor, lee las solicitudes de trabajo en el buzón del sistema.
Elige a un hilo trabajador inactivo (bloqueado) y le envía la solicitud, despertándolo.
El hilo trabajador verifica si puede satisfacer la solicitud por medio del bloque caché
compartido, al que tienen acceso todos los hilos.
Si no envía un mensaje al disco para obtener el bloque necesario y se duerme esperando el fin
de la operación.
Se llama:
o Al planificador y se inicializa otro hilo, que tal vez sea el servidor, para pedir más trabajo; o.
o A otro trabajador listo para realizar un trabajo.
Pagina 63
Sistemas Distribuidos
Los hilos ganan un desempeño considerable pero cada uno de ellos se programa en forma
secuencial.
Aspectos del Diseño de un Paquete de Hilos
Un conjunto de primitivas relacionadas con los hilos (ej.: llamadas a biblioteca) disponibles para
los usuarios se llama un “paquete de hilos”.
Respecto del manejo de los hilos se tienen hilos estáticos e hilos dinámicos.
En un diseño estático:
Se elige el número de hilos al escribir el programa o durante su compilación.
Cada uno de ellos tiene asociada una pila fija.
Se logra simplicidad pero también inflexibilidad.
En un diseño dinámico:
Se permite la creación y destrucción de los hilos durante la ejecución.
La llamada para la creación de hilos determina:
o El programa principal del hilo.
o Un tamaño de pila.
o Una prioridad de planificación, etc.
La llamada generalmente regresa un identificador de hilo
Un proceso:
o Se inicia con un solo hilo.
o Puede crear el número necesario de hilos.
Pagina 64
Sistemas Distribuidos
Implantación de un Paquete de Hilos
Un paquete de hilos se puede implantar en el espacio:
Del usuario.
Del núcleo.
Implantación del paquete de hilos en el espacio del usuario:
El núcleo no sabe de su existencia.
El núcleo maneja procesos con un único hilo.
No requiere soporte de hilos por parte del S. O.
Los hilos se ejecutan en un sistema de tiempo de ejecución:
o Es un grupo de procedimientos que manejan los hilos.
Cuando un hilo ejecuta una llamada al sistema o cualquier acción que pueda provocar su
suspensión:
o Llama a un procedimiento del sistema de tiempo de ejecución.
o El procedimiento verifica si hay que suspender al hilo, en cuyo caso:
Almacena los registros del hilo en una tabla.
Busca un hilo no bloqueado para ejecutarlo.
Vuelve a cargar los registros de la máquina con los valores resguardados del nuevo hilo.
Las principales ventajas son:
Pagina 65
Sistemas Distribuidos
o El intercambio de hilos es más rápido que si se utilizaran los señalamientos al núcleo.
o Cada proceso puede tener su propio algoritmo adaptado de planificación de hilos.
o Tienen una mejor escalabilidad para un número muy grande de hilos, ya que no afectan al
núcleo con tablas y bloques de control (pila). Un problema fundamental de los paquetes de hilos
a nivel usuario es el de las llamadas al sistema con bloqueo.(ver imagen 21)
2.3.2 MODELOS DE SISTEMAS
En un sistema distribuido, con varios procesadores, un aspecto fundamental del diseño
es cómo se los utiliza.
Los procesadores distribuidos se pueden organizar de varias formas:
Modelo de estación de trabajo.
Modelo de la pila de procesadores.
Modelo híbrido.
El Modelo de Estación de Trabajo
El sistema consta de estaciones de trabajo (PC) dispersas conectadas entre sí mediante una red
de área local (LAN).
Pueden contar o no con disco rígido en cada una de ellas.
Los usuarios tienen:
Una cantidad fija de poder de cómputo exclusiva.
Pagina 66
Sistemas Distribuidos
Un alto grado de autonomía para asignar los recursos de su estación de trabajo.
Uso de los discos en las estaciones de trabajo:
Sin disco:
o Bajo costo, fácil mantenimiento del hardware y del software, simetría y flexibilidad.
o Gran uso de la red, los servidores de archivos se pueden convertir en cuellos de botella.
Disco para paginación y archivos de tipo borrador:
o Reduce la carga de la red respecto del caso anterior.
o Alto costo debido al gran número de discos necesarios.
Disco para paginación, archivos de tipo borrador y archivos binarios (ejecutables):
o Reduce aún más la carga sobre la red.
Uso de Estaciones de Trabajo Inactivas
La idea consiste en ordenar remotamente la ejecución de procesos en estaciones de trabajo
inactivas.
Los aspectos clave son:
¿Cómo encontrar una estación de trabajo inactiva?.
¿Cómo lograr que un proceso remoto se ejecute de forma transparente?.
¿Qué ocurre si regresa el poseedor de la máquina?.
Generalmente se considera que una estación de trabajo está “inactiva” cuando se dan ambas
condiciones:
Pagina 67
Sistemas Distribuidos
Nadie toca el ratón o el teclado durante varios minutos.
No se ejecuta algún proceso iniciado por el usuario.
Los algoritmos para localizar las estaciones de trabajo inactivas se pueden dividir en dos
categorías:
Controlados por el servidor.
Controlados por el cliente.
Algoritmos controlados por el servidor:
Cuando una estación de trabajo está inactiva:
o Se convierte en un servidor potencial.
o Anuncia su disponibilidad:
Proporciona su nombre, dirección en la red y propiedades:
Grabándolos en un archivo, o.
Transmitiéndolos a las otras estaciones.
El Modelo de la Pila de Procesadores.
Se dispone de un conjunto de cpu que se pueden asignar dinámicamente a los usuarios según la
demanda. Los usuarios no disponen de estaciones de trabajo sino de terminales gráficas de alto
rendimiento. No existe el concepto de propiedad de los procesadores, los que pertenecen a todos
y se utilizan compartidamente.
El principal argumento para la centralización del poder de cómputo como una pila de
procesadores proviene de la teoría de colas:
Pagina 68
Sistemas Distribuidos
Llamamos “l” a la tasa de entradas totales de solicitudes por segundo de todos los usuarios
combinados.
Llamamos “m” a la tasa de procesamiento de solicitudes por parte del servidor.
Para una operación estable debe darse que “m > l”:
o Se pueden permitir pequeños lapsos de tiempo en los que la tasa de entrada exceda a la de
servicio.
Llamamos “T” al promedio de tiempo entre la emisión de una solicitud y la obtención de una
respuesta completa:
o T = 1 / ( m - l ).
o Cuando “ l ” tiende a “0”, “T” no tiende a “0”.
2.3.3 MODELOS DE ASIGNACIÓN
Generalmente se utilizan las siguientes hipótesis.
Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo
en la velocidad.
Cada procesador se puede comunicar con los demás.
Las estrategias de asignación de procesadores se dividen en:
No migratorias:
o Una vez colocado un proceso en una máquina permanece ahí hasta que termina.
Migratorias:
Pagina 69
Sistemas Distribuidos
o Un proceso se puede trasladar aunque haya iniciado su ejecución.
o Permiten un mejor balance de la carga pero son más complejas.
Los algoritmos de asignación intentan optimizar algo:
Uso de las cpu:
o Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
o Minimizar el tiempo de inactividad de las cpu.
Tiempo promedio de respuesta:
o Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
Tasa de respuesta:
o Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta
máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
Aspectos del Diseño de Algoritmos de Asignación de Procesadores
Los principales aspectos son los siguientes:
Algoritmos deterministas vs. heurísticos.
Algoritmos centralizados vs. distribuidos.
Algoritmos óptimos vs. subóptimos.
Algoritmos locales vs. globales.
Algoritmos iniciados por el emisor vs. iniciados por el receptor.
Pagina 70
Sistemas Distribuidos
Los algoritmos deterministas son adecuados cuando se sabe anticipadamente todo acerca del
comportamiento de los procesos, pero esto generalmente no se da, aunque puede haber en
ciertos casos aproximaciones estadísticas.
Los algoritmos heurísticos son adecuados cuando la carga es impredecible.
Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor
decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante
su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los subóptimos, además, en la
mayoría de los sistemas reales se buscan soluciones subóptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en
otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde
enviarlo:
Necesita información de la carga en todas partes, obteniéndola de:
o Un emisor sobrecargado que busca una máquina inactiva.
o Un receptor desocupado que busca trabajo.(ver imagen 22)
Pagina 71
Sistemas Distribuidos
2.3.4 PLANIFICACIÓN EN SISTEMAS DISTRIBUIDOS
Generalmente cada procesador hace su planificación local (si tiene varios procesos en ejecución)
independientemente de lo que hacen los otros procesadores.
La planificación independiente no es eficiente cuando se ejecutan en distintos procesadores
un grupo de procesos:
Relacionados entre sí.
Con una gran interacción entre los procesos.
Se necesita una forma de garantizar que los procesos con comunicación frecuente se ejecuten de
manera simultánea.
En muchos casos un grupo de procesos relacionados entre sí iniciarán juntos.
La comunicación dentro de los grupos debe prevalecer sobre la comunicación entre los grupos.
Se debe disponer de un número de procesadores suficiente para soportar al grupo de mayor
tamaño.
Pagina 72
Sistemas Distribuidos
Cada procesador se multiprograma con “n” espacios para los procesos (multiprogramación de
nivel “n”).
El algoritmo de Ousterhout utiliza el concepto de coplanificación:
Toma en cuenta los patrones de comunicación entre los procesos durante la planificación.
Debe garantizar que todos los miembros del grupo se ejecuten al mismo tiempo.
Se emplea una matriz conceptual donde:
o Las filas son espacios de tiempo.
o Las columnas son las tablas de procesos de los procesadores.
2.3.5 TOLERANCIA A FALLOS
El objetivo de diseñar y construir sistemas distribuidos tolerantes a fallos es garantizar que el
sistema continúe funcionando de manera correcta como un todo, incluso en presencia de fallas.
Se dice que un sistema falla cuando no cumple su especificación. Como las computadoras y los
sistemas distribuidos se utilizan cada vez m[as en misiones donde la seguridad es críticas, la
necesidad de soportar las fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados
para proveer un servicio específico. Un desperfecto de un sistema ocurre cuando el sistema no
desempeña estos servicios de manera especificada. Un estado erróneo en un sistema es un estado
en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las
Pagina 73
Sistemas Distribuidos
causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o
en la implementación), problemas de fabricación, deterioro por el uso u otros problemas
externos (como condiciones ambientales adversas, interferencia electromagnética, entradas
imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere
de los valores esperados.
Es necesario que el sistema sea capaz de recuperarse de las fallas, entonces necesitamos
deshacernos del estado de error del sistema.
Clasificación De Las Fallas.
Falla De Procesos.
Aquí, la ejecución arroja un resultado incorrecto, los procesos provocan que el sistema se desvíe
de las especificaciones y el proceso puede suspender su progreso. Por ejemplo interbloqueos,
tiempo expirado, violación de protección, error en la entrada provista por el usuario, violaciones
de consistencia.
Falla Del Sistema.
Es cuando el procesador falla en la ejecución. Esto es causado por errores de software y
problemas de hardware, como por ejemplo errores de CPU, falla en la memoria principal, falla
en el bus, falla de energía, etc.
Recuperación De Errores.
Ya dijimos que un error es una parte del estado del sistema que es distinto a los valores
esperados, así, la recuperación de una falla es un proceso que involucra la recuperación de
estados erróneos a un estado libre de error.
Pagina 74
Sistemas Distribuidos
Hay dos enfoques para la recuperación de un estado de error a un estado libre de error.
- Si la naturaleza del error y los daños causados pueden ser completamente calculados, entonces
es posible remover esos errores del estado del proceso (o sistema) y habilitar el movimiento
hacia adelante del proceso a un estado libre de error. Esta técnica es conocida
como recuperación hacia adelante.
Elementos de las estrategias tolerantes a fallas.
Al momento de diseñar un sistema tolerante a fallas se puede hacer desde dos puntos de vista:
- Puede ocultar la falla
- Puede corregir la falla y seguir funcionando
En el primero, al ocurrir una falla, el sistema continua con sus funciones específicas. En el
segundo, el sistema puede o no ejecutar funciones específicas, sin embargo, puede seguir
acciones para recuperación.
Estrategia Tolerante A Fallas.
Redundancia. Con este enfoque, el sistema puede emplear varios procesos, muchos
componentes de hardware, muchas copias de datos, etc. Cada uno con independencia en el modo
de la falla, esto quiere decir que si un componente falla no afecta a los demás componentes.
Se utilizan dos protocolos en las técnicas para sistemas tolerantes a fallas:
Protocolo de compromiso: se utiliza para sistemas que hasta cierto punto pueden corregir las
fallas
Protocolo de elección: es utilizado para sistemas que ocultan las fallas.
Pagina 75
Sistemas Distribuidos
Efectos De Fallas Más Comunes.
Un proceso muere
Cuando un proceso muere, es importante que los recursos asignados al proceso sean
recuperados, de otra manera pueden estar perdidos permanentemente.
La máquina falla
Todos los procesos ejecutándose en la máquina se mueren. La diferencia con el caso anterior es
como detectar la falla.
La red falla (ver imagen 23)
2.3.6 SISTEMAS DISTRIBUIDOS EN TIEMPO REAL
La naturaleza de los sistemas distribuidos de tiempo real (SDTR) requiere técnicas de análisis,
diseño y prueba específicas que permitan representar las situaciones típicas de estos sistemas.
Un sistema distribuido de tiempo real debe interactuar con el mundo real, en puntos físicamente
distantes, en periodos de tiempo que vienen determinados por el contexto o las restricciones de
la especificación (en muchos casos a partir de una activación asincrónica).
La evolución tecnológica en el tratamiento de señales (locales o remotas) y en los sistemas de
comunicaciones ha impulsado enormemente esta área temática, sobre todo en los aspectos de
planificación y desarrollo de software para Sistemas
Distribuidos de Tiempo Real [HAT88] [LAP93] [SHU92].
Pagina 76
Sistemas Distribuidos
Como cualquier sistema basado en computadora, un SDTR debe integrar software, hardware,
personas, bases de datos, no solo para cumplir con los requisitos funcionales del sistema, sino
también con los requerimientos de rendimiento.
Las dificultades principales del desarrollo de software para sistemas de tiempo real son:
• Controlar hardware en forma directa
• Procesar mensajes que arriban en forma asincrónica, con diferentes velocidades y diferentes
prioridades
• Detectar y controlar condiciones de falla. Prever diferentes grados de recuperación del sistema.
• Manejar colas y buffers de almacenamiento y mensajes.
• Modelizar condiciones de concurrencia en un conjunto apropiado de procesos.
• Asignar procesos lógicos a procesadores fisicos (si se dispone de ellos).
• Manejar las comunicaciones inter-procesos e inter-procesadores.
• Proteger datos compartidos por procesos concurrentes.
• Organizar (schedule) y despachar la atención de procesos.
• Manejar las restricciones de tiempo y performance.
• Relacionarse con un reloj de tiempo real y evitar desfasajes de procesadores - tiempos.
• Testear y poner a punto un sistema que normalmente está distribuido en diferentes
procesadores.
• Elaborar herramientas de software que permitan simular o emular dispositivos o eventos de
hardware no disponibles en el desarrollo.
• Reducir y estructurar los requerimientos.
• Seleccionar la estructura de hardware adecuada.
Mecanismos de especificación y verificación de restricciones de tiempo.
Pagina 77
Sistemas Distribuidos
Existen numerosos enfoques que tienden a la especificación y verificación de restricciones de
tiempo entre los que se cuentan los lenguajes de simulación, las aproximaciones axiomáticas y
las Redes de Petri.
En particular las Redes de Petri son un elemento útil para modelar sistemas en los que existen
dependencias secuenciales dinámicas y consideraciones de procesamiento concurrente, por las
siguientes características:
• Son inherentemente paralelas y soportan eventos asincrónicos.
• Permiten una representación explícita de las dependencias causales y de las interdependencias
entre procesos.
• Permiten la descripción de un sistema en diferentes niveles de abstracción
• Favorecen la verificación y en particular la detección de situaciones críticas (por ejemplo
deadlocks).
• Soportan extensiones para manipular temporizaciones aleatorias y/o determinísticas.
Para poder utilizarlas en modelizaciones de Sistemas de Tiempo Real se incorporan restricciones
de tiempo y se han extendido las clases de arcos del grafo de Petri para simular condiciones de
funcionamiento. De esta manera pueden modelarse fenómenos tales como tiempo entre llegadas
de eventos externos, tiempos de reacción, duración de actividades, tiempos de time out, acciones
periódicas, etc. Actualmente se está investigando la incorporación de las Redes de Petri
extendidas a ambientes CASE orientados a tratamiento de sistemas de tiempo real y asimismo se
están estudiando variantes (en particular Queued Petri Nets y la incorporación de atributos a los
tokens) para analizar mejor fenómenos de espera y de manejo de datos distinguidos dentro del
sistema.
Pagina 78
Sistemas Distribuidos
Sistemas DTR:
Los sistemas de tiempo real (STR) y los sistemas distribuidos de tiempo Real (SDTR) son
sistemas de tiempo crítico, es decir, se trata de aplicaciones para las cuales el tiempo en que se
produce la respuesta es un requerimiento esencial.
Por lo general, un STR o SDTR incluye un conjunto de dispositivos independientes (hardware y
software) que operan a diferentes velocidades. Deben satisfacer requerimientos de performance.
Comparando con un sistema tradicional, se debe tener especial control sobre la utilización de
recursos, mejora en los tiempos de respuesta y manejo de distintas prioridades.
Existen algunas diferencias importantes entre un sistema de software tradicional y uno de
tiempo real:
• Control de dispositivos externos.
• Procesamiento de mensajes que pueden llegar en intervalos irregulares.
• Detección y control de condiciones de falla.
• Modelización de condiciones concurrentes.
• A locación y control de procesos concurrentes.
• Manejo las comunicaciones entre procesos.
• Protección de datos compartidos.
• Manejo de requerimientos de tiempos y performance.
• Testeo y debug de procesos concurrentes.
• Diseño de simuladores del hardware que no se encuentra disponible durante la fase de pruebas.
Pagina 79
Sistemas Distribuidos
• Selección del hardware adecuado para soportar el diseño del software.
• Distribución de tareas.
Se espera que un STR se ejecute en forma continua, automática y segura, teniendo un impacto
en los costos de desarrollo y la seguridad.
En particular nos interesan las aplicaciones industriales, caracterizadas por la distribución y el
control del tiempo.
Claramente un STR tiene que emplear herramientas de desarrollo y modelado diferentes a las
utilizadas en el desarrollo de software tradicional que es la temática correspondiente a los temas
del Subproyectos 2 del III-LIDI en relación a la Ingeniería de Software de Sistemas Distribuidos
y Sistemas Distribuidos en Tiempo Real.(ver imagen 24)
2.4 SISTEMAS DE ARCHIVOS
Sistemas Distribuidos De Archivos.
Muchos aspectos son similares a los de los sistemas convencionales centralizados.
En un sistema distribuido es importante distinguir entre los conceptos de servicio de archivos y
el servidor de archivos.
El servicio de archivos:
Es la especificación de los servicios que el sistema de archivos ofrece a sus clientes.
Describe las primitivas disponibles, los parámetros que utilizan y las acciones que llevan a
cabo.
Pagina 80
Sistemas Distribuidos
Define precisamente el servicio con que pueden contar los clientes sin decir nada respecto de
su implantación.
El despachador (servidor) de archivos:
Es un proceso que se ejecuta en alguna máquina y ayuda con la implantación del servicio de
archivos.
Puede haber uno o varios en un sistema.
Los clientes no deben ser conscientes de la forma de implantar el sistema de archivos:
o No precisan conocer el número de servidores de archivos, su posición o función.
o Deberían ver al sistema distribuido de archivos como un sistema de archivos normal de
uniprocesador.
Generalmente un servidor de archivos es un proceso del usuario (a veces del núcleo) que se
ejecuta en una máquina:
Un sistema puede contener varios servidores de archivos, cada uno con un servicio distinto:
o Ej.: un sistema con un servidor de archivos en “UNIX” y otro en “DOS”.
o Cada proceso usuario utilizaría el servidor apropiado.
2.4.1 DISEÑO DE LOS SISTEMAS DISTRIBUIDOS DE ARCHIVOS
Los componentes de un sistema distribuido de archivos son:
El verdadero servicio de archivos:
Pagina 81
Sistemas Distribuidos
o Realiza operaciones en los archivos individuales: lectura, escritura, adición.
El servicio de directorios:
o Crea y maneja directorios, añade y elimina archivos de los directorios, etc.
La Interfaz del Servicio de Archivos.
La protección en los sistemas distribuidos utiliza las mismas técnicas de los sistemas con
uniprocesador:
Posibilidades:
o Cada usuario tiene un permiso o posibilidad para cada objeto al que tiene acceso:
Determina los tipos de accesos permitidos.
Listas para control de acceso:
o Se asocia a cada archivo una lista implícita o explícita de:
Los usuarios que pueden tener acceso al archivo.
Los tipos de acceso permitidos a cada uno de ellos.
Los servicios de archivos se pueden clasificar en dos tipos:
Modelo carga / descarga:
o Las principales operaciones son la lectura de un archivo y la escritura en un archivo.
o La lectura transfiere todo un archivo de uno de los servidores de archivos al cliente
solicitante.
o La escritura transfiere en sentido contrario.
o Los archivos se pueden almacenar en memoria o en un disco local.
Modelo de acceso remoto:
Pagina 82
Sistemas Distribuidos
o El sistema de archivos se ejecuta con todas las funciones en los servidores y no en los
clientes.(ver imagen 25)
2.4.2 IMPLANTACIÓN DE UN SISTEMA DISTRIBUIDO DE ARCHIVOS
Uso de Archivos
Antes de implantar un sistema de archivos resulta de interés analizar los “patrones de uso” de
dichos archivos.
Para determinar los patrones de uso es necesario tomar mediciones que pueden ser:
Estáticas:
o Representan una toma instantánea del sistema en un momento dado.
o – Comprenden la distribución de tamaño de los archivos, la distribución de tipo de archivos,
la cantidad de espacio que ocupan los archivos de varios tamaños y tipos, etc.
Dinámicas:
o Registran en una bitácora todas las operaciones que modifican el sistema de archivos.
o Comprenden información sobre la frecuencia relativa de varias operaciones, el número de
archivos abiertos en un momento dado, la cantidad de archivos compartidos, etc.
Las principales propiedades observadas son:
La mayoría de los archivos son pequeños.
La lectura es más común que la escritura.
Pagina 83
Sistemas Distribuidos
La mayoría de los accesos es secuencial.
La mayoría de los archivos son de corta vida.
Es poco usual compartir archivos.
Los procesos promedio utilizan pocos archivos.
Distintas clases de archivos poseen propiedades distintas.
Estructura del Sistema
En ciertos sistemas no existe distinción entre un cliente y un servidor:
Todas las máquinas ejecutan el mismo software básico.
Una máquina que desee dar servicio de archivos lo puede hacer:
o Debe exportar los nombres de los directorios seleccionados, para que otras máquinas los
puedan acceder.
En otros sistemas el servidor de archivos y el de directorios son solo programas del usuario, y se
puede configurar un sistema para que ejecute o no el software de cliente o servidor en la misma
máquina.
Los clientes y servidores también podrían ser máquinas totalmente distintas en términos de
hardware o de software.
Ocultamiento
En un sistema cliente - servidor, cada uno con su memoria principal y un disco, existen
cuatro lugares donde se pueden almacenar los archivos o partes de ellos:
Pagina 84
Sistemas Distribuidos
El disco del servidor.
La memoria principal del servidor.
El disco del cliente (si existe).
La memoria principal del cliente.
Si los archivos se almacenan en el disco del servidor:
Disponen de abundante espacio.
Serían accesibles a todos los clientes.
No habrá problemas de consistencia al existir solo una copia de cada archivo.
Puede haber problemas de desempeño:
o Antes de que un cliente pueda leer un archivo se lo debe transferir:
Del disco del servidor a la memoria principal del servidor.
De la memoria principal del servidor a la memoria principal del cliente, a través de la red.
Se puede mejorar el desempeño ocultando (conservando) los archivos de más reciente uso en
la memoria principal del servidor:
o Un cliente que lea un archivo ya presente en el caché del servidor elimina la transferencia del
disco.
o Se necesita un algoritmo para determinar los archivos o partes de archivos que deben
permanecer en el caché.
Consistencia del Caché
El ocultamiento por parte del cliente introduce inconsistencia en el sistema.
Pagina 85
Sistemas Distribuidos
Si dos clientes leen un mismo archivo en forma simultánea y después lo modifican, aparecen
algunos problemas:
Cuando un tercer proceso lee el archivo del servidor obtendrá la versión original y no alguna
de las nuevas:
o Se puede evitar mediante la “semántica de sesión”:
o No es aplicable cuando se requiere la “semántica de UNIX”.
Cuando dos archivos se escriben de nuevo al servidor, el último de ellos se escribirá sobre el
otro.
Una solución a la inconsistencia del caché es el algoritmo de escritura a través del caché:
Cuando se modifica una entrada del caché (archivo o bloque), el nuevo valor:
o Se mantiene dentro de él.
o Se envía de inmediato al servidor.
Los principales problemas de la escritura a través del caché son los siguientes:
Posible suministro de valores obsoletos:
o Un proceso cliente en la máquina “A” lee un archivo “f ” y mantiene a “f ” en su caché.
o Un cliente en la máquina “B” lee el mismo archivo, lo modifica y lo escribe en el servidor.
o Otro proceso cliente inicia en la máquina “A” abriendo y leyendo “f ”, que se toma del caché.
o El valor de “f” es obsoleto.
Réplica.
Pagina 86
Sistemas Distribuidos
Frecuentemente los sistemas distribuidos de archivos proporcionan la réplica de archivos como
un servicio:
Existen varias copias de algunos archivos.
Cada copia está en un servidor de archivos independiente.
Las principales razones para la réplica son:
Aumentar la confiabilidad al disponer de respaldos independientes de cada archivo.
Permitir el acceso a archivos aun cuando falle un servidor de archivos.
Repartir la carga de trabajo entre varios servidores.
Protocolos de Actualización.
El principal problema es asegurar la sincronización de las distintas copias.
Un algoritmo posible es el de réplica de la copia primaria:
Uno de los servidores se denomina como primario.
Los demás servidores son secundarios.
La actualización se envía al servidor primario:
o Realiza los cambios localmente.
o Envía comandos a los servidores secundarios para ordenarles la misma modificación.
Las lecturas se pueden hacer de cualquier copia.
La desventaja es que si falla el primario no se pueden llevar a cabo las actualizaciones.(ver
imagen 26)
Pagina 87
Sistemas Distribuidos
2.4.3 TENDENCIAS EN LOS SISTEMAS DISTRIBUIDOS DE ARCHIVOS
Es probable que los cambios en el hardware tengan un efecto muy importante en los futuros
sistemas distribuidos de archivos.
También es probable el impacto del cambio en las expectativas del usuario.
Consideraciones Respecto del Hardware
El abaratamiento de la memoria principal permitirá disponer de servidores con memorias cada
vez mayores:
Se podría alojar directamente en memoria el sistema de archivos logrando mayor sencillez y
desempeño.
Se debería prever la obtención de respaldos continuos o por incrementos ante la posibilidad
del corte en el suministro eléctrico.
El respaldo podría hacerse en discos ópticos regrabables que tengan una asociación uno a uno
con la memoria:
o El byte “k” de la memoria correspondería al byte “k” del disco.
La disponibilidad de redes de fibra óptica de alta velocidad permitiría esquemas tales como:
Un servidor de archivos en la memoria principal del servidor con respaldo en el disco óptico.
Eliminación del disco del servidor y del caché del cliente.
Se simplificaría significativamente el software.
Pagina 88
Sistemas Distribuidos
La posible construcción de interfaces de red especializadas que permitan resolver por hardware
problemas difíciles de soportar por software:
Cada interfaz de red tendría un mapa de bits con un bit por cada archivo en el caché.
Se podrían habilitar cerraduras por archivo.
Para modificar un archivo un procesador activaría el bit correspondiente en la interfaz.
Escalabilidad.
Una tendencia definida en los sistemas distribuidos es hacia los sistemas cada vez más grandes.
Los sistemas distribuidos de archivos que operan bien para cientos de máquinas podrían fallar en
algún aspecto trabajando con miles o decenas de miles de máquinas.
Generalmente los algoritmos centralizados no se escalan bien ya que el servidor centralizado
podría convertirse en un cuello de botella; por ello se podría separar el sistema en unidades más
pequeñas relativamente independientes entre sí.
Las transmisiones también son un área problemática:
Si cada máquina transmite una vez por segundo:
o Con “n” máquinas habría “n” transmisiones y “n 2” interrupciones por segundo.
o Si “n” crece esto se puede convertir en un problema.
Pagina 89
Sistemas Distribuidos
2.5 MEMORIA DISTRIBUIDA
Es un tipo de implementación hardware y software, en la que cada nodo de un cluster tiene
acceso a una amplia memoria compartida que se añade a la memoria limitada privada, no
compartida, propia de cada nodo.
Los sistemas de software DSM pueden ser implementados bajo un sistema operativo (SO), o
como una biblioteca de programación. Los sistemas de software DSM implementados en el SO
pueden concebirse como extensiones de la arquitectura de memoria virtual subyacente. Estos
sistemas son transparentes al desarrollador, lo que significa que la memoria distribuida
subyacente está completamente oculta para los usuarios. En contraste, los sistemas de software
DSM implementados en una biblioteca no son transparentes y los desarrolladores tienen que
programarlos separadamente. Sin embargo, estos últimos sistemas ofrecen mejores
características de portabilidad en la implementación de sistemas DSM.
Los sistemas de software DSM también tienen capacidad para organizar la región de memoria
compartida de manera flexible. Las aproximaciones basadas en páginas organizan la memoria
compartida en páginas de tamaño fijo. Por su parte, las aproximaciones basadas en objetos
organizan la región como un espacio abstracto en el que se pueden almacenar objetos
compartidos de tamaño variable.(ver imagen 27)
2.5.1 MEMORIA COMPARTIDA
Pagina 90
Sistemas Distribuidos
En informática, la memoria compartida es aquel tipo de memoria que puede ser accedida por
múltiples programas, ya sea para comunicarse entre ellos o para evitar copias redundantes. La
memoria compartida es un modo eficaz de pasar datos entre aplicaciones. Dependiendo del
contexto, los programas pueden ejecutarse en un mismo procesador o en procesadores
separados. La memoria usada entre dos hilos de ejecución dentro de un mismo programa se
conoce también como memoria compartida.
Software:
En el software, memoria compartida puede referirse a:
Un método de comunicación entre procesos, por ejemplo: el intercambio de datos entre dos
programas ejecutándose al mismo tiempo. Uno de los procesos creará un área en RAM a la que
el otro pueda acceder, o
Un método para conservar espacio en la memoria, usando mapeos virtuales o bien soporte
explícito del programa en cuestión, dirigiendo los accesos a una sola instancia de datos que
normalmente serían duplicados. Comúnmente destinado para bibliotecas de enlace
dinámico dinámicas y el espacio de usuario (XIP, "execute in place”).
Dado que ambos procesos pueden acceder al área de memoria compartida como memoria de
trabajo regular, esta es una forma de comunicación veloz (al contrario de otros mecanismos de
comunicación entre procesos como tuberías nombradas, socket de dominio UNIX o CORBA.
Pagina 91
Sistemas Distribuidos
En cambio, este sistema es menos potente, si, por ejemplo, los procesos que se comunican deben
ejecutarse en la misma máquina (en cuanto a otros métodos de comunicación entre procesos,
solo los sockets del Internet Domain (no los sockets de UNIX), pueden usar una red de
computadoras). Esto se debe a que se requiere mayor atención y cuidado si los procesos que
comparten memoria corren en CPUs separadas y la arquitectura subyacente no
soporta coherencia de caché.
Hardware:
Se refiere a la situación dónde cada nodo (computadora) comparte sus tablas de páginas,
su memoria virtual y todo lo que habita en la memoria RAM con otros nodos en la misma red de
interconexión. Un ejemplo de memoria compartida es DSM.
En otras palabras, una computadora convencional tiene una memoria RAM y un CPU (entre
otras partes de hardware), las cuales están comunicadas de manera local. Cuando se habla
de multicomputadoras es necesario entenderlas como un conjunto de máquinas convencionales
trabajando coordinadamente con el objetivo de compartir recursos de software y hardware para
tareas muy específicas, como por ejemplo la investigación. El hecho de que cada CPU sólo
pueda acceder a la RAM local no beneficia mucho y agrega complejidad a los programadores de
Multicomputadoras, con la compartición de memoria se mitiga esta complejidad ya que todas las
CPUs pueden acceder a la misma RAM.
Soporte en otras plataformas:
En Windows se puede usar la función CreateSharedMemory para crear memoria
compartida o CreateFileMapping y MapViewOfFile como alternativa. Algunas bibliotecas
Pagina 92
Sistemas Distribuidos
para C++ proporcionan acceso portable y orientado a objetos de la memoria compartida. Por
ejemplo, Boost incluye Boost.Interprocess y Qt proporciona QSharedMemory .
Además de C/C++ hay otros lenguajes con soporte nativo para memoria compartida. Por
ejemplo PHP provee un API para crear memoria compartida similar a las funciones POSIX.(ver
imagen 28)
2.5.2 MODELOS DE CONSISTENCIA
Un modelo de consistencia es esencialmente un contrato entre procesos y el almacenamiento de
datos. Es decir: si los procesos acuerdan obedecer ciertas reglas, el almacenamiento promete
trabajar correctamente. Normalmente un proceso que realiza una operación de lectura espera que
esa operación devuelva un valor que refleje el resultado de la última operación de escritura sobre
el dato.
En Informática, en un sistema distribuido, tales como una memoria compartida distribuida o
almacenes de datos distribuido, tales como una base de datos, sistema de archivos, caché web o
sistemas de replicación optimista, hay una serie de posibles modelos de consistencia de datos. Se
dice que un sistema soporta un determinado modelo, si las operaciones en memoria siguen
normas específicas. La consistencia de los datos es definida entre el programador y el sistema,
que garantiza que si el programador sigue las reglas, la memoria será consistente y el resultado
de las operaciones de memoria será predecible.
Los lenguajes de alto nivel, tales como C, C++ y Java, respetan parcialmente este modelo
traduciendo operaciones de memoria en operaciones de bajo nivel para preservar la memoria
Pagina 93
Sistemas Distribuidos
semántica. Para mantener el modelo, los compiladores pueden reordenar algunas instrucciones
de memoria, y las llamadas a las bibliotecas como pthread_mutex_lock (), encapsular la
sincronización necesaria.
Los ejemplos incluyen:
Linealizable (también conocido como el estricta o consistencia atómica)
Consistencia secuencial
Consistencia de causalidad
Consistencia liberada
Consistencia eventual
Consistencia delta
Consistencia PRAM (también conocido como consistencia FIFO)
Consistencia débil
Consistencia vector campo
La duplicidad de los bloques compartidos aumenta el rendimiento, pero produce un problema de
consistencia entre las diferentes copias de la página en caso de una escritura. Si con cada
escritura es necesario actualizar todas las copias, el envío de las páginas por la red provoca que
el tiempo de espera aumente demasiado, convirtiendo este método en impracticable.(ver imagen
29)
2.5.3 MEMORIA COMPARTIDA DISTRIBUIDA CON BASES DE
PÁGINAS
Pagina 94
Sistemas Distribuidos
El esquema de DSM propone un espacio de direcciones de memoria virtual que integra la
memoria de todas las computadoras del sistema, y su uso se realiza mediante paginación. Las
páginas quedan restringidas a estar necesariamente en un único nodo. Cuando un programa
intenta acceder a una posición virtual de memoria, se comprueba si esa página se encuentra de
forma local. Si no se encuentra, se provoca un fallo de página, y el sistema operativo solicita la
página al resto de nodos. El sistema funciona de forma análoga al sistema de memoria virtual
tradicional, pero en este caso los fallos de página se propagan al resto de ordenadores, hasta que
la petición llega al nodo que tiene la página virtual solicitada en su memoria local. A primera
vista este sistema parece más eficiente que el acceso a la memoria virtual en disco, pero en la
realidad ha mostrado ser un sistema demasiado lento en ciertas aplicaciones, ya que provoca un
tráfico de páginas excesivo.
Una mejora dirigida a mejorar el rendimiento sugiere dividir el espacio de direcciones en una
zona local y privada y una zona de memoria compartida, que se usará únicamente por procesos
que necesiten compartir datos. Esta abstracción se acerca a la idea de programación mediante la
declaración explícita de datos públicos y privados, y minimiza el envío de información, ya que
sólo se enviarán los datos que realmente vayan a compartirse.
Memoria comparativa distribuida en base a páginas.
Los sistemas de memoria compartida distribuida (MCD) representan la creación hibrida de dos
tipos de computación paralelos:
La memoria distribuida en sistemas multiprocesador.
Pagina 95
Sistemas Distribuidos
Los sistemas distribuidos.Ellos proveen la abstracción de memoria compartida en sistemas con
memorias distribuidas físicamente y consecuentemente combinan las mejores características de
ambos enfoques. Debido a esto, el concepto de memoria compartida distribuida es reconocido
como uno de los enfoques más atractivos para la creación de sistemas escalables, de alto
rendimiento de sistemas multiprocesador;Ventajas / Desventajas De La Memoria Distribuida
(ver imagen 30)
Implementacion De Una Memoria Distribuida.
Acceso compartido a la memoria à comunicación Inter-procesos.
Ningún procesador puede acceder directamente a la memoria de otro procesador à NORMA
(NO Remote Memory Access) Systems.
Los procesadores hacen referencia a su propia memoria local. Hay que aumentar software para
que, cuando un procesador haga referencia a una página remota, esta página sea recuperada.
El espacio de direccionamiento común es particionado en pedazos.
Cada pedazo es situado en una estación.
Cuando un procesador hace referencia a una página no local à "trap" (page fault).
2.5.4 MEMORIA COMPARTIDA DISTRIBUIDA CON VARIABLES
COMPARTIDAS
Pagina 96
Sistemas Distribuidos
Un método más estructurado que la DSM con base a páginas consiste en compartir sólo ciertas
variables y estructuras de datos necesarias para más de un proceso. Ahora el problema pasa a ser
la forma de mantener una base de datos distribuida, en potencia duplicada, consistente en las
variables compartidas.
Uno de los aspectos más importantes a tratar de estos sistemas es el de si las variables
compartidas deben o no duplicarse, y de qué manera, parcial o total. Si se duplicasen existiría
más potencial que en un sistema DSM basado en páginas, en términos de actualización, dado
que las escrituras en las variables compartidas individuales se pueden aislar. Dos de los
ejemplos más interesantes de este tipo de sistemas son el Munin y el Midway; el primero se basa
en una implantación software de la consistencia de liberación, y el segundo consiste en
compartir las estructuras de datos individuales, permitiendo que los programas multiprocesador
existentes y los nuevos se ejecuten de manera eficiente en las Multicomputadoras, con ligeros
cambios de código.
2.5.5 MEMORIA COMPARTIDA DISTRIBUIDA CON BASE DE
OBJETOS
En los MCD basados en objetos se busca el acceso a datos por medio de la encapsulación de la
información y repartida a través de la red, estos objetos serán definidos por el Programador y las
CPU´s cambiaran los estados según procedan con los accesos. Nace como respuesta a la
creciente popularización de los lenguajes orientados por objetos. Los datos se organizan y son
transportados en unidades de objetos, no unidades de páginas
Una alternativa al uso de páginas es tomar el objeto como base de la transferencia de memoria.
Aunque el control de la memoria resulta más complejo, el resultado es al mismo tiempo modular
Pagina 97
Sistemas Distribuidos
y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las
restricciones de este modelo es que todos los accesos a los objetos compartidos han de realizarse
mediante llamadas a los métodos de los objetos, con lo que no se admiten programas no
modulares y se consideran incompatibles.(ver imagen 31)
Ventajas:
Es más modular que otras técnicas.
La implementación es más flexible por que los accesos son controlados. Sincronización y
accesos se pueden integrar juntos, más fácilmente
Desventajas:
No corre en viejos programas para multiprocesadores.
Los accesos se deben hacer invocando a los accesos, lo que significa más trabajo que los
métodos de páginas compartidas.
Ejemplos: Linda y Orca
No existe una memoria lineal en bruto.
La localización y administración de los objetos es controlada por el sistema de tiempo de
ejecución.
Los objetos se pueden duplicar o no. En caso de duplicarse, hay que decidir cómo se harán
las actualizaciones.
Evitan el compartimiento falso.
El Sistema Linda
Pagina 98
Sistemas Distribuidos
El acceso a memoria se hace mediante un pequeño conjunto de primitivas que se agregan a
los lenguajes existentes.
Las ventajas son que no hay que aprender un nuevo lenguaje, es sencillo de implantar y es
portable.
Se basa en un espacio de n-adas global a todo el sistema.
¿Qué son los objetos?
Estructura de datos encapsulada definida por el programador. Se componen de datos internos
(estado) y operaciones o métodos.‡ Cumplen con la propiedad de ocultamiento dela
información, por lo que contribuyen con la modularidad.
No existe una memoria lineal en bruto.‡ La localización y administración de los objetos es
controlada por el sistema de tiempo de ejecución.‡ Los objetos se pueden duplicar o no. En caso
de duplicarse, hay que decidir cómo se harán las actualizaciones. ‡ Evitan el compartimiento
falso.
Sus principales desventajas son que no soportan programas multiprocesadores antiguos y el
costo adicional que genera el acceso indirecto a los datos.
Una alternativa al uso de páginas es tomar el objeto como base de la transferencia de memoria.
Aunque el control de la memoria resulta más complejo, el resultado es al mismo tiempo modular
y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las
restricciones de este modelo es que todos los accesos a los objetos compartidos han de realizarse
mediante llamadas a los métodos de los objetos, con lo que no se admiten programas no
modulares y se consideran incompatibles.(ver imagen 32 e imagen 33)
Pagina 99
Sistemas Distribuidos
Unidad 3:
Pagina 100
Sistemas Distribuidos
Modelos De Sistemas
Distribuidos
3.1 AMOEBA
3.1.1 INTRODUCCION A LA AMOEBA
Es un uso general del sistema operativo distribuido. Está diseñado para tomar una colección de
máquinas y hacerlos actuar en conjunto como un único sistema integrado.
Usos de Amoeba:
· Uso de redes y un sistema compartido de archivos.
Pagina 101
Sistemas Distribuidos
Administración de Memoria:
La arquitectura del sistema Amoeba está constituida principalmente de cuatro componentes:
1ero se encuentran las estaciones de trabajo (Workstations), una por usuario.
2do, está el pool de procesadores, un grupo de procesadores que se alocan de manera dinámica
de acuerdo con la necesidad.
3ero, los servidores especializados, servidores tales como: Servidores de archivos, de directorio,
de impresión, etc.
4to son lo gateways, que son utilizados para la conexión de sistemas Amoeba en distintas
ciudades o países en un solo sistema uniforme.(ver imagen 34)
Forma de Comunicación:
Uno a muchos.
Todos los receptores están garantizados para recibir todos los mensajes de grupo en el mismo
orden.
Este mecanismo simplifica problemas de programación paralela.
3.1.2 OBJETOS Y POSIBILIDADES
Pagina 102
Sistemas Distribuidos
Posibilidades.
Los objetos reciben su nombre y proteccion de manera uniforme mediante boletos especiales
llamadas posibilidades. Para crear un objeto, un cliente realiza una RPC con el servidor
apropiado, donde indica lo que desea. El servidor entonces crea el objeto y regresa una
posibilidad al cliente. En las operaciones siguientes, el cliente debe presentar la posibilidad para
identificar el objeto. Una posibilidad no es mas que un numerobinario de gran tamaño.
Cuando el cliente desea llevar a cabo una operación en un objeto, llama a un procedimiento de
resguardo, el cual construye un mensaje con la posibilidad del objeto y despues hacemos un
señalamiento al nucleo. Este extrael el campo.
Proteccion de objetos.
El algoritmo basico para la proteccion de los objetos es el siguiente. Cuando se crea un objeto, el
servidor elige un campo de verificacion al azar y lo guarda en una nueva posibilidad y dentro de
sus propias tablas. Se activan todos los bits de derechos a una nueva posibilidad y esta
posibilidad del propietario es lo que regresa al cliente. Cuando la posibilidad regresa al servidor
en una solicitud para llevar a cabo una operación, verifica el campo de verificacion.
Operación estandar .
Aunque muchas de las operaciones en los objetos dependen del tipo de los mismos existen
algunas operaciones que se aplican a la mayoria; esta se muestran en la figura. Algunas de ellas
necesitan que algunos bits esten activados, pero otros pueden ser llevadas a cabo por cualquier
persona que puede presentar un servidor con una posibilidad valida para uno de sus objetos.(ver
imagen 35)
Pagina 103
Sistemas Distribuidos
3.1.3 ADMINISTRACIÓN DE PROCESOS EN MEMORIA
Un proceso en Amoeba es básicamente un espacio de direcciones y una colección de hilos que
se ejecutan en el. Un proceso con un hilo es muy semejante a un proceso UNIX o en MS-DOS,
en términos de su comportamiento o su función. En esta sección aplicaremos el funcionamiento
de los procesos e hilos y la forma de implantarlos.
Procesos:
Es un Objeto en Amoeba. Al crear un proceso, el proceso padre obtiene una posibilidad para el
proceso hijo, al igual que con cualquier otro objeto recién creado. Mediante esta posibilidad, el
hijo se puede suspender o reiniciar o destruir. (ver imagen 36)
Hilos:
Amoeba soporta un modelo sencillo de hilos. Al iniciar un proceso, este tiene al menos un hilo.
Durante la ejecución, el proceso puede crear más hilos y los existentes pueden terminar su labor.
Asi, el número de hilos es por completo dinámico. Al crearse un nuevo hilo, los parámetros de la
llamada especifican el procedimiento por ejecutar y el tamaño de la pila.
3.1.4 ADMINISTRACION DE MEMORIA EN AMOEBA
Pagina 104
Sistemas Distribuidos
Amoeba tiene un modelo de memoria en extremo sencillo. Un proceso puede tener el número de
segmentos que desee y estoy se pueden localizar en cualquier parte del espacio de direcciones
virtuales del proceso. Los segmentos no se intercambian ni se paginan, por lo que un proceso
debe estar por completo contenido en la memoria para su ejecución. Además, aunque se utiliza
el hardware MMU, cada segmento se almacena de manera adyacente a los demás en la memoria.
Segmentos:
Los procesos disponen de varias llamadas al sistema para el manejo de los segmentos. Entre las
más importantes están las que permiten crear, destruir, leer y escribir segmentos. Al crear un
segmento, el proceso que hizo la llamada recibe a cambio una posibilidad, la cual es utilizada
para la lectura y escritura del segmento, asi como para las demás llamadas relacionadas con el
segmento.
Segmentos asociados:
Los espacios de direcciones virtuales en Amoeba se construyen a partir de los segmentos. Al
iniciar un proceso, este debe tener al menos un segmento. Sin embargo, durante su ejecución, un
proceso puede crear más segmentos y asociados con un espacio de direcciones en cualquier
dirección virtual no utilizada.
Un segmento se puede asociar con el espacio de direcciones de dos o más procesos a la vez.
Esto permite que los procesos operen en la memoria compartida. Sin embargo, por lo general es
mejor crea un proceso con varios hilos cuando se necesite la memoria compartida. La principal
Pagina 105
Sistemas Distribuidos
razón para tener varios procesos es una mejor protección, pero si los dos procesos la comparten,
lo usual es que no desee la protección.
3.1.5 COMUNICACIÓN EN AMOEBA
Amoeba soporta dos formas de comunicación: RPC mediante la transferencia puntual de
mensajes y la comunicación en grupo. En el nivel más bajo, una RPC consta de un mensaje de
solicitud seguido de un mensaje de respuesta. La comunicación en un grupo utiliza la
transmisión en hardware o multitransmision si se dispone de esta; en caso contrario, la simula de
manera transparente mediante mensajes individuales.
Llamada a procedimientos remotos (RPC)
Concepto y objetivos
Idea: Ocultar/abstraer los detalles relativos a la comunicación que son comunes a diversas
aplicaciones
Gestión de los diálogos petición-respuesta
Aplanamiento y formateo de datos (enteros, reales, cadenas, estructuras,...) [marshaling,
serializacion]
• Aplanar: organizar datos complejos en un mensaje
• Desaplanar: extraer datos complejos de un mensaje aplanado
• Gestionar: representación info. (Orden de bytes, tipos complejos, alineado en memoria),
diferencias de hardware y S.O.
Pagina 106
Sistemas Distribuidos
Gestión de la interfaz de comunicación (crear y configurar sockets, conectar, escribir, leer,...)
Aproximación: llamada a procedimientos remotos (RPC: Remote Procedure Call)
Generar automáticamente el codigo usado en esas tareas comunes
Ofrecer el entorno y los componentes de apoyo necesarios para dar soporte a esa infraestructura
Procedimiento llamante y procedimiento llamado se ejecutan en máquinas distintas
Ofrecer la ilusión de que la llamada remota parezca idéntica a una llamada local (transparencia)
Objetivo: Proporcionar un middleware que simplifique el desarrollo de aplicaciones distribuidas
Evitar que programador tenga que interactuar directamente con el interfaz de Sockets
• Abstraer (ocultar) los detalles relativos a la red
Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos locales
• Se busca ofrecer un entorno de programación lo más similar posible a un entorno no
distribuido
• El sistema RPC oculta los detalles de implementación de esas llamadas remotas
◦ implementa la llamada remota mediante un diálogo petición respuesta mensaje de petición:
identifica procedimiento llamado contiene parámetros de la llamada ¦ mensaje de respuesta:
contiene valor/es devuelto/s
◦ se encarga de enviar/recibir mensajes para comunicar ambas partes
◦ se encarga de gestionar los contenidos de esos mensajes (empaquetado y formateado de datos)
Pagina 107
Sistemas Distribuidos
Funcionamiento general
Proceso llamador (cliente):
• Proceso realiza la llamada a una función.
• Llamada empaqueta id. De función y argumentos en mensaje
• Envía mensaje a otro proceso.
• Queda a la espera del resultado.
• Al recibirlo, lo desempaqueta y retorna el valor
Proceso llamado (servidor):
• Recibe mensaje con id. De función y argumentos.
• Se invoca función en el servidor.
• Resultado de la función se empaqueta en mensaje
• Se transmite mensaje de respuesta al cliente. (ver imagen 37)
3.1.6 LOS SERVIDORES DE AMOEBA
Servidor de archivos: Los archivos son inmutables. Se crean, se leen y se eliminan, pero no
se modifican, para favorecer la réplica automática.
Servidor de directorios: Ofrece los archivos, pero el manejo de éstos se hace a través del
servidor de archivos. Mayor flexibilidad.
Pagina 108
Sistemas Distribuidos
Servidor de réplicas: Replicas retardadas. Cuando se crea algún objeto se hace una copia y
cuando tenga tiempo la actualizará. Funciona mejor con objetos inmutables como los archivos.
Servidor de ejecución.
La mayoría de los servicios de los sistemas operativos tradicionales se implantan en Amoeba
como procesos servidores.
Todos los servidores estándar de Amoeba se definen mediante un conjunto de procedimientos de
resguardo. Los resguardos más recientes se definen en AIL (Lenguaje de Interfaz de Amoeba),
aunque los más antiguos están escritos a mano en C. Los procedimientos de resguardo son
generados por el compilador AIL a partir de las definiciones de resguardo y se colocan entonces
en la biblioteca, de manera que los usuarios los puedan utilizar. De hecho, los resguardos
definen de manera precisa los servicios que proporcionan un servidor, así como sus parámetros.
El servidor de Archivos
Como todos los sistemas operativos, Amoeba tiene un sistema de archivos. Sin embargo, a
diferencia de la mayoría de los demás, la elección del sistema de archivos no está dictada por el
sistema operativo. El sistema de archivos se ejecuta como colección de procesos servidores.
El sistema de archivos estándar consta de tres servidores, el servidor de archivos, que controla
el espacio de almacenamiento de archivos; el servidor de directorio, que se encarga de los
nombres de los archivos y del manejo de los directorios; y el servidor de réplicas, el cual
controla la réplica de archivos. El sistema de archivos se ha separado en estos componentes
independientes para lograr mayor flexibilidad y hacer que cada uno de los servidores tenga una
implantación directa.
Pagina 109
Sistemas Distribuidos
Un proceso cliente puede crear un archivo mediante la llamada créate.(ver imagen 38)
El servidor de archivos mantiene una tabla de archivos con una entrada por cada uno de éstos,
similar a la tabla de nodos-i de UNIX. Toda la tabla se lee de memoria cuando se arranca el
servidor de archivos y se mantiene ahí mientas el servidor de archivos esté ejecutándose.(ver
imagen 39)
El servidor TCP/IP.
Aunque Amoeba utiliza el protocolo FLIP de manera interna para lograr un alto desempeño,
necesita hablar TCP/IP, por ejemplo para la comunicación con las terminales X, para enviar y
recibir correo de otras máquinas que no sean de tipo Amoeba, así como para ejecutar con otros
sistemas Amoeba por medio de Internet.
Para establecer una conexión, un proceso en Amoeba hace una RPC con el servidor TCP/IP
dando una dirección TCP/IP. El proceso de la llamada se bloquea hasta que se establece o niega
la conexión. En la respuesta, el servidor TCP/IP proporciona una posibilidad para el uso de la
conexión. Las RPC posteriores pueden enviar y recibir paquetes de la máquina remota sin que el
proceso Amoeba tenga conciencia del uso de TPC/IP. Este mecanismo es menos eficiente que
FLIP, pero se utiliza cuando este no está disponible
Servidor de directorios.
El servidor de directorios, como hemos visto, solo controla el mantenimiento de archivos. La
colocación de nombres y otros objetos se controlan mediante el servidor de directorios. Su
principal función consiste en proporcionar una asociación entre los nombres legibles para los
humanos (ASCII) y las posibilidades. Los procesos pueden crear uno o más directorios, cada
Pagina 110
Sistemas Distribuidos
uno de los cuales puede contener varios renglones. Cada renglón describe un objeto y contiene
tanto el objeto como su posibilidad. Se dispone de operaciones para la creación y eliminación de
directorios, adición y eliminación de reglones y búsqueda de nombres de directorios. A
diferencia de los archivos, los directorios no son inmutables. Se pueden añadir o eliminar
entradas de los directorios existentes.
Los propios directorios son objetos y están protegidos por posibilidades, al igual que los demás
objetos. Las operaciones en directorios, como la búsqueda de nombres y la adición de nuevas
entradas, son protegidas por bits en el campo de derecho, de manera usual. Las posibilidades de
los directorios se pueden almacenar en otros directorios y estructuras más generales.
Aunque el servidor de directorios se puede utilizar simplemente para almacenar parejas (nombre
del archivo, posibilidad), también puede soportar a un modelo mas general. En primer lugar, una
entrada de un directorio puede nombrar cualquier tipo de objeto descrito mediante una
posibilidad, no solo un archivo o un directorio. El servidor de directorios no sabe ni se preocupa
por el tipo de objetos que controlan las posibilidades. Las entradas de un directorio pueden
corresponder varios tipos de objetosy eston pueden estar muy dispersos en todo e mundo. No
existe el requisito de que los objetos de un directorio sean del mismo tipo o que deban ser
controlados por el mismo servidor. Cuando se busca y utiliza una posibilidad, su servidor lo
localiza ante una transmicion. . (Ver imagen 40)
Servidor de Replicas.
Los objetos por el servidor de directorios se pueden duplicar en forma automática mediante el
servidor de réplicas. Este practica lo que se llama replica retardada. Lo que esto significa es que
Pagina 111
Sistemas Distribuidos
cuando se crea un archivo o algún otro objeto, al principio solo se hace una copia. Entonces se le
puede llamar servidor de réplicas, para producirlas idénticas, cuando tenga tiempo. En vez de
recibir llamadas directas, el servidor de réplicas se mantiene en ejecución en un plano
secundario todo el tiempo, examinando partes especificas del sistema de directorio en forma
periódica. Cuando encuentra una entrada de directorio que supuestamente debe obtener n
posibilidades pero que contiene menos, se pone en contacto con los servidores correspondientes
y ordena la creación de iobjetos adicionales. Aunque el servidor de réplicas se puede utilizar
para copiar cualquier tipo de objetos, funciona mejor para el caso de objetos inmutables, como
los archivos. La ventaja es que los objetos inmutables no pueden cambiar durante el proceso de
réplica, por lo que puede trabajar son seguridad en un plano secundario, aunque un tiempo
considerable. Los objetos inmutables podrían cambiar durante el proceso de réplica agregando
mayor complejidad para evitar la inconsistencia.
Además el servidor de réplicas ejecuta los mecánicos de maduración y de recolección de basura
utilizados para el servidor de archivos y otros servidores. De manera periódica, toca cada objeto
que este bajo el control del servidor de directorios, para evitar que su tiempo expire. También
envía los mensajes age a los servidores con el fin de decrementar todos los contadores de los
objetos y recolectar la basura de aquellas cuyo contador tenga el valor cero.
El Servidor de ejecución.
Cuando el usuario escribe un comando (por ejemplo, sort) en la terminal, hay que tomar dos
decisiones:
1¿en qué tipo de arquitectura se debe ejecutar el proceso?
La primera pregunta se refiere asi el proceso se debe ejecutar en una 386, sparc, 680x0, etc
Pagina 112
Sistemas Distribuidos
2¿Qué procesador se debe elegir?
La segunda se relaciona con la elección del CPU específico y depende de la carga y
disponibilidad de memoria de los procesadores candidatos. El servidor de ejecución ayuda a
tomar decisiones.
Cada servidor de ejecución controla una o varias pilas de procesadores. Una pila de
procesadores se representa mediante un directorio llamado pooldir, el cual contiene
subdirectorios por cada una de las arquitecturas de CPU soportadas. Los subdirectorios
contienen las posibilidades para el acceso a los servidores de procesos para cada una de las
maquinas en pila. (ver imagen 41)
Servidor de arranque.
Como otro ejemplo de servidor de Amoeba, consideremos el servidor de arranque. Este se
utiliza para proporcionar cierto grado de tolerancia de fallas en Amoeba, mediante la
verificación de todos los servidores que deberían estar en ejecución y aquellos en la realidad lo
estén, además de que toma medidas correctivas en caso de que no estén trabajando. Un servidor
interesado en la sobrevivencia de las fallas se puede incluir el archivo de configuración del
servidor de arranque. Cada entrada indica la frecuencia y la forma en que el servidor de arranque
debe realizar una encuesta. Mientras el servidor responda de manera correcta, el servidor de
arranque no realiza ninguna acción posterior.
Sin embargo, si el servidor no responde después de ciertos números de intentos, el servidor de
arranque lo declara muerto. O intenta reiniciarlo. Si eso falla, entonces asigna de alguna manera
un nuevo procesador de la pila donde inicia una nueva copia. De esa forma, los servicios críticos
Pagina 113
Sistemas Distribuidos
vuelven a arrancar de manera automática si llegan a fallar. El servidor de arranque se puede
duplicar asi mismo, para protegerse de sus propias fallas.
.
3.2 CHORUS
3.2.1 Introducción a CHORUS
Chorus es un micro kernel embebido de tiempo real típicamente usado en ambientes de
aplicaciones distribuidas dedicadas de bajo costo, que necesitan un mínimo de funcionalidad y
un mínimo uso de memoria, tal como líneas de tarjetas de crédito, teléfonos portables, y
dispositivos de mano. Pero también se encuentra en otras aplicaciones embebidas como
impresoras, autómatas, etc. es un sistema operativo altamente escalable y de implementación
confiable, tanto así que se ha establecido entre los proveedores superiores de
telecomunicaciones.
Chorus OS es un sistema operativo para aplicaciones empotradas o en tiempo real, desarrollado
por la empresa Sun Microsystems. Actualmente está liberado bajo código abierto.
Es sistema operativo altamente escalable y estable, sirve para sistemas distribuidos, en red,
empotrados o en tiempo real y se ha establecido como un sistema operativo muy utilizado en
hardware para comunicaciones, desde móviles hasta switches. Pero también se encuentra en
otras aplicaciones empotradas, tales como impresoras, autómatas, etc.
Es de arquitectura basada en componentes (módulos), lo que le dota de una alta configurabilidad
y escalabilidad.
Pagina 114
Sistemas Distribuidos
Este sistema operativo pertenece a la quinta generación de los sistemas operativos.
Historia
CHORUS surgió del instituto francés INRA en 1980, como proyecto de investigación en
sistemas distribuidos desde entonces han aparecido 4 versiones numeradas del cero al 3. La idea
de tras de la versión cero era la de modelar aplicaciones distribuidas como colección de actores.
La Version cero fue escrita en Pascal UCSD interpretado y se ejecutó en una conexión de
máquinas 8086 conectadas mediante una red de anillo.
Version 1
Se centró en la investigación de los multiprocesadores. Fue escrita para el multiprocesador
francés CM90, que constaba de ocho cpu 68020 de Motorola en un bus común.
Un cpu ejecutaba UNIX; las otras 7 ejecutaban CHORUS y utilizaban el cpu de UNIX para los
servicios del sistema
Version 2 (1984/1986)
Fue una reescritura fundamental del sistema. se diseñó en C de modo que las llamadas de
sistema fuesen compatibles con UNIX en el nivel de codigo fuente, lo que significa que podía
recompilar los programas existentes en UNIX en CHORUS y ejecutarlos en él.
Version 3 .
Pagina 115
Sistemas Distribuidos
La Version 3 se inicia en 1987. Esta Version marco la transición de un sistema de investigación
aun producto comercial, ya que los diseñadores de CHORUS salieron de INRIA, y formaron una
compañía, CHORUS SYSTEMES, para seguir desarrollando y comercializando CHORUS.
Los Conceptos Principales De Memoria En Chorus Son Los Siguientes:
Región: Es un rango adyacente de direcciones virtuales. Todos lo bytes de una región tienen las
mismas características de protección (Exclusivo para lecturas. Las regiones son una propiedad
de los procesos y todos los hilos de un proceso ven las mismas regiones.
SEGMENTOS
Colección adyacente de BYTES que reciben el nombre y protección de una posibilidad. Los
archivos y las areas de intercambio son los tipos más comunes de segmentos. Los segmentos se
pueden leer o escribir en ellos utilizando las llamadas al sistema que proporcionen la
posibilidad, el desplazamiento, el número de bytes, el buffer y la dirección de transferencia del
segmento. (ver imagen 42)
3.2.2 ADMINISTRACIÓN DE PROCESOS EN CHORUS
Procesos:
Un proceso en chorus es una colección de elementos activos y pasivos que funcionan juntos para
realizar cierto cálculo. Los elementos activos son los hilos. Los elementos pasivos son un
espacio de direcciones (que contiene ciertas regiones) y una colección de puertos (para él envió
y resecciones de mensajes).
Pagina 116
Sistemas Distribuidos
Existen tres tipos de procesos que difieren en la cantidad de privilegios y confianza como se
enumera en la figura. El privilegio se refiere a la capacidad de ejecutar la E/S y otras
instrucciones. La confianza significa que se permite llamar de manera directa al núcleo.
Los procesos del núcleo son los más poderosos. Se ejecutan en modo núcleo y todos comparten
el mismo espacio .se cargan o se descargan durante la ejecución.
Cada proceso del sistema se ejecuta en un propio espacio d dirección. Los procesos del sistema
no son privilegiados (es decir se ejecutan en modo usuario) y por lo tanto no pueden ser
ejecutados de manera directa E/S. Sin embargo el núcleo confía en ellos para realizar llamadas.
Los procesos usuario no son confiables ni privilegiados. No pueden realizar E/s de manera
directa ni llamar al núcleo.
Hilos:
Cada proceso activo en chorus tiene uno o más hilos que ejecutan código. Cada hilo tiene un
propio contexto privado (es decir, su pila, contador de programa y registro), que se guarda
cuando el hilos bloque en espera de cierto evento y se restaura cuando se reasume de nuevo el
hilo.
Los hilos se comunican entre sí enviándose y recibiendo mensaje .No importa el emisor ni el
receptor o si están en máquinas diferentes.
Se distinguen los siguientes casos que no son mutuamente excluyentes.
1. ACTIVO ---El hilo es lógicamente capas de ejecutar.
Pagina 117
Sistemas Distribuidos
2. SUSPENDIDO ---El hilo se ha suspendido de manera intencional.
3. DETENIDO ---El proceso del hilo ha sido suspendido.
4. EN ESPERA ---El hilo está esperando que ocurra cierto evento.
Planificación:
La planificación del CPU se realiza mediante el uso de prioridad con base en los hilos. Cada
proceso tiene prioridad y cada hilo tiene prioridad relativa dentro de su proceso.
Como podemos lograr ver en el siguiente diagrama
Estos hilos no se separan en intervalos de tiempo
Estos hilos se separan en intervalos de tiempo
Mayor prioridad
Señalamientos, exenciones y interrupciones
El software de chorus distingue tres tipos de entradas al núcleo:
Los señalamientos: son llamados intencionales al núcleo o a un subsistema para llamar a
servicios.
Los programas causan señalamientos llamando aun procedimiento de biblioteca para una
llamada al sistema.
Las excepciones: son eventos inesperados que son causados por accidentes, como la excepción
de división entre cero, el desbordamiento de punto flotante, o un fallo de página.
Pagina 118
Sistemas Distribuidos
Las interrupciones: son causados por eventos asíncronos, como las marcas de reloj o la
terminación de una solicitud de E/S, estas no necesariamente están relacionadas con algo
realizado por el hilo activo, por lo que no es posible permitir que el proceso del hilo las maneje.
Llamadas al núcleo para la administración de procesos:
La mejor forma para ver lo que un núcleo o sistema operativo realiza es examinar su interfaz. La
llamadas a sistema que proporciona a sus usuarios. En esta sección revisaremos las llamadas
más importantes al sistema del núcleo del chorus.
Llamada Descripción
Comenzaremos con las llamadas a procesos, enumeradas en la figura ActorCreate crea un
proceso nuevo y regresa la posibilidad de ese proceso a quien Hizo la llamada. El proceso nuevo
hereda la propiedad, el identificador de protección y el puerto de excepción del proceso padre.
La llamada ActorDelete elimina un proceso .el proceso por eliminar se especifica mediante la
posibilidad trasferida como parámetro.
La llamada ActorStop congela un proceso, colocando todo sus hilos en el estado DETENIDO.
Los hilos solo se ejecutan de nuevo cuando una llamada ActorStart.
La llamada ActorPriority permite que un proceso lea la prioridad de otro proceso y
opcionalmente que le dé un valor nuevo.
ActorExcept se utiliza para obtener o modificar el puerto de excepción para quien hizo la
llamada.
Pagina 119
Sistemas Distribuidos
El siguiente grupo de llamadas al núcleo se relaciona con los hilos y se muestra en el siguiente
dibujo.
Llamada Descripción
ThreadCreate y threadDelete crean y eliminan hilos en algún proceso (no necesariamente quien
hizo la llamada). Los parámetros dethreadCreate especifican el nivel de privilegio, el estado
inicial, la prioridad, el punto de entrada y el apuntador a la pila.
ThreadSuspendythreadResume detienen y reinician los hilos en el proceso objetivo.
ThreadPriority regresa la prioridad relativa actual del hilo objetivo y opcionalmente lo configura
como valor dado como parámetro.
Nuestras últimas tres llamadas se utilizan para controlar el contexto privado de un hilo, las
llamadas threadLoad y threadStore cargan y configuran el registro del contexto actual del
software, respectivamente. Este registro apunta al contexto del hilo, incluyendo sus variables
particulares. La llamada threadContext copia de manera opcional contexto anterior del hilo a un
buffer, y opcionalmente configura el nuevo contexto de otro buffer.
Las operaciones de sincronización aparecen en la figura siguiente. Se dispone de llamas para
iniciar, adquirir y liberar mútex y semáforos. Funciona de la manera usual.
3.2.3 ADMINISTRACIÓN DE LA MEMORIA EN CHORUS
Pagina 120
Sistemas Distribuidos
Los conceptos principales detrás de la administración de memoria en Chorus son las regiones
y los segmentos.
Una región es un rango adyacente de direcciones virtuales. Todos los bytes de una región
tienen las mismas características de protección (por ejemplo, exclusivo para lectura). Las
regiones son una propiedad de los procesos y todos los hilos de un proceso ven las mismas
regiones.
Un segmento es una colección adyacente de bytes que reciben el nombre y protección de una
posibilidad. Los archivos y las áreas de intercambio son los tipos más comunes de segmentos.
Los segmentos se pueden leer o escribir en ellos utilizando llamadas al sistema que
proporcionen la posibilidad, el desplazamiento, el número de bytes, el buffer y la dirección de
transferencia del segmento.
Los segmentos asociados son paginados por lo general según la demanda Cuando un proceso
hace referencia por vez primera a un segmento recién asociado, ocurre un fallo de página y la
página del segmento correspondiente a la dirección de referencia se recupera y se reinicia la
instrucción fallida. De esta forma, se puede implantar la memoria virtual ordinaria, y, además,
un proceso puede hacer que uno o más archivos sean visibles en su espacio de direcciones
virtuales, de modo que tenga un acceso directo a ellos en vez de tener que leerlos o escribir en
ellos mediante llamadas al sistema.(ver imagen 43)
El núcleo soporta segmentos especiales de E/S para al acceso a los registros de E/S de la
máquina en máquinas con registros de dispositivos asociados con memoria. Al utilizar estos
Pagina 121
Sistemas Distribuidos
segmentos, los hilos del núcleo pueden realizar E/S leyendo o escribiendo de manera directa en
la memoria.
3.2.4 COMUNICACIÓN EN CHORUS
Chorus proporciona dos tipos de operaciones de comunicación: envío asíncrono y RPC. El
envío asíncrono permite que un hilo sólo envíe un mensaje a un puerto. No existe garantía de
que el mensaje llegue a su destino y no existe una notificación si algo sale mal.
La otra operación de comunicación es la RPC. Cuando un proceso ejecuta una operación de
RPC, se bloquea en forma automática hasta que llega la respuesta o expira el cronómetro de la
RPC, en cuyo momento se elimina el bloqueo del emisor. Se garantiza que el mensaje que
elimina el bloqueo del emisor es la respuesta a la solicitud.
Las RPC utilizan una semántica "a lo más una vez”, el sistema garantiza que una RPC
regresará un código de error en vez de intentar la ejecución de una operación más de una vez.
También es posible enviar un mensaje a un grupo de puertos. Se dispone de varias opciones,
estas opciones determinan la cantidad de mensajes que se envían y a cuáles puertos.(ver imagen
44)
Conclusión.
Chorus es un poderoso sistema operativo enfocado a trabajar en maquinas que requieren de una
respuesta en tiempo real para realizar determinados trabajos distribuidos; las aplicaciones de
Chorus son variadas y de mucha importancia, van desde hacer funcionar maquinaria de línea de
Pagina 122
Sistemas Distribuidos
producción, impresoras, equipos de mano, etc. Chorus es un ejemplo de un sistema operativo
extremadamente optimizado y seguro. Provee características sin comparación con otros sistemas
operativos, convirtiéndolo en la elección segura en el mercado de los sistemas embebidos
distribuidos.
Pagina 123
Sistemas Distribuidos
Unidad 4: Proyectos
De Modelamiento
4.1 METODOLOGÍA PARA LA REALIZACIÓN DE PROYECTOS DE
TECNOLOGÍA BASADOS EN SISTEMAS DISTRIBUIDOS
Pagina 124
Sistemas Distribuidos
Pagina 125
Sistemas Distribuidos
Pagina 126
Sistemas Distribuidos
Pagina 127
Sistemas Distribuidos
Pagina 128
Sistemas Distribuidos
Pagina 129
Sistemas Distribuidos
CONCLUSIONES
En este trabajo se ha hablado de los sistemas distribuidos, de cómo se ha evolucionado desde los
sistemas monolíticos, pasando por los sistemas Cliente-Servidor, luego los sistemas de
publicación y finalmente lo que se ha convertido en las aplicaciones distribuidas. Se ha
planteado por qué este tipo de aplicaciones son complicadas de construir y mucho más
complejas de operar que las aplicaciones cliente servidor o aplicaciones legacy, pero lo que se
pretende resaltar es el hecho de que un sistema distribuido es una cadena de valor en el que
intervienen múltiples factores, así como múltiples elementos que hacen que el sistema tenga
éxito o sea un rotundo fracaso. La responsabilidad de este tipo de sistemas ya no depende
solamente de los analistas, diseñadores y desarrolladores, ahora es necesario llevar más allá la
responsabilidad del sistema ya que un sistema distribuido necesita una postimplementación, un
seguimiento, un mantenimiento, pero no solo de código, sino también operativo, es necesario
obtener métricas de servicio, realizar un monitoreo constante, medir los tiempos de respuesta,
realizar el cálculo de capacidades antes y después de la liberación para que de ser necesario el
sistema sea escalado. La palabra escalabilidad es uno de los principales objetivos de un sistema
distribuido, y se puede decir que si un sistema es fácil de escalar entonces todo el trabajo del que
se ha hablado en este documento ha sido llevado a buen término, y es que debe recordarse por
qué los sistemas Cliente Servidor han dejado de ser la respuesta a las crecientes demandas del
mercado, por ejemplo su disponibilidad. Este factor ha llevado a las corporaciones a replantearse
sus objetivos en términos de tecnología de la información y pensar en construir sistemas
distribuidos que representen servicios de negocio, ya que hoy día no es suficiente contar con
resultados correctos en términos de cálculo, ni es suficiente dar servicio en horarios hábiles, hoy
es requisito dar un servicio 7 días por 24 horas, los 365 días del año, y quizás el reto mayor es el
Pagina 130
Sistemas Distribuidos
de dar el servicio a todos los clientes, a cualquier hora, cualquier día y sin importar el lugar de
residencia del cliente. También se observó que los sistemas distribuidos ayudan a las
corporaciones a actualizar la versión de estas aplicaciones más fácilmente y sin necesidad de
interrumpir el servicio ya que un sistema distribuido con una buena actualización de versiones
puede dar servicio ininterrumpido mientras es actualizado. Como hemos visto esto puede
lograrse al apagar y luego actualizar una parte de los componentes mientras la otra parte
continua trabajando y una vez realizada la actualización en la partición primaria se puede
continuar con la actualización secundaria mientras la nueva versión implementada en la primera
partición da el servicio ya en su nueva versión. La fórmula como se ha descrito consiste en crear
una arquitectura distribuida en múltiples capas que distribuya la funcionalidad y las
responsabilidades del sistema entre diferentes objetos y capas, con esto es posible armar
múltiples sistemas aprovechando la reusabilidad de componentes al distribuir la funcionalidad
en todos los sistemas, contribuyendo de esta manera a la reducción de costos y más importante
aún, a la reducción del tiempo en el que un sistema es modificado y se libera a producción para
adaptarse a las nuevas necesidades del mercado.
En este trabajo se observó que los sistemas distribuidos basados en capas y componentes
además de tener una gran flexibilidad para realizar actualizaciones y crear nuevos sistemas,
proveen la posibilidad de crear conexiones con aliados de negocios, esto es un beneficio tanto
del diseño como de la tecnología en la que se basan los sistemas distribuidos. Con esto es
posible ofrecer un servicio a un socio de negocio, permitiéndole contar con algunos servicios
que le ayuden a ofrecer sus propios servicios a sus clientes, acrecentando de esta manera la
cadena de valor y creando nuevos negocios al realizar transacciones.
Pagina 131
Sistemas Distribuidos
Anexos
Pagina 132
Sistemas Distribuidos
Imagen 1
Imagen 2
Pagina 133
Sistemas Distribuidos
Imagen 3
Imagen 4
Imagen 5
Pagina 134
Sistemas Distribuidos
Imagen 6
Imagen 7
Pagina 135
Sistemas Distribuidos
Imagen 8
Imagen 9
Pagina 136
Sistemas Distribuidos
Imagen 10
Imagen 11
Imagen 12
Pagina 137
Sistemas Distribuidos
Imagen 13
Imagen 14
Pagina 138
Sistemas Distribuidos
Imagen 15
Imagen 16
Imagen 17
Pagina 139
Sistemas Distribuidos
Imagen 18
Imagen 19
Imagen 20
Pagina 140
Sistemas Distribuidos
Imagen 21
Imagen 22
Imagen 23
Pagina 141
Sistemas Distribuidos
Imagen 24
Ver imagen 25
Pagina 142
Sistemas Distribuidos
Imagen 26
Imagen 27
Imagen 28
Pagina 143
Sistemas Distribuidos
Imagen 29
Imagen 30
Imagen 31
Pagina 144
Sistemas Distribuidos
Imagen 32
Imagen 33
Pagina 145
Sistemas Distribuidos
Imagen 34
Imagen 35
Imagen 36
Pagina 146
Sistemas Distribuidos
Imagen 37
Imagen 38
Imagen 39
Pagina 147
Sistemas Distribuidos
Imagen 40
Imagen 41
Imagen 42
Pagina 148
Sistemas Distribuidos
Imagen 43
Imagen 44
Pagina 149
Sistemas Distribuidos
BIBLIOGRAFÍA
http://es.slideshare.net/AleksNet/antecedentes-de-los-sistemas-distribuidos?from_action=save
http://www1.frm.utn.edu.ar/soperativos/Archivos/Sistemas_Distribuidos.pdf
http://sisdistrib.blogcindario.com/2009/10/00001-que-es-un-sistema-distribuido.html
http://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida#Sistemas_distribuidos
http://www.sc.ehu.es/acwlaroa/SDI/Apuntes/Cap1.pdf
http://antares.itmorelia.edu.mx/~antolino/sis-dis-1/capitulo_1.html
http://exa.unne.edu.ar/informatica/SO/SO8.htm
http://es.wikipedia.org/wiki/Remote_Procedure_Call
http://www.geocities.ws/nancy_aguas/rmta.html
http://exa.unne.edu.ar/informatica/SO/SO9.htm
http://exa.unne.edu.ar/informatica/SO/SO9.htm#Intro
http://exa.unne.edu.ar/informatica/SO/SO10.htm#Intro
http://samadistribuidos.blogspot.com/2012/05/tolerancia-fallos.html
http://sedici.unlp.edu.ar/bitstream/handle/10915/22203/Documento_completo.%20Modelizaci
%C3%B3n.pdf?sequence=1
http://es.wikipedia.org/wiki/Distributed_Shared_Memory
http://es.wikipedia.org/wiki/Memoria_compartida
https://sites.google.com/site/sistemasoperativospaty/unidad-4/42-modelos-de-consistencia
https://sites.google.com/site/sistemasoperativospaty/unidad-4/43-mcd-en-base-a-paginas
http://iinfequipo2.es.tl/4-.-3-.--Memoria-comparativa-distribuida-en-base-a-p%E1ginas.htm
Pagina 150
Sistemas Distribuidos
http://ais-sistemasdistribuidos.blogspot.com/p/tema-8.html
https://sites.google.com/site/sistemasoperativospaty/unidad-4/45-mcd-en-base-a-objetos
http://sod-ingenieria-lasallepachuca.blogspot.com/p/amoeba.html
http://tutoriasprogramacioncucei.blogspot.com/2014/02/amoeba-introduccion-es-un-
sistema_37.html
http://sod-ingenieria-lasallepachuca.blogspot.com/p/chorus.html
https://prezi.com/dv51ytpgwi40/copy-of-chorus/
http://primer-tecnologia.globered.com/
http://www.instituto.continental.edu.pe/biblioteca/images/documentos/proyectos/
proyecto_entorno_educativo_web.pdf
http://www.capacinet.gob.mx/Cursos/Tecnologia%20amiga/desarrolladordesoftware/
IntroduccionSistemasDistribuidos_SE.pdf
Pagina 151