Presentacion

¿Qué es Paxos?
Replicación =>Alta Disponibilidad
•Consenso
Es un algoritmo que tiene los siguientes
objetivos

Paxos:Replicación
Varias máquinas han de alcanzar el mismo
estado en algún instante de tiempo.
Si tenemos n máquinas, todas ellas deberán
alcanzar un estado común.

Paxos:Replicación
Esto en un principio parece sencillo,pero...
Si hay varios usuarios conectados al mismo
tiempo... ¿Quién va primero?

Paxos:Replicación
No se puede asegurar que las dos máquinas
reciben las peticiones en el mismo orden.
La máquina 1 puede recibir la petición Naranja
y Azul.
La máquina 2 puede recibir la petición Azul y
Naranja.
¡Existe inconsistencia!

Paxos:Replicación
Para que todos los ordenadores reciban las
peticiones en el mismo orden se necesita algo
que elija dicho orden.

Paxos:Consenso
Todos los procesos han de llegar a un
acuerdo, para decidir que operación se
realiza.
Para esto se realiza una votación.

Paxos:Votación
Un proceso propone una operación para una
posición a unos procesos del sistema.
Estos procesos deciden si están a favor o no.
Si la mayoría está a favor se acepta la
operación.

Paxos
Una vez explicados los objetivos...
Expliquemos como funciona
Paxos!!!

Paxos:Estructura
En Paxos existen 3 tipos de procesos:
Réplicas.
Líderes.
Aceptores.

Paxos:Réplicas
Endpoint de entrada para los clientes.
Sobre la misma se implementa la aplicación
que deseamos replicar.
Internamente recibe las peticiones, las ordena
en diferentes posiciones y las envía a
votación.
Una vez votada la operación , el programa la
procesa y se retorna al cliente.

Paxos:Réplicas
op1
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas 0 1 2
op1
op2
op2

Paxos:Réplicas
Al recibir las peticiones, observa la posición
más pequeña entre aceptadas y propuestas
que no tienen valor.
Introduce las operaciones para proponer en
dicha posición.
Se asegura que al menos una de las
propuestas en X será aceptada en X.

Paxos:Réplica
op1 op3
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op1
0 1 2
op2
op1
op3
op2

Paxos:Réplica
op1 op3 op2
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op1 op3
0 1 2
op2
op3
op2

Paxos:Réplica
Cuando una operación es aceptada, se
proponen las operaciones pendientes en el
siguiente slot libre.
Se procesa la operación aceptada y se
retorna al cliente.
¡No tienen porque coincidir con el orden de
envío del cliente!

Paxos:Réplica
Una réplica recibe una operación aceptada
para una posición que no ha propuesto, y
posterior a las que propone.
La réplica ha de almacenar pero no ejecutar
dicha operación.
Cuando decida una operación, ejecutará
todas las operaciones en orden secuencial.

Paxos:Réplica
Se asegura que todas las operaciones se
ejecutan en el mismo orden.
¡¡Incluso si se reciben en orden desordenado!!

op0
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op4
0 1 2
op4
R1
R2
Paxos:Réplica

op0
Peticiones
Propuestas
0 1 2
Peticiones
Aceptadas
op0 op4
0 1 2
op4
R1
R2
Ejecuta
Paxos:Réplica

Paxos:Líderes
Son los encargados de inicializar las
votaciones de las peticiones.
Reciben mensajes de las réplicas. Si el
mensaje no ha sido decidido entonces inician
la votación.

Paxos:Líderes
¡Problema!
Petición(x),pos:1
Petición(x1),pos:1
¿Cuál de las dos
se decide?
¡Existe una colisión!

Paxos:Líderes
Para estos casos se introduce el concepto de
Ballot.

Paxos:Líderes
Cada votación se realiza dentro de un espacio
llamado ballot.
Varias peticiones pueden pertenecer a un
mismo ballot.
Pero un ballot solamente pertenece a un líder.
¡Así se evitan colisiones!.

Paxos:Líderes
Cada líder posee un ballot.
El ballot se identifica por un número
secuencial y el nombre del líder.
Ante una votación se comparan los valores
del ballot.
Gana aquel que tiene un ballot mayor.

Paxos:Líderes
Ballot:<0,Jose>
Ballot:<0,Mariano>
Petición(x),pos:1
Petición(x1),pos:1
Mariano posee un ballot mayor.
Su petición seguramente sea la aceptada.

Paxos:Líderes
Con esta solución se impide la colisión, pero...
¿El otro líder nunca conseguirá decidir alguna
petición?

Paxos:Líderes
Un líder con un ballot inferior recibe de sus
votantes un PREEMPT.
Es decir, se le ofrece la posibilidad de
aumentar su ballot y tomar el control.
Simplemente ha de aumentar su ballot una
unidad por encima del ballot actual.

Paxos:Líderes
Ballot:<0,Jose>
Ballot:<0,Mariano>
Petición(x),pos:1
Petición(x1),pos:1
PREEMPTED
ACEPTED

Paxos:Líderes
Ballot:<1,Jose>
Ballot:<0,Mariano>
Petición(X1),pos:1 ACEPTED

Paxos:Líderes
Al recibir el PREEMTED, el líder aumenta su
ballot y realiza de nuevo la votación.
¡¡Pero ha de votar con el mismo valor ya
adoptado!!
Así se asegura que todos los líderes votan el
mismo valor para la misma posición incluso en
diferentes ballots.

Paxos:Líderes
Esto conlleva otro problema.
Cada vez que hay una colisión, un líder
aumenta su ballot y realiza de nuevo la
petición.
¡El número de mensajes aumenta en función
del número de Líderes!
Más Líderes => Más mensajes => Menor rendimiento.

Paxos:Líderes
La duplicidad de los líderes se permite para
aumentar la disponibilidad del sistema.
Si hay un líder y este cae el sistema no
avanzaría.
Con varios líderes se resuelve.
Vale...muy bien,
¿pero el
rendimiento?

Paxos: Líderes
El mejor rendimiento se obtiene con un único
líder.
Para acercarse a este rendimiento sin perder
la disponibilidad...
Si un líder recibe PREEMPTED, se mantiene
dormido durante un intervalo T.
Al finalizar dicho intervalo toma el control.

Paxos:Líderes
De esta forma los líderes se van
intercambiando el control, y el número de
colisiones se ve disminuida.

Paxos:Líderes
Espera un momento... antes has dicho una
cosa...
Después de recibir un PREEMPTED el líder
aumenta su ballot y propone el valor ya
aceptado en la posición...

Paxos:Líderes
¿Como sabe el líder que valor fue votado en
dicha posición?

Paxos:Líderes
Es más... Si aparece un líder nuevo, este no
sabe que se ha votado y puede dar todo el
rato “palos de ciego”.
¿Como consigue conocer todo el estado del
sistema y así “estar al día”?

Paxos:Aceptores
Los aceptores tienen dos propósitos en
Paxos:
1.Votar las peticiones de los líderes.
2.Actuar como la memoria principal del sistema,
almacenando todas las peticiones aceptadas.

Paxos:Aceptores
Al almacenartodaslasoperaciones, esposible
re-establecer el sistema a partir de ellos.
Un
nuevolíderpuedeconocertodaslasvotaciones.
Unanuevaréplicapuedeejecutartodaslasoperac
ionesparaponerse al día.

Paxos:Aceptores
Por lo tanto...

Paxos:Aceptores
Son una parte crítica del sistema
Si los aceptores fallan no se pueden aceptar
peticiones.
Y se pierden todas las peticiones.

Paxos:Aceptores
Si los aceptorespierdensuestado,
seríacomosihubiésemostrabajadodurantedías
y el día de la
entregatodohubiesedesaparecido.
¡Nosabríamosquedado sin nada!

Paxos:Aceptores
Para evitar esta situación es necesario
realizar una replicación de los aceptores, para
asegurar que siempre estén disponibles.
Es necesario que existan siempre al menos
(f/2)+1 aceptores funcionando, donde f es el
número de fallos soportados.

Paxos:Aceptores
Esto significa que...
Una petición es aceptada si la mayoría de los
aceptores del sistema aceptan la petición.
¡Existe un consenso!

Paxos:Aceptores
El líder envía su petición y el ballot a todos los
aceptores del sistema.
Los aceptores comparan los ballots:
Si el ballot es mayor acepta la petición y la
almacena.
Si es inferior manda un PREEMTED al
líder.

Paxos:Aceptores
El líder ha
de cambiar el ballot!
Preempted

Paxos:Aceptores
Obligando a que la mayoría de los aceptores
respondan la petición se consiguen dos
objetivos:
Un consenso.
Asegurar que siempre hay un conjunto de
aceptores que conocen todas las
peticiones.

Paxos:Aceptores
Los mensajes
pueden perderse!

Paxos:Arquitectura
El sistema se ejecuta dentro de un clúster de
ordenadores.
En el clúster, al menos los aceptores deben
estar desplegados.
Los líderes y réplicas podrían encontrarse en
una red externa.

Paxos:Arquitectura
Esta arquitectura ofrece el
servicio
¡¡Pero si falla la red se pierde la
disponibilidad!!

Paxos:Arquitectura
Se duplica la red y los puntos
de entrada.
Se soportan las caídas de red.
Se consiguen distintos dominios
de fallo: Ante el fallo de un
sistema el resto sigue
disponible.

Paxos:Arquitectura
Es necesario que exista un
balanceo de aceptores en cada
dominio.
Se deben de crear nuevos
procesos dinámicamente ,
según las necesidades.

Paxos:Arquitectura
Si un dominio cae, el otro
dominio desplegará n
aceptores, hasta que estos
constituyan una mayoría.

Paxos:Arquitectura
Los nuevos aceptores realizan
una actualización de su estado.
!De esta forma el sistema
puede seguir funcionando!

Paxos
¿Y todo esto al final para que sirve?

Paxos
Conseguir alta disponibilidad.
Si un programa (réplica) cae, seguirá otro
funcionando con el mismo estado.
El sistema podría crear tantas réplicas como
sean necesarias en cada momento.

Paxos
Permite realizar un “balanceo” de las
peticiones.
Un número N de réplicas pueden conectarse a
un Líder L1.
Un número N’ de réplicas pueden conectarse
a un Líder L2.
Si ambos líderes tienen en común los
aceptores, ambos tendrán la misma
información.

Paxos
Réplicas Líderes Aceptores

Paxos
Todas las réplicas tienen un punto de entrada
al sistema.
Pero todos los puntos de entrada comparten
la misma memoria, por lo que tienen el mismo
estado.

Paxos:Demo
Se ha realizado una implementación del
algoritmo sobre CoffeeScript.
Se ha realizado una aplicación web que utiliza
dicha implementación para replicar su estado.

Paxos:Demo
La aplicación tiene dos partes:
Servidor: Desarrollada sobre Node.JS
Cliente: Desarrollada sobre PHP.

Paxos:Demo-Servidor
El servidor realiza dos acciones.
Contiene un servidor HTTPs, ofrece al
exterior un servicio REST con un conjunto
de aplicaciones.
Procesa las operaciones y guarda los datos
en una BBDD MongoDB.

Paxos:Demo-Cliente
Aplicación diseñada sobre PHP utilizando
Symfony2.
“Simplemente” consume el servicio REST y
muestra los resultados al cliente.

Paxos:Demo
Symfony+REST+Réplica
Symfony+REST+Réplica
Líder+Aceptor

Paxos:Demo
¿Y en que consiste?

Permite al usuario subir ficheros a la “nube”.
El usuario puede listar , subir y borrar los
ficheros.
Todos los ficheros son replicados en
diferentes servidores
Vale..es una copia descarada de DropBox.

El servicio REST que ofrece tiene las
siguientes acciones:
LIST => Obtiene una lista de todos los
ficheros. Realiza una petición GET.
UPLOAD => Sube un fichero al
sistema.Realiza una petición PUT.

DOWNLOAD => Descarga un fichero al
sistema. Realiza una petición GET.
DELETE => Elimina un fichero del
sistema.Realiza una petición DELETE.

El servidor utiliza HTTPs con el fin de
encriptar la comunicación.
Para asegurar que una petición se refiere a un
fichero de un usuario en concreto... Se puede
enviar el mensaje con un token vinculado a la
sesión del usuario. Si no coincide no tiene
derechos sobre el mismo.

express = require 'express’
http = require 'https’
fs = require 'fs’
key = fs.readFileSync('key.pem').toString()
cert = fs.readFileSync('cert.pem').toString()
app = express()
https = http.createServer({key:key,cert:cert},app)
app.use(require('connect').bodyParser())
https.listen 3000
Creación servidor Https

app.put '/file' , ( req , res ) =>
resultado = (msg)=>
res.set('Content-Type', 'application/json')
msg = JSON.parse msg
msg = {operation:'UPLOAD',result:msg.body.result}
res.send(msg)
Stub.sendOperation('WRITE’,type:'UPLOAD',
name:req.body.name, file:req.body.file, mimetype:req.body.mimetype}).then
resultado
Servicio REST: Upload File

app.get '/list', ( req , res ) =>
result = ( msg ) ->
res.set('Content-Type','application/json')
msg = {operation:'LIST',result:msg.body.result} res.send(msg)
Stub.sendOperation('READ',{type:'LIST'}).then result
Servicio REST: Listar Ficheros

app.get '/file', (req , res ) =>
result = ( msg ) ->
result = msg.body.result
msg = {operation:'DOWNLOAD',result:result}
res.send(msg)
Stub.sendOperation('READ',{type:'DOWNLOAD',id:req.query.id}).then result
Servicio REST: Descargar Fichero

app.delete '/file' , ( req , res ) =>
result = ( msg ) ->
result = msg.body.result
msg = {operation:'DELETE',result:result}
res.send(msg)
Stub.sendOperation('WRITE',{type:'DELETE',id:req.query.id}).then result
Servicio REST: Eliminar Fichero

En el cliente se utiliza Guzzle.
Un API sobre PHP que facilita la creación y
consumo de servicios web utilizando REST.

MyBox: Guzzle
$client = new Client("https://127.0.0.1:3000");
//crea el tipo de cliente y forma la query
$request = $client->delete("file");
$request->getQuery()->add("id", $id);
//utilizado para no comprobar el certificado SSL
$request->getCurlOptions()->set(CURLOPT_SSL_VERIFYHOST, false);
$request->getCurlOptions()->set(CURLOPT_SSL_VERIFYPEER, false);
//Se envía la petición y se procesa el resultado en JSON
$response = $request->send();
$data = $response->json();
$data = $data['result'];
$data = json_decode($data,true);

La autorización se realiza con Google+

• Puedesver un video en:
• http://www.youtube.com/watch?v=qtxz7Mvj0l4

Presentacion

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (14)

Presentacion