PowerScale, Isilon OneFS: HBase-ytelsestesting på Isilon

Innledning

Vi gjorde en rekke ytelsestestingstester på en Isilon X410-klynge ved hjelp av YCSB-ytelsestestingspakken og CDH 5.10.

CAE POC-laboratoriemiljøet ble konfigurert med 5x Isilon x410-noder som kjører OneFS 8.0.0.4 og nyere 8.0.1.1 NFS large Block streaming benchmark vi bør forvente 5 x ~700 MB/s skriving (3,5 GB/s) og 5 x ~1 GB/s leseoperasjoner (5 GB/s) for våre teoretisk aggregerte maksimum i noen av disse testene.

De (9) databehandlingsnodene er Dell PowerEdge FC630-servere som kjører CentOS 7.3.1611 hver konfigurert med 2 x 18C / 36T-Intel Xeon® CPU E5-2697 v4 ved 2,30 GHz med 512 GB RAM. Lokal lagring er 2xSSD i RAID 1 formatert som XFS for både operativsystem og ripeplass/sølfiler.

Det var også tre ekstra Edge-servere som ble brukt til å drive YCSB-lasten.

Backend-nettverket mellom databehandlingsnoder og Isilon er 10 Gbps med jumborammer angitt (MTU =9162) for nic-ene og svitsjportene.

Første testing

Den første testserien var å fastslå de relevante parametrene på HBASE-siden som påvirket den totale utdataene. Vi brukte YCSB-verktøyet til å generere lasten for HBASE. Denne første testen ble kjørt ved hjelp av én enkelt klient (edge server) ved hjelp av "last"-fasen av YCSB- og 40 millioner rader. Denne tabellen ble slettet før hver kjøring.
 

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

hbase.regionserver.maxlogs – maksimalt antall WRITE-Ahead Log -filer (PST). Denne verdien multiplisert med HDFS-blokkstørrelse (dfs.blocksize) er størrelsen på THECR SOM MÅ spilles av når en server krasjer. Denne verdien er invertert proporsjonal med frekvensen av tømminger til disken.

hbase.pst.regiongrouping.numgroups – Når du bruker multiple HDFS- OG NUM-numredusator, angir du hvor mange forhåndsskrivingslogger hver RegionServer skal kjøre. Resulterer i dette antallet HDFS-pipeliner. Skriveoperasjoner for en gitt region går bare til én enkelt pipeline, og sprer den totale regionserverbelastningen.

her var det å parallellisere så mange skriveoperasjoner som vi kunne, slik at det å øke antall wal-er og deretter antallet tråder (pipeline) per PST oppnår dette. De to foregående diagrammene viser at for et gitt nummer for "maxlogs" 128 eller 256 ser vi ingen reell endring som indikerer at vi egentlig ikke skyver inn dette tallet fra klientsiden. Oby varying the number of 'pipelines' per file though we see the trend indicating the parameter that is sensitive to parallelization (Vi ser trenden som indikerer parameteren som er følsom for parallellisering). Det neste spørsmålet er hvor Isilon "kommer i veien", enten med disk-I/O, nettverk, CPU eller OneFS, og vi kan se på hvilken Isilon-statistikkrapport.


 
Nettverks- og CPU-grafene forteller oss at Isilon-klyngen er underutnyttet og har plass til mer arbeid. CPU-en vil være > 80 %, og nettverksbåndbredden vil være mer enn 3 GB/s.



Disse tegnene viser HDFS-protokollstatistikken og hvordan de oversettes av OneFS. HDFS-operasjoner er multipler av dfs.blocksize, som er 256 MB her. Det interessante her er at "Heat"-grafen viser OneFS-filoperasjoner, og du kan se korrelasjon av skriving og låser. I dette tilfellet legger HBase til ID-ene slik at OneFS låser DLL-filen for hver skriveoperasjon som legges til. Det er det vi forventer for stabil skriving på et klyngefilsystem. Disse ser ut til å bidra til den begrensende faktoren i dette settet med tester.

HBase-oppdateringer

Neste test var å eksperimentere litt mer med å finne ut hva som skjer i stor skala, så jeg opprettet en tabell på én milliard rad, noe som tok en god time å generere, og deretter ble det kjørt en YCSB som oppdaterte 10 millioner av radene ved hjelp av workloada-innstillingene (50/50 lese/skrive). Dette ble kjørt på én enkelt klient, og jeg lette også etter den mest gjennomstrømmingen jeg kunne generere, så jeg kjørte dette som en funksjon av antallet YCSB-tråder. Et annet notat var at vi justerte Isilon og gikk til OneFS 8.0.1.1, som har ytelsesjusteringer for datanodetjenesten. Du kan se ytelsesstøt sammenlignet med forrige sett med kjøringer. For disse kjøringene angir vi hbase.regionserver.maxlogs = 256 og hbase.pst.regiongrouping.numgroups = 20

Når du ser på disse, kjører det første som er tydelig, at det faller av ved høyt antall tråder. Jeg var utydelig hvis dette var et Isilon-problem eller et problem på klientsiden. Vi ser flere tester i forbindelse med dette i de kommende avsnittene. Men jeg kan si at det er imponerende å kjøre 200K+ Ops med en ventetid < på 3 ms. Hver av disse oppdateringene var rask, og jeg kunne gjøre dem etter hverandre, og grafen nedenfor viser jevn balanse på tvers av Isilon-nodene for disse kjøringene.



På nytt kan du se fra varmegrafen at filoperasjonene skrives og låses i samsvar med den tilføyde typen AVSING-prosesser.

Områdeserverskalering

Den neste testen var å finne ut hvordan Isilon-nodene (fem av dem) ville gå mot et annet antall regionservere. Det samme oppdateringsskriptet som ble kjørt i forrige test, ble kjørt her. En tabell på én milliard rad og 10 millioner rader oppdatert ved hjelp av workloada med én enkelt klient og YCSB-tråder på 51, har vi også den samme innstillingen på makslogs og pipelines (henholdsvis 256 og 20).

 
Resultatene er informative, ikke overraskende. Skalerbar natur HBase kombinert med skalerbar natur Isilon og mer ==bedre. Dette er en test som jeg vil anbefale kundene å kjøre på miljøene sine som en del av sin egen størrelsesøvelse. Det kan komme til et punkt med redusert avkastning, men her har vi ni serverenheter som skyver fem Isilon-noder, og det ser ut til at det er plass til mer.

Flere klienter

De siste testene kommer fra det mørke stedet som gjør at du vil ødelegge systemet du tester. Det er tross alt en helt gyldig, vitenskapelig metode for å teste opp til ting går i stykker, og dermed vite hva den øvre grensen for parametrene som testes, er. I denne testserien hadde jeg to ekstra servere som jeg kunne bruke til å kjøre klienten fra, i tillegg kjørte jeg to YCSB-klienter på hver av dem, slik at jeg kunne skalere opptil seks klienter hver med 512 tråder, noe som ville være 4096 tråder totalt. Jeg gikk tilbake og opprettet to forskjellige tabeller én med 4 milliarder rader fordelt på 600 regioner, og én med 400 arsurrader fordelt på 90 områder.  

 



 

Som du kan se, teller størrelsen på tabellen lite i denne testen. Når du ser på Isilon Heat-diagrammene igjen, kan du se at det er noen få prosent forskjell i antall filoperasjoner som hovedsakelig er innebygd, med forskjellene på en tabell på fire milliarder rader til 400 millioner rader.

Konklusjon

HBase er en god kandidat for å kjøre på Isilon, hovedsakelig på grunn av utskalering til skalerbare arkitekturer. HBase utfører mye av sin egen hurtigbufring, og deler tabellen over et godt antall regioner du får HBase til å skalere ut med dataene dine. Med andre ord gjør det en god jobb å ta vare på sine egne behov, og filsystemet er der for utholdenhet. Vi var ikke i stand til å skyve belastningstestene til det punktet hvor du faktisk kunne bryte ting, men hvis du ser på fire milliarder rader i HBase-designen din og forventer 800 000 operasjoner med mindre enn 3 ms ventetid, støtter denne arkitekturen den. Hvis du legger merke til at jeg ikke nevnte mye mer om noen av de andre justeringene på den andre klientens side, kan du bruke på HBase selv, jeg forventer at alle disse justeringene fortsatt er gyldige, og utover omfanget til denne testen.