Sistemas Distribuidos PDF

Summary

This document contains lecture notes on Distributed Systems, covering topics such as definitions, architectures, communication methods, fault tolerance and other relevant considerations. The lecture notes are suitable for undergraduate-level students studying computer science.

Full Transcript

**SISTEMAS DISTRIBUIDOS** **\#Semana 1: Sistemas Distribuidos Definición y tipos** **1. Introducción:** Surge en los 70´, al mismo tiempo de la creación del ethernet y las áreas de red local (LAN). **2. Definición:** Es una colección de dispositivos que trabajan de manera coordinada, para forma...

**SISTEMAS DISTRIBUIDOS** **\#Semana 1: Sistemas Distribuidos Definición y tipos** **1. Introducción:** Surge en los 70´, al mismo tiempo de la creación del ethernet y las áreas de red local (LAN). **2. Definición:** Es una colección de dispositivos que trabajan de manera coordinada, para formar un objetivo en común. → Características: Uso consistente (datos sincronizados) , uniforme (independiente de el lugar desde donde se accede) y transparente (único y homogéneo). → Objetivos: Compartir recursos, ser transparentes con el usuario, ser interoperable (fácil comunicación) con otros sistemas, además de ser escalable. **3. Tipos:** 1. Sistemas distribuidos de alto rendimiento (HPC): procesan tareas intensivas en recursos. → Clusters: Computadoras conectadas mediante una red local (LAN). - Storage.- ofrece almacenamiento distribuido, redundante y es escalable. - High Availability (HA).- garantiza que los servicios sigan disponibles, aún si uno o mas nodos fallan. - Load Balancing (LB).- distribuyen efectivamente las cargas de trabajo entre nodos para optimizar recursos y evitar la sobrecarga. - High performance (HP).- proporciona potencia, divide el trabajo en nodos y trabajan en paralelo. → Grid: Computadoras heterogéneas, colaboran para compartir recursos, además de resolver problemas complejos. 2. Sistemas de información Distribuidos: diseñados para gestionar y compartir información entre diferentes componentes, su propósito principal es integrar soluciones empresariales. 3. Sistema de procesamiento de transacciones: diseñados para gestionar y registrar transacciones de forma confiable y eficiente. 4. Sistema de integración: conocidos como middleware, facilita la comunicación y cooperación entre sistemas. 5. Sistemas distribuidos Omnipresentes: diseñados para mezclarse naturalmente en nuestro entorno. **\#Semana 2: Arquitectura de Sistemas Definición, tipos y estilos** **1. Introducción:** La organización de los componentes es crucial para el funcionamiento eficaz de los sistemas distribuidos. **2. Estilos de arquitectura:** Es la forma de como los componentes (una unidad modular bien definida) se conectan. Nos sirve para intercambiar datos o componentes que requieren de conectores(permite la comunicación entre los componentes). 1. En capas: organización en capas, las capas superiores se comunican con las inferiores. 2. Basada en objetos: sistema en base a un conjunto de objetos, cada objeto corresponde a un componente (conectados a través de mecanismos de llamadas a procedimientos). 3. Orientada a servicios: sistema compuesto por muchos servicios diferentes. \[SOA\] 4. Basada en recursos: se enfoca en la gestión y acceso a recursos (datos/servicios), recursos a través de identificadores únicos como URLs \[RESTful\] 5. De publicación-subscripción: los componentes se comunican publicando y suscribiéndose a eventos. **\#Semana 3: Arquitectura de Sistemas - Modelos de Arquitectura** **1. Sistemas Centralizados:** La centralización se debe a la existencia de un servidor que brinda los recursos solicitados por el cliente. 1. Cliente/Servidor: los clientes solicitan (request) servicios y recursos al servidor, que los procesa y responde (reply). → TCP (orientado a la conexión) y UDP (NO orientado a la conexión). 2. Multicapa: permite la conexión de muchas maquinas, las capas son ( presentación, procesamiento/lógica del negocio y datos). **2. Sistemas descentralizados:** Sistema dividido físicamente en partes equivalentes, cada parte es responsable de la información que le corresponde. Se les conoce como sistema peer-to-peer. → P2P.- Todos los procesos que lo constituyen son todos iguales, debe contar con una simetría en la comunicación de los procesos. 1. P2P Estructurado: redes descentralizadas, nodos organizados según una topología lógica especifica. Guarda pares de clave-valor, cada nodo se responsabiliza por un subconjunto de claves. 2. P2P No Estructurados: nodo mantiene lista ad-hoc de nodos vecinos, los nodos debe descubrir a otros, son escalables. → Flodding.- envía solicitud a nodos vecinos, hasta alcanzar al nodo que contenga los datos buscados. → Random Walk.- envía solicitudes al azar, hasta encontrar los datos o agotar los intentos. 3. P2P Jerárquicamente Organizados: mejora la escalabilidad de los p2p no estructurados, usa nodos especiales. **3. Arquitecturas Hibridas:** Combinación de muchas características de arquitectura (cliente-servidor con arquitectura descentralizada), denominadas super-peer network. 1. Edge Servers: sistemas desplegados de internet "al borde de la red" (red empresa - red internet). → ISP 2. Sistemas Colaborativos Distribuidos: sistemas diseñados para colaborar y compartir, valiéndose de los nodos (proveen información para poder acceder a los recursos de otros nodos). → BitTorrent **\#Semana 4: Middleware** **1. Organización:** Integra sistemas, facilita la comunicación entre componentes (RPC, REST, RMI), hay 2 tipos de patrones: wrappers e interceptores. **2. Wrappers (Adaptadores):** Nos proporciona una "interfaz aceptable", solucionando el problema de las interfaces incompatibles. La función principal de los middleware es facilitar un numero reducido de wrappers, este proceso de llama \[broker\]. →Broker.- maneja los accesos entre diferentes apps, los message broker es una implementación muy común, permiten traducir mensajes entre apps según sus formatos de comunicación. **3. Interceptores:** Son módulos que capturan y modifican solicitudes o respuestas entre los componentes del sistema. Mejoran la gestión del sistema y del propio sistema distribuido como un todo. **4. Middleware modificable:** Permite adaptar el sistema "sin reiniciar los servicios" según las necesidades del sistema mediante la configuración o inclusión de módulos adicionales. **\#Semana 5: PC1** **\#Semana 6: Autoadministración** **1. Autoadministración en SD:** Propiedad de los sistemas en gestionar sus propios recursos y adaptarse a los cambios \[cómputo automático o self-star\]. Se organizan en ciclos de control de retroalimentación, involucran auto reparación, auto configuración, auto optimización, etc. **2. Sistemas de control de retroalimentación:** Sistemas adaptativos mediante uno o mas ciclos de control de retroalimentación, basándose en información sobre el desempeño actual del sistema. Elementos básicos: - Necesita monitoreo constante. - Análisis de mediciones. - Modificación del comportamiento. **3.Monitoreo de sistemas:** Proceso continuo de recopilar y analizar la información {agente} sobre el estado y desempeño de los sistemas distribuidos. Algunos usos comunes son: - Health checking (monitoreo del estado de servicios y reporte). - Telemetría (mediciones remotas de magnitudes físicas). - Automatic Performance Tunning (ajuste automático de rendimiento en sistemas de base de datos). - Network monitoring (monitoreo del estado de la red. → WIRESHARK **4. Estrategias de replicación:** Permite que los servidores distribuyan información en varios servidores replicas \[nodos\], mejorando las disponibilidad, confiabilidad y rendimiento. → HDR (High-Availability Data Replication). **5. Reparación automática de componentes:** Los sistemas distribuidos deben poder agregar y eliminar componentes en tiempo de ejecución, por si algún nodo falla. Cuando un nodo falla este inicia un procedimiento de 'reparación'. **\#Semana 7: Fundamentos de Comunicación** **1. Fundamentos de Comunicación:** Es el pilar esencial en los sistemas distribuidos, permite la interacción de los procesos, componentes y dispositivos de una red. → Componentes de un sistema general de comunicación: - Fuente de información (FI) - Transmisor (T) - Mensaje (M) - Señal (S) - Señal recibida (SR) - Canal de comunicación (C) - Receptor (R) - Destino (D) - Fuente de ruido (FR) **2. Protocolos en capas:** Organizan la comunicación (incluye hardware y software ) entre nodos, garantizando la interoperabilidad. 1. El modelo OSI: modelo conceptual estándar desarrollado por ISO, cuenta con 7 niveles o capas: application (7), presentation (6), session (5), transport (4) network (3), data-link (2) and physical (1). 2. Protocolos de bajo nivel: conformada por las 3 ultimas capas del modelo OSI (network, data link, physical). Ofrecen comunicación básica de la red. → La capa física envía los bits, la capa de enlace efectúa transferencia sin errores y la capa de red enruta los paquetes. 3. Protocolos de transporte: Garantizan que los datos viajen de forma eficiente y fiable entre sistemas. → TCP 4. Protocolos de alto nivel: Están diseñados para proporcionar servicios específicos y permitir que las apps intercambien información (Application, presentation y session). → La capa de sesión permite hacer seguimiento a las sesiones entre aplicaciones. La capa de presentación permite especificar el formato que tendrá la información y procesarlo. 5. Protocolos middleware: Se encuentra en medio de la capa aplicación y transporte, facilita la interacción entre apps y sistemas homogéneos. **3. Tipos de Comunicación:** Estos tipos de comunicación se adaptan a las necesidades de los sistemas cliente-servidor y de apps distribuidas. 1. Persistente: Los mensajes enviados entre sistemas se almacenan en el middleware, hasta que el usuario este disponible para recibirlos. → EMAIL 2. No Persistente: Los mensajes solo se almacenan si el remitente y el destinatario están activos y conectados. → ROUTERS 3. Asíncrona: El remitente puede enviar varios mensajes sin esperar la respuesta del destinatario, el mensaje es almacenado de forma temporal con la supervisión del middleware. 4. Síncrona: El remitente se bloquea y espera una respuesta después de enviar un mensaje. **\#Semana 8: Llamadas a Procedimiento Remoto** **1. Fundamento RPC:** → Remote Procedure Call.- Permite a los programas llamar a funciones o procedimientos ubicados en otras maquinas. - Ventajas: - Transparencia de acceso - Transparencia de ubicación - Fácil de uso - Robusto y probado - Desventajas: - Si el server node tiene problemas, llamar al procedimiento no procederá. - Surgen errores por arquitectura de maquinas diferentes. - Interfaces desactualizadas. **2. Operaciones básicas RPC:** → En la maquina local A, se coloca en la biblioteca del S.O. (Cliente Stub) → En la maquina B se implementa un Server Stub, en donde se recepcionan todas las llamadas y se transforman en llamadas locales. → Cuando el server node ejecuta el procedimiento y devuelve a B, quien lo empaqueta y lo reenvía a A. → Luego que lo recibe, se lo pasa a cliente Stub quien lo examina y repara. → Al finalizar para Cliente y Server Node todo se ha ejecutado localmente. **3. Paso de parámetros:** Para evitar problema de orden de secuencia de bytes se utiliza una transformación (empaquetados de parámetro para su envió \[marshaling\] el proceso inverso es \[unmarshaling\]) de datos con formato independiente de la red. **4. Soporte de apps basada en RPC:** - Basado en generaciones de Stubs: define de forma detallada un protocolo RPC para una aplicación especifica. Se puede utilizar IDL (Interface Definition Language) para generar stubs. - Basado en lenguajes: es independiente del lenguaje de programación, implementa llamadas a procedimiento remoto dentro del lenguaje de programación. **5. Variaciones en RPC:** - Asíncrono: el cliente se bloquea hasta obtener una respuesta del servidor, la respuesta del servidor actúa como una notificación al cliente \[callbacks\]. - Multicast: permite enviar peticiones RPC a múltiples servidores, estos procesan las peticiones en paralelo, cuando devuelven el resultado, el cliente junta y ensambla todo en un solo bloque de datos. **\#Semana 9:** **1. Tipos de comunicación:** Estos tipos de comunicación se adaptan a las necesidades de los sistemas cliente-servidor y de apps distribuidas. 1. Persistente: Los mensajes enviados entre sistemas se almacenan en el middleware, hasta que el usuario este disponible para recibirlos. → EMAIL 2. No Persistente: Los mensajes solo se almacenan si el remitente y el destinatario están activos y conectados. → ROUTERS 3. Asíncrona: El remitente puede enviar varios mensajes sin esperar la respuesta del destinatario, el mensaje es almacenado de forma temporal con la supervisión del middleware. 4. Síncrona: El remitente se bloquea y espera una respuesta después de enviar un mensaje. **2. Comunicación transitoria** orientada a mensajes (Sockets): Es una interfaz API para la comunicación y el estándar de facto. socket → Crear un nuevo end point. bind → Asocia una dirección local a un socket. listen → Indica al OS cuantas conexiones aceptará. accept → Recibe intentos de conexión desde el cliente. connect → Intenta establecer una nueva conexión. send → Envía datos a través de la conexión establecida. receive → Recibe datos a través de la conexión establecida. close → Cierra la conexión. **3. Comunicación persistente** orientada a mensajes: Soportan comunicación asíncrona persistente, ofrecen almacenamiento de termino medio para mensajes sin la necesidad de que el remitente o el destinatario estén activos durante su envió. → Procesamiento de transacciones bancarias. Este tipo de comunicación se centra en insertar mensajes en "colas". Funcionamiento: - El remitente llama a la función put para colocar un mensaje a una cola específica. - Si la cola soporta callbacks , se efectúa la notificación. - El mensaje puede pasar por varios servidores y llegar a su destino que utiliza. → Permite construir soluciones escalables de colas de mensajes. **4. Comunicación multicast:** Para contar con el soporte para poder enviar datos a varios destinatarios (seleccionados), se le denomina comunicación por retransmisión (multicast). - Nivel aplicación.- los nodos se organizan en una red sobrepuesta para diseminar información a sus miembros. → No es tan optima debido a que los nodos pueden estar físicamente a varios saltos. Por ello los nodos se organizan en: árbol o una red mesh (cada nodo se conecta con otro dentro de su alcance). - Basado en inundación (flooding).- enviar el mensaje como si fuera un broadcast, se utiliza cuando no se encuentra información de la red supuesta, solución sencilla pero ineficiente. **\#Semana 10: PC2** **\#Semana 11: Nombres, identificadores y direcciones** **1. Nombres, identificadores y** direcciones: Un nombre es una cadena de bits o caracteres, hace referencia a una entidad (servidores, archivos, discos, redes, etc.) Se usan para compartir recursos, identificar entidades y referenciar ubicaciones. → La resolución de nombres es la capacidad de un proceso para poder encontrar o acceder al nombre, implementando un sistema de nombres \[naming system\]. → Una dirección es un identificador único, para acceder a un punto de acceso en la red. → Un identificador (código a nivel intermedio de los sistemas) es un tipo de nombre que permite identificar de manera única a una entidad. **2. Nombres planos:** A las cadenas aleatorias de bits se les conoce como nombre plano. Estos no contienen información de la ubicación de acceso de una entidad, para ello se usan las técnicas para la resolución. → Broadcast (ej.: protocolo ARP) → Home location (ej.: mobile IP) → Distributed Hash Tables (DHT) **3. Nombres estructurados:** Es un identificador compuesto y legible para los humanos, sigue un formato jerárquico o lógico.La resolución de un nombre estructurado consiste en traducir el nombre en una referencia concreta hacia un recurso o entidad. → Usando un espacio de nombres (namespace) que organiza los nombres de forma jerárquica o lógica. - DNS.- es un sistema de nombres de dominio, se usa para obtener las direcciones IP de host y servidores de correo. Estaba basado en un espacio de nombres jerárquicamente organizado. - NFS.- es un network file system, permite compartir un sistema de archivos a diferentes clientes de manera transparente. Conceptos básicos: - Archivo export Contiene la información de todos los directorios compartidos por el servidor NFS. - Showmount : Esta operación devuelve el contenido del archivo export. - Mount : Esta operación del cliente, permite asociar un directorio compartido con un directorio local - Unmount : Esta operación del cliente, permite desvincular el directorio compartido con su directorio local (previamente montado). **4. Nombres basados en atributos:** Es un método de identificación que describe una identidad utilizando pares de atributo-valor. Para resolver un nombre basado en atributos se realiza una búsqueda en un sistema de nombres (atributo, valor). - LDAP.- Lightweight directory access protocol, es un protocolo de servicio de directorios basado en X.500 de OSI, nos permite acceder a un directorio ordenado y distribuido. → Se basa en una estructura de un árbol jerárquico de registro o entradas de directorio que se organizan en nodos. **\#Semana 12: Sincronización del reloj** **1. Fundamentos de sincronización:** La coordinación es un proceso de naturaleza distribuida que involucra al tiempo, es un aspecto crítico y muy complejo de resolver. → En un sistema distribuido, el tiempo no debe ser ambiguo, permite un acuerdo global con todos los componentes del sistema, además de mitigar los problemas en el funcionamiento del sistema a toda escala. **2. Relojes físicos:** Casi todas las computadoras tiene un circuito de seguimiento de tiempo. básicamente un cronometro (timer), su funcionamiento se basa en la oscilación y el conteo de su frecuencia. → El principal problema es que es imposible garantizar la hora, ya que no es la misma en todos los equipos (distorsión de reloj). **3. Algoritmos de sincronización:** - NTP: network time protocol, es un método para sincronizar un sistema distribuido, los clientes contactan con un servidor NTP, y esta permite estimar retrasos que forma parte de la transmisión de mensajes. →A = Cliente, B = Servidor. NTP tiene en cuenta los retardos que pueden haber en la transferencia de las peticiones. Ambos toman su tiempo en cada paso que dan, así se calcula la compensación. Se almacenan en buffer de 8 pares, para tomar el valor mínimo como la mejor estimación del retraso. NTP, funciona como un nivel de jerarquía denominada STRATUM, a mayor jerarquía más confiable es la hora entregada. → El stratum 0 está asignado a los relojes atómicos. Si A contacta a B, solo actualizará su hora si B está en un stratum superior. - Algoritmo Berkeley: hace lo opuesto a NTP, el servidor consulta a N clientes para promediar el tiempo y devolverlo a los clientes para su sintonización. Al servidor se le conoce como Time daemon. → Suponiendo que tenemos 1 servidor y 2 clientes, el algoritmo base es el siguiente: a) El Time daemon pregunta a los clientes los valores de sus relojes. b) Los clientes responden. c) El Time daemon les indica como ajustar sus relojes. **5. Relojes lógicos:** Los relojes lógicos no tienen en cuenta el tiempo UTC, aquí no importa la precisión del tiempo sino la sincronía de los eventos. - Lamport: se definió una relación llamada ocurrencia anterior → A ⇒ B se lee "A ocurrió antes que B". → Utiliza contadores incrementales ("el tiempo nunca retrocede"). a\) Cada proceso (P) tiene su propio reloj lógico , que aumenta con cada evento a velocidades diferentes. b) Cuando los procesos se envían mensajes, adjuntan su contador y al recibir las respuestas, ajustan su reloj lógico al valor máximo +1 (si es necesario). **\#Semana 13: Exclusión mutua** **1. Aspectos generales:** Propiedad de un sistema distribuido que permite el control recurrente de sus recursos. Evitan que los accesos recurrentes corrompan los recursos o lo vuelvan inconsistentes, se consigue a través de algoritmos distribuidos de exclusión mutua. Clasificación: - Soluciones basadas en token → Usa mensajes especiales llamados token. → Solo hay 1 token disponible. →El que lo tiene, accede al recurso. - Soluciones basadas en permisos → Los procesos solicitan permisos entre sí. **2. Algoritmo centralizado:** Similar al sistema cliente-servidor, donde el servidor otorga permisos, los demás procesos (actúan como cliente) envían peticiones para acceder a un recurso. → Su funcionamiento se basa en la existencia de un **coordinador central** que controla el acceso a los recursos y resuelve conflictos entre las solicitudes de los procesos. Nos garantiza la exclusión mutua, accesos justo, ningún proceso en espera por siempre, además de la fácil implementación. **3. Algoritmo descentralizado:** Se basa en el algoritmo centralizado, usa replica de los recursos, cada replica tiene un coordinador \[algoritmo de votación\]. Para acceder al recurso se debe lograr un voto mayoritario. → Utiliza tablas hash distribuidas (DHT) para replicar los recursos en múltiples nodos, cada recurso se asocia a una clave hash única. Cada nodo mantiene una tabla con las claves hash de los recursos y los nodos responsables de sus réplicas, permitiendo localizar y controlar el acceso a un recurso de manera distribuida, sin depender de un coordinador central. **4. Algoritmo distribuido:** Se basa en Lamport (sincronización), el acceso a los recursos se da entrando a "sección crítica", los nodos la consiguen si los demás nodo le dan acceso y cuando se libera el recurso, se les notifica a todos. → Todos los procesos interesados en acceder a un recurso envían solicitudes con un **timestamp** a los demás procesos. Cada proceso decide otorgar permiso en función del orden temporal de las solicitudes, priorizando las de menor timestamp. Si un proceso no está interesado, responde inmediatamente con un **OK**. Cuando un proceso finaliza el uso del recurso, notifica al siguiente proceso en la cola para que acceda. Garantiza la exclusión mutua, no produce deadlocks (estado de espera continua) y no ocasionan cuellos de botella. **5. Algoritmo token-ring:** Se basa en el uso de un anillo lógico vía software, donde cada proceso es asignado con un orden numérico y solo conoce el número del siguiente nodo. → Un proceso solo puede acceder al recurso compartido si posee el token. Al recibir el token, verifica si necesita el recurso; si no lo necesita, lo pasa al siguiente proceso. Si lo requiere, retiene el token durante el tiempo necesario y, al terminar, lo libera para que continúe circulando. Garantiza la exclusión mutua, no se produce inanición, sencillo de implementar y se recupera bien de las fallas. Rápido y eficiente cuando pocos nodos requieren acceso. **\#Semana 14: Algoritmos de Elección** **1. Aspectos generales:** Es un método utilizado en sistemas distribuidos para designar un proceso como coordinador cuando todos los procesos tienen un estatus igualitario. Este algoritmo garantiza que todos los procesos lleguen a un consenso sobre quién actuará como coordinador, asegurando la coherencia y continuidad del sistema en tareas que requieren un proceso centralizado para coordinar acciones. → Permite elegir un proceso que asumirá el rol de coordinador, garantiza la obediencia de los proceso, aseguran la exclusión mutua. **2. Algoritmo Bully:** Si un proceso detecta que el coordinador no responde, inicia una elección notificando a los procesos con identificadores más altos que el suyo. Si uno de esos procesos responde, asume el control de la elección, descartando al inicial. El proceso con el identificador más alto que no recibe respuestas se convierte en el nuevo coordinador. Si el coordinador anterior se recupera, puede iniciar una nueva elección, restableciendo su rol si tiene el identificador más alto. → Cada proceso tiene un ID asignado: - P envía un mensaje de ELECCION a todos los procesos con IDs superiores al suyo. - Si no le responden, se convierte en Coordinador. - Si algún proceso con ID superior responde, toma el mando. **3. Algoritmo de Anillo:** Este algoritmo, no usa token. Cada proceso conoce quién es su sucesor en el anillo lógico. → Si un proceso detecta que el coordinador no responde, inicia una elección enviando un mensaje a su sucesor, que continúa propagándose por el anillo, cada proceso agrega su identificador al mensaje. Cuando el mensaje regresa al iniciador, este determina el proceso con el identificador más alto como el nuevo coordinador y envía un mensaje de notificación a todos los procesos del anillo para informar el resultado. **4. Algoritmo de elección en ambiente inalámbrico:** En redes inalámbricas, los algoritmos de elección tradicionales no funcionan bien porque los mensajes pueden perderse y la red cambia constantemente debido al movimiento de los nodos. Esto ocurre especialmente en redes móviles, donde es necesario usar algoritmos adaptativos para elegir un coordinador de manera confiable. → En el algoritmo para redes inalámbricas, un nodo inicial (en este caso, **a(4)**) empieza una elección enviando un mensaje a sus vecinos. Cada nodo que recibe el mensaje selecciona quién será su \"padre\" y retransmite el mensaje a sus propios vecinos. Si un nodo recibe el mensaje de varios lados, elige al mejor \"padre\" según quién llegó primero o quién es más potente. Cuando el mensaje ya no puede avanzar, cada nodo informa a su \"padre\" sobre el nodo más fuerte que encontró. Al final, el nodo inicial recopila toda la información y elige al nodo más potente (**h(8)**) como el nuevo coordinador. **5. Algoritmo de elección en sistemas de gran escala:** En sistemas de gran escala, los algoritmos tradicionales no son suficientes, ya que concentran toda la selección en un único nodo. En estos casos, se utilizan **múltiples nodos coordinadores** que trabajan juntos, distribuyendo la carga de gestión. Estos coordinadores tienen un rol similar al de los **super peers** en redes punto a punto, manejando tareas de control y comunicación de manera más eficiente y escalable para soportar un mayor número de nodos. → Requerimientos para la selección de super peers - Los nodos normales deben tener acceso de baja latencia a los super peers. - Los super peers deben distribuirse uniformemente a través de la red superpuesta. - Debe haber una porción predefinida de super peers relativa al nro. de nodos totales. - Cada super peer debe soportar un nro. fijo de nodos normales. **\#Semana 15: PC3** **\#Semana 16: Tolerancia a fallas** **1. Aspectos generales:** Una falla parcial, es una que afecta a un componente en particular, afectando así la operación de varios componentes. 1. Conceptos básicos: En un sistema no distribuido una falla es a menudo total y trae abajo todo el sistema. El sistema debe continuar operando de modo aceptable mientas se realizan las reparaciones (sistema fiable). 2. Tipos de falla: - Falla transitoria : Son fallas que ocurren una vez y luego desaparecen, suelen ser por causas fortuitas. - Falla intermitente : Aparece y reaparece cada cierto tiempo, son difíciles de diagnosticar y causan muchos problemas. - Falla permanente : No desaparece hasta que el componente defectuoso sea reemplazado. → Para que un sistema sea fiable debe: - Estar disponible - Ser confiable - Ser seguro - Contra con mantenimiento c\. Modelos de falla: **Tipo de falla** **Descripción** -------------------------------- ------------------------------------------------------------------- Falla de congelamiento (Crash) Un servidor trabajaba correctamente y se detuvo Falla de omisión Un servidor no responde a las peticiones entrantes Omisión de recepción Un servidor no recibe mensajes entrantes Omisión de envío Un servidor no envía mensajes Falla de tiempo La respuesta del servidor está fuera del intervalo de tiempo Falla de respuesta La respuesta de un servidor es incorrecta Falla de valor El valor de la respuesta es incorrecta Falla de transición de estado El servidor se desvía del flujo de control correcto Falla arbitraria Un servidor produce respuestas arbitrarias en tiempos arbitrarios **2. Atenuación:** Propone el uso de varios proceso idénticos en un grupo como aspecto cable para la tolerancia a fallas. Su implementación puede ser como un grupo simple o jerárquico. → En un grupo simple, todos los procesos son idénticos y las decisiones se toman de manera colectiva. Es simétrico y no tiene puntos únicos de falla. Si un proceso falla, el grupo solamente se reduce. Las decisiones son más complejas. → En un grupo jerárquico, los procesos se organizan en una jerarquía de mando y se elige a un coordinador. Permite decisiones rápidas y simples pero es más propenso a fallas. - Gestión de membresía: son los mecanismos que permiten que los procesos se unan o se retiren de un grupo. Un enfoque común es usar un **servidor de grupo**, que es rápido y sencillo de implementar, pero presenta el riesgo de ser un **punto único de falla**. Otra alternativa es el **multicasting**, que permite que los mensajes sean enviados a múltiples miembros del grupo sin depender de un servidor central, mejorando la resiliencia y escalabilidad del sistema. - Enmascaramiento de fallas y replicación: es una técnica para asegurar que un sistema distribuido siga funcionando incluso si algunos de sus componentes fallan. **La replicación** es una forma de hacerlo, creando copias de procesos o recursos para que, si uno falla, otro pueda tomar su lugar. Existen dos formas principales de replicación: 1. **Protocolo Primary-Based**: protocolo donde existe un **ente primario** que se encarga de coordinar todas las operaciones de escritura en un sistema. Los demás nodos en el sistema actúan como **backups** (copias) que almacenan la información replicada. 2. **Protocolo Replicated Write**: enfoque de **replicación activa** mediante **protocolos basados en quorum**. En este modelo, un grupo de procesos se organiza en un **grupo simple**, donde todos los nodos pueden participar activamente en las operaciones de escritura. - Detección de fallas: es crucial para la **tolerancia a fallas** en sistemas distribuidos. En un grupo de procesos, los nodos **no defectuosos** deben ser capaces de identificar cuándo un nodo ha fallado. Generalmente, esto se logra mediante un proceso conocido como **ping**, donde los nodos envían señales periódicas para verificar si otros están activos. Sin embargo, es importante diferenciar entre **fallas de red** y **fallas de nodo**, ya que un nodo puede no responder debido a problemas de red y no necesariamente porque haya fallado. La **transmisión del estado** de cada nodo entre todos los nodos es crítica para detectar y manejar estas fallas correctamente. **3. Comunicación confiable:** - Entre cliente y servidor: no solo debe enfocarse en la tolerancia a fallas de los **procesos defectuosos**, sino también en las **fallas en la comunicación**. Estas fallas en el canal de comunicación pueden manifestarse de diversas formas: 1. **Congelamiento**: Cuando un canal deja de transmitir datos. 2. **Omisión**: Cuando un mensaje enviado no llega a su destino. 3. **Tiempo**: Cuando el mensaje tarda más de lo esperado, provocando retrasos. 4. **Fallos arbitrarios**: Errores impredecibles que afectan la integridad de los datos transmitidos. - Comunicación punto a punto: se logra comúnmente a través de **protocolos de transporte confiables** como **TCP** (Transmisión Control Protocol). Este protocolo garantiza que los mensajes lleguen de forma confiable entre los puntos de comunicación, y maneja ciertas fallas, como: 5. **Fallas por omisión**: Si un mensaje no llega a su destino, TCP asegura que se reenvíe hasta que se confirme la recepción. 6. **Fallas por congelación**: Este tipo de fallas, que ocurren cuando un canal de comunicación deja de funcionar temporalmente, son más complejas. Sin embargo, TCP permite establecer una nueva conexión para continuar la comunicación en caso de que falle la anterior. - Fallas en RPC: pueden interferir con la comunicación entre el cliente y el servidor. Algunas de las fallas más comunes incluyen: 1. **El cliente no puede localizar al servidor**: Puede ocurrir cuando el servidor está apagado o si hay versiones incompatibles del software. Se puede resolver implementando excepciones en los lenguajes de programación. 2. **La petición del cliente o la respuesta del servidor se pierde**: Es una falla sencilla de solucionar. Se usa un cronómetro para cada mensaje enviado, y si el cronómetro expira, se reenvía el mensaje. El servidor o el cliente no diferencian entre la retransmisión y el primer envío. 3. **El servidor se congela después de recibir una petición**: Esta es más compleja. La solución generalmente involucra retransmisiones, ya sea antes o después de que el servidor ejecute la petición. 4. **El cliente se congela después de emitir una petición**: Es la falla más difícil de solucionar, ya que puede generar \"huérfanos\", que son cálculos realizados por el servidor sin que un cliente espere los resultados, lo que consume recursos innecesarios o genera bloqueos. **\#Semana 17: REPASO** **\#Semana 18: EXAMEN FINAL**

Use Quizgecko on...
Browser
Browser