Modelagem e implementação de um sistema de arquivos distribuído baseado em DHT

Fabio Moretti Serra

Modelagem e implementacao de um

sistema de arquivos distribuıdo baseado em

DHT

Itatiba - Sao Paulo - Brasil

Dezembro de 2008

Fabio Moretti Serra

Modelagem e implementacao de um

sistema de arquivos distribuıdo baseado em

DHT

Monografia apresentado a disciplina Tra-balho de Conclusao de Curso, do Curso deEngenharia da Computacao da UniversidadeSao Francisco, sob a orientacao do Prof.Rodrigo Chavez Monteiro do Prado, comoexigencia parcial para conclusao do curso degraduacao.

Orientador:

Prof. Ms. Rodrigo Chavez Monteiro do Prado

Curso de Engenharia da ComputacaoUniversidade Sao Francisco

Itatiba - Sao Paulo - Brasil

Dezembro de 2008

i

Modelagem e implementacao de um sistema de

arquivos distribuıdo baseado em DHT

Fabio Moretti Serra

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 Sao Francisco – Itatiba – SP.

Prof. Ms. Thales Coelho Borges LimaUSF - Universidade Sao Francisco – Itatiba – SP.

Prof. Angelo AmaralUSF - Universidade Sao Francisco – Itatiba – SP.

ii

“A sorte favorece so a mente preparada”

Isaac Asimov

iii

Sumario

Lista de abreviaturas e siglas v

Lista de Figuras vi

Resumo vii

Abstract viii

1 INTRODUCAO 1

1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Organizacao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 ARQUITETURAS DE SISTEMAS DISTRIBUIDOS 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 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.1 Sistema distribuıdo . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.2 DHT Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.3 Gerenciamento dos diretorios . . . . . . . . . . . . . . . . . . . . . 17

3.3.4 Interface com o usuario . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Sumario iv

4 CONCLUSAO 22

Apendice A -- Tabela comparativa dos sistemas de arquivo distribuıdos 23

Apendice B -- Diagramas UML 24

B.1 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.2 Diagramas de sequencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Referencias 30

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

vi

Lista de Figuras

1 Estrutura de sobreposicao de sistemas baseada em DHT . . . . . . . . . . 7

2 Exemplos de resolucao de chaves no Chord (TANENBAUM; STEEN, 2007). . 8

3 Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Relacao entre as principais classes do projeto . . . . . . . . . . . . . . . . . 24

5 Sequencia para a abertura de um arquivo . . . . . . . . . . . . . . . . . . . 25

6 Sequencia para a gravacao de um arquivo . . . . . . . . . . . . . . . . . . . 26

7 Sequencia para a remocao de um arquivo . . . . . . . . . . . . . . . . . . . 27

8 Sequencia para a alteracao das permissoes de um arquivo . . . . . . . . . . 28

9 Sequencia para a obter informacoes sobre um arquivo . . . . . . . . . . . . 28

10 Sequencia para obter o conteudo de um diretorio . . . . . . . . . . . . . . . 29

11 Sequencia para a entrada de um novo no na DHT . . . . . . . . . . . . . . 29

vii

Resumo

Uma caracterıstica dos sistemas de arquivos para redes e que todas as operacoes deleitura e escrita sao realizadas por um servidor, causando uma centralizacao de carga deprocessamento e armazenamento.

Uma alternativa para resolver este problema e a configuracao de um sistema de ar-quivos distribuıdo, em que os dados permanecem espalhados de forma controlada, entrediversas maquinas constituintes de um agrupamento. Dessa forma a carga e dividida entretodos os computadores da rede. Exemplos desse modelo de sistema sao o Andrew FileSystem, CODA, SPRITE e Google File System.

Os objetivos desse projeto sao a pesquisa, implementacao e a elaboracao da docu-mentacao tecnica de um sistema de arquivos distribuıdo em nıvel de usuario. Possuindorequisitos como transparencia, escalabilidade e replicacao e fragmentacao dos arquivos.

Para atender estes requisitos, o sistema foi montado sobre uma tabela hash distribuıda(DHT) que cria uma rede de sobreposicao fornecendo os metodos necessarios para o geren-ciamento dos dados do sistema. Desta maneira, as maquinas clientes obtem a localizacaodos arquivos atraves de consultas na DHT que possui o mapeamento de um determinadohash a uma maquina servidora responsavel pelo arquivo.

viii

Abstract

One of the network file systems feature is that all read and write operations are doneon 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 dataremain 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 ofthis system model are Andrew File System, CODA, SPRITE and Google File System.

The goals of this project are research, implementation and development of a technicalpaper 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 dataon the system. In this way, the client machines get the data location through queries onthe DHT that holds the mappings from a hash to a server node responsible for that file.

1

1 INTRODUCAO

O sistema de arquivos tem a funcao de abstrair os possıveis dispositivos de armaze-

namento apresentando ao usuario uma unica estrutura padrao de diretorios e arquivos.

Este tambem deve fornecer maneiras independentes para criar, ler, escrever e remover

arquivos. (TANENBAUM, 1995)

Quando se trata de um sistema de arquivos em rede, o objetivo basico e permitir

que um conjunto arbitrario de clientes e servidores possam compartilhar um sistema de

arquivos comum. Um padrao muito conhecido e o Network File System (NFS) (SHE-

PLER, 2003). A caracterıstica basica da arquitetura do NFS e o fato de os servidores

disponibilizarem alguns de seus diretorios e de os clientes montarem remotamente estes

diretorios. Os arquivos compartilhados sao justamente aqueles pertencentes a hierarquia

de diretorios, podendo ser lidos e escritos da maneira usual.

Esta topologia cliente-servidor, tıpica do NFS, caracteriza-se por todas as operacoes

de leitura e escrita serem realizadas pelo servidor, causando uma centralizacao de carga

de processamento e armazenamento.

Uma alternativa para resolver este problema e a configuracao de um sistema de ar-

quivos distribuıdo, em que os dados permanecem espalhados de forma controlada, entre

diversas maquinas constituintes de um agrupamento. Dessa forma a carga e dividida entre

todos os computadores da rede.

Um exemplo de sistema de arquivos distribuıdos e o Andrew File System (AFS)

(MELLON, 2008), ele e constituıdo por clusters, com um servidor de arquivos e varias

estacoes clientes. Seu objetivo e fazer com que a maioria do trafego seja local a um unico

cluster, para reduzir a carga no servidor. Quando um usuario solicita a abertura de um

arquivo, este e carregado para o disco da estacao, de maneira a parecer um arquivo comum

para o sistema operacional, desta forma as chamadas de leitura e escrita trabalham de

forma usual.

1.1 Objetivos 2

O armazenamento distribuıdo pode proporcionar nativamente varios requisitos de-

sejaveis de um sistema de arquivo comum, como reducao da duplicidade de um mesmo

arquivo em maquinas clientes, replicacao dos dados para seguranca (backup), aproveita-

mento adequado de discos e a disponibilidade da informacao para qualquer estacao.

Um ponto importante para todo sistema distribuıdo e a capacidade de ampliacao sem

degradar o desempenho do ambiente. Este requisito, conhecido como escalabilidade, pode

ser atingido com a utilizacao de tabelas hash distribuıdas. Atraves deste recurso nao so

os dados do sistema estao distribuıdos, como tambem as informacoes de controle.

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ıvel de usuario, isto e, nao serao alteradas as funcoes do sistema operacional e do

sistema de arquivos local. O sistema devera ser funcionalmente simetrico, onde todas as

maquinas do agrupamento terao o mesmo papel dentro do sistema.

Objetivos especıficos:

• Estudo detalhado dos principais sistemas de arquivos distribuıdos e comparacao de

seus recursos;

• Elaboracao do projeto incluindo o detalhamento dos recursos e diagramas;

• Desenvolvimento de um prototipo do software para realizacao de testes e analise;

1.2 Organizacao do trabalho

O presente trabalho esta organizado da seguinte forma, o capıtulo 2 descreve algumas

conhecidas implementacao de sistemas distribuıdos e um esclarecimento sobre tabela hash

distribuıda, a capıtulo 3 contem explanacoes sobre a arquitetura e o projeto desenvolvido

e os diagramas construıdos, no final os testes e as conclusoes sao expostas.

3

2 ARQUITETURAS DESISTEMAS DISTRIBUIDOS

2.1 Sistemas de arquivos distribuıdos

A seguir serao apresentadas algumas implementacoes de sistemas de arquivos dis-

tribuıdos (DFS - Distributed File System) produzidas por empresas e universidades.

Encontra-se disponıvel no apendice A uma tabela comparativa entre os sistemas descritos.

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 especificacoes para acesso

a arquivos remotos em redes locais. (SILBERSCHATZ; GALVIN, 2000)

O NFS e o DFS mais amplamente utilizado em ambientes UNIX. Apos a liberacao

da primeira versao do NFS, em 1985, a Sun tornou publica a especificacao do protocolo

NFS, isto permitiu a implementacao de servidores e clientes NFS por outros vendedores

(KON, 1995).

Este protocolo visa a operacao em ambientes heterogeneos (hardware, sistema ope-

racional, arquiteturas de redes) (SILBERSCHATZ; GALVIN, 2000). Requisito obtido por

meio de chamadas de procedimentos remotos (RPC). Assim, a construcao de sistemas

aderentes a especificacao NFS permite a interacao entre implementacoes de diferentes

desenvolvedores. Hoje e possıvel encontrar implementacoes do NFS para quase todos os

sistemas operacionais como UNIX, MacOS, OS/2 e Windows.

Por definicao os servidores NFS sao sem estados, ou seja, eles nao armazenam in-

formacoes sobre o estado de acesso pelo cliente a seus arquivos. Isto garante uma sim-

plificacao no desenvolvimento da aplicacao e uma ganho de desempenho. Por outro lado,

servidores sem estado nao podem controlar acessos concorrentes e, por conseguinte, nao

asseguram a coerencia do seu sistema de arquivos. Diferentes clientes podem ter diferentes

2.1 Sistemas de arquivos distribuıdos 4

e conflitantes copias de um mesmo arquivo ou diretorio em seu cache local.

O espaco de nomes de cada cliente pode ser diferente dos demais, mas, a partir do

ponto de vista do usuario, este e local e transparente. E tarefa do administrador do

sistema determinar como cada cliente ira ver a estrutura de diretorios.

A aplicacao de nıvel de usuario baseada em RPC e a polı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 e o DFS mais utilizado em redes de trabalho.

Andrew File System

O projeto Andrew (AFS) comecou no Carnegie Mellon University em 1983 com o

apoio da IBM. Seu objetivo era conceber e implementar um DFS ideal para o ambiente

academico, que iria permitir o compartilhamento de uma estrutura comum de diretorios

entre milhares de maquinas clientes Kon (1995).

O espaco de nomes do AFS e composto pelos chamados volumes, estes sao associados

aos arquivos de um unico cliente. Os volumes sao agrupados por um mecanismo similar

aos de montagem do UNIX. A localizacao dos arquivos e registrada em bancos de dados,

replicados em cada servidor, assim os clientes obtem a localizacao dos volumes atraves de

consultas a essa base de dados. (SILBERSCHATZ; GALVIN, 2000)

O AFS foi construıdo para quando um cliente abrir um arquivo remoto, todo ele seja

obtido a partir do servidor. Todas as operacoes subsequentes de leitura e escrita utilizarao

uma copia armazenada em um disco local. So quando o arquivo e fechado, e se este foi

modificado, ele e transferido de volta para o servidor. Uma das consequencia desta tecnica

e que um cliente C1 somente pode perceber uma atualizacao do arquivo F feita por outro

cliente C2, somente se C1 abrir F apos C2 fecha-lo.

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 versao do arquivo a partir de outro cliente.

CODA

O sistema CODA, implementado no inıcio dos anos noventa, e um descendente do AFS

(KON, 1995). Seu principal objetivo e fornecer acesso a um DFS a partir de computadores

portateis. O CODA implementa mecanismos de duplicacao automatica nao presentes


no AFS, porem a coerencia entre varias copias de um mesmo arquivo e mantida com

chamadas de retorno, semelhante ao AFS.

O recurso mais interessante do CODA e a possibilidade de acessar arquivos do DFS

sem estar conectado a rede. Se um arquivo esta armazenado em cache local no disco

do computador portatil, o usuario pode ler e atualizar este sem a permissao do servidor.

Quando o computador portatil e reconectado a rede, o sistema propaga para os servi-

dores apropriados as atualizacoes feitas durante o perıodo desconectado. Podem ocorrer

conflitos, por exemplo, atualizacoes no mesmo arquivo feitas por clientes diferentes, de-

vido a isto o CODA fornece algumas ferramentas para o usuario decidir qual versao deve

prevalecer.

Para permitir o acesso aos arquivos enquanto estiver desconectado, o cliente CODA

tenta manter em seu disco local a maior quantidade possıvel de dados. Se o disco local esta

cheio e um novo arquivo deve ser copiado para ele, o arquivo em cache com a prioridade

mais baixa e descartado.

SPRITE

Os dois principais objetivos do sistema de arquivos SPRITE foram de obter alto

desempenho e a semantica UNIX para compartilhamento de arquivos. O desempenho

alcancado foi um dos melhores do seu tempo, certamente melhor do que o NFS e o AFS

(KON, 1995). A semantica UNIX tambem foi atingida, o usuario encontra o mesmo tipo

de estrutura de uma maquina UNIX local.

O cliente obtem a localizacao dos arquivos consultando uma tabela de prefixos. Cada

entrada nesta tabela consta o nome do diretorio, o endereco do servidor e um numero

identificador do diretorio. Esse mapeamento e construıdo e atualizado dinamicamente

atraves de mensagem em broadcast na rede.

Como o SPRITE e utilizado em ambientes de servidores com memorias de grande

capacidade e estacoes de trabalho normalmente sem discos, este utiliza um esquema em

que a memoria cache de arquivos e alocada na memoria fısica, e nao em discos. Normal-

mente, o cache do sistema de arquivos pode chegar a centenas de megabytes da memoria

disponıvel.

A fim de economizar o trafego da rede, as alteracoes dos arquivos sao gerenciadas por

um mecanismo chamado atualizacao atrasada (SILBERSCHATZ; GALVIN, 2000). Uma vez

a cada 30 segundos, todos os blocos, que nao foram alterados sao enviados para o servidor.


Um bloco de dados alterado pode levar ate 60 segundos para ser enviado para o servidor

e depois ate mais 60 segundos para ser escrito no disco. Por outro lado, a atualizacao

atrasada torna o sistema mais sensıvel a falhas (KON, 1995).

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 esta utiliza sao, em

sua maioria, maiores que gigabytes e as alteracoes que eles sofrem sao frequentemente

por anexacao e nao por substituicao, tendendo a um crescimento contınuo. Aliando esses

fatores ao problema de falhas em servidores de baixo custo, os desenvolvedores visaram a

criacao de um sistema escalavel, a prova de falhas e com bom desempenho (GHEMAWAT;

GOBIOFF; LEUNG, 2003).

O GFS e um sistema baseado em clusters, onde cada um possui um servidor mestre

(master server) e diversos servidores de porcao (chunkservers). Os arquivos sao divididos

com tamanho fixo de 64 megabytes, identificados por um rotulo de 64 bits e replicadas

entre os chunkservers (TANENBAUM; STEEN, 2007). Usualmente as porcoes possuem 3

replicas, contudo este numero pode ser alterado para arquivos com maior demanda.

Essa tecnica melhora consideravelmente o desempenho do sistema, pois os arquivos

podem ser obtidos paralelamente entre os diversos servidores de porcoes. Tambem visa

o controle a falhas, pois mesmo no caso de uma falha fısica num chunkservers, outros

servidores ainda terao copias das porcoes perdidas.

Os chunkservers mantem uma tabela atualizada contendo os dados que possui. Essas

informacoes sao enviadas para o servidor mestre, estando sempre atualizado e conhecendo

a localizacao das porcoes dos arquivos.

O servidor mestre armazena tres tipos principais de meta-dados: servico de nomes

para os arquivos e porcoes, o mapeamento dos arquivos para suas porcoes, e a loca-

lizacao de cada replica. Tambem tem conhecimento dos processos que estao utilizando

as replicas. Em outras palavras, sua funcao e de gerenciar as porcoes para que estejam

sempre disponıveis nos chunkservers para que o cliente GFS possa acessa-las.

Essa organizacao nao gera gargalo no servidor mestre, pois apos a consulta inicial

para localizacao das porcoes, o dialogo passa a ser entre o cliente e o chunkservers. A

organizacao do GFS permite que um servidor mestre controle centenas de chunkservers, e

varios cluster podem ser interligados definindo o GFS como um DFS altamente escalavel.

2.2 Tabela hash distribuıda 7

2.2 Tabela hash distribuıda

Uma tabela hash e uma estrutura de dados que associa chaves (hash) a valores. As

chaves sao obtidas atraves de uma funcao de tal maneira que seja simples e eficiente

encontrar um valor na tabela apenas atraves de sua chave.

Como mostra a figura 1 (LUA et al., 2005) uma tabela hash distribuıda (DHT - Distri-

buted Hash Table) configura uma camada entre os nos (tradado na figura como peer) e a

rede de sobreposicao, e fornece os metodos necessarios para o gerenciamentos dos dados

do sistema.

Figura 1: Estrutura de sobreposicao de sistemas baseada em DHT

Os dados e os nos da rede recebem uma chave identificadora dentro do mesmo espaco

de endereco da DHT, desta forma, a consulta pelo hash dos dados leva ao no responsavel.

Principais objetivos de uma DHT:

• Sempre e possıvel localizar um item da tabela;

• Manter a operacionalidade mesmo com um grande nıvel de participantes no sistema;

• Fornecer recursos eficientes para a adicao e remocao de nos

Existem varios modelos de DHT, como Chord (STOICA et al., 2001), CAN (RATNA-

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

tracar um mapa de nos e dados, relacionados por suas chaves. Possui a capacidade de

2.2 Tabela hash distribuıda 8

adaptar-se a entrada e a saıda de nos do sistema, respondendo a requisicoes mesmo com

sistema mudando continuamente.

O Chord organiza os nos em um anel de maneira que cada um conhece a chave e a

situacao o seu predecessor e sucessor, alem disto, cada no contem uma tabela de derivacao

(finger table) que contem o par chave e endereco de outros nos da rede (TANENBAUM;

STEEN, 2007). Esta tabela possui numero limitado de registros e e montada atraves de

uma formula matematica com a propria chave do no.

Figura 2: Exemplos de resolucao de chaves no Chord (TANENBAUM; STEEN, 2007).

A figura 2 mostra um exemplo de como o sistema Chord utilizando as informacoes da

tabela de derivacao realizaria a resolucao de uma chave igual 26 a partir do no 1 (linha

contınua) e outra da chave 12 a partir do no 28 (linha pontilhada).

A localizacao de um no responsavel normalmente exige O(log(N)) etapas, sendo N o

numero de nos do anel (TANENBAUM; STEEN, 2007), a caracterıstica logarıtmica garante

a escalabilidade do modelo Chord.

9

3 ARQUITETURA

Este projeto consiste em um software distribuıdo baseado em DHT para armazena-

mento de arquivos em rede, onde todas os nos da DHT tem o mesmo papel.

3.1 Requisitos do sistema

Transparencia para o usuario. O mapeamento de nomes nao contem referencias

sobre a localizacao fısica do arquivo. O usuario pode utilizar o sistema remoto como um

recurso local, o sistema distribuıdo e responsavel por localizar os dados.

Esta caracterıstica tambem proporciona mobilidade, nao restringindo o usuario a

iniciar uma sessao em uma estacao de trabalho especıfica.

Configuracao funcional simetrica. Os elementos do sistema possuem o mesmo

grau de importancia e autonomia, todas as maquinas componentes tem igual papel na

operacao do sistema (SILBERSCHATZ; GALVIN, 2000).

Esta configuracao garante a escalabilidade do sistema, fornecendo facilidade de adi-

cionar e gerenciar novos usuarios e maquinas.

Replicacao dos arquivos. Diferentes copias de um mesmo arquivo residem em

maquinas diferentes. A atualizacao de uma copia e refletida em todas as outras, mantendo

a semantica de coerencia. Acoes de exclusao e inclusao tambem sao replicadas.

Fragmentacao dos dados entre os nos servidores do sistema. Os arquivos sao divi-

didos em blocos e armazenados em servidores distintos.

Coerencia. O sistema contem medidas para garantir a coerencia dos arquivos, prin-

cipalmente as copias abertas simultaneamente, coletando e armazenado informacoes de

estado de cada arquivo da estrutura.

Memoria Cache. O cliente mantem copias locais dos arquivos recentemente abertos,

a fim de otimizar o trafico na rede. As alteracoes feitas pelo usuario sao realizadas na

3.2 Projeto 10

copia local, e somente ao fechar o arquivo as modificacoes sao enviadas para os servidores.

Seguranca. Os arquivos e diretorios do sistema contem permissoes de acesso seme-

lhante ao empregado em ambientes UNIX, mas sem a presenca dos grupos de usuario.

Possibilidade de diferente nıveis de permissao para o proprietario e para os demais usuario.

Fornecendo o isolamento ou compartilhamento de dados.

3.2 Projeto

Elementos

O sistema de arquivos distribuıdo (DFS) e constituıdo de dois elementos principais:

nos clientes e nos servidores.

Os nos clientes sao caracterizados por possuırem uma interface de navegacao do DFS

(isolada do sistema de arquivo local da estacao cliente), por nao armazenarem os arquivos

distribuıdos e por manterem um cache temporario com os ultimos dados acessados.

Os nos servidores constituem o agrupamento mapeado pela DHT. Nestes nos sao

armazenados os arquivos e a estrutura de diretorio. Cada no e integrante da tabela hash

distribuıda, esta fornece o mapeamento da localizacao de todos os dados do DFS e as

regras para o armazenamento de novos arquivos.

O sistema possui servicos com informacao de estados, ou seja, os nos servidores tem

conhecimento referente a cada arquivo e sobre os clientes que estao acessando o sistema.

A carga principal de processamento e gerenciamento do sistema esta nos servidores,

isto garante uma baixa configuracao mınima de hardware para o cliente.

Tabela hash distribuıda

A fim de atender os requisitos do sistema de escalabilidade e a nao necessidade de

um servidor central, o projeto e construıdo sobre uma DHT. Os nos clientes obtem a

localizacao dos arquivos atraves de consultas na DHT, esta possui o mapeamento de um

determinado hash (correspondente a um arquivo dentro da arvore de diretorios) a um no

servidor que possui o arquivo.

Entre os projetos estudados, o Chord foi escolhido para a construcao do sistema de

arquivos por conseguir atender todos os requisitos de maneira simples.

3.2 Projeto 11

Neste projeto a funcao hash da DHT fornecera a localizacao fısica de um dado, ou seja,

o no responsavel, atraves do posicionamento logico do arquivo ou diretorio na estrutura

de arquivos logica do sistema. A chave e gerada a partir do caminho completo do arquivo

na arvore de diretorios virtual.

Mapeamento de nomes

A visao da arvore de diretorios e arquivos do sistema para um usuario cliente nao

contem qualquer informacao sobre a localizacao fısica do dado. Esta arvore e apresentada

de maneira semelhante a estrutura de arquivos locais. Mesmo que um dado fisicamente

seja movido para um outro no da DHT, a arvore e o nome do arquivo continuam inalte-

rados. Dessa forma o sistema fornece transparencia e independencia da localizacao fısica

do dado.

Estas caracterısticas sao atingidas por um modelo de estrutura de arquivos semelhante

a um sistema de arquivos convencional, atraves de inodes. Os inode sao arquivos de

controle que contem informacoes sobre um determinado diretorio ou arquivo. Na visao

do sistema, os inodes sao arquivos comuns armazenados nos servidores e indexados pela

DHT.

Quando um cliente solicita visualizar o conteudo de um diretorio, e enviado a ele um

arquivo de controle (o inode correspondente) com a lista de arquivos e subdiretorios do

diretorio requisitado. Esta informacao e processada e apresentada pela interface cliente

do sistema, adicionando os elementos descritos no inode dentro da arvore de diretorios.

Essa estrutura e montada de forma semelhante ao ambiente UNIX, utilizando a barra ‘/’

como separador de diretorios e como raiz do sistema.

Quando ha uma alteracao na arvore, como remocao ou inclusao de arquivos ou di-

retorios, os inodes correspondentes sao atualizados pelo sistema.

Coerencia

Para manter a coerencia dos arquivos, o sistema possibilita que somente um cliente

abra um determinado arquivo para edicao. Caso esta condicao seja atingida, as novas

solicitacoes por este arquivo sao caracterizadas como somente leitura.

O inode carrega o parametro que indica se o arquivo esta sendo utilizado por algum

cliente. A responsabilidade de atualizar este parametro e do no servidor que possui o inode

alocado, pois quando o cliente solicitar o arquivamento deste dado, o sistema informa a

este servidor para liberar o arquivo.

3.2 Projeto 12

Para garantir que um arquivo nao permaneca bloqueado no caso de falhas do cliente,

o no responsavel envia mensagens de controle a este para cada outra requisicao para esse

mesmo arquivo, caso o no nao obtenha uma resposta, o arquivo e liberado para o novo

cliente e o primeiro requisitante perde os privilegios sobre aquele arquivo ate um proximo

pedido.

Quando os arquivos sofrem alteracoes, a coerencia tambem deve ser tratada nas

replicas. Da mesma forma, o no responsavel por essa tarefa e o que possui o inode.

Memoria Cache

Ao ser solicitado para o sistema um arquivo, este e salvo na memoria cache localizada

no disco rıgido da maquina cliente. Todos os acessos futuros sao feitos nesta copia local.

O arquivo e reenviado para o sistema somente quando o cliente solicita, pela interface do

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 alteracao da copia remota (informacao fornecida ao modulo cliente atraves do

inode deste arquivo) com a do arquivo em cache. O arquivo so e novamente transferido

se a copia remota for mais recente que a local. Mesmo nesta situacao o sistema marca o

inode deste arquivo como em uso, garantido a coerencia.

O tamanho da cache sera limitado, assim quando o limite for atingido os dados mais

antigos sao removidos para que novos arquivos sejam salvos na area de cache. Um dado

mais antigo tem maior chance de ter sofrido alteracoes por outro cliente do sistema.

Replicacao

O sistema conta com o recurso de replicacao dos dados entre os nos da DHT de forma

autonoma, a fim de aumentar a disponibilidade dos arquivos em caso de falha de algum

no servidor.

A escolha por qual no armazena a copia e feita baseada na propria estrutura da DHT,

como os nos sao organizados logicamente em um anel, o no sucessor tera uma copia dos

arquivos de seu predecessor.

Este modelo foi escolhido pela sua simplicidade e por utilizar os recursos ja fornecidos

pela DHT.

Os metodos de replicacao sao chamados quando um novo arquivo e inserido ou atu-

alizado no sistema. A responsabilidade por manter a coerencia das copias e do no que

3.2 Projeto 13

possui seu inode.

Em caso de falha de um no servidor, o cliente esta configurado para solicitar o arquivo

para o no imediatamente seguinte na estrutura da DHT.

Quando o sistema percebe a falha de algum no, e iniciado o processo de balanceamento

dos dados, isto porque um no que antes empregava o papel de replica passa a ser o servidor

principal para aquele conjunto de inode e fragmentos e precisa enviar todos os seus dados

para o seu sucessor para manter a duplicidade das informacoes.

Fragmentacao

Os arquivos sao fragmentados em partes menores, cada um de seus fragmentos e arma-

zenado e indexado em um no servidor distinto. O processo de fragmentacao e transparente

para o usuario.

Apenas arquivos que ultrapassam um tamanho especıfico sao fragmentados e em blo-

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 ira ser empregado. Estruturas de maior porte admitem blocos maiores.

As informacoes sobre os fragmentos sao armazenadas no inode do arquivo. Quando

um cliente abre um arquivo, o no responsavel gera requisicoes para os servidores citados no

inode solicitando os blocos. Apos receber todos os fragmentos, este no faz a reconstrucao

do arquivo e o envia ao cliente.

Esta caracterıstica garante que a carga do sistema seja igualmente distribuıda pelo

nos da DHT. Desta forma quando um grande arquivo e requisitado varios nos participam

do processo por um curto perıodo de tempo. Caso a fragmentacao nao existisse apenas o

no responsavel executaria toda a tarefa, trabalhando um longo perıodo.

Seguranca

Quando um novo arquivo e armazenado no sistema, seu inode gerado carrega a in-

formacao de qual e o usuario proprietario do arquivo. Por padrao este arquivo nao possui

qualquer restricao de acesso.

Os proprietarios podem alterar a permissao de acesso de seus arquivos, configurando

o nıvel de acesso que deseja que os outros usuarios tenham de seus dados. Esse nıvel pode

ser acesso completo, somente para leitura ou bloqueado.

3.2 Projeto 14

O nıvel de acesso completo permite que os demais abram, removam ou atualizem o

arquivo. Para o nıvel de leitura, apenas a opcao de abrir e liberada, enquanto que para o

bloqueado nenhuma opcao esta disponıvel. O proprietario sempre possui nıvel de acesso

completo de seus dados.

O nıvel de permissao deve ser aplicado diretamente ao dado desejado, nao e possıvel

atribuir nıveis de permissao para os diretorios do sistema. Esta limitacao existe, pois nao

e eficiente verificar a permissao de cada inode dos diretorios da estrutura de um arquivo

com o objetivo de liberar cada uma das acoes dos usuarios.

Diagrama UML

Figura 3: Diagrama de casos de uso

A figura 3 mostra os possıveis casos de uso de um usuario para com o sistema. A

modelagem UML completa e encontrada no apendice B.

3.3 Implementacao 15

3.3 Implementacao

Alguns dos pontos descritos na secao Projeto foram implementados gerando um

prototipo do sistema. O intuito deste desenvolvimento foi verificar a viabilidade do projeto

e a realizacao de testes.

O sistema foi escrito na linguagem de programacao JAVA com apoio das classes nativas

de sockets, sem a utilizacao de API externas.

Das funcionalidades propostas, o sistema implementado esta focado no nucleo do

projeto, a interacao dos clientes com os arquivos e diretorios do sistema. Os requisitos

desenvolvidos foram transparencia e configuracao funcional simetrica.

A implementacao possui programas especıficos para cada acao do cliente e um modulo

de multiplas threads para os servidores.

Estao disponıveis para o cliente as acoes de abrir arquivos, em que o dado requisitado e

carregado do sistema para a estacao do cliente, gravar um arquivo, onde um novo arquivo e

enviado para o sistema, a acao de remover um arquivo e de listar o conteudo de diretorios.

O programa para os servidores possui metodos para a criacao e manutencao da DHT,

montando uma tabela de nos servidores. Estes tambem contem metodos para atender a

cada uma das acoes dos clientes descritas anteriormente.

O controle dos dados do sistema e realizado atraves de arquivos de meta-dados, de-

nominados inode. Os inodes sao gerenciados pelos servidores e contem informacoes sobre

um arquivo ou diretorio.

3.3.1 Sistema distribuıdo

O elemento do sistema executado pelos nos da DHT, constitui um programa denomi-

nado noDHT responsavel pelo gerenciamento dos dados, atendimento das requisicoes dos

clientes e realizacao de manutencoes e consultas na DHT.

Para tanto este programa e divido em duas threads. A primeira contem os codigos

especıficos para o tratamento das acoes solicitadas pelos clientes do sistema. Ao ser

iniciada, esta cria um socket TCP/IP na porta 9009. O numero desta porta e comum a

todos e assim os usuarios nao necessitam fornece-la para se conectar a um servidor.

A segunda thread e destinada apenas as requisicoes dos outros nos da DHT, como os

metodos de entrada e saıda da DHT e o gerenciamento dos diretorios do sistema. Esta


inicia um socket tambem TCP/IP na porta 9000.

Manutencao da DHT

A DHT comeca a ser montada quando o primeiro no servidor e iniciado. Este, sabendo

desta situacao, apenas acrescenta seu endereco IP a recem criada DHT e aguarda por

requisicoes.

Exemplo: java noDHT

Este comando e utilizado para iniciar o primeiro no da DHT.

Ao iniciar os demais nos e preciso fornecer o endereco IP de um no ja pertencente

da DHT. Este novo no recebe da maquina indicada a copia da DHT contendo a lista das

maquinas existentes no sistema. O no atualiza a sua lista com seu proprio endereco IP e

envia uma mensagem para todos os nos indicados na DHT, solicitando que o adicionem

em suas tabelas.

Exemplo: java noDHT 192.168.0.94

Este comando inicia um novo no servidor solicitando a DHT para o no 192.168.0.94.

Antes de deixar o sistema, um no avisa todos os outros, para que estes o removam da

DHT. Nao foi implementado metodos para detectar que um no deixou a DHT sem avisar

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 metodos descritos em Stoica et al. (2001). O

OpenChord e uma implementacao de codigo aberto em linguagem JAVA e esta disponıvel

gratuitamente sob a licenca GNU GPL, o desenvolvimento e do Distributed and Mobile

Systems Group da Universidade de Bamberg.

Porem optou-se por implementar as funcionalidades da DHT ao inves de utilizar o

OpenChord pois esta se trata de uma API completa e extensa, incorporando muitos

recursos alem do necessario para o desenvolvimento deste projeto.

O modulo da DHT foi desenvolvido desde o inıcio baseado-se nas documentacoes

oficiais. Esta construcao tem como vantagem que o resultado final e uma implementacao

enxuta e otimizada para a finalidade.


Este modulo construıdo nao implementa o conceito de tabela de derivacao, onde cada

no conhece apenas um numero limitado de outros nos, mas sim, cada no mantem uma

relacao de todos os nos da rede. Esta decisao teve como base o tempo de desenvolvimento

desta caracterıstica do Chord, preferiu-se dedicar os recursos disponıveis para a criacao

do projeto em si.

Geracao de chaves

A construcao do modulo da DHT tambem exigiu o desenvolvimento de um algoritmo

para geracao de chaves. Assim como a API OpenChord, a chave e gerada atraves da

funcao SHA1 (JONES, 2001).

Ao submeter uma sequencia de bits para a funcao SHA1 e obtido um hash de 160

bits, comumente tratado como uma sequencia de letras e numeros, como o Chord faz

comparacoes entre as chaves (maior ou menor), o valor gerado pelo SHA1 recebe um

tratamento removendo todas as letras e truncando o resultado em cinco caracteres. O

resultado e sempre um numero inteiro de zero a 99999.

O valor obtido e associado ao no ou a um dado do sistema na DHT, que por essa

caracterıstica tem um espaco de endereco de cem mil posicoes.

Para as chaves relacionadas aos nos, o valor enviado a funcao e um texto constituıdo

de seu endereco IP no formato de quatro grupos de numeros separados por pontos. Pelos

testes realizados, a funcao SHA1 garante a diversidade das chaves, mesmo com pouca

variacao entre um endereco e outro.

Para os arquivos, a geracao das chaves utiliza o caminho completo mais o nome do

arquivo. O mesmo processo e feito para os diretorios, a chave e obtida atraves da estrutura

completa ate o referido diretorio.

3.3.3 Gerenciamento dos diretorios

Nao existem diretorios reais no sistema distribuıdos, sua existencia e mapeada atraves

de arquivos de controle denominados inode. Os inodes sao arquivos de texto tratados pela

DHT como arquivos convencionais, ou seja, possui uma chave e um no responsavel, porem

os servidores utilizam-se destes para o controle da arvore de diretorio do sistema.

Quando um cliente envia um novo arquivo, este indica em qual diretorio deseja ar-

mazenar o novo dado. Assim enquanto o servidor responsavel recebe os dados binarios

atraves da conexao com o cliente, outras conexoes sao abertas para os nos responsaveis


por cada nıvel da estrutura fornecida pelo usuario.

Por exemplo, quando o cliente solicita gravar um novo arquivo no diretorio /home/usuario,

o servidor responsavel tera que enviar uma requisicao para outros tres servidores, o res-

ponsavel pelo diretorio raiz /, outra para o responsavel pelo /home e por ultimo para o

responsavel pelo /home/usuario.

Estes nos verificam a necessidade criar o inode correspondente aquele diretorio e em

seguida, escrevem o seu conteudo (nome do arquivo ou do proximo diretorio). O nome

do inode e constituıdo do prefixo ‘i’ mais o valor de sua chave e o nome do diretorio.

Continuando o exemplo anterior, o no responsavel por /home, deve possuir um arquivo

de controle com o nome i 70476 home e conteudo uma linha com a palavra usuario.

Desta forma o conteudo gravado em um inode de diretorio e a lista de seus arquivos

e subdiretorios, assim quando o usuario utiliza o comando listar o no responsavel pelo

diretorio lhe envia o conteudo do inode.

3.3.4 Interface com o usuario

Todas as interacoes dos clientes com o sistema sao feitas atraves de programas exe-

cutados em linha de comando. Para o cliente e transparente a existencia de um conjunto

de servidores que gerencia o sistema distribuıdo, mas e preciso informar em qual maquina

servidora o cliente ira se conectar. Todo os nos da DHT tem a capacidade de atender a

essas requisicoes.

No inıcio de cada comando do cliente, o servidor indicado manualmente tem a funcao

de consultar a DHT e responder aos programas clientes qual o endereco IP do servidor

responsavel pelo dado requisitado. Desta forma uma nova conexao e aberta entre o cliente

o servidor responsavel e assim so assim executada a acao especıfica.

Estao disponıveis aos clientes as acoes de abrir, gravar, remover e listar.

Com o comando abrir o cliente solicita um arquivo especıfico do sistema para ser

carregado em sua maquina local e assim ter acesso a seu conteudo. O comando possui

dois parametros, o endereco IP de um dos servidores e o caminho completo do arquivo

desejado.

Exemplo: java abrir 192.168.0.1 /home/usuario/documento.pdf

Com isso o programa abrir apos receber de 192.168.0.1 o endereco IP do servidor


responsavel por /home/usuario/documento.pdf estabelece uma nova conexao para receber

o arquivo binario.

Com o comando gravar o cliente indica um arquivo local para ser submetido para

o sistema distribuıdo. O comando possui tres parametros, o endereco IP de um dos

servidores, o arquivo local que deseja enviar para o sistema e o caminho completo do

diretorio destino.

Exemplo: java gravar 192.168.0.1 c:\usuario\filme.avi /home/usuario

Neste caso a maquina 192.168.0.1 apos receber todos os parametros, realiza uma

concatenacao do diretorio destino com o nome do arquivo (/home/usuario/filme.avi) para

assim consultar na DHT qual sera o servidor responsavel por aquele novo arquivo. Na

sequencia o programa gravar estabelece uma conexao com o endereco IP recebido e envia

o arquivo binario para o servidor responsavel.

Com o comando remover o cliente envia um pedido para que um arquivo remoto

seja excluıdo do sistema. O comando possui dois parametros, o endereco IP de um dos

servidores e o caminho completo do arquivo.

Exemplo: java remover 192.168.0.1 /home/usuario/documento.pdf

Logo apos receber o endereco IP do responsavel, o programa remover solicita a este

servidor para que o dado /home/usuario/documento.pdf seja removido.

Com o comando listar o cliente solicita um visualizar o conteudo de determinado di-

retorio do sistema. O comando possui dois parametros, o endereco IP de um dos servidores

e o caminho completo do diretorio.

Exemplo: java listar 192.168.0.1 /home/usuario

A maquina 192.168.0.1 deve consultar na DHT o responsavel pelo diretorio /home

/usuario, este responsavel possui um arquivo de controle (inode) referente a esse diretorio

contendo o nome de seus arquivos e subdiretorios. O endereco IP do servidor responsavel

e retornado para o programa listar que apos realizar a nova conexao recebe o conteudo do

arquivo de controle, ou seja, a lista com os nomes dos subdiretorios e arquivos do diretorio

requisitado.

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 memoria

RAM e sistema operacional Windows XP SP 3. Pela necessidade dos testes exigirem um

consideravel numero de estacoes, a rede foi construıda atraves de virtualizacao utilizando

o software Microsoft Virtual PC 2007 SP1.

Todas as maquinas virtuais possuıam 128 megabytes de memoria RAM e Windows

XP Service Pack 3 com o Java Runtime Environment 1.6.0 06. Simultaneamente eram

executadas quatro maquinas virtuais, cada uma com um endereco IP e executando o

programa noDHT.

Os primeiros testes focaram a construcao e manutencao da DHT por parte dos servi-

dores. Devido a caracterıstica do ambiente de teste, as rotinas de entrada e saıda de nos

mostram-se eficiente para uma DHT de quatro maquinas.

Para este, os resultados sao:

• Todas as maquinas, sem considerar a ordem de entrada na DHT, sao capazes de

controlar a entrada de um novo no servidor.

• A saıda do primeiro no nao causou instabilidades na DHT.

• Nao e importante a quantidade de vezes que uma maquina deixa e retorna ao sis-

tema.

Para os testes com as acoes da interface cliente, a DHT era constituıda de quatro

maquinas servidoras e uma delas tambem executava o software cliente. Todos os metodos

implementados (gravar, abrir, remover) foram alvos de teste.

Resultados obtidos:

• A gravacao de um arquivo de 3.649.965 bytes (3,48 megabytes) foi executada na

ordem de 3 segundos. Para um arquivo de 126.933.775 bytes (121 megabytes) a

acao foi finalizada na ordem de 1 minuto.

• A acao de abrir, ou seja, enviar um arquivo do servidor ao cliente, para o menor

arquivo foi executada na ordem de 3 segundos e 59 segundos para o maior.

• A acao de remocao por parte do cliente funciona de maneira satisfatoria.

3.4 Testes 21

• Nao foram detectados problemas nas transferencias de dados em formato de texto

ou binario.

• O sistema notifica o cliente caso as acoes de abrir ou remover sejam solicitadas para

dados nao presentes no sistema.

• A acao de gravar nao avisa o cliente caso o arquivo ja exista na estrutura de diretorios

informada, causando a sobreposicao do dado.

22

4 CONCLUSAO

Uma vez analisadas diversas arquiteturas de sistemas de arquivos distribuidos, ela-

borada a documentacao de um projeto e executados a implementacao e testes de um

prototipo, obtiveram-se resultados que permitem apresentar as seguintes conclusoes:

• As atuais tecnologias e estudos na area de sistema de arquivos distribuıdos encontram-

se em avancado nıvel de desenvolvimento fornecendo uma grande quantidade de

projetos e solucoes para o desenvolvimento de aplicacoes nesta area.

• No que tange a elaboracao do projeto com o detalhamento dos recursos e diagramas,

foram descritos todos os requisitos levantados com suas dependencias e relaciona-

mentos e construıdo a documentacao na linguagem UML.

• O prototipo desenvolvido com o objetivo de estruturar uma DHT e fornecendo

recursos para gerenciar os arquivos dos clientes atendeu os requisitos propostos e de

acordo com os testes realizados confirmou a eficacia do projeto.

Conclui-se, em vista do exposto, que a tecnologia DHT mostra-se viavel para o de-

senvolvimento de sistemas de arquivos distribuıdos.

Trabalhos futuros

Alguns pontos deste projeto nao foram implementados em sua totalidade, utilizando

a documentacao elaborada e possıvel concluir a construcao do sistema. Ressaltando itens

como o modulo da DHT, onde cabe desenvolver a finger table do Chord (STOICA et al.,

2001), as funcionalidades de replicacao, fragmentacao e seguranca, e a interface cliente,

construindo uma aplicacao grafica mais amigavel.

Outro foco para novos trabalhos e a pesquisa e testes para a utilizacao no sistema

de outras implementacoes de tabelas hash distribuıdas, como a CAN (RATNASAMY et al.,

2001) e Pastry (CASTRO et al., 2003).

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

Replicacao Ruim: SomenteLeitura (somentediretorios)

Ruim: SomenteLeitura (somentediretorios)

Boa: A carga e dis-tribuıdas entre cli-entes

Ruim: SomenteLeitura (somentediretorios)

Excelente: Porcoessao distribuıdas en-tre diferentes servi-dores

Consistencia Ruim: Acessosimultaneo geraresultados impre-visıveis

Razoavel:Semantica dasessao

Ruim: Semanticada sessao enfraque-cida

Excelente:Semantica doUnix

Boa: Adequado asua finalidade

Escalabilidade Ruim: Rapida sa-turacao dos servi-dores

Excelente: Idealpara WANs combaixo grau dacompartilhamento

Excelente: Idealpara WANs combaixo grau dacompartilhamento

Ruim: O protocolorequer broadcasts

Excelente: Orga-nizacao em clusters

Performance Ruim: Protocoloineficiente

Razoavel: Grandelatencia para arqui-vos nao armazena-dos em cache

Boa: Procurapor replica ‘maisproxima’

Boa: Imple-mentacao dokernel. Atualizacaoatrasada. Grandescache

Boa: Performanceotimizada para ar-quivos grandes

Persistencia emcaso de falhas

Ruim: Gravacoesatrasadas podemcausar perda dedados

Boa: Ferramen-tas de backupautomaticos

Boa Ruim: Longos atra-sos nas gravacoespodem causarperda de dados

Boa: Recuperacaorapida e replicacaode dados - simplese eficiente

Disponibilidade Ruim Ruim Excelente:Operacoes des-conectadas

Razoavel: Rapidarecuperacao de fa-lhas

Excelente: Re-plicacao dos dadosdos servidores deporcoes

Seguranca Ruim: Servidoresconfiam nos clien-tes

Boa: Lista de con-trole de acesso. Au-tenticacao entre cli-ente e servidores.

Boa: Lista de con-trole de acesso. Au-tenticacao entre cli-ente e servidores.

Ruim: Servidoresconfiam nos clien-tes

Usuarios nao temacesso direto ao sis-tema

Localizacao docache do cliente

Memoria Disco Disco Memoria Disco

Plataformas Todas as principais Estacoes SGI, HP,Nest, DCE, IBM,SUN e VAX

IBM RT, estacoesDEC e IBM PC

Estacoes SPARC eDEC

IBM PC

Caracterısticasde Hardware

Permitir clientessem disco

- Permite compu-tadores portateis.Replicacao requerservidores extras.

Permitir clientessem disco

Utilizacao de ser-vidores de baixocusto

Tabela 1: Tabela comparativa dos sistemas de arquivo distribuıdos.

24

APENDICE B -- Diagramas UML

B.1 Diagrama de classes

Figura 4: Relacao entre as principais classes do projeto

B.2 Diagramas de sequencia 25

B.2 Diagramas de sequencia

Figura 5: Sequencia para a abertura de um arquivo


Figura 6: Sequencia para a gravacao de um arquivo


Figura 7: Sequencia para a remocao de um arquivo


Figura 8: Sequencia para a alteracao das permissoes de um arquivo

Figura 9: Sequencia para a obter informacoes sobre um arquivo


Figura 10: Sequencia para obter o conteudo de um diretorio

Figura 11: Sequencia para a entrada de um novo no na DHT

30

Referencias

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ıvel em: <http://labs.google.com/papers/gfs-sosp2003.pdf>.Acesso em: 29 abr. 2008.

JONES, P. RFC, RFC3174 - US Secure Hash Algorithm 1 (SHA1). 2001. Disponıvel em:<http://www.ietf.org/rfc/rfc3174.txt>. Acesso em: 11 set. 2008.

KON, F. Distributed File Systems Past, Present and Future A Distributed File Systemfor 2006. 1995. Disponıvel em: <http://citeseer.ist.psu.edu/kon96distributed.html>.Acesso em: 15 abr. 2008.

LOESING, K.; KAFFILLE, S. Open Chord. 2008. Disponıvel em: <http://open-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ıvel em:<http://www.acm.org/sigs/sigcomm/sigcomm2001/p13-ratnasamy.pdf>. Acesso em: 02jun. 2008.

SHEPLER, S. RFC, RFC 3530: Network File System (NFS) version 4 Protocol. abr.2003. Disponıvel em: <http://www.ietf.org/rfc/rfc3530.txt>. Acesso em: 21 abr. 2008.

SILBERSCHATZ, A.; GALVIN, P. Sistemas Operacionais: conceitos. 5. ed. Sao Paulo: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>. Acessoem: 02 jun. 2008.

STOICA, I. et al. The Chord/DHash Project - Chord HOWTO. 2007. Disponıvel em:<http://pdos.csail.mit.edu/chord/howto.html>. Acesso em: 04 jun. 2008.

Referencias 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ıvel em: <http://citeseer.ist.psu.edu/stoica01chord.html>.

TANENBAUM, A.; STEEN, M. V. Sistemas Distribuıdos - Princıpios e Paradigmas. 2.ed. Sao Paulo, SP: Pearson, 2007. 416 p. ISBN 9788576051428.

TANENBAUM, A. S. Sistemas Operacionais Modernos. 1. ed. Rio de Janeiro, RJ:Prentice Hall do Brasil LTDA, 1995.

Technology

Modelagem e implementação de um sistema de arquivos distribuído baseado em DHT