75.

74 Sistemas Distribuidos I Consenso frente a cadas o fallos bizantinos

FIUBA

Los algoritmos corresponden al libro de M. Ben-Ari: Principles of Concurrent and Distributed Programming, 2nd. Edition, Addison-Wesley, 2006.

El motivo principal para construir sistemas distribuidos es para lograr sistemas confiables, por ejemplo, usando replicacin de procesos sobre varios procesadores independientes. Hay dos propiedades que necesitamos cumplir en un sistema confiable: es un sistema seguro frente a fallos, si una o mas fallas no causan dao al sistema o al usuario. Un sistema es tolerante a fallos, si continua cumpliendo con sus requerimientos frente a una o mas fallas. Un sistema distribuido no es automticamente seguro frente a fallos o tolerante a fallos. Por ejemplo, un algoritmo de exclusin mutua distribuido requiere de la colaboracin de todos los procesos y va a tener un deadlock si uno de ellos se cae. Temperatura

CPU
Regulador

CPU
Presin

Comparador

CPU
Un sistema confiable requiere de replicacin, por ejemplo, de sensores y de las computadoras que procesan la informacin. Se comparan las salidas y se usa un algoritmo como el votacin por mayora, para decidir que comando se enva al sistema central. La simplicidad del diagrama enmascara la complejidad de las dificultades que hay que resolver al disearlo: Cuando se replican los sensores de entrada, no todos van a dar exactamente el mismo valor. La votacin no es entonces, una comparacin trivial entre dos valores digitales. Un sensor averiado (que falla) o un procesador que falla (y no se cae), pueden producir datos errneos o valores fuera del rango de los que considera el algoritmo. Si todos los procesadores usan el mismo software, el sistema no es tolerante a bugs de software. Si se usan programas diferentes, puede haber diferencia en los valores de los mismos datos. Adems, programadores diferentes pueden hacer la misma interpretacin errnea de la especificacin.

75.74 Sistem as D istrib uidos I Consenso

Veamos como lograr consenso en un sistema distribuido: Cada nodo elige un valor inicial y se requiere que todos los nodos en el sistema decidan por uno de esos valores. Si no hay fallos en el sistema, hay un algoritmo trivial: cada nodo enva su eleccin a todos los dems y luego se aplica un algoritmo como el de votacin por mayora. Como todos los nodos tienen los mismo datos y ejecutan el mismo algoritmo, todos deciden por el mismo valor y se logra el consenso. Consideremos dos tipos de fallos: Fallos por cadas: en los cuales el nodo simplemente para de enviar mensajes. Fallos bizantinos: en el cual un nodo que falla enva mensajes arbitrarios (se llama as por Lamport, Shostak y Pease: Byzantine Generals Algorithm). El enunciado del problema: Un grupo de ejrcitos bizantinos est rodeando una ciudad enemiga. El balance de fuerzas es tal que si todos los ejrcitos atacan simultneamente, pueden capturar la ciudad, sino para evitar una derrota, todos se retiran (no atacan). Los generales tienen mensajeros confiables que exitosamente despachan los mensajes de un general a otro. Sin embargo, algunos de los generales son traidores y quieren que los ejrcitos sean derrotados. Se debe encontrar un algoritmo tal que todos los generales leales lleguen a un consenso sobre un plan. La decisin final ser por votacin de la mayora sobre sus elecciones iniciales. Si empatan, la decisin es retirada. Nota histrica: El imperio bizantino existi del ao 323 hasta que fue destruido por los turcos otomanos en 1453. Su capital era Constantinopla (hoy Estambul) y fue nombrada as por Constantino, el fundador del imperio. Su historia dio origen al trmino bizantino como sinnimo de manejos turbios y traicioneros, los cuales no deben ser peores que los que us o usa cualquier entidad poltica. Para mantener la verosimilitud con la historia, los nodos del sistema tendrn los nombres de emperadores bizantinos (segn Ben-Ari). En trminos de sistemas distribuidos, los generales modelan nodos y los mensajeros modelan los canales de comunicaciones. Mientras los generales pueden fallar, los mensajeros son totalmente confiables. Modelamos dos tipos de fallos: Cadas: Un traidor (un nodo fallado) simplemente deja de enviar mensajes en algn momento de la ejecucin del algoritmo. Bizantinas: Un traidor puede enviar mensajes arbitrarios y no exactamente aquellos requeridos por el algoritmo. En el caso de cada, asumimos que sabemos que el nodo se cay, por ejemplo, por un valor de timeout, tal que el nodo receptor sabe dentro de que periodo tiene que arribar un mensaje. Si no tenemos forma de decidir si el nodo se cay o si el mensaje est demorado, el problema del consenso no tiene solucin. Los fallos bizantinos son mas difciles de tratar, ya que hace falta un nico escenario que demuestre que el algoritmo es incorrecto para que no sirva. Debemos buscar si hay por lo menos un traidor malicioso cuyo conjunto de mensajes hace caer a nuestro algoritmo. El requerimiento que el consenso sea sobre el voto de la mayora, nos asegura que el algoritmo es aplicable y que no hay una solucin trivial. Una solucin trivial es por ejemplo: supongamos que todos los generales leales deciden atacar, pero esto no modela un sistema que calcula el mismo valor en todos los casos. Supongamos que tenemos 10 generales de los cuales dos son traidores. Si el valor inicial de 6 generales

75.74 Sistem as D istrib uidos I Consenso

es atacar y de dos retirarse, los traidores pueden hacer creer a algunos generales que las elecciones estaban divididas entre 8-2 y a otros 6-4, pero la mayora vota por atacar en cualquier caso y el algoritmo debe asegurar que se llegue a esta decisin. Por el otro lado, si las elecciones iniciales son 4-4 o 5-3 es muy posible que la decisin final est afectada por los traidores. Los algoritmos se ejecutan concurrentemente, o sea es sincrnico en el sentido que cada nodo enva un conjunto de mensajes y luego recibe las respuestas de esos mensajes. Ya que los diferentes tipos de mensajes no se reciben concurrentemente, no hace falta especificar el tipo de mensaje. El mensaje enviado incluye solamente el ID del nodo destino seguido de los datos a enviar, y en la recepcin solamente se necesitan variables para almacenar los datos que se reciben.

Algoritmo de una ronda:

Veamos el algoritmo obvio:
planType finalPlan planType array[generals] plan plan[myID] = chooseAttackorRetreat for all other generals G send(G, myID, plan[myID]) for all other generals G receive(G, plan[G]) finalPlan = majority(plan)

Los valores para planType son A para atacar y R para retirarse. Cada general elige un plan, enva su plan a todos los otros y espera sus planes. El plan final es el voto por mayora entre el propio y los recibidos por los otros. Supongamos ahora que hay 3 generales, dos de los cuales ( Zoe y Len) son leales y el tercero, Basilio, es un traidor. Basilio y Zoe eligen atacar (A) Len elige retirarse (R) El diagrama muestra el intercambio de mensajes, de acuerdo al algoritmo, donde Basilio se cae luego de enviar el mensaje a Len, indicando que quiere atacar y justo antes de enviar el mensaje a Zoe

Basilio A Zoe A A R R A

Len R

Las siguientes tablas muestran el contenido de los arreglos con los planes de ataque de los leales y el resultado del voto:
Le n
General Plan General

Z oe
Plan

Basilio Len Zoe Mayora

A R A A

Basilio Len Zoe Mayora

R A R

75.74 Sistem as D istrib uidos I Consenso

Ac vemos que si uno se cae, no hay consenso. Esto se puede extender a cualquier cantidad de generales, si unos pocos se caen, los restantes no llegan a un consenso.

Algoritmo de los generales bizantinos

El problema con el algoritmo anterior es que no usamos el hecho que ciertos generales son leales. Len podra atribuirle mas peso al plan de la general leal Zoe, que al del traidor. En un sistema distribuido, un nodo no puede conocer la identidad de los traidores directamente, sino que debe asegurar que el plan de los traidores no haga que los leales no lleguen a un consenso. El algoritmo de los generales bizantinos lo logra usando rondas adicionales de envo de mensajes: En la primera ronda cada general enva su propio plan y en las rondas subsiguientes, cada general enva lo que recibi de los otros generales. Por definicin, los generales leales siempre envan lo que recibieron, tal que si hay suficientes generales leales, pueden llegar a un consenso a pesar de los traidores. Veamos un algoritmo con dos rondas (o rounds): La primera ronda es la explicada antes, al finalizar, el arreglo de plan tiene los planes de cada uno de los generales. En la segunda ronda, estos planes se envan a los otros generales. Un general no tendra que enviar a si mismo su propio plan, ni tampoco enviarle a otro general lo que este general report. Entonces en cada ronda, se reduce en uno la cantidad de mensajes que hay que enviar.
planType finalPlan planType array[generals] plan planTpe array[general, generals] reportedPlan planType array[generals] majorityPlan plan[myID] = chooseAttackorRetreat for all other generals G send(g, myID, plan[myID]) for all other generals G receive(G, plan[G]) for all other generals G for all other generals G excepto G send(G, myID, G, plan[G]) for all other generals G for all other generals G except G receive(G, G, reportedPlan[G, G]) for all other generals G // primer votacin majorityPlan[G] = majority(plan[G] U reportedPlan[*,G]) majorityPlan[myID] = plan[myID] //segunda votacin finalPlan = majority(majorityPlan) send(G, myID, G, plan[G]):

significa enviar al general G lo que yo (general receptor (myID)) recib del plan almacenado en plan[G] del general G. Cuando este mensaje se recibe se almacena en reportedplan, donde el valor del elemento del arreglo reportedPlan[G,G] es el plan que G dice que recibe de G. La votacin se hace en dos etapas, una para cada general G, un voto por mayora del plan recibido directamente de G junto con todos los planes recibidos de G de los otros generales [*,G]. Esto es la intencin real de G y se almacena en majorityPlan[G].

75.74 Sistem as D istrib uidos I Consenso

La decisin final se obtiene de la segunda votacin de los valores almacenados en majorityPlan, que tambin contiene la propia.

Fallos por cadas Veamos primero el algoritmo en el caso de fallos por cadas con 3 generales, uno de los cuales es un traidor. La estructura de los dos generales leales para el mismo escenario anterior (en el cual Basilio se cae luego de enviar un mensaje a Len en el primer ronday antes de enviarlo a Zoe):
General Basilio Len Zoe Mayora Plan A R A Len Informado por Basilio Zoe Mayora A R A A General Basilio Len Zoe Mayora Plan R A Zoe Informado por Basilio Len A Mayora A R A A

Basilio solamente enva informacin en el primer ronda. Ambos generales eligen bien. Veamos otro escenario, en el cual el traidor enva todos sus mensajes en la primera ronda y uno en la segunda. Basilio enva un mensaje a Len diciendo que el plan de Zoe es atacar, pero se cae antes de enviarle a Zoe. Falta solamente un mensaje;
General Basilio Len Zoe Mayora Plan A R A Len Informado por Basilio Zoe A A Mayora A R A A General Basilio Len Zoe Mayora Plan R A Zoe Informado por Basilio Len A Mayora A R A A

La estructura es consistente y llegan al mismo resultado.

Fallos bizantinos con 3 generales:

El algoritmo de los generales bizantinos de 2 rondas es mucho mas complicado de lo que se necesita para un sistema que sufre solamente de cadas. Hay algoritmos mas simples (por ejemplo: flooding) para este problema. Es necesario solamente cuando hay fallos bizantinos, o sea, cuando un nodo enva cualquier mensaje y el algoritmo es incorrecto, si falla por un solo mensaje malicioso. En el contexto de la historia de los generales bizantinos, un traidor enva un mensaje de atacar (A) o retirarse (R), segn su estado interno. No muestra la eleccin o plan inicial del traidor, porque el plan puede ser ignorado totalmente al decidir que mensaje debe enviar. Siguiendo con el ejemplo anterior, en la primera ronda, el traidor Basilio, en lugar de caerse, enva R a Zoe.

Basilio A R Zoe A A R R A

Len R

75.74 Sistem as D istrib uidos I Consenso

Las estructuras de datos son las siguientes y los dos generales leales van a tomar decisiones finales inconsistentes, si trabajamos con el algoritmo de una sola ronda:
Len General Basilio Len Zoe Mayora Planes A R A A Zoe General Basilio Len Zoe Mayora Planes R R A R

El algoritmo de un solo rondaya era incorrecto para las cadas de procesadores. Consideremos el algoritmo de 2 rondas. En la primera ronda, Basilio enva A a ambos, en la segunda ronda, le informa correctamente a Zoe que el plan de Len es R, pero inconsistentemente reporta a Len, que el plan de Zoe es R. El resumen de resultados es el siguiente:
General Basilio Len Zoe Mayora Plan A R A Len Informado por Basilio Zoe A R Mayora A R R R General Basilio Len Zoe Mayora Plan R A Zoe Informado por Basilio Len A R Mayora A R A A

Len hace una decisin errnea sobre el plan de Zoe, por la informacin que recibi de Basilio. El algoritmo es incorrecto para 3 generales de los cuales uno es un traidor (2 leales y un traidor). Fallos bizantinos con 4 generales: Vamos a ver que el algoritmo de consenso es correcto para 4 generales, de los cuales 3 generales son leales y uno es un traidor. Cuando los generales leales votan la primera vez, para decidir cual es la eleccin de cada general, va a ser la informacin recibida de otros dos generales contra la de un solo traidor, as los generales leales deciden correctamente. Veamos los distintos escenarios para el algoritmo: Nuestro 4to. general es Alejandro y Zoe, pasa a ser nuestra traidora. Basilio y Alejandro eligen A, y Len elige R. La estructura de datos parcial del general leal Basilio muestra los mensajes recibidos de los generales leales, no los de la traidora Zoe:
General Basilio Alejandro Len Zoe Mayora Plan A A R ? Basilio Informado por Alejandro Len A R ? ? Mayora Zoe ? ? A A R ? ?

Basilio recibe el plan correcto del general leal Alejandro, de si mismo e indirectamente de Len. El informe de Zoe, lo ignoramos inicialmente ya que puede hacer que la votacin sea 2-1 en vez de 3-0, pero el resultado es correcto en cualquier caso. Basilio recibe tiene dos planes correctos de Len. Basilio tiene 3 votos correctos, el suyo propio y los de Alejandro y Len. Lo mismo ocurre en los otros dos generales leales. Pero es prematuro concluir que llegan a un consenso en la votacin final, porque Zoe puede enviar mensajes convenciendo a alguno de los otros

75.74 Sistem as D istrib uidos I Consenso

que su plan es A y a otros que es R. Falta mostrar que los tres generales llegan a un consenso sobre el plan de Zoe. Supongamos que Zoe enva, en la primera ronda, R a Basilio y a Len y A a Alejandro. Estos mensajes son reenviados correctamente por los generales leales en la segunda ronda. La estructura de datos de Basilio ser:
General Basilio Alejandro Len Zoe Mayora Plan A A R R Basilio Informado por Alejandro Len A R A R Mayora Zoe ? ? A A R R R

Zoe puede enviar mensajes arbitrarios a los generales leales, pero estos mensajes se informan correctamente por todos los generales leales, llegando a una mayora con respecto al plan de Zoe. En este caso, la decisin final de todos los leales es 2-1 a favor de R sobre el plan de Zoe.

El algoritmo del rey (King Algorithm)

El algoritmo de los generales bizantinos requiere una gran cantidad de mensajes, especialmente, si la cantidad de traidores (y por consiguiente, la de los generales) crece. Hay otro algoritmo para consenso, el algoritmo del rey, que usa una cantidad menor de mensajes. Sin embargo, el algoritmo requiere un general extra por cada traidor, o sea, si la cantidad de generales es n, n debe ser por lo menos 4t + 1, donde t es la cantidad de traidores, en vez de 3t + 1 que requiere el algoritmo de los generales bizantinos. Veamos el algoritmo para un traidor y 4*1+1=5 generales. El algoritmo se basa en que una pequea cantidad de traidores no puede influir en el voto final, si hay una mayora importante sobre un plan. Si hay 4 generales leales y el voto es 4-0 o 3-1, entonces un solo traidor no puede influir en el resultado. Solamente, si el voto es 2-2, el traidor puede obligar a que el consenso falle enviando A a algunos y R a otros. El algoritmo recibe el nombre de el algoritmo del rey, porque en cada ronda uno de los generales recibe el status especial de rey y cuyo voto es mas importante que el voto de los otros generales. Para preservar la naturaleza distribuida del algoritmo, asumimos que la identidad del rey no es conocida por los otros nodos. En cada ronda cada nodo sabe si es o no el rey. Adems, para preservar la propiedad que el sistema es tolerante a fallos con cualquier falla arbitraria, asumimos que el nodo del rey no se cae. Esto significa, que cualquiera sea el mtodo para designar el rey, es posible que el rey sea el traidor. Sin embargo, si dos generales toman el rol del rey en secuencia, est asegurado que por lo menos uno de ellos es leal. Cuando un general leal es el rey, l logra que los dems lleguen a un consenso. Si el segundo rey es leal, el voto final ser de acuerdo a este consenso. Si el primer rey es leal, los generales leales tendrn una mayora absoluta a favor al consenso, tal que si el segundo rey es un traidor, no lograr que los leales cambien sus planes.

75.74 Sistem as D istrib uidos I Consenso

El algoritmo es el siguiente:
planType finalPlan, myMajority, kingPlan planType array[generals] plan integer votesMajority, kingID, myID plan[myID] = choose AtackOrRetreat do 2 times for all other generals G // primera y tercera ronda send(G, myID, plan[myID]) for all other generals G receive(G, plan[G]) myMajority= majority(plan) votesMajority=cantidad de votos para myMajority if my turn to be king //segunda y cuarta ronda for all other generals G send(g, myID, myMajority) plan[myID] = myMajority else receive(kingID, kingPlan) if votesMajority > 3 plan[myID] = myMajority else plan[myID] = kingPlan finalPlan = plan[myID] // decision final

Cada general elige un plan y lo enva a todos los otros generales. Luego de recibir todos los mensajes, cada general tiene 5 planes y almacena el resultado del voto de la mayora en myMajority. Adems, la cantidad de votos para la mayora (3, 4 o 5) se almacenan en la variable votesMajority. La segunda ronda empieza con el rey enviando su plan a todos los otros generales. La eleccin del rey es arbitraria, por algn algoritmo fijo que ejecutan todos los generales, por ejemplo, los generales se pueden ordenar alfabticamente y el rey se elige en este orden. Cuando el nodo recibe el plan del rey, verifica votesMajority contra la cantidad de votos en favor de myMajority. Si la mayora es amplia (mayor que [n/2]+1, en este caso mayor que 3), se ignora el plan del rey, en el otro caso, cambia su propio plan al plan del rey. Finalmente, todo el algoritmo se ejecuta una segunda vez, durante este tiempo, otro general ser el rey. Veamos el algoritmo en un ejemplo: Necesitamos 5 generales: agregamos a Constantino y asumimos que es el traidor, solo nos interesan las estructuras de datos de los otros 4 generales. Los planes iniciales son A para Basilio y Alejandro y R para Zoe y Len. Constantino enva A a dos de los generales y R a los otros 2, para romper el consenso. Luego de la primera ronda las estructuras son las siguientes:

75.74 Sistem as D istrib uidos I Consenso

Basilio A Basilio A Basilio A Basilio A

Alejandro A Alejandro A Alejandro A Alejandro A

Len R Len R Len R Len R

Basilio Zoe R Alejandro Constantino Zoe A R Len Constantino Zoe A R Zoe Constantino Zoe R R Constantino R

myMajority R myMajority A myMajority A myMajority R

votesMajority 3 votesMajority 3 votesMajority 3 votesMajority 3

kingPlan

kingPlan

kingPlan

kingPlan

Consideremos que la primera reina, Zoe, es leal y enva R, su myMajority, como ningn general tiene amplia mayora (votesMajority>3), cambian su plan al de la reina:
Basilio R Basilio Alejandro Len Constantino Basilio Zoe myMajority votesMajority kingPlan R kingPlan R kingPlan R kingPlan R

Alejandro R Alejandro

Len

Constantino

Alejandro Zoe myMajority Len Zoe Zoe Zoe R

votesMajority

Basilio

Len R Len

Constantino

myMajority

votesMajority

Basilio

Alejandro

Constantino

myMajority

votesMajority

En la tercera ronda se envan los planes nuevamente y se recalculan myMajority y votesMajority. Dejamos sin completar al traidor, para ver si el resultado es afectado o no por el traidor
Basilio R Basilio R Basilio R Basilio R Alejandro R Alejandro R Alejandro R Alejandro R Len R Len R Len R Len R Basilio Zoe R Alejandro Constantino Zoe ? R Len Constantino Zoe ? R Zoe Constantino Zoe ? R Constantino ? myMajority R myMajority R myMajority R myMajority R votesMajority 4-5 votesMajority 4-5 votesMajority 4-5 votesMajority 4-5 kingPlan

kingPlan

kingPlan

kingPlan

Vemos que los mensajes del traidor Constantino no afectan el resultado, ya que es indistinto lo que l enve, todos los generales leales eligen R con amplia mayora (45) y a lo sumo podra ser 5-0. Consideremos el caso en el cual el primer rey es el traidor. En su condicin de rey puede enviar cualquier mensaje:

75.74 Sistem as D istrib uidos I Consenso

10

Basilio R Basilio

Alejandro

Len

Constantino

Basilio Zoe

myMajority

votesMajority

kingPlan R kingPlan A kingPlan A kingPlan R

Alejandro A Alejandro

Len

Constantino

Alejandro Zoe myMajority Len Zoe Zoe Zoe R

votesMajority

Basilio

Len A Len

Constantino

myMajority

votesMajority

Basilio

Alejandro

Constantino

myMajority

votesMajority

Durante la tercera ronda, los planes se intercambian nuevamente y se recalculan los votos. El resultado es:
Basilio R Basilio R Basilio R Basilio R Alejandro A Alejandro A Alejandro A Alejandro A Len A Len A Len A Len A Basilio Zoe R Alejandro Constantino Zoe ? R Len Constantino Zoe ? R Zoe Constantino Zoe ? R Constantino ? myMajority ? myMajority ? myMajority ? myMajority ? votesMajority 3 votesMajority 3 votesMajority 3 votesMajority 3 kingPlan

kingPlan

kingPlan

kingPlan

Todos los generales leales tienen el mismo conjunto de planes, cualquiera que sea el voto que emiti el traidor. El voto va a afectar el valor de myMajority en cada nodo, pero no la cantidad de votos, que permanece en 3, lo que significa que la eleccin no es absoluta. Ahora el general que se elige como rey/reina en la cuarta ronda, ser un/una general leal, o sea Zoe, as que cualquiera sea el kingPlan que enve, supongamos A, ser adoptado por todos los otros generales leales:
Basilio A Basilio Alejandro Len Constantino Basilio Zoe myMajority votesMajority kingPlan A kingPlan A kingPlan A kingPlan A

Alejandro A Alejandro

Len

Constantino

Alejandro Zoe myMajority Len Zoe Zoe Zoe A

votesMajority

Basilio

Len A Len

Constantino

myMajority

votesMajority

Basilio

Alejandro

Constantino

myMajority

votesMajority

Estos planes se convertirn en el plan final como vimos en el caso anterior y todos llegan a un consenso sobre A. El algoritmo llega a un consenso en todos los casos, con las restricciones, que el rey no se cae y que los dos generales que toman el rol del rey en secuencia, se asegura que por lo menos uno de ellos es leal.