PowerScale, Isilon OneFS: HBase-suorituskykytestaus Isilonilla

Johdanto

Suoritimme isilon X410 -klusterin suorituskyvyn vertailutestejä käyttämällä YCSB-vertailusarjaa ja CDH 5.10 -versiota.

CAE POC -testiympäristössä oli 5x Isilon x410 -solmua, joissa on OneFS 8.0.0.4 ja sitä uudemmat 8.0.1.1 NFS -suurten lohkojen suoratoistovertailut testien teoreettisten enimmäiskokojen pitäisi odottaa olevan 5 –700 Mt/s kirjoitustoimintoa (3,5 Gt/s) ja 5 –1 Gt/s (5 Gt/s).

(9) Laskentasolmuja ovat Dell PowerEdge FC630 -palvelimet, joissa on CentOS 7.3.1611, joista jokaisessa on 2 x 18C/ 36T-Intel Xeon® CPU E5-2697 v4 ja 2,30 GHz ja 512 Gt RAM-muistia. Paikallinen tallennustila on 2 xSSD RAID 1 -kokoonpanossa, joka on alustettu XFS-muotoon sekä käyttöjärjestelmässä että naarmuuntumistilassa/läikkymistiedostoissa.

Lisäksi YCSB-kuormitusta käytettiin kolmella lisäpalvelimella.

Laskentasolmujen ja Isilonin taustaverkko on 10 Gbps ja verkkokorttien ja kytkinporttien Jumbo-kehykset (MTU=9162).

Alkutestaus

Ensimmäisessä testisarjassa määritettiin HBASE-puolella tarvittavat parametrit, jotka vaikuttivat kokonaistulokseen. YCSB-työkalulla kuormitimme HBASE-tietokannan. Alkutesti suoritettiin yhdellä työasemalla (Edge-palvelimella) YCSB-tietokannan load-vaiheessa ja 40 miljoonalla rivillä. Tämä taulukko poistettiin ennen jokaista suoritusta.
 

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

hbase.regionserver.maxlogs - KIRJOITUS-Ahead-lokitiedostojen enimmäismäärä. Tämä arvo kerrottuna HDFS-lohkon koolla (dfs.blocksize) on SEN KOON KOOT, joka on toistettava palvelimen kaatuessa. Tämä arvo on käänteisessä suhteessa levyn tyhjennysten taajuudeseen.

hbase.solmu.regiongrouping.numgroups : kun KÄYTÖSSÄ on USEITA HDFS-piirtolevyjä VERKKOSOLProviderina, määritä, miten monta Write-ahead-lokia RegionServerin pitäisi suorittaa. Tämä johtaa tähän HDFS-pipeline-siirtojen määrään. Tietyn alueen kirjoitusohjelmat siirtyvät vain yhteen liitäntään, mikä jakaa RegionServer-kuormituksen kokonaismäärän.

Tämän oli tarkoitus rinnakkaistaa mahdollisimman monta kirjoitusta, joten WALien määrän lisääminen ja SEN jälkeen Säikeiden (pipeline) määrä VOI saavuttaa tämän. Kahdesta edellisestä taulukosta näkyy, että tietyn maxlogs-numeron 128 tai 256 kohdalla ei näy todellista muutosta, mikä osoittaa, että emme todellisuudessa lisää tätä numeroa työasemasta toiseen. Tiedostokohtainen pipeline-toimintojen määrä vaihtelee kuitenkin trendin mukaan, joka ilmaisee rinnakkaistukselle herkän parametrin. Seuraava kysymys on, missä Isilon "estää" Isilonin levyn I/O:n, verkon, suorittimen tai OneFS:n avulla, ja voimme tarkastella Isilonin tilastoraporttia.


 
Verkon ja suorittimen kaaviot kertovat, että Isilon-klusteria käytetään liian vähän ja että siinä on enemmän työtä. Suorittimen koko olisi > 80 % ja verkon kaistanleveys yli 3 Gt/s.



Näissä välityspalstoja ovat HDFS-protokollan tilastot ja oneFS:n kääntämät tiedot. HDFS ops on useita dfs.blocksize-tiedostoita, joiden koko on tässä 256 Mt. Kiinnostavaa tässä on se, että Lämpö-kaavio näyttää OneFS-tiedostotoiminnot ja kirjoitusten ja lukkojen korreloinnin. Tässä tapauksessa HBase tekee liitännät YHTEENSTYM-tiedostoihin, joten OneFS lukitsee JOKAista lisättyä kirjoitusta varten TIEDOT-tiedoston. Tämä vastaa klusteroitujen tiedostojärjestelmien vakaata kirjoitusta. Nämä vaikuttavat osaltaan näiden testien rajoitintekijään.

HBase-päivitykset

Seuraava testi oli kokeilla tarkemmin, mitä asteikolla tapahtuu, joten loin yhden miljardin rivin taulukon, jonka luonti kesti hyvän tunnin, ja suoritin YCSB-testin, joka päivitti 10 miljoonaa riviä kuormitusasetuksilla (50/50 luku/kirjoitus). Tämä suoritettiin yhdessä työasemassa, ja etsin myös suurinta mahdollista siirtonopeutta, joten suoritin tämän YCSB-säikeiden määrän toimintona. Lisäksi suoritimme Isilon-viritystä ja valitsimme OneFS 8.0.1.1 -versioon, jossa datasolmupalvelun suorituskykyä on muutettu. Suorituskyvyssä näkyy edellisiin versioihin verrattuna suorituskyvyn heikkeneminen. Näitä tyksiä varten määritetään hbase.regionserver.maxlogs = 256 ja hbase.solmu.regiongrouping.numgroups = 20

Kun näitä tarkastellaan, ensimmäinen ongelma on, että putoamisen säikeiden määrä on suuri. Oliko kyseessä Isilon-ongelma vai asiakaspuolen ongelma? Tulevissa kappaleissa on joitakin lisätestejä. Voin kuitenkin todeta, että yli 200 000 käyttöiän ohjaaminen päivitysviiveen ollessa < 3 ms on vaikuttava. Kukin päivitys toimi nopeasti, ja pystyin tekemään ne yksi kerrallaan. Seuraava kaavio osoittaa näiden päivitysten tasaisen tasapainon Isilon-solmuissa.



Lämpökaaviosta näkyy myös, että tiedostotoiminnot ovat KIRJOITUS- ja lukitustoimintoja, jotka vastaavat AUTOMATISOINTI-prosessien liitännässä näkyvää luontoa.

Alueen palvelinten skaalaus

Seuraava testi oli määrittää, miten Isilon-solmut (viisi niistä) menestyisivät eri aluepalvelimien kanssa. Sama edellisen testin päivityskomentosarja suoritettiin tässä. Yhden miljardin rivin taulukko ja 10 miljoonaa riviä päivitettiin workloada-komennolla yhden työaseman ja YCSB-säikeen avulla 51:een. Sama asetus säilyi myös enimmäis- ja pipeline-asemissa (vastaavasti 256 ja 20).

 
Tulokset ovat informatiivisia, ei yllättäviä. HBasen skaalautuvuus ja Isilonin skaalautuvuus ja enemmän==parempi. Suosittelen, että asiakkaat suorittavat tämän testin ympäristöissään osana omaa mitoitusansa. Palautukset saattavat heikentyä, mutta täällä on yhdeksän palvelimea, jotka työntävät viittä Isilon-solmua, ja näyttää siltä, että siinä on enemmän tilaa.

Enemmän asiakkaita

Testien viimeinen sarja tulee siitä syvästä pimeästä paikasta, jossa haluat hajottaa testaamaasi järjestelmää. Onhan se täysin pätevä tapa testata testiä, kunnes tilanne hajoaa, ja tietää testattavien parametrien ylärajan. Tässä testisarjassa minulla oli kaksi lisäpalvelinta, joiden avulla suoritin työaseman. Lisäksi suoritin kummassakin kaksi YCSB-asiakasohjelmaa, joiden avulla voin skaalata kuhunkin 512 säikeeseen, mikä olisi 4 096 säiettä. Olen luonut kaksi taulukkoa, joista toinen on 4 miljardia riviä jaettu 600 alueeseen ja toinen 400 riviä jaettu 90 alueeseen.  

 



 

Kuten näet, taulukon koolla on vain vähän merkitystä tässä testissä. Kun tarkastelet Isilon Heat -kaavioita uudelleen, huomaat, että tiedostotoimintojen määrässä on muutama prosenttiero, joka liittyy lähinnä neljän miljardin rivin taulukon ja 400 miljoonan rivin eroihin.

Johtopäätös

HBase on hyvä kandidaatti Isilon-suorittimiin lähinnä skaalautuvien arkkitehtuurien vuoksi. HBase tekee monia omia välimuistitallennustaan ja jakaa taulukon useille alueille, joilla HBase skaalautuu tietoihin. Toisin sanoen se tekee hyvää työtä huolehtiakseen omista tarpeistaan, ja tiedostojärjestelmä on luotettava. Kuormitustestit eivät ehtineet hajottaa asioita, mutta jos katsot HBase-mallissasi neljää miljardia riviä ja odotat 800 000 toimintoa alle 3 ms:n viiveellä, tämä arkkitehtuuri tukee sitä. Jos havaitset, että en ole maininnut paljonkaan muita asiakaspuolen säätöjä, joita voit käyttää itse HBasessa, oletan, että kaikki nämä muutokset ovat edelleen voimassa, eivätkä ne sisälly tähän testiin.