Este documento descreve a modelagem e implementação de um sistema de arquivos distribuído baseado em DHT. O objetivo é pesquisar, projetar e documentar um sistema de arquivos em nível de usuário que seja transparente, escalável e permita a replicação e fragmentação de arquivos de forma distribuída. O sistema foi construído usando uma tabela hash distribuída que mapeia hashes para nós servidores responsáveis pelos arquivos.

1. F´bio Moretti Serra
a
Modelagem e implementa¸˜o de um
ca
sistema de arquivos distribu´ baseado em
ıdo
DHT
Itatiba - S˜o Paulo - Brasil
a
Dezembro de 2008

2. F´bio Moretti Serra
a
Modelagem e implementa¸˜o de um
ca
sistema de arquivos distribu´ baseado em
ıdo
DHT
Monografia apresentado a disciplina Tra-
`
balho de Conclus˜o de Curso, do Curso de
a
Engenharia da Computa¸ao da Universidade
c˜
S˜o Francisco, sob a orienta¸ao do Prof.
a c˜
Rodrigo Chavez Monteiro do Prado, como
exigˆncia parcial para conclus˜o do curso de
e a
gradua¸ao.
c˜
Orientador:
Prof. Ms. Rodrigo Chavez Monteiro do Prado
¸˜
Curso de Engenharia da Computacao
˜ o Francisco
Universidade Sa
Itatiba - S˜o Paulo - Brasil
a
Dezembro de 2008

3. i
Modelagem e implementa¸˜o de um sistema de
ca
arquivos distribu´ baseado em DHT
ıdo
F´bio Moretti Serra
a
Monografia defendida e aprovada em 10 de Dezembro de 2008 pela Banca Examina-
dora assim constitu´
ıda:
Prof. Ms. Rodrigo Chavez Monteiro do Prado (Orientador)
USF - Universidade S˜o Francisco – Itatiba – SP.
a
Prof. Ms. Thales Coelho Borges Lima
USF - Universidade S˜o Francisco – Itatiba – SP.
a
Prof. Angelo Amaral
USF - Universidade S˜o Francisco – Itatiba – SP.
a

4. ii
“A sorte favorece s´ ` mente preparada”
oa
Isaac Asimov

5. iii
Sum´rio
a
Lista de abreviaturas e siglas v
Lista de Figuras vi
Resumo vii
Abstract viii
¸˜
1 INTRODUCAO 1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Organiza¸˜o do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ca 2
2 ARQUITETURAS DE SISTEMAS DISTRIBU´
IDOS 3
2.1 Sistemas de arquivos distribu´
ıdos . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Tabela hash distribu´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ıda 7
3 ARQUITETURA 9
3.1 Requisitos do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Implementa¸˜o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
ca
3.3.1 Sistema distribu´ . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
ıdo
3.3.2 DHT Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.3 Gerenciamento dos diret´rios . . . . . . . . . . . . . . . . . . . . . 17
o
3.3.4 Interface com o usu´rio . . . . . . . . . . . . . . . . . . . . . . . . . 18
a
3.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6. Sum´rio
a iv
˜
4 CONCLUSAO 22
Apˆndice A -- Tabela comparativa dos sistemas de arquivo distribu´
e ıdos 23
Apˆndice B -- Diagramas UML
e 24
B.1 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2 Diagramas de seq¨ˆncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ue
Referˆncias
e 30

7. v
Lista de abreviaturas e siglas
AFS Andrew File System
API Application Programming Interface
DFS Distributed File System
DHT Distributed Hash Table
GFS Google File System
GPL General Public License
IP Internet Protocol
NFS Network File System
PC Personal Computer
RAM Random Access Memory
RPC Remote Procedure Call
SHA Secure Hash Algorithm
TCP Transmission Control Protocol
UML Unified Modeling Language
WAN Wide Area Network

8. vi
Lista de Figuras
1 Estrutura de sobreposi¸ao de sistemas baseada em DHT . . . . . . . . . .
c˜ 7
2 Exemplos de resolu¸ao de chaves no Chord (TANENBAUM; STEEN, 2007). .
c˜ 8
3 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Rela¸˜o entre as principais classes do projeto . . . . . . . . . . . . . . . . . 24
ca
5 Seq¨ˆncia para a abertura de um arquivo . . . . . . . . . . . . . . . . . . . 25
ue
6 Seq¨ˆncia para a grava¸˜o de um arquivo . . . . . . . . . . . . . . . . . . . 26
ue ca
7 Seq¨ˆncia para a remo¸ao de um arquivo . . . . . . . . . . . . . . . . . . . 27
ue c˜
8 Seq¨ˆncia para a altera¸ao das permiss˜es de um arquivo . . . . . . . . . . 28
ue c˜ o
9 Seq¨ˆncia para a obter informa¸oes sobre um arquivo . . . . . . . . . . . . 28
ue c˜
10 Seq¨ˆncia para obter o conte´do de um diret´rio . . . . . . . . . . . . . . . 29
ue u o
11 Seq¨ˆncia para a entrada de um novo n´ na DHT . . . . . . . . . . . . . . 29
ue o

9. vii
Resumo
Uma caracter´ ıstica dos sistemas de arquivos para redes ´ que todas as opera¸˜es de
e co
leitura e escrita s˜o realizadas por um servidor, causando uma centraliza¸ao de carga de
a c˜
processamento e armazenamento.
Uma alternativa para resolver este problema ´ a configura¸ao de um sistema de ar-
e c˜
quivos distribu´
ıdo, em que os dados permanecem espalhados de forma controlada, entre
diversas m´quinas constituintes de um agrupamento. Dessa forma a carga ´ dividida entre
a e
todos os computadores da rede. Exemplos desse modelo de sistema s˜o o Andrew File
a
System, CODA, SPRITE e Google File System.
Os objetivos desse projeto s˜o a pesquisa, implementa¸ao e a elabora¸ao da docu-
a c˜ c˜
menta¸˜o t´cnica de um sistema de arquivos distribu´ em n´ de usu´rio. Possuindo
ca e ıdo ıvel a
requisitos como transparˆncia, escalabilidade e replica¸˜o e fragmenta¸ao dos arquivos.
e ca c˜
Para atender estes requisitos, o sistema foi montado sobre uma tabela hash distribu´
ıda
(DHT) que cria uma rede de sobreposi¸˜o fornecendo os m´todos necess´rios para o geren-
ca e a
ciamento dos dados do sistema. Desta maneira, as m´quinas clientes obt´m a localiza¸˜o
a e ca
dos arquivos atrav´s de consultas na DHT que possui o mapeamento de um determinado
e
hash a uma m´quina servidora respons´vel pelo arquivo.
a a

10. viii
Abstract
One of the network file systems feature is that all read and write operations are done
on server side resulting on storage and CPU load centralization.
An option to solve this issue is the setup of a distributed file system, where the data
remain distributed on a controllable way, between different machines belonging to a group.
In this way the load is divided between all computers in the network. Some examples of
this system model are Andrew File System, CODA, SPRITE and Google File System.
The goals of this project are research, implementation and development of a technical
paper describing a user level distributed file system. With requirements as transparency,
scalability, replication and file fragmentation.
To accomplish such requisites, the system was designed over a distributed hash table
(DHT) which creates an overlay network providing the necessary methods to manage data
on the system. In this way, the client machines get the data location through queries on
the DHT that holds the mappings from a hash to a server node responsible for that file.

11. 1
1 ¸˜
INTRODUCAO
O sistema de arquivos tem a fun¸˜o de abstrair os poss´
ca ıveis dispositivos de armaze-
namento apresentando ao usu´rio uma unica estrutura padr˜o de diret´rios e arquivos.
a ´ a o
Este tamb´m deve fornecer maneiras independentes para criar, ler, escrever e remover
e
arquivos. (TANENBAUM, 1995)
Quando se trata de um sistema de arquivos em rede, o objetivo b´sico ´ permitir
a e
que um conjunto arbitr´rio de clientes e servidores possam compartilhar um sistema de
a
arquivos comum. Um padr˜o muito conhecido ´ o Network File System (NFS) (SHE-
a e
PLER, 2003). A caracter´
ıstica b´sica da arquitetura do NFS ´ o fato de os servidores
a e
disponibilizarem alguns de seus diret´rios e de os clientes montarem remotamente estes
o
diret´rios. Os arquivos compartilhados s˜o justamente aqueles pertencentes a hierarquia
o a `
de diret´rios, podendo ser lidos e escritos da maneira usual.
o
Esta topologia cliente-servidor, t´
ıpica do NFS, caracteriza-se por todas as opera¸oes
c˜
de leitura e escrita serem realizadas pelo servidor, causando uma centraliza¸˜o de carga
ca
de processamento e armazenamento.
Uma alternativa para resolver este problema ´ a configura¸ao de um sistema de ar-
e c˜
quivos distribu´
ıdo, em que os dados permanecem espalhados de forma controlada, entre
diversas m´quinas constituintes de um agrupamento. Dessa forma a carga ´ dividida entre
a e
todos os computadores da rede.
Um exemplo de sistema de arquivos distribu´
ıdos ´ o Andrew File System (AFS)
e
(MELLON, 2008), ele ´ constitu´ por clusters, com um servidor de arquivos e v´rias
e ıdo a
esta¸oes clientes. Seu objetivo ´ fazer com que a maioria do tr´fego seja local a um unico
c˜ e a ´
cluster, para reduzir a carga no servidor. Quando um usu´rio solicita a abertura de um
a
arquivo, este ´ carregado para o disco da esta¸ao, de maneira a parecer um arquivo comum
e c˜
para o sistema operacional, desta forma as chamadas de leitura e escrita trabalham de
forma usual.

12. 1.1 Objetivos 2
O armazenamento distribu´ pode proporcionar nativamente v´rios requisitos de-
ıdo a
sej´veis de um sistema de arquivo comum, como redu¸ao da duplicidade de um mesmo
a c˜
arquivo em m´quinas clientes, replica¸˜o dos dados para seguran¸a (backup), aproveita-
a ca c
mento adequado de discos e a disponibilidade da informa¸ao para qualquer esta¸ao.
c˜ c˜
Um ponto importante para todo sistema distribu´ ´ a capacidade de amplia¸ao sem
ıdo e c˜
degradar o desempenho do ambiente. Este requisito, conhecido como escalabilidade, pode
ser atingido com a utiliza¸˜o de tabelas hash distribu´
ca ıdas. Atrav´s deste recurso n˜o s´
e a o
os dados do sistema est˜o distribu´
a ıdos, como tamb´m as informa¸˜es de controle.
e co
1.1 Objetivos
Pesquisa, modelagem e desenvolvimento de um software para armazenamento de ar-
quivos em rede baseado em tabela hash distribu´
ıda, simulando um sistema de arquivos
em n´ de usu´rio, isto ´, n˜o ser˜o alteradas as fun¸oes do sistema operacional e do
ıvel a e a a c˜
sistema de arquivos local. O sistema dever´ ser funcionalmente sim´trico, onde todas as
a e
m´quinas do agrupamento ter˜o o mesmo papel dentro do sistema.
a a
Objetivos espec´
ıficos:
• Estudo detalhado dos principais sistemas de arquivos distribu´
ıdos e compara¸ao de
c˜
seus recursos;
• Elabora¸ao do projeto incluindo o detalhamento dos recursos e diagramas;
c˜
• Desenvolvimento de um prot´tipo do software para realiza¸˜o de testes e an´lise;
o ca a
1.2 Organiza¸˜o do trabalho
ca
O presente trabalho est´ organizado da seguinte forma, o cap´
a ıtulo 2 descreve algumas
conhecidas implementa¸ao de sistemas distribu´
c˜ ıdos e um esclarecimento sobre tabela hash
distribu´
ıda, a cap´
ıtulo 3 cont´m explana¸˜es sobre a arquitetura e o projeto desenvolvido
e co
e os diagramas constru´
ıdos, no final os testes e as conclus˜es s˜o expostas.
o a

13. 3
2 ARQUITETURAS DE
´
SISTEMAS DISTRIBUIDOS
2.1 Sistemas de arquivos distribu´
ıdos
A seguir ser˜o apresentadas algumas implementa¸˜es de sistemas de arquivos dis-
a co
tribu´
ıdos (DFS - Distributed File System) produzidas por empresas e universidades.
Encontra-se dispon´ no apˆndice A uma tabela comparativa entre os sistemas descritos.
ıvel e
Network File System
O Network File System (NFS) foi desenvolvido pela Sun Microsystems e trata-se tanto
de um projeto de sistema de arquivos quanto um conjunto de especifica¸˜es para acesso
co
a arquivos remotos em redes locais. (SILBERSCHATZ; GALVIN, 2000)
O NFS ´ o DFS mais amplamente utilizado em ambientes UNIX. Ap´s a libera¸˜o
e o ca
da primeira vers˜o do NFS, em 1985, a Sun tornou p´blica a especifica¸ao do protocolo
a u c˜
NFS, isto permitiu a implementa¸˜o de servidores e clientes NFS por outros vendedores
ca
(KON, 1995).
Este protocolo visa a opera¸ao em ambientes heterogˆneos (hardware, sistema ope-
c˜ e
racional, arquiteturas de redes) (SILBERSCHATZ; GALVIN, 2000). Requisito obtido por
meio de chamadas de procedimentos remotos (RPC). Assim, a constru¸˜o de sistemas
ca
aderentes a especifica¸ao NFS permite a intera¸˜o entre implementa¸˜es de diferentes
c˜ ca co
desenvolvedores. Hoje ´ poss´ encontrar implementa¸˜es do NFS para quase todos os
e ıvel co
sistemas operacionais como UNIX, MacOS, OS/2 e Windows.
Por defini¸ao os servidores NFS s˜o sem estados, ou seja, eles n˜o armazenam in-
c˜ a a
forma¸oes sobre o estado de acesso pelo cliente a seus arquivos. Isto garante uma sim-
c˜
plifica¸ao no desenvolvimento da aplica¸˜o e uma ganho de desempenho. Por outro lado,
c˜ ca
servidores sem estado n˜o podem controlar acessos concorrentes e, por conseguinte, n˜o
a a
asseguram a coerˆncia do seu sistema de arquivos. Diferentes clientes podem ter diferentes
e

14. 2.1 Sistemas de arquivos distribu´
ıdos 4
e conflitantes c´pias de um mesmo arquivo ou diret´rio em seu cache local.
o o
O espa¸o de nomes de cada cliente pode ser diferente dos demais, mas, a partir do
c
a e ´
ponto de vista do usu´rio, este ´ local e transparente. E tarefa do administrador do
sistema determinar como cada cliente ir´ ver a estrutura de diret´rios.
a o
A aplica¸˜o de n´ de usu´rio baseada em RPC e a pol´
ca ıvel a ıtica de cache do cliente NFS
configuram um desempenho pior do que o da maioria dos sistemas que descrevemos a
seguir, no entanto atualmente NFS ´ o DFS mais utilizado em redes de trabalho.
e
Andrew File System
O projeto Andrew (AFS) come¸ou no Carnegie Mellon University em 1983 com o
c
apoio da IBM. Seu objetivo era conceber e implementar um DFS ideal para o ambiente
acadˆmico, que iria permitir o compartilhamento de uma estrutura comum de diret´rios
e o
entre milhares de m´quinas clientes Kon (1995).
a
O espa¸o de nomes do AFS ´ composto pelos chamados volumes, estes s˜o associados
c e a
aos arquivos de um unico cliente. Os volumes s˜o agrupados por um mecanismo similar
´ a
aos de montagem do UNIX. A localiza¸˜o dos arquivos ´ registrada em bancos de dados,
ca e
replicados em cada servidor, assim os clientes obtˆm a localiza¸ao dos volumes atrav´s de
e c˜ e
consultas a essa base de dados. (SILBERSCHATZ; GALVIN, 2000)
O AFS foi constru´ para quando um cliente abrir um arquivo remoto, todo ele seja
ıdo
obtido a partir do servidor. Todas as opera¸˜es subseq¨entes de leitura e escrita utilizar˜o
co u a
uma c´pia armazenada em um disco local. S´ quando o arquivo ´ fechado, e se este foi
o o e
modificado, ele ´ transferido de volta para o servidor. Uma das conseq¨ˆncia desta t´cnica
e ue e
´ que um cliente C1 somente pode perceber uma atualiza¸ao do arquivo F feita por outro
e c˜
cliente C2, somente se C1 abrir F ap´s C2 fech´-lo.
o a
AFS-2 trouxe o conceito de chamada de retorno, o que permitiu um cliente abrir e
fechar um arquivo muitas vezes sem acessar o servidor. A chamada de retorno pode ser
enviada pelo cliente quando se atualiza o arquivo, ou pelo servidor quando ele recebe uma
nova vers˜o do arquivo a partir de outro cliente.
a
CODA
O sistema CODA, implementado no in´ dos anos noventa, ´ um descendente do AFS
ıcio e
(KON, 1995). Seu principal objetivo ´ fornecer acesso a um DFS a partir de computadores
e
port´teis. O CODA implementa mecanismos de duplica¸˜o autom´tica n˜o presentes
a ca a a

15. 2.1 Sistemas de arquivos distribu´
ıdos 5
no AFS, por´m a coerˆncia entre v´rias c´pias de um mesmo arquivo ´ mantida com
e e a o e
chamadas de retorno, semelhante ao AFS.
O recurso mais interessante do CODA ´ a possibilidade de acessar arquivos do DFS
e
sem estar conectado ` rede. Se um arquivo est´ armazenado em cache local no disco
a a
do computador port´til, o usu´rio pode ler e atualizar este sem a permiss˜o do servidor.
a a a
Quando o computador port´til ´ reconectado ` rede, o sistema propaga para os servi-
a e a
dores apropriados as atualiza¸oes feitas durante o per´
c˜ ıodo desconectado. Podem ocorrer
conflitos, por exemplo, atualiza¸˜es no mesmo arquivo feitas por clientes diferentes, de-
co
vido a isto o CODA fornece algumas ferramentas para o usu´rio decidir qual vers˜o deve
a a
prevalecer.
Para permitir o acesso aos arquivos enquanto estiver desconectado, o cliente CODA
tenta manter em seu disco local a maior quantidade poss´ de dados. Se o disco local est´
ıvel a
cheio e um novo arquivo deve ser copiado para ele, o arquivo em cache com a prioridade
mais baixa ´ descartado.
e
SPRITE
Os dois principais objetivos do sistema de arquivos SPRITE foram de obter alto
desempenho e a semˆntica UNIX para compartilhamento de arquivos. O desempenho
a
alcan¸ado foi um dos melhores do seu tempo, certamente melhor do que o NFS e o AFS
c
(KON, 1995). A semˆntica UNIX tamb´m foi atingida, o usu´rio encontra o mesmo tipo
a e a
de estrutura de uma m´quina UNIX local.
a
O cliente obt´m a localiza¸ao dos arquivos consultando uma tabela de prefixos. Cada
e c˜
entrada nesta tabela consta o nome do diret´rio, o endere¸o do servidor e um n´mero
o c u
identificador do diret´rio. Esse mapeamento ´ constru´ e atualizado dinamicamente
o e ıdo
atrav´s de mensagem em broadcast na rede.
e
Como o SPRITE ´ utilizado em ambientes de servidores com mem´rias de grande
e o
capacidade e esta¸oes de trabalho normalmente sem discos, este utiliza um esquema em
c˜
que a mem´ria cache de arquivos ´ alocada na mem´ria f´
o e o ısica, e n˜o em discos. Normal-
a
mente, o cache do sistema de arquivos pode chegar a centenas de megabytes da mem´ria
o
dispon´
ıvel.
A fim de economizar o tr´fego da rede, as altera¸oes dos arquivos s˜o gerenciadas por
a c˜ a
um mecanismo chamado atualiza¸˜o atrasada (SILBERSCHATZ; GALVIN, 2000). Uma vez
ca
a cada 30 segundos, todos os blocos, que n˜o foram alterados s˜o enviados para o servidor.
a a

16. 2.1 Sistemas de arquivos distribu´
ıdos 6
Um bloco de dados alterado pode levar at´ 60 segundos para ser enviado para o servidor
e
e depois at´ mais 60 segundos para ser escrito no disco. Por outro lado, a atualiza¸ao
e c˜
atrasada torna o sistema mais sens´ a falhas (KON, 1995).
ıvel
Google File System
Buscando um sistema que atendesse as suas necessidades um DFS, denominado Google
`
File System (GFS), foi desenvolvido pela Google. Os arquivos que est´ utiliza s˜o, em
a a
sua maioria, maiores que gigabytes e as altera¸oes que eles sofrem s˜o frequentemente
c˜ a
por anexa¸˜o e n˜o por substitui¸ao, tendendo a um crescimento cont´
ca a c˜ ınuo. Aliando esses
fatores ao problema de falhas em servidores de baixo custo, os desenvolvedores visaram a
cria¸ao de um sistema escal´vel, ` prova de falhas e com bom desempenho (GHEMAWAT;
c˜ a a
GOBIOFF; LEUNG, 2003).
O GFS ´ um sistema baseado em clusters, onde cada um possui um servidor mestre
e
(master server ) e diversos servidores de por¸˜o (chunkservers). Os arquivos s˜o divididos
ca a
com tamanho fixo de 64 megabytes, identificados por um r´tulo de 64 bits e replicadas
o
entre os chunkservers (TANENBAUM; STEEN, 2007). Usualmente as por¸oes possuem 3
c˜
r´plicas, contudo este n´mero pode ser alterado para arquivos com maior demanda.
e u
Essa t´cnica melhora consideravelmente o desempenho do sistema, pois os arquivos
e
podem ser obtidos paralelamente entre os diversos servidores de por¸˜es. Tamb´m visa
co e
o controle a falhas, pois mesmo no caso de uma falha f´
` ısica num chunkservers, outros
servidores ainda ter˜o c´pias das por¸˜es perdidas.
a o co
Os chunkservers mant´m uma tabela atualizada contendo os dados que possui. Essas
e
informa¸oes s˜o enviadas para o servidor mestre, estando sempre atualizado e conhecendo
c˜ a
a localiza¸˜o das por¸˜es dos arquivos.
ca co
O servidor mestre armazena trˆs tipos principais de meta-dados: servi¸o de nomes
e c
para os arquivos e por¸oes, o mapeamento dos arquivos para suas por¸˜es, e a loca-
c˜ co
liza¸ao de cada r´plica. Tamb´m tem conhecimento dos processos que est˜o utilizando
c˜ e e a
as r´plicas. Em outras palavras, sua fun¸˜o ´ de gerenciar as por¸˜es para que estejam
e ca e co
sempre dispon´
ıveis nos chunkservers para que o cliente GFS possa acess´-las.
a
Essa organiza¸ao n˜o gera gargalo no servidor mestre, pois ap´s a consulta inicial
c˜ a o
para localiza¸˜o das por¸oes, o di´logo passa a ser entre o cliente e o chunkservers. A
ca c˜ a
organiza¸ao do GFS permite que um servidor mestre controle centenas de chunkservers, e
c˜
v´rios cluster podem ser interligados definindo o GFS como um DFS altamente escal´vel.
a a

17. 2.2 Tabela hash distribu´
ıda 7
2.2 Tabela hash distribu´
ıda
Uma tabela hash ´ uma estrutura de dados que associa chaves (hash) a valores. As
e
chaves s˜o obtidas atrav´s de uma fun¸˜o de tal maneira que seja simples e eficiente
a e ca
encontrar um valor na tabela apenas atrav´s de sua chave.
e
Como mostra a figura 1 (LUA et al., 2005) uma tabela hash distribu´ (DHT - Distri-
ıda
buted Hash Table) configura uma camada entre os n´s (tradado na figura como peer ) e a
o
rede de sobreposi¸ao, e fornece os m´todos necess´rios para o gerenciamentos dos dados
c˜ e a
do sistema.
Figura 1: Estrutura de sobreposi¸ao de sistemas baseada em DHT
c˜
Os dados e os n´s da rede recebem uma chave identificadora dentro do mesmo espa¸o
o c
de endere¸o da DHT, desta forma, a consulta pelo hash dos dados leva ao n´ respons´vel.
c o a
Principais objetivos de uma DHT:
• Sempre ´ poss´ localizar um item da tabela;
e ıvel
• Manter a operacionalidade mesmo com um grande n´ de participantes no sistema;
ıvel
• Fornecer recursos eficientes para a adi¸˜o e remo¸˜o de n´s
ca ca o
Existem v´rios modelos de DHT, como Chord (STOICA et al., 2001), CAN (RATNA-
a
SAMY et al., 2001) e Pastry (CASTRO et al., 2003). Cada um com suas particularidades e
todos com os mesmos objetivos principais.
Para este projeto foi adotado o modelo Chord de DHT. O Chord foi desenvolvido
por pesquisadores do MIT Laboratory for Computer Science e fornece mecanismos para
tra¸ar um mapa de n´s e dados, relacionados por suas chaves. Possui a capacidade de
c o

18. 2.2 Tabela hash distribu´
ıda 8
adaptar-se a entrada e a sa´ de n´s do sistema, respondendo a requisi¸oes mesmo com
ıda o c˜
sistema mudando continuamente.
O Chord organiza os n´s em um anel de maneira que cada um conhece a chave e a
o
situa¸ao o seu predecessor e sucessor, al´m disto, cada n´ cont´m uma tabela de deriva¸˜o
c˜ e o e ca
(finger table) que cont´m o par chave e endere¸o de outros n´s da rede (TANENBAUM;
e c o
STEEN, 2007). Est´ tabela possui n´mero limitado de registros e ´ montada atrav´s de
a u e e
uma f´rmula matem´tica com a pr´pria chave do n´.
o a o o
Figura 2: Exemplos de resolu¸ao de chaves no Chord (TANENBAUM; STEEN, 2007).
c˜
A figura 2 mostra um exemplo de como o sistema Chord utilizando as informa¸oes da
c˜
tabela de deriva¸˜o realizaria a resolu¸˜o de uma chave igual 26 a partir do n´ 1 (linha
ca ca o
cont´
ınua) e outra da chave 12 a partir do n´ 28 (linha pontilhada).
o
A localiza¸ao de um n´ respons´vel normalmente exige O(log(N)) etapas, sendo N o
c˜ o a
n´mero de n´s do anel (TANENBAUM; STEEN, 2007), a caracter´
u o ıstica logar´
ıtmica garante
a escalabilidade do modelo Chord.

19. 9
3 ARQUITETURA
Este projeto consiste em um software distribu´ baseado em DHT para armazena-
ıdo
mento de arquivos em rede, onde todas os n´s da DHT tem o mesmo papel.
o
3.1 Requisitos do sistema
Transparˆncia para o usu´rio. O mapeamento de nomes n˜o cont´m referˆncias
e a a e e
sobre a localiza¸ao f´
c˜ ısica do arquivo. O usu´rio pode utilizar o sistema remoto como um
a
recurso local, o sistema distribu´ ´ respons´vel por localizar os dados.
ıdo e a
Esta caracter´
ıstica tamb´m proporciona mobilidade, n˜o restringindo o usu´rio a
e a a
iniciar uma sess˜o em uma esta¸ao de trabalho espec´
a c˜ ıfica.
Configura¸˜o funcional sim´trica. Os elementos do sistema possuem o mesmo
ca e
grau de importˆncia e autonomia, todas as m´quinas componentes tem igual papel na
a a
opera¸ao do sistema (SILBERSCHATZ; GALVIN, 2000).
c˜
Esta configura¸˜o garante a escalabilidade do sistema, fornecendo facilidade de adi-
ca
cionar e gerenciar novos usu´rios e m´quinas.
a a
Replica¸˜o dos arquivos. Diferentes c´pias de um mesmo arquivo residem em
ca o
m´quinas diferentes. A atualiza¸ao de uma c´pia ´ refletida em todas as outras, mantendo
a c˜ o e
a semˆntica de coerˆncia. A¸oes de exclus˜o e inclus˜o tamb´m s˜o replicadas.
a e c˜ a a e a
Fragmenta¸˜o dos dados entre os n´s servidores do sistema. Os arquivos s˜o divi-
ca o a
didos em blocos e armazenados em servidores distintos.
Coerˆncia. O sistema cont´m medidas para garantir a coerˆncia dos arquivos, prin-
e e e
cipalmente as c´pias abertas simultaneamente, coletando e armazenado informa¸˜es de
o co
estado de cada arquivo da estrutura.
Mem´ria Cache. O cliente mantem c´pias locais dos arquivos recentemente abertos,
o o
a fim de otimizar o tr´fico na rede. As altera¸oes feitas pelo usu´rio s˜o realizadas na
a c˜ a a

20. 3.2 Projeto 10
c´pia local, e somente ao fechar o arquivo as modifica¸oes s˜o enviadas para os servidores.
o c˜ a
Seguran¸a. Os arquivos e diret´rios do sistema cont´m permiss˜es de acesso seme-
c o e o
lhante ao empregado em ambientes UNIX, mas sem a presen¸a dos grupos de usu´rio.
c a
Possibilidade de diferente n´
ıveis de permiss˜o para o propriet´rio e para os demais usu´rio.
a a a
Fornecendo o isolamento ou compartilhamento de dados.
3.2 Projeto
Elementos
O sistema de arquivos distribu´ (DFS) ´ constitu´ de dois elementos principais:
ıdo e ıdo
n´s clientes e n´s servidores.
o o
Os n´s clientes s˜o caracterizados por possu´
o a ırem uma interface de navega¸˜o do DFS
ca
(isolada do sistema de arquivo local da esta¸ao cliente), por n˜o armazenarem os arquivos
c˜ a
distribu´
ıdos e por manterem um cache tempor´rio com os ultimos dados acessados.
a ´
Os n´s servidores constituem o agrupamento mapeado pela DHT. Nestes n´s s˜o
o o a
armazenados os arquivos e a estrutura de diret´rio. Cada n´ ´ integrante da tabela hash
o oe
distribu´
ıda, esta fornece o mapeamento da localiza¸ao de todos os dados do DFS e as
c˜
regras para o armazenamento de novos arquivos.
O sistema possui servi¸os com informa¸ao de estados, ou seja, os n´s servidores tˆm
c c˜ o e
conhecimento referente a cada arquivo e sobre os clientes que est˜o acessando o sistema.
a
A carga principal de processamento e gerenciamento do sistema est´ nos servidores,
a
isto garante uma baixa configura¸ao m´
c˜ ınima de hardware para o cliente.
Tabela hash distribu´
ıda
A fim de atender os requisitos do sistema de escalabilidade e a n˜o necessidade de
a
um servidor central, o projeto ´ constru´ sobre uma DHT. Os n´s clientes obtˆm a
e ıdo o e
localiza¸ao dos arquivos atrav´s de consultas na DHT, esta possui o mapeamento de um
c˜ e
determinado hash (correspondente a um arquivo dentro da ´rvore de diret´rios) a um n´
a o o
servidor que possui o arquivo.
Entre os projetos estudados, o Chord foi escolhido para a constru¸˜o do sistema de
ca
arquivos por conseguir atender todos os requisitos de maneira simples.

21. 3.2 Projeto 11
Neste projeto a fun¸ao hash da DHT fornecer´ a localiza¸ao f´
c˜ a c˜ ısica de um dado, ou seja,
o n´ respons´vel, atrav´s do posicionamento l´gico do arquivo ou diret´rio na estrutura
o a e o o
de arquivos l´gica do sistema. A chave ´ gerada a partir do caminho completo do arquivo
o e
na ´rvore de diret´rios virtual.
a o
Mapeamento de nomes
A vis˜o da arvore de diret´rios e arquivos do sistema para um usu´rio cliente n˜o
a ´ o a a
cont´m qualquer informa¸ao sobre a localiza¸ao f´
e c˜ c˜ ısica do dado. Esta ´rvore ´ apresentada
a e
de maneira semelhante a estrutura de arquivos locais. Mesmo que um dado fisicamente
seja movido para um outro n´ da DHT, a arvore e o nome do arquivo continuam inalte-
o ´
rados. Dessa forma o sistema fornece transparˆncia e independˆncia da localiza¸˜o f´
e e ca ısica
do dado.
Estas caracter´
ısticas s˜o atingidas por um modelo de estrutura de arquivos semelhante
a
a um sistema de arquivos convencional, atrav´s de inodes. Os inode s˜o arquivos de
e a
controle que cont´m informa¸oes sobre um determinado diret´rio ou arquivo. Na vis˜o
e c˜ o a
do sistema, os inodes s˜o arquivos comuns armazenados nos servidores e indexados pela
a
DHT.
Quando um cliente solicita visualizar o conte´do de um diret´rio, ´ enviado a ele um
u o e
arquivo de controle (o inode correspondente) com a lista de arquivos e subdiret´rios do
o
diret´rio requisitado. Esta informa¸˜o ´ processada e apresentada pela interface cliente
o ca e
do sistema, adicionando os elementos descritos no inode dentro da arvore de diret´rios.
´ o
Essa estrutura ´ montada de forma semelhante ao ambiente UNIX, utilizando a barra ‘/’
e
como separador de diret´rios e como raiz do sistema.
o
Quando h´ uma altera¸ao na ´rvore, como remo¸ao ou inclus˜o de arquivos ou di-
a c˜ a c˜ a
ret´rios, os inodes correspondentes s˜o atualizados pelo sistema.
o a
Coerˆncia
e
Para manter a coerˆncia dos arquivos, o sistema possibilita que somente um cliente
e
abra um determinado arquivo para edi¸ao. Caso esta condi¸ao seja atingida, as novas
c˜ c˜
solicita¸oes por este arquivo s˜o caracterizadas como somente leitura.
c˜ a
O inode carrega o parˆmetro que indica se o arquivo est´ sendo utilizado por algum
a a
cliente. A responsabilidade de atualizar este parˆmetro ´ do n´ servidor que possui o inode
a e o
alocado, pois quando o cliente solicitar o arquivamento deste dado, o sistema informa a
este servidor para liberar o arquivo.

22. 3.2 Projeto 12
Para garantir que um arquivo n˜o permane¸a bloqueado no caso de falhas do cliente,
a c
o n´ respons´vel envia mensagens de controle a este para cada outra requisi¸ao para esse
o a c˜
mesmo arquivo, caso o n´ n˜o obtenha uma resposta, o arquivo ´ liberado para o novo
o a e
cliente e o primeiro requisitante perde os privil´gios sobre aquele arquivo at´ um pr´ximo
e e o
pedido.
Quando os arquivos sofrem altera¸oes, a coerˆncia tamb´m deve ser tratada nas
c˜ e e
r´plicas. Da mesma forma, o n´ respons´vel por essa tarefa ´ o que possui o inode.
e o a e
Mem´ria Cache
o
Ao ser solicitado para o sistema um arquivo, este ´ salvo na mem´ria cache localizada
e o
no disco r´
ıgido da m´quina cliente. Todos os acessos futuros s˜o feitos nesta c´pia local.
a a o
O arquivo ´ reenviado para o sistema somente quando o cliente solicita, pela interface do
e
sistema, o armazenamento do arquivo, caso este tenha sido modificado.
Quando um novo pedido por este arquivo parte do cliente, o sistema verifica a data
da ultima altera¸ao da c´pia remota (informa¸ao fornecida ao m´dulo cliente atrav´s do
´ c˜ o c˜ o e
inode deste arquivo) com a do arquivo em cache. O arquivo s´ ´ novamente transferido
oe
se a c´pia remota for mais recente que a local. Mesmo nesta situa¸ao o sistema marca o
o c˜
inode deste arquivo como em uso, garantido a coerˆncia.
e
O tamanho da cache ser´ limitado, assim quando o limite for atingido os dados mais
a
antigos s˜o removidos para que novos arquivos sejam salvos na area de cache. Um dado
a ´
mais antigo tem maior chance de ter sofrido altera¸oes por outro cliente do sistema.
c˜
Replica¸˜o
ca
O sistema conta com o recurso de replica¸ao dos dados entre os n´s da DHT de forma
c˜ o
autˆnoma, a fim de aumentar a disponibilidade dos arquivos em caso de falha de algum
o
n´ servidor.
o
A escolha por qual n´ armazena a c´pia ´ feita baseada na pr´pria estrutura da DHT,
o o e o
como os n´s s˜o organizados logicamente em um anel, o n´ sucessor ter´ uma c´pia dos
o a o a o
arquivos de seu predecessor.
Este modelo foi escolhido pela sua simplicidade e por utilizar os recursos j´ fornecidos
a
pela DHT.
Os m´todos de replica¸ao s˜o chamados quando um novo arquivo ´ inserido ou atu-
e c˜ a e
alizado no sistema. A responsabilidade por manter a coerˆncia das c´pias ´ do n´ que
e o e o

23. 3.2 Projeto 13
possui seu inode.
Em caso de falha de um n´ servidor, o cliente est´ configurado para solicitar o arquivo
o a
para o n´ imediatamente seguinte na estrutura da DHT.
o
Quando o sistema percebe a falha de algum n´, ´ iniciado o processo de balanceamento
o e
dos dados, isto porque um n´ que antes empregava o papel de replica passa a ser o servidor
o
principal para aquele conjunto de inode e fragmentos e precisa enviar todos os seus dados
para o seu sucessor para manter a duplicidade das informa¸˜es.
co
Fragmenta¸˜o
ca
Os arquivos s˜o fragmentados em partes menores, cada um de seus fragmentos ´ arma-
a e
zenado e indexado em um n´ servidor distinto. O processo de fragmenta¸˜o ´ transparente
o ca e
para o usu´rio.
a
Apenas arquivos que ultrapassam um tamanho espec´
ıfico s˜o fragmentados e em blo-
a
cos sempre de mesmo tamanho. Os valores limite para o tamanho do arquivo e tamanho
de cada fragmento devem ser definidos observando as caracter´
ısticas da rede em qual o
sistema ir´ ser empregado. Estruturas de maior porte admitem blocos maiores.
a
As informa¸oes sobre os fragmentos s˜o armazenadas no inode do arquivo. Quando
c˜ a
um cliente abre um arquivo, o n´ respons´vel gera requisi¸˜es para os servidores citados no
o a co
inode solicitando os blocos. Ap´s receber todos os fragmentos, este n´ faz a reconstru¸˜o
o o ca
do arquivo e o envia ao cliente.
Esta caracter´
ıstica garante que a carga do sistema seja igualmente distribu´ pelo
ıda
n´s da DHT. Desta forma quando um grande arquivo ´ requisitado v´rios n´s participam
o e a o
do processo por um curto per´
ıodo de tempo. Caso a fragmenta¸ao n˜o existisse apenas o
c˜ a
n´ respons´vel executaria toda a tarefa, trabalhando um longo per´
o a ıodo.
Seguran¸a
c
Quando um novo arquivo ´ armazenado no sistema, seu inode gerado carrega a in-
e
forma¸ao de qual ´ o usu´rio propriet´rio do arquivo. Por padr˜o este arquivo n˜o possui
c˜ e a a a a
qualquer restri¸ao de acesso.
c˜
Os propriet´rios podem alterar a permiss˜o de acesso de seus arquivos, configurando
a a
o n´ de acesso que deseja que os outros usu´rios tenham de seus dados. Esse n´ pode
ıvel a ıvel
ser acesso completo, somente para leitura ou bloqueado.

24. 3.2 Projeto 14
O n´ de acesso completo permite que os demais abram, removam ou atualizem o
ıvel
arquivo. Para o n´ de leitura, apenas a op¸ao de abrir ´ liberada, enquanto que para o
ıvel c˜ e
bloqueado nenhuma op¸˜o est´ dispon´
ca a ıvel. O propriet´rio sempre possui n´ de acesso
a ıvel
completo de seus dados.
O n´ de permiss˜o deve ser aplicado diretamente ao dado desejado, n˜o ´ poss´
ıvel a a e ıvel
atribuir n´
ıveis de permiss˜o para os diret´rios do sistema. Est´ limita¸ao existe, pois n˜o
a o a c˜ a
´ eficiente verificar a permiss˜o de cada inode dos diret´rios da estrutura de um arquivo
e a o
com o objetivo de liberar cada uma das a¸oes dos usu´rios.
c˜ a
Diagrama UML
Figura 3: Diagrama de casos de uso
A figura 3 mostra os poss´
ıveis casos de uso de um usu´rio para com o sistema. A
a
modelagem UML completa ´ encontrada no apˆndice B.
e e

25. 3.3 Implementa¸˜o
ca 15
3.3 Implementa¸˜o
ca
Alguns dos pontos descritos na se¸˜o Projeto foram implementados gerando um
ca
prot´tipo do sistema. O intuito deste desenvolvimento foi verificar a viabilidade do projeto
o
e a realiza¸˜o de testes.
ca
O sistema foi escrito na linguagem de programa¸˜o JAVA com apoio das classes nativas
ca
de sockets, sem a utiliza¸ao de API externas.
c˜
Das funcionalidades propostas, o sistema implementado est´ focado no n´cleo do
a u
projeto, a intera¸˜o dos clientes com os arquivos e diret´rios do sistema. Os requisitos
ca o
desenvolvidos foram transparˆncia e configura¸ao funcional sim´trica.
e c˜ e
A implementa¸ao possui programas espec´
c˜ ıficos para cada a¸ao do cliente e um m´dulo
c˜ o
de m´ltiplas threads para os servidores.
u
Est˜o dispon´
a ıveis para o cliente as a¸oes de abrir arquivos, em que o dado requisitado ´
c˜ e
carregado do sistema para a esta¸ao do cliente, gravar um arquivo, onde um novo arquivo ´
c˜ e
enviado para o sistema, a a¸ao de remover um arquivo e de listar o conte´do de diret´rios.
c˜ u o
O programa para os servidores possui m´todos para a cria¸˜o e manuten¸ao da DHT,
e ca c˜
montando uma tabela de n´s servidores. Estes tamb´m contˆm m´todos para atender a
o e e e
cada uma das a¸oes dos clientes descritas anteriormente.
c˜
O controle dos dados do sistema ´ realizado atrav´s de arquivos de meta-dados, de-
e e
nominados inode. Os inodes s˜o gerenciados pelos servidores e cont´m informa¸˜es sobre
a e co
um arquivo ou diret´rio.
o
3.3.1 Sistema distribu´
ıdo
O elemento do sistema executado pelos n´s da DHT, constitui um programa denomi-
o
nado noDHT respons´vel pelo gerenciamento dos dados, atendimento das requisi¸˜es dos
a co
clientes e realiza¸˜o de manuten¸oes e consultas na DHT.
ca c˜
Para tanto este programa ´ divido em duas threads. A primeira cont´m os c´digos
e e o
espec´
ıficos para o tratamento das a¸oes solicitadas pelos clientes do sistema. Ao ser
c˜
iniciada, esta cria um socket TCP/IP na porta 9009. O n´mero desta porta ´ comum a
u e
todos e assim os usu´rios n˜o necessitam fornecˆ-la para se conectar a um servidor.
a a e
A segunda thread ´ destinada apenas as requisi¸˜es dos outros n´s da DHT, como os
e ` co o
m´todos de entrada e sa´ da DHT e o gerenciamento dos diret´rios do sistema. Esta
e ıda o

26. 3.3 Implementa¸˜o
ca 16
inicia um socket tamb´m TCP/IP na porta 9000.
e
Manuten¸˜o da DHT
ca
A DHT come¸a a ser montada quando o primeiro n´ servidor ´ iniciado. Este, sabendo
c o e
desta situa¸˜o, apenas acrescenta seu endere¸o IP a rec´m criada DHT e aguarda por
ca c e
requisi¸oes.
c˜
Exemplo: java noDHT
Este comando ´ utilizado para iniciar o primeiro n´ da DHT.
e o
Ao iniciar os demais n´s ´ preciso fornecer o endere¸o IP de um n´ j´ pertencente
o e c o a
da DHT. Este novo n´ recebe da m´quina indicada a c´pia da DHT contendo a lista das
o a o
m´quinas existentes no sistema. O n´ atualiza a sua lista com seu pr´prio endere¸o IP e
a o o c
envia uma mensagem para todos os n´s indicados na DHT, solicitando que o adicionem
o
em suas tabelas.
Exemplo: java noDHT 192.168.0.94
Este comando inicia um novo n´ servidor solicitando a DHT para o n´ 192.168.0.94.
o o
Antes de deixar o sistema, um n´ avisa todos os outros, para que estes o removam da
o
DHT. N˜o foi implementado m´todos para detectar que um n´ deixou a DHT sem avisar
a e o
os demais.
3.3.2 DHT Chord
Para auxiliar no desenvolvimento foi analisado o emprego da API OpenChord (LO-
ESING; KAFFILLE, 2008), este fornece os m´todos descritos em Stoica et al. (2001). O
e
OpenChord ´ uma implementa¸ao de c´digo aberto em linguagem JAVA e est´ dispon´
e c˜ o a ıvel
gratuitamente sob a licen¸a GNU GPL, o desenvolvimento ´ do Distributed and Mobile
c e
Systems Group da Universidade de Bamberg.
Por´m optou-se por implementar as funcionalidades da DHT ao inv´s de utilizar o
e e
OpenChord pois esta se trata de uma API completa e extensa, incorporando muitos
recursos al´m do necess´rio para o desenvolvimento deste projeto.
e a
O m´dulo da DHT foi desenvolvido desde o in´
o ıcio baseado-se nas documenta¸oes
c˜
oficiais. Esta constru¸ao tem como vantagem que o resultado final ´ uma implementa¸ao
c˜ e c˜
enxuta e otimizada para a finalidade.

27. 3.3 Implementa¸˜o
ca 17
Este m´dulo constru´ n˜o implementa o conceito de tabela de deriva¸ao, onde cada
o ıdo a c˜
n´ conhece apenas um n´mero limitado de outros n´s, mas sim, cada n´ mant´m uma
o u o o e
rela¸ao de todos os n´s da rede. Est´ decis˜o teve como base o tempo de desenvolvimento
c˜ o a a
desta caracter´
ıstica do Chord, preferiu-se dedicar os recursos dispon´
ıveis para a cria¸˜o
ca
do projeto em si.
Gera¸˜o de chaves
ca
A constru¸˜o do m´dulo da DHT tamb´m exigiu o desenvolvimento de um algoritmo
ca o e
para gera¸ao de chaves. Assim como a API OpenChord, a chave ´ gerada atrav´s da
c˜ e e
fun¸ao SHA1 (JONES, 2001).
c˜
Ao submeter uma seq¨ˆncia de bits para a fun¸ao SHA1 ´ obtido um hash de 160
ue c˜ e
bits, comumente tratado como uma seq¨ˆncia de letras e n´meros, como o Chord faz
ue u
compara¸oes entre as chaves (maior ou menor), o valor gerado pelo SHA1 recebe um
c˜
tratamento removendo todas as letras e truncando o resultado em cinco caracteres. O
resultado ´ sempre um n´mero inteiro de zero a 99999.
e u
O valor obtido ´ associado ao n´ ou a um dado do sistema na DHT, que por essa
e o
caracter´
ıstica tem um espa¸o de endere¸o de cem mil posi¸oes.
c c c˜
Para as chaves relacionadas aos n´s, o valor enviado a fun¸ao ´ um texto constitu´
o c˜ e ıdo
de seu endere¸o IP no formato de quatro grupos de n´meros separados por pontos. Pelos
c u
testes realizados, a fun¸ao SHA1 garante a diversidade das chaves, mesmo com pouca
c˜
varia¸˜o entre um endere¸o e outro.
ca c
Para os arquivos, a gera¸ao das chaves utiliza o caminho completo mais o nome do
c˜
arquivo. O mesmo processo ´ feito para os diret´rios, a chave ´ obtida atrav´s da estrutura
e o e e
completa at´ o referido diret´rio.
e o
3.3.3 Gerenciamento dos diret´rios
o
N˜o existem diret´rios reais no sistema distribu´
a o ıdos, sua existˆncia ´ mapeada atrav´s
e e e
de arquivos de controle denominados inode. Os inodes s˜o arquivos de texto tratados pela
a
DHT como arquivos convencionais, ou seja, possui uma chave e um n´ respons´vel, por´m
o a e
os servidores utilizam-se destes para o controle da ´rvore de diret´rio do sistema.
a o
Quando um cliente envia um novo arquivo, este indica em qual diret´rio deseja ar-
o
mazenar o novo dado. Assim enquanto o servidor respons´vel recebe os dados bin´rios
a a
atrav´s da conex˜o com o cliente, outras conex˜es s˜o abertas para os n´s respons´veis
e a o a o a

28. 3.3 Implementa¸˜o
ca 18
por cada n´ da estrutura fornecida pelo usu´rio.
ıvel a
Por exemplo, quando o cliente solicita gravar um novo arquivo no diret´rio /home/usuario,
o
o servidor respons´vel ter´ que enviar uma requisi¸ao para outros trˆs servidores, o res-
a a c˜ e
pons´vel pelo diret´rio raiz /, outra para o respons´vel pelo /home e por ultimo para o
a o a ´
respons´vel pelo /home/usuario.
a
Estes n´s verificam a necessidade criar o inode correspondente `quele diret´rio e em
o a o
seguida, escrevem o seu conte´do (nome do arquivo ou do pr´ximo diret´rio). O nome
u o o
do inode ´ constitu´ do prefixo ‘i’ mais o valor de sua chave e o nome do diret´rio.
e ıdo o
Continuando o exemplo anterior, o n´ respons´vel por /home, deve possuir um arquivo
o a
de controle com o nome i 70476 home e conte´do uma linha com a palavra usuario.
u
Desta forma o conte´do gravado em um inode de diret´rio ´ a lista de seus arquivos
u o e
e subdiret´rios, assim quando o usu´rio utiliza o comando listar o n´ respons´vel pelo
o a o a
diret´rio lhe envia o conte´do do inode.
o u
3.3.4 Interface com o usu´rio
a
Todas as intera¸oes dos clientes com o sistema s˜o feitas atrav´s de programas exe-
c˜ a e
cutados em linha de comando. Para o cliente ´ transparente a existˆncia de um conjunto
e e
de servidores que gerencia o sistema distribu´ mas ´ preciso informar em qual m´quina
ıdo, e a
servidora o cliente ir´ se conectar. Todo os n´s da DHT tem a capacidade de atender a
a o
essas requisi¸˜es.
co
No in´ de cada comando do cliente, o servidor indicado manualmente tem a fun¸˜o
ıcio ca
de consultar a DHT e responder aos programas clientes qual o endere¸o IP do servidor
c
respons´vel pelo dado requisitado. Desta forma uma nova conex˜o ´ aberta entre o cliente
a a e
o servidor respons´vel e assim s´ assim executada a a¸˜o espec´
a o ca ıfica.
Est˜o dispon´
a ıveis aos clientes as a¸oes de abrir, gravar, remover e listar.
c˜
Com o comando abrir o cliente solicita um arquivo espec´
ıfico do sistema para ser
carregado em sua m´quina local e assim ter acesso a seu conte´do. O comando possui
a u
dois parˆmetros, o endere¸o IP de um dos servidores e o caminho completo do arquivo
a c
desejado.
Exemplo: java abrir 192.168.0.1 /home/usuario/documento.pdf
Com isso o programa abrir ap´s receber de 192.168.0.1 o endere¸o IP do servidor
o c

29. 3.3 Implementa¸˜o
ca 19
respons´vel por /home/usuario/documento.pdf estabelece uma nova conex˜o para receber
a a
o arquivo bin´rio.
a
Com o comando gravar o cliente indica um arquivo local para ser submetido para
o sistema distribu´
ıdo. O comando possui trˆs parˆmetros, o endere¸o IP de um dos
e a c
servidores, o arquivo local que deseja enviar para o sistema e o caminho completo do
diret´rio destino.
o
Exemplo: java gravar 192.168.0.1 c:usuariofilme.avi /home/usuario
Neste caso a m´quina 192.168.0.1 ap´s receber todos os parˆmetros, realiza uma
a o a
concatena¸ao do diret´rio destino com o nome do arquivo (/home/usuario/filme.avi ) para
c˜ o
assim consultar na DHT qual ser´ o servidor respons´vel por aquele novo arquivo. Na
a a
seq¨ˆncia o programa gravar estabelece uma conex˜o com o endere¸o IP recebido e envia
ue a c
o arquivo bin´rio para o servidor respons´vel.
a a
Com o comando remover o cliente envia um pedido para que um arquivo remoto
seja exclu´ do sistema. O comando possui dois parˆmetros, o endere¸o IP de um dos
ıdo a c
servidores e o caminho completo do arquivo.
Exemplo: java remover 192.168.0.1 /home/usuario/documento.pdf
Logo ap´s receber o endere¸o IP do respons´vel, o programa remover solicita a este
o c a
servidor para que o dado /home/usuario/documento.pdf seja removido.
Com o comando listar o cliente solicita um visualizar o conte´do de determinado di-
u
ret´rio do sistema. O comando possui dois parˆmetros, o endere¸o IP de um dos servidores
o a c
e o caminho completo do diret´rio.
o
Exemplo: java listar 192.168.0.1 /home/usuario
A m´quina 192.168.0.1 deve consultar na DHT o respons´vel pelo diret´rio /home
a a o
/usuario, este respons´vel possui um arquivo de controle (inode) referente a esse diret´rio
a o
contendo o nome de seus arquivos e subdiret´rios. O endere¸o IP do servidor respons´vel
o c a
´ retornado para o programa listar que ap´s realizar a nova conex˜o recebe o conte´do do
e o a u
arquivo de controle, ou seja, a lista com os nomes dos subdiret´rios e arquivos do diret´rio
o o
requisitado.

30. 3.4 Testes 20
3.4 Testes
Foram realizados testes qualitativos para avaliar as funcionalidades do projeto. O
ambiente de teste foi um PC com processador AMD Turion 1.6 GHz com 2 GB de mem´ria
o
RAM e sistema operacional Windows XP SP 3. Pela necessidade dos testes exigirem um
consider´vel n´mero de esta¸oes, a rede foi constru´ atrav´s de virtualiza¸˜o utilizando
a u c˜ ıda e ca
o software Microsoft Virtual PC 2007 SP1.
Todas as m´quinas virtuais possu´
a ıam 128 megabytes de mem´ria RAM e Windows
o
XP Service Pack 3 com o Java Runtime Environment 1.6.0 06. Simultaneamente eram
executadas quatro m´quinas virtuais, cada uma com um endere¸o IP e executando o
a c
programa noDHT.
Os primeiros testes focaram a constru¸˜o e manuten¸ao da DHT por parte dos servi-
ca c˜
dores. Devido ` caracter´
a ıstica do ambiente de teste, as rotinas de entrada e sa´ de n´s
ıda o
mostram-se eficiente para uma DHT de quatro m´quinas.
a
Para este, os resultados s˜o:
a
• Todas as m´quinas, sem considerar a ordem de entrada na DHT, s˜o capazes de
a a
controlar a entrada de um novo n´ servidor.
o
• A sa´ do primeiro n´ n˜o causou instabilidades na DHT.
ıda o a
• N˜o ´ importante a quantidade de vezes que uma m´quina deixa e retorna ao sis-
a e a
tema.
Para os testes com as a¸˜es da interface cliente, a DHT era constitu´ de quatro
co ıda
m´quinas servidoras e uma delas tamb´m executava o software cliente. Todos os m´todos
a e e
implementados (gravar, abrir, remover) foram alvos de teste.
Resultados obtidos:
• A grava¸ao de um arquivo de 3.649.965 bytes (3,48 megabytes) foi executada na
c˜
ordem de 3 segundos. Para um arquivo de 126.933.775 bytes (121 megabytes) a
a¸ao foi finalizada na ordem de 1 minuto.
c˜
• A a¸˜o de abrir, ou seja, enviar um arquivo do servidor ao cliente, para o menor
ca
arquivo foi executada na ordem de 3 segundos e 59 segundos para o maior.
• A a¸˜o de remo¸ao por parte do cliente funciona de maneira satisfat´ria.
ca c˜ o

31. 3.4 Testes 21
• N˜o foram detectados problemas nas transferˆncias de dados em formato de texto
a e
ou bin´rio.
a
• O sistema notifica o cliente caso as a¸oes de abrir ou remover sejam solicitadas para
c˜
dados n˜o presentes no sistema.
a
• A a¸˜o de gravar n˜o avisa o cliente caso o arquivo j´ exista na estrutura de diret´rios
ca a a o
informada, causando a sobreposi¸ao do dado.
c˜

32. 22
4 ˜
CONCLUSAO
Uma vez analisadas diversas arquiteturas de sistemas de arquivos distribuidos, ela-
borada a documenta¸ao de um projeto e executados a implementa¸ao e testes de um
c˜ c˜
prot´tipo, obtiveram-se resultados que permitem apresentar as seguintes conclus˜es:
o o
• As atuais tecnologias e estudos na ´rea de sistema de arquivos distribu´
a ıdos encontram-
se em avan¸ado n´
c ıvel de desenvolvimento fornecendo uma grande quantidade de
projetos e solu¸oes para o desenvolvimento de aplica¸oes nesta area.
c˜ c˜ ´
• No que tange a elabora¸ao do projeto com o detalhamento dos recursos e diagramas,
` c˜
foram descritos todos os requisitos levantados com suas dependˆncias e relaciona-
e
mentos e constru´ a documenta¸ao na linguagem UML.
ıdo c˜
• O prot´tipo desenvolvido com o objetivo de estruturar uma DHT e fornecendo
o
recursos para gerenciar os arquivos dos clientes atendeu os requisitos propostos e de
acordo com os testes realizados confirmou a efic´cia do projeto.
a
Conclui-se, em vista do exposto, que a tecnologia DHT mostra-se vi´vel para o de-
a
senvolvimento de sistemas de arquivos distribu´
ıdos.
Trabalhos futuros
Alguns pontos deste projeto n˜o foram implementados em sua totalidade, utilizando
a
a documenta¸˜o elaborada ´ poss´ concluir a constru¸ao do sistema. Ressaltando itens
ca e ıvel c˜
como o m´dulo da DHT, onde cabe desenvolver a finger table do Chord (STOICA et al.,
o
2001), as funcionalidades de replica¸˜o, fragmenta¸ao e seguran¸a, e a interface cliente,
ca c˜ c
construindo uma aplica¸˜o gr´fica mais amig´vel.
ca a a
Outro foco para novos trabalhos ´ a pesquisa e testes para a utiliza¸ao no sistema
e c˜
de outras implementa¸˜es de tabelas hash distribu´
co ıdas, como a CAN (RATNASAMY et al.,
2001) e Pastry (CASTRO et al., 2003).

33. 23
ˆ
APENDICE A -- Tabela comparativa dos
sistemas de arquivo
distribu´
ıdos
A tabela 1 apresenta uma comparativa entre as principais caracter´
ısticas dos sistemas
citados.
NFS AFS CODA SPRITE GFS
Replica¸˜o
ca Ruim: Somente Ruim: Somente Boa: A carga ´ dis-
e Ruim: Somente Excelente: Por¸˜es
co
Leitura (somente Leitura (somente tribu´
ıdas entre cli- Leitura (somente s˜o distribu´
a ıdas en-
diret´rios)
o diret´rios)
o entes diret´rios)
o tre diferentes servi-
dores
Consistˆncia
e Ruim: Acesso Razo´vel:
a Ruim: Semˆntica
a Excelente: Boa: Adequado a
simultˆneo
a gera Semˆntica
a da da sess˜o enfraque-
a Semˆntica
a do sua finalidade
resultados impre- sess˜o
a cida Unix
vis´
ıveis
Escalabilidade Ruim: R´pida sa-
a Excelente: Ideal Excelente: Ideal Ruim: O protocolo Excelente: Orga-
tura¸˜o dos servi-
ca para WANs com para WANs com requer broadcasts niza¸˜o em clusters
ca
dores baixo grau da baixo grau da
compartilhamento compartilhamento
Performance Ruim: Protocolo Razo´vel: Grande
a Boa: Procura Boa: Imple- Boa: Performance
ineficiente latˆncia para arqui-
e por r´plica ‘mais
e menta¸˜o
ca do otimizada para ar-
vos n˜o armazena-
a pr´xima’
o kernel. Atualiza¸˜o
ca quivos grandes
dos em cache atrasada. Grandes
cache
Persistˆncia em
e Ruim: Grava¸˜es
co Boa: Ferramen- Boa Ruim: Longos atra- Boa: Recupera¸˜oca
caso de falhas atrasadas podem tas de backup sos nas grava¸˜es
co r´pida e replica¸˜o
a ca
causar perda de autom´ticos
a podem causar de dados - simples
dados perda de dados e eficiente
Disponibilidade Ruim Ruim Excelente: Razo´vel: R´pida
a a Excelente: Re-
Opera¸˜es
co des- recupera¸˜o de fa-
ca plica¸˜o dos dados
ca
conectadas lhas dos servidores de
por¸˜es
co
Seguran¸a
c Ruim: Servidores Boa: Lista de con- Boa: Lista de con- Ruim: Servidores Usu´rios n˜o tˆm
a a e
confiam nos clien- trole de acesso. Au- trole de acesso. Au- confiam nos clien- acesso direto ao sis-
tes tentica¸˜o entre cli-
ca tentica¸˜o entre cli-
ca tes tema
ente e servidores. ente e servidores.
Localiza¸˜o do
ca Mem´ria
o Disco Disco Mem´ria
o Disco
cache do cliente
Plataformas Todas as principais Esta¸˜es SGI, HP,
co IBM RT, esta¸˜es
co Esta¸˜es SPARC e
co IBM PC
Nest, DCE, IBM, DEC e IBM PC DEC
SUN e VAX
Caracter´
ısticas Permitir clientes - Permite compu- Permitir clientes Utiliza¸˜o de ser-
ca
de Hardware sem disco tadores port´teis.
a sem disco vidores de baixo
Replica¸˜o requer
ca custo
servidores extras.
Tabela 1: Tabela comparativa dos sistemas de arquivo distribu´
ıdos.

34. 24
ˆ
APENDICE B -- Diagramas UML
B.1 Diagrama de classes
Figura 4: Rela¸˜o entre as principais classes do projeto
ca

35. B.2 Diagramas de seq¨ˆncia
ue 25
B.2 Diagramas de seq¨ˆncia
ue
Figura 5: Seq¨ˆncia para a abertura de um arquivo
ue

36. B.2 Diagramas de seq¨ˆncia
ue 26
Figura 6: Seq¨ˆncia para a grava¸˜o de um arquivo
ue ca

37. B.2 Diagramas de seq¨ˆncia
ue 27
Figura 7: Seq¨ˆncia para a remo¸ao de um arquivo
ue c˜

38. B.2 Diagramas de seq¨ˆncia
ue 28
Figura 8: Seq¨ˆncia para a altera¸ao das permiss˜es de um arquivo
ue c˜ o
Figura 9: Seq¨ˆncia para a obter informa¸oes sobre um arquivo
ue c˜

39. B.2 Diagramas de seq¨ˆncia
ue 29
Figura 10: Seq¨ˆncia para obter o conte´do de um diret´rio
ue u o
Figura 11: Seq¨ˆncia para a entrada de um novo n´ na DHT
ue o

40. 30
Referˆncias
e
CASTRO, M. et al. Topology-aware routing in structured peer-to-peer overlay networks.
2003. Dispon´ ıvel em: <http://www.cs.rice.edu/∼druschel/publications/Pastry-
locality.pdf>. Acesso em: 02 jun. 2008.
GHEMAWAT, S.; GOBIOFF, H.; LEUNG, S.-T. The Google File System. Lake George,
NY: Google, 2003. Dispon´ em: <http://labs.google.com/papers/gfs-sosp2003.pdf>.
ıvel
Acesso em: 29 abr. 2008.
JONES, P. RFC, RFC3174 - US Secure Hash Algorithm 1 (SHA1). 2001. Dispon´ em:
ıvel
<http://www.ietf.org/rfc/rfc3174.txt>. Acesso em: 11 set. 2008.
KON, F. Distributed File Systems Past, Present and Future A Distributed File System
for 2006. 1995. Dispon´ em: <http://citeseer.ist.psu.edu/kon96distributed.html>.
ıvel
Acesso em: 15 abr. 2008.
LOESING, K.; KAFFILLE, S. Open Chord. 2008. Dispon´ em: <http://open-
ıvel
chord.sourceforge.net/>. Acesso em: 04 jun. 2008.
LUA, E. K. et al. A Survey and Comparison of Peer-
to-Peer Overlay Network Schemes. 2005. Dispon´ ıvel em:
<http://www.cl.cam.ac.uk/teaching/2005/AdvSysTop/survey.pdf>. Acesso em:
16 jun. 2008.
MELLON, C. Computing@Carnegie Mellon :: Course Documentation :: Networking
:: Andrew File System (AFS). 2008. Dispon´ıvel em: <http://www.cmu.edu/c-
cm/networking/networking-afs.htm>. Acesso em: 21 abr. 2008.
RATNASAMY, S. et al. A Scalable Content-Addressable Network. 2001. Dispon´ em:
ıvel
<http://www.acm.org/sigs/sigcomm/sigcomm2001/p13-ratnasamy.pdf>. Acesso em: 02
jun. 2008.
SHEPLER, S. RFC, RFC 3530: Network File System (NFS) version 4 Protocol. abr.
2003. Dispon´ em: <http://www.ietf.org/rfc/rfc3530.txt>. Acesso em: 21 abr. 2008.
ıvel
SILBERSCHATZ, A.; GALVIN, P. Sistemas Operacionais: conceitos. 5. ed. S˜o Paulo:
a
Prentice Hall, 2000.
STOICA, I. et al. Chord: A Scalable Peer-to-peer Loo-
kup Service for Internet Applications. 2001. Dispon´ıvel em:
<http://pdos.csail.mit.edu/papers/chord:sigcomm01/chord sigcomm.pdf>. Acesso
em: 02 jun. 2008.
STOICA, I. et al. The Chord/DHash Project - Chord HOWTO. 2007. Dispon´ em:
ıvel
<http://pdos.csail.mit.edu/chord/howto.html>. Acesso em: 04 jun. 2008.

41. Referˆncias
e 31
STOICA, I. et al. Chord: A scalable Peer-To-Peer lookup service for internet applications.
In: Proceedings of the 2001 ACM SIGCOMM Conference. [s.n.], 2001. p. 149–160.
Dispon´ em: <http://citeseer.ist.psu.edu/stoica01chord.html>.
ıvel
TANENBAUM, A.; STEEN, M. V. Sistemas Distribu´dos - Princ´pios e Paradigmas. 2.
ı ı
ed. S˜o Paulo, SP: Pearson, 2007. 416 p. ISBN 9788576051428.
a
TANENBAUM, A. S. Sistemas Operacionais Modernos. 1. ed. Rio de Janeiro, RJ:
Prentice Hall do Brasil LTDA, 1995.