Esse problema parece estar corrigido no ESXi 5. Eu testei a compilação 469512 com sucesso.
Estou com latências de fsync de cerca de cinco segundos em datastores do NFS no ESXi, acionados por determinadas VMs. Eu suspeito que isso pode ser causado por VMs usando NCQ / TCQ, pois isso não acontece com as unidades IDE virtuais.
Isso pode ser reproduzido usando fsync-tester (por Ted Ts'o) e ioping . Por exemplo, usando um sistema live Grml com um disco de 8GB:
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 ...]
São 5 segundos, não milissegundos. Isso está até criando latências de IO em uma VM diferente em execução no mesmo host e datastore :
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 não fizeram diferença:
SO convidado testado, mostrando problemas:
Eu não consegui reproduzir este 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 blocos pequenos 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 escrever vários pequenos blocos? Minhas habilidades C são ruins;)
Atualização de 2011-07-02:
Este problema não ocorre com o iSCSI. Eu tentei isso com o servidor OpenIndiana COMSTAR iSCSI. 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 wireshark, capturada por uma terceira VM no mesmo vSwitch. Tudo isso acontece no mesmo host, sem rede física envolvida.
Eu comecei a brincar com o tempo 20. Não havia pacotes enviados até o atraso de cinco segundos:
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
2nd Update 2011-07-06:
Parece haver alguma influência dos tamanhos das janelas TCP. Eu não era capaz de reproduzir esse problema usando FreeNAS (baseado no FreeBSD) como um servidor NFS. As capturas wireshark mostraram atualizações da janela TCP em 29127 bytes em intervalos regulares. Eu não os vi com o OpenIndiana, que usa tamanhos de janela maiores por padrão.
Eu não consigo mais reproduzir este 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 mata o desempenho: Escrever de / dev / zero em um arquivo com dd_rescue vai de 170MB / s para 80MB / s.
Atualização de 2011-07-07:
Enviei esta captura do tcpdump (pode ser analisada com o wireshark). Neste caso, 192.168.250.2 é o servidor NFS (OpenIndiana b148) e 192.168.250.10 é o host ESXi.
Coisas que testei durante essa captura:
Iniciado "ioping -w 5 -i 0.2" no momento 30, 5 segundos pendurar na configuração, concluída no tempo 40.
Iniciado "ioping -w 5 -i 0.2" no tempo de 60, 5 segundos pendurar na configuração, concluída no momento 70.
Iniciou "fsync-tester" no horário 90, com a seguinte saída, interrompida 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
2nd Update 2011-07-07:
Testei outra VM do servidor NFS, desta vez a edição da comunidade NexentaStor 3.0.5: mostra os mesmos problemas.
Atualização 2011-07-31:
Eu também posso reproduzir esse problema no novo ESXi build 4.1.0.433742.
Obrigado, nfsstat parece bom. Eu revisei a captura. Não encontrei nada conclusivo, mas encontrei algo interessante. Eu filtrado em tcp.time_delta > 5. O que eu 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 todas as solicitações.
Resultados:
Uma grande chamada de gravação pode se dividir em 300 pacotes TCP individuais, e apenas o primeiro é atrasado, mas o restante é transmitido. Nunca o atraso ocorre no meio. Não tenho certeza de como o tamanho da janela pode afetar o início da conexão de forma tão drástica.
Próximos passos: 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 2.6.18 funciona enquanto 2.6.38 não. Eu sei que o suporte foi adicionado para o driver VMXnet3 durante esse período de tempo. Quais drivers da NIC você está usando nos hosts? Descarregamento de TCP sim / não? Em torno da marca de 95 segundo, há mais de 500 pacotes TCP para uma única chamada de gravação NFS. O que quer que seja encarregado do TCP e dividir a grande PDU pode ser o que está bloqueando.
Eu tenho o que parece ser o mesmo problema usando ESXi4.1U1 e CentOS VM's. Os hosts são Dell R610s, o armazenamento é um cluster do Isilon EMC2.
Você por acaso usou VLANs? Eu encontrei usando uma VLAN na porta VMkernel para armazenamento causou o 4000-5000ms 'trava' para todo o tráfego de armazenamento no VMHost. No entanto, se eu mover a porta VMkernel para fora 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 Datastore NFS (o meu está na mesma VLAN, ou seja, o Isilon recebe pacotes marcados)
4) Instale 2 CentOS 5.5 VM's, um com ioping.
5) Inicialize a VM no modo de usuário único (ou seja, sem rede, serviços mínimos)
6) Execute o ioping em uma máquina para gravar em seu disco virtual
7) Execute dd ou algo assim na outra máquina para escrever 100MB de dados para / tmp ou similar
Frequentemente, vejo o congelamento de ambas as VMs por 4 a 5 segundos.
Esteja realmente interessado em ver se alguém viu algo semelhante.
Tivemos exatamente o mesmo problema há duas semanas. Datastores ESX41 U1 e Netapp FAS3170 + NFS. As VMs do RHEL5 são interrompidas por 2 ou 4 segundos e vimos picos muito altos no console de desempenho do Virtual Center.
Eu peço ao cara da rede para verificar a configuração e o problema estava no switch cisco. Temos dois links ethernet que foram configurados no Etherchannel no lado do Netapp e não no lado do 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 as coisas estão indo.
A segunda coisa que fizemos foi remover o Controle de Fluxo no switcj e no arquivador porque suspeitamos que ele enviaria um quadro de pausa.
Como está o seu DNS? Seu /etc/resolv.conf está correto? 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:3 ao seu /etc/resolv.conf e, em seguida, execute seus testes de fsync novamente.
Agarrando palhas aqui, mas quais NICs você está usando nesses servidores? Os sysadmins do Stack Overflow tiveram problemas de rede estranhos com as NICs Broadcom que desapareceram quando mudaram para as NICs Intel: link
Aqui está outro palpite ... O seu IPv6 está ativado no host EXS? Se sim, tente desligá-lo? Da minha experiência, se toda a sua rede não está configurada corretamente para o IPv6 (por exemplo, RADV, DHCP6, DNS, DNS reverso), pode ser um problema para alguns serviços. Além disso, verifique se ele está desativado no servidor NFS.