A recuperac¸˜ao de estado num servic¸o BFT ´e parte fundamental da concepc¸˜ao deste tipo de servic¸os, sendo portanto largamente discutido [2, 9, 11, 12, 20, 27].
Nesta secc¸˜ao v˜ao ser apresentados os protocolos de recuperac¸˜ao de estado que per- mitem ao DDS recuperar o seu estado ap´os a ocorrˆencia de falhas parciais e tamb´em de falhas totais.
3.3.1
Transferˆencia de estado
Na ocorrˆencia de uma falha parcial, em que apenas f r´eplicas falham, estas r´eplicas po- dem recuperar os seus estados a partir das restantes r´eplicas que se tenham mantido em funcionamento e com o estado consistente.
Quando uma r´eplica recupera de uma falha, pede o estado a uma das r´eplicas que se manteve em funcionamento e pede ainda os hashes dos estados das restantes r´eplicas para conseguir validar o estado recebido.
Esta recuperac¸˜ao de estado a partir de outras r´eplicas faz parte dos protocolos ofere- cidos pela biblioteca BFT-SMaRt [41], pelo que n˜ao ser˜ao dados mais detalhes quanto `a implementac¸˜ao desta transferˆencia de estados.
3.3.2
Sincronizac¸˜ao de estados iniciais
Em caso de falha total, onde todas as r´eplicas param de funcionar (p.ex., devido a uma falha de energia), o sistema tem de ser capaz de reiniciar e reconstruir todo o estado anterior `a falha.
Apesar de ser de extrema importˆancia, apenas o servic¸o de coordenac¸˜ao Sinfonia [2] faz referˆencia a um protocolo capaz de recuperar o sistema deste tipo de falhas. O proto- colo mencionado faz uso de uma r´eplica de gest˜ao do sistema, respons´avel por iniciar a troca de estados entre as r´eplicas reiniciadas, o que pode ser um ponto ´unico de falha do protocolo, j´a que esta r´eplica pode tamb´em falhar e comprometer assim a transferˆencia de estados e a garantia de durabilidade dos dados. O DDS evita este ponto ´unico de fa- lha usando uma troca de mensagens entre as r´eplicas ao inv´es de uma r´eplica que faz a comunicac¸˜ao entre elas.
Existem n = 3f + 1 r´eplicas do servic¸o, das quais apenas f podem apresentar estado persistente inv´alido (p.ex., por ter os seus ficheiros de logs e checkpoints corrompidos antes da falha total). Durante a execuc¸˜ao do protocolo, se uma r´eplica enviar informac¸˜ao
Cap´ıtulo 3. DDS – Durable DepSpace 30
incorrecta, isso pode bloquear a execuc¸˜ao do protocolo, levando a que as r´eplicas reini- ciem e voltem a tentar sincronizar-se. Por essa raz˜ao, o protocolo executa entre 3 e 3 + f rondas, onde as r´eplicas trocam mensagens entre si. Estas f rondas adicionais correspon- dem a uma ronda por cada r´eplica que contenha algum estado corrompido. Este estado ter´a de ser recuperado por inteiro atrav´es da transferˆencia dos estados das n − f r´eplicas que contˆem o estado correcto.
O protocolo de sincronizac¸˜ao est´a dividido em dois algoritmos (descoberta do estado iniciale transferˆencia e instalac¸˜ao do estado), descritos a seguir.
O algoritmo de descoberta do estado inicial processa-se da seguinte forma:
1. Uma r´eplica reinicia e envia uma mensagem `as restantes r´eplicas com o formato hREINIT, id, last log eidi, onde id corresponde ao identificador da r´eplica e last log eid ao n´umero de sequˆencia da ´ultima operac¸˜ao do seu log;
• Ao receber esta mensagem, uma r´eplica guarda o last log eid da mensagem e, caso o seu id seja superior ao da mensagem, responde com uma mensagem semelhante, com os seus id e last log eid;
• Se for a ´unica r´eplica a reiniciar:
– Se as restantes r´eplicas n˜ao falharam, a r´eplica n˜ao vai obter qualquer resposta, pelo que o protocolo de transferˆencia de estados ´e activado (ver secc¸˜ao 3.3.1);
– Se as restantes r´eplicas falharam, a r´eplica espera que elas reiniciem e lhe enviem uma mensagem igual `a descrita anteriormente.
2. Caso receba 3f mensagens de r´eplicas diferentes, a r´eplica ordena todos os last log eids recebidos por ordem decrescente e escolhe o (f + 1)-´esimo last log eid como last commited eid;
• Como os last log eids est˜ao ordenados por ordem decrescente, o (f + 1)- ´esimo corresponde ao last log eid que f + 1 r´eplicas receberam e guardaram nos seus respectivos logs;
3. A r´eplica envia para todas as restantes uma mensagem com o formato hSTATE, id,
ckp, logi, onde id corresponde ao identificador da r´eplica e ckp ao hash do es- tado recuperado do seu checkpoint e log ao hash das last commited eid operac¸˜oes recuperadas do seu log;
4. Na presenc¸a de pelo menos f + 1 hashes semelhantes de checkpoints e de logs, a r´eplica verifica se estes hashes coincidem com o seus;
(a) Caso coincidam, a r´eplica instala o seu ckp e as last commited eid operac¸˜oes do seu log;
Cap´ıtulo 3. DDS – Durable DepSpace 31
(b) Caso contr´ario precisa de obter o estado das restantes r´eplicas (executando o algoritmo descrito a seguir);
5. Caso n˜ao existam f +1 hashes semelhantes de checkpoints e de logs, significa que o estado da r´eplica que tem o last log eid escolhido n˜ao ´e correcto, pelo o protocolo remove a r´eplica com o estado incorrecto e volta ao passo 1;
O algoritmo de transferˆencia e instalac¸˜ao do estado funciona da seguinte forma: 1. Caso se verifique o passo 4b do algoritmo anterior, a obtenc¸˜ao do estado das restan-
tes r´eplicas pode processar-se de trˆes formas diferentes:
• Apenas o hash do checkpoint da r´eplica difere dos restantes: a r´eplica envia uma mensagem com o formato hGET CKP, idi a uma r´eplica escolhida aleato- riamente de entre as que possuem o hash do checkpoint correcto;
• Apenas o hash do log da r´eplica difere dos restantes: a r´eplica envia uma men- sagem com o formato hGET LOG, idi a uma r´eplica escolhida aleatoriamente de entre as que possuem o hash do log correcto;
• Ambos os hashes diferem: a r´eplica envia uma mensagem com o formato hGET ALL STATE, idi a uma r´eplica escolhida aleatoriamente de entre as que possuem os hashes do log e do checkpoint correctos.
2. Em resposta a estas mensagens, as restantes r´eplicas respondem com:
• Uma mensagem com o formato hCKP STATE, id, ckpi, onde ckp ´e o estado contido no seu ficheiro de checkpoint;
• Uma mensagem com o formato hLOG STATE, id, logi, onde log ´e o estado
contido no seu ficheiro de log;
• Uma mensagem com o formato hALL STATE, id, ckp, logi, contento o estado de ambos os ficheiros log e checkpoint.
3. Ao receber a resposta, a r´eplica verifica cria o hash do estado contido na mensagem e verifica se coincide com os hashes recebidos anteriormente;
• Caso coincida, a r´eplica instala o estado;
• Caso contr´ario, a r´eplica escolhe outra r´eplica de entre as que possuem os hashescorrectos e repete o pedido de estado;
4. Para finalizar, todas as r´eplicas criam um novo checkpoint do seu estado.
No final do protocolo, todas as r´eplicas possuem o estado confirmado do sistema an- tes da falha total ocorrer (i.e., todas as operac¸˜oes dos clientes que obtiveram respostas est˜ao nesse estado), podendo comec¸ar a executar operac¸˜oes de clientes como se fossem as primeiras operac¸˜oes a serem recebidas (do ponto de vista da biblioteca de replicac¸˜ao).
Cap´ıtulo 3. DDS – Durable DepSpace 32