PowerScale, Isilon OneFS: HBase-prestandatest på Isilon

Introduktion

Vi gjorde en serie prestandatester på ett Isilon X410-kluster med hjälp av YCSB benchmarking Suite och CDH 5.10.

CAE POC-labmiljön konfigurerades med 5x Isilon x410-noder kör OneFS 8.0.0.4 och senare 8.0.1.1 NFS stora blockströmningstester Vi bör förvänta oss 5x ~700 MB/s skrivningar (3,5 GB/s) och 5 x ~1 Gbit/s-läsningar (5 GB/s) för våra teoretiska sammanlagda maxvärden i något av dessa tester.

De (9) beräkningsnoderna är Dell PowerEdge FC630-servrar som kör CentOS 7.3.1611 var och en konfigurerad med 2 x 18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2,30 GHz med 512 GB RAM. Lokal lagring är 2xSSD i RAID 1 formaterad som XFS för både operativsystem och scratch space/spill-filer.

Det fanns även tre ytterligare kantservrar som användes för att öka YCSB-belastningen.

Backend-nätverket mellan beräkningsnoder och Isilon är 10 Gbit/s med jumboramar inställda (MTU=9162) för nätverkskorten och switchportarna.

Första test

Den första testserien var att fastställa de relevanta parametrarna på HBASE-sidan som påverkade det totala utdata. Vi använde YCSB-verktyget för att generera belastningen för HBASE. Det här första testet kördes med en enda klient (kantserver) med hjälp av belastningsfasen på YCSB och 40 miljoner rader. Den här tabellen togs bort före varje körning.
 

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

hbase.regionserver.maxlogs – maximalt antal WAL-filer (Write-Ahead Log). Det här värdet multiplicerat med HDFS-blockstorlek (dfs.blocksize) är storleken på WAL som måste spelas upp när en server kraschar. Det här värdet är omvänt proportionerligt med rensningsfrekvensen till disken.

hbase.wal.regiongrouping.numgroups – När du använder Multiple HDFS WAL som WALProvider anger du hur många write-ahead-loggar som varje RegionServer ska köra. Resulterar i det här antalet HDFS-pipelines. Skrivningar för en viss region går bara till en enda pipeline som sprider den totala RegionServer-belastningen.

Filosofin här var att parallellisera så många skrivningar som möjligt, så att öka antalet WAL:er och sedan antalet trådar (pipeline) per WAL åstadkommer detta. De två föregående diagrammen visar att vi för ett visst nummer för "maxlogs" 128 eller 256 inte ser någon verklig förändring som indikerar att vi inte riktigt trycker in det här numret från klientsidan. Oby varierande antalet "pipelines" per fil, men vi ser den trend som indikerar den parameter som är känslig för parallellisering. Nästa fråga är då var Isilon "kommer i vägen" antingen med disk-I/O, nätverk, cpu eller OneFS, och vi kan titta på vad Isilon-statistikrapporten rapporterar.


 
Nätverks- och PROCESSORdiagrammet visar att Isilon-klustret är underutnyttat och har utrymme för mer arbete. Processorn skulle vara > 80 %, och nätverkets bandbredd skulle vara mer än 3 Gbit/s.



I dessa diagram visas statistik för HDFS-protokoll och hur de översätts av OneFS. HDFS ops är multipler av dfs.blocksize, vilket är 256 MB här. Det intressanta här är att "Heat"-diagrammet visar OneFS-filåtgärderna och du kan se korrelation mellan skrivningar och lås. I det här fallet lägger HBase till WAL-filerna så OneFS låser WAL-filen för varje skrivning som läggs till. Det är vad vi förväntar oss för stabila skrivningar i ett klustrat filsystem. De verkar bidra till begränsningsfaktorn i den här testuppsättningen.

HBase-uppdateringar

Nästa test var att experimentera lite mer med att hitta vad som händer i skala så jag skapade en tabell på en miljard rader, som tog en bra timme att generera, och sedan gjorde en YCSB-körning som uppdaterade 10 miljoner av raderna med inställningarna "workloada" (50/50 läs/skriv). Detta kördes på en enda klient, och jag letade även efter det dataflöde jag kunde generera så att jag körde det här som en funktion av antalet YCSB-trådar. En annan anmärkning var att vi finjusterade Isilon och gick till OneFS 8.0.1.1 som har prestandajusteringar för datanodstjänsten. Du kan se en ökning av prestanda jämfört med föregående uppsättning körs. För dessa körs ställer vi in hbase.regionserver.maxlogs = 256 och hbase.wal.regiongrouping.numgroups = 20

När man tittar på dessa körs det första som syns är att det faller av vid högt antal trådar. Jag var inaktiv om det var ett Isilon-problem eller problem på klientsidan. Vi ser ytterligare test angående det i kommande stycke. Men jag kan säga att det är imponerande att köra 200 000 + drift vid en uppdateringslatens < på 3 ms. Var och en av de här uppdateringarna gick snabbt och jag kunde göra dem en efter en, och diagrammet nedan visar en jämn balans mellan Isilon-noderna för dessa körs.



I diagrammet Heat ser du återigen att filåtgärderna skrivs och lås som motsvarar append-karaktären hos WAL-processerna.

Skalning av regionserver

Nästa test var att fastställa hur Isilon-noderna (fem av dem) skulle användas mot ett annat antal regionservrar. Samma uppdateringsskript som kördes i föregående test kördes här. En tabell på en miljard rader och 10 miljoner rader uppdaterades med hjälp av "workloada" med en enda klient och YCSB-trådar på 51. Vi har också samma inställning på maxlogs- och pipelines (256 respektive 20).

 
Resultaten är informativa, det är inte överraskande. Den utskalade karaktären hos HBase kombinerat med isilons skalbara natur och more==bättre. Det här är ett test som jag skulle rekommendera kunder att köra på sina miljöer som en del av sin storleksändring. Det kan komma att minska returerna, men här finns nio stora servrar som pressar fem Isilon-noder och det ser ut som att det finns utrymme för mer.

Fler klienter

Den sista serien tester kommer från den djupa mörka platsen som gör att du vill bryta det system som du testar. Det är trots allt en perfekt giltig vetenskapliga metod att rat fabrikstesta tills något går sönder och därmed veta vad den övre gränsen för de parametrar som testas är. I den här testserien hade jag två ytterligare servrar som jag kunde använda för att köra klienten från. Dessutom körde jag två YCSB-klienter på var och en, vilket gjorde att jag kunde skala upp till sex klienter var och en med 512 trådar, vilket skulle vara totalt 4 096 trådar. Jag gick tillbaka och skapade två olika tabeller ett med 4 miljarder rader indelade i 600 regioner och en med 400s rader uppdelade i 90 regioner.  

 



 

Som du ser betyder storleken på tabellen lite i det här testet. När du tittar på Isilon Heat-diagrammen igen kan du se att det finns en par procentuell skillnad i antalet filåtgärder som oftast infogas med skillnaderna i en tabell med fyra miljarder rader till 400 miljoner rader.

Slutsats

HBase är en bra kandidat för att köra Isilon, främst på grund av de utskalade till utskalade arkitekturerna. HBase utför en stor del av sin egen cachelagring och delar tabellen över ett stort antal regioner där HBase kan skalas ut med dina data. Med andra ord gör den ett bra jobb med att ta hand om sina egna behov, och filsystemet finns där för beständighet. Vi kunde inte göra inläsningstesterna, men om du tittar på fyra miljarder rader i din HBase-design och förväntar dig 800 000 operationer med mindre än 3 ms latens stöder den här arkitekturen den. Om du märker att jag inte nämnde mycket mer om någon av de andra justeringarna på klientsidan som du kan tillämpa på själva HBase skulle jag förvänta mig att alla dessa justeringar fortfarande är giltiga, och utanför det här testets omfattning.