[01] Sistemas Distribuidos - Introduccion

Tema 1

Introducción a los Sistemas Distribuidos

1.1 Introducción

La era de los ordenadores comenzó en 1945. Sin embargo, en los últimos diez años se ha

producido un avance espectacular en su evolución. Son dos las causas de este fenómeno. Una, la invención del microprocesador y, dos, la invención de las redes de comunicación de alta velocidad. La introducción de los microprocesadores ha provocado la evolución de las primeras máquinas, que ejecutaban una instrucción por segundo y costaban 1000 millones de pesetas, hacia los ordenadores personales actuales, que cuestan 200.000 pesetas y ejecutan 10 millones de instrucciones por segundo. La relación precio/prestaciones de las primeras máquinas es de (1000 x 106) / 1 = 109 y la de las máquinas actuales es de (2 x 105) / (10 x 106) = 2 x 10-2. Esta gana a aquella por una relación de 0.5 x 1011. Ante esta cifra, es difícil que cualquier otro área de la ciencia pueda siquiera acercarse a la explosión experimentada por las tecnologías de la información en los últimos cincuenta años.

El desarrollo de las redes de ordenadores está permitiendo la comunicación y la

cooperación de las nuevas maquinas. Una red local conecta decenas de máquinas. Las redes de área ancha pueden conectar, virtualmente, todas las máquinas del planeta. La red internet es el más claro exponente de ello. El panorama trazado es que los bajos precios de los ordenadores ha provocado la apacición de cientos de miles de máquinas de una alta potencia de cómputo que pueden cooperar para multiplicarlo. Aparentemente, el avance es imparable. Sólo queda superar un obstáculo: el software. La cooperación de máquinas diferentes para coordinar esfuerzos y compartir recursos requiere de sistemas operativos distribuidos, cuyo diseño es radiacalmente diferente al de los sistemas centralizados. No obstante, la investigación reciente en el área de sistemas operativos distribuidos está ya sentando las primeras ideas. Incluso existen implementaciones experimentales reales de sistemas operativos distribuidos. En la presente asignatura, nos dedicaremos a estudiar conceptos, implementaciones y ejemplos sobre sistemas operativos distribuidos.

1.2 Definición y objetivos de un sistema distribuido

Existen muchas definiciones y no siempre coincidentes. Nosotros diremos que un sistema distribuido es un cojunto de computadores independientes que se presenta a los usuarios como un sistema único. En esta definición cabe destacar dos aspectos. Uno, el hardware. La

UNIVERSIDAD NACIONAL DE TRUJILLO ESCUELA DE INFORMATICA

2

definición habla de máquinas autónomas, es decir, que pueden operar sin la supervisión de ninguna otra. Dos, el software, que debe conseguir que los usuarios del sistema lo vean como una máquina central convencional única.

1.2.1 Ventajas de los sistemas distribuidos sobre los centralizados

La más importante es la economía, ya que los ordenadores personales tienen un relación precio-prestaciones mucho mejor que la de los antiguos mainframes. Así, la tendencia actual es migrar las aplicaciones que corrían en un mainframe hacia un conjunto de estaciones de trabajo mucho más baratas y de mantenimiento mucho más económico. Un segundo aspecto, este más teórico, es el de la velocidad global de la instalación. Un mainframe, por muy potente que sea su UCP, esta siempre tiene un límite. La idea es que si esta UPC tiene una potencia de P MIPS (millones de instrucciones por segundo) y un PC tiene p MIPS, siempre es posible reunir n PC's de modo que m * p > P. Por ejemplo, si n es 10000 PC's y p es 50 MIPS, el conjunto puede alcanzar 500000 MIPS. Una única máquina de esta potencia ejecutaría una instrucción cada dos picosegundos (10-12 segundos). Cada dos picosegundos, la luz sólo puede recorrer 0.6 milímetros, de modo que una UCP de 500000 MIPS no debe superar el tamaño de un milímetro cúbico. Con este tamaño, generaría tanto calor que se fundiría insantánemente. La conclusión es que conseguir una potencia de cálculo dada está limitado por consideraciones técnicas y teóricas. El superar este obstáculo pasa por el trabajo conjunto y simultáneo de más de una UPC. Una tercera razón es que la resolución de muchos problemas pasan por el empleo de computadores físicamente distantes. Un ejemplo puede ser un banco con sucursales en distintas ciudades. En cada sucursal opera un computador. Un computador central se encarga de trabajar sobre los datos de los computadores de las sucursales. Otro ejemplo es el de un sistema de control de un experimento científico complejo. Cada aspecto del esperimento es supervisador por un computador diferente, tal vez operando en un entorno hostil al ser humano. Un computador central, físicamente distante, debe supervisar el resto de los computadores e iniciar el experimento a las órdenes de un operador. Un cuarto aspecto tiene que ver con la seguridad de la instalación. Ante la avería de una UCP, un conjunto de más de una de ellas puede reorganizarse y seguir operando correctamente si bien con prestaciones inferiores. La avería de un sistema con una potente pero única UCP provoca la caída total de la misma. Por último, un sistema distribuido permite la aportación incremental de nuevos recusos de cómputo a fin de elevar su potencia global. El crecimiento incremental resulta muy útil a las empresas. Un mainframe no puede soportar continuamente un aumento continuo de la carga de trabajo debido al crecimiento de la empresa. Llegará un momento en que hará falta su sustitución y, con ello, una inversión muy costosa. La adición de dos o tres estaciones de trabajo adicionales es un gasto perfectamente asumible.

1.2.2 Ventajas de los sistemas distribuidos sobre PC's independientes

La primera es la posibilidad de compartir datos y aplicaciones. Un sistema de reserva de billetes de una compañía aérea necesita mantener una base de datos centralizada a la que acceden las aplicaciones residentes en PC's de oficinas diversas. Un servidor de ficheros permite a los usuarios de una red local de PC's tener una copia única de las aplicaciones, residentes en un PC que actúa de servidor de ficheros. Otra ventaja de los sistemas distribuidos de PC's es la posibilidad de compartir dispositivos periféricos de un precio alto, como impresoras laser, etc.


3

Una tercera razón para conectar PC's independientes en un sistema distribuido es la comunicación personal. El correo electrónico es el exponente más claro. Hay que tener en cuenta que en una comunicación telefónica hay una probabilidad muy alta de que el receptor no pueda atenderla. El correo electrónico es ajeno a ello y es infinitamente más rápido, barato y eficiente que el correo convencional. Finalmente, un PC independiente tiene la potencia de su propia UCP. Conectado en red, puede asignar tareas de cómputo a cualquiera de los PC's ociosos en la red.

1.2.3 Desventajas de los sistemas distribuidos

Pese a todas las ventajas descritas anteriormente, los sistemas distribuidos también tienen sus debilidades. Vamos a destacar tres de ellas. La primera ya ha sido apuntada, y es que hasta la fecha no se tiene la experiencia suficiente para saber cómo ha de ser el software de los sistemas distribuidos en las áreas de diseño, implementación, funcionalidad, uso, etc. No conocemos con precisión cómo deben ser los sistemas operativos, lenguajes o aplicaciones de estos sistemas. Por ejemplo, ¿Cuánto debe saber el usuario respecto a la distribución de sus datos? ¿Qué debe hacer el usuario y qué debe hacer el sistema? Los actuales expertos discrepan notoriamente. El segundo problema asociado a los sistemas distribuidos es su total dependencia de la red de comunicación. Cuando la distribución crece, el tráfico en la red crece y puede llegar a saturarse. Entonces resultará necesario reemplazar la instalación de red. Habrá que realizar una costosa operación de recableado del edificio, reemplazar las tarjetas de red, etc. Por otra parte, un corte en la red deja al sistema completamente inutilizado debido a su total dependencia de ella. Mientras este problema no se resuelva o se adquiera la experiencia suficiente en el mismo, la utilidad de los sistemas distribuidos queda en entredicho. Una tercer problema que acarrean los sistemas distribuidos es su falta de seguridad. Hemos hablado de que una de la ventajas de los sistemas distribuidos es la posibilidad de compartir datos ya que proporcionan un fácil acceso a los mismos. Esta accesibilidad resulta muy peligrosa cuando los datos deben ser secretos. No es una buena idea ubicar datos secretos en un sistema abierto al resto. Este es un factor que juega en contra de los sistemas distribuidos.

1.3 El Hardware de los sistemas distribuidos

Un sistema distribuido está formado por máquinas independientes conectadas entre sí. No obstante, hay varias formas de conectar y organizar todas ellas. En la literatura aparecen varios intentos de clasificación. La taxonomía más citada es la de Flynn (1972). Flynn considera dos características en la arquitectura de una máquina. Una es el número de flujos de instrucción y otra es el número de flujos de datos (Fig 1.1).

Fig. 1.1 Clasificación de los sistemas distribuidos atendiendo a su hardware


4

Una máquina SISD (single instruction, single data) tiene un único flujo de instrucciones y un único flujo de datos. Es la arquitectura convencional Von Neumann que todos conocemos. Una máquina SIMD consta de una única unidad de control con un único flujo de instrucciones que gobierna un determinado número de unidades de proceso, todas ellas idénticas. Cada instrucción se envía simultáneamente a todas las unidades de proceso, cada una con sus propios datos, que la ejecutan o no dependiendo de alguna condición interna almacenada e la propia unidad de proceso (Fig 1.2). Un computador MISD puede considerarse como una estructura pipe-line formada por varios procesadores en la que cada uno hace parte del trabajo sobre un flujo continuo de datos que circula entre ellos. No es una solución muy utilizada. El caso MIMD lo constituyen los multiprocesadores propiamente dichos. Su estructura viene reflejada en la figura 1.3. Se basa en más de un procesadores convencionales serie, cada uno de ellos con una única unidad de proceso que soporta su flujo de datos y una única unidad de control que soporta su flujo de instrucciones.

Fig. 1.2 Arquitectura SIMD

Fig. 1.3 Arquitectura MIMD

Los computadores MIMD podemos subdividirlos, a su vez, en dos categorías. Por una parte, aquellos en los que todas las CPU's comparten la misma memoria, denominados multiprocesadores, y aquellos que no comparten la memoria, denominados multicomputadores, en los que cada UCP tiene su propia memoria. En los primeros se suele decir que las UCP están fuertemente acopladas y en los segundos que están débilmente acopladas. Un ejemplo muy común de estos últimos computadores es el una red local de ordenadores personales. Cada una de estas dos categorías puede subdividirse de nuevo en función de la arquitectura de la red de comunicación que une UCP's y memorias. La Fig. 1.4 muestra la taxonomía completa de los computadores MIMD.


5

Fig. 1.4 Clasificación de sistemas paralelos y distribuidos.

1.3.1 Multiprocesadores en bus

Los multiprocesadores basados en bus consisten en un número determinado de UCP's que están conectadas por un bus en una placa madre o en un panel frontal y comparten la memoria tal y como ilustra la figura 1.5. El bus tiene un número de señales de datos, dirección y control en un número del orden de cien. Ya que la memoria es única, si una UCP escribe una palabra de la memoria e inmediatamente después una segunda UCP lee de la misma posición, el valor leído coincidirá con el recientemente escrito. Esta propiedad de la memoria se llama la coherencia.

Fig. 1.5 Un computador multiprocesador basado en bus.

El problema de este modelo de conexión es que al aumentar el número de UCP se produce la saturación de bus y el rendimiento del sistema desciende de forma drástica. Para disminuir el número de accesos al bus no queda más remedio que introducir en cada placa de UPC una memoria local privada denominada memoria caché. La memoria caché se sitúa entre la UCP y el bus, de modo que todo acceso a la memoria pasa por la caché. ¿Qué contine la caché? Contiene las palabras más recientemente usadas por la UCP. Cuando se lee una palabra que no está en la caché, se acude a la memoria compartida y se la inserta en la caché. Cuando se vuelva a leer esa palabra, ya se encuentra en la caché y no es necesario acceder al bus. Una caché suficientemente grande, capaz de soportar toda la localidad del proceso, provocará una tasa de aciertos elevada y disminuirá drásticamente el tráfico en el bus. Son comumes memorias caché entre 64 Kb y 1 Mb, que consiguen tasas de acierto superiores al 90 %. Por supuesto,la introducción de la caché destruye la coherencia del sistema. Supongamos que dos UCP's leen en su caché una posición de memoria. Entonces una de ellas reescribe en esta posición. Como la palabra accedida se encuentra en la caché, ahora ambas UCP tienen versiones diferentes de la misma palabra. Cuando ambas vuelvan a leerla obtendrán resultados dispares. Hemos perdido la coherencia. Este problema tiene varias soluciones. Veamos una de ellas, que tiene dos vertientes. Por una parte, toda escritura en la caché se reproduce en la memoria. Por otra parte, todas las UCP's monitorizan el bus. Cuando detectan una escritura en la memoria actualizan su memoria caché. Un diseño de este tipo, denominado "snoopy writethrough" caché es coherente, invisible al programador y utilizada en casi todos los multiprocesadores basados en bus. Permite conectar entre 32 y 64 UCP.

1.3.2 Multiprocesadores conmutados

Para conectar más de 64 procesadores y una memoria es preciso seguir otra orientación. La idea es separar la memoria en módulos y conectar las UCP y los módulos de memoria mediante una matriz de conmutadores o "crossbar switch" tal y como indica la figura 1.6, a). Cuando una UPC necesita acceder a un módulo de memoria, el conmutador correspondiente se cierra momentáneamente y después se vuelve a abrir. La ventaja evidente de este esquema es que si dos UPC acceden a módulos diferentes, este acceso puede llevarse a cabo en paralelo. Si ambas acceden al mismo módulo, sin embargo, una de ellas tendrá que esperar.


6

Fig. 1.6 Crossbar switch

Fig. 1.7 Red omega

La desventaja del crossbar switch está en que con n UCP's y n módulos de memoria necesitamos nxn conmutadores, un número que puede llegar a ser prohibitivo. Nuevos métodos de conmutación han sido buscados y una alternativa es la red de comutadores omega de la figura 1.7. Como en ella puede apreciarse, toda UCP puede acceder a cualquier módulo de memoria. El retardo que introduce cada conmutador es del orden del nanosegundo. Puede demostrarse que utilizando conmutadores de 2x2, con n UCP y n memorias, la red omega necesita log2n etapas de conmutación -en la figura 1.7 se muestran, de izquierda a derecha, dos etapas- y cada etapa requiere n/2 conmutadores, lo que hace un total de (n*log2n)/2. Es menor que n2, pero es aún una cantidad importante. Además, la red omega introduce retraso en cada etapa. Para n=1024, existen 10 etapas de conmutación, lo que significa un retraso de 10+10 = 20 retrasos hasta que una palabra llega al procesador que la solicitó. Supongamos una UCP RISC que ejecuta 100 MIPS (Millones de Instrucciones Por Segundo). Esto significa que tarda 10 nanosegundos (10-9 s) en ejecutar una instrucción. Si en esos 10 nanosegundos ha de leer un dato de la memoria, el tiempo de conmutación de cada conmutador ha de ser menor o igual a 10/20 ns = 0.5 ns. El multiprocesador completo necesita (1024*log21024)/2 = 1024*10/2 = 5120 conmutadores de 0.5 ns, algo que no va ser barato. Resumiendo, los computadores multiprocesador basados en bus, incluso con cachés snoopys están limitados a 64 UCP's. Ir más allá requiere redes de conmutación como un "crossbar swuitch" o una red omega. Las redes "crossbar switch" son muy caras cuando su tamaño crece y la red omega, si su tamaño aumenta, se hace cara y, además, es lenta.

1.3.3 Multicomputadores en bus

Si construir y usar computadores multiprocesador en bus es difícil y caro, con los multicomputadores en bus resulta todo lo contrario. Cada UCP tiene su propia memoria y el tráfico UPC-memoria es local. Sólo cuando una UCP necesita comunicar con otra UCP es cuando se genera tráfico en el bus. Así, el volumen de tráfico en el bus será varios órdenes de magnitud menor que en el multiprocesador, que utiliza el bus para soportar el tráfico UCP-memoria entre todas las UCP's y todas las memorias. La Fig. 1.8 muestra un multicomputador en bus. Es muy similar al multiprocesador en bus de la Fig. 1.4, pero con mucho menos tráfico. Este descenso del tráfico no exige un bus de alta velocidad como el bus de una placa madre o panel frontal, que proporcionan velocidades de transferencia del orden de 300 Mbits/s o superiores. Así, puede utilizarse una red ethernet, de 10 Mbits/s. La figura 1.8 es, así más una red local de UCP's más que un conjunto de tarjetas insertadas en un panel frontal, aunque esta configuración es también posible.


7

Fig. 1.8 Un multicomputador en bus con estaciones de trabajo

independientes comunicadas por una red de área local. 1.3.4 Multicomputadores conmutados

Las figura 1.9 y 1.10 muestra dos topologías profusamente implementadas de este tipo de computador, en el cada nodo accede únicamente a su propia memoria. La figura 1.9 se denomina celosía y la figura 1.10 hipercubo. Las celosías son más fáciles de comprender, se implementan en tarjetas y son más apropiadas para problemas que son implícitamente bidimensionales, como el tratamiento de imagen.

Fig. 1.9 Multicomputador en celosía.

Fig. 1.10 Multicomputador hipercubo.

Un hipercubo es un cubo n-dimensional. La figura 1.10 muestra un cubo de dimensión cuatro. En un cubo de dimensión tres, cada vértice -cada UCP- está conectada a otras tres UCP, los vecinos más próximos. En el hipercubo de la figura 1.10 cada UPC está conectada a otras cuatro UCP, los vecinos más próximos. En general, cada UPC de un cubo n-dimensional está conectado a n UCP's. Es fácil demostrarse que si n es la dimensión de hipercubo, el número de conexiones sigue una ley recurrente: Cn = 2*Cn-1 + 2n-1. También Cn = 22*Cn-2 + 2n, o Cn = 24*Cn-4 + 2n+1. En un hipercubo sólo están conectados los vecinos más próximos, de modo que un mensaje puede tener que dar varios saltos hasta alcanzar su destino lejano. De todas formas, el camino más largo entre dos UCP's es más corto que en la celosía. En esta última, el camino más largo es del orden de la raíz cuadrada del número de UCP's. En un hipercubo, sin embargo, el camino más largo es del orden del logaritmo base 2 del número de UCP's, mucho más corto. El camino más largo que debe recorrer un mensaje en un hipercubo también sigue una ley recurrente. Para un hipercubo de dimensión 1, que consta de 21 UCP's, el camino más largo es el único existente, que es de longitud 1. Para un hipercubo de dimensión 2, que nace de la conexión de dos hipercubos A y B de dimensión 1, el camino más largo estará entre dos nodos que se encuentran en distintos subhipercubos. La distancia entre estos nodos será el resultado de la suma del salto desde el hipercubo A al hipercubo B más la distancia más larga en el hipercubo B, es decir 1 más 1, dos, que es la dimensión del hipercubo total. Para un hipercubo de dimensión 3, que nace de la conexión de dos hipercubos de dimensión 2, la distancia más larga es el resultado de sumar 1 a la distancia más larga en un hipercubo de dimensión 2, que es 2 como acabamos de ver, es decir, 3. Luego podemos decir que la


8

distancia más larga entre nodos en un hipercubo conicide con su dimensión n. Por tanto, si N es el número de UCP's de un hipercubo, la distancia máxima entre UCP's será de log2N. Así, un hipercubo de 256 UCP's tendrá una distancia máxima entre nodos de log2256 = 8.

En contraste, una celosía de 256 UCP's tiene un camino máximo entre nodos de 2561/2 = 16. Esta diferencia se debe a que una celosía de N = d*d UCP's tiene un número de conexiones de (d-1)2*2 + (d-1)*2 = 2*d2 - 2*d, menor que el número de conexiones de un hipercubo con el mismo número de UCP's, Cn = 2*Cn-1 + 2n-1, donde n = log2N. Por ejemplo, para un número de UCP's de 256, el número de conexiones entre ellas, dispuestas en un hipercubo de dimensión 8 es de 1024. Si las 256 UCP's se disponen en celosía, el número de conexiones es de 480.

1.4 El Software de los Sistemas Distribuidos

Hemos examinado los tipos de hardware conocidos sobre los que escribir un sistema distribuido. Con independencia del tipo de hardware escogido, la impresión que los usuarios tienen sobre el sistema no viene dado por el hardware subyacente, sino por el software, de modo que si el hardware es importante, el software es más importante aún. El software, por su naturaleza inmaterial, es mucho más difícil de clasificar que el hardware. Aun así, podemos identificar, al igual que en el hardware MIMD, dos clases de software para máquinas con múltiples UCP's: fuertemente acoplado y débilmente acoplado. El software débilmente acoplado permite a las máquinas y a los usuarios ser independientes unos de los otros pero mantener cierto grado de interacción. Un sistema débilmente acoplado es, por ejemplo una red local de PC's, cada uno de ellos con su propia UPC, su propia memoria y su propio disco, pero el software permite compartir recursos como una impresora u otro disco. En esta red, cada máquina es claramente identificable y en cada una de ellas opera un determinado software, también claramente identificable. Si el software de uno de los PC's falla, el resto continúa funcionando incluso sin apreciarlo. Sólo aquél PC cuyo software preste un servicio provocará cierta pérdida de funcionalidad en el resto. Así, por ejemplo, no se podrán ejecutar ciertos programas o no se podrán imprimir documentos. Un ejemplo de software fuertemente acoplado es un sistema multiprocesador dedicado al juego del ajedrez. A cada UCP puede asignársele la evaluación de un tablero y los que se derivan de las posibles jugadas de ese tablero. Cuando un UCP termina, informa sobre los resultados y se le asigna un nuevo tablero. El sistema operativo que soporta la aplicación de ajedrez y la aplicación misma pueden ser considerados como un software fuertemente acoplado. Hay que hacer notar, sin embargo que el grado de acoplamiento del software es más difícil de cuantificar que el del hardware. En la sección 1.3 hablamos de dos tipos de computadores en cuanto a su tipo de hardware, los sistemas fuertemente acoplados y los sistemas débilmente acoplados. En la sección presente hemos introducido, con independencia de la arquitectura hardware, dos tipos de software, el software fuertemente acoplado y el software débilmente acoplado. Se dan, entonces, cuatros tipos de combinaciones de sistemas en función de su tipo de software y su tipo de hardware. A continuación vamos a ver tres de ellos, las más comunmente utilizadas.

1.4.1 Sistemas operativos de red

La configuración más común de combinación hardware-software existente es sin duda la formada por un hardware débilmente acoplado con un software débilmente acoplado, ya que la mayoría de las empresas y organizaciones utilizan máquinas con sistemas operativos


9

autónomos comunicados por red local, son los sistemas operativos de red. Las primeras aplicaciones que se dieron a las redes de ordenadores fue la creación de servicios de terminal remoto, correo electrónico y trasporte de ficheros. En aquel momento el software de máquinas autónomas comenzó a conectase entre sí. El sistema operativo SunOS, una implementación de UNIX, tiene un comando denominado rlogin para entrar en otra máquina SunOS que disponga de un servicio de conexión remota. El comando rlogin se invoca en la línea de comandos desde un máquina dada como # rlogin ceres, donde ceres es la dirección simbólica de una máquina donde deseamos iniciar una sesión. La característica de esta forma de conexión es que es enteramente manual. El usuario indica explícitamente la máquina ceres porque es allí donde se encuentran los servicios, ficheros, programas, al fin y al cabo recursos que necesita. El usuario debe ser consciente de la asociación entre máquina y recursos y, además conocerla. El otro ejemplo de aplicación en que interactúa el software de máquinas diferentes es el de la transmisión de ficheros. Cuando un usuario necesita un fichero que se encuentra en la máquina pizarro y se encuentra trabajando en una sesión de la máquina ceres, invoca el comando # rcp pizarro:/usr/pepo ceres:~/pepo. De la misma forma que en el anterior caso, el usuario es consciente de la localidad del recurso. Aunque esta forma de interacción es primitiva, es aún muy utilizada en entornos de red local. Avances sobre estos esquemas de comunicación son los servidores de ficheros. Un servidor de ficheros es una máquina que mantiene una jerarquía de ficheros en un disco propio. Partes de esta jerarquía pueden ser montadas por procesos remotos que ejecutan en máquinas denominadas clientes. El resultado de esta interacción es que un proceso de un cliente ve como parte de su sistema de ficheros un sistema de ficheros que es mantenido por otra máquina sin que el usuario del sistema cliente deba ser necesariamente consciente de la localización de su sistema de ficheros. El administrador del sistema puede cambiar la localización de un disco o sistema de ficheros sin que el usuario lo aprecie. Los sistemas operativos de las máquinas servidor y cliente se ponen de acuerdo para ofrecer al usuario un servicio de ficheros de forma transparente a éste. Incluso es posible que el sistema operativo sea diferente en la máquina servidora y la cliente. Sólo es necesario un acuerdo en el protocolo de acceso al servicio. Sistemas operativos que usan y ofrecen servicios -recursos- de este tipo con cierto grado transparencia al usuario final se denominan sistemas operativos de red.

1.4.2 Sistemas Distribuidos Auténticos

Los sistemas operativos en red son un ejemplo de software débilmente acoplado sobre hardware débilmente acoplado. En ellos, aparte de ciertos servicios "que proporciona la red", como un sistema de ficheros compartido, cada usuario es consciente de la máquina en la que se encuentra y de que existen otras máquinas en la red. Los sistemas operativos de todas ellas están dedicadas únicamente al servicio de sus usuarios conectados. No hay necesidad de que todas las máquinas se coordinen, salvo en el seguimiento de protocolos de comunicación comunes para acceder y ofrecer servicios determinados. Un paso más alla es la implantación de software fuertemente acoplado sobre un hardware multicomputador o débilmente acoplado. Un software de este tipo tiene como objetivo principal crear en el usuario la ilusión de que está trajando en un sistema convencional de tiempo compartido, desconociendo la naturaleza del hardware subyacente (varias UCP's comunicadas por una red local). Para conseguir este fin, el sistema debe cumplir una serie de requisitos. Entre ellos:


10

1 Un mecanismo de comunicación de procesos global y único que permita a los procesos

comunicarse con independencia de la UCP en la que ejecutan. No debe haber un mecanismo local para los procesos locales y un mecanismo global para procesos remotos.

2 Debe haber un mecanismo unificado de gestión de procesos. 3 Las llamadas al sistema debe ser iguales en todas las UCP's. Como consecuencia, el

núcleo del sistema debe ser idéntico en todas las UCP's. Esta homogeneidad de los núcleos hace más sencilla la cooperación. Cuando un proceso va a ser ejecutado, los núcleos deben ponerse de acuerdo en encontrar la UCP más adecuada.

4 Cada núcleo debe ejercer un control local sobre sus propios recursos. Por ejemplo, parece razonable que cada núcleo gestione su propia memoria. Así sólo el núcleo local decide qué pagina reemplazar, tras una solicitud de un proceso local. Asimismo sólo el planificador del núcleo local decide qué proceso local activar de todos los procesos locales dispuestos.

5 El sistema de ficheros debe aparecer único desde todas las máquinas ofreciendo en todas ellas las mismas operaciones sobre los ficheros y dispositivos. En particular, debe haber un mecanismo de protección de recursos único a fin de dar una imagen de sistema único.

Como puede apreciarse, ya se ha establecido un cuerpo de conocimiento notable sobre la forma de diseñar e implementar sistemas operativos distribuidos. No obstante, sigamos nuestro recorrido panorámico sobre el acoplamiento de hardware y software.

1.4.3 Sistemas de Tiempo Compartido Multiprocesador

Vamos a examinar ahora la combinación de software fuertemente acoplado sobre hardware fuertemente acoplado. La más común de estas combinaciones son máquinas UNIX con más de una UCP. Como ya hemos discutido, una combinación de 32 UCP's de 30 MIPS pueden dar al sistema una potencia equivalente a una UCP de 960 MIPS. Para lograrlo es necesario construir sobre ellas un software fuertemente acoplado. El diseño de este software es mucho más sencillo que en un hardware débilmente acoplado, ya que todas estructuras de datos del diseño se pueden centralizar en la memoria compartida común.

Fig. 1.11 Un computador multiprocesador necesita una única cola de procesos dispuestos.

El objetivo último de estas máquinas es dar la ilusión a los procesos que ejecutan sobre una máquina uniprocesador. Vamos a ver dos aspectos de este tipo de sistema. En primer lugar, tenemos una estructura de dados que resulta la clave de su diseño. Es la cola de procesos


11

dispuestos, que es única para todos los procesadores. Hemos de tener en cuenta que en un sistema convencional uniprocesador, el sistema operativo puede ser reentrante o no serlo. En el caso de serlo, las reentradas se producen como consecuencia de las interrupciones del reloj y de los dispositivos periféricos y que ambos eventos suelen llevar aparejada una operación sobre la cola de procesos dispuestos, bien para reordenar una cola pasando el proceso que ha agotado su cuantum al final de la cola, bien para desbloquear un proceso que estaba bloqueado en una operación de E/S. Este mismo problema se produce en entornos multiprocesador. En ellos, las reentradas al núcleo del sistema operativo se producen como consecuencia no sólo de las interrupciones, sino también de los traps que se producen en dos UCP distintas. Examinemos el siguiente ejemplo. Recordemos que un multiprocesador sigue el patrón de la figura 1.5, con varias CPU's que comparten una memoria común. En la memoria se encuentran las imágenes de todos los procesos, que en cualquier momento pueden ejecutar en cualquiera de las UCP's. La figura 1.11 muestra un sistema con tres UCP's, 1, 2 y 3. Dos procesos están dispuestos, E y D, y tres ejecutando, A, B y C. En un principio, A, B y C ejecutan código de su propio espacio de direccionamiento. Cuando el proceso A, que ejecuta en la UCP 1, realiza una llamada al sistema para realizar una operación de E/S, ejecuta una instrucción de trap y salta al sistema operativo, por su puesto también residente en la memoria común. Seguimos teniendo tres procesos ejecutando, uno de ellos, el A, en el segmento de código del sistema operativo. El sistema operativo salva el estado del proceso A en su descriptor de proceso y se dispone a entrar en el código que modifica la cola de procesos activos para sacar de ella al proceso A y conceder la UCP 1 al proceso D. Supongamos que en la mitad de la actualización de la cola, se produce un trap en el proceso B y el flujo de ejecución de la UCP 2 salta al código del sistema operativo en una primera reentrada en este. A continuación, el sistema operativo ejecuta el planificador y da la UCP 2 al proceso D. Mientras esto ocurría la UCP también estaba ejecutando el código del sistema operativo, que también ha otorgado al proceso D la UCP 1. La conclusión es que la ejecución simultánea del planificador por parte de la UCP 1 y la UCP 2 ha hecho que el proceso D se ejecute simultánemente en los procesadores 1 y dos. Esta situación es incorrecta y se evita imponiendo que el planificador ejecute en región crítica. Otro factor que hay que considerar en los sistemas mutiprocesador son los cambios de contexto en cada una de las UCP's. Cuando al proceso D del anterior ejemplo se la otorgó la UCP 1 por que el proceso A se había bloqueado en una operación de E/S, D se encuentra una caché llena de direcciones de memoria que pertenecen al espacio de direccionamiento del proceso A. Se produce una ejecución más lenta hasta que la caché se actualiza con direcciones del espacio de direccionamiento de D. Si la operación de E/S lleva mucho tiempo, esta pérdida de prestaciones compensa. Sin embargo, si es rápida, como es la lectura o escritura de un disco RAM, la carga impuesta por el cambio de contexto es a todas luces excesiva e inútil. Hubiese compensado realizar la operación de E/S manteniendo a A en la UCP 1. Cuando un proceso X ejecutando en un UCP' n realiza una operación de E/S, es suspendido y otro toma su UCP. Cuando la operación de E/S termina, el proceso X es reiniciado bien en la UCP n bien en otra cualquiera. El resultado es que, al final de su ejecución, el proceso ha sido ejecutado la misma cantidad de tiempo en todas la UCP's. Estos cambios de UCP de los procesos tienen el inconveniente de la actualización inicial de la caché, de modo que como factor de optimiación, es preferible, siempre que sea posible, reiniciar un proceso en la UCP que previamente usaba si esta no ha sido ya reutilizada en su intervalo de servicio.

1.5 Aspectos clave en el diseño de Sistemas Distribuidos

Hasta aquí nos hemos dedicado a hacer un repaso del hardware sobre el que puede construirse un sistema distribuido y del tipo de software que da al usuario del mismo una


12

vista o apariencia más o menos integrada. En el resto del capítulo vamos a detenernos en los aspectos que hay que considerar en la construcción de un sistema para que pueda ser entendido como realmente distribuido. Estos aspectos son la transparencia, la flexibilidad, la fiabilidad, las prestaciones y la escalabilidad.

1.5.1 Trasparencia

Se dice que un sistema distribuido es trasparente cuando es visto tanto por el usuario como por el programador como un sistema convencional de tiempo compartido. La trasparencia total es difícil de lograr. Parcialmente, el concepto de transparencia puede ser aplicado a varios aspectos de un sistema distribuido. La transparecia a la ubicación consiste en que los nombres de los recursos no estén ligados a las máquinas concretas. Por ejemplo, en un sistema que sea transparente a la localidad, no se permiten en una llamada al sistema open nombres como maquina1/home/pipo/agenda. La transparencia a la migración es un concepto un tanto más elaborado. Consiste en que los recursos, si bien su nombre no depende de su localización, cuando esta cambia, el nombre del recurso cambia. Consideremos un sistema con dos servidores de ficheros. Los usuarios ven el directorio raíz del primer servidor como el directorio /libros y el segundo como /articulos. Supongamos que en el servidor segundo tenemos el directorio actaInf93, que los usuarios ven como /artículos/actaInf93. El administrador del sistema puede considerar que los artículos del directorio actaInf93, que han sido compilados y editados en una publicación única, deben ser considerados como un libro, de modo que son migrados al otro servidor en el directorio actaInf93. Ahora, el usuario no ve el directorio /articulos/actaInf93 y sí percibe que ha aparecido el directorio /libros/actaInf93. Este cambio en la ubicación física de un directorio ocasiona que el nombre del directorio cambie de nombre. Se puede decir que este sistema de ficheros no es transparente a la migración. Para aumentar la seguridad de los sistemas, en ocasiones se replican ciertos recursos. La transparencia a la replicación consiste en que el nombre de los recursos debe ser independientes de la réplica concreta. En el ejemplo anterior, el directorio /actaInf93 puede residir en los dos servidores para mayor seguiridad. Sin embargo cada réplica tendría un nombre asociado, bien /artículos/actaInf93, bien /libros/actaInf93. Un sistema de ficheros transparente a la replicación sería aquel en el cual varios servidores dispuestos en un anillo lógico mantuviesen la misma jerarquía de directorios, pero los ficheros no se encuentran en todas las máquinas. El sistema decide en qué máquinas replicar un fichero. Cuando se produce un acceso a un fichero por parte de un proceso, la petición se dirige al primer servidor. Si no está el fichero, la solicitud se redirije al siguiente, etc. El primer servidor que mantenga el fichero atenderá la petición. Lo importante es que el nombre del fichero es independiente de si el fichero está replicado o no, cuántas veces y en qué máquinas. Otro aspecto de la transparencia es la denominada transparencia a la concurrencia. En ocasiones, en un sistema de tiempo compartido dos procesos acceden al mismo registro de un fichero. El que dicha posibilidad exista no debe influir en la forma que es accedido el fichero en el proceso de usuario. Este sistema de acceso debiera se transparente a la concurrencia. Sin duda alguna, la transparencia más difícil de alcanzar es la transparencia al paralelismo. Cuando se dispone de más de una UCP, los problemas se pueden descomponer en procesos, cada uno de ellos ejecutando en una UCP y comunicándose a través de mensajes. Esta aproximación exige del programador que conozca de cúantas UCP dispone su sistema y conozca que su programa admite una descomposición en actividades que pueden ser


13

ejecutadas en paralelo. Sería ideal que el compilador del programa y el sistema operativo llevasen a cabo dicha descomposición. Desgraciadamente, el estado actual de los conocimientos en nos sitúa aún muy lejos de lograr la transparencia al paralelismo. Flexibilidad Este aspecto se refiere a la forma en que debe ser construido el sistema operativo. Conviven dos escuelas de pensamiento que son las del kernel monolítico y las del sistema operativo basado en microkernel. La primera sostiene que los servicios del sistema deben residir en el sistema operativo y la segunda que es preciso extraer todos los servicios posibles fuera del núcleo del sistema operativo y disponerlos en procesos de usuario, logrando un mayor estructura e independencia en los servicios, que pueden residir en máquinas diferentes. Hoy en día el kernel monolítico domina el mundo de los sistemas operativos, pero parece que el futuro se impondrá la filosofía microkernel, debido a su mayor flexibilidad. Para obtener un servicio, un proceso de usuario envía un mensaje al servidor adecuado. El kernel sólo se ocupa de realizar el paso del mensaje y es el proceso de usuario quien realiza el trabajo cuado recibe el mensaje. Es la facilidad para añadir, suprimir y modificar los servicios los que que da la flexibilidad al sistema microkernel. Por ejemplo, puede fácilmente disponerse de dos sistemas de ficheros, UNIX, donde los discos mantienen la asignación de los ficheros en i-nodos y MS-DOS, donde los discos mantienen la FAT. Con un kernel monolítico, el sistema de ficheros es el que es y no puede modificarse. La única ventaja de los kernel monolíticos sobre los microkernels es su mayor velocidad debido a la ausencia de tráfico de mensajes. Sin embargo, en los sistemas operativos distribuidos existen otros factores a considerar además del tráfico de mensajes que minimizan el impacto de estos en las prestaciones del sistema global, de modo que en un futuro previsible se impondrán los sistemas microkernel. Fiabilidad Una de las motivaciones originales para tratar de construir sistemas distribuidos fue el aumento de la fiabilidad del sistema. En un sistema con cien UCP's el fallo de uno de ellas no tendrá consecuencias graves, por que su trabajo será realizado por las otras. En un sistema en el que el sistema de ficheros se reparte en cuatro servidores, cada uno de ellos con una probabilidad de que en un instante dado sea inoperativo de 0.05, la probabilidad de que el sistema de ficheros completo no sea operativo es de 0.054 = 0.000006. No obstante, esta es sólo parte de la verdad. Una cita muy famosa de Leslie Lamport define un sistema distribuido como aquel en el que nunca se puede hacer nada porque siempre necesita de un servicio que presta una máquina que uno nunca sabe donde está que se ha estropeado. Así, el ejemplo anterior puede interpretarse del siguiente modo. Ya que la probabilidad de que uno de los servidores esté disponible es del 0.95, la probabilidad de que un proceso que necesite acceder a los cuatro servidores pueda ejecutarse es de 0.954 = 0.84. La fiablilidad tiene varios aspectos. Uno es la disponibilidad, que es la fracción de tiempo en que el sistema es operativo. La disponibilidad aumenta cuando no es preciso que muchos componentes críticos del sistema necesiten estar operativos simultáneamente, pero desde luego la clave para garantizar la disponibilidad es la replicación de los componentes, sean software o hardware. Si uno falla, otro estará disponible. La redundancia, no obstante, acarrea otros problemas. Entre ellos está la consistencia de los datos. A mayor número de copias, mayor es la probabilidad de que se produzcan inconsistencias, especialmente si al número de escrituras es muy alto. Otro aspecto de la fiablidad es el de la seguridad de los datos, que deben ser protegidos contra accesos no autorizados que los corrompan o eliminen. La problema de seguridad crece


14

en los sistemas distribuidos debido al aumento del número de mensajes que circulan por las líneas de comunicación, que pueden ser interceptados e impostados por máquinas ajenas al sistema. Supongamos un sistema distribuido formado por las máquinas A, B, C y D. Si la máquina F tiene acceso a las líneas de comunicación, F puede enviar un mensaje a A solicitándola un servicio como puede ser el acceso a determinado registro de datos confidencial. En el campo del mensaje que determina la máquina fuente siempre puede insertar el nombre de la máquina B. La máquina A no tiene medio de saber que el mensaje ha sido impostado y contesta a la máquina B. Este mensaje también es interceptado o leído por la máquina F. Prestaciones Por muy brillantemente que hayan sido resueltos los objetivos de transparencia y fiabilidad de un sistema operativo distribuido, este no tendrá éxito si es lento. La velocidad de los sistemas distribuidos viene comprometida por el tráfico de mensajes en las líneas de comunicación. En una red local, el envío de un mensaje puede llevar alrededor de un milisegundo. La mayoría de este tiempo se gasta en la ejecución de los protocolos de comunicacióne en ambos extremos de la línea. El aumento de velocidad pasa necesariamente por minimizar el número de mensajes intercambiados. Por una parte, el descomponer un problema en actividades que pueden ser ejecutadas en paralelo y asignarlas a distintos procesadores es la mejor manera de resolver el problema de forma eficiente. Por otra parte, a mayor número de procesadores, mayor es el número de mensajes intercambiados. Aparece así el concepto de la granularidad de los cálculos. El problema de sumar cuatro enteros puede ser descompuesto en dos subproblemas. El primero es sumar los dos primeros números y el segundo el sumar los dos últimos. Desde luego no merece la pena el solicitar un servicio remoto para sumar dos enteros por que el costo de las comunicaciones es incomparablemente mayor que el ahorro de tiempo conseguido en su ejecución simultánea. En general, se puede decir que un sistema operativo distribuido dará pocas prestaciones en problemas de granularidad fina, es decir aquellos en que muestran muchos cálculos pequeños que se comunican intensamente. Si son apropiados en la resolución de problemas de granularidad gruesa, aquellos que exiben unos pocos bloques de cálculo independientes y pocas necesidades de comunicación. Escalabilidad A pesar de los progresos de los últimos años, con sistemas concretos y desarrollados, el diseño de sistemas operativos distribuidos es un campo aún poco conocido e investigado. Los actuales sistemas abarcan como máximo unos cientos de máquinas. A medida que la informática se introduce en las actividades cotidianas y el ordenador se introduce en los hogares, comienzan a perfilarse sistemas de miles de millones de máquinas. La pregunta que se plantea es la siguiente. ¿Los métodos y algoritmos utilizados en los sistemas operativos distribuidos actuales son apropiados, es decir, escalan adecuadamente cuando el número de componentes aumenta en órdenes de magnitud? Aunque se sabe aún muy poco acerca de estos enormes sistemas futuros, una cosa parece estar clara: hay que evitar componentes, estructuras de datos -tablas, etc- y algoritmos que operen de forma centralizada. En cuanto a los componentes o máquinas, es posible tener un único servidor que atienda a cuatro cientos millones de hispanohablantes, pero más vale repartir su carga de trabajo entre otros servidores a fin de paliar los esfectos de una interrupción del servicio. En cuanto a las tablas, se puede mantener los números de teléfono de cuatrocientos millones de personas en una sóla máquina. Supongamos un registro de 50 caracteres. El listado total requiere un almacenamiento de 50 * 4 * 108 = 20 * 109 = 20 Gbytes, que puede soportar incluso una única unidad de disco. No obstante, concentrar las peticiones en está máquina saturaría no sólo su UCP sino las líneas de comununicación que salen y entran en el sistema.


15

Centralizar algoritmos tampoco es una buena idea. En un sistema distribuido grande, una cantidad enorme de mensajes debe ser encaminada a lo largo de muchas líneas y máquinas. La forma más eficiente de hacer esto es recabar periódicamente toda la información de la carga de todas las líneas y máquinas en una máquina central. Con la información obtenida esta máquina calculará todas las rutas óptimas empleando un algoritmo de teoría de teoría de grafos. Sus resultados serán después extendidos al resto de las máquinas del sistema. Una máquina única prestando servicios a demasiados clientes hemos visto que es inadecuada. En general, algoritmos que exijan el requerir información a todos los componentes, realizar cálculos con la información recabada y después distribuir los resultados deben ser evitados. Sólo deben usarse algoritmos descentralizados, que tienen las siguientes características. 1. Ninguna máquina tiene información completa acerca de todo el sistema. 2. Las máquinas toman decisiones basadas sólamente en información local. 3. El fallo de una de las máquinas no malogra el algoritmo. 4. No existe un reloj común. Este último aspecto quizás se entienda peor. En una red local, las máquinas se pueden sincronizan en un intervalo del milisegundo, pero sincronizar máquinas a nivel nacional, por ejemplo, es más complicado.

Bibliografía [01]Tanenbaum, A. S., "Distributed Operating Systems", Prentice-Hall, 1995. [02]Tanenbaum, A. S., "Operating Systems, Design and Implementation", Prentice-Hall, 1987. [03]Coulouris, G., "Distributed Systems, Concepts and Design", Second Edition, Addison-Wesley, 1994.

[01] Sistemas Distribuidos - Introduccion

Documents

Transcript of [01] Sistemas Distribuidos - Introduccion