NOTAS SOD

Published on February 2017 | Categories: Documents | Downloads: 51 | Comments: 0 | Views: 257
of 34
Download PDF   Embed   Report

Comments

Content

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Sistemas Operativos Distribuidos
1. Introducción
De 1945 a 1985, las computadoras eran grandes y caras. Sin embargo a mitad de la década de los 80’s, dos avances tecnológicos comenzaron a cambiar esta situación: 1. Desarrollo de poderosos microprocesadores. 2. Invención de redes de área local de alta velocidad (LAN) y redes WAN. Un sistema distribuido consiste de una colección de computadoras autónomas conectadas mediante una red y equipadas con software de sistemas distribuidos. El software de un sistema distribuido habilita a las computadoras para coordinar sus actividades y compartir los recursos del sistema. Los usuarios de un sistema distribuido bien diseñado deben percibir una sola computadora y no un sistema implementado por muchas computadoras en diferentes lugares. Definición. Un sistema distribuido es una colección de computadoras independientes que aparecen ante los usuarios del sistema como una única computadora. Esta definición tiene dos aspectos: 1. El hardware: las máquinas son autónomas. 2. El software: los usuarios piensan que el sistema es como una única computadora. Aplicaciones: - Una red de computadoras con una pila de procesadores - Una aerolínea - Fábrica de robots - Un banco con sucursales - Internet - Multimedia y conferencias Sistema operativos distribuidos - Amoeba - Mach

- Chorus - Clouds - Plan9 - Mosix - OpenMosix Ventajas de los sistemas distribuidos con respecto de los centralizados • Economía. Los microprocesadores ofrecen mejor proporción precio/rendimiento que los mainframes, pues se pueden reunir un gran número de CPU’s baratos en un mismo sistema y dado el avance tecnológico de estos, se puede dar un mejor rendimiento que un solo mainframe. • Velocidad. Un sistema distribuido puede tener mayor poder de cómputo que un mainframe. • Distribución inherente. Algunas aplicaciones utilizan máquinas que están separadas a cierta distancia. Por ejemplo, trabajo cooperativo apoyado por computadora, juegos cooperativos apoyados por computadora. • Confiabilidad. Si una máquina se descompone, el sistema puede sobrevivir como un todo. • Crecimiento por incrementos. Se puede añadir poder de cómputo en pequeños incrementos. Ventajas de los sistemas distribuidos con respecto a las computadoras personales aisladas. • Datos compartidos. Permiten que varios usuarios tengan acceso a una base de datos común. • Dispositivos compartidos. Permiten que varios usuarios compartan periféricos caros como scanners o impresoras a color. • Comunicación. Facilita la comunicación de persona a persona; por ejemplo, mediante correo electrónico, FAX, chats, foros, etc. • Flexibilidad. Difunde la carga de trabajo entre las máquinas disponibles en la forma más eficaz en cuanto a costos. Además de las ventajas anteriores, podemos sumar dos más en forma general:

1

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Sistema de ficheros con raíz única. Este sistema de ficheros hace que la administración sea más sencilla (no hay que administrar varios discos independientemente) y deja a cargo del sistema varias de las tareas. Capacidad de comunicación de procesos y de intercambio de datos universal. Permite enviar señales a cualquier proceso del conjunto de computadoras, asimismo permite trabajar conjuntamente con cualquier proceso e intercambiar datos. Por lo tanto será posible tener todos los procesos trabajando en un mismo trabajo. Desventajas de los Sistemas Distribuidos La principal desventaja de estos sistemas es la complejidad que implica su creación. La Economía, la Velocidad y la Distribución de máquinas no tienen problemas de implantación porque son inherentes a los sistemas distribuidos. Confiabilidad (alta disponibilidad). Se puede conseguir alta disponibilidad pues al tener varios nodos independientes, hay menos posibilidades de que caigan todos a la vez. Para esto hay que implantar los mecanismos necesarios para que cuando una máquina caiga, se sigan dando todos los servicios. Esto nos lleva a la necesidad de actualizar todas las réplicas de un servicio. También se tiene que disponer de los mecanismos adecuados para que el nodo que ve el fallo del servidor busque los servidores alternativos en busca de la información que necesita. Además también se debe disponer de los mecanismos necesarios para que los nodos que han caido, cuando vuelvan a conectarse puedan continuar con su trabajo normalmente. Escalabilidad. Al incrementarse el número de nodos aumentan las comunicaciones, por lo tanto se debe diseñar un sistema lo más escalable posible. Por ejemplo elegir una comunicación todos contra todos no es una solución escalable. Comunicación. Estos sistemas tienen más necesidad de comunicación que los sistemas normales, por lo tanto tenemos que crear nuevos métodos de comunicación lo más eficientes posibles.

Sistemas de ficheros con raíz única. Tenemos que independizar los sistemas de ficheros distintos de cada uno de los nodos para crear un sistema de ficheros general. Un problema que nos encontramos en sistemas tipo UNIX es por ejemplo cómo manejar los directorios /proa y /dev; los PID’s deberían ser independientes para cada nodo, pero además se incluye información como /proa/cpuinfo, /proa/meminfo, etc. Entonces debería crearse un directorio para cada nodo para evitar problemas de compatibilidad. En el caso de /dev, no hay problema si todos los dispositivos son distintos, en caso contrario se debe diseñar un nuevo esquema para nombrar los dispositivos. Capacidad de comunicación de procesos y de intercambio de datos universal. Para conseguir este objetivo necesitamos una forma de distinguir unívocamente cada proceso del conjunto de computadoras. Redes. La red se puede saturar o causar otro problemas. Seguridad. Como los datos son fáciles de compartir entonces también se puede tener acceso a datos con los que no se tiene nada que ver.

1.1 Conceptos de Hardware
Sistemas fuertemente acopladas. El retraso que se experimenta el enviar un mensaje de una computadora a otra es corto y la tasa de transmisión de los datos (número de bits por segundo que se pueden transferir) es alta. Sistema débilmente acoplado. El retraso es grande y la tasa de transmisión es baja. Los sistemas fuertemente acoplados tienden a utilizarse más como sistemas paralelos. Los sistemas débilmente acoplados tienden a utilizarse como sistemas distribuidos.

Clasificación de Flynn (1972).

2

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Considera dos características el número de flujos de instrucciones y el número de flujos de datos. SISD (single instruction, single data) Computadoras personales. SIMD (single instruction, multiple data) MISD (multiple instruction, single data) MIMD (multiple instruction, multiple data) Todos los sistemas distribuidos son MIMD. Las computadoras MIMD se divide en Multprocesadores y Multicomputadoras.

ejecutivo o maestro ejecuta el sistema operativo y maneja la E/S. Los otros procesadores no pueden manejar las E/S y se los llama attached processors (APs). Los procesadores attached ejecutan código bajo la supervisión del procesador maestro. (Ejemplo Sequent S-81)

El modelo NUMA
La memoria está fisicamente distribuida entre todos los procesadores, se llaman memorias locales. Es más rápido acceder un dato en la memoria local, para acceder información en una memoria remota existe una demora debida a la red de interconexión(BBN TC-2000 Butterfly). Además de estas memorias distribuidas se puede agregar memoria globalmente accesible por todos los procesadores. En este caso existen tres patrones de acceso a memoria: - el más rápido es acceder a memoria local - un poco más lento es acceder la memoria global - y por último el más lento de todos es acceder la memoria remota de otro procesador (ejemplo Cedar de la universidad de Illinois)

Multiprocesadores.
Existen dos categorías de computadoras paralelas. Estos modelos físicos se diferencian en el hecho de tener memoria compartida o distribuida.

Multiprocesadores de memoria compartida.
Existen tres modelos que se diferencian en como la memoria y los periféricos se comparten o distribuyen. - UMA (uniform memory access) - NUMA (no uniform memory access) - COMA (cache-only memory access)

El modelo COMA
El modelo COMA utiliza solo memoria de tipo caché (ej. KSR-1 de Kendall Square Research). Son un caso particular de la NUMA en el cual la memoria distribuida se convierte en memorias caché. No existen jerarquías de memoria en cada nodo procesador. Todas las caches forman un espacio de direccionamiento global. El acceso a una cache remota se facilita a través de los directorios distribuidos de cache los cuales en ciertas arquitecturas pueden estructurarse en forma jerárquica. Una de las mayores desventajas que poseen estos multiprocesadores es la falta de escalabilidad debido a la centralización de la memoria compartida.

El modelo UMA
La memoria se comparte uniformemente entre los procesadores. Todos tienen igual tiempo de acceso a todas las palabras de memoria. Cada memoria puede tener una caché privada. Los periféricos también se comparten en la misma forma. Se les denomina sistemas fuertemente acoplados. Para coordinar los eventos paralelos, la sincronización e intercomunicación entre procesos se utilizan variables en la memoria común. Cuando todos los procesadores tienen igual acceso a todos los periféricos el sistema se denomina simétrico (MP). En un multiprocesador asimétrico solo uno o un subconjunto de los procesadores tienen la capacidad ejecutiva. El procesador

3

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Multicomputadoras
Consisten de múltiples computadoras llamadas a menudo nodos interconectados por una red de paso de mensajes. Cada nodo es un sistema autónomo con su procesador, su memoria y a veces periféricos de E/S. La red de paso de mensajes provee un mecanismo de comunicación punto a punto. Todas las memorias locales con privadas y son solo accesibles por el conjunto de procesadores locales del nodo, por esta razón se las denomina máquinas NORMA (no remote memory access).

El rango de transferencia de datos es similar a B-ISDN , utiizan ATM como técnica de switcheo Con B-ISDN y ATM, se pueden trabajar sistemas distribuidos en redes WAN. Protocolo Conjunto de reglas y formatos usados para la comunicación entre procesos para desempeñar una tarea. Un protocolo tiene dos partes importantes: 1. Una especificación de la secuencia de mensajes que debe ser intercambiado 2. Una especificación del formato de datos de los mensajes

Tipos de red
Las redes de computadoras pueden ser divididas en dos clases: Redes de área local (LAN) Mensajes de alta velocidad Los nodos se encuentran repartidos en un solo edificio o campus. Son apropiadas para sistemas distribuidos aunque algunas aplicaciones multimedia necesitan un mayor ancho de banda Redes de área amplia (WAN) Mensajes a baja velocidad Las computadoras se encuentran separadas a grandes distancias Las computadoras que con interconectadas por una WAN son llamadas computadoras host, estas pueden estar ubicadas en diferentes ciudades, países o continentes Es necesario el ruteo de paquetes El tiempo de transmisión depende de la ruta Una tercera clase son las redes de área metropolitana (MAN) Utilizan cable de fibra óptica Los nodos se encuentran ubicados en una misma ciudad, y se transmite video, voz y otros datos a una distancia de alrededor de 50km

1.2 Conceptos de Software
En un sistema distribuido el software es más importantes que el hardware, pues la imagen y la forma d pensar de los usuarios la determina el software del sistema operativo. Es posible distinguir dos tipos de sistemas operativos para multiprocesadores o multicomputadoras: • Software débilmente acoplado. Permite que las máquinas y los usuarios en un sistema distribuido sean independientes entre sí en lo fundamental, pero que interactúen cuando sea necesario. • Software fuertemente acoplado. Las máquinas interactúan entre sí (y los usuarios) para llevar a cabo las tareas en forma conjunta.

Sistemas operativos de redes
Software débilmente acoplado en hardware débilmente acoplado. Por ejemplo una red de estaciones de trabajo conectadas mediante una LAN. Cada usuario tiene una estación de trabajo para uso exclusivo y los comandos se ejecutan normalmente de manera local. Aunque existen comandos que permiten que un usuario se conecte de forma remota a otra estación de trabajo, entonces su máquina se convierte en terminal de otra máquina. Esto no es muy conveniente.

4

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Una mejora es tener un sistema de archivos global accesible desde todas las estaciones de trabajo (compartido), utilizando los llamados servidores de archivos. Estos utilizan un sistema jerárquico de archivos (directorio raíz, subdirectorio y archivos). Las estaciones de trabajo pueden importar o montar estos sistemas de archivos. Por lo tanto cada cliente tiene un punto de vista distinto del sistema de archivos. El sistema en el que cada máquina tiene un alto grado de autonomía y existen pocos requisitos a lo largo de todo el sistema, se llama sistema operativo de red.

Sistemas realmente destribuidos Software fuertemente acoplado en hardware débilmente acoplado (multicomputadoras).
Objetivos: • Hacer creer a los usuarios que toda la red de computadoras es un sistema de tiempo compartido, a esta propiedad algunos autores le llaman la imagen de único sistema Algunos otros autores dicen que un sistema distribuido es aquel que se ejecuta en un conjunto de máquinas enlazadas mediante una red pero que actúan como un uniprocesador virtual. Conclusión. Los usuarios no deben darse cuenta de la existencia de varios CPU en el sistema.

Características de los sistemas distribuidos
Algunas de las características de los Sistemas Distribuidos son: • Recursos compartidos. Discos, impresoras, archivos, bases de datos y otros objetos. • Manejador de recursos. Denota un módulo de software que maneja un conjunto de recursos de un tipo particular. Incluye provisión de nombres, maneja direcciones y coordina los accesos concurrentes.

Los usuarios de recursos se comunican con el manejador de recursos para accesar los recursos compartidos del sistema. Para realizar la comunicación se puede emplear alguno de los siguientes modelos. Modelo cliente-servidor. El más comunmente usado. Los servidores actúan como manejadores de recursos. Modelo basado en objetos. Cada recurso compartido es un objeto, los cuales pueden ser movidos de cualquier lugar en la red sin cambiar sus identidades. • Mecanismo de comunicación global entre procesos • “Openness”(Abierto). En un sistema distribuido el “openness” es determinado por el grado en el cual nuevos servicios de recursos pueden ser añadidos sin interrumpir o duplicar los servicios existentes. La publicación de documentos acerca del sistema es la clave de esta característica. Los sistemas que son diseñados para soportar recursos compartidos que pueden ser expansibles en hardware y software son llamados sistemas distribuidos abiertos. Características de los sistemas distribuidos abiertos. - Sus interfaces son publicadas - Están provistos de un mecanismo de comunicación entre procesos uniforme e interfaces públicas para acceso a recursos compartidos. - Puede ser construido con hardware y software heterogéneo. • Esquema global de protección • Concurrencia. Ejecución de varios procesos al mismo tiempo. • Escalabilidad. Un sistema distribuido debe operar efectiva y eficientemente a diferentes escalas. El sistema y las aplicaciones del software no deben cambiar cuando la escala del sistema se incrementa (memoria, procesadores, canales de E/S) • Misma administración de procesos • La misma apariencia del sistema de archivos en todas partes • Sistema de archivos global • Cada núcleo debe controlar sus propios recursos locales.

5

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Sistemas de Multiprocesador con tiempo compartido
Es software y hardware fuertemente acoplado. Por ejemplo los multiprocesadores que operan como un sistema de tiempo compartido, estos utilizan una cola de ejecución. El despachador utiliza exclusión mutua mediante semáforos, monitores, etc., para evitar que dos CPU elijan el mismo proceso para su ejecución.

Transparencia de paralelismo. Las actividades pueden ocurrir en paralelo sin el conocimiento de los usuarios. Transparencia en fallas. Si falla un nodo, el usuario no debe darse cuenta y el sistema debe seguir trabajando. Transparencia de escalamiento. Se pueden agregar nodos o software y el sistema debe permanecer activo. Transparencia de acceso. El acceso a los recursos debe realizarse de la misma forma en cualquier lugar.

1.3 Aspectos del diseño
Transparencia.
La transparencia es uno de los aspectos de diseño más importantes dentro de los sistemas distribuidos, pero también uno de los más complejos. La transparencia puede darse en dos niveles: • Hacia los usuarios • Hacia los programas Es más fácil lograr la transparencia dirigida a los usuarios mediante una interfaz con comandos que aunque se ejecuten en otra máquina o hagan uso de varias máquinas, los usuarios no se dan cuenta; que lograr la transparencia para los programas, pues para accesar a archivos remotos por ejemplo deben establecer una conexión, y esto ya no es transparente. Existen distintos tipos de transparencia en un sistema distribuido. Transparencia de localización. Los usuarios no pueden indicar la localización de los recursos. Transparencia de migración.Los recursos se pueden mover a voluntad sin cambiar sus nombres. Transparencia de réplica. Los usuarios no pueden indicar el número de copias existentes. Transparencia de concurrencia. Varios usuarios pueden compartir recursos de manera automática.

Flexibilidad
Existen dos tipos de estructuras de los sistemas distribuidos. - Los que utilizan núcleo monolítico en cada máquina, es decir, cada máquina debe ejecutar un núcleo tradicional que proporcione la mayoría de los servicios. - Los que utilizan un micronúcleo, es decir, el núcleo proporciona lo menos posible y el grueso de los servicios del sistema operativo se obtienen a partir de servidores a nivel de usuario. La mayoría de los sistemas distribuidos diseñados a partir de cero utilizan micronúcleo y servidores. El micronúcleo proporciona cuatro servicios mínimos. 1. Un mecanismo de comunicación entre procesos 2. Cierta administración de la memoria 3. Una cantidad limitada de planificación y administración de procesos de bajo nivel 4. Entrada/Salida de bajo nivel Todos los demás servicios se implantan a manera de servidores a nivel de usuario. Debido a esto es fácil implantar, depurar, e instalar o modificar cierto servicios; esto no puede hacerse en un núcleo monolítico. Esto es lo que da flexibilidad al micronúcleo. Ventaja del núcleo monolítico. Rendimiento (es más rápido), aunque en la práctica esta ventaja ya no existe. (Sprite- núcleo monolítico, Amoeba-micronúcleo)

6

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Confiabilidad
Este aspecto fue uno de los objetivos originales en la construcción de sistemas distribuidos, la idea es que si alguna máquina falla, alguna otra máquina se encargue del trabajo. Pero llevar a cabo esto en la práctica es muy difícil. Existen varios aspectos dentro de la confiabilidad. • La disponibilidad, se refiere a la fracción de tiempo en que se puede usar el sistema. Esta se mejora si en el diseño no se exige el funcionamiento simultáneo de un número sustancia de componentes críticos o mediante la redundancia en el software y en el hardware. • Seguridad. Los archivos y otros recursos deben ser protegidos contra el uso no autorizado. • Tolerancia a fallas. Que el sistema pueda recuperarse de las fallas sin que el usuario se de cuenta.

Escalabilidad
El objetivo es que los métodos actuales puedan escalarse hacia grandes sistemas. El principal problema son los cuellos de botella. Por lo tanto hay que evitar componentes centralizados, tablas centralizadas y algoritmos centralizados. Se deben utilizar algoritmos descentralizados, los cuales tienen las siguientes características, que los distingue de los algoritmos centralizados: - Ninguna máquina tiene la información completa acerca del estado del sistema - Las máquinas toman decisiones solo con base en la información local. - La falla de una máquina no arruina el algoritmo - No existe una hipótesis implícita de la existencia de una regla global.

Desempeño
El mayor problema del desempeño en un sistema distribuido se da en las comunicaciones, ya que estas son lentas, la lentitud se da más en el manejo de protocolo que en la transmisión física real. Una posible solución es verificar el tamaño de grano. Si un trabajo implica gran número de pequeños cálculos que interactúa mucho, se dice que el trabajo exhibe un paralelismo de grano fino; si el trabajo implica grandes cálculos y la interacción es poca, se dice que exhibe un paralelismo de grano grueso. También es importante verificar si habrá ganancia en la ejecución de un trabajo de forma remota, ya que habrá trabajos pequeños que no deben ser ejecutados remotamente, sino de manera local. También entra en juego la tolerancia a fallas, pues si un nodo falla y estaba ejecutando un trabajo, otro nodo debe continuar con la ejecución del trabajo.

Otros temas básicos de diseño son: Nombres. Los procesos deben saber los nombres de los recursos
para accesarlos. Un nombre es resuelto cuando es trasladado a una forma tal que puede ser usado para invocar una acción sobre el recurso. En un sistema distribuido un nombre resuelto es generalmente un identificador de comunicación. Nombre. Nombres que pueden ser interpretados por usuarios y por programas Identificador. Nombre que puede ser interpretado solo por programas. Se deben seleccionar nombres apropiados a cada tipo de recurso. Todos los objetos son nombrados de manera uniforme y ocupan un solo espacio de nombres. Los nombres de los recursos deben poder ser resueltos. El esquema de nombramiento puede ser diseñado para proteger los recursos que ellos identifican de accesos no autorizados. Todos los recursos manejados por un tipo de manejador de recursos dado, deben tener nombre diferentes.

7

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Comunicación
Los componentes de un sistema distribuido están separados lógica y físicamente, así que deben comunicarse para interactuar. La comunicación entre un par de procesos involucra: - Transferencia de datos - Sincronización en la recepción y transmisión. La programación básica utiliza primitivas de programación que desempeñan acciones de paso de mensajes. El mecanismo de paso de mensajes puede ser: Síncrono o con bloqueo. El transmisor espera después de transmitir un mensaje hasta que el receptor ha desempeñado una operación de recepción. Asincrono o sin bloqueo. El proceso receptor se bloquea cuando ningún mensaje esta actualmente disponible. El proceso transmisor se bloquea si no existe mensaje a transmitir. Mecanismos de comunicación que utilizan paso de mensajes: canales, sockets y puertos. Modelos de comunicación más usados en sistemas distribuidos: cliente-servidor, comunicación en grupo para grupos de procesos cooperativos.

Mantenimiento de la consistencia
Los problemas de consistencia surgen de la separación de recursos de procesamiento y concurrencia en sistemas distribuidos. - Consistencia en la actualización - Consistencia en la replicación - Consistencia en el caché - Consistencia en las fallas - Consistencia en el reloj - Consistencia en la interfaz de usuario

Requerimientos de usuario
Los diseñadores de sistemas deben considerar las necesidades de sus usuarios potenciales

Funcionalidad
Lo que el sistema debe hacer para los usuarios Un distribuido debe mejorar los servicios proporcionados por una computadora aunado a uno o dos de los siguientes: - El compartir recursos de red lleva al acceso de una variedad de recursos - Se pueden utilizar las ventajas de la distribución en la programación de aplicaciones paralelas, interfaces de programación. Al migrar de un ambiente centralizado multiusuario o monousuario a un distribuido se tienen tres opciones: - Adaptarse a los sistemas operativos existentes - Moverse totalmente a un nuevo SO diseñado específicamente para sistemas distribuidos - Emular un ambiente distribuido

Asignación de la carga de trabajo
En un sistema distribuido existe un modelo básico llamado “workstation-server”, pero no optimiza el uso de procesamiento y memoria. Dos modificaciones se han desarrollado: a) Modelo de pila de procesadores. Los procesadores pueden ser asignados dinámicamente a las tareas de usuarios. b) Uso de estaciones de trabajo vacías. Las tareas son asignadas a estaciones de trabajo vacías o bajoutilizadas. En sistemas distribuidos es común que los servidores sean computadoras multiprocesadores con memoria compartida.

Reconfigurabilidad

8

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

-

El diseño de la escalabilidad de un sistema distribuido es importante Cambios a corto plazo en condiciones de tiempo de ejecución Evolución a mediano y a corto plazo en tiempo de ejecución

Calidad de servicio
Desempeño Confiabilidad y disponibilidad Seguridad

Network File System, es como su nombre lo indica un sistema de archivos distribuido a lo largo de una red de máquinas, con el objetivo de tener un número arbitrario de usuarios compartiendo un sistema de archivos común, sin restricciones de sistemas operativos y hardware utilizado. NFS permite, tanto a usuarios como a programas, acceder a archivos remotos ubicados en maquinas remotas como si fueran locales.

2. El sistema de archivos de red (NFS) de Sun.

NFS que fue diseñado e implantado por Sun en un principio para su uso en las estaciones de trabajo UNIX. Ahora, otros fabricantes lo soportan, tanto para UNIX como para otros sistemas operativos (incluido MS-DOS). NFS soporta sistemas heterogéneos; por ejemplo, clientes de MS-DOS que utilizan servidores UNIX. Ni siquiera es necesario que todas las máquinas utilicen el mismo hardware. Tres aspectos de NFS son de interés: la arquitectura, el protocolo y la implantación.

Arquitectura de NFS.

9

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

NFS posee dos tipos distintos de máquinas, las que operan como NFS Cliente y las que operan como NFS Servidor. Las NFS Cliente utiliza los directorios remotos como si fueran parte de su sistema de archivo local. Por su parte las máquinas que operan como NFS Servidor, se encargan de publicar sus directorios y responder a las peticiones de los NFS Cliente. En la mayoría de los casos, todos los clientes y servidores están en la misma LAN, pero esto no es necesario. Es posible ejecutar NFS en una red de área amplia. Se hablará de los clientes y servidores como si estuvieran en máquinas diferentes, sin embargo, NFS permite que cada máquina sea cliente y servidor al mismo tiempo. Cada servidor NFS exporta uno o más de sus directorios para su acceso por parte de los clientes remotos. Cuando se dispone de un directorio, también de todos sus subdirectorios. La lista de directorios que puede exportar un servidor se conserva en el archivo /etc/exports, de modo que estos directorios se pueden exportar de manera automática al arrancar el servidor. Los clientes tienen acceso a los directorios exportados al montarlos. Cuando un cliente monta un directorio (remoto), éste se vuelve parte de su jerarquía de directorios. Si así lo desea, un cliente sin disco puede montar un sistema de archivos remoto en su directorio raíz, lo que produce un sistema de archivos por completo soportado en un servidor remoto. Las estaciones de trabajo que sí tienen discos locales pueden montar directorios remotos en el sitio que deseen de su jerarquía local de directorios, lo que produce un sistema de archivos parcialmente local y parcialmente remoto. Así, la característica básica de la arquitectura de NFS es que los servidores exportan directorios y los clientes los montan de manera remota. Si dos o más clientes montan el mismo directorio al mismo tiempo, se pueden comunicar compartiendo archivos en sus directorios comunes. Un programa en un cliente puede crear un archivo, y un programa en otro cliente puede leer el archivo. Una vez realizados los montajes, no hay que hacer nada especial para lograr compartir los archivos. Los archivos compartidos sólo están ahí, en la jerarquía de directorios de varias máquinas y pueden leerse y escribir en ellos de la manera usual. Esta sencillez es uno de los puntos fuertes de NFS.

NFS utiliza llamadas a procedimientos remotos o RPC (Remote Procedure Calls), para la comunicacion entre los clientes y el servidor. RPC permite que los clientes hagan llamadas de procedimientos a procesos que aparentemente son locales, pero que en realidad estan corriendo en una máquina remota. En el caso de NFS, el servidor que recibe la llamada contiene recursos (especificamente archivos), necesitados por los clientes que lo invocan. Para asegurar la integridad del intercambio de datos entre el servidor y los clientes, NFS emplea el mecanismo XDR (eXternal Data Representation). Este mecanismo define un formato independiente de la plataforma para realizar el intercambio de datos binarios.

Protocolos de NFS.
Puesto que uno de los objetivos de NFS es soportar un sistema heterogéneo, con clientes y servidores que tal vez ejecuten diferentes sistemas operativos con un hardware distinto, es esencial que la interfaz entre los clientes y los servidores esté bien definida. NFS logra este objetivo al definir dos protocolos cliente-servidor. Un protocolo es un conjunto de solicitudes enviadas por los clientes a los servidores, junto con las respuestas enviadas de regreso de los servidores a los clientes. De manera análoga, los clientes pueden tratar a los servidores como "cajas negras" que aceptan y procesan un conjunto especifico de solicitudes. La forma en que lo hacen es asunto de ellos. El primer protocolo NFS controla el anclaje. Un cliente puede enviar un nombre de ruta de acceso a un servidor y solicitar que monte ese directorio en alguna parte de su jerarquía de directorios. El lugar donde se montará no está contenido en el mensaje, ya que el servidor no se preocupa por dicho lugar. Si la ruta es válida y el directorio especificado ha sido exportado, el servidor regresa un identificador de archivo al cliente. El asa de archivo contiene campos que identifican de manera única al tipo de sistema de archivo, el disco, el número de inodo del directorio, e información de seguridad. Las llamadas posteriores para la lectura y escritura de archivos en el directorio montado utilizan el identificador del archivo.

10

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Otra alternativa a la versión de UNIX de Sun soporta también el automontaje. Esta característica permite asociar un conjunto de directorios con un directorio local. Ninguno de los directorios remotos se monta (ni se realiza el contacto con sus servidores) cuando arranca el cliente. En vez de esto, la primera vez que se abre un archivo remoto, el sistema operativo envía un mensaje a cada uno de los servidores. El primero en responder gana, y se monta su directorio. El automontaje tiene dos ventajas principales sobre el montaje estático por medio del archivo /etc/rc. La primera es que si uno de los servidores NFS llamados en /etc/rc no está sirviendo peticiones, es imposible despertar al cliente, al menos no sin cierta dificultad, retraso y unos cuantos mensajes de error. Si el usuario ni siquiera necesita ese servidor por el momento, todo ese trabajo se desperdicia. En segundo lugar, al permitir que el cliente intente comunicarse con un conjunto de servidores en paralelo, se puede lograr cierto grado de tolerancia a fallos (puesto que sólo se necesita que uno de ellos esté activo) y se puede mejorar el desempeño (al elegir el primero que responda, que supuestamente tiene la menor carga). NFS no da soporte para la réplica de archivos o directorios, el usuario debe lograr que todos los sistemas de archivos sean iguales. En consecuencia, el automontaje se utiliza con más frecuencia para los sistemas de archivos exclusivos para lectura que contienen binarios del sistema y para otros archivos que rara vez cambian. El segundo protocolo NFS es para el acceso a directorios y archivos. Los clientes pueden enviar mensajes a los servidores para que manejen los directorios y lean o escriban en archivos. Además, también pueden tener acceso a los atributos de un archivo, como el modo, tamaño y tiempo de su última modificación. NFS omite las llamadas OPEN y CLOSE. No es necesario abrir un archivo antes de leerlo, o cerrarlo al terminar. En vez de esto, para leer un archivo, un cliente envía al servidor un mensaje con el nombre del archivo, una solicitud para buscarlo y regresar un identificador de archivo, que es una estructura de identificación del archivo. La llamada READ contiene al identificador de archivo que se desea leer, el ajuste para determinar el punto de inicio de la lectura y el número de bytes deseados. El servidor no tiene que recordar lo relativo a las conexiones abiertas entre las llamadas a él. Así, si un servidor falla y después se recupera, no se pierde información acerca de los archivos abiertos, puesto que no hay ninguno. Un servidor

como éste, que no conserva información del estado de los archivos abiertos se denomina sin estado. Por el contrario, en el sistema V de UNIX, el sistema de archivos remotos (RFS) requiere abrir un archivo antes de leerlo o escribir en él. El servidor crea entonces una entrada de tabla con un registro del hecho de que el archivo está abierto y la posición actual del lector, de modo que cada solicitud no necesita un ajuste. La desventaja de este esquema es que si un servidor falla y vuelve a arrancar rápidamente, se pierden todas las conexiones abiertas, y fallan los programas cliente. NFS no tiene esta característica. El método NFS dificulta el hecho de lograr la semántica de archivo propia de UNIX. Por ejemplo, en UNIX un archivo se puede abrir y bloquear para que otros procesos no tengan acceso a él. Al cerrar el archivo, se liberan los bloqueos. En un servidor sin estado como NFS, las cerraduras no se pueden asociar con los archivos abiertos, puesto que el servidor no sabe cuáles son los archivos están abiertos. Por lo tanto, NFS necesita un mecanismo independiente adicional para controlar los bloqueos. NFS utiliza el mecanismo de protección de UNIX, con los bits rwx para el propietario, grupo y demás personas. En un principio, cada mensaje de solicitud sólo contenía los identificadores del usuario y del grupo de quien realizó la llamada, lo que utilizaba el servidor NFS para validar el acceso. De hecho, confiaba en que los clientes no mintieran. Varios años de experiencia han demostrado que tal hipótesis era un tanto ingenua. Actualmente, se puede utilizar la criptografía de claves públicas para establecer una clave segura y validar al cliente y al servidor en cada solicitud y respuesta. Los datos nunca se encriptan. Todas las claves utilizadas para la autenticación, así como la demás información, son mantenidas por el NIS (servicio de información de la red). NIS se conocía antes como el directorio de páginas amarillas (yellow pages). Su función es la de guardar parejas (clave, valor). Cuando se proporciona una clave, regresa el valor correspondiente. No sólo controla las claves de cifrado, sino también la asociación de los nombres de usuario con las contraseñas (cifradas), así como la asociación de los nombres de las máquinas con las direcciones de la red, y otros elementos. Los servidores de información de la red se duplican mediante un orden maestro/esclavo. Para leer sus datos, un proceso puede utilizar al maestro o cualquiera de sus copias (esclavos). Sin embargo, todas las

11

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

modificaciones deben ser realizadas únicamente en el maestro, que entonces las propaga a los esclavos. Existe un breve intervalo después de una actualización en el que la base de datos es inconsistente.

Implantación de NFS
La capa superior es la capa de llamadas al sistema, la cual controla las llamadas como OPEN, READ y CLOSE. Después de analizar la llamada y verificar sus parámetros, llama a la segunda capa, la capa del sistema virtual de archivos (VFS). La tarea de la capa VFS es mantener una tabla con una entrada por cada archivo abierto, análoga a la tabla de inodos para los archivos abiertos en UNIX. En el UNIX ordinario, un inodo queda indicado de manera única mediante una pareja (dispositivo, inodo). En vez de esto, la capa VFS tiene una entrada, llamada vnodo (inodo virtual), para cada archivo abierto. Los vnodos se utilizan para indicar si un archivo es local o remoto. Para los archivos remotos, se dispone de suficiente información para tener acceso a ellos. Para ver la forma de utilizar los vnodos, sigamos una secuencia de llamadas al sistema MOUNT, OPEN y READ. Para montar un sistema remoto de archivos, el administrador del sistema llama al programa mount con la información del directorio remoto, el directorio local donde será montado y algunos otros datos adicionales. El programa mount analiza el nombre del directorio remoto por montar y descubre el nombre de la máquina donde se localiza dicho directorio. Entonces, entra en contacto con la máquina en la que se localiza el directorio remoto. Si el directorio existe y está disponible para su montaje remoto, el servidor regresa entonces un identificador de archivo para el directorio. Por último, llama a MOUNT para transferir el identificador del archivo al núcleo. El núcleo construye entonces un vnodo para el directorio remoto y pide el código del cliente NFS para crear un rnodo (inodo remoto) en sus tablas internas, con el fin de mantener el identificador del archivo. El vnodo apunta al rnodo. Así, cada vnodo de la capa VFS contendrá en última instancia una referencia a un rnodo en el código del cliente NFS o una referencia a un inodo en el sistema operativo local. Así, es posible ver desde el vnodo si un archivo o directorio es local o remoto y, si es remoto, encontrar su identificador de archivo.

Al abrir un archivo remoto, en cierto momento durante el análisis del nombre de la ruta de acceso, el núcleo alcanza el directorio donde se desea montar el sistema de archivos remoto. Ve que este directorio es remoto y en el vnodo del directorio encuentra la referencia al rnodo. Le pide entonces al código del cliente NFS que abra el archivo. El código del cliente NFS busca en la parte restante del nombre de la ruta de acceso en el servidor remoto asociado con el directorio montado y regresa un identificador de archivo para él. Crea en sus tablas un rnodo para el archivo remoto y regresa a la capa VFS, la cual coloca en sus tablas un vnodo para el archivo que apunta al rnodo. De nuevo, vemos aquí que todo archivo o directorio abierto tiene un vnodo que apunta a un rnodo o a un inodo. Quien hizo la llamada recibe un descriptor de archivo para el archivo remoto. Este descriptor de archivo se asocia con el vnodo mediante las tablas en la capa VFS. Observe que no se crean entradas en las tablas del lado del servidor. Aunque el servidor está listo para proporcionar los identificadores de archivo que le soliciten, no mantiene un registro de los archivos que tienen identificadores activos y los que no. Cuando se le envía un asa de archivo para el acceso a un archivo, verifica el identificador y, si éste es válida, sa utiliza. El proceso de validación puede incluir una clave de autenticación contenida en los encabezados RPC, si la seguridad está activada. Cuando el descriptor de archivo se utiliza en una llamada posterior al sistema, por ejemplo, READ, la capa VFS localiza el vnodo correspondiente y por medio de él determina si es local o remoto y el inodo o rnodo que lo describe. Por razones de eficiencia, las transferencias entre el cliente y el servidor se realizan en bloques grandes, por lo general de 8192 bytes, aunque se soliciten menos. Después de que la capa VFS del cliente ha obtenido el bloque de 8K que necesitaba, emite en forma automática una solicitud del siguiente bloque, por lo que lo recibirá rápidamente. Esta característica se conoce como lectura adelantada y mejora en forma considerable el rendimiento. Se sigue una política análoga para la escritura. Sin embargo, al cerrar un archivo, todos sus datos se envían al servidor de manera inmediata. Otra de las técnicas que se utilizan para mejorar el rendimiento es el ocultamiento, como en el UNIX ordinario. Los servidores ocultan los datos para evitar el acceso al disco, pero esto es invisible para los clientes. Los

12

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

clientes mantienen dos caches, uno para los atributos de archivo (inodos) y otro para los datos del archivo. Cuando se necesita un inodo o un bloque del archivo, primero hay que verificar si esta solicitud se puede satisfacer mediante el caché del cliente. En este caso, se evita el tráfico en la red. Pero puede suceder que el caché no sea coherente. Debido a la severidad potencial de este problema, la implantación de NFS hace varias cosas para mitigarlo. Una de ellas es que a cada bloque caché se le asocia un cronómetro. Cuando éste expira, la entrada se descarta. Por lo general, el tiempo es de 3 segundos para los bloques de datos y de 30 segundos para los bloques de directorio. Esto reduce un poco el riesgo. Además, al abrir un archivo con caché, se envía un mensaje al servidor para revisar la hora de la última modificación. Si la última modificación ocurrió antes de capturar en el caché la copia local, se descarta la copia del caché y se utiliza la nueva copia del servidor. Por último, el cronómetro del caché expira cada 30 segundos y todos los bloques sucios (es decir, modificados) en el caché se envían al servidor. Aún así, NFS ha recibido amplias críticas por no implantar de manera adecuada la semántica apropiada de UNIX. Una escritura a un archivo de un cliente podría o no ser vista cuando otro cliente lea el archivo, según la sincronización. Además, al crear un archivo, esta acción podría no ser visible para el mundo exterior durante un periodo de 30 segundos. Existen otros problemas similares. Por medio de este ejemplo, vemos que aunque NFS tiene un sistema compartido de archivos, como el sistema resultante es una especie de UNIX parchado, la semántica del acceso a los archivos no está por completo bien definida y la ejecución de un conjunto de programas que cooperen entre sí podría producir diversos resultados, según la sincronización. Además, lo único con lo que trata NFS es con el sistema de archivos. No hace referencia a otros aspectos, como la ejecución de un proceso. A pesar de todo, NFS es popular y tiene un uso muy extendido.

Reducción de requerimento de espacio de Almacenamiento en disco en las Estaciones de Trabajo. Incluso proveer espacio en disco a estaciones que no posean uno propio. Reducción de Tareas de Administración, debida a la centralización de archivos tanto comunes como no comunes. Puede ser utilizado como complemento a NIS. Facilita el trabajo con archivo remotos ya que no es necesarios conocer los comandos remotos (ftp, rlogin, rsh, etc). Ayuda a mantener la consistencia de los archivos entre las diferentes estaciones de trabajo. Puede utilizarse para la Comunicación entre Usuarios y/o Programas. Con el uso de NFS se pueden configurar los home directories de los usuarios con lo que, una vez exportados en la red, cada usuario puede utilizar su mismo “home directory” independientemente de la máquina de la red que este utlizando. Usuarios y aplicaciones pueden acceder a archivos remotos como si estos fuesen locales; por el hecho de utilizar RPC, los tiempos de respuesta son tan rápidos, como si los archivos estuviesen almacenados en discos locales. NFS utiliza RPC sobre el protocolo XDR (eXternal Data Representation), el cual asegura inviolabilidad en los datos transportados. Ademas, RPC utiliza intercambio de parámetros de autenticación, para dar dar seguridad a la informacion transportada en la red.

Características Básicas de NFS
Los servidores NFS no mantienen el estado de ninguno de sus clientes, esto impulsa dos cualidades para NFS como lo son la disminución del tiempo de reestablecimiento de los servidores al momento de fallar. Asi como también impulsa a una gran escalabilidad en el número de clientes a los cuales puede servir.

Ventajas de NFS

13

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

NFS realiza sus comunicaciones a través del Protocolo UDP. Para solventar las deficiencias inherentes de confiabilidad de UDP, NFS implementa en sus servidores un mecanismo de reconocimiento (acuse de recibo) a cada petición ejecutada por los clientes, de tal manera le asegura a los clientes que su petición fue atendida, de no recibir ningun “ack”, los clientes reenvian su petición. La mayoria de las peticiones son idempotentes, para lidiar con las pocas peticiones no idempotentes y las posibles retransmitidas de las mismas, los servidores mantienen en una memoria caché las últimas peticiones no-idempotentes realizadas, con el objetivo de eliminar la posible doble-ejecución de las mismas. NFS esta contruido sobre RPC (Remote Procedure Call). NFS utiliza la permisología de UNIX (ACL), por lo que para cada peticion de un cliente NFS , el servidor NFS recibe el UID y el GID del usuario. Para evitar problemas de seguridad, NFS le da el UID de usuario a cada usuario root de las máquinas cliente. Existen dos tipos de Montaje de un direcitorio por parte de un cliente, Hard y Soft, Con el primero de ellos el cliente va a intentar montar el directorio cuantas veces sea necesario hasta lograrlo, mientras que del modo Soft, lo intentara hasta que suceda un timeuot establecido. NFS es independiente de la plataforma de hardware y software sobre la cual opera. Esto permite que sea portable a múltiples Sistemas Operativos y plataformas de hardware, que van desde computadores hasta mainframes. NFS es flexible en cuanto a los protocolos de transporte, es decir, que puede correr en multiples protocolos de transporte, en vez de estar restringido a uno en especifico.

mountd

Es un servidor de RPC que responde a las peticiones de montaje de sistemas de archivos y a peticiones de informacion de acceso. Lee el archivo /etc/dfs/sharetab para determinar que sistemas de archivos están exportados y quienes tienen acceso a ellos.

-v Modo detallado. -r rechaza las peticiones de nuevos clientes.

nfsd

Es el demonio central del NFS, es quien se encarga de atender las peticiones efectuadas por los clientes

-a levanta el demonio con capacidad de trabajar tanto con TCP como UDP. -c fija el # maximo de conexiones TCP. -l # maximo de entradas para la cola de conexiones TCP. -p protocolo sobre el cual se levantará el demonio. -t levanta el demonio sobre el transporte especificado. nservers # de hilos para atender peticiones concurrentemente. -g especifíca el tiempo que tienen los clientes para reclamar el bloqueo de los archivos después que el servido arranca. -t fija el número de segundo a esperar antes

Lockd

Demonios involucrados en NFS.
Nombre Descripicion Opciones

Se encarga del bloqueo de archivos para asegurar así la consistencia de los mismos al ser accesados concurrentemente. Corre tanto en el servidor como en el cliente.

14

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

de retransmitir una petición de bloqueo a otro servidor remoto. nthreads # de hilos a levantar para atender las peticiones concurrentes. Funciona en cooperación con lockd para recuperar el estado de los archivos bloqueados cuando el servidor se cae. Luego de levantarse de nuevo, informa a los clientes que se reestableció el servicio basándose en la información del lockd. Tambien se encarga de avisar a los servidores en caso que ocurra una caída de un cliente que posea un archivo bloqueado. Es el demonio que permite a los clientes NFS, descubrir cual puerto esta siendo usado por el servidor NFS para prestar el servicio.

Debería estar configurado para dar acceso solo a ciertos clientes, por lo que se debería configurar para utilizar autentificación de usuarios. De ser posible deberían solo exportarse sistemas de archivos de solo lectura. Limitar el número de sistemas de archivos que cada cliente monta, mientras menos mejor. Evitar exportar los ejecutables. Evitar exportar directorios home. No exportar directorios que tienen permiso de escritura para todo el mundo (ACL). Evitar que una máquina sea tanto servidor como cliente NFS. No permitir login a usuarios desde otras maquinas Servidores NFS.

Statd

Comandos
mount Este comando permite a un cliente a montar un directorio remoto dentro de la estructura jerárquica de su sistema de archivos. La estructura general del Comando es: mount host_name:remote_dir local_dir. unmount Este Comando permite a un usuario cliente desmontar un directorios que no esten en uso, para ello es necesario especificar donde esta montado el sistema de archivos. La estructura gerenal del Comando es: unmount host_name:remote_dir.

portmap

Protocolos Involucrados en el NFS
Nombre del Protoc olo MOUNT

Recomendaciones de Seguridad.

Descripción Es "hablado" por el montd, se utiliza para la negociación iniciada entre

Peticiones Comprendidas NULL: no hace nada. MNT: Retorna un asa de archivo de la raíz del

15

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

el cliente y el servidor NFS. Con este protocolo en cliente puede conocer que directorios estan exportados, así como obtener el manejador de archivos del sistema de archivos que esta montando.

directorio exportado, también avisa al mountd que un cliente ha montado un sistema de archivos. DUMP: Retorna una lista de sistemas de archivos montados. UMNT: Retira la entrada de montaje de un cliente para cierto directorio de archivos exportado. UMNTALL: Retira todas las entradas de montaje para ese cliente. EXPORT: Retorna la lista de todos los sistemas de archivos exportados para ese cliente.

RENAME: Renombra un archivo de un directorio. RMDIR: Elimina un directorio. SYMLINK: Crea un enlace simbolico. GETATTR: Retorna los atributos de un archivo. SETATTR: Establece los atributos de un archivo. READ: Lee un archivo. WRITE: Escribe en un archivo

NFS

Este es el protocolo que CREATE: Crea o Trunca un actúa después que la fase de archivo dentro de un montaje ha concluido. directorio. Permite sistema montado. manipular el LINK: Crea un enlace. de archivos LOOKUP: Busca un archivo en un directorio. MKDIR: Crea un directorio. READDIR: Lee el contenido de un directorio. REMOVE: Borra un archivo de un directorio.

3. Núcleo
El Kernel consiste en la parte principal del código del sistema operativo, el cual se encargan de controlar y administrar los servicios y peticiones de recursos y de hardware con respecto a uno o varios procesos, este se divide en 5 capas: Nivel 1. Gestión de Memoria: que proporciona las facilidades de bajo nivel para la gestión de memoria secundaria necesaria para la ejecución de procesos. Nivel 2. Procesador: Se encarga de activar los cuantums de tiempo para cada uno de los procesos, creando interrupciones de hardware cuando no son respetadas.

16

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Nivel 3. Entrada/Salida: Proporciona las facilidades para poder utilizar los dispositivos de E/S requeridos por procesos. Nivel 4. Información o Aplicación o Intérprete de Lenguajes: Facilita la comunicación con los lenguajes y el sistema operativo para aceptar las órdenes en cada una de las aplicaciones. Cuando se solicitan ejecutando un programa el software de este nivel crea el ambiente de trabajo e invoca a los procesos correspondientes. Nivel 5. Control deArchivos: Proporciona la facilidad para el almacenamiento a largo plazo y manipulación de archivos con nombre, va asignando espacio y acceso de datos en memoria.

• • • • • • • • • • • •

Creación y destrucción de procesos. Cambio de estado de los procesos. Despacho. Suspensión y reanudación de procesos. Sincronización de procesos. Comunicación entre procesos. Manipulación de los bloques de control de procesos. Apoyo para las actividades de entrada/salida. Apoyo para asignación y liberación de memoria. Apoyo para el sistema de archivos. Apoyo para el mecanismo de llamada y retorno de un procedimiento. Apoyo para ciertas funciones de contabilidad del sistema.

El núcleo y los procesos
Todas las operaciones en las que participan procesos son controladas por la parte del sistema operativo denominada núcleo (nucleus, core o kernel, en inglés). El núcleo normalmente representa sólo una pequeña parte de lo que por lo general se piensa que es todo el sistema operativo, pero es tal vez el código que más se utiliza. Por esta razón, el núcleo reside por lo regular en la memoria principal, mientras que otras partes del sistema operativo son cargadas en la memoria principal sólo cuando se necesitan. Los núcleos se diseñan para realizar “el mínimo” posible de procesamiento en cada interrupción y dejar que el resto lo realice el proceso apropiado del sistema, que puede operar mientras el núcleo se habilita para atender otras interrupciones.

Tipos de kernel
En función del tamaño y de las funcionalidades que posea el kernel podemos clasificarlo. Realmente, y pese a seguidores incondicionales en un modelo u otro, existe una tendencia básica a reducir el tamaño del núcleo proporcionando menos funcionalidades, que son desplazadas a módulos que se cargan en tiempo de ejecución. En función a esta idea tenemos tres tipos fundamentales de kernel:

Resumen de las Funciones del Núcleo
El núcleo de un sistema operativo normalmente contiene el código necesario para realizar las siguientes funciones: • Manejo de interrupciones.

17

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Kernel monolítico Todas las funcionalidades posibles están integradas en el sistema. Se trata de un programa de tamaño considerable que deberemos recompilar al completo cada vez que queramos añadir una nueva posibilidad. Esta es la estructura original de Linux. Por tratarse de una técnica clásica y desfasada el creador de Linux fue muy criticado. Kernel modular (Núcleo Colectivo): En esta estructura se tiene una colección de procesos que son ampliamente independientes unos de otros. Los servicios del Sistema Operativo ( Administración de memoria distribuida, sistemas de archivos distribuidos, sincronización distribuida, procesos RPC, administración de tiempos, etc.) son implementados como procesos independientes. El núcleo del Sistema Operativo ( Comúnmente llamado Microkernel ) soporta la interacción entre los procesos que proveen los servicios al Sistema Operativo, también provee los servicios típicamente esenciales para cada computadora tal como la administración de tareas. El microkernel se ejecuta en todas las computadoras del sistema, mientras que los otros procesos pueden o no correr según se requiera. Se trata de la tendencia actual de desarrollo. Sin embargo no tiene sentido que el núcleo de un sistema operativo englobe toda la parafernalia para comunicarse con todas las posibles de tarjetas de vídeo o de sonido. En otros sistemas operativos esto se soluciona con unos ficheros proporcionados por el fabricante llamados drivers. En Linux se creó un interfaz adecuado para posibilitar el desarrollo de módulos que cumplieran esas funcionalidades. Esos módulos pueden ser compilados por separado y añadidos al kernel en tiempo de ejecución.

bloquear. A diferencia de un proceso, un Hilo (proceso ligero) comparte el espacio de direcciones con otros hilos por lo tanto comparten variables globales. Los hilos se inventaron para permitir la combinación del paralelismo con la ejecución secuencial y el bloqueo de las llamadas al sistema.

Aspectos del diseño de paquetes de hilos
Paquete de hilos. Un conjunto de primitivas relacionadas con los hilos. • Manejo de hilos Se tienen dos alternativas: - Hilos estáticos. 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. - Hilos dinámicos. Se permite la creación y destrucción de los hilos durante la ejecución. Los hilos pueden concluir de dos maneras: - Pueder terminar por sí mismos al finalizar su trabajo. - Pueden ser eliminados desde el exterior. Una técnica dentro de los paquetes de hilos para el manejo de exclusión mutua es el mútex, que es cierto tipo de semáforo binario. Un mútex solo tiene dos estados: cerrado, mediante la operación LOCK (si un hilo intenta cerrar un mútex ya cerrado, se bloquea); y no cerrado, para liberar un mútex se utiliza la operación UNLOCK (cuando UNLOCK elimina la cerradura de un mútex y uno o más hilos esperan ese mútex, se libera solo uno de ellos. El resto continua en espera. Otra operación que se tiene en ciertos casos es TRYLOCK, que intenta cerrar un mútex. Si el mútex no esta cerrado, TRYLOCK regresa un código de estado que indica el éxito. En caso contrario, TRYLOCK no bloquea el hilo, sino que regresa un código de error. Otra característica de sincronización a veces disponible en los paquetes de hilos es la variable de condición. Por lo general se asocia una variable de condición a un mútex cuando éste se crea. La diferencia entre un mútex y una variable de condición, es que el primero se utiliza para una cerradura a corto plazo, principalmente para proteger la entrada a regiones

3.Procesos y procesadores en sistemas distribuidos
Los procesos no comparten el mismo espacio de direcciones y no tienen nada que ver uno con otro. Para comunicarse utilizan primitivas de comunicación como memoria compartida, tuberías y paso de mensajes. En muchos sentidos los hilos son como miniprocesos. Cada hilo tiene su contador del programa, su pila para llevar el registro de su posición y se ejecutan en forma estrictamente secuencial. Los hilos comparten el mismo CPU (a menos que haya varios CPU, en ese caso se ejecutan en paralelo). Los hilos pueden crear hilos hijo y se pueden

18

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

críticas. Las variables de condición se utilizan para una espera a largo plazo hasta que un recurso esté disponible. Un problema que presentan los hilos es el manejo de variables globales que no son globales en todo el programa, por ejemplo la variable errno. Si un hilo hizo una llamada al sistema y dejó en errno un valor importante, puede ser que el despachador interrumpa a ese hilo antes de llevar a cabo la operación correspondiente al valor de errno, suponga que el siguiente hilo en despacharse también hace una llamada al sistema, la cual modifica errno; por lo tanto, el primer hilo habrá perdido el valor que obtuvo en errno, ya que ésta ha sido sobreescrita por otro hilo. 1. 2. Las posibles soluciones a este problema son las siguientes: Prohibir las variables globales Asignar a cada hilo sus propias variables globales particulares. Cada hilo tiene copia de la variable global. Una mejora a esto es asignar un bloque de memoria a las variables globales y transferirlo a cada procedimiento del hilo como un parámetro adicional. Introducir nuevos procedimientos de biblioteca para crear, dar valores y leer estas variables globales a lo largo de todo un hilo.

1. 2. 3. 4.

El sistema operativo no debe soportar hilos. Por ejemplo UNIX La planificación y cambio de estado la realiza un Sistema de Tiempo de Ejecución a nivel de usuario. Se permite que cada proceso tenga su algoritmo de planificación adaptado. Los hilos en este espacio tienen mejor escalabilidad, puesto que los hilos del núcleo requieren algún espacio para sus tablas y su pila en el núcleo, lo cual puede ser un problema si existe un número muy grande de hilos.

3. •

Planificación Se pueden utilizar los algoritmos de prioridad, roun robin, lotería, etc. A menudo los paquetes de hilos proporcionan ciertas llamadas para que el usuario pueda especificar el algoritmo de despacho y establecer las prioridades (si es el caso).

Implantación de un paquete de hilos
Existen dos métodos: • En el espacio de usuario • En el espacio de núcleo Implantación de los hilos en el espacio de usuario El núcleo no sabe de la existencia de los hilos. Ventajas

Desventajas 1. La implantación de las llamadas al sistema con bloqueo. Por ejemplo la lectura a un pipe vacío. Se puede permitir el bloqueo a un hilo pero que no afecte a los demás. Con las llamadas al sistema con bloqueo esto no se puede lograr. Una posible solución sería modificar tales llamadas al sistema, pero cambiar el sistema operativo no es atractivo. Además uno de los objetivos de tener un paquete de hilos a nivel de usuario es poder ejecutar los sistemas operativos existentes. Un cambio de una llamada al sistema requeriría muchos cambios a muchos programas de usuario. Otra alternativa es, revisar primero si una llamada al sistema se bloqueará utilizando la llamada SELECT. Entonces la llamada al sistema bloqueante es reemplazada por SELECT y luego la llamada al sistema. SELECT verifica si la llamada es segura (no se va a bloquear), si es así se lleva a cabo, sino no se ejecuta. El código que se coloca junto a la llamada al sistema para hacer la verificación recibe el nombre de jacket. Este método requiere escribir parte de la biblioteca de llamadas. 2. Bloqueo de las llamadas al sistema en el fallo de páginas. Si un hilo causa un fallo de páginas, el núcleo que desconoce la existencia de los hilos, bloqueará todo el proceso hasta que la página necesaria sea incluida aunque se puedan correr otros hilos. 3. Si un hilo comienza su ejecución, ningún otro hilo de ese proceso puede ejecutarse, a menos que el primer hilo entregue en forma voluntaria el CPU. Dentro de un proceso, no existen interrupciones de reloj, lo que imposibilita la planificación round robin.

19

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

4.

5.

Sincronización. Cuando un hilo realiza espera ocupada esperando la respuesta de un hilo, necesita interrupciones de reloj. La espera ocupada es atractiva cuando se espera una respuesta rápida y el costo del semáforo es alto, pero se pueden dar bloqueos. Los programadores desean los hilos en aplicaciones donde esto se bloqueen a menudo, por ejemplo en un servidor de archivos.

El modelo de estación de trabajo Este modelo consiste de estaciones de trabajo (WS) dispersas en un edificio o campus y conectadas entre sí por medio de una LAN. Las WS de trabajo pueden tener discos locales o no. Estaciones de trabajo sin disco

Implantación de hilos en el núcleo El núcleo sabe de los hilos y como manejarlos. Este contiene una tabla con una entrada por cada hilo, con los registros, estado, prioridades y demás información relativa al hilo. Las llamadas que pueden bloquear un hilo se implantan como llamadas al sistema, con un costo considerable. Cuando un hilo se bloquea el núcleo ejecuta otro hilo del mismo proceso o de otro proceso. Pero el programador esperaría que se ejecutara un hilo del mismo proceso. Algunos sistemas reciclan sus hilos, cuando un hilo termina y se destruye, se marca como no ejecutable, pero sus estructuras de datos en el núcleo no se afectan sino que se ocupan cuando se crea otro hilo. Esto implica un ahorro. Los hilos del núcleo no requieren nuevas llamadas al sistema sin bloqueo, no conducen a bloqueos cuando se utiliza la espera ocupada. Si un hilo de un proceso provoca un fallo de página, el núcleo puede ejecutar otro hilo mientras que espera que la página requerida sea traida del disco. Los hilos en el espacio del usuario o del núcleo tienen asociados otros problemas. Muchos procedimientos no son reentrantes, por ejemplo cuando ambos hilos utilizan la variable errno o algún bufer estático. Esto sucede porque estos procedimientos no fueron escritos para hilos sino para un solo proceso. Una solución sería escribir toda la biblioteca. Otra solución consiste en proporcionar a cada quien su jacket que cierre un semáforo mutex global al iniciar el procedimiento. De hecho la biblioteca se convierte en un enorme monitor. Las señales también presentan dificultades. Si las WS sw trabajo carecen de disco, el sistema de archivos debe ser implantado en uno o varios servidores de archivos de red. Ventajas • Precio más bajo • Fácil mantenimiento y respaldo. Al cambiar de versión de software o instalar uno nuevo, solo se tiene que instalar en pocos servidores. • Son silenciosas (no tienen ventiladores ) • Proporcionan simetría y flexibilidad. Un usuario puede entrar a cualquier estación de trabajo y entrar al sistema. Desventajas • Se debe contar con uno o más servidores de archivos equipados con discos enormes y rápidos a los cuales se tiene acceso mediante una LAN. • Gra uso de la red que puede llevar a cuellos de botella. Estaciones de trabajo con disco Formas en las que se puede utilizar el disco: 1. Para paginación y archivos temporales, los cuales se eliminan al finalizar la sesión. Su ventaja es reducir la carga de la red comparado con el caso sin disco, y su desventaja es el alto costo debido al gran número de discos duros. 2. Para paginación, archivos temporales y binarios del sistema, tales como compiladores, editores de texto, controladores de correo electrónico, etc. Este esquema reduce aún más la carga sobre la

Modelos de Sistemas

20

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

3.

4.

red. Su desventaja es el alto costo y la complejidad adicional para actualizar los binarios. Para paginación, archivos temporales, binarios del sistema y sistema de ocultamiento de archivos. Los usuarios pueden cargar archivos desde los servidores de archivos hasta sus propios discos, leerlos y escribir en ellos en forma local, y después regresar los archivos modificados al final de la sesión. El objetivo es mantener centralizado el almacenamiento a largo plazo, pero reducir la carga en la red. Su principal desventaja es que puede tener problemas de consistencia del caché. Un sistema local de archivos completo. Su ventaja es la escasa carga en la red y que elimina la necesidad de los servidores de archivos. Pero hay pérdida de transparencia y es más parecido a un sistema operativo de red

3.

¿Qué ocurre si regresa el poseedor de la máquina?

1. La estación de trabajo esta inactiva cuando nadie toca el ratón o el teclado durante varios minutos y no se ejecuta algún proceso iniciado por el usuario. Los algoritmos para localizar una WS inactiva se pueden dividir en dos categorías: a) Controlados por el servidor b) Controlador por el cliente En el primer caso cuando una WS esta inactiva anuncia su disponibilidad registrándose en un archivo o base de datos, da su nombre, dirección de red y propiedades. Cuando el usuario desea ejecutar un comando en una WS inactiva, mediante un comando busca en el registro la WS adecuada (el registro de WS inactivas esta centralizado con algunas copias). Otra alternativa es que la WS inactiva envíe un mensaje en toda la red. Las demás WS registran el mensaje en su propio registro. Así la búsqueda tiene menor costo y mayor redundancia. La desventaja es pedir a todas las máquinas que se encarguen de mantener el registro. Puede haber condiciones de competencia si dos usuarios descubren una misma máquina como inactiva. Para solucionar este problema, se envía un mensaje a la máquina inactiva para detectar su estado, si aún esta libre, la máquina inactiva se elimina del registro. Entonces quien hizo la llamada puede enviar su ambiente e iniciar el proceso remoto. En el segundo método, controlado por el cliente. La máquina que busca una WS(ws) inactiva transmite una solicitud donde indica el programa que desea ejecutar, y los requerimientos de memoria, procesador, etc. Al regresar la respuesta se elige a una ws inactiva. Las ws inactivas retrasan sus respuestas, con un retraso proporcional a la carga actual. Así, la respuesta de la máquina con la menor carga llega primero y se selecciona. 2.Ahora hay que ejecutar el programa. El desplazamiento de código es fácil. Se debe configurar el proceso remoto de modo que vea el mismo ambiente que tendría en el caso local y llevar a cabo el cómputo de la misma forma que en el caso local.

Otros problemas relacionados con este modelo son los siguientes: Si los circuitos siguen abaratándose pronto será posible proporcionar a cada usuario varios CPU, pero serían demasiados en un solo lugar; además surgiría otro problema, la asignación de recursos sería ineficiente ya que algunos usuarios recibirían recursos que no necesitan mientras que otros usuarios si los necesitan. Uso de estaciones de trabajo inactivas El problema en el modelo de estaciones de trabajo es que existen WS inactivas o subutilizadas. La primera solución a este problema fue proporcionar el comando rsh (UNIX Berkeley), con este comando se puede ejecutar en una máquina remota un comando. Para llevar a cabo la ejecución remota de un comando en una máquina inactiva mediante rsh se debe tener un registro acerca de cuál WS esta inactiva. Además el proceso que se ejecuta en una máquina remota seguirá ejecutándose aunque llegue un usuario, quien debe aceptar el desempeño menor de su sistema o buscar otra máquina. Problemas clave a solucionar con respecto al tema de las estaciones de trabajo inactivas 1. ¿Cómo encontrar una estación de trabajo inactiva? 2. ¿Cómo lograr que un proceso remoto se ejecute en forma transparente?

21

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Necesita la misma visión del sistema de archivos, el mismo directorio de trabajo, mismas variables de ambiente. Problemas al ejecutar un proceso en otra máquina. • Las llamadas al sistema ¿dónde dirigirlas? ¿a la máquina origen o a la máquina remota? Por ejemplo, la lectura de teclado y escritura a pantalla son funciones que deben dirigir la solicitud a la máquina origen; pero las llamadas que tienen que ver con prioridades o tamaño de memoria deben dirigir su solicitud a la máquina remota. • Llamadas al sistema relacionadas con el tiempo • Seguimiento del ratón • Escritura en dispositivos de hardware 3.Si el poseedor de la máquina regresa no hacer nada, fácil pero destruye la idea de ws personales. Otra posibilidad es eliminar el proceso intruso, advirtiéndole primero para que tenga tiempo de cerrar archivos, escribir los búferes editados en un disco, etc. Sino sale después de unos segundos el proceso es terminado. Otro método es hacer que el proceso emigre a otra máquina, ya sea a la máquina origen o a alguna otra estación de trabajo inactiva. Esto es un proceso complejo. El proceso debe dejar la máquina en el mismo estado exactamente como la encontró. El modelo de pila de procesadores Se construye una pila de procesadores, repleta de CPU, en un cuarto de máquinas, los cuales se pueden ejecutar de forma dinámica a los usuarios según la demanda. A cada usuario se le da una terminal gráfica de alta rendimiento, como las terminales X, incluso se pueden utilizar terminales ascii. Ventajas • Precio • Elimina la asociación entre el número de usuarios y el de ws • Facilita el crecimiento por incrementos

De hecho se convierte el poder de cómputo en ws inactivas, a las que se puede tener acceso de manera dinámica. Aquí no existe el concepto de propiedad. El principal argumento para la centralización del poder de cómputo como pila de procesadores proviene de la teoría de colas. Los sistemas de colas son útiles, puesto que es posible modelarlos de forma analítica. Sea λ la tasa de entradas totales de solicitudes por segundo de todos los usuarios combinados. Sea µ la tasa de procesamiento de solicitudes por parte del servidor. Para una operación estable debemos tener µ > λ. Si el servidor procesa menos solicitudes que las que los usuarios generan, la cola crecerá sin límite. El promedio de tiempo entre la emisión de una solicitud y la obtención de una respuesta completa está relacionado con λ y µ mediante la fórmula T=1/(µ - λ) 1) Si tenemos n computadoras, T estará dado en cada computadora como en 1). Ahora si reemplazamos estos n pequeños recursos por uno grande que sea n veces más poderoso, entonces tenemos, T=1/(nµ - nλ) = T/n Se reduce el tiempo promedio de respuesta n veces. Por esto una pila de procesadores tiene un mejor desempeño, aunque este en contra de los propios sistemas distribuidos. Sin embargo el tiempo promedio de respuesta no lo es todo. También esta el costo, la confiabilidad y la tolerancia a fallas. Una variación en el tiempo de respuesta también puede influir. Además en muchos trabajos la pila no es n veces mejor, pues no todos los trabajos se pueden ejecutar en paralelo. Aún así, el modelo de pila de procesadores es una forma más limpia de obtener poder de cómputo adicional que la búsqueda de estaciones inactivas. Ningún procesador pertenece a alguien, no hay máquina origen, no hay peligro de que el poseedor regrese. Seleccionar pila de procesadores o estaciones de trabajo inactivas va a depender del trabajo que se desarrolle. Modelo híbrido

22

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Se puede establecer una mediación al proporcionar a cada usuario una ws personal y además tener una pila de procesadores. Esto es más caro. Para procesos interactivos sería mejor utilizar ws. Para procesos que requieren un gran poder de procesamiento y no son interactivos es más adecuado una pila de procesadores.

Asignación de procesadores
Las estrategias de asignación de procesadores se pueden dividir en dos categorías amplias: -No migratorios. Cuando un proceso es creado, se decide donde colocarlo. Una vez colocado en una máquina, el proceso permanecerá ahí hasta que termine su ejecución. -Migratorios. Un proceso se puede trasladar aunque haya iniciado su ejecución. Este tipo de categorías permiten un mejor balance de carga. Un algoritmo que asigne procesos a procesadores, tiene como meta optimizar algún aspecto, por ejemplo los siguientes: -Maximizar el uso de CPU -Minimizar el tiempo de respuesta Aspectos del diseño de algoritmos de asignación de procesadores Las principales decisiones que deben tomar los diseñadores se pueden resumir en cinco aspectos: 1. Algoritmos deterministas vs. Heurísticos 2. Algoritmos centralizados vs. Distribuidos 3. Algoritmos óptimos vs. Subóptimos 4. Algoritmos locales vs. Globales 5. Algoritmos iniciados por el emisor vs. Iniciados por el receptor Los algoritmos deterministas son adecuados cuando se sabe de antemano todo acerca del comportamiento de los procesos o por lo menos una aproximación razonable. Cuando la carga del sistema es completamente impredecible se utilizan técnicas heurísticas.

Tener toda la información en un solo lugar permite tomar una mejor decisión, pero es menos robusta y coloca una carga pesada en la máquina central. Son preferibles los descentralizados, pero carecen de alternaticas adecuadas. Encontrar la mejor asignación, la mas óptima es más caro, pues hay que recolectar más información y procesarla más. En la práctica se buscan soluciones subóptimas, heuríticas y distribuidas. Otro aspecto llamado política de transferencia, también es importante, tiene que ver con ejecutar un proceso en la máquina local o transferirlo, esta decisión depende de la carga de la máquina. Una escuela dice que la decisión se debe tomar con respecto a la información de la máquina local, si esta sobrecargada (esta por sobre una marca) entonces hay que migrar el proceso, sino el proceso se debe ejecutar en la máquina local. Otra escuela dice que es mejor recolectar toda la información del sistema para decidir donde ejecutar el proceso. El último aspecto tiene que ver con lo que se llama política de localización, decidir dónde enviarlo una vez que se ha decidido migrar el proceso. En el caso de los algoritmos iniciados por el emisor, es el emisor (la máquina local que necesita colocar su proceso en otra máquina) quien envia solicitudes a las demás máquinas en busca de ayuda y de un lugar apropiado para su proceso. En el caso de los algoritmos iniciados por el receptor, es el receptor quien decide que esta subcargada y que necesita trabajo, así que enviar mensajes a las demás máquinas a ver quien necesita ayuda. Aspectos de la implantación de algoritmos de asignación de procesadores • Medición de la carga - Los algoritmos suponen que cada máquina conoce su carga. - Algunos algoritmos cuentan el número de procesos para determinar su carga. - Una mejora al criterio anterior es contar solo los procesos en ejecución o listos. - Otra forma de medir la carga es determinar la fracción de tiempo que el CPU esta ocupado.

23

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP







Costo excesivo - Muchos algoritmos teóricos ignoran el costo de recolectar medidas y desplazar los procesos de aquí para allá. - Al desplazar un proceso se debe verificar si hay ganancia en hacerlo. Para esto hay que tomar en cuenta el uso de memoria, tiempo de CPU y ancho de banda de la red. Complejidad - Existen algortimos que tienen un desempeño un poco mejor que otros, pero son más complejos. - Eager realizó un estudio a este respecto, y para ello trabajó con tres algoritmos. Se supone que al crear un nuevo proceso en una máquina, ésta se sobrecargará, por lo tanto hay que desplazar el proceso a otro lugar. 1. Se elige una máquina al azar y se envía el proceso, si la máquina esta subcargada entonces aceptará el proceso, en caso contrario se repite la operación hasta que alguien acepte el proceso o se exceda un contador de tiempo. 2. Se elige una máquina al azar y se le pregunta si esta subcargada, si su respuesta es afirmativa entonces la máquina origen le envía el proceso, sino se repite la operación con otra máquina elegida al azar y así hasta encontrar una máquina adecuada o se exceda el número de pruebas, en cuyo caso permanecerá en el sitio de su creación. 3. Se analizan k máquinas para determinar sus cargas exactas. El proceso se envía a la máquina con la carga más pequeña. El mejor algoritmos es el 3, sin embargo el algoritmo 2 tiene un desempeño casi igual al 3, pero es más sencillo. La conclusión a la que llegó Eager fue: “Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno más caro y más complejo, es mejor utilizar el más sencillo”. Estabilidad

-

El sistema nunca esta en equilibrio por la actualización constante de las tablas de las máquinas, así una máquina podría pensar que otra esta actualizada sin que sea así.

Ejemplo de algoritmos de asignación de procesadores Un algoritmo determinista según la teoría de gráficas Para sistemas que constan de procesos con requerimientos conocidos de CPU y memoria, además de una matriz conocida con el tráico promedio entre cada pareja de procesos. Si el número de CPU es menor que el número de procesos, habrá que asignar varios procesos al mismo CPU. La idea es llevar a cabo esta asignación de forma que se minimice el tráfico en la red. Sea la la siguiente gráfica de procesos, los arcos indican el nivel de comunicación entre los procesos. Una posible asignación es la siguiente: CPU1 CPU2 CPU3
A 2 6 3 4 E 4 3 2 B 2 1 F 1 8 5 C 3 D 4

5

30 unidades

G

H Otra posible asignación es: CPU1 CPU2 A 2 6 3 4 E 4 H 3 B 2 2 1 F 1

2 C 3

I

CPU3

D 4

8 5

5

28 unidades

G

2

I

Podemos observar que la segunda asignación es la mejor.

24

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Un algoritmo centralizado Arriba-abajo (Mutka y Livny, 1987) es centralizado. Usa una tabla de uso, con una entrada por cada estación de trabajo personal. Si un proceso se ejecuta en otra máquina, la máquina origen acumula puntos de penalización cada segundo. Si tiene solicitudes pendientes no satisfechas, los puntos de penalización se restan de su entrada en la tabla de usos. Si no existen solicitudes pendientes y ningún procesador esta en uso, la entrada de la tabla de usos se desplaza un cierto número de puntos hacia el cero. Si la puntuación asociada a una estación de trabajo en la tabla de usos es positiva, indica que la estación de trabajo es un usuario de los recursos del sistema. Si tiene una puntuación negativa indica que necesita recursos, si es cero es neutra. El objetivo de este algoritmo es asignar la capacidad de manera justa. Su desventaja es que en sistemas grandes con muchos nodos crea cuellos de botella. Un algoritmo jeráquico Para este tipo de algoritmo es necesario una gran cantidad de procesadores, los cuales se agrupan por jerarquías, en un primer nivel (el nivel más alto) un grupo de procesadores forman el comité de coordinadores, en el siguiente nivel están los jefes de departamento. Los niveles pueden ser n, todo dependerá del número de procesadores. En el último nivel están los trabajadores. Este algoritmo es utilizado en el sistema MICROS. Cuando una tarea requiere de varios procesadores, entonces la solicitud se hace a los jefes de departamento (o el nivel anterior al de los trabajadores), si estos no la pueden resolver la envían a su jefe inmediato, hasta alcanzar un nivel en donde se pueda resolver el problema. El administrador divide la solicitud en partes y los esparce entre los administradores por debajo de él, quienes repiten la operación hasta llegar a los trabajadores. Se señalan a los procesadores elegidos para realizar la Comité de tarea como ocupados y se informa de regreso en el árbol.
Coordinadores

Un algoritmo heurístico distribuido iniciado por el emisor Este algoritmo es el segundo algoritmo de Eager mencionado en páginas anteriores. La desventaja de este algoritmo es que si casi todas las ws están sobrecargadas entonces se enviarán pruebas de forma constante en vano. La red se sobrecargará cuando más trabajo existe. Un algoritmo heurístico distribuido iniciado por el receptor Este algoritmo es complementario al anterior. Cuando un proceso termina, el sistema verifica si la ws donde terminó el proceso tiene suficiente trabajo. En caso contrario, elige alguna máquina al azar y le solicita trabajo. Si no encuentra trabajo en N pruebas, el receptor deja de preguntar por cierto tiempo, e intenta de nuevo. Este algoritmo crea tráfico en la red cuando las ws están subcargadas (desempleadas), pero es mejor en este momento y crear tráfico cuando el sistema esta sobrecargado. Una posible modificación a este algoritmo es combinar el algoritmo anterior y este. Si una ws esta sobrecargada deberá intentar deshacerse de trabajo, y cuando este subcargada debe tratar de conseguir trabajo. Se puede manejar un historial de máquinas que estén crónicamente subcargadas o sobrecargadas.

coordinadores

Jefes de departamento

25
Trabajadores

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Un algoritmo de remates Este algoritmo fue creado por Ferguson En este caso se crea una comunidad económica en donde los procesos compran tiempo de CPU para terminar su trabajo. Los procesadores venden sus ciclos al mejor postor. El precio de un procesador va de acuerdo a su velocidad, tamaño de memoria, hardware y a lo que pagó el último cliente, incluso el tiempo de respuesta. Cuando se desea iniciar un proceso hijo, verifica si alguien ofrece el servicio que necesita y elije el mejor. Genera una oferta. Los procesadores reúnen todas las ofertas y eligen una. Se informa a los ganadores y perdedores.

Una falla es un desperfecto, causado por un error de diseño, de fabricación, de programación, físico, tiempo, condiciones ambientales, etc. Las fallas se clasifican en: -Transitorias. Ocurren una vez y después desaparecen. -Intermitente. Desaparece y reaparece. -Permanente. Continua existiendo hasta reparar el componente con el desperfecto. El objetivo del diseño y construcción de sistemas tolerantes a fallas consisten en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en la presencia de fallas. Fallas del sistema Se pueden distinguir dos tipos de fallas del procesador: 1. Fallas silentes. Un procesador que fallas solo se detiene y no responde a las entradas subsecuentes ni produce más entradas (también se llaman fallas de detención). 2. Fallas bizantinas. Un procesador que falla continúa su ejecución, proporcionando respuestas incorrectas a las preguntas, y posiblemente trabajando de manera maliciosa junto con otros procesadores que han fallado, para dar la impresión de que todos funcionan de manera correcta aunque no sea así. Sistemas síncronos vs. Asíncronos En el contexto de la investigación relativa a la tolerancia a fallas, un sistema que tiene la propiedad de responder siempre a un mensaje dentro de un límite finito conocido, es síncrono. Un sistema que no tiene esta propiedad es asíncrono. Uso de redundancia El método general para la tolerancia de fallas consisten en el uso de redundancia. Existen tres tipos posibles: • Redundacia de la información. Se agregan bits para poder recuperar los bits revueltos.

Planificación en Sistemas Distribuidos
Cada máquina se puede planificar de forma independiente, pero si existen procesos que interactúan entre sí y que se ejecutan en diferentes procesadores habrá problemas. Por ejemplo, supongamos que A y B son procesos que van a comunicarse, lo mismo ocurre con C y D; supongamos que A y C se ejecutarán en el procesador 1, y B y D en el procesador 2, cuando A es despachado en el procesador 1 , D es despachado en el procesador 2, como A neesita comunicarse con B entonces se interrumpe su ejecución y lo mismo sucede con D en el procesador 2, en el procesador 1 se despacha ahora C y en el procesador 2 B; esto significa que la comunicación no se esta llevando a cabo de forma eficiente, y se pierde tiempo de cómputo. Ousterhout (1982) propuso algoritmos basados en un concepto llamado coplanificación, el cual toma en cuenta los patrones de comunicación entre los procesos durante la planificación para garantizar que todos los miembros de un grupo se ejecuten al mismo tiempo.

Tolerancia de fallas
Fallas de componentes

26

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Redundacia del tiempo. Se realiza una acción y en caso necesario se vuelve a realizar. Este tipo de redundacia es de utilidad cuando las fallas son transitorias o intermitentes. • Redundancia física. Se trata de agregar equipo adicional. Formas de organizar procesadores 1. Réplica activa 2. Respaldo primario Tolerancia de fallas mediante réplica activa (método de la máquina de estados) Las solicitudes deben ser recibidas y procesados en el mismo orden. Un sistema es tolerante de ka fallas si puede sobrevivir a fallas de k componentes, entonces son necesarios k+1 componentes. Tolerancia de fallas mediante respaldo primario
2.Realiza el trabajo 1.Solicitud Cliente 6.Respuesta Primario 3.Actualiza Respaldo 5.Reconocimiento 4.Realiza el trabajo



procesador se supone la existencia de una memoria compartida, lo cual no existe en un sistema distribuido. La comunicación entre procesos debe respetar reglas llamadas protocolos. Protocolos con capas Para que dos procesos logren la comunicación se deben poner de acuerdo en varios aspectos como, cuántos voltios hay que utilizar para señalar un bit 0 y un bit 1; cómo detectar el fin de un mensaje, etc. Para facilitar este trabajo la organización internacional de estándares (internacional standards organization- ISO) ha desarrollado un modelo de referencia llamado el modelo de referencia para interconexión de sistemas abiertos, lo cual se abrevia como ISO OSI o el modelo OSI. El modelo OSI está diseñado para permitir la comunicación de los sistemas abiertos. Un sistema abierto es aquel preparado para comunicarse con cualquier otro sistema abierto mediante estándares que gobiernan el formato, contenido y significado de los mensaje enviados y recibidos. Un protocolo es un acuerdo entre las partes acerca de cómo debe desarrollarse la comunicación. El modelo OSI maneja dos tipos generales de protocolos (conexiones). 1. Protocolos orientados a la conexión. Antes de intercambiar datos, el emisor y el receptor deben establecer en forma explícita una conexión y tal vez el protocolo. 2. Protocolos son conexión. No es necesaria una negociación previa. En el modelo OSI, la comunicación se divide en 7 niveles o capas. Cada capa se maneja de forma independiente y se encarga de un aspecto específico. Cada capa proporciona una interfaz con la capa por encima de ella. La interfaz es un conjunto de operaciones que juntas definen el servicio que la capa está preparada para ofrecer a sus usuarios. La ventaja de un protocolo por capaz es su independencia, ya que una capa puede modificarse o mejorarse sin afectar a las demás. En el modelo OSI cuando se va a enviar un mensaje, este pasa por todas las capas comenzando en la de Aplicación. Cada capa le coloca un encabezado al frente o al final, al llegar el mensaje al otro lado, cada capa

Acuerdos en sistemas defectuosos -El problema de los dos ejércitos -El problema de los generales bizantinos

4. Comunicación en los sistemas distribuidos
La diferencia más importante entre un sistema distribuido y un sistema con un procesador es la comunicación entre procesos. En un sistema con un

27

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

lo va desmenuzando, quitándole el encabezado que le corresponde; la capa que recibe el mensaje es la capa física. Capas Fisica, Enlace de Datos, Red, Transporte, Sesión, Presentación, Aplicación La colección de protocolos utilizados en un sistema particular se llama una serie de protocolos o pila de protocolos. Capa física Su propósito es transportar el flujo de bits de una máquina a otra. El protocolo de la capa física se encarga de la estandarización de las interfaces eléctricas, mecánicas y de señalización. Maneja elementos como la intensidad de la señal de red, cables, enchufes, voltajes, distancias entre cables. Capa de enlace de datos La tarea principal de esta capa es agrupar a los bits en unidades llamadas marcos o tramas, y detectar y corregir errores. Uno de los mecanismos en la detección de errores es asignar números secuenciales a las tramas y a cada trama colocarle una suma de verificación, sino esta correcta la suma de verificación a la hora de recibir el marco, entonces el receptor le pide al transmisor que vuelva a transmitir el marco x. Capa de red La tarea principal de la capa de red es elegir la mejor ruta (a esta actividad se le llama ruteo), la ruta más corta no siempre es la mejor, lo importante es la cantidad de retraso, y esto complica los algoritmos de ruteo. La capa de red maneja dos protocolos: X.25 (orientado a la conexión) y el IP (sin conexión). Capa de transporte La tarea de la capa de transporte es proporcionar conexiones confiables y económicas. Las conexiones confiables (orientadas a la conexión) se pueden construir por arriba de X.25 o IP. En X.25 los paquetes llegan en orden, en IP no, entonces la capa de transporte es la encargada de ponerlos en orden.

El protocolo de transporte oficial ISO tiene cinco variantes, TP0, TP1, … , TP4. Los protocolos más utilizados en esta capa son: TCP (transmisión control protocol- protocolo para el control de transmisiones), orientado a la conexión y UDP (universal datagrama protocol- protocolo datagrama universal) que es un protocolo sin conexión. Capa de sesión Esta es en esencia una versión mejorada de la capa de transporte. Proporciona el control del diálogo, facilidades en la sincronización, la posibilidad de establecer conexiones llamadas sesiones y la posibilidad de transferir datos sobre las sesiones en forma ordenada. En la práctica rara vez las aplicaciones soportan esta capa. Capa de presentación Esta capa trata los problemas relacionados con la representación y el significado de los datos. Capa de aplicación Es una colección de varios protocolos para actividades comunes, como el correo electrónico, la transferencia de archivos y la conexión entre terminales remotas a las computadoras en una red. Esta capa contiene los programas de usuario. Protocolos utilizados: X.400 para correo electrónico, X.500 para el servidor de directorios. ATM Redes con modo de transferencia asíncrona Nació a finales de los 80’s debido a la necesidad de enviar además de datos a través de la red, también enviar voz. Para esto se eligió una forma híbrida con bloques de tamaño fijo sobre circuitos virtuales, para ambos tipos de tráfico. Este esquema es llamado modo de transferencia asíncrona (ATM- Asynchronous Transfer Mode), el cual se ha convertido en un estándar internacional. El modelo ATM consiste en que un emisor establece primero una conexión con él o los receptores. En el establecimiento de la conexión, se determina una ruta desde el origen hasta el destino y se guarda la información del ruteo en los conmutadores a lo largo del camino. Con esta

28

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

conexión se pueden enviar paquetes, pero el hardware los separa en pequeñas unidades de tamaño fijo llamadas celdas, las cuales siguen todas la misma ruta. Cuando ya no se necesita la conexión, ésta se libera y se purga la información de ruteo de los conmutadores. Ventajas • Se pueden enviar datos, voz, televisión, video, radio, etc. • Se puede dar el servicio de videoconferencias. • La red solo ve celdas sin saber lo que contienen, esto representa un ahorro, pues se puede enviar lo que sea por un solo cable. • Una celda puede ir a varios destinos (multitransmisión) • La multitransmisión se puede controlar de manera eficaz. • Celdas de tamaño fijo y no de tamaño variable como los actuales ATM tiene su propio protocolo de jerarquías. Algunas de las implicaciones de ATM en sistemas distribuidos son: • Velocidad a 155Mb/seg, a 622 Mb/seg y potencialmente a 25Gb/seg • Tiene mayor ancho de banda Los problemas son que este tipo de redes es más caro, y al utilizarlas implicaría crear nuevos protocolos y arquitecturas de sistemas. El modelo cliente servidor Un sistema distribuido basado en LAN no utiliza de modo alguno los protocolos con capas; y si lo hacen, solo utilizan un subconjunto de toda una pila de protocolos. El modelo cliente-servidor se presenta con la idea de estructurar el sistema operativo como un grupo de procesos en cooperación, llamados servidores, que ofrezcan servicios a los usuarios, llamados clientes. Las máquinas de los clientes y servidores ejecutan el mismo micronúcleo (generalmente) y ambos se ejecutan como procesos de usuario. Este modelo se basa usualmente en un protocolo solicitud/respuesta sencillo y sin conexión. El cliente es quien solicita al servidor algún servicio, y el servidor es quien atiende la solicitud y regresa los datos solicitados o un código de error si algo falló. Ventajas • Sencillez. El cliente envía un mensaje y obtiene respuesta.

• •

Eficiencia. La pila del protocolo es más corta y por tanto más eficiente. No es necesario implantar capas como la de sesión o red y transporte, ya que este trabajo lo hace el hardware. Se reducen los servicios de comunicación. Solo necesitamos las llamadas send (enviar) y receive (recibir).

Direccionamiento Para que un proceso envíe un mensaje a otro proceso que esta en otra máquina, es necesario que el primer proceso sepa donde esta el otro proceso (su dirección). El primer acercamiento para resolver el problema de cómo identificar un proceso, es asociarle a cada máquina una dirección, aunque esto implicaría que cada máquina solo puede ejecutar un proceso. Para resolver esta limitante, entonces se podrían dar identificadores a los procesos y no a las máquinas, pero ahora surge el problema de cómo identificar dos procesos. Un esquema común consiste en utilizar nombre con dos partes, una para especificar la máquina y la otra para especificar el proceso. Sin embargo este tipo de direccionamiento no es bueno, ya que cada usuario debe conocer la dirección del servidor y esto ya no es transparente. Si el servidor falla y su dirección cambia, entonces se deben recompilar los programas que utilicen ese servidor. Una alternativa es que cada proceso elija su identificador de un gran espacio de direcciones dispersas, como el espacio de enteros de 64 bits. La posibilidad de que dos procesos elijan el mismo número es muy pequeña y el método puede utilizarse en sistemas extensos. ¿Cómo sabe el núcleo emisor a qué máquina enviar el mensaje? En una LAN que soporte transmisiones, el emisor puede transmitir un paquete especial de localización con la dirección del proceso destino. Todas las máquinas de la red lo recibiran y los núcleos verificarán si la dirección es la suya, en este caso, regresa un mensaje “aquí estoy” con su dirección en la red. El núcleo emisor utiliza entonces esa dirección y la captura, para evitar el envío de otra transmisión la próxima vez que necesite al servidor. Este último esquema tiene un problema: la carga adicional en el sistema. Esto se evita utilizando una máquina adicional para la asociación a alto nivel de los nombres de los servicios con las direcciones de las máquinas. Así se utilizan nombres de procesos y no números. Cada vez

29

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

que se ejecute un cliente, primero va al servidor de nombres, y pide el número de la máquina donde se localiza algún servidor. Así las direcciones se ocultan. Este método tiene la desventaja de utilizar un componente centralizado. Primitivas con bloqueo vs. Sin bloqueo La forma de comunicación entre los procesos es el intercambio de mensajes, para lo cual son necesarias ciertas primitivas como send para enviar y receive para recibir. Existen dos tipos de primitivas: con bloqueo o sin bloqueo. Primitivas con bloqueo (síncronas). Al invocarse un send o un receive, el control del proceso no regresas hasta que se haya enviado el mensaje o hasta que se haya recibido un mensaje en el caso de receive, mientras tanto el proceso queda bloqueado. En este caso la desventaja esta en que el CPU esta inactivo durante la transmisión de los mensajes. Primitivas sin bloqueo (asíncronas). Tanto send como receive no tiene bloqueo. En el caso de send, esta primitiva coloca el mensaje en el buffer de mensaje y regresa el control inmediatamente sin que el mensaje haya sido enviado. El problema esta en saber cuando se puede volver a utilizar el buffer de mensajes. Existen dos soluciones a este problema. La primera es que el núcleo copie el mensaje a un buffer interno del núcleo y luego permita el proceso continuar. Así el proceso permanecerá bloqueado mientras se lleva a cabo la copia. La desventaja es que cada mensaje debe ser copiado del espacio del usuario al espacio del núcleo. Esto puede reducir el desempeño del sistema. La segunda solución es interrumpir al emisor cuando el mensaje ha sido enviado y hacerle saber que ya puede usar nuevamente el buffer de mensajes. Este método es eficiente, pero es muy difícil escribir los programas en forma correcta y es casi imposible depurarlos cuando están incorrectos. En el caso de un receive sin bloqueo, éste solo avisa al núcleo de la localización del buffer y regresa el control inmediatamente. Para hacer que éste espere se utilizaría un wait. En las primitivas síncronas puede suceder que un send o receive se queden esperando por siempre, así que para evitarlo se utilizan los

llamados tiempos de espera, si en este tiempo nada llega, la llamada send termina con un estado de error. Primitivas almacenadas en buffer vs. No almacenadas Las primitivas anteriores son primitivas no almacenadas, esto es, los mensajes son enviados a una dirección específica. El proceso receptor se bloquea mientras copia el mensaje a un buffer. Esto funciona bien mientras el receptor este siempre listo para escuchar un mensaje. Pero cuando primero se ejecuta send y luego receive hay problemas, puesto que la llamada a receive es el mecanismo que indica al núcleo del servidor la dirección que utiliza el servidor y la posición donde colocar el mensaje que está por llegar; entonces si primero llega un mensaje, el servidor no sabrá de quién es y dónde ponerlo. Soluciones: 1. Confiar que se va a ejecutar siempre un receive antes de un send. Mala idea. 2. Hacer que el transmisor realice varios intentos para enviar su mensaje, pero si el servidor esta muy ocupado, otros esperarán un tiempo y luego se rendirán. 3. Que el núcleo receptor mantenga pendientes los mensajes. Si no ocurre un receive en un determinado tiempo, el mensaje es descartado. 4. Utilizar un buzón donde almacenar los mensajes. Un proceso que va a recibir mensajes pide al núcleo que le sea creado un buzón, en donde le depositarán los mensajes y él los irá leyendo. A esta técnica se le conoce como primitiva con almacenamiento en buffers. El problema con los buzones es que son finitos y se pueden llenar. Soluciones: 1. Mantener pendientes los mensajes 2. Descartarlos 3. El cliente debe verificar primero si hay espacio, si existe entonces enviar mensaje sino bloquearse. Primitivas confiables vs. No confiables

30

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Cuando el cliente envía un mensaje, a pesar de utilizar primitivas con bloqueo, no existe garantía de que el mensaje haya sido entregado. El mensaje pudo haberse perdido. Existen tres enfoques de este problema: 1. Volver a definir la semántica de send para hacerla no confiable, es decir, la primitiva no se encarga de verificar que su mensaje haya sido entregado y toda la responsabilidad de comunicación confiable se deja en manos del usuario. 2. El núcleo de la máquina receptora envía un reconocimiento al núcleo de la máquina emisora. El reconocimiento va de núcleo a núcleo, así ni el cliente ni el servidor se dan cuenta de esto. El núcleo entonces liberará al proceso cuando reciba el reconocimiento. 3. Aprovechar el hecho de que en la comunicación cliente-servidor se realiza de la siguiente manera: el cliente le envía un mensaje de solicitud al servidor y el servidor le da una respuesta al cliente. Entonces no hay mensaje de reconocimiento por parte del núcleo del servidor, sino que la respuesta del servidor funciona como reconocimiento. Así, el emisor (cliente) permanece bloqueado hasta que regresa la respuesta. Si se tarda demasiado, el núcleo emisor puede enviar la solicitud nuevamente. En este método no existe reconocimiento para la respuesta, esta omisión puede ocasionar problemas si el servicio solicitado por el cliente requiere cómputo extenso, porque el servidor no se enteraría si el cliente recibió o no la respuesta. Para solucionar esto se envía reconocimiento de la respuesta en base a un cronómetro, si la respuesta llegó rápido, no hay reconocimiento, si tardó demasiado si hay reconocimiento.

Llamada a un procedimiento remoto (RPC- Remote Procedure Call)
Birrel y Nelson abordaron este tema en 1984. En este esquema el programador no se preocupa por la transferencia de mensajes.

Mediante RPC se puede invocar la ejecución de un procedimiento en la máquina A que no está en A, sino en B. Operación básica de RPC. De manera convencional, cuando un procedimiento es invocado, la dirección que tiene el registro apuntador a la próxima instrucción (IP) es almacenada en la pila, y el registro apuntador será cargado con la dirección del procedimiento invocado, cuando el procedimiento invocado termina, entonces el registro IP es cargado con la dirección que esta en el tope de la pila y sigue la ejecución del programa. En la mayoría de los casos es necesario enviar parámetros de entrada y obtener parámetro de salida. Los lenguajes de programación como C, utilizan dos tipos de paso de parámetros: por valor o por referencia. En un paso de parámetros por valor se pasa el valor de la variable y no hay problema, puesto que no se modifica la variable. En el caso del paso de parámetro por referencia, lo que se pasa es la dirección, y es posible realizar modificaciones sobre esta variable. Existe otra forma de pasar parámetros que no maneja el lenguaje C, este mecanismo se llama copia/restauración. Quien recibe la llamada copia la variable en la pila, como en la llamada por valor, y entonces copia de regreso la variable después de la llamada, escribiendo sobre el valor original. El objetivo de un RPC es que se parezca lo más posible a una llamada local (transparencia). Cuando un servidor se ejecuta por primera vez, lo primero que hace es exportar su interfaz, esto es, el nombre de los servicios y sus parámetros, especificando si son parámetros de entrada o de salida, su versión, su identificador único y su asa. Un proceso llamado conector es quien recibe la interfaz y realiza el registro. El conector además de realizar el registro de un servidor, puede darlo de baja y buscar algún servidor. La versión de un servicio es importante, pues indica si un servidor ha sido actualizado o no. Así el conector contendrá las últimas versiones de los servidores. Este método de exportación e importación es altamente flexible. Por ejemplo, puede manejar varios servidores que manejen la misma interfaz. Pero tiene sus desventajas. El conector se puede convertir en un

31

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

cuello de botella, además un proceso puede tener un tiempo de vida corto y el tiempo entre importar y exportar interfaces puede ser significativo. Semántica de RPC en presencia de fallas El objetivo es ocultar la comunicación, al hacer que las llamadas a los procedimientos remotos se parezcan a los locales. Sin embargo, esto no es tan sencillo. Existen cinco clases distintas de fallas que pueden ocurrir en los RPC’s. 1. El cliente no puede localizar al servidor 2. Se pierde el mensaje de solicitud del cliente al servidor 3. Se pierde el mensaje de respuesta del servidor al cliente 4. El servidor falla antes de recibir una solicitud 5. El cliente falla después de enviar la solicitud El cliente no puede localizar al servidor Debido a que el servidor cambió de dirección y el cliente no se actualizó (tal vez preguntó antes de que se actualizara). En UNIX se retorna -1 y una variable global errno, pero si -1 es un valor válido, habrá confusión acerca de si fue error o el resultado de alguna operación. Otro mecanismo que no tiene la desventaja anterior es que el error provoque una excepción. Por ejemplo se podrían utilizar señales. Pero no todos los lenguajes tienen excepciones y/o señales. Además el uso de estos mecanismos, destruyen la transparencia. Pérdida de mensajes de respuesta Se puede utilizar un cronómetro, si no llega respuesta en un periodo razonable, se envía la solicitud nuevamente. Pero qué se perdió, la solicitud, la respuesta o el servidor es lento? Si es la respuesta la que se perdió, entonces esto es más difícitl de enfrentar. Algunas operaciones se pueden repetir muchas veces sin efectos colaterales y sin causar daños. A esta propiedad se le llama idempotencia.

Pero existen operaciones que no son idempotentes, por ejemplo retirar dinero de un cajero automático. Una posible solución es asociar un número secuencial a cada solicitud. Entonces el núcleo del servidor debe mantener un registro del número secuencial más reciente, así podrá notar la diferencia entre una solicitud original y las retransmisiones. Como protección adicional se podría colocar un bit en el encabezado del mensaje para distinguir las solicitudes originales de las retransmisiones. Fallas del servidor Puede suceder que: -El servidor falla después de responder -El servidor falla antes de responder Existen tres escuelas en torno a lo que se debe hacer en este caso: 1. Semántica al menos una vez. Seguir intentando hasta conseguir una respuesta (el servidor puede volver a arrancar o se reconecta un nuevo servidor). Garantiza que la RPC se realiza al menos una vez o más veces. 2. Semántica a lo más una vez. Se da por vencido inmediatamente e informa de la falla. La RPC se realiza a lo más una vez o ni una sola vez. 3. No garantiza nada. Fallas del cliente Cuando un cliente falla después de enviar una solicitud sin que haya recibido respuesta, existirá una labor de cómputo de la cual nadie espera respuesta. A esta labor de cómputo no deseada se le llama huérfano. Problemas que puede provocar un huérfano. - desperdiciar ciclos de cpu - bloquear archivos o capturar recursos valiosos - crear confusión (si el cliente vuelve a arrancar y realiza de nuevo la RPC, la respuesta puede ser inmediata y entonces no sabrá lo que paso) ¿Qué hacer con los huérfanos?

32

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Nelson (1981) hizo un estudio acerca de este problema y propuso lo siguiente: 1. Exterminación. Antes de enviar la solicitud, el resguardo del cliente crea un registro de lo que se va a hacer y lo almacena en dusci. Al vo9lver a arrancar (el cliente) se verifica el contenido del registro y se elimina al huérfano. Desventaja. Gasto en la escritura y disco. Si hay más huérfanos es muy probable que no se puedan localizar No es un buen método. 2. Reencarnación. Se divide el tiempo en épocas. Cuando el cliente arranca de nuevo envía un mensaje a todas las máquinas que declaran el inicio de una época. Se eliminan los cómputos remotos que estén fuera de época. 3. Reencarnación sutil. Utiliza también épocas, pero el que está ejecutando el RPC verifica si existe el dueño de la RPC cuando le llega un mensaje de cierta época, si no existe elimina la operación. 4. Expiración. Se asigna a cada RPC una cantidad de tiempo, si no puede terminar en ese tiempo pide otro quantum, sino entonces se elimina el proceso. En la práctica ninguno es recomendable. La eliminación de un huérfano puede traer consecuencias imprescindibles. Protocolos RPC Orientado a la conexión Ventaja. Comunicación fácil Desventaja: Pérdida de desempeño Sin conexión En este caso se debe adaptar el protocolo para garantizar seguridad. Algunos sistemas utilizan UDP o UDP integrado a IP. Ventajas -El protocolo ya ha sido diseñado -Estos protocolos son utilizados en casi todos los sistemas UNIX. UDP e IP son soportados por muchas redes existentes. Desventajas -Cada protocolo forma un paquete con varios campos y además ambos realizan una suma de verificación.

-Lo anterior hace que se pierda el desempeño. Alternativa -Utilizar un protocolo especializado para RPC, el cual debe ser diseñado e implantado por el programador. Con respecto a la longitud del paquete y el mensaje, sale más caro hacer 64 RPC de 1k que 1 RPC de 64k. Por lo tanto el protocolo debe permitir las transmisiones largas (Sun Microsystems 8k, el límite de Ethernet es de 1536 bytes) Reconocimientos 1) Protocolo detenerse y esperar. Envía un paquete y espera reconocimiento. Los paquetes son enviados uno a uno. 2) Protocolo de chorro. El cliente envía todos los paquetes tan pronto como pueda. Así el servidor reconoce todo el mensaje al recibir todo el paquete, y no uno por uno. Propiedades del protocolo detenerse y esperar Si se daña o pierde un paquete, el cliente no puede recibir a tiempo un reconocimiento, por lo que vuelve a transmitir el paquete defectuoso. En el protocolo de chorro, si se pierde el paquete 1, pero el llega de manera correcta, puede abandonar todo y esperar a que el cliente vuelva a transmitir todo el mensaje o esperar con la esperanza de que 3 llegue bien y luego pedirle al cliente que envíe el paquete 1. A esto se le llama repetición selectiva. Comunicación en grupo Para RPC la comunicación solo es entre dos partes, el cliente y el servidor. A veces existen casos donde es necesario que varios procesos se comuniquen (por ejemplo, enviar un mensaje a todos los usuarios avisando que el sistema será dado de baja temporalmente para darle mantenimiento). Un grupo es una colección de procesos que actúan juntos en cierto sistema o alguna forma determinada por el usuario. La propiedad fundamental de un grupo es que cuando se envía un mensaje al propio grupo, todos los miembros de este lo reciben. A este tipo de comunicación se le llama uno-muchos (la de cliente-servidor es una comunicación puntual).

33

Sistemas Operativos Distribuidos MC Hilda Castillo Zacatelco BUAP

Los grupos son dinámicos, se pueden crear nuevos grupos y destruir grupos anteriores. Un proceso puede unirse a un grupo o dejarlo. Un proceso puede ser miembro de varios grupos a la vez. La implantación de comunicación en grupo depende del hardware en gran medida. - Multitrasmisión. Cuando se envía un mensaje a un grupo, éste se recibe automáticamente en todas las máquinas que escuchan esa dirección. Cada grupo escucha una dirección de multitransmisión. - Transmisión simple. Los procesos deben ser concientes acerca de a cuál grupo pertenecen, porque el mensaje lo verifican todos y solo los miembros del grupo al cual va dirigido el mensaje lo toman. La desventaja es que si un proceso no pertenece al grupo entonces descarta el mensaje, pero esto implica desperdicio de tiempo. - Unitransmisión. El mensaje es enviado a cada proceso uno a uno, es decir, si el grupo tiene n miembros, se envían n paquetes. Grupos cerrados vs. Grupos abiertos Los procesos pueden clasificarse en grupos cerrados y grupos abiertos. En un grupo cerrado, solo los miembros del grupo pueden enviar mensajes al grupo. En un grupo abierto, cualquiera puede enviar mensajes al grupo. Grupos de compañeros vs. Grupos jerárquicos Otra forma de clasificar a los grupos es en grupos de compañeros y grupos jerárquicos. En un grupo de compañeros todos los procesos son iguales, la ventaja es que si uno falla los demás pueden seguir trabajando. La desventaja es que al tomar una decisión se debe votar, esto implica mayor retraso y costo. En el caso de un grupo jerárquico existe un jefe o coordinador, la ventaja es que hay menos retraso y costo, la desventaja es que si falla el jefe, el grupo hace un alto. Membresía del grupo Para manejar la creación y eliminación de grupos, así como permitir a los procesos que se unan o dejen grupos se puede utilizar un servidor de

grupos. Este servidor debe mantener una base de datos acerca de qué grupos existen y quiénes lo forman. La desventaja es que si el servidor falla, se pierde información acerca de grupos y tal vez deban ser reconstruidos los grupos totalmente. Otro método es manejar la membresía de grupo en forma distribuida. En un grupo abierto un extraño puede enviar un mensaje a todos los miembros del grupo para anunciar su presencia. En un grupo cerrado es necesario algo similar. Para salir del grupo se debe enviar mensaje de despedida a todos. Si un miembro falla, al no haber mensaje de despedida, los otros miembros se darán cuenta al tratar de comunicarse con él, entonces sino responde, lo eliminan de su grupo.

34

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close