Replicacin Sistemas Distribudos Objetivos z Aumentar la disponibilidad

Replicación Sistemas Distribuídos

Objetivos z. Aumentar la disponibilidad z. Mejorar los tiempos de respuesta z. Incrementar la tolerancia a fallas

Candidatos a replicación z. Datos (por ejemplo, una base de datos críticos) z. Servicios: y. Comunicaciones y. Servicio de nombres y. Servicio de archivos z. Recursos en general

Concepto z. Replicación es el mantenimiento de copias on-line de datos y otros recursos, a fin de alcanzar mejor perfomance, alta disponibilidad y tolerancia a fallas z. Ejemplos de replicación en Internet: y. El servicio DNS y. El Servicio USENET (Internet News)

Mejoras en la perfomance z. Múltiples clientes accediendo a un solo servidor lo transforman en un cuello de botella: por encima de un nro. máximo de requerimientos por segundo, el tiempo medio de respuesta cae significativamente z. Múltiples servidores atendiendo a subconjuntos de clientes permiten mejorar el tiempo medio de respuesta

Mejoras en la disponibilidad z. Datos replicados en dos servidores independientes, conectados a la red por vínculos independientes permiten seleccionar al otro servidor ante la falla de uno cualquiera de ellos o de su enlace

Mejoras en la disponibilidad z. Supongamos n servidores replicados, cada uno con una probabilidad p de falla independiente. La disponibilidad de los datos será: d = 1 - (prob. todos los serv en falla) = 1 - pn

Tolerancia a Fallas z. Tipos de falla cubiertos por la replicación: y. Fallas bizantinas o arbitrarias (resultados incorrectos) y. Fallas de parada: un componente entra en un estado de falla detectable

Tolerancia a Fallas z. Una réplica cualquiera podrá seguir prestando servicio ante la falla de otra z. Un conjunto de réplicas puede producir un dato correcto mediante una elección por mayoría, frente a fallas aleatorias en una cualquiera de las réplicas

Requerimientos z. Transparencia de replicación: y. Los clientes no deben tener percepción de la existencia de múltiples copias físicas del objeto referenciado nombre único y conjunto de resultados único z. Consistencia: y. Las mismas operaciones sobre los mismos objetos hechas por distintos clientes deben producir idénticos resultados

Operaciones de acceso a objetos zread: lectura del estado de un objeto (no lo modifica) zwrite: cambio del estado de un objeto (lo modifica) también llamada update u overwrite

Operaciones de lectura Leer uno (primario) lectura Leer uno Leer quorum

Operaciones de escritura Escribir uno (primario) Sobreescribir Escribir todos los disponibles Escritura Leer y modificar Escribir un quorum Escribir Gossip

Modelos de Replicación z. Asíncrono: y. Todos los requerimientos de un cliente son atendidos por su servidor local (el mas cercano en términos de red) y. El ordenamiento de las operaciones puede diferir entre réplicas. y. Cuando un servidor procesa un update desde un cliente local lo propaga al resto de los servidores de réplica

Modelos de Replicación z. Sincrónico total: y. Todo requerimiento de update se procesa en orden temporal y. Sólo cuando todas las réplicas procesaron la operación, el control retorna al cliente y. Es un modelo de consistencia estricta, en el cual los tiempos de respuesta son mayores al asíncrono

Técnicas de diseño z. Los esquemas reales utilizan un punto intermedio entre el modelo asíncrono y el sincrónico total: y. Esquemas basados en quorum: requieren la participación de un subconjunto de las réplicas activas y. Esquemas basados en causalidad: imponen ordenamiento sólo a las operaciones que lo requieren.

Modelo Arquitectural Front Ends cliente FE Servicio replicado AR AR cliente FE Requerimientos y respuestas AR Administradores de réplica

Componentes del modelo z. Clientes: procesos usuarios del servicio z. Front-Ends: responsable de la comunicación con uno o mas AR’s, abstraen al cliente de la implementación del servicio z. Administradores de réplica: procesos que contienen las réplicas y efectúan operaciones directamente sobre ellas

Implementación I: Gossip mensajes cliente FE AR AR cliente FE FE cliente AR Cada FE se comunica con uno o mas AR’s para satisfacer el requerimiento del cliente. Los AR intercambian mensajes (gossip), propagando los cambios registrados

Implementación II: Réplica primaria Primario cliente FE AR AR cliente FE En rojo: escrituras En verde: lecturas FE cliente AR Secundarios Cada FE se comunica con el AR designado primario cuando la operación requerida es un update. El AR primario propaga los cambios al resto de los AR’s.

Réplica primaria z. Para las operaciones de lectura, los FE’s pueden utilizar cualquier AR, dado que el modelo garantiza que todos están sincronizados. z. En la eventualidad de falla del AR primario, un algoritmo distribuido fuerza una elección de otro AR para promoverlo a primario

Consistencia y ordenamiento de requerimientos z. Asumimos que cada Administrador de Réplica: y. Procesa un requerimiento por vez (o, si es multithreaded, suponemos equivalencia serial) y. Es una máquina de estados, es decir, los datos administrados tienen valores en función del valor inicial y de la secuencia de operaciones aplicadas

Ordenamiento z. Requerimientos totalmente ordenados: y. Dados requerimientos {r 1, r 2}, se asegura que: yr 1 es procesado antes que r 2 en todas los AR, o yr 2 es procesado antes que r 1 en todas los AR

Ordenamiento causal z. Establece una relación causal entre dos eventos (requerimientos): yr 1 sucedió antes que r 2 si hubo un flujo de información desde r 1 hacia r 2 y. Dada esta relación, r 1 debe procesarse antes que r 2 en todos los AR z. El ordenamiento total no necesariamente es causal.

Ordenamiento Sincrónico z. Permite establecer eventos de sincronización, que imponen a todas las réplicas respetar el ordenamiento consistentemente, antes o después del evento de sincronzación.

Diagramas de ordenamiento FE 1 t 1 c 2 AR 1 AR 2 AR 3 FE 2 Totalmente t 2 Ordenado Ord. Causal (c 1 y c 2) Arbitrario (c 3) c 3

Ordenamiento Sincrónico FE 1 S AR 1 AR 2 AR 3 FE 2 c 1 t 1 c 2 t 2 c 1, c 2: causal t 1, t 2: total s: sincrónico

Implementaciones del ordenamiento de mensajes z. Hay dos aproximaciones al problema: y. Hold-Back: un requerimiento ri que arriba a un AR no es procesado hasta que no se satisfacen las condiciones de ordenamiento requeridas y. El problema guarda similitud con las condiciones de comunicación en grupo (por ej. Multicast Ordenado)

Hold-Back z. Un requerimiento r es estable en un AR si todos los requerimientos previos (según el criterio de ordenamiento vigente) han sido procesados z. Todo requerimiento estable está en condiciones de ser procesado por el AR

Hold-Back: Arquitectura Procesamiento de Requerimientos Cola de Procesamiento Cola de ‘Hold-Back’ requerimiento

Funcionamiento z. Al arribar un requerimiento al AR es encolado en Hold-Back z. Cuando este requerimiento está estable, pasa a la cola de Procesamiento z. La unidad de procesamiento extrae los requerimientos uno a uno de esta cola

Requerimientos para la implementación z. Seguridad: la implementación debe asegurar que una vez que se procesó un requerimiento r es imposible que arribe un requerimiento previo z. Liveness: Ningún requerimiento debe esperar indefinidamente en la cola de Hold -Back

Implementaciones: z. ISIS toolkit: es un software que corre sobre Unix y brinda un entorno de multicast ordenado para entregar los requerimientos a los AR’s z. Gossip: entrega los mensajes no ordenados, basándose en la propagación de updates entre AR’s