ARIES - Durabilidade de dados e recuperac¸˜ao de estado

2.3 Durabilidade de dados e recuperac¸˜ao de estado

2.3.2 ARIES

No anos 90, Mohan et al. apresentaram o ARIES [27], um método eficiente de recuperação de transacções que suporta retrocessos parciais ou totais de transacções. Este método garante as propriedades ACID [19] das transacções, mesmo na existência de falhas nos processos, transacções ou no sistema.

Como foi referido, as transacções podem ser parcialmente retrocedidas até a um save- pointpreviamente efectuado, assegurando a propriedade de atomicidade. Este retrocesso significa que todas as alterações efectuadas desde então são descartadas e a transacção continua a sua execução com os valores que tinha no savepoint.

O ARIES utiliza um mecanismo de write-ahead logging, tal como o Chubby [11] e, à semelhança da maioria dos serviços e protocolos referidos nas secções anteriores, executa batches de operações numa só operação de I/O. Os logs criados contêm operações de retrocesso e de reparação das transacções efectuadas.

Cap´ıtulo 2. Trabalhos relacionados 20

Para reduzir o trabalho efectuado durante a recuperação, o algoritmo também cria checkpointsperiódicos dos logs do sistema. Estes checkpoints consistem em gravar duas tabelas no log: a tabela de páginas sujas (a DPT), que mantém o registo de todos os dados modificados que ainda não estão armazenados fisicamente; e a tabela de transacções (a TT), que mantém o registo de todas as transacções que estão em execução.

O ARIES propõe a recuperação de processos divida em três fases: a análise, a fase de recuperação e a de retrocesso. A fase de análise consiste na recuperação do conteúdo das tabelas DPT e TT, de forma a recuperar todas as transacções incompletas no momento da ocorrência da falha. A fase de recuperação executa o paradigma de repetição do histórico, ou seja, são efectuadas todas as alterações pendentes que fazem as transacções incompletas avançarem na sua execução. Finalmente, a fase de retrocesso faz com que todas as operações que não terminaram sejam retrocedidas. Nesta fase, o algoritmo escreve no log todas as alterações efectuadas, para que estas não se repitam no caso de existirem múltiplos rein´ıcios do processo.

O processo de recuperação tem de levar os processos a manterem um estado con- sistente e ainda assegurar a atomicidade e durabilidade das transacções efectuadas. A disponibilidade do sistema tem também de ser assegurada pelo processo, pelo que deve executar o menor espaço de tempo poss´ıvel.

2.3.3 Gaios

Como já referido, o Paxos [23] é um protocolo importante para a implementação da replicação de máquinas de estados [37]. Apesar disso, é considerado um protocolo com um baixo desempenho.

Para contradizer isso, Bolosky et al. criaram o sistema Gaios [9], que oferece um serviço de armazenamento de dados constru´ıdo sobre a SMARTER, uma versão melho- rada da biblioteca SMART [25] (que é baseada no Paxos; não confundir com a BFT- SMaRt [41]). A SMARTER foi desenhada para oferecer métodos de armazenamento de grupos de operações e para melhorar o esquema de logging da SMART, reduzindo a latência das operações.

Tratando-se de um serviço de armazenamento de dados, o Gaios tem de ser o mais eficiente poss´ıvel. Porém, as máquinas de estados apenas executam uma operação por ronda, enquanto os discos r´ıgidos são mais eficientes na presença de múltiplas operações de escritas, que podem ser reordenadas de forma a minimizar o movimento do braço do disco. O Gaios implementa soluções diferentes para operações de leitura e de escrita. Na presença de operações de escrita, as modificações apenas são escritas para a memória cachedo sistema. Mais tarde, na criação de um checkpoint, os dados em memória são reordenados para serem escritos em disco. Depois de reordenados, os dados são escritos para disco em grupos, para minimizar o movimento do braço do disco.

Cap´ıtulo 2. Trabalhos relacionados 21

escritas nos logs. O sistema tenta escolher as réplicas que não estão a criar checkpoints para processar estas operações, para que as operações não sejam adicionadas à fila de operações pendentes. Isto permite melhorar o desempenho das operações de leitura.

Em termos de tolerância a faltas, o Gaios não é um serviço BFT, já que apenas detecta um conjunto de faltas bizantinas simples, relacionadas com a corrupção de dados em disco, transformando-as em faltas por paragem e obrigando as réplicas a reiniciar. As réplicas do serviço são ainda protegidas por medidas de segurança externas, para que não sejam comprometidas por agentes maliciosos. Este modelo de tolerância a faltas é justificado pelo maior número de réplicas utilizadas em serviços BFT (3f + 1) em comparação com as 2f + 1 requeridas pelo Paxos.

Para testar o desempenho do Gaios, compararam-no a três sistemas diferentes: um disco de uma máquina e duas versões de um sistema com replicação primário-secundário [10]. Os autores dizem que o seu sistema apresentou resultados próximos dos resultados dos seus concorrentes. Desta forma conseguiram alcançar o seu objectivo de constru´ırem um sistema baseado no protocolo Paxos e que apresenta um bom desempenho.

2.3.4 Recuperac¸˜ao proactiva

Em [12], Castro e Liskov estenderam o protocolo PBFT (ver secção 2.1.1) com um protocolo de recuperação proactiva que permite ao sistema tolerar um qualquer número de faltas durante o seu per´ıodo de execução, desde que menos do que 1/3 das réplicas do sistema sejam faltosas numa determinada janela de vulnerabilidade.

A recuperação proactiva é usada para rejuvenescer periodicamente as réplicas de um serviço, eliminando os efeitos de ataques maliciosos ou falhas do sistema. O algoritmo reinicia periodicamente as réplicas, através do uso de temporizadores, independentemente de serem detectadas faltas ou não. Quando um temporizador expira, uma réplica guarda os seus estado e log no disco, reiniciando de seguida. Ao reiniciar, a réplica carrega o seu código correcto (removendo, por exemplo, qualquer código malicioso existente) e também o estado que guardou antes de reiniciar.

A réplica que está a reiniciar, descarta as chaves que partilha com os seus clientes e restantes réplicas, para prevenir que um atacante consiga personificar qualquer um deles. O passo seguinte consiste no envio de uma mensagem às restantes réplicas para determi- nar se o seu estado está corrompido ou inválido.

A transferência de estado que decorre após o envio desta mensagem tem de ser eficiente, de modo a permitir um grande número de recuperações de estado com pouco im- pacto no desempenho do protocolo. O processo de recuperação de estado é considerado completo quando as réplicas conseguem criar um checkpoint estável do estado global do sistema. Isto garante que o checkpoint criado está presente em, pelo menos, f + 1 réplicas correctas, conseguindo assim sobreviver a falhas de até f réplicas.

Cap´ıtulo 2. Trabalhos relacionados 22

2.4 Considerac¸˜oes finais

Neste cap´ıtulo apresentámos o conceito de serviços de coordenação, apresentando vários exemplos como o ZooKeeper e o DepSpace.

De seguida são apresentados vários protocolos de replicação CFT e BFT, utilizados na comunicação entre as réplicas dos serviços de coordenação, tal como o PBFT e o BFT-SMaRt.

Por último introduzimos algumas técnicas utilizadas para garantir a durabilidade dos dados em serviços de coordenação, tal como mecanismos de logging e de armazenamento estável. Estas técnicas são o foco principal do desta dissertação, que irá descrever a forma como foram optimizadas e implementadas na construção de um serviço baseado no DepSpace.

Cap´ıtulo 3

DDS – Durable DepSpace

Este cap´ıtulo apresenta e descreve o trabalho efectuado na construção do serviço de coordenação DDS (Durable DepSpace), nomeadamente a arquitectura do DDS, a durabilidade de dados no DDS, o modelo de dados utilizado e ainda o protocolo de sincronização inicial de estados das réplicas do serviço.

3.1 Arquitectura

O DDS tem como base o DepSpace [5], um serviço de coordenação BFT que oferece uma abstracção de espaços de tuplos para a coordenação de processos. O modelo de coordenação baseado em espaços de tuplos foi introduzido pela linguagem de programação Linda [17]. Este modelo suporta comunicação desacoplada no tempo e no espaço: os processos clientes não necessitam de estar activos no mesmo instante de tempo nem de conhe- cer a localização ou endereços dos restantes processos para ser poss´ıvel sincronizarem-se. Um espaço de tuplos, como o próprio nome indica, consiste num conjunto de tuplos. Um tuplo pode ser definido como uma sequência finita de atributos. Estes atributos são independentes entre si e podem assumir, por exemplo, valores numéricos e sequências de bytes. As operações suportadas pelos espaços de tuplos são basicamente as de escrita, leitura e remoção de tuplos, existindo ainda diversas variantes destas.

Assim como o DepSpace, o DDS suporta a existência de diversos espaços de tuplos em simultâneo e é constitu´ıdo por diversas camadas, encarregues de garantir as suas propriedades (ver figura 3.1). A camada mais complexa é a de replicação, que é concretizada pela biblioteca BFT-SMaRt [41]. As camadas de controlo de acesso, pol´ıticas de acesso e confidencialidade garantem que os tuplos armazenados são acedidos apenas por processos que tenham permissão para o fazer. Não são fornecidos aqui mais detalhes sobre essas camadas dado serem semelhantes às do DepSpace (ver secção 2.2.4).

O DDS vem adicionar três componentes à arquitectura original do DepSpace [5]: Du- rability Manager (DM), Logging e Checkpointing (cf. figura 3.1). Os componentes de logginge de checkpointing são responsáveis pela criação dos ficheiros de log e de check-

Cap´ıtulo 3. DDS – Durable DepSpace 24

point, respectivamente. Estão ainda encarregues da gestão desses ficheiros, bem como das suas actualizações. O DM é a camada que faz a comunicação entre a biblioteca de replicação e as camadas de logging, de checkpointing e os espaços de tuplos, encami- nhando as mensagens recebidas para as camadas adjacentes. Esta camada está também encarregue de executar o protocolo de transferência de estado entre as réplicas.

No DDS foi introduzida a execução de batches de pedidos de clientes. Este mecanismo possibilita a entrega de um conjunto, ou batch, de mensagens à aplicação, em vez de ser entregue uma mensagem de cada vez, fazendo com que a fila de mensagens à espera de serem executadas esvazie mais rapidamente. Uma das tarefa realizada pelo Durability Manager é a de dividir um batch de mensagens em batches menores, cada um contendo as mensagens relativas a um dos espaços de tuplos. Estes batches são depois entregues em paralelo a todos os espaços de tuplos de destino, que processam as mensagens e devol- vem as respostas pela mesma ordem pela qual receberam as mensagens. Esta ordenação é importante na medida em que os clientes necessitam de receber as respostas pela ordem em que enviaram as suas mensagens.

Figura 3.1: Arquitectura do DDS.

3.2 Durabilidade no DDS

3.2.1 Logging de mensagens

De forma a manter as operações dos clientes deste serviço em caso de falha, é necessário que estas sejam guardadas num local que ofereça boas garantias de durabilidade. No caso do DDS, consideramos que os discos das réplicas oferecem tais garantias. Foi então desenvolvida uma camada de logging que, como mostra a figura 3.2, apenas faz logging

Cap´ıtulo 3. DDS – Durable DepSpace 25

das operações que alteram o estado do sistema. O facto de não efectuarem qualquer modificação no estado do sistema faz com que seja desnecessário fazer o logging das operações como a leitura de tuplos (operação rdp).

Figura 3.2: Execução de operações, ordenadas e não ordenadas, no DDS.

Na inicialização de uma réplica, e no caso do logging de mensagens estar activo, a camada de logging é responsável pela criação dos ficheiros de log. Normalmente, operações de escrita para disco são mantidas em buffers internos de modo a melhorar a sua eficiência [40, p. 514]. Quando uma aplicação cliente quer escrever dados para um ficheiro guar- dado em disco, faz uma chamada ao kernel do sistema operativo para efectuar tal escrita (operações de escrita para disco são operações privilegiadas, sendo o kernel o único a poder executá-las) [40, p. 515]. O kernel verifica se a região do ficheiro pedida está dis- pon´ıvel em memória. Se estiver, a operação de escrita para o disco f´ısico é adiada, caso contrário a operação é guardada em memória para permitir largas transferências de dados para disco [40, p. 414].

Para assegurarmos que as actualizações ao ficheiro de log são escritas para disco, não podemos utilizar estas escritas que retêm os dados em memória porque pode dar-se uma falha numa réplica antes do sistema operativo dessa réplica conseguir armazenar os dados, que estão em memória, no disco. Isto significa que se o DDS entregar o resultado de uma operação ao cliente e depois perder as alterações feitas por essa operação, não existe qualquer garantia de que essas alterações sobrevivam no futuro. Precisamos então de fazer com que as escritas de disco sejam directamente enviadas para disco sem que sejam mantidas em memória pelo sistema operativo. Para isso utilizamos a classe Rando- mAccessFile[31] do Java. A criação de um objecto desta classe permite o acesso a um

Cap´ıtulo 3. DDS – Durable DepSpace 26

ficheiro num destes quatro modos:

r: Abre o ficheiro apenas para leitura;

rw: Abre o ficheiro para escrita e leitura;

rws: Semelhante ao modo “rw”, mas faz com que todas as actualizações ao conteúdo e os metadados do ficheiro sejam escritas sincronamente para o dispositivo de armazenamento;

rwd: Semelhante ao modo “rw”, mas faz com que todas as actualizações ao conteúdo do ficheiro apenas sejam escritas sincronamente para o dispositivo de armazenamento.

O modo “r” não nos é útil, pois apenas permite o acesso para leitura e nós precisamos de escrever no ficheiro. O modo “rw” entrega os dados ao sistema operativo que, como já foi discutido, os armazena em memória. Os únicos modos que forçam as escritas para disco são os modos “rws” e “rwd”. O que difere nestes dois modos é o facto de o primeiro, para além de forçar as actualizações ao conteúdo, força também as actualizações aos metadados do ficheiro (informação adicional sobre o ficheiro, como por exemplo o seu tamanho, data da última modificação e permissões de acesso), enquanto o primeiro força apenas as actualizações ao conteúdo. A única condição imposta pelo utilização de um RandomAccessFile é a presença do ficheiro de destino no disco local (e não num sistema de ficheiros distribu´ıdo, por exemplo). Caso esta condição não se verifique, não é garantido que as actualizações ao ficheiro surtam efeito.

Para além de forçar as escritas para disco, foi ainda utilizada a pré-alocação do ficheiro de log. A pré-alocação do ficheiro em disco permite definir antecipadamente um dado número de bytes em disco, que ficam reservados à escrita do ficheiro, diminuindo a latência das escritas para o ficheiro que não façam o ficheiro aumentar para lá do número de bytes pré-alocados. Assim, as escritas para ficheiro serão mais rápidas, dado não ser necessário alocar recursos antes de cada escrita. No cap´ıtulo 4, apresentamos resultados que justificam a escolha do modo “rwd” na escrita dos ficheiros utilizados no DDS.

Grupos de mensagens. Com o aumento do número de clientes, o número de mensagens no serviço também aumenta, fazendo com que o processamento de apenas uma mensagem aumente a latência de cada operação. O processamento de um grupo, ou batch, de mensagens permite ao DDS responder de uma só vez a várias mensagens que se encon- trem pendentes, diminuindo assim a latência de cada operação e aumentando débito do sistema.

No entanto, as escritas para disco impõem sempre uma latência adicional no serviço, por muito pequena que seja. A escrita de grupos de operações para disco reduziria essa latência, pois a latência da escrita simultânea de várias operações será inferior à da escrita

Cap´ıtulo 3. DDS – Durable DepSpace 27

alternada das mesmas. Com estes resultados podemos então optimizar o DDS para escrever grupos de mensagens em simultâneo para disco, ao invés de uma mensagem de cada vez, de forma a aumentar o débito do sistema. Assim, quando o nosso serviço recebe um grupo de mensagens, executa todas as operações contidas nessas mensagens e em seguida escreve para disco todas as operações de uma vez só.

Logging paralelo. As escritas das operações do DDS para os discos das réplicas impõem uma latência adicional na execução das operações, o que afecta o desempenho do sistema. Como a latência de um grupo de mensagens dentro do sistema (lat batch) é defi- nida pela latência da sua execução (lat exec) somada à latência da sua escrita para disco (lat write), temos então de diminuir lat write de forma a não atrasar em demasia a entrega de respostas aos clientes.

Para isso, paralelizámos as escritas para disco e a execução de operações, o que dimi- nui lat batch para max(lat exec, lat log), como pode ser observado na figura 3.3. Note que a eficiência deste método depende de lat log ≈ lat exec, o que requer batches de muitas mensagens, já que lat exec cresce linearmente com o tamanho do batch e lat log varia menos com o aumento do tamanho do batch. Esta optimização permite garantir a durabilidade dos dados armazenados no DDS com um débito muito melhor do que o conseguido com o logging não paralelo, como poderemos observar no cap´ıtulo 4.

Figura 3.3: Logging de operações s´ıncrono (à esquerda) e paralelo (à direita).

3.2.2 Checkpointing

Como já referido, os ficheiros de checkpoint são criados de modo a limitar o crescimento dos ficheiros de log. Enquanto os ficheiros de log contêm as operações enviadas pelos clientes, o ficheiros de checkpoint contêm o estado do sistema no momento em que são criados. Isto significa que, no momento da criação de um checkpoint, uma réplica pára de executar operações dos clientes e escreve o seu estado actual para o disco.

Para obter todo o estado actual do sistema, foi criada uma nova operação no DepSpace, a rdAll(), que devolve todos os tuplos presentes em todos os espaços de tuplos existentes. O novo checkpoint permite a remoção das operações do log que o antecedem, visto que o seu conteúdo reflecte as alterações no estado impostas por essas mesmas operações.

Cap´ıtulo 3. DDS – Durable DepSpace 28

No entanto, existe uma dificuldade na remoção do ficheiro de log. Por um lado, ele não pode ser removido antes da criação dos ficheiros de checkpoint, pois a existência de uma falha entre a remoção e a criação de ficheiros poderia levar a que os dados dos clientes se perdessem, contradizendo a propriedade de durabilidade. Por outro lado, não podem ser removidos depois, porque a ocorrência de uma falha após a criação do checkpoint levaria o sistema a recuperar e a assumir que o log é mais recente do que o checkpoint. Isto faria o sistema executar em primeiro lugar as operações no checkpoint, sobrepondo depois as operações presentes no log. Como os checkpoints contêm o estado presente no logque os antecede, a execução errada destes ficheiros levaria uma mesma operação a ser executada duas vezes. Como as operações do DDS não são idempotentes, ao contrário do

No documento Gestão de estado eficiente no serviço de coordenação DDS (páginas 39-48)