Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Create and access a list of your products

PowerScale, Isilon OneFS: HBase-prestandatest på Isilon

Summary: I den här artikeln beskrivs prestandatesterna för prestandatester på ett Isilon X410-kluster med hjälp av YCSB benchmarking Suite och CDH 5.10.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Krävs inte

Cause

Krävs inte

Resolution

Obs! Det här avsnittet är en del av Informationshubben använda Hadoop med OneFS. 


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.

SLN319167_en_US__1i_isilon_1arch_kb_v1a
 
CDH 5.10 har konfigurerats för att köras i en åtkomstzon på Isilon. Tjänstekonton skapades i Isilon Local-leverantören och lokalt i klientens /etc/passwd-filer. Alla tester kördes med en grundläggande testanvändare utan några särskilda behörigheter.

Isilon-statistik övervakades med både IIQ- och Grafana/Data Insights-paketet. CDH-statistik övervakades med Cloudera Manager och även med Grafana.


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.

SLN319167_en_US__2i_isilon_2thruvspipe_kb_v1a

SLN319167_en_US__3i_isilon_3latvspipe_kb_v1a
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.

SLN319167_en_US__4i_isilon_4networkload_kb_v1a
 
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.

SLN319167_en_US__5i_isilon_5proto_kb_v1a

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

SLN319167_en_US__6i_isilon_6table1_kb_v1a

SLN319167_en_US__7i_isilon_7table2_kb_v1a
SLN319167_en_US__8i_isilon_8table3_kb_v1a

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.

SLN319167_en_US__9i_isilon_9heat_kb_v1a

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).

SLN319167_en_US__10i_isilon_10scaling1_kb_v1a

SLN319167_en_US__11i_isilon_11scaling2_kb_v1a
 
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.  

 SLN319167_en_US__12i_isilon_12clientscaling1_kb_v1a

SLN319167_en_US__13i_isilon_13clientscaling2_kb_v1a

 
SLN319167_en_US__14i_isilon_14clientscaling3_kb_v1a
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.

SLN319167_en_US__15i_isilon_15row1_kb_v1a


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.

 

Affected Products

Isilon, PowerScale OneFS
Article Properties
Article Number: 000128942
Article Type: Solution
Last Modified: 20 Sept 2023
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.