“Dedupeer: um Algoritmo para Deduplicação de Arquivos
Através de Processamento Particionado”
Por
Paulo Fernando Almeida Soares
Dissertação de Mestrado
Universidade Federal de Pernambuco [email protected]
www.cin.ufpe.br/~posgraduacao
Universidade Federal de Pernambuco
Centro de Informática
Pós-graduação em Ciência da Computação
Paulo Fernando Almeida Soares
“Dedupeer: um Algoritmo para Deduplicação de
Arquivos Através de Processamento Particionado”
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Silvio Romero de Lemos Meira Co-Orientador: Vinicius Cardoso Garcia
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
Soares, Paulo Fernando Almeida
Dedupeer: um algoritmo para deduplicação de arquivos através de processamento particionado. / Paulo Fernando Almeida Soares. - Recife: O Autor, 2013.
xvi, 100 f., il., fig., tab.
Orientador: Silvio Romero de Lemos Meira.
Dissertação (mestrado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2013.
Inclui referências e apêndice.
1. Sistemas distribuídos. 2. Deduplicação de dados. I. Meira, Silvio Romero de Lemos (orientador). II. Título.
Dissertação de Mestrado apresentada por Paulo Fernando Almeida Soares à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “Um Algoritmo para Deduplicação de Arquivos
Através de Processamento Particionado” orientada pelo Prof. Silvio Romero de Lemos Meira e aprovada pela Banca Examinadora formada pelos professores:
______________________________________________ Prof. Vinicius Cardoso Garcia
Centro de Informática / UFPE
______________________________________________ Prof. Manoel Gomes de Mendonça Neto
Departamento de Ciência da Computação /UFBA
_______________________________________________ Prof. Rodrigo Elia Assad
Departamento de Estatística e Informática / UFRPE
Visto e permitida a impressão. Recife, 28 de agosto de 2013.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Eu dedico esta dissertação à minha tia Joarina (in memorian) por todo o apoio e incentivo em meus estudos.
Resumo
A deduplicação é uma técnica de compressão de dados sem perda que elimina dados redundantes tanto intra-file como inter-file, diferente de ferramentas de compressão de dados como o gzip que só eliminam a redundância intra-file. A deduplicação reduz a necessidade de armazenamento através da eliminação de blocos de dados redundantes. Na deduplicação, todos os blocos de dados que estão duplicados em um sistema de armazenamento podem ser reduzidos à uma única cópia, esses blocos desalocados pela deduplicação são transformados em referência para o que foi mantido no sistema.
Técnicas de deduplicação começaram a ser estudadas para sistemas de armazenamento comerciais em meados de 2004. Hoje, os principais sistemas de armazenamento de dados usam deduplicação, mas os algoritmos implementados e as técnicas utilizadas não são detalhadas publicamente. Existem alguns trabalhos acadêmicos focados na implementação de algoritmos de deduplicação, mas eles são raros e não são voltados para a sua utilização em sistemas de armazenamento existentes. O principal objetivo deste trabalho é criar um algoritmo para deduplicação de arquivos no cliente de forma remota, através de processamento particionado e utilizando comparação por fingerprints. Este algoritmo foi incorporado em um componente de software com interface interoperável para facilitar a utilização em qualquer sistema de armazenamento de dados e beneficiá-los com economia de armazenamento, e na transferência de dados no caso dos sistemas de armazenamento distribuídos.
Além do componente de software, foi desenvolvido também um sistema de armazena-mento com gerenciaarmazena-mento de dados baseado no Apache Cassandra, o que o torna capaz de ser distribuído, com o objetivo de validar o algoritmo de deduplicação. A integração do componente de software com o sistema de armazenamento foi implementada e avaliada neste trabalho.
Palavras-chave: Deduplicação, compressão de dados, economia de armazenamento, sistemas de armazenamento de dados
Abstract
The deduplication is a technique for lossless data compression that eliminates redun-dant data intra-file and inter-file, different data compression tools like gzip only eliminates the redundancy intra-file. The deduplication reduces storage needs through eliminating redundant blocks. In the deduplication, all data blocks or files that are duplicates in a storage system are reduced to a solely copy, and the unallocated data are transformed in reference to the data content maintained in the system.
Deduplication techniques began to be studied in mid-2004. Today, the main storage systems use deduplication, but the algorithms implemented and the techniques used are not detailed. There are researches focused in the implementation of algorithms, but they are rare and the main goal not is the integration with the existing systems. The main aim of this research is to create an algorithm to deduplication of files on the source with remote data, through of the partitioned processing and using of fingerprint comparisons. This algorithm was integrated in a software component with interoperable interface to facilitate the using in any storage system and benefit them with storage economy, and in the data transfer when the system was distributed.
Besides the software component was developed also a storage system with data management made with the Apache Cassandra, which make it able to be distributed with the goal to validate the deduplication algorithm. The integration of the software component with the storage system was implemented and evaluated in this research.
Agradecimentos
Primeiramente eu gostaria de agradecer ao meu orientador e co-orientador, Silvio Meira e Vinicius Garcia, respectivamente, por toda a dedicação para me ajudar a tornar possível a realização desse meu sonho.
Minha família, em especial para minha mãe e minha tia Joarina por todo o apoio e incentivo que me deram nos meus estudos.
Meus amigos da Usto.re, Rodrigo Assad, Anderson Fonseca, Francisco Soares, Marco Machado e Thiago Jamir por sempre estarem dispostos a me ajudar nos desafios técnicos que enfrentei.
Todos os meus amigos do CIn, em especial para os mais presentes: Thiago Vieira, Lenin Ernesto, Marco Machado, Jamilson Batista, Adriano Tito, Rodolfo Arruda, Dhiego Abrantes, Francisco Airton, João Emanoel, Bruno Felipe e Kellyton Brito.
Eduardo Almeida pelo grande apoio, ajuda e conselhos.
Tassio Vale pelas conversas sobre o Mestrado e por me mostrar o quão bom seria estudar na UFPE.
Rogério por me receber em seu apartamento nos meus primeiros meses no Recife. Frederico Durão pela ajuda na estruturação da dissertação.
Minhas amigas forrozeiras, Natália, Dalyla, Ione, Anne e Ana Tereza, as pessoas mais animadas de todo o Pernambuco.
E a todos os que contribuiram direta e indiretamente para que este trabalho fosse realizado!
Lista de Figuras
1.1 Aumento da demanda e redução do custo de hardware de armazenamento
(gráfico baseado em Kaplan et al. [21]). . . 1
2.1 Armazenamento dos super-chunks nos nós [46]. . . 11
2.2 Processo do algoritmo do FERAPARDA . . . 15
2.3 Exemplo da economia de espaço oferecida em um sistema de armazena-mento com 20% de alteração nos dados. . . 20
3.1 Diagrama de componentes de alto nível da biblioteca do Dedupeer . . . 23
3.2 Modelo de dados do sistema distribuído desenvolvido com o Cassandra 28 3.3 Visão de componentes e conectores do DeFS integrado com a biblioteca do Dedupeer . . . 30
4.1 Desempenho na serialização dos dados [39] . . . 42
4.2 Desempenho na desserialização dos dados [39] . . . 43
5.1 Funcionamento do algoritmo 1. . . 51
5.2 Funcionamento do algoritmo 2 . . . 55
5.3 Vantagem da utilização da carga extra de dados . . . 59
6.1 Tempo em milissegundos para as execuções da operação de armazena-mento utilizando MD5 . . . 64
6.2 Tempo em milissegundos para as execuções da operação de armazena-mento utilizando SHA-1 . . . 64
6.3 Tempo em milissegundos para as execuções da operação de armazena-mento, separadas por tamanho de chunk . . . 65
6.4 Tempo em milissegundos das execuções da operação de deduplicação, separadas por tamanho de chunk, utilizando SHA-1 . . . 67
6.5 Tempo em milissegundos das execuções da operação de deduplicação, separadas por tamanho de chunk, utilizando MD5 . . . 67
6.6 Tempo em milissegundos das execuções da operação de deduplicação + armazenamento, separadas por tamanho de chunk, utilizando SHA-1 . . 69
6.7 Tempo em milissegundos das execuções da operação de deduplicação + armazenamento, separadas por tamanho de chunk, utilizando MD5 . . . 70
LISTA DE FIGURAS
6.8 Tempo em milissegundos das execuções da operação de reidratação,
separadas por tamanho de chunk, utilizando SHA-1 . . . 71
6.9 Tempo em milissegundos das execuções da operação de reidratação,
separadas por tamanho de chunk, utilizando MD5 . . . 71
6.10 Mapa de chunks deduplicados da versão 3.10-rc7 do código-fonte do Kernel do Linux processado com os chunks da versão 3.9.8, para chunks
com tamanho 128, 64, 32, 16 e 8KB . . . 72
6.11 Tamanho em megabytes ocupado pelo arquivo no sistema, com a
porcen-tagem de economia alcançada . . . 74
6.12 Mapa de chunks deduplicados da máquina virtual Linux 12.10 atualizada processada com os chunks da mesma máquina virtual sem atualização,
para chunks com tamanho 128, 64, 32, 16 e 8KB . . . 74
C.1 Tempo emparelhado para a operação de armazenamento com chunks de
128KB . . . 90
C.2 Tempo emparelhado para a operação de armazenamento com chunks de 64KB . . . 91
C.3 Tempo emparelhado para a operação de armazenamento com chunks de 32KB . . . 91
C.4 Tempo emparelhado para a operação de armazenamento com chunks de 16KB . . . 92
C.5 Tempo emparelhado para a operação de armazenamento com chunks de 8KB . . . 92
C.6 Tempo emparelhado para a operação de deduplicação com chunks de
128KB . . . 93
C.7 Tempo emparelhado para a operação de deduplicação com chunks de 64KB 93
C.8 Tempo emparelhado para a operação de deduplicação com chunks de 32KB 94
C.9 Tempo emparelhado para a operação de deduplicação com chunks de 16KB 94
C.10 Tempo emparelhado para a operação de deduplicação com chunks de 8KB 95
C.11 Tempo emparelhado para a operação de deduplicação + armazenamento
com chunks de 128KB . . . 95
C.12 Tempo emparelhado para a operação de deduplicação + armazenamento
com chunks de 64KB . . . 96
C.13 Tempo emparelhado para a operação de deduplicação + armazenamento
LISTA DE FIGURAS
C.14 Tempo emparelhado para a operação de deduplicação + armazenamento
com chunks de 16KB . . . 97
C.15 Tempo emparelhado para a operação de deduplicação + armazenamento
com chunks de 8KB . . . 97
C.16 Tempo emparelhado para a operação de reidratação com chunks de 128KB 98
C.17 Tempo emparelhado para a operação de reidratação com chunks de 64KB 98
C.18 Tempo emparelhado para a operação de reidratação com chunks de 32KB 99
C.19 Tempo emparelhado para a operação de reidratação com chunks de 16KB 99
Lista de Tabelas
3.1 Força do consistência baseada nos níveis das operações [7] . . . 34
6.1 p-values para os dados capturados na operação de armazenamento . . . 66
Lista de Acrônimos
CPU Central Processing Unit CTO Chief Technology Officer DDR2 Double Data Rate DE Delta Encoding
DeFS Dedupeer File Storage DHT Distributed Hash Table
EPA Environmental Protection Agency FBH Fixed Block Hashing
FIFO First In First Out GSI Green Storage Initiative GUI Graphical User Interface
HDFS Hadoop Distributed File System I/O Input/Output
JXTA Juxtapose
MD5 Message-Digest Algorithm 5 NoSQL Not only SQL
P2P Peer-to-peer
RAM Random-Access Memory RPC Remote Procedure Call SAN Storage Area Network SHA-1 Secure Hash Algorithm SQL Structured Query Language
LISTA DE TABELAS
SSD Solid State Drive
TI Tecnologia da Informação VBH Variable Block Hashing VDI Virtual Disk Image
Sumário
Lista de Acrônimos xi 1 Introdução 1 1.1 Motivação . . . 3 1.2 Definição do problema . . . 4 1.3 Resultados esperados . . . 4 1.4 Escopo negativo . . . 5 1.5 Contribuições . . . 6 1.6 Sumário . . . 6 2 Trabalhos relacionados 8 2.1 Sistemas de armazenamento de dados com foco em deduplicação . . . . 82.1.1 Trabalho de Kathpal et al. . . 9
2.1.2 Trabalho de Kaiser et al. . . 9
2.1.3 Σ-Dedup . . . 10
2.1.4 Dropbox . . . 12
2.1.5 Conclusão sobre os sistemas com foco em deduplicação . . . . 13
2.2 Algoritmos para eliminação de redundância de dados . . . 13
2.2.1 FERAPARDA . . . 14
2.2.2 DYNABYTE . . . 14
2.2.3 Trabalho de Langille et al. . . 16
2.3 Deduplicação . . . 17 2.3.1 Localização . . . 17 Cliente (source) . . . 17 Servidor (target) . . . 18 2.3.2 Momento . . . 18 2.3.3 Algoritmo. . . 19 2.3.4 Benefícios . . . 20 2.4 Sumário do capítulo . . . 21
3 O Dedupeer File Storage 22 3.1 Introdução . . . 22
3.1.1 Escopo . . . 22
LISTA DE TABELAS
3.2.1 Modelo de dados . . . 23
3.3 Visão de componentes e conectores . . . 29
O componente Dedupeer File Storage . . . 29
O componente Dedupeer . . . 30
3.4 Decisões de projeto e considerações . . . 31
3.4.1 Tamanho do chunk . . . 31
3.4.2 Cassandra para gerenciamento do armazenamento . . . 31
Tolerância à falhas . . . 33
Recuperação de falhas . . . 33
Consistência . . . 34
Disponibilidade . . . 34
Empacotamento de requisições. . . 35
3.4.3 Alternativa para o gerenciamento de armazenamento . . . 35
Facilidade de instalação e manutenção . . . 35
Clusterspequenos . . . 35
3.4.4 Escalabilidade . . . 36
O que é escalabilidade?. . . 36
Escalabilidade com o Cassandra . . . 37
3.5 Sumário do capítulo . . . 37
4 Componente para deduplicação em sistemas de armazenamento de dados 38 4.1 Introdução . . . 38
4.2 Interoperabilidade . . . 39
4.2.1 Interoperabilidade de comunicação através do Thrift . . . 39
4.2.2 Comparação com o Protocols Buffer . . . 41
Protocols Buffer . . . 41
Comparação de desempenho . . . 42
4.2.3 Comparação por hash (fingerprints) . . . 42
Vantagem . . . 44 4.3 Sumário do capítulo . . . 45 5 Os algoritmos 46 5.1 Fundamentos . . . 46 5.1.1 O algoritmo Rsync . . . 46 Rolling checksum . . . 47 5.1.2 Fingerprinting . . . 48
LISTA DE TABELAS
5.2 Detalhando os algoritmos . . . 49
5.2.1 Algoritmo para deduplicação com carga completa do arquivo na memória . . . 49
5.2.2 Algoritmo com deduplicação particionada . . . 54
5.3 Sumário do capítulo . . . 60
6 Análise de desempenho 61 6.1 Datasets . . . 61
6.2 Análise de desempenho utilizando o código fonte do Kernel do Linux . 63 Operação de armazenamento . . . 63
Operação de deduplicação . . . 66
Operação de deduplicação + armazenamento . . . 68
Operação de reidratação . . . 70
6.2.1 Mapa de chunks deduplicados . . . 72
6.3 Análise de economia utilizando máquinas virtuais . . . 73
6.4 O Ustore . . . 75 6.5 Sumário do capítulo . . . 75 7 Conclusão 77 7.1 Trabalhos futuros . . . 78 Referências Bibliográficas 80 A Apêndice 85 A.1 Arquivo de definição dos serviços Thrift . . . 85
B Apêndice 87 B.1 Resultados da avaliação dos arquivos do código fonte do Kernel do Linux 87 C Apêndice 90 C.1 Gráficos dos tempos emparelhados por tamanho de chunk para a operação de armazenamento . . . 90
C.2 Gráficos dos tempos emparelhados por tamanho de chunk para a operação de deduplicação . . . 93
C.3 Gráficos dos tempos emparelhados por tamanho de chunk para a operação de deduplicação + armazenamento . . . 95
LISTA DE TABELAS
C.4 Gráficos dos tempos emparelhados por tamanho de chunk para a operação
de reidratação . . . 98
1
Introdução
Com o aumento da capacidade das unidades de armazenamento, aumentou também a demanda por sua utilização. Em 2000, a estimativa da indústria era de um aumento anual entre 50% a 100% dessa demanda [26], estimativa essa que se consolidou. Nos últimos anos esse aumento atingiu um valor anual de mais de 50% [21].
A Figura 1.1 mostra dois gráficos com informações sobre demanda e preço do armazenamento entre os anos de 2006 e 2011. Um deles demonstra o forte crescimento da demanda por armazenamento nas empresas, e o segundo, exibe a queda de 20% ao ano no preço por Gigabytes.
Figura 1.1 Aumento da demanda e redução do custo de hardware de armazenamento (gráfico baseado em Kaplan et al. [21])
nos últimos anos. Empresas como Amazon1, Google2, Microsoft3e Salesforce4 come-çaram a investir em centros de armazenamentos de dados na nuvem (Cloud Storages), espalhados pelo mundo, com garantia de redundância e tolerância à falhas [47].
Com esse aumento da demanda por armazenamento, a utilização de técnicas de compressão de dados se torna um fator chave para redução dos custos. A compressão de dados é uma técnica que codifica informações, usando uma quantidade menor de dados que a original, para economizar espaço de armazenamento. As técnicas mais conhecidas de compressão de dados funcionam apenas com a compressão intra-file, ou seja, utilizando no processamento apenas os bytes do arquivo a ser comprimido, como exemplo, pode ser citado o formato de arquivo zip [32], que é um tipo de compressão sem perda. E também existe a compressão intra-file com perda de dados, que é o caso dos famosos formatos de arquivos jpg e mp3, o qual reduz a qualidade da imagem e do áudio, respectivamente, para obter uma redução no espaço necessário para armazenar o arquivo [35].
A deduplicação é um técnica de compressão sem perda que elimina dados redundantes tanto intra-file quanto inter-file, o que possibilita utilizar dados remotos para ajudar na compressão dos dados. Com a popularização dos sistemas de armazenamento distribuído em nuvem, a deduplicação ajudará muito na economia de espaço de armazenamento, já que ela pode utilizar informações em diferentes arquivo e entidades para economizar o espaço utilizado no sistema. A deduplicação de dados é um técnica de compressão que armazena uma única cópia de dados redundantes, eliminando as outras do sistema de armazenamento. Ela pode ser feita em nível de arquivo completo ou de chunks, os quais são blocos de dados pertencentes ao arquivo.
Muitos sistemas de backup atuais escolhem fazer o armazenamento dos arquivos em fitas magnéticas por serem mais baratas que os discos rígidos. A fita magnética tem a desvantagem de ter o acesso apenas sequencial dos dados, enquanto que no disco o acesso pode ser randômico. Com a utilização das fitas, a deduplicação dos dados se torna eficientemente inviável pela falta de capacidade em acesso randômico. Por esse fator, a deduplicação está tornando um diferencial na escolha dos discos rígidos como dispositivo de armazenamento dos backups, a vantagem do preço das fitas em relação aos discos é contornada pelo fato de que com os discos rígidos a deduplicação pode ser feita e como consequência o espaço de armazenamento é economizado [20].
1http://aws.amazon.com/pt/s3/
2http://www.google.com/enterprise/cloud/storage/ 3http://www.windowsazure.com
1.1. MOTIVAÇÃO
A utilização de deduplicação de dados em sistemas de armazenamento em nuvem dá uma grande vantagem à empresa que fornece o serviço. Com a utilização da deduplicação, a empresa poderá vender para os cliente mais espaço de armazenamento do que ela poderia fornecer em um sistema sem deduplicação, já que a deduplicação diminui a quantidade de bytes armazenados por arquivos no sistema, principalmente quando o mesmo arquivo em diferentes versões é salvo ou quando o mesmo arquivo é enviado para o sistema, mesmo que por usuários distintos.
Uma forma de aumentar os blocos de dados redundantes em sistemas de armaze-namento que possua arquivos com partes idênticas, é através da redivisão dos chunks baseado no conteúdo, e a partir disso, aumentar a quantidade de blocos de dados idênticos. Para que esse procedimento seja executado é preciso uma comparação byte à byte entre os arquivos, tarefa essa que demanda muito processamento e utilização de E/S (entrada e saída). Esse processo torna-se mais viável com a distribuição do processamento dos dados para a redefinição dos novos pontos de cortes dos chunks e utilização de algoritmos de hashing para identificar a redundância de dados.
1.1
Motivação
Os principais sistemas distribuídos de deduplicação de dados são feitos para serem executados em clusters [4] [10] [20] [48] ou em nós simples, alguns deles usam framework para processamento distribuído de dados [22], como Hadoop5por exemplo, mas é difícil encontrar trabalhos de pesquisa envolvendo sistemas de deduplicação para ambientes de armazenamento de dados construídos com arquitetura peer-to-peer sobre computadores pessoais para armazenar esses dados.
No desenvolvimento do Usto.re6, um sistema de armazenamento de dados distribuído que usa o espaço ocioso de computadores em rede para armazenamento de dados e que será utilizado para validação deste projeto em ambiente comercial, foi demandada a adoção de deduplicação de dados para reduzir o espaço de armazenamento para versões diferentes de um mesmo arquivo. Um pesquisa foi executada para identificar bibliotecas de código-fonte aberto com licença que não restrigisse o uso comercial para utilização da mesma e nenhuma foi encontrada.
Baseado nos fatos supracitados, este trabalho propõe o desenvolvimento de um componente de software para deduplicação de dados que pode ser integrado com qualquer
5"http://hadoop.apache.org/" 6"http://usto.re"
1.2. DEFINIÇÃO DO PROBLEMA
sistema de armazenamento de dados que tenha sido implementado em uma das linguagens suportadas pelo Thrift7, que é uma biblioteca para serialização de dados que suporta comunicação entre diferentes linguagens de programação. O componente será integrado a um sistema comercial de armazenamento de dados que foi construído em uma arquitetura peer-to-peer.
A deduplicação traz vários benefícios para o sistema que a utiliza, entre eles:
• Redução no espaço necessário para armazenar arquivos. Isso ajuda um sistema de armazenamento ser considerado dentro dos padrões da green storage, o qual será melhor detalhado no Capítulo4. Com a redução do espaço necessário para armazenar os arquivos, um sistema de armazenamento pode ser vendido com mais espaço do que ele possui fisicamente.
• Redução da quantidade de bytes trafegados, para o caso de sistemas distribuído, pois com a deduplicação feita na fonte os dados redundantes não são enviados. • Maior facilidade no gerenciamento de replicação de chunks, já que a deduplicação
reduz a quantidade deles.
1.2
Definição do problema
Algoritmos detalhados para deduplicação utilizando processamento de forma particio-nada são escassos. Existe também uma falta de componentes de softwares interoperáveis para deduplicação que possam ser integrados aos sistemas de armazenamento de dados existentes.
1.3
Resultados esperados
Esta pesquisa tem como principal objetivo desenvolver um algoritmo para dedupli-cação de dados, que faça processamento particionado e que seja interoperável e de fácil integração com os sistemas existentes. Este algoritmo deverá ser disponibilizado como um componente de software, com uma interface de comunicação multilinguagem, para executar a deduplicação exata dos dados em sistemas de armazenamento. Ele deverá ser integrado ao sistema de armazenamento que será desenvolvido como parte da pesquisa e com um sistema distribuído de armazenamento de dados comercial.
1.4. ESCOPO NEGATIVO
O algoritmo a ser desenvolvido nesta pesquisa deve resolver os três benefícios cita-dos na Motivação proporcionacita-dos pela deduplicação e com o mínimo de alteração no sistema de armazenamento para integrá-lo, isso porque o algoritmo será feito tendo a interoperabilidade e modificabilidade mínima para integração como alguns dos principais requisitos.
O algoritmo deve ser disponibilizado através de uma biblioteca com uma interface Thrift, que vai receber os valores de hash dos chunks e o arquivo a ser deduplicado, e retornará o arquivo deduplicado como um mapa dos chunks e das referências aos chunks redundantes.
O algoritmo deve fazer a busca por redundância baseada em conteúdo, independente da quantidade de bytes alterados, removidos ou adicionado entre duas versões de um arquivo ou entre arquivos distintos. O algoritmo será capaz de identificar as redundâncias se a sequência de bytes não modificados for no mínimo do tamanho padrão do chunk.
1.4
Escopo negativo
Deduplicação através de chunks maiores que 128KB está fora do escopo da pesquisa, pelo fato da detecção de redundância diminuir com o aumento do tamanho do chunk e este ser o tamanho padrão do Ustore, o sistema comercial de backup de dados onde o Dedupeer será implantado. Também foi definido como limite mínimo de tamanho de chunk 8KB. Apesar de conseguir um maior ganho de redução de espaço com chunks menores, o tempo para processamento e a quantidade de chunks gerados começa a degradar muito o desempenho do sistema.
O Dedupeer File Storage será desenvolvido utilizando o Cassandra8, que é um banco de dados distribuído que utiliza arquitetura P2P, mas está fora de escopo o teste do sistema de forma distribuída. Todos os testes serão feitos localmente, já que serão suficientes para avaliar o algoritmo de deduplicação.
Os testes do algoritmo funcionando com deduplicação no alvo, tanto post-processing, que é a deduplicação feita depois que os dados são armazenados, como inline, que é a deduplicação onde os dados são processados no momento em que chegam no alvo e antes de serem armazenados, estão fora do escopo do trabalho. Estes tipos de deduplicação serão descritos na Seção2.3.2.
Por serem os algoritmo de hashing mais comuns em processamentos de deduplicação de dados, os testes só serão feitos com MD5 e SHA-1.
1.5. CONTRIBUIÇÕES
1.5
Contribuições
As principais contribuições desta pesquisa serão:
• O algoritmo para deduplicação de dados com processamento particionado encapsu-lado em um componente de software interoperável. Essa forma de processamento torna possível fazer a deduplicação de arquivos muito maiores do que a memória principal, já que a configuração do tamanho da carga dos bytes para a memória, independente do tamanho do arquivo, será configurável no algoritmo.
• O sistema de armazenamento de dados distribuído, com código-fonte aberto, ad-ministrável através de interface gráfica e com gerenciamento de armazenamento delegado para um banco de dados não-relacional construído em uma arquitetura peer-to-peercom topologia de anel.
• A melhoria da descoberta de redundância de dados através da carga extra de dados no processamento particionado, possibilitando a diminuição da perda de identificação por causa da quebra do arquivo.
1.6
Sumário
Neste capítulo foi apresentada uma introdução sobre o crescimento da demanda por sistemas de armazenamento de dados e a importância da deduplicação para a economia de espaço nos tempos onde os sistemas de cloud storage estão sendo cada vez mais utilizados.
Este trabalho está dividido em sete Capítulos e um Apêndice.
No Capítulo2serão descritos como funcionam alguns sistemas de armazenamento de dados que utilizam deduplicação. Em seguida será feita uma introdução sobre quais são os tipos de deduplicação existentes e quais os benefícios que ela pode trazer.
No Capítulo3será detalhada a arquitetura do Dedupeer File Storage, que é o sistema de armazenamento de arquivos desenvolvido neste trabalho, e serão discutidas algumas decisões de projeto relacionadas à construção desse sistema.
No Capítulo 4 será detalhado o funcionamento do componente de software que disponibilizará o algoritmo de deduplicação como um serviço. Será discutida a intero-perabilidade do componente e quais poderiam ser as alternativas à biblioteca que foi escolhida, também será discutida a decisão de utilização da comparação por hash e quais são as suas vantagens e desvantagens.
1.6. SUMÁRIO
O Capítulo5detalhará os dois algoritmos de deduplicação desenvolvidos na pesquisa, tanto o algoritmo mais simples como o algoritmo de processamento particionado, que é a principal contribuição deste trabalho. Serão apresentados os fundamentos do algoritmo desenvolvido para identificação de redundância entre arquivos remotos, os quais serviram de base para os algoritmos desenvolvidos. Serão detalhados também os pseudocódigos de alto nível dos dois algoritmos criados.
O Capítulo 6apresentará os testes de desempenho e compressão executados para demonstrar a eficiência do algoritmo de deduplicação e o sistema de armazenamento de dados desenvolvidos.
E o Capítulo7apresentará as conclusões sobre o trabalho e algumas propsotas para trabalhos futuros.
2
Trabalhos relacionados
Neste capítulo, os conceitos e técnicas fundamentais sobre os assuntos relevantes para o entendimento dessa pesquisa serão discutidos. Serão discutidos os principais trabalhos relacionados à sistemas de armazenamento de dados com foco em deduplicação, os quais serão detalhados afim de identificar conceitos e técnicas que aprimorem o desenvolvimento do projeto Dedupeer, o qual é dividido em dois, o Dedupeer File Storage e o componente de software que implementa o algoritmo de deduplicação chamado de Dedupeer.
Primeiramente vai ser feito um estudo com alguns dos sistemas de armazenamento de dados que utilizam deduplicação para identificar as técnicas e os conceitos, e com isso, analisar quais as que melhor servirão de base para o desenvolvimento do Dedupeer File Storage. A análise feita nesses sistemas servirá para que uma melhor estratégia para o processamento da deduplicação seja implementada no Dedupeer, com base nos princípios desejados para a execução do mesmo.
É pequeno o número de sistemas de armazenamento que declaram a utilização de deduplicação, e ainda menor os que detalham esse processo. Será apresentado o conceito de deduplicação de dados e quais são os seus tipos.
2.1
Sistemas de armazenamento de dados com foco em
deduplicação
Nesta seção serão descritos alguns dos sistemas pesquisados que têm como objetivo armazenamento de dados e que têm como um dos focos principais a deduplicação. Os trabalhos acadêmicos serão apresentados por ordem de ano de publicação.
2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM DEDUPLICAÇÃO
2.1.1
Trabalho de Kathpal et al.
Devido ao desafio cada vez mais comum em armazenar e gerenciar o crescente volume de dados gerados nos dias atuais, conhecido como Big Data[19], é importante pensar em arquiteturas escaláveis para que os sistemas consigam dar suporte a essa grande quantidade de dados. Uma proposta de um sistema escalável para dar suporte à deduplicação para grande volume de dados foi descrita em [22]. Diferente das pesquisas mais comuns para escalabilidade de sistemas de deduplicação, que geralmente têm o foco na otimização dos algoritmos de deduplicação e em formas de deduplicação de mais alto nível, como arquivos e objetos. [22] tem o trabalho direcionado para o projeto arquitetural do sistema e usa deduplicação em nível de bloco, que apesar de ter vantagens de velocidade, em contrapartida tem problemas no gerenciamento da enorme quantidade de blocos a serem processados.
O projeto descrito em [22] foi proposto para funcionar de forma otimizada em ambientes de cluster, o qual é um conjunto de computadores interligados através de um sistema distribuído com uma finalidade em comum. Suas rotinas de deduplicação offline de dados são executadas nestes cluster externos, isso é feito para que o processamento da deduplicação não dispute os recursos com as outras rotinas do sistema. Para a execução das tarefas foi usado o Apache Hadoop, que é um framework para computação distribuída baseado em Map/Reduce, o qual ajudou a aumentar a capacidade de escalabilidade do projeto.
Todo o processo para deduplicação dos dados é feito após o armazenamento no sistema, o que tem como desvantagem a necessidade do dado ser todo transferido para o destino, para que depois seja analisado para eliminação de blocos duplicados. Com isso, não existe a economia de banda que é obtida com a deduplicação feita no cliente.
2.1.2
Trabalho de Kaiser et al.
Em Kaiser et al.[20], é explicado sobre o funcionamento de um sistema que executa em cluster e utiliza um tipo de deduplicação que eles chamam de "exact deduplication", que recebe esse nome pelo fato do sistema conseguir detectar todos os chunks duplicados. Os sistemas com exact deduplication geralmente possuem chunks com tamanho entre 4KB e 16 KB. Sistemas que utilizam chunks grandes perdem muitas vezes a detecção da redundância, já a utilização de chunks muito pequenos, apesar de aumentar a chance de deduplicação, torna o sistema menos eficiente por causa da alta sobrecarga ocasionada pela alta quantidade deles.
2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM DEDUPLICAÇÃO
O HYDRAstor, descrito em [10], utiliza uma granularidade alta nos chunks (64KB) para a deduplicação. Ele não faz o compatilhamento dos dados entre os nós e distribui os chunks na rede através de uma DHT (Distributed Hashtable). A escolha da granularidade alta dos chunks é para aumentar o desempenho da deduplicação através da redução do envio de metadados.
O sistema em [20] foi projetado para trafegar a menor quantidade de dados possível na deduplicação para aumentar a escalabilidade do mesmo. Basicamente o que é trocado entre as máquinas do cluster são fingerprints. O sistema descrito foi baseado no dedupv1 [28], o qual faz deduplicação em discos de estado sólido (SSDs) para evitar gargalos de leitura e escrita de dados.
Ele é dividido nos seguintes componentes: deduplication nodes, shared storage, interconnect between deduplication nodes, clients and distributed coordination. Os deduplication nodessão responsáveis por grande parte das funções mais importantes para a deduplicação e gerenciamento dos dados no sistema, neles são feitas as quebras dos dados em chunks e em seguida o cálculo do fingerprint de cada um deles. Eles também retornam os pedidos de chunks para outros nós e são responsáveis pela escrita deles no containerde armazenamento.
Cada deduplication node tem acesso às várias partições em que os discos são divi-didos pela rede através de storage area network (SAN) [42], as quais são redes de alta velocidade para acesso à dados. Cada partição só é acessada por um único nó, caso esse nó falhe, a tarefa de gerenciamento da partição é passada para outro nó, essa é a responsabilidade do componente do sistema que é chamado de shared storage. A distributed coordinationé delegada para o Zookeeper1, um software de código aberto que integra o projeto Apache2e o qual é o responsável pela escolha dos nós mestres e da decisão de qual deduplication node assumirá o controle de determinada partição. Cada delegação de controle das partições para os nós são armazenadas no Zookeeper e gerenciada por um nó mestre, no caso de uma falha ocorrer nesse mestre, o Zookeeper elegerá outro nó para tomar o lugar do que falhou.
2.1.3
Σ-Dedup
O Σ-Dedup, que é descrito em [13], é um middleware de deduplicação de dados para data centerse cloud storages. O Σ-Dedup foi criado para otimizar a deduplicação de dados em clusters.
1http://zookeeper.apache.org/ 2http://apache.org
2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM DEDUPLICAÇÃO
O Σ-Dedup utiliza um conceito chamado de super-chunk, que é um agrupamento de chunksconsecutivos. Com os super-chunks são calculados um handprint que será enviado para um conjunto de nós, que já possui um índice de similaridade de todos os handprints dos super-chunks armazenados nele para aumentar a eficiência e diminuir a consulta ao disco. Os handprints dos super-chunks semelhantes são enviados para um mesmo nó para aumentar a probabilidade de encontrar chunks idênticos e com isso a eficiência da deduplicação. Com o handprint, os nós efetuam um cálculo para determinar a semelhança entre ele e os demais que estão armazenados no nó. Quando for encontrado o nó que possui um super-chunk mais semelhante ao que vai ser enviado, todos os fingerprints dos chunkspertencentes ao super-chunk serão enviados para o nó selecionado. Com esses fingerprintso nó verificará quais deles já estão armazenados e quais são novos. Depois dessa identificação, o nó pede ao cliente que está fazendo o backup apenas os chunks que não foram encontrados.
Na Figura2.1 os super-chunks do arquivo são identificados pelas letras. Eles são enviados para nós diferentes, já que a escolha do nó onde cada um deles será enviado no momento do backup depende da similaridade com os que estão armazenados nos nós.
A deduplicação no Σ-Dedup é feita à nível de nó, logo, podem existir chunks duplica-dos se eles estiverem armazenaduplica-dos em diferentes nós.
Figura 2.1 Armazenamento dos super-chunks nos nós [46].
A arquitetura do Σ-Dedup possui 3 componentes principais: o Backup Client, o Deduplication Server Clustere o Director.
O Backup Client tem como principal função fazer o backup e o restore dos arquivos. Ele é composto de três módulos, um deles é Data Partitioning que é o responsável pelo particionamento do arquivo e agrupamento dos chunks em super-chunks. O cálculo dos
2.1. SISTEMAS DE ARMAZENAMENTO DE DADOS COM FOCO EM DEDUPLICAÇÃO
fingerprintsé feito no módulo Chunk Fingerprinting que é uma camada abaixo do Data Partitioning. O terceiro e último módulo do Backup Client é o Similarity-aware Data Routing, é nesse módulo que é definido o nó de deduplicacação para o qual os dados serão enviados.
Por ser um sistema de deduplicação inline, o qual será descrito na seção2.3.2, os dados são avaliados antes do envio para os nós e só são transferidos os chunks que ainda não foram armazenados no sistema. Com isso, é economizada a banda de transferência da rede.
O Deduplication Server Cluster também possui três módulos: Similarity Index Loo-kup, Chunk Fingerprinting Cache e Parallel Container Management. Eles são responsá-veis respectivamente por retornar o índice de similaridade para o roteamento dos dados, pelo armazenamento dos fingerprints mais utilizados em um cache para facilitar a busca por chunks idênticos, e o último é o responsável pelo armazenamento de forma paralela dos chunks únicos nos containers.
Um outro trabalho similar ao Σ-Dedup, onde os dados são enviados para determinados nós baseados na similaridade, é o Extreme Binning [4].
2.1.4
Dropbox
Apesar de não haver nenhuma declaração explícita na homepage do Dropbox 3, segundo um artigo publicado no site Slight Paranoia, o mais popular sistema de armaze-namento de dados em cloud [3] utiliza deduplicação de dados entre arquivos de usuários distintos [40]. Se dois usuários enviarem o mesmo arquivo para o sistema, o Dropbox só armazenará um deles nos seus servidores.
Segundo o mesmo artigo, o CTO da empresa declarou que o Dropbox utiliza dedu-plicação no Forum oficial da empresa, respondendo à uma pergunta de um usuário que questionava o porquê de um arquivo de 750MB ser enviado tão rápido. Esse tópico não está mais hospedado no forum, mas a resposta do CTO para a pergunta "Woah! How did that 750MB file upload so quickly?"está no Slight Paranoia:
Dropbox tries to be very smart about minimizing the amount of bandwidth used. If we detect that a file you’re trying to upload has already been uploaded to Dropbox, we don’t make you upload it again. Similarly, if you make a change to a file that’s already on Dropbox, you’ll only have to upload the pieces of the file that changed. This works across all data on Dropbox, not
2.2. ALGORITMOS PARA ELIMINAÇÃO DE REDUNDÂNCIA DE DADOS
just your own account. There are no security implications [emphasis added] - your data is still kept logically separated and not affected by changes that
other users make to their data."
Com a explicação do CTO, fica claro que o Dropbox utiliza deduplicação de dados, mas o processo de deduplicação usado no Dropbox não é detalhado pela empresa.
2.1.5
Conclusão sobre os sistemas com foco em deduplicação
Todos os sistemas de armazenamento estudados utilizam armazenamento de dados baseado em chunks ou blocos de dados. Pelo fato de todos eles serem sistemas distribuídos para armazenamento de dados, precisam se preocupar com os problemas decorrentes desse tipo de sistema descritos no trabalho sobre o Dynamo [8], como: robustez e escalabilidade no balanceamento de carga, detecção de filiação e de falhas, entre outros, os quais serão melhor descritos na seção3.4.2. Como esse não é o foco principal do trabalho, para a resolução desses problemas foi adotado para o Dedupeer File Storage o banco de dados Cassandra, que funciona em uma rede P2P e já trata todos eles. Com essa escolha será possível dedicar um maior tempo no que realmente interessa no estudo, que é o desenvolvimento do algoritmo de deduplicação.
Os sistemas comerciais, como o Dropbox, não tem seus algoritmos ou processo de deduplicação detalhados publicamente, e os trabalhos acadêmicos não possuem seus algoritmos ou sistemas de deduplicação facilmente acessíveis para utilização em um sistema de armazenamento. Esses foram os principais fatos que despertaram o interesse em desenvolver um algoritmo, com um processo diferente dos descritos, de código-aberto e interoperável entre linguagens para ser facilmente integrado aos sistemas de armazenamento existente.
2.2
Algoritmos para eliminação de redundância de
da-dos
Nesta seção será descrito alguns dos trabalhos relacionados ao desenvolvimento de algoritmos para eliminação de redundância de dados. Apesar de não estarem totalmente relacionado à forma como o Dedupeer irá trabalhar, a abordagem dos algoritmos descritos poderá ajudar em algumas das decisões no desenvolvimento do mesmo. O principal foco do Dedupeer será deduplicação de arquivos, enquanto que os trabalhos abaixo descritos estão em áreas como eliminação de dados redundantes em banco de dados, tráfego
2.2. ALGORITMOS PARA ELIMINAÇÃO DE REDUNDÂNCIA DE DADOS
de redes de computadores e regiões de imagens. Como dito anteriormente, apesar de muitas empresas que trabalham com softwares para gerenciamento de armazenamento de dados terem seus próprios algoritmos de deduplicação, os detalhes sobre funcionamento, técnicas de otimização entre outros fatores que ajudariam a criação de novos algoritmos, não são reveladas por motivos comerciais.
2.2.1
FERAPARDA
Um trabalho desenvolvido na UFMG [34] apresenta um algoritmo paralelo e esca-lável para deduplicação de dados. O foco principal deste trabalho é a identificação de duplicações em bancos de dados, e não em arquivos armazenados, como o presente trabalho.
O trabalho apresentado por Santos et al. pode ser executado de forma paralela, e como consequência fazer processamento de grande conjunto de dados em um tempo viável. Em um teste apresentado neste trabalho, eles executaram o algoritmo em um cluster de 20 computadores e conseguiram realizar a detecção de duplicatas em um banco de dados com 1 milhão de registros em 7 minutos.
A Figura2.2mostra o processo de deduplicação do algoritmo. O processo de padroni-zação dos dados, chamado de Standardization não foi desenvolvido no trabalho descrito. A segunda etapa do processo, chamada de Blocking, tem por finalidade limitar o número de comparação entre os registros para que não inviabilize o processamento. Apesar de no caso geral uma quantidade n2de comparações ser necessaria, o algoritmo consegue eliminar várias dessas comparações. A fase de Pair comparison simplesmete pega todos os produtos cartesianos que foram gerados na fase de Blocking e compara os atributos, em busca de encontrar os registros duplicados, esta comparaçao pode ser simples ou levar em consideração erros de digitação e conseguir identificar registros que foram gravados com valores diferentes mas que representam o mesmo objeto. Por fim, a fase Classifier é responsável por classificar os resultados dos pares "não réplicas", "possiveis réplicas"e "réplicas". Uma função de similaridade é aplicada aos dados, e a depender do resultado, os pares são classificados em uma das três classes acima citadas.
2.2.2
DYNABYTE
DYNABYTE [15] é um algoritmo para identificação de redundância de dados em pacotes trafegados em redes de computadores. O algoritmo RTE - redundant traffic elimination, apesar de não estar classificado como algoritmo de deduplicação, tem o
2.2. ALGORITMOS PARA ELIMINAÇÃO DE REDUNDÂNCIA DE DADOS
Figura 2.2 Processo do algoritmo do FERAPARDA
mesmo propósito, que é o de eliminar dados redudntantes, e por isso será incluído como um dos trabalhos relacionados ao Dedupeer.
O principal objetivo deste trabalho é o de eliminar a redundância dos dados trafegados na rede, que segundo trabalhos citados no mesmo, está entre 15% a 60% de tudo que é trafegado na rede.
Os trabalhos desenvolvidos para RTE geralmente são executados dentro da camada de rede. Com uma abordagem diferente, o algoritmo SAMPLEBYTE, no qual o DY-NABYTE é baseado, é executado dentro dos sistemas finais, o que possibilita a sua utilização até em telefones celulares. Ele foi projetado para que pudesse ser configurado de forma a não consumir muita bateria dos dispositivos móveis, o que o tornou viável em ser utilizados por eles. O problema do SAMPLEBYTE é que ele exige uma pré-configuração baseada no treinamento dos dados, e a proposta do DYNABYTE é que essa configuração seja feita de forma dinâmica, sem a necessidade do treinamento.
Em Halepovic et al. [15] foi feita a coleta de todo o tráfego de rede do link de acesso da Universidade de Calgary. Foi coleta um total de oito traces, todos eles bidirecionais, chegando a um total de 233,6GB de dados. Os traces foram então separados em tráfego de entrada e saída e estudados separadamente. Para a avaliação foram utilizadas as métricas: economia de bytes, tempo de processamento e taxa de amostragem. Foram utilizados chunksde 64 bytes, um valor inviável para ser utilizado em algoritmos de deduplicação para grandes arquivos, mas que funciona bem na identificação de redundância para tráfego de rede.
Como o DYNABYTE é baseado no SAMPLEBYTE, o processo de funcionamento a ser descrito será o do SAMPLEBYTE. Ele usa uma tabela com 256 entradas, uma para cada valor possível de um byte. Os blocos são varridos byte a byte, o qual é escolhido com um marcador caso o seu correspondente na tabela esteja configurado. Após isso, o
2.2. ALGORITMOS PARA ELIMINAÇÃO DE REDUNDÂNCIA DE DADOS
seu fingerprint é computado através do algoritmo Jenkis Hash, algoritmo este que foi substituído pelo FNV Hash Function4para o DYNABYTE. Fingerprints serão detalhados na seção5.1.2.
Os principais benefícios do SAMPLEBYTE são: evita cálculo de fingerprints que não serão mais selecionados e limita a taxa de amostragem, o que resulta em um controle do custo de processamento. No modelo cliente-servidor os fingerprints só são necessários no servidor, deixando o cliente mais flexível para criar os marcadores dos chunks. O DYNABYTE conseguiu facilitar a configuração do SAMPLEBYTE mantendo os seus benefícios e taxa de economia.
2.2.3
Trabalho de Langille et al.
A proposta de Langille et al. [25] é um algoritmo eficiente para detecção de regiões duplicadas em imagens. Com o algoritmo proposto é possível identificar partes duplicadas dentro de uma mesma imagem, como por exemplo, quando se usa as ferramentas de clone do Phosothop, o que dá a possibilidade de encontrar adulterações em imagens. Para que a identificação seja realizada, é preciso que as regiões duplicadas da imagem tenham as mesmas dimensões e orientação. Por utilizar o algoritmo ZNCC (Zero-Mean Normalized Cross Correlation)5para identificação de similaridade é possivel identificar as regiões duplicadas até em imagens onde o algoritmo de compressão do JPEG tenha sido aplicado.
O algoritmo pode ser resumido nos seguintes passos:
• A imagem é segmentada em pequenos blocos sobrepostos
• Para cada um dos blocos é feita uma busca por outro bloco similar através do algoritmo ZNCC
• Os blocos são ordenados com base nas informações dos seus pixels através de uma técnica baseada no kd-tree6, o que coloca os blocos similares mais próximos um do outro. Com isso, a busca só precisa ser efetuada nos blocos vizinhos
• É aplicada uma série de operações morfológicas baseadas em cor, a qual é feita para eliminação de possíveis erros do resultado. Fica provado no trabalho que esta técnica reduz eficientemente os erros que podem ocorrer na busca por regiões duplicadas
4"http://www.isthe.com/chongo/tech/comp/fnv/index.html"
5ZNCC em Python:
"https://github.com/MartinThoma/algorithms/blob/master/cross-correlation/zncc.py"
2.3. DEDUPLICAÇÃO
Para medir a eficiência do algoritmo foram criadas imagens com regiões duplicadas onde a localização exata das regiões era conhecida, com isso, foi possível verificar se o algoritmo estava funcionando corretamente.
2.3
Deduplicação
A deduplicação de dados é um técnica de compressão sem perda que elimina dados redundantes tanto intra-file quanto inter-file, diferente de ferramentas de compressão de dados como o gzip que só eliminam a redundância intra-file. A deduplicação reduz a quantidade de espaço necessário para armazenamento de dados através da eliminação de blocos e/ou arquivos redundantes. Na deduplicação, todos os blocos de dados ou arquivos que estão duplicados em um sistema de armazenamento são reduzidos à uma única cópia, e os dados que foram desalocados são convertidos para uma referência ao conteúdo mantido no sistema.
As técnicas de compressão de dados referem-se ao trabalho de dois algoritmos. Há o algoritmo de compressão, e o de reconstrução. O algoritmo de compressão pega um arquivo X e gera uma representação Xc desse arquivo. O algoritmo de reconstrução é
responsável por pegar a representação gerada pelo algoritmo de compressão e transformá-la no arquivo Y. Baseado no funcionamento do algoritmo de reconstrução, a técnica pode ser classificada de dois modos: sem perdas (lossless), quando Y = X; e com perdas (lossy), permite Y 6= X [35].
2.3.1
Localização
A deduplicação distribuída pode ser feita tanto na entidade que envia os dados quanto na que os recebe. Para facilitar, será utilizado o padrão cliente/servidor para explicar as formas de deduplicação. A entidade que requisita o armazenamento do dado será referenciada como Cliente; a entidade de destino dos dados será referenciada como Servidor.
Cliente (source)
Mandagere et al.[27] descreve a deduplicação baseada no cliente como sendo a deduplicação feita antes do cliente enviar seus dados para o servidor. O cliente faz o cálculo e obtem o valor do hash de um chunk, chamado de fingerprint, em seguida ele os envia para o servidor de metadados, que faz a comparação com os fingertprints que estão
2.3. DEDUPLICAÇÃO
armazenados para poder identificar prováveis dados redundantes no sistema. Ao receber as informações, o cliente executa uma busca de conjuntos de bytes redundantes e remove esses dados antes de enviar o arquivo através da rede.
Esse tipo de deduplicação tem como vantagem a redução da quantidade de dados tra-fegados na rede e redução da sobrecarga de processamento no servidor. Em contrapartida, há um consumo maior de CPU e I/O no cliente, pelo fato dele ser o executor da tarefa de detecção de dados redundantes.
Um ponto crítico desta técnica é a capacidade que o cliente tem de identificar blocos de arquivos armazenados no sistema e que são idênticos aos seus. O cliente precisa saber os bytes dos blocos dos arquivos cujo fingerprint é igual ao do seu para fazer a comparação e verificar se os dados são realmente idênticos, já que mais de um bloco de mesmo tamanho pode ter um fingerprint igual mesmo tendo conteúdos diferentes. Apesar da probabilidade disso ocorrer ser quase zero, é preciso garantir a integridade dos dados armazenados pelos usuário, o que torna importante essa verificação byte a byte.
Servidor (target)
Considerada nessa categoria toda deduplicação que é processada na entidade que recebe os dados para armazenamento. Nela estão os appliances para armazenamento, sto-rage arrays, peers de recebimento de dados em sistemas de armazenamento construídos com arquitetura peer-to-peer, entre outros.
A deduplicação feita no servidor pode acontecer em dois momentos: inline e post-processing. Eles serão descritos no próximo tópico.
Uma desvantagem dessa abordagem é a centralização do processamento para iden-tificação de dados redundantes no servidor, o que pode ocasionar a sobrecarregar do mesmo.
2.3.2
Momento
A deduplicação pode ser de dois momentos: Inline deduplication ou Post-process deduplication[12].
• Inline deduplication: os dados são examinados no momento em que chegam, antes da escrita no sistema de armazenamento. Esse processamento antes da escrita pode tornar o servidor um gargalo.
• Post-process deduplication: a deduplicação é feita depois que os dados são arma-zenados, em intervalos de tempo regulares ou quando um certo limite definido é
2.3. DEDUPLICAÇÃO
alcançado. Esse tipo de deduplicação é a melhor para ser utilizada em sistemas onde a velocidade de recebimento de dados é um fator crítico, já que o processamento pode deixar pra ser feito quando o servidor estiver ocioso.
2.3.3
Algoritmo
Os algortimos para fazer a deduplicação são categorizados em três tipos, segundo [27]: Whole File Hashing, Sub File Hashing e Delta Encoding.
• Whole File Hashing: é aplicada alguma função de hashing como o SHA1 [1] ou o MD5[33] no arquivo todo, esse valor é comparado com a base de armazenamento de arquivos armazenados no sistema, caso algum outro arquivo possua o hash com o mesmo valor, é feita uma comparação byte a byte para ter certeza que os arquivos são idênticos, se forem, um dos arquivos é removido do sistema e o usuário ao qual o arquivo apagado pertencia terá um referência para o arquivo que é idêntico ao seu.
• Sub File Hashing: nessa categoria, o arquivo é dividido em pedaços que podem ser de tamanhos iguais, chamado de Fixed Block Hashing (FBH), ou variáveis, chamado de Variable Block Hashing (VBH). No algoritmo FBH, o arquivo é todo dividido em blocos de tamanho fixo, em seguida, é aplicada alguma função de hash nos blocos para obtenção dos fingerprints. O VBH utiliza o Rabin Fingerprinting [31], a ideia de computar o fingerprint de cada bloco para apenas transferir os que têm fingerprint diferente dos blocos que estão no computador de destino, com isso é possível reduzir os dados trafegados na transferência de arquivos que possuem partes comuns aos arquivos do outro lado, mas esta técnica tem um ponto que precisa ser tratado. Quando qualquer dado é inserido ou removido de um arquivo, todos os fingerprints dos blocos subsequentes serão modificados se o algoritmo utiliza blocos de tamanho fixo. O Rabin Fingerprinting utiliza uma janela deslizante (rolling checksum e utiliza uma técnica para subdividir os blocos que tenham maior probabilidade de serem iguais a outros.
• Delta Encoding/Compression (DE): com o Delta Encoding é gerado um arquivo conhecido como patch que é um arquivo que tem informações das diferenças entre dois arquivos. Um algoritmo é usado para identificar quais partes devem ser copiadas e substituidas em um arquivo e quais partes devem ser inseridas para que seja possível remontar o arquivo apenas com as informações das diferenças.
2.3. DEDUPLICAÇÃO
2.3.4
Benefícios
Um exemplo do benefício que pode-se obter com a deduplicação foi apresentado pela IBM. A IBM representou ganho de economia com um sistema de deduplicação baseado em alterações de 20% do conteúdo dos arquivos através da Figura2.3[18]. A Figura mostra um backup inicial de 7TB de dados, e em uma semana o backup dos dados chegou a 79TB de dados. Em um sistema de armazenamento sem a deduplicação, todos os 49TB de dados seriam ocupados, mesmo se a alteração nos dados for de 20%, mas se esse sistema usa deduplicação, é possível armazenar todo o conteúdo no sistema utilizando apenas 8,45TB físico no disco. Ainda no exemplo, em 30 dias seria necessário 210TB de disco para armazenamento em um sistema sem deduplicação, e de apenas 26,2TB para armazenar os mesmos dados em um sistema com deduplicação. É grande o ganho de economia que pode ser atingido com a utilização de deduplicação.
Figura 2.3 Exemplo da economia de espaço oferecida em um sistema de armazenamento com 20% de alteração nos dados.
2.4. SUMÁRIO DO CAPÍTULO
2.4
Sumário do capítulo
Neste capítulo, foi feita a descrição de alguns dos sistemas de armazenamento de dados, que utilizam deduplicação e fornecem detalhes sobre como ela é feita. Alguns dos problemas enfrentados por esses sistemas, que não têm relação direta com a deduplicação, só com o armazenamento distribuído, será atribuído ao Cassandra, que vai ser usado como base para o gerenciamento dos dados do Dedupeer File Storage, fazendo com que o foco principal do trabalho, que é o algoritmo de deduplicação, tenha um maior tempo para ser dedicado na pesquisa.
A utilização de chunks para o processo de deduplicação, apesar de ser óbvio, foi confirmado como base em todos os sistemas que fornecem esse serviço. Neste capítulo também foi feita uma introdução sobre o que é deduplicação e quais são os seus tipos.
No próximo capítulo, será feito um aprofundamento no desenvolvimento do Dedupeer File Storage, o modelo de dados utilizado, algumas decisões de projetos que foram tomadas e será detalhada a visão de componentes e conectores do mesmo.
3
O Dedupeer File Storage
3.1
Introdução
O Projeto Dedupeer é composto pela biblioteca homônima e pelo Dedupeer File Storage (DeFS), que foi desenvolvido para facilitar os testes e avaliação dos algoritmos implementados para a deduplicação, que é a principal contribuição deste trabalho.
Para representar de forma simples a comunicação entre o componente, o sistema de arquivos e o sistema de armazenamento que adicionar o componente, foi usado o diagrama de componentes apresentado na Figura 3.1. Observando a interação entre os artefatos que compõem todo o sistema para deduplicação, percebe-se que o acesso aos arquivos é abstraído pelo Dedupeer. De uma forma transparente para o sistema de armazenamento o Dedupeer lê, quebra, e processa os bytes do arquivo especificado, levando em consideração os parâmetros passados pelo sistema através da interface de comunicação Thrift1. O Thrift será melhor detalhado na seção4.2.1.
O DeFS foi desenvolvido para ocupar o lugar no diagrama que pertence aos sistemas de armazenamento de dados. Com a arquitetura planejada dessa forma, fica fácil fazer a integração do algoritmo em muitos sistemas. O Thrift dá suporte à comunicação entre diversas linguagens, o que aumenta a quantidade de sistemas que podem ser integrados ao Dedupeer.
3.1.1
Escopo
O Dedupeer File Storage é um sistema de armazenamento de dados, que pode ser usado de forma distribuída, com capacidade de armazenamento e recuperação de arquivos.
3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUÍDO
Figura 3.1 Diagrama de componentes de alto nível da biblioteca do Dedupeer
Apesar de poder ser usado de forma distribuída, como escopo deste trabalho só será considerado a utilização dele em uma máquina simples.
3.2
O sistema de armazenamento distribuído
Para facilitar os testes e a validação dos algoritmos, foi desenvolvido um sistema de armazenamento que tem como base o banco de dados não relacional desenvolvido dentro do Facebook, e hoje projeto incubado no Apache Foundation, chamado Cassandra2. O Cassandra foi desenvolvido com o objetivo de ser escalável e altamente disponível.
Para mais informações sobre a escolha do banco de dados para ser usado como base do sistema de armazenamento, ele é descrito em detalhes na seção3.4.2.
3.2.1
Modelo de dados
Pelo fato do Cassandra ser um banco de dados NoSQL, também conhecido como banco de dados não relacional, o seu modelo de dados é totalmente diferente dos utilizados nos bancos relacionais, os quais possuem tabelas com colunas, cada registro na tabela é adicionado em uma nova linha, com toda linha tendo que ter a mesma quantidade de colunas das outras. Como a maioria das pessoas está acostumada com essa forma de organização de um banco de dados, será feita uma breve apresentação do modelo de dados utilizado no Cassandra, para facilitar o entendimento sobre as escolhas de projeto para a modelagem do sistema de armazenamento.
3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUÍDO
No modelo de dados do Cassandra existe uma flexibilidade muito grande sobre como estruturar os dados. A forma mais simples de dado que se pode armazenar é uma lista ou array. Com a adição de uma nova dimensão é possível transformar essa lista em um Mape deixar os dados mais organizados. Essa nova dimensão pode servir para nomear os dados da dimensão citada primeiramente, o que torna o modelo um pouco parecido com a estrutura utilizada no relacional. Abaixo tem um exemplo de um registro simples no modelo de dados do Cassandra [17].
"Paulo Fernando":
"email": "[email protected]", "idade": "25"
Essa esttutura tem como chave o valor "Paulo Fernando". A primeira dimensão, citada acima, seria os valores que representam os nomes das colunas "email"e "idade". A consideração desses valores como nome de coluna é apenas organizacional, pois eles não precisam ser necessariamente uma string, o valor armazenado em qualquer uma das dimensões pode ser até dados binários com limite de 2 GB, mas para melhor estruturação a maioria dos bancos usam esse valor como uma string ou um long para representar um identificador para o valor da segunda dimensão, que está sendo representada no exemplo pelos valores "[email protected]"e "25". Todos esses valores juntos representam uma linha, e a reunião das linhas recebe o nome de família de colunas. As famílias de colunas são associadas a um keyspace, que é um container de família de colunas, e que seria o equivalente a um banco de dados no modelo relacional. Cada instância do Cassandra pode ter vários keyspaces.
Além da coluna normal, representada pelos pares dos valores no exemplo acima, como por exemplo, "idade": "25", existe também a chamada super coluna, que é um tipo especial de coluna que possui uma estrutura mais complexa, onde existe um campo que é usado como identificação e uma agregação lógica de colunas simples. O exemplo abaixo, demonstra como seria um conjunto de dados representado por uma super coluna.
"Paulo Fernando": "endereço"
"rua": "Rua ABC", "número": "123" "informações pessoais"
3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUÍDO
"email": "[email protected]", "idade": "25"
O Cassandra, quando utiliza super colunas, funciona como uma hastable de 5 dimen-sões [Keyspace] [ColumnFamily] [Key] [SuperColumn] [SubColumn] [17]. Para acessar a "idade"de "Paulo Fernando", por exemplo, o caminho seria [Keyspace] [ColumnFamily] ["Paulo Fernando"] ["informações pessoais"] ["idade"], onde Keyspace e ColumnFamily teriam que ser previamente criadas no Cassandra para que esses dados pudessem ser armazenados dentro da ColumnFamily.
Toda a estrutura que foi definida para o sistema de armazenamento desenvolvido está representado na Figura3.2. A escolha da estrutura utilizada será discutida a seguir.
Foram definidas duas famílias de super colunas para armazenar e organizar os dados dos arquivos: UserFiles, Chunk; e um família de colunas para agilizar o processo de identificação do arquivo: Files.
Na família de super colunas UserFiles, a chave é representada pelo nome do usuário. O nome da super coluna é definido como sendo o nome do arquivo, no caso do exemplo o arquivo se chama "lorem.txt". Foram definidas seis subcolunas para essa família: file id
Armazena o identificador único do arquivo no sistema. size
Armazena o tamanho do arquivo em bytes. chunks
Armazena a quantidade de chunks em que o arquivo foi dividido. with content
Armazena a quantidade de chunk que possui conteúdo without content
Armazena a quantidade de chunks que não possui conteúdo. Este valor representa a quantidade de chunks que são referências à chunks que estão duplicados no sistema. A criação das colunas with content e without content foi uma decisão para aumentar o desempenho evitando ter que consultar todos os chunks do arquivo para identificar quais deles são referências e quais armazenam o conteúdo. A criação de apenas um dos dois resolveria o problema, mas nesse caso, para a identificação do outro valor seria necessário
3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUÍDO
a consulta da quantidade total de chunks, então foi tomada a decisão de já armazenar o valor calculado.
Na família de super colunas chamada Chunk a chave que identifica a linha é o identificador único do arquivo, localizado na coluna com nome file id na família de super colunas UserFiles. Cada linha representa as informações de todos os chunks pertencentes ao arquivo referenciado. Cada arquivo só tem uma linha nessa família de super colunas. As subcolunas dessa família são detalhadas abaixo.
md5
Armazena o valor do fingerprint representado por um valor do cálculo de uma função SHA-1 sobre os dados do chunk atual.
hash32
Armazena o valor do fingerprint representado por o resultado do cálculo de uma hashde 32 bits sobre os dados do chunk.
index
Armazena a posição do início do chunk dentro do arquivo completo. Por exemplo, se ele for o primeiro segmento do arquivo, esse valor será 0, se ele for o segundo segmento do arquivo e o primeiro segmento tiver 512 bytes de tamanho, esse valor será 512.
length
Armazena a quantidade de bytes que o chunk possui. content
Armazena o conteúdo binário que se inicia na posição index e vai até a posição index + lengthdentro do arquivo. Armazena a quantidade de bytes que o chunk possui.
pfile
Armazena o identificador do arquivo ao qual o segmento referenciado pertence. pchunk
Armazena o identificador do segmento ao qual foi identificado que o conjunto de dados é idêntico. Em outras palavras, adiciona uma referência ao segmento que possui o conteúdo que não foi armazenado no sistema por ser duplicado.
3.2. O SISTEMA DE ARMAZENAMENTO DISTRIBUÍDO
Percebe-se a flexibilidade da utilização do Cassandra nessa família de colunas, na mesma família de colunas são armazenados dois tipo estruturais de dados, um para representar um segmento com conteúdo binário e outro para representar uma referência para um outro segmento já armazenado no sistema. Para uma melhor visualização dessa família de super colunas, elas serão detalhada na Figura3.2.
A família de colunas chamada Files é bem simples, ela é apenas uma atalho de consulta para o identificador de um arquivo de um determinado usuário baseado no nome desse arquivo. A chave dessa família de colunas é o nome do usuário. Ela possui apenas uma coluna que tem o nome do arquivo do usuário e o id desse arquivo.