Sistema de arquivos distribuído

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Merge-arrows 2.svg
Foi proposta a fusão deste artigo ou se(c)ção com sistema de ficheiros distribuído. Por favor crie o espaço de discussão sobre essa fusão e justifique o motivo aqui; não é necessário criar o espaço em ambas as páginas, crie-o somente uma vez. Perceba que para casos antigos é provável que já haja uma discussão acontecendo na página de discussão de um dos artigos. Verifique ambas (1, 2) e não se esqueça de levar toda a discussão quando levar o caso para a central.
Editor, considere adicionar mês e ano na marcação. Isso pode ser feito automaticamente, com {{Fusão|1=sistema de ficheiros distribuído|{{subst:DATA}}}}.

A abstração usada para armazenar dados em sistemas computacionais é o arquivo. Para que esses arquivos sejam acessados, modificados e que sejam criados outros arquivos é necessária uma estrutura que permita tais operações. Essa estrutura recebe o nome de sistema de arquivos.

A motivação básica dos sistemas distribuídos é o compartilhamento de recursos[1] e no âmbito dos sistemas de arquivos, o recurso a ser compartilhado são os dados sob a forma de arquivos.

Um Sistema de Arquivos, ou ficheiros, Distribuído (SAD), é um sistema de arquivos no qual os arquivos nele armazenados estão espalhados em hardwares diferentes, interconectados através de uma rede. Eles tem vários aspectos semelhantes aos dos sistemas de arquivos centralizados, além de operações de manipulação de arquivos, preocupações com redundância, consistência, dentre outros atributos desejados de um sistema de arquivos.

Com fins de simplificação, considere no artigo o cliente como qualquer pessoa ou aplicação que faça uso dos arquivos que estão armazenados em um SAD.

Requisitos de um SAD[editar | editar código-fonte]

Os requisitos para um SAD, são[1] :

Transparência[editar | editar código-fonte]

Transparência, nesse caso, é um conceito relativo a tornar menos perceptível alguns detalhes do que se trata. O SAD deve prover transparência nos seguintes contextos:

  • De acesso: Oculta diferenças na representação de dados e no modo de acesso a um recurso.
  • De localização: Oculta o lugar em que um recurso está localizado.
  • De migração: Oculta que um recurso pode ser movido para outra localização.
  • De realocação: Oculta que um recurso pode ser movido para uma outra localização enquanto em uso.
  • De replicação: Oculta que um recurso é replicado.
  • De concorrência: Oculta que um recurso pode ser compartilhado por diversos usuários concorrentes.
  • De falha: Oculta a falha e a recuperação de um recurso.

Modificações concorrentes de arquivos[editar | editar código-fonte]

Como o nome fala por si mesmo, alterações feitas por um cliente não devem interferir nas operações de outros clientes, mesmo que esses clientes estejam manipulando o mesmo arquivo.

Replicação de arquivos[editar | editar código-fonte]

O SAD deve manter cópias atualizadas dos arquivos em diferentes locais. Essa medida traz algumas benesses como balanceamento de carga, pois mais servidores podem atender a uma determinada requisição, melhora a escalabilidade e tolerância a falhas, pois se caso algum arquivo falhar, ele pode ser requisitado a algum outro servidor que o tenha, retornando a um estado consistente, sem que os clientes tenham conhecimento.

Heterogeneidade[editar | editar código-fonte]

O SAD deve ser concebido levando em conta a heterogeneidade de plataformas ( sistemas operacionais, arquiteturas de processador, dentre outros fatores), que podem ser usadas, tanto do lado dos servidores como dos clientes.

Tolerância a Falhas[editar | editar código-fonte]

O serviço deve continuar executando mesmo com falhas parciais.

Consistência[editar | editar código-fonte]

Só deve haver uma versão disponível de cada arquivo no SAD, ou seja, se algum cliente ler um arquivo X em um momento, e outro cliente ler o mesmo arquivo X em outro momento e/ou outro lugar, se X não foi modificado, ambos os clientes devem visualizar exatamente o mesmo conteúdo.

Proteção[editar | editar código-fonte]

O SAD deve ter preocupação com permissão (a pessoa que está acessando o arquivo pode fazê-lo?), autenticação (essa pessoa é realmente ela?), privacidade (dados secretos podem ser vistos por outras pessoas?) e integridade (esse dado arquivo foi danificado no transporte?).

Eficiência[editar | editar código-fonte]

O SAD deve fazer todas as atividades listadas nos requisitos acima com um desempenho comparável a, ou melhor que, um sistema de arquivos centralizado, de modo que, mesmo se a carga nos servidores varie constantemente, o funcionamento de aplicações clientes do SAD não sejam muito penalizadas.

A provisão dos serviços oferecidos pelos sistemas de arquivos distribuídos é feita pelo serviço de arquivo e pelo serviço de diretório, que serão abordados a seguir.

Serviço de arquivo[editar | editar código-fonte]

O serviço d arquivo é responsável por expor a interface de manipulação dos arquivos, em outras palavras, é a definição dos serviços providos pelo SAD no tocante a manipulação dos arquivos como leitura, escrita e alteração do conteúdo e alguns atributos do arquivo. Esses atributos do arquivo pode ser algo como o dono, tamanho, data de criação, permissões, dentre outros.

Quando o cliente está manipulando um determinado arquivo, o mesmo pode estar completamente copiado e disponível ou qualquer operação será feita via rede. A essas duas abordagens de construção do serviço de arquivo dá-se o nome de cópia remota e acesso remoto respectivamente[2] .

Quando a manipulação é feita completamente remota, ou seja sem que nenhuma parte do arquivo seja copiada, o gerenciamento de versões do arquivo é menos complexo, pois toda alteração é feita diretamente no arquivo. A cópia remota será tratada em uma seção posterior, sob o nome de cache.

Serviço de diretório[editar | editar código-fonte]

O serviço de diretório, por sua vez, é responsável por informar quais as operações para manipulação de diretórios, ou seja, é a definição dos serviços providos pelo SAD no que concerne a criação e remoção de diretórios, movimentação de arquivos de um diretório para outro, nomear e renomear arquivos. Além disso este serviço também precisa manter uma lista com todos os diretórios ativos, seus respectivos arquivos e ainda dos diretórios que eventualmente forem apagados[2] , remover os arquivos filhos deste que fora apagado, se o cliente tiver a devida permissão.

Além das operações naturais dos diretórios, o serviço de diretório auxilia o serviço de arquivos a desempenhar algumas de suas atividades como listar os arquivos de algum diretório, efetuar buscas por determinados arquivos.

Como conseguimos encontrar um arquivo no sistema de arquivos de um computador doméstico onde o sistema de arquivos é centralizado? Cada arquivo possui um path, do inglês caminho[3] , ou localização no referido sistema de arquivos. Como fazer com um sistema de arquivos distribuído se os todos arquivos de um diretório podem não estar no mesmo computador dele? Para esse problema existe o serviço de resolução de nomes.

Serviço de resolução de nomes[editar | editar código-fonte]

É uma parte bem complexa de um SAD pois precisa descobrir, em tempo útil, a localização dos arquivos solicitados. Cada arquivo deve ter seu nome mapeado para o servidor que o armazena, de modo que as aplicações consigam identificar unicamente os arquivos [4] . Existem três formas básicas de implementar a nomeação de arquivos e de diretórios[5] :

  1. máquina + caminho_do_arquivo, ex. maquina/caminho/do/arquivo ou maquina:caminho/do/arquivo
  2. montar pedaços do sistema de arquivos remoto na hierarquia local de arquivos;
  3. um único espaço de nomes, ou seja, o mesmo espaço de nomes em todas as máquinas.

As técnicas 1 e 2 são especialmente usadas para distribuir um conjunto de sistemas de arquivos que inicialmente não foram concebidos para serem distribuídos. Já a terceira técnica é a desejada de um SAD, pois provê a transparência suficiente para que quem o use, sinta como se estivesse acessando um sistema de arquivos local.

Para não gerar tráfego demasiado na rede com muita informação de controle, ferindo o requisito de eficiência definido , pode-se usar o mecanismo de cache, tanto nos servidores do SAD quanto no cliente.

Cache[editar | editar código-fonte]

Como o sistema está em uma rede local, o tráfego excessivo é indesejado. Para diminuir essa quantidade de acessos, pode-se recorrer ao mecanismo de cache.

O cache aumenta o desempenho[5] pois reduz a quantidade de acessos aos arquivos guardados no SAD, com isso são feitas menos requisições usando a rede.

É possível manter o arquivo inteiro em cache (mais simplicidade na implementação e menos eficiência) ou manter apenas um trecho que está sendo editado (mais eficiente, porém de difícil implementação). A literatura prevê alguns modelos de atualização de arquivos da cache para o SAD, são eles:

Write through[editar | editar código-fonte]

O cliente mantém um arquivo (ou trecho) sendo utilizado e acontecendo qualquer mudança nele, a mudança é refletida de imediato nos servidores.

  • Prós: leituras subseqüentes a uma escrita estarão sempre atualizadas.
  • Contras: Ocorre um problema nesse modelo, imagine:
 * um cliente A altera um arquivo f e o tem em seu cache e o servidor mantem a versão atualizada de f. 
 * A fecha o arquivo f e ainda mantem f em cache.
 * outro cliente, adote B, abre o arquivo f, o modifica e o fecha e o servidor está com a última versão editada por B.
 * se A abrir f, ele verá que está em seu cache, portanto não o requisitará ao SAD e com isso terá uma versão não atualizada.

Delayed write[editar | editar código-fonte]

Uma melhoria ao modelo anterior. Melhoria no sentido de as escritas não serem a cada modificação, mas sim havendo alguma modificação e considerando algum intervalo de tempo, as alterações são enviadas ao SAD. E melhoria também no momento que um cliente abre um dado arquivo que está em cache. É verificado se esse arquivo está atualizado com o arquivo no SAD, se não estiver, o mesmo é atualizado e enfim o mesmo é aberto.

  • Prós: versões de arquivos em cache são verificadas de modo a não haver inconsistência.
  • Contras: leituras feitas depois de uma escrita, não estarão garantidamente atualizadas, pois o tempo de atualização pode ainda não ter passado.

Write on close[editar | editar código-fonte]

Todas as alterações são submetidas sempre quando o arquivo é fechado.

  • Prós: reduz bastante a quantidade de atualizações no SAD.
  • Contras: problemas de edição simultânea, pois quem fechar o arquivo por último é que terá sua versão persistida.

Centralize control[editar | editar código-fonte]

Centraliza o controle de acesso aos arquivos no servidor, de modo que ele enfileira as requisições de leitura e escrita de modo a: - Se algum acesso ao arquivo for feito apenas para leitura, nenhuma precaução precisa ser tomada - Se um arquivo é aberto para escrita, o servidor não permite que outro cliente abra o mesmo arquivo para escrita.

  • Prós: facilidade em bloquear uma escrita indevida.
  • Contras: não é elegante, pois o servidor que é proativo e não o cliente e ainda necessita de verificação de cache no momento de um novo acesso.

Após a exposição desses conceitos e detalhes acerca dos SAD, a seguir serão expostos alguns exemplos mais famosos de SAD.

Exemplos de Sistemas de Arquivos Distribuídos[editar | editar código-fonte]

SUN Network File System[editar | editar código-fonte]

O SUN Network File System é um sistema de arquivos distribuído no qual clientes acessam os arquivos armazenados em apenas um servidor. Criado em 1984, sofreu algumas modificações e no ano seguinte a SUN Microsystems o tornou público[2] , assim sendo possível encontrar atualmente implementações do NFS para quase todos os sistemas operacionais.

Como o NFS é stateless, ou seja, não mantém nenhum estado de qualquer requisição feita a eles, não corre risco de haver perda de informações em caso de queda do servidor, mas por esse mesmo motivo, não consegue lidar com acesso concorrente, entregando a cada cliente uma cópia do mesmo arquivo.

A equipe de desenvolvimento do NFS tinha em mente os seguintes objetivos para seu sistema de arquivos[6] :

  • Funcionar em diversas plataformas de hardware e de software;
  • Tanto o cliente quanto o servidor serem capazes de se recuperar rapidamente de crashes;
  • Acesso transparente, de modo que as aplicações-cliente não necessitem ser modificadas para acessar tais arquivos;
  • Manter a mesma semântica do sistema de arquivos do UNIX, de modo que a transparência seja maior ainda em máquinas UNIX;
  • Cumprir todos esses objetivos e ainda manter um desempenho aceitável, comparável a um sistema de arquivos SCSI local.

Algumas decisões foram tomadas para a implementação do NFS[6] . Dentre elas veremos algumas a diante.

Sistema de nomes[editar | editar código-fonte]

No NFS se pode montar um pedaço do sistema de arquivos distribuído em algum diretório do sistema de arquivos local do cliente, de modo que a nomenclatura dos diretórios provenientes do NFS segue o mesmo padrão do sistema de arquivos local. Portanto o NFS provê transparência no acesso, pois se o servidor onde os dados se encontram mudar de lugar, o cliente não precisa saber dessa mudança para continuar a usar o NFS.

Segurança[editar | editar código-fonte]

O NFS usa o mesmo esquema de conceder e verificar permissões do UNIX.

Acesso concorrente[editar | editar código-fonte]

O NFS não dá suporte a acesso concorrente e lock de arquivos, portanto a alteração do mesmo arquivo poderá implicar em resultados indesejáveis.

Semântica[editar | editar código-fonte]

Foi implementada a semântica UNIX para o tratamento dos arquivos. Nela, por exemplo, é permitido que um arquivo possa ser excluído enquanto alguma aplicação o utiliza. Outra particularidade dessa semântica é de que a permissão de um arquivo pode ser alterada enquanto o mesmo está aberto. Se essa alteração for feita no arquivo remoto, ela sempre será checada, caso contrário não.

Com todas essas funcionalidades, o NFS ainda funciona com eficiência, e como indício disso, continua sendo largamente usando ainda hoje.

Andrew File System[editar | editar código-fonte]

O Andrew File System ou AFS surgiu na Universidade Carnegie Mellon com o intuito de prover compartilhamento de arquivos entre os, pelo menos, 7 mil estudantes, professores e funcionários da referida universidade[7] , além de tentar avançar o estado da arte em computação distribuída.

Antes de tudo, como todos na universidade de Carnegie Melo usavam UNIX, a primeira decisão de projeto sobre o AFS foi que ele deveria ser completamente compatível com o UNIX, no nível das chamadas ao sistema operacional.

Outra decisão foi de que a unidade básica de tráfego do sistema foi o arquivo inteiro; isso sem dúvida é o aspecto mais controverso e interessante do AFS[7] .

A integridade do cache é implementado usando o princípio de callback. Quando um arquivo é aberto, é posto em cache no sistema de arquivos local e o servidor guarda essa informação. Sempre que algum outro cliente alterar o mesmo arquivo, ele é avisado via callback de que o arquivo foi alterado. Toda alteração é checada através desse callback.

Dentre as funcionalidades do AFS, podemos citar[7] :

Autenticação[editar | editar código-fonte]

O cliente se autentica usando suas informações de conta de usuário UNIX.

Access Control List[editar | editar código-fonte]

As Acess Control List ou ACL são implementadas de modo a restringir o acesso indevido aos arquivos armazenados no AFS. Elas são:

  • Leitura de arquivos
  • Escrita (Atualização) em arquivos
  • Inserção (Criação) de arquivos
  • Deleção de arquivos
  • Pesquisa nos arquivos
  • Bloquear arquivos
  • Gerenciar diretórios (mudar ACL)

O AFS é atualmente[quando?] distribuído com o Linux, mas ainda em versão experimental.

Referências

  1. a b COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Distributed Systems: Concepts and Design. Addison-Wesley, 3rd edition, 2003.
  2. a b c CARVALHO, Roberto Pires de; Sistemas de arquivos Distribuidos. Monografia disponível em: http://www.ime.usp.br/~carvalho/monografia-sad
  3. http://www1.uol.com.br/babylon/
  4. FARLEY, Marc. Storage Networking Fundamentals: An Introduction to Storage Devices, Subsystems, Applications, Management and Filing Systems. CISCO Press, 2004.
  5. a b TANENBAUM, Andrew S. Distributed Operating Systems. Prentice Hall, 1994.
  6. a b Sandberg, Russel; The Sun Network Filesystem: Design, Implementation and Experience.
  7. a b c HOWARD, John H; An Overview of the Andrew File System. Carnegie Melon University, 1988.