UNIVERSIDADE DE LISBOA Faculdade de...

UNIVERSIDADE DE LISBOAFaculdade de Ciências

Departamento de Informática

DEPSKY: SISTEMA DE ARMAZENAMENTO EMCLOUDS TOLERANTE A INTRUSÕES

Bruno Miguel Maia Rovisco Quaresma

MESTRADO EM ENGENHARIA INFORMÁTICAEspecialização em Arquitectura, Sistemas e Redes de Computadores

2010

UNIVERSIDADE DE LISBOAFaculdade de Ciências

Departamento de Informática

DEPSKY: SISTEMA DE ARMAZENAMENTO EMCLOUDS TOLERANTE A INTRUSÕES

Bruno Miguel Maia Rovisco Quaresma

DISSERTAÇÃO

Projecto orientado pelo Prof. Doutor Alysson Neves Bessanie co-orientado pelo Prof. Doutor Paulo Jorge Paiva de Sousa

MESTRADO EM ENGENHARIA INFORMÁTICAEspecialização em Arquitectura, Sistemas e Redes de Computadores

2010

Agradecimentos

Em primeiro lugar, quero agradecer aos meus orientadores do PEI, os ProfessoresDoutores Alysson Bessani e Paulo Sousa, pela orientação dada neste último ano do MEI.

Também quero agradecer aos meus colegas, tanto de investigação como de curso,pelos bons momentos passados e troca de impressões sobre temas de interesse.

Agradeço à minha família, especialmente aos meus pais e irmã por me aturarem efacilitarem a conclusão dos meus estudos.

Finalmente agradeço, a todos os meus amigos e amigas, a força e motivação paraatingir os meus objectivos.

iii

Resumo

A manutenção da disponibilidade e da integridade da informação é um requisito fun-damental em sistemas de armazenamento. Estes sistemas lidam com a perda de dadosatravés de replicação, na qual os dados são armazenados em múltiplas unidades básicasde armazenamento. A ideia base do trabalho aqui apresentado surgiu da constatação queas clouds de armazenamento podem ser vistas como unidades desse tipo.

Com a crescente popularidade das clouds de armazenamento, empresas que lidamcom dados críticos começam a pensar em usar estes serviços para armazenar bases dedados de registos médicos, históricos de infra-estruturas críticas, dados financeiros, entreoutros. No entanto, muitas pessoas acreditam que informação armazenada num sistemadeste tipo é vulnerável, apesar de todas as garantias dadas pelos fornecedores, o que fazda fiabilidade e da segurança as maiores preocupações sobre o armazenamento em clouds.

Este trabalho apresenta o DEPSKY, um sistema que melhora a disponibilidade, in-tegridade e confidencialidade de informação armazenada em clouds. Para garantir es-tas propriedades, o sistema DEPSKY disponibiliza dois protocolos, o ADS (AvailableDEPSKY), focado em melhorar a disponibilidade e integridade da informação, e o CADS(Confidential & Available DEPSKY), que adicionalmente melhora a confidencialidade dainformação. Ambos os protocolos fornecem algoritmos para leitura e escrita, à seme-lhança do que acontece com todos os sistemas de armazenamento.

Palavras-chave: Clouds de armazenamento, replicação, disponibilidade,confidencialidade, integridade

v

Abstract

Maintaining availability and integrity of information is a fundamental requirement instorage systems. These systems deal with the loss of data through replication, where datais stored in multiple basic units of storage. The initial idea of the work presented hereresulted from the realization that storage clouds can be viewed as such units.

With the increasing popularity of cloud storaging services, companies that deal withcritical data start thinking of using these services to store medical records databases, his-torical data of critical infrastructures, financial data, among others. However, many peo-ple believe that information stored that way is vulnerable, despite the guarantees given byproviders, which makes reliability and security the major concerns about cloud storaging.

This work presents DEPSKY, a system that improves the availability, integrity andconfidentiality of information stored in the cloud. To ensure these properties DEPSKY

provides two protocols, ADS (Available DEPSKY), focused on improving the availabilityand integrity of information, and CADS (Confidential & Available DEPSKY), which addi-tionally enhances the confidentiality of information. Both provide algorithms for readingand writing data, as is any storage systems.

Keywords: Storage clouds, replication, availability, confidentiality, integrity

vii

Conteúdo

Lista de Figuras xiii

Lista de Tabelas xv

1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Publicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Trabalho Relacionado 72.1 Tolerância a Intrusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Introdução ao Tema . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Replicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Confidencialidade . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Clouds de Armazenamento . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Considerações Gerais . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Detalhes Adicionais . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 DEPSKY 193.1 Apresentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Modelo de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 ADS - Available DEPSKY . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.1 Algoritmo de Escrita . . . . . . . . . . . . . . . . . . . . . . . . 223.4.2 Algoritmo de Leitura . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 CADS - Confidential & Available DEPSKY . . . . . . . . . . . . . . . . 233.6 Trabalhos Similares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ix

4 Concretização do DEPSKY 294.1 Considerações Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Diagramas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Avaliação Experimental do DEPSKY 395.1 Custo do Armazenamento Replicado . . . . . . . . . . . . . . . . . . . . 395.2 Desempenho e Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.2 Latência de Leitura . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.3 Latência de Escrita . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6 Conclusões e Trabalho Futuro 476.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Referências 51

x

Lista de Figuras

3.1 Visão sobre a distribuição de informação pelas clouds. . . . . . . . . . . . . . 203.2 Decomposição do Data Unit X do DEPSKY, do conceito à concretização. . . . . 22

4.1 Visão minimalista sobre a estrutura do DepSky. . . . . . . . . . . . . . . . . 314.2 Diagrama de classes do sistema. . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Diagrama de sequência simplificado de uma operação de escrita. . . . . . . . . 344.4 Diagrama de sequência simplificado de uma operação de leitura. . . . . . . . . 36

5.1 FDC para as latências de leitura de dados com 100K bytes observadas em quatro

diferentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três

versões do DEPSKY replicando dados por essas clouds. . . . . . . . . . . . . 425.2 FDC para as latências de leitura de dados com 1M bytes observadas em quatro


versões do DEPSKY replicando dados por essas clouds. . . . . . . . . . . . . 435.3 FDC para as latências de leitura de dados com 10M bytes observadas em quatro


versões do DEPSKY replicando dados por essas clouds. . . . . . . . . . . . . 43

xiii

Lista de Tabelas

1.1 Planeamento inicial do PEI. . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Custo, em USD, do armazenamento, entrada e saída de 1 Gb de dados emserviços de armazenamento pay-per-use estudados. . . . . . . . . . . . . 16

2.2 Custo, em USD, de efectuar 10000 pedidos a serviços de armazenamentopay-per-use estudados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Alguns limites conhecidos de serviços livres de encargos estudados. . . . 17

4.1 Número de linhas de código necessárias para cada componente do sistema. 30

5.1 Custo estimado, em USD, de 10.000 operações de leitura e escrita dedados com 100KB, 1MB e 10MB nas clouds. . . . . . . . . . . . . . . . 40

5.2 Custo estimado, em USD, de 10.000 operações de leitura e escrita dedados com 100KB, 1MB e 10MB usando os protocolos do DEPSKY. . . . 40

5.3 Número de falhas observadas durante as experiências de leitura. O “10+10hs”para a Azure na experiência de 10M significa que para além das 10 falhasreportadas houve um período de 10 horas onde mais de 95% dos acessosindividuais a este sistema falharam. . . . . . . . . . . . . . . . . . . . . 44

5.4 Latência média (ms) de escrita para diferentes tamanhos de unidades dedados, configurações do DEPSKY e clouds de armazenamento. . . . . . . 44

xv

Capítulo 1

Introdução

Este relatório descreve o trabalho realizado no âmbito da disciplina de Projecto deEngenharia Informática (PEI) do Mestrado em Engenharia Informática da Faculdade deCiências da Universidade de Lisboa.

Este projecto foi desenvolvido na unidade de investigação LaSIGE (Laboratório deSistemas Informáticos de Grande Escala) sito no Departamento de Informática da Facul-dade de Ciências da Universidade de Lisboa. Fui inserido no grupo de investigação Na-vigators no qual o meu orientador, Prof. Doutor Alysson Neves Bessani, e co-orientador,Prof. Doutor Paulo Jorge Paiva de Sousa, estão também inseridos.

Por este motivo de proximidade, ao longo do projecto foi possível a existência de umaboa comunicação de forma a que certas ideias ou dúvidas, que tenham surgido, fossemrapidamente discutidas.

Neste capítulo introdutório são apresentadas a motivação, os objectivos, as contribui-ções e o planeamento do trabalho descrito neste relatório. A secção final deste capítulodescreve de forma resumida a oraganização dos restantes capítulos.

1.1 Motivação

A manutenção da disponibilidade e da integridade da informação é um requisito fun-damental em sistemas de armazenamento. Os sistemas de armazenamento distribuídoestão a tornar-se cada vez mais populares com o advento das tecnologias SAN (StorageArea Network) e NAS (Network Attached Storage), assim como a crescente disponibili-dade de discos de baixo custo. Estes sistemas lidam com a perda de dados através dareplicação, na qual os dados são armazenados em múltiplas unidades básicas de armaze-namento (discos ou servidores), doravante denominados objectos base.

Um desafio importante deste tipo de sistemas é fornecer uma elevada disponibilidade,tal como já tinha sido referido. Isto significa que o sistema deve permanecer disponívelainda que um objecto base falhe; por vezes mais falhas são toleradas dependendo da resili-ência do sistema. A resiliência de um sistema de armazenamento distribuído está definida

1

Capítulo 1. Introdução 2

como o número f de um total de n objectos base que podem falhar sem este sistema deixarde oferecer disponibilidade e consistência. O nível de resiliência dita a disponibilidadedo serviço pois ao replicar-se a informação em vários objectos base (discos, servidores),a disponibilidade da informação aumenta.

Um sistema de armazenamento distribuído emula um objecto partilhado robusto atra-vés da manutenção de cópias deste em locais diferentes, para que a informação sobreviva.Isto pode ser conseguido sem muito esforço financeiro usando vários discos de baixocusto ou PC’s de capacidade moderada, em vez de servidores poderosos, para armazenara informação. É típico focar na abstracção de objecto de armazenamento, que apenassuporta as operações básicas de leitura e escrita pelos clientes. O estudo destes objectos éfundamental, pois estes são os alicerces para a construção de sistemas de armazenamentomais complexos.

Os algoritmos de armazenamento distribuído enfrentam o desafio de superar a as-sincronia e uma variedade de faltas, sem se desviar significativamente das garantias deconsistência e desempenho do armazenamento tradicional (centralizado). Tais algoritmosvariam em função de várias dimensões: na semântica de consistência que fornecem; nasua resiliência (número e tipos de faltas toleradas); na sua arquitectura (se os objectosbase são simples discos ou servidores mais complexos); e na sua complexidade (e.g., la-tência). Claramente, existem muitos tradeoffs: por exemplo, oferecer maior consistênciaou resiliência adicional tem impacto na complexidade.

Nos últimos tempos tem-se observado uma crescente oferta de serviços na Internet quedisponibilizam espaço nos seus servidores para um cliente armazenar e partilhar informa-ção, normalmente ficheiros. No contexto deste trabalho tais serviços podem ser vistoscomo objectos base para a construção de um sistema de armazenamento. Contudo, terãode ser asseguradas características fundamentais como integridade, disponiblidade e con-fidencialidade, que são características básicas da segurança da informação, não estandoesta segurança restrita somente a sistemas computacionais, informação digital ou sistemasde armazenamento. A segurança da informação está relacionada com a protecção de umconjunto de dados, no sentido de preservar o valor que possuem para uma entidade, indi-víduo ou organização. O conceito de segurança informática está directamente relacionadocom o de segurança da informação, incluindo não apenas este mas também a segurançados próprios sistemas.

Actualmente, muitas organizações começam a optar de forma progressiva pelo uso declouds de armazenamento. Exemplos recentes são serviços como o Twitter e o Facebookque até há bem pouco tempo tinham os seus próprios data centers de armazenamento ehoje tercerizam parte deste serviço para a Amazon e o seu Simple Storage Service (Ama-zon S3) [1]. Esta tendência pode ser definida como o armazenamento de informação numsistema de armazenamento remoto mantido por terceiros. A Internet fornece a ligaçãoentre o computador e esse sistema.


O armazenamento em clouds tem algumas vantagens sobre o armazenamento tradici-onal. Por exemplo, se se armazenar informação numa cloud, esta estará acessível a partirde qualquer local com acesso à Internet e evita a necessidade da manutenção de umainfra-estrutura de armazenamento na organização.

À medida que as clouds de armazenamento se tornam mais populares, empresas quelidam com dados critícos começam a pensar em usar estes serviços para armazenar basesde dados de registos médicos, históricos de infra-estruturas críticas, dados financeiros,entre outros. No entanto, um perigo muitas vezes ignorado está no facto dos sistemasde armazenamento remoto estarem fora do controlo dos donos dos dados, apesar dasgarantias dadas pelos fornecedores (e.g., SLA - Service Level Agreement), o que faz dafiabilidade e da segurança as maiores preocupações sobre o armazenamento em clouds.

1.2 Objectivos

O principal objectivo deste trabalho era a concretização de um sistema de armazena-mento em clouds tolerante a intrusões, o DEPSKY, assegurando a integridade, disponibi-lidade e confidencialidade da informação. Outro dos objectivos deste trabalho era realizardiversos tipos de testes ao sistema, analisando o seu desempenho.

1.3 Contribuições

No inicio desta dissertação, foi necessário realizar um estudo acerca do tema tolerân-cia a intrusões, de forma a aprofundar conhecimentos nesta área de investigação, inci-dindo na replicação e confidencialidade de informação. Durante este estudo inicial foidada uma pequena contribuição a um projecto paralelo, que consistiu na actualização deuma biblioteca baseada em sistemas de quóruns activos 2.1.2.

Também foi necessária investigação sobre clouds de armazenamento (2.2), incluindoo estudo de API’s de variados serviços do género.

Após este processo foi iniciado o desenho e concretização do DEPSKY. Estas tarefasforam realizadas de forma incremental tendo sido efectuadas várias revisões de modo amelhorar o sistema. À medida que se efectuava uma nova versão, eram realizados testesao desempenho de modo a se perceber o que poderia ser melhorado.

A principal contribuição desta tese é o DEPSKY, um sistema que garante disponibi-lidade, integridade e confidencialidade de informação armazenada em clouds. A ideiafundamental deste sistema é replicar a informação por várias clouds de armazenamento,utilizando algoritmos para armazenamento fiável e partilha de segredos.

O DEPSKY fornece uma abstracção de um sistema de armazenamento tolerante aintrusões, possuindo algoritmos que permitem a leitura e escrita de dados em clouds. Du-rante o seu desenvolvimento tomaram-se opções tendo em conta a disponibilidade e o


custo do armazenamento em clouds. Outra contribuição importante é a análise das medi-das efectuadas ao sistema e a esses serviços de armazenamento em clouds. Os resultadosobtidos permitiram efectuar a avaliação aos protocolos do DEPSKY.

É também de referir que a parte considerável do tempo dispendido em termos dedesenvolvimento do sistema foi para estudo das API’s dos serviços usados e subjacenteconcretização do controlador (responsável pela comunicação) para cada serviço.

1.4 Publicações

O trabalho descrito neste relatório deu origem à seguinte publicação:

Título: Melhorando a Disponibilidade e Confidencialidade dos Dados Armazenados emClouds [30]

Autores: Bruno Quaresma, Alysson Bessani e Paulo Sousa

Em: INForum 2010 [6] - Segurança de Sistemas de Computadores e Comunicações

1.5 Planeamento

O planeamento inicial deste trabalho consistia nas seguintes tarefas:

• T1 - Estudo da replicação e de técnicas de replicação

• T2 - Estudo de técnicas que garantem confidencialidade em informação replicada,nomeadamente esquemas de partilha de segredos e códigos de apagamento

• T3 - Estudo das clouds de armazenamento existentes na web e suas API’s

• T4 - Desenho do sistema

• T5 - Concretização do sistema

• T6 - Testes ao sistema

• T7 - Escrita da Tese de Mestrado

A calendarização destas tarefas é apresentada na figura 1.5. Este planeamento foiseguido na perfeição até à fase de testes ao sistema (T6). Teve que ser investido mais ummês nesta tarefa devido à necessidade de se efectuarem melhoramentos ao sistema, o quelevou ao adiamento da escrita desta tese para o mês de Junho de 2010.


Tarefas Mês/AnoT1 Setembro e Outubro de 2009T2 Novembro de 2009T3 Dezembro de 2009 e Janeiro de 2010T4 Fevereiro de 2010T5 Março de 2010T6 Abril de 2010T7 Maio de 2010

Tabela 1.1: Planeamento inicial do PEI.

1.6 Estrutura do Documento

Este documento encontra-se organizado da seguinte forma:

• Capítulo 2 - Este capítulo descreve o trabalho relacionado com o sistema desenvol-vido. É introduzido o conceito tolerância a intrusões e como a replicação é impor-tante para este tipo de sistemas. Também são introduzidas técnicas de distribuiçãode informação por réplicas de maneira a garantir confidencialidade. Mais especi-ficamente são abordadas as seguintes técnicas: partilha de segredos e códigos deapagamento com criptografia simétrica. Neste capítulo também são apresentadasas clouds de armazenamento, assim como são analisadas propriedades e caracterís-ticas que estas devem assegurar.

• Capítulo 3 - Apresentação do sistema de armazenamento tolerante a intrusões DEPSKY,modelo de sistema, modelo de dados e protocolos concretizados. Para concluir sãoanalisados trabalhos recentes que tentam fazer algo similar ao DEPSKY, sendo efec-tuadas algumas comparações entre os sistemas estudados.

• Capítulo 4 - Neste capítulo são analisados os detalhes da concretização do sistemadescrito no capítulo anterior.

• Capítulo 5 - Este capítulo contém uma avaliação experimental ao DEPSKY, efectu-ada durante o mês de Junho de 2010. São analisados os desempenhos dos protoco-los e das clouds individualmente.

• Capítulo 6 - Neste último capítulo são apresentadas as conclusões deste trabalhoassim como algum trabalho a desenvolver no futuro.

Capítulo 2

Trabalho Relacionado

Neste capítulo é resumido o estudo inicial efectuado sobre a área de tolerância a in-trusões e sobre clouds de armazenamento.

2.1 Tolerância a Intrusões

2.1.1 Introdução ao Tema

Com a utilização crescente dos sistemas distribuídos, em variadas áreas de actividade,aumentou a preocupação com a confiabilidade dos diversos componentes de um sistema[33, 17]. A tolerância a faltas é um dos aspectos mais importantes nos modelos de sis-temas distribuídos clássicos e o seu objectivo é aumentar a disponibilidade e fiabilidadedos sistemas. Um sistema tolerante a faltas deve continuar a prestar o seu serviço correc-tamente mesmo na eventualidade de existir um problema com algum dos componentes.Esta visão levou à adopção de uma atitude pessimista em relação ao funcionamento dossistemas distribuídos, na qual se assume que nenhum sistema é totalmente correcto (e.g.,foram cometidos erros na fase de especificação, desenho ou concretização do sistema) epoderá estar susceptível a faltas.

Os sistemas distribuídos em geral assentam no modelo: Falta ⇒ Erro ⇒ Falha. Atolerância a faltas não trata de impedir ou prevenir que faltas aconteçam mas antes evitarque estas levem a erros e consequente falha do sistema. Opta-se por esta abordagemporque pode ser impossível prever todas as faltas possíveis num sistema, já que estaspodem ser causadas por diversos motivos assim como ter uma origem interna ou externa.

A replicação foi a técnica encontrada para construir sistemas tolerantes a faltas poiscontribui para um aumento da resiliência do sistema. A resiliência de um sistema distri-buído está definida como o número f de um total de n máquinas que podem falhar semeste sistema renunciar à disponibilidade e à consistência. Esta distribuição também au-menta a resistência a faltas na medida em que, ao contrário de um sistema centralizado,não existe um ponto único de falha. Contudo, no paradigma da tolerância a faltas, astécnicas usadas assumem que componentes do sistema podem falhar por paragem ou por

7

Capítulo 2. Trabalho Relacionado 8

omissão de passos do algoritmo que executa. Isto significa que o sistema pode não estarpreparado para lidar com falhas causadas com intencionalidade por um atacante malici-oso, e consequentemente pode ser comprometido.

O número de ataques efectuados com sucesso a sistemas distribuídos tem vindo aaumentar o que levou organizações a preocuparem-se com a segurança e confiabilidadedos seus serviços. Isto fez com que surgisse o conceito tolerância a intrusões [33, 20]. Atolerância a intrusões é uma extensão da tolerância a faltas tradicional que considera intru-sões como faltas. Com esta abordagem tornou-se possível desenvolver sistemas tolerantesa faltas que, ao mesmo tempo, respeitam as propriedades de segurança definidas.

Existe ainda outro conceito relacionado com tolerância a intrusões, denominado tole-rância a faltas bizantinas. Faltas bizantinas [27], ou arbitrárias, são o tipo de faltas maisgenérico que existe e englobam todos os tipos de faltas que podem ocorrer num sistema,incluindo as intrusões. Quando ocorre uma falta bizantina, o sistema pode responder deforma imprevisível a menos que tenha sido construído para tolerar este tipo de faltas.

A maioria dos trabalhos relacionados com a tolerância a intrusões assume que o sis-tema está envolvido num ambiente bizantino, ou seja, que o sistema é susceptível a faltasarbitrárias, seja uma intrusão, acidental ou maliciosa, uma falha do software ou por moti-vos externos ao sistema.

Tal como na tolerância a faltas clássica, recorre-se a replicação para conceber sistemastolerantes a faltas bizantinas. Nas próximas secções são discutidas alguns modelos dereplicação tolerantes a faltas bizantinas estudados. Também são discutidas técnicas paragarantir a confidencialidade de dados replicados.

2.1.2 Replicação

A ideia básica da replicação consiste em distribuir cópias de informação por um con-junto de servidores e tem sido amplamente usada em tolerância a faltas para garantir adisponibilidade e a fiabilidade de sistemas distribuídos. Muitos dos trabalhos em sistemasdistribuídos tolerantes a intrusões são também baseados em replicação. Este tipo de so-lução permite garantir a disponibilidade e a integridade do sistema se existirem intrusõesnum número limitado de réplicas.

Existem dois modelos de replicação tolerantes a faltas bizantinas, a Replicação deMáquina de Estados [25] e Sistemas de Quóruns Bizantinos [28]. Existe ainda uma outraabordagem que foi estudada e que pode ser vista como um híbrido entre os dois modelosreferidos antes, denominada Sistemas de Quóruns Activos [12].

Seguidamente, todas estas abordagens são analisadas com mais detalhe.

Replicação de Máquina de Estados

A replicação de máquina de estados é a abordagem generalista para a concretizaçãode serviços tolerantes a faltas em que cada servidor é uma máquina de estados definida


por variáveis de estado e comandos atómicos, que são operações sobre as variáveis deestado. Os clientes enviam pedidos para a execução de comandos para todas as réplicasdo sistema. Nesta abordagem as réplicas começam todas com o mesmo estado e no tempode actividade das réplicas existe acordo e ordem total o que significa que todas as réplicasexecutam os mesmos comandos pela mesma ordem. Obter estas propriedades, acordo eordem total, requer o uso de algoritmos distribuídos que ofereçam certas garantias sobre aentrega das mensagens ao conjunto de réplicas. Para além disso, as operações executadaspelas réplicas têm de ser deterministas pois o estado resultante, após a operação, em todasas réplicas do sistema tem de ser o mesmo. Como é impossível resolver o problemado consenso, também conhecido como o problema da difusão atómica, em ambientesassíncronos de forma determinista os sistemas usualmente requerem a existência de certoslimites temporais [19].

Sistemas de Quóruns Bizantinos

Um sistema de quóruns bizantinos [28] pode ser definido como um conjunto de sub-conjuntos de servidores, em que cada sub-conjunto é um quórum. A intersecção e adisponibilidade são duas características fundamentais dos quóruns. A primeira asseguraque as operações efectuadas nos diferentes quóruns mantêm-se consistentes enquanto quea segunda está implícita pois cada quórum actua em prol do sistema.

Um sistema de quóruns pode ser usado para prover uma abstracção de memória par-tilhada fiável bastando para isso definir objectos distribuídos e operações a realizar sobreestes. Através de um sistema de quóruns é possível definir objectos distribuídos e sobreeles realizar operações de tal forma que simulam a existência de uma memória partilhadafiável.

Na maioria das implementações de sistemas de quóruns bizantinos são usados n ≥3f +1 servidores com quóruns de tamanho 2f +1, sendo f o número de faltas toleradas.Assim é assegurado que, mesmo na eventualidade de acontecerem f faltas, existem pelomenos dois quóruns que se intersectam numa réplica correcta, ou seja, cada um dos doisquóruns mantém um número de servidores correctos de maneira a que pelo menos umquórum é formado apenas por servidores correctos.

Tipicamente, em sistemas de quóruns, o estado de um registo em cada servidor érepresentado pelo seu valor e por uma estampilha temporal, ou número de versão. Umaoperação de escrita sobre este registo é processada da seguinte maneira: a estampilhatemporal é lida dos quóruns, incrementada, indicando a próxima versão do registo, e logoa seguir é escrito o novo valor para o sistema juntamente com a nova estampilha. Numaoperação de leitura sobre este registo o sistema retorna o valor e estampilha correntesdo registo. Em alguns sistemas de quóruns bizantinos em que existe concorrência entreoperações, é usado um mecanismo denominado de writeback no qual o valor lido é escritode volta no sistema obrigando a que todas as leituras realizadas posteriormente retornem


o mesmo par (valor, e estampilha temporal) ou uma versão mais recente desse par.

Sistemas de Quóruns Activos

Enquanto que a replicação de máquina de estados é uma solução genérica para con-cretizar sistemas tolerantes a faltas bizantinas, os quóruns são geralmente usados paraconstruir repositórios de dados tolerantes a faltas bizantinas. Ao servirem para concre-tizar algo de mais simples do que replicação de máquina de estados, muitas vezes ostrabalhos com quóruns evitam a necessidade de realizar consenso não ficando limitadospelo resultado FLP [19], podendo os algoritmos ser totalmente assíncronos. No entanto,a principal diferença entre a replicação de máquina de estados e os sistemas de quorunsé que as operações na replicação de máquina de estados envolvem sempre todos os ser-vidores, enquanto que nos sistemas de quóruns as operações são geralmente feitas sobreum quórum, o que torna os algoritmos mais escaláveis.

Segundo a proposta [12], os Sistemas de Quóruns Activos (SQA) surgiram da consta-tação de que os sistemas de quóruns apresentam uma escalabilidade e simplicidade maiorque os protocolos baseados em máquinas de estados, mas apenas podem ser utilizados naconcretização de sistemas simples como por exemplo sistemas de armazenamento.

Sistemas mais complexos que necessitam que exista acordo entre servidores têm deser concretizados recorrendo a replicação de máquinas de estado. Um sistema de quórunsactivos pode ser visto como um híbrido entre sistemas de quóruns e máquinas de estado,que junta as duas abordagens num único sistema. Um sistema deste tipo usa diferentesprotocolos para diferentes operações, ou seja, protocolos de sistemas de quóruns paraas operações de leitura e escrita, e, protocolos de máquina de estados para outras maiscomplexas, como uma actualização.

Através de SQA é assegurado que um sistema construído sobre esta abordagem per-manece correcto na presença de n ≥ 3f + 1 réplicas, sendo f o número máximo deréplicas que podem falhar de forma bizantina. Se este pressuposto for satisfeito um ob-jecto implementado usando o SQA satisfaz as seguintes propriedades:

• Linearizability: O sistema executa operações numa determinada ordem de modo aque aparente ser acedido sequencialmente [21];

• Wait-freedom: Operações requesitadas por clientes correctos terminam, indepen-dentemente do comportamento de outros clientes, correctos ou maliciosos, do sis-tema [23].

A primeira é uma propriedade de safety que garante que as réplicas se comportam si-mulando um sistema centralizado, executando uma mensagem de cada vez. A segundapropriedade é uma propriedade de liveness importante para garantir a correcta terminaçãode todas as operações.


Um SQA permite replicar objectos sendo que, sobre estes, é possível realizar três tiposde operações distintas:

• Escrita: O estado do objecto é alterado para o valor recebido como entrada.

• Leitura: O estado do objecto é retornado.

• Actualização (Read-Modify-Write): O estado do objecto é modificado de acordocom os parâmetros recebidos e o estado do objecto.

As operações de leitura e escrita são implementadas através de sistemas de quórunsbizantinos e por isso são operações assíncronas, não dependentes de condições optimistasou pressupostos sobre tempo para garantir a terminação ao contrário da operação de actu-alização que recorre a replicação de máquina de estados, necessitando de sincronia parcialpara resolver o consenso. Os protocolos de leitura e escrita são baseados nos sistemas dequóruns e o de actualização é baseado no CL-BFT, apresentado em [15].

2.1.3 Confidencialidade

Confidencialidade é a propriedade da informação que garante que esta não será di-vulgada a entidades sem autorização, por outras palavras, garantir que a informação estáapenas acessível para os que têm autorização de acesso a esta.

A confidencialidade é compreendida no domínio da segurança informática, como aprotecção de informação trocada entre um remetente e um ou mais destinatários contraterceiros. Isto deve ser feito independentemente da segurança do sistema de comunicaçãoutilizado. De facto, uma questão de grande interesse é o problema de garantir o sigilo decomunicação utilizado quando o sistema é inerentemente inseguro, como a Internet.

Num sistema que garante a confidencialidade, um terceiro que obtenha informaçãotrocada entre rementente e destinatário não será capaz de extrair qualquer informaçãointeligível. Isto é garantido através de mecanismos de criptografia.

A replicação é normalmente vista como sendo má para a confidencialidade, porque seinformação privada se encontra replicada apenas se torna mais fácil para um atacante aconseguir, não mais difícil. Apesar disso, existem algumas técnicas para garantir confi-dencialidade em dados replicados, como as que são explicadas de seguida.

Partilha de Segredos

Um esquema de partilha de segredos [32] é o método para dividir um segredo entreum grupo de participantes, em que a cada um deles é atribuída um parte do segredo.O segredo pode ser reconstruído apenas quando um determinado número de partes sãorecombinadas, pois partes individuais não têm utilidade por si só.

Mais formalmente, num esquema de de partilha de segredos existe um distribuidor e nparticipantes. O distribuidor gera o segredo a partir da informação original, divide-o por


n partes e entrega uma parte a cada participante. As partes poderão mais tarde ser usadaspara a reconstrução da informação original mas individualmente não fornecem nenhumainformação sobre seu conteúdo, ou seja, é inexequível extrair de uma parte alguma dainformação original.

O distribuidor usa um algoritmo de maneira a que grupos de t ou mais participantes,possam reconstruir a informação original, com as suas partes. Se por exemplo n = 5 et = 3, a informação original é distribuída por 5 partes, uma para cada participante, e umgrupo de 3 ou mais partes participantes pode desvendar o segredo.

Códigos de Apagamento

Os códigos de apagamento são semelhantes aos códigos de correcção de erros (FEC- Forward Error Correction) usados em telecomunicações, mas enquanto nos primeiros ainformação pode apenas ser apagada, nos últimos pode também ser modificada. A ideiabase consiste na divisão de um ficheiro em n fragmentos de forma a que seja suficienteter k fragmentos para reconstruí-lo, mas k−1 fragmentos não cheguem para o fazer. Paraeste efeito usa-se um código de apagamento-(k,n).

No contexto da confiabilidade apenas foram estudadas algumas propostas, nomeada-mente o mecanismo denominado AVID (Asynchronous Verifiable Information Dispersal)e o mesmo mecanismo mas com confidencialidade, o cAVID. Ambos propostos em [14].

Um cliente que quer armazenar um ficheiro F começa por o codificar como um vec-tor [F1; ...;Fn] usando um código de apagamento-(k,n). Além disso obtém um conjuntode fingerprints [24] calculando um vector com sínteses criptográficas de cada Fi : D =

[D1; ...;Dn]. Depois, toda essa informação é enviada para os servidores usando um pro-tocolo de difusão fiável.

Se o cliente for malicioso e alguns dos fragmentos estiverem corrompidos, há duaspossibilidades: o número de fragmentos disponíveis permite reconstruir o ficheiro, o queé feito; ou não é possível reconstruir esses fragmentos e o ficheiro não é armazenado.Quando a operação termina os servidores apagam todos os fragmentos que não lhes per-tencem.

A operação de leitura consiste simplesmente em pedir fragmentos aos servidores até seobterem os k necessários para reconstruir F . O parâmetro k tem de verificar a condição:f + 1 ≤ k ≤ n− 2f . A melhor resistência é obtida quando n = 3f + 1, logo k = f + 1.

O mesmo artigo apresenta o esquema cAVID que garante também a confidencialidadedos dados armazenados. Para garantir a confidencialidade é necessário haver controlo deacesso ao ficheiro. Para o efeito junto do ficheiro é guardada uma lista de controlo deacesso L com os identificadores dos clientes que a eles podem aceder. A forma como éconseguida a confidencialidade é simples: o ficheiro é cifrado usando criptografia simé-trica antes de ser armazenado usando o esquema AVID. Uma desvantagem é a necessidadede partilha de uma chave secreta O problema é o que se faz da chave secreta. Se o cliente


ficasse com a chave para si, só ele poderia recuperar o ficheiro, o que em geral não é oobjectivo.

2.2 Clouds de Armazenamento

2.2.1 Considerações Gerais

Uma cloud de armazenamento pode ser descrita como um serviço online que forneceespaço nos seus servidores para um cliente armazenar informação. A comunicação entreo cliente e o serviço, como o acesso ou actualização de dados, é efectuada sobre a Internet.

Existem variados sistemas de armazenamento em clouds, uns possuem um foco muitoespecífico, como armazenar apenas mensagens de e-mail ou imagens digitais, outros po-dem armazenar todo o tipo de informação digital.

As instalações que abrigam sistemas de armazenamento em clouds são chamados dedata centers. Uma cloud de armazenamento pode ser concretizada com um ou mais datacenters.

O seu funcionamento pode ser descrito da seguinte forma: um cliente envia ficheirosatravés da Internet para os servidores que guardam a informação. O acesso aos servidorespelo cliente é efectuado através de interfaces web ou serviços web, que permitem o acessoe manipulação dos dados armazenados. Tais serviços são usualmente baseados no modeloREST (REpresentational State Transfer) ou na arquitectura SOAP (Simple Object AccessProtocol).

Os sistemas de armazenamento em clouds geralmente usam centenas de servido-res porque ocasionalmente os computadores precisam de manutenção ou reparação logotorna-se importante armazenar a mesma informação em várias máquinas, para introduzirredundância no sistema. Sem redundância, um sistema de armazenamento em clouds nãopoderia garantir a um cliente que a sua informação estará sempre disponível. Por exem-plo, a maioria dos sistemas replica a informação por servidores que usam diferentes fontesde electricidade (normalmente também geograficamente afastados) ou usam UPS1, per-mitindo aos clientes o acesso à sua informação mesmo em caso de falha no fornecimentode electricidade.

Nem todos os clientes estão preocupados apenas com a falta de espaço, alguns usamsistemas de armazenamento em clouds para backup de informação, o que garante que,caso haja algum problema na infra-estrutura computacional do cliente, a informação es-tará intacta na cloud de armazenamento.

Actualmente estão disponíveis na web algumas centenas de fornecedores de armaze-namento em clouds e o número tem vindo a aumentar. Além disso, também o espaço dearmazenamento oferecido aos clientes parece crescer regularmente.

1UPS (Uninterruptible Power Supply) - é um sistema de alimentação elétrico que entra em funciona-mento quando há interrupção no fornecimento de energia, alimentando os dispositivos a ele ligados.


Existem fornecedores de armazenamento em clouds que cobram uma quantia fixa poruma quota de espaço e largura de banda de entrada e saída de dados, enquanto outrosusam um modelo pay-per-use e cobram quantias variáveis consoante o espaço ocupado ea largura de banda utilizada pelo cliente. Além disso, o modelo de cobrança das cloudspay-per-use incorpora o conceito de elasticidade de recursos: paga-se apenas pelo uso eo serviço pode crescer arbitrariamente para acomodar altas demandas esporádicas.

De seguida exemplificam-se alguns dos serviços que fornecem armazenamento emclouds (Cloud Storaging):

• Clouds Pay-per-use

– Amazon Simple Storage Service (Amazon S3) [1]

– Microsoft Windows Azure Platform [8]

– Nirvanix Storage Delivery Network (Nirvanix SDN) [9]

– RackSpace [10];

• Clouds de custo fixo

– DivShare [3]

– DocStoc [4]

– Box.net [2]

– FilesAnywhere [5]

Em geral, o preço do armazenamento online tem vindo baixar devido à entrada decada vez mais empresas neste negócio. Isto levou muitas empresas que cobram pelos seusserviços a optarem por fornecer uma alternativa gratuita que oferece algum espaço paraarmazenamento, mas com limitações quando comparados aos serviços pagos.

As duas maiores preocupações acerca do armazenamento em clouds são a fiabilidadee a segurança. É improvável que uma organização confie a seus dados critícos a outraentidade sem a garantia que terá acesso a estes dados sempre que quiser (disponibilidade),que estes não serão corrompidos (integridade) e que mais ninguém terá acesso a eles sema sua autorização (confidencialidade). Para garantir a segurança da informação, a maioriados sistemas usa uma combinação de técnicas, incluindo:

• Criptografia: algoritmos criptográficos são usados para codificar a informação tornando-a ininteligível e quase impossível de decifrar sem a chave usada para cifrar a infor-mação, normalmente uma chave secreta partilhada entre cliente e o serviço;

• Autenticação: é necessário o registo do cliente através da criação de credenciais deacesso (e.g., username e password);


• Autorização: o cliente define quem pode aceder à sua informação.

Mesmo com estas medidas de protecção, muitas pessoas acreditam que informaçãoarmazenada num sistema de armazenamento remoto é vulnerável. Existe sempre a pos-sibilidade de um hacker malicioso, de alguma maneira, ganhar acesso à informação dosistema, por exemplo, devido a vulnerabilidades existentes neste. Existe também a pos-sibilidade de funcionários da empresa com acesso aos servidores poderem roubar, alterarou destruir informação. As empresas no negócio de armazenamento em clouds investemmuito dinheiro em medidas de segurança para limitar a possibilidade de roubo ou corrup-ção da informação. Além disso, há sempre a preocupação de colocar os dados critícos (emuitas vezes confidenciais) nas mãos de terceiros, que terão acesso às informações nelescontidos.

Finalmente, há também a questão da fiabilidade e disponibilidade dos serviços de ar-mazenamento. Armazenar informação num sistema remoto acedido via Internet coloca aorganização vulnerável a todos os problemas de conectividade e indisponibilidade tem-porária da Internet. Além disso, praticamente todos os grandes fornecedores de serviçosde armazenamento já sofreram problemas de disponibilidade e/ou corromperam dados declientes, mesmo com a redundância interna de seus sistemas (os dados são tipicamentearmazenados em diferentes data centers do provedor).

2.2.2 Detalhes Adicionais

Nesta secção são descritos detalhes adicionais de alguns serviços de armazenamentoestudados.

Distribuição geográfica de Data Centers

A distribuição geográfica é importante na medida em que cria redundância no serviço,não existindo um ponto único de falha, e principalmente porque também aproxima osdados dos clientes.

A lista seguinte relata esta distribuição global de data centers das clouds pay-per-useestudadas:

• Amazon S3 - 3 nos Estados Unidos mais um na Irlanda e outro em Singapura.

• Azure - Pelo menos um nos Estados Unidos (Chicago) e outro na Irlanda (Dublin).

• Nirvanix - 3 nos Estados Unidos (California, Texas e New Jersey) mais um naAlemanha e outro no Japão.

• RackSpace - 6 nos Estados Unidos (3 no Texas, 2 na Virginia e 1 em Chicago) mais2 no Reino Unido e outro em Hong Kong.


Acordo de nível de serviço

Um SLA (Service Level Agreement) é a parte de um contrato de serviços entre duas oumais entidades no qual o nível de prestação do serviço é definido formalmente. Na prática,o termo é usado no contexto de tempo de entrega de um serviço ou de um desempenhoespecífico. Por exemplo, se a empresa A contratar um nível de serviço de entregas de95% em menos de 24 horas à Empresa B, esta já sabe que de todas as entregas que lheforem dadas para fazer, no mínimo 95% tem que ser feitas em menos de 24 horas.

No contexto do armazenamento em clouds este acordo concentra-se principalmenteno nível de disponibilidade dos dados armazenados.

Todas as clouds de armazenamento pay-per-use estudadas (i.e., Amazon S3, Azure,Nirvanix e RackSpace) garantem uma disponibilidade de 99,9% existindo compensaçõespara o cliente caso esta percentagem não se verifique. Estas compensações são, em geral,aplicadas como descontos na facturação do cliente. Os descontos podem variar entre os10% e os 100% dependendo do nível de disponibilidade efectivamente verificado. 2

A única desvantagem para o cliente é ter de monitorizar a disponibilidade e depoister de relatar ao fornecedor se o nível contratualizado não se verificar para ter direito aosdescontos. Existe também um tempo limite para reclamação dos descontos (e.g., 15 diasno caso da Nirvanix e 30 dias nos restantes).

Custo do armazenamento em clouds

O preço praticado pelos serviços de armazenamento em clouds é um dos factores quetorna este tipo de armazenamento tão atractivo e que leva muitas organizações a migraremos seus dados para estes serviços. A tabela 2.1 apresenta o preço praticado por 4 dos servi-ços mais utilizados actualmente. É de salientar que alguns dos serviços fazem a distinçãode armazenamento em diferentes localizações (e.g., o custo de armazenamento num datacenter na Europa e num na Ásia é diferente). Por isso, apenas estão representados oscustos para armazenamento em data centers europeus (i.e., Azure e Amazon S3).

Nirvanix Azure - EU Amazon S3 - EU RackSpaceArmazenamento 0,25 0,15 0,15 0,15

Entrada 0,18 0,10 0,10 0,08Saída 0,18 0,15 0,10 0,22

Tabela 2.1: Custo, em USD, do armazenamento, entrada e saída de 1 Gb de dados emserviços de armazenamento pay-per-use estudados.

A tabela 2.2 complementa a informação apresentada na tabela 2.1 com o custo depedidos efectuados aos serviços mencionados.

2e.g., No SLA do Amazon S3 está contratualizado um desconto de 10%, se a disponibilidade verificadafor inferior a 99,9% mas igual ou superior a 99%, e um desconto de 25% se esta for inferior a 99%.


Tipo de Pedido Nirvanix Azure - EU Amazon S3 - EU RackSpaceGET * 0 0,01 0,01 0PUT ** 0 0,01 0,10 0 ***

Tabela 2.2: Custo, em USD, de efectuar 10000 pedidos a serviços de armazenamentopay-per-use estudados.

Legenda da tabela 2.2* também inclui pedidos do tipo HEAD e DELETE.** também inclui pedidos do tipo POST, LIST ou COPY.*** cobra 0,20 se forem pedidos para ficheiros com menos de 250K bytes.

Para finalizar esta análise a tabela 2.3 apresenta as limitações conhecidas de alternati-vas gratuitas fornecidas por algumas clouds de custo fixo estudadas.

Serviço (conta gratuita) Limitações conhecidasDivShare 5 Gb de armazenamento; 10 Gb downloads/mês; Um down-

load apenas pode ser efectuado dez segundos após o pedido;Docstoc 1000 pedidos por minuto; Número de uploads diário limitado

a 50000; 50 Mb é o tamanho máximo permitido de um fi-cheiro; Apenas são permitidos 200 downloads diariamente;

FilesAnywhere 1 Gb de armazenamento; 25 Mb é o tamanho máximo per-mitido de um ficheiro; Apenas são permitidos 25 downloadsdiariamente;

Box.net 1 Gb de armazenamento; 25Mb é o tamanho máximo permi-tido de um ficheiro;

Tabela 2.3: Alguns limites conhecidos de serviços livres de encargos estudados.

É de salientar que com estas alternativas gratuitas, a maior parte destes serviços nãopermite transferências de dados concorrentes. No entanto estes limites são removidos oualterados quando se adquire um dos serviços pagos (e.g., contas Premium ou Professio-nal).

2.3 Considerações Finais

Neste capítulo foram discutidos os paradigmas da tolerância a faltas e tolerância aintrusões, convergindo estas para um modelo mais generalista de tolerância a faltas bi-zantinas, e a razão da necessidade de adoptar este tipo de abordagens na concepção desistemas seguros e confiáveis.

Foram estudadas algumas técnicas para a concretização de sistemas tolerantes a fal-tas bizantinas, a replicação máquina de estados, os sistemas de quóruns bizantinos e ossistemas de quóruns activos. Também foram abordadas técnicas para garantir a confiden-cialidade em dados replicados, a partilha de segredos e os códigos de apagamento.


Finalmente houve também uma análise das características e a oferta existente de ser-viços para armazenamento de informação na cloud.

Este estudo sobre o estado da arte foi importante na medida em que serviu de base parao desenho do sistema proposto nesta tese, que irá ser apresentado no próximo capítulo.

Capítulo 3

DEPSKY

3.1 Apresentação

Este capítulo apresenta o DEPSKY, um sistema para replicação de dados em váriasclouds que melhora a disponibilidade, integridade e confidencialidade da informação ar-mazenada. O DEPSKY é a contribuição mais importante desta tese.

Os blocos atómicos de dados no DEPSKY designam-se por unidades de dados (dataunits), que podem ser actualizadas pelos seus donos e acedidas por um conjunto arbitráriode leitores. A disponbilidade destas unidades é garantida mesmo em caso de falhas devidoao uso de algoritmos de replicação para sistemas de quóruns bizantinos de disseminação[28], onde os dados armazenados em cada servidor (i.e., que neste caso são clouds dearmazenamento) são auto-verificáveis devido ao uso de assinaturas digitais e resumoscriptográficos (i.e., se um servidor alterar o conteúdo dos dados, o leitor descobre e ignoraos dados corrompidos).

O DEPSKY oferece também a possibilidade da informação mais sensível ser protegidaatravés de um esquema de partilha de segredos [32, 31], introduzindo garantias de con-fidencialidade. Desta maneira, nenhuma cloud individualmente tem acesso à informaçãocontida nos dados.

A figura 3.1 ilustra como o DEPSKY distribui a informação (e.g., um ficheiro) pe-las várias clouds. Estão representados dois clientes do sistema, um a usar o protocoloADS (Available DEPSKY) e outro a usar o protocolo CADS (Confidential & AvailableDEPSKY). A diferença entre estes protocolos é a informação enviada para as clouds. Nocaso de um cliente usar o protocolo ADS , é enviada uma cópia da informação para todasas clouds. Com o protocolo CADS a informação é dividida em partes, tantas quanto o nú-mero de clouds, e depois cada parte é enviada para sua cloud. A informação é dividida demaneira a que apenas seja necessário um determinado número de partes para reconstruira informação original, e não a totalidade das partes.

Nas secções seguintes são apresentados o modelo de sistema, o modelo de dados, osdois protocolos já mencionados, ADS e CADS, e trabalhos similares ao DEPSKY.

19

Capítulo 3. DEPSKY 20

RackSpaceAmazon

S3Windows

Azure

Nirvanix SDN

Cliente [ADS] Cliente [CADS]O valor é replicado pelas clouds.

O valor é dividido em partes que serão enviadas uma para cada cloud

Valor ValorJSS

Parte #1

Parte #2

Parte #3

Parte #4

Figura 3.1: Visão sobre a distribuição de informação pelas clouds.

3.2 Modelo de Sistema

O modelo de sistema utilizado no DEPSKY segue uma série de hipóteses pragmáticastidas em conta no desenho dos protocolos de replicação em clouds de armazenamento.

Cada cloud é representada por um servidor passivo (não executa nenhum códigodos protocolos) que oferece operações de leitura e escrita de dados com semântica deconsistência regular [26]: uma operação de leitura executada concorrentemente com umaoperação de escrita retorna o valor da unidade de dados antes da escrita ou o valor queestá a ser escrito.

Em primeiro lugar, assume-se que para cada unidade de dados há apenas um escritor,e este escritor só sofre falhas por paragem. Isto significa que cada bloco de dados éescrito por uma única entidade 1 , o que simplifica os protocolos já que não têm de lidarcom escritas concorrentes. Além disso, escritores maliciosos não são considerados poisestes poderiam escrever dados sem sentido do ponto de vista da aplicação de qualquerforma. Finalmente, estas duas hipóteses permitem a concretização de protocolos de leiturae escrita em sistemas onde os servidores são apenas discos passivos, como as clouds de

1Na prática pode existir mais de um escritor para uma unidade de dados desde que os acessos paraescrita sejam feitos isoladamente (o que pode requerer algum controlo de concorrência).


armazenamento.Os servidores (clouds) e leitores estão sujeitos a faltas arbitrárias ou bizantinas [27].

Esta decisão vai de encontro à hipótese pessimista de que não conhecemos o que hádentro de uma cloud e portanto é seguro assumir que os dados lá armazenados podem sercorrompidos arbitrariamente. Da mesma forma, como são suportados múltiplos leitorespara cada unidade de dados, é conveniente também assumir que estes podem ter qualquercomportamento. Devido ao uso de sistemas de quóruns bizantinos de disseminação [28],o sistema requer n ≥ 3f +1 servidores para tolerar até f servidores um número ilimitadode clientes faltosos.

É assumida também a ausência de um sistema de distribuição de chaves entre os clien-tes. Os leitores apenas sabem como aceder ao sistema para ler dados e também possuema chave pública do escritor para verificação e validação de dados.

3.3 Modelo de Dados

A figura 3.2 apresenta o modelo de dados do DEPSKY em três níveis:

Conceptual Data Unit Num nível conceptual temos os blocos representados por unida-des de dados (data units) que contêm, além do seu valor (data), um número de versão(version number) e informações de verificação que tornam os dados auto-verificáveis (ve-rification data). Além disso são identificadas por um nome único (e.g.,X).

Generic Data Unit Genericamente, uma unidade de dados do DEPSKY é representadaem cada cloud por dois ficheiros: um contendo os metadados e o outro com o valor maisrecente armazenando na unidade. Estes dois ficheiros estão sempre dentro de um contai-ner. O container de uma unidade de dados, para além de conter os metadados e o valoractual, pode conter também versões anteriores do valor desta unidade. O identificadoré usado para obter referências para container e metadados dessas unidades nos proto-colos definidos, ou seja, o nome dos containers e dos ficheiros advém do identificadorda unidade de dados (e.g., numa unidade de dados com o identificador X, o containerdenomina-se Xcontainer e o ficheiro de metadados denomina-se Xmetadata). Os fichei-ros de metadados são os mais importantes pois é sempre necessário um quórum destesnos protocolos definidos. Os metadados consistem na seguinte informação: um númerode versão (Version Number), o nome do ficheiro com o valor desta versão (Data Pointer)e informação de verificação (Verification Data), que inclui um resumo criptográfico dovalor para verificação de integridade deste e, no caso de ser uma unidade de dados comconfidencialidade, dados públicos necessários para a leitura do valor. Para escrever ouler uma unidade de dados é sempre necessário obter o ficheiro de metadados deste emprimeiro lugar.


Data Unit Implementation Ao nível de implementação, cada cloud possui uma repre-sentação da unidade de dados de acordo com a definição da sua estrutura interna (e.g., umcontainer é mapeado para um bucket na Amazon S3 ou para um blobcontainer na Azure).

X Amazon S3

Bucket X

Container X

Metadata

Metadata

Generic Data Unit Data Unit Implementation

Data

Version Number

Verification Data

Data

Data Pointer

Conceptual Data Unit

Verification Data

Version Number

Data

Nirvanix SDN

Folder X

Metadata

Data

Windows Azure

BlobContainer X

Metadata

Data

DivShare

Folder X

Metadata

Data

Figura 3.2: Decomposição do Data Unit X do DEPSKY, do conceito à concretização.

3.4 ADS - Available DEPSKY

Esta secção apresenta o algoritmo ADS que promove uma melhoria da disponibili-dade de dados na cloud através da replicação das unidades de dados por várias clouds dearmazenamento.

3.4.1 Algoritmo de Escrita

1. Um cliente escritor começa por enviar um pedido de leitura dos metadados a todasas clouds. O escritor espera n− f ficheiros de metadados correctamente assinadospor ele e lidos de diferentes clouds para então obter o número de versão máximodentre os contidos nestes ficheiros. O algoritmo 1 ilustra como são lidos os meta-dados.

2. O número de versão lido no passo anterior é incrementado em uma unidade, dandoorigem ao número de versão dos dados a serem escritos nesta operação (linhas 4-8do algoritmo 3). Um ficheiro, a conter os dados a serem escritos e cujo nome corres-ponde ao nome da unidade de dados concatenado com o número de versão, é criadoem todas as clouds (linhas 9-10 do algoritmo 3). O escritor espera confirmação daescrita deste ficheiro de n− f clouds.


3. Após conclusão da escrita da nova versão, são actualizados os metadados para anova versão sendo enviados pedidos de escrita para este efeito. Antes de seremenviados, os metadados são assinados pelo escritor (linhas 11-17 do algoritmo 3).Neste passo o ficheiro de metadados é actualizado (ficheiro com metadados anterioré sobrescrito), ao contrário do passo 2 em que é escrita uma nova versão dos dadosnum ficheiro diferente do da versão anterior. A operação de escrita termina quandose recebe confirmação da actualização de metadados de n − f clouds (linha 18 doalgoritmo 3).

Note que o algoritmo de escrita preserva as versões anteriores da unidade de dados.Estas versões podem ser apagadas quando o escritor achar conveniente através de umprocedimento de garbage collection que envia pedidos de remoção a todas as clouds.

3.4.2 Algoritmo de Leitura

1. Um cliente leitor começa por efectuar pedidos de metadados a todas as clouds eesperar por n − f ficheiros de metadados correctamente assinados pelo escritor,como está descrito no algoritmo 1. O leitor obtém o número de versão máximoreportado nestes ficheiros.

2. Após obter o número de versão mais actual da unidade de dados, o cliente enviapedidos de leitura para esta versão a todas as clouds e aguarda. A operação terminaquando é recebido um valor cujo resumo criptográfico é igual ao resumo cripto-gráfico contido nos metadados. Só depois desta verificação de integridade é que ovalor é retornado (linhas 8-11 do algoritmo 4).

Optimização de leitura. Uma optimização importante para diminuir os custos mone-tários do protocolo de leitura (ver secção 5.1) é enviar o pedido de leitura da versão maisactual do valor da unidade de dados apenas à cloud que responder mais rapidamente àrequisição de metadados e reportar a versão mais actual dos dados. Desta forma, emcasos sem falhas, apenas uma das clouds será lida. Caso esta cloud não responda atempa-damente (timeout) ou retorne uma versão anterior, outras clouds são acedidas até que seobtenha a versão mais recente.

3.5 CADS - Confidential & Available DEPSKY

O ADS garante a integridade e disponibilidade dos dados em clouds de armazena-mento. No entanto, um dos problemas fundamentais neste tipo de solução é evitar queentidades não autorizadas tenham acesso aos dados armazenados na cloud.


Esta secção apresenta o protocolo CADS, que integra um algoritmo criptográfico departilha de segredo de tal forma que os dados armazenados em cada cloud individual-mente sejam de pouca utilidade.

Um esquema de partilha de segredos [32, 31], conforme já explicado na secção 2.1.3,é o método para dividir um segredo entre um grupo de n participantes, em que a cada umdeles é atribuída um parte do segredo (que tem o mesmo tamanho do segredo original).O segredo pode ser reconstruído apenas quando f + 1 dessas partes são recombinadas equalquer combinação de até f partes individuais não revelam nenhuma informação sobreo segredo.

A única diferença entre os protocolos de escrita do ADS e do CADS é que nesteúltimo introduziu-se um algoritmo de partilha de segredos no passo 2 do ADS de talforma a produzir tantas partes do segredo (valor a ser escrito na unidade de dados) quantoo número de clouds. Cada uma destas partes é depois enviada para sua respectiva cloud(linhas 8-10 do algoritmo 5).

O algoritmo de leitura do CADS funciona de forma bastante similar ao ADS, porém,ao invés de aguardar apenas uma resposta com a versão mais actual dos dados (ADS -passo 2), esperam-se f + 1 partes de diferentes clouds para combiná-las usando o al-goritmo de partilha de segredos, obtendo o valor originalmente escrito (linhas 9-13 doalgoritmo 6).

Para garantir a confidencialidade ponto-a-ponto na Internet, o CADS depende da uti-lização de HTTP sobre SSL (HTTPS) para que a informação que circula na rede sejaimperceptível para terceiros. Com a utilização de HTTP sem SSL um atacante que con-seguisse interceptar f + 1 partes poderia reconstruir o segredo.

Algoritmo 1: query_metadata(dataUnit)

Entrada: unidade de dados do DEPSKY

Saída: vector com n− f metadados assinados lidos de diferentes clouds

início1

m[0 .. n− 1] ←−⊥2

para 0 ≤ i ≤ n− 1 faça em paralelo3

tmi ←− cloudi.get(dataUnit, ”metadata”)4

se verify(tmi, Pukw) então5

m[i]←− tmi6

fim7

fim8

enquanto |{i |m[i] 6=⊥}| < n− f faça9

sleep(50ms); /* aguarda 50ms antes de continuar */10

fim11

retorna m12

fim13


Algoritmo 2: write_value(dataUnit, n[0 .. n− 1], v[0 .. n− 1])

Entrada: unidade de dados do DEPSKY, identificadores (nomes) e valores aescrever

Saída: nada

início1

ok[0 .. n− 1] ←− false2


oki ←− cloudi.put(dataUnit, n[i], v[i])4

fim5

enquanto |{i |m[i] = true}| < n− f faça6


fim8

fim9

Algoritmo 3: ADS_write(dataUnit,v)

Entrada: unidade de dados do DEPSKY e valor a escreverSaída: nada

início1

n[0 .. n− 1] ←−⊥2

v[0 .. n− 1] ←−⊥3

se max_ver = −1 então4

m←− query_metadata(dataUnit)5

max_ver ←− max ({m[i].version|0 ≤ i ≤ n− 1})6

fim7

new_ver ←− max_ver + 18

∀i ∈ {0 , ..., n− 1} : n[i]←− ”value” + new_ver, v[i]←− v9

write_value(dataUnit, n, v)10

∀i ∈ {0 .. n− 1} : n[i]←− ”metadata”11

para 0 ≤ i ≤ n− 1 faça12

new_meta←− 〈new_ver,H(v), n[i]〉13

sign(new_meta, Prkw)14

v[i]←− new_meta15

fim16


max_ver ←− new_ver18

fim19


Algoritmo 4: ADS_read(dataUnit)


Saída: valor da unidade de dados do DEPSKY

início1


max_id←− i |m[i].version = max ({m[i].version|0 ≤ i ≤ n− 1})3

v[0 .. n− 1]←−⊥4

para 0 ≤ i < n− 1 faça em paralelo5

v[i]←− cloudi.get(dataUnit, ”value” +m[max_id].version)6

fim7

enquanto ¬∃i : v[i] 6=⊥ ∧H(v[i]) = m[max_id].verification faça8


fim10

retorna v[i]11

fim12

Algoritmo 5: CADS_write(dataUnit,v)

Entrada: unidade de dados do DEPSKY e valor a escreverSaída: nada

início1

n[0 .. n− 1]←−⊥2

se max_ver = −1 então3


max_ver ←− max ({m[i].version|0 ≤ i ≤ n− 1})5

fim6

new_ver ←− max_ver + 17

v[0 .. n− 1]←− get_shares(v)8

∀i ∈ {0 .. n− 1} : n[i]←− ”value” + new_ver9


para 0 ≤ i < n− 1 faça11

new_meta←− 〈new_ver,H(v[i]), n[i]〉12

sign(new_meta, Prkw)13

v[i]←− new_meta14

fim15

∀i ∈ {0 .. n− 1} : n[i]←− ”metadata”16


max_ver ←− new_ver18

fim19


Algoritmo 6: CADS_read(dataUnit)


Saída: valor da unidade de dados do DEPSKY

início1


max_id←− i |m[i].version = max ({m[i].version|0 ≤ i ≤ n− 1})3

v[0 .. n− 1]←−⊥4


v[i]←− cloudi.get(dataUnit, ”value” +m[max_id].version)6

fim7

valueHash←− m[max_idx].verification8

enquanto |{i | v[i] 6=⊥}| < n− f9

faça10


fim12

retorna combine_shares(v)13

fim14

3.6 Trabalhos Similares

De acordo com a pesquisa efectuada e até onde se sabe, existem apenas dois trabalhosbastante recentes que tentam fazer algo similar ao DEPSKY para melhorar a confiabili-dade e segurança dos dados armazenados em clouds de armazenamento, e ambos foramdesenvolvidos em paralelo com o trabalho aqui apresentado.

O HAIL (High-Availability Integrity Layer) [13] consiste num conjunto de protocoloscriptográficos que juntam códigos de apagamento com provas de recuperação que permi-tem a concretização de uma camada de software para proteger a integridade dos dadosarmazenados em clouds, mesmo que estas sejam invadidas e corrompidas por um adver-sário móvel.

Quando comparado ao DEPSKY, o HAIL apresenta pelo menos três limitações: sólida com dados estáticos (i.e., os algoritmos não suportam actualizações e multiplas ver-sões dos dados), requer que os servidores executem código (ao contrário do DEPSKY, queconsidera as clouds de armazenamento como discos passivos) e não usa nenhum meca-nismo para protecção da confidencialidade dos dados armazenados.

O sistema RACS (Redundant Array of Cloud Storage) [22] utiliza técnicas similaresàs empregues nos sistemas RAID nível 5 [29] para concretizar replicação de dados emdiversas clouds.

Diferentemente do DEPSKY, o RACS não se preocupa com problemas de segurança,mas sim com possíveis “falhas económicas”, onde uma cloud aumenta o seu custo de tal


forma que torna inviável o acesso aos dados.Além de não proteger contra corrupção de dados e violações de confidencialidade, o

RACS também não suporta actualizações dos dados armazenados. Todas estas limitaçõestornam o RACS muito menos poderoso que o DEPSKY.

Além das diferenças entre os sistemas, os trabalhos sobre o HAIL e RACS não apre-sentam nenhum tipo de medida que utilize a diversidade de clouds.

O protocolo CADS e a sua concretização são baseados nas ferramentas desenvolvidaspara a concretização da camada de confidencialidade do DepSpace [11].

Este sistema utiliza um esquema de partilha de segredos publicamente verificável paraadicionar uma camada genérica de confidencialidade sobre sistemas replicados que se-guem a abordagem de replicação por máquina de estados.

Apesar de utilizar a mesma biblioteca de partilha de segredos escrita em Java (JSS [7]),os mecanismos e protocolos desenhados para o DepSpace não podem ser directamenteaplicados ao armazenamento em clouds uma vez que requerem execução de código nosservidores na verificação dos dados, e assumem que as actualizações de unidades de dadossão sempre processadas na mesma ordem global no sistema.


Neste capítulo foi apresentado o DEPSKY, um novo sistema de armazenamento to-lerante a intrusões, que promove uma melhoria da disponibilidade, integridade e confi-dencialidade dos dados armazenados em clouds. Tal como a maioria dos sistemas dearmazenamento, o DEPSKY suporta duas operações básicas, leitura e escrita, mas oferecea possibilidade dos dados serem armazenados de acordo com um esquema de partilha desegredos, garantindo a confidencialidade destes. No próximo capítulo são apresentadosos detalhes da concretização do sistema.

Capítulo 4

Concretização do DEPSKY

4.1 Considerações Gerais

O DepSky e todos os seus componentes foram concretizados na linguagem de pro-gramação Java. Em primeiro lugar foram concretizados alguns controladores, que sãoresponsáveis pela comunicação com os diferentes sistemas de armazenamento em clouds.

Cada controlador comunica com a respectiva cloud através dos seus serviços webdisponibilizados, utilizando uma interface ReSTful ou através de envelopes SOAP. Todaa comunicação é efectuada sobre HTTPS (HyperText Tranfer Protocol secure).

Os controladores foram os componentes que mais tempo consumiram em termos dedesenvolvimento dada a variedade no funcionamento dos diferentes serviços web decada cloud. Foram concretizados controladores para os seguintes serviços: AmazonSimple Storage Service, Microsoft Windows Azure Platform, Nirvanix Storage DeliveryNetwork, DivShare, DocStoc e Box.net.

Os controladores do Amazon S3 e do Windows Azure foram concretizados sobre bi-bliotecas Java, que contêm uma implementação completa dos serviços web, disponibiliza-das pelos fornecedores. Estas bibliotecas foram usadas mas tiveram que ser ligeiramentemodificadas para suportarem proxies sem autenticação, porque a rede do DI-FCUL estádependente de uma proxy deste tipo para acesso ao exterior (Internet).

Os restantes controladores foram concretizados recorrendo a classes da API do Javacomo a URLConnection para as ligações, os parsers de XML para processar respostasdos serviços web e uma variedade de módulos Java vocacionados para segurança, comoo JSSE (Java Secure Socket Extension) e o JCA (Java Cryptography Architecture), queinclui o JCE (Java Cryptographic Extension).

Após a conclusão de um número suficiente de controladores, iniciou-se o desenvolvi-mento do componente responsável pelos protocolos (DepSky), e de outro responsável pelaverificação, validação e criação de metadados do sistema (DepSkyManager). Foi tambémconcretizado um wrapper para controladores que efectua a gestão dos retries e timeoutsdos pedidos HTTP, para garantir fiabilidade ponto-a-ponto (DepSkyCloudManager).

29

Capítulo 4. Concretização do DEPSKY 30

O componente DepSky fornece ao cliente o ponto de partida para a execução dosprotocolos, ADS e CADS. A sua interface disponibiliza as operações de leitura (read)e escrita (write) para ambos. É ainda disponibilizada outra operação, denominada rea-dOptimized, para inicializar o protocolo de leitura optimizada do ADS. É também nestecomponente que está incluído o processo para partilha de segredos.

O DepSkyManager efectua a ponte entre o DepSky e os DepSkyCloudManager’s, ge-rindo os pedidos efectuados, processando as respostas obtidas e tratando as excepções lan-çadas internamente. Para além disso, este componente também é responsável por efectuarverificações de integridade dos valores das unidades de dados assim como assinar novosmetadados ou verificar a assinatura de metadados recebidos.

Um DepSkyCloudManager encapsula um controlador numa thread e é o componenteresponsável pela comunicação com a cloud que esse controlador representa. Este podeser configurado para permitir um determinado número de tentativas (retries), caso a pri-meira falhe. Outros parâmetros que podem ser configurados são os timeouts das ligaçõesHTTP1.

Finalmente, utilizou-se a biblioteca JSS (Java Secret Sharing) [7] para concretizar apartilha de segredos no sistema. Esta biblioteca concretiza um esquema de partilha desegredos publicamente verificável proposto por Schoenmakers [31].

A tabela 4.1 apresenta o número de linhas de código necessário para concretizar cadacomponente do DEPSKY.

Componente Linhas de CódigoControlador Amazon S3 175Controlador Azure 200Controlador Nirvanix 280Controlador DivShare 350Controlador DocStoc 350Controlador Box.net 380Controlador FilesAnywhere 460DepSky 600DepSkyManager 300DepSkyCloudManager 300

Tabela 4.1: Número de linhas de código necessárias para cada componente do sistema.

1Em Java, existem dois timeouts na classe URLConnection que podem ser redefinidos, o connectTime-out, relativo ao tempo máximo de espera para que a conexão seja estabelecida, e o readTimeout, relativo aotempo máximo de espera até dados estarem disponíveis na socket, depois da ligação já estar estabelecida.


4.2 Arquitectura

A figura 4.1 mostra a forma como foi estruturado o sistema, desde o nível da interfacedo utilizador até aos serviços de armazenamento em clouds, passando pelo DepSky.

Interface

Unidade de Dados

A

Unidade de Dados

B

Unidade de Dados

<id>

...

Leitura Escrita

DepSky

Iniciar / Terminar

Controlador Cloud#1

...

Sistemas de armazenamento em clouds

Controlador Cloud#2

Controlador Cloud#n

HTTP (REST) HTTP (SOAP)

Figura 4.1: Visão minimalista sobre a estrutura do DepSky.

Para simplicidade de os componentes descritos na secção anterior estão incluídos noDepSky representado nesta figura.

A interface permite que o utilizador execute as operações disponibilizadas pelo sis-tema (leitura e escrita). Com a execução de qualquer operação é inicializado o DepSky,mas apenas se ainda não estiver activo.

O DepSky está basicamente encarregue da "tradução" entre uma unidade de dadose dois ficheiros que a representam em cada cloud. Isto significa que se, por exemplo,exitirem 4 clouds para as quais são replicados os dados vão necessariamente existir umtotal de 8 ficheiros que representam essa unidade de dados, 4 com metadados e outros4 com o valor (ou uma parte deste no caso do CADS). Esta "tradução"é completamentetransparente para o cliente, que apenas precisa saber o identificador de uma unidade dedados. Aliás, este identificador é o único parâmetro numa operação de leitura, e um dosdois parâmetros numa operação de escrita (o outro parâmetro é o valor a escrever).


Este modelo foi adoptado para que, através da utilização de metadados, fosse maisfácil efectuar o controlo de versão e verificar a autenticidade do valor da unidade de dados.Esta separação entre dados e metadados também permitiu a concretização do ADS comleituras optimizadas já que neste protocolo é pedido o valor da unidade a apenas umacloud (no melhor caso).

Os controladores, representados abaixo do DepSky, são os componentes responsáveispela comunicação com as clouds , como já foi referido.

Uma descrição mais detalhada é efectuada na próxima secção.

4.3 Diagramas UML

Nesta secção são apresentados alguns diagramas UML, como o diagrama de classesdo sistema, e os diagramas de sequência para as operações de escrita e leitura.

A figura 4.2 apresenta o diagrama de classes do DEPSKY. Através deste diagramaconseguimos ter uma visão mais abrangente sobre como funciona o sistema.

Os componentes representados no diagrama passam mensagens e outra informação deuns para os outros através de handlers. Estes handlers estão representados pelas interfacesIDepSkyProtocol e ICloudDataManager. Por exemplo, sempre que um DepSkyCloudMa-nager recebe um ficheiro de metadados, invoca o método processMetadata do DepSky-Manager para verificação de assinatura e saber se se trata de uma unidade de dados compartilha de segredos, ou seja, se foi escrita através do ADS ou CADS. Já a outra interface,a IDepSkyDriver, representa todas as operações que um controlador deve implementarpara ser compatível com o DEPSKY. Todos os controladores concretizados implementamos métodos desta interface.

A classe DepSkyDataUnit representa uma unidade de dados. É um objecto destaclasse que é passado como argumento às operações definidas. Para além de representaruma unidade de dados do DEPSKY um objecto deste tipo também tem outras funcionali-dades, como manter uma cache com as versões e valores lidos anteriormente ou indicar,numa operação de escrita, se queremos utilizar o ADS ou o CADS, através de um parâ-metro booleano (useSS).

As classes CloudRequest e CloudReply são subclasses da classe CloudMessage, querepresenta um pedido ou resposta de uma cloud. Embora a interface seja comum foi ne-cessário fazer a separação entre pedidos e respostas essencialmente para fazer debuggingao sistema e perceber a direcção das mensagens, se estavam a chegar ou a sair.

Por fim, também é representada a excepção genérica lançada pelos DepSkyCloudMa-nager’s sempre que houve um problema de comunicação com uma cloud. Estas excepçõessão tratadas ao nível do DepSkyManager, no entanto convém relembrar que o sistema foiconcebido para tolerar apenas f faltas. Se acontecerem mais de f faltas os protocoloslançam uma excepção para a camada superior.


DepSky

+pro

cess

Req

ues

t()

+pro

cess

Rep

ly()

+req

ues

ts :

Clo

ud

Req

ues

t+r

eplie

s : C

lou

dR

eply

DepSkyCloudMan

ager

+do

Req

ues

t(in

clo

ud

Id :

Stri

ng,

in r

equ

est

: Clo

ud

Req

ues

t)

DepSkyM

anager

«u

tilit

y»DepSkyLogger

+rea

d(i

n d

ata

un

it :

Dep

SkyD

ata

Un

it)

: Ob

ject

+rea

dO

pti

miz

ed(i

n d

ata

un

it :

Dep

SkyD

ata

Un

it)

: Ob

ject

+wri

te(i

n d

ata

un

it :

Dep

SkyD

ata

Un

it)

+da

taR

ecei

ved

(in

rep

ly :

Clo

ud

Rep

ly)

«in

terf

ace»

IDepSkyProtocol

+in

itSe

ssio

n(i

n p

rop

erti

es :

Ob

ject

) : S

trin

g+c

rea

teC

on

tain

er(i

n s

id :

Stri

ng

, in

cid

: St

rin

g)

: Str

ing

+del

eteC

on

tain

er(i

n s

id :

Stri

ng

, in

cid

: St

rin

g)

: Bo

ole

an

+up

loa

dD

ata

(in

sid

: St

rin

g, i

n c

id :

Stri

ng

, in

did

: St

rin

g, i

n d

ata

: O

bje

ct)

: Str

ing

+do

wn

loa

dD

ata

(in

sid

: St

rin

g, i

n c

id :

Stri

ng

, in

did

: St

rin

g)

: Ob

ject

+del

eteD

ata

(in

sid

: St

rin

g, i

n c

id :

Stri

ng

, in

did

: St

rin

g)

: Bo

ole

an

+en

dSe

ssio

n(i

n s

id :

Stri

ng

) : B

oo

lea

n+g

etSe

ssio

nK

ey()

: St

rin

g+g

etD

rive

rClo

ud

ID()

: St

rin

g+g

etC

on

tain

erA

nd

Da

taID

sByN

am

e(in

sid

: St

rin

g, i

n c

na

me

: Str

ing

, in

dn

am

e : S

trin

g)

: Ob

ject

«in

terf

ace»

IDepSkyD

river

AmazonS3Driver

WindowsAzureDriver

RackSpaceDriver

NirvanixDriver

DivShareDriver

FilesAnyw

hereDriver

BoxN

etDriver

DocStocD

river

+pro

cess

Met

ad

ata

(in

md

rep

ly :

Clo

ud

Rep

ly)

+ch

eckD

ata

Inte

gri

ty(i

n v

rep

ly :

Clo

ud

Rep

ly)

+wri

teN

ewM

eta

da

ta(i

n v

rep

ly :

Clo

ud

Rep

ly)

«in

terf

ace»

ICloudDataM

anager

+get

Co

nta

iner

Nam

e()

: Str

ing

+get

Met

adat

aFin

enam

e()

: Str

ing

+get

Val

ued

ataF

ilen

ame(

in v

ersi

on

: Lo

ng)

: St

rin

g

+id

: St

rin

g+v

ersi

on

: Lo

ng

+use

SS :

Bo

ole

an

DepSkyD

ataU

nit

DepSkyD

river

1 1

*

1

CloudRequest

CloudReply

Esta

cla

sse

par

a al

ém d

e ge

rir

ped

ido

se

resp

ost

as t

amb

ém e

fect

ua

a ge

stão

d

os

retr

ies

e ti

meo

uts

das

liga

ções

HTT

P.

in m

essa

ge :

Stri

ng

«ex

cep

tio

n»

Sto

rage

Clo

ud

Exce

pti

on

11

0..

1

1

+seq

uen

ce :

Lon

g+p

roto

Op

: In

tege

r+s

id :

Stri

ng

+cid

: St

rin

g+d

id :

Stri

ng

+dat

aun

it :

Dep

SkyD

ataU

nit

+clo

ud

Op

: In

tege

r+v

alu

e : O

bje

ct-i

sMet

adat

a : B

oo

lean

-ver

sio

n :

Lon

g-v

alu

eHas

h :

Stri

ng

CloudMessage

Esta

cla

sse

rep

rese

nta

um

a u

nid

ade

de

dad

os

do

Dep

Sky

e ta

mb

ém s

erve

co

mo

cac

he

par

a m

etad

ado

s e

valo

r d

a ú

ltim

a ve

rsão

lid

ad

essa

un

idad

e d

e d

ado

s.

0..

*

1..

*

Co

nju

nto

de

con

tro

lad

ore

s co

ncr

etiz

ado

s.

São

res

po

nsá

veis

pel

os

ped

ido

s e

resp

ost

as H

TTP

d

o s

ervi

ço q

ue

rep

rese

nta

m.

Figura 4.2: Diagrama de classes do sistema.


loop

loop

[du.cloudVersion.size() < N - F]

[lastValuedata.size() < N - F]

CloudRequest : req

DepSkyDataUnit :du

CloudReply: rep

DepSky ManagerDepSkyClient

4: write completed

1: init()

3.8.1: new (du,NEW_DATA_OK)

3.8.2: lastValuedata.add(rep)

3.8: writeNewMetadata(rep)

3.7.1: new (du,NEW_DATA_OK)

3.7.2: dataReceived(rep)

3.6: new (NEW_DATA,du,data2write)

3.7: doRequest(req)

3.5: newVersion = du.getMaxVersion() + 1

3.5: cloudVersion.put(rep.cloudId,rep.version)

3.4: lastMetadata.add(rep)

3.3: processMetadata(rep)

3.2.1: new (du,METADATA)3.2.2: dataReceived(rep)

3.2: doRequest(req)

2: new (regid)

3.1: new (GET_DATA,du)3: write (du,data2write)

Visual Paradigm for UML Community Edition [not for commercial use]

Figura 4.3: Diagrama de sequência simplificado de uma operação de escrita.

As figuras 4.3 e 4.4 ilustram os fluxos de informação e como são criados os objectos noDEPSKY, através de diagramas de sequência UML para as operações de escrita e leitura.Os diagramas estão simplificados pois todos os DepSkyCloudManager’s foram incluídosno DepSkyManager. Basicamente foi abstraída a comunicação com a cloud nos passosem que são criados novos objectos do tipo CloudReply. Se ocorrerem excepções duranteesta comunicação, só depois de esgotados os retries de um DepSkyCloudManager, é queum CloudReply é criado e inicializado com um valor nulo. Nos diagramas estas excepçõestambém não estão representadas. De referir que cada DepSkyCloudManager cria um novoobjecto CloudReply sempre que recebe uma resposta do controlador, para depois o passarao DepSkyManager.

Operação write

Numa operação de escrita o cliente começa por criar um objecto do tipo DepSkyDa-taUnit passando como argumento o identificador, que tem de ser único. Este objecto édepois passado como argumento da operação write juntamente com os dados que o clientequer escrever na unidade de dados.

Após este passo, o DepSky cria um objecto do tipo CloudRequest para obter os meta-


dados da unidade de dados indicada e passa-o ao DepSkyManager. Este gestor é respon-sável por multiplicar este pedido pelos DepSkyCloudManager’s que por sua vez o passamaos controladores para o encaminhar para a cloud correspondente. Este último passo éefectuado em todos os controladores ao mesmo tempo, ou seja, os pedidos são enviadosparalelamente a todas as clouds do sistema. Assim que os metadados são recebidos sãoreencaminhados para o DepSkyManager que verifica a assinatura dos metadados e, se estafor válida, guardar a informação contida nestes (i.e., versão ) porque será necessária nospassos seguintes.

O DepSky aguarda a recepção de n − f metadados antes de prosseguir. Como já foireferido, obter os metadados é essencial para que o sistema calcule o valor da próximaversão. Assim que são obtidos, o DepSky cria um CloudRequest, mas desta vez paraescrever uma nova versão do valor. Este pedido é encaminhado para o DepSkyManagerque repete o processo com os DepSkyCloudManager’s já descrito anteriormente (pedidosefectuados paralelamente a todas as clouds). O novo número de versão é lido do objectoDepSkyDataUnit, que possui em cache o número de versão existente em cada cloud,obtido dos metadados.

Após a recepção da confirmação de escrita do novo valor em n − f clouds dá-seinício à actualização dos metadados nas clouds. Para este efeito, é criado outro objecto dotipo CloudRequest com o novo ficheiro de metadados. O novo ficheiro é construído peloDepSkyManager e contém o novo número de versão, um resumo criptográfico do novovalor e o nome do ficheiro com a nova versão.

A operação write termina quando são recebidas n − f confirmações da actualizaçãodos metadados.

Operação read

Numa operação de leitura o cliente começa por criar um objecto do tipo DepSkyDa-taUnit, passando como argumento o identificador único, que por sua vez é passado comoargumento da operação read.

Após este passo, o DepSky cria um objecto do tipo CloudRequest para obter os me-tadados da unidade de dados, exactamente como na operação write, com a diferença quenuma operação read é guardada temporariamente toda a informação contida nos meta-dados (i.e., versão, nome do ficheiro com o valor e resumo criptográfico do valor) poisserão necessárias nos passos seguintes (na operação write apenas é relevante o número deversão).

O DepSky aguarda a recepção de n − f metadados antes de prosseguir2. Assim quesão obtidos os metadados, o DepSky cria um CloudRequest com o nome do ficheiro com

2No protótipo, uma pequena optimização efectuada, é não aguardar os n − f metadados para pedir ovalor e pedi-lo assim que os metadados sejam validados. Obviamente que o protocolo só prossegue após arecepção de n− f metadados válidos


loop

[hasMoreDrivers = true & du.cloudVersion.size() < N - F & lastValuedata.size() < F]

CloudRequest : req

DepSkyDataUnit :du

CloudReply: rep

DepSky ManagerDepSkyClient

4: lastValuedata.get(0).response

1: init()

3.7.2: [rep.version = maxVersion] lastValuedata.add(rep)

3.7.1: new (du,VALUE)

3.6: new (GET_DATA,du,rep.valueId)

3.7: doRequest(req)

3.5: maxVersion = du.getMaxVersion()

3.5: cloudVersion.put(rep.cloudId,rep.version)

3.4: lastMetadata.add(rep)

3.3: processMetadata(rep)

3.2.1: new (du,METADATA)3.2.2: dataReceived(rep)

3.2: doRequest(req)

2: new (regid)

3.1: new (GET_DATA,du)3: read (du)

Visual Paradigm for UML Community Edition [not for commercial use]

Figura 4.4: Diagrama de sequência simplificado de uma operação de leitura.

o valor obtido dos metadados referentes à versão mais recente. Este pedido é passado aoDepSkyManager que o multiplica pelos DepSkyCloudManager’s, sendo depois efectuadoem paralelo às clouds. Cada DepSkyCloudManager cria um objecto do tipoCloudReply epassa-o ao DepSkyManager com o valor recebido da cloud. O DepSkyManager quandorecebe este objecto faz a verificação de integridade, e só se os dados não tiverem sidomodificados é que entrega ao DepSky

A operação termina quando é entregue no DepSky um CloudReply que reporte umvalor íntegro e referente à versão mais actual da unidade de dados.

4.4 Controladores

Foi definido que os controladores deviam fazer apenas as operações necessárias parao correcto funcionamento do DEPSKY. As funções básicas de um controlador são lere escrever dados na cloud, no entanto para o DEPSKY foram definidas mais algumasoperações (listadas na interface IDepSkyDriver do diagrama de classes 4.2), entre elas apossibilidade de criar containers.

Para concretizar o controlador de uma cloud de armazenamento, é necessário o estudoda API dos serviços web disponibilizados. Devem ser analisadas as funcionalidades ne-cessárias (e.g., uploadFile, createBucket) e concretizá-las seguindo a sua especificação.Esta especificação indica como devem ser construídos os pedidos HTTP a enviar ao ser-viço web, podendo ser necessários cabeçalhos adicionais (e.g., para autenticação), ou que


o corpo HTTP do pedido esteja estruturado numa determinada forma.Embora a maioria das clouds pay-per-use disponibilizem serviços ReST e SOAP, to-

dos os controladores para este tipo de clouds foram implementados usando os serviçosReSTfull. A maioria das clouds de custo fixo apenas disponibiliza API para uma dasabordagens, normalmente ReST. Contudo o FilesAnywhere apenas disponibiliza servi-ços web através de SOAP. Comparando as duas abordagens, ReST e SOAP, o nível decomplexidade de programação experienciado é semelhante, não havendo mais ou menosdificuldade de concretização.


Neste capítulo foram descritos os detalhes da concepção do DEPSKY, como a sua ar-quitectura e como o sistema funciona na prática, ou seja, como efectua a "tradução"entreum unidade de dados DEPSKY e os dados armazenados nas clouds. Foram também apre-sentados detalhes da implementação do sistema, o diagrama de classes e diagramas desequência para as operações de leitura e escrita. Os controladores do DEPSKY e a aborda-gem tomada na concretização destes também foi descrita. Uma avaliação ao desempenhodo sistema, e das clouds individualmente, é efectuada no próximo capítulo.

Capítulo 5

Avaliação Experimental do DEPSKY

Neste capítulo apresenta-se uma avaliação do DepSky que tenta responder a três per-guntas:

• Qual o custo adicional em se utilizar replicação de clouds de armazenamento?

• Qual o ganho de desempenho e de disponibilidade em se usar clouds replicadaspara armazenar dados?

• Qual o custo relativo das diferentes versões (ADS, ADS com leitura optimizada eCADS) do DEPSKY?

5.1 Custo do Armazenamento Replicado

As clouds de armazenamento usualmente cobram pela quantidade de dados que en-tram, saem e ficam armazenados nos seus data centers.

A tabela 5.11 mostra os gastos com leituras e escritas nas clouds, para diferentes ta-manhos de blocos de dados.

A tabela 5.2 vem no seguimento da tabela 5.1 e, adicionalmente, apresenta os custosda utilização do modelo de unidade de dados descrito neste artigo pelos protocolos doDEPSKY nas mesmas condições. É de salientar o baixo custo da utilização da leituraoptimizada quando comparada com a normal.

Ambas as tabelas mostram o custo, em USD, de se realizar 10.000 operações de leiturae escrita para diferentes tamanhos de blocos de dados.

É necessário relembrar que os protocolos de leitura do DepSky efectuam 2 pedidosde leitura a cada cloud, e também, que os protocolos de escrita efectuam um pedido deleitura e 2 pedidos de escrita a cada cloud.

A coluna “DEPSKY” apresenta os custos do uso dos protocolos ADS e CADS propos-tos. É importante referir que o uso de confidencialidade (protocolo CADS) não apresenta

1Nesta tabela são paresentados os custos do RackSpace ao invés do Divshare (usado nas experiênciasde latência) devido ao facto do primeiro cobrar por uso, enquanto o segundo oferece apenas pacotes fixos.

39

Capítulo 5. Avaliação Experimental do DEPSKY 40

Operação Tamanho Amazon S3 (EU) RackSpace Windows Azure Nirvanix

10k Leituras100 kb 0,11 0,22 0,16 0,181 Mb 1,01 2,20 1,51 1,80

10 Mb 10,01 22,0 15,01 18,0

10k Escritas100 kb 0,20 0,28 0,11 0,181 Mb 1,10 0,80 1,01 1,80

10 Mb 10,10 8,00 10,01 18,0

Tabela 5.1: Custo estimado, em USD, de 10.000 operações de leitura e escrita de dadoscom 100KB, 1MB e 10MB nas clouds.

Operação Tamanho DEPSKY DEPSKY opt. (melhor caso)

10k Leituras100 kb 0,69 entre 0,12 e 0,221 Mb 6,54 entre 1,02 e 2,20

10 Mb 65,04 entre 10,02 e 22,0

10k Escritas100 kb 1,10 1,101 Mb 4,84 4,84

10 Mb 46,24 46,24

Tabela 5.2: Custo estimado, em USD, de 10.000 operações de leitura e escrita de dadoscom 100KB, 1MB e 10MB usando os protocolos do DEPSKY.

acréscimo representativo de custo, em termos de armazenamento, uma vez que os seusmetadados ocupam, em média, 500 bytes enquanto os metadados para unidades de dadossem confidencialidade ocupam cerca de metade desse valor.

A coluna “DEPSKY opt. (melhor caso)” apresenta os custos quando a optimizaçãode leitura para o protocolo ADS é utilizada. O custo varia porque a cloud mais rápida aresponder aos pedidos de metadados não é sempre a mesma, logo estão representados oscustos mínimo (Amazon S3) e o máximo (RackSpace) para cada tamanho de dados.

Custo de leitura. Este custo corresponde apenas ao custo de se ler os metadados daunidade de dados e os dados propriamente ditos. O custo de leitura do DEPSKY é similara soma dos custos de leitura em cada uma das quatro clouds individualmente, enquantoque na versão optimizada o custo é bastante reduzido, já que só é pedido o valor a umadas clouds. No entanto, há que considerar um acréscimo de poucos cêntimos devido aospedidos de metadados a todas as clouds.

Custo de escrita. O custo da escrita considera o custo de se ler os metadados, escreveruma nova versão destes e escrever a nova versão dos dados. Além disso, neste custoestão incluídos os custos de armazenamento dos dados, o que significa que se consideraum sistema onde nenhuma versão de uma unidade de dados será apagada (i.e., escritasapenas criam novas versões). Como já foi referido, esta funcionalidade é importante paradados critícos na medida que permite recuperar versões anteriores das unidades de dados


armazenadas. Entretanto, na prática esse custo pode ser amortizado eliminando versõesantigas dos valores das unidades de dados.

Os resultados das tabelas 5.1 e 5.2 mostram que o custo apresentado para as versõesdo DEPSKY correspondem a soma dos custos de escrita nas clouds. Estes custos, assimcomo na leitura não-optimizada, advém do modelo de replicação utilizado onde o blocode dados é replicado em todas as clouds.

Se tivessem sido aplicadas técnicas similares ao RAID nível 5 [29], estes custos di-minuiriam aproximadamente para metade, já que os dados armazenados em cada cloudteriam um tamanho menor.

5.2 Desempenho e Disponibilidade

O DEPSKY foi desenhado tendo em conta um modelo em que as leituras são muitomais frequentes que as escritas, como é observado em praticamente todos os sistemas dearmazenamento [16]. Por isso, a avaliação efectuada concentra-se na latência das opera-ções de leitura em diferentes configurações. No entanto, são reportados também algunsvalores de latência do protocolo de escrita no fim desta secção para fins de completude doestudo.

5.2.1 Metodologia

As medidas de latência de leitura foram obtidas através de uma aplicação que acedeos dados de 7 formas diferentes (configurações): às 4 clouds de armazenamento individu-almente sem utilização do DEPSKY (Amazon S3, Windows Azure, Nirvanix e Divshare)e às 3 versões do protocolo de leitura do DEPSKY (ADS, ADS com leituras optimiza-das e CADS). Todas as versões do DEPSKY usam as quatro clouds mencionadas paraarmazenar dados, e portanto toleram uma falha.

Foram medidos tempos de leitura para unidades de dados de três tamanhos: 100K,1M e 10M bytes. A aplicação executou todas estas leituras periodicamente - de um emum minuto (10K e 1M) ou de cinco em cinco minutos (10M) - e armazenou os temposobtidos em ficheiros de log.

O objectivo foi ler os dados através das diferentes configurações dentro de um inter-valo de tempo o mais curto possível tentando minimizar as variações no desempenho daInternet.

As experiências aqui reportadas foram efectuadas entre 31 de Maio e 13 de Junhode 2010, com o cliente a executar numa máquina do Departamento de Informática daFCUL e a aceder às quatro clouds de armazenamento. Foram efectuadas 99414 medidasde latência, isto é, 14202 medidas por cada uma das 7 configurações.


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

Função d

e D

istr

ibuiç

ão C

um

ula

tiva

Latência (milisegundos)

LegendaDivshareNirvanixAzureAmazon S3

(a) Clouds.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1000 2000 3000 4000 5000 6000

Função d

e D

istr

ibuiç

ão C

um

ula

tiva


LegendaDS−ReadODS−ReadDS−ReadSSAmazon S3

(b) DEPSKY.

Figura 5.1: FDC para as latências de leitura de dados com 100K bytes observadas em quatro dife-rentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três versões do DEPSKY

replicando dados por essas clouds.

5.2.2 Latência de Leitura

As figuras 5.1, 5.2 e 5.3 apresentam a FDC (função de distribução cumulativa) daslatências medidas na leitura dos diversos tamanhos dos dados nas diversas clouds indivi-dualmente e utilizando as diferentes versões do DEPSKY.

São apresentados resultados relativos ao acesso às clouds individualmente, e utili-zando diferentes versões do DEPSKY (com os resultados da Amazon S3, para fins decomparação).

Através da figura 5.1(a) observa-se que as distribuições de latência para todas as con-figurações são bastante semelhantes com destaque para a Azure que demonstra ser maislenta. Já a figura 5.1(b) mostra que com este tamanho o desempenho dos protocolos deleitura do DEPSKY é bastante semelhante ao da Amazon S3. Mais especificamente, oADS e o ADS com leituras optimizadas obtiveram melhor tempo de resposta em relaçãoà Amazon S3 em cerca de 70% das medidas.

Nas experiências com unidades de dados de 1M já se pode observar alguma discre-pância entre os desempenhos da Amazon S3 e da Nirvanix (figura 5.2(a)). Na verdade aNirvanix obteve um desempenho pelo menos duas vezes melhor que as restantes clouds.

Além disso, com este tamanho já se commeça a notar a diferença entre usar replicaçãode dados em clouds e apenas uma cloud: 90% das leituras optimizadas com o DEPSKY

estão abaixo de 3,2 segundos, enquanto com a Amazon S3 este valor aproxima-se de 8segundos (o pior resultado de 90% das medidas).

Através da comparação das figuras 5.2(a) e 5.2(b) pode afirmar-se que o bom desem-penho dos protocolos do DEPSKY está directamente relacionado com o desempenho daNirvanix no intervalo em que foram efectuadas as medições.

As experiências com unidades de dados de 10M já demonstram as dificuldades emlidar com o armazenamento de dados na Internet.


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Função d

e D

istr

ibuiç

ão C

um

ula

tiva



(a) Clouds.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Função d

e D

istr

ibuiç

ão C

um

ula

tiva



(b) DEPSKY.

Figura 5.2: FDC para as latências de leitura de dados com 1M bytes observadas em quatro dife-rentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três versões do DEPSKY


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5000 10000 15000 20000 25000 30000 35000 40000

Função d

e D

istr

ibuiç

ão C

um

ula

tiva



(a) Clouds.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5000 10000 15000 20000 25000 30000 35000 40000

Função d

e D

istr

ibuiç

ão C

um

ula

tiva



(b) DEPSKY.

Figura 5.3: FDC para as latências de leitura de dados com 10M bytes observadas em quatro dife-rentes clouds (Amazon S3, Windows Azure, Nirvanix e DivShare) e nas três versões do DEPSKY


Na figura 5.3(a) observa-se uma larga discrepância entre os resultados observadospara a Nirvanix e a Divshare quando comparados com os resultados da Azure e da S3.Também se manteve a tendência verificada nos dados de 1M, a Nivanix continua a mostarser o serviço com melhor tempo de resposta. Em particular, no decorrer destas medidasobservou-se um acentuado período de indisponibilidade da Azure (ver tabela 5.3), o queé representado no gráfico pelos cerca de 20% de resultados que não estão na figura.

No que diz respeito às diversas versões do DEPSKY, a figura 5.3(b) mostra que nestecaso a replicação dos dados em diversas clouds diminui de forma significativa a latênciade leitura dos dados, mesmo na versão optimizada em que não se tenta ler de várias cloudsmas apenas da que retornou os metadados mais rapidamente.

De notar também que o uso da primitiva de partilha de segredos para confidencialidade


(protocolo CADS), torna o DEPSKY muito menos eficiente já que se têm de obter os dadosde duas clouds diferentes, ao invés de apenas de uma (como acontece no ADS e no ADScom leitura optimizada).

Falhas

Durante as experiências foram observadas várias falhas no acesso aos sistemas dearmazenamento, conforme reportado na tabela 5.3.

Dados (bytes) Todas falharam Amazon S3 Azure Nirvanix100K 1 0 0 11M 1 9 13 2

10M 0 0 10+10hs 7

Tabela 5.3: Número de falhas observadas durante as experiências de leitura. O “10+10hs”para a Azure na experiência de 10M significa que para além das 10 falhas reportadashouve um período de 10 horas onde mais de 95% dos acessos individuais a este sistemafalharam.

Durante as experiências observou-se um período de instabilidade e indisponibilidadena cloud Azure entre as 11 e as 21 horas do dia 10 de Junho. Neste período mais de 95%

das leituras dos dados falharam com a mensagem de erro “Unable to read complete datafrom server”.

Para além deste evento, o número de operações mal sucedidas é bastante pequeno setivermos em conta a quantidade total de operações executadas (14202 em cada cloud). Éde salientar que o DEPSKY falhou apenas duas vezes, quando todas as clouds estavamindisponíveis. Estas falhas aconteceram possivelmente devido a problemas de conectivi-dade na saída da rede do DI/FCUL.

5.2.3 Latência de Escrita

Para fins de completude da avaliação são reportados na tabela 5.4 os tempos médiosde escrita em diferentes configurações (obtidos a partir de um conjunto de 100 escritaspara cada tamanho de unidade de dados, executadas no dia 14 de Junho).

Dados DEPSKY-ADS DEPSKY-CADS Amazon S3 DivShare Azure Nirvanix100K 1767 2790 2336 3287 2801 28021M 4376 4928 5640 4684 3823 2626

10M 20315 24012 32204 8298 20017 4816

Tabela 5.4: Latência média (ms) de escrita para diferentes tamanhos de unidades de dados,configurações do DEPSKY e clouds de armazenamento.

Estes resultados mostram que algumas clouds (Divshare e Nirvanix) apresentam poucoaumento de latência quando passamos a escrever altos volumes de dados, enquanto outras


(Azure e S3), apresentam uma perda de desempenho proporcional ao tamanho dos dadossendo escritos. O desempenho das versões do DEPSKY é similar a estas versões maislentas na medida que os protocolos de escrita requerem a confirmação de escrita em 3 das4 clouds utilizadas.


Neste capítulo foi efectuada uma avaliação experimental aos protocolos concretizadosno DEPSKY (ADS e CADS) assim como uma análise crítica aos resultados verificados.Mais especificamente, foram avaliados os custos e medida a latência, para operações deleitura e escrita, em 4 clouds e através da utilização do DEPSKY.

Para finalizar este relatório, no próximo capítulo são apresentadas as conclusões e otrabalho futuro.

Capítulo 6

Conclusões e Trabalho Futuro

6.1 Conclusões

Construir sistemas de armazenamento de maneira distribuída é muito atractivo, porquea disponibilidade da informação pode ser aumentada significativamente.

Algoritmos de armazenamento distribuído podem ser optimizados para forneceremum nível elevado de coerência, disponibilidade e resiliência, enquanto ao mesmo tempoinduzem um overhead muito pequeno em comparação com uma solução centralizada efalível. Não é de surpreender que através da combinação de propriedades de armazena-mento desejáveis incorrem diferentes tradeoffs.

No entanto, vale a pena mencionar que, na prática, sistemas de armazenamento distri-buído enfrentam outros desafios, como sobrevivência, interoperabilidade, escalabilidadee balanceamento de carga.

Neste trabalho foi apresentado o DEPSKY, um sistema que garante disponibilidade,integridade e confidencialidade de informação armazenada na cloud. Com estas garantiaspode-se definir o DEPSKY como um sistema confiável e seguro. Para garantir a disponi-bilidade do sistema a informação é replicada por várias clouds. A confidencialidade dainformação é garantida nas clouds, através da utilização de um esquema de partilha desegredos, que permite a divisão da informação pelas clouds de maneira a que nenhumadelas possua a informação na íntegra, e ponto-a-ponto na Internet, através da utilizaçãode HTTPS.

Na avaliação de resultados mostrou-se que o DEPSKY não fica muito aquém, em ter-mos de desempenho, dos serviços testados. Pode-se afirmar que com o DEPSKY temossempre o melhor serviço independentemente das condições que cada cloud de armazena-mento experiencia individualmente.

Além disso, os resultados demonstram a viabilidade económica (especialmente paracargas de trabalho com bastantes mais leituras que escritas) e os benefícios em termos dedesempenho e disponibilidade do sistema.

47

Capítulo 6. Conclusões e Trabalho Futuro 48

6.2 Trabalho Futuro

O trabalho futuro deverá passar pela inclusão de códigos de apagamento no sistema.O propósito será diminuir o tamanho dos blocos armazenados (de forma similar ao RAID[29] e permitir uma avaliação da disponibilidade e desempenho do DEPSKY a partir dediferentes locais no mundo. Esta avaliação também deverá ser realizada usando dife-rentes configurações de clouds, desenvolvendo-se novos controladores (para serviços nãocontemplados neste trabalho) se tal for necessário.

Referências

[1] Amazon Simple Storage Service (https://s3.amazonaws.com), June 2010.

[2] Box.net (http://www.box.net), June 2010.

[3] DivShare (http://www.divshare.com), June 2010.

[4] DocStoc (http://www.docstoc.com), June 2010.

[5] FilesAnywhere (http://www.filesanywhere.com), June 2010.

[6] Inforum2010 (http://inforum.org.pt/INForum2010), September 2010.

[7] Java Secret Sharing (http://www.navigators.di.fc.ul.pt/software/jitt/jss.html), June 2010.

[8] Microsoft Windows Azure Platform (http://www.windowsazure.com),June 2010.

[9] Nirvanix Storage Delivery Network (http://www.nirvanix.com), June2010.

[10] RackSpace CloudFiles (http://www.rackspace.com), June 2010.

[11] Alysson Neves Bessani, Eduardo Pelison Alchieri, Miguel Correia, and Joni SilvaFraga. Depspace: a byzantine fault-tolerant coordination service. In Eurosys ’08:Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on ComputerSystems 2008, pages 163–176, New York, NY, USA, 2008. ACM.

[12] Alysson Neves Bessani, Miguel Correia, and Paulo Sousa. Active quorum systems:Specification and correction proof. Technical report, Department of Informatics,Faculty of Sciences, University of Lisbon, December 2008.

[13] Kevin D. Bowers, Ari Juels, and Alina Oprea. HAIL: a high-availability and inte-grity layer for cloud storage. In CCS ’09: Proceedings of the 16th ACM conferenceon Computer and communications security, pages 187–198, New York, NY, USA,2009. ACM.

49

https://s3.amazonaws.com

http://www.box.net

http://www.divshare.com

http://www.docstoc.com

http://www.filesanywhere.com

http://inforum.org.pt/INForum2010

http://www.navigators.di.fc.ul.pt/software/jitt/jss.html

http://www.navigators.di.fc.ul.pt/software/jitt/jss.html

http://www.windowsazure.com

http://www.nirvanix.com

http://www.rackspace.com

Referências 50

[14] Christian Cachin and Stefano Tessaro. Asynchronous verifiable information disper-sal. In DISC, pages 503–504, 2005.

[15] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance and proac-tive recovery. ACM Transactions on Computer Systems (TOCS), 20(4):398–461,November 2002.

[16] Gregory Chockler, Rachid Guerraoui, Idit Keidar, and Marko Vukolic. ReliableDistributed Storage. Computer, 42(4):60–67, 2009.

[17] Miguel Correia. Serviços distribuídos tolerantes a intrusões: resultados recentese problemas abertos. In V Simpósio Brasileiro em Segurança da Informação e deSistemas Computacionais - Livro Texto dos Minicursos, pages 113–162. SociedadeBrasileira de Computação, September 2005.

[18] Miguel Correia, Nuno Ferreira Neves, Lau Cheuk Lung, and Paulo Veríssimo. Lowcomplexity byzantine-resilient consensus. Distributed Computing, 17(3):237–249,2005.

[19] Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility ofdistributed consensus with one faulty process. In PODS ’83: Proceedings of the 2ndACM SIGACT-SIGMOD symposium on Principles of database systems, pages 1–7,New York, NY, USA, 1983. ACM.

[20] J. Fraga and D. Powell. A fault- and intrusion-tolerant file system. In In Proceedingsof the 3rd International Conference on Computer Security, pages 203–218, 1985.

[21] David K. Gifford. Weighted voting for replicated data. In SOSP, pages 150–162,1979.

[22] L. Princehouse H. Abu-Libdeh and H. Weatherspoon. RACS: A case for cloudstorage diversity. ACM Symposium on Cloud Computing (SOCC), June 2010.

[23] Maurice Herlihy. Wait-free synchronization. ACM Transactions on ProgrammingLanguages and Systems (TOPLAS), 13(1):124–149, 1991.

[24] Hugo Krawczyk. Distributed fingerprints and secure information dispersal. InPODC ’93: Proceedings of the twelfth annual ACM symposium on Principles ofdistributed computing, pages 207–218, New York, NY, USA, 1993. ACM.

[25] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system.Commun. ACM, 21(7):558–565, 1978.

[26] Leslie Lamport. On Interprocess Communication. Part I: Basic Formalism. Distri-buted Computing, 1(2):77–85, 1986.

Referências 51

[27] Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine Generals Pro-blem. ACM Trans. Program. Lang. Syst., 4(3):382–401, 1982.

[28] Dahlia Malkhi and Michael Reiter. Byzantine Quorum Systems. Distributed Com-puting, 11(4):203–213, October 1998.

[29] David A. Patterson, Garth Gibson, and Randy H. Katz. A case for redundant arraysof inexpensive disks (RAID). In SIGMOD ’88: Proceedings of the 1988 ACM SIG-MOD international conference on Management of data, pages 109–116, New York,NY, USA, 1988. ACM.

[30] Bruno Quaresma, Alysson Bessani, and Paulo Sousa. Melhorando a Disponibilidadee Confidencialidade dos Dados Armazenados em Clouds. In 2a edição do INForum- Segurança de Sistemas de Computadores e Comunicações, 2010.

[31] Berry Schoenmakers. A simple publicly verifiable secret sharing scheme and itsapplication to electronic. In CRYPTO ’99: Proceedings of the 19th Annual Interna-tional Cryptology Conference on Advances in Cryptology, pages 148–164, London,UK, 1999. Springer-Verlag.

[32] Adi Shamir. How to Share a Secret. Commun. ACM, 22(11):612–613, 1979.

[33] P. E. Veríssimo, N. F. Neves, and M. P. Correia. Intrusion-tolerant architectures:Concepts and design. In R. Lemos, C. Gacek, and A. Romanovsky, editors, Archi-tecting Dependable Systems, volume 2677. 2003.

UNIVERSIDADE DE LISBOA Faculdade de...

Documents

Transcript of UNIVERSIDADE DE LISBOA Faculdade de...