NFS istemci / sunucu yığınını ayarlama

Disk görüntülerini tutan NFS üzerinden bir OpenSolaris 2009.06 makinesine bağlanan bir CentOS 5 VMWare sunucum var. Sanal makinelerim yavaş IO ile bağlı görünüyor, bu yüzden bağlantıyı optimize etmek için elimden gelen her şeyi yapmak istiyorum.

Bir üretim sistemindeki verimi ölçmenin en iyi yolundan emin değilim, ancak dd bs=1024k count=400show local (OpenSolaris) yazma işlemlerini ~ 1.6GB / s ve uzak (CentOS) yazma işlemlerinden ~ 50MB / s kullanan bazı bilimsel olmayan testler . Bunların 7 VM'nin şu anda bağlantı üzerinden çalıştığından beri aldığımdan daha düşük olduğunu düşünüyorum.

Şu anda, 2 makine, her iki NIC'de de (MTU = 9000) jumbo çerçevelerin etkin olduğu doğrudan bağlı konserdir. Bunun dışında hiçbir optimizasyon yapılmadı. NFS bağlama / verme varsayılanları kullanıyor.

Performansı artırmak için düğmeleri çevirmeye nereden başlamalıyım?

Açıklığa kavuşturmak gerekirse, tek bir Gb ethernet bağlantısı üzerinden NFS ile 50 MB / sn alıyorsunuz?

Ve ana sunucu CentOS'u VMware Server kurulu olarak çalıştırıyor, bu da 7 VM'yi çalıştırıyor mu? Daha yüksek performanslı bir çözüm olan VMware ESXi yerine CentOS ve VMware Server ile birlikte gitmenizin özel bir nedeni var mı?

50 MB / sn harika değil, ancak tek bir Gb ağ kablosu üzerinden beklediğinizin çok altında değil - NFS tweaks'i koyduktan sonra, insanların yukarıda bahsettikleri belki 70- 80MB / sn. Seçenekler:

"Ro, sert, geçişsiz, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, TCP"

muhtemelen sistemin her iki ucunda da sizin için makul olacaktır.

Bunun üstesinden gelmek için, ağ kartlarını çiftler halinde gruplandırmaya bakmanız gerekir, bu da iş hacminizi yaklaşık% 90 oranında artırmalıdır. Bağlantı birleştirme ile en iyi performansı elde etmek için 802.3ad'ı destekleyen bir anahtara ihtiyacınız olabilir .

Yine de önereceğim bir şey, OpenSolaris kutusundaki G / Ç işleminizin şüpheli bir şekilde yüksek olduğu, 12 diskin 1.6 GB / sn'lik çıkışı desteklemesi muhtemel değildir ve bu Solaris + ZFS tarafından büyük ölçüde önbelleğe alınabilir.

RHEL / CentOS 5 makinelerimiz için aşağıdaki montaj bayraklarını kullanıyoruz

nfsvers = 3, TCP timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, sert, geçişsiz, noatime

Daha yeni Linux çekirdeği sürümü, daha büyük rsize / wsize parametrelerini bile destekler, ancak EL5'teki 2.6.18 çekirdeği için maksimum 32k'dir.

NFS sunucularında, BBWC ile bir disk denetleyiciniz varsa, en azından Linux için no_wdelay sözde yardımcı olur. Ayrıca, istemcilerde noatime bayrağını kullanırsanız, dosya sistemlerini de noatime ile sunuculara monte etmek muhtemelen mantıklıdır.

Ve daha önce de belirtildiği gibi, UDP ile uğraşmayın. Daha yüksek hızlı ağlarda (1GbE +), veri bozulmasına neden olan sıra numarası sargısının küçük fakat sıfır olmayan bir şansı vardır. Ayrıca, paket kaybı olasılığı varsa, TCP UDP'den daha iyi performans gösterir.

Veri bütünlüğü konusunda bu kadar endişelenmiyorsanız, "eşzamansız" dışa aktarma seçeneği önemli bir performans artışı olabilir (eşzamansızlık sorunu, sunucu çöktüğünde veri kaybedebilmenizdir).

Ayrıca, en azından Linux sunucusu için, yeterli NFS sunucusu iş parçacığının çalıştığından emin olmanız gerekir. Varsayılan 8 çok düşük.

Bir keresinde dell r710, 1 cpu, 4 GB RAM, RAID-10 ile 6 SATA disk ile bir test yaptım. Müşteri hem CentOS 5.3 hem de nfs parametrelerine sahip, yukarıda belirtildiği gibi bir x2100 güneşiydi.

"Ro, sert, geçişsiz, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, TCP"

her iki tarafa noatime ile monte edilmiştir.

Ayrıca 256 kadar nfsds kadar çarptı ve perc6 raid denetleyicisi için noop zamanlayıcı kullandım. Yaptığım başka bir şey, bölümleri raid kontrolörünün 64K şerit boyutuna hizalamaktı.

o zaman i ile dfs nfs performansını ölçülen - okumalar için gigE boru doldurabiliriz ama yazarlar için sadece biraz daha iyi sonuçlar elde edebilirsiniz. Zaman uyumsuz etkinken ben 70 ila 80 MB / s alabilir ama asenkron benim için bir seçenek değildi.

Belki bir gigE bağlantısından nfs ile daha fazlasını elde edemezsiniz?

Bunu deneyin: Aşağıdaki iki adımla OpenSolaris NFS sunucusunda ZFS Amaç Günlüğü'nü (ZIL) geçici olarak devre dışı bırakın

1. echo zil_disable/W0t1 | mdb -kw
2. test bölümünü yeniden monte edin

Sonra tekrar test edin. Zilstat'ı artık ZIL için artık IO olmadığından emin olmak için kullanabilirsiniz . Test daha hızlı çalışırsa, performans sorununun ZIL ile ilgisi olduğunu bilirsiniz. Hala yavaş çalışıyorsa, ZIL'in suçlu olmadığını ve ZIL için bir SSD kullanmanın da yardımcı olmayacağını biliyorsunuz. ZIL hakkında daha fazla bilgi için ZFS Evil Tuning Guide'a bakın .

Başka bir seçenek, ağ trafiğini (örneğin Wireshark ile) yakalamak ve örneğin Jumbo çerçevelerinde herhangi bir sorun olup olmadığını görmek olacaktır. Kablodaki paketlerin yapılandırmanızdan beklediğiniz gibi göründüğünü doğrulayın. Devam eden kötü bir parçalanma var mı? Yeniden iletim var mı?

Okuma ve yazma yükü boyutlarını yükseltmek yardımcı olabilir. Özellikle jumbo çerçevelerle birlikte.

Ben optimum olmak için 32k bulmak eğilimindedir.

rsize=32768,wsize=32768

UDP aktarımına geçmek elbette TCP'den daha hızlıdır, çünkü iletim kontrolünün yükünü kurtarır. Ancak yalnızca güvenilir ağlarda ve NFSv4'ün kullanılmadığı yerlerde geçerlidir.

ZFS'deki NFS performansı, ZFS amaç günlüğü (ZIL) için bir SSD kullanılarak büyük ölçüde iyileştirilmiştir, çünkü bu işlemlerin gecikmesini azaltır. OpenSolaris NFS ve ZFS posta listelerindeki ZFS performansı hakkında VMWare NFS hakkındaki bu iş parçacığında , ZIL performansının darboğaz olup olmadığını görmek için bir karşılaştırma aracı da dahil olmak üzere daha fazla bilgi bulunmaktadır.

FYI dd komutu önbelleğe yazacak ve hiçbir diske yazamayacak, bu, 1,6G / s gibi çılgın sayılar alabilirsiniz, çünkü RAM'e yazıyorsunuz ve Solaris'e disk yazmıyorsunuz, "-oflag = sync" komutunu kullanarak diske yazmayı zorlayabilirsiniz