Your SlideShare is downloading. ×
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Análise comparativa entre as versões 3 e 4 do protocolo NFS em arquitetura NAS, por Kléber José da Silva

1,156

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,156
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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çãoO protocolo NFSv4 tem sido pouco adotado emarquiteturas NAS, apesar de apresentar diversasmelhorias em relação a sua predecessora - a versão 3(NFSv3). Este artigo tem como objetivo avaliar odesempenho do NFSv4, comparando com o NFSv3,por meio de experimentos baseados em alterações naparametrização do cliente NFS e nas configurações doprotocolo no servidor NFS (Sistema deArmazenamento - Storage).ContextoAmbientes de grupos de servidores (clusters / farms)como correio eletrônico, web, virtualização e bancode dados necessitam armazenar seus dados em umsistema de arquivos que possibilite um acessosimultâ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 deconectado à 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 NAScompartilhado. Outra arquitetura possível é a SAN - operando com o protocolo NFS somente. O NFS é umStorage Area Network, que depende de um serviço dos protocolos mais utilizados para troca de arquivos eadicional no servidor que gerencie o sistema de armazenamento de dados com servidores quearquivos 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 pelaconectividade do Storage com a rede e servidores, e O Protocolo NFSv4principalmente pela disposição do elementoresponsá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] esistema 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 emmesmo 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 Solarisque a versão 4 é a mais recente do protocolo NFS e versão 10, por exemplo. Em algumas dessasque apresenta diversas melhorias em relação a sua distribuições o NFSv3 ainda é a versão padrão depredecessora, a versão 3 (NFSv3) – especificada na montagem do cliente NFS, como no IBM AIX versãoRFC 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 últimasstateful), aperfeiçoando técnicas de análise de versões dos servidores de virtualização vSphere daproblemas; 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 outrossistemas (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 (ServicesControl Lists, facilitando a integração com ambientes for Unix) que é pouco utilizado e suporta no máximo oWindows; NFSv3. O progresso do desenvolvimento desse cliente• Incorporação dos sub-protocolos (separados no com NFSv4 foi feito pelo CITI que disponibilizou emNFSv3: 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 servidoressimplificando a necessidade de substituir um servidor justamente para que eles possam aproveitar asNFS 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édioservidor da mesma chamada RPC (Remote Procedure prazo. Em 2006 esse processo já começou a ocorrerCall) - RPC Composto, melhorando nativamente o nos Estados Unidos conforme exposto no artigo dedesempenho de aplicações que necessitam de acesso Pohlmann e Hess [POHL06]. Neste caso oscontínuo aos arquivos. administradores de ambientes NAS passarão a utilizar a nova versão do protocolo, porém não gostariam deO aumento da complexidade como apontado por ter o desempenho do ambiente reduzido.Kirch [KIRC06] e as grandes mudanças da novaversão do protocolo conforme exposto por Harrington Para que o processo de atualização ocorra semet al. [HARR06] e Hildebrand [HILD07], associados à problemas, o administrador de um ambiente NAS devepequena base instalada dessa nova versão são os avaliar as configurações possíveis e disponíveis namotivos aparentes que fazem os administradores de nova versão que trariam um melhor desempenho.ambientes NAS continuarem a usar o NFSv3. Além deser um protocolo mais simples e leve, o NFSv3 Parametrizações do NFSv4permite a utilização do UDP como protocolo decamada de transporte, mais ágil e menos confiável do A motivação para explorar as alterações nosque o TCP. Entretanto, utilizar UDP em ambientes de parâmetros do protocolo é o fato de alguns estudos, como o de Boumenot [BOUM02], apontarem que osarmazenamento de dados, exporia ao risco de perder elementos básicos da infra-estrutura de um arquiteturapacotes em grandes volumes de trocas de arquivos NAS baseada em NFS como processador, disco eem 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 sejaEstado da Arte causada por um comportamento evitável do NFS, mediante ajustes.Em alguns países, como nos Estados Unidos eFrança, a base instalada de NFSv4 tem aumentandoao longo do tempo, como identificado pelo CITI Delegações de arquivos a clientes(Center for Information Technology Integration) - daUniversidade de Michigan e pelo projeto GNU/Linux São divididas em dois tipos: leitura e escrita, sendoNFSv4 da Bull Open Source [BULL]. possível habilitá-las isolada ou conjuntamente. Essa é uma característica nativa presente apenas na versãoA 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 acessarSistemas Operacionais baseados em Linux, o NFSv4 (leitura) e modificar (escrita) o arquivo dentro do seujá era suportado, como apontado pelo CITI. Em cache local, sem a necessidade de transferi-lo para osistemas comerciais baseados em UNIX, como IBM servidor, até que o servidor informe ao atual clienteAIX, Oracle Solaris e HP-UX ele também está
  • 3. que há outro cliente desejando acessar o mesmoarquivo. Quando isso ocorre, o arquivo submetido àalteração é atualizado no servidor. Este modelo deoperação reduz o tráfego de rede consideravelmente,casos os clientes não acessem um conjunto dearquivos concorrentemente. RPC CompostoO NFSv4 apresenta nativamente um modelo deprocedimentos compostos (RPC Compound)englobando diversas operações em somente umarequisição RPC, característica não disponível noNFSv3. Esse modelo somente é possível emdecorrência da última versão do NFS suportar apenasTCP (como já informado anteriormente) pois o RPCcomposto não é compatível com UDP, como pode servisto na figura 2 e 3 que representam as arquiteturasdas versões 3 e 4.Pohlmann e Hess [POHL06] estimam que, em média,o número de chamadas RPC da versão anterior eramcinco vezes maior que a da nova versão, ou seja, háa tendência de uma boa redução no tráfego demetadados na rede e na quantidade de IOPs do ladodo 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 ExperimentoFigura 2 – Arquitetura do NFSv2/v3Fonte: [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 paraFigura 4 – Topologia do ExperimentoFonte: elaborado pelo autor identificar eventuais gargalos. Como nenhum ponto foi observado nestes elementos, então somente oA topologia apresentada é composta por um servidor resultado dos 3 principais recursos desejados foiHP modelo Proliant DL360G5 fazendo o papel de coletado e apresentado graficamente.cliente NFS, com Sistema Operacional Linux RedHat5.2. Este servidor tem conectividade TCP/IP com o CenáriosSistema de Armazenamento NAS por meio de umcomutador Ethernet (switch) com portas Gigabit. O Um gráfico foi gerado para cada cenário:Sistema de Armazenamento é do fabricante NetAppmodelo FAS2040, com sistema operacional Cenário NFS Deleg. RPC TCP /proprietário Data ONTAP 7.3.2. Sua configuração de Arquivos Comp. UDPdiscos foi disponibilizada em RAID 6 (Redundant Array 1 v3 N/A N/A TCPof Independent Disks) formada por cinco discos de 2 v3 N/A N/A UDPdados e dois de paridade, do tipo SAS (Serial Attached 3 v4 Não Sim TCPSCSI) de 15.000 RPM (Rotations Per Minute). 4 v4 Sim Sim TCP Tabela 1 – Cenários para a execução dos testesEssa é uma topologia muito comum em ambientesNAS encontrados nas organizações, em que o No intervalo entre a execução de um cenário e outro, oSistema de Armazenamento fornece uma área ambiente foi reiniciado (servidores e storage) e oscompartilhada para servidores Linux por meio do volumes de dados de testes recriados para evitarprotocolo NFS. No papel de clientes, além de resultados eventualmente influenciados pelo cache deservidores Linux, também é comum haver servidores operações de outros cenários.monitores de máquinas virtuais da VMware e Citrix, eservidores UNIX como IBM AIX, HP-UX, e Oracle VariáveisSolaris. Presume-se que em um ambiente real a escolha doSimulação de carga de acesso tamanho de bloco seria feita baseada no conhecimento prévio do perfil da aplicação de cadaPor se tratar de um experimento em laboratório e não servidor. Dessa forma, os gráficos foram geradosum estudo de caso em ambiente real, a carga de variando o tamanho simultaneamente na montagemproduçã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 NFSv3denominada 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 dosresultados seguintes foi coletada a partir daferramenta SIO no servidor Linux e da ferramentanativa 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 peloAná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 StorageFigura 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 proporcionalmenteao tamanho de bloco utilizado. A diferença de Os resultados de utilização média de CPU ficaramresultados do TCP e UDP não foi significativa, muito próximos em todos os cenários.desencorajando inicialmente o uso de UDP devido aosriscos expostos ao ambiente. O resultado do NFSv4 Trabalhos Futurosficou abaixo do NFSv3 em todos os cenários mesmocom as funcionalidades nativas como RPC composto, Em vista das delimitações dos cenários dos testespor exemplo, que teoricamente eram para melhorar. deste artigo, nota-se que trabalhos futuros podem ser realizados alterando o perfil de aplicação configuradoOBS.: O resultado do cenário 1 (NFSv3/TCP) foi muito na ferramenta de simulação. Um exemplo seria apróximo do máximo possível para um canal Gigabit alteração da porcentagem de relação leitura x escritaethernet que seria de 128MBytes/s (1024Mbits / 8). que influencia diretamente no comportamento doNeste caso uma infra-estrutura com agregação de acesso. O sistema operacional do cliente NFScanais ethernet poderia atingir um resultado ainda também pode ser substituído para analisarmelhor, porém não foi feito devido à idéia inicial de implementações específicas como, por exemplo, docriar 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.8do NFSv4 em relação ao NFSv3 seria explorar /mnt/nfs/file.9 Outputsalterações na infra-estrutura de rede para tentar atingir IOPS: 1636um melhor desempenho do NFSv4. Primeiramente KB/s: 104695 IOs: 196336pode-se aumentar o canal de comunicação entreservidor e storage por meio de agregação de canaisethernet (Link Aggregation). Em seguida pode-se sysstat (Storage)implementar Jumbo Frames em todos os pontos decomunicação para reduzir a sobrecarga de Sintaxe padrão utilizada no Sistema demensagens 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 1explorar sua funcionalidade de jumbogramas. Legenda: –s apresenta um sumário ao final doConclusão comando, –c 120 execuções, 1 segundo de intervaloDas 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/sambiente NAS por apresentar uma melhor vazão dos in out read writedados e menor utilização de IOPs em relação à versão Min 7% 3899 0 0 3961 5242 76 04. Todavia percebe-se que essa diferença é Avgminimizada em transferências com tamanho de blocos 41% 26761 0 0 38301 24320 685 37872 Maxmaiores, possível apenas nas configurações em TCP, 53% 31421 0 0 59767 35308 5540 68544uma vez que em UDP pode-se apresentar problemasde perda de dados. Opções configuradas no Servidor NFSNão se deve descartar totalmente o uso do NFSv4 Algumas configurações de NFS foram feitas noprincipalmente nos ambientes em que suas novas Sistema de Armazenamento que se aplicaram parafuncionalidades compensariam a pequena perda de todos os cenários executados:desempenho em relação a versão anterior, justificadapela complexidade introduzida nessa nova versão. vol options nfs no_atime_update onNos casos em que ele já esteja no gargalo, um options nfs.tcp.recvwindowsize 65536 options nfs.tcp.xfersize 65536upgrade de versão poderia ajudar. Para os demais options nfs.ifc.rcv.high 98304casos, deve-se explorar um pouco mais o estudoconforme sugestões apresentadas na seção Opções configuradas no Cliente NFS“Trabalhos Futuros”. Alguns parâmetros de montagem do cliente NFSApêndices (Servidor Linux) foram mantidos para todos os cenários executados: SIO (Servidor) actimeo=0,nointr,suid,timeo=600Sintaxe 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/nfsLegenda: 50% leitura, 100% randômico, 8k tamanhode bloco, 10m tamanho do arquivo em MBytes, 120 Referências/Bibliografiasegundos de execução, 3 threads. [HIRA10] Sérgio Hirata; “Análise comparativa dasResultado exemplo: arquiteturas de armazenamento NAS e SAN paraSIO_NTAP: suporte a uma aplicação de entrada de pedidos”,InputsRead %: 50 Dissertação, IPT (2010)Random %: 100Block Size: 65536File Size: 10485760 [SHEP03] S. Shepler et al; “Network File SystemSecs: 120Threads: 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 ProtocolSpecification”, 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 toParalell File System”, Dissertação, The University ofMichigan - USA (2007)[BULL] Bull Open Source. GNU Linux/NFSv4Project. Disponível em:<http://nfsv4.bullopensource.org/>.[CITI] CITI Project: Center for InformationTechnology Integration. Disponível em:<http://www.citi.umich.edu/projects/nfsv4/linux>.[POHL06] Frank Pohlmann, Kenneth Hess; “NFSv4delivers seamless network access”, Artigo, IBMDeveloper Works, United Kingdom (2006)[BOUM02] Christopher Boumenot; “ThePerformance 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)

×