PowerScale, Isilon OneFS: Test af HBase-ydeevne på Isilon

Ikke påkrævet

Ikke påkrævet

Indledning

En række performance benchmarking-tests blev udført på en Isilon X410-klynge ved hjælp af YCSB benchmarking suite og CDH 5.10.

Laboratorietestmiljøet blev konfigureret med fem Isilon x410-noder, der kører OneFS v8.0.0.4 og nyere v8.0.1.1. Network File System (NFS) Large Block-streamingbenchmarks blev kørt. Det forventede teoretiske samlede maksimum for testene var ~700 MB/s (3,5 GB/s) skrivninger og ~1 GB/s læsninger (5 GB/s) pr. node.

De (9) beregningsnoder er Dell PowerEdge FC630-servere, der kører CentOS v7.3.1611, alle konfigureret med 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2,30 GHz med 512 GB RAM. Lokal lagring er 2xSSD i RAID 1 formateret som XFS til både operativsystem og scratch space eller spildte filer.

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

Backend-netværket mellem computernoder og Isilon er 10 Gbps med Jumbo Frames indstillet (MTU=9162) til netværkskortene og switchportene.
CDH 5.10 blev konfigureret til at køre i en adgangszone på Isilon-klyngen. Servicekonti blev oprettet i Isilon Local-udbyderen og lokalt i klienten /etc/passwd-filerne. Alle tests blev kørt ved hjælp af en grundlæggende testklient uden særlige rettigheder.

Isilon-statistikker blev overvåget med både IIQ- og Grafana/Data Insights-pakken. CDH-statistikker blev overvåget med Cloudera Manager og også med Grafana.

Indledende test

Den første serie af test skulle bestemme de relevante parametre på HBASE-siden, der påvirkede det samlede output. YCSB-værktøjet blev brugt til at generere belastningen for HBASE. Denne indledende test blev kørt ved hjælp af en enkelt klient (edge-server) ved hjælp af "load"-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 – Maksimalt antal WAL-filer (Write-Ahead Log) – Denne værdi ganget med HDFS-blokstørrelse (dfs.blocksize) er størrelsen på den WAL, der skal afspilles igen, når en server går ned. Denne værdi er omvendt proportional med hyppigheden af skylninger til disken.
• hbase.wal.regiongrouping.numgroups - Når du bruger Multiple HDFS WAL som WALProvider angiver dette, hvor mange write-ahead-logfiler hver RegionServer skal køre. Resultaterne viser antallet af HDFS-pipelines. Skrivninger for et givet område går kun til en enkelt pipeline og spreder den samlede RegionServer-belastning.

   
Filosofien her var at parallelisere så mange skrifter som muligt. Ved at øge antallet af VAL og derefter antallet af tråde (pipeline) pr. WAL opnås dette. De to foregående diagrammer viser, at der for et givet tal for 'maxlogs', 128 eller 256, ikke vises nogen reel ændring. Dette indikerer, at testen ikke rigtig påvirker resultaterne fra klientsiden. Antallet af »pipelines« pr. fil varierede, hvilket viste en tendens, der angiver den parameter, der er følsom over for parallelisering. Det næste spørgsmål er, hvor kommer Isilon-klyngen "i vejen" enten med Disk I/O, Network, CPU eller OneFS. For at besvare dette spørgsmål se på Isilon-statistikrapporten.
Netværks- og CPU-graferne fortæller os, at Isilon-klyngen er underudnyttet og har plads til mere arbejde. CPU ville være > 80%, og netværksbåndbredde ville være mere end 3 GB / s.
 
Disse afbildninger viser HDFS-protokolstatistikken, og hvordan OneFS oversætter outputtet. HDFS ops er multipla af dfs.blocksize, som er 256MB her. Det interessante her er, at grafen 'Varme' viser OneFS-filoperationerne, og korrelationen mellem skrivninger og låse vises. I dette tilfælde foretager HBase tilføjelser til WAL'erne, så OneFS låser WAL-filen for hver skrivning, der tilføjes. Hvilket er, hvad der forventes for stabile skrivninger på et grupperet filsystem. Disse synes at bidrage til den begrænsende faktor i dette sæt test.

HBase-opdateringer

Denne næste test var at eksperimentere mere for at finde ud af, hvad der sker i stor skala. Der oprettes en tabel med en række på 1 milliard, som det tog en time at generere. Der køres en YCSB-test, som opdaterede 10 millioner af rækkerne ved hjælp af indstillingerne for "workloada" (50/50 læsning/skrivning). Denne test blev kørt på en enkelt klient. Testen kørte som en funktion af antallet af YCSB-tråde, så der kan genereres mest gennemløb. Der blev også anvendt en vis justering, og OneFS blev opgraderet til v8.0.1.1, som har ydeevnejusteringer til datanodetjenesten. Følgende diagram viser stigningen i ydeevne sammenlignet med det forrige sæt kørsler. For disse kørsler er hbase.regionserver.maxlogs indstillet til 256 og hbase.wal.regiongrouping.numgroups til 20.    
Gennemgang af disse testkørsler viser et tilsyneladende fald ved højt trådantal, hvilket enten kan være et problem med Isilon eller klientsiden. Test viser og imponerer 200 tusind operationer i sekundet ved en opdateringsforsinkelse på < 3 ms. Hver af opdateringstestkørslerne var hurtige og kunne køres fortløbende. Grafen nedenfor viser en jævn balance på tværs af Isilon-noderne for hver testkørsel.
Varmegrafen viser, at filhandlingerne er skrivninger og låse, der svarer til WAL-processernes tilføjelseskarakter.

Skalering af regionserver

Den næste test var at bestemme, hvordan Isilon-noderne (fem noder) ville klare sig mod et forskelligt antal regionsservere. Det samme opdateringsscript, der blev kørt i den forrige test, blev kørt med en tabel på en milliard rækker og en opdatering på 10 millioner rækker ved hjælp af 'workloada'. Testen brugte en enkelt klient med YCSB-tråde indstillet til 51. Den samme indstilling for maxlogs og rørledninger anvendes (henholdsvis 256 og 20).  
Resultaterne er informative, omend ikke overraskende. HBases udskaleringskarakter kombineret med Isilons udskaleringskarakter indikerede, at mere er bedre. Denne test anbefales til klienter at køre i deres miljøer som en del af deres egen størrelsesøvelse. Her er der ni servere, der skubber fem Isilon-noder, og det ser ud til, at der stadig er plads til flere, før de når det punkt med faldende afkast.

Flere kunder

Den sidste serie af tests tjente til at teste grænserne for hardwarekonfigurationen. Dette blev gjort for at bestemme den øvre grænse for de parametre, der testes. I denne serie af tests bruges to ekstra servere til at køre klienter fra. Derudover køres to YCSB-klienter fra hver server, hvilket tillod op til seks klienter hver. Hver klient kørte 512 tråde, hvilket resulterede i 4096 tråde i alt. To forskellige tabeller blev oprettet. En tabel med 4 milliarder rækker er opdelt i 600 områder og en anden med 400 millioner rækker opdelt i 90 områder.  
Graferne nedenfor viser, at tabellens størrelse betyder lidt i denne test. Isilon Heat-diagrammerne viser igen, at der er nogle få procentvise forskelle i antallet af filhandlinger. De fleste forskelle var på linje med forskellene mellem en tabel på fire milliarder rækker og en tabel med 400 millioner rækker.

Konklusion

HBase er en god kandidat til at køre på Isilon, primært på grund af udskaleringsarkitekturerne. HBase gør meget af sin egen caching, og ved at opdele tabellen på tværs af et stort antal regioner kan HBase skaleres ud med dataene. Med andre ord gør det et godt stykke arbejde med at tage sig af sine egne behov, og filsystemet er der for applikationsrobusthed. Test var ude af stand til at skubbe belastningen til det punkt, hvor tingene blev brudt. Hvis HBase er designet til 800.000 handlinger med mindre end 3 ms ventetid, understøtter denne arkitektur det. HBase understøtter et utal af præstationsjusteringer og tweaks til både klientsiden og HBase selv. Test af alle disse justeringer og justeringer var uden for rammerne af denne test.