Tema 2.1 Comunicación en Sistemas Distribuidos PDF

TEMA 2.1 COMUNICACIÓN EN SISTEMAS DISTRIBUIDOS Índice de contenidos 1. Repaso protocolos en capas. 2. Tipos de comunicación. (Entra en teoría, solo saber cómo funciona y tipos de comunicación) 3. Llamadas a procedimientos remotos. (Entra en t...

TEMA 2.1 COMUNICACIÓN EN SISTEMAS DISTRIBUIDOS Índice de contenidos 1. Repaso protocolos en capas. 2. Tipos de comunicación. (Entra en teoría, solo saber cómo funciona y tipos de comunicación) 3. Llamadas a procedimientos remotos. (Entra en teoría) 4. Comunicación orientada a mensajes. (Entra en teoría) 5. Comunicación multitransmisión. (Entra en teoría) 1. Repaso de protocolo en capas 1.1 Capa de middleware El middleware se inventa para proporcionar servicios y protocolos comunes que pueden ser utilizados por muchas aplicaciones diferentes. - Un amplio conjunto de protocolos de comunicación. - (Un)marshaling de datos, necesarios para los sistemas integrados. - Protocolos de nombrado, para permitir compartir fácilmente los recursos. - Protocolos de seguridad para una comunicación segura. - Mecanismos de escalado, como la replicación y el almacenamiento en caché. Nota: Lo que queda son protocolos verdaderamente especí cos de la aplicación... ¿cómo? (Un)marshaling: Tomar un dato complejo, formatearlo, y cuando llega a la aplicación B, la aplicación hace el proceso ((Un)marshaling) para ver el dato sin formalizar. Es decir, convierte los datos recibidos o almacenados en una representación que pueda ser utilizada nuevamente en su formato original dentro de un programa o sistema. 1.2 Esquema de capas adaptado Luego de modi car el modelo OSI: Mantenemos aplicación, ponemos middleware, y aparecen sistema operativo y hardware. Esquema simpli cado de capas para la comunicación en redes, diferente al modelo OSI. Aquí, las capas se agrupan de manera más general. Cada capa está asociada a protocolos especí cos que gestionan las funciones correspondientes, desde la transmisión física de los datos hasta la interacción a nivel de aplicación. 2. Tipos de comunicación 1. Comunicación transitoria vs. Comunicación persistente. 2. Comunicación asíncrona vs. comunicación síncrona. Sincronización al enviar la solicitud: El cliente envía la solicitud al servidor y se sincroniza en ese momento. Luego, puede continuar sin esperar a que la solicitud sea procesada ni recibida. Sincronización al recibir la solicitud: El cliente se sincroniza cuando el servidor recibe la solicitud, pero no espera a que se procese completamente. Sincronización después del procesamiento: El cliente espera hasta que el servidor procese completamente la solicitud y envíe la respuesta antes de continuar. 2.1 Comunicación transitoria vs. Comunicación persistente Comunicación transitoria: El servidor de comunicaciones descarta el mensaje cuando no se puede entregar en el siguiente servidor o en el receptor. El cliente y servidor deben conocerse y la comunicación sucede de forma directa, nada se almacena en ningún sitio, si uno de los dos cae, los mensajes se pierden. Es decir, la comunicación dura lo que dure la conexión. Ejemplo: P2P. Comunicación persistente: Un mensaje se almacena en un servidor de comunicaciones el tiempo que sea necesario para entregarlo. Alguien se encarga de controlar que si la comunicación cae, la conexión persista. Ejemplo: Correo. 2.2 Comunicación asíncrona vs. comunicación síncrona Comunicación asíncrona: Los participantes no interactúan en tiempo real, sino que pueden responder en momentos diferentes. Puede ocurrir que uno de los participantes de la comunicación no esté despierto. Ejemplo. Sistemas de mensajería. Comunicación síncrona: Los participantes se comunican en tiempo real, es decir, al mismo tiempo. Implica que ambos participantes estén despiertos. Ejemplo. Llamada a RPC. Página 1 fi fi fi fi 2.3 Donde hacer la sincronización (Tipos de sincronización) - Al enviar la solicitud. - Entrega bajo petición. - Después del procesamiento de la solicitud. 2.4 Cliente/servidor La computación cliente/servidor generalmente se basa en un modelo de comunicación síncrona transitoria: - El cliente y el servidor deben estar activos en el momento de la comunicación. - El cliente emite la solicitud y se bloquea hasta que recibe respuesta. - Básicamente, el servidor espera solo las solicitudes entrantes y, posteriormente, las procesa. Inconvenientes: Comunicación síncrona - El cliente no puede hacer ningún otro trabajo mientras espera la respuesta. - Los fallos deben manejarse de inmediato —> el cliente está bloqueado esperando. - El modelo puede simplemente no ser apropiado (correo, noticias). 2.5 Mensajería Middleware orientado a mensajes. Tiene como objetivo la comunicación asíncrona persistente de alto nivel: - Los procesos se envían mensajes entre sí, que están en cola. No puede almacenar in nito. - El remitente no necesita esperar una respuesta inmediata, pero puede hacer otras cosas. - El middleware a menudo garantiza la tolerancia a fallos, porque si se cae una el sistema sigue funcionado. 3. Llamadas a procesamientos remotos 3.1 Funcionamiento básico de RPC Observaciones: - Los desarrolladores de aplicaciones están familiarizados con el modelo de procedimiento simple. - Los procedimientos bien diseñados operan de forma aislada (black box). - No hay ninguna razón fundamental para no ejecutar procedimientos en una máquina separada. Esquema de llamada a RPC. Se tienen comunicaciones síncronas por defecto, por el hecho de que el cliente espera y está bloqueado hasta que el servidor responda. Conclusión: La comunicación entre la persona que llama y el destinatario de la llamada se puede ocultar mediante el mecanismo de llamada de procedimiento. La maquina cliente pretende ejecutar un proceso que no se encuentra en ella, sino en la máquina servidor. Pasos para que esto ocurra: 1. El procedimiento del cliente llama al Stub del cliente. 2. Stub genera mensaje; llama al sistema operativo local. 3. El sistema operativo envía un mensaje al sistema operativo remoto. 4. El sistema operativo remoto envía un mensaje al Stub. 5. Stub descomprime los parámetros; llama al servidor. 6. El servidor realiza llamadas locales; devuelve el resultado a Stub. 7. Stub genera mensaje; llama al sistema operativo. 8. El sistema operativo envía un mensaje al sistema operativo del cliente. 9. El sistema operativo del cliente envía un mensaje a Stub. 10. Client Stub descomprime el resultado; devoluciones al cliente. 3.2 RPC: Paso de parámetros Hay más que simplemente envolver parámetros en un mensaje. Las máquinas cliente y servidor pueden tener diferentes representaciones de datos (Ejemplo: en el orden de bytes). Envolver (wrap) un parámetro (en el stub) signi ca transformar un valor en una secuencia de bytes. El cliente y el servidor tienen que acordar la misma codi cación: - Cómo se representan los valores de datos básicos (enteros, otantes, caracteres). - Cómo se representan los valores de datos complejos (arrays, uniones). Conclusión: Cliente y Servidor necesitan interpretar correctamente los mensajes, transformándolos en representaciones dependientes de la máquina. Página 2 fi fi fl fi Algunos supuestos: - Semántica de copia de entrada/copia de salida. Mientras se ejecuta el procedimiento, no se puede suponer nada sobre los valores de los parámetros. No se toca el objeto original, siempre se trabaja sobre una copia. - Todos los datos que se van a operar se pasan por parámetros. Excluye referencias de paso a datos (globales). No se pasan variables globales, todo se pasa como atributos sobre los que se quiere trabajar. Conclusión para aumentar la transparencia: - No se puede lograr una transparencia total del acceso. - Un mecanismo de referencia remota mejora la transparencia del acceso. - La referencia remota ofrece acceso uni cado a datos remotos. - Las referencias remotas se pueden pasar como parámetro en RPC. - Nota. Los stubs a veces se pueden usar como tales referencias. Empaquetar todo y enviar el stub (código entero) junto con los procesos, en caso de que sea necesario o sea un programa complejo. Pasar un objeto por referencia o por valor: La máquina A tiene referencia a un objeto local O1. La máquina B tiene una referencia remota del O1 (O2). La máquina C tiene una copia del objeto de la máquina A (copy of O1). (Como querer hacer una pizza, necesitas la masa y tu madre te dice que vayas por ella al super, que está en el pasillo 3. Así que vas con esa información al super para encontrar la masa) Una función con su correspondiente mensaje, y el orden por el cual los bytes y palabras son enviados a través de la red. ¿Qué hay detrás de esas llamadas? Un conjunto de palabras cada una compuesta de unos bytes. Primero se pasa el tamaño del array, y luego su información en palabras. El orden es importante: Primero el identi cador de función, luego el tamaño del array y luego si contenido. 3.3 RPC Asíncronas Intentar deshacerse del comportamiento estricto de solicitud-respuesta, pero dejar que el cliente continúe sin esperar una respuesta del servidor. 3.4 Envio de varios RPC Envío de una solicitud RPC a un grupo de servidores. Posibilidad de enviar una solicitud a varios por razones como: reparto de carga, reparto de tareas, por seguridad, por tolerancia a fallos, o porque no quieras que te engañen, entonces preguntas a varios a ver qué resultado dan y para ver si coinciden. Página 3 fi fi 4. Comunicación orientada a mensajes 4.1 Mensajería transitoria: Sockets Interfaz de socket Berkeley: Comunicación entre sockets. Lo primero que hace el servidor es crear el socket a partir del cual los clientes se van a conectar (a través de una IP y un puerto) y queda a la escucha de solicitudes. Se queda bloqueado y en espera hasta que llegue una conexión. Y luego sucede el intercambio de información. 4.2 Facilitar el trabajo con los sockets - Los sockets son de nivel bastante bajo y los errores de programación se cometen fácilmente. - Sin embargo, la forma en que se usan suele ser la misma (como en una con guración cliente-servidor). Alternativa: ZeroMQ (biblioteca para elaborar aplicaciones distribuidas). - Proporciona un mayor nivel de expresión mediante el emparejamiento de sockets: Uno para enviar mensajes en el proceso P. Uno correspondiente en el proceso Q para recibir mensajes. Toda la comunicación es asíncrona. Cada par de sockets P-Q soporta estos tres patrones: - Solicitud - Respuesta. - Emisor - Suscriptor. - Pipeline. 4.3 Interfaz de paso de mensajes (MPI): Cuando se necesita mucha exibilidad Búsqueda de primitivas orientadas a mensajes para desarrollo e ciente de aplicaciones. Sockets ine cientes: - Sólo soportan primitivas de enviar y recibir. - Diseñados para comunicación a través de redes mediante protocolos como TCP/IP. Sockets no adecuados para protocolos privados para redes de alta velocidad ( como los clústeres): - Se requieren nuevas y mejores formas de utilizar el búfer y la sincronización. - Producción de bibliotecas propietarias mutuamente incompatibles, porque cada uno trabaja de una manera o de otra. - Elaboración de estándar Interfaz de Paso de Mensajes (MPI). MPI diseñada para aplicaciones paralelas: - Confeccionado para comunicación transitoria. - Uso directo de la red subyacente. - Asume que ciertos fallos son fatales y no requieren recuperación automática. Asume la comunicación dentro de un grupo de procesos: - Cada grupo tiene asignado un identi cador, porque hay aplicaciones con varios procesos trabajando, entonces se identi can los grupos. Sirve para que se le puede asignar a un grupo un mismo trabajo. - Cada proceso de un grupo tiene asignado otro identi cador. - Par (Id_grupo, Id_proceso). Puede haber diversos grupos de procesos involucrados en el mismo cálculo y que estén en ejecución al mismo tiempo. Página 4 fi fi fi fi fl fi fi 4.4 Interfaz de paso de mensajes (MPI): Operaciones representativas 4.5 Comunicación persistente orientada a mensajes Servicio middle orientado a mensajes: - Conocido como Sistemas de Colas de Mensajes. - También como Middleware Orientado a Mensajes (MOM). Amplio soporte para comunicación asíncrona persistente. Ofrecen almacenamiento de mensajes en un plazo intermedio: Emisor/Receptor no necesitan estar activos durante la transmisión. Orientado a mensajes que tardan minutos en lugar de segundos o milisegundos: Diferencia relevante con Sockets y MPI. Modelo de colas de mensajes: - Comunicación basada en la inserción de mensajes en colas especí cas. - Una cola puede ser leída sólo por su aplicación asociada: Es posible que varias aplicaciones compartan una sola cola. - No garantizan que el mensaje sea leído, sólo que se inserta en cola. - Cola independiente de la ejecución del remitente o destinatario. - Mensajes con cualquier información: Direccionamiento adecuado desde el punto de vista del middleware. 4.6 Mensajería basada en colas Cuatro posibles combinaciones: Middleware orientado a mensajes (MOM): Esencia. Comunicación persistente asíncrona mediante la compatibilidad con colas a nivel de middleware. Las colas corresponden a búferes en los servidores de comunicaciones. Operaciones: Arquitectura general de un sistema de colas de mensajes: Gestores de colas. Las colas son administradas por administradores de colas. Una aplicación sólo puede colocar mensajes en una cola local. Obtener un mensaje es posible extrayéndolo solo de una cola local —> Los gestores de colas necesitan enrutar los mensajes. Página 5 fi Enrutamiento Proceso separado / Uso de librerías: Vinculado siempre a la aplicación. Gestor de cola y aplicación como instancias locales. Problemas - Hacer que los mensajes lleguen al destino. - Hacer saber al gestor de colas de la asociación nombre-dirección. - Escalabilidad —> No todos pueden conocer a todos. Agentes de mensajes: Observación. Los sistemas de cola de mensajes asumen un protocolo de mensajería común: todas las aplicaciones acuerdan el formato del mensaje (es decir, la estructura y la representación de datos). Broker (agente) maneja la heterogeneidad de la aplicación en un sistema MQ: - Transforma los mensajes entrantes al formato de destino. - Es otra aplicación más, independiente del emisor/destinatario: No se considera parte del sistema de colas. - Muy a menudo actúa como una puerta de enlace de aplicaciones. - Puede proporcionar capacidades de enrutamiento basadas en sujetos (es decir, capacidades de publicación-suscripción). Arquitectura general El agente de mensajes es un gestor de las colas, tanto local como destino. 4.7 Ejemplo: Advanced Message Queuing Protocol (AMQP) Falta de estandarización: Advanced Message-Queue Protocol (AMQP) estaba destinado a desempeñar el mismo papel que, por ejemplo, TCP en redes: un protocolo para mensajería de alto nivel con diferentes implementaciones. Los stub son los encargados de hacer unmarshalling. Modelo básico: El cliente con gura una conexión (estable), que es un contenedor para canales unidireccionales varios (posiblemente efímeros). Dos canales unidireccionales pueden formar una sesión. Un enlace es similar a un socket y mantiene el estado sobre las transferencias de mensajes. Interoperabilidad entre aplicaciones pero no entre sistemas de colas. Los sistemas de colas se vinculan con aplicaciones: Normalmente basados en modelos propietarios. Comunicación AMQP: - Conexión a sistema de colas estable. - Una conexión soporta múltiples sesiones. - Un canal no tiene que formar siempre parte de una session. Enlace necesario para mantener seguimiento del estado de los mensajes enviados: Cada mensaje asociado con un enlace especí co. Mensajería AMQP: - Soporta fragmentación y ensamblado de mensajes. - Mensajería persistente. Página 6 fi fi 5. Comunicación multitransmisión 5.1 Comunicación multidifusión Multidifusión a nivel de aplicación (ALM): Organizar nodos de un sistema distribuido en una red superpuesta y utilizar esa red para difundir datos: - A menudo un árbol, que conduce a caminos únicos. - Alternativamente, también redes de malla, que requieren una forma de enrutamiento. Comunicación multicast también mediante otros caminos que sea establecer explícitamente rutas: Difusión de información por medio de rumores. Multidifusión a nivel de aplicación en CHORD: Enfoque básico: 1. El iniciador genera un identi cador de multidifusión: m_id. 2. Determinar el nodo responsable el identi cador m_id. 3. La solicitud se enruta al nodo sucesor de m_id, que se convertirá en la raíz del árbol de multidifusión. 4. Si P quiere unirse, envía una solicitud de unión a la raíz. 5. Cuando la solicitud llega a Q: - Q no ha visto una solicitud de unión antes —> se convierte en reenviador; P se convierte en hijo de Q. La solicitud de unión continúa siendo reenviada. - Q conoce el árbol —> P se convierte en hijo de Q. Ya no es necesario reenviar la solicitud de unión. ALM: Métricas/Cálculo costes: Diferentes métricas: Tensión de enlace. ¿Con qué frecuencia un mensaje ALM cruza el mismo vínculo físico? Ejemplo: el mensaje de A a D debe cruzar ⟨Ra, Rb⟩ dos veces. Elasticidad. Relación de retraso entre la ruta de acceso de nivel de ALM y la ruta de acceso de nivel de red. Ejemplo: los mensajes B a C siguen una ruta de longitud 73 en ALM, pero 47 en el nivel de red —> estiramiento = 73/47. Flooding: Esencia. P simplemente envía un mensaje m a cada uno de sus vecinos. Cada vecino reenviará ese mensaje, excepto a P, y solo si no había visto m antes. Variación. Dejemos que Q reenvíe un mensaje con una cierta probabilidad p ood, posiblemente incluso dependiente de su propio número de vecinos (es decir, grado de nodo) o del grado de sus vecinos. Protocolos epidémicos (GOSSIP): Supongamos que no hay con ictos de escritura-escritura: - Las operaciones de actualización se realizan en un único servidor. - Una réplica pasa el estado actualizado solo a unos pocos vecinos. - La propagación de la actualización es lenta, es decir, no es inmediata. - Eventualmente, cada actualización debería llegar a todas las réplicas. Dos formas de epidemias: - Anti-entropía. Cada réplica elige regularmente otra réplica al azar e intercambia diferencias de estado, lo que lleva a estados idénticos en ambos después. - Difusión de rumores. Una réplica que acaba de ser actualizada (es decir, ha sido contaminada), informa a varias otras réplicas sobre su actualización (contaminándolas también). Página 7 fi fl fi fl  Anti-Entropía: Operaciones principales: - Un nodo P selecciona otro nodo Q del sistema al azar. - Pull. P solo extrae nuevas actualizaciones de Q. - Push. P solo envía sus propias actualizaciones a Q. - Push-pull. P y Q se envían actualizaciones entre sí. Observación: Para push-pull se necesitan O(log(N)) rondas para difundir actualizaciones a todos los N nodos (ronda = cuando cada nodo ha tomado la iniciativa de iniciar un intercambio). Anti-Entropía: Análisis: Básico. Considere una sola fuente, propagando su actualización. Sea pi la probabilidad de que un nodo no haya recibido la actualización después de la i-ésima ronda. Análisis. Permanecer ignorante: Con pull, p(i + 1) = (pi)2. El nodo no se actualizó durante la i-ésima ronda y debería ponerse en contacto con otro nodo ignorante durante la siguiente ronda. Con push, p(i + 1) = pi(1 - (1 / N - 1)) (N - 1) (1 - pi) ≈ pie -1 (para pequeñas pi y grandes N). El nodo era ignorante durante la i-ésima ronda y ningún nodo actualizado elige contactarlo durante la próxima ronda. Con push-pull: (pi)2 (pie -1). Anti-Entropía: Rendimiento Difusión de rumores: Modelo básico. Un servidor S que tiene una actualización para informar, se pone en contacto con otros servidores. Si se contacta con un servidor al que ya se ha propagado la actualización, S deja de ponerse en contacto con otros servidores con probabilidad pstop. Observación: Si s es la fracción de servidores ignorantes (es decir, que no son conscientes de la actualización), se puede demostrar que con muchos servidores: Difusión de rumores: Análisis formal: Notaciones. Sea s la fracción de nodos que aún no se han actualizado (es decir, susceptibles; i la fracción de nodos actualizados (infectados) y activos; y son la fracción de nodos actualizados que abandonaron (eliminados). De la teoría de las epidemias: Deriva en: i (1) = 0 —> 1 + pstop —> i (s) = (1 + pstop) · (1 - s) + pstop · ln(s) Buscamos el caso i (1) = 0, lo que lleva a = e - (1/pstop + 1) (1 - s) El efecto de detenerse: Nota. Si realmente tenemos que asegurarnos de que todos los servidores se actualicen eventualmente, la propagación de rumores por sí sola no es su ciente. Página 8 fi Eliminación de datos: Problema fundamental. No podemos eliminar un valor antiguo de un servidor y esperar que la eliminación se propague. En cambio, la mera eliminación se deshará a su debido tiempo utilizando algoritmos epidémicos. Solución. La eliminación debe registrarse como una actualización especial insertando un certi cado de defunción. Cuándo eliminar un certi cado de defunción (no está permitido quedarse para siempre): - Ejecutar un algoritmo global para detectar si la eliminación es conocida en todas partes y, a continuación, recopilar los certi cados de defunción (como la recolección de basura). - Suponer que los certi cados de defunción se propagan en tiempo nito y asociar una duración máxima para un certi cado (se puede hacer a riesgo de no llegar a todos los servidores). Nota. Es necesario que una eliminación llegue realmente a todos los servidores. Página 9 fi fi fi fi fi fi