ESXi NFS veri depolarındaki gecikme ani sorunlarını giderme

44

Bazı VM'ler tarafından tetiklenen, ESXi'deki NFS veri depolarında yaklaşık beş saniyelik fsync gecikmeleri yaşıyorum . Sanal IDE sürücülerinde olmadığından, NCQ / TCQ kullanan VM'lerin neden olabileceğinden şüpheleniyorum.

Bu, fsync-tester (Ted Ts'o) ve ioping kullanılarak çoğaltılabilir . Örneğin, 8GB diskli bir Grml canlı sistemi kullanmak:

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

Bu 5 saniye, milisaniye değil. Bu, aynı ana bilgisayarda ve veri deposunda çalışan farklı bir VM'de IO-gecikmeleri yaratıyor :

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

İlk VM'yi yerel depolamaya taşıdığımda tamamen normal görünüyor:

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

Denedim şeyler hiçbir fark yaratmadı:

Birkaç ESXi Yapılışı test edildi: 381591, 348481, 260247
Farklı donanım, farklı Intel ve AMD kutuları üzerinde test edilmiştir
Farklı NFS sunucuları ile test edilmiş, hepsi aynı davranışı gösterir:
- OpenIndiana b147 (ZFS senkronizasyonu her zaman veya devre dışı: fark yok)
- OpenIndiana b148 (ZFS senkronizasyonu her zaman veya devre dışı: fark yok)
- Linux 2.6.32 (senkronizasyon veya zaman uyumsuz: fark yok)
- NFS sunucusu aynı makinede (sanal depolama aygıtı olarak) veya farklı bir ana bilgisayarda bulunuyorsa, bu fark yaratmaz

Konuk işletim sistemi test edildi ve sorunları gösterdi:

Windows 7 64 Bit (CrystalDiskMark kullanarak, gecikme artışları çoğunlukla hazırlık aşamasında gerçekleşir)
Linux 2.6.32 (fsync-tester + ioping)
Linux 2.6.38 (fsync-tester + ioping)

Linux 2.6.18 VM'lerinde bu sorunu tekrar oluşturamadım.

Diğer bir geçici çözüm, sanal IDE disklerini (vs SCSI / SAS) kullanmaktır, ancak bu, performansı ve VM başına sürücü sayısını sınırlamaktadır.

2011-06-30 Güncellemesi:

Gecikme ani yükselmeleri, uygulama fsync'ten önce çok sayıda küçük blokta yazıyorsa daha sık görülür. Örneğin, fsync-tester bunu yapar (strace çıkışı):

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

ioping dosyayı hazırlarken bunu yapar:

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

İoping kurulum aşaması neredeyse her zaman askıda kalırken, fsync-tester bazen iyi çalışıyor. Birisi birden çok küçük blok yazmak için fsync-tester yazılımını güncelleme yeteneğine sahip mi? C becerilerim emmek;)

2011-07-02 Güncellemesi:

Bu sorun iSCSI ile oluşmaz. Bunu OpenIndiana COMSTAR iSCSI sunucusuyla denedim. Ancak iSCSI size VMDK dosyalarına kolay erişim sağlamaz, böylece bunları anlık görüntüleri ve rsync özellikli ana bilgisayarlar arasında taşıyabilirsiniz.

2011-07-06 Güncellemesi:

Bu, aynı vSwitch'teki üçüncü bir VM tarafından yakalanan bir wireshark yakalamanın bir parçasıdır. Tüm bunlar aynı ana bilgisayar üzerinde gerçekleşir, fiziksel bir ağ yoktur.

20. zamanın iyiyosunu başladım. Beş saniyelik gecikme sona erene kadar gönderilen hiçbir paket yoktu:

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. Güncelleme 2011-07-06:

TCP pencere boyutlarından bazı etkilerin olduğu görülüyor. Bir NFS sunucusu olarak FreeNAS (FreeBSD'ye dayanarak) kullanarak bu sorunu tekrar oluşturamadım. Wireshark yakalamaları, düzenli aralıklarla TCP penceresi güncellemelerinin 29127 bayta ulaştığını gösterdi. Onları varsayılan olarak daha büyük pencere boyutları kullanan OpenIndiana ile görmedim.

OpenIndiana'da aşağıdaki seçenekleri ayarladıysam ve NFS sunucusunu yeniden başlattıysam, bu sorunu artık oluşturamıyorum:

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

Ancak bu performansı düşürür: / dev / zero'dan dd_rescue olan bir dosyaya yazma işlemi 170 MB / sn'den 80 MB / sn'ye çıkar.

2011-07-07 Güncellemesi:

Bu tcpdump yakalamasını yükledim (wireshark ile analiz edilebilir). Bu durumda 192.168.250.2 NFS sunucusudur (OpenIndiana b148) ve 192.168.250.10 ESXi ana bilgisayarıdır.

Bu çekim sırasında test ettiklerim:

"İoping -w 5 -i 0.2" ile başladı saat 30 da, 5 saniye kurulumda, 40 saatte tamamlandı.

"İoping -w 5 -i 0.2" ile başladı saat 60, saatte 5 saniye, kurulum 70'de tamamlandı.

"Fsync-tester" 90. saatte başladı, şu çıkış 120 ile durdu:

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. Güncelleme 2011-07-07:

Başka bir NFS sunucusu VM'si test edildi, bu sefer NexentaStor 3.0.5 topluluk baskısı: Aynı sorunları gösteriyor.

2011-07-31 Güncellemesi:

Bu sorunu yeni ESXi 4.1.0.433742 sürümünde de yeniden oluşturabilirim.

vmware-esxi nfs latency

— exo_cw
kaynak

12

Yepyeni bir kullanıcının bu kadar iyi belgelenmiş ve düşünülmüş bir soru ile tahtaya gelmesinden bu yana bir süre geçtiğini söylemeliyim. Gerçekten de ilginç, fsync-test cihazına daha önce rastlamadım ya da teşekkür ederim. Ekleyecek bir şeyim olduğundan emin değildim, zaten sahip olduğum pek çok şeyi denedin - dürüst olmak için VMWare ile konuşun derdi, bu türleri almada çok başarılılar 'uzun kuyruk' / 'fiili bir servis kesintisi değil' ciddiyetle işler. Her neyse, şu ana kadar yaptığın şey hakkında iyi şeyler söylemek istedim :)

— Chopper3

Maalesef VMware web sitesi onlarla iletişim

— kurmama

ah, evet, bu elbette bir sorun olabilir ...

— Chopper3

3

NFS ile 5 saniye zaman aşina tanıdık geliyordu. Linux NFS'de, her başarısızlıktan sonra ikiye katlanan ve 3 başarısızlıktan sonra büyük bir sayı çeken RPC için .7 saniye zaman aşımı vardır (varsayılan ayarlar). .7 + 1.4 + 2.8 = 4.9 saniye. Buna neden olabilecek çok çeşitli RPC kimlik doğrulama sorunları vardır.

— Mark

2

@Ryan: Yakalama dosyasını yükledim. Ayrıca nfsstat çıktısını yükledim .

— exo_cw

5

Bu sorun ESXi 5'te düzeltilmiş görünüyor. Yapı 469512'yi başarıyla test ettim.

— exo_cw
kaynak

3

Teşekkürler, Nfsstat iyi görünüyor. Yakalamayı gözden geçirdim. Kesin bir şey bulamadım, ancak ilginç bir şey buldum. Tcp.time_delta> 5 dizininde filtreledim. Her gecikme vakasında bulduğum şey bir RPC çağrısının tam başlangıcıydı. Tüm yeni RPC çağrıları yavaş değildi, ancak tüm yavaşlamalar bir RPC çağrısının tam başlangıcında gerçekleşti. Ayrıca, yakalamadan itibaren, 192.168.250.10 tüm gecikmeyi içerdiği anlaşılıyor. 192.168.250.2 derhal tüm isteklere cevap verir.

Bulgular:

Gecikmeler, her zaman RPC çağrısının ilk paketinde gerçekleşir.
NFS Komutu türleri gecikme örnekleri ile ilişkilendirilmedi
Parçalanma = sadece ilk paketi geciktirir

Büyük bir Yazma Çağrısı, 300 ayrı TCP paketine bölünebilir ve yalnızca birincisi ertelenir, ancak geri kalan her şey geçer. Gecikme hiçbir zaman ortasında gerçekleşmez. Pencere boyutunun bağlantının başlangıcını nasıl bu kadar sert bir şekilde etkileyebileceğinden emin değilim .

Sonraki adımlar: TCP penceresi yerine NFSSVC_MAXBLKSIZE gibi NFS seçeneklerini ayarlamaya başlayacağım. Ayrıca, 2.6.18’in çalışmadığını 2.6.18’in çalıştığını fark ettim. Bu süre zarfında VMXnet3 sürücüsüne destek eklendiğini biliyorum. Ana makinelerde hangi NIC sürücülerini kullanıyorsunuz? TCP boşaltma evet / hayır? 95 saniye işaretinin çevresinde, tek bir NFS Yazma araması için 500'den fazla TCP paketi var. TCP’den sorumlu olan ve büyük PDU’yu parçalayan ne olursa olsun engelleyen şey olabilir.

— Ryan
kaynak

Nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots ve nfs: nfs3_bsize ayarlarının hepsini 8192 ye kadar ayarlamayı denedim. Linux konukları SCSI / SAS disklerini yalnızca NFS kullanmıyorlar - ESXi NFS istemcisi, bu nedenle linux konuğu için ağ sürücüsü sorunu yok. NFS sunucusu tarafında hem sanal e1000 hem de vmxnet3'ü denedim: Fark etmedim. Bildiğim kadarıyla ESXi, iSCSI için sadece TCP boşaltma kullanıyor.

— exo_cw

En büyük ? TCP penceresini ayarlamanın neden bir fark yaratacağını biliyorum ... Bağırsaklarım bana bu büyük PDU'ların TCP üzerinden parçalanması ile ilgili olduğunu söylüyor. Ağ yığında boğulan bir şey. Gördüğümüz davranışa uyacak bir şey düşünemiyorum. Eğer pencere boyutu bir sorunsa, büyük bir aktarımın ortasında bant genişliğini sınırlayan gecikmeyi görmeliyiz, başlangıçta değil, fakat her zaman RPC çağrısının ilk paketidir.

— Ryan,

2

ESXi4.1U1 ve CentOS VM'leri kullanarak aynı konuya benzeyen bir şeye sahibim. Ana bilgisayarlar Dell R610s'dur, depolama EMC2 Isilon kümesidir.

VLANS'ı kullanma şansınız oldu mu? Depolama için VMkernel portunda bir VLAN kullandım ve VMHost'taki tüm depolama trafiği için 4000-5000ms 'kilitlenmesine' neden oldu. Ancak VMkernel portunu VLAN'ın dışına çıkardıysam etiketlenmemiş paketler alırsa sorunu göremiyorum.

Aşağıdaki basit kurulum ağımdaki soruna neden olur:

1) ESXi 4.1U1'i bir sunucuya veya iş istasyonuna yükleyin (her ikisi de denediğimde sorunu gösterdi)

2) VLAN'a bir VMkernel portu ekleyin.

3) Bir NFS Veri Deposu ekleyin (benimki aynı VLAN'da, yani Isilon etiketli paketleri alıyor)

4) 2 CentOS 5.5 VM'yi, biri ioping ile kurun.

5) VM'leri tek kullanıcı moduna geçirin (yani ağ yok, minimum servisler)

6) Bir makinede ioping'i çalıştırın, böylece sanal diske yazıyor

7) / tmp veya benzeri birime 100 MB veri yazmak için dd veya diğer makinede bir şeyler çalıştırın.

Çoğunlukla, her iki VM'nin de 4-5 saniye donup donmadığını görüyorum.

Başka birinin de benzer görüp görmediğini görmek gerçekten ilgileniyor.

— Nick
kaynak

Sunucu Arızasına Hoşgeldiniz! Bu eski bir soru. Cevapları doğrudan size yardımcı olmuyorsa, Soru Sor düğmesini tıklatarak yeni bir YENİ soru sormalısınız .

— user9517, GoFundMonica

Evet, tabiki etiketli VLAN kullanıyorum. Onları heryerde kullandığım için onları bu problemin potansiyel bir kaynağı olarak düşünmedim. Bunu etiketsiz bir bağlantı noktasında yeniden oluşturmaya çalışacağım.

— exo_cw

Bu sorunu etiketsiz bir bağlantı noktasında da yeniden oluşturabilirim, bu ana bilgisayara hiçbir VLAN dahil değildir.

— exo_cw

Sadece tekrar deniyordum ve etiketsiz limandaki problemi de gördüm, biraz daha az sıklıkta, belki de bu yüzden kaçırdım. Serseri-yönlendirici için üzgünüm. Win7 64 bit'teki sorunu iometre kullanarak göremiyorum, artı c: sürücüyü gezerken diğer Linux vms kapatılmış gibi görünüyor. Ben crystaldiskmark

— Nick

Aslında sonuçlarınızı win7 x64'teki iometer ile görmek istiyorum. Gecikme süresini ölçüyor ancak elde ettiğim en yüksek rakam 4000 + ms değil 4k okuma testini kullanarak 300ms idi

— Nick

2

İki hafta önce de aynı sorunu yaşadık. ESX41 U1 ve Netapp FAS3170 + NFS Veri Merkezleri. RHEL5 VM'ler 2 ya da 4 saniye bekler ve Virtual Center performans konsolundan çok büyük yükselmeler gördük.

Ağ elemanından konfigürasyonu kontrol etmesini rica ediyorum ve sorun cisco anahtarındaydı. Netapp tarafında Etherchannel'de yapılandırılmış iki cisnet bağlantımız var, cisco tarafında değil. Cisco'da statik bir Ethechannel yaratıyor ve şimdi iyi çalışıyor. Bu tür bir sorunu tanımlamak için, doldurucu ve anahtar arasındakiler dışındaki tüm portları kapatın. Sadece bir limanı canlı bırakın ve işlerin nasıl yürüdüğünü görün.

Yaptığımız ikinci şey, switcj ve filer üzerindeki Flow Control'ü kaldırmaktı, çünkü duraklama çerçevesi gönderdiğinden şüphelendik.

— Laurent
kaynak

1

DNS'iniz nasıl görünüyor? Sizin mi /etc/resolv.confdoğru? Varsayılan zaman aşımı 5 saniyedir.

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

Ekleme deneyin timeout:3adresinden Müşteri /etc/resolv.confve sonra tekrar fsync testleri.

— Joseph Kern
kaynak

Bunu NFS sunucusuna (bu durumda OpenIndiana) ve ESXi ana bilgisayarına eklemeye çalıştım. Ne yazık ki bu bir fark yaratmıyor. Sunucuyu ve misafir IP’sini çözebilirim.

— exo_cw

nfs akışıyla ilgili olmayan tüm trafiği filtrelemiş gibisiniz, daha fazlasını görmemiz gerekebilir!

— Tony Roth

@ tony roth: Aslında o zaman tüm trafik budur. Bunu sadece ana bilgisayar ve üzerindeki NFS sunucusu ile ayrı bir vSwitch üzerinde test ettim.

— exo_cw

DNS'yi wireshark ile silebilir misiniz?

— Joseph Kern,

@Joseph Kern: Yakalama dosyalarını tekrar analiz ettim: Yakalamalarımda hiç DNS trafiği yoktu. NFS veri deposu, ESXi ana bilgisayarında IP ile eşlenir. DNS, ESXi ve NFS sunucusunda iyi çalışır, ilgili tüm IP'lerin ileriye ve geriye doğru aramasını test ettim. Şu anda, DNS'nin bunun nedeni olduğuna inanmak için hiçbir nedenim yok.

— exo_cw

1

Buradaki payetlere hakim olmak, ancak bu sunucularda hangi NIC'leri kullanıyorsunuz? Yığın Taşması sistem yöneticileri, Intel NIC'lere geçtiklerinde kaybolan Broadcom NIC'lerle ilgili garip ağ sorunları yaşadılar: http://blog.serverfault.com/post/broadcom-die-mutha/

— hareketli
kaynak

Son testler yalnızca bir vSwitch üzerinde yapıldı, fiziksel ağ yoktu (e1000 ve vmxnet3: fark yaratmadı). Ancak bunu, sorunu gösteren Intel 82574L, Intel 82576 ve Intel 82567LF-3 üzerinde de test ettim. Henüz bir çoğunu bulamadım hiçbir yerde bulamadım.

— exo_cw

1

İşte bir başka tahmin ... IPv6'nız EXS sunucusunda etkin mi? Eğer öyleyse, kapatmayı deneyin? Tecrübelerime göre, tüm ağınız IPv6 için uygun şekilde yapılandırılmadıysa (örn. RADV, DHCP6, DNS, ters DNS), bazı servisler için bir problem olabilir. Ayrıca, NFS sunucusunda kapalı olduğundan emin olun.

— dtoubelis
kaynak

IPv6, ESXi ana bilgisayarında zaten devre dışı bırakıldı. NFS sunucusundaki IPv6'yı devre dışı bıraktım (ifconfig -a6 şu anda boş), ancak bir fark yaratmıyor: Aynı sorunları gösteriyor.

— exo_cw