• Author / Uploaded
• Marcos Alexander Ordinola Lozada

• Categories
• Computación distribuida
• Modelo OSI
• Unidad central de procesamiento
• Protocolos de comunicaciones
• Núcleo (Sistema operativo)

Citation preview

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 1.1 Historia de los Sistemas Distribuidos

---------------------------------- 15

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

Pagina 8

Sistemas Distribuidos   

CHORUS (imagen 42)---------------------------------------------------------------------------147 Administración en memoria en CHORUS (imagen 43)-------------------------------------148 Comunicación en CHORUS (imagen 44)-----------------------------------------------------148

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)

Pagina 9

Sistemas Distribuidos Rendimiento Escalabilidad Flexibilidad Seguridad Cada uno de los distintos modelos de sistemas distribuidos requiere diferentes facetas de estos objetivos.

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

Pagina 10

Sistemas Distribuidos los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.

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.

Pagina 11

Sistemas Distribuidos

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.

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

Pagina 12

Sistemas Distribuidos 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.

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 13

Sistemas Distribuidos

Capítulo 1: Sistemas Distribuidos

Pagina 14

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.), se encarguen de modificar sus programas. Establecían o apartaban tiempo, metían o introducían

Pagina 15

Sistemas Distribuidos 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 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

Pagina 16

Sistemas Distribuidos 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. Factores que han afectado el desarrollo de los Sistemas Distribuidos. 1.-Avances Tecnológicos. 2 .Nuevos requerimientos.

Pagina 17

Sistemas Distribuidos 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 18

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

Pagina 19

Sistemas Distribuidos -Administración más compleja. -Costos. (ver imagen 3)

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

Pagina 20

Sistemas Distribuidos 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. 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

Pagina 21

Sistemas Distribuidos 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 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

Pagina 22

Sistemas Distribuidos 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 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:

Pagina 23

Sistemas Distribuidos 

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.



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

Pagina 24

Sistemas Distribuidos 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. 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

Pagina 25

Sistemas Distribuidos 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. 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.

Pagina 26

Sistemas Distribuidos

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

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:

Pagina 27

Sistemas Distribuidos 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 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.

Pagina 28

Sistemas Distribuidos 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.



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.

Pagina 29

Sistemas Distribuidos 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)

1.7 COMPONENTES DE LOS SISTEMAS DISTRIBUIDOS El desarrollo de un sistema distribuido complejo requiere el uso de las siguientes funciones y servicios:

Pagina 30

Sistemas Distribuidos –

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:

Pagina 31

Sistemas Distribuidos –

Paso de mensajes: Berkeley sockets.

–

Llamada a procedimientos remotos: RPC.

–

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.

Pagina 32

Sistemas Distribuidos Afecta a otros servicios: –

Nombrado e identificación.

–

Seguridad y fiabilidad.

–

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

Pagina 33

Sistemas Distribuidos –

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)

Capítulo 2: Recursos

Pagina 34

Sistemas Distribuidos

De Los 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.

Pagina 35

Sistemas Distribuidos 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.

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

Pagina 36

Sistemas Distribuidos 

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.

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:

Pagina 37

Sistemas Distribuidos 

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 38

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 39

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 40

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 41

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

Pagina 42

Sistemas Distribuidos 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.



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:

Pagina 43

Sistemas Distribuidos 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) 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.

Pagina 44

Sistemas Distribuidos 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:

o Ante la pérdida de un paquete, solo retransmite ése paquete. o Requiere más paquetes en la red. 

Por mensaje completo:

Pagina 45

Sistemas Distribuidos 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.

Pagina 46

Sistemas Distribuidos o El paquete anterior que ha llegado. 

Aya:

o ¿Estás vivo? 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.

Pagina 47

Sistemas Distribuidos 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. 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.

Pagina 48

Sistemas Distribuidos 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ó). 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.

Pagina 49

Sistemas Distribuidos 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.

Funcionamiento

1. El cliente envía la petición y queda a la espera un tiempo.

Pagina 50

Sistemas Distribuidos 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 51

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

Pagina 52

Sistemas Distribuidos 

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.



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

Pagina 53

Sistemas Distribuidos 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. 

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.

Pagina 54

Sistemas Distribuidos 

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:

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.

Pagina 55

Sistemas Distribuidos 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:

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.

Pagina 56

Sistemas Distribuidos 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. Se elige un proceso coordinador.

Pagina 57

Sistemas Distribuidos 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.

Pagina 58

Sistemas Distribuidos 

Se supone que cada mensaje tiene un reconocimiento.

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.

Pagina 59

Sistemas Distribuidos 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. 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.

Pagina 60

Sistemas Distribuidos 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.

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.

Pagina 61

Sistemas Distribuidos 

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.

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:

Pagina 62

Sistemas Distribuidos 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:

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.

Pagina 63

Sistemas Distribuidos 

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

Detección Distribuida de Bloqueos Cuando se detecta un bloqueo en un S. O. convencional se resuelve eliminando uno o más procesos.

Pagina 64

Sistemas Distribuidos 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.



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.

Pagina 65

Sistemas Distribuidos 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 La prevención consiste en el diseño cuidadoso del sistema para que los bloqueos sean imposibles estructuralmente.

Pagina 66

Sistemas Distribuidos 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.

Pagina 67

Sistemas Distribuidos 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. 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.

Pagina 68

Sistemas Distribuidos 

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

Pagina 69

Sistemas Distribuidos 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.

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.

Pagina 70

Sistemas Distribuidos 

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

Pagina 71

Sistemas Distribuidos 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.



Un alto grado de autonomía para asignar los recursos de su estación de trabajo.

Pagina 72

Sistemas Distribuidos 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?.

Pagina 73

Sistemas Distribuidos 

¿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: 

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.

Pagina 74

Sistemas Distribuidos 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: 

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

Pagina 75

Sistemas Distribuidos

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:

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.

Pagina 76

Sistemas Distribuidos 

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.

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.

Pagina 77

Sistemas Distribuidos 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 78

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

Pagina 79

Sistemas Distribuidos 

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

Pagina 80

Sistemas Distribuidos 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.

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

Pagina 81

Sistemas Distribuidos 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 82

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 83

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 84

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 85

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 86

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 87

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

Pagina 88

Sistemas Distribuidos Los componentes de un sistema distribuido de archivos son: 

El verdadero servicio de archivos:

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.

Pagina 89

Sistemas Distribuidos 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:

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:

Pagina 90

Sistemas Distribuidos 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.



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

Pagina 91

Sistemas Distribuidos 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: 

El disco del servidor.



La memoria principal del servidor.



El disco del cliente (si existe).



La memoria principal del cliente.

Pagina 92

Sistemas Distribuidos 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 93

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.

Pagina 94

Sistemas Distribuidos 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. 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.

Pagina 95

Sistemas Distribuidos 

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

Pagina 96

Sistemas Distribuidos 

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.

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.

Pagina 97

Sistemas Distribuidos 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.

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.

Pagina 98

Sistemas Distribuidos 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 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.

Pagina 99

Sistemas Distribuidos

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

Pagina 100

Sistemas Distribuidos 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 para C++ proporcionan acceso portable y orientado a objetos de la memoria compartida. Por ejemplo, Boost incluye Boost.Interprocess y Qt proporciona QSharedMemory .

Pagina 101

Sistemas Distribuidos 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 semántica. Para mantener el modelo, los compiladores pueden reordenar algunas instrucciones

Pagina 102

Sistemas Distribuidos 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)

Pagina 103

Sistemas Distribuidos

2.5.3 MEMORIA COMPARTIDA DISTRIBUIDA CON BASES DE PÁGINAS 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:

Pagina 104

Sistemas Distribuidos La memoria distribuida en sistemas multiprocesador. 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 105

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 y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las

Pagina 106

Sistemas Distribuidos 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.

Pagina 107

Sistemas Distribuidos 

Evitan el compartimiento falso.

El Sistema Linda 

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

Pagina 108

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 32 e imagen 33)

Unidad 3: Pagina 109

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 110

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 111

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 112

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 113

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 114

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 115

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 116

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 117

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 118

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 119

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 120

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 121

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 122

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.

Pagina 123

Sistemas Distribuidos Es de arquitectura basada en componentes (módulos), lo que le dota de una alta configurabilidad y escalabilidad. 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)

Pagina 124

Sistemas Distribuidos 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 . 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)

Pagina 125

Sistemas Distribuidos

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

Pagina 126

Sistemas Distribuidos 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. 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:

Pagina 127

Sistemas Distribuidos 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. 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.

Pagina 128

Sistemas Distribuidos 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. 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.

Pagina 129

Sistemas Distribuidos 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

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

Pagina 130

Sistemas Distribuidos 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 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)

Pagina 131

Sistemas Distribuidos

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 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 132

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 133

Sistemas Distribuidos

Pagina 134

Sistemas Distribuidos

Pagina 135

Sistemas Distribuidos

Pagina 136

Sistemas Distribuidos

Pagina 137

Sistemas Distribuidos

CONCLUSIONES

Pagina 138

Sistemas Distribuidos 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 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

Pagina 139

Sistemas Distribuidos 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 140

Sistemas Distribuidos

Anexos

Pagina 141

Sistemas Distribuidos Imagen 1

Imagen 2

Pagina 142

Sistemas Distribuidos Imagen 3

Imagen 4

Imagen 5

Imagen 6

Pagina 143

Sistemas Distribuidos

Imagen 7

Imagen 8

Pagina 144

Sistemas Distribuidos

Imagen 9

Imagen 10

Pagina 145

Sistemas Distribuidos

Imagen 11

Imagen 12

Imagen 13

Pagina 146

Sistemas Distribuidos

Imagen 14

Imagen 15

Pagina 147

Sistemas Distribuidos

Imagen 16

Imagen 17

Imagen 18

Pagina 148

Sistemas Distribuidos

Imagen 19

Imagen 20

Imagen 21

Pagina 149

Sistemas Distribuidos

Imagen 22

Imagen 23

Imagen 24

Pagina 150

Sistemas Distribuidos

Ver imagen 25

Imagen 26

Pagina 151

Sistemas Distribuidos

Imagen 27

Imagen 28

Imagen 29

Pagina 152

Sistemas Distribuidos

Imagen 30

Imagen 31

Imagen 32

Pagina 153

Sistemas Distribuidos

Imagen 33

Imagen 34

Pagina 154

Sistemas Distribuidos

Imagen 35

Imagen 36

Imagen 37

Pagina 155

Sistemas Distribuidos

Imagen 38

Imagen 39

Imagen 40

Pagina 156

Sistemas Distribuidos

Imagen 41

Imagen 42

Imagen 43

Pagina 157

Sistemas Distribuidos

Imagen 44

Pagina 158

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 159

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-unsistema_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_entor no_educativo_web.pdf http://www.capacinet.gob.mx/Cursos/Tecnologia %20amiga/desarrolladordesoftware/IntroduccionSistemasDistribuidos_SE.pdf

Pagina 160