Sistemas Distribuidos
Soporte de Sistemas Operativos
Sistemas Distribuidos
Soporte de Sistemas Operativos
Sistemas Distribuidos
Soporte de Sistemas Operativos
Sistemas Distribuidos
Soporte de Sistemas Operativos
Tareas principales de un SO: Administrar recursos Proveer abstracciones de los recursos f´ısicos: memoria, procesador, almacenamiento, comunicaciones Bloques de disco → Archivos Acceso a Red → Sockets Celdas de Memoria → P´ aginas, segmentos
Pueden ser clasificados en dos grupos: Sistemas Operativos de Red Sistemas Operativos Distribuidos
Sistemas Distribuidos
Sistemas Operativos de Red
Poseen operaciones para el acceso a redes, que permiten el acceso a recursos remotos Provee transparencia solo en el acceso a ciertos recursos Sistemas de Archivos NFS
Cada nodo (computador con su SO) mantiene autonom´ıa en la administraci´on de los recursos de procesamiento En caso de necesitar ejecutar procesos en otras m´ aquinas, se debe hacer uso de telnet, ssh, rlogin, etc
Por lo tanto no permite la planificaci´ on de la ejecuci´on de procesos en otros nodos Ejemplos: Windows, UNIX
Sistemas Distribuidos
Sistemas Operativos Distribuidos
El SO mantiene un control sobre todos los nodos del sistema (y sus recursos) Asigna transparentemente (para el usuario) los nuevos procesos en cualquier nodo (pol´ıtica de scheduling) Ejemplo: asignar nuevo proceso al nodo menos cargado
Apunta a un mejor aprovechamiento de los recursos El usuario no es consciente d´onde se ejecutan los procesos o de la localizaci´on de los recursos Existe una imagen de un ´ unico sistema, como un todo y no por partes Ejemplos: Mach, Amoeba
Sistemas Distribuidos
¿Cu´al tipo de SO es m´as usado?
No hay un SOD en uso comercial. Los SO de red son los m´as usados: UNIX, MacOS, Windows (y sus variantes) ¿Por qu´e? Usuarios no adoptar´ an un nuevo SO donde no se ejecuten sus aplicaciones (independiente del beneficio en performance) Mantener la autonom´ıa en las m´ aquinas individuales El uso de middleware + SO de Red proveen un balance adecuado entre autonom´ıa y transparencia en el acceso a los recursos en la red
Sistemas Distribuidos
Funciones de la capa de SO
Los kernels y procesos servidores de cada nodo realizan la administraci´on de los recursos y presentan las interfaces a los usuarios (procesos clientes) Se debe proveer: Encapsulaci´ on: interfaces de acceso a los recursos Protecci´ on: acceso controlado y protegido a los recursos Procesamiento concurrente: proveer acceso concurrente de manera transparente
Middleware usa la combinaci´on de los recursos locales de cada SO para proveer los mecanismos de acceso y ejecuci´on remota.
Sistemas Distribuidos
Funciones de la capa de SO
El acceso a los recursos involucra las siguientes tareas: Comunicaci´ on: entre administradores de recursos (podr´ıan estar en la misma m´ aquina) Scheduling: la operaci´ on debe ser planificada dentro del kernel
Algunas caracter´ısticas: Apuntan a ser portables Escritos en lenguaje de alto nivel (C, C++) Poseen un esquema de capas. Componentes dependientes de la m´ aquina se encuentran en la capa inferior Algunos kernels pueden ser usados en sistemas de multiprocesadores con memoria compartida. Apoya el highperformance computing
Sistemas Distribuidos
Funciones de la capa de SO Componentes funcionales Centrales de un SO
Sistemas Distribuidos
Funciones de la capa de SO
Administrador de Procesos Creaci´ on y operaciones de procesos
Administrador de Threads Creaci´ on, sincronizaci´ on y scheduling
Administrador de Memoria F´ısica y virtual: compartici´ on y copiado
Administrador de Comunicaci´ on Comunicaci´ on entre threads (mismo proceso o procesos remotos)
Supervisi´on Manejo de excepciones, llamados a sistema, unidad de control de acceso a memoria y cache, manipulaci´ on de registros
Sistemas Distribuidos
Protecci´on de Recursos
Objetivo: Controlar el acceso ileg´ıtimo: Acceso o c´ odigo malicioso Tambi´en se debe cuidar el c´ odigo confiable, ¿por qu´e?
La protecci´ on puede se aplicada via: Lenguajes de programaci´ on: C v/s Java Kernel: Programa que tiene acceso a los recursos f´ısicos de la m´ aquina Administra la asignaci´ on de memoria y el acceso a ella (protecci´ on de memoria)
Sistemas Distribuidos
Procesos y Threads ¿Qu´e es un proceso? Ejecuci´ on de una actividad en particular Requiere del uso de recursos y de un ambiente de ejecuci´ on Un Proceso est´ a compuesto de una serie de threads Todos los threads comparten el mismo ambiente de ejecuci´ on
Threads pertenecientes a diferentes ambientes de ejecuci´ on no acceden a recursos de otros ambientes de ejecuci´on. Existen algunas excepciones en el uso de memoria f´ısica Espacio de Direcciones Compuesto de una o m´ as regiones: definir los permisos de acceso para los threads y formas de crecimiento Espacio compartido: librer´ıas de funciones, kernel, Comunicaci´ on de datos y compartici´ on
Sistemas Distribuidos
Procesos y Threads
Creaci´on de un proceso Selecci´ on de localizaci´ on (target host) Pol´ıtica de transferencia: ¿El proceso ser´ a creado de manera local o remota Pol´ıtica de localizaci´ on: En caso de ser remoto, ¿en qu´ e m´ aquina? Pueden ser decisiones est´ aticas o adaptativas En el caso de las est´ aticas pueden ser determin´ısticas (nodo A siempre transfiere a nodo B) o probabil´ısticas (nodo A transfiere aleatoriamente a nodo B)
Sistemas Distribuidos
Procesos y Threads
Creaci´on de un proceso (cont.) Creaci´ on del ambiente de ejecuci´ on Creaci´ on est´ atica y determinista Creaci´ on asociada al ambiente del padre: SO Mach (1986) usa el esquema copy-on-write
Sistemas Distribuidos
Procesos y Threads
Threads: Inicialmente todos los procesos son creados con un thread Se pueden crear threads para atender varios procesos ¿C´ omo aumenta el throughput del sistema?
Sistemas Distribuidos
Procesos y Threads
Ejemplo de mejoramiento usando threads Un requerimiento a un servidor (como en la figura anterior) necesita de de 2 ms de procesamiento y 8 ms de I/O. Se asume que los acceso a I/O son secuenciales. 1 2 3
¿Cu´ antos requerimientos por segundo puede procesar un thread? ¿Qu´e sucede si se aumenta el n´ umero de threads a 2, 3, 4...? Suponga se agrega un sistema de cach´e de acceso frecuente, con una tasa de acierto de 75% ¿Cu´ antos requerimientos se pueden atender en un segundo con 1 thread? ¿Qu´ e sucede si se aumenta el n´ umero de threads? Debido al uso de cache, el tiempo de procesamiento aumenta a 2.5 ms, ¿Cu´ antos requerimientos se pueden atender?
Sistemas Distribuidos
Procesos y Threads Arquitecturas alternativas usando threads
Threads en los clientes
Sistemas Distribuidos
Procesos y Threads ¿Por qu´e utilizar threads y no procesos? Creaci´ on de threads es menos costosa Cambio de contexto es m´ as r´ apido Permite la compartici´ on de recursos entre threads de un mismo proceso
Esto ´ultimo tambi´en puede ser un problema, ya que no hay protecci´ on entre threads de un mismo proceso Otras caracter´ısticas de los threads Soportadas por el lenguaje de programaci´ on Tiempo de vida: termino de su ejecuci´ on o por medio de una llamada a sistema (destroy()) Sincronizaci´ on: variables locales son privadas, pero las variables de clase son compartidas Planificaci´ on: preemptive vs non-preemptive Implementaci´ on: a nivel de kernel o a nivel de usuario
Sistemas Distribuidos
Comunicaci´on e Invocaci´on
Es otra de las tareas en las que apoya el SO Para la construcci´on y dise˜ no de un SD, es necesario conocer: Primitivas de comunicaci´ on provistas por el SO Protocolo de comunicaci´ on ¿C´ omo hacer la comunicaci´ on eficiente? Tolerancia a fallos provista (ej: latencia alta, desconexi´ on)
¿C´ omo influyen los protocolos provistos por el SO (ya implementados) en la caracter´ıstica de adaptabilidad? TCP, UDP, BlueTooth, etc
Sistemas Distribuidos
Comunicaci´on e Invocaci´on
Performance Es un factor cr´ıtico en el dise˜ no de un SD Mayor n´ umero de componentes separados ⇒ mayor n´ umero de invocaciones remotas requeridas Overhead de software supera al overhead de comunicaci´ on por la red (LAN o intranets) ¿Qu´ e sucede en Internet?. RPC y RMI son muy u ´tiles para implementar un procesamiento gen´ erico de la arquitectura cliente/servidor
Sistemas Distribuidos
Comunicaci´on e Invocaci´on
Costos de invocaci´on Diferentes espacios de direcciones Uso de la red Planificaci´ on y cambios de contexto de threads
Sistemas Distribuidos
Comunicaci´on e Invocaci´on
Invocaci´on a trav´es de la red Costo para transmitir un requerimiento null Pasos de la invocaci´ on Cliente: marshalling de argumentos, env´ıo del requerimiento, recibo y unmarshalling de la respuesta Servidor: thread recibe el requerimiento, unmarshall el mensaje, invoca al procedimiento, marshalling de la respuesta, y envio de ´ esta.
Tareas de administraci´ on involucradas en la invocaci´ on Marshalling Copia de datos Inicializaci´ on de paquetes Planificaci´ on y cambios de contexto: thread-thread o thread-kernel Espera por respuesta (acknowledgement)
Sistemas Distribuidos
Comunicaci´on e Invocaci´on Operaciones As´ıncronas Problemas de alta latencia y latencia no acotada Conexi´ on y reconexi´ on, especialmente en aparatos m´ oviles Uso de operaciones as´ıncronas (manejadas a nivel del middleware, m´ as que de los SO) Invocaciones concurrentes: uso de varios threads para realizar una serie de operaciones bloqueantes
Invocaciones as´ıncronas: uso de llamadas non-blocking no se requiere respuesta o se usa otra llamada para la respuesta
Invocaciones as´ıncronas persistentes: Intenta persistentemente realizar una invocaci´ on, hasta el ´exito, falla o retiro de la petici´ on QRPC (Queued RPC, Joseph et al 1997): uso de colas para las invocaciones y resultados. Puede asignar prioridad a los resultados dependiendo de la calidad de la conexi´ on
Sistemas Distribuidos
Comunicaci´on e Invocaci´on
Sistemas Distribuidos
Arquitectura del Sistema Operativo
Caracter´ısticas Heterogeneidad Solo debe ejecutar el software necesario para su rol Uso de m´ odulos redundantes malgasta recursos Permitir el cambio de servicios de un software sin alterar el resto del sistema Implementar alternativas del mismo servicio, para satisfacer necesidades distintos clientes o aplicaciones Agregar nuevos servicios sin da˜ nar los existentes
Implementaci´ on de pol´ıticas var´ıa entre aplicaciones y servicios Idealmente el kernel solo debiera proveer los mecanismos m´ as b´ asicos
Sistemas Distribuidos
Arquitectura del Sistema Operativo
Kernel Monol´ıtico vs Microkernels
Sistemas Distribuidos
Arquitectura del Sistema Operativo Monol´ıtico: UNIX Realiza todas las operaciones b´ asicas No es modular (dificultad para realizar modificaciones posteriores)
Microkernel Provee solo las abstracciones b´ asicas: espacio de direcciones, threads y comunicaci´ on local entre procesos El resto son din´ amicamente cargados seg´ un la demanda Los servicios se acceden usando los mecanismos de invocaci´ on basados en los mensajes del kernel
Sistemas Distribuidos
Arquitectura del Sistema Operativo
Comparaci´on Microkernel: extendible y modular, tama˜ no peque˜ no reduce la posibilidad de bugs Monol´ıtico: operaciones son relativamente m´ as eficientes
Hay algunas implementaciones h´ıbridas Chorus y Mach: uso de micrkernels. Migran la carga de los servidores hacia el kernel o hacia el espacio de usuario. Puede causar problemas de seguridad e integridad. SPIN OS: provee protecci´ on a nivel de lenguaje. Kernel y los m´ odulos cargados se ejecutan en el mismo espacio de direcciones, la protecci´ on es dada por la codificaci´ on
Los sistemas con microkernels no son ampliamente utilizados
Sistemas Distribuidos
Resumen
Descripci´ on del apoyo de los SO a la capa de middleware Uso de threads para mejorar el performance de los sistemas El SO provee las primitivas de paso de mensajes Invocaciones remotas son los principales causantes de degradaciones de performance Mirokernels v/s Monol´ıticos
