Apuntes básicos de la asignatura:

SISTEMAS OPERATIVOS DISTRIBUIDOS

Tema 1.- Introducción

[Conceptos básicos de Sistemas Operativos] [Evolución Histórica de los SSOO] [Introducción a los SSDD] [Tendencias]

Capítulo 1.1.- Conceptos básicos de Sistemas Operativos

Qué es un SO?

Un sistema operativo es un programa que actua como intermediario entre el usuario de un ordenador y el hardware de esa máquina; por lo tanto, su misión principal es la de proporcionar un entorno donde los programas se puedan ejecutar de forma conveniente y eficiente.

Características de los Sistemas Operativos

Componentes (funciones)

Servicios de un Sistema Operativo

Llamadas al Sistema (System Calls)

Son intefaces entre los procesos y el sistema operativo. Casi todos los lenguajes de alto nivel poseen una interfaz con UNX (standard POSIX: Portable Operating System Interface on Unix, C, Fortran, Ada, ....).

Ejemplos:

Programas del Sistema

Constituyen un entorno de desarrollo y ejecución de programas que resulta cómodo al usuario. Permite facilidades de compilación, edición, accounting, configuración... que forma el interfaz gráfico (SHELL).

Estructura de un SO

Capítulo 1.2.- Evolución histórica de los Sistemas Operativos

Fase I

Fase II

Capítulo 1.3.- Introducción: Sistemas Distribuidos

Definición:

Un sistema distribuido es una colección de ordenadores independientes que aparecen ante el usuario como si se tratara de uno solo. Esto implica que:

• las máquinas pueden ser autónomas.

• los usuarios piensan en la aplicación Software como si estuviera integrada en su máquina.

Ejemplos:
1.- Red de estaciones de trabajo en un departamento universitario de ingeniería informática, con pool de procesadores

2.- Compañía bancaria con cientos de sucursales por todo el mundo.

3.- Correo electrónico. Tiene el problema de "name resolution": DNS.

Un sistema distribuido simple.

• Basado en una red local.

• Cumple los mismos requisitos que un sistema centralizado.

• UNIX

• UNIX 4BSD de Berkely, a finales de los 70. La arquitectura utilizada fue la mostrada aquí.

• La implementación UNIX COMERCIAL (no Linux) más utilizada es la de Sun Microsystems, basado en el BSD. Este sistema fue el que comenzó a utilizar el NFS (Network File System) para servicio de ficheros, el RPC (Remote Procedure Calling), y el NIS (Network Information Service).

• Otras han intentado evitar los problemas de UNIX, de diferentes maneras:

• Ejemplo: cajero automático.

• Ejemplo: sistema Pandora.

Importante: un sistema se ha de considerar distribuido si es capaz de actuar como si fuera un sistema uniprocesador, sin conocimiento directo del usuario, y con transparencia.

Ventajas de Sistemas Distribuidos con respecto a Sistemas Centralizados:

1.- Económico

2.- Prestaciones en modo absoluto

3.- Algunas aplicaciones HAN de ser distribuidas

4.- Trabajo cooperativo.

5.- Mayor confianza del sistema.

6.- Escalabilidad.

Ventajas de Sistemas Distribuidos con respecto a Sistemas Aislados:

1.- Compartición de datos.

2.- Compartición de dispositivos.

3.- Comunicación entre usuarios.

4.- Flexibilidad.

Desventajas de los Sistemas Distribuidos:

1.- Diseño de aplicaciones Software.

2.- Red de comunicación.

3.- Seguridad.

Capítulo 1.4.- Tendencias

Objetos Distribuídos:

• OMG CORBA.

• Microsoft DCOM.

Remote Method Invocation:

• Java RMI.

Agentes móviles:

• Voyager con CORBA.

Tema 2.- Sistemas de Multiprocesado

[Threads y Procesos] [Gestión y Planificación de Tareas]

Capítulo 2.1.- Threads y Procesos

Concepto de proceso

Ejecución concurrente de procesos

Creación y terminación de procesos

Concepto de Thread

Existen muchas ocasiones en las que resulta útil que los recursos fueran compartidos y accedidos de modo concurrente.

Son procesos, unidades lógicas de planificación en la CPU, que consisten en:

Los threads creados por un proceso comparten:

Capítulo 2.2.- Gestión y Planificación de Tareas

[Multithreading] [Modelos de diseño] [Arquitectura Solaris 2.x]

Beneficios de Mutithreading

Problemas Potenciales

Modelos de Implementación Multithread

• Modelo Boss-Worker

• Un thread funciona como jefe, y asigna tareas al resto para que las ejecuten.

• Cuando el thread empleado termina, puede mandar una notificación al jefe informándole del resultado final, y de que está preparado para otra tarea, o es el propio jefe el que realiza un "polling" sobre los empleados.

• Variación: el modelo de colas: el jefe pone sus trabajos en una cola accesible por el resto de los threads, y estos los van capturando y ejecutando. Ejemplo: pool de secretarias, donde el jefe va poniendo en una cesta los documentos que han de ser pasados a máquina.

• Modelo Work Crew

• Un conjunto de threads trabaja en paralelo sobre una tarea.

• La tarea se divide horizontalmente en piezas, y cada thread ejecuta una de ellas.

• Ejemplo: gente limpiando un edificio.

• Modelo Pipelining

• La tarea se divide VERTICALMENTE en pasos, que deben ser ejecutados secuencialmente.

• Cada thread ha de ejecutar un paso, y avisar al siguiente thread para que realice el siguiente.

• Ejemplo: fábrica de ensamblaje de automóviles.

Arquitectura Multithread Solaris 2.x: definiciones

Threads de Usuario

Los threads comparten las instrucciones de código, y la mayoría de los datos, así que un cambio por parte de un thread de los datos compartidos puede ser visto por el resto de los threads del proceso. Cuando un thread necesita comunicarse con otros threads del mismo proceso, el sistema operativo no tiene por qué estar involucrado.

Los threads de usuario se manejan en el espacio de usuario, para así evitar retrasos por cambios de contexto del kernel. Una aplicación así puede tener miles de threads sin consumir recursos kernel.

Características:

Generalmente, los threads son muy ligeros. Si es necesario ligarlos a recursos de ejecución, se convierten en recursos kernel.

Procesos ligeros

La biblioteca de threads utiliza threads inherentes de control: LWP, soportados por el kernel. Se pueden ver como CPU VIRTUAL que ejecuta código o llamadas al sistema.

Generan un puente entre el nivel de usuario y el nivel kernel.

Cada proceso contiene uno o más LWPs, cada uno de los cuales ejecuta uno o más threads de usuario. La creación de un thread implica, generalmente, la creación de algún contexto de usuario, pero no la creación de un LWP.

No existe una relación one-on-one entre threads de usuario y LWPs, pudiendo los threads de usuario migrar de un LWP a otro. Es la biblioteca de threads, con la ayuda del programador y del sistema operativo, quien se asegura de que el número de LWPs disponible sea el adecuado para los threads de usuario activos en ese momento.

Cuando un thread de usuario se bloquea (sincronización), su LWP se marcha a otro thread en ejecución.

El sistema operativo decide que LWP se ejecuta en qué procesador y cuándo. No ha de preocuparse de cuántos threads de usuario
existen ni nada por el estilo. Son los LWPs los que se planifican en los recursos CPU a partir de sus prioridades.

Unbound Threads

Los threads que se planifican dentro de un pool de LWP se denominan "threads ligados". Generalmente se desea esta situación para que puedan flotar libremente entre diferentes LWPs.
Los LWPs se asignan a threads en ejecución => el LWP asume sus instrucciones. Cuando el thread se bloquea, u otro tiene más prioridad, el estado se almacena y el LWP va a otro thread (todo gestionado por la biblioteca de threads).

Bound Threads

Para qué ligar permanentemente un thread a un LWP:

A veces, tener más threads que LWPs, caso que puede ocurrir con threads desligados, es una desventaja.

Clases de Planificación (scheduling classes)

El kernel Solaris tiene tres clases de planificación:

La clase de planificación la mantiene cada LWP por separado. Cuando un proceso es creado, el LWP inicial hereda la clase de planificación y la prioridad del proceso padre.

Cuando se crean nuevos LWPs para threads desligados, también heredan esa clase y prioridad. De hecho, todos los threads desligados de un mismo proceso tienen la misma clase de planificación y prioridad.

Los threads ligados tienen la clase de planificación y la prioridad de sus LWPs.

Planificación Timeshare:

Distribuye el recurso en modo Round-Robin, dependiendo de la prioridad.

La prioridad de despacho de los LWPs "time-shared" se calcula a partir del ratio de uso instantaneo de la CPU, y de la prioridad relativa de los procesos con respecto al planificador timeshare (a un LWP que haya recibido una gran cantidad de tiempo de procesamiento se le asigna una prioridad más baja).

Planificación Realtime:

Se puede aplicar a todo un proceso, o a un LWP o más dentro de un proceso, lo cual requiere privilegio de superusuario.

El planificador siempre despacha el LWP relatime con más alta prioridad. Este retiene control del procesador hasta que es "preempted", se suspende, o su prioridad realtime se cambia.

Los LWPs realtime tienen prioridad absoluta.

Planificación de LWP y Binding de threads:

La biblioteca de threads ajusta automáticamente el número de LWPs en el pool para ejecutar threads desligados. Así:

Cuando todos los LWPs en un proceso están bloqueados, el sistema operativo lanza una señal SIGWAITING al proceso, gestionada por la biblioteca de threads, de forma que se cree un nuevo LWP y se asigne a ejecución.

Al contrario, cuando existe un "overbooking" de LWPs, debido a que la biblioteca de threads asigna a cada LWP una edad, los no utilizados serán eliminados en un tiempo medio de cinco minutos.

Categorías funcionales en la implementación de Threads

POSIX

El grupo POSIX 1003.1c (anteriormente POSIX 1003.4a) está trabajando en un estándar para programación multithread.
No existen diferencias fundamentales entre los threads Solaris que aquí se han expuesto y el estándar POSIX (Portable Operating System Interface for UniX), también conocidos como pthreads.

Tema 3.- Sistemas Multiprocesadores

[Conceptos HW] [Conceptos SW] [Combinación HW-SW]

Capítulo 3.1.- Conceptos HW

• Existen diferentes formas de organización.

• Existen varias clasificaciones; una de las más citadas taxonomías: Flynn (1972):

• Nueva clasificación:

• Conceptos:

3.1.1.- Multiprocesadores "Bus-based"

• CPUs en un bus común más un módulo de memoria.

• El bus puede tener:

• Coherencia en memoria: si la CPU A escribe en dirección X y la CPU B lee X => obtiene el mismo valor.

• Memoria Caché: para evitar sobrecarga, la caché almacena las palabras accedidas más recientemente (HIT RATE máximo: la caché suele tener entre 64 K y 1 M).

• Problema: se presenta un problema de incoherencia: A y B tienen X en su caché. A escribe en X, B lee de X en su caché: valor antiguo!!!

• Solución: Write-through caché: cuando se escribe en caché, se escribe en memoria: las "read misses" y los "writes" causan tráfico en la red.

• Además, todos los cachés monitorizan el bus para que, cuando exista un "write" sobre una dirección de memoria presente en la caché, o elimina la entrada del caché, o la actualiza: SNOOPY CACHÉ.

• SNOOPY + WRITE-THROUGH = COHERENCIA.

3.1.2.- Multiprocesadores "Switched"

• Crossbar switch:

• Omega switching network

• NUMA (Non Uniform Memory Access)

• Conclusión: Los grandes sistemas multiprocesadores son posibles, pero caros.

3.1.3.- Multicomputadores "Bus-based"

• LAN (10 - 100 Mbps).

• Bus backplane: 300 Mbps.

3.1.4.- Multicomputadores "Switched"

• Grid (rejilla)

• Basado en circuitos integrados.

• Mejor para problemas 2-D (teoría de grafos, visión).

• Hipercubo: cubo n-dimensional.

• En un hipercubo n-dimensional, cada CPU tiene n conexiones a otras CPUs.

• La complejidad del cableado se incrementa en O(lg2n).

• El camino más largo crece en O(log2n) con el tamaño (grid: sqrt(n)).

• 1024 CPUs han funcionado durante años. Actualmente se llega a 16.384 CPUs.

Capítulo 3.2.- Conceptos SW

Capítulo 3.3.- Combinaciones HW-SW

3.3.1.- SW débilmente acoplado con HW débilmente acoplado

• La combinación más típica: LAN: NETWORK OPERATING SYSTEM.

• Cada usuario tiene una Workstation para su uso exclusivo.

• Puede o no tener disco duro, pero sí Sistema Operativo.

• A veces conexión remota: rlogin machine, rcp m1:file1 m2:file2...pero es un esquema primitivo => CLIENTE/SERVIDOR (sistema de ficheros global, con servidores de fichero, necesitando la concepción de CLIENTE).

• Ya se tiende a la nueva concepción de objetos distribuidos, y movilidad de la funcionalidad.

• Diferentes usuarios pueden tener diferentes visiones del mismo sistema operativo: servidor con dos directorios.

• Ante diferentes SSOO: mismo protocolo de mensajes.

3.3.2.- SW fuertemente acoplado con HW débilmente acoplado

• Se trata de crear la ilusión de un monoprocesador virtual (single-system image).

• Cómo se consigue:

3.3.3.- SW fuertemente acoplado con HW fuertemente acoplado

• Por ejemplo: máquinas de Bases de Datos dedicadas. Multiprocesadores operados como sistemas de compartición de tiempo UNIX.

• Clave:

• Una sola cola de ejecución: lista de todos los procesos del sistema que están desbloqueados y listos para ejecutarse.

• El scheduler ha de estar en una región crítica (no puede haber dos CPUs cogiendo el mismo proceso).

3.3.4.- Comparación

Nota: Algunas de las imágenes utilizadas en este tema están recogidas del curso "Commnunication Technology" del MIT.

Tema 4.- Introducción a los Sistemas Distribuidos

[Base histórica] [Modelos de SSDD] [Requisitos y características de un SD]

Capítulo 4.1.- Base histórica

• El comienzo potencial de la utilización de sistemas distribuidos es a principios de los 70. Tras el emergimiento de los

• minicomputadores; la utilización de estos como estaciones de trabajo gráficas uniusuario fue una gran éxito, sobre todo en el desarrollo de SW. Este éxito condujo a pensar en la posibilidad de conseguir los mismos resultados desde un punto de vista multiusuario.

• Problema: la tecnología necesaria para transformar aquel sistema uniusuario en otro coopoerativo no existía en aquellos momentos.

• Uno de los primeros éxitos en desarrollo fue gracias al Xerox Palo Alto Research Center (Xerox PARC), en 1971-1980:

• Servidores de impresión y de ficheros.

• Primera red local de alta velocidad (Ethernet).

• Sistemas distribuidos experimentales.

• Primera estación de trabajo: Alto:

• monitor monocromo de alta resolución.

• 128 Kb de memoria principal.

• Disco duro de 2.5 Mb.

• CPU microprogramada a la velocidad de 1 instrucción/2-6 microsegundos.

• Xerox DFS (Distributed File System).

• En primera época, también:

• UNIX

• ARPANet (padre de la Internet actual).

• SmallTalk (primer concepto de programación orientada a objetos).

• Después:

• Berkeley UNIX.

• Ethernet (ya comentada)

• Sun NFS

• AFS (Andrew File System)

• Mach

• Amoeba

• Chorus

Capítulo 4.2.- Modelos de sistema distribuído

4.2.1.- Estaciones y servidores

• Es el más común en la actualidad.

• A cada usuario se le asigna una estación.

• Las estaciones:

• ejecutan las aplicaciones.

• dan soporte a la interfaz de usuario (GUI).

• acceden a los servicios compartidos, mediante SW de comunicaciones.

• Los servidores dan acceso a:

• información compartida (servicio de ficheros)

• dispositivos HW compartidos (impresoras, scanners, ...)

• funciones del Sistema Operativo (autentificación, ...)

• Ejemplos:

• XDS y Cedar, del Xerox PARC.

• V-system de la Universidad de Stanford.

• Argus, del MIT.

4.2.2.- Banco de procesadores

• Los procesadores del pool tienen un CPU, suficiente memoria, pero no tienen ni discos ni terminales.

• Los usuarios acceden al sistema desde terminales-X.

• Gestor de recursos: controla el acceso a los procesadores del pool (PP).

• el usuario especifica sus requerimientos (CPU, memoria, programa).

• el Gestor de Recursos le asigna un procesador como ordenador personal.

• Ventajas con respecto a Estaciones y Servidores:

• mejor utilización de recursos: muchos puntos de entrada con pocas CPUs.

• mayor flexibilidad: se pueden dedicar procesadores para expandir servicios.

• compatibilidad con el SW preexistente.

• utilización de procesadores heterogeneos.

• Incoveniente: mala respuesta interactiva: terminales conectados a una linea serie.

• Ejemplo: CDCS, basado en el anillo de Cambridge.

4.2.3.- Miniordenadores integrados

• Basado en máquinas multiusuario.

• El usuario se conecta a una máquina específica.

• Enfoques históricos:

• acceso remoto mediante copias: de esta forma no se mezclan los espacios de nombramiento locales, pero no es distribuido.

• sistemas de ficheros contiguos:

• superdirectorio virtual: "/../", esquema de nombramiento global.

• no es distribuido: el nombre de los ficheros depende de su ubicación (máquina A, B, C????)

• ejemplo: NETIX, Newcastle Connection.

• Locus (UCLA):

• cada ordenador mantiene su autonomía (conjunto completo de SW estándar, aplicaciones y servicios propios).

• esquema de nombramiento global: acceso independiente de la ubicación, posibilidad de migración de ficheros entre máquinas.

4.2.4.- Modelos híbridos

• AMOEBA, de la Universidad Libre de Amsterdam.

• Consiste en: sistema de estaciones y servidores más un pool de procesadores.

• Funcionalidad mixta:

• estaciones para las aplicaciones interactivas.

• procesadores variados.

• servidores especializados.

• Características:

• Kernel pequeño: planificación y paso de mensajes.

• el SO corre como procesos de usuario.

• servicio de gateway a WAN.

• gestión del pool mediante un servidor de carga y otro de procesos.

• Ventajas:

• recursos de procesamiento ajustados a las necesidades del usuario.

• ejecución concurrente.

• acceso a través de terminales (precio).

Capítulo 4.3.- Requisitos y características de un SOD.

4.3.1.- Características

4.3.1.1.- Compartición de recursos (resource sharing)

• Definición de recurso: rango de "cosas" que pueden ser compartidas en un sistema distribuido, de forma útil. Desde componentes HW (disqueteras, impresoras) a entidades SW (ficheros, ventanas, bases de datos).

• Dispositivos HW: se comparten para reducir costes.

• SW: compartición de herramientas de desarrollo, ficheros, facilidad de actualización.

• Groupware.

• Gestor de recursos: módulo SW que gestiona un conjunto de recursos de un tipo particular. Para cada conjunto de recursos existe un número de políticas diferentes, pero tambien características comunes.

• Modelos de gestión de recursos:

• Modelo Cliente/Servidor

• UNIX.

• Necesidad de centralización de gestión.

• Necesidad de diferenciar entre servidor y servicio.

• Inconveniente: algunas aplicaciones pueden requerir una cooperación más directa entre clientes.

• Modelo orientado a objetos

• Cada recurso es visto como un objeto, unívocamente identificado, y móvil.

• Ventajas: simplicidad, flexibilidad. Los objetos pueden actuar como usuarios de recursos y como gestores de recursos.

• Se necesita un gestor de objetos: colección de procedimientos y datos que caracterizan una clase de objetos.

• Ejemplos: Argus, Amoeba, Mach.

4.3.1.2.- Apertura (openness)

• Definición: permite a un SOD expandirse en múltiples direcciones.

• Un sistema puede ser abierto o cerrado con respecto a HW o SW:

• La apertura se consigue especificando y documentando las interfaces fundamentales del sistema y poniéndolos disponibles a los desarrolladores, para, finalmente, estandarizar esas interfaces:

• UNIX: los recursos del SO se acceden mediante System Calls, totalmente documentadas y disponibles a los desarrolladores. La apertura de UNIX está inherentemente asociada a sus System Calls.

4.3.1.3.- Concurrencia (concurrency)

• Varios procesos existen al mismo tiempo en una máquina: ejecución concurrente.

• Con un solo procesador, esto implica planificación de CPU.

4.3.1.4.- Escalabilidad (scalability)

• Definición: capacidad de un sistema de operar de manera efectiva independientemente de su tamaño.

• La existencia de crecimientos en el sistema no implican modificaciones de la arquitectura básica del mismo.

• Distribución de cargas. Se trata de evitar las siguientes centralizaciones:

• Técnicas empleadas:

• replicación de datos.

• caching.

• duplicación o complemento de tareas entre servidores.

4.3.1.5.- Tolerancia a Fallos (fault tolerance)

• Un fallo HW o SW puede producir inconsistencias o pérdidas de servicio.

• Dos ideas: redundancia del HW, programas de recuperación de fallos.

• Redundancia: arquitecturas de servidores en HOT STANDBY: muy caro (cada vez menos).

• Redireccionamiento de servidores (yahoo).

• Roll-back: transacciones atómicas.

• Sistemas de Alta disponibilidad (HA).

4.3.1.6.-Transparencia (transparency)

• Definición: abstracción que permite al usuario o al desarrollador desconocer los diferentes componentes del sistema distribuído.

• La separación de componentes en inherente en un sistema distribuído => acceso a recursos es un problema.

• Tipos de transparencia (ANSA Reference Manual, ISO's Reference Model for Open Distributed Processing, [ISO RM ODP]:

• Las más importantes: t. de acceso y de lugar: TRANSPARENCIA DE RED.

4.3.2.- Requisitos de diseño

Los componentes y arquitecturas del sistema utilizadas para cumplir con las características mencionadas arriba necesitan a su vez cumplir con unos requisitos:

4.3.2.1.- Metas en el diseño:

4.3.2.2.- Requisitos básicos de diseño:

• Capas en un sistema centralizado.

• En un SD, los servicios deben ser fácilmente añadidos y escalables, por lo que el Kernel será la única parte rígida, restringiéndose a:

• alojamiento y protección de memoria.

• creación de procesos y planificador.

• comunicación entre procesos (IPC).

• manejo de dispositivos periféricos.

• Categorías principales de SW en un SD. De áquí se distinguen tres categorías:

• Kernel (OS Kernel Services). Ya comentado anteriormente. Se ha llegado al desarrollo de microkernels: el conjunto mínimo de servicios y recursos a partir de los cuales el resto de servicios se pueden construir. De esta forma se consigue el máximo nivel de APERTURA.

• Servicios abiertos (Open Services): facilidades añadidas. Generalmente se ofrece el conjunto de servicios típicos de un sistema UNIX (servicio de ficheros, correo electrónico...).

• Soporte para programación distribuida (distributed programming support): por ejemplo, RPC.

• Alojamiento de la carga de trabajo:

• Modelo de pool de procesadores.

• Aprovechamiento de "idle workstations".

• Multiprocesadores de memoria compartida. Cada procesador ejecuta lo que va pudiendo.

• Mantenimiento de la consistencia:

• c. de actualización: problema que aparece cuando varios procesos acceden y actualizan datos constantemente. Es necesaria la atomicidad de operaciones, mediante mecanismos de exclusión mutua.

• c. de replicación: la réplica de datos ha de efectuarse óptimamente.

• c. de caché.

• c. de fallos: en un sistema centralizado, si falla, todo falla. En uno distribuido, existirán diferentes MODOS DE FALLOS (failure modes), donde si el sistema en conjunto falla, en cada máquina su proceso se encontrará en un estado determinado: transacciones atómicas.

• c. de reloj: debido al ancho de banda de las redes, la sincronización entre máquinas no es obvia. Afortunadamente, este requerimiento en SSDD no suele ser absoluto, sino relativo a orden.

• c. de interfaz de usuario.

4.3.2.3.- Requerimientos del usuario:

• Funcionalidad: qué debería hacer el sistema por los usuarios.

• Requerimiento mínimo: la funcionalidad provista por un sistema distribuído no debería de ser menos que el obtenido por un sistema aislado.

• Requerimiento máximo: mejora sobre los servicios provistos por cualquier ordenador personal por sí sólo, a través de:

• compartición a través de la red, y especialización de recursos (p.e. servidor de impresión).

• aplicación de las ventajas de la distribución al nivel de APIs (application programming interface), para que puedan ser implementadas.

• Opciones de migración de computación centralizada multiusuario a computación distribuída:

• Adaptar Sistemas Operativos ya existentes: adición de servicios, tipo NFS.

• Migrar a un SO totalmente nuevo: el SW anterior es inútil.

• Emulación: migrar a un SO nuevo, pero con características de emulación de uno o más SSOO ya existentes. Ejemplos: Mach, Chorus. Problema: prestaciones.

• Reconfiguración: necesidad del sistema para adaptación a cambios sin causar discapacidad a la provisión de servicio existente.

• Diseño de un sistema distribuído en relación a la escala temporal:

• Cambios a corto plazo:

• una máquina, red, componente... estropeada se reemplaza por otra.

• la carga de trabajo se ha de reequilibrar, pasándo procesos a máquinas libres.

• la comunicación de red se minimiza.

• Cambios a medio y largo plazo:

• Asignación de nuevos roles a máquinas.

• Adición de nuevas máquinas, o nuevos tipos.

Calidad de servicio: temas de prestaciones, confianza y seguridad.

Tema 5.- Diferentes Sistemas Distribuidos

[Introducción][El Kernel][Procesos y Threads][Dominios de Protección][Comunicación e Invocación][Memoria Virtual][Sistemas Distribuidos de Tiempo Real][Un caso práctico: Sun Spring][Ejercicios]




5.1.- Introducción

• La base de construcción de un SD es su Microkernel.

• En este capítulo el concepto de SOD es purista (UNIX no puede gestionar procesos en red de forma transparente, por ejemplo).

• Un kernel será al fin y al cabo un gestor de recursos.

• Qué requerimos de un kernel de un SD:

• Encapsulamiento: conjunto de operaciones que satisfagan las necesidades de sus clientes. Los detalles de gestión de memoria han de permanecer ocultos.

• Procesamiento concurrente: acceso concurrente a recursos por parte de los usuarios.

• Protección.

• Invocaciones: acceso a un recurso encapsulado por parte del cliente, ya sea mediante una System Call, o una RPC, por ejemplo.

• Tareas relativas a invocaciones:

• Name resolution: el servidor o kernel que gestiona un recurso ha de ser localizado a partir del identificador del recurso.

• Comunicación: los parámetros de entrada de la invocación, así como el resultado de salida, han de poder ser transmitidos a través de la red de comunicaciones.

• Planificación:

5.2.- El Kernel

5.2.1.- Protección en un Kernel

• ¿Qué es un kernel?: es un programa cuyo código se ejecuta con total privilegio de acceso sobre los recursos físicos en el host: gestión de memoria, registros de proceso, etc.

• Protección: el kernel puede preparar espacios de direcciones separados, para evitar que un proceso pueda acceder a datos restringidos de otro. Un proceso no puede acceder a memoria fuera de su espacio de direcciones.

• El kernel tiene un espacio de direcciones propio.

• El kernel ejecuta sus procesos en modo supervisor, y se las arregla para que cualquier otro proceso de usuario tenga un modo no privilegiado (unprivileged).

• El kernel gestiona la invocación de recursos mediante sus system call traps: al invocar este tipo de llamadas, una instrucción máquina, llamada TRAP, pone el procesador en modo de supervisión y cambia al espacio de direcciones del kernel, y es forzado a utilizar un "handler" provisto por el kernel, de forma que ningún otro usuario pueda conseguir control del HW.

5.2.2.- Kernels monolíticos y microkernels

• Un SD tiene como una de sus ventajas principales la capacidad de adición de nuevos servicios sin prejuicio de los ya existentes.

• Se puede obtener un grado de apertura en sistemas tradicionales como UNIX, añadiéndoles ciertas características.

• Por ejemplo: OSF DCE (Distributed Computing Environment of the Open Software Foundation).- es una arquitectura SW para computación distribuida, diseñada para funcionar en diferentes kernels, como UNIX, VMS, OS/2, etc. Incluye estándars para RPC, servicios de name binding, servicios de sincronización de tiempo, servicios de seguridad y servicios de threads.

• Pero, ¿qué ocurre con la apertura de servicios del propio kernel?

• Tipos de kernel:

• Kernels monolíticos:

• Como el de UNIX.

• Es masivo: realiza todas las funciones básicas de un SO.

• Ocupara más o menos 1 Mb de código fuente y datos.

• No diferenciado: no está codificado de forma modular.

• Intratable: el rediseño de SW es complicado.

• Un kernel monolítico puede estar diseñado para funcionar como SOD (Sprite), pero tendría problemas ante ajustes.

• Microkernels:

• El kernel solo provee las abstracciones básicas (procesos, memoria, IPC).

• El resto de los servicios son provistos por servidores que se cargan dinámicamente en aquellas máquinas que necesitan ofrecer esos servicios.

• Generalmente, estos servicios serán ejecutados como procesos del usuario; cuando se necesite un acceso directo a HW, existirán system calls especiales que permitan manejar interrupciones del sistema. Como contrapartida, el microkernel del Chorus permite que los servicios se carguen dinámicamente, o en el espacio de direcciones del kernel, o en el del espacio de usuario.

• Papel del microkernel:

• Entre el HW y los denominados subsistemas.

• Puede haber más de un interfaz de llamadas al sistema, es decir, más de un "Sistema Operativo". Por ejemplo, las implementaciones de Unix y OS/2 por encima de Mach.

• Comparación:

• Ventajas del microkernel:

• Apertura.

• Modularidad inherente (para un kernel monolítico, se puede forzar mediante técnicas de ingeniería de SW, como en MULTICS, o de orientación a objetos, como en Choices).

• Más fácil de programar, libre de bugs.

• Pocas personas son necesarias para la implementación.

• Más fácil de mantener.

• Ventajas del kernel monolítico:

• Eficiencia en invocación de operaciones: el cambio de espacio de direcciones es caro, y en un kernel monolítico, la mayoría de las operaciones se pueden realizar desde el kernel.

5.2.3.- Arquitectura de un microkernel

• Diseñado para ser portable => lenguaje de alto nivel (C, C++, Java).

• Diseño en capas: acceso a recursos HW en capa más profunda (manipulación del procesador, gestión de memoria, registros, gestión de interrupciones y traps, etc).

• Componentes principales:

• Gestor de procesos (process manager): creación y manipulación de procesos. Generalmente existirá algún subsistema por encima de mejora de la utilidad.

• Gestor de threads (thread manager): creación, sincronización y planificación de threads. La política de planificación se puede dejar a módulos superiores.

• Gestor de comunicaciones (communication manager): comunicación entre threads de diferentes procesos locales, o incluso en procesos remotos. A veces, es necesario un soporte adicional superior.

• Gestor de memoria (memory manager): gestión de recursos de memoria física, caché, etc.

• Supervisor: "dispatcher" de interrupciones, traps y excepciones.

5.3.- Procesos y Threads

• Mach y Chorus mejoran la copia del espacio de direcciones, mediante el método copy-on-write: cuando se crea un proceso hijo, no se duplica el espacio de direcciones, sino que el hijo apunta al del padre, hasta que el hijo intenta modificarlo.

5.4.- Dominios de Protección

• Un dominio de protección (protection domain) es un entorno de protección compartido por una colección o conjunto de procesos: es un conjunto de pares {recurso, derechos}. Por ejemplo, el dominio de protección de un proceso en UNIX se determina con los identificadores de usuario y de grupo.

• Es una abstracción. Existen dos implementaciones básicas:

• Capacidades (capabilities): conjunto de capacidades por proceso.

• Listas de control de acceso (access control list): cada recurso guarda una lista, dando los dominios que tienen acceso al recurso, y las operaciones permitidas.

5.5.- Comunicación e Invocación

• A tratar en el tema: Remote Procedure Call.

5.6.- Memoria Virtual

• Diferencia con respecto a la memoria virtual de un SO convencional: el interfaz de almacenamiento de back-up es un servidor en vez de un disco local.

• La memoria virtual permite incrementar el número de procesos simultaneos, mediante swapping en cambios de contexto.

• External pager (gestor de memoria externo): la información de paginación se almacena en el servidor, por lo que el paginador habrá de ser externo al lugar donde el proceso se crea. El servidor mantiene objetos de memoria (memory objects), regiones del espacio de direcciones del servidor que serán "mapeadas" al proceso remoto (por ejemplo, los datos de un fichero). Después del mapeo, existirá un paso de mensajes entre el kernel creador del proceso y el servidor externo para el tratamiento de la paginación.

5.7.- SSDD de Tiempo Real

5.7.1.- Introducción

• La corrección de su ejecución no sólo depende de la secuencia lógica de instrucciones ejecutadas, sino de cuándo son ejecutadas.

• Cuando aparece un estímulo, el sistema debe responder de una cierta forma antes de un tiempo determinado; el hecho de que responda correctamente, tras el tiempo necesario, se considera como un fallo del sistema.

• Ejemplos: lector de Compact-Disc, mando y control, control aéreo...

• Tipos de estímulos:

• Periódicos: ocurren regularmente cada delta segundos.

• Aperiódicos: estímulos recurrentes, pero no regulares.

• Esporádicos: inesperados.

• Tipos de sistemas de tiempo real:

• Duros: restricciones inflexibles.

• Blandos: restricciones flexibles.

5.7.2.- Factores de diseño

• Sincronización de relojes.

• Orientación a eventos vs. Orientación a tiempo

• Orientación a eventos: cuando un evento ocurre, se detecta mediante algun sensor, y se lanza una interrupción a la CPU.

• Problema: puede fallar si existe una gran carga (muchas alarmas a la vez).

• Solución: correlación de alarmas.

• Orientación a tiempo: existe una interrupción de reloj cada delta segundos.

• Problema: elección de delta.

• Predicción: es necesario saber desde la fase de diseño cómo se tiene que comportar EXACTAMENTE el sistema en cada situación: análisis estadístico del comportamiento.

• Tolerancia a fallos.

• Soporte de lenguaje:

• el tiempo máximo de ejecución de cada tarea ha de poder ser computada en tiempo de compilación => no se permiten bucles while (sólo for con parámetros constantes); no se permite recursividad tampoco.

• esto nos lleva a la necesidad de lenguajes de programación específicos: Ada, por ejemplo.

• una característica concreta: variable clock, para poder escribir: every (25 msec) { ... }

5.7.3.- Planificación en Tiempo Real

• Los sistemas en tiempo real se programan generalmente como una colección de tareas cortas (procesos o threads), cada una con una función bien definida y un tiempo de ejecución.

• Problema: orden de ejecución => se necesitan unos algoritmos de scheduling, caracterizados por:

• Tiempo real DURO contra tiempo real BLANDO.

• Planificación "preemptive" contra "nonpreemptive".

• Dinámica contra estática: una planificación dinámica, ante la llegada de una nueva tarea, ve si ha de ejecutarla automáticamente o continuar ejecutando la tarea actual. Una planificación dinámica no preemptiva tan sólo guardaría información de que otro proceso esta en estado de ejecución.

• Centralizada contra descentralizada: en una planificación descentralizada, cada procesador decide lo que hay que hacer con sus procesos.

Tema 6.- Comunicación en Sistemas Distribuidos

[Modelo Cliente/Servidor]

6.1.- Modelo Cliente/Servidor

[Características][Tipos de sistemas C/S][Pesadez C/S][Arquitectura 2, 3-tier]["Star-Trek"][Arquitectura]

6.1.1.- Características de un sistema Cliente/Servidor

• Cómo podemos diferenciar entre un sistema C/S y un sistema sencillamente conectado en red. Todo es muy parecido a las características de los Sistemas Distribuidos, aunque especializándonos un poco.

• Servicio

• el cliente es un consumidor de servicios.

• el servidor es un proveedor de servicios.

• el modelo C/S nos da una separación limpia de funcionalidad basada en la idea de SERVICIO.

• Recursos compartidos

• Protocolos asimétricos

• relación de muchos a uno.

• los clientes inician el diálogo, pidiendo un servicio.

• los servidores esperan de forma pasiva.

• Transparencia de localización

• "Mix-and-match"

• mezcla de plataformas, SSOO, etc.

• Comunicación basada en el paso de mensajes.

• Encapsulamiento de servicios

• petición de servicio = caja negra. El servidor es el especialista, no el cliente, por lo que no ha de tener conocimiento alguno en el CÓMO, sino en el QUÉ.

• Escalabilidad

• Horizontal: adición/eliminación de clientes, sin impacto.

• Vertical: migración a servidores más grandes, o a multiservidores.

• Integridad

6.1.2.- Tipos de Sistemas Cliente/Servidor

• Servidores de ficheros

• compartición de fichero (documentos, imágenes, BLOBS, ...).

• Servidores de BBDD

• el servidor es quien procesa la consulta y devuelve los datos => el Cliente es ligero (Quest, Paradox), no como el servidor de fichero.

• Servidores de transacciones

• el cliente invoca "procedimientos remotos" que residen en el servidor con una base de datos SQL. Esos PRs ejecutan un conjunto de queries SQL => por red sólo se pasa un mensaje de petición y otro de repuesta => On Line Transaction Processing: OLTP.

• se suele utilizar para sistemas críticos (1.3 segundos de tiempo medio de respuesta).

• requieren: integridad, seguridad.

• Tipos:

• TP Lite: basado en procedimientos almacenados.

• TP Heavy: TP Monitors.

• Servidores Groupware

• Gestión de información semi-estructurada (texto, imágenes, correo, bulletin boards, flujo de trabajo).

• Ej: Lotus Notes.

• Servidores de Objetos

• La aplicación C/S se escribe como un conjunto de objetos comunicantes.

• Los objetos cliente se comunican con los objetos servidores mediante un ORB (Object Request Broker):

• el cliente invoca un método sobre un objeto remoto.

• el ORB localiza la instancia de esa clase.

• el ORB invoca el método pedido.

• el ORB devuelve los resultados al objeto cliente.

• Los objetos servidores han de proveer soporte de Concurrencia y Compartición.

• Ejemplos de OMG CORBA:

• IBM's SOM 3.0.

• Sun's NEO.

• HP's ORBPlus.

• Iona's ORBIX.

• Visigenic's Visibroker.

• Aparte: Microsoft's DCOM.

• Servidores Web

• Idea básica: clientes universales, portables y pequeños que hablan con servidores pesados: un servidor Web devuelve documentos cuando un cliente los pide.

• Comunicación C/S mediante un sistema parecido al RPC: protocolo HTTP.

• Primer paso hacia la red objetual (Object Web).

6.1.3.- "Pesadez" Cliente/Servidor

• Un modelo Cliente/Servidor puede distribuir la carga entre el C y el S:

• Cliente Pesado: más tradicional: servidores de fichero (ejercicio).

• Servidor Pesado: groupware, Web, transacciones.

• Los objetos distribuídos dependerán.

• Las dos ideas pueden cooperar: groupware "all-in-one": servidores de ficheros, transacciones y objetos.

• (transparencia 6.4)

6.1.4.- Arquitectura 2, 3-tier

• Cuáles son las unidades funcionales básicas en una aplicación:

• Interfaz de usuario.

• Lógica.

• Datos compartidos.

• Arquitectura 2-Tier

• la lógica está "enterrada" dentro del GUI del cliente, o de la BBDD del servidor, o en ambos.

• Ejemplos: servidores de ficheros, s. de BBDD con procedimientos almacenados.

• Arquitectura 3-Tier

• la lógica (y/o sus procesos) viven en la capa intermedia.

• Ventajas:

• escalabilidad.

• robustez.

• flexibilidad.

• pueden integrar datos de diferentes fuentes.

• Ejemplos: TP Monitors, s. de objetos distribuídos, s. Web.

6.1.5.- Visión "Star-Trek"

• El futuro está ya aquí (tabla comparativa).

• Qué necesitamos para conseguirlo:

• Alto grado de procesamiento de transacciones:

• transacciones anidadas entre múltiples servidores.

• transacciones seguras.

• Agentes "desarraigados": Java, agentes móviles, scripts multiplataforma (Javascript, Perl)

• Entidades inteligentes de autogestión:

• No podemos tener un administrador por cada máquina de 60.000 pts.

• Middleware inteligente: idea de monoprocesador virtual.

• Estas son necesidades de alto nivel, y no todas las apps. pueden o tienen que conseguirlo.

6.1.6.- Arquitectura

• Bloque Cliente

• tiene GUI/OOUI.

• puede acceder a servicios distribuidos.

• generalmente, el C se encarga de lo local, dejando los temas distr. al middleware.

• ejecuta un componente del DSM (Dist. System Management): desde un agente PC, al sistema de atención al cliente.

• Bloque Servidor

• generalmente se ejecuta por encima de algún SW servidor (p.e. NT 4.0 Server).

• Next Generation (¿actual?):

• Servidores BBDD SQL.

• TP Monitors.

• S. Groupware.

• S. de Objetos.

• S. de Web.

• Tb. ejecuta un componente DSM (desde agente PC al back-end del sistema gestor).

• Middleware

• se ejecuta en ambas partes.

• es el sistema nervioso de la infraestructura C/S.

• Se divide en:

• pila de transporte

• NOS

• "Service-specific" Middleware

• Tb. tiene un componente DSM.

6.1.6.1.- Pila de Transporte

• Stack sandwich

• provee los "ganchos" de unión de protocolos de diferentes vendedores en un SO.

• Los nuevos SSOO han de incoporar muchos protocolos, redirectores y APIs => interfaces BIEN DEFINIDOS, que escondan esos sistemas propietarios.

• Driver lógico de red

• provee un único interfaz para todos los adaptadores de red. Es un interfaz entre el adaptador de red y las pilas de transporte.

• lo último que quieren los fabricantes de pilas de transporte es tener que escribir un interfaz para cada posible pila.

• Ejemplos: Microsoft/3Com's NDIS, Novell's ODI.

• APIs independientes de transporte

• permiten a los desarrolladores "enchufar" sus programas en un único interfaz (que soporta protocolos múltiples).

• Ejemplos:

• Sockets.

• TLI (transport layer interface) utilizado en Netware, y algo en Unix.

• CPI-C: API punto-a-punto. En SNA y TCP/IP.

• Name Pipes: por encima de NetBIOS, IPX/SPX y TCP/IP.

• Emparejador de protocolos (protocol matchmaker)

• Permite que applicaciones escritas para un transporte específico (SNA, por ejemplo) se pueda ejecutar en otros (TCP/IP, IPX/SPX).

• Ejemplo: LotusNotes para NetBIOS => SNA sin cambiar una línea de código.

• Herramienta: IBM's AnyNet.