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

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.

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

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.

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.

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.

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.

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/

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.