PowerScale, Isilon OneFS: HBase prestatietests op Isilon

Inleiding

We hebben een reeks prestatiebenchmarktests uitgevoerd op een Isilon X410 cluster met behulp van de YCSB benchmarking suite en CDH 5.10.

De CAE POC lab-omgeving is geconfigureerd met 5x Isilon x410 knooppunten waarop OneFS 8.0.0.4 en later 8.0.1.1 NFS grote Block streaming benchmarks worden uitgevoerd moet 5x ~700 MB/s schrijfbewerkingen (3,5 GB/s) en 5x ~1 GB/s leesbewerkingen (5 GB/s) verwachten voor onze theoretische geaggregeerde maximumaantalken in een van deze tests.

De (9) computeknooppunten zijn Dell PowerEdge FC630 servers met CentOS 7.3.1611 die elk zijn geconfigureerd met 2 x 18C/36T-Intel Xeon® CPU E5-2697 v4 bij 2,30 GHz met 512 GB RAM. Lokale storage is 2xSSD in RAID 1 geformatteerd als XFS voor zowel besturingssysteem- als scratchruimte/morsbestanden.

Er waren ook drie extra edge-servers die werden gebruikt om de YCSB-belasting te stimuleren.

Het backend-netwerk tussen computeknooppunten en Isilon is 10 Gbps met Jumbo Frames ingesteld (MTU=9162) voor de NIC's en de switchpoorten.

Initiële test

De eerste reeks tests was het bepalen van de relevante parameters aan de HBASE-kant die van invloed waren op de algehele uitvoer. We hebben de YCSB-tool gebruikt om de belasting voor HBASE te genereren. Deze initiële test is uitgevoerd met behulp van één client (edge server) met behulp van de laadfase 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 Write-Ahead Log (WAL)-bestanden. Deze waarde vermenigvuldigd met HDFS Block Size (dfs.blocksize) is de grootte van de WAL die moet worden vertegenwoordigd wanneer een server crasht. Deze waarde is omgekeerd evenredig aan de frequentie van doorspoeling naar de schijf.

hbase.wal.regiongrouping.numgroups - Wanneer u meerdere HDFS WAL gebruikt als de WALProvider, stelt u in hoeveel write-ahead-logs elke RegionServer moet worden uitgevoerd. Resulteert in dit aantal HDFS-pipelines. Schrijfbewerkingen voor een bepaalde regio gaan alleen naar één pipeline, waarbij de totale belasting van de RegionServer wordt verspreid.

De filosofie hier was om zo veel mogelijk schrijfbewerkingen parallel te stellen, zodat het verhogen van het aantal WAL's en vervolgens het aantal threads (pipeline) per WAL dit bereikt. Uit de vorige twee grafieken blijkt dat er voor een bepaald getal voor 'maxlogs' 128 of 256 geen echte verandering is wat aangeeft dat we dit nummer niet echt aan de clientkant doordrukken. Oby varieert het aantal 'pipelines' per bestand, hoewel we de trend zien die aangeeft dat de parameter gevoelig is voor parallelisatie. De volgende vraag is dan waar Isilon "in de weg zit" met schijf-I/O, netwerk, CPU of OneFS en we kunnen kijken naar het Isilon statistiekenrapport.


 
De netwerk- en CPU-grafieken laten zien dat het Isilon cluster onderbenut is en ruimte heeft voor meer werk. DE CPU zou 80% zijn > en de netwerkbandbreedte zou meer dan 3 GB/s zijn.



Deze bestanden tonen de HDFS-protocolstatistieken en hoe ze worden vertaald door OneFS. De HDFS ops zijn meerdere dfs.blocksize, wat hier 256 MB is. Het interessante hier is dat de 'Heat'-grafiek de OneFS-bestandsbewerkingen weergeeft en dat u correlatie van schrijfbewerkingen en vergrendelingen kunt zien. In dit geval voegt HBase appends toe aan de WAL's, zodat OneFS het WAL-bestand vergrendelt voor elke schrijfbewerking die wordt toegevoegd. Dat is wat we verwachten voor stabiele schrijfbewerkingen op een geclusterd bestandssysteem. Deze zouden bijdragen aan de beperkende factor in deze reeks tests.

HBase-updates

Deze volgende test was om wat meer te experimenteren in het vinden van wat er op schaal gebeurt, dus heb ik een tabel met één miljard rijen gemaakt, die een goed uur duurde om te genereren, en vervolgens een YCSB-run uitgevoerd die 10 miljoen rijen bijwerkte met behulp van de 'workloada'-instellingen (50/50 lezen/schrijven). Dit werd uitgevoerd op één client en ik was ook op zoek naar de meeste doorvoer die ik kon genereren, dus heb ik dit uitgevoerd als een functie van het aantal YCSB-threads. Een andere opmerking was dat we Isilon hebben afgestemd en naar OneFS 8.0.1.1 zijn gegaan met prestatieaanpassingen voor de dataknooppuntservice. U kunt de stoten in prestaties zien in vergelijking met de vorige reeks uitvoeringen. Voor deze uitvoeren stellen we de hbase.regionserver.maxlogs = 256 in en de hbase.wal.regiongrouping.numgroups = 20

Als u naar deze runs kijkt, is het eerste wat duidelijk is, de daling bij het hoge aantal threads. Ik was niet zeker of dit een Isilon-probleem of een probleem aan de client was. In de komende alinea's zien we nog enkele verdere tests hierover. Maar ik kan zeggen dat het aansturen van 200K+ Ops bij een updatelatentie van < 3 ms indrukwekkend is. Elk van deze update-runs was snel en ik kon ze de ene na de andere uitvoeren en de onderstaande grafiek toont de gelijkmatige balans tussen de Isilon knooppunten voor deze runs.



Nogmaals, in de warmtegrafiek ziet u dat de bestandsbewerkingen schrijfbewerkingen zijn en vergrendelt die overeenkomen met de toegevoegde aard van de WAL-processen.

Serverschaal regio

De volgende test was om te bepalen hoe de Isilon knooppunten (vijf van hen) het zouden doen ten opzichte van een ander aantal regioservers. Hetzelfde updatescript dat in de vorige test is uitgevoerd, is hier uitgevoerd. Een tabel met 1 miljard rijen en 10 miljoen rijen bijgewerkt met behulp van 'workloada' met één client- en YCSB-threads op 51, we hebben ook dezelfde instelling behouden op de maxlogs en pipelines (respectievelijk 256 en 20).

 
De resultaten zijn informatief, maar niet verrassend. De scale-out aard van HBase in combinatie met de scale-out aard van Isilon en meer==beter. Dit is een test die klanten aanraadt om hun omgeving te gebruiken als onderdeel van hun eigen formaat. Het kan een punt worden van een afnemend rendement, maar hier hebben we negen forse servers die vijf Isilon knooppunten pushen en het lijkt erop dat er ruimte is voor meer.

Meer clients

De laatste serie tests komen uit die diepe donkere plaats waardoor u het systeem dat u test wilt breken. Het is immers een perfect geldige wetenschappelijke methode om een test uit te voeren totdat de dingen breken en te bellen, zodat u weet wat de bovengrens voor de geteste parameters is. In deze reeks tests had ik twee extra servers waarvan ik de client kon gebruiken. Daarnaast heb ik op elke client twee YCSB-clients uitgevoerd, waardoor ik maximaal zes clients kon opschalen die elk 512 threads aansturen, wat in het algemeen 4096 threads zou zijn. Ik ging terug en maakte twee verschillende tabellen één met 4 miljard rijen verdeeld in 600 regio's en één met 400 rijen voor 400 rijen verdeeld in 90 regio's.  

 



 

Zoals u kunt zien, is de grootte van de tabel in deze test weinig van belang. Als u de Isilon heatdiagrammen opnieuw bekijkt, kunt u zien dat er een verschil is van een paar procent in het aantal bestandsbewerkingen dat meestal in lijn is met de verschillen van een tabel met vier miljard rijen tot 400 miljoen rijen.

Conclusie

HBase is een goede kandidaat voor het uitvoeren op Isilon, voornamelijk vanwege de scale-out naar scale-out architecturen. HBase doet veel van zijn eigen caching en splitst de tabel op in een groot aantal regio's die U HBase krijgt om uit te schalen met uw data. Met andere woorden, het doet goed werk om te zorgen voor zijn eigen behoeften en het bestandssysteem is er voor persistentie. We konden de belastingstests niet pushen om daadwerkelijk dingen te breken, maar als u naar vier miljard rijen in uw HBase-ontwerp kijkt en 800.000 bewerkingen verwacht met minder dan 3 ms latentie, ondersteunt deze architectuur dit. Als u merkt dat ik niet veel meer heb gezegd over een van de talloze tweaks aan de andere clientzijde die u op HBase zelf zou kunnen toepassen, zou ik verwachten dat al deze tweaks nog steeds geldig zijn en buiten het bereik van deze test vallen.