Bir GlusterFS birimi oluşturduktan sonra, uygulamanız için yeterli performansa sahip olduğunu doğrulamanız gerekir ve değilse, sorunun temel nedenini yalıtmak için bir yola ihtiyacınız vardır.

İki tür iş yükü vardır:

• sentetik – aşağıdakiler gibi bir test programı çalıştırın
• uygulama – mevcut uygulamayı çalıştır

Profil oluşturma araçları

İdeal olarak, Gluster’da çalıştırmak istediğiniz asıl uygulamayı kullanmak en iyisidir, ancak uygulamalar sistem yöneticisine performans sorunlarının, özellikle gecikme (yanıt süresi) sorunlarının nerede olduğunu çoğu zaman söylemez. Dolayısıyla, Gluster’da yerleşik olarak, uygulamanın gördüğü performansı, uygulamayı değiştirmeden ölçebilen, istilacı olmayan profil oluşturma araçları vardır. Şu anda Gluster profil oluşturma yöntemleri, io-stats çeviricisine dayanmaktadır ve şunları içerir:

• istemci tarafı profil oluşturma – profil oluşturma verilerini örneklemek için bir Gluster bağlama noktası veya libgfapi işlemi uygulayın. Bu durumda, io-stats tercümanı, tercüman yığınının “en üstünde” bulunur, bu nedenle profil verileri, uygulamanın (veya FUSE bağlama noktasının) Gluster’dan yapmasını istediği şeyi gerçekten temsil eder. Örneğin, tek bir uygulama yazma işlemi bir kez WRITE FOP (dosya işlemi) çağrısı olarak sayılır ve bu WRITE FOP’nin gecikme süresi, yığının alt kısmındaki AFR çeviricisi tarafından yapılan veri çoğaltma gecikmesini içerir.
• sunucu tarafı profil oluşturma – bu, “gluster volume profile” komutu kullanılarak yapılır (ve “gluster volume top”, kullanımda olan belirli sıcak dosyaları tanımlamak için de kullanılabilir). Sunucu tarafı profil oluşturma, zaman içinde tüm Gluster biriminin verimini ölçebilir ve sunucu tarafı gecikmelerini ölçebilir. Ancak, ağ veya istemci tarafı gecikmelerini içermez. G/Ç iş yükünü değiştiren istemci tarafı çevirmenleri (örnekler: silme kodlaması, önbellek katmanlaması) nedeniyle uygulama davranışını anlamak da zordur.

Kısacası, “uygulamam neden yanıt vermiyor”u anlamak için istemci tarafı profil oluşturmayı kullanın. ve Gluster biriminizin ne kadar meşgul olduğunu, ona ne tür bir iş yükünün uygulandığını (yani çoğunlukla okunur mu? küçük dosya mı?) ve G/Ç yükünün ne kadar iyi yayıldığını anlamak için sunucu tarafı profil oluşturmayı kullanın. hacim boyunca.

İstemci tarafı profil oluşturma

İstemci tarafı profil oluşturmayı çalıştırmak için,

• gluster hacim profili senin-hacim başlangıcın
• setfattr -n trust.io-stats-dump -v io-stats-pre.txt /your/mountpoint

/var/run/gluster/io-stats-pre.txtBu , istemcide belirtilen dosyayı ( ) oluşturur . gvp-client.sh gibi bir komut dosyası bu verilerin toplanmasını otomatikleştirebilir.

TBS: Farklı FOP’ların ne olduğu ve ne anlama geldikleri.

Sunucu taraflı profil oluşturma

Çalıştırmak için:

• gluster hacim profili senin-hacim başlangıcın
• bu komutu periyodik olarak tekrarlayın: hacim profilinizi yapıştırın hacim bilginiz
• gluster hacim profili hacim durağınız

gvp.sh gibi bir komut dosyası bu prosedürü otomatikleştirmenize yardımcı olabilir.

Bu verileri sonradan işlemek için komut dosyaları şu anda geliştirme aşamasındadır, neye ihtiyacınız olduğunu ve verileri sunmak için neyin yararlı bir format olacağını bize bildirin.

Test araçları

Bu bölümde, çok çeşitli POSIX benzeri işletim sistemleri ve çalışma zamanı ortamları için Gluster performansını uygulamadan bağımsız bir şekilde ölçmek için kullanılabilecek bazı temel iş yükü testleri öneriyoruz. Daha sonra bu sonuçları yorumlamak için bazı terminoloji ve kavramsal çerçeve sağlıyoruz.

Burada önerdiğimiz araçlar, dağıtılmış bir dosya sisteminde çalışacak şekilde tasarlanmıştır. Bu, şu anda bile dosya sistemi karşılaştırmaları için nispeten nadir bir özelliktir! Tek bir sistemden çalıştırılabilen çok daha büyük bir kıyaslama seti mevcuttur. Tek sistem sonuçları önemli olmakla birlikte, dağıtılmış bir dosya sisteminin performans yeteneklerinin kesin bir ölçüsü olmaktan uzaktır.

• fio – büyük dosya G/Ç testleri için.
• smallfile – saf iş yükü küçük dosya testleri için
• iozone – saf iş yükü büyük dosya testleri için
• parallel-libgfapi – saf iş yükü libgfapi testleri için

SPECsfs2014’ün “netmist” karma iş yükü oluşturucusu bazı durumlarda uygun olabilir, ancak teknik olarak açık kaynaklı bir araç değildir. Bu araç, iozone’un yazarı olan Don Capps tarafından yazılmıştır.

Fio Nasıl Kullanılır?

fio son derece güçlüdür ve iozone’dan farklı olarak geleneksel dağıtımlardan kolayca yüklenir ve Mayıs 2015 itibarıyla –client parametresi yukarı akışında açıklanan giderek daha güçlü dağıtılmış test yeteneklerine sahiptir. Bu modu kullanmak için her iş yükü oluşturucu ana bilgisayarı şunları kullanır:

    fio --server --daemonize=/var/run/fio-svr.pid

Ve güvenlik duvarınızın bunun için 8765 numaralı bağlantı noktasına izin verdiğinden emin olun. Artık, aşağıdaki gibi sözdizimini kullanarak ana bilgisayar kümelerinde testler çalıştırabilirsiniz:

    fio --client=workload-generator.list --output-format=json my-workload.fiojob

Bununla birlikte, fio örneklerini ayrı ana bilgisayarlarda başlatarak, tüm fio örneklerini mümkün olduğunca aynı zamana yakın başlatmaya özen göstererek, iş parçacığı başına aktarım hızını sınırlayarak ve miktar yerine çalıştırma süresini belirterek dağıtılmış test için de kullanabilirsiniz. tüm fio örneklerinin yaklaşık olarak aynı anda bitmesi için. Ardından, anlamlı bir toplu sonuç elde etmek için farklı ana bilgisayarlardan gelen fio sonuçlarını toplayabilirsiniz.

fio ayrıca farklı I/O motorlarına sahiptir, özellikle Huamin Chen, FUSE kullanmadan Gluster performansını test etmek için fio’yu kullanabilmeniz için fio için libgfapi motorunu yazdı.

Dağıtılmış modda fio sınırlamaları:

• taş duvar – fio, son iş parçacığının bir test çalıştırmasını ne zaman bitirdiğini temel alarak verimi hesaplar. Buna karşılık, iozone, FIRST iş parçacığının iş yükünü ne zaman bitirdiğini temel alarak verimi varsayılan olarak hesaplar. Bu, (aldatıcı bir şekilde?) iozone için daha yüksek verim sonuçlarına yol açabilir, çünkü kaçınılmaz olarak bitiş çizgisine diğerlerinden daha sonra topallayan bazı “gecikmiş” iplikler vardır. Bazı durumlarda, test için bir zaman sınırı belirleyerek bu sınırlamanın üstesinden gelmek mümkündür. Bu, tipik olarak tüm dosyayı/aygıtı yine de okumak/yazmak istemediğiniz rastgele G/Ç testleri için iyi çalışır.
• yanıt süreleri > 1 saniye olduğunda hata – en azından bazı durumlarda fio, fio iş parçacıkları 1 saniyeden çok daha uzun yanıt süreleriyle karşılaştığında aşırı yüksek IOPS bildirdi, bu, uygulamada adaletsizlik olduğunda dağıtılmış depolama için olabilir.
• io motorları entegre değildir.

Smallfile Dağıtılmış G/Ç Karşılaştırması Nasıl Kullanılır?

Smallfile , bir kümenin tamamında çeşitli meta veri yoğun iş yüklerinin performansını hızlı bir şekilde ölçmek için kullanılabilen python tabanlı küçük dosya dağıtılmış bir POSIX iş yükü oluşturucudur. Herhangi bir belirli dosya sistemine veya AFAIK uygulamasına bağımlılığı yoktur. Linux, Windows üzerinde çalışır ve çoğu Unix’te de çalışması gerekir. Büyük dosya iş yüklerinin performansını ölçmek için iozone kıyaslama kullanımını tamamlamayı amaçlamaktadır ve iozone ve Ric Wheeler’ın fs_mark’ından belirli kavramları ödünç almaktadır. Ben England tarafından Mart 2009’da geliştirilmiştir ve şu anda açık kaynaklıdır (Apache Lisansı v2).

Burada, bir ilk oluşturma testinde ortaya konan dosyaların daha sonra sonraki testlerde kullanıldığı tipik bir basit test dizisi verilmiştir. Bu 5’ten çok daha fazla küçük dosya işlemi türü vardır (dokümana bakın), ancak bunlar en yaygın kullanılanlardır.

    SMF="./smallfile_cli.py --top /mnt/glusterfs/smf --host-set h1,h2,h3,h4 --threads 8 --file-size 4 --files 10000 --response-times Y "
    $SMF --operation create
    for s in $SERVERS ; do ssh $h 'echo 3 > /proc/sys/vm/drop_caches' ; done
    $SMF --operation read
    $SMF --operation append
    $SMF --operation rename
    $SMF --operation delete

Iozone Nasıl Kullanılır?

Bu aracın sınırlamaları vardır, ancak -+m seçeneğini (aşağıda) kullanarak dağıtılmış testi iyi yapar.

Tüm kullanım durumlarının otomatik olarak test edilmesi için “-a” seçeneği önerilmez, çünkü:

• bu, bir testten önce okuma önbelleğini sunucuya bırakmanıza izin vermez.
• ölçülen veri noktalarının çoğu, çözdüğünüz problemle ilgisiz olacaktır.

Tek iş parçacığı testi önemli bir kullanım durumudur, ancak mevcut donanımı tam olarak kullanmak için genellikle çoklu iş parçacığı ve hatta çoklu ana bilgisayar testi yapmanız gerekir.

Verilerin kalıcı depolamaya ulaşması için geçen süreyi ölçmek için “-c -e” seçeneklerini kullanmayı düşünün. “-C” seçeneği, her bir iş parçacığının teste ne kadar katıldığını görmenizi sağlar. “-+n”, yeniden okuma ve yeniden yazma testlerini atlayarak zamandan tasarruf etmenizi sağlar. “-w” seçeneği, iozone’a eriştiği dosyaları silmemesini söyler, böylece sonraki testler bunları kullanabilir. Her testte şu seçenekleri belirtin:

• -i — test tipi, 0=yazma, 1=okuma, 2=rastgele okuma/yazma
• -r — veri aktarım boyutu — uygulama tarafından kullanılan G/Ç boyutunu simüle etmenize olanak tanır
• -s — iş parçacığı başına dosya boyutu — sistemin sabit duruma ulaşması için yeterince büyük olacak şekilde bunu seçin (genellikle birden çok GB gerekir)
• -t — iş parçacığı sayısı — aynı anda kaç alt işlem G/Ç istekleri yayınlayacak
• -F — dosya listesi — hangi dosyaların yazılacağı/okunacağı. Belirtmezseniz, varsayılan dizinde iozone.DUMMY.* dosya adları kullanılacaktır.

64 KB aktarım boyutu ve 1 GB dosya boyutuyla paylaşılan Gluster bağlama noktası dizinine /mnt/glusterfs ile 8 iş parçacıklı sıralı yazma testi örneği, aktarım hızı hesaplamasındaki dosyaları fsync() ve kapatma() zamanı dahil:

    iozone -w -c -e -i 0 -+n -C -r 64k -s 1g -t 8 -F /mnt/glusterfs/f{0,1,2,3,4,5,6,7,8}.ioz

UYARI: iozone’da rastgele G/Ç testi, rastgele okuması ve ardından tüm dosyayı rastgele yazması gereken iozone kısıtlamasıyla büyük ölçüde kısıtlanmıştır! İstediğimiz bu değil – bunun yerine dosya boyutunun veya sürenin bir kısmı için rastgele okuma/yazma yapmalı ve testin bitmesi için fazla beklemeden diske daha fazla yayılmamıza izin vermelidir. Bu nedenle fio (aşağıda), rastgele G/Ç iş yükleri için tercih edilen test aracıdır.

Dağıtılmış test, iozone yardımcı programının bir gücüdür, ancak bu, “-F” seçeneği yerine “-+m” seçeneğinin kullanılmasını gerektirir. “-+m” seçeneğiyle iletilen yapılandırma dosyası şuna benzeyen bir dizi kayıt içerir:

    hostname   directory   iozone-pathname

Ana bilgisayar adı, iozone’un kullanabileceği bir test sürücüsü makinesinin ana bilgisayar adı veya IP adresi olduğunda, dizin, o ana bilgisayar içinde kullanılacak bir dizinin yol adıdır ve iozone-yol adı, o ana bilgisayarda kullanılacak iozone yürütülebilir dosyasının tam yol adıdır. Her hedef ana bilgisayarın, iozone komutunun çalıştırıldığı ana bilgisayarın ana bilgisayar adını çözebildiğinden emin olun. Tüm hedef ana bilgisayarlar, komutu çalıştıran ana bilgisayardan parolasız ssh erişimine izin vermelidir.

Örneğin: (Burada ip adresim, iozone’un çalıştırıldığı makineyi ifade eder)

    export RSH=ssh
    iozone -+m ioz.cfg -+h my-ip-address -w -c -e -i 0 -+n -C -r 64k -s 1g -t 4

Ve ioz.cfg dosyası bu kayıtları içerir (burada /mnt/glusterfs, her test makinesindeki Gluster bağlama noktasıdır ve test-client-ip, bir istemcinin IP adresidir). Ayrıca, dosyadaki her kaydın IOZone terminolojisinde bir iş parçacığı olduğunu unutmayın. Yukarıdaki örnekte thread sayısını 4 olarak tanımladığımız için tek bir client için 4 tane kaydımız(thread) var.

    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone
    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone
    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone
    test-client-ip  /mnt/glusterfs  /usr/local/bin/iozone

Kısıtlama: iozone ayrıcalıklı olmayan bağlantı noktaları kullandığından, bazı/tüm ana bilgisayarlarda iptables’ı geçici olarak kapatmak veya değiştirmek gerekebilir. İkincil makineler, ssh aracılığıyla Birincil makineden parolasız erişimi desteklemelidir.

-+h seçeneğinin belgelenmemiş olduğunu, ancak ikincil ana bilgisayara hangi IP adresinin kullanılacağını söyler, böylece ikincil ana bilgisayarın test sürücüsünün ana bilgisayar adını çözümleyebilmesi gerekmez. my-ip-address, sonuçları ana bilgisayara geri bildirmek için ikincil kişinin bağlanması gereken IP adresidir. Bunun, ana bilgisayarın ana bilgisayar adıyla aynı olması gerekmez.

Tipik olarak, dosyayı yerleştirmek, sunuculara (ve gerekirse istemcilere) önbelleği bırakmak, sıralı okuma testi yapmak, önbelleği bırakmak, istenirse rastgele G/Ç testi yapmak için önce sıralı yazma testini çalıştırırsınız. Yukarıdaki örneği kullanarak:

    export RSH=ssh
    IOZ="iozone -+m ioz.cfg -+h my-ip-address -w -C -c -e -r 64k -+n "
     hosts="`awk '{ print $1 }' ioz.cfg`"
    $IOZ -i 0 -s 1g -t 4`\
    for n in $hosts $servers ; do \
       ssh $n 'sync; echo 1 > /proc/sys/vm/drop_caches' ; done
    $IOZ -i 1 -s 1g -t 4
    for n in $hosts $servers ; do \
       ssh $n 'sync; echo 1 > /proc/sys/vm/drop_caches' ; done
    $IOZ -i 2 -s 1g -t 4

Arabelleğe alınmış G/Ç (varsayılan) ile istemci kullanıyorsanız, önce istemci makinelere, ardından sunucu makinelerine de yukarıda gösterildiği gibi önbelleği bırakın.

paralel-libgfapi

Bu test Gluster performansını libgfapi API kullanarak, FUSE’yi atlayarak uygular – hiçbir bağlama noktası kullanılmaz. Burada mevcut .

Bunu kullanmak için, parallel_gfapi_test.sh komut dosyasındaki komut dosyası parametrelerini düzenlersiniz – bunların tümü “BU SATIRIN ALTINDA DÜZENLENEBİLİR PARAMETRE YOK” yorumunun üzerindedir. Bunlar, Gluster birim adı, o birime hizmet veren bir ana bilgisayar, dosya sayısı vb. gibi şeyleri içerir. Ardından, gfapi_perf_test yürütülebilir dosyasının belirtilen dizindeki istemci makinelere dağıtıldığından emin olun ve ardından komut dosyasını çalıştırın. Komut dosyası, tüm libgfapi iş yükü oluşturucu işlemlerini, hepsi testi aynı anda başlatacak şekilde paralel olarak başlatır. Hepsi tamamlanana kadar bekler ve ardından sonuçları sizin için toplar ve bir araya getirir.

libgfapi süreçlerinin parça başına bir soket tükettiğine dikkat edin, bu nedenle yüksek parça sayısına sahip Gluster hacimlerinde, aynı anda çalışabilen libgfapi işlemlerinin sayısında kısıtlamalar olabilir. Spesifik olarak, her ana bilgisayar yalnızca yaklaşık 30000 eşzamanlı TCP bağlantı noktasını destekleyebilir. “ulimit -n” parametresini ayarlamanız gerekebilir (kalıcı ayar için /etc/security/limits.conf “nofile” parametresine bakın).

Nesne Deposu araçları

COSBench , Intel çalışanları tarafından geliştirildi ve hem Swift hem de S3 iş yükü üretimi için çok kullanışlı.

ssbench , OpenStack Swift araç setinin bir parçasıdır ve iş yükü tanımı dosya formatına sahip komut satırı aracıdır.

İş yoğunluğu

Bir uygulama, bazı dosyaları yazmak kadar basit olabilir veya Gluster’ın üzerinde bir bulut çalıştırmak kadar karmaşık olabilir. Ancak tüm uygulamaların, kullanıcılar farkında olsun ya da olmasın, performans gereksinimleri vardır ve bu gereksinimler karşılanmazsa, sistem bir bütün olarak kullanıcı açısından işlevsel değildir. Uygulamanın zamanının çoğunu Gluster ile yaptığı aktiviteler aşağıda “iş yükü” olarak adlandırılmaktadır. Gluster dosya sistemi için “iş yükü”, uygulama tarafından Gluster’a iletilen dosya sistemi isteklerinden oluşur. İş yüküne bakmanın iki yolu vardır:

• yukarıdan aşağıya – dosya sisteminin yapmasını sağlamaya çalışan uygulama nedir?
• aşağıdan yukarıya – uygulama aslında dosya sistemine hangi istekleri üretiyor?

Veri vs meta veri

Bu sayfada sık sık “büyük dosya” veya “küçük dosya” iş yüklerine atıfta bulunuyoruz. Ama “büyük dosya” veya “küçük dosya” terimleriyle ne demek istiyoruz? “büyük dosya”, uygulama zamanının çoğunun dosyayı okumak/yazmak için harcandığı iş yüklerini ifade eden, kasten belirsiz ancak açıklayıcı bir terimdir. Bu, uygulamanın zamanının çoğunu dosyayı açmak/kapatmak veya dosyayla ilgili meta verilere erişmek için harcadığı “küçük dosya” iş yükünün aksine. Meta veri “veri hakkında veri” anlamına gelir, bu nedenle dosyanın içeriğinden ziyade dosyanın durumunu tanımlayan bilgidir. Örneğin, bir dosya adı, dizinler ve genişletilmiş öznitelikler gibi bir meta veri türüdür.

Yukarıdan aşağıya iş yükü analizi

Genellikle kullanıcıların size bu konuda yardımcı olabileceği şey budur – örneğin, bir iş yükü bir milyar .mp3 dosyasının alınmasından oluşabilir. Yanıtlanması gereken tipik sorular (yaklaşık olarak):

• dosya boyutu dağılımı nedir? Ortalamalar genellikle yeterli değildir – dosya boyutu dağılımları iki modlu olabilir (yani çoğunlukla çok büyük ve çok küçük dosya boyutlarından oluşur). TBS: Bunu toplayabilen komut dosyalarına işaretçiler sağlar.
• Dosya erişimlerinin ne kadarı okuma ve yazma işlemleridir?
• iş yükü ne kadar önbellek dostu? Aynı dosyalar farklı Gluster istemcileri tarafından veya bu istemcilerdeki farklı işlemler/iş parçacığı tarafından tekrar tekrar okunuyor mu?
• büyük dosya iş yükleri için, erişimlerin ne kadarı sıralı/rastgele? Sıralı dosya erişimi, uygulama iş parçacığının dosyayı baştan sona bayt ofset sırasına göre okuduğu/yazdığı ve rastgele dosya erişiminin tam tersi olduğu anlamına gelir – iş parçacığı herhangi bir zamanda herhangi bir ofsetten okuyabilir/yazabilir. Sanal makinenin dosya sistemi bir Gluster dosyasına gömülü olduğundan, sanal makine disk görüntülerine genellikle rastgele erişilir.

Bu sorular neden önemli? Örneğin, büyük bir dosya sıralı okuma iş yükünüz varsa, ağ yapılandırması + Gluster ve Linux okuması önemlidir. Küçük bir dosya iş yükünüz varsa, depolama yapılandırması önemlidir vb. İş yükünü temel olarak anlamadığınız sürece Gluster için hangi ayarın uygun olduğunu bilemezsiniz.

Aşağıdan yukarıya analiz

Dosya sisteminin isteklerine hizmet etmesi açısından karmaşık bir uygulama bile çok basit bir iş yüküne sahip olabilir. Uygulamanızın zamanını ne yaparak geçirdiğini bilmiyorsanız, “gluster volume profile” ve “gluster volume top” komutlarını çalıştırarak başlayabilirsiniz. Bu son derece kullanışlı araçlar, hem iş yükünü hem de bu iş yükünün performansını sınırlayan darboğazları anlamanıza yardımcı olacaktır.

TBS: Verileri kullanılabilir forma indirgeyen bu araçlar ve komut dosyaları için belgelere bağlantılar.

Yapılandırma

Bir Gluster sunucusunda, önem sırasına göre burada listelenen 4 temel donanım boyutu vardır:

• ağ – muhtemelen bir Gluster sitesinin en önemli donanım bileşeni
• erişim protokolü – dosyalara/nesnelere ulaşmak için ne tür bir istemci kullanılıyor?
• depolama – bu, hemen öne geçmek için kesinlikle çok önemlidir
• cpu – istemcide, sıcak konuları arayın (aşağıya bakın)
• bellek – okuma yoğun, önbelleğe alınabilir iş yüklerinin performansını etkileyebilir

Ağ Testi için Netperf Nasıl Kullanılır?

Ağ yapılandırmasının, dağıtılmış depolamanın performansı üzerinde büyük bir etkisi vardır, ancak küme yaşam döngüsünün planlama ve kurulum aşamalarında genellikle hak ettiği dikkat gösterilmez. Neyse ki, ağ yapılandırması genellikle ek donanım olmadan önemli ölçüde geliştirilebilir.

Ağ performansını ölçmek için netperf tabanlı bir komut dosyası kullanmayı düşünün.

Bu iki aracın amacı, birden çok ağ bağlantısını paralel olarak kullanarak, dağıtılmış depolamanın neden olduğu istenen trafik düzeyini desteklemek için tüm ağ altyapınızın kapasitesini karakterize etmektir. İkinci komut dosyası, dağıtılmış depolama için muhtemelen en gerçekçi ağ iş yüküdür.

Dağıtılmış depolamayı etkileyen en yaygın iki donanım sorunu, şaşırtıcı olmayan bir şekilde, disk sürücüsü arızaları ve ağ arızalarıdır. Bu hatalardan bazıları, sabit hatalara neden olmaz, bunun yerine performansın düşmesine neden olur. Örneğin, iki fiziksel ağ arabirimi içeren bağlı bir ağ arabirimi ile, fiziksel arabirimlerden biri (NIC/anahtar üzerindeki bağlantı noktası veya kablo) arızalanırsa, bağlı arabirim çalışmaya devam eder, ancak daha az performansa sahip olur (ne kadar daha az? bağlama moduna bağlıdır). Başka bir hata, 10-GbE Ethernet arabiriminin hızı 10-Gbps’ye otomatik olarak ayarlayamaması olabilir – bazen ağ arabirimleri bunun yerine otomatik olarak 1-Gbps’ye geçer. TCP bağlantısı yüksek oranda paket kaybı yaşıyorsa veya doğru ayarlanmazsa, donanım tarafından desteklenen tam ağ hızına ulaşamayabilir.

Öyleyse neden sadece bir tane yerine paralel netperf oturumları çalıştırıyorsunuz? Ağ topolojisi (ana bilgisayarların birbirine bağlanma şekli), özellikle ağ anahtarı ve yönlendirici topolojisi ile ilgili çeşitli ağ performans sorunları vardır ve bunlar yalnızca birkaç ana bilgisayar çifti aynı paylaşılan kaynak üzerinden trafik iletmeye çalıştığında ortaya çıkar. örneğin, raf üstü anahtarları birbirine bağlayan bir ana hat veya arka paneli değiştirmek için yetersiz bant genişliğine sahip blade tabanlı bir anahtar olabilir. Bireysel netperf/iperf oturumları bu sorunları bulamaz, ancak bu komut dosyası bulur.

Bu test, örneğin dağıtılmış bir dosya sistemi aracılığıyla veri akışını simüle etmek için kullanılabilir. 4 Gluster istemcisini simüle etmek istiyorsanız, onları c1’den c4’e kadar arayın, büyük dosyaları 2 sunucu kümesine yazın, s1 ve s2 olarak adlandırın, şu (gönderen, alıcı) çiftlerini belirleyebilirsiniz:

    (c1,s1), (c2, s2), (c3, s1), (c4, s2)

Öte yandan, okumaları simüle etmek istiyorsanız, bu (gönderen, alıcı) çiftlerini kullanabilirsiniz:

    (s1, c1), (s2, c2), (s1, c3), (s2, c4)

Karışık bir okuma-yazma iş yükünü simüle etmek için her iki çift kümesini kullanın:

    (c1,s1), (c2, s2), (c3, s1), (c4, s2), (s1, c1), (s2, c2), (s1, c3), (s2, c4)

Daha karmaşık akışlar, bir küme düğümünün bir proxy sunucusu gibi davrandığı yerel olmayan protokollerin davranışını modelleyebilir; bu, bir sunucu (yerel olmayan protokol için) ve bir istemcidir (yerel protokol için). Örneğin, bu tür protokoller genellikle, ağı tek yönlü giriş/çıkış trafiğinden farklı şekilde zorlayabilen tam çift yönlü trafiği tetikler. Örneğin, bu akış kümesini önceki akışa eklemeyi deneyin:

    (s1, s2),.(s2, s3),.(s3, s4),.(s4, s1)

Komut dosyasının üst kısmındaki yorumlar, giriş sözdizimini açıklar, ancak burada en iyi şekilde nasıl kullanılacağına dair bazı öneriler. Bu komut dosyasını genellikle, test edilen makine grubuna parolasız ssh erişimi olan bir ana düğümden veya test sürücüsünden çalıştırırsınız. Testi çalıştıran ana bilgisayarların birbirlerine ssh erişimine ihtiyacı yoktur – yalnızca ana düğümden parolasız ssh erişimine izin vermeleri gerekir. Komut dosyası kök ayrıcalıklarına dayanmaz, bu nedenle onu kök olmayan bir hesaptan çalıştırabilirsiniz. Doğru hesapta (genellikle \$HOME/.ssh/id_rsa.pub içinde) baş düğümde bir genel anahtar oluşturun ve ardından bu ortak anahtarı, teste katılan her ana bilgisayarda \$HOME/.ssh/authorized_keys öğesine ekleyin.

Göndericileri ve alıcıları, satır başına 1 ana bilgisayar olmak üzere ayrı metin dosyaları kullanarak giriyoruz. Çift için (gönderen[j], alıcı[j]), gönderici dosyasındaki j satırından gönderici[j] ve alıcı dosyasındaki j satırından alıcı[j] alırsınız. Test etmek istediğiniz arabirime karşılık gelen IP adresini/adını kullanmanız ve bu arabirimi kullanarak ana düğümden her ana bilgisayara ssh yapabilmeniz gerekir.

Sonuçlar

Önem sırasına göre değil, 3 temel performans sonucu biçimi vardır:

• çıktı — Birim zamanda ne kadar iş yapılır? En iyi ölçümler genellikle iş yüküne bağlıdır:
• büyük dosya rastgele için: IOPS
• büyük dosya sırası için: MB/sn
• küçük dosya için: dosyalar/sn
• yanıt süresi — ÖNEMLİ, dosya sistemi isteğinin tamamlanması ne kadar sürer?
• kullanım — iş yükü çalışırken donanım ne kadar meşgul?
• ölçeklenebilirlik — bir Gluster birimine sunucu eklerken yanıt süresinden ödün vermeden verimi doğrusal olarak ölçeklendirebilir miyiz?

Tipik olarak aktarım hızı sonuçları en çok dikkati çeker, ancak dağıtılmış depolama ortamında ulaşılması en zor hedef aktarım hızı değil, SÜREKLİ DÜŞÜK YANIT SÜRESİ olabilir.

Yanıt süresinin o kadar önemli olmadığı etkileşimli olmayan iş yükleri olsa da, bir kullanıcının dosya sistemiyle doğrudan etkileşime girmesi gereken her durumda yanıt süresine dikkat etmelisiniz. Dosya sistemini mutlak en yüksek verimi elde edecek şekilde ayarlamak, yüksek yanıt süresi nedeniyle kullanılamaz olan bir dosya sistemiyle sonuçlanabilir. Bir kıyaslama durumunda değilseniz, iyi bir çıktı ve yanıt süresi dengesi elde etmek istersiniz. Tipik olarak etkileşimli bir kullanıcı, çoğu yanıt süresi bundan çok daha düşük olmak üzere, her zaman 5 saniyenin altında bir yanıt süresi görmek ister. Yanıt sürelerini kontrol altında tutmak için (sistem yönetimi dahil!), herhangi bir donanım bileşeninin maksimum kullanımda çalışmasını istemezsiniz, tipik olarak %60-80 kullanım, iyi bir tepe kullanım hedefidir. Öte yandan, donanım israfını önlemek için,