PowerScale, Isilon OneFS: Testování výkonu databáze HBase v řešení Isilon

Úvod

V clusteru Isilon X410 jsme provedli sérii srovnávacích testů výkonu pomocí benchmarkingové sady YCSB a CDH 5.10.

Laboratorní prostředí CAE POC bylo nakonfigurováno s 5 uzly Isilon x410, které používají srovnávací testy streamování Large Block OneFS 8.0.0.4 a novějších 8.0.1.1 NFS. očekávejte 5x ~700 MB/s zápis (3,5 GB/s) a 5x ~1 GB/s čtení (5 GB/s) pro naše teoretické agregované maximum v kterémkoli z těchto testů.

(9) Výpočetními uzly jsou servery Dell PowerEdge FC630 se systémem CentOS 7.3.1611 konfigurované s procesorem 2x18C/36T-Intel Xeon® E5-2697 v4 s frekvencí 2,30 GHz a 512 GB paměti RAM. Místní úložiště je 2xSD v poli RAID 1 naformátované jako XFS pro operační systém a pomocné místo /rozlité soubory.

K podpoře zatížení YCSB byly použity také tři další servery Edge.

Backendová síť mezi výpočetními uzly a řešením Isilon je 10 Gb/s se sadou rámců typu Jumbo (MTU=9162) pro síťové karty a porty přepínače.

Počáteční testování

První řada testů zjistila příslušné parametry na straně HBASE, které ovlivnily celkový výstup. K vygenerování zatížení pro HBASE jsme použili nástroj YCSB. Tento počáteční test byl spuštěn pomocí jednoho klienta (okrajový server) ve fázi "zatížení" YCSB a 40 milionů řádků. Tato tabulka byla před každým spuštěním odstraněna.
 

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

hbase.regionserver.maxlogs – Maximální počet souborů protokolu WRITE-Ahead Log (NFC). Tato hodnota vynásobená velikostí bloku HDFS (velikost dfs.blocksize) je velikost ÚLOŽIŠTĚ, kterou je nutné znovu přehrát při selhání serveru. Tato hodnota je inverzálně úměrná frekvenci vyprázdnění disku.

hbase.přeinstalace.regiongrouping.numgroups – Při použití více služeb HDFSFS GIF jako SLUŽBY NEÚSKLADNĚ nastaví, kolik protokolů write-ahead-logs má každý server RegionServer spustit. Vede k tomuto počtu kanálů HDFS. Zápisy pro danou oblast se odehrají pouze do jednoho kanálu, který rozšíří celkové zatížení regionserveru.

Filozofií zde bylo paralelizovat tolik zápisů, kolik bylo možné, a zvýšit tak počet walů a poté toho dosáhnout počet vláken (pipeline) na každé ZAŘÍZENÍ. Předchozí dva grafy ukazují, že u daného čísla "maxlogs" 128 nebo 256 se nemění žádná skutečná změna, což znamená, že toto číslo z klientské strany neprovádíme. Oby mění počet "kanálů" na soubor, ačkoli vidíme trend označující parametr, který je citlivý na paralelizaci. Další otázkou pak bude, kde se řešení Isilon "překážou" s I/O disku, sítí, procesorem nebo systémem OneFS a můžeme se podívat, co isilon statistics report.


 
Grafy sítě a procesoru sdělují, že cluster Isilon se nedostatečně využívá a má prostor pro větší práci. Procesor by na > 80 % a šířka pásma sítě byla vyšší než 3 GB/s.



Tyto obrázky zobrazují statistiky protokolu HDFS a způsob jejich překladu systémem OneFS. Systémy HDFS jsou násobky velikosti dfs.block, které zde činí 256 MB. Zajímavé je, že graf "tepla" zobrazuje operace souborů OneFS a vidíte korelaci zápisů a zámků. V takovém případě služba HBase provádí dodatky k řadiči LOM, takže systém OneFS uzamkne soubor NENÁVŘEný pro každý přidaný zápis. Co byste čekali u stabilních zápisů do systému souborů clustered. Zdá se, že přispívají k omezujícímu faktoru v této sadě testů.

Aktualizace HBase

Dalším testem bylo provést další experimenty s cílem zjistit, co se stane v měřítku, takže jsem vytvořil jednu tabulku s miliardou řádků, která trvala dobrou hodinu a poté proběhl test YCSB, který pomocí nastavení "workloada" (čtení/zápis 50/50) aktualizoval 10 milionů řádků. Tento příkaz byl spuštěn na jednom klientovi a hledal jsem také největší propustnost, kterou jsem mohl vygenerovat, takže jsem tento příkaz spustil jako funkci počtu vláken YCSB. Jednou další poznámkou bylo, že jsme provedli určité ladění řešení Isilon a provedli jsme řešení OneFS 8.0.1.1, které obsahuje vylepšení výkonu pro službu datového uzlu. Ve srovnání s předchozí sadou běží náraz do vyššího výkonu. Pro tyto spuštění nastavíme hodnotu hbase.regionserver.maxlogs = 256 a hbase.clusteru.regiongrouping.numgroups = 20.

Při pohledu na ně je první, co je patrná, je pokles při vysokém počtu vláken. Byl jsem bádný, pokud se jednalo o problém Isilon nebo o problém na straně klienta. Některé další testy týkající se tohoto problému naleznete v nadcházejících bodech. Mohu však říci, že výkon 200 tisíc a více operačních < modulů s aktualizační latencí 3 mil je působivý. Každá z těchto aktualizací byla rychlá a jedna po druhé jsem je dokázala provést a graf níže zobrazuje sudou rovnováhu mezi uzly Isilon.



Opět je v grafu tepla patrné, že operace se soubory zapisují a uzamknou podle povahy dodatku procesů DIAGNOSTIKY.

Škálování oblastní serveru

Dalším testem bylo určit, jak si uzly Isilon (pět z nich) zasází jiný počet oblastních serverů. Stejný skript aktualizace, který byl spuštěn v předchozím testu, byl spuštěn zde. Jedna tabulka s miliardou řádků a 10 milionů řádků aktualizovaných pomocí "workloada" s jedním klientem a vlákny YCSB na 51. Postup jsme také udržovali na stejném nastavení na maxlogech a kanálech (256, resp. 20).

 
Výsledky jsou informativní, nepochytivé. Horizontálně škálovaná povaha služby HBase v kombinaci s horizontálním škálováním řešení Isilon a další = lepší. Jedná se o test, který doporučuji, aby zákazníci běželi ve svém prostředí v rámci svého vlastního testu velikosti. Může dojít k sníženému návratu, ale zde máme devětftových serverů, které zatlačí na pět uzlů Isilon a zdá se, že je prostor pro více.

Více klientů

Poslední série testů pochází z hlubokého tmavého místa, kvůli kterému chcete narušit systém, který testujete. Koneckonců, jde o dokonale platnou výzkumnou metodu, jak provést test až do okamžiku, kdy se vše rozbije a rozbije a rozzvedne, čímž víte, co je horní limit testovaných parametrů. V této sérii testů jsem měl dva další servery, ze kterých bych mohl spustit klienta, a navíc jsem spustil dva klienty YCSB na každém z nich, což mi umožnilo škálovat až šest klientů na každé 512 vláken, což bylo celkem 4 096 vláken. Vrátil jsem se zpět a vytvořil jsem dvě různé tabulky jedna se 4 miliardami řádků rozdělenými do 600 regionů a jednoho se 400 biliony řádků rozdělených do 90 regionů.  

 



 

Jak vidíte, velikost tabulky je v tomto testu jen malá. Při opětovném pohledu na grafy Isilon Heat je patrné, že u počtu operací se soubory je několik procentuálních rozdílů, většinou v porovnání s rozdíly čtyř miliard řádků na 400 milionů řádků.

Závěr

Služba HBase je dobrým doplňkem provozu na řešení Isilon, a to především z důvodu škálovaného škálování na škálovatelné architektury. Služba HBase provádí velké množství své vlastní mezipaměti a rozděluje tabulku mezi velké množství oblastí, ve které získáte řešení HBase pro škálování dat. Jinými slovy, dělá dobrou práci, aby se starala o své vlastní potřeby a systém souborů má trvalou životnost. Nepodařilo se odeslat zátěžové testy do bodu, kdy došlo k narušení věcí, ale pokud jste hledali čtyři miliardy řádků v návrhu HBase a očekáváte 800 000 operací s latencí menší než 3 ms, tato architektura ji podporuje. Pokud si všimnete, že jsem nezměňoval mnoho dalších vylepšení na straně klienta, můžete použít i samotnou databázi HBase, očekávám, že všechna tato vylepšení budou stále platná a nad rámec tohoto testu.