Solução de problemas de picos de latência nos datastores do ESXi NFS

44

Estou com latências fsync de cerca de cinco segundos nos datastores NFS no ESXi, acionados por determinadas VMs. Suspeito que isso possa ser causado por VMs usando NCQ / TCQ, pois isso não acontece com as unidades IDE virtuais.

Isso pode ser reproduzido usando o fsync-tester (de Ted Ts'o) e o ioping . Por exemplo, usando um sistema ao vivo Grml com um disco de 8 GB:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

Isso são 5 segundos, não milissegundos. Isso até cria latências de E / S em uma VM diferente em execução no mesmo host e armazenamento de dados :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

Quando movo a primeira VM para o armazenamento local, parece perfeitamente normal:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

As coisas que tentei que não fizeram diferença:

  • Testou várias compilações ESXi: 381591, 348481, 260247
  • Testado em diferentes hardwares, diferentes caixas Intel e AMD
  • Testado com diferentes servidores NFS, todos mostram o mesmo comportamento:
    • OpenIndiana b147 (sincronização ZFS sempre ou desativada: sem diferença)
    • OpenIndiana b148 (sincronização ZFS sempre ou desativada: sem diferença)
    • Linux 2.6.32 (sincronização ou assíncrona: sem diferença)
    • Não faz diferença se o servidor NFS estiver na mesma máquina (como um dispositivo de armazenamento virtual) ou em um host diferente

SO convidado testado, mostrando problemas:

  • Windows 7 de 64 bits (usando o CrystalDiskMark, os picos de latência ocorrem principalmente durante a fase de preparação)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Não foi possível reproduzir esse problema nas VMs do Linux 2.6.18.

Outra solução alternativa é usar discos IDE virtuais (vs SCSI / SAS), mas isso limita o desempenho e o número de unidades por VM.

Atualização 2011-06-30:

Os picos de latência parecem ocorrer com mais frequência se o aplicativo gravar em vários pequenos blocos antes do fsync. Por exemplo, o fsync-tester faz isso (saída strace):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

O ioping faz isso enquanto prepara o arquivo:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

A fase de configuração do ioping quase sempre trava, enquanto o fsync-tester às vezes funciona bem. Alguém é capaz de atualizar o fsync-tester para gravar vários pequenos blocos? Minhas habilidades C sugam;)

Atualização 2011-07-02:

Esse problema não ocorre com o iSCSI. Eu tentei isso com o servidor iSCSI OpenIndiana COMSTAR. Mas o iSCSI não oferece acesso fácil aos arquivos VMDK, para que você possa movê-los entre hosts com snapshots e rsync.

Atualização 2011-07-06:

Isso faz parte de uma captura do wireshark, capturada por uma terceira VM no mesmo vSwitch. Tudo isso acontece no mesmo host, sem rede física envolvida.

Comecei a mexer por volta do tempo 20. Não havia pacotes enviados até o atraso de cinco segundos terminar:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

2a atualização 2011-07-06:

Parece haver alguma influência dos tamanhos das janelas TCP. Não consegui reproduzir esse problema usando o FreeNAS (baseado no FreeBSD) como servidor NFS. As capturas do wireshark mostraram atualizações da janela TCP para 29127 bytes em intervalos regulares. Eu não os vi com o OpenIndiana, que usa tamanhos de janela maiores por padrão.

Não consigo mais reproduzir esse problema se eu definir as seguintes opções no OpenIndiana e reiniciar o servidor NFS:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

Mas isso prejudica o desempenho: gravar de / dev / zero em um arquivo com dd_rescue vai de 170 MB / s para 80 MB / s.

Atualização 2011-07-07:

Fiz upload desta captura do tcpdump (pode ser analisada com o wireshark). Nesse caso, 192.168.250.2 é o servidor NFS (OpenIndiana b148) e 192.168.250.10 é o host ESXi.

Coisas que testei durante esta captura:

Iniciado "ioping -w 5 -i 0.2." no tempo 30, 5 segundos travado na configuração, concluído no tempo 40.

Iniciado "ioping -w 5 -i 0.2." no tempo 60, 5 segundos travar na configuração, concluída no tempo 70.

Iniciado "fsync-tester" no horário 90, com a seguinte saída, interrompido no horário 120:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

2ª atualização 2011-07-07:

Testou outra VM do servidor NFS, desta vez na comunidade NexentaStor 3.0.5: mostra os mesmos problemas.

Atualização 2011-07-31:

Também posso reproduzir esse problema no novo ESXi build 4.1.0.433742.

vmware-esxi nfs latency exo_cw
fonte
12
Devo dizer que já faz um tempo desde que um usuário novinho em folha chegou ao conselho com uma pergunta tão bem documentada e pensada - sério, tirando o chapéu para você. Também é genuinamente interessante, eu nunca encontrei o fsync-tester antes, então obrigado. Dito isto, não tenho certeza se tenho algo a acrescentar, você já tentou muitas das coisas que eu já teria - eu diria que fale com o VMWare para ser honesto, eles são muito bons em aceitar esse tipo de 'cauda longa' / 'não é uma falha real de serviço' seriamente. De qualquer forma só queria dizer bem feito o que você fez até agora :)
Chopper3
Infelizmente, o site da VMware não me permite contatá-los: "No momento, você não tem direitos de suporte ativos"
exo_cw 29/06/11
ah, sim, isso pode ser um problema, é claro ...
Chopper3
3
O tempo limite de 5 segundos com o NFS parecia familiar. No NFS do Linux, existe um tempo limite de 0,7 segundo para o RPC que dobra após cada falha e puxa um grande após três falhas (configurações padrão). 0,7 + 1,4 + 2,8 = 4,9 segundos. Há uma grande variedade de problemas de autenticação RPC que podem causar isso.
6117 Mark
2
@ Ryan: eu enviei o arquivo de captura. Também enviei a saída nfsstat .
Exo_cw 07/07

Respostas:

5

Esse problema parece estar corrigido no ESXi 5. Testei a compilação 469512 com êxito.

exo_cw
fonte
3

Obrigado, nfsstat parece ser bom. Eu revi a captura. Não encontrei nada conclusivo, mas encontrei algo interessante. Eu filtrei em tcp.time_delta> 5. O que encontrei em cada instância de atraso foi o início exato de uma chamada RPC. Nem todas as novas chamadas RPC eram lentas, mas todas as lentidões ocorreram no início exato de uma chamada RPC. Além disso, a partir da captura, parece que 192.168.250.10 contém todo o atraso. 192.168.250.2 responde imediatamente a todos os pedidos.

Constatações:

  • Sempre ocorrem atrasos no primeiro pacote de uma chamada RPC
  • Os tipos de comando NFS não foram correlacionados para atrasar instâncias
  • Fragmentação = atrasa apenas o primeiro pacote

Uma chamada de gravação grande pode ser dividida em 300 pacotes TCP individuais, e apenas o primeiro é atrasado, mas o restante é executado. O atraso nunca ocorre no meio. Não tenho certeza de como o tamanho da janela poderia afetar o início da conexão de maneira tão drástica.

Próximas etapas: eu começaria a ajustar as opções do NFS como NFSSVC_MAXBLKSIZE para baixo, em vez da janela TCP. Além disso, notei que o 2.6.18 funciona enquanto o 2.6.38 não. Eu sei que o suporte foi adicionado ao driver VMXnet3 durante esse período. Quais drivers de NIC você está usando nos hosts? Descarregamento de TCP sim / não? Em torno da marca de 95 segundos, existem mais de 500 pacotes TCP para uma única chamada de gravação NFS. O que quer que esteja encarregado do TCP e da ruptura da grande PDU pode ser o que está bloqueando.

Ryan
fonte
Eu tentei definir nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots e nfs: nfs3_bsize, tudo até 8192: sem diferença, com os mesmos problemas. Os convidados linux usam apenas seus discos SCSI / SAS, sem NFS - o ESXi é o cliente NFS, portanto, não há problema de driver de rede no convidado linux. No lado do servidor NFS, tentei o e1000 virtual e o vmxnet3: não fez diferença. Tanto quanto sei, o ESXi usa apenas a transferência de TCP para iSCSI.
Exo_cw 9/07/11
O maior ? Eu tenho é por isso que ajustar a janela TCP faria diferença ... Meu instinto me diz que é algo a ver com a fragmentação dessas grandes PDUs sobre TCP. Algo na pilha de rede que está sufocando. Só não consigo pensar em nada que se encaixe no comportamento que estamos vendo. Se o tamanho da janela era um problema, veríamos a latência restringir a largura de banda no meio de uma grande transferência, não no começo, mas é sempre o primeiro pacote da chamada RPC ... difícil.
Ryan
2

Eu tenho o que parece o mesmo problema usando ESXi4.1U1 e CentOS VM. Os hosts são Dell R610s, o armazenamento é um cluster EMC2 Isilon.

Por acaso você estava usando o VLANS? Descobri que o uso de uma VLAN na porta VMkernel para armazenamento causou a interrupção de 4000-5000ms para todo o tráfego de armazenamento no VMHost. No entanto, se eu mover a porta VMkernel da VLAN para receber pacotes não marcados, não vejo o problema.

A configuração simples abaixo causará o problema na minha rede:

1) Instale o ESXi 4.1U1 em um servidor ou estação de trabalho (ambos exibiram o problema quando tentei)

2) Adicione uma porta VMkernel em uma VLAN.

3) Adicione um armazenamento de dados NFS (o meu está na mesma VLAN, ou seja, o Isilon recebe pacotes marcados)

4) Instale 2 VMs do CentOS 5.5, uma com ioping.

5) Inicialize as VMs no modo de usuário único (ou seja, sem rede, serviços mínimos)

6) Execute o ioping em uma máquina para que esteja gravando no disco virtual

7) Execute dd ou algo assim na outra máquina para gravar 100 MB de dados em / tmp ou similar

Na maioria das vezes, vejo as duas VMs congelando por 4-5 segundos.

Seja realmente interessado em ver se alguém já viu algo parecido.

usuario
fonte
Bem-vindo à falha do servidor! Esta é uma pergunta antiga. Se as respostas não o ajudarem diretamente, faça uma nova pergunta clicando no botão Fazer pergunta .
user9517 suporta GoFundMonica
Sim, é claro que estou usando VLANs marcadas. Como os estou usando em todos os lugares, nem sequer os considerava uma fonte potencial desse problema. Vou tentar reproduzir isso em uma porta não marcada.
Exo_cw 17/12/11
Também posso reproduzir esse problema em uma porta não marcada, sem VLANs envolvidas nesse host.
Exo_cw
Eu estava apenas tentando novamente e vejo o problema na porta não marcada também, é um pouco menos frequente, talvez seja por isso que eu perdi. Desculpe pelo boi-boi. Não consigo ver o problema no Win7 de 64 bits usando o iometer, além disso, parece que posso navegar no drive c: enquanto os outros vms do linux estão travados. Vou tentar com crystaldiskmark
Nick
Na verdade, eu estaria interessado em ver seus resultados com o iometer no win7 x64. Ele mede a latência, mas o valor global mais alto que consegui foi 300ms usando o teste de 4k leitura, e não 4000 + ms
Nick
2

Tivemos exatamente o mesmo problema há duas semanas. Armazenamento de dados do ESX41 U1 e Netapp FAS3170 + NFS. As VMs RHEL5 travam por 2 ou 4 segundos e vimos picos muito altos no console de desempenho do Virtual Center.

Eu peço ao cara da rede que verifique a configuração e o problema estava no switch Cisco. Temos dois links Ethernet configurados no Etherchannel no lado Netapp e não no lado Cisco. Ele cria um Ethechannel estático no Cisco e agora funciona bem. Para identificar esse tipo de problema, desligue toda a porta, exceto uma entre o arquivador e o comutador. Deixe apenas uma porta viva e veja como estão as coisas.

A segunda coisa que fizemos foi remover o controle de fluxo no switcj e no arquivador porque suspeitamos que ele enviasse um quadro de pausa.

Laurent
fonte
1

Como é o seu DNS? Você está /etc/resolv.confcorreto? O tempo limite padrão é de 5 segundos.

De man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

Tente anexar timeout:3ao seu /etc/resolv.confe, em seguida, execute seus testes fsync novamente.

Joseph Kern
fonte
Tentei adicionar isso no servidor NFS (OpenIndiana neste caso) e no host ESXi. Infelizmente, isso não faz diferença. Eu posso resolver o IP do servidor e convidado muito bem.
Exo_cw 6/07/11
parece que você filtrou todo o tráfego não relacionado ao fluxo nfs, talvez precisemos ver mais!
tony roth
@ Tony Roth: Na verdade, esse é o tráfego inteiro naquele momento. Eu testei isso em um vSwitch separado, apenas com o host e o servidor NFS.
Exo_cw 6/07/11
Você pode despejar o DNS com o wireshark?
Joseph Kern
@ Joseph Kern: Acabei de analisar os arquivos de captura novamente: não havia tráfego DNS durante minhas capturas. O armazenamento de dados NFS é mapeado por IP no host ESXi. O DNS funciona bem no servidor ESXi e NFS, testei a pesquisa direta e inversa de todos os IPs envolvidos. No momento, não tenho motivos para acreditar que o DNS seja a causa disso.
Exo_cw 6/07/11
1

Compreendendo aqui, mas que placas de rede você está usando nesses servidores? Os administradores do Stack Overflow tiveram problemas estranhos de rede com as NICs Broadcom que desapareceram quando mudaram para as NICs da Intel: http://blog.serverfault.com/post/broadcom-die-mutha/

zippy
fonte
Os últimos testes foram feitos apenas em um vSwitch, sem rede física envolvida (e1000 e vmxnet3: não fizeram diferença). Mas também testei isso nos processadores Intel 82574L, Intel 82576 e Intel 82567LF-3, todos mostrando o problema. Ainda não encontrei nenhum hardware em que não possa reproduzir isso.
Exo_cw 9/07/11
1

Aqui está outro palpite ... O seu IPv6 está ativado no host EXS? Se sim, tente desativá-lo? Pela minha experiência, se toda a sua rede não estiver configurada corretamente para IPv6 (por exemplo, RADV, DHCP6, DNS, DNS reverso), pode ser um problema para alguns serviços. Além disso, verifique se está desativado no servidor NFS.

dtoubelis
fonte
O IPv6 já estava desativado no host ESXi. Desabilitei o IPv6 no servidor NFS (ifconfig -a6 está vazio agora), mas não faz diferença: mostra os mesmos problemas.
Exo_cw 12/07/11