UM SISTEMA DE ARQUIVOS COMPARTILHADO EM NÍVEL DE USUÁRIO BASEADO EM TABELAS HASH DISTRIBUÍDAS

Transcrição

1 PEDRO EUGÊNIO ROCHA UM SISTEMA DE ARQUIVOS COMPARTILHADO EM NÍVEL DE USUÁRIO BASEADO EM TABELAS HASH DISTRIBUÍDAS Trabalho apresentado ao Bacharelado em Ciência da Computação da Universidade Federal do Paraná, como requisito parcial à obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Luiz Carlos Erpen de Bona Curitiba 2009

2 Resumo Este trabalho apresenta o DIFS (Distributed Filesystem), um sistema de arquivos totalmente distribuído que utiliza uma DHT (Distributed Hash Table) como rede overlay. No DIFS, cada nodo cede uma certa quantidade de espaço de armazenamento para a rede, formando um grande sistema de arquivos compartilhado e disponível a todos os participantes. O sistema utiliza o FUSE (Filesystem in Userspace) para criar um sistema de arquivos real e em nível de usuário, não necessitando de privilégios de administrador para utilizá-lo. Cada arquivo ou diretório criado na rede é replicado e armazenado em um conjunto de nodos, designados pelo algoritmo de balanceamento de carga do sistema. Para cada arquivo criado na rede, é inserido na DHT o par [nome do arquivo, endereço dos nodos que o armazenam]. Para manter a disponibilidade e consistência das várias réplicas de um arquivo, um dos nodos que o armazena será responsável por checar periodicamente o estado das cópias, propagando quaisquer modificações feitas ao arquivo aos demais nodos que o armazenam. Operações de escrita são sempre encaminhadas para o nodo responsável pelo arquivo. Entretanto, operações de leitura de conteúdo e meta-informações, que com boa probabilidade serão em maior número, podem ser enviadas a qualquer nodo que armazene réplica do arquivo. Com o objetivo de avaliar o desempenho e compará-lo com outros sistemas similares, um protótipo foi desenvolvido e testado.

3 Sumário 1 Introdução p. 4 2 Trabalhos Relacionados p Redes de Compartilhamento de Arquivos p Sistemas de Arquivos Distribuídos p. 8 3 Redes peer-to-peer (P2P) p Tabelas Hash Distribuídas (DHT) p CAN p Chord p Pastry p Sistemas de arquivos p FUSE p Distributed Filesystem (DIFS) p Arquitetura do Sistema p Serviço de Indexação p Serviço de Gerenciamento de Espaço Livre p Operações p Resultados Experimentais p Conclusão p. 29

4 Referências Bibliográficas p. 30

5 5 1 Introdução Atualmente, as redes P2P (Peer-to-peer) vêm sendo muito utilizadas para o compartilhamento de recursos e informações em larga escala. Por serem redes, em geral, altamente escaláveis, auto-organizáveis e que não necessitam de controle centralizado, diversas aplicações de compartilhamento presentes hoje na Internet as utilizam [2, 5, 4, 18, 20, 21]. Diferentemente do modelo de comunicação tradicional cliente-servidor, nas redes P2P todos os peers realizam ambas as tarefas, cedendo recursos (espaço de armazenamento, poder computacional, etc.) para a rede. Além disso, essas redes não possuem mais um único ponto de falha como em comunicações baseada em servidores. Um tipo especial de rede P2P cada vez mais utilizada na construção de aplicações distribuídas, são as chamadas DHT s. As DHT s são redes P2P para armazenamento de dados (chave e valor), totalmente distribuídas e estruturadas, apresentando tolerância à falhas e grande escalabilidade. As DHT s são utilizadas como rede overlay para uma grande parcela das aplicações P2P [13, 2, 20] desenvolvidas atualmente. Grande parte das aplicações de compartilhamento de arquivo existentes hoje necessitam de um programa específico para que o usuário possa transferir e manipular arquivos [2, 5, 4]. Ainda, muitas dessas redes e dos sistemas de arquivos distribuídos são baseados em servidores ou em peers especiais [22, 15, 7]. Aliando a popularização dessas redes e o crescente aumento pela demanda de espaço de armazenamento, este trabalho propõe o DIFS. O DIFS é um sistema de arquivos totalmente distribuído, com o intuito de prover um grande espaço de armazenamento compartilhado entre os participantes de uma rede P2P. Todos os nodos participantes cedem uma certa quantidade de espaço de armazenamento para a rede, criando um grande sistema de arquivos compartilhado e disponível a todos. O DIFS garante a disponibilidade de um arquivo mesmo diante de falhas de nodos. O sistema possui a interface de um sistema de arquivos convencional, implementando todas as operações pertinentes. Para que seja possível utilizar o sistema (montar/desmontar o sistema de arquivos) sem a necessidade de obter privilégios de administrador, utilizamos o FUSE (Fi-

6 6 lesystem in Userspace) como interface com o sistema operacional. Quando um arquivo ou diretório é criado na rede, o sistema decide quais nodos serão responsáveis por armazená-lo fisicamente. Vários nodos armazenam um mesmo arquivo, possibilitando que ele continue acessível mesmo em caso de falhas. Os nodos que armazenam fisicamente um arquivo são os únicos que podem disponibilizar seu conteúdo e meta-informações, e toda requisição referente ao arquivo deve ser encaminhada a um desses nodos. Para acessar um arquivo, não é necessário transferi-lo completamente. O DIFS o tranfere por demanda, a medida em que é requisitado, diminuindo a quantidade de dados transitando entre os nodos. Apesar de vários nodos armazenarem um mesmo arquivo, um deles será escolhido responsável por manter a consistência entre as cópias. Esse nodo irá coordenar as operações de escrita no arquivo e checar periodicamente o estado das demais réplicas. As operações de leitura, que com boa probabilidade serão em maior número que as de escrita, podem ser enviadas a qualquer nodo que armazene cópia do arquivo, não necessitando de intervenção do nodo responsável. Para indexar os arquivos aos nodos que os armazenam, o sistema utiliza um Serviço de Indexação, tipicamente uma DHT. A DHT é reponsável por armazenar os índices, guardando para cada arquivo inserido na rede, o par [nome do arquivo, endereço dos nodos que o armazenam]. Na DHT também são armazenadas informações sobre o espaço disponível em cada participante. Utilizando as informações sobre espaço disponível, o sistema decide onde criar novos arquivos. O nodo designado pela DHT por manter o índice (link) a um arquivo, não possui nenhuma relação com os nodos escolhidos pelo sistema para armazená-lo fisicamente. O DIFS supõe que falhas em nodos não afetam o estado dos dados armazenados na DHT (links). O restante deste trabalho está organizado da seguinte maneira. O capítulo 2 apresenta alguns dos trabalhos relacionados, em especial sobre redes P2P de compartilhamento e sistemas de arquivos distribuídos. O capítulo 3 contém um breve resumo sobre redes P2P. No capítulo 4 são examinados alguns tópicos relacionados a sistemas de arquivos importantes a este trabalho. O capítulo 5 apresenta em detalhes a proposta do DIFS, e dados referentes ao protótipo existente e resultados de teste de desempenho são mostradas no capítulo 6. Finalmente, o capítulo 7 conclui este trabalho.

7 7 2 Trabalhos Relacionados Com a popularização das redes P2P nos últimos anos, diversos sistemas foram propostos visando beneficiar-se das características destas redes. Dois tipos de redes são especialmente importantes para este trabalho: as redes de compartilhamento de arquivos e os sistemas de arquivos distribuídos. As redes de compartilhamento de arquivos têm como principal objetivo o compartilhamento de dados entre os seus participantes. Os arquivos inseridos nestas redes dificilmente são modificados, e nem todos os nodos precisam possuir permissão de escrita neste sistema. Já os sistemas de arquivos distribuídos precisam lidar com arquivos sendo constantemente atualizados (inclusive por vários nodos ao mesmo tempo), inseridos e excluídos. Nas sessões seguintes descreveremos algumas destas principais redes. 2.1 Redes de Compartilhamento de Arquivos O Napster [3] foi a primeira rede de compartilhamento de arquivos P2P, surgindo no final da década de 90. O Napster era baseado em um conjunto de servidores centrais e permitia a troca de músicas MP3 entre os participantes. Para entrar na rede, um nodo deveria conectar-se a um dos servidores, e enviar-lhe a lista de músicas que estava disposto a compartilhar. Os servidores armazenavam as listas de músicas de todos os participantes, e eram responsáveis por realizar buscas nas mesmas. O download era realizado diretamente entre os nodos, ou seja, os servidores não interferiam na transferência dos arquivos. A estratégia de compartilhar a carga de download entre os participantes e utilizar servidores centrais apenas para indexação funcionou muito bem na Internet, permitindo que a rede alcançasse dimensões muito maiores do que as redes baseadas no modelo cliente-servidor. Apesar de suas interessantes características e grande escalabilidade, o Napster teve diversos problemas legais relacionados a direitos autorais, pois tratava-se de uma rede de compartilhamento exclusivo de arquivos MP3, culminando no desativamento da rede por ordem judicial. Após a queda do Napster, surgiram várias outras redes de compartilhamento de arquivos. Uma delas foi a rede edonkey [5], que continua sendo muito utilizada hoje em dia. A rede

8 8 edonkey também é baseada em um conjunto de servidores centrais, os quais gerenciam as listas de arquivos que cada nodo está compartilhando. A tranferência também é realizada diretamente entre os nodos. Diferentemente do Napster, que compartilhava apenas arquivos MP3, a rede edonkey possibilita o compartilhamento de qualquer tipo de arquivo entre os nodos. Por ser uma rede de compartilhamento de arquivos quaisquer, a rede edonkey não sofreu tanto com problemas judiciais quanto o Napster, e continua acessível até hoje. O mesmo fato ocorreu com a rede Gnutella [18]. O Gnutella é uma rede P2P não-estruturada e totalmente distribuída, que diferentemente do Napster e edonkey não é baseada em servidores. Por este motivo, um nodo precisa conhecer previamente algum dos participantes para conectarse à rede. Após entrar, o nodo recebe uma lista de peers, um subconjunto dos nodos presentes na rede. Para buscar dados, são realizados floods com profundidade máxima estabelecida. Por ter profundidade máxima, as buscas nem sempre encontram o conteúdo buscado, principalmente tratando-se de arquivos raros na rede. Da mesma maneira que as redes anteriores, os downloads são realizados através de conexão direta entre os nodos. A rede KAD [2] é a sucessora da rede edonkey. Esta rede tem como objetivo criar um sistema de compartilhamento de arquivos completamente distribuído e estruturado. O KAD utiliza o Kademlia [12] como rede overlay, que subtitui os servidores e realiza a indexação. Assim como na rede Gnutella, para entrar na rede KAD, um nodo precisa conhecer previamente o endereço de algum outro participante que esteja conectado à ela. Por ser uma rede totalmente descentralizada, o número de mensagens necessárias para gerenciá-la e fazer buscas é maior, quando comparado a uma rede baseada em servidores. Por ser estruturada, a rede KAD sempre encontra os dados nela inseridos, diferentemente do Gnutella, uma rede não-estruturada. Outro sistema distribuído de compartilhamento de arquivos é o PAST [20], que utiliza a rede Pastry [19] como overlay para indexação de arquivos. No PAST, cada nodo deve ceder uma quantidade de espaço de armazenamento para a rede. O PAST utiliza o espaço cedido por todos os participantes para armazenar os arquivos que serão compartilhados. Somente administradores podem inserir arquivos na rede; os demais usuários podem apenas utilizá-los. Uma das vantagens do PAST, é que uma vez inserido, um arquivo torna-se acessível mesmo quando o nodo que o inseriu tornar-se indisponível. Apesar dessas vantagens, o PAST não é um sistema de arquivos distribuído por possuir um conjunto de operações muito pobre. Ele possui somente as as seguintes operações: inserir um novo arquivo (insert), buscar (lookup) e apagar um arquivo (reclaim). Outra diferença entre o PAST e sistemas de arquivos distribuídos, é que nele os arquivos inseridos são imutáveis, fato característico de redes de compartilhamento de arquivos.

9 9 2.2 Sistemas de Arquivos Distribuídos O NFS (Network Filesystem) [22] é um sistema de arquivos distribuído feito pela empresa SUN, com o objetivo de compartilhar arquivos e diretórios entre computadores conectados em rede. O NFS segue o modelo cliente-servidor, possibilitando que um cliente possa montar um sistema de arquivos exportado por um servidor remoto. Todo armazenamento e todas as requisições são respondidas pelo sevidor. É o sistema de arquivos distribuído mais utilizado hoje em dia. O sistema de arquivos distribuído Ivy [13] é um exemplo de um sistema de arquivos baseado em uma rede P2P totalmente distribuído. O Ivy consiste em um conjunto de logs, um por participante, armazenados em uma DHT. Todas as modificações em um bloco de dados realizadas por um usuário qualquer, serão armazenadas nos logs. Para acessar um arquivo, um nodo deve consultar todos os logs referentes a ele, obtendo assim a sua versão mais atual. Esta estratégia garante a consistência dos dados mesmo diante de modificações concorrentes. Sempre que for necessário, um arquivo pode ser restaurado, pois todas as modificações realizadas estão armazenadas nos logs. Em contrapartida, aumentar o número de nodos compartilhando e modificando um mesmo arquivo, implica em percorrer um grande número de logs para acessá-lo [16]. Este fato pode limitar a escalabilidade do sistema. Um sistema de arquivos distribuído amplamente utilizado nas instalações do Google é o GFS (Google Filesystem) [7]. O GFS foi desenvolvido pelo próprio Google, o seu código é fechado e sem fins comerciais. O GFS possui o objetivo de atender as necessidades específicas da empresa, portanto, conforme as características da rede, pode ser inviável utilizá-lo. Uma das peculiaridade do caso do Google, é ter arquivos extremamente grandes e que raramente são alterados. A grande maioria das operações é de leitura ou complemento (append), e por isso o sistema assume que uma vez gravado, dificilmente um arquivo será modificado [7]. O GFS utiliza um servidor mestre para gerenciar meta-informações e indexar os arquivos aos nodos que o armazenam. Todas as requisições passam por um servidor central, o que impossibilita o seu uso em uma rede P2P totalmente distribuída. Outro sistema de arquivos distribuído muito utilizado é o AFS (Andrew Filesystem) [15]. O AFS é um sistema de arquivos ditribuído baseado em um sub-conjunto de nodos servidores de arquivos, que armazenam todos os arquivos do sistema. Quando um cliente acessa um arquivo, ele faz uma requisição para um dos servidores de arquivos da rede. O cliente mantém uma cópia do arquivo em sua máquina enquando o arquivo permanecer aberto. Quando o arquivo é fechado, todas as modificações são enviadas para o servidor de arquivos. Caso algum outro

10 10 cliente tenha modificado o arquivo neste tempo, o servidor avisa ao cliente que a operação falhou [14]. O AFS possui um servidor de Autenticação que utiliza o algoritmo Kerberos [9] para autenticar os seus usuários. Este algoritmo assegura a autenticação segura entre cliente e servidor sobre uma rede não-confiável. O fato de ser baseado em um ou um conjunto de servidores centrais, inviabiliza a utilização do AFS em uma rede P2P totalmente distribuída.

11 11 3 Redes peer-to-peer (P2P) Atualmente as redes P2P [1] têm sido muito utilizadas para compartilhamento de recursos em larga escala na Internet e em redes privadas. Essas redes possuem diversas características interessantes, como alta escalabilidade, auto-organização, adaptabilidade e controle descentralizado [20]. Essas características são especialmente importantes quando tratamos de aplicações massivamente escaláveis, como muitas das existentes hoje na Internet [18, 5, 12, 20, 4]. No modelo tradicional de comunicação cliente-servidor, o servidor é o único responsável por responder requisições de uma rede. Para utilizar um serviço qualquer, um cliente deve comunicar-se com o servidor que o oferece. O servidor recebe a requisição, e após processá-la retorna o resultado ao cliente. Apesar deste ser um dos modelos mais comuns para aplicações distribuídas, ele é potencialmenteme suscetível a problemas de escalabilidade. Em redes P2P não existem clientes ou servidores, mas sim peers que desempenham ambas as tarefas. Em geral, nas redes P2P não existe nenhum tipo de unidade centralizadora para exercer funções específicas. Em grande parte das redes P2P, todos os peers desempenham as mesmas tarefas. A grande vantagem de uma rede P2P sobre o modelo cliente-servidor, é que todos os peers da rede podem ceder recursos, como bandwidth, espaço de armazenamento e poder computacional, que podem ser utilizados em conjunto para um determinado fim. Outra vantagem está no fato que em redes P2P não existe mais um único ponto de falha como no modelo cliente-servidor, sendo essas redes em geral tolerantes à falha, garantindo que a queda de um peer, por exemplo, não prejudique o seu funcionamento. Apesar destas vantagens, essas redes criaram vários novos problemas, como a localização de dados e serviços, autenticação de usuários e detecção de falhas em nodos. Algumas redes P2P utilizam algum tipo de unidade centralizadora para exercer tarefas específicas, como indexação e autenticação. A rede edonkey [5], por exemplo, utiliza servidores para indexar os arquivos aos usuários que os possuem. Redes P2P que possuam algum grau de centralização ou que possuam nodos exercendo funções especiais são chamadas redes P2P mistas. Algumas redes P2P executam todas as tarefas de forma distribuída, descartando a ne-

12 12 cessidade de nodos especiais para gerenciar a rede ou rotear mensagens. Essas são as chamadas redes P2P puras ou redes P2P totalmente distribuídas. Hoje na Internet, existem vários exemplos de redes P2P puras [2, 18, 4]. Redes P2P podem ser classificadas em estruturadas e não-estruturadas, baseado na maneira em que os nodos estão organizados. As redes ditas estruturadas organizam os nodos participantes em uma estrutura bem definida. Todos os dados inseridos nestas redes são armazenados em locais bem determinados, de forma que as buscas realizadas nestas redes sejam eficientes. A estrutura da rede provê mecanismos de roteamento de mensagens para a localização de dados, para que qualquer item inserido na rede possa ser encontrado. Essas redes, ao menos em sua forma básica, não realizam nenhum tipo de busca refinada. As buscas são feitas apenas por uma chave exata [11]. Diferentemente das redes estruturadas, nas redes não-estruturadas não existe controle sobre a topologia da rede. Em geral cada nodo conhece apenas os seus vizinhos, e buscas nas redes são feitas através de inundações (floods) ou de mensagens aleatórias. Os algoritmos de busca por inundação tendem a limitar a escalabilidade do sistema devido ao alto número de mensagens. Outra limitação destas redes é fato de dados raros nem sempre serem encontrados devido à falta de estruturação da rede. Apesar disso, como as buscas são enviadas de nodo a nodo, elas podem ser mais complexas (palavras chave ou meta-informações, por exemplo) se comparadas às buscas em redes estruturadas ao menos em sua forma básica. 3.1 Tabelas Hash Distribuídas (DHT) Um dos maiores problemas em redes P2P é a localização de dados. Além de eficiência nas buscas, é preciso também a garantia que todos os dados inseridos possam ser encontrados. Esse objetivo pode ser alcançado utilizando redes P2P puras e estruturadas. Existem diversas propostas de implementação destas redes, todas seguindo um mesmo princípio, diferindo apenas na forma em que os nodos são estruturados ou na maneira como realizam o roteamento. Todas os dados inseridos são armazenados em algum local da rede, podendo ser recuperados a qualquer momento. Essas redes provêem a funcionalidade de uma grande tabela hash, distribuída entre os seus participantes. As DHT s (Distributed Hash Tables), como essas redes são chamadas, realizam basicamente a operação: dada uma chave qualquer, retornar o objeto associado (valor). Objetos podem ser arquivos, serviços, dados, ou qualquer outro valor indexado à chave. As DHT s são descentralizadas, e em geral possuem grande escalabilidade, se adaptando a entrada e saída

13 13 constante de nodos. Alguns dos principais protocolos de DHT são CAN, Chord e Pastry. Apesar das diversas implementações e propostas de DHT, elas possuem muitas características em comum. Em uma DHT, em geral, todo nodo possui uma chave ou identificador (ID) único, assim como os dados. O conjunto de todas as chaves possíveis nesta rede forma um espaço de chaves, e todo nodo é responsável por armazenar um subconjunto de chaves deste espaço, segundo algum critério de distribuição. Todo nodo mantém uma lista com um subconjunto de nodos conhecidos desta rede (em alguns casos log(n) nodos), e seus identificadores. As DHT s possuem também uma noção abstrata de distância entre chaves, que em geral não tem relação com fatores físicos, como localização geográfica ou latência da rede entre os nodos. Para inserir ou buscar dados, uma chave deve ser associada ao conteúdo em questão e enviada a algum nodo participante da DHT. Esta chave será roteada, até que chegue ao nodo responsável por armazená-la. O roteamento em DHT s é baseado em chaves e ocorre da seguinte forma. Um nodo recebe a chave e verifica se é o responsável por armazená-la. Caso ele seja o responsável, a mensagem já chegou ao seu destino. Caso contrário, ele irá localizar em sua tabela de nodos conhecidos, qual nodo possui a chave mais próxima da buscada, encaminhndoa para este nodo. Este algoritmo se repetirá, convergindo a cada passo do nodo responsável pela chave CAN O CAN [17] é uma proposta de implementação de DHT, que organiza o espaço de chaves em um espaço cartesiano d-dimensional baseado em um d-torus. Quanto maior o número d de dimensões, menor é o número saltos necessários para localizar uma chave. Todos os dados e nodos da rede são mapeados para pontos neste espaço cartesiano. Cada nodo da rede é responsável por uma fatia deste espaço, definida dinamicamente. Para entrar em uma rede CAN, um nodo deve buscar o responsável por armazenar o ponto a qual sua chave mapeou. Esta área é então dividida entre os nodos, de forma que cada um seja responsável por manter as chaves referentes à metade deste espaço. Todos os nodos mantém uma tabela contendo o endereço dos seus vizinhos imediatos. Quanto maior o número d de dimensões, maior o tamanho desta tabela. As buscas são roteadas através desta lista, sendo encaminhadas para o vizinho que está mais próximo ao ponto de destino. Como todas as chaves são mapeadas para pontos em um espaço, no CAN, a distância entre as chaves é definida pela distância euclidiana entre os dois pontos.

14 Chord O Chord [8] é uma proposta de implementação de tabela hash distribuída que organiza os nodos em um espaço circular (anel). O nodo responsável por armazenar uma chave, é o primeiro que a sucede no sentido horário neste espaço. Cada nodo n mantém uma tabela chamada finger table, onde cada entrada i contém o endereço do nodo que sucede n em pelo menos n+2 n 1 unidades de distância. As chaves são dispostas ordenadamente no anel do Chord, e a distância entre elas é calculada por comparações aritméticas. Os nodos utilizam as finger tables para rotear mensagens, encaminhando-as sempre para o nodo que possua a maior chave menor que a buscada. O protocolo Chord garante que, estando as finger tables de todos os nodos atualizadas, qualquer chave pode ser encontrada em no máximo log n saltos com grande probabilidade. A rede utiliza também um algoritmo de Hash Consitente para gerar chaves dos nodos e objetos, realizando um certo balanceamento da carga entre os participantes da rede Pastry Assim como o Chord, o Pastry [19] também organiza as chaves em um espaço circular. No Pastry, todos os nodos mantém ao menos uma lista chamada leaf set e uma tabela de roteamento. O leaf set de um certo nodo contém os seus vizinhos imediatos em ambas as direções do círculo. A tabela de roteamento é construída de forma que a n-ésima entrada na tabela contenha o endereço do nodo cujo identificador possui os n primeiros dígitos em comum. Existindo mais de um nodo que compartilhe certa quantidade de dígitos em comun, a tabela irá armazenar o endereço do nodo mais próximo. Para realizar o roteamento, sempre que um nodo receber uma mensagem, ele primeiramente irá examinar o seu leaf set. Caso o nodo que armazena a chave buscada esteja nesta lista, a mensagem é encaminhada para seu destino. Caso contrário, o nodo irá procurar em sua tabela de roteamento o endereço do nodo que possui o maior número de dígitos em comum com a chave buscada. Seguindo este algoritmo, o protocolo de roteamento converge até encontrar o nodo destino.

15 15 4 Sistemas de arquivos Um sistema de arquivos deve eficientemente guardar e recuperar dados, indexando e organizando-os sobre um dispositivo de armazenamento qualquer. Os dados são armazenados na forma de arquivos, uma abstração utilizada para agrupar uma certa quantidade de dados relacionados entre si. O sistema de arquivos gerencia a alocação de espaço de armazenamento para estes arquivos, alocando espaço para novos arquivos e liberando o espaço ocupado por arquivos removidos. Para organizar a grande quantidade de arquivos que esses sistemas podem armazenar, utilizam-se diretórios. Os diretórios são estruturas lógicas que podem armazenar arquivos e outros diretórios, chamados sub-diretórios, criando uma estrutura hierárquica entre os arquivos do sistema. Na maioria dos sistemas de arquivos, os diretórios são armazenados como arquivos especiais, sendo o seu conteúdo a lista de arquivos e sub-diretórios nele armazenados. Os diretórios em geral guardam, para cada arquivo ou sub-diretório, informações como nome, localização, tamanho e tipo dos arquivos, armazenando-as de forma que possam ser modificadas, buscadas e listadas com eficiência. Os sistemas operacionais Unix-like, foco deste trabalho, criam um sistema de arquivos virtual (VFS), que agrupa todos os arquivos presentes no sistema em um único grande sistema de arquivos. Nestes sistemas, existe um único diretório raiz, e todos os arquivos são armazenados em algum local dentro desta hierarquia. Para acessar arquivos presentes em um dispositivo qualquer de armazenamento, o sistema operacional deve ser informado do local na hierarquia virtual de diretórios em que os arquivos devem ser posicionados. Esse processo chama-se montagem de um sistema de arquivos. Por exemplo, para acessar o sistema de arquivos presente em um CD-ROM, o sistema deverá montar este dispositivo em um determinado diretório do sistema de arquivos virtual. Este diretório é denominado mount-point ou ponto de montagem. Após a montagem deste dispositivo, todos os arquivos presentes neste dispositivo estarão disponíveis dentro deste ponto de montagem. Toda a interação entre uma aplicação qualquer e o sistema de operacional é feita através

16 16 de chamadas de sistema. Existem cinco categorias principais de chamadas de sistema: controle de processos, manipulação de dispositivos, manutenção da informação, comunicações e manipulação de arquivos [23]. É através das chamadas de sistema de manipulação de arquivos que uma aplicação faz requisições ao sistema de arquivos. As chamadas de sistema presentes em sistemas Unix-like mais relevantes a este trabalho são: read: Lê certa quantidade de dados do sistema de arquivos. write: Escreve dados no sistema de arquivos. readdir ou getdents: Retorna a lista de arquivos de um diretório. stat: Retorna os atributos de um arquivo ou diretório. open: Abrir ou criar um novo arquivo. close: Fechar um arquivo. mkdir: Criar um diretório. unlink: Apagar um arquivo. rmdir: Apagar um diretório. Todas as chamadas de sistema referentes a arquivos são repassadas para o sistema de arquivos através do kernel do sistema operacional. O código do sistema de arquivos, em geral, encontra-se dentro do kernel do sistema. Por este motivo, para inserir suporte a outros sistemas de arquivos em seu kernel, o usuário deve possuir poderes de administrador do sistema. 4.1 FUSE O FUSE (Filesystem in Userspace) é um projeto código-livre disponível para a maioria dos sistemas Unix-like, que permite a implementação de um sistema de arquivos completo em um programa modo usuário. Desta forma, é possível que um usuário qualquer rode ou implemente o seu próprio sistema de arquivos, sem necessitar permissões de administrador ou quaisquer modificações no kernel do sistema. O FUSE faz a ligação entre o programa modo usuário e a interface de sistema de arquivos do kernel. Para tal, ele é composto por um módulo carregável do kernel, responsável por repassar as requisições pela interface do sistema de arquivos, e uma API, que é utilizada pelo programa

17 17 modo usuário. Para a comunicação entre a API e o módulo do kernel, é utilizado um descritor de arquivo especial, obtido através do device node /dev/fuse [6]. Este descritor de arquivos é passado ao kernel através da chamada de sistema mount, criando assim um sistema de arquivos real no sistema. A figura 4.1 ilustra o funcionamento de um sistema de arquivos utilizando o FUSE. Uma operação de listagem de diretório (ls -l) é realizada no diretório /tmp/fuse. Esta operação é traduzida em uma chamada de sistema e repassada ao kernel. Por tratar-se de uma chamada de sistema referente ao sistema de arquivos, o kernel a encaminha ao VFS. O VFS checa a qual sistema de arquivos pertence o diretório em questão, e posteriormente encaminha-o ao módulo do kernel do FUSE. O módulo do FUSE se comunica com a API utilizada pelo programa modo usuário através do device node /dev/fuse, como descrito anteriormente, encaminhando a requisição ao programa. O programa responde à requisição, percorrendo o mesmo caminho até ser processada de volta pela aplicação que a requisitou (ls neste exemplo). Figura 4.1: Exemplo de funcionamento do fuse. Retirado de [6] O FUSE é muito utilizado na implementação de sistemas de arquivos especiais, onde os arquivos não são armazenados em disco ou dispositivos de armazenamento. Qualquer recurso disponível ao programa pode ser exportado como um sistema de arquivos.

18 18 5 Distributed Filesystem (DIFS) DIFS é uma rede P2P totalmente distribuída (pura), em que nenhum nodo possui função especial, e possui o objetivo de armazenar arquivos de forma distribuída entre os participantes. Os usuários acessam os arquivos armazenados na rede utilizando a interface de um sistema de arquivos convencional. Cada participante da rede determina a quantidade de espaço em disco local que está disposto a compartilhar. A soma dos espaços compartilhados forma um grande sistema de arquivos, comum a todos, e qualquer nodo é capazer de criar e remover arquivos e diretórios deste ambiente. Uma vez criado, o arquivo estará disponível a todos os participantes. Como em um sistema de arquivos qualquer, para iniciar uma sessão um ponto de montagem deve ser selecionado. Após o início da sessão, todos os arquivos estarão disponíveis dentro deste ponto de montagem. Exemplificando, caso o usuário monte o sistema de arquivos no ponto de montagem /tmp/sandbox, um arquivo artigo.pdf armazenado na pasta raíz do sistema estará disponível em /tmp/sandbox/artigo.pdf. O mesmo vale para diretórios e subdiretórios. Para que qualquer usuário possa utilizar o sistema, o DIFS utiliza o FUSE, descrito nos capítulos anteriores, como interface com o kernel do sistema operacional. Quando um arquivo ou diretório é criado, o sistema decide qual nodo será responsável por armazená-lo fisicamente. Além disso, réplicas são distribuídas na rede para que o arquivo continue acessível mesmo que o nodo responsável falhe. Todos os acessos a esse arquivo ou diretório devem ser encaminhados para estes nodos, que são os únicos capazes de disponibilizar conteúdo e meta-informações deste arquivo. Neste sistema, é possível manipular arquivos que não estão armazenados fisicamente em um mesmo computador. Para utilizá-lo, não é necessário realizar o download completo de todos os arquivos acessados. A transferência é feita sob demanda, caso seja necessária, e depende unicamente da implementação da aplicação que está utilizando o sistema de arquivos.

19 Arquitetura do Sistema O DIFS é uma rede P2P totalmente distribuída (pura) e estruturada que utiliza uma DHT como rede overlay. O sistema é composto por diversos nodos que cedem espaço de armazenamento à rede. O capacidade de armazenamento do sistema é igual a soma dos espaços cedidos pelos participantes. Cada arquivo criado na rede é armazenado por um conjunto de nodos. Todo arquivo possui um nodo responsável, denominado keeper, que é o responsável por gerenciar as réplicas e manter a consistência entre elas. Os nodos que armazenam as réplicas de um arquivo são denominados storers. O sistema distribui o armazenamento dos arquivos entre os vários participantes da rede. Arquivos de um mesmo diretório ou de um mesmo usuário não são necessariamente armazenados em um mesmo nodo, não existindo restrição quanto à localização física dos arquivos na rede. O sistema também garante a distribuição de carga de maneira eficiente entre os participantes. Como em qualquer sistema de arquivos, os diretórios são armazendos da mesma maneira que arquivos normais. No DIFS, por questões de desempenho, os diretórios guardam também os atributos dos arquivos. Isso significa que o nodo que armazena um diretório é capaz de responder chamadas getattr para todos os arquivos que estão dentro deste diretório. Isso garante que operações que listam diretórios e exibem atributos dos arquivos, como ls -l, resultem em apenas um acesso ao diretório, e não um acesso a cada arquivo. Daqui em diante arquivo pode significar um arquivo normal ou um diretório. Todas as operações que modifiquem um arquivo ou suas meta-informações devem ser encaminhadas ao keeper do arquivo, para que ele repasse aos storers, mantendo assim a coerência entre as réplicas. Já as operações de leitura, que com grande probabilidade serão em maior número, podem ser requisitadas à qualquer storer. Essa estratégia diminui a formação de gargalos na rede devido a arquivos populares ou diretórios frequentemente acessados. Por estarem distribuídos pela rede, torna-se necessária a utilização de um mecanismo que possa indexar o nome de um arquivo qualquer, aos nodos que o armazenam, em especial ao seu keeper. Para tal, o DIFS possui uma interface bem definida com um Serviço de Indexação. Este serviço deve retornar o keeper e os storers, dado o nome de um arquivo qualquer existente na rede. O sistema não possui nenhuma restrição quanto ao Serviço de Indexação que utiliza. Para localizar arquivos na rede, o Serviço de Indexação poderia realizar floods na rede, por exemplo. Todavia, um dos objetivos deste sistema é ser totalmente distribuído, e fazer flood na rede para cada arquivo acessado limitaria em muito a sua escalabilidade. Por isso, consideramos que o

20 20 sistema utiliza uma DHT [8, 19, 12], como Serviço de Indexação. Para cada arquivo presente no sistema existe uma entrada na DHT, sendo a chave o nome do arquivo, e o valor a lista de endereços dos nodos que o armazenam. O primeiro nodo desta lista é o keeper do arquivo, o restante, storers. A maneira em que esta lista é armazenada na DHT é descrita na sessão Por tratar-se de uma rede altamente heterogênea, onde podem existir nodos com quantidades variáveis de espaço em disco para compartilhar, o sistema utiliza um algoritmo próprio para decidir onde armazenar arquivos. Para viabilizar esta estratégia, o nodo escolhido para armazenar o arquivo pela função hash da DHT armazena apenas o endereço do keeper e dos storers do arquivo. O sistema possui também um Serviço de Gerenciamento de Espaço Livre, que provê informações sobre o espaço livre em todos os nodos da rede. A partir destas informações, o algoritmo de balancemanto decide onde armazenar arquivos, permitindo que possamos criar mecanismos para balancear a carga de maneira eficiente, ao custo de aumentar o overhead no acesso aos arquivos. O Sistema de Gerenciamento de Espaço Livre será descrito na sessão Um exemplo de operação executada no sistema é mostrado na figura 5.1. O nodo A deseja executar uma operação de leitura sobre o arquivo /arquivo. Primeiramente A chama o Serviço de Indexação (DHT), para localizar os nodos que armazenam /arquivo. O nodo E é o responsável por armazenar esta chave na DHT. A partir da resposta que A recebeu da DHT (que estava armazenada em E), ele conclui que o nodo B é o keeper deste arquivo, e os nodos D, F e C os storers. A escolhe um desses nodos e envia diretamente a ele a requisição. A interface com a DHT é descrita com mais detalhes na sessão Serviço de Indexação O Serviço de Indexação é responsável por armazenar o endereço dos nodos que armazenam um arquivo qualquer. O DIFS utiliza uma DHT para guardar estas informações. Independentemente do protocolo e implementação da DHT que o sistema utilize, ela provê apenas a operação: dada uma chave encontre o valor [8, 19, 12]. Utilizando esta abordagem, cada chave pode mapear um único valor. Entretanto, a forma como o sistema indexa os arquivos e réplicas requer que o nome do arquivo (chave), possa mapear o endereço do keeper e dos storers. Para isso, quando um arquivo é criado, o seguinte par [chave, valor] é inserido na DHT: [nome do arquivo, A#B#C#D], considerando que A, B, C e D sejam os endereços dos nodos que armazenam o arquivo. Para acessar um arquivo qualquer, um nodo irá fazer uma busca pela

21 21 Figura 5.1: Exemplo de funcionamento do sistema. chave nome do arquivo, recebendo da DHT a lista de nodos que o armazenam caso o arquivo exista na rede. O primeiro nodo da lista é o keeper do arquivo, o restante, storers. Internamente, o sistema repassa para a DHT o caminho completo sempre que necessita identificar algum arquivo. Por exemplo, ao acessar o arquivo monografia.pdf que está dentro do diretório arquivos na raíz do sistema, a chave buscada na DHT deve ser /arquivos/monografia.pdf. Isso garante que arquivos com o mesmo nome mas armazenados em pastas diferentes possam ser indexados de maneira correta. Um fragmento exemplo de uma DHT é apresentado na tabela Neste exemplo, o keeper do arquivo /arquivo é o nodo A, e existem réplicas nos nodos B, C e D (storers). O mesmo vale para as outras entradas, como o diretorio /diretorio, em que B é o seu keeper e D, F e C os storers. O arquivo /diretorio/subdiretorio/arquivo possui apenas um storer, F. O sistema assume que falhas em nodos não irão interferir na indexação dos arquivos. Protocolos como Pastry [19] armazenam réplicas em nodos próximos, e garantem a disponibilidade dos dados mesmo diante de falhas em nodos.

22 22 Chave /arquivo /diretorio /diretorio/arquivo /diretorio/subdiretorio /diretorio/subdiretorio/arquivo Valor A#B#C#D B#D#F#C D#A#B#F C#F#A#B A#F Tabela 5.1: Exemplo de um fragmento de uma DHT Serviço de Gerenciamento de Espaço Livre Uma das grandes vantagens um utilizar um sistema de arquivos distribuído, é a possibilidade de armazenar uma quantidade de dados superior ao espaço de disco disponível localmente. Para isso, é necessário um algoritmo para a distribuição da carga nesta rede. O primeiro passo é gerenciar o espaço livre em cada nodo. Para realizar esta tarefa, o sistema conta com um Serviço de Gerenciamento de Espaço Livre, que divide os nodos em várias categorias, baseado na quantidade de espaço livre que ele possui. As categorias são faixas pré-determinadas de espaço livre, sendo que um nodo pertence à categoria que possui o valor menor e mais próximo que a sua quantidade de espaço disponível. Supondo que o sistema determine as faixas a cada 512Mb, por exemplo, um nodo que possua 2.8Gb livres se encaixará na categoria 2.5Gb, significando para a rede que ele possui ao menos 2.5Gb disponíveis. Para disponibilizar estas informações para toda a rede, é criada uma entrada em uma DHT para cada categoria. As chaves referentes às categorias irão apontar para o conjunto de nodos que se encaixam nelas. Cada nodo deve monitorar o seu espaço disponível, atualizando a DHT sempre que atingir o limiar de alguma categoria. De posse destas informação, o sistema utiliza uma espécie de algoritmo Best-fit para decidir qual nodo irá armazenar um arquivo. Por exemplo, para criar um arquivo de 1.2Gb, o sistema busca os nodos que estão na categoria 1.5Gb. Caso não existam nodos suficiente nesta categoria, o sistema irá busca nodos em categorias com maior espaço de armazenamento (2Gb, 2.5Gb, etc.). Um fragmento exemplo da DHT utilizada pelo Serviço de Gerenciamento de Espaço Livre é apresentado na tabela Neste exemplo, o nodo F possui entre 512Mb e 1Gb de espaço livre. Os nodos C, A, D e H possuem entre 2Gb e 2.5Gb livres, e o nodo E possui mais do que 2.5Gb livres.

23 23 Chave Valor 512 Mb F 1 Gb G#B 1.5 Gb 2 Gb C#A#D#H 2.5 Gb E Tabela 5.2: Exemplo de um fragmento da DHT usada pelo Sistema de Gerenciamento de Espaço Livre. Por questões de otimização, o Serviço de Gerenciamento de Espaço Livre e o Serviço de Indexação utilizam a mesma DHT. Como todos os arquivos inseridos na DHT são referenciados pelo caminho completo, /aquivos/monografia.pdf por exemplo, não existirá conflito entre as entradas referentes a arquivos e as referentes a espaço livre. Todas as entradas referentes a arquivos iniciam com o caracter /, enquanto as referentes a espaço livre iniciam com dígitos Operações Nesta sessão estão descritas as sequências de passos realizadas pelo sistema para executar algumas das principais operações realizadas na rede. Criar arquivo Para criar um arquivo, o sistema escolhe através do algoritmo de balanceamento e do Serviço de Gerenciamento de Espaço Livre os nodos que irão armazená-lo. Suponhamos que o nodo A esteja criando um arquivo, e que os nodos B, C, D e E irão armazená-lo, sendo B o seu keeper e o restante storers. O nodo A transfere o arquivo para o seu novo keeper, o nodo B. Logo após, o keeper (nodo B) envia uma cópia do arquivo para os storers (nodos C, D, e E). Finalizadas as transferência, A insere uma entrada na DHT, contendo o nome do arquivo e os endereços dos nodos B, C, D e E. O último passo é criar uma nova entrada no diretório em que o arquivo está sendo criado, inserindo este arquivo na hierarquia do sistema de arquivos. Para isso, o DIFS obtém através da DHT o endereço do keeper do diretório em que o arquivo está sendo criado. Após obter o endereço, o nodo A irá avisá-lo sobre o novo arquivo para que as requisições seguintes de listagem deste diretório contenham a entrada referente ao novo arquivo. O keeper do diretório deve encarregar-se de repassar as modificações feitas (inserção de novo arquivo) aos nodos que

24 24 possuem réplicas deste diretório. Apagar arquivo Para apagar um arquivo qualquer da rede, o primeiro passo é buscar o keeper do seu diretório pai. Após encontrar este nodo, o sistema o informa que o arquivo está sendo deletado, e que a entrada da lista de arquivos deste diretório referente ao arquivo a ser excluído, pode ser apagada. O próximo passo é encontrar o keeper do arquivo e informá-lo que o arquivo está sendo excluído. Ele irá encaminhar a mensagem para os storers, para que todas as réplicas sejam excluídas. Após enviar a mensagens, o keeper irá excluir a entrada referente a este arquivo da DHT. Acessar arquivo O procedimento para ler, escrever, obter ou setar informações sobre arquivos é essencialmente o mesmo. Em todos esses casos, através da DHT é localizada a lista de nodos que armazenam o arquivo. Em operações de leitura, escolhemos aleatoriamente um dos nodos (keeper ou storer) para fornecer as informações desejadas. Em operações de escrita ou que modifique alguma meta-informação, é necessário que a operação seja enviada ao keeper do arquivo, que será o responsável por propagar as modificações para todos os storers, mantendo a coerência entre as réplicas. Caso seja uma operação de escrita, o keeper do diretório pai do arquivo também deve ser acessado, pois os diretórios também armazenam meta-informações sobre os arquivo nele contidos. Listagem de diretório Diferentemente dos sistemas de arquivos convencionais, no DIFS, por questões de desempenho, os diretórios armazenam também meta-informações dos arquivos. Isso garante que operações de listagem de diretórios necessitem também de meta-informações dos arquivos, sejam realizadas com acessa a um nodo apenas. Esta estratégia aumenta o overhead para modificar um arquivo, pois todas as alterações que modifiquem alguma meta-informação, devem ser enviadas ao keeper do seu diretório pai para que as informações armazenadas continuem consistentes. Entretanto, esta abordagem aumenta a performance das operações de listagem de diretórios, sendo que o número de arquivos presente em um diretório pode crescer indefinidamente.

25 25 Entrada e saída de nodos Para o usuário, entrar na rede é semelhante a montar um sistema de arquivos. A maneira em que o nodo entra na rede após iniciar uma sessão pode diferir de acordo com o Serviço de Indexação utilizado. Para o caso da DHT, o nodo precisa conhecer o endereço de algum outro participante, para através dele ingressar na rede [8]. A partir do momento que o nodo entrou na rede, ele estará cendendo seus recursos a todos os integrantes. Caso o nodo não possua o endereço de nenhum participante da rede ou deseje criar um novo sistema de arquivos, ele deverá iniciar uma nova DHT. Logo após, ele deve criar o diretório /, a pasta raíz do sistema de arquivos. Outros nodos que desejem ingressar na rede devem conhecêlo. Para sair da rede, um nodo deve passar a responsabilidade dos arquivos e réplicas que armazena para algum outro participante. Para cada réplica armazenada, o nodo deve informar ao keeper deste arquivo que está deixando a rede, para que este possa criar mais uma réplica em outro nodo qualquer. Caso o nodo seja keeper de algum arquivo, ele deve transferir a responsabilidade para algum dos seus storers, que então será responsável por criar mais um réplica do arquivo na rede, mantendo sempre o número correto de cópias disponíveis. Esta estratégia garante que os arquivos e suas réplica estarão sempre disponíveis. Desta forma, os nodos não precisam tranferir nenhum arquivo para sair da rede. Enviando poucas mensagens, o nodo estará pronto para deixar a rede sem causá-la dano algum. Falha em nodo Como mencionado anteriormente, para sair da rede um nodo deve passar a responsabilidade pelos arquivos e réplicas que armazena para algum outro participante. Isso garante a disponibilidade dos arquivos inseridos. Entretanto, caso ocorra algum outro tipo de falha em algum dos integrantes, como queda de energia, problemas de hardware ou problemas de conexão, nada pode-se afirmar sobre a presença dos arquivos que ele armazenava. Além de distribuir a carga proveniente de acesso a arquivos, as réplicas garantem a disponibilidade dos arquivos do sistema mesmo em caso de falhas. O número de réplicas que o sistema armazena para cada arquivo pode variar de acordo com a implementação. Um número pequeno de réplicas pode diminuir a confiabilidade do sistema, enquanto um número grande aumenta o overhead para a manutenção e coerência, exigindo maior capacidade de armazenamento. Como mencionado anteriormente, para criar um arquivo o algoritmo de balanceamento

26 26 seleciona nodos que possuam espaço suficiente para armazená-lo. Caso o algoritmo de balanceamento não consiga selecionar nodos suficiente para armazenar o número correto de réplicas, ele é criado com um número menor de cópias. O primeiro nodo a acessar este arquivo possuindo espaço suficiente será eleito seu storer, e irá manter uma réplica do arquivo. Isso se repetirá até que o arquivo possua o número de storers especificado. Todos os keepers de algum arquivo devem checar periodicamente o estado dos storers. Para diminuir o overhead causado por essas checagens, elas podem estar embutidas em mensagens de atualização de réplicas, enviadas sempre que um arquivo sofre alguma modificação. A diminuição no intervalo entre essas mensagens aumenta a confiabilidade da rede, pois diminui o tempo de detecção de falha de um storer. Sempre que um keeper detectar falha em algum dos storer, ele irá criar uma nova réplica deste arquivo na rede. Caso ocorra falha em algum keeper, os storers irão detectar, pois não estarão mais recebendo as checagens periódicas. Caso isto ocorra, o próximo nodo da lista da DHT irá ser o novo keeper do arquivo, e deve criar uma outra réplica na rede e atualizar a lista de nodos na DHT.

27 27 6 Resultados Experimentais Visando testar a viabilidade e desempenho do DIFS, um protótipo do sistema foi desenvolvido. A partir deste protótipo foram realizados diversos testes, cujos resultados foram comparados aos resultados dos mesmos testes aplicados sobre o sistema de arquivos de rede NFS [22]. Apesar de ser baseado no modelo cliente-servidor, o NFS é um sistema estável e com bom desempenho, sendo utilizado como base para a medida de desempenho de muitos dos trabalhos existentes na área de sistemas de arquivos distribuídos [13, 16, 10]. O protótipo do sistema foi desenvolvido na linguagem C, sendo compatível com sistemas operacionais Unix-like em geral. O protótipo pode ser executado em qualquer máquina que possua suporte ao FUSE, implementando as funcionalidades fundamentais para a realização da prova de conceito do sistema. Uma das limitações do protótipo é que todos os arquivos e diretórios criados na rede possuem fator de replicação 1, o que significa que um arquivo é sempre armazenado em um único nodo da rede. Desta forma, caso ocorra falha em algum nodo da rede, dados armazenados podem ser perdidos. Para a simulação foi desenvolvido também um software que simula o comportamento de uma DHT. Este simulador é implementado na liguagem Ruby, e segue o protocolo Chord [8] tanto na organização dos nodos quanto no roteamento das mensagens. Para iniciar uma sessão do simulador, os participantes devem ter conhecimento de todos os nodos envolvidos, para assim criarem as estruturas necessárias e realizar o roteamento correto das mensagens. Apesar de somente um simulador, este software é útil para acrescentar e estimar o overhead causado pela DHT no desempenho do sistema. Os testes de desempenho foram realizados utilizando 8 máquinas conectadas por uma rede local (LAN) 100Mbps. As máquinas possuem poderes computacionais diversos, variando de um Pentium dual core 1.8GHz com 1Gb de memória RAM a um Celerom 2.66GHz com 256Mb de memória RAM. Foram realizados 4 testes que executam as principais operações relevantes a um sistema de