Sistema de arquivos de rede - Network File System

O Network File System ( NFS ) é um protocolo de sistema de arquivos distribuído originalmente desenvolvido pela Sun Microsystems (Sun) em 1984, permitindo que um usuário em um computador cliente acesse arquivos em uma rede de computadores da mesma forma que o armazenamento local é acessado. O NFS, como muitos outros protocolos, baseia-se no sistema Open Network Computing Remote Procedure Call (ONC RPC). NFS é um padrão IETF aberto definido em um Request for Comments (RFC), permitindo que qualquer pessoa implemente o protocolo.

Versões e variações

A Sun usou a versão 1 apenas para fins experimentais internos. Quando a equipe de desenvolvimento adicionou mudanças substanciais ao NFS versão 1 e o lançou fora da Sun, eles decidiram lançar a nova versão como v2, para que a interoperação da versão e o fallback da versão RPC pudessem ser testados.

NFSv2

A versão 2 do protocolo (definida na RFC 1094, março de 1989) operava originalmente apenas no User Datagram Protocol (UDP). Seus designers pretendiam manter o servidor sem estado , com bloqueio (por exemplo) implementado fora do protocolo principal. As pessoas envolvidas na criação do NFS versão 2 incluem Russel Sandberg , Bob Lyon , Bill Joy , Steve Kleiman e outros.

A interface do Virtual File System permite uma implementação modular, refletida em um protocolo simples. Em fevereiro de 1986, as implementações foram demonstradas para sistemas operacionais como System V versão 2, DOS e VAX / VMS usando Eunice . O NFSv2 só permite que os primeiros 2 GB de um arquivo sejam lidos devido às limitações de 32 bits .

NFSv3

Versão 3 (RFC 1813, junho de 1995) adicionada:

• suporte para tamanhos e deslocamentos de arquivo de 64 bits, para lidar com arquivos maiores que 2 gigabytes (GB);
• suporte para gravações assíncronas no servidor, para melhorar o desempenho de gravação;
• atributos de arquivo adicionais em muitas respostas, para evitar a necessidade de buscá-los novamente;
• uma operação READDIRPLUS, para obter identificadores de arquivo e atributos junto com nomes de arquivo ao escanear um diretório;
• diversas outras melhorias.

A primeira proposta do NFS Versão 3 dentro da Sun Microsystems foi criada não muito depois do lançamento do NFS Versão 2. A principal motivação foi uma tentativa de mitigar o problema de desempenho da operação de gravação síncrona no NFS Versão 2. Em julho de 1992, a prática de implementação havia resolvido muitas deficiências do NFS Versão 2, deixando apenas a falta de suporte a arquivos grandes (tamanhos e deslocamentos de arquivos de 64 bits) um problema urgente. Isso se tornou um ponto crítico para a Digital Equipment Corporation com a introdução de uma versão de 64 bits do Ultrix para oferecer suporte ao processador RISC de 64 bits recém-lançado , o Alpha 21064 . No momento da introdução da Versão 3, o suporte do fornecedor para TCP como um protocolo de camada de transporte começou a aumentar. Enquanto vários fornecedores já haviam adicionado suporte para NFS Versão 2 com TCP como um transporte, a Sun Microsystems adicionou suporte para TCP como um transporte para NFS ao mesmo tempo que adicionou suporte para Versão 3. Usando TCP como um transporte feito usando NFS em uma WAN mais viável e permitiu o uso de tamanhos maiores de transferência de leitura e gravação além do limite de 8 KB imposto pelo protocolo de datagrama do usuário .

NFSv4

A versão 4 (RFC 3010, dezembro de 2000; revisada na RFC 3530, abril de 2003 e novamente na RFC 7530, março de 2015), influenciada por Andrew File System (AFS) e Server Message Block (SMB, também denominado CIFS), inclui melhorias de desempenho, exige forte segurança e apresenta um protocolo com monitoração de estado . A versão 4 se tornou a primeira versão desenvolvida com a Internet Engineering Task Force (IETF) depois que a Sun Microsystems entregou o desenvolvimento dos protocolos NFS.

O NFS versão 4.1 (RFC 5661, janeiro de 2010; revisado no RFC 8881, agosto de 2020) tem como objetivo fornecer suporte de protocolo para aproveitar as implantações de servidor em cluster, incluindo a capacidade de fornecer acesso paralelo escalonável a arquivos distribuídos entre vários servidores (extensão pNFS). A versão 4.1 inclui mecanismo de entroncamento de sessão (também conhecido como NFS Multipathing) e disponível em algumas soluções corporativas como VMware ESXi .

O NFS versão 4.2 (RFC 7862) foi publicado em novembro de 2016 com novos recursos, incluindo: clone e cópia do lado do servidor, aviso de E / S do aplicativo, arquivos esparsos, reserva de espaço, bloco de dados do aplicativo (ADB), rotulado NFS com sec_label que acomoda qualquer Sistema de segurança MAC e duas novas operações para pNFS (LAYOUTERROR e LAYOUTSTATS).

Uma grande vantagem do NFSv4 sobre seus predecessores é que apenas uma porta UDP ou TCP, 2049, é usada para executar o serviço, o que simplifica o uso do protocolo em firewalls.

Outras extensões

O WebNFS , uma extensão da versão 2 e da versão 3, permite que o NFS se integre mais facilmente aos navegadores da Web e possibilite a operação por meio de firewalls. Em 2007, a Sun Microsystems abriu o código-fonte de sua implementação WebNFS do lado do cliente.

Vários protocolos de banda lateral foram associados ao NFS. Observação:

• o protocolo Network Lock Manager (NLM) consultivo de intervalo de bytes (adicionado para oferecer suporte a APIs de bloqueio de arquivo UNIX System V )
• o protocolo de relatório de cota remoto (RQUOTAD), que permite aos usuários NFS visualizar suas cotas de armazenamento de dados em servidores NFS
• NFS sobre RDMA , uma adaptação do NFS que usa acesso remoto direto à memória (RDMA) como meio de transporte
• NFS-Ganesha, um servidor NFS, rodando no espaço do usuário e suportando vários sistemas de arquivos como GPFS / Spectrum Scale, CephFS através dos respectivos módulos FSAL (File System Abstraction Layer). O CephFS FSAL com suporte usando libcephfs

• NFS confiável (TNFS)

Plataformas

O NFS é frequentemente usado com sistemas operacionais Unix (como Solaris , AIX , HP-UX ), macOS da Apple e sistemas operacionais semelhantes a Unix (como Linux e FreeBSD ). Também está disponível para sistemas operacionais como Acorn RISC OS , AmigaOS , o clássico Mac OS , OpenVMS , MS-DOS , Microsoft Windows , OS / 2 , ArcaOS , Novell NetWare e IBM i . Os protocolos de acesso remoto a arquivos alternativos incluem o Server Message Block (SMB, também denominado CIFS), Apple Filing Protocol (AFP), NetWare Core Protocol (NCP) e sistema de arquivos OS / 400 File Server (QFileSvr.400).

O SMB e o NetWare Core Protocol (NCP) ocorrem com mais freqüência do que o NFS em sistemas que executam o Microsoft Windows; AFP ocorre com mais freqüência do que NFS em sistemas Apple Macintosh ; e QFileSvr.400 ocorre com mais freqüência em sistemas IBM i. O Haiku em 2012 adicionou suporte a NFSv4 como parte de um projeto Google Summer of Code.

Comparação de desempenho NFS SPECsfs2008, a partir de 22 de novembro de 2013

Implementação típica

Supondo um cenário de estilo Unix em que uma máquina (o cliente ) precisa de acesso aos dados armazenados em outra máquina (o servidor NFS ):

1. O servidor implementa processos daemon NFS , rodando por padrão como nfsd, para tornar seus dados genericamente disponíveis aos clientes.
2. O administrador do servidor determina o que disponibilizar, exportando os nomes e parâmetros dos diretórios , normalmente usando o /etc/exportsarquivo de configuração e o exportfscomando.
3. A administração de segurança do servidor garante que ele possa reconhecer e aprovar clientes validados.
4. A configuração da rede do servidor garante que os clientes apropriados possam negociar com ele por meio de qualquer sistema de firewall .
5. A máquina cliente solicita acesso aos dados exportados, normalmente emitindo um mountcomando. (O cliente pergunta ao servidor (rpcbind) qual porta o servidor NFS está usando, o cliente se conecta ao servidor NFS (nfsd), o nfsd passa a solicitação para o mountd)
6. Se tudo correr bem, os usuários na máquina cliente podem visualizar e interagir com sistemas de arquivos montados no servidor dentro dos parâmetros permitidos.

Observe que a automação do processo de montagem NFS pode ocorrer - talvez usando /etc/fstab e / ou recursos de montagem automática .

Desenvolvimento de protocolo

Durante o desenvolvimento do protocolo ONC (denominado SunRPC na época), apenas o Network Computing System (NCS) da Apollo oferecia funcionalidade comparável. Dois grupos concorrentes desenvolveram-se sobre diferenças fundamentais nos dois sistemas de chamada de procedimento remoto. Argumentos focados no método de codificação de dados - Representação de Dados Externos (XDR) do ONC sempre renderizou inteiros na ordem big-endian , mesmo se ambos os pares da conexão tivessem arquiteturas de máquina little-endian , enquanto o método NCS tentava evitar a troca de bytes sempre que dois pares compartilham um endianness comum em suas arquiteturas de máquina. Um grupo da indústria chamado Network Computing Forum foi formado (março de 1987) em uma tentativa (malsucedida) de reconciliar os dois ambientes de computação em rede.

Em 1987, a Sun e a AT&T anunciaram que desenvolveriam em conjunto o UNIX System V Release 4. da AT&T. Isso fez com que muitos dos outros licenciados da AT&T para o UNIX System ficassem preocupados que isso colocaria a Sun em uma posição vantajosa e, por fim, levou à Digital Equipment, HP, IBM e outros formando a Open Software Foundation (OSF) em 1988. Ironicamente, a Sun e a AT&T haviam competido anteriormente pelo NFS da Sun contra o Remote File System (RFS) da AT&T , e pela rápida adoção do NFS sobre o RFS pela Digital Equipment, HP, IBM , e muitos outros fornecedores de computador deram a maioria dos usuários a favor do NFS. A interoperabilidade do NFS foi auxiliada por eventos chamados "Connectathons" a partir de 1986 que permitiram o teste neutro do fornecedor das implementações entre si. A OSF adotou o Distributed Computing Environment (DCE) e o DCE Distributed File System (DFS) sobre Sun / ONC RPC e NFS. O DFS usou o DCE como o RPC e o DFS derivou do Andrew File System (AFS); O próprio DCE derivou de um conjunto de tecnologias, incluindo o NCS e Kerberos da Apollo .

Década de 1990

A Sun Microsystems e a Internet Society (ISOC) chegaram a um acordo para ceder o "controle de mudança" do ONC RPC para que o órgão de padrões de engenharia do ISOC, a Internet Engineering Task Force (IETF), pudesse publicar documentos de padrões (RFCs) relacionados ao ONC RPC protocolos e pode estender ONC RPC. A OSF tentou fazer do DCE RPC um padrão IETF, mas acabou não se mostrando disposto a abrir mão do controle de mudanças. Posteriormente, a IETF optou por estender o ONC RPC adicionando um novo tipo de autenticação com base na GSSAPI ( Generic Security Services Application Program Interface ), RPCSEC GSS , para atender aos requisitos da IETF de que os padrões de protocolo tenham segurança adequada.

Posteriormente, a Sun e a ISOC chegaram a um acordo semelhante para dar ao ISOC o controle de alterações sobre o NFS, embora redigindo o contrato cuidadosamente para excluir o NFS versão 2 e versão 3. Em vez disso, o ISOC ganhou o direito de adicionar novas versões ao protocolo NFS, o que resultou no IETF especificando o NFS versão 4 em 2003.

Década de 2000

No século 21, nem o DFS nem o AFS alcançaram qualquer grande sucesso comercial em comparação com o SMB-CIFS ou o NFS. A IBM, que anteriormente havia adquirido o principal fornecedor comercial de DFS e AFS, Transarc , doou a maior parte do código-fonte do AFS para a comunidade de software livre em 2000. O projeto OpenAFS continua vivo . No início de 2005, a IBM anunciou o fim das vendas de AFS e DFS.

Em janeiro de 2010, Panasas propôs um NFSv4.1 baseado em sua tecnologia NFS Paralelo (pNFS) alegando melhorar a capacidade de paralelismo de acesso a dados. O protocolo NFSv4.1 define um método de separar os metadados do sistema de arquivos da localização dos dados do arquivo; vai além da simples separação de nome / dados, dividindo os dados entre um conjunto de servidores de dados. Isso difere do servidor NFS tradicional, que mantém os nomes dos arquivos e seus dados sob o guarda-chuva único do servidor. Alguns produtos são servidores NFS de vários nós, mas a participação do cliente na separação de metadados e dados é limitada.

O servidor NFSv4.1 pNFS é um conjunto de recursos ou componentes do servidor; estes são assumidos como controlados pelo servidor de metadados.

O cliente pNFS ainda acessa um servidor de metadados para travessia ou interação com o namespace; quando o cliente move dados de e para o servidor, ele pode interagir diretamente com o conjunto de servidores de dados pertencentes à coleção de servidores pNFS. O cliente NFSv4.1 pode ser ativado para ser um participante direto na localização exata dos dados do arquivo e para evitar a interação solitária com um servidor NFS ao mover os dados.

Além do pNFS, o NFSv4.1 oferece:

• Sessões
• Delegação de diretório e notificações
• Namespace de vários servidores
• listas de controle de acesso e controle de acesso discricionário
• Atribuições de retenção
• SECINFO_NO_NAME

Veja também

Referências

links externos