jueves, 18 de noviembre de 2010

falla de equipo

El objetivo del diseño y construcción de sistemas tolerantes a fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en presencia de fallas.

Se dice que un sistema falla cuando no cumple su especificación. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.

Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.

Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.

Clasificación de fallas

Las fallas de un sistema de cómputo pueden clasificarse como sigue:

Falla de procesos: en una falla de proceso, la ejecución arroja un resultado incorrecto, los procesos provocan que el sistema se desvíe de las especificaciones y el proceso puede suspender su progreso. Ejemplos de errores que causan la falla de los procesos son los interbloqueos, tiempo expirado, violación de protección, error en la entrada provista por el usuario, violaciones de consistencia (puede ocurrir si se emplea la técnica de control de concurrencia optimista). Dependiendo del tipo de error que cause que un proceso falle, este proceso puede ser abortado o reiniciado desde un estado anterior. Por ejemplo, un proceso interbloqueado puede ser restablecido desde un estado anterior, donde este puede tratar de adquirir nuevamente recursos. Por otro lado, entradas erróneas requieren que el proceso se aborte.

Falla del sistema: una falla de un sistema ocurre cuando el procesador falla en la ejecución. Esto es causado por errores de software y problemas de hardware (como errores de CPU, falla en la memoria principal, falla en el bus, falla de energía, etc.). En el caso de una falla de sistema, el sistema es detenido y reiniciado en un estado correcto. El estado correcto puede estar en algún estado predefinido o en un estado anterior (punto de revisión) del sistema guardado en un almacenamiento no volátil.

Una falla del sistema puede ser clasificado como sigue:

Falla de amnesia: ocurre cuando se reinicia el sistema en un estado predefinido, y no depende del estado del sistema antes de la falla. No se conoce el estado que tenía el sistema antes de la falla.

Falla de amnesia parcial: ocurre cuando se reinicia el sistema y se conoce parte del estado que presentaba antes de ocurrir la falla. También se predefine un estado inicial para fallas.

Falla de pausa: ocurre cuando el sistema se reinicia al mismo estado en que se encontraba antes de la falla.

Falla de aborto (halting): ocurre cuando un sistema nunca se reinicializa.

Falla en medio de almacenamiento secundario: se dice que ocurre una falla en medio de almacenamiento cuando los datos almacenados no pueden ser accedidos (cualquiera de sus partes o en su totalidad). La causa de esta falla normalmente es provocada por error de paridad, daño de las cabezas lectoras, partículas de polvo depositadas en el medio. En caso de una falla en el medio de almacenamiento secundario, sus contenidos se encuentran alterados y deberían ser reconstruidos desde una versión del archivo, que se toma del registro histórico de actividades del archivo. Para tolerar una falla del medio de almacenamiento secundario, el sistema puede ser configurado con un sistema de discos espejos. Un sistema de disco espejo generalmente son dos discos físicamente independientes que se comunican con la memoria y/o con el CPU a través de controladores y buses independientes. Esto hace que el almacenamiento de datos en un disco sea la imagen del otro. Así, un sistema puede tolerar fallas de un disco de subsistema.

Falla en los medios de comunicación: una falla de un medio de comunicación, ocurre cuando un sitio no puede comunicarse con otro sitio operacional de la red. Esto es ocasionado por la falla del nodo de conmutación y/o por los enlaces de comunicación del sistema. La falla de un nodo de conmutación incluye la falla del sistema y la falla de almacenamiento secundario, por otro lado, la falla de enlace incluye una ruptura física y ruido en los canales de comunicación. Note que una falla en un medio de comunicación (esto depende de la topología y la conectividad) puede no causar la pérdida total de las facilidades de comunicación. Por ejemplo, una falla en el medio de comunicación puede simplemente causar una pérdida del mensaje, la recepción de un mensaje con algunos errores, o la partición de una red donde un segmento de sitios pueden ser incomunicados con los sitios en otro segmento, aunque los sitios dentro de un segmento pueden comunicarse entre sí.

RECUPERACIÓN DE ERRORES.

Recordemos que un error es esa parte del estado del sistema que es distinto de los valores esperados y que pueden conducir a la falla de un sistema, la recuperación de una falla es un proceso que involucra la recuperación de estados erróneos a un estado libre de error. Hay dos enfoques para la recuperación de un estado de error a un estado libre de error.

Si la naturaleza del error y los daños causados por la falla pueden ser completamente calculados, entonces es posible remover esos errores del estado del proceso (o sistema) y habilitar el movimiento hacia adelante del proceso a un estado libre de error. Esta técnica es conocida como recuperación hacia adelante.

Si no es posible prever la naturaleza de las fallas y remover todos los errores en el estado del proceso (o sistema), entonces el estado del proceso puede ser restaurado a un estado previo libre de error. Esta técnica es conocida como recuperación de error hacia atrás.

Note que la recuperación del error hacia atrás es más simple que la recuperación del error hacia adelante, ya que es independiente de la falla y de los errores causados por la falla. Además un sistema puede recuperarse de una falla arbitraria por la restauración a un estado previo. Esto generalmente habilita que la recuperación hacia atrás sea provista como un mecanismo de recuperación general para cualquier tipo de proceso.

Los principales problemas asociados con la recuperación hacia atrás son:

Penalidad en rendimiento: la sobrecarga de trabajo para restaurar el estado del proceso a un estado anterior libre de errores puede resultar muy alto.

No esta garantizado que las fallas no ocurrirán nuevamente cuando se inicialice el procesamiento desde un estado anterior.

Algunos componentes del estado del sistema pueden ser irrecuperables. Por ejemplo, el dinero dispuesto en un cajero automático no puede recuperarse.

La técnica de recuperación hacia delante, por otro lado, provoca una menor sobrecarga, porque sólo esas partes del estado que se desviaron de un valor esperado necesitan ser corregidas. Sin embargo, esta técnica puede ser usada solo cuando los daños debido a fallas pueden ser calculados correctamente, por lo tanto, este no es un concepto tan general como la recuperación de error hacia atrás y no puede ser provista como un mecanismo general para recuperar errores.

Recuperación de error hacia atrás

En la recuperación de error hacia atrás, un proceso es restaurado a un estado anterior con la esperanza de que el estado anterior este libre de errores. Los puntos en la ejecución de un proceso en los cuales los procesos pueden ser restaurados más tarde se conocen como puntos de recuperación. Se dice que un punto de recuperación es recuperado cuando el estado actual de un proceso es remplazado por el estado del proceso en el punto de recuperación. Los conceptos anteriores y la discusión que sigue son aplicables también a nivel del sistema. Una recuperación hecha a nivel de proceso es simplemente un subconjunto de acciones necesarias para recuperar el sistema completo. En la recuperación del sistema, todos los procesos que fueron activados necesitan ser restaurados a sus respectivos puntos de recuperación y los datos modificados (en el almacenamiento secundario) por los procesos necesitan ser restaurados a su estado apropiado.

Hay dos formas de implementar una recuperación de error hacia atrás, a saber, el enfoque basado en la operación y el enfoque basado en estado. Estos enfoques son explicados en el contexto de el siguiente sistema modelo.

Sistema modelo. El sistema que adoptamos consiste de una máquina simple. La máquina esta conectada a un sistema de almacenamiento secundario y a un sistema de almacenamiento estable (ver figura 1.1.). Un almacenamiento que no pierde información en un evento de falla del sistema es conocido como un almacenamiento estable. Cuando un proceso accesa a un objeto dato almacenado en un medio secundario, el objeto dato es traído a la memoria principal si este no se encuentra ya en la memoria. Si el acceso es una operación escribir, la copia del objeto en la memoria principal es actualizada. El objeto dato es eventualmente actualizado cuando la copia del objeto en la memoria principal es liberado al disco por el esquema de paginación o cuando el proceso de actualización del objeto termina. El almacenamiento estable es usado para almacenar los registros históricos y los puntos de recuperación. El contenido de ambos, almacenamiento secundario y almacenamiento estable pueden sobrevivir a las fallas del sistema. Sin embargo, el contenido del almacenamiento estable es mucho más seguro que el almacenamiento secundario. Se asume que los datos en el almacenamiento secundario son periódicamente archivados.

Enfoque basado en la operación

En el enfoque basado en la operación, todas las modificaciones que son hechas al estado de un proceso son registrados con suficiente detalle, así los estados previos del proceso pueden ser restaurados dando marcha atrás a todos los cambios hechos al estado. El registro de la actividad del sistema es conocido como registro histórico.

Considere un entorno basado en transacciones donde las transacciones modifican una base de datos. En tal ambiente es deseable tener la capacidad de comprometer o deshacer las modificaciones realizadas por una transacción. El comprometer (commit) es una acción la cual indica que el proceso o la transacción de actualización se ha completado con éxito, y por lo tanto los cambios hechos a la base de datos pueden ser permanentes. Note que incluso antes de comprometer una transacción, si se modificó pudo haber sido registrada en la base de datos por el esquema de paginación. Por lo tanto, si una transacción no ha sido comprometida, la actualización de la base de datos podrá deshacerse. Por otro lado, si una parte de la base de datos se pierde por un error de medio de almacenamiento, debería ser posible reconstruir esa parte.

Protocolo de escritura inmediata (Updating-in-place)

Bajo este esquema de actualización de escritura inmediata, cada operación de actualización (escritura) a un objeto, se actualiza el objeto y los resultados en un registro se graban en un medio de almacenamiento estable, el cuál, al final de las operaciones, tendrá suficiente información para deshacer y rehacer completamente las operaciones. La información registrada incluye: (1) El nombre del objeto, (2) El estado antiguo del objeto (usado para deshacer) y (3) El nuevo estado del objeto (usado para rehacer).

Una operación de actualización recuperable puede ser implementada como una colección de operaciones como sigue:

Operación hacer, la cual hace la acción (actualización) y la escribe en el registro histórico.

Operación deshacer, la cual, dado un registro histórico escrito por una operación hacer, deshace la acción realizada por la operación hacer.

Operación rehacer, la cual, dado un registro histórico escrito por una operación hacer, rehace la acción especificada por la operación hacer.

Operación opcional visualización, la cual visualiza el registro histórico.

Cuando una transacción no está comprometida o falla, los cambios hechos por la transacción a la base de datos pueden deshacerse, usando operaciones deshacer (undo). Por otro lado, si una porción de la base de datos va a ser reconstruida, entonces se utiliza la operación rehacer (redo) sobre la porción guardada previamente de la base de datos.

El principal problema con la actualización inmediata es que la operación hacer no se puede deshacer, si el sistema se daña después de una operación de actualización pero antes de que el registro histórico sea almacenado. Este problema es resuelto por el protocolo de escritura de registro anticipado (write-ahead-log).

Protocolo de escritura de registro anticipado

En el protocolo de escritura de registro anticipado, una operación de actualización recuperable se implementa por las siguientes operaciones:

Actualización de un objeto solo después de que el registro deshacer es guardado.

Antes de comprometer la actualización, los registros rehacer y deshacer son guardados.

Al reiniciar el sistema después del fallo (de hardware o alguna otra razón), puede ser necesario deshacer los cambios hechos por la transacción que estaba en progreso al momento que ocurrió el fallo. Por otro lado, en el reinicio, las operaciones de rehacer podrían haber sido realizadas si los objetos actualizados estuvieron en la memoria principal en el momento en que falló el sistema. Por lo tanto, ambas acciones de deshacer y rehacer deberían trabajar correctamente, aun bajo fallas repetitivas, si los protocolos actualización al momento o de escritura de registro anticipado son usados. Note que también la escritura del registro histórico en cada operación de actualización es caro en términos de requerimiento de almacenamiento y la CPU sufre de sobrecarga innecesaria especialmente si los fallos son raros.

Enfoque basado en estado

En el enfoque basado en estado, para la recuperación, el estado completo de un proceso es guardado cuando se establece un punto de verificación y la recuperación de un proceso involucra reincorporarle el estado guardado y reiniciar la ejecución del proceso desde ese estado. Al proceso de guardado del estado también se le conoce como tomar un punto de verificación. El punto de recuperación, en los que se encuentra un punto de verificación a menudo se le refiere como punto de revisión. Al proceso de restauración de un proceso a un estado anterior se le refiere como rolar al procesos hacia atrás (rolling back), y el proceso de reiniciar la ejecución en un estado anterior consume tiempo de CPU y retarda la terminación del proceso, es preferible retroceder a un estado más reciente tanto como sea posible. Por lo tanto, se acostumbra establecer muchos puntos de revisión.

Página sombra. Un caso especial del enfoque de recuperación basado en estado es la técnica basada en páginas sombra. Bajo esta técnica, solo una parte del estado del sistema es guardado para facilitar la recuperación. Sin embargo cuando un proceso quiere modificar un objeto, la página que contiene al objeto es duplicada y mantenida en un medio estable. Desde este punto en adelante, solo una de las copias recibirá todas las modificaciones hechas por el proceso. La otra copia no modificada es conocida como página sombra. Si el proceso falla, la copia modificada es descartada y se restablece la base de datos en el estado anterior. Si el proceso se comprometió exitosamente, entonces la página sombra es descartada y la página modificada es hecha parte de la base de datos.

ELEMENTOS DE LAS ESTRATEGIAS TOLERANTES A FALLAS.

Un sistema puede ser diseñado para que sea tolerante a falla desde dos puntos de vista. Un sistema puede ocultar la falla o puede en caso de ocurrir una falla corregirla y seguir funcionando. Cuando el sistema se diseña para ocultar la falla, cuando ocurre una falla continúa con sus funciones específicas. Por otro lado un sistema diseñado para corregir una falla puede o no ejecutar funciones específicas, sin embargo, puede seguir acciones para recuperación.
Estrategia tolerante a fallas

Redundancia. Con este enfoque, el sistema puede emplear varios procesos, muchos componentes de hardware, muchas copias de datos, etc. Cada uno con independencia en el modo de la falla, (es decir, si un componente falla no afecta la operación de otro componente).


Técnica para sistemas tolerantes a fallas.

Protocolo de compromiso.
Protocolo de elección.

La primera técnica se utiliza para sistemas que pueden hasta cierto punto corregir las fallas y el segundo, el protocolo de elección, es utilizado para sistemas que oculten las fallas.

Efectos de las fallas más comunes.

Un proceso muere. Cuando un proceso muere, es importante que los recursos asignados al proceso sean recuperados, de otra manera pueden estar perdidos permanentemente.

La máquina falla. Cuando una máquina falla, todos los procesos ejecutándose en esa máquina se mueren. La diferencia con el caso anterior es, como detectar la falla.

La red falla. Una falla de enlace de comunicación puede particionar la red en sub-redes, haciendo imposible la comunicación entre nodos localizados en sub-redes diferentes. Un proceso no puede notar la diferencia entre una falla de máquina y una falla de enlace de comunicación, dependiendo de la red, en algunos casos se pueden detectar falla de máquina. En las redes que no detectan falla de máquina (Ethernet), el diseño tolerante a falla debe asumir que la máquina puede estar en operación y que los procesos en ella están activos.
Acciones atómicas y compromiso

La actividad de un sistema es gobernada por una secuencia de primitivas u operaciones atómicas que ejecuta permanentemente. Generalmente, una instrucción a nivel de máquina, es indivisible, instantánea, y no puede ser interrumpida (a menos que ocurra una falla), corresponde a una operación atómica. Sin embargo es deseable disponer de un conjunto de instrucciones que completan una cierta tarea y hacemos que este grupo sea una operación atómica.

El concepto de acción atómica se extiende al concepto de atomicidad desde un nivel de instrucción de máquina hasta una secuencia de instrucciones o un grupo de procesos los cuales deben ellos mismos ser ejecutados atómicamente. Las acciones atómicas forman un bloque básico en la construcción de operaciones tolerantes a fallas.

Una transacción agrupa una secuencia de acciones (sobre una base de datos) y al grupo se le trata como una acción atómica que mantiene la consistencia de la base de datos.

En los sistemas distribuidos, varios procesos pueden coordinarse para ejecutar una tarea. Sus acciones deben ser atómicas con respectos a los otros procesos. Como ejemplo, en un sistema de base de datos distribuidos, una transacción debe procesarse en cada sitio o en ninguno para mantener la integridad de la base de datos. Esto es atomicidad global. El protocolo que permite una atomicidad global es el protocolo de compromiso.

Protocolo de compromiso de dos fases

Este protocolo asume que uno de los procesos cooperativos actúa como coordinador, otros procesos se les refiere como subordinados (se asume que los subordinados se ejecutan en diferentes sitios). Éste protocolo asume que se dispone de un medio de almacenamiento estable en cada sitio y que se encuentra activo el protocolo de escritura de registro anticipado. Al inicio de la transacción, el coordinador envía el mensaje “inicio de transacción” a cada subordinado.

Fase 1. En el sitio del coordinador.

El coordinador envía el mensaje “solicitud de compromiso” a cada subordinado, para solicitarles el compromiso.

El coordinador espera la respuesta de todos los subordinados.

En cada sitio subordinado.

Al recibir el mensaje “solicitud de compromiso”, un subordinado toma las siguientes acciones. Si la transacción ejecutándose en su sitio termina satisfactoriamente, escribe los registros deshacer y rehacer en un medio estable y envía un mensaje “de acuerdo” al coordinador. En otro caso, envía el mensaje “abortar” al coordinador.

Fase 2. En el sitio del coordinador.

Si todos los subordinados responden “de acuerdo” y el coordinador también está de acuerdo, entonces el coordinador escribe el registro “compromiso” en el registro histórico. Luego envía el mensaje “compromiso” a todos los subordinados. En otro caso, el coordinador envía el mensaje “abortar” a todos los subordinados.

El coordinador espera un mensaje de “reconocimiento” de cada subordinado.

Si el mensaje “reconocimiento” no es recibido por el coordinador después de un período de tiempo, el coordinador reenvía el mensaje “compromiso/abortar” a los subordinados.

Si se reciben todos los “reconocimientos”, el coordinador escribe el registro “completo” al registro histórico.

En cada sitio subordinado.

Al recibir el mensaje “compromiso”, un subordinado libera todos los recursos, ejecuta la transacción y envía un “reconocimiento”.

Al recibir el mensaje “abortar”, un subordinado deshace la transacción utilizando el registro deshacer, libera todos los recursos, y envía un “reconocimiento”.

Cuando no hay fallas ni pérdidas de mensajes, es fácil ver que todos los sitios se comprometerán incluyendo al coordinador.

Protocolo de compromiso en presencia de fallas de sitio

Suponga que el coordinador falla antes de escribir el registro “compromiso”. En la recuperación, el coordinador difunde el mensaje “abortar” a todos los subordinados. Todos los subordinados que estaban de acuerdo con el compromiso simplemente deshacen la transacción utilizando el registro deshacer y abortan. Otros subordinados solamente abortarán la transacción. Note que todos los subordinados se bloquean mientras no reciban el mensaje “abortar”.
Suponer que el coordinador falla después de escribir el registro “compromiso” pero antes de escribir el registro “completo”. En la recuperación, el coordinador difunde el mensaje “compromiso” a todos los subordinados y espera el reconocimiento. En este caso también los subordinados se bloquean mientras no reciban el mensaje “compromiso”.

Suponer que el coordinador falla después de escribir el registro “completo”. En la recuperación, no hay nada que pueda ser hecho por la transacción.

Si un subordinado falla en la fase 1, el coordinador puede abortar la transacción porque no recibe ninguna respuesta del subordinado fallido.

Suponer que un subordinado falla en la fase 2, esto es, después de escribir los registros deshacer y rehacer. En la recuperación, el subordinado debe consultar con el coordinador si debe abortar (es decir, si debe ejecutar una operación deshacer) o comprometer la transacción. Note que el comprometer significa realizar una operación rehacer porque el subordinado pudo fallar antes de actualizar la base de datos.

En el caso de falla en la transmisión de mensajes, el protocolo de dos fases perderá mucho tiempo enviando mensajes y posiblemente la transacción no se ejecute. El protocolo de compromiso de dos fases garantiza la atomicidad global, su principal desventaja es que es un protocolo con bloqueo, existe otro protocolo de compromiso sin bloqueo el cual se sale del alcance de este material.
Protocolo de elección
Una técnica común la cual provee tolerancia a fallas en sistemas distribuidos es la replicación de datos en múltiple sitios. Si un sitio no esta disponible, los datos se pueden obtener de otras copias en otros sitios. El protocolo de compromiso puede ser utilizado para actualizar múltiples copias de datos, pero no es resistente en el caso de que se presenten múltiples fallas de sitios, fallas del medio de comunicación y fraccionamiento de red. En el protocolo de compromiso, cuando un sitio no es recuperable, el coordinador envía mensajes en repetidas ocasiones y eventualmente decide abortar la transacción, por ello se niega el acceso a los datos. Sin embargo, es deseable que un sitio continúe operando aunque otros  tengan fallas, o por lo menos, un fragmento debe seguir funcionado cuando el sistema se ha fragmentado. Una bien conocida técnica para el manejo de datos replicados es el mecanismo de elección. Con el mecanismo de elección, a cada replica se le asigna algún número de votos y un proceso debe reunir la mayoría de votos antes de que pueda acceder a una replica. El mecanismo de elección es más tolerante a fallas que el protocolo de compromiso en el sentido de que permite el acceso a datos bajo fragmentación de red, fallas de sitios y pérdida de mensajes con el compromiso de mantener la integridad de los datos. Existen dos métodos de elección, el método estático y el dinámico, en este material abarcaremos solamente el método de elección estático.

Protocolo de elección estático
Sistema modelo. Las replicas se almacenan en sitios diferentes. Cada operación de acceso a archivo debe obtener un bloqueo apropiado. El bloqueo otorga reglas que permiten: “una escritura y ninguna lectura” o “múltiples lecturas y ninguna escritura” en el acceso simultáneo a archivos. Se asume que cada sitio tiene un manejador de bloqueo que ejecuta las operaciones relacionadas al bloqueo, y a cada archivo se le asocia un número de versión, el cual nos dice el número de veces que un archivo ha sido actualizado. El número de versión se almacena en un medio estable, y cada operación de escritura exitosa en una replica, actualiza su número de versión.

Idea básica. La esencia del algoritmo de elección el cual controla el acceso a datos replicados es como sigue: A cada replica se le asigna un cierto número de votos. Esta información se almacena en un medio estable. Se permite una operación de lectura o escritura si se obtiene un cierto número de votos, quórum de lectura o quórum de escritura, respectivamente, de los procesos participantes.

Cuando un proceso ejecutándose en el sitio i realiza una solicitud de operación de lectura o escritura a un archivo, se inicia el siguiente protocolo:

El sitio i hace una solicitud de bloqueo al manejador local.

Cuando se acuerda la solicitud, el sitio i envía un mensaje de “solicitud de voto” a todos los sitios.

Cuando un sitio j recibe el mensaje “solicitud de voto”, hace una solicitud de bloqueo al manejador de bloqueo local, si se acuerda la solicitud de bloqueo, entonces devuelve el número de versión de su replica (VNj) y el número de votos asignados a la replica (Vj) al sitio i.

El sitio i decide tiene o no el quórum, basándose en las respuestas recibidas en tiempo de la siguiente manera (P denota el conjunto de sitios que respondieron).

Sea v el número total de votos asignados a todas las copias. Los valores para r (quórum de lectura) y w (quórum de escritura) son seleccionados de tal manera que:

r + w > v;     w > v/2
Si la solicitud fue de lectura, entonces el total de votos obtenido es:  vr = Suma vk, donde k є P.

Si la solicitud fue de escritura: El quórum de escritura es igual a la suma de votos del conjunto Q, donde Q se determina de la siguiente manera:

vw = Suma vk,  k є Q

Sea M = max {VNj  :  j ε P}, Q = {j ε P  :  VNj = M} si su copia de archivo está actualizada. La copia está actualizado si el número de versión es igual a M. Si la copia no esta actualizada, la copia actualizada se obtiene de un sitio que la tenga actualizada. Una vez que la copia actualizada se tiene localmente, el sitio i ejecuta el siguiente paso.

Si la solicitud es de lectura, el sitio i, lee la copia local. Si la solicitud es de escritura, el sitio i actualiza la copia local . Una vez que todos los accesos a la copia han concluido, el sitio i actualiza VNi y envía todas las actualizaciones y VNi a todos los sitios en Q. Notar que la operación de escritura actualiza solamente las copias actualizadas. Después el sitio i hace una solicitud de liberación de bloqueo a su manejador de bloqueo local y a todos los sitios en P.

Todos los sitios que reciben la actualización la ejecutan en sus copias locales, y al recibir una solicitud de liberar bloqueo liberan el bloqueo.

Los valores seleccionados para r y w combinado con la idea de que las operaciones de escritura actualizan solamente las copias actualizadas garantizan lo siguiente:

Ninguna copia obsoleta es actualizada por una operación de escritura.

Existe un subconjunto de replicas que están actualizadas cuyos votos totales son w.

El quórum de escritura w es los suficientemente grande tal que no permite escrituras simultáneas sobre dos subconjuntos distintos de replicas.