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 conectado à rede, ou simplesmente Storage. O NAS tem a capacidade nativa de fornecer e de operar essa área de dados como um sistema de arquivos

compartilhado. Outra arquitetura possível é a SAN - Storage Area Network, que depende de um serviço adicional no servidor que gerencie o sistema de arquivos compartilhado denominado “serviço de cluster”, em uma topologia com mais de um servidor. Essas arquiteturas são diferenciadas pela conectividade do Storage com a rede e servidores, e principalmente pela disposição do elemento responsável pelo sistema de arquivos. A figura 1 mostra as duas arquiteturas, sendo que na SAN o sistema de arquivos é mantido no servidor, e na NAS é mantido no Storage. OBS.: Outra arquitetura pouco usada é a DAS (Direct Access Storage) que tem o mesmo conceito de SAN, mas sem o uso da rede.

Figura 1 – Sistemas de Arquivos nas Arquiteturas de Armazenamento NAS e SAN [HIRA10]

O objeto de estudo desse trabalho é a arquitetura NAS

operando com o protocolo NFS somente. O NFS é um dos protocolos mais utilizados para troca de arquivos e armazenamento de dados com servidores que possuem seu Sistema Operacional baseado em Unix, como Oracle Solaris, IBM AIX, Red Hat Linux, Fedora, VMware vSphere e Citrix XenServer.

O Protocolo NFSv4 O protocolo NFSv4 - Network File System version 4 - foi especificado em 2003 na RFC 3530 [SHEP03] e atualmente - oito anos depois – é pouco adotado em ambientes NAS e, praticamente ignorado no Brasil. Há resistência entre os administradores de rede em adotá-la em suas instalações, temendo degradação

dos serviços de acesso aos dados, mesmo sabendo que a versão 4 é a mais recente do protocolo NFS e que apresenta diversas melhorias em relação a sua predecessora, a versão 3 (NFSv3) – especificada na RFC 1813 [CALL95]: • Gerenciamento do estado das sessões (o protocolo é stateful), aperfeiçoando técnicas de análise de problemas;

• Implementações de mecanismos de segurança nativas no protocolo ou integrações com outros sistemas (RPCSEC_GSS, Kerberos v5 e LipKey); • Padronização do tratamento de ACLs – Access

Control Lists, facilitando a integração com ambientes

Windows; • Incorporação dos sub-protocolos (separados no NFSv3: mountd, lockd e statd) utilizando apenas uma porta TCP (Transmission Control Protocol), e exclusão do protocolo UDP (User Datagram Protocol),

facilitando a comunicação através de firewalls; • Suporte à migração e replicação de arquivos,

simplificando a necessidade de substituir um servidor NFS por outro; • Comunicação por meio de múltiplos pedidos ao servidor da mesma chamada RPC (Remote Procedure

Call) - RPC Composto, melhorando nativamente o desempenho de aplicações que necessitam de acesso contínuo aos arquivos.

O aumento da complexidade como apontado por

Kirch [KIRC06] e as grandes mudanças da nova versão do protocolo conforme exposto por Harrington et al. [HARR06] e Hildebrand [HILD07], associados à pequena base instalada dessa nova versão são os motivos aparentes que fazem os administradores de ambientes NAS continuarem a usar o NFSv3. Além de ser um protocolo mais simples e leve, o NFSv3

permite a utilização do UDP como protocolo de camada de transporte, mais ágil e menos confiável do

que o TCP. Entretanto, utilizar UDP em ambientes de armazenamento de dados, exporia ao risco de perder pacotes em grandes volumes de trocas de arquivos em altas taxas de transferências.

Estado da Arte 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 (Center for Information Technology Integration) - da Universidade de Michigan e pelo projeto GNU/Linux NFSv4 da Bull Open Source [BULL]. A partir dos primeiros núcleos versão 2.6 dos

Sistemas Operacionais baseados em Linux, o NFSv4 já era suportado, como apontado pelo CITI. Em sistemas comerciais baseados em UNIX, como IBM AIX, Oracle Solaris e HP-UX ele também está

disponível nas versões mais recentes, como o Solaris versão 10, por exemplo. Em algumas dessas distribuições o NFSv3 ainda é a versão padrão de montagem do cliente NFS, como no IBM AIX versão 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 quando o servidor NFS também o suporta. As últimas versões dos servidores de virtualização vSphere da VMware e XenServer da Citrix já suportam a versão 4, apesar de manter a 3 como padrão. Para os Sistemas Operacionais Windows a Microsoft

desenvolveu um cliente NFS chamado SFU (Services for Unix) que é pouco utilizado e suporta no máximo o NFSv3. O progresso do desenvolvimento desse cliente com NFSv4 foi feito pelo CITI que disponibilizou em

2010 o pacote para instalação em Windows Vista x64, Windows Server 2008 R2 x64, e Windows 7 x64.

A tendência é que o NFSv4 se consolide como opção

padrão nas próximas versões dos servidores justamente para que eles possam aproveitar as melhorias apresentadas nessa versão, e conseqüentemente o NFSv3 seria desativado a médio prazo. Em 2006 esse processo já começou a ocorrer nos Estados Unidos conforme exposto no artigo de Pohlmann e Hess [POHL06]. Neste caso os administradores de ambientes NAS passarão a utilizar a nova versão do protocolo, porém não gostariam de ter o desempenho do ambiente reduzido.

Para que o processo de atualização ocorra sem problemas, o administrador de um ambiente NAS deve avaliar as configurações possíveis e disponíveis na nova versão que trariam um melhor desempenho.

Parametrizações do NFSv4 A motivação para explorar as alterações nos parâmetros do protocolo é o fato de alguns estudos, como o de Boumenot [BOUM02], apontarem que os elementos básicos da infra-estrutura de um arquitetura NAS baseada em NFS como processador, disco e rede não serem as origens de uma baixa vazão entre servidor e cliente. Supõe-se que a deficiência seja causada por um comportamento evitável do NFS,

mediante ajustes.

Delegações de arquivos a clientes

São divididas em dois tipos: leitura e escrita, sendo possível habilitá-las isolada ou conjuntamente. Essa é uma característica nativa presente apenas na versão 4, não sendo suportada nas versões anteriores. Essa opção foi concebida para o cliente NFS acessar (leitura) e modificar (escrita) o arquivo dentro do seu cache local, sem a necessidade de transferi-lo para o servidor, até que o servidor informe ao atual cliente

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 2 – Arquitetura do NFSv2/v3 Fonte: [BULL]

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 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:

Figura 4 – Topologia do Experimento Fonte: elaborado pelo autor

A topologia apresentada é composta por um servidor HP modelo Proliant DL360G5 fazendo o papel de

cliente NFS, com Sistema Operacional Linux RedHat

5.2. Este servidor tem conectividade TCP/IP com o Sistema de Armazenamento NAS por meio de um

comutador Ethernet (switch) com portas Gigabit. O Sistema de Armazenamento é do fabricante NetApp

modelo FAS2040, com sistema operacional proprietário Data ONTAP 7.3.2. Sua configuração de

discos foi disponibilizada em RAID 6 (Redundant Array of Independent Disks) formada por cinco discos de dados e dois de paridade, do tipo SAS (Serial Attached SCSI) de 15.000 RPM (Rotations Per Minute). Essa é uma topologia muito comum em ambientes NAS encontrados nas organizações, em que o Sistema de Armazenamento fornece uma área compartilhada para servidores Linux por meio do protocolo NFS. No papel de clientes, além de servidores Linux, também é comum haver servidores monitores de máquinas virtuais da VMware e Citrix, e servidores UNIX como IBM AIX, HP-UX, e Oracle Solaris.

Simulação de carga de acesso Por se tratar de um experimento em laboratório e não um estudo de caso em ambiente real, a carga de produção foi simulada por uma ferramenta da NetApp (fabricante do Sistema de Armazenamento)

denominada SIO (Simulated Input Output). Trata-se de

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 identificar eventuais gargalos. Como nenhum ponto foi observado nestes elementos, então somente o resultado dos 3 principais recursos desejados foi coletado e apresentado graficamente.

Cenários Um gráfico foi gerado para cada cenário:

Cenário NFS Deleg. Arquivos

RPC Comp.

TCP / UDP

1 v3 N/A N/A TCP

2 v3 N/A N/A UDP

3 v4 Não Sim TCP

4 v4 Sim Sim TCP Tabela 1 – Cenários para a execução dos testes

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.

Variáveis Presume-se que em um ambiente real a escolha do tamanho de bloco seria feita baseada no conhecimento prévio do perfil da aplicação de cada servidor. Dessa forma, os gráficos foram gerados variando o tamanho simultaneamente na montagem

do cliente NFS e na ferramenta de simulação SIO: 8K,

16K, 32K, 64 e 128KBytes. (Com exceção do NFSv3 em UDP que não contemplou tamanhos grandes)

Resultados

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 (coletada na ferramenta de simulação no servidor Linux).

Utilização da CPU: porcentagem do tempo que a CPU do Servidor NFS está ocupada (coletada no sysstat do Storage).

Utilização de IOPs: Operações de Entrada e Saída por segundo no Servidor NFS (coletada no sysstat do Storage).

Análise Comparativa dos gráficos de desempenho

Vazão

Figura 5 – Gráfico de Desempenho – Vazão (MBytes/s)

Nota-se o 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. O resultado do NFSv4 ficou abaixo do NFSv3 em todos os cenários mesmo com as funcionalidades nativas como RPC composto, por exemplo, que teoricamente eram para melhorar. OBS.: O resultado do cenário 1 (NFSv3/TCP) foi muito próximo do máximo possível para um canal Gigabit ethernet que seria de 128MBytes/s (1024Mbits / 8). Neste caso uma infra-estrutura com agregação de canais ethernet poderia atingir um resultado ainda melhor, porém não foi feito devido à idéia inicial de criar uma limitação e comparar as versões somente.

Operações NFS (IOPs)

Figura 6 – Gráfico de Desempenho – Operações NFS

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 gráfico mostra também que na medida em que o tamanho de blocos é reduzido, até atingir 32KB, resulta-se em menor utilização de IOPs no Sistema de Armazenamento. Ao passo que após esse ponto, a utilização volta a aumentar. Analisando apenas pelo quesito “utilização de IOPS” o melhor comportamento ocorre com tamanho de blocos de 32KBytes.

Utilização média de CPU do Storage

Figura 7 – Gráfico de Desempenho – Utilização de CPU (%)

Os resultados de utilização média de CPU ficaram muito próximos em todos os cenários.

Trabalhos Futuros Em vista das delimitações dos cenários dos testes deste artigo, nota-se que trabalhos futuros podem ser realizados alterando o perfil de aplicação configurado na ferramenta de simulação. Um exemplo seria a alteração da porcentagem de relação leitura x escrita que influencia diretamente no comportamento do acesso. O sistema operacional do cliente NFS também pode ser substituído para analisar implementações específicas como, por exemplo, do FreeBSD, Solaris ou Fedora.

O próximo estágio no estudo da diferença de resultado do NFSv4 em relação ao NFSv3 seria explorar alterações na infra-estrutura de rede para tentar atingir um melhor desempenho do NFSv4. Primeiramente 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 implementar Jumbo Frames em todos os pontos de comunicação para reduzir a sobrecarga de mensagens devido à fragmentação. Outra sugestão seria utilizar uma comunicação baseada em IPv6 e explorar sua funcionalidade de jumbogramas.

Conclusão

Das opções analisadas, nas condições presentes no experimento, conclui-se que a versão 3 ainda é a melhor escolha no quesito desempenho para um ambiente NAS por apresentar uma melhor vazão dos dados e menor utilização de IOPs em relação à versão 4. Todavia percebe-se que essa diferença é minimizada em transferências com tamanho de blocos maiores, possível apenas nas configurações em TCP, uma vez que em UDP pode-se apresentar problemas de perda de dados. Não se deve descartar totalmente o uso do NFSv4 principalmente nos ambientes em que suas novas funcionalidades compensariam a pequena perda de desempenho em relação a versão anterior, justificada pela complexidade introduzida nessa nova versão. Nos casos em que ele já esteja no gargalo, um upgrade de versão poderia ajudar. Para os demais casos, deve-se explorar um pouco mais o estudo conforme sugestões apresentadas na seção “Trabalhos Futuros”.

Apêndices

SIO (Servidor) Sintaxe padrão utilizada na ferramenta SIO: ./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

/mnt/nfs/file.4 /mnt/nfs/file.5 /mnt/nfs/file.6

/mnt/nfs/file.7 /mnt/nfs/file.8 /mnt/nfs/file.9

Legenda: 50% leitura, 100% randômico, 8k tamanho

de bloco, 10m tamanho do arquivo em MBytes, 120

segundos de execução, 3 threads. Resultado exemplo:

SIO_NTAP:

Inputs

Read %: 50

Random %: 100

Block Size: 65536

File Size: 10485760

Secs: 120

Threads: 3

File(s): /mnt/nfs/file.0 /mnt/nfs/file.1

/mnt/nfs/file.2 /mnt/nfs/file.3 /mnt/nfs/

nt/nfs/file.6 /mnt/nfs/file.7 /mnt/nfs/file.8

/mnt/nfs/file.9

Outputs

IOPS: 1636

KB/s: 104695

IOs: 196336

sysstat (Storage) Sintaxe padrão utilizada no Sistema de Armazenamento para coleta de CPU e IOPs:

sysstat –s –c 120 1

Legenda: –s apresenta um sumário ao final do

comando, –c 120 execuções, 1 segundo de intervalo Resultado exemplo: Summary Statistics ( 120 samples 1 secs/sample) CPU NFS CIFS HTTP Net kB/s Disk kB/s in out read write Min 7% 3899 0 0 3961 5242 76 0 Avg 41% 26761 0 0 38301 24320 685 37872 Max 53% 31421 0 0 59767 35308 5540 68544

Opções configuradas no Servidor NFS Algumas configurações de NFS foram feitas no Sistema de Armazenamento que se aplicaram para todos os cenários executados: vol options nfs no_atime_update on

options nfs.tcp.recvwindowsize 65536

options nfs.tcp.xfersize 65536

options nfs.ifc.rcv.high 98304

Opções configuradas no Cliente NFS Alguns parâmetros de montagem do cliente NFS (Servidor Linux) foram mantidos para todos os cenários executados: actimeo=0,nointr,suid,timeo=600

As demais opções foram variadas em cada cenário, como tamanho de bloco e versão do protocolo. Exemplo do comando de montagem para NFSv4 e 32KBytes:

mount -t nfs4 -o rsize=32768,wsize=32768,actimeo=0,

nointr,suid,timeo=600 fas01:/vol/nfs /mnt/nfs

Referências/Bibliografia [HIRA10] Sérgio Hirata; “Análise comparativa das arquiteturas de armazenamento NAS e SAN para suporte a uma aplicação de entrada de pedidos”, Dissertação, IPT (2010) [SHEP03] S. Shepler et al; “Network File System (NFS) version 4 Protocol”, RFC 3530, USA (2003)

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