PowerStore: Depolama Dizisi Performansını Değerlendirmek için Etkili Teknikler

Not: Kıyaslama yalnızca her şey PowerStore En İyi Uygulamalarına göre ayarlanmışsa ve bağlantı veya yapılandırma sorunu yoksa geçerlidir. Aksi takdirde, test muhtemelen alakasız veriler üretir.

• Gerçek iş yükünün/ortamın ne olacağına benzeyen değişkenleri kullanarak test edin. Çoğu aracın simülatör olduğunu ve simüle edilen gerçek bir üretim iş yükünün %100'üne asla ulaşamadığını unutmayın.
• İş yükü geniş aralıklar arasındaysa, farklı blok boyutları ve erişim desenleri ile birden çok Okuma/Yazma testi yinelemesi yapmayı göz önünde bulundurun.
• Paralel veya eşzamanlı performans özellikleri sağlamak ve genel toplam aktarım hızı potansiyelinin kullanıldığından emin olmak için çok iş parçacıklı ve zaman uyumsuz işlemler veya testler kullanın. 
• İşletmenizin üretim iş yüküyle ilgili olduklarından değerlendirilen ekipmanlar için endüstri standardı karşılaştırmalı testleri göz önünde bulundurun ve inceleyin.
• Boş veya az alan kullanımlı dosya sistemine ve/veya Disk Bölümlerine göre test yapmaktan kaçının. Yazma iş yüklerinde önceden alan ayırmazsanız test sırasında anında alan ayrılması nedeniyle gecikme süresi görebilirsiniz.
• Çoğu ortamda genellikle ikisi arasında baskın olan Okuma G/Ç'yi test etmeyi unutmayın. Test sırasında ağ altyapısındaki paket/çerçeve kaybı durumlarına dikkat edin.
• Çok sayıda ana bilgisayar veya istemci içeren tipik bir ortamı simüle etmek için birden fazla aygıta karşı test ettiğinizi doğrulayın. Örneğin, PowerStore'da iyi bir sayı 16 Disk Bölümüdür. Birim sayısı genellikle kullanılan ana bilgisayar veya istemci (fiziksel veya sanal) sayısıyla eşleşir; Eşzamanlılığın sağlandığı yer burasıdır.

 

Kıyaslama Araçları ve Simülatörler
Çoğu aracın simülatör olduğunu ve muhtemelen hiçbir zaman gerçek bir üretim iş yükünün %100'ünü simüle etmediğini unutmayın. Bu kıyaslama araçları, performansın belirli durumlarda nasıl olabileceği, olması gerektiği veya olacağı hakkında bir fikir edinmek için kullanılır. Dell bu araçların sahibi değildir ve bunlarla ilişkili olabilecek herhangi bir sorun veya problemden sorumlu değildir.

Herhangi bir performans testi durumunda, zaman uyumsuz ve çoklu iş parçacığı özelliklerine sahip araçların kullanıldığından emin olun. Bu araçlara örnek olarak şunlar verilebilir:

• Esnek G/Ç Test Cihazı (FIO)
• IOmeter
• Vdbench (Oracle hesabı gerektirir)
• NFSometre (Yalnızca Fedora/NFS)
• Intel'in NAS Performans Kontrol Listesi

 

Aşağıdaki test türlerinden kaçının:

• Kopyala ve Yapıştır
• Sürükle ve Bırak
• Diske tek dosya sistemi yedekleme
• DD Testleri
• Büyüt
• Genişlik
• Mkfile
• Sıkıştırmayı Açma, Çıkarma ve Sıkıştırma

Çoğu tezgah işaretleme senaryosunda dikkat edilmesi gereken bazı şeyler vardır. Bu bölüm, iş yükü boyutunu ve özelliklerini anlamanın yerini tutmaz. Ancak geçmiş verileriniz yoksa ve PowerStore'un özelliklerini (belirli iş yükü performansını değil) karşılaştırmak için uygulamanızın davranışına ilişkin kabaca bir tahmine ihtiyacınız varsa aşağıdaki faktörleri göz önünde bulundurun:

 

 

IODepth(sıra derinliği)
Düşük bir GÇ derinliği (veya yeterince yüksek değil), duruma bağlı olarak potansiyel veriminizi sınırlayabilir. Bu nedenle, GÇ derinliğinin her zaman bir iş yükünün eşzamanlılık gereksinimlerini yansıtacak veya taklit edecek kadar yüksek olduğunu doğrulayın. Çok düşük bir GÇ derinliği, cihazı tam potansiyeliyle doğru şekilde kullanmayabilir. Ayrıca, çok yüksek bir GÇ derinliğine karşı dikkatli olun, bu cihazda bazı önemli kuyruklara neden olabilir ve cihazın servis süresine bağlı olarak sonuç olarak daha büyük yanıt süreleri olabilir. Bu, aşırı yüklenmiş bir sistemin nasıl görünebileceğini yansıtıyor olabilir.

Bu test için, 64 gibi daha gerçek dünyadaki bir şeyin GÇ derinliği ile karşılaştırıldığında, bir GÇ derinliği olduğunda sayılar önemli ölçüde daha düşüktür. Bunun bir all-flash dizisi ile olduğunu ve bu nedenle bu kavramın aşırı ancak giderek daha yaygın bir biçimde görüldüğünü unutmayın.

" IOdepth=1" test için Saniyede ~30.000 Giriş ve Çıkış İşlemi (IOPS) ort.

 

"IOdepth=64", test için ortalama ~107.000 IOPS civarındadır.

 

 

"IOdepth=256", test için ortalama ~142.000 IOPS civarındadır.

 

 

Belirtildiği gibi, çoğu yapılandırmada performans belirli bir GÇ derinliğinde dengelenir. Burada 512'lik bir sıra derinliği var ve IOPS'de 64'lük bir GÇ derinliğinden yalnızca küçük bir artış var.

GÇ derinliği=512" test için ortalama ~146.000 IOPS civarındadır.

 

 


Async vs Sync
Kullanılan iki ana motor vardır. Performans açısından en popüler ve açık ara en verimli olanı "asenkron I/O"dur. Daha az verimli ve daha az performanslı motor türü Senkron G/Ç'dir ve normalde katı veri bütünlüğü ve güvencesi gereksinimleri olan uygulamalarda kullanılır. Senkronize G/Ç, sıfıra yakın Kurtarma Noktası Amacı (RPO) çoğaltma teknolojilerinde de bulunabilir. Performans testi ve kıyaslamasında, ana bilgisayar açısından bakıldığında Zaman Uyumsuz, bir sonraki G/Ç'yi istemek için tek bir G/Ç için onay gerekmediği anlamına gelir. Zaman Uyumlu iş yüklerinde, bir sonraki G/Ç gönderilmeden önce bir Onay ve istenen sonraki her G/Ç için bir Onay (ACK) gerekir. Bu nedenle, zaman uyumlu G/Ç genellikle 1 veya daha az kuyruğa sahiptir ve kaynağı hiçbir zaman tam potansiyeliyle tam olarak kullanmaz. Zaman uyumlu işlemleri düşük veya tek iş parçacığı sayısıyla bağlamak performans potansiyelini ciddi şekilde sınırlayabilir, bu nedenle her zaman zaman uyumsuz test yaptığınızdan emin olun ve zaman uyumlu test kullanıyorsanız, uygulama ortamı açıkça belirtmediği sürece birden çok iş parçacığı kullandığınızdan emin olun.

Async (Libaio - Linux native async) = 1 thread



Sync (synchronous I/O):  

 

 

Ilmekli
İş parçacıkları önemlidir. Test, özellikle zaman uyumlu testlerde/iş yüklerinde her zaman birden çok iş parçacığı kullanılarak yapılmalıdır. Bu, bir kurumsal uygulamanın sürecinin davranışına dayalı olarak bir işin/testin birden çok yinelemesinin benzetimini yapmaya çalışmak içindir. Eşzamanlı etkinlikle birleştirilmiş birden çok iş parçacığı, bir sistemin toplam veriminin elde edildiği yerdir. Çoğu zaman uyumsuz motor birden çok iş parçacığı kullanır, bu nedenle iş parçacığı sayısı konusunda çok fazla endişelenmenize gerek yoktur. Zaman uyumlu iş yükleri sırasında yeterli iş parçacığına sahip olmadan, bir sisteme karşı yük testinin toplam potansiyel aktarım hızını önemli ölçüde sınırlayabilirsiniz.

" Çok iş parçacıklı", birden çok iş parçacığının paralel olarak çalıştığı anlamına gelir. Örneğin, zaman uyumlu bir iş yükünde 1000 IOPS'ye hizmet verebilen tek bir cihazınız varsa, bu, kuyruk olmadan 1 ms yanıt süresine sahip cihaza çıkar (bu nedenle kuyruk olmadan, hizmet süresi ve yanıt süresi eş anlamlı olmalıdır). Açıkçası, 1 ms yanıt süresine sahip cihazlar 1000 IOPS'den çok daha fazla iş yapabilir ve bu, aynı iş yükünün birden çok iş parçacığını veya paralel akışını istifleyerek elde edilir. Bu nedenle, iş parçacıklarını (veya "bu belirli işi yapan şeyleri") 10'a yükseltirseniz, artık bir cihaza 1 ms'de G/Ç yapan 10 ayrı iş parçacığınız olur. Her bir iş yükü iş parçacığı hala 1 ms alıyor, bu da her iş parçacığının hala yalnızca 1000 IOPS'ye ulaştığı anlamına geliyor, ancak şimdi bu birden çok iş parçacığı tarafından çalıştırılan tüm "işlem" veya "iş" 10.000 IOPS alıyor.

Tek bir iş parçacığıyla bir cihazın sınırlarını yeterince zorlayabilecek araçlar ve iş yükleri vardır ve bazıları daha fazlasına ihtiyaç duyar. Özetle, zaman uyumlu bir yükün benzetimini yaparken, genel yanıt süresini etkilemeden mümkün olduğunca çok iş parçacığına/çalışana/akışa sahip olmak istersiniz. İş parçacığı sayısını artırmanın olumlu bir etkiye sahip olmayı bıraktığı bir nokta vardır (cihaz %100 meşgul olduğunda). Genellikle, Zaman Uyumsuz iş yüklerinde iş parçacığı sayısı varsayılan olarak halledilir. Örneğin, aşağıda zaman uyumsuz bir iş yükü için 1 iş parçacığı ile 10 arasında önemli olmasa da bir fark görebilirsiniz. Hikayeden çıkarılacak ders, zaman uyumsuz iş yüklerinde iş parçacıkları hakkında çok fazla endişelenmenize gerek olmamasıdır. 

Buradaki tek bir iş parçacığı, "libaio" (zaman uyumsuz) altyapısını kullanarak 68.000 IOPS elde edebilir. 

 

İş parçacıklarını (numjobs) 10'a yükseltirseniz, IOPS'de yine de bir artış görebilirsiniz.

 

Zaman uyumlu iş yükleri söz konusu olduğunda, bu aşırı bir durum olsa da, bunu kötü performans gösteren bir test haline getiren iki ana faktöre sahip olabilirsiniz: zaman uyumlu yapı. 

I/O-1 gönderin, ACK'yi bekleyin, I/O-2'yi gönderin, ACK'yi bekleyin vb.

 Ve aynı amaç için birden fazla iş parçacığını istifleyememek. 

job1=G/Ç-1 gönder - job2=G/Ç-1 gönder - job3=G/Ç-1 gönder..... job1=ack al, G/Ç-2 gönder - job2=ack al, G/Ç-2 gönder - job3= ack al, G/Ç-2 gönder vb

Doğrudan bayrak

Bazı araçlarda, özellikle *nix tabanlı araçlarda/İşletim Sistemlerinde "Doğrudan G/Ç" seçeneği görebilirsiniz. Bu, "zaman uyumsuz" motorlarla kullanılabilir ve "zaman uyumlu" G/Ç ile karıştırılmamalıdır. Bu bayrak belirtilmemiş bazı araçlarda, doğrudan diske değil, sunucu önbelleğine yazıyor olabilirsiniz. Ana bilgisayar kendi önbelleğini atlayıp doğrudan diske yazmak istiyor. Bu, depolamayı test ederken önemli bir faktördür. "Doğrudan" bayrağını ayarladığınızda, teknik olarak diske yazıyorsunuz, ancak bu durumda "disk" gerçekten depolama önbelleğidir. Bu, test amacıyla hala kabul edilebilir, çünkü doğru iş yüküyle bile, bu iş yükünün gerçek dünya ortamında nasıl davrandığını simüle etmeye ve doğru bir şekilde taklit etmeye devam edersiniz, çünkü üretim yükü de onayı geri göndermeden önce önbelleğe girer. (Yalnızca arka uç millerini değil, önbellek performans numaralarını da aldığınız için aldatılmış hissetmeyin.)

 

Bant Genişliği (MB/sn) ve Aktarım Hızı (IOPS)

Test edebileceğiniz iki ana perspektif vardır. Ağ ve performans dünyasında üretilen iş genellikle veri aktarımını ifade etse de SAN/blok ortamında IOPS'yi temsil etmek için "throughput" kullanımı yaygındır. Bu nedenle, öncelikle test ettiğiniz iş yükü özelliklerini anlamanız gerekir.

Bant genişliği (MB/sn) - Bant genişliği, bir boruya veya sisteme bir kerede (veya X aralığında, genellikle "saniyede") sığdırabileceğiniz verilerin ölçüsüdür. Bu, belirli bir süre boyunca ne kadar veri aktardığınızı ölçtüğü anlamına gelir. Bant genişliği ve IOPS birbirini dışlamasa da, aynı miktarda IOPS ile daha yüksek veya daha düşük bant genişliği sayılarına sahip olabilirsiniz, hepsi blok boyutuna bağlıdır. Unutmayın, hızı bant genişliği ile ölçmüyorsunuz, hız tamamen farklı bir şeydir ve bant genişliğini etkilese de, genellikle yoğun bant genişliğine sahip iş yükleriyle kontrol edemeyeceğiniz bir şeydir. Bu nedenle, bant genişliği için test yapıyorsanız, her zaman daha büyük bloklar kullanın (mantık dahilinde), böylece G/Ç başına verileriniz IOPS için test edeceğinizden daha büyük olur, çünkü daha büyük blokların bakımı doğal olarak daha uzun sürer. Örneğin, 1 MB/sn elde etmek istiyor ancak 8 KB blok boyutları kullanıyorsanız, bunu başarmak için yaklaşık 125 IOPS'yi zorlamanız gerekir. Ancak 512 KB'lık bloklar kullanıyorsanız yalnızca iki (2) IOPS gerekir.
(125 IOPS'yi koruyup blok boyutunu 8 KB'den 512 KB'ye yükseltirseniz, şimdi 64 MB/sn'yi zorluyorsunuz!)

Ancak, tek bir G/Ç'de daha fazla veri olduğundan, bu G/Ç'nin "paketlenmesi" (bulma, bir araya getirme vb.) genellikle daha uzun sürer. Bu nedenle, servis süreleri doğal olarak daha uzun olabilir. Bazen daha küçük bir kuyruğunuz olur, bu nedenle yanıt süreleriniz doğal olarak daha yüksek olmasına rağmen oldukça yakın olmalıdır. Yanıt süresi ne kadar bant genişliği elde edebileceğiniz konusunda bir rol oynasa da, G/Ç başına ne kadar veri olduğundaki artışın genellikle bu tür bir G/Ç başına Yanıt Süresindeki (RT) herhangi bir hafif artıştan daha ağır bastığını unutmayın. Yanıt süreleri daha yüksek olduğundan, büyük bloklu iş yüklerinin rastgele olmasını istemezsiniz. Bu nedenle, bant genişliği iş yükleri sıralı olma eğilimindedir. Büyük bir blok iş yüküne rastgele bir yapı getirdiğinizde, sabit veri aktarım hızınız sürekli olarak kesintiye uğrar ve G/Ç başına biraz daha yüksek yanıt sürelerinin etkilerini hissetmeye başlarsınız.

Aktarım hızı (IOPS) - Aktarım hızı/IOPS, özellikle daha rastgele hale geldikçe küçük blok iş yüklerinde en yaygın perspektiftir. 32 KB-64 KB'nin üzerindeki herhangi bir şey büyük bir blok olarak kabul edilebilir. Aktarım hızında, yukarıda belirtilen faktörler en önemlidir (iş parçacığı sayısı, eşitleme veya zaman uyumsuz, sıra derinliği vb. gibi). Burada, X aralığında ne kadar toplam veri aktarabileceğinizi değil, hizmet vermeye çalıştığınız (her x aralıkta) bu verileri taşıyan kaç ayrı paket (G/Ç isteği) ölçmeye çalışıyorsunuz. OLTP (bankacılık) gibi ortamlar, veri ayak izleri genellikle küçük olduğu için ne kadar veri aktarabileceklerini pek umursamazlar. Ancak, bu küçük veri kümeleri meşgul olabilir ve normalde meşguldür. Bu veri kümeleri yüksek bir çarpıklığa sahiptir (az miktarda alan referans verilir, ancak agresif ve tutarlı bir şekilde değişir). Küçük veri paketleri genellikle yalnızca sayısal veya daha küçük dize değerlerine sahip blokları değiştirme/güncelleme isteklerini içerir ve bu nedenle büyük G/Ç paketleri gerekli değildir. Ancak, işlemlerin doğası gereği ve çok sayıda olduğu için, her bir talebe ayak uydurabileceğimizi doğrulamak istiyoruz. Genellikle, blok boyutu ne kadar küçük olursa, belirli bir senaryoda o kadar fazla IOPS elde edebilirsiniz ve küçük blok iş yükleri çoğunlukla rastgele erişimle ilişkilendirilse de, küçük blok sıralı iş yükleriyle daha da fazla aktarım hızı elde edebilirsiniz. Ancak, küçük blok sıralı iş yükleri spesifiktir ve yaygın değildir, bu nedenle bu senaryoları yalnızca ortamınız gerektiriyorsa test edin.