O que é protocolo de consenso, Raft e etcd (parte 1)?
Essa é uma série de 3 artigos com o intuito de explicar os principais conceitos sobre protocolo de consenso, raft e uma demonstração de como isso funciona na vida real através do etcd.
Esse primeiro artigo vai percorrer pelos conceitos de protocolo de consenso e do raft (máquina de estado, estados de um servidor e o que é term).
O segundo artigo vai explorar os mecanismos de eleição de um líder, replicação de logs e mudanças de membros de um cluster do raft.
E o terceiro e último artigo vai demonstrar como isso funciona na vida real, em um cluster de etcd implementado na AWS.
Quando pensamos em plataforma de sistemas distribuídos existe dois temas fundamentais que é a capacidade de tolerância a falhas e sincronização da máquina de estado dos servidores pertencentes a um sistema distribuído.
Esses temas são endereçados através de um algoritmo de protocolo de consenso, que permite que uma coleção de servidores trabalhem em um grupo coerente de máquinas que continuam funcionando mesmo quando ocorre alguma falha em algum elemento do grupo.
Existem alguns protocolos de consenso, dois dos mais conhecidos são o Paxos (cujo a variante multipaxos é usado no Google) e o raft (usado no etcd, que é usado no Kubernetes).
Ambos possuem boas documentações e implementações:
- Paxos: https://paxos.systems/
- Raft: https://raft.github.io/
Legal, agora que já sabemos o principal conceito de protocolos de consenso, vamos entrar mais em detalhe nos conceitos do raft. E por que o raft é importante? Porque seu entendimento é muito importante para quem faz gestão de containers do Kubernetes. O Kubernetes implementa o Raft através do etcd, que garante o sincronismo de chaves e estado do cluster.
Então vamos resumir alguns conceitos do Raft (todos eles estão detalhados no paper disponível em https://raft.github.io/raft.pdf).
Base do Raft
O Raft é um protocolo de consenso (desculpe a repetição, mas ela é importante :)) que faz a gestão da replicação dos logs nas máquinas de estado dos servidores de um sistema distribuído. Meio difícil entender isso com essa frase né? Mas calma que vamos ter uma sessão para explicar o que é a máquina de estado.
Alguns pontos super importantes do raft:
- Strong Leader: sempre vamos ter um servidor líder no sistema distribído que utiliza o raft. É ele que recebe os comandos dos clientes e tem a responsabilidade de replicar o comando para a maioria (ou seja, 50% + 1) dos servidores membros do sistema;
- Leader Election: usa um mecanismo de timeout randômico para garantir que, caso o líder tenha algum problema, outro servidor do sistema se candidate, inicie uma eleição e se torne líder (também vamos ver todos esses conceitos);
- Membership Changes: é muito comum termos mudanças nos elementos do sistema distribuído, como remoção ou adição de membros. O raft utiliza um mecanismo que garante o funcionamento do consenso mesmo nos momentos de sobreposição do número de elementos do sistema.
Replicação da Máquina de Estado
A figura abaixo (https://raft.github.io/raft.pdf) mostra o fluxo de sincronização de logs entre as várias instâncias de máquina de estado de um sistema distribuído:
O raft implementa a replicação da máquina de estado replicando o log do servidor líder para os demais servidores. Com isso, cada instância contêm a mesma série de comandos (logs) replicado com o servidor líder para ser executado na máquina de estado. Isso garante a alta disponibilidade do sistema. Como o Raft precisa de um consenso para funcionar (50% + 1), o mínimo de servidores para garantir a alta disponibilidade são 3.
Explicando melhor o fluxo:
1- O Servidor líder (sempre ele) recebe o comando do cliente;
2- Que adiciona o comando em seu próprio log e sincroniza o comando com as demais instâncias;
3- Uma vez o comando replicado em consenso, cada instância processa na devida ordem na máquina de estado;
4- Servidor líder retorna o resultado do comando para o cliente.
Obviamente o resultado da execução na máquina de estado é sempre determinístico.
Server States e Terms
Bom, até o momento sabemos o básico dos conceitos de um protocolo de consenso, entendemos a base do Raft e a replicação da máquina de estado. A ideia agora é entender os estados que um servidor pode estar em um cluster usando Raft e o que é um term.
Bora lá, começando com o server states, um servidor pode estar em um dos 3 estados: follower, candidate ou leader. A figura abaixo (https://raft.github.io/raft.pdf) demonstra o fluxo de movimentação de um servidor entre esses 3 estados.
Os servidores iniciam no estado follower, nesse estado o servidor apenas responde aos requests de outros servidores. Uma vez que o follower não recebe alguma comunicação do leader (heartbeat) ele se torna candidate e inicia uma eleição. O candidato que receber a maioria dos votos dos demais servidores do cluster (50% + 1) ele se torna o leader. O líder opera com esse estado até ele falhar.
Em uma operação normal de funcionamento, o cluster possui um servidor líder e os demais ficam no estado follower.
Agora, o que é um term?
Um term é um tempo lógico, ele começa todas as vezes que existe uma eleição de um líder. Esse term fica válido enquanto esse líder estiver em operação. Caso ocorra algum problema com esse líder e é preciso iniciar uma nova eleição então inicia-se um novo term.
Veja que pode acontecer de uma eleição não ter um vencedor (na figura acima isso aconteceu no term 3), nesse caso inicia-se uma nova eleição e um novo term.
Cada servidor do cluster armazena o term atual. Todos os servidores ativos do cluster precisam estar no mesmo term.
E aqui finalizamos o primeiro dos 3 artigos. Explicamos o conceito básico de um protocolo de consenso, apresentamos o raft e entendemos a replicação da máquina de estado, quais são os estados que um servidor pode estar e o que é um term (relógio lógico).
No artigo 2 (https://medium.com/@mclortizz/f12e48fd962e), vamos entender um pouco mais sobre o raft, nomeadamente: mecanismo de eleição, de replicação de log e de segurança de consenso para a mudanças de configuração do cluster (adição ou remoção de membros).
No artigo 3 (https://medium.com/@mclortizz/o-que-%C3%A9-protocolo-de-consenso-raft-e-etcd-parte-3-4ece5d158e9e) entraremos no etcd e demonstraremos com isso funciona na prática (em um cluster de etcd na AWS).
Obrigado por ter chego até aqui e até breve.
Marcelo Ortiz, Engenheiro da Computação, mestrando em Ciência da Computação.
