PowerScale, Isilon OneFS: HBase-prestatietests op Isilon

Niet vereist

Niet vereist

Inleiding

Er werd een reeks prestatiebenchmarktests uitgevoerd op een Isilon X410-cluster met behulp van de YCSB-benchmarkingsuite en CDH 5.10.

De labtestomgeving was geconfigureerd met vijf Isilon x410 knooppunten met OneFS v8.0.0.4 en later v8.0.1.1. Network File System (NFS) Large Block-streamingbenchmarks zijn uitgevoerd. Het verwachte theoretische totaalmaximum voor de tests was ~700 MB/s (3,5 GB/s) schrijfbewerkingen en ~1 GB/s leesbewerkingen (5 GB/s) per knooppunt.

De (9) rekenknooppunten zijn Dell PowerEdge FC630 servers met CentOS v7.3.1611, elk geconfigureerd met 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2,30GHz met 512GB RAM. Lokale storage is 2xSSD in RAID 1 geformatteerd als XFS voor zowel het besturingssysteem als scratch space of gemorste bestanden.

Er waren ook drie extra Edge-servers die werden gebruikt om de YCSB-belasting aan te sturen.

Het backendnetwerk tussen compute knooppunten en Isilon is 10 Gbps met Jumbo Frames set (MTU=9162) voor de NIC's en de switchpoorten.
CDH 5.10 is geconfigureerd om te worden uitgevoerd in een toegangszone op het Isilon cluster. Serviceaccounts zijn gemaakt in de Isilon Local provider en lokaal in de client /etc/passwd-bestanden. Alle tests zijn uitgevoerd met behulp van een eenvoudige testclient zonder speciale bevoegdheden.

Isilon-statistieken werden gemonitord met zowel IIQ als het Grafana/Data Insights-pakket. CDH-statistieken werden gemonitord met Cloudera Manager en ook met Grafana.

Eerste testen

De eerste reeks tests was bedoeld om de relevante parameters aan de HBASE-zijde te bepalen die van invloed waren op de totale output. De YCSB-tool is gebruikt om de belasting voor HBASE te genereren. Deze eerste test werd uitgevoerd met één client (edge-server) met behulp van de 'load'-fase van YCSB en 40 miljoen rijen. Deze tabel is vóór elke uitvoering verwijderd.
 

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

• hbase.regionserver.maxlogs - Maximum aantal WAL-bestanden (Write-Ahead Log): deze waarde vermenigvuldigd met de HDFS-blokgrootte (dfs.blocksize) is de grootte van de WAL die opnieuw moet worden afgespeeld wanneer een server crasht. Deze waarde is omgekeerd evenredig met de frequentie van spoelingen naar de schijf.
• hbase.wal.regiongrouping.numgroups - Bij gebruik van Multiple HDFS WAL als WALProvider wordt hiermee ingesteld hoeveel write-ahead-logs elke RegionServer moet uitvoeren. De resultaten tonen het aantal HDFS-pipelines. Schrijfbewerkingen voor een bepaalde regio gaan slechts naar één pijplijn, waardoor de totale belasting van de RegionServer wordt verspreid.

   
De filosofie hier was om zoveel mogelijk geschriften parallel te laten lopen. Dit wordt bereikt door het aantal WAL's en vervolgens het aantal threads (pijplijn) per WAL te verhogen. De vorige twee grafieken laten zien dat voor een gegeven getal voor 'maxlogs', 128 of 256, geen echte verandering wordt getoond. Dit geeft aan dat de test niet echt van invloed is op de resultaten aan de kant van de klant. Het aantal 'pipelines' per bestand werd gevarieerd, wat een trend liet zien die aangeeft welke parameter gevoelig is voor parallellisatie. De volgende vraag is, waar zit een Isilon-cluster "in de weg" met schijf-I/O, netwerk, CPU of OneFS. Bekijk het Isilon statistics report om deze vraag te beantwoorden.
De netwerk- en CPU-grafieken vertellen ons dat het Isilon-cluster onderbenut is en ruimte heeft voor meer werk. CPU zou 80% zijn > en de netwerkbandbreedte zou meer dan 3 GB/s zijn.
 
Deze grafieken tonen de statistieken van het HDFS-protocol en hoe OneFS de uitvoer vertaalt. De HDFS-bewerkingen zijn veelvouden van dfs.blocksize, wat hier 256 MB is. Het interessante hier is dat de grafiek 'Heat' de OneFS-bestandsbewerkingen toont en de correlatie van schrijfbewerkingen en vergrendelingen wordt weergegeven. In dit geval doet HBase toevoegingen aan de WAL's, zodat OneFS het WAL-bestand vergrendelt voor elke schrijfbewerking die wordt toegevoegd. Dat is wat verwacht wordt voor stabiele schrijfbewerkingen op een geclusterd bestandssysteem. Deze lijken bij te dragen aan de beperkende factor in deze reeks tests.

HBase-updates

Deze volgende test was om meer te experimenteren om te ontdekken wat er op grote schaal gebeurt. Er wordt een tabel met 1 miljard rijen gemaakt die een uur heeft geduurd om te genereren. Er wordt een YCSB-test uitgevoerd die 10 miljoen rijen heeft bijgewerkt met behulp van de 'workloada'-instellingen (50/50 lezen/schrijven). Deze test is uitgevoerd op één client. De test werd uitgevoerd als een functie van het aantal YCSB-threads, zodat de meeste doorvoer kan worden gegenereerd. Ook is er wat afstemming toegepast en is OneFS geüpgraded naar v8.0.1.1 met prestatieaanpassingen voor de dataknooppuntservice. De volgende grafiek toont de toename in prestaties in vergelijking met de vorige reeks runs. Voor deze uitvoeringen is de hbase.regionserver.maxlogs ingesteld op 256 en de hbase.wal.regiongrouping.numgroups op 20.    
Uit onderzoek van deze testruns blijkt dat er een duidelijke afname is bij een hoog aantal threads, wat een probleem kan zijn met Isilon of aan de clientzijde. Tests tonen en maken indruk op 200 duizend bewerkingen per seconde bij een updatelatentie van < 3 ms. Alle updatetests verliepen snel en konden achter elkaar worden uitgevoerd. De onderstaande grafiek toont een gelijkmatige verdeling over de Isilon knooppunten voor elke testrun.
De warmtegrafiek laat zien dat de bestandsbewerkingen schrijfbewerkingen en vergrendelingen zijn die overeenkomen met de toevoegingsaard van de WAL-processen.

Schaalbare regioservers

De volgende test was om te bepalen hoe de Isilon-knooppunten (vijf knooppunten) het zouden doen ten opzichte van een ander aantal regioservers. Hetzelfde updatescript dat in de vorige test werd uitgevoerd, werd uitgevoerd met een tabel met één miljard rijen en een update met 10 miljoen rijen met behulp van 'workloada'. De test gebruikte een enkele client met YCSB-threads ingesteld op 51. Dezelfde instelling wordt toegepast voor de maxlogs en pipelines (respectievelijk 256 en 20).  
De resultaten zijn informatief, zij het niet verrassend. Het scale-out karakter van HBase in combinatie met het scale-out karakter van Isilon gaf aan dat meer beter is. Deze test wordt aanbevolen voor clients om in hun omgeving uit te voeren als onderdeel van hun eigen maatvoeringsoefening. Hier zijn negen servers die vijf Isilon-knooppunten pushen en het lijkt erop dat er nog ruimte is voor meer voordat het punt van afnemende opbrengsten wordt bereikt.

Meer klanten

De laatste reeks tests diende om de grenzen van de hardwareconfiguratie te testen. Dit werd gedaan om de bovengrens van de te testen parameters te bepalen. In deze reeks tests worden twee extra servers gebruikt om clients vanaf uit te voeren. Bovendien worden vanaf elke server twee YCSB-clients uitgevoerd, waardoor er elk maximaal zes clients mogelijk zijn. Elke klant reed 512 threads, wat resulteerde in 4096 threads in totaal. Er zijn twee verschillende tabellen gemaakt. Een tabel met 4 miljard rijen opgesplitst in 600 regio's en een andere tabel met 400 miljoen rijen opgesplitst in 90 regio's.  
Onderstaande grafieken laten zien dat de grootte van de tabel er in deze test weinig toe doet. De Isilon Heat grafieken laten weer zien dat er een paar procenten verschil is in het aantal bestandsbewerkingen. De meeste verschillen waren in lijn met de verschillen van een tabel met vier miljard rijen naar een tabel met 400 miljoen rijen.

Conclusie

HBase is een goede kandidaat om op Isilon te draaien, voornamelijk vanwege de scale-out naar scale-out architecturen. HBase doet veel van zijn eigen caching en door de tabel over een groot aantal regio's te verdelen, kan HBase opschalen met de gegevens. Met andere woorden, het zorgt goed voor zijn eigen behoeften en het bestandssysteem is er voor de veerkracht van applicaties. Het testen was niet in staat om de belasting zo ver te duwen dat dingen braken. Als de HBase is ontworpen voor 800.000 bewerkingen met minder dan 3 ms latentie, ondersteunt deze architectuur dit. HBase ondersteunt een groot aantal prestatie-aanpassingen en tweaks voor zowel de clientzijde als HBase zelf. Het testen van al die aanpassingen en tweaks viel buiten het bestek van deze test.