Um sistema de arquivos de rede é uma abstração em rede de um sistema de arquivos que permite que um cliente remoto o acesse pela rede de uma forma semelhante a um sistema de arquivos local. Embora não tenha sido o primeiro desse tipo de sistema, o NFS cresceu e evoluiu para o sistema de arquivos de rede mais poderoso e mais amplamente usado em UNIX®. O NFS permite o compartilhamento de um sistema de arquivos comum entre uma infinidade de usuários e oferece o benefício de centralização de dados para minimizar o armazenamento necessário.

Este artigo inicia com uma história breve do NFS, suas origens e como ele evoluiu. Depois explora a arquitetura do NFS e para onde o NFS está caminhando.

Uma história breve do NFS

O primeiro sistema de arquivos de rede—chamado File Access Listener—foi desenvolvido em 1976 pela Digital Equipment Corporation (DEC). Era uma implementação do Data Access Protocol (DAP), e fazia parte do conjunto de protocolos DECnet. Assim como o TCP/IP, a DEC publicou especificações de protocolo para seus protocolos de rede, que incluem o DAP.

O NFS foi o primeiro sistema de arquivos de rede moderno (construído sobre o protocolo IP). Ele começou como um sistema de arquivos experimental desenvolvido internamente na Sun Microsystems no início de 1980. Dada a popularidade da abordagem, o protocolo do NFS foi documentado como uma especificação de Pedido de Comentário (RFC) e evoluiu para o conhecido NFSv2. Como um padrão, o NFS cresceu rapidamente devido à sua capacidade de interoperar com outros clientes e servidores.

O padrão continuou a evoluir para o NFSv3, definido pela RFC 1813. Essa iteração do protocolo era muito mais escalável que as versões anteriores, suportando arquivos grandes (maiores que 2 GB), gravações assíncronas, e TCP como protocolo de transporte, abrindo caminho para os sistemas de arquivos de rede de longa distância. Em 2000, a RFC 3010 (revisada pela RFC 3530) trouxe o NFS para o ambiente corporativo. A Sun apresentou o NFSv4, com muita segurança, junto com um protocolo stateful (as versões anteriores do NFS eram stateless). Hoje, o NFS está na versão 4.1 (como definido pela RFC 5661), que adiciona suporte de protocolo para acesso paralelo por servidores distribuídos (chamado de extensão pNFS).

A linha do tempo do NFS, incluindo as RFCs específicas que documentam seu comportamento, podem ser vistas na figura 1.

De forma surpreendente, o NFS está em desenvolvimento há quase 30 anos. Ele representa um sistema de arquivos em rede extremamente estável (e móvel), que é escalável, possui alto desempenho e qualidade corporativa. À medida que as velocidades de rede aumentam e as latências diminuem, o NFS continua a ser uma opção atraente para fornecer um sistema de arquivos em uma rede. Mesmo em ambientes de rede locais, a virtualização leva o armazenamento para a rede para suportar mais máquinas virtuais remotas. O NFS suporta até os modelos computacionais mais recentes para otimizar as infraestruturas virtualizadas.

Voltar para parte superior

A arquitetura do NFS

O NFS segue o modelo computacional cliente/servidor (consulte a figura 2). O servidor implementa o sistema de arquivos e o armazenamento compartilhados aos quais os clientes se conectam. Os clientes implementam a interface com o usuário para o sistema de arquivo compartilhado, disposto no espaço no arquivo do cliente.

No Linux®, o comutador do sistema de arquivo virtual (VFS) fornece os meios para suportar vários sistemas de arquivos simultaneamente em um host (como International Organization for Standardization [ISO] 9660 em um CD-ROM e ext3fs no disco rígido local). O VFS determina para qual armazenamento uma solicitação é destinada e qual sistema de arquivos deve ser usado para satisfazer a solicitação. Por esse motivo, o NFS é um sistema de arquivos conectável como qualquer outro. A única diferença com o NFS é que as solicitações de entrada/de saída (E/S) podem não ser atendidas localmente, tendo, em vez disso, que atravessar a rede para sua conclusão.

Quando se sabe que a solicitação é destinada para o NFS, o VFS a passa para a instância do NFS no kernel. O NFS interpreta a solicitação de E/S e a converte para um procedimento do NFS (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE, e assim por diante). Esses procedimentos, que estão documentados na RFC do NFS em particular, especificam os comportamentos no protocolo do NFS. Quando um procedimento é selecionado de uma solicitação de E/S, ele é realizado na camada de chamada de procedimento remoto (RPC). Como o nome sugere, a RPC fornece os meios para a realização de chamadas de procedimentos entre sistemas. Ele serializa a solicitação do NFS e acompanha os argumentos ao mesmo tempo, gerencia seu envio para o peer remoto apropriado e depois gerencia e controla a resposta, fornecendo-a para o solicitante apropriado.

Além disso, a RPC inclui uma camada de interoperabilidade importante chamada de external data representation (XDR), que assegura que todos os participantes do NFS se comuniquem com facilidade ao tratarem de tipos de dado. Quando uma dada arquitetura realiza uma solicitação, a representação do tipo de dado pode ser diferente do host de destino que atende à solicitação. A XDR cuida de converter os tipos para a representação comum (XDR), para que todas as arquiteturas possam interoperar e compartilhar sistemas de arquivos. A XDR especifica o formato de bit para tipos como float e a disposição dos bytes para tipos como arrays fixos e de comprimento variável. Embora a XDR seja mais conhecida por seu uso no NFS, ela é uma especificação útil sempre que estiver lidando com várias arquiteturas em um ambiente de aplicativo comum.

Quando a XDR tiver convertido os dados para a representação comum, a solicitação é transferida pela rede, fornecendo um protocolo de camada de transporte. Os NFS mais antigos usavam o Universal Datagram Protocol (UDP), mas atualmente o TCP é o mais comumente usado para uma maior confiabilidade.

No servidor, o NFS opera de forma semelhante. A solicitação flui pela pilha de rede, através de RPC/XDR (para converter os tipos de dado para a arquitetura do servidor), e para o servidor do NFS. O servidor do NFS é responsável por atender à solicitação. A solicitação é passada para o daemon do NFS, que identifica a árvore do sistema de arquivos de destino necessária para a solicitação, e o VFS é usado novamente para obter o sistema de arquivos no armazenamento local. Todo esse processo é mostrado na figura 3. Observe que o sistema de arquivos local no servidor é um típico sistema de arquivos Linux (como ext4fs). Assim sendo, o NFS não é um sistema de arquivos no sentido tradicional, mas um protocolo para acessar sistemas de arquivos remotamente.

Para rede de maior latência, o NFSv4 implementa aquilo que é chamado de procedimento composto. Esse procedimento permite essencialmente que várias chamadas RPC sejam incorporadas a uma solicitação única para minimizar a taxa de transferência da solicitação pela rede. Ele também implementa um esquema de retorno de chamada para respostas.

Voltar para parte superior

O protocolo do NFS

Da perspectiva do cliente, a primeira operação que deve ocorrer no NFS é chamada de montagem. A montagem representa a montagem de um sistema de arquivos remoto em um espaço de sistema de arquivos local. Esse processo começa como uma chamada de montagem (uma chamada do sistema Linux), que é encaminhada através do VFS para o componente do NFS. Depois de estabelecer o número da porta para a montagem (através da chamada RPC de solicitação get_port para o servidor remoto), o cliente realiza uma solicitação RPC de montagem . Essa solicitação ocorre entre o cliente e um daemon especial responsável pelo protocolo de montagem (rpc.mountd). Esse daemon verifica a solicitação do cliente em relação à lista do servidor de sistemas de arquivos exportados atualmente; se o sistema solicitado de arquivos existir e o cliente tiver acesso, uma resposta de montagem estabelece o identificador de arquivos para o sistema de arquivos. O lado do cliente armazena informações remotas de montagem com o ponto de montagem local e estabelece a capacidade de realizar solicitações de E/S. Esse protocolo representa um problema de segurança potencial; portanto, o NFSv4 substitui esse protocolo de montagem auxiliar com chamadas RPC internas para gerenciar o ponto de montagem.

Para ler um arquivo, o arquivo precisa primeiro ser aberto. Não há um procedimento OPEN na RPC; em vez disso, o cliente simplesmente verifica se o diretório e o arquivo existem no sistema de arquivos montado. O cliente começa com uma solicitação RPC GETATTR para o diretório, o que resulta em uma resposta com os atributos do diretório ou uma indicação de que o diretório não existe. Em seguida, o cliente emite uma solicitação RPC LOOKUP para ver se o arquivo solicitado existe. Se sim, uma solicitação RPC GETATTR é emitida para o arquivo solicitado, que retorna os atributos do arquivo. Com base em GETATTRs e LOOKUPs bem-sucedidas, o cliente cria um identificador de arquivos que é fornecido ao usuário para solicitações futuras.

Com o arquivo identificado no sistema de arquivos remoto, o cliente pode emitir solicitações RPC READ . A READ consiste em identificador de arquivos, estado, distância e contagem para o leitor. O cliente usa o estado para determinar se a operação pode ser realizada (ou seja, se o arquivo está bloqueado). A distância indica onde começar a ler, e a contagem identifica o número de bytes a serem lidos. O servidor pode ou não retornar o número de bytes solicitados, mas identifica o número de bytes retornados (junto com os dados) na resposta RPC READ .

Voltar para parte superior

Inovação no NFS

As últimas duas versões do (4 e 4.1) estão entre as mais interessantes e importantes para o NFS. Vamos dar uma olhada nos aspectos mais importantes da evolução do NFS.

Antes do NFSv4, havia uma série de protocolos auxiliares para montagem, bloqueios e outros elementos no gerenciamento de arquivos. O NFSv4 simplifica esse processo para um protocolo e remove o suporte para UDP como protocolo de transporte. O NFSv4 também integra suporte para semânticas de acesso de arquivos baseados em UNIX e Windows®, estendendo o NFS para integração nativa em outros sistemas operacionais.

O NFSv4.1 apresenta o conceito de NFS paralelo (pNFS) para maior escala e melhor desempenho. Para suportar uma escala maior, o NFSv4.1 implementa uma arquitetura de dados/metadados dividida com striping, de maneira semelhante aos sistemas de arquivos em cluster. Conforme mostrado na figura 4, o pNFS quebra o ecossistema em três partes: o cliente, o servidor e o armazenamento. Você verá que há dois caminhos: um para os dados e outro para controle. O pNFS divide o layout dos dados a partir dos próprios dados, permitindo a arquitetura de dois caminhos. Quando um cliente quer acessar um arquivo, o servidor responde com o layout. O layout descreve o mapeamento do arquivo para dispositivos de armazenamento. Quando o cliente possui o layout, ele pode acessar diretamente o armazenamento sem ter de trabalhar através do servidor (que permite maior escala e desempenho). Quando o cliente concluir com o arquivo, ele confirma os dados (mudanças) e o layout. Se necessário, o servidor pode solicitar o layout de volta do cliente.

O pNFS implementa uma série de operações de novo protocolo para suportar esse comportamento. LayoutGet e LayoutReturn obtêm e liberam o layout do servidor, respectivamente, enquanto LayoutCommit confirma os dados do cliente para o armazenamento, de modo que fique disponível para outros usuários. O servidor chama o layout novamente de um cliente que esteja usando LayoutRecall. O layout é espalhado por certo número de dispositivos de armazenamento para ativar o acesso paralelo e maior desempenho.

Tanto os dados quanto os metadados são armazenados na área de armazenamento. O cliente pode realizar E/S direta dado o recebimento do layout, e o servidor do NFSv4.1 trata do gerenciamento e armazenamento de metadados. Embora esse comportamento não seja necessariamente novo, o pNFS adiciona a capacidade de suportar vários métodos de acesso ao armazenamento. Hoje, o pNFS suporta o uso de protocolos baseados em bloco (Fibre Channel), protocolos baseados em objetos e o próprio NFS (mesmo em uma forma que não seja pNFS).

O trabalho no NFS continua, com os requisitos para o NFSv2 tendo sido publicados em setembro de 2010. Alguns dos novos avanços abordam o mundo em transformação do armazenamento em ambientes de virtualização. Por exemplo, a duplicação de dados é muito provável em ambientes de hypervisor (muitos sistemas operacionais de leitura e gravação e armazenamento em cache dos mesmos dados). Por esse motivo, é desejável para o sistema de armazenamento como um todo entender onde a duplicação ocorre. Isso preservaria o espaço em cache e a capacidade no final do armazenamento. O NFSv4.2 propõe um mapa em bloco de blocos compartilhados para lidar com esse problema. Como os sistemas de armazenamento começaram a integrar capacidades de processamento no backend, a cópia do lado do servidor é introduzida para transferir a rede de armazenamento interior de cópia de dados quando ela pode ser feita de modo eficiente no próprio backend de armazenamento. Outras inovações estão aparecendo, incluindo armazenamento em cache de subarquivos para memória flash e sugestões para o lado do cliente para E/S (usando potencialmente mapadvise como caminho).

Voltar para parte superior

Alternativas ao NFS

Embora o NFS seja o sistema de arquivos de rede mais popular nos sistemas UNIX e Linux, certamente ele não é a única escolha. Nos sistemas Windows® , o bloco de mensagens do servidor [SMB], também conhecido como CIFS) é a opção mais usada (embora o Windows também suporte NFS, assim como o Linux suporta SMB).

Um dos sistemas de arquivos distribuído mais recentes, que também é suportado no Linux, é o Ceph. O Ceph foi elaborado a partir do zero como sistema de arquivos distribuído tolerante a falhas com compatibilidade com a Interface de Sistema Operacional Portátil para UNIX (POSIX). É possível aprender mais sobre o Ceph em Recursos .

Outros exemplos incluem OpenAFS, uma versão de software livre do sistema de arquivos distribuído Andrew (da Carnegie Mellon e IBM), GlusterFS, que foca um sistema de arquivos distribuído para fins gerais para armazenamento escalável, e Lustre, que é um sistema de arquivos distribuído paralelo de forma maciça que foca computação em cluster. Todas são soluções de software livre para armazenamento distribuído.

Voltar para parte superior

Um pouco além

O NFS continua a evoluir, e, semelhante à evolução do Linux (suportando desempenho de pequena escala, integrado e de alta escala), o NFS implementa uma solução de armazenamento escalável para consumidores e empresas. Será interessante acompanhar o que está por vir em relação ao NFS, mas dado seu histórico e um peek no curto prazo, ele mudará o modo como visualizamos e usamos o armazenamento de arquivos.

Recursos

Aprender

• O NFS é uma especificação padrão para um sistema de arquivos de rede que seja móvel e multiplataforma. Ele está documentado em uma série de especificações, incluindo a primeira especificação padrão NFSv2, NFSv3, NFSv4, e a mais recente, NFSv4.1. É possível saber mais sobre o futuro do NFS no documento de requisitos do NFSv4.2.
  
  
• Yet Another NFS (YANFS) é um projeto da Sun, anteriormente chamado de WebNFS. O YANFS é uma implementação Java™ de NFSv3 e RPC/XDR para permitir acesso ao NFS a partir de aplicativos Java.
  
  
• XDR é uma codificação padronizada para dados que permite que hosts de arquiteturas diferentes se comuniquem por uma rede usando tipos de dado comuns.
  
  
• O Linux suporta uma grande variedade de sistemas de arquivos em um grande número de mídias de armazenamento. O Linux torna isso possível através da integração de muitos sistemas de arquivos, dos drivers para vários tipos de hardware de armazenamento e do VFS. É possível aprender mais sobre o VFS em "Anatomia do Sistema de Arquivos do Linux" (developerWorks, outubro de 2007).
  
  
• O NFS certamente não é a única maneira de construir sistemas de armazenamento em rede. Outros exemplos incluem OpenAFS, GlusterFS, Lustree Ceph. É possível aprender mais sobre o Ceph em Ceph: Um sistema de arquivos distribuído Linux de escala petabyte" (developerWorks, maio de 2010).
  
  
• Na zona Linux do developerWorks, você encontrará muitos artigos e tutoriais de instruções, bem como downloads, fóruns de discussão e muitos outros recursos para desenvolvedores e administradores Linux.
  
  
• Fique por dentro dos eventos técnicos e webcasts do developerWorks sobre uma série de produtos IBM e tópicos do segmento de mercado de TI.
  
  
• Participe de um briefing ao vivo e gratuito developerWorks para se atualizar rapidamente sobre produtos e ferramentas IBM, bem como tendências do segmento de mercado de TI.
  
  
• Assista demos on demand no developerWorks que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.
  
  
• Siga o o developerWorks no Twitter ou inscreva-se para receber tweets sobre o Linux no developerWorks.
  
  

Obter produtos e tecnologias

• Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox aprendendo a implementar a Arquitetura Orientada a Serviços de modo eficiente.
  
  

Discutir

• Participe da comunidade do My developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  

Sobre o autor

M. Tim Jones é arquiteto de firmware integrado e autor de Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming (atualmente em sua segunda edição), AI Application Programming (em sua segunda edição) e BSD Sockets Programming from a Multilanguage Perspective. Seu conhecimento em engenharia varia do desenvolvimento de kernels para naves espaciais geossincrônicas até a arquitetura de sistemas embarcados e o desenvolvimento de protocolos de rede. Tim é arquiteto senior da Emulex Corp. em Longmont, Colorado.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Uma história breve do NFS
• A arquitetura do NFS
• O protocolo do NFS
• Inovação no NFS
• Alternativas ao NFS
• Um pouco além
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais