Ajustando pilha de cliente / servidor NFS

Question

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 ligadas por IO lento, 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=400 mostram gravações locais (OpenSolaris) de ~ 1.6GB / se remoto (CentOS) escreve ~ 50MB / s. Eu imagino que estes são mais baixos do que o que eu estou realmente recebendo desde que 7 VMs estão atualmente rodando sobre a conexão.

Atualmente, as duas máquinas são conectadas diretamente com quadros jumbo habilitados em ambos os NICs (MTU = 9000). Fora isso, nenhuma otimização foi feita. O NFS mount / export está usando padrões.

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

    

Answer 1

Só para esclarecer, você está recebendo 50MB / 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 está executando as 7 VMs? Existe uma razão particular pela qual você utilizou o CentOS e o VMware Server combinados, em vez do VMware ESXi, que é uma solução de maior desempenho?

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

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

provavelmente são razoáveis para você em ambas as extremidades do sistema.

Para superar isso, você precisará procurar agrupar as placas de rede em pares, o que deve aumentar sua taxa de transferência em cerca de 90%. Você pode precisar de um switch que suporte o 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 IO na caixa do OpenSolaris soe suspeitamente alta, 12 discos não suportarão 1,6 GB / s de taxa de transferência, e isso pode ser muito armazenado pelo Solaris + ZFS.

    

Answer 2

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

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, disco, intr, noatime

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

No (s) servidor (es) NFS, pelo menos no Linux, o no_wdelay supostamente ajuda se você tiver um controlador de disco com o BBWC. Além disso, se você usar o flag noatime nos clientes, provavelmente fará sentido montar os sistemas de arquivos nos servidores com o noatime também.

E, como já foi mencionado, não se incomode com o UDP. Com redes de velocidade mais alta (1GbE +) existe uma chance pequena, mas não nula, de um número de seqüência envolvente que causa 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 está se preocupando muito com a integridade dos dados, a opção de exportação "async" pode ser uma grande melhoria no desempenho (o problema com o async é que você pode perder dados se o servidor travar).

Além disso, pelo menos para o servidor Linux, é necessário certificar-se de que você tenha threads do servidor NFS em execução. O padrão 8 é muito baixo.

    

Answer 3

Uma vez eu 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, disco, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

montado em ambos os lados com noatime.

Eu também bump up para nfsds para 256 e usei o noop scheduler para o controlador de raid perc6. Outra coisa que fiz foi alinhar as partições com o tamanho da faixa de 64K do controlador RAID.

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

Talvez você não consiga mais com o nfs de um link gigE?

    

Answer 4

Tente isto: Desabilite o Log de Intenção do ZFS (ZIL) temporariamente no servidor NFS do OpenSolaris com as duas etapas a seguir

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

Em seguida, teste novamente. Você pode usar zilstat para ter certeza de que realmente não há mais IO para o ZIL. Se o teste correr mais rápido, você sabe 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 usar um SSD para o ZIL também não ajuda. Consulte o Guia do ZFS Evil Tuning 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 que você espera da sua configuração. Existe alguma fragmentação ruim acontecendo? Existem retransmissões?

    

Answer 5

Aumentar os tamanhos de leitura e gravação pode ajudar. Especialmente em conjunto com jumbo frames.

Eu costumo encontrar 32k para ser o melhor.

rsize=32768,wsize=32768

Mudar para o transporte UDP é, obviamente, mais rápido que o TCP, porque economiza a sobrecarga do controle da transmissão. Mas só é aplicável em redes confiáveis e onde o NFSv4 não está em uso.

    

Answer 6

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

    

Answer 7

FYI o comando dd irá gravar em cache e sem disco, isso você pode obter números loucos como 1.6G / s, porque você está escrevendo para a RAM e não para o disco no Solaris você pode usar o "-oflag = sync" forçar gravações no disco