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