Armazenamento est´avel, checkpoints e logs

Tal como ´e mostrado da figura 2.7, a recuperac¸˜ao de estados pode ser feita de duas for- mas: para tr´as e para a frente. No primeiro caso, a recuperac¸˜ao ´e feita de forma a que o processo faltoso recupere para o ´ultimo estado correcto que conheceu antes de falhar. Para que isto acontec¸a, ´e necess´ario que o estado do sistema seja armazenado periodica- mente para que, na presenc¸a de falhas, seja poss´ıvel voltar a recuper´a-lo. Pelo contr´ario, na recuperac¸˜ao para a frente, um processo faltoso evolui para um novo estado correcto, de onde ´e seguro continuar a execuc¸˜ao normal do sistema. Aqui, o problema reside no facto de, para avanc¸ar para um novo estado, o sistema tem de conhecer todos os erros poss´ıveis de forma a conseguir corrigi-los.

Cap´ıtulo 2. Trabalhos relacionados 17

No geral, a recuperac¸˜ao para tr´as ´e a mais utilizada, apesar de o seu uso levantar al- guns problemas. Em primeiro lugar, ´e uma operac¸˜ao cara em termos de desempenho do sistema, devido ao uso de mecanismos de logging e checkpointing, que ser˜ao discutidos de seguida. Em segundo lugar, n˜ao nos garante que uma falta n˜ao se repetir´a no futuro. Finalmente, existem estados para o quais n˜ao ´e poss´ıvel recuperar. Por exemplo, na mai- oria dos sistemas UNIX, ´e muito pouco prov´avel conseguir-se recuperar para um estado anterior `a execuc¸˜ao da operac¸˜ao rm -fr * (remoc¸˜ao de todo o conte´udo de uma directoria).

Armazenamento est´avel. O armazenamento est´avel consiste em guardar dados no local que oferec¸a boas garantias de que esses dados permanecer˜ao intactos em caso de falha. Este armazenamento ´e de extrema importˆancia no ˆambito da recuperac¸˜ao de processos faltosos, dado que o estado de um sistema precisa de ser armazenado de forma a sobrevi- ver a paragem ou falha de processos. Tamb´em ´e importante que esse estado sobreviva a falhas o local onde ´e armazenado (p.ex., disco r´ıgido) [29, 44].

Existem trˆes tipos de armazenamento: em mem´oria RAM, em disco, ou armazena- mento est´avel. O problema da mem´oria RAM ´e que ´e apagada em caso de falha de energia ou paragem da m´aquina. O armazenamento em disco sobrevive a falhas da m´aquina mas n˜ao sobrevive a falhas no disco em si.

O armazenamento est´avel foi desenhado para sobreviver a quase qualquer falha, ex- cepto a desastres naturais de grande escala, como inundac¸˜oes e terramotos, e ´e bom para aplicac¸˜oes que requeiram um alto n´ıvel de tolerˆancia a faltas, tal como as transacc¸˜oes at´omicas, devido `a m´ınima probabilidade de perda de dados nas operac¸˜oes de escrita.

Este ´ultimo pode ser implementado com um par de discos r´ıgidos ligados, digamos Disco1 e Disco2. O Disco2 serve de backup do Disco1, sendo que uma modificac¸˜ao dos dados ´e efectuada em primeiro lugar no Disco1, os dados s˜ao verificados e s˜ao finalmente guardados no Disco2. No caso de os discos terem blocos com diferentes valores, pode-se assumir que os do Disco1 s˜ao os correctos, j´a que foi o primeiro a ser modificado. Os blocos do Disco1 podem ent˜ao ser copiados para o Disco2 para que, quando o processo de recuperac¸˜ao iniciar, os discos estejam idˆenticos.

Este tipo de armazenamento ´e bom para aplicac¸˜oes que requeiram um alto n´ıvel de tolerˆancia a faltas, tal como as transacc¸˜oes at´omicas, devido `a m´ınima probabilidade de perda de dados nas operac¸˜oes de escrita.

Checkpoints. O checkpointing consiste em criar uma c´opia do estado actual do sistema e grav´a-la para um local seguro. Esta t´ecnica ´e a mais utilizada na recuperac¸˜ao para tr´as, j´a que permite o armazenamento est´avel peri´odico do estado do sistema [44]. Este estado do sistema ´e global e consistente em todos os processos, sendo denominado de snapshot. Aquando uma recuperac¸˜ao, os processos devem recuperar a snapshot mais recente, sendo que esta define a linha de recuperac¸˜ao do sistema. No entanto, encontrar a linha de

Cap´ıtulo 2. Trabalhos relacionados 18

recuperac¸˜ao pode n˜ao ser simples usando apenas checkpoints. Para o fazer, cada processo tem de retroceder o seu estado at´e ao checkpoint mais recente e, caso o estado recuperado desse checkpoint n˜ao forme uma snapshot distribu´ıda, os processos ter˜ao de retroceder ainda mais, at´e que isso acontec¸a.

Caso os checkpoints efectuados sejam independentes, i.e., se os processos realiza- rem os seus checkpoints locais e independentemente dos restantes, o c´alculo da linha de recuperac¸˜ao torna-se ainda mais complexo. Para al´em disso, tem de existir tamb´em um garbage collectorque limpa periodicamente o armazenamento local de cada processo, `a medida que o n´umero de checkpoints guardados aumenta.

Para resolver os problemas dos checkpoints independentes, ´e preciso coorden´a-los en- tre os processos. Isto significa que todos os processos sincronizam as suas escritas para o local de armazenamento, mantendo o estado gravado consistente. Uma soluc¸˜ao simples para implementar estes checkpoints coordenados ´e um protocolo de commit de duas fases e bloqueante. Um processo coordenador envia uma mensagem CHECKPOINT REQUEST

a todos os restantes processos. Ao receberem essa mensagem, criam um checkpoint local e guardam quaisquer operac¸˜oes posteriores para mais tarde serem executadas, ou seja, bloqueiam a sua execuc¸˜ao. Depois, confirmam com o processo coordenador que j´a efec- tuaram o checkpoint. Quando o coordenador recebe todas as confirmac¸˜oes, envia uma mensagem CHECKPOINT DONE a todos os restantes processos que estejam bloqueados, para que estes possam continuar a execuc¸˜ao de operac¸˜oes.

Muitos sistemas distribu´ıdos BFT combinam checkpoints com logging de mensagens. Um processo poderia tamb´em fazer um log das mensagens que recebe (logging baseado no receptor), antes de as entregar `a aplicac¸˜ao. Na reproduc¸˜ao do estado, cada processo retrocede para o checkpoint mais recente e reproduz o log de mensagens pela respectiva ordem. Isto garante a reproduc¸˜ao dos eventos que ocorreram ap´os a criac¸˜ao do checkpoint mais recente.

Logging de mensagens. A ideia do logging de mensagens ´e que, se a transmiss˜ao de mensagens pode ser repetida, ent˜ao conseguimos atingir um estado globalmente consis- tente sem que seja necess´ario carreg´a-lo do local de armazenamento. Em vez disso, um checkpointpreviamente armazenado ´e considerado um ponto de partida e todas as mensa- gens trocadas ap´os esse checkpoint s˜ao simplesmente retransmitidas e reprocessadas [44]. Esta abordagem funciona bem assumindo um modelo determin´ıstico, em que os processos executam eventos n˜ao deterministas (p.ex., recepc¸˜ao de mensagens), deterministicamente. Existem duas formas de logging poss´ıveis: pessimista e optimista. Os protocolos de logging pessimista asseguram que cada mensagem n˜ao est´avel m ´e entregue a um pro- cesso P , no m´aximo uma vez. As mensagens s˜ao consideradas est´aveis quando s˜ao guar- dadas de forma a que n˜ao se percam (p.ex., s˜ao escritas para o armazenamento est´avel). No pior cen´ario, o processo P falha sem ter armazenado m. Para lidar com este cen´ario, o

Cap´ıtulo 2. Trabalhos relacionados 19

loggingpessimista faz com que P armazene m antes de enviar qualquer outra mensagem, para evitar inconsistˆencias no estado entre processos correctos e faltosos.

Figura 2.8: Logging optimista [44].

Pelo contr´ario, os protocolos de logging optimista, permitem que o processo R envie m2 antes de a armazenar num local seguro (ver figura 2.8). Isto significa que, ap´os a falha de Q e a sua respectiva recuperac¸˜ao, R n˜ao reenvia m2 a Q, fazendo com que este processo n˜ao re-execute m2 e reenvie m3. Esta situac¸˜ao deixa o sistema num estado inconsistente.

Para evitar esta inconsistˆencia, os protocolos de logging optimista fazem com que os processos correctos que dependem dos processos que falharam (R depende de Q na recepc¸˜ao de m3), retrocedam para um estado onde a inconsistˆencia deixe de se verificar. No caso da figura 2.8, R recuaria at´e ao momento anterior `a recepc¸˜ao de m1 e voltaria a executar m1, seguindo-se o envio de m2 que levaria `a recepc¸˜ao de m3.

Os protocolos de logging optimista s˜ao mais complexos e portanto mais dif´ıceis de implementar, sendo os protocolos de logging pessimista os mais utilizados na pr´atica.