modelagem e implementação de um sistema de arquivos distribuído baseado em dht
DESCRIPTION
Uma característica dos sistemas de arquivos para redes é que todas as operações de leitura e escrita são realizadas por um servidor, causando uma centralização de carga de processamento e armazenamento.Uma alternativa para resolver este problema é a configuração de um sistema de arquivos 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 todos os computadores da rede. Exemplos desse modelo de sistema são o Andrew File System, CODA, SPRITE e Google File System.Os objetivos desse projeto são a pesquisa, implementação e a elaboração da documentação técnica de um sistema de arquivos distribuído em nível de usuário. Possuindo requisitos como transparência, escalabilidade e replicação e fragmentação dos arquivos.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 gerenciamento dos dados do sistema. Desta maneira, as máquinas clientes obtém a localização dos arquivos através de consultas na DHT que possui o mapeamento de um determinado hash a uma máquina servidora responsável pelo arquivo.TRANSCRIPT
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
2.1 Sistemas de arquivos distribuıdos 5
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.
2.1 Sistemas de arquivos distribuıdos 6
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
3.3 Implementacao 16
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.
3.3 Implementacao 17
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
3.3 Implementacao 18
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
3.3 Implementacao 19
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
B.2 Diagramas de sequencia 26
Figura 6: Sequencia para a gravacao de um arquivo
B.2 Diagramas de sequencia 27
Figura 7: Sequencia para a remocao de um arquivo
B.2 Diagramas de sequencia 28
Figura 8: Sequencia para a alteracao das permissoes de um arquivo
Figura 9: Sequencia para a obter informacoes sobre um arquivo
B.2 Diagramas de sequencia 29
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.