Algoritmo de Paxos

Algoritmo de Paxos
El algoritmo de Paxos es un algoritmo que nos permite llegar a consensos en sistemas distribuidos. Entendemos
consenso como el proceso de ponerse de acuerdo sobre uno de los resultados entre un grupo de participantes. Este
problema se hace difcil cuando los participantes o su medio de comunicacin puede experimentar fallos.
El protocolo Paxos primero fue publicado en 1989 e incluye una gama de soluciones de compensacin entre el
nmero de procesos, el nmero de mensajes con retraso antes de aprender el valor acordado, el nivel de actividad de
los participantes, el nmero de mensajes enviados, y los tipos de fallos. Aunque un protocolo de consenso con
tolerancia a fallos determinista no puede garantizar el progreso en una red asncrona, Paxos garantiza la seguridad
(libre de inconsistencia), y las condiciones que podran hacer que no progrese son difciles de ocurrir.
Funciona en el modelo de paso de mensajes con asincrona y con menos n/2 fallos (pero no con fallos bizantinos). El
algoritmo de Paxos garantiza que se llegar a un acuerdo y garantiza la finalizacin si hay un tiempo suficientemente
largo sin que ningn proceso reinicie el protocolo.

Contexto: Algoritmos de consenso

Cuando se habla de consenso en sistemas distribuidos nos referimos a un conjunto de procesos que han de ponerse
de acuerdo en un valor una vez uno o varios procesos han propuesto cul debera ser este valor.
Supongamos que tenemos una coleccin de procesos pi(i= 1, 2...N ) los cuales se comunican por paso de mensajes.
El objetivo es llegar a consenso aunque haya fallos, por lo que se asume que la comunicacin es fiable, pero que los
procesos pueden fallar. Para llegar a un consenso, cada proceso pi empieza en el estado de no decisin y propone un
valor vi. Los procesos se comunican unos con otros intercambiando valores. A continuacin, cada proceso fija un
valor en una variable de decisin di. Cuando lo hace, entra en el estado decidido, en el cual ya no se podr cambiar
di. Cada una de las ejecuciones de un algoritmo de consenso debera satisfacer las siguientes condiciones:
Finalizacin: cada proceso correcto debe acabar asignando un valor a su variable de decisin.
Acuerdo: el valor finalmente decidido por todos los procesos correctos es el mismo.
Integridad: si todos los procesos correctos han propuesto el mismo valor, entonces cualquier proceso correcto en
el estado de decisin ha elegido este valor.

Roles
Durante su funcionamiento, Paxos describe las acciones de los procesos mediante una serie de roles establecidos en
el protocolo: Cliente, Aceptador, Proponente, Aprendiz y Lder. En las implementaciones tpicas, un mismo proceso
puede tener diferentes roles al mismo tiempo. Estos roles son:
Cliente
El cliente emite una peticin al sistema distribuido, y espera una respuesta.
Proponente
Un proponente media por una peticin del cliente, tratando de convencer a los aceptadores para que se pongan
de acuerdo sobre el mismo ratificando un valor propuesto, y actan como un coordinador para seguir adelante
con el protocolo cuando se producen conflictos.
Aceptadores
Los aceptadores actan como la "memoria" con tolerancia a fallos del protocolo. Los aceptadores se recogen
en grupos llamados Qurums. Cualquier mensaje enviado a un aceptador debe ser enviado a un Qurum de
aceptadores. Cualquier mensaje recibido de un aceptador se ignora a menos que se reciba una copia de cada
aceptador en un Qurum.

Algoritmo de Paxos
Aprendiz
Los aprendiz actan como el factor de replicacin para el protocolo. Una vez que la peticin del cliente ha sido
acordada por los Aceptadores, el aprendiz puede tomar accin (es decir, ejecutar la peticin y enviar una
respuesta al cliente).
Lder
Paxos requiere un proponente completo (llamado el lder) para garantizar que el sistema va pasando por las
diferentes fases y concluye finalmente. Muchos procesos pueden creer que son lder, pero el protocolo slo
garantiza el progreso, si uno de ellos es finalmente elegido. Si dos procesos creen que son los lder, pueden
paralizar el protocolo de forma continua proponiendo cambios conflictivos.

Qurums
Los Qurums expresan las propiedades de seguridad de Paxos, garantizando que al menos algn proceso conserve el
conocimiento de los resultados. Los Qurums se definen como subconjuntos del conjunto de aceptadores tales que
dos Qurums cualesquiera comparten al menos un miembro. Tpicamente, un Qurum es cualquier mayora de
aceptadores participantes. Por ejemplo, dado el conjunto de aceptadores {A, B, C, D}, un Qurum sera cualquiera
de los tres grupos de aceptadores: {A, B, C}, {A, C, D}, {A, B, D} , {B, C, D}.

Seguridad
La familia Paxos define tres propiedades de seguridad que siempre han de llevarse a cabo para poder garantizar la
seguridad, independientemente del patrn de fallos:
No trivialidad: Slo valores propuestos se pueden aprender.
Consistencia: El valor aprendido tiene que ser nico (es decir, dos aprendices distintos no pueden aprender
valores diferentes).
Vitalidad(C, A): Si un aprendiz A propone un valor C, entonces el aprendiz A aprender obligatoriamente algn
valor (siempre y cuando existan suficientes procesos funcionando correctamente).

Funcionamiento
Paxos Bsico
Esta implementacin es la ms bsica del protocolo de Paxos. Cada instancia del protocolo bsico Paxos decide un
nico valor de salida. El protocolo consta de varias fases. Un proponente no debe iniciar el protocolo si no se puede
comunicar con al menos un Qurum de aceptadores.
El algoritmo de consenso se estructura en dos fases:
Fase 1
Preparar
Un proponente (el lder) crea una propuesta identificada con un nmero N. Este nmero debe ser mayor
que cualquier propuesta anterior que utiliza este proponente. Despus, enva un mensaje (peticin)
prepara(N) a una Qurum de aceptantes.
Prometer
Si un aceptador recibe una peticin de prepara con un nmero N mayor que cualquier otra peticin de
prepara que haya respondido hasta ese momento, entonces contesta a la peticin con una promesa de no
aceptar ninguna otra propuesta con nmero inferior a N y con el nmero de propuesta mayor (si hay
alguna) que ha aceptado.

Algoritmo de Paxos
Fase 2
Aceptar peticin
Si el proponente recibe una respuesta a su peticin de prepara(N), es decir una promesa de un Qurum
de aceptadores. Entonces:
Si cualquier aceptador haba aceptado previamente una propuesta, entonces se enva una peticin de
aceptar(N,V) a cada uno de los aceptadores, donde V es el valor del nmero de propuesta mayor entre todas
las respuestas recibidas.
En cambio, si ninguno de los aceptadores haba aceptado una propuesta hasta ese momento, en este caso se
enviar una peticin de aceptar(N,V) a cada uno de los aceptadores, donde V es el nuevo valor que hay que
aceptar que es elegido por el proponente.
Aceptado
Si un aceptador recibe un mensaje de peticin aceptar la propuesta N, debe aceptarlo si y solamente si
an no lo ha prometido tener en cuenta slo las propuestas tengan un identificador mayor que N, es
decir, si an no ha respondido a ninguna peticin de prepara(N) (enviar un mensaje de promesa). En este
caso, se debe registrar el valor correspondiente V y enviar un mensaje de aceptado al Proponente y cada
aprendiz. Si no, se puede ignorar la peticin Aceptar.
Las fases fallan cuando varios proponentes envan mensajes conflictivos de preparar(N), o cuando el
proponente no recibe la respuesta del Qurum (promesa o aceptado). En estos casos, una nueva
iteraccin del protocolo debe iniciarse con un nmero de propuesta superior.
Hay que tener en cuenta que cuando un aceptador acepta una solicitud, est reconociendo el liderazgo
del proponente. Por lo tanto, Paxos se puede utilizar para seleccionar un lder en un grupo de nodos.
Esto es una representacin grfica del protocolo bsico Paxos. Por lo que hay que tener en cuenta que
los valores devueltos en el mensaje Promise son nulas la primera vez que se hace una propuesta, ya que
ningn aceptador ha aceptado un valor antes en esta iteracin.
Flujo de mensajes: Paxos Bsico
(Primera iteracin completada)

Cliente
Proponente
Aceptadores
Aprendices
|
|
| | |
| |
X---------->|
| | |
| |
Peticin
|
X--------->|->|->|
| |
Prepara(1)
|
|<---------X--X--X
| |
Promesa(1,{Va,Vb,Vc})
|
X--------->|->|->|
| |
Aceptar!(1,Vn)
|
|<---------X--X--X------->|->|
Aceptado(1,Vn)
|<------------------------------------X--X
Respuesta
|
|
| | |
| |
Vn = last(Va, Vb, Vc)

Algoritmo de Paxos

Casos de error en paxos bsico

En estos casos de error, el protocolo no requiere recuperacin. No son necesarios iteraciones o mensajes adicionales,
tal y como se muestra a continuacin:
Flujo de mensajes: Paxos bsico, fallo del aceptador
(Tamao del Qurum = 2 Aceptadores)

Cliente
Proponente
Aceptadores
Aprendices
|
|
| | |
| |
X---------->|
| | |
| |
|
X--------->|->|->|
| |
|
|
| | !
| |
|
|<---------X--X
| |
|
X--------->|->|
| |
|
|<---------X--X----------->|->|
|<-------------------------------------X--X
|
|
| |
| |

Peticin
Prepara(1)
!! FALLO !!
Promesa(1,{null,null, null})
Aceptar(1,V)
Aceptado(1,V)
Respuesta

Flujo de mensajes: Paxos bsico, fallo del aprendiz redundante

Cliente
Proponente
Aceptadores
Aprendices
|
|
| | |
| |
X---------->|
| | |
| |
|
X--------->|->|->|
| |
|
|<---------X--X--X
| |
|
X--------->|->|->|
| |
|
|<---------X--X--X-------->|->|
|
|
| | |
| !
|<-------------------------------------X
|
|
| | |
|

Peticin
Prepara(1)
Promesa(1,{null,null,null})
Aceptar(1,V)
Aceptado(1,V)
!! FALLO !!
Respuesta

Flujo de mensajes: Paxos bsico, fallo del proponente

(Re-eleccin no mostrada, una instancia, dos rondas)

Cliente
|

Proponente

Aceptadores

Aprendices

X-------->|

Peticin

X---------->|->|->|

Prepara(1)

|<----------X--X--X

Promesa(1,{null, null, null})

!! FALLO DEL LDER DURANTE LA DIFUSIN !!

X---------->|

Aceptar(1,Va)

!! NUEVO LDER !!

X---------->|->|->|

Prepara(2)

|<----------X--X--X

Promesa(2,{null, null, null})

X---------->|->|->|

Aceptar(2,V)

|<----------X--X--X-------->|->|

|<------------------------------------X--X

Aceptado(2,V)
Respuesta

Algoritmo de Paxos
|

5
|

Multi-Paxos
La implementacin ms comn de Paxos requiere un flujo continuo de los valores acordados que actan como
comandos para una mquina de estado distribuido. Si cada comando es el resultado de una nica instancia del
protocolo bsico de Paxos, obtendramos una gran cantidad de gasto.
Si el proceso que acta como lder es relativamente estable, la fase 1 sera innecesaria. Por lo tanto, es posible omitir
la fase 1 para futuras instancias del protocolo con el mismo lder.
Para lograr esto, el nmero de instancia I es incluido junto con cada valor. Multi-Paxos reduce el retraso de los
mensajes libres de fallos (del proponente al aprendiz) a la mitad (de 4 a 2 delays).
Flujo de mensajes: Multi-Paxos, inicio
(Primera estancia con un nuevo lder)

Cliente
Proponente
Aceptadores
Aprendices
|
|
| | |
| |
--- Primera peticin --X---------->|
| | |
| |
Peticin
|
X--------->|->|->|
| |
Prepara(N)
|
|<---------X--X--X
| |
Promesa(N,I,{Va,Vb,Vc})
|
X--------->|->|->|
| |
Aceptar(N,I,Vm)
|
|<---------X--X--X-------->|->|
Aceptado(N,I,Vm)
|<-------------------------------------X--X
Respuesta
|
|
| | |
| |
Vm = last of (Va, Vb, Vc)
Flujo de mensaje: estado estacionario Multi-Paxos colapsado
(Instancias posteriores con el mismo lder)

Cliente
Proponente
Aceptadores
Aprendices
|
|
| | |
| |
X---------->|
| | |
| |
|
X--------->|->|->|
| |
|
|<---------X--X--X-------->|->|
|<-------------------------------------X--X
|
|
| | |
| |

Referencias

--- Primera peticin --Peticin

Aceptar(N,I+1,W)
Aceptado (N,I+1,W)
Resppuesta

Fuentes y contribuyentes del artculo

Fuentes y contribuyentes del artculo

Algoritmo de Paxos Fuente: http://es.wikipedia.org/w/index.php?oldid=72179858 Contribuyentes: Fixertool, Ikrespo, Miketanis, 8 ediciones annimas

Licencia
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/