Sistemas de arquivos de rede e Linux

NFS: Útil como sempre e ainda em evolução

O Network File System (NFS) está sendo usado desde 1984, mas continua a evoluir e a fornecer a base para sistemas de arquivos distribuídos. Hoje, o NFS (através da extensão pNFS) fornece acesso escalável a arquivos distribuídos pela rede. Explore as ideias por trás dos sistemas de arquivos distribuídos e, em particular, os avanços recentes no NFS.

M. Tim Jones, Independent author, .

author photo - M. Tim JonesM. 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.



21/Dez/2010

Entre em contato com o Tim

Tim é um dos nossos autores mais populares e prolíficos. Navegue em todos os artigos do Tim no developerWorks. Confira o perfil dele e entre em contato com ele e com outros autores e leitores no My developerWorks.

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.

Figura 1. Linha do tempo dos protocolos do NFS
Timeline of NFS protocols

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.


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.

Figura 2. A arquitetura cliente/servidor do NFS
The client-server architecture of NFS

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.

Figura 3. A pilha de cliente e servidor do NFS
The client and server NFS stack

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.


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 .


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.

Figura 4. Arquitetura do pNFS do NFSv4.1
NFSv4.1's pNFS architecture

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


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.


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

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.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux
ArticleID=604420
ArticleTitle=Sistemas de arquivos de rede e Linux
publish-date=12212010