PowerScale, Isilon OneFS: HBase-ydeevnetest på Isilon

Indledning

Vi foretog en række benchmarking-test af ydeevnen på en Isilon X410-klynge ved hjælp af YCSB-benchmarkingpakken og CDH 5.10.

CAE POC lab-miljøet blev konfigureret med 5x Isilon x410-noder, der kører OneFS 8.0.0.4 og nyere 8.0.1.1 NFS-benchmarks for streaming af store blokke vi bør forvente 5x ~700 MB/s skrivninger (3,5 GB/s) og 5x ~1 GB/s læsninger (5 GB/s) for vores teoretiske aggregerede maksimum i en af disse test.

De (9) beregningsnoder er Dell PowerEdge FC630-servere, der kører CentOS 7.3.1611, der hver er konfigureret med 2 x 18C/36T-Intel Xeon® CPU E5-2697 v4 ved 2,30 GHz med 512 GB RAM. Lokalt lager er 2xSSD i RAID 1 formateret som XFS til både operativsystem og skrabeplads/spildfiler.

Der var også tre ekstra Edge-servere, som blev brugt til at drive YCSB-belastningen.

Backend-netværket mellem beregningsnoder og Isilon er 10 Gbps med Jumbo Frames set (MTU=9162) til NIC'erne og switch-portene.

Indledende test

Den første serie af test var til at bestemme de relevante parametre på HBASE-siden, som påvirkede det samlede output. Vi brugte YCSB-værktøjet til at generere belastningen til HBASE. Denne indledende test blev kørt ved hjælp af en enkelt klient (edge-server) ved hjælp af "belastnings"-fasen af YCSB og 40 millioner rækker. Denne tabel blev slettet før hver kørsel.
 

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

hbase.regionserver.maxlogs - Det maksimale antal NOTD-filer (Write-Ahead Log). Denne værdi multipliceret med HDFS-blokstørrelse (dfs.blocksize) er størrelsen på den GENSTART, der skal afspilles igen, når en server går ned. Denne værdi er omvendt proportional med frekvensen af udtømninger til disken.

hbase.at.regiongrouping.numgroups - Når du bruger Flere HDFS ADMINISTRER som BERPROVIDER, angives det, hvor mange write-ahead-logfiler hver RegionServer skal køre. Resulterer i dette antal HDFS-pipelines. Skrivninger for en given region går kun til en enkelt pipeline og spreder den samlede regionServer-belastning.

Filosofien her var at parallelisere så mange skrivninger, som vi kunne, så en forøgelse af antallet af WAL'er og derefter antallet af tråde (pipeline) pr. ISOLATION opnår dette. De foregående to diagrammer viser, at for et givent tal for "maxlogs" 128 eller 256 ser vi ingen reel ændring, der angiver, at vi ikke rigtig skubber ind på dette tal fra klientsiden. Undgå at variere antallet af "pipelines" pr. fil, selvom vi ser tendensen, der angiver det parameter, der er følsomt over for parallelisering. Det næste spørgsmål er så, hvor "get in way" af Isilon enten kommer i vejen med Disk I/O, netværk, CPU eller OneFS, og vi kan se på, hvad Isilon-statistikrapporten er.


 
Netværks- og CPU-graferne fortæller os, at Isilon-klyngen er underudnyttet og har plads til mere arbejde. CPU'en vil være > 80 %, og netværksbåndbredden vil være mere end 3 GB/s.



Disse fejl viser HDFS-protokolstatistik, og hvordan de oversættes af OneFS. HDFS-ops er et multiplum af dfs.blocksize, som er 256 MB her. Det interessante her er, at "Varme"-grafen viser OneFS-filhandlinger, og du kan se korrelation af skrivninger og låse. I dette tilfælde føjer HBase sig til BER'erne, så OneFS låser KNAPPEN-filen for hver skrivning, der er tilføjet. Det er, hvad vi forventer af stabile skrivninger på et klyngefilsystem. Disse synes at bidrage til den begrænsende faktor i dette sæt test.

HBase-opdateringer

Denne næste test var at eksperimentere mere med at finde ud af, hvad der sker i stor skala, så jeg oprettede en tabel på en milliardrække, hvilket tog en god time at generere, og udførte derefter en YCSB-kørsel, der opdaterede 10 millioner af rækkerne ved hjælp af indstillingerne for "workloada" (50/50 læse/skrive). Dette blev kørt på en enkelt klient, og jeg var også på udkig efter den mest overførselshastighed, jeg kunne generere, så jeg kørte dette som en funktion af antallet af YCSB-tråde. En anden bemærkning var, at vi foretog en justering af Isilon og gik til OneFS 8.0.1.1, som har justering af ydeevnen for Data node-tjenesten. Du kan se stød i ydeevne sammenlignet med det forrige sæt kørsler. Til disse kørsler indstiller vi hbase.regionserver.maxlogs = 256 og hbase.regiongrouping.numgroups = 20

Når man ser på disse kørsler, er det første, der er synligt, faldet af ved højt trådtælling. Jeg er blevet spurgt, om det var et Isilon-problem eller et problem på klientsiden. Det kan vi se nogle yderligere test vedrørende i den kommende version. Men jeg kan sige, at det er imponerende at køre 200K+ Ops med en opdateringsventetid < på 3 ms. Hver af disse opdateringskørsler var hurtig, og jeg kunne gøre dem en efter en, og diagrammet nedenfor viser lige saldoen på tværs af Isilon-noderne for disse kørsler.



Igen kan du fra varme-grafen se, at filhandlinger skrives og låser, der svarer til append-karakteren af ATP-processerne.

Region serverskalering

Den næste test var at finde ud af, hvordan Isilon-noderne (fem af dem) ville klare sig på et andet antal landeservere. Det samme opdateringsscript kørte i den forrige test, blev kørt her. En tabel på en milliardrække og 10 millioner rækker opdateret ved hjælp af "workloada" med en enkelt klient og YCSB-tråde ved 51. Vi havde også den samme indstilling på maxlogs og pipelines (henholdsvis 256 og 20).

 
Resultaterne er informative, overraskende og overraskende. Udskalerings karakteren af HBase kombineret med udskalerings karakteren af Isilon og more==better. Dette er en test, som jeg anbefaler kunderne at køre på deres miljøer som en del af deres egen størrelsesudvidelse. Det kan være kommet til et punkt, hvor det bliver sværere at returnere, men her har vi ni heftiske servere, der skubber fem Isilon-noder, og det ser ud til, at der er plads til mere.

Flere klienter

Den sidste serie af tests kommer fra det dybe, mørke sted, der får dig til at ønske at ødelægge det system, du tester. Det er trods alt en helt gyldig videnskabelig metode at klamme en test, indtil tingene går i stykker og ringer således, så du ved, hvilken øvre grænse for de testede parametre er. I denne serie af tests havde jeg to ekstra servere, som jeg kunne bruge til at køre klienten fra, og derudover kørte jeg to YCSB-klienter på hver, hvilket gav mig mulighed for at skalere op til seks klienter hver med 512 tråde, hvilket ville være 4096 tråde overordnet. Jeg gik tilbage og oprettede to forskellige tabeller en med 4 milliarder rækker fordelt på 600 regioner og en med 400 rækker fordelt på 90 regioner.  

 



 

Som du kan se, betyder tabellens størrelse ikke meget i denne test. Når du ser på Isilon-varme diagrammerne igen, kan du se, at der er et par procentvise forskelle i antallet af filhandlinger, der hovedsageligt er indlejret med forskellene fra en tabel med fire milliarder rækker til 400 millioner rækker.

Konklusion

HBase er en god kandidat til at køre på Isilon, primært på grund af udskaleringsarkitekturerne. HBase udfører meget af sin egen cachelagring og opdeler tabellen på tværs af en lang række regioner, hvor du får HBase til at skalere ud med dine data. Det gør det med andre ord en god idé at tage sig af sine egne behov, og filsystemet er der for udholdenhed. Vi kunne ikke skubbe belastningstestene til det punkt, hvor vi rent faktisk ødelægge tingene, men hvis du kigger på fire milliarder rækker i dit HBase-design og forventer 800.000 handlinger med mindre end 3 ms ventetid, understøtter denne arkitektur det. Hvis du bemærker, at jeg ikke har nævnt meget mere om nogle af de myriad andre tweaks på klientsiden, du kunne anvende på HBase selv, ville jeg forvente, at alle disse tweaks stadig var gyldige og ud over omfanget af denne test.