Rozwiązywanie problemów z skokami opóźnień w magazynach danych NFS ESXi

44

Występują opóźnienia około Fsync wynoszące około pięciu sekund w magazynach danych NFS w ESXi, uruchamiane przez niektóre maszyny wirtualne. Podejrzewam, że może to być spowodowane przez maszyny wirtualne korzystające z NCQ / TCQ, ponieważ nie dzieje się tak w przypadku wirtualnych napędów IDE.

Można to odtworzyć za pomocą fsync-testera (Ted Ts'o) i ioping . Na przykład za pomocą systemu Grml Live z dyskiem 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 ...]

To 5 sekund, a nie milisekund. Powoduje to nawet tworzenie opóźnień we / wy na innej maszynie wirtualnej działającej na tym samym hoście i magazynie danych :

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

Kiedy przenoszę pierwszą maszynę wirtualną do lokalnego magazynu, wygląda ona zupełnie normalnie:

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 ...]

Rzeczy, których próbowałem, nie miały znaczenia:

  • Testowano kilka kompilacji ESXi: 381591, 348481, 260247
  • Testowany na innym sprzęcie, różnych urządzeniach Intel i AMD
  • Testowane na różnych serwerach NFS wszystkie wykazują takie samo zachowanie:
    • OpenIndiana b147 (synchronizacja ZFS zawsze lub wyłączona: bez różnicy)
    • OpenIndiana b148 (synchronizacja ZFS zawsze lub wyłączona: bez różnicy)
    • Linux 2.6.32 (synchronizacja lub asynchronizacja: bez różnicy)
    • Nie ma znaczenia, czy serwer NFS znajduje się na tej samej maszynie (jako wirtualne urządzenie pamięci masowej), czy na innym hoście

Testowany system operacyjny gościa, wykazujący problemy:

  • Windows 7 64 Bit (przy użyciu CrystalDiskMark, skoki opóźnień występują głównie podczas fazy przygotowywania)
  • Linux 2.6.32 (fsync-tester + ioping)
  • Linux 2.6.38 (fsync-tester + ioping)

Nie mogłem odtworzyć tego problemu na maszynach wirtualnych z systemem Linux 2.6.18.

Innym obejściem jest użycie wirtualnych dysków IDE (w porównaniu z SCSI / SAS), ale ogranicza to wydajność i liczbę dysków na maszynę wirtualną.

Aktualizacja 30.06.2011:

Skoki opóźnień wydają się występować częściej, jeśli aplikacja zapisuje wiele małych bloków przed fsync. Na przykład robi to fsync-tester (wyjście strace):

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

ioping robi to podczas przygotowywania pliku:

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

Faza konfiguracji Ioping prawie zawsze się zawiesza, podczas gdy fsync-tester czasami działa dobrze. Czy ktoś jest w stanie zaktualizować fsync-tester, aby napisał wiele małych bloków? Moje umiejętności C są do kitu;)

Aktualizacja 2011-07-02:

Ten problem nie występuje w przypadku iSCSI. Próbowałem tego na serwerze iSCSI OpenIndiana COMSTAR. Ale iSCSI nie zapewnia łatwego dostępu do plików VMDK, więc możesz przenosić je między hostami za pomocą migawek i rsync.

Aktualizacja 2011-07-06:

Jest to część przechwytywania wireshark, przechwyconego przez trzecią maszynę wirtualną na tym samym przełączniku vSwitch. Wszystko to dzieje się na tym samym hoście, bez fizycznej sieci.

Zacząłem iopować około 20. czasu. Żadne pakiety nie zostały wysłane, dopóki minęło pięć sekund:

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

2. aktualizacja 2011-07-06:

Wygląda na to, że wpływ na rozmiary okien TCP ma pewien wpływ. Nie mogłem odtworzyć tego problemu za pomocą FreeNAS (opartego na FreeBSD) jako serwera NFS. Przechwyty wireshark pokazały aktualizacje okna TCP do 29127 bajtów w regularnych odstępach czasu. Nie widziałem ich z OpenIndiana, która domyślnie używa większych rozmiarów okien.

Nie mogę już odtworzyć tego problemu, jeśli ustawię następujące opcje w OpenIndiana i zrestartuję serwer NFS:

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

Ale to zabija wydajność: Zapis z / dev / zero do pliku z dd_rescue zmienia się z 170 MB / s do 80 MB / s.

Aktualizacja 2011-07-07:

Przesłałem to przechwytywanie tcpdump (może być analizowane za pomocą wireshark). W tym przypadku 192.168.250.2 to serwer NFS (OpenIndiana b148), a 192.168.250.10 to host ESXi.

Rzeczy, które przetestowałem podczas tego przechwytywania:

Rozpoczęto „ioping -w 5 -i 0.2.” w czasie 30, 5 sekund zawiesi się w konfiguracji, ukończone w czasie 40.

Rozpoczęto „ioping -w 5 -i 0.2.” w czasie 60, 5 sekund zawiesi się w konfiguracji, ukończone w czasie 70.

Uruchomiono „fsync-tester” w czasie 90, z następującym wyjściem, zatrzymano w czasie 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. aktualizacja 2011-07-07:

Przetestowano inną maszynę wirtualną serwera NFS, tym razem wydanie społeczności NexentaStor 3.0.5: Pokazuje te same problemy.

Aktualizacja 2011-07-31:

Mogę również odtworzyć ten problem na nowej wersji ESXi 4.1.0.433742.

vmware-esxi nfs latency exo_cw
źródło
12
Muszę powiedzieć, że minęło trochę czasu, odkąd nowy użytkownik przybył do forum z tak dobrze udokumentowanym i przemyślanym pytaniem - poważnie, czapki z głów. To też jest naprawdę interesujące, wcześniej nie spotkałem się z testerem fsync, więc dziękuję. To powiedziawszy, nie jestem pewien, czy mam coś do dodania, próbowałeś już wielu rzeczy, które już bym miał - powiedziałbym, że porozmawiam z VMWare, mówiąc szczerze, są bardzo dobrzy w przyjmowaniu tego rodzaju „długiego ogona” / „nie jest to faktyczne wyłączenie usługi” poważnie. W każdym razie chciałem tylko powiedzieć, że dobrze zrobiłeś na temat tego, co do tej pory zrobiłeś :)
Chopper3,
Niestety witryna VMware nie pozwala mi się z nimi skontaktować: „Obecnie nie masz aktywnych uprawnień do pomocy technicznej”
exo_cw,
Ach, tak, to może być oczywiście problem ...
Chopper3
3
5 sekund przerwy z NFS brzmiało znajomo. W linuksowym systemie plików NFS istnieje limit czasu dla RPC wynoszący 0,7 sekundy, który podwaja się po każdym niepowodzeniu i ciągnie znacznik po 3 nieudanych próbach (ustawienia domyślne). .7 + 1,4 + 2,8 = 4,9 sekundy. Istnieje wiele różnych problemów z uwierzytelnianiem RPC, które mogą to powodować.
Mark
2
@ Ryan: przesłałem plik przechwytywania. Przesłałem również wyjście nfsstat .
exo_cw,

Odpowiedzi:

5

Wydaje się, że ten problem został rozwiązany w ESXi 5. Z powodzeniem przetestowałem kompilację 469512.

exo_cw
źródło
3

Dzięki, nfsstat wygląda dobrze. Przejrzałem zdjęcie. Nie znalazłem niczego rozstrzygającego, ale znalazłem coś interesującego. Przefiltrowałem na tcp.time_delta> 5. W każdej instancji opóźnienia znalazłem dokładny początek wywołania RPC. Nie wszystkie nowe wywołania RPC były powolne, ale wszystkie spowolnienia wystąpiły dokładnie na początku wywołania RPC. Ponadto z przechwytywania wydaje się, że 192.168.250.10 zawiera całe opóźnienie. 192.168.250.2 natychmiast odpowiada na wszystkie żądania.

Wyniki:

  • Opóźnienia występują zawsze w pierwszym pakiecie wywołania RPC
  • Typy poleceń NFS nie były skorelowane z instancjami opóźniającymi
  • Fragmentacja = opóźnia tylko pierwszy pakiet

Duże połączenie zapisu może podzielić na 300 pojedynczych pakietów TCP i tylko pierwszy z nich jest opóźniony, ale wszystkie pozostałe przelatują. Nigdy nie występuje opóźnienie w środku. Nie jestem pewien, jak rozmiar okna może tak drastycznie wpłynąć na początek połączenia.

Kolejne kroki: zacznę dostosowywać opcje NFS, takie jak NFSSVC_MAXBLKSIZE, w dół, a nie okno TCP. Zauważyłem też, że 2.6.18 działa, a 2.6.38 nie. Wiem, że w tym czasie dodano obsługę sterownika VMXnet3. Jakich sterowników karty sieciowej używasz na hostach? Odciążanie TCP tak / nie? Wokół znaku 95 sekund jest ponad 500 pakietów TCP dla pojedynczego wywołania zapisu NFS. Cokolwiek jest odpowiedzialne za TCP i rozbicie dużego PDU, może być tym, co blokuje.

Ryan
źródło
Próbowałem ustawić nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots i nfs: nfs3_bsize wszystko do 8192: Bez różnicy, te same problemy. Goście systemu Linux używają tylko dysków SCSI / SAS, bez systemu plików NFS - ESXi jest klientem systemu plików NFS, dlatego nie ma problemu ze sterownikiem sieciowym gościa systemu Linux. Po stronie serwera NFS wypróbowałem zarówno wirtualny e1000, jak i vmxnet3: bez różnicy. O ile wiem ESXi używa tylko odciążania TCP dla iSCSI.
exo_cw
Największy ? Rozumiem, dlaczego dostosowanie okna TCP miałoby znaczenie ... Moja intuicja mówi mi, że ma to coś wspólnego z fragmentowaniem tych dużych PDU przez TCP. Coś w stosie sieciowym, które go dusi. Po prostu nie mogę wymyślić niczego, co pasowałoby do zachowania, które widzimy. Jeśli rozmiar okna był problemem, powinniśmy zobaczyć opóźnienie ograniczające przepustowość w środku dużego transferu, a nie na początku, ale zawsze jest to pierwszy pakiet wywołania RPC ... trudny.
Ryan,
2

Mam coś, co wygląda na ten sam problem przy użyciu ESXi4.1U1 i maszyn wirtualnych CentOS. Hostami są Dell R610, pamięć masowa to klaster EMC2 Isilon.

Czy przypadkiem korzystałeś z VLANS? Odkryłem, że używanie VLAN na porcie VMkernel do przechowywania spowodowało zawieszenie się 4000-5000ms dla całego ruchu magazynu na VMHost. Jeśli jednak przeniosę port VMkernel poza VLAN, aby odbierał nieoznaczone pakiety, nie widzę problemu.

Poniższa prosta konfiguracja spowoduje problem w mojej sieci:

1) Zainstaluj ESXi 4.1U1 na serwerze lub stacji roboczej (oba pokazały problem, gdy próbowałem)

2) Dodaj port VMkernel w sieci VLAN.

3) Dodaj magazyn danych NFS (mój znajduje się w tej samej sieci VLAN, tj. Isilon odbiera otagowane pakiety)

4) Zainstaluj 2 maszyny wirtualne CentOS 5.5, jedną z procesorem IOP.

5) Uruchom maszyny wirtualne w tryb jednego użytkownika (tj. Bez sieci, minimalne usługi)

6) Uruchom ioping na jednej maszynie, aby zapisywać na dysk wirtualny

7) Uruchom dd lub jakoś na innym komputerze, aby zapisać 100 MB danych do / tmp lub podobnego

Najczęściej widzę, że oba VM zawieszają się na 4-5 sekund.

Naprawdę zainteresuj się, czy ktoś jeszcze widział podobne.

Nacięcie
źródło
Witaj w Server Fault! To jest stare pytanie. Jeśli odpowiedzi nie pomogą ci bezpośrednio, powinieneś zadać nowe NOWE pytanie, klikając przycisk Zadaj pytanie .
user9517 obsługuje GoFundMonica
Tak, oczywiście, że używam otagowanych sieci VLAN. Ponieważ używam ich wszędzie, nawet nie myślałem o nich jako o potencjalnym źródle tego problemu. Spróbuję odtworzyć to na nieoznakowanym porcie.
exo_cw,
Mogę odtworzyć ten problem również na nieoznaczonym porcie, bez żadnych sieci VLAN na tym hoście.
exo_cw
Właśnie próbowałem ponownie i zobaczyłem problem na nieoznakowanym porcie, jest to trochę mniej częste, może dlatego go przegapiłem. Przepraszam za bum-steer. Nie widzę problemu na 64-bitowym Win7 przy użyciu iometru, a także wydaje się, że mogę przeglądać dysk c: podczas gdy inne vms linux są zawieszone. Spróbuję z kryształowym znakiem
Nick
Właściwie chciałbym zobaczyć twoje wyniki z iometrem na Win7 x64. Mierzy opóźnienie, ale najwyższy ogólny wynik, jaki uzyskałem, to 300 ms przy użyciu testu odczytu 4k, a nie 4000 + ms
Nick
2

Dwa tygodnie temu mieliśmy dokładnie ten sam problem. ESX41 U1 i Netapp FAS3170 + NFS. Maszyny wirtualne RHEL5 zawieszają się na 2 lub 4 sekundy i widzieliśmy bardzo wysokie skoki z konsoli wydajności Virtual Center.

Proszę faceta z sieci, aby sprawdził konfigurację, a problem dotyczył przełącznika cisco. Mamy dwa łącza ethernetowe skonfigurowane w kanale Etherchannel po stronie Netapp, a nie po stronie cisco. Tworzy statyczny Ethechannel na cisco, a teraz działa dobrze. Aby zidentyfikować tego rodzaju problem, zamknij wszystkie porty oprócz jednego między filer a przełącznikiem. Pozostaw tylko jeden port przy życiu i sprawdź, jak się sprawy mają.

Drugą rzeczą, którą zrobiliśmy, było usunięcie kontroli przepływu na przełączniku i filtrze, ponieważ podejrzewamy, że wysyła ramkę pauzy.

Laurent
źródło
1

Jak wygląda Twój DNS? Czy masz /etc/resolv.confrację? Domyślny limit czasu to 5 sekund.

Od 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>).

Spróbuj dołączyć timeout:3do swojego, /etc/resolv.confa następnie ponownie uruchom testy fsync.

Joseph Kern
źródło
Próbowałem dodać to na serwerze NFS (w tym przypadku OpenIndiana) i na hoście ESXi. Niestety nie robi to różnicy. Mogę dobrze rozwiązać adres IP serwera i gościa.
exo_cw
wygląda na to, że odfiltrowałeś cały ruch niezwiązany ze strumieniem NFS, być może będziemy musieli zobaczyć więcej!
Tony Roth,
@tony roth: Właściwie to cały ruch w tym czasie. Przetestowałem to na osobnym przełączniku vSwitch z samym hostem i serwerem NFS.
exo_cw
Czy możesz zrzucić DNS za pomocą Wireshark?
Joseph Kern
@Joseph Kern: Właśnie ponownie przeanalizowałem pliki przechwytywania: Podczas przechwytywania w ogóle nie było ruchu DNS. Magazyn danych NFS jest mapowany przez IP na hoście ESXi. DNS działa dobrze na ESXi i serwerze NFS, przetestowałem wyszukiwanie do przodu i do tyłu wszystkich zaangażowanych adresów IP. W tej chwili nie mam powodu, aby sądzić, że przyczyną tego jest DNS.
exo_cw
1

Chwytasz tu słomki, ale jakich kart sieciowych używasz na tych serwerach? Sysadmini przepełnienia stosu mieli dziwne problemy z siecią z kartami sieciowymi Broadcom, które zniknęły po przejściu na karty sieciowe Intel: http://blog.serverfault.com/post/broadcom-die-mutha/

pełen werwy
źródło
Ostatnie testy przeprowadzono tylko na vSwitchu, bez fizycznej sieci (e1000 i vmxnet3: nie robiło różnicy). Ale przetestowałem to również na procesorach Intel 82574L, Intel 82576 i Intel 82567LF-3, wszystkie wykazały problem. Nie znalazłem jeszcze żadnego sprzętu, w którym nie mogę tego odtworzyć.
exo_cw
1

Oto kolejne przypuszczenie ... Czy Twój IPv6 jest włączony na hoście EXS? Jeśli tak, to spróbuj go wyłączyć? Z mojego doświadczenia wynika, że ​​jeśli cała sieć nie jest poprawnie skonfigurowana do IPv6 (tj. RADV, DHCP6, DNS, zwrotny DNS), może to stanowić problem dla niektórych usług. Upewnij się także, że jest wyłączony na serwerze NFS.

dtoubelis
źródło
Protokół IPv6 został już wyłączony na hoście ESXi. Wyłączyłem IPv6 na serwerze NFS (ifconfig -a6 jest teraz pusty), ale to nie robi różnicy: pokazuje te same problemy.
exo_cw,