Saltar para o conteúdo

Sistema de arquivos distribuídos

Origem: Wikipédia, a enciclopédia livre.

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.

Conceitos básicos

[editar | editar código-fonte]

Não podemos iniciar nenhuma discussão sobre sistemas de arquivos distribuídos sem definir alguns conceitos fundamentais.[2]

Um serviço é um conjunto de facilidades oferecidas aos nós de uma rede por um software que opera em uma ou mais máquinas.

Um servidor é o software que opera em uma determinada máquina e que trata de oferecer o serviço. Chamaremos, também, de servidor a máquina que executa esse software.

O cliente é o software que utiliza o serviço do servidor. Também chamaremos de cliente a máquina que executa o software cliente.

Um sistema de Arquivos é uma parte de um sistema Operacional que trata de oferecer um repositório de dados de longa duração.

Um Sistema de Arquivos Distribuído é um Sistema de Arquivos onde vários servidores são responsáveis por oferecer o serviço de arquivos para vários clientes instalados em diferentes máquinas.

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, consiste em promover acesso a recursos distribuídos de forma oculta, como se fosse um único sistema para o usuário. Considerando os SAD’s, de acordo com Coulouris, Dollimore e Kindberg (2005)[3] e  Tanenbaum e Steen (2007)[4] ela pode ser dividida em transparecias:

  • De acesso: não necessita fornecer a localização dos recursos, ou seja, os programas devem executar os processos de leitura e escrita de arquivos remotos da mesma maneira que operam sobre os arquivos locais, sem qualquer modificação no programa. O usuário não deve perceber se o recurso acessado é local ou remoto.
  • De localização: os programas clientes devem ver um espaço de nomes de arquivos uniforme, sem a necessidade de fornecer a localização física dos arquivos para encontrá-los, mesmo que esses arquivos se desloquem entre os servidores.
  • De mobilidade: independente dos arquivos se moverem entre servidores, os programas clientes não precisam ser alterados para a nova localidade do grupo de arquivos. Essa característica permite flexibilidade em mover arquivos sem comprometer toda a estrutura, ou ter que refazer links entre programas clientes e o local do arquivo.
  • De desempenho: o desempenho da aplicação cliente não poderá ser comprometido enquanto ocorre uma variação dos processos sobre os recursos disponíveis pelos SAD's, isto é, mesmo que haja concorrência no acesso pelos arquivos isso não deve afetar os usuários.
  • De escalabilidade: os recursos computacionais podem sofrer alterações para abrigar maior poder computacional ou o ingresso de novos servidores sem prejudicar o serviço.
  • Contra falhas: garantir a disponibilidade dos arquivos ininterruptamente e se ocorrerem falhas o programa cliente não deverá saber como elas serão tratadas.
  • De replicação: várias cópias dos mesmos arquivos armazenados em locais diferentes para garantir a disponibilidade. A aplicação cliente deverá visualizar apenas uma cópia do mesmo, não necessitando saber a quantidade replicada e o local.[5]

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.

Quando diversos processos acessam os mesmos dados simultaneamente, é preciso tomar cuidado para que esses processos recebam informações corretas e também para que a consistência do sistema de arquivos não seja afetada.[6]

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.

Umas rede Heterogênea, isto é, que possui nós de diferentes tipos, pode ser vantajosa na medida em que cada tipo de tarefa pode ser executada em uma máquina apropriada.[6]

Tolerância a Falhas

[editar | editar código-fonte]

O serviço deve continuar executando mesmo com falhas parciais.Tanto os clientes quanto os servidores de arquivos podem sofrer quedas e romperem a comunicação com os outros nós da rede por intervalos que podem variar entre segundos e até horas. O sistema deve evitar , sempre que possível, que falhas como esta causem uma depreciação muito grande no tempo de resposta aos clientes ou que o serviço seja interrompido.[6]

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.

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?).

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 de 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.[7]

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,[7] 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,[8] ou localização no referido sistema de arquivos. Como fazer com um sistema de arquivos distribuído se todos os 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.[9] Existem três formas básicas de implementar a nomeação de arquivos e de diretórios[10]:

  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.

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[10] 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,[7] 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[11]:

  • 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.[11] 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.

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.

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,[12] 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.[12]

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[12]:

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. KON, Fabio. Sistemas de Arquivos Distribuídos. 1994. Dissertação (Mestrado em Matemática Aplicada) - Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, 1994. doi:10.11606/D.45.1994.tde-23052012-180225. Acesso em: 2018-06-11.
  3. Coulouris, George; Dollimore, Jean; Kindberg, Tim (2005). Distributed systems: concepts and design. [S.l.]: Addison-Wesley 
  4. Tanenbaum, Andrew S. (2007). Distributed systems: principles and paradigms. [S.l.]: Pearson Prentice Hall 
  5. Fernandes, Silas E. Nachif. «Sistemas de Arquivos Distribuídos Flexível e Adaptável» (PDF). Departamento de Ciências de Computação e Estatística do Instituto de Biociências, Letras e Ciências Exatas da Universidade Estadual Paulista " Júlio de Mesquita Filho". Consultado em 11 de junho de 2018 
  6. a b c Kon, Fabio (8 de novembro de 1994). «Sistemas de Arquivos Distribuídos». doi:10.11606/D.45.1994.tde-23052012-180225 
  7. a b c CARVALHO, Roberto Pires de; Sistemas de arquivos Distribuidos. Monografia disponível em: http://www.ime.usp.br/~carvalho/monografia-sad
  8. http://www1.uol.com.br/babylon/
  9. FARLEY, Marc. Storage Networking Fundamentals: An Introduction to Storage Devices, Subsystems, Applications, Management and Filing Systems. CISCO Press, 2004.
  10. a b TANENBAUM, Andrew S. Distributed Operating Systems. Prentice Hall, 1994.
  11. a b Sandberg, Russel; The Sun Network Filesystem: Design, Implementation and Experience.
  12. a b c HOWARD, John H; An Overview of the Andrew File System. Carnegie Melon University, 1988.