Ajustando a Pilha Cliente / Servidor NFS

Eu tenho um servidor CentOS 5 VMWare conectado a uma máquina OpenSolaris 2009.06 por NFS que contém as imagens de disco. Minhas máquinas virtuais parecem estar limitadas por E / S lentas, então eu gostaria de fazer tudo o que puder para otimizar a conexão.

Não tenho certeza da melhor maneira de medir a taxa de transferência em um sistema de produção, mas alguns testes não científicos usando dd bs=1024k count=400gravações show local (OpenSolaris) de ~ 1.6GB / se remotas (CentOS) gravam ~ 50MB / s. Eu imagino que estes são mais baixos do que o que estou obtendo, pois 7 VMs estão sendo executadas atualmente na conexão.

Atualmente, as duas máquinas são gigE conectadas diretamente com os jumbo-frames habilitados nas duas placas de rede (MTU = 9000). Fora isso, nenhuma otimização foi feita. A montagem / exportação do NFS está usando padrões.

Onde devo começar a girar os botões para melhorar o desempenho?

Só para esclarecer, você está recebendo 50 MB / s com o NFS em uma única conexão Ethernet Gb?

E o servidor host está executando o CentOS com o VMware Server instalado, que, por sua vez, executa as 7 VMs? Existe uma razão específica para você usar o CentOS e o VMware Server combinados, em vez do VMware ESXi, que é uma solução de alto desempenho?

Os 50 MB / s não são ótimos, mas não estão muito abaixo do que você esperaria em um único cabo de rede Gb - depois de inserir os ajustes do NFS que as pessoas mencionaram acima, você estará olhando talvez 70- 80MB / seg. Opções ao longo da linha de:

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

provavelmente são razoáveis ​​para você nas duas extremidades do sistema.

Para superar isso, será necessário agrupar as placas de rede em pares, o que deve aumentar sua taxa de transferência em cerca de 90%. Pode ser necessário um switch que suporte 802.3ad para obter o melhor desempenho com a agregação de links .

Uma coisa que eu sugiro é que sua taxa de transferência de E / S na caixa do OpenSolaris pareça suspeitamente alta, 12 discos provavelmente não suportam 1,6 GB / s de taxa de transferência e isso pode ser fortemente armazenado em cache pelo Solaris + ZFS.

Para nossas máquinas RHEL / CentOS 5, usamos os seguintes sinalizadores de montagem

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, rígido, intr, noatime

A versão mais recente do kernel Linux suporta parâmetros rsize / wsize ainda maiores, mas 32k é o máximo para o kernel 2.6.18 no EL5.

Nos servidores NFS, pelo menos para o Linux no_wdelay, supostamente ajuda se você tiver um controlador de disco com BBWC. Além disso, se você usar o sinalizador noatime nos clientes, provavelmente faz sentido montar os sistemas de arquivos nos servidores também com noatime.

E, como já foi mencionado, não se preocupe com o UDP. Nas redes de alta velocidade (1GbE +), há uma pequena, mas diferente de zero, chance de um número de sequência envolver causando corrupção de dados. Além disso, se houver a possibilidade de perda de pacotes, o TCP terá um desempenho melhor que o UDP.

Se você não se preocupa tanto com a integridade dos dados, a opção de exportação "assíncrona" pode ser uma grande melhoria de desempenho (o problema com a assíncrona é que você pode perder dados se o servidor travar).

Além disso, pelo menos para o servidor Linux, você precisa ter threads de servidor NFS suficientes em execução. O padrão 8 é muito baixo.

Uma vez fiz um teste com um dell r710, 1 CPU, 4 GB de RAM, 6 discos SATA com RAID-10. O cliente era um sun x2100, ambos com o CentOS 5.3 e os parâmetros nfs como mencionado acima

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

montado em ambos os lados com noatime.

Também aumentei o nfsds para 256 e usei o agendador noop para o controlador perc6 raid. Outra coisa que fiz foi alinhar as partições ao tamanho da faixa de 64K do controlador RAID.

então eu medi o desempenho do nfs com dd - para leituras eu poderia encher o tubo gigE, mas para gravações eu só consegui resultados um pouco melhores que você. Com o async ativado, eu poderia obter de 70 a 80 MB / s, mas o async não era uma opção para o meu.

Talvez você não possa obter mais com o nfs a partir de um link gigE?

Tente isso: Desative o ZIL (Zent Intent Log) temporariamente no servidor OpenSolaris NFS com as duas etapas a seguir

1. echo zil_disable/W0t1 | mdb -kw
2. monte novamente a partição de teste

Depois teste novamente. Você pode usar o zilstat para garantir que realmente não haja mais IO no ZIL. Se o teste for mais rápido, você saberá que o problema de desempenho tem algo a ver com o ZIL. Se continuar lento, você sabe que o ZIL não é o culpado e que o uso de um SSD para o ZIL também não ajudará. Consulte o ZFS Evil Tuning Guide para obter mais informações sobre o ZIL.

Outra opção seria capturar o tráfego da rede (por exemplo, com o Wireshark) e verificar se há algum problema, por exemplo, com os quadros Jumbo. Verifique se os pacotes no fio se parecem com o esperado da sua configuração. Existe alguma fragmentação ruim acontecendo? Existem retransmissões?

Aumentar os tamanhos de carga útil de leitura e gravação pode ajudar. Especialmente em conjunto com quadros jumbo.

Eu costumo achar 32k o ideal.

rsize=32768,wsize=32768

A mudança para o transporte UDP é obviamente mais rápida que o TCP, porque economiza a sobrecarga do controle de transmissão. Mas é aplicável apenas em redes confiáveis ​​e onde o NFSv4 não está em uso.

O desempenho do NFS no ZFS é bastante aprimorado usando um SSD para o ZIL (Zent Intent Log) do ZFS, pois isso reduz a latência das operações. Este tópico sobre o desempenho do VMWare NFS no ZFS nas listas de discussão do OpenSolaris NFS e ZFS contém mais informações, incluindo uma ferramenta de referência para verificar se o desempenho do ZIL é o gargalo.

Para sua informação, o comando dd gravará no cache e não no disco; você pode obter números malucos como 1,6G / s, porque está gravando na RAM e não no Solaris, pode usar o "-oflag = sync" para forçar gravações no disco