PowerScale, Isilon OneFS: Isilon'da HBase Performans Testi

Giriş

YCSB karşılaştırma paketi ve CDH 5.10 kullanarak bir Isilon X410 kümesinde bir dizi performans karşılaştırma testi gerçekleştirdik.

CAE POC laboratuvar ortamı, OneFS 8.0.0.4 ve sonraki 8.0.1.1 NFS büyük Blok akışı karşılaştırmalı testini çalıştıran 5x Isilon x410 düğümüyle yapılandırılmıştır Bu testlerden herhangi birinde teorik toplam maksimum değerlerimiz için 5 x ~700 MB/sn yazma (3,5 GB/sn) ve 5 x ~1 GB/sn okuma (5 GB/sn) beklemiz gerekir.

(9) Bilgi işlem düğümleri, 512 GB RAM ile 2,30 GHz'de 2x18C/36T-Intel Xeon® CPU E5-2697 v4 ile yapılandırılmış CentOS 7.3.1611 çalıştıran Dell PowerEdge FC630 sunucularıdır. Yerel depolama, hem işletim sistemi hem de boş alan/dökülme dosyaları için XFS olarak biçimlendirilmiş RAID 1'de 2xSSD'dir.

Ayrıca YCSB yükünü sürücüye yüklemek için kullanılan üç ek edge sunucusu da bulunur.

Bilgi işlem düğümleri ve Isilon arasındaki arka uç ağı, NIC'ler ve anahtar bağlantı noktaları için Jumbo Çerçeve seti (MTU=9162) ile 10 Gb/sn'dir.

İlk Test

İlk test serisi, genel çıktıyı etkilenen HBASE tarafındaki ilgili parametreleri belirlemektir. HBASE için yük oluşturmak için YCSB aracını kullandık. Bu ilk test, YCSB'nin "yük" aşaması ve 40 Milyon satır kullanılarak tek bir istemci (edge server) kullanılarak çalıştırılmaktadır. Bu tablo her çalıştırmadan önce silindi.
 

ycsb load hbase10 -P workloads/workloada1 -p table='ycsb_40Mtable_nr' -p columnfamily=family -threads 256 -p recordcount=40000000

hbase.regionserver.maxlogs - Maksimum Ileri Yazma Günlüğü (VENİ) dosyası sayısı. HDFS Blok Boyutu (dfs.blocksize) ile çarpınan bu değer, sunucu çöktüğü zaman tekrar oynatılmalıdır. Bu değer, diske temizleme sıklığıyla ters orantılıdır.

hbase.ubuntu.regiongrouping.numgroups - WİVIDProvider olarak Multiple HDFSFSFS KULLANıRKEN her Bir RegionServer'ın kaç adet ileri yazma günlüklerinin çalıştırılacağını ayarlar. Bu sayıda HDFS ardışık düzeniyle sonuçlanmıştır. Belirli bir Bölge için yazma işlemi yalnızca tek bir ardışık düzene gidin ve toplam RegionServer yükünü yayın.

Buraya kadar yazma işlemini paralelleştirmenin yolu, WAL sayısını artırmak ve ardından DAÜ'ye göre iş parçacığı (ardışık düzen) sayısını artırmaktır. Önceki iki tablo, belirli bir sayı için "maxlogs" 128 veya 256 için istemci tarafından gerçekten bu sayıya iten bir değişiklik olmadığını gösterir. Ancak paralelleştirmeye duyarlı parametreyi gösteren eğilim, dosya başına "ardışık düzen" sayısına göre farklılık gösterir. Bir sonraki soru, Disk G/Ç, ağ, CPU veya OneFS ile Isilon'un "nasıl bir işe yaramazsa" nerede olduğudur ve isilon istatistiklerinin rapora bakarak ne olduğuna bakarak bunu nasıl gerçekleştirebilirim?


 
Ağ ve CPU grafikleri, Isilon kümesine az yer olduğunu ve daha fazla iş için yer olduğunu gösterir. CPU % > 80, ağ bant genişliği ise 3 GB/sn'den fazla olur.



Bu çizimlerde HDFS protokolü istatistikleri ve bunların OneFS tarafından nasıl çevril ettikleri gösterilmektedir. HDFS op'ları, burada 256 MB olan dfs.blocksize'ın katılarıdır. Burada enteresan olan şey, "Isı" grafiğinin OneFS dosya operasyonlarını görüntülemesi ve yazma ile kilitlerin bağıntısını görebilirsiniz. Bu durumda HBase, EKLENEN HER yazma işlemi için ONEFS'nin TAKİP dosyasını kilitler. Bu da kümelenmiş dosya sistemindeki kararlı yazmalar için beklentimizdir. Bu testler, bu test setine sınırlayıcı faktöre katkıda bulunuyor gibi görünür.

HBase Güncelleştirmeleri

Bir sonraki test, ölçeğinde ne olduğunu bulmak için biraz daha deneme yapmak içindi. Bu nedenle oluşturmak için iyi bir saat süren bir Milyar satırlık tablo oluşturuldu ve ardından bir YCSB, "workloada" ayarlarını kullanarak 10 milyon satır güncelleştirdi (50/50 okuma/yazma). Bu, tek bir istemcide çalıştırılmış ve ayrıca YCSB iş parçacığı sayısının bir işlevi olarak çalıştırılmam için oluştur karşılayıldığım en yüksek performansı elde etmek için de bu işlemi kullandım. Bir diğer not da Isilon'un bazı ayarlarının gerçekleştirildiğini ve Veri düğümü hizmeti için performans ayarlarına sahip OneFS 8.0.1.1'e gittiğini unutmayın. Önceki çalışma setlerine kıyasla performansta görülen bir sarsıntıyı görüntülebilir. Bu çalışmalarda hbase.regionserver.maxlogs = 256 ve hbase.rpm.regiongrouping.numgroups = 20'yi ayarlamış oluruz

Bunlara bakarak belirgin olan ilk şey, yüksek iş parçacığı sayısındaki düşüş olur. Bunun bir Isilon sorunu mu, istemci tarafı sorunu mu olduğunu çok merak ediyorum. Gelecek paragraflarda bu sorunla ilgili bazı testler daha var. Ancak 200.000'den fazla Ops'u < 3m'lik bir güncelleştirme gecikme süresiyle çalıştırmanın etkileyici olduğunu da ifade bırakabilirsiniz. Bu güncelleştirme çalışmalarının her biri hızlı oldu ve bunları birer birer gerçekleştirebilirken aşağıdaki grafik, bu çalıştırmalar için Isilon düğümlerinde eşit dengeyi gösterir.



Isı grafiğinden yine dosya işlemlerin YAZILAMA İşlemleri'nin ekleme niteliğine karşılık gelen yazma ve kilitler olduğunu görebilirsiniz.

Bölge Sunucusu Ölçeklendirmesi

Sonraki test, Isilon düğümlerinin (beş) farklı sayıda bölge sunucusuna göre nasıl ücret alacağını belirlemektir. Önceki testte çalıştırılan aynı güncelleştirme komut dosyası burada çalıştırılmış. Tek bir istemci ve 51'de YCSB iş parçacıklarıyla "workloada" kullanılarak güncelleştirilen bir Milyar satırlık tablo ve 10 milyon satır da maxlog'larda ve ardışık hatlarda (sırasıyla 256 ve 20) aynı ayarı kullanıyoruz.

 
Sonuçlar bilgilendiricidir ancak şaşırtıcı değildir. HBase'in ölçeğini genişletme yapısı, Isilon'un ölçeğini genişletme yapısıyla birleştirildiğinde ve daha fazla==daha iyi. Bu, müşterilerin kendi boyutlandırma alıştırmalarının bir parçası olarak ortamlarında çalıştırmalarını öneren bir testtir. Geri dönüşlerin azaldığını görebilirsiniz ancak burada beş Isilon düğümüne sahip dokuz ağır sunucu var ve daha fazlası için yer var gibi görünüyor.

Daha Fazla İstemci

Son test serisi, test ettiğiniz sistemi bozan derin karanlık bir yerden gelir. Ne de çok geçerli bir bilimsel yöntemdir. Test edilen parametrelerdeki üst sınırın ne olduğunu bilerek bir testi bozana kadar yeniden başlatma ve arama. Bu test serisinde, istemciyi çalıştırmak için iki ek sunucum vardı. Ayrıca her birinde iki YCSB istemcisi çalıştırarak her biri 512 iş parçacığı kullanan altı adede kadar istemciyi ölçeklendirmeme olanak sağlanmıştır. Bu da genel olarak 4096 iş parçacığı olabilir. Geri gidip 600 bölgeye ayrılmış 4 Milyar satır ve 90 bölgeye ayrılmış 400 milyon satır içeren iki farklı tablo oluşturuldu.  

 



 

Bu testte tablo boyutu çok az öneme sahip. Isilon Isı grafiklerini tekrar incelerken, dört milyar satırlık tablo ile 400 Milyon satır arasındaki farklar ile çoğunlukla dahili dosya işlemleri sayısı arasında birkaç yüzde fark olduğunu görebilirsiniz.

Sonuç

HBase, genellikle ölçeği genişletme mimarileri nedeniyle Isilon'da çalıştırma için iyi bir adaydır. HBase, kendi ön belleğe alma işleminin büyük bir fazlasını gerçekleştirmektedir ve tabloyu, HBase'i verilerinizi ölçeklendirmek için iyi sayıda bölgeye böler. Başka bir deyişle, kendi ihtiyaçlarına dikkat etmek iyi bir iş çıkarır ve dosya sistemi kalıcılık için vardır. Yük testlerini gerçekten kopma noktasında itemedik ancak HBase tasarımında dört Milyar satıra baksanız ve 3 ms'den az gecikme süresiyle 800.000 işlem bekliyorsanız bu mimari bunu destekler. HBase'in kendisi için geçerli olan diğer istemci ayarları hakkında çok fazla şey değinmediyseniz tüm bu ayarların geçerli olmasını ve bu testin kapsamının ötesini beklemeniz gerekir.