Gestão de estado eficiente no serviço de coordenação DDS

(1)

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciˆencias

Departamento de Inform´atica

GEST ˜

AO DE ESTADO EFICIENTE NO

SERVIC

¸ O DE COORDENAC

¸ ˜

AO DDS

Jo˜ao Lu´ıs Monteiro F´elix

DISSERTAC

¸ ˜

AO

MESTRADO EM INFORM ´

ATICA

(2)

(3)

U

NIVERSIDADE DE

L

ISBOA

Faculdade de Ciˆencias

Departamento de Inform´atica

GEST ˜

AO DE ESTADO EFICIENTE NO

SERVIC

¸ O DE COORDENAC

¸ ˜

AO DDS

Jo˜ao Lu´ıs Monteiro F´elix

DISSERTAC

¸ ˜

AO

Projecto orientado pelo Prof. Doutor Alysson Neves Bessani e co-orientado pelo Prof. Doutor Miguel Pupo Correia

MESTRADO EM INFORM ´

ATICA

(4)

(5)

Agradecimentos

Começo por agradecer aos meus orientadores, Alysson Bessani e Miguel Correia. Por vezes foi complicado ver que os meus esforços não estavam a produzir os resultados desejados, mas mesmo assim deram-me sempre força e ânimo para continuar a trabalhar. Um muit´ıssimo obrigado a eles os dois, pois sem eles este trabalho não teria sido poss´ıvel. Um muito obrigado a todos os meus amigos, nomeadamente à Sofia, Andreia, Carme-lita, Miguel Pedras, Filipe, Marina, Mafalda Gomes, Marta Carvalho, Diogo Carvalho, V´ıtor Oliveira, e Rui Pires por todos estes bons anos de convivência e de grandes aven-turas e mudanças. Um especial obrigado ao Bruno Pombeiro por todas aquelas noitadas de muito trabalho e por todo o esforço, amizade e dedicação no decorrer destes 5 anos. Também agradeço imenso ao Miguel Garcia pelas discussões, pelos conselhos e pela sua experiência e trocas de ideias que deram sempre muito jeito. Quero agradecer também a todos os meus colegas investigadores dos Navigators, que se mostraram sempre dis-pon´ıveis a ajudar quando e no que foi preciso.

Em último lugar, não poderia deixar de agradecer à minha querida Mafalda, pelo seu amor, amizade, pela confiança e inspiração que me transmite e por me fazer sorrir todos os dias.

Como filho que sou, quero naturalmente agradecer aos meus pais por tudo o que sem-pre fizeram por mim. Obrigado pela educação que me deram, pelos sacrif´ıcios que eu sei que fizeram para que nunca me faltasse nada. A verdade é que conseguiram atin-gir esse objectivo e estou-vos eternamente gratos pela qualidade de vida que sempre me proporcionaram.

E como uma fam´ılia tem mais membros para além dos pais, um muito obrigado à minha querida avó “Bá” por toda a sua energia, positivismo, imensa sabedoria e invulgar, mas muito apreciada mundialmente, habilidade culinária. Não posso agradecer aqui à fam´ılia toda membro a membro, por isso, um muito obrigado a todos os outros, em espe-cial à minha prima Saeda e à minha tia Beatriz. A secção familiar dos agradecimentos é conclu´ıda com um imenso obrigado à fam´ılia Bernardo, que me albergou durante os meus primeiros dias de mudança para Lisboa e sempre se preocuparam comigo.

Um muito obrigado `a FCT, que financiou este projecto e acreditou no seu valor para a comunidade cient´ıfica.

(6)

(7)

(8)

(9)

Resumo

Durante alguns anos, os serviços de coordenação utilizaram protocolos de replicação de informação entre as suas réplicas que seguiram o modelo de faltas por paragem (crash). Assim, estes serviços toleravam até f faltas simultâneas de réplicas, desde que fosse ga-rantido que um conjunto de f +1 réplicas continuavam o seu bom funcionamento. Porém, este modelo é simples de quebrar porque apenas considera que uma réplica apresenta um estado incorrecto se esta deixar de participar no protocolo.

Mais tarde, surgiram os primeiros serviços a seguir o modelo de faltas arbitrárias, ou bizantinas. Este novo modelo sugere a adopção de 3f +1 réplicas para que se possa tolerar até f réplicas faltosas. Para além disso, o serviço precisa ainda de manter a durabilidade dos seus dados, para ser poss´ıvel recuperar de falhas gerais, i.e., de falhas que afectam todas as réplicas do serviço.

Existem já serviços que garantem essa durabilidade dos dados, à custa de perda de desempenho do sistema, pois uma operação tem ser escrita para um local seguro antes de ser enviada uma resposta ao cliente que a efectuou. Esta perda de desempenho afecta a disponibilidade e escalabilidade do sistema, pelo que deve ser minimizada através da optimização das técnicas que garantem a persistência dos dados.

Este projecto tem como objectivo melhorar o DepSpace com uma camada que garante a durabilidade dos dados sem que o desempenho do sistema seja afectado em demasia e ainda um protocolo de recuperação do estado do serviço, de forma a ser poss´ıvel recuperar de falhas gerais no sistema. O DepSpace é um sistema de coordenação tolerante a faltas arbitrárias baseado num espaço de tuplos, constru´ıdo no LaSIGE. A durabilidade dos dados vai ser garantida através de mecanismos como o logging de operações, aumentando a fiabilidade do sistema.

Palavras-chave: DepSpace, Tolerˆancia a faltas bizantinas, Durabilidade, Logging paralelo, Checkpoints.

(10)

(11)

Abstract

For many years, information services replicated information among their replicas us-ing crash fault tolerant (or CFT ) protocols. The CFT model makes those systems tolerate up to f replicas crash faults if at least f + 1 other replicas are alive to keep the service running. Nevertheless, it is simple to break these protocols and make more than f + 1 replicas crash simultaneously, making the service unavailable.

Some years later, the first services using a Byantine fault tolerant (or BFT ) model were created. Protocols that follow this model tolerate Byzantine, meaning arbitrary, faults. This new model requires at least 3f + 1 replicas to tolerate up to f Byzantine faults. Furthermore, BFT services need to guarantee their data durability, in order to provide methods to recover the system from total failures, where all the services’ replicas fail by crashing.

Some modern services already guarantee their data durability. However, in order to do that, they lose some performance due to the fact that an operation needs to be written to stable storage before it is committed to the client who performed it. This performance loss affects both the system’s availability and scalability, and that is why it should be reduced through the optimization of the durability techniques used to stable store the operations.

The goal of this project is to enhance the DepSpace service with a durability layer that enforces the clients’ operations to be stable stored without having much impact on the system’s performance and also with a recovery protocol that recovers the system from total failures. DepSpace is a coordination service built that tolerates Byzantine faults that was built in LaSIGE. The data durability is going to be guaranteed through the use of mechanisms such as operations logging, which increases the system reliability.

Keywords: DepSpace, Byzantine-fault tolerance, Durability, Parallel logging, Checkpoints.

(12)

(13)

Conte ´udo

Lista de Figuras xv

Lista de Tabelas xvii

1 Introdução 1 1.1 Motivação . . . 2 1.2 Objectivos . . . 2 1.3 Estrutura do documento . . . 3 2 Trabalhos relacionados 5 2.1 Replicação BFT . . . 5 2.1.1 PBFT . . . 6 2.1.2 UpRight . . . 8 2.1.3 BFT-SMaRt . . . 9 2.1.4 Outros protocolos BFT . . . 9 2.2 Serviços de coordenação . . . 10 2.2.1 Chubby . . . 11 2.2.2 Sinfonia . . . 12 2.2.3 ZooKeeper . . . 14 2.2.4 DepSpace . . . 16

2.3 Durabilidade de dados e recuperac¸˜ao de estado . . . 17

2.3.1 Armazenamento est´avel, checkpoints e logs . . . 18

2.3.2 ARIES . . . 22 2.3.3 Gaios . . . 22 2.3.4 Recuperação proactiva . . . 23 2.4 Considerações finais . . . 24 3 DDS – Durable DepSpace 25 3.1 Arquitectura . . . 25 3.2 Durabilidade no DDS . . . 26 3.2.1 Loggingde mensagens . . . 26 3.2.2 Checkpointing . . . 30 xi

(14)

3.2.3 Modelo de dados . . . 31

3.3 Gest˜ao de estado . . . 31

3.3.1 Transferˆencia de estado . . . 32

3.3.2 Sincronizac¸˜ao de estados iniciais . . . 32

3.4 Melhorias no DepSpace . . . 34

3.4.1 Paralelização de operações nos diversos espaços de tuplos . . . . 34

3.4.2 Optimização das operações de leitura e remoção de tuplos . . . . 35

3.4.3 Locking . . . 37

3.5 Considerac¸˜oes finais . . . 38

4 Avaliac¸˜ao 39 4.1 Ambiente experimental . . . 39

4.2 Custo do armazenamento em disco . . . 40

4.3 Microbenchmarkssem replicac¸˜ao . . . 42

4.3.1 Avaliação das concretizações do espaço de tuplos . . . 43

4.3.2 DDS vs DepSpace . . . 44

4.3.3 Logging& Checkpointing . . . 45

4.4 Desempenho do DDS . . . 46

4.4.1 100% de inserc¸˜oes de tuplos . . . 47

4.4.2 100% de remoc¸˜oes de tuplos . . . 48

4.4.3 100% de leituras de tuplos . . . 49

4.4.4 50% inserções e 50% remoções de tuplos . . . 49

4.4.5 80% leituras, 10% inserções e 10% remoções de tuplos . . . 51

4.5 Recuperação no DDS . . . 52 4.6 Considerações finais . . . 54 5 Conclusão 55 Abreviaturas 58 Bibliografia 62 Índice 63 xii

(15)

(16)

(17)

Lista de Figuras

2.1 Protocolo de trˆes fases do PBFT [24]. . . 7

2.2 Arquitectura da UpRight [13]. . . 8

2.3 Serviço de coordenação vs Serviço de comunicação em grupo [35]. . . 10

2.4 Arquitectura do Chubby [11]. . . 12

2.5 Arquitectura do Sinfonia [2]. . . 13

2.6 Execução de operações de escrita e de leitura no ZooKeeper [20]. . . 15

2.7 Recuperação para trás vs Recuperação para a frente. . . 18

2.8 Loggingoptimista [44]. . . 21

3.1 Arquitectura do DDS. . . 27

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

3.3 Loggingde operações s´ıncrono (à esquerda) e paralelo (à direita). . . 30

3.4 Execução s´ıncrona (à esquerda) e paralela (à direita) de operações nos diversos espaços de tuplos do DepSpace. . . 35

3.5 Espac¸o de tuplos com ´ındices. . . 36

4.1 Resultados das experiências no DepSpace e no DDS sem a camada de replicação. . . 45

4.2 Resultados das experiˆencias efectuadas com as camadas de logging e checkpointingdo DDS. . . 46

4.3 Resultados do DepSpace e do DDS com 100% de inserc¸˜oes de tuplos. . . 48

4.4 Resultados do DepSpace e do DDS com 100% de remoc¸˜oes de tuplos. . . 49

4.5 Resultados do DepSpace e do DDS com 100% de leituras de tuplos. . . . 50

4.6 Resultados do DepSpace e do DDS com 50% de inserções e 50% de remoções de tuplos. . . 50

4.7 Resultados do DepSpace e do DDS com 80% de leituras, 10% de inserções e 10% de remoções de tuplos. . . 51

4.8 Comparac¸˜ao dos resultados do DDS com moderate e extreme locking. . . 52

4.9 Latências das recuperações de estado do DDS. . . 53

(18)

(19)

Lista de Tabelas

4.1 Latência das escritas para o disco da Workstation. . . 41 4.2 Latência das escritas para o disco da Servidor. . . 41 4.3 Latências das operações out com o processamento de batches de

diferen-tes tamanhos no DepSpace e no DDS com diferendiferen-tes concretizações dos espaços de tuplos. . . 44 4.4 Latências das operações inp com o processamento de batches de

diferen-tes tamanhos no DepSpace e no DDS com diferendiferen-tes concretizações dos espaços de tuplos. . . 44

(20)

(21)

Cap´ıtulo 1

Introduc¸˜ao

Um sistema distribu´ıdo é composto por processos que comunicam através de uma rede. Estes processos podem comunicar entre si através de métodos como a troca expl´ıcita de mensagens ou o acesso a recursos partilhados. Para além de comunicarem, existem situações em que os processos precisam de se coordenar entre si, de forma a que, por exemplo, possam controlar o acesso a recursos partilhados (p.ex., através de exclusão mútua).

Um serviço de coordenação é um serviço que permite manter informações de con-trolo e configuração e realizar sincronização distribu´ıda em aplicações distribu´ıdas. Estes serviços apresentam uma forma de retirar ao programador a responsabilidade de coorde-nar os processos, dando espaço para que este se foque no desenvolvimento da aplicação propriamente dita, reduzindo consideravelmente o esforço e as linhas de código necessárias.

Existem diversos serviços de coordenação, comerciais, abertos e de investigação, como por exemplo o GigaSpace [18], ZooKeeper [20], Chubby [11], Sinfonia [2] e DepS-pace [5]. Estes serviços diferem em vários aspectos, entre os quais o modelo de dados que suportam (p.ex., sistema de ficheiros ou espaços de tuplos). Apesar das suas diferenças, o propósito é sempre o mesmo: disponibilizar uma abstracção de coordenação que simpli-fique a programação de mecanismos como a eleição de um l´ıder ou o consenso.

Sendo o objectivo destes serviços suportar aplicações distribu´ıdas, dois dos seus re-quisitos fundamentais são a fiabilidade e a disponibilidade. Por isso, geralmente os servi-dores que implementam esses serviços são replicados, usando replicação de máquinas de estados [37] ou técnicas similares.

Além da fiabilidade e disponibilidade, algumas aplicações distribu´ıdas requerem que o serviço garanta a durabilidade dos dados, ou seja, que estes sejam recuperáveis caso aconteça uma falha generalizada (p.ex., a paragem de todo um centro de dados devido a uma quebra prolongada de energia) ou a reinicialização do sistema por parte dos seus administradores. No entanto, garantir a durabilidade dos dados aumenta a latência das operações dos clientes e reduz o débito do serviço [29]. Tanto quanto é do nosso conheci-mento, nenhuma das publicações sobre serviço de coordenação faz referência ao impacto

(22)

Cap´ıtulo 1. Introduc¸˜ao 2

da durabilidade no desempenho do servic¸o.

Quando uma réplica de um serviço falha, é reinicializada e tem de recuperar o seu estado. Esta recuperação pode ser feita através da rede recorrendo às demais réplicas ou a partir do disco. Apesar de vários dos serviço de coordenação descritos na literatura oferecerem este tipo de durabilidade dos dados, apenas o Sinfonia [2] tem em conta uma falha total do sistema, na qual todas as réplicas falham e reiniciam o seu estado a partir do disco. No entanto, o protocolo utilizado é referido de uma forma muito sucinta e pouco clara.

Esta tese tem como objectivo melhorar o DepSpace através da implementação da du-rabilidade dos seus dados. O DepSpace é um sistema de coordenação tolerante a faltas ar-bitrárias baseado num espaço de tuplos, que tem como foco principal a confidencialidade dos dados guardados. A introdução da durabilidade dos dados vai aumentar a fiabilidade do sistema e vai ser garantida através de mecanismos como o logging de operações. De forma a recuperar de falhas totais do sistema, o serviço deve ter também um protocolo de recuperação de estado que permite às suas réplicas trocarem os seus estados entre si e recuperar o estado que tinham antes de a falha acontecer.

1.1 Motivac¸˜ao

Como foi referido na secção anterior, a durabilidade dos dados é vital para que os sistemas tolerem qualquer tipo de faltas que possam ocorrer.

Normalmente, garantir a durabilidade de dados implica um aumento das latências das operações efectuadas no sistema, o que se traduz numa perda de desempenho consi-derável.

Com este projecto pretende-se desenvolver o Durable DepSpace, ou DDS, uma ex-tensão do DepSpace que garante a durabilidade dos dados e que mantém o seu desem-penho muito próximo do original (i.e., muito próximo do seu desemdesem-penho sem durabi-lidade dos dados). A persistência dos dados permite ainda desenvolver protocolos de recuperação para que o sistema consiga continuar a sua execução normal mesmo na existência de faltas.

1.2 Objectivos

O REGENESYS, projecto em que esta tese se enquadra, tem como objectivo o estudo, desenvolvimento e avaliação de sistemas distribu´ıdos que consigam lidar com faltas aci-dentais (p.ex., falha de um servidor) e faltas maliciosas (p.ex., intrusões no sistema).

Este projecto tem como principal propósito o desenvolvimento e avaliação do DDS, um sistema que garante a durabilidade dos dados dos processos clientes sem comprometer significativamente o seu desempenho.

(23)

Cap´ıtulo 1. Introduc¸˜ao 3

Assim, esta dissertac¸˜ao tem como objectivos:

• Apresentar de um mecanismo de persistência de dados optimizado para diminuir o impacto das escritas para disco na latência das operações;

• Introduzir de um protocolo de sincronização de estados iniciais das réplicas para a recuperação de falhas totais do sistema.

O trabalho realizado teve ainda direito à publicação do artigo:

• J.Félix, A. Bessani, M. Correia, “Gestão de Estado Eficiente no DDS”, em INFo-rum’12: Simpósio de Informática, Caparica, 2012.

1.3 Estrutura do documento

Este documento est´a organizado da seguinte forma:

• Cap´ıtulo 2 – Trabalho relacionado: Introdução a alguns trabalhos existentes que estão relacionados com este projecto;

• Cap´ıtulo 3 – DDS: Apresentação e explicação do trabalho efectuado;

• Cap´ıtulo 4 – Avaliação: Apresentação das experiências feitas com o DDS e dos respectivos resultados;

(24)

(25)

Cap´ıtulo 2

Trabalhos relacionados

Este cap´ıtulo apresenta os temas que são relevantes para o desenvolvimento do nosso trabalho. Apresentamos vários trabalhos existentes na literatura que estão relacionados com o trabalho apresentado nesta dissertação e que não podem deixar de ser referenciados devido à sua importância.

Os temas abordados são: serviços de coordenação, protocolos tolerantes a faltas bi-zantinas (ou BFT, de Byzantine Fault-Tolerant), técnicas para garantir a durabilidade de dados e protocolos de recuperação proactiva.

2.1 Replicac¸˜ao BFT

Num sistema cliente / servidor, um cliente envia operações a um servidor, que as executa e devolve os respectivos resultados de volta ao cliente. Se este o servidor for constru´ıdo por apenas uma máquina, uma falta nessa máquina faz o sistema falhar por completo.

Para colmatar esta falha, os sistemas distribu´ıdos actuais utilizam técnicas, como a replicação de máquinas de estados [37], que permitem a interligação de várias máquinas servidoras, ou réplicas, que replicam a execução do serviço. Esta replicação aumenta a fiabilidade do sistema, dado que uma falta numa réplica não implica a falha total do sistema, pois as restantes réplicas não afectadas por essa falta conseguem continuar a sua normal execução.

Os protocolos de replicação seguem dois modelos distintos: o modelo tolerante a faltas por paragem, ou modelo CFT (Crash Fault-Tolerant) e modelo tolerante a faltas bizantinas, ou modelo BFT (Byzantine-Fault Tolerant). O primeiro modelo dita que o sistema deve utilizar n ≥ 2f + 1 réplicas para conseguir tolerar até f faltas por paragem (i.e., até f réplicas do sistema podem estar paradas / desligadas). No entanto, este modelo não assume a existência de potenciais faltas nas réplicas que as façam executar incorrec-tamente como, por exemplo, uma intrusão maliciosa que controle uma réplica e a faça enviar mensagens erradas para os clientes.

O modelo BFT vem colmatar esta falha, adicionando f r´eplicas `as 2f + 1, propostas

(26)

Cap´ıtulo 2. Trabalhos relacionados 6

pelo modelo CFT, de forma a conseguir tolerar até f faltas arbitrárias, ou seja, até f fal-tas de qualquer tipo. Este modelo é cada vez mais utilizado na construção de serviços, nomeadamente de serviços de coordenação, devido aos benef´ıcios que introduz na dispo-nibilidade e fiabilidade dos mesmos.

Esta secção apresenta vários protocolos existentes que oferecem este tipo de replicação com tolerância a faltas bizantinas, incluindo a BFT-SMaRt [41], a biblioteca utilizada para a replicação do serviço desenvolvido nesta tese.

2.1.1 PBFT

O PBFT [24], ou “Practical Byzantine Fault Tolerance”, é um protocolo BFT baseado no modelo de replicação de máquinas de estado [37] e que assumem a existência de ligações fiáveis ponto a ponto e de um modelo parcialmente s´ıncrono [16]. Num modelo de replicação de máquinas de estados, o estado de um serviço é replicado por um conjunto de máquinas, denominadas réplicas do serviço. Assim, os clientes executam operações sobre essas réplicas, modificando os seus estados sincronizadamente. Para que isto seja poss´ıvel, todas as réplicas devem iniciar com o mesmo estado e têm de executar todas as operações pela mesma ordem, utilizando um algoritmo de difusão atómica. Para além disso, as operações executadas devem ser deterministas, de modo a que a sua execução faça as réplicas avançarem para o mesmo estado, mantendo a consistência do sistema.

O PBFT garante as propriedades de disponibilidade e confiabilidade do serviço desde que existam no máximo f réplicas faltosas. Porém, para tolerar faltas bizantinas, são necessárias 3f + 1 réplicas.

Figura 2.1: Protocolo de trˆes fases do PBFT [24].

Para que um adversário não seja capaz de adulterar o protocolo (p.ex., através da reordenação de mensagens), o PBFT utiliza uma réplica primária, encarregue, por exem-plo, da ordenação das mensagens dos clientes. Mesmo assim, a réplica primária pode ser faltosa e por isso o protocolo deve ser capaz de lidar com esse problema.

Isto é feito através da adição de uma fase extra, a fase pre-prepare no in´ıcio do pro-tocolo de duas fases, como mostra a figura 2.1. Nesta fase adicional, a réplica primária

(27)

recebe uma nova operação de um cliente e envia uma mensagem PREPREPAREàs restan-tes réplicas. Ao receber essa mensagem, as réplicas adicionam-na ao seu log e enviam uma mensagem PREPARE às outras réplicas. Quando uma réplica recebe 2f + 1 mensa-gens PREPAREde outras réplicas, referente à mesma mensagem de um cliente, envia uma

mensagem COMMIT a todas as réplicas. Ao receber 2f + 1 mensagens COMMIT para uma mesma mensagem de um cliente, uma réplica entrega essa mensagem do cliente à aplicação. Após o seu processamento, o resultado de cada operação é enviado de volta ao cliente que a invocou.

Para ser poss´ıvel tolerar faltas na réplica l´ıder sem comprometer a execução do pro-tocolo, o PBFT permite que diferentes réplicas assumam o papel de réplica l´ıder. Assim, o protocolo utiliza o conceito de vistas. Em cada vista existe a eleição de uma nova réplica l´ıder. Caso a réplica l´ıder apresente um comportamento malicioso, as réplicas ini-ciam uma mudança de vista para que uma nova réplica l´ıder seja eleita. O problema da utilização de vistas num ambiente bizantino é perceber quais as operações que devem fa-zer parte da próxima vista. Assim, todas as operações que tenham sido executadas numa réplica correcta têm de prosseguir para a vista seguinte pela mesma ordem em que foram processadas. É por isto que uma réplica correcta apenas executa uma operação depois de receber 2f + 1 mensagens COMMITde outras réplicas.

´

E poss´ıvel que apenas uma réplica correcta participe no protocolo de troca de vista, fazendo com que réplicas faltosas possam também participar e apresentar mensagens inválidas como sendo correctas. Este problema é resolvido através de certificados, cada um contendo as mensagens assinadas por 2f +1 réplicas referentes a uma mesma requisição de um cliente. Como as mensagens estão assinadas com as chaves criptográficas públicas de cada réplica, as restantes réplicas podem verificar a validade de cada mensagem, vali-dando ou não o certificado.

Relativamente ao número de mensagens trocadas, o PBFT é um protocolo significa-tivamente pesado. Para diminuir o tráfego de mensagens, o protocolo recorre ao agrupa-mento (batching) de mensagens. Com isto, o protocolo ordena um número de mensagens de uma só vez, ao invés de uma mensagem por execução. Isto reduz o tempo de execução do protocolo sem afectar a latência das operações dos clientes.

2.1.2 UpRight

A biblioteca de replicação de máquinas de estados UpRight [13] foi desenhada de forma a oferecer tolerância a faltas bizantinas a serviços CFT, aumentando a sua robustez. A UpRight foi implementada de forma a que a sua integração num sistema não implique grandes esforços de engenharia ou alterações de hardware.

Para que seja simples de integrar num serviço CFT, a UpRight isola a aplicação e o protocolo de replicação de máquinas de estado [37].

(28)

shimda UpRight através da camada glue, que serve de middleware entre a aplicação CFT e o protocolo da UpRight. A camada shim é comum a todas as aplicações que utilizem esta biblioteca, sendo a camada responsável pela comunicação entre as diversas partes do sistema.

Figura 2.2: Arquitectura da UpRight [13].

A UpRight permite às réplicas do servidor criarem logs e checkpoints dos seus esta-dos. No caso dos checkpoints, são oferecidas várias formas de os criar, como através da técnica copy-on-write, ou através de um processo secundário. Para além disso, esta bibli-oteca permite também a execução de operações de leitura sem que seja necessária a sua ordenação (como no PBFT [24]), processamento paralelo de vários pedidos de clientes.

2.1.3 BFT-SMaRt

A BFT-SMaRt1 [41] é uma biblioteca de replicação que implementa um protocolo si-milar ao no PBFT e que foi desenvolvida no LaSIGE. As principais diferenças para o PBFT são a modularidade dos seus protocolos e ainda a não implementação de algumas optimizações que adicionam complexidade ao código.

Esta biblioteca BFT é completamente reconfigurável, para permitir uma fácil adaptação às diferentes necessidades dos sistemas, e foi desenvolvida na linguagem de programação Javapara evitar a existência de vulnerabilidades comuns a linguagens de mais baixo n´ıvel (p.ex., buffer overflows em C). A sua implementação tem qualidade suficiente para ser usada em protótipos robustos de sistemas tolerantes a faltas e intrusões.

Existem três protocolos que compõe esta biblioteca: ordenação de mensagens, eleição de l´ıder e transferência de estados. O protocolo de ordenação de mensagens é semelhante ao apresentado anteriormente no PBFT.

(29)

Se a réplica l´ıder for faltosa (p.ex., não envia uma mensagem de um cliente para, pelo menos, n+f₂ réplicas), é activado o protocolo de eleição de l´ıder. O protocolo também será activado no caso de a execução normal da ordenação de mensagens não terminar num per´ıodo de tempo predefinido.

Quando uma réplica verifica alguma das anteriores condições, envia uma mensagem “STOP” a todas as réplicas. Ao receber 2f + 1 mensagens “STOP”, inicia-se a troca de l´ıder, sendo que o identificador da nova réplica é calculado deterministicamente. Após a eleição do l´ıder, todas as réplicas enviam o seu respectivo log e mensagens pendentes à nova réplica l´ıder. No caso de existirem réplicas atrasadas durante o protocolo de eleição de l´ıder, estas executam o protocolo de transferência de estados para se actualizarem.

O protocolo de transferência de estados permite que réplicas atrasadas se actualizem mais rapidamente e é ainda utilizado na recuperação de estados das réplicas faltosas. A sua execução inicia-se com uma réplica a pedir o estado mais actual das restantes réplicas. Em resposta, as réplicas enviam os seus estados as respectivas estampilhas temporais. Na recepção de f + 1 respostas semelhantes, a réplica que iniciou o protocolo actualiza o seu estado e retorna à sua execução normal.

2.1.4 Outros protocolos BFT

Existem outros protocolos de replicação na literatura como, por exemplo, o Zyzziva [21], HQ [15], Q/U [1], Spinning [46] e o Aardvark [14]. No entanto, as suas concretizações não são suficientemente estáveis para serem usadas na construção de serviços confiáveis.

2.2 Serviços de coordenação

Os serviços de coordenação, tal como o nome indica, têm como função coordenar um conjunto de processos. Para isso, estes serviços oferecem abstracções suficientemente fortes que permitem aos processos, por exemplo, eleger um processo l´ıder, de forma de-terminista.

A figura 2.3, mostra as diferenças entre um serviço de coordenação e um serviço de comunicação em grupo. Um serviço de comunicação em grupo consiste numa abstracção em que um participante envia uma mensagem e todos os membros do grupo a recebem (são suportadas diferentes qualidades de serviço). Um serviço de coordenação oferece abstracções fortes o suficiente para que processos possam, de forma determinista, par-tilhar estado, eleger um l´ıder, verificar quantos processos estão ligados ao serviço e até concretizar comunicação em grupo.

Estes serviços são maioritariamente usados para que os processos consigam manter informações de configuração do sistema, podendo acedê-los e modificá-los de uma forma simples e segura. Para além disso, os serviços de coordenação conseguem resolver o

(30)

Figura 2.3: Serviço de coordenação vs Serviço de comunicação em grupo [35].

problema do consenso, o que permite a implementação de protocolos de eleição de l´ıder e de difusão de mensagens com ordem total.

Nesta secção apresentamos alguns serviços de coordenação existentes, e comparamos as suas caracter´ısticas.

2.2.1 Chubby

O Chubby [11] é um serviço de coordenação da Google que oferece uma interface seme-lhante à de um sistema de ficheiros. O sistema garante as propriedades de disponibilidade e fiabilidade e baseia-se num mecanismo de eventos (p.ex., eventos para modificações de ficheiros) e num mecanismo de locks, para controlo de concorrência nos acessos a estes ficheiros. O sistema foi desenhado com o intuito de ser utilizado para a escrita e leitura de pequenos ficheiros onde, por exemplo, um conjunto de processos possa escrever e ler o resultado de uma eleição de um processo l´ıder.

Ao contr´ario dos locks usuais, o Chubby oferece locks que podem ser mantidos du-rante um longo per´ıodo de tempo (horas ou dias), permitindo que um lock sobreviva a falhas no servidor.

Uma célula Chubby é formada por poucos servidores (tipicamente são 5 de forma a tolerar 2 faltas), dos quais um é a réplica mestre (ver figura 2.4). As réplicas são colocadas em locais diferentes de modo a diminuir a a probabilidade da existência de falhas corre-lacionadas. Todas as réplicas de uma célula mantêm uma cópia dos dados, mas apenas a réplica mestre inicia operações de leitura e escrita, propagando todas as actualizações nos dados para as restantes réplicas através do protocolo Paxos [23].

O Paxos oferece um protocolo de consenso, pelo qual são propagadas todas as operações de escrita dos clientes. As operações de leitura são satisfeitas apenas pela réplica mestre, pelo que não requerem a execução do protocolo de consenso. Esta medida permite dimi-nuir o número de mensagens trocadas entre as réplicas sem qualquer impacto no serviço, Os ficheiros e directorias mantidas no Chubby são generalizados como sendo nós e podem ser permanentes ou efémeros. Qualquer nó pode ser removido explicitamente, sendo os nós efémeros removidos no caso de não estarem abertos por qualquer cliente ou se estiverem vazios, no caso de nós representarem directorias. Isto significa que os

(31)

Figura 2.4: Arquitectura do Chubby [11].

nós efémeros são utilizados como ficheiros temporários e como indicadores de que um cliente está activo (caso um cliente falhe, os seus ficheiros são removidos). Cada nó pode comportar-se com um lock leitor-escritor, dado que um cliente pode obter um lock em modo exclusivo (de escrita) ou um número arbitrário de clientes pode obter o mesmo lock em modo partilhado (de leitura), semelhantes aos apresentados em [8, 22].

De forma a reduzir o tráfego de mensagens, os clientes deste serviço guardam os metadados dos seus nós numa cache local. Esta cache é mantida consistente através de invalidações enviadas pela réplica mestre, que mantém uma lista do que cada cliente pode ter armazenado na sua memória. O protocolo garante que os clientes mantêm uma vista actualizada do estado do serviço ou é lançado um erro no caso contrário.

Para alcançar uma maior escalabilidade, o Chubby utiliza mecanismos de proxies e de partições. Por um lado, o serviço permite que se utilizem proxies que encaminhem mensagens de vários clientes para as suas células. Por outro lado, a partição do espaço de nomes pelas diferentes réplicas permite a existência de células maiores com pouco custo de comunicação entre as partições. No caso de se usar esta partição, uma célula Chubby seria composta por várias partições, cada uma com a sua réplica mestre e mais quatro réplicas. Estes dois mecanismos podem ser combinados para se conseguir lidar com um maior número de clientes.

Em termos de durabilidade, o Chubby utiliza um mecanismo de write-ahead logging, onde as réplicas do serviço escrevem as operações dos clientes num log em disco antes de as executarem. Estes logs são replicados pelas diversas réplicas através da execução do protocolo Paxos [23].

Após um per´ıodo de tempo predefinido (normalmente horas), a réplicas mestre de cada célula Chubby escreve uma cópia do seu estado para um servidor localizado num edif´ıcio diferente do seu. Este mecanismo permite a recuperação do estado do serviço mesmo após um desastre e ainda a inicialização de uma nova réplica sem sobrecarregar as restantes réplicas que se encontram activas.

(32)

2.2.2 Sinfonia

O Sinfonia [2] permite a partilha de dados entre aplicações num ambiente escalável através da introdução do paradigma das minitransacções. Uma minitransacção consiste num conjunto de três operações: leitura, escrita, e comparação. A sua utilização melhora o desempenho do sistema na medida em que agrupam as actualizações de estados de forma a reduzir o intervalo de tempo necessário a completar cada uma das actualizações. Para conseguir alcançar uma alta escalabilidade, o serviço desacopla as operações de clientes diferentes, para que possam ser executadas independentemente. O Sinfonia baseia-se em registos partilhados para manter os dados dos seus clientes, não impondo qualquer estrutura para os dados guardados (p.ex., tabelas). As réplicas do serviço são de-nominadas nós de memória (ver figura 2.5) e conseguem manter os dados na sua memória RAM ou em memória secundária (p.ex., disco r´ıgido), dependendo das necessidades da aplicação. Cada nó tem um identificador único e o seu próprio conjunto de registos, forçando os dados do serviço a ser referenciados por um par hid, addressi, sendo id o identificador do nó a que pertence o registo address, onde estão mantidos os dados.

Figura 2.5: Arquitectura do Sinfonia [2].

Ao contrário do que acontece no Chubby, o Sinfonia não mantém dados na memória cachedos clientes, oferecendo no entanto formas destes constru´ırem a sua própria ca-che. Isto faz do Sinfonia um serviço mais simples, já que os seus dados estão sempre actualizados.

Apesar de ser poss´ıvel utilizar a replicação de máquinas de estados [37] e o protocolo Paxos [23], o Sinfonia faz uso da técnica de replicação primário-secundário [10], na qual um nó mestre é encarregue de servir os clientes. Antes de responder aos clientes, este nó envia as modificações nos dados, causadas pelas operações executadas, a todos os restantes nós.

Sendo um serviço CFT (Crash Fault-Tolerant), garante que os dados não são perdi-dos na ocorrência de falhas por paragem perdi-dos nós através da propriedade de atomicidade das minitransacções oferecidas. Para além disso, o sistema consegue executar normal-mente mesmo na presença de alguns nós indispon´ıveis, preservando os dados mesmo na

(33)

ocorrência de faltas correlacionadas. Isto apenas é poss´ıvel no caso de existir uma maioria de nós de memória activos e actualizados, de forma a permitir a recuperação de réplicas faltosas. Adicionalmente, são utilizadas quatro técnicas para a tolerância de paragens de alguns nós: imagens de disco, logging, replicação e backups.

As imagens de disco são cópias do estado de cada nó de memória. Como estes da-dos são escritos assincronamente, podem ficar desactualizada-dos. Este problema é resol-vido através do logging das actualizações dos dados para um ficheiro. Aquando uma recuperação de uma falha, os nós utilizam um algoritmo de recuperação que reproduz o conteúdo deste ficheiro de log.

Caso um nó de memória do Sinfonia perca o seu armazenamento seguro devido a uma falha, tem de recuperar os dados de um backup. Se não for poss´ıvel, o nó actualiza-se através da sincronização da sua imagem de disco e da execução do seu ficheiro de log. De forma a não executar ficheiros de log muito longos, existe um apontador que indica a operação no log a partir da qual a recuperação deverá ser iniciada. Este apontador é periodicamente escrito para disco. Para além disso, uma minitransacção conclu´ıda apenas poderá ser removida do ficheiro de log quando tiver sido aplicada em todos os nós de memória envolvidos na sua execução.

Na falha de um um cliente, o coordenador de recuperações do Sinfonia, que é exe-cutado num nó dedicado, força todos os nós a abortarem as minitransacções referentes a esse cliente.

2.2.3 ZooKeeper

O ZooKeeper [20] oferece uma API que manipula dados sob a forma de objectos orga-nizados hierarquicamente, como num sistema de ficheiros ou serviço de nomes, com o nome de znodes. Existem dois tipos de znodes: os regulares e os efémeros (cuja definição se encontra na secção 2.2.1). Adicionalmente ao que é descrito no Chubby, o ZooKeeper permite que znodes regulares tenham znodes filhos, ao contrário do que acontece com os efémeros. Ao criar um znode, um cliente pode solicitar a criação de um sentinela (ou watch), que o notifique no caso desse znode sofrer qualquer alteração. Este mecanismo permite aos clientes do ZooKeeper manterem-se informados sobre as actualizações dos seus dados sem que o sistema manipule as suas caches locais, como é feito no Chubby (ver secção 2.2.1).

O ZooKeeper utiliza a ordenação FIFO para as mensagens de clientes, o que significa que as suas operações são processadas pela ordem de chegada ao serviço, e escritas li-nearizáveis, permitindo a um cliente ter múltiplas operações em espera. Para além disso, as operações oferecidas são também livres de espera (wait-free), significando que um cliente consegue completar uma operação num número finito de iterações, independente-mente das acções dos restantes clientes, ao contrário do que acontece no Chubby, onde um cliente pode obter um lock por um tempo indeterminado e bloquear os restantes clientes.

(34)

Para a comunicação entre as réplicas, é usado o Zab [36], um protocolo de difusão atómica similar ao Paxos [23] e que utiliza uma réplica l´ıder. Este protocolo força as réplicas a executarem as operações pela mesma ordem. Tal como no Chubby, apenas as operações de escrita requerem a execução deste protocolo (ver figura 2.6).

Figura 2.6: Execução de operações de escrita e de leitura no ZooKeeper [20].

A replicação dos dados pelas diferentes réplicas permite que este serviço CFT man-tenha uma alta disponibilidade e permite ainda a recuperação de réplicas indispon´ıveis. Para que a recuperação de estados seja poss´ıvel, as alterações efectuadas num znode são escritas num ficheiro de log em disco e só depois são executadas. Periodicamente, cada réplica escreve para disco uma cópia do seu estado actual (checkpointing), de modo a processar menos mensagens na recuperação de eventuais falhas. As cópias do estado de cada réplica são consideradas imprecisas (fuzzy) porque as réplicas não bloqueiam o es-tado para realizar as cópias. Assim as cópias de eses-tado obtidas podem não corresponder ao estado do sistema em qualquer momento, porque podem conter um subconjunto de operações realizadas paralelamente à sua realização.

UpRight ZooKeeper. Clement et al., apresentaram a UpRight [13], uma biblioteca que oferece tolerância a faltas bizantinas a serviços CFT, de forma a aumentar a sua robustez. Para testar a UpRight transformaram o Zookeeper [20] num serviço BFT sem que fos-sem necessárias muitas alterações no seu código. As maiores modificações foram efectu-adas na geração de checkpoints, na interacção do serviço com a UpRight e na remoção do Zab.

Ao compararem o ZooKeeper CFT com o novo UpRight ZooKeeper, os resultados mostram que a performance deste último se aproximava do primeiro, concluindo que a inclusão de tolerância a faltas bizantinas não tem um impacto significativo.

2.2.4 DepSpace

O DepSpace [5] foi o primeiro serviço de coordenação a fazer uso de replicação de máquinas de estado BFT e de um esquema de confidencialidade, oferecendo um espaço

(35)

de tuplos fiável, concretizado sobre um conjunto de réplicas não confiáveis.

O DepSpace usa um protocolo de difusão com ordem total, originalmente baseado no protocolo Paxos at war [48], que garante que todas as réplicas recebem a mesma sequência de operações. Para além disso, e contrariamente aos protocolos usados nos anteriores serviços, o Paxos at war tolera falta bizantinas.

O DepSpace opta por oferecer uma abstracção de espaço de tuplos (ao invés de, por exemplo, um espaço de nomes hierárquico) devido às suas propriedades de simplicidade, dada a existência de apenas quatro operações básicas (e algumas variantes) são supor-tadas; endereçamento por conteúdo, o que faz os tuplos serem identificados pelo seu conteúdo, dando uma alta flexibilidade ao sistema e comunicação desacoplada, que per-mite a comunicação entre processos sem restrições espaço-temporais. Ao fazerem uso de um mecanismo de pol´ıticas de controlo de acesso, o PEATS (de Policy-Enforced Augmen-ted Tuple Space[6]), as operações sobre os espaços de tuplos do DepSpace são efectuadas apenas pelos clientes que têm permissões para o fazer, o que torna o serviço mais seguro. Apesar do reduzido número de operações, o modelo de espaço de tuplos pode ser utilizado em qualquer programa. Considerando uma operação adicional, a cas [4] (de conditional atomic swap), este modelo tem um poder de sincronização suficiente para resolver o problema do consenso e, consequentemente, outros problemas de acordo como a eleição de um processo l´ıder.

O DepSpace também utiliza o modelo de replicação de máquinas de estados [37]. No entanto, este modelo não garante a confidencialidade dos dados mantida pelas réplicas, já que a replicação dos dados pelas réplicas oferece uma maior superf´ıcie de ataque, dado que uma réplica comprometida dá acesso a todos os dados armazenados na sua memória (e em todo o sistema). Assim, é necessário um esquema de confidencialidade que mantenha a informação confidencial nas réplicas do serviço.

Para resolver este problema, uma réplica não deve ter acesso ao conteúdo dos tuplos que guarda e o acesso a estes apenas deve ser poss´ıvel com a aprovação de um conjunto de réplicas. Neste sentido, o DepSpace implementa um tipo especial de esquema de partilha secreta [39].

Num esquema de partilha secreta, um cliente distribui um segredo por n réplicas, mas cada réplica apenas guarda parte desse segredo. Para recuperar um segredo inteiro, um cliente precisa de obter pelo menos f + 1 partes diferentes para que o segredo seja revelado. No caso do DepSpace, a solução é baseado num esquema secreto publicamente verificável (n, f + 1), ou PVSS [38]. No PVSS, um cliente conhece as chaves públicas de todas as n réplicas. Cada tuplo criado pelo cliente é dividido em n partes, sendo cada parte cifrada com uma chave partilhada entre o cliente e a réplica onde será guardado. Como o modelo assume que apenas f réplicas podem ser faltosas e um tuplo apenas é revelado com a obtenção de f + 1 partes diferentes, a execução de réplicas faltosas não revela o conteúdo dos tuplos guardados. O esquema PVSS também oferece às réplicas

(36)

um método para analisar as partes recebidas pelos clientes e ainda oferece aos clientes um método para verificar se as partes recebidas das réplicas estão corrompidas.

A ideia fundamental o esquema de confidencialidade usado é que as réplicas não têm o mesmo estado, já que guardam partes diferentes dos dados. Em vez disso, o DepSpace garante que todas as réplicas possuem estados equivalentes, ou seja, para cada tuplo in-serido no espaço de tuplos, cada réplica guarda a sua respectiva parte. Isto é assegurado pelo protocolo de multicast de ordem total oferecido pela camada de replicação.

DepSpace 2.0. A segunda versão do DepSpace [35], foi criada para colmatar algumas limitações da versão anterior.

A integração com a biblioteca BFT-SMaRt [41] foi melhorada e simplificada e foram criadas operações para a manipulação de conjuntos de tuplos, que permitem, por exemplo, ler ou remover um conjunto de tuplos em vez de tuplos singulares.

2.3 Durabilidade de dados e recuperac¸˜ao de estado

Na ocorrência de falhas no sistema, é vital que os processos faltosos possam recupe-rar para um estado correcto. Esta recuperação é feita armazenando o estado do sistema através do logging das mensagens trocadas entre os processos. Este armazenamento é feito de forma a ser poss´ıvel reproduzir o estado armazenado [44].

Nesta secção serão apresentadas as técnicas de durabilidade comuns à maioria do serviços de coordenação. Estas técnicas serão também utilizadas neste projecto, com algumas optimizações que visam melhorar o desempenho do sistema.

2.3.1 Armazenamento est´avel, checkpoints e logs

Tal como é mostrado da figura 2.7, a recuperação de estados pode ser feita de duas for-mas: para trás e para a frente. No primeiro caso, a recuperação é feita de forma a que o processo faltoso recupere para o último estado correcto que conheceu antes de falhar. Para que isto aconteça, é necessário que o estado do sistema seja armazenado periodica-mente para que, na presença de falhas, seja poss´ıvel voltar a recuperá-lo. Pelo contrário, na recuperação para a frente, um processo faltoso evolui para um novo estado correcto, de onde é seguro continuar a execução normal do sistema. Aqui, o problema reside no facto de, para avançar para um novo estado, o sistema tem de conhecer todos os erros poss´ıveis de forma a conseguir corrigi-los.

(37)

No geral, a recuperação para trás é a mais utilizada, apesar de o seu uso levantar al-guns problemas. Em primeiro lugar, é uma operação cara em termos de desempenho do sistema, devido ao uso de mecanismos de logging e checkpointing, que serão discutidos de seguida. Em segundo lugar, não nos garante que uma falta não se repetirá no futuro. Finalmente, existem estados para o quais não é poss´ıvel recuperar. Por exemplo, na mai-oria dos sistemas UNIX, é muito pouco provável conseguir-se recuperar para um estado anterior à execução da operação rm -fr * (remoção de todo o conteúdo de uma directoria).

Armazenamento estável. O armazenamento estável consiste em guardar dados no local que ofereça boas garantias de que esses dados permanecerão intactos em caso de falha. Este armazenamento é de extrema importância no âmbito da recuperação 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ém é importante que esse estado sobreviva a falhas o local onde é armazenado (p.ex., disco r´ıgido) [29, 44].

Existem três tipos de armazenamento: em memória RAM, em disco, ou armazena-mento estável. O problema da memória RAM é que é apagada em caso de falha de energia ou paragem da máquina. O armazenamento em disco sobrevive a falhas da máquina mas não sobrevive a falhas no disco em si.

O armazenamento estável foi desenhado para sobreviver a quase qualquer falha, ex-cepto a desastres naturais de grande escala, como inundações e terramotos, e é bom para aplicações que requeiram um alto n´ıvel de tolerância a faltas, tal como as transacções atómicas, devido à m´ınima probabilidade de perda de dados nas operações de escrita.

Este último 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 modificação dos dados é efectuada em primeiro lugar no Disco1, os dados são verificados e são finalmente guardados no Disco2. No caso de os discos terem blocos com diferentes valores, pode-se assumir que os do Disco1 são os correctos, já que foi o primeiro a ser modificado. Os blocos do Disco1 podem então ser copiados para o Disco2 para que, quando o processo de recuperação iniciar, os discos estejam idênticos.

Este tipo de armazenamento é bom para aplicações que requeiram um alto n´ıvel de tolerância a faltas, tal como as transacções atómicas, devido à m´ınima probabilidade de perda de dados nas operações de escrita.

Checkpoints. O checkpointing consiste em criar uma cópia do estado actual do sistema e gravá-la para um local seguro. Esta técnica é a mais utilizada na recuperação para trás, já que permite o armazenamento estável periódico do estado do sistema [44]. Este estado do sistema é global e consistente em todos os processos, sendo denominado de snapshot. Aquando uma recuperação, os processos devem recuperar a snapshot mais recente, sendo que esta define a linha de recuperação do sistema. No entanto, encontrar a linha de

(38)

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

Caso os checkpoints efectuados sejam independentes, i.e., se os processos realiza-rem os seus checkpoints locais e independentemente dos restantes, o cálculo da linha de recuperação torna-se ainda mais complexo. Para além disso, tem de existir também um garbage collectorque limpa periodicamente o armazenamento local de cada processo, à medida que o número de checkpoints guardados aumenta.

Para resolver os problemas dos checkpoints independentes, é preciso coordená-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 solução simples para implementar estes checkpoints coordenados é 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 operações posteriores para mais tarde serem executadas, ou seja, bloqueiam a sua execução. Depois, confirmam com o processo coordenador que já efec-tuaram o checkpoint. Quando o coordenador recebe todas as confirmações, envia uma mensagem CHECKPOINT DONE a todos os restantes processos que estejam bloqueados, para que estes possam continuar a execução de operações.

Muitos sistemas distribu´ıdos BFT combinam checkpoints com logging de mensagens. Um processo poderia também fazer um log das mensagens que recebe (logging baseado no receptor), antes de as entregar à aplicação. Na reprodução do estado, cada processo retrocede para o checkpoint mais recente e reproduz o log de mensagens pela respectiva ordem. Isto garante a reprodução dos eventos que ocorreram após a criação do checkpoint mais recente.

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

(39)

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ário, 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ós a falha de Q e a sua respectiva recuperação, R não reenvia m2 a Q, fazendo com que este processo não re-execute m2 e reenvie m3. Esta situação deixa o sistema num estado inconsistente.

Para evitar esta inconsistência, os protocolos de logging optimista fazem com que os processos correctos que dependem dos processos que falharam (R depende de Q na recepção de m3), retrocedam para um estado onde a inconsistência deixe de se verificar. No caso da figura 2.8, R recuaria até ao momento anterior à recepção de m1 e voltaria a executar m1, seguindo-se o envio de m2 que levaria à recepção 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.

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 ga-rante 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.

(40)

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 incom-pletas 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.

(41)

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 pro-tocolo 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 efici-ente, 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.

(42)

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.

(43)

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 durabi-lidade 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 pro-cessos 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 pro-priedades (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 proces-sos 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

(44)

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 meca-nismo 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

(45)

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 ca-mada 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 da-dos, 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