1. ANÁLISE COMPARATIVA ENTRE AS VERSÕES 3 E 4 DO PROTOCOLO NFS
EM ARQUITETURAS NAS
Kleber José da Silva
co-autor: Prof. Dr. Antonio Luiz Rigo
Neste artigo é apresentada uma avaliação de desempenho das versões 3 e 4 do
protocolo NFS (Network File System) em arquiteturas NAS (Network Attached
Storage), baseada em alterações nos parâmetros do protocolo, com foco na vazão
dos dados e na utilização de recursos do Sistema de Armazenamento.
Introdução
O protocolo NFSv4 tem sido pouco adotado em
arquiteturas NAS, apesar de apresentar diversas
melhorias em relação a sua predecessora - a versão 3
(NFSv3). Este artigo tem como objetivo avaliar o
desempenho do NFSv4, comparando com o NFSv3,
por meio de experimentos baseados em alterações na
parametrização do cliente NFS e nas configurações do
protocolo no servidor NFS (Sistema de
Armazenamento - Storage).
Contexto
Ambientes de grupos de servidores (clusters / farms)
como correio eletrônico, web, virtualização e banco
de dados necessitam armazenar seus dados em um
sistema de arquivos que possibilite um acesso
simultâneo e íntegro à área de uso compartilhado.
Uma arquitetura típica nesses ambientes é a NAS,
baseada em um Sistema de Armazenamento Figura 1 – Sistemas de Arquivos nas Arquiteturas de
conectado à rede, ou simplesmente Storage. O NAS Armazenamento NAS e SAN [HIRA10]
tem a capacidade nativa de fornecer e de operar essa
área de dados como um sistema de arquivos O objeto de estudo desse trabalho é a arquitetura NAS
compartilhado. Outra arquitetura possível é a SAN - operando com o protocolo NFS somente. O NFS é um
Storage Area Network, que depende de um serviço dos protocolos mais utilizados para troca de arquivos e
adicional no servidor que gerencie o sistema de armazenamento de dados com servidores que
arquivos compartilhado denominado “serviço de possuem seu Sistema Operacional baseado em Unix,
cluster”, em uma topologia com mais de um servidor. como Oracle Solaris, IBM AIX, Red Hat Linux, Fedora,
VMware vSphere e Citrix XenServer.
Essas arquiteturas são diferenciadas pela
conectividade do Storage com a rede e servidores, e O Protocolo NFSv4
principalmente pela disposição do elemento
responsável pelo sistema de arquivos. A figura 1 O protocolo NFSv4 - Network File System version 4 -
mostra as duas arquiteturas, sendo que na SAN o foi especificado em 2003 na RFC 3530 [SHEP03] e
sistema de arquivos é mantido no servidor, e na NAS atualmente - oito anos depois – é pouco adotado em
é mantido no Storage. OBS.: Outra arquitetura pouco ambientes NAS e, praticamente ignorado no Brasil. Há
usada é a DAS (Direct Access Storage) que tem o resistência entre os administradores de rede em
mesmo conceito de SAN, mas sem o uso da rede. adotá-la em suas instalações, temendo degradação

2. dos serviços de acesso aos dados, mesmo sabendo disponível nas versões mais recentes, como o Solaris
que a versão 4 é a mais recente do protocolo NFS e versão 10, por exemplo. Em algumas dessas
que apresenta diversas melhorias em relação a sua distribuições o NFSv3 ainda é a versão padrão de
predecessora, a versão 3 (NFSv3) – especificada na montagem do cliente NFS, como no IBM AIX versão
RFC 1813 [CALL95]: 6.1. Em outras como o Red Hat Enterprise Linux 5 e o
próprio Solaris 10, o NFSv4 já é o usado como padrão
• Gerenciamento do estado das sessões (o protocolo é quando o servidor NFS também o suporta. As últimas
stateful), aperfeiçoando técnicas de análise de versões dos servidores de virtualização vSphere da
problemas; VMware e XenServer da Citrix já suportam a versão 4,
• Implementações de mecanismos de segurança apesar de manter a 3 como padrão.
nativas no protocolo ou integrações com outros
sistemas (RPCSEC_GSS, Kerberos v5 e LipKey); Para os Sistemas Operacionais Windows a Microsoft
• Padronização do tratamento de ACLs – Access desenvolveu um cliente NFS chamado SFU (Services
Control Lists, facilitando a integração com ambientes for Unix) que é pouco utilizado e suporta no máximo o
Windows; NFSv3. O progresso do desenvolvimento desse cliente
• Incorporação dos sub-protocolos (separados no com NFSv4 foi feito pelo CITI que disponibilizou em
NFSv3: mountd, lockd e statd) utilizando apenas uma 2010 o pacote para instalação em Windows Vista x64,
porta TCP (Transmission Control Protocol), e exclusão Windows Server 2008 R2 x64, e Windows 7 x64.
do protocolo UDP (User Datagram Protocol),
facilitando a comunicação através de firewalls; A tendência é que o NFSv4 se consolide como opção
• Suporte à migração e replicação de arquivos, padrão nas próximas versões dos servidores
simplificando a necessidade de substituir um servidor justamente para que eles possam aproveitar as
NFS por outro; melhorias apresentadas nessa versão, e
• Comunicação por meio de múltiplos pedidos ao conseqüentemente o NFSv3 seria desativado a médio
servidor da mesma chamada RPC (Remote Procedure prazo. Em 2006 esse processo já começou a ocorrer
Call) - RPC Composto, melhorando nativamente o nos Estados Unidos conforme exposto no artigo de
desempenho de aplicações que necessitam de acesso Pohlmann e Hess [POHL06]. Neste caso os
contínuo aos arquivos. administradores de ambientes NAS passarão a utilizar
a nova versão do protocolo, porém não gostariam de
O aumento da complexidade como apontado por ter o desempenho do ambiente reduzido.
Kirch [KIRC06] e as grandes mudanças da nova
versão do protocolo conforme exposto por Harrington Para que o processo de atualização ocorra sem
et al. [HARR06] e Hildebrand [HILD07], associados à problemas, o administrador de um ambiente NAS deve
pequena base instalada dessa nova versão são os avaliar as configurações possíveis e disponíveis na
motivos aparentes que fazem os administradores de nova versão que trariam um melhor desempenho.
ambientes NAS continuarem a usar o NFSv3. Além de
ser um protocolo mais simples e leve, o NFSv3 Parametrizações do NFSv4
permite a utilização do UDP como protocolo de
camada de transporte, mais ágil e menos confiável do A motivação para explorar as alterações nos
que o TCP. Entretanto, utilizar UDP em ambientes de parâmetros do protocolo é o fato de alguns estudos,
como o de Boumenot [BOUM02], apontarem que os
armazenamento de dados, exporia ao risco de perder
elementos básicos da infra-estrutura de um arquitetura
pacotes em grandes volumes de trocas de arquivos
NAS baseada em NFS como processador, disco e
em altas taxas de transferências.
rede não serem as origens de uma baixa vazão entre
servidor e cliente. Supõe-se que a deficiência seja
Estado da Arte
causada por um comportamento evitável do NFS,
mediante ajustes.
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 Delegações de arquivos a clientes
(Center for Information Technology Integration) - da
Universidade de Michigan e pelo projeto GNU/Linux São divididas em dois tipos: leitura e escrita, sendo
NFSv4 da Bull Open Source [BULL]. possível habilitá-las isolada ou conjuntamente. Essa é
uma característica nativa presente apenas na versão
A partir dos primeiros núcleos versão 2.6 dos 4, não sendo suportada nas versões anteriores. Essa
opção foi concebida para o cliente NFS acessar
Sistemas Operacionais baseados em Linux, o NFSv4
(leitura) e modificar (escrita) o arquivo dentro do seu
já era suportado, como apontado pelo CITI. Em
cache local, sem a necessidade de transferi-lo para o
sistemas comerciais baseados em UNIX, como IBM
servidor, até que o servidor informe ao atual cliente
AIX, Oracle Solaris e HP-UX ele também está

3. que há outro cliente desejando acessar o mesmo
arquivo. Quando isso ocorre, o arquivo submetido à
alteração é atualizado no servidor. Este modelo de
operação reduz o tráfego de rede consideravelmente,
casos os clientes não acessem um conjunto de
arquivos concorrentemente.
RPC Composto
O NFSv4 apresenta nativamente um modelo de
procedimentos compostos (RPC Compound)
englobando diversas operações em somente uma
requisição RPC, característica não disponível no
NFSv3. Esse modelo somente é possível em
decorrência da última versão do NFS suportar apenas
TCP (como já informado anteriormente) pois o RPC
composto não é compatível com UDP, como pode ser
visto na figura 2 e 3 que representam as arquiteturas
das versões 3 e 4.
Pohlmann e Hess [POHL06] estimam que, em média,
o número de chamadas RPC da versão anterior eram
cinco vezes maior que a da nova versão, ou seja, há
a tendência de uma boa redução no tráfego de
metadados na rede e na quantidade de IOPs do lado
do servidor NFS. Figura 3 – Arquitetura do NFSv4
Fonte: [BULL]
Tamanho de blocos
O tamanho de blocos usado em uma transferência de
dados entre cliente e servidor NFS em uma arquitetura
NAS é definida no momento da montagem do sistema
de arquivos pelo cliente, ou seja, é um parâmetro
estabelecido por cada cliente. Tradicionalmente o
administrador de ambiente utiliza tamanho de blocos
pequenos: 4 e 8KBytes no NFSv2, aumentando para
8, 16 e 32KBytes no NFSv3 e chegando a 64 e até
128KBytes no NFSv4. Hildebrand e Honeyman
[HILD05] expõe que “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. Esse risco é eliminado pelo TCP,
mesmo operando com Jumbo Frames e transferindo
blocos maiores, como 64KB e 128KB.” Por esse
motivo os cenários de testes deste experimento não
contemplam o uso blocos maiores para NFSv3 em
UDP.
Especificação do Experimento
Figura 2 – Arquitetura do NFSv2/v3
Fonte: [BULL]
Todos os cenários das execuções de testes foram
baseados em uma única topologia mostrada figura 4,
sendo que essa arquitetura permite realizar alterações
propostas de parâmetros do protocolo NFS:

4. um script que é executado no servidor Linux e tem o
propósito de gerar cargas de acesso ao volume
disponibilizado pelo Sistema de Armazenamento. A
ferramenta permite a simulação do perfil de acesso
por meio de ajustes de relação leitura x escrita,
tamanho dos blocos transferidos, número de threads
simultâneos e número de arquivos acessados.
Com o intuito de delimitar as combinações possíveis,
todas as simulações foram executadas utilizando
configurações fixas de relação leitura x escrita em
50% x 50%, usando 3 threads, em 2 minutos de tempo
de execução por 3 vezes, e acessando 10 arquivos
simultaneamente. 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 testes foram executados com o ambiente de
laboratório dedicado, dessa forma o resultado não foi
influenciado por outros acessos. Os demais recursos
dos servidores Linux e do Sistema de Armazenamento
como utilização de disco, memória e CPU dos
servidores Linux foram monitorados apenas para
Figura 4 – Topologia do Experimento
Fonte: elaborado pelo autor identificar eventuais gargalos. Como nenhum ponto foi
observado nestes elementos, então somente o
A topologia apresentada é composta por um servidor resultado dos 3 principais recursos desejados foi
HP modelo Proliant DL360G5 fazendo o papel de coletado e apresentado graficamente.
cliente NFS, com Sistema Operacional Linux RedHat
5.2. Este servidor tem conectividade TCP/IP com o Cenários
Sistema de Armazenamento NAS por meio de um
comutador Ethernet (switch) com portas Gigabit. O Um gráfico foi gerado para cada cenário:
Sistema de Armazenamento é do fabricante NetApp
modelo FAS2040, com sistema operacional Cenário NFS Deleg. RPC TCP /
proprietário Data ONTAP 7.3.2. Sua configuração de Arquivos Comp. UDP
discos foi disponibilizada em RAID 6 (Redundant Array 1 v3 N/A N/A TCP
of Independent Disks) formada por cinco discos de 2 v3 N/A N/A UDP
dados e dois de paridade, do tipo SAS (Serial Attached 3 v4 Não Sim TCP
SCSI) de 15.000 RPM (Rotations Per Minute). 4 v4 Sim Sim TCP
Tabela 1 – Cenários para a execução dos testes
Essa é uma topologia muito comum em ambientes
NAS encontrados nas organizações, em que o No intervalo entre a execução de um cenário e outro, o
Sistema de Armazenamento fornece uma área ambiente foi reiniciado (servidores e storage) e os
compartilhada para servidores Linux por meio do volumes de dados de testes recriados para evitar
protocolo NFS. No papel de clientes, além de resultados eventualmente influenciados pelo cache de
servidores Linux, também é comum haver servidores operações de outros cenários.
monitores de máquinas virtuais da VMware e Citrix, e
servidores UNIX como IBM AIX, HP-UX, e Oracle Variáveis
Solaris.
Presume-se que em um ambiente real a escolha do
Simulação de carga de acesso tamanho de bloco seria feita baseada no
conhecimento prévio do perfil da aplicação de cada
Por se tratar de um experimento em laboratório e não servidor. Dessa forma, os gráficos foram gerados
um estudo de caso em ambiente real, a carga de variando o tamanho simultaneamente na montagem
produção foi simulada por uma ferramenta da NetApp do cliente NFS e na ferramenta de simulação SIO: 8K,
(fabricante do Sistema de Armazenamento) 16K, 32K, 64 e 128KBytes. (Com exceção do NFSv3
denominada SIO (Simulated Input Output). Trata-se de em UDP que não contemplou tamanhos grandes)

5. Resultados Operações NFS (IOPs)
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), conforme valores exemplos:
Vazão NFS IOPs CPU
92MBytes/s 5.240 84%
Tabela 2 – Exemplo de resultados obtidos das execuções
 Vazão: taxa de transferência efetiva de
dados expressa em Mega Bytes por Segundo Figura 6 – Gráfico de Desempenho – Operações NFS
(coletada na ferramenta de simulação no
servidor Linux). A utilização de Operações NFSv4 é em todos os
 Utilização da CPU: porcentagem do tempo casos maior que o dobro da versão 3. Essa relação é
que a CPU do Servidor NFS está ocupada mais próxima apenas com tamanhos de blocos de
(coletada no sysstat do Storage). 32KB. O gráfico mostra também que na medida em
 Utilização de IOPs: Operações de Entrada que o tamanho de blocos é reduzido, até atingir 32KB,
e Saída por segundo no Servidor NFS (coletada resulta-se em menor utilização de IOPs no Sistema de
no sysstat do Storage). Armazenamento. Ao passo que após esse ponto, a
utilização volta a aumentar. Analisando apenas pelo
Análise Comparativa dos gráficos de desempenho quesito “utilização de IOPS” o melhor comportamento
ocorre com tamanho de blocos de 32KBytes.
Vazão
Utilização média de CPU do Storage
Figura 5 – Gráfico de Desempenho – Vazão (MBytes/s)
Figura 7 – Gráfico de Desempenho – Utilização de CPU (%)
Nota-se o aumento linear da vazão proporcionalmente
ao tamanho de bloco utilizado. A diferença de Os resultados de utilização média de CPU ficaram
resultados do TCP e UDP não foi significativa, muito próximos em todos os cenários.
desencorajando inicialmente o uso de UDP devido aos
riscos expostos ao ambiente. O resultado do NFSv4 Trabalhos Futuros
ficou abaixo do NFSv3 em todos os cenários mesmo
com as funcionalidades nativas como RPC composto, Em vista das delimitações dos cenários dos testes
por exemplo, que teoricamente eram para melhorar. deste artigo, nota-se que trabalhos futuros podem ser
realizados alterando o perfil de aplicação configurado
OBS.: O resultado do cenário 1 (NFSv3/TCP) foi muito na ferramenta de simulação. Um exemplo seria a
próximo do máximo possível para um canal Gigabit alteração da porcentagem de relação leitura x escrita
ethernet que seria de 128MBytes/s (1024Mbits / 8). que influencia diretamente no comportamento do
Neste caso uma infra-estrutura com agregação de acesso. O sistema operacional do cliente NFS
canais ethernet poderia atingir um resultado ainda também pode ser substituído para analisar
melhor, porém não foi feito devido à idéia inicial de implementações específicas como, por exemplo, do
criar uma limitação e comparar as versões somente. FreeBSD, Solaris ou Fedora.

6. /mnt/nfs/file.2 /mnt/nfs/file.3 /mnt/nfs/
O próximo estágio no estudo da diferença de resultado nt/nfs/file.6 /mnt/nfs/file.7 /mnt/nfs/file.8
do NFSv4 em relação ao NFSv3 seria explorar /mnt/nfs/file.9
Outputs
alterações na infra-estrutura de rede para tentar atingir IOPS: 1636
um melhor desempenho do NFSv4. Primeiramente KB/s: 104695
IOs: 196336
pode-se aumentar o canal de comunicação entre
servidor e storage por meio de agregação de canais
ethernet (Link Aggregation). Em seguida pode-se sysstat (Storage)
implementar Jumbo Frames em todos os pontos de
comunicação para reduzir a sobrecarga de Sintaxe padrão utilizada no Sistema de
mensagens devido à fragmentação. Outra sugestão Armazenamento para coleta de CPU e IOPs:
seria utilizar uma comunicação baseada em IPv6 e sysstat –s –c 120 1
explorar sua funcionalidade de jumbogramas.
Legenda: –s apresenta um sumário ao final do
Conclusão comando, –c 120 execuções, 1 segundo de intervalo
Das opções analisadas, nas condições presentes no Resultado exemplo:
experimento, conclui-se que a versão 3 ainda é a
Summary Statistics ( 120 samples 1 secs/sample)
melhor escolha no quesito desempenho para um CPU NFS CIFS HTTP Net kB/s Disk kB/s
ambiente NAS por apresentar uma melhor vazão dos in out read write
dados e menor utilização de IOPs em relação à versão Min
7% 3899 0 0 3961 5242 76 0
4. Todavia percebe-se que essa diferença é Avg
minimizada em transferências com tamanho de blocos 41% 26761 0 0 38301 24320 685 37872
Max
maiores, possível apenas nas configurações em TCP, 53% 31421 0 0 59767 35308 5540 68544
uma vez que em UDP pode-se apresentar problemas
de perda de dados. Opções configuradas no Servidor NFS
Não se deve descartar totalmente o uso do NFSv4 Algumas configurações de NFS foram feitas no
principalmente nos ambientes em que suas novas Sistema de Armazenamento que se aplicaram para
funcionalidades compensariam a pequena perda de todos os cenários executados:
desempenho em relação a versão anterior, justificada
pela complexidade introduzida nessa nova versão. vol options nfs no_atime_update on
Nos casos em que ele já esteja no gargalo, um options nfs.tcp.recvwindowsize 65536
options nfs.tcp.xfersize 65536
upgrade de versão poderia ajudar. Para os demais options nfs.ifc.rcv.high 98304
casos, deve-se explorar um pouco mais o estudo
conforme sugestões apresentadas na seção Opções configuradas no Cliente NFS
“Trabalhos Futuros”.
Alguns parâmetros de montagem do cliente NFS
Apêndices (Servidor Linux) foram mantidos para todos os
cenários executados:
SIO (Servidor) actimeo=0,nointr,suid,timeo=600
Sintaxe padrão utilizada na ferramenta SIO: As demais opções foram variadas em cada cenário,
como tamanho de bloco e versão do protocolo.
./sio_ntap_linux 50 100 8k 10m 120 3 /mnt/nfs/file.0
/mnt/nfs/file.1 /mnt/nfs/file.2 /mnt/nfs/file.3
Exemplo do comando de montagem para NFSv4 e
/mnt/nfs/file.4 /mnt/nfs/file.5 /mnt/nfs/file.6 32KBytes:
/mnt/nfs/file.7 /mnt/nfs/file.8 /mnt/nfs/file.9
mount -t nfs4 -o rsize=32768,wsize=32768,actimeo=0,
nointr,suid,timeo=600 fas01:/vol/nfs /mnt/nfs
Legenda: 50% leitura, 100% randômico, 8k tamanho
de bloco, 10m tamanho do arquivo em MBytes, 120
Referências/Bibliografia
segundos de execução, 3 threads.
[HIRA10] Sérgio Hirata; “Análise comparativa das
Resultado exemplo:
arquiteturas de armazenamento NAS e SAN para
SIO_NTAP: suporte a uma aplicação de entrada de pedidos”,
Inputs
Read %: 50 Dissertação, IPT (2010)
Random %: 100
Block Size: 65536
File Size: 10485760 [SHEP03] S. Shepler et al; “Network File System
Secs: 120
Threads: 3
(NFS) version 4 Protocol”, RFC 3530, USA (2003)
File(s): /mnt/nfs/file.0 /mnt/nfs/file.1

7. [CALL95] B. Callaghan et al; “NFS version 3 Protocol
Specification”, RFC 1813, USA (1995)
[KIRC06] O. Kirch; “Why NFS Sucks”, Proceedings,
Linux Symposium, Ottawa, Canada (2006)
[HARR06] B. Harrington et al; “NFSv4 Test Project”,
Proceedings, Linux Symposium, Ottawa, Canada
(2006)
[HILD07] D. Hildebrand; “Distributed Access to
Paralell File System”, Dissertação, The University of
Michigan - USA (2007)
[BULL] Bull Open Source. GNU Linux/NFSv4
Project. Disponível em:
<http://nfsv4.bullopensource.org/>.
[CITI] CITI Project: Center for Information
Technology Integration. Disponível em:
<http://www.citi.umich.edu/projects/nfsv4/linux>.
[POHL06] Frank Pohlmann, Kenneth Hess; “NFSv4
delivers seamless network access”, Artigo, IBM
Developer Works, United Kingdom (2006)
[BOUM02] Christopher Boumenot; “The
Performance of a Linux NFS Implementation”, Tese,
Worcester Polytechnic Institute - USA (2002)
[HILD05] Dean Hildebrand, Peter Honeyman;
“Scaling NFSv4 with Parallel File Systems”,
Proceedings, Fifth IEEE International Symposium,
Cardiff, UK (2005)