Resumen progresivo de S.O.D Unidad 1: Introducción Introducción a los sistemas distribuidos Definición Características de los sistemas distribuidos Tipos de sistemas distribuidos Sistemas distribuidos de cómputo Sistemas distribuidos de información Sistemas embebidos Sistemas en tiempo real Sistemas colaborativos Arquitecturas y modelos Arquitecturas de software: Modelos de SW aplicables a S.D. Arquitecturas en capas Arquitectura basadas en objetos Unidad 2: Procesos Relación procesos - hilo: Intercambio de procesos en la CPU Hilos en Sistemas Hilos en Sistemas Distribuidos Procesos clientes Servidores multihilos Migración y virtualización Marco de trabajo proceso (framework) Según iniciativa de migración Resumen progresivo de S.O.D 1 Virtualización Unidad 3: Sincronización, estado Sincronización de relojes Relojes físicos Algoritmos de sincronización de relojes Algoritmos de resincronización de relojes Algoritmo de Berkeley Relojes lógicos Relojes lógicos de Lamport Relojes vectoriales Exclusión mutua Algoritmos centralizado para exclusión mutua distribuida Algoritmo distribuidos Algoritmo de Token Algoritmo de Elección (Coordinador o proceso especial) Algoritmo "Bully" abuson Algoritmo de anillo Elecciones en ambientes inalámbricos Unidad 4: Comunicación Tipos de comunicación Llamadas a procedimientos remotos RPC Asíncrona RPC síncrona diferida Comunicación transitoria Orientada a mensajes Sockets Berkeley (a nivel capa de transporte) Interfaz de paso de mensajes (MPI) Comunicación persistente orientada a mensajes Middleware orientado a mensajes MOM o sistemas de Colas de mensajes Direccionamiento de un sistema de colas de mensajes Organización con ruteadores de un sistema de colas de mensajes Comunicación en Grupo Comunicación en objetos distribuidos e invocación remota (RMI) Localizar objetos remotos: Aplicación distribuida: creación usando RMI Comunicación orientada a flujos Medio continuo Sincronización de flujos Comunicación por multitransmisión Parcial 1 Resumen progresivo de S.O.D 2 Unidad 5: Nombres (naming) Unidad 6: Consistencia y replicación Unidad 7: Archivos y memoria en S.D. Unidad 8: Seguridad en S.D Unidad 9: Transacción y control de concurrencia en S.D Unidad 1: Introducción 📚 Temas: 1. Introducción a los Sistemas Operativos Distribuidos, definición, objetivos, hardware, software. 2. Sistemas en tiempo real, embebidos, y colaborativos: definición y conceptos. 3. Tipos de Sistemas Distribuidos 4. Arquitecturas: modelos, arquitecturas. Introducción a los sistemas distribuidos Definición Un sistema distribuido es una colección de computadoras independientes que dan al usuario la impresión de construir un único sistema coherente. Estas computadoras colaboran entre sí. La colaboración es el factor clase de los Sistemas Distribuidos. Organizados a menudo como una capa de software entre las aplicaciones de usuario y el Sistema Operativo y soporte a las comunicaciones, De la siguiente forma: Resumen progresivo de S.O.D 3 Características de los sistemas distribuidos Facilidad de acceso a los recursos: esto se hace por razones económicas, colaborativas y de intercambio de información (groupware) Ocultar razonablemente el hecho que los recursos están dispersos: en esto se define el acceso a los datos, la ubicación del recurso, el número de copias (replicación del recurso), las condiciones de competencia, y los errores y recuperación de un recurso. Debe ser abierto: es decir que debe haber interoperatividad entre los sistemas, la portabilidad de aplicaciones, y la expansibilidad de componentes que conforman al S.D. Debe ser escalable: cumple 3 dimensiones. 1) el tamaño, agregado fácil de componentes. 2) geográficamente, usuarios y recursos distantes uno de los otros. 3) administrativamente, gestionable aún con muchas organizaciones. Tipos de sistemas distribuidos Sistemas distribuidos de cómputo Es una colección de computadoras separadas físicamente y conectadas entre sí por una red de comunicaciones distribuida. Cada máquina posee sus componentes de hardware y software que el usuario percibe como un sólo sistema. El usuario accede a los recursos remotos de la misma manera en que accede a recursos locales, o un grupo de computadores que usan un software para conseguir un objetivo en común. Tiene como objetivo el cómputo de alto rendimiento. Se divide en 2 categorías: 1. Cómputo en cluster: son conjuntos de computadoras construidas mediante la utilización de componentes de hardware comunes y que se comportan como si fuesen una única computadora. Están conectadas por una red de área local de alta velocidad. 2. Cómputo en malla (GRID): la computación en grid o en malla es un nuevo paradigma de computación distribuida en el cual todos los recursos de un número indeterminado de computadoras son englobadas para ser tratadas como un único super ordenador de manera transparente. ¿Cómo funciona? [ Todo S.D de cómputo: Recopilado de acá ] Sistemas distribuidos de información Resumen progresivo de S.O.D 4 Asociados a las Bases de Datos, donde se realizan peticiones al servidor. Ejecutan todas las peticiones o ninguna, utilizan primitivas especiales. <Completar> Sistemas embebidos Asociados al control de las funciones de dispositivos. Tiene operaciones restringidas, donde el dispositivo las ofrece como funciones que el usuario puede ejecutar. Funciona en computadoras que operan dispositivos pero que no aceptar software de usuario. Por lo general, brindan funciones relacionadas al dispositivos en cuestión, por ejemplo, robots, placas mecánicas, cosas con Arduino, etc. Un ejemplo de esto pueden ser redes caseras (con computadoras, televisores, consolas, etc), o sistemas electrónicos para el cuidado de la salud (como los de los estudios. O sistemas de monitoreo. Sistemas en tiempo real Garantizan la acción en un instante dado. El tiempo es el parámetro clave del sistema. Controla procesos y sondea y toma acciones en un determinado instante a los dispositivos. Si las acciones hay que tomarlas en un cierto tiempo sin excepción, el sistema es un sistema de tiempo real duro. Si se permite una franja de tiempo de fallo, se le considera un sistema de tiempo real suave. Sistemas colaborativos Son sistemas que intentan satisfacer la necesidad de realizar actividades que necesiten de colaboración. Para esto, existen dos tipos de software colaborativo, el groupware y el workflow. El primero es un tipo de software colaborativo que ayuda a grupos de trabajo a realizar sus actividades a través de una red. Este provee un ambiente de colaboración, en el que realmente se percibe que el trabajo en grupo se lleva a cabo. Mantiene la información en un único sitio común para todos los miembros. El workflow permite administrar y automatizar procesos de negocios. Responden a necesidades individuales, reducen tiempo, dinero y esfuerzo en la ejecución de un proceso de negocio. Arquitecturas y modelos Resumen progresivo de S.O.D 5 Arquitecturas de software: Modelos de SW aplicables a S.D. Arquitecturas en capas <xd> Arquitectura basadas en objetos <xd> Unidad 2: Procesos 📚 Temas: 1. Hebras de control, Asignación de procesadores, Planificación. 2. Agentes, clientes, servidores. 3. Migración de procesos, virtualización. Relación procesos - hilo: Para ejecutar un programa en S.O, se crea un cierto número virtual de procesadores, donde cada uno ejecuta un programa diferente. Existe una tabla de control de procesos (BCP) que da continuidad a la ejecución. Almacena las entradas correspondientes a registros, mapas de memoria, información, etc. El S.O asegura la ejecución normal y concurrente de todos los procesos que comparten la CPU. Esta asignación de hardware se hace en forma transparente. Intercambio de procesos en la CPU Conlleva: 1. Cambios de contexto 2. Modificaciones de los registros de la MMU 3. Invalidar caches de traducción de direcciones TLB 4. Intercambio de procesos entre memoria principal y el disco Resumen progresivo de S.O.D 6 Un proceso ejecuta una única actividad, NOI es adecuado en sistemas distribuidos porque plantea limitaciones en la concurrencia. Para que esto no pase, tienen que utilizarse hilos para ejecutar distintas actividades de manera concurrente. En S.O.D, los procesos forman un bloque de construcción y amplían la integración de aplicaciones proporcionadas por los S.O locales. Tener múltiples hilos de control por proceso nos da una facilidad para la construcción de aplicaciones y un mejor rendimiento. Hilos en Sistemas El problema de los hilos en los sistemas es que al tener un único hilo de control es que una llamada de sistema se bloquea como un todo. Entonces la manera para solucionarlo es una tecnología multihilos, y podemos adoptar una mirada más paralelista cuando ejecutamos el programa dentro de un sistema multiprocesador. En esencia, el hilo es igual a un proceso que posee su propio segmento de código, independientemente de los demás hilos. No hace ningún intento de lograr un alto grado de transparencia (si el rendimiento se ve afectado). Este sistema de hilos mantiene un mínimo de información para la CPU con varios hilos. En general, se ignora la información que no es estrictamente necesaria para manipular múltiples hilos. Una aplicación multihilos rara vez tiene un rendimiento peor que usar un hilo solo, también demanda un esfuerzo intelectual adicional para proteger a los hilos entre sí, tener en cuenta un diseño simple resulta de ayuda y la protección de datos recae en los desarrolladores. Al usar hilos la comunicación se afectúa mediante datos compartidos. Algunas aplicaciones son fáciles de estructurar como una colección de hilos cooperativos. Para esto, se puede implementar un paquete de hilos para crearlos y destruirlos, y para manejar la sincronización. Esto de hace por: 1. Biblioteca de hilos: crearla y destruirla es barato y toda la administración de los hilos se mantiene en el espacio de direcciones del usuario. Lo que cuesta es establecer una pila de hilos y liberarla. El intercambio de contexto de hilo se realiza mediante instrucciones cortas, no requiere modificar mapas de memoria, reinicio de TBL, etc. 2. Hilos a nivel kernel. <no entendi xd> Hilos en Sistemas Distribuidos Permiten llamadas al sistema sin bloquear todo el proceso en que se ejecuta el hilo. Permiten expresar la comunicación como conexiones lógicas concurrentes. En el caso de clientes Resumen progresivo de S.O.D 7 multihilos la transparencia de distribución involucra retardos en la propagación en redes de área amplia. Procesos clientes Están compuestos por dos interfaces: 1. La de usuario 2. La de red Para la interacción usuario-servidor_remoto. Depende de la aplicación parte del procesamiento y el nivel de datos se ejecutan del lado del cliente. Servidores multihilos El principal uso de multihilos en SD está del lado del servidor, porque simplifica el código del servidor, el paralelismo es más sencillo de implementar y hay mayor disponibilidad a la hora de aceptar peticiones y procesar trabajo. Arquitecturas alternativas de servidor basada en hilos: 1. Hilos por objeto 2. Hilos por conexión 3. Hilos por soilicitud Procesos servidores Servidores: proceso que implementa servicio específico para un conjunto de clientes. Hay dos que están dentro del PDF: 1. Servidor iterativo: manipula la petición y si es necesario devuelve respuesta 2. Servidor concurrente: no manipula peticiones, pasa la petición a un hilo separado u otro proceso. Migración y virtualización La migración es una técnica que permite transferir un proceso de un nodo a otro. Por supuesto esto tiene sus beneficios: 1. Equilibrio de carga, en un SD evita que ciertos nodos lleguen a un rendimiento casi nulo y otros se encuentren ociosos. Resumen progresivo de S.O.D 8 2. Aumenta la tolerancia de fallos 3. Mejoras en el rendimiento en general 4. Mejor uso de los recursos. Configurar sistemas distribuidos en forma dinámica es posible con la migración del código. Hay modelos para la migración de código, son los siguientes según el PDF: Marco de trabajo proceso (framework) Consta de 3 segmentos: 1. Código 2. Recursos 3. Ejecución Y tiene tipos como por ejemplo la movilidad débil que transfiere el segmento de código + algunos datos de sincronización, el programa transferido comienza desde unoi de los diversos puntos de inicio preferido. Y luego la movilidad fuerte que también transfiere el segmento de ejecución. Según iniciativa de migración Migración iniciada por remitente: Inicia en la máquina donde reside el código Requiere validar al cliente en el servidor receptor. En general, se hace cuando los programas se cargan al servidor de cómputo. Migración iniciada por destinatario: La máquina destino toma iniciativa para migrar el código Ocurre entre un cliente y un servidor Suele ser anónima y responde a mejoras de rendimiento en el cliente Virtualización La separación entre una sola CPU y ser capaz de pretender que existe más CPU de procesamiento para la virtualización de recursos. Las arquitecturas y sistemas bases cambian de Resumen progresivo de S.O.D 9 manera más rápida que el software de alto nivel. Esto permite simplificar la diversidad de plataformas y máquinas y ejecutar aplicaciones de forma virtual. Unidad 3: Sincronización, estado 📚 Temas: 1. Sincronización de relojes 2. Ordenamiento de eventos 3. Exclusión mutua 4. Elección de coordinador. Sincronización de relojes La cooperación entre procesos y su sincronización tienen mucha relación entre sí. En ambientes SD la sincronización es por mucho más difícil que en ambientes mono y multiprocesador. En ambientes distribuidos se crece de un tiempo global. Si cada máquina tiene su propio reloj, es factible que un evento anterior a otro tenga un tiempo superior. Relojes físicos Los relojes poseen cristales de cuarzo mecanizado con precisión. Oscilan a una frecuencia bien definida. Usan dos registros: 1. Un contador, donde cada oscilación disminuye el contador en 1, al llegar a 0 genera interrupción y el contador se reinicia a partir del mantenedor. 2. Y el mantenedor xd Esta pérdida de sincronía entre relojes es gradual, pero en tiempo real la hora es importante. Algoritmos de sincronización de relojes Hay una máquina sincronizada con una máquina que posea un receptor de tiempo. Cada máquina tiene un cronómetro que ocasiona una interrupción n veces por segundo. Al apagarse el cronómetro, el manipulador de interrupciones agrega 1 al reloj de software. El reloj de software mantiene el número de marcas a partir de algún momento acordado en el pasado. Resumen progresivo de S.O.D 10 Algoritmos de resincronización de relojes NTP protocolo de tiempo de red. El servidor de tiempo al cual se conectan los clientes da el tiempo exacto (posee un receptor WWV). Se estiman los retrasos ocasionados por los mensajes para contactar el servidor. Si el retraso de A a B es igual a B a A → T1 - T1 es mas o menos T4 - T3 El NTP se configura entre pared de servidores, es decir, que el sondeo será de A a B y también de B a A. Se almacenan ocho pares de valores de compensación X y la estimación de desvío Y, (X, Y) se usa ese valor mínimo Y y su asociado X como estimación más confiable para compensar. Algoritmo de Berkeley Es un servidor de tipo activo. Cada cierto tiempo pregunta a cada máquina sobre la hora registrada en ellas. Usa las respuestas para calcular el promedio. Indica a cada máquina que adelante o retrase su reloj, según la nueva hora. Este algoritmo es conveniente si ninguna máquina tiene un receptor WWV y se ajustan los tiempos manualmente por el operador del demonio del tiempo (servidor) ?????? se fumo algo Soto Resumen progresivo de S.O.D 11 Relojes lógicos No siempre la sincronización de los relojes está relacionada al tiempo real. Puede ser suficiente que se coincidan con el tiempo actual. Los relojes lógicos apuntan a ordenar los eventos de cada nodo. Según Lamport: "lo importante es que los procesos coincidan en como ocurren los eventos". Relojes lógicos de Lamport Se define la relación ocurrencia anterior a —> b "a ocurre antes que b". Si a y b son eventos del mismo proceso, a—>b es verdadero, y a ocurre antes que b. Si un proceso envía un mensaje a y b es el evento de recepción en otro proceso, a→ b es verdadero. Entonces un mensaje no puede recibirse al mismo tiempo o antes de ser enviado (se requiere valor distinto a 0 para envío). Los envíos son concurrentes si nada se puede decir sobre como ocurrieron los eventos. Resumen progresivo de S.O.D 12 En S.D: Relojes vectoriales Con Lamport no es posible determinar oden de dos eventos solo por comparar sus tiempos: si C(a) < C(b) entonces no implica que a→b Lamport no captura la causalidad, los relojes vectoriales sí. VC(a) reloj vectorial con evento a, tiene la propiedad de que sí. NO ENTIENDO ESTO. Exclusión mutua Los accesos concurrentes pueden corromper o hacer inconsistentes los recursos, se necesita acceso mutuamente exclusivo: Requisitos de las soluciones: No debe producir bloqueo indefinido No debe producir inanición La solución debe ser equilibrada. Medidas a considerar: Números de mensajes por solicitud Retraso de sincronización Resumen progresivo de S.O.D 13 Tiempo de respuesta. Planteamos el modelo de sistema como uno que contiene n procesos, cada uno con un procesador diferente y una sección crítica que precisa una exclusión mutua. Algoritmos centralizado para exclusión mutua distribuida Emula lo que se hace con un procesador. Elige uno de los procesos para coordinar la entrada en la sección crítica. Si un proceso que quiere entrar en su sección crítica envía un mensaje de solicitud (request) al coordinador. El esquema precisa de tres mensajes por entrada a SC: request, reply y release. Algoritmo distribuidos Es el algoritmo de Ricart y Agrawala (1981), que mejora el de Lamport (1978). Requiere un ordenamiento de eventos (Lamport). Tiene estas weas: 1. Para acceder a un recurso, el proceso elabora un mensaje 2. El mensaje contiene el nombre del recurso, un número del proceso, tiempo actual. 3. Envía los mensajes a los demás procesos (autoincluido). 4. Supone la no pérdida de mensajes. 5. Espera hasta tener todos los OK → ingresa, al salir envía OK a todos los encolados y se borra de la misma. Funcionamiento básico del Algoritmo distribuido. Al recibir petición de otro proceso, la acción depende del recurso mencionado: El destinatario no accede y no desea acceder envía OK. El destinatario ya cuenta con acceso, no responde y coloca en cola la petición. Resumen progresivo de S.O.D 14 Si el receptor, también quiere acceder, compara los registros de tiempos (mensaje enviado vs recibido) el mejor gana. ????. Caso contrario, no responde y coloca en cola de petición. Lo que pasa que si hay una falla de un nodo al no responder, se interpreta como negativa de permiso. Es n veces menos eficaz y requiere mayor tráfico de red. Esto se puede solucionar generando una respuesta por parte del destinatario cuando llega una petición, SOTO ESCRIBI BIEN POR FAVOR NO ENTIENDO Algoritmo de Token Es más o menos así esto: al iniciar el proceso 0, recibe un token. El token circula en el anillo. Al recibir el token, el proceso verifica si requiere acceder al recurso. Si accede retiene el token y libera al terminar. No se permite acceder dos veces al recurso con el mismo token. Solo un proceso tiene el token en un tiempo dado. Y obvio tiene inconvenientes. Si se pierde el token, se retrasa al usuario (obvio xd), si el proceso falla, se "soluciona" con un acuse de recibo. Todos deben conocer la configuración del anillo en cuestión donde "viajan" los procesos. Resumen progresivo de S.O.D 15 Algoritmo de Elección (Coordinador o proceso especial) Dentro de los SD existen procesos que deben coordinar, inicializar y desempeñar algún papel especial. En general, se busca al proceso con mayor número o identificador para designarlo como coordinador. En general, por consenso se selecciona un coordinador. Algoritmo "Bully" abuson Al advertir que el coordinador deja de responder. P(i) envía un mensaje ELECCIÓN a cada proceso con un número superior. Si no responde ningún proceso, Pi gana la elección. Si un proceso mayor Pj responde, Pi queda afuera. Pj inicia una nueva elección. Genera mensaje broadcast para dar aviso que es el nuevo coordinador. Algoritmo de anillo NO utiliza token, los procesos están lógica y físicamente ordenados. Cada proceso sabe quién es su sucesor. Al advertir que el coordinador no funciona, el proceso dispara un proceso de Resumen progresivo de S.O.D 16 elección. Genera un mensaje con su número de proceso y lo envía a su sucesor. Si se produce una falla en el sucesor, este lo salta y así, hasta localizar un proceso activo. Cada proceso receptor agrega un número para volverse candidato. En algún momento vuelve un mensaje a iniciador del proceso. Se cambia tiepo de mensaje a coordinador y se re-circula mensaje entre los nodos. También se informa los procesos que pertenecen al anillo. Al circula una vez el mensaje es destruido. Elecciones en ambientes inalámbricos En ambientes inalámbricos no es aplicables que: El paso de mensajes sea confiable, La topología de la red cambia Esto se acentúa en redes móviles de medida. Vasudevan (2004) propone un algoritmo que tolera falla de nodos y partición de la red. Se elije al mejor líder y no al azar. Mecanismo: Cualquier nodo (fuente) inicia la elección enviado un mensaje de ELECCIÓN, el mensaje enviado a los vecinos inmediatos. Cuando un proceso recibe un mensaje de ELECCIÓN por primera vez designa al remitente como su padre. El mensaje es enviado a los vecinos inmediatos del nodo, salvo al padre. Cuando un nodo recibe un mensaje de ELECCIÓN, de otro nodo que no sea su padre, acusa recibo. Resumen progresivo de S.O.D 17 Unidad 4: Comunicación 📚 Temas: 1. 2. 3. 4. 5. Pasaje de mensajes Modelo Cliente-Servidor. Procedimientos remotos. Objetos distribuidos. Eventos distruibidos. En SD la comunicación se basa en el paso de mensajes a bajo nivel (a través de la red subyacente). Los modelos más ampliamente utilizados para realizar la comunicación son el: RPC MOM Comunicación en grupo Flujos de datos Comunicación en objetos distribuidos. Tipos de comunicación Resumen progresivo de S.O.D 18 Comunicación persistente: middleware almacena comunicación hasta entregarla al destinatario. Comunicación transitoria: mientras el destinatario y remitente estén activos, los mensajes serán almacenados para ser entregados, sino se descartan. Comunicación asíncrona: el remitente CONTINUA inmediatamente de pasado su mensaje para su transmisión. Comunicación sincrónica: el remitente se bloquea hasta que la petición es aceptada. Se puede originar por: 1. El remitente hace espera ocupada que el middleware confirma gestión de la petición 2. Remitente se sincroniza hasta que la petición fue entregada al destinatario 3. El remitente se sincroniza hasta recibir una respuesta del destinatario. Llamadas a procedimientos remotos SEND Y RECIEVE: no ocultan la comunicación, falta transparencia. RPC (Remote Procedure Call): Permite a los programas invocar procedimientos de otras máquinas. Al invocar el procedimiento origen, se bloquea para que se procese el procedimiento destino invocado. La información se transporta en los parámetros desde el origen invocado. El resultado del procedimiento retorna la información al origen. El programador no ve el paso de mensajes. Es ampliamente aceptado en la intercomunicación de sistemas distribuidos. Resumen progresivo de S.O.D 19 Paso de parámetros por valor: En general, el modelo no representa problemas mientras las máquinas sean idénticas y los resultados y parámetros son del tipo escalar. En SOD, sí presentan muchos problemas. Paso de parámetros por referencia: Los apuntadores tienen sentido dentro un espacio de direcciones del proceso. Primera solución: prohibir los apuntadores y parámetros de referencia. Segunda solución: reemplazar la llamada por referencia por una de copia-restauración. RPC Asíncrona Con la RPC asíncrona al recibir una solicitud al servidor elabora una respuesta de inmediato al cliente y luego llama al procedimiento solicitado. Utilidad: Cuando el comportamiento escrito solicitud-respuesta NO es necesario. En general, cuando No hay resultado de devolución. Resumen progresivo de S.O.D 20 RPC síncrona diferida Con la RPC síncrona diferida permite que el cliente realice tareas mientras espera la respuesta del servidor . Comunicación transitoria Orientada a mensajes Sockets Berkeley (a nivel capa de transporte) En la capa de transporte existen protocolos con interfaces estandarizadas con un conjunto de primitivas. Las interfaces facilitan a las aplicaciones la comunicación con partes residentes Resumen progresivo de S.O.D 21 en máquinas diferentes. ¿Qué es un socket? Es el punto final de comunicación, en dicho punto, una aplicación puede escribir información. Dicha información se envía fuera de la red subyacente y desde la que se lee la información entrante. Socket primitivas: Socket() : Crea un punto final de comunicación Blind() : Asocia una dirección local a un socket Listen() : Anuncia la conveniencia de aceptar conexiones. Accept() : Bloquea a quien llama hasta que llega una petición de conexión Connect() : Activa conexión Send() : Envía datos por conexión Receive() : Recibe datos por conexión Close() : Libera la conexión Resumen progresivo de S.O.D 22 Interfaz de paso de mensajes (MPI) Orientado a alto rendimiento en multicomputadoras, sencillo para el desarrollo. Esto aporta: Manejo de buffer y de sincronización avanzados. Soporte para redes de interconexión de alta velocidad. Diseñada para aplicaciones paralelas. Explota directamente la red subyacente. Independencia de hardware y plataforma. Además: el manejo de fallas asume que existen fallas serias o fatales que no requieren de recuperación inmediata. La comunicación se da dentro de un grupo de procesos conocidos. Para esto se utiliza un identificador de grupo y uno para cada proceso. El par (Idgrupo, Idproceso) se utiliza en vez de la dirección al nivel de transporte. Primitivas: MPI_bsend() : Adjunta un mensaje de salida a un buffer local de envío y continúa MPI_send() : Envía un mensaje y espera hasta que es copiado en un buffer local o remoto. MPI_ssend() : Envía un mensaje hasta que comienza la recepción MPI_sendrecv() : Envía un mensaje y espera una respuesta MPI_isend() : Pasa una referencia a un mensaje de salida y continua MPI_issend() : Pasa una referencia a un mensaje de salida y espera hasta que inicia la recepción. MPI_recv() : Recibe mensaje; bloquea si no hay MPI_irecv() : Verifica existencia de mensaje de entrada, pero no bloquea Comunicación persistente orientada a mensajes Middleware orientado a mensajes MOM o sistemas de Colas de mensajes Soporte a la comunicación asíncrona persistente. Almacenamiento de término medio a los mensajes. Soporte a transferencias de larga duración. Resumen progresivo de S.O.D 23 MODELO DE COLA DE MENSAJES: La comunicación se realiza insertando mensajes en cols específicas. Los mensajes son reenviados a otros servidores de comunicación. En algún momento, se entregan a destinatario los mensajes. Cada aplicación posee una cola privada. En ella, otras aplicaciones pueden enviar mensajes. La cola sólo es leída por su aplicación asociada, la cola puede ser compartida por varias aplicaciones. Direccionamiento de un sistema de colas de mensajes El administrador de colas interactua en el envío y recepción de mensajes de la aplicación. Existen otros administradores que operan retransmitiendo o enrutando mensajes. Los retransmisores ayudan a escalar los sistemas de colas de mensajes. Conformando redes sobrepuestas. Resumen progresivo de S.O.D 24 Organización con ruteadores de un sistema de colas de mensajes Aplicar formato común de mensajes difícil abstracciones diferentes de las aplicaciones. Agente de mensajes: entre nivel de aplicación y sistema de colas de mensajes como puerta de enlace. Garantiza que la aplicación destino comprenda los mensajes, aplicando una conversión de formato a los mensajes. Comunicación en Grupo El destino de los mensajes es un grupo de procesos que requiere de: Multidifusión Replicar mensajes N veces. Un proceso determinado puede pertenecer a varios grupos. Existe una dirección de grupo. En general, tiene una estructura dinámica, se incorporan o retiran procesos de los grupos y la "membresía" requiere coordinación y comunicación entre los miembros. Ordenamiento de eventos o mensajes: Resumen progresivo de S.O.D 25 Comunicación en objetos distribuidos e invocación remota (RMI) Mediante RMI → Objetos de diferentes procesos se pueden comunicar. Esto extiende la invocación de métodos locales. El objeto de un proceso invoca los métodos de un objeto residente en otro proceso. Permite a los objetos recibir notificaciones de los eventos que ocurren en otros objetos. Solo reciben notificaciones en las que han notificado interés. Objetos distribuidos Extensión de objetos a otros procesos o computadoras. Debido a que lógicamente están fraccionados: el estado de un programa OO está asociado a partes separadas vinculadas a un objeto. El estado de un objeto consta de valores de sus variables de instancias. Algunos objetos de un proceso pueden recibir tanto invocaciones locales como remotas. Localizar objetos remotos: Las aplicaciones obtienen referencias a objetos remotos. Por ejemplo: Aplicación registrar sus objetos remotos con nomenclatura de RMI y el registro RMI. Alternativamente, una aplicación pasa y devuelve referencias a objetos remotos como parte de otras invocaciones remotas. Resumen progresivo de S.O.D 26 Aplicación distribuida: creación usando RMI 1. Diseño e implementación de los componentes de la aplicación distribuida. 2. Compilar fuentes 3. Haciendo red clases accesible 4. Inicio de la aplicación Implementación: Módulo de comunicación: Usa mensajes de petición-respuesta. Proporciona una semántica de invocación. La parte residente en el servidor selecciona el distribuidor para la clase invocada. Resumen progresivo de S.O.D 27 Módulo de referencia remota: Traduce referencias entre objetos locales y remotos. Crea referencias a objetos remotos. Mantiene una tabla de objetos remotos que tiene la entrada por cada uno y una entrada por proxy local. Software RMI (Proxy - Distribuidos - Esqueleto) El proxy implementa transparencia para el cliente. Oculta detalles de la referencia a obj. remoto, empaquetado de argumentos, y desempaquetado del resultado. Se incorpora como objeto local para el que invoca y dirige invocación al objeto remoto. El distribuidor existe en el servidor un distribuidor por clase que representa a un objeto remoto. Selecciona el método apropiado, usando el idmetodo que llega en el mensaje de petición derivado por el módulo de comunicación. Resumen progresivo de S.O.D 28 El esqueleto es parte de la clase de un objeto remoto. Implementa los métodos de la interfaz remota. Comunicación orientada a flujos Comunicación donde la sincronización es importante. Información dependiente del tiempo y tiene medios (continuo, discreto) y un flujo de datos (secciones de unidades de datos). Medio continuo Modo de transmisión asíncrona: NO relevante cuando se completa el flujo. Se transmiten elementos uno después del otro (discreto). Modo de transmisión síncrono: retraso máximo fin a fin para cada unidad de datos. Puede ser más rápido pero no debe ser más lento que el máximo. Modo de transmisión isócrono: retraso máximo y mínimo de fin a fin, requiere transferencia a tiempo (multimedia distribuida). Resumen progresivo de S.O.D 29 Sincronización de flujos En multimedia los de datos son complejos y de tipo diferentes, se dan dos alternativas: Flujo continuo - discreto (audio) Continuo (video y audio) La sincronización se aplica en las unidades de datos del flujo. Si la sincronización de la comunicación se efectúa en el remitente se puede enviar un solo tipo de unidad de datos. Comunicación por multitransmisión Seine el soporte de envío de datos a varios destinatarios. Existen soluciones a niveles de red y a nivel transporte En base a redes punto a punto y red sobrepuestas es posible configurare rutas de comunicación. Lo que permitió varias técnicas de multitransmisión a nivel de aplicación. Los nodos se organizan a través de una red sobrepuesta, la que disemina información a los miembros. Método de diseño red sobrepuesta: los nodos se auto-organizan en un árbol. Existe una única ruta entre un par de nodos. Los nodos se organizan en una red acoplada. Cada uno de los nodos tiene varios vecinos (varias rutas entre un par de nodos). Resumen progresivo de S.O.D 30 Parcial 1 Preguntas Pregunta Column Por qué 1. Todas las arquitecturas intentan obtener un grado razonable de transparencia, balanceado aspecto de rendimiento, tolerancia a fallas, facilidad de programación, etc. 2. La interacción entre cliente-servidor es también conocida como publicación- Verdadero Falso subscripción 3. En la arquitectura cliente-servidor la parte cliente implementa servicios Falso Relación cliente-servidor: comportamiento solicitud-respuesta Servidor: proceso que implementa un servicio específico Cliente: solicita un servicio a un servidor, enviando una petición y esperando la respuesta 4. Existe simetría en las funciones clienteservidor en el modelo peer to peer Verdadero 5. Las redes no estructuras punto a punto utilizan un procedimiento determinista para la construcción de la Red sobrepuesta Resumen progresivo de S.O.D Todos los procesos son iguales, existe una simetría entre cliente-servidor al mismo tiempo (proceso sirviente= Las redes no estructuradas no siguen un Falso procedimiento, son creadas al azar y para realizar una petición realizan una inundación 31 Pregunta Column Por qué 6. Las vistas parciales selectivas permiten generar redes estructuradas punto a punto en redes no estructuradas punto a punto 7. En la implementación de arquitecturas peer to peer en general un proceso sólo debe utilizar los canales disponibles para comunicarse con otro 8. En las arquitecturas basadas en eventos, la comunicación se logra mediante propagación de eventos y en forma opcional datos. 9. El software adaptativo aplicado a sistemas distribuidos le permiten al middleware adaptarse a los cambios de su entorno por las aplicaciones. A definir Verdadero Un proceso no puede comunicarse con cualquier proceso, debe hacerlo por los canales disponibles. Verdadero Es verdadera. De hecho, es esto lo que se conoce como sistema de publicaciónsubscipción Verdadero 10. La autoadministración de los sistemas distribuidos se logra mediante siclos de retroalimentación, donde se monitorea, analiza y se aplican mecanismos de modificación de comportamiento. Verdadero Sino no sería autoadministración Verdadero Permite flexibilidad y esas cosas Falso Es lo que ofrece Falso La migración de CODIGO permite esto 11. Virtualización permite a una aplicación e incluso a un ambiente ejecutarse de forma concurrente con las aplicaciones 12. La virtualización tiene las desventajas de dismunición de portabilidad y imposibilidad de aislar fallas. 13. La migración de procesos permite la escalabildad y configuración dinámica de clientes y servidores 14. Los múltiples hilos de control de por procesos permiten mayor facilidad para la construcción de aplicaciones y se obtiene un mejor rendimiento Resumen progresivo de S.O.D En S.O.D, los procesos forman un bloque de construcción y amplían la integración de Verdadero aplicaciones proporcionadas por los S.O locales. Tener múltiples hilos de control por proceso nos da una facilidad para la construcción de aplicaciones y un mejor rendimiento. 32 Pregunta 15. Para ejecutar un programa un SO crea un cierto número virtual de procesadores, Column Por qué Verdadero Lo dice el PDF Falso Lo dice el PDF. Es el SO que hace eso Verdadero Lo dice el PDF cada uno ejecuta un programa diferente 16. El middleware se asegura la ejecución concurrente y normal de todos los procesos que comporten la CPU 17. un hilo al igual que un proceso tiene su propio segmento de código, independiente de los otros hilos 18. Los hilos no permiten llamadas al sistema sin bloquear todo el proceso en que se ejecute el hilo Falso Si permite llamadas al sistema sin bloquear todo el proceso 19. Los hilos permiten expresar la comunicación como conexiones lógicas concurrentes 20. La transparencia de distribución involucra oculta retardos en la propagación A definir A definir en redes área amplia 21. Los multihilos del lado del servidor permiten simplificar el código, obtener un paralelismo más sencillo, aumentar la Verdadero Eso es lo que hace xd disponibilidad del cliente 22. La virtualización permite permite el copado dinámico de ambientes de software en servidores laterales 23. El proxy en objetos distribuidos implementa la transparencia de la invocación a objeto remoto para el cliente 24. La transparencia de replicación del lado cliente, se puede implementar mediante replicas de peticiones a los servidores y filtrado de una respuesta a la aplicación Resumen progresivo de S.O.D 33 Pregunta Column Por qué 25. La organización básica de un servidor consta de una espera por una petición entrante del servidor: procesado de la petición, realiza algo con la petición y una espera por la siguiente petición entrante. 26. La localización de un servidor sin asignación previa, se realiza solicitando el puerto a un demonio especial del servidor local, para luego contactar al servidor 27. La interrupción al servidor mediante la técnica de datos fuera de banda se puede implementar con un puerto adicional de control con mayor prioridad que el puerto de servicio del servidor 28. Un cluster consiste de máquinas conectadas a través de una red, organizadas en general en tres niveles: switch, servidor de procesamiento de aplicaciones y servidor procesamiento de datos Unidad 5: Nombres (naming) 📚 Temas: 1. Servicio de nombres. 2. Directorios y servicio de directorios Unidad 6: Consistencia y replicación 📚 Temas: 1. Arquitecturas 2. Modelos de consistencia Resumen progresivo de S.O.D 34 Unidad 7: Archivos y memoria en S.D. 📚 Temas: 1. Sistemas de archivos distribuidos: arquitectura, comunicaciones, sincronización, consistencia y replicación, tolerancia a fallas y seguridad. 2. Memoria en sistemas distribuidos: introducción, cuestiones de diseño e implementación. Consistencia. Unidad 8: Seguridad en S.D 📚 Temas: 1. Introducción a la seguridad 2. Canales desguros 3. Control de acceso 4. Administración de la seguridad Unidad 9: Transacción y control de concurrencia en S.D 📚 Temas: 1. Transacciones 2. Transacciones anidadas 3. Manejo de bloqueos 4. Control básico de concurrencia Resumen progresivo de S.O.D 35
