REPLICACIÓN

REPLICACIÓN
Mariela Curiel
[email protected]
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
 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.
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.
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.
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.
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.
A BASIC ARCHITECTURAL MODEL FOR
THE MANAGEMENT OF REPLICATED DATA
Requests and
replies
C
FE
RM
RM
Clients
Front ends
C
FE
Service
RM
Replica
managers
Clients request are handled by front ends.
A front end makes replication transparent.
9
•
P1
X=5
Y=4
P2
A= X;
B =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
P3
Print (X,Y)
Gestor de
Réplicas
Gestor de
Réplicas
X,Y
P1
X,Y
Gestor de
Réplicas
P2
Gestor de
Réplicas
X,Y
Front End
P3
P1:
P2 :
P3 :
W(X) W(Y)
y
x x y
R(X) R(Y)
R(X) R(Y)
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.
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
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.
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.
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.
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.
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
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)
COMUNICACIÓN EN GRUPO
Modelo de vistas VSCAST (view synchronous broadcast) :
 Una secuencia de vistas v0(g), v1(g), …vi(g).. De un grupo g.
 Cada vista define vi(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 vi+1(g), que refleje el cambio.
COMUNICACIÓN EN GRUPO
 VSCAST: el VSCAST de un mensaje m que realiza un miembro del grupo g
actualmente dentro de la vista vi(g) asegura la siguiente propiedad: si un
proceso p en vi(g) entrega m antes de instalar la vista vi+1(g), ningún proceso
instalará la vista vi+1(g), antes de haber primero entregado m.
VSCAST
a (allowed).
b (allowed).
p crashes
p crashes
p
p
q
q
r
r
view (p, q, r)
view (q, r)
c (disallowed).
view (p, q, r)
view (q, r)
d (disallowed).
p crashes
p crashes
p
p
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
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.
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.
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
REPLICACIÓN PASIVA
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.
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
REPLICACIÓN ACTIVA
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