O documento analisa o desempenho do protocolo NFS versão 3 e 4 em arquiteturas NAS, variando parâmetros como tamanho de bloco e delegações de arquivos. Os resultados mostraram que o NFSv3 teve melhor desempenho em termos de vazão e IOPs em configurações mais antigas, enquanto em configurações mais recentes a diferença foi menor, sugerindo que o NFSv4 não deve ser descartado, especialmente quando suas novas funcionalidades são úteis. Trabalhos futuros incluem alterar perfis de
Lei geral de proteção de dados por Kleber Silva e Ricardo Navarro (Pise4)
Comparação entre NFSv3 e NFSv4 em desempenho em arquiteturas NAS
1. Artigo Kleber José da Silva Co-autor: Prof. Dr. Antonio Rigo IPT – 05/07/2011 Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquiteturas NAS
Evolução de DAS para SAN; Diferenças: NAS -> LAN e Arquivos . Protocolos NFS para UNIX e CIFS (SMB) para Windows SAN -> Blocos. Protocolos FCP, iSCSI e FCoE.
Arquiteturas NAS facilitam o processo de Backup para fita com o NDMP ao copiar os dados diretamente do Storage para a Fita.
Além do linux, VMware e XenServer possuem versão gratuitas .
Pouco Adotado: Resistência entre os administradores de rede em adotá-la em suas instalações, temendo degradação. Ausência de base instalada. Aumento da complexidade por Kirch (2006) Grandes mudanças da nova versão do protocolo conforme exposto por Harrington et al. (2006) e Hildebrand (2007) UDP Risco de perder pacotes em grandes volumes de trocas de arquivos em altas taxas de transferências, o que seria trágico
Em 1997 a SUN transferiu oficialmente o desenvolvimento do NFS para o IETF ( Internet Engineering Task Force ) O NFSv4 foi extremamente modificado em relação às versões anteriores do protocolo NFS
Stateful -> Aperfeiça técnicas de análise de problemas ACL -> facilitando a integração com ambientes Windows Sub-Protocolos -> separados no NFSv3: mountd , lockd e statd Única porta TCP -> facilita a comunicação através de firewalls Migração/Replicação -> simplificando a necessidade de substituir um servidor NFS por outro
Em alguns países, como nos Estados Unidos e França , a base instalada de NFSv4 tem aumentando ao longo do tempo, como identificado pelo CITI. CITI disponibilizou em meados de 2010 o pacote para instalação do SFU para NFSv4 em Windows Vista x64, Windows Server 2008 R2 x64, e Windows 7 x64
Dois tipos: leitura e escrita O conceito de cache já existia nas versões anteriores do NFS (2 e 3 ) mas para garantir consistência entre diferentes clientes, eles trocavam mensagens com o servidor. As delegações de arquivos no NFSv4 são possíveis porque o protocolo mantém o estado das sessões (é stateful ) , o que não ocorria nas versões anteriores Harrington et al. (2006): Clusters de Renderização e Banco de Dados
Diversas operações em somente uma requisição RPC. Esse modelo somente é possível em decorrência da última versão do NFS suportar apenas TCP . Essa mudança busca melhorar o desempenho em redes com alta latência, Mas mesmo em redes locais com baixa latência espera-se reduzir o número de operações do NAS. Pohlmann e Hess (2006) estimam que, eram 5 vezes maior que a da nova versão.
Parâmetro estabelecido por cada cliente Uso de UDP na camada de transporte, caso do NFSv2 e 3 , limitava o uso de um tamanho de blocos maior devido ao risco de perda do bloco inteiro ao falhar uma requisição simples. Blocos grandes são mais eficientes do que pequenos, mas se o tamanho dos arquivos em trânsito é pequeno, haveria desperdício de espaço.
Storage em RAID 6 em 5+2, com discos SAS de 15K RPM. No papel de clientes NFS, além de servidores Linux, também é comum haver servidores de virtualização como VMware e Citrix para seus repositórios ( DataStores ) e servidores UNIX como IBM AIX, HP-UX, e Oracle Solaris
Apenas o tamanho de blocos foi variado em conjunto com o tamanho utilizado na montagem do cliente NFS e seus valores especificados formaram um dos eixos dos gráficos de desempenho. Os cenários foram divididos em 2 grupos, sendo que cada um deles utilizou versões diferentes de Sistema Operacional do cliente e servidor NFS.
No intervalo entre a execução de um cenário e outro, o ambiente foi reiniciado (servidores e storage ) e os volumes de dados de testes recriados para evitar resultados eventualmente influenciados pelo cache de operações de outros cenários.
o uso de UDP na camada de transporte, caso do NFSv2 e às vezes do NFSv3, limita o uso de um tamanho de blocos maior devido ao risco de perda do bloco inteiro ao falhar uma requisição simples
Cada cenário foi executado 3 vezes e a média dos resultados seguintes foi coletada a partir da ferramenta SIO no servidor Linux e da ferramenta nativa sysstat no Sistema de Armazenamento ( Storage )
aumento linear da vazão proporcionalmente ao tamanho de bloco utilizado A diferença de resultados do TCP e UDP não foi significativa, desencorajando inicialmente o uso de UDP devido aos riscos expostos ao ambiente
aumento proporcional ao tamanho de bloco estabilizado a partir de 32K Nesta configuração B, a diferença de vazão entre NFSv3/TCP e NFSv4 ficou menor que na configuração A, ou seja, mostra que houve realmente uma melhoria na implementação dos Sistemas Operacionais
A utilização de Operações NFSv4 é em todos os casos maior que o dobro da versão 3. Essa relação é mais próxima apenas com tamanhos de blocos de 32KB
o NFSv4 também apresenta uma maior utilização de IOPs, mas a diferença para o NFSv3 é reduzida quando as delegações de arquivos é habilitada, no caso de tamanho de blocos menores. Mas bem como na vazão, o número de IOPs se mantém estabilizado com a alteração do tamanho de blocos. Sem as delegações de arquivos - cenário 3B, comparando a configuração anterior no cenário 3A, a diferença é minimizada no tamanho de bloco em 64KBytes, mesmo assim ainda é o dobro
Os resultados de utilização média de CPU ficaram muito próximos em todos os cenários. Nota-se que as delegações de arquivos do NFSv4 reduzem um pouco sua utilização
Os resultados de utilização média de CPU ficaram muito próximos em todos os cenários. Nota-se que as delegações de arquivos do NFSv4 reduzem um pouco sua utilização
No IPv6, Jumbograma poderia trazer vantagens de desempenho para tamanho de blocos grandes.
Entretanto, deve-se explorar um pouco mais o estudo conforme sugestões apresentadas na seção “Trabalhos Futuros”.