Storages com NFS: Rápidos como iSCSI e Fibre Channel
O NFS, apesar de sua fácil implementação e administração, não possui performance boa o suficiente para ser implementado em uma SAN (Storage Area Network). Isso é um MITO!
Se bem configurado e planejado, o NFS performa tão bem quanto seus concorrentes comumente vistos em storages, como o iSCSI e o Fibre Channel (FC). O segredo? Tratar o NFS da mesma forma que seus concorrentes.
Historicamente, o iSCSI é uma alternativa de menor custo ao FC, pois possibilita que seja utilizada uma infraestrutura de rede padrão, ao ponto que os FCs necessitam de hardwares especiais (switches de fibra, gbics, etc), que custam muitos dólares. A alguns anos atrás, somente conexões de fibra eram capazes de alcançar velocidaes de 1gbit/s. Atualmente, temos velocidaes de 2, 4 e até 10gbits/s via conexões de fibra. Mas o custo permanece muito elevado. Felizmente, já está disseminada no mercado a utilização de redes Ethernet Gigabit, que utilizam conexões de cobre, por um custo expressivamente menor que ao das redes de fibra. Como o preço das redes de cobre é menor, é possível que sejam comprados mais equipamentos, como placas de rede, e agregá-las para que funcionem em conjunto, conseguindo assim alcançar velocidades iguais às das conexões de fibra, E o melhor, agregando interfaces, além de desempenho, ganhamos resiliência. Ou seja, alta disponibilidade.
Interessante, certo? Mas parece complexo de implementar. Na verdade, não é. Alguns comandos básicos nos switches e no SO (Linux/Solaris), e nada mais. Leia mais sobre isso aqui e aqui.
Mas estávamos falando de performance NFS, e que ele precisava ser tratado de forma semelhante ao iSCSI/FC para que tenha o mesmo desempenho.
Um erro comum, é que o SysAdmin “monta” as partições NFS a partir de uma LAN utilizada pelos usuários e demais máquinas na rede, sem pensar que esta LAN já possui tráfego passante demais.
Em contra partida, costuma-se preparar ambientes iSCSI/FC em uma rede a parte, com interfaces e endereçamentos de rede dedicados (assim não temos concorrência no meio físico). Fica quase impossível não ter um desempenho melhor que o restante da LAN neste canal dedicado a comunicações com o storage. Ou seja, se adotarmos interfaces e IPs dedicados para o uso do NFS, teremos quase a mesma performance.
Mas por que quase? Pois não é somente ter um canal dedicado e correr para o abraço. É preciso fazer Tunning (ajuste) da configuração do NFS, para que este performe melhor. Normalmente isso é um trabalho chato e demorado, mas não tema, você não está lendo este post à toa. Vou lhe dizer tudo o que é preciso saber para ter uma boa performance.
Temos várias versões de NFS em prática no mercado, a saber:
- NFSv2: Mais antigo, mais rápido mas possui alguns bugs.
- NFSv3: Possui uma boa relação entre performance/segurança.
- NFSv4: Mais recente, mais seguro, porém mais lento.
Os melhores resultados durante a pesquisa que realizei foram com o NFSv3. Para fins de comparação, haviam os seguintes ambientes:
- Storage NetApp FAS2040 via iSCSI
- Storage NetApp FAS2040 via NFS
- Storage EMC CX3-10 via iSCSI
Não vou entrar em todos os detalhes técnicos dos testes realizados, mas falarei do que mostrou maior relevância para o usuário final: Gravação/Leitura de arquivos. Utilizamos 5000 arquivos de 100Kb cada e 1 arquivo de 500Mb. Para o arquivo maior (500Mb), não foi observada variância significativa de tempo de acesso dentre os ambientes de teste. No entanto, para os arquivos menores, a diferença foi grande. Focaremos nestes.
Qualquer controladora de discos faz um esforço muito maior no tratamento de grandes quantidades de arquivos pequenos, em relação ao tratamento de arquivos grandes. É comum levar o dobro do tempo para transferir um volume de 10Gb composto de milhares de arquivos pequenos, em relação a transferência de um único arquivo deste tamanho.
Assim sendo, o tunning do NFS precisa ser direcionado ao fato de que arquivos menores necessitam de tratamento especial. Após inúmeros testes, decidimos que estes parâmetros para montagem de um volume NFS eram os mais adequados a performance que estávamos buscando:
root@canopus:/# grep nfs /etc/vfstab | tail -1 173.11.1.100:/vol/nfs_files_e0b - /mnt/vol/files nfs - yes rw,hard,nointr,llock,vers=3,proto=tcp,rsize=524288,wsize=524288Com estas configurações, foi possível obter estes tempos de acesso:
NetApp FAS2040 NFS: Cópia de 5000 arquivos de 100kb (média de tempo):
real 0m16.985s user 0m0.221s sys 0m5.157sNetApp FAS2040 NFS: Cópia de 1 arquivo de 500Mb (média de tempo):
real 0m5.700s user 0m0.003s sys 0m3.366sNetApp FAS2040 iSCSI: Cópia de 5000 arquivos de 100kb (média de tempo):
real 0m7.458s user 0m0.221s sys 0m6.213sNetApp FAS2040 iSCSI: Cópia de 1 arquivo de 500Mb (média de tempo):
real 0m5.242s user 0m0.003s sys 0m4.300sEMC CX3-10 iSCSI: Cópia de 5000 arquivos de 100kb (média de tempo):
real 0m16.571s user 0m0.220s sys 0m6.796sEMC CX3-10 iSCSI: Cópia de 1 arquivo de 500Mb (média de tempo):
real 0m5.572s user 0m0.004s sys 0m4.352sObserve que os parâmetros NFS apresentados são um estudo de caso, e podem não atender a todos os ambientes. Então antes de colocá-los em produção, faça um teste em laboratório para ver se o comportamento será satisfatório para sua estrutura.
Nota: propositalmente não mostrei os números iniciais antes das otimizações.
O que podemos aprender disso tudo:
O NFS é rápido, fácil de implementar, fácil de administrar, não requer interação com softwares adicionais (Netapp SanTool, MPxIO, PowerPath, etc) e não possui as complexidades de lidar com LUNs, comuns em estorages que funcionam apenas com iSCSI/FC.
O VMWare, dentre muitos outros, já possui suporte nativo a NFS, e funciona muito bem.
Ah, e para os meus saudosos amigos que acham que fibra é o único meio capaz de transportar 10Gbit/s, já ouviram falar em Twinax? É de cobre, faz 10Gbit/s, e custa menos.
O que você está esperando para implementar NFS em sua SAN? Facilite sua vida!
Comentários