PowerScale, Isilon OneFS: Isilon'da HBase Performans Testi

Gerekli değil

Gerekli değil

Giriş

Bir Isilon X410 kümesi üzerinde YCSB karşılaştırmalı test paketi ve CDH 5.10 kullanılarak bir dizi performans kıyaslama testi gerçekleştirilmiştir.

Laboratuvar test ortamı, OneFS v8.0.0.4 ve sonraki v8.0.1.1 sürümlerini çalıştıran beş Isilon x410 düğümüyle yapılandırıldı. Network File System (NFS) Büyük Blok akışı karşılaştırmalı testleri çalıştırıldı. Testler için beklenen teorik toplam maksimum, düğüm başına ~700 MB/sn (3,5 GB/sn) yazma ve ~1 GB/sn okuma (5 GB/sn) idi.

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

Ayrıca YCSB yükünü sürmek için kullanılan üç ek Edge sunucusu da vardı.

Bilgi işlem düğümleri ile Isilon arasındaki arka uç ağı, NIC'ler ve anahtar bağlantı noktaları için ayarlanmış Jumbo Frame'lerle (MTU=9162) 10 Gb/sn'dir.
CDH 5.10, Isilon Kümesindeki bir Erişim Bölgesinde çalışacak şekilde yapılandırıldı. Servis hesapları, Isilon Yerel sağlayıcısında ve yerel olarak istemci /etc/passwd dosyalarında oluşturuldu. Tüm testler, özel ayrıcalıkları olmayan temel bir test istemcisi kullanılarak çalıştırıldı.

Isilon istatistikleri hem IIQ hem de Grafana/Data Insights paketi ile izlendi. CDH istatistikleri Cloudera Manager ve ayrıca Grafana ile izlendi.

İlk Test

İlk test serisi, HBASE tarafında genel çıktıyı etkileyen ilgili parametreleri belirlemekti. HBASE yükünü oluşturmak için YCSB aracı kullanıldı. Bu ilk test, YCSB'nin "yükleme" aşaması ve 40 Milyon satır kullanılarak tek bir istemci (uç sunucu) kullanılarak çalıştırıldı. Bu tablo her çalıştırmadan önce siliniyordu.
 

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

• hbase.regionserver.maxlogs - En fazla İleri Yazma Günlüğü (WAL) dosyası sayısı - HDFS Blok Boyutu (dfs.blocksize) ile çarpılan bu değer, bir sunucu çöktüğünde yeniden yürütülmesi gereken WAL boyutudur. Bu değer, diske yapılan boşaltmaların sıklığı ile ters orantılıdır.
• hbase.wal.regiongrouping.numgroups - WALProvider olarak Birden Çok HDFS WAL kullanılırken, bu, her RegionServer'ın kaç tane ileri yazma günlüğü çalıştırması gerektiğini ayarlar. Sonuçlar, HDFS işlem hatlarının sayısını gösterir. Belirli bir Bölge için yazma işlemleri yalnızca tek bir işlem hattına gider ve toplam RegionServer yükünü yayar.

   
Buradaki felsefe, mümkün olduğu kadar çok yazıyı paralel hale getirmekti. WAL başına WAL sayısını ve ardından iş parçacığı (boru hattı) sayısını artırmak bunu başarır. Önceki iki grafik, belirli bir 'maxlog' sayısı olan 128 veya 256 için gerçek bir değişikliğin gösterilmediğini göstermektedir. Bu, testin istemci tarafındaki sonuçları gerçekten etkilemediğini gösterir. Dosya başına 'işlem hatları' sayısı çeşitlendirildi ve bu da paralelleştirmeye duyarlı parametreyi gösteren bir eğilim gösterdi. Bir sonraki soru, Isilon kümesinin Disk G/Ç, Ağ, CPU veya OneFS ile nerede "yoluna çıktığı"dır. Bu soruyu yanıtlamak için Isilon istatistik raporuna bakın.
Ağ ve CPU grafikleri bize Isilon kümesinin yeterince kullanılmadığını ve daha fazla çalışma için yer olduğunu söylüyor. CPU %80 olur > ve ağ bant genişliği 3 GB/sn'den fazla olur.
 
Bu grafikler, HDFS protokol istatistiklerini ve OneFS'nin çıktıyı nasıl çevirdiğini gösterir. HDFS işlemleri, burada 256 MB olan dfs.blocksize'ın katlarıdır. Burada ilginç olan, 'Heat' grafiğinin OneFS dosya işlemlerini göstermesi ve yazma ve kilitlerin korelasyonunun gösterilmesidir. Bu durumda HBase, WAL'lere ekleme yapar, bu nedenle OneFS, eklenen her yazma için WAL dosyasını kilitler. Bu, kümelenmiş bir dosya sisteminde kararlı yazmalar için beklenen şeydir. Bunlar, bu test setindeki sınırlayıcı faktöre katkıda bulunuyor gibi görünmektedir.

HBase Güncelleştirmeleri

Bir sonraki test, ölçekte ne olduğunu bulmak için daha fazla deney yapmaktı. Oluşturulması bir saat süren 1 Milyar satırlık bir tablo oluşturulur. 'workloada' ayarları (50/50 okuma/yazma) kullanılarak satırların 10 milyonunu güncelleştiren bir YCSB testi çalıştırılır. Bu test tek bir istemci üzerinde çalıştırıldı. Test, en fazla aktarım hızının oluşturulabilmesi için YCSB iş parçacığı sayısının bir fonksiyonu olarak çalıştırıldı. Ayrıca bazı ayarlamalar uygulandı ve OneFS, Veri düğümü hizmeti için performans ayarlamaları içeren v8.0.1.1 sürümüne yükseltildi. Aşağıdaki grafikte, önceki çalıştırma kümesine kıyasla performanstaki artış gösterilmektedir. Bu çalıştırmalar için hbase.regionserver.maxlogs 256 ve hbase.wal.regiongrouping.numgroups 20 olarak ayarlanır.    
Bu test çalıştırmalarının gözden geçirilmesi, Isilon veya istemci tarafı sorunu olabilecek yüksek iş parçacığı sayısında belirgin bir düşüş olduğunu gösteriyor. Testler, 3 ms'lik < bir güncelleme gecikme süresinde saniyede 200 Bin İşlem gösteriyor ve etkiliyor. Güncelleştirme testi çalıştırmalarının her biri hızlıydı ve art arda çalıştırılabiliyordu. Aşağıdaki grafikte, her test çalıştırması için Isilon düğümleri arasında eşit bir denge gösterilmektedir.
Isı grafiği, dosya işlemlerinin, WAL işlemlerinin ekleme doğasına karşılık gelen yazma ve kilitleme işlemleri olduğunu gösterir.

Bölge Sunucu Ölçeklendirme

Bir sonraki test, Isilon düğümlerinin (beş düğüm) farklı sayıda bölge sunucusuna karşı ne durumda olduğunu belirlemekti. Önceki testte çalıştırılan aynı güncelleştirme betiği, bir milyar satırlık bir tablo ve 'workloada' kullanılarak 10 milyon satırlık bir güncelleştirme içeren çalıştırıldı. Test, YCSB iş parçacıkları 51 olarak ayarlanmış tek bir istemci kullandı. Maxlogs ve işlem hatları için aynı ayar uygulanır (sırasıyla 256 ve 20).  
Sonuçlar şaşırtıcı olmasa da bilgilendiricidir. HBase'in ölçeği genişletilmiş doğası, Isilon'un ölçeği genişletilmiş doğasıyla birleştiğinde, daha fazlasının daha iyi olduğunu gösterdi. Bu test, müşterilerin kendi boyutlandırma egzersizlerinin bir parçası olarak ortamlarında çalıştırmaları için önerilir. Burada beş Isilon düğümünü zorlayan dokuz sunucu var ve azalan getiri noktasına ulaşmadan önce daha fazlası için hala yer var gibi görünüyor.

Daha Fazla Müşteri

Son test serisi, donanım yapılandırmasının sınırlarını test etmeye yetti. Bu, test edilen parametreler üzerindeki üst sınırı belirlemek için yapıldı. Bu test serisinde, istemcilerini çalıştırmak için iki ek sunucu kullanılır. Buna ek olarak, her sunucudan her biri altı istemciye kadar izin veren iki YCSB istemcisi çalıştırılır. Her istemci 512 iş parçacığı sürdü ve toplamda 4096 iş parçacığı elde edildi. İki farklı tablo oluşturuldu. 600 bölgeye ayrılmış 4 Milyar satırlı bir tablo ve 90 bölgeye ayrılmış 400 milyon satırlı başka bir tablo.  
Aşağıdaki grafikler, tablonun boyutunun bu testte çok az önemli olduğunu göstermektedir. Isilon Heat grafikleri, dosya işlemlerinin sayısında birkaç yüzde fark olduğunu bir kez daha gösteriyor. Farklılıkların çoğu, dört milyar satırlık bir tablo ile 400 milyon satırlık bir tablo arasındaki farklarla aynı hizadaydı.

Sonuç

HBase, temel olarak ölçeği genişletmeden ölçeği genişletme mimarilerine kadar Isilon üzerinde çalışmak için iyi bir adaydır. HBase kendi önbelleğe alma işleminin çoğunu yapar ve tabloyu çok sayıda bölgeye bölerek HBase verilerle ölçeği genişletebilir. Başka bir deyişle, kendi ihtiyaçlarını karşılama konusunda iyi bir iş çıkarır ve dosya sistemi uygulama esnekliği için oradadır. Test, yükü bir şeyleri kırma noktasına getiremedi. HBase, 3 ms'den az gecikme süresiyle 800.000 işlem için tasarlanmışsa, bu mimari bunu destekler. HBase, hem istemci tarafı hem de HBase'in kendisi için sayısız performans ayarlamasını ve ince ayarını destekler. Tüm bu ayarlamaların ve ince ayarların test edilmesi bu testin kapsamı dışındaydı.