Replicación, consistencia

y tolerancia a fallas

Objetivo: Que el alumno analice y comprenda los diferentes esquemas re-

lacionados a la replicación, consistencia y tolerancia a fallos, así como su
impacto en el diseño de sistemas distribuidos.

1. I ntroduccIón

La replicación juega un importante rol en los sistemas distribuidos y, por lo

general, se utiliza para incrementar la confiabilidad y mejorar el rendimiento
de un sistema. Sin embargo, uno de los principales retos en los sistemas
distribuidos es hacer que estas replicas se mantengan consistentes, lo que
implica garantizar que todas las copias del sistema sean actualizadas.
Un reto importante en la consistencia es con respecto a los datos com-
partidos, que son accedidos por varios procesos simultáneamente, ya que
implementar la consistencia crece en complejidad conforme el sistema dis-
tribuido es escalado. En este escenario, dos cuestiones relacionados a la
consistencia deben ser considerados [Tanenbaum & Van Steen, 2008]. La pri-
mera está relacionada con la administración de la réplica, donde se conside-
ran aspectos como la ubicación de los servidores de réplicas y distribución
del contenido entre estos servidores. La segunda cuestión a considerar es
sobre el mantenimiento de consistencia de las réplicas, lo cual implica que
las actualizaciones de todas las réplicas se deben de realizar de una mane-
ra rápida (casi inmediata). Por otro lado, también los sistemas distribuidos
son diseñados de manera que puedan recuperarse automáticamente de fa-
llas parciales, sin que se afecte seriamente el desempeño total. Esto es una
característica sobresaliente de los sistemas distribuidos que los distingue
de los sistemas de una sola máquina o centralizados. Una falla se puede
 SiStemaS diStribuidoS

presentar en un sistema distribuido y afectar el funcionamiento de algunos

componentes, sin embargo, el sistema puede seguir operando. Esto no es
posible en un sistema no distribuido.
Este capítulo revisa los temas relacionados a replicación, consistencia y
tolerancia a fallas en los sistemas distribuidos.

2r eplIcacIón

La replicación significa mantener copias de una información en múltiples

computadoras. Este recurso es ampliamente usado en los sistemas distribui-
dos, debido a que proporciona un mejor rendimiento, alta disponibilidad y
tolerancia a fallas. Algunos ejemplos donde se usa la replicación son [Cou-
louris et al., 2012]:

• Almacenamiento en caché en los servidores web y servidores proxy web.

• El servicio de nombres DNS.

2.1 b eneFIcIos de usar replIcacIón en los sIstemas dIstrIbuIdos

2.1.1 Mejoras del rendimiento

Entre las características con respecto al rendimiento del sistema distribuido

que deben de ser observadas al replicar datos se pueden mencionar las si-
guientes [Coulouris et al., 2012]:

• La replicación se implementa principalmente a través de cachés en clien-

tes o servidores.
• Es importante mantener copias de los resultados obtenidos en llamadas
anteriores al servicio para evitar o reducir el coste de llamadas idénticas.
• Se evita el tiempo de latencia derivado del cálculo del resultado o de
realizar consultas a otros servidores.
• La replicación de datos con actualizaciones muy frecuentes en la red ge-
nera un costo en el uso de protocolos de intercambio y actualización,
además de limitar la efectividad de la réplica.
r eplicación , conSiStencia y tolerancia a fallaS

2.1.2 Alta disponibilidad

Entre las características con respecto a la disponibilidad del sistema distri-

buido que deben de ser observadas al replicar datos se pueden mencionar
las siguientes [Coulouris et al., 2012]:

• La proporción de tiempo que un servicio está accesible con tiempos de

respuesta razonables, que debe de ser cercana al 100%.
• Existen pérdidas de disponibilidad debido a los siguientes factores:
• Fallas en el servidor. Si se replica n veces el servidor, la disponibilidad
será 1-p
n
. Por ejemplo, para n = 2 servidores, la disponibilidad es 1 -
0.05 = 1 – 0.0025 = 9 75%.
2

• Particiones de red o desconexiones.

• Operación desconectada (son aquellas desconexiones de comunica-
ción que a menudo no se planifican y son un efecto secundario de la
movilidad del usuario).

2.1.3 Tolerancia a fallas

Entre las características respecto a la tolerancia a falla en los sistemas distri-

buidos, se pueden mencionar las siguientes [Coulouris et al., 2012]:

• Una alta disponibilidad no implica necesariamente corrección, esto se

debe a que puede haber datos no actualizados, o inconsistentes, origi-
nados por procesos concurrentes.
• Se puede utilizar la replicación para alcanzar una mayor tolerancia a fallas.
• Ante una caída o suspensión de servidores; por ejemplo, si se tienen
n servidores, pueden fallar n-1 sin que el servicio sufra alteración.
• Ante fallas bizantinas, es decir, si f servidores presentan fallas bizan-
tinas, un sistema con 2f+1 servidores proveería un servicio correcto.

2.2 Requisitos para realizar la replicación

Entre los requisitos más importantes que se deben considerar al implemen-

tar la replicación en un sistema distribuido, están:

• Transparencia.
• Consistencia.
 SiStemaS diStribuidoS

El requisito de transparencia implica que los clientes no son conscientes

de que hay múltiples copias del recurso al que ellos están accediendo. Para
los usuarios, solo existen recursos lógicos individuales. Por otro lado, la con-
sistencia implica que las operaciones sobre un conjunto de objetos replica-
dos deben de dar resultados que sigan la especificación de corrección defi-
nida para esos objetos. De acuerdo con el tipo de aplicación, la consistencia
puede ser más o menos estricta.

2.3 Modelo general de gestión de réplica

Esta sección presenta un modelo de sistema general para la gestión de ré-

plicas. Además, describe el papel de los sistemas de comunicación grupal
en la consecución de la tolerancia a fallas a través de la replicación. El mode-
lo general de gestión de réplica se muestra en la figura 1.

Figura 1. Modelo de arquitectura básica para la gestión de los datos replicados

Los componentes principales de esta arquitectura de gestión de datos

replicados son:

• Gestor de réplicas.
• Frontal (front-end).

El gestor de réplicas son los componentes que almacenan las réplicas

de un determinado objeto o servicio y operan sobre ellas. Frontal (FE) es el
componente o interfaz que atiende las llamadas de los clientes y se comuni-
ca con los gestores de réplicas.
En general, cinco fases están involucradas en el desempeño de una única
solicitud a los objetos replicados [Wiesmann, Pedone, Schiper, Kemme &
Alonso, 2000]:
r eplicación , conSiStencia y tolerancia a fallaS

1. La petición es enviada por el frontal a uno o más gestores con las si-
guientes opciones:
• Se envía la petición a un gestor y este la reenvía a otros.
• Multidifundir la petición a varios gestores.
2. Los gestores se coordinan para ejecutar la petición de manera consistente.
Los tipos de ordenación para que los gestores manipulen las réplicas son:
• Ordenamiento FIFO.
• Ordenamiento casual.
• Ordenamiento total.
3. Se ejecuta la petición, la cual podría ser realizada de manera tentativa.
4. Se llega a un acuerdo o consenso antes de consumar la ejecución.
5. Uno o más gestores de réplicas entrega una respuesta al frontal.

2.4 Servicios de tolerancia a fallas basados en replicación

2.4.1 Replicación pasiva

En la replicación pasiva existe un gestor de réplicas primario y uno o más

gestores secundarios también conocidos como “respaldos” o “esclavos”.
Los frontales se comunican con el gestor primario, quien ejecuta las ope-
raciones y manda copias a los respaldos. Si el gestor de réplicas primario
falla, entonces un gestor de réplicas de respaldo lo sustituye. La figura 2
muestra este escenario.

Figura 2. Modelo de replicación pasiva para tolerancia a fallas

Una replicación pasiva tiene las siguientes fases de ejecución [Coulouris

et al., 2012]:
 SiStemaS diStribuidoS

1. Petición.
2. Coordinación.
3. Ejecución.
4. Acuerdo.
5. Respuesta.

Durante la fase de petición, el frontal envía la petición al gestor primario,

quien activa la fase de coordinación y ejecuta las peticiones siguiendo una
ordenación FIFO. Se realiza la fase de ejecución de la petición y se almace-
na la respuesta. Si es una petición de actualización, entonces en la fase de
acuerdo el gestor primario envía la actualización a todos los respaldos, quie-
nes confirman la recepción. Finalmente, en la fase de respuesta, el gestor
primario envía la respuesta correspondiente al frontal. La replicación pasiva
tolera fallas de procesos pero no tolera fallas bizantinas. El frontal requiere
poca funcionalidad, sin embargo, este esquema de replicación es propenso
a problemas de cuellos de botella en el gestor primario.

2.4.2. Replicación activa

En la replicación activa todos los gestores de réplicas tienen el mismo rol.

Los frontales multidifunden las peticiones a todos los gestores y todos los
frontales procesan la petición de manera idéntica pero independiente. En la
figura 3 se muestra un escenario de replicación activa.

Figura 3. Modelo de replicación activa para tolerancia a fallas

Al igual que la replicación pasiva, una replicación activa tiene las siguien-
tes fases de ejecución [Coulouris et al., 2012]:
r eplicación , conSiStencia y tolerancia a fallaS

1. Petición.
2. Coordinación.
3. Ejecución.
4. Acuerdo.
5. Respuesta.

Sin embargo, las actividades que se realizan en cada fase difieren sustan-
cialmente de las actividades que se hacen en la replicación pasiva. Durante
la fase de petición, el frontal multidifunde la petición a los gestores usando
multidifusión fiable y de ordenación total. No se envía otra petición hasta
que se reciba la respuesta a la petición actual. El sistema de comunicación
durante la fase de coordinación entrega la petición a todos los gestores
según una ordenación total. Entonces, cada gestor realiza la fase para eje-
cutar la petición. La fase de acuerdo no es necesaria, debido a que se utiliza
multidifusión. Finalmente, en la fase de respuesta, cada gestor manda su
respuesta al frontal. El número de respuesta que recibe el frontal está en
función de las asunciones de falla y del algoritmo de multidifusión.
En la replicación activa, la tolerancia a fallas está soportada principal-
mente por la multidifusión fiable y totalmente ordenada. La multidifusión
es equivalente a un algoritmo de consenso, por lo que la replicación activa
permite resolver fallas bizantinas. Esto se debe a que el frontal recoge f+1
respuestas iguales antes de responder al cliente.

3c onsIstencIa

La consistencia en los sistemas de cómputo es una necesidad vital, ya que

sin ella el sistema simplemente no funciona. El problema de la consistencia
está presente tanto en los sistemas de cómputo centralizados como en los
sistemas distribuidos. El acceso a los datos en un sistema centralizado pue-
de caer en estado inconsistente ante accesos concurrentes, por lo que se
requiere prever mecanismos de exclusión que eviten estos escenarios. Sin
embargo, en los sistemas distribuidos el problema de la inconsistencia es de
mayor dimensión, tanto por su importancia como por la gran cantidad de si-
tuaciones en que puede producirse. Debido a que un sistema distribuido es
un único sistema, entonces debe tener un único estado global compartido
por todas las computadoras que la componen. Este estado global compren-
de las tablas de mantenimiento del sistema, la hora actual o los datos que
están siendo compartidos por distintas computadoras.
 SiStemaS diStribuidoS

3.1 Tipos de inconsistencias

En un sistema distribuido, los diferentes tipos de consistencias más frecuen-

temente estudiadas son:

• Consistencia de actualización.
• Consistencia de replicación.
• Consistencia de caché.
• Consistencia de reloj.

3.1.1 Consistencia de actualización

La consistencia de actualización es importante observarla cuando varios

procesos acceden concurrentemente a un dato para actualizarlo, ya que la
actualización de todo el dato en su conjunto no se realiza como una única
operación atómica y se puede caer en una inconsistencia de actualización.
Este tipo de inconsistencia es un problema clásico en el acceso a bases de
datos o datos compartidos. Sin embargo, en los sistemas distribuidos esto
tiene una mayor relevancia debido a que estos sistemas generalmente tie-
nen un gran número de usuarios. Este tipo de inconsistencia se evita usando
transacciones.
Las transacciones son las primitivas equivalentes a las entradas y salidas
de una región crítica usada para proteger la consistencia de un dato com-
partido. Asimismo, una transacción asegura que las operaciones incluidas en
esta se ejecuten todas o no se ejecuta una sola.

3.1.2 Consistencia de replicación

Una situación de inconsistencia de replicación puede producirse cuando un

conjunto de datos debe replicarse en diversas computadoras de la red, pu-
diendo ser modificado por cualquiera de estas. En este escenario, es muy
probable que se puedan producir situaciones en que los datos no sean igua-
les en todas las computadoras al mismo tiempo. Los juegos interactivos mul-
tiusuarios pueden ser un ejemplo de inconsistencia de replicación, pues las
acciones que introduzca un jugador deben de propagarse usando un proto-
colo de difusión de manera inmediata al resto de los jugadores en la red. En
caso de que la red falle o tenga alta latencia, cada jugador tendrá una visión
distinta del juego. La consistencia de replicación tiene gran importancia en
r eplicación , conSiStencia y tolerancia a fallaS

los sistemas distribuidos, más aun si estos son en ambientes colaborativos

e interactivos.

3.1.3 Consistencia de caché

Cuando una aplicación cliente accede a archivo de datos, se pueden guar-

dar estos datos en un espacio de la memoria local del lado del cliente para
facilitar el acceso a este dato en futuras referencias. Esto se conoce como
memoria caché y reduce la transferencia de datos por la red. La memoria
caché tiene como objetivo mejorar los accesos locales mediante el mode-
lo de jerarquías de memoria [Patterson & Hennessy, 1994]. Sin embargo, el
problema de inconsistencia se puede presentar cuando el cliente también
tiene que actualizar el mismo dato pero este reside en las memorias cachés
de otros clientes. En este caso, existe el riesgo de que las copias del dato en
las otras memorias cachés queden desactualizadas. Para evitar este escena-
rio, se deben considerar técnicas que aseguren la consistencia de los cachés
por parte de los sistemas operativos distribuidos o por las arquitecturas de
sistemas multiprocesadores.

3.1.4 Consistencia de reloj

Diversas aplicaciones y programación en ambientes distribuidos basan su

funcionalidad en algoritmos que muchas veces dependen de estampillas
de tiempo. Estas estampillas de tiempo (ver capítulo 5. Sincronización) son
usadas para indicar el momento en que un evento ha sucedido. Por ejem-
plo, algunos algoritmos de reemplazo de página en memoria virtual hacen
uso de estampillas de tiempo. Una computadora en un sistema distribuido
puede generar una estampilla de tiempo, la cual se puede enviar a cual-
quier otra computadora del sistema. Así, cada computadora puede com-
parar su estampilla de tiempo local con la estampilla de tiempo recibida.
El problema de inconsistencia de reloj se presenta debido a que no es fácil
mantener la misma hora física en todas las computadoras del sistema de
manera simultánea.

3.2 Modelos de consistencia

Los modelos de consistencia para los datos compartidos son a menudo difí-
ciles de implementar de manera eficiente en los sistemas distribuidos a gran
escala [Tanenbaum & Van Steen, 2008]. Además, en muchos casos se pueden
 SiStemaS diStribuidoS

utilizar modelos más simples, que también son a menudo más fáciles de
implementar. Un modelo de consistencia es un contrato en los procesos y
el almacenamiento de datos. Es decir, si los procesos acuerdan obedecer
ciertas reglas, entonces el almacenamiento promete trabajar correctamente.
Normalmente, una operación de lectura debe retornar la última actualiza-
ción del dato. Los modelos de consistencia pueden ser:

• Centrados en los datos.

• Centrados en el cliente.

3.2.1 Modelo de consistencia centrado en los datos

Este modelo asume que un almacén de datos (base de datos distribuida o

un sistema de archivos) puede estar físicamente distribuido en varias máqui-
nas. Todo proceso que pueda acceder a datos del almacén tiene una copia
local disponible de todo el almacén y todas las operaciones de escritura se
propagan hacia las otras copias. Ante la ausencia de un reloj global, es difícil
sincronizar y determinar cuál es la última operación de escritura. Lo anterior
permite que una consistencia centrada en datos presente una gama de mo-
delos de consistencia, entre los que se pueden mencionar los siguientes:

• Modelos de consistencia que no usan variables de sincronización:

• Estricta.
• Linealizada.
• Secuencial.
• Causal.
• FIFO.

• Modelos de consistencia con operaciones de sincronización:

• Débil.
• Relajada.
• Entry.

3.2.2 Modelo de consistencia centrado en el cliente

Este modelo de consistencia está orientado a un conjunto de datos que tie-

nen un bajo número de actualizaciones simultáneas o, cuando estas ocurren,
pueden resolverse fácilmente. Generalmente está orientado a operaciones
r eplicación , conSiStencia y tolerancia a fallaS

de lectura de datos, por lo que se puede catalogar como un modelo de con-

sistencia bastante débil [Tanenbaum & Van Steen, 2008]. Los modelos de con-
sistencias basados en el cliente permiten ver que es posible ocultar muchas
inconsistencias de un sistema distribuido de una manera relativamente fácil.
Tanenbaum y Van Steen [2008] citan como ejemplos de modelos de con-
sistencia centrados en el cliente los siguientes:

• Consistencia momentánea.
• Lecturas monotónicas.
• Escrituras monotónicas.
• Lea sus escrituras.
• Las escrituras siguen a las lecturas.

4. t olerancIa a Fallas

Los sistemas distribuidos se distinguen principalmente de los sistemas cen-

tralizados de una sola computadora en su capacidad de falla parcial. La to-
lerancia a fallas ha sido un tema de investigación por muchos años en las
ciencias de la computación. Un sistema tolerante a fallas es un sistema que
posee la capacidad interna para asegurar la ejecución correcta y continuada
a pesar de las presencia de fallas en hardware o software. El objetivo de este
tipo de sistemas es ser altamente fiable.

4.1 Origen de una falla

El origen de las fallas en un sistema puede ser clasificado como:

• Fallas en hardware:
• Son generalmente fallas permanentes o transitorias en los compo-
nentes del hardware.
• Fallas permanentes o transitorias en los subsistemas de comunicación.

• Fallas en software:
• Se originan por especificaciones inadecuadas.
• Fallas introducidas por errores en el diseño y programación de com-
ponentes de software.
 SiStemaS diStribuidoS

Se dice que un sistema distribuido es un sistema fiable cuando compren-

de varios requerimientos útiles, como los siguientes:

• Disponibilidad.
• Confiabilidad.
• Seguridad.
• Mantenimiento.

La fiabilidad de un sistema es una medida de su conformidad con una

especificación autorizada de su comportamiento [Tanenbaum & Van Steen,
2008]. En contraste, una avería o defecto es una desviación del comporta-
miento de un sistema respecto a esta especificación. Las averías se mani-
fiestan en el comportamiento externo del sistema pero son el resultado de
errores internos. Las fallas pueden ser consecuencia de averías en los com-
ponentes del sistema. Las fallas pueden ser pequeñas pero los defectos muy
grandes. En la figura 4 se muestran las relaciones causa-efecto de una falla.

Figura 4. Relación causa-efecto de una falla

4.2. Clasificación de fallas

El objetivo de la tolerancia a fallas en un sistema distribuido es evitar que las fa-

llas produzcan averías. Las fallas se clasifican generalmente como (ver figura 5):

• Transitorias.
• Intermitentes.
• Permanentes.

Es una falla transitoria, si esta desaparece sola al cabo de cierto tiempo.

Ejemplos de este tipo de falla son las interferencias en las señales de co-
municación o las fallas transitorias en los enlaces de comunicación. Por otro
r eplicación , conSiStencia y tolerancia a fallaS

lado, las fallas permanentes son aquellas fallas que permanecen hasta que el
componente se repare o sustituya, por ejemplo, los errores de software o la
rotura de una tarjeta de video. Finalmente, las fallas intermitentes se refieren
a aquellas fallas transitorias que ocurren de vez en cuando, por ejemplo, el
calentamiento de algún componente de la computadora.

Figura 5. Clasificación de fallas

4.3 Fallas en los procesos distribuidos

En un sistema distribuido, tanto los procesos como los canales de comuni-

cación pueden fallar, es decir que pueden apartarse de lo que se considera
el comportamiento correcto o deseable. En la figura 6 se ilustra un mo-
delado de procesos y canales. El modelo de fallas define las formas en las
que puede ocurrir una falla, con el fin de proporcionar una comprensión de
los efectos de los fallas. Bajo este enfoque, Hadzilacos y Toueg [1994] pro-
porcionaron una taxonomía que distingue entre las fallas de los procesos y
canales de comunicación y los presenta como fallas por omisión, fallas arbi-
trarias y fallas temporales. La tabla 1 resume las principales características
de este tipos de fallas.

Figura 6. Procesos y canales

 SiStemaS diStribuidoS

Tabla 1. Fallas por omisión y arbitrarias [Coulouris et al, 2012]

Tipo de falla Efecto Descripción

Falla de Proceso El proceso para y permanece así. Otros procesos pue-
congelación den detectar este estado
Crash (caída) Proceso El proceso para y permanece así. Otros procesos pue-
den no ser capaces de detectar este estado
Omisión Canal Un mensaje insertado en un buffer de mensajes de sa-
lida no llega al siguiente buffer de llegada de mensajes
Omisión de Proceso Un proceso completa un envío pero el mensaje no es
envío puesto en su buffer de mensajes de salida
Omisión de Proceso Un mensaje es puesto en el buffer de mensajes de lle-
recepción gada de un proceso pero este no lo recibe
Arbitraria Proceso El proceso/canal muestra un comportamiento arbitra-
(Bizantino) o canal rio: podría enviar/transmitir arbitrariamente mensajes
en tiempos arbitrarios, comete omisiones; un proceso
puede detenerse o tomar un paso incorrecto

Las fallas más serias son las arbitrarias o bizantinas. Cuando estas fallas
ocurren, los clientes deben de estar preparados para lo peor. Este problema
suele conocerse en la literatura como el problema de los Generales Bizanti-
nos, que fue planteado originalmente por Lamport et al. [1982].

4.4 Redundancia

Todas las técnicas de tolerancia a fallas se basan en el uso de la redundancia,

de la cual pueden ser identificados los siguientes tipos:

• Redundancia estática: Los componentes redundantes se utilizan dentro del

sistema para enmascarar los efectos de los componentes con defectos.
• Redundancia dinámica: La redundancia se utiliza solo para la detección
de errores. La recuperación debe de realizarla otro componente.
• Redundancia en el diseño: Partes de un diseño pueden ser redundantes.
• Redundancia temporal: Mediante el uso repetido de un componente en
presencia de fallas. Adecuado para fallas transitorias.
r eplicación , conSiStencia y tolerancia a fallaS

ejercIcIos

1. Define el concepto de tolerancia a fallas en los sistemas distribuidos.

2. ¿Cuál es la importancia del problema de los generales bizantinos para la

tolerancia a fallas?

3. Investiga sobre los esquemas de redundancia más usuales para soportar

la tolerancia a fallas en los sistemas distribuidos.

4. Cita tres ejemplos de fallas transitorias, intermitentes y permanentes.

5. Explica las ventajas y desventajas de usar una replicación en los sistemas

interactivos multiusuarios desplegados globalmente.

6. Explica qué es un modelo de consistencia.

7. Explica la diferencia entre la replicación pasiva y activa.

8. ¿Cuáles son los retos a que se enfrenta la consistencia de caché en los

sistemas distribuidos?

9. Explica la relación entre transparencia, consistencia y replicación en los

sistemas distribuidos.

10. ¿Qué requerimientos debe de cumplir un sistema distribuido para con-

siderarlo fiable?