REPLICACIÓN. Mariela Curiel.

Transcripción

1 REPLICACIÓN Mariela Curiel

2

3 QUÉ SON RÉPLICAS Y PARA QUÉ SIRVEN? Mantener copias de los datos en múltiples computadores. Es una técnica para mejorar los servicios. Permite: mejorar el desempeño de un servicio, incrementar la disponibilidad y la tolerancia a fallos. Desempeño:. Se hacen replicas cuando el sistema necesita crecer en número y en área geográfica. Número

4 Desempeño: Área Geográfica: se coloca una copia de los datos en la proximidad del proceso que los usa. Ejem: se almacenan datos en el caché de los clientes y servidores para mejorar el rendimiento. Disponibilidad: la proporción de tiempo que un servicio es accesible con tiempos de respuesta razonables debería estar cercana al 100%. Los factores relevantes para una disponibilidad elevada son: Fallos en el Servidor: si los datos se replican en dos o mas servidores independientes, entonces el software cliente podría ser capaz de acceder a los datos en un servidor alternativo cuando el servidor por defecto falle o no esté accesible. Particiones de la red y operación sin conexión: desconexiones no planificadas que son efecto colateral de la movilidad del usuario. Para poder trabajar en estas circunstancias el usuario se suele preparar copiando los datos frecuentemente usados, como el contenido de una agenda compartida, al portatil. Se paga un precio: el usuario se arriesga que los datos estén siendo alterados durante el periodo de desconexión. Este funciona sólo si el usuario (o la aplicación) puede arreglárselas con datos anticuados y resolver más tarde los conflictos que surjan.

5 POR QUÉ REPLICAMOS? Tolerancia a Fallos: Datos con alta disponibilidad no equivales a datos estrictamente correctos. Un servicio Tolerante a Fallos siempre garantiza un comportamiento estrictamente correcto a pesar de cierto número y cierto tipo de fallos.

6 REQUERIMIENTOS PARA DATOS REPLICADOS Transparencia: los clientes no deberían advertir que existen múltiples copias físicas de los datos. Consistencia: se refiere a si los operaciones efectuadas sobre una colección de objetos replicados producen resultados que cumplen las especificaciones de corrección para esos objetos.

7 MODELO DE SISTEMA El sistema se compone de un conjunto de réplicas sobre las cuales se pueden realizar actualizaciones Los clientes realizan las actualizaciones Los procesos pueden fallar sólo por caída. No pueden darse particiones en la red El comportamiento en las réplicas es determinista: Si se realizan operaciones en el mismo orden, las réplicas producen el mismo resultado. Los gestores de réplica mantienen las distintas réplicas y realizan operaciones sobre ellas. Los GR tienen capacidad de recuperación El conjunto de Gestores de Réplica puede ser estático o dinámica.

8 MODELO DE SISTEMA En un sistema dinámico pueden aparecer o desaparecer gestores de réplica. Cuando se caen, se considera que han abandonado el sistema (aunque después sean reemplazados) En un sistema estático los GR no se caen, sino que pueden cesar en su operación durante un periodo indefinido de tiempo.

9 A BASIC ARCHITECTURAL MODEL FOR THE MANAGEMENT OF REPLICATED DATA Requests and replies C FE RM RM Clients Front ends Service C FE RM Replica managers Clients request are handled by front ends. A front end makes replication transparent. 9

10 P1 X = 5 Y = 4 P2 A= X; B = Y Gestor de Réplicas P1 P3 Print (X,Y) X,Y Gestor de Réplicas X,Y Problemas: - Cómo es la actualización de las Réplicas del FE a los Gestores. - Tolerancia a Fallas (Comunicación en Grupo) - Problemas de Consistencia Gestor de Réplicas Gestor de Réplicas P2 X,Y P3 Front End P1: W(X) W(Y) x x y y P2 : R(X) R(Y) P3 : R(X) R(Y)

11 FASES PARA LAS OPERACIONES SOBRE LOS OBJETOS REPLICADOS. Requerimiento (RE): el Front end realiza una petición a uno o más gestores de réplica. Coordinación (SC, Server Coordination): los servidores de réplica se coordinan entre ellos para sincronizar la ejecución de las operaciones (orden de las operaciones concurrentes) Ejecución (EX): los gestores de réplica ejecutan la operación (puede que de forma tentativa) Acuerdo (AC, Agreement Coordination): los gestores de réplica alcanzan consenso para «consumar» o no la operación. Respuesta (END): uno o más Gestores de Réplica responden al Front End.

12 REQUERIMIENTO Se puede hacer de dos formas: El FE se comunica sólo con un gestor de réplicas, que a su vez se comunicará con los otros Multidifunde las peticiones a todos los gestores de réplica

13 COORDINACIÓN Durante esta fase los diferentes gestores de réplica tratan de encontrar un orden para ejecutar las operaciones. Las ordenaciones posibles son: FIFO: si un FE solicita r y luego r, entonces cualquier GR correcto que manipule r debe haber manipulado antes r. Ordenación Total: si un GR correcto manipula la petición de r antes que la petición de r, entonces cualquier gestor de réplicas correcto que manipule r ha de haber manipulado antes r. Si los miembros de un grupo g entregan m y m, todos los deben entregar en el mismo orden (multidifusión ordenada) La mayor parte de las aplicaciones requiere de ordenamiento FIFO.

14 ACUERDO Durante esta fase, todos los gestores de réplica están seguros de que harán lo mismo. En esta fase hay diferencias entre los protocolos de BD y de SD. BD: en esta fase se realiza el 2PC, durante la cual se decide si las operaciones serán consumadas o abortadas. Una vez que se ha acordado un orden las réplicas necesitan asegurarse de que todas están de acuerdo en hacer commit. Ser capaz de ordenar las operaciones no necesariamente implica que la operación tendrá éxito. En SD esta fase puede no ser necesaria. Una vez que se ha alcanzado orden en las operaciones no hay necesidad de hacer un chequeo posterior.

15 RESPUESTA Uno o más gestores de réplicas responden al FE. En alguno de los sistemas sólo uno de los GR envía la respuesta. En otros, el FE recibe respuestas de una colección de GR y selecciona o sintetiza una respuesta para devolvérsela al cliente.

16 COMUNICACIÓN EN GRUPO Los grupos son útiles tanto para gestionar datos replicados, como para otros sistemas donde los procesos cooperen para lograr un objetivo común, recibiendo y procesando el mismo conjunto de mensajes multicast. Grupos dinámicos: se pueden añadir un GR o puede fallar.

17 COMUNICACIÓN EN GRUPO Un servicio de comunicación de grupo tiene 4 tareas principales: Proporcionar una interfaz para los cambios de pertenencia al grupo. Implementar un detector de fallos: vigila a los miembros del grupo, no sólo en el caso en el que puedan caerse, sino cuando se hagan inaccesibles debido a un fallo en la comunicación. El detector de fallos marca a los procesos como sospechosos o no sospechosos. Notificar a los miembros del grupo los cambios en la pertenecia Expandir Direcciones de grupo

18 COMUNICACIÓN EN GRUPO Multicast: SI: - Permite que los procesos se unan o dejen los grupos dinámicamente y realiza expansión de direcciones. No: Proporciona información acerca de los miembros actuales y la entrega de los mensajes no está coordinada con los cambios en los miembros. Un servicio completo de pertenencia a grupos mantiene vistas de grupo (lista de los miembros actuales del grupo)

19 COMUNICACIÓN EN GRUPO Modelo de vistas VSCAST (view synchronous broadcast) : Una secuencia de vistas v 0 (g), v 1 (g), v i (g).. De un grupo g. Cada vista define v i (g) define la composición de un grupo en un instante de tiempo t, es decir los miembros del grupo que se perciben como correctos en ese instante de tiempo. Cuando se sospecha que un proceso p en una vista ha fallado, o un proceso q desea unirse, se debe generar una nueva vista v i+1 (g), que refleje el cambio.

20 COMUNICACIÓN EN GRUPO VSCAST: el VSCAST de un mensaje m que realiza un miembro del grupo g actualmente dentro de la vista v i (g) asegura la siguiente propiedad: si un proceso p en v i (g) entrega m antes de instalar la vista v i+1 (g), ningún proceso instalará la vista v i+1 (g), antes de haber primero entregado m.

21 VSCAST a (allowed). p p crashes b (allowed). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) c (disallowed). p p crashes d (disallowed). p p crashes q q r r view (p, q, r) view (q, r) view (p, q, r) view (q, r) Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

22 MODELOS PARA EL MANEJO DE REPLICAS Replicación Pasiva (Primario-Respaldo) En cada instante existe un único gestor de réplicas primario y uno o más gestores de réplica secundarios (gestores de respaldo) El FE se comunica exclusivamente con el GR Primario para obtener el servicio. El GR primario ejecuta las operaciones y envía copia de los datos actualizados a los Gestores de respaldo Si el primario falla, uno de los secundarios se promociona para que actúe como gestor primario.

23 REPLICACIÓN PASIVA Cuando un cliente solicita la operación, la secuencia de eventos es la siguiente: El FE envía un requerimiento al GR Primario. No hay Coordinación inicial. El GR Primario ejecuta el requerimiento (Fase de Ejecución) Acuerdo: si la petición es una actualización el primario envía a todas las copias de seguridad el estado actualizado. Los Respaldos envían acuse de recibo. Respuesta: el Primario responde al FE, que proporciona la respuesta de vuelta al Cliente.

24 THE PASSIVE (PRIMARY-BACKUP) MODEL Primary C FE RM RM Backup C FE RM Backup Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

25 REPLICACIÓN PASIVA

26 REPLICACIÓN ACTIVA Los GR son desempeñan roles equivalentes y se organizan como un grupo. Los GR son máquinas de estado. Cada FE multidifunde (VSCAST) sus peticiones al grupo de gestores de réplicas y estos procesan la información en forma independiente pero idéntica y responden. Si cae uno de los gestores de réplica no tiene impacto en el desempeño, puesto que el resto de los gestores de réplica continua respondiendo en forma habitual.

27 REPLICACIÓN ACTIVA Petición: El FE multidifunde la petición al grupo de gestores de réplica usando una primitiva de comunicación en grupo fiable y que garantice la entrega ordenada de mensajes. Coordinación: la primitiva anterior garantiza el orden. Ejecución: Cada gestor de réplicas ejecuta la petición Acuerdo: no se necesita acuerdo porque las réplicas se procesan en el mismo orden. Como son máquinas de estado y las peticiones se entregan en orden, todos los gestores de réplica procesan en forma idéntica la petición (SD) Respuesta: Cada GR envía su respuesta al FE

28 REPLICACIÓN ACTIVA

29 REFLEXIONES Existen otros factores a ser tomados en consideración en la replicación de datos: Modelos de consistencia centrados en los datos y hay modelos de consistencia centrados en el cliente. Dónde, cuando y quien coloca las réplicas? réplicas permanentes, colocadas por el servidor, colocadas por el cliente. Cómo se propagan las actualizaciones Otros protocolos para mantener la consistencia