PowerScale, Isilon OneFS: HBase-suorituskykytestaus Isilonissa

Ei tarvita

Ei tarvita

Johdanto

Isilon X410 -klusterille suoritettiin sarja suorituskyvyn vertailutestejä käyttäen YCSB benchmarking suitea ja CDH 5.10:tä.

Laboratoriotestiympäristöön määritettiin viisi Isilon x410 -solmua, joissa oli OneFS 8.0.0.4 tai uudempi versio 8.0.1.1. Network File System (NFS) Large Block -suoratoiston vertailuarvot suoritettiin. Testien odotettu teoreettinen yhteenlaskettu enimmäismäärä oli ~700 Mt/s (3,5 Gt/s) kirjoitusta ja ~1 Gt/s lukua (5 Gt/s) solmua kohti.

(9) Laskentasolmut ovat Dell PowerEdge FC630 -palvelimia, joissa on CentOS v7.3.1611 ja joissa kussakin on 2x18C/36T-Intel Xeon® CPU E5-2697 v4 @ 2,30 GHz ja 512 Gt RAM-muistia. Paikallinen tallennus on 2xSSD RAID 1 -alustalla, joka on alustettu XFS-muotoon sekä käyttöjärjestelmälle että työavaruus- tai vuototiedostoille.

Siellä oli myös kolme muuta Edge-palvelinta, joita käytettiin YCSB-kuorman ajamiseen.

Laskentasolmujen ja Isilonin välinen taustaverkko on 10 Gbps, ja jumbokehykset on asetettu (MTU=9162) verkkokorteille ja kytkinporteille.
CDH 5.10 on määritetty toimimaan Isilon-klusterin Access Zone -alueella. Palvelutilit on luotu Isilonin paikallisessa palveluntarjoajassa ja paikallisesti asiakkaan /etc/passwd-tiedostoissa. Kaikki testit suoritettiin perustestiohjelmalla ilman erityisiä oikeuksia.

Isilonin tilastoja seurattiin sekä IIQ- että Grafana/Data Insights -paketilla. CDH:n tilastoja seurattiin Cloudera Managerilla ja myös Grafanalla.

Alustava testaus

Ensimmäisen testisarjan tarkoituksena oli määrittää HBASE-puolen asiaankuuluvat parametrit, jotka vaikuttivat kokonaistuotokseen. YCSB-työkalua käytettiin HBASE-kuorman luomiseen. Tämä ensimmäinen testi suoritettiin yhdellä työasemalla (reunapalvelimella) käyttäen YCSB:n ja 40 miljoonan rivin latausvaihetta. Tämä taulukko on poistettu 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 - Write-Ahead Log (WAL) -tiedostojen enimmäismäärä – Tämä arvo kerrottuna HDFS-lohkokoolla (dfs.blocksize) on WAL-koon koko, joka on toistettava, kun palvelin kaatuu. Tämä arvo on kääntäen verrannollinen levyn huuhtelujen taajuuteen.
• hbase.wal.regiongrouping.numgroups - Kun WALProviderina käytetään Multiple HDFS WAL -arvoa, tämä määrittää, kuinka monta eteenpäin kirjoittavaa lokia kunkin RegionServerin tulisi suorittaa. Tulokset osoittavat HDFS-putkistojen määrän. Tietyn alueen kirjoitukset menevät vain yhteen putkeen, mikä jakaa RegionServerin kokonaiskuormituksen.

   
Filosofiana oli rinnastaa mahdollisimman monta kirjoitusta. Tämä saavutetaan lisäämällä WALien määrää ja sitten kierteiden (putkien) määrää WALia kohti. Kaksi edellistä kaaviota osoittavat, että tietylle "maxlogs" -luvulle, 128 tai 256, todellista muutosta ei näytetä. Tämä osoittaa, että testi ei todellakaan vaikuta tuloksiin asiakkaan puolelta. "Putkien" määrä tiedostoa kohti vaihteli, mikä osoitti suuntauksen, joka osoittaa rinnakkaisuudelle herkän parametrin. Seuraava kysymys kuuluu, mistä Isilon-klusteri tulee tielle, kun käytössä on I/O-levy, verkko, suoritin tai OneFS. Voit vastata tähän kysymykseen tutustumalla Isilonin tilastoraporttiin.
Verkko- ja suoritinkaaviot kertovat, että Isilon-klusteri on vajaakäytössä ja sillä on tilaa lisätyölle. CPU olisi > 80% ja verkon kaistanleveys olisi yli 3 GB/s.
 
Nämä kaaviot näyttävät HDFS-protokollan tilastot ja sen, miten OneFS kääntää tuloksen. HDFS-toiminnot ovat dfs.blocksizen kerrannaisia, mikä on tässä 256 Mt. Mielenkiintoista tässä on se, että Heat-kaavio näyttää OneFS-tiedostotoiminnot ja kirjoitusten ja lukitusten korrelaatio näkyy. Tässä tapauksessa HBase tekee lisäyksiä WAL-tiedostoihin, joten OneFS lukitsee WAL-tiedoston jokaisen liitetyn kirjoituksen osalta. Tätä odotetaan vakailta kirjoituksilta klusteroidussa tiedostojärjestelmässä. Nämä näyttäisivät vaikuttavan rajoittavaan tekijään näissä testeissä.

HBase-päivitykset

Seuraava testi oli tehdä lisää kokeiluja selvittääkseen, mitä tapahtuu suuressa mittakaavassa. Luodaan 1 miljardin rivin taulukko, jonka luominen kesti tunnin. YCSB-testi suoritetaan, joka päivitti 10 miljoonaa riviä workloada-asetuksilla (50/50 luku/kirjoitus). Tämä testi suoritettiin yhdelle asiakkaalle. Testi suoritettiin YCSB-säikeiden lukumäärän funktiona, jotta voidaan tuottaa eniten läpimenoa. Lisäksi joitakin hienosäätöjä käytettiin ja OneFS päivitettiin versioon 8.0.1.1, jossa on suorituskykyparannuksia Datasolmu-palvelua varten. Seuraavassa kaaviossa esitetään suorituskyvyn paraneminen edellisiin suorituksiin verrattuna. Näiden suoritusten hbase.regionserver.maxlogs-arvoksi määritetään 256 ja hbase.wal.regiongrouping.numgroups-arvoksi 20.    
Näiden testiajojen tarkastelu osoittaa ilmeisen pudotuksen suurella säiemäärällä, mikä voi olla joko Isilon- tai asiakaspuolen ongelma. Testitulos on 200 tuhatta toimintoa sekunnissa 3 ms:n päivitysviiveellä < . Jokainen päivitystesti oli nopea ja voitiin suorittaa peräkkäin. Alla oleva kaavio näyttää Isilon-solmujen tasaisen tasapainon kullekin testiajolle.
Lämpökaavio osoittaa, että tiedostotoiminnot ovat kirjoitus- ja lukitustoimintoja, jotka vastaavat WAL-prosessien liittämisluonnetta.

Aluepalvelimen skaalaus

Seuraavassa testissä määritettiin, miten Isilon-solmut (viisi solmua) pärjäisivät eri määrällä aluepalvelimia. Sama päivityskomentosarja, joka suoritettiin edellisessä testissä, sisälsi miljardin rivin taulukon ja 10 miljoonan rivin päivityksen workloada-komennolla. Testissä käytettiin yhtä asiakasta, jonka YCSB-säikeet oli asetettu arvoon 51. Samaa asetusta käytetään maxlogeille ja putkille (vastaavasti 256 ja 20).  
Tulokset ovat informatiivisia, vaikkakaan eivät yllättäviä. HBase-ominaisuuden skaalautuva luonne yhdistettynä Isilonin skaalautuvaan luonteeseen osoitti, että enemmän on parempi. Tätä testiä suositellaan asiakkaille suoritettavaksi ympäristöissään osana omaa mitoitusharjoitustaan. Täällä on yhdeksän palvelinta, jotka työntävät viittä Isilon-solmua, ja näyttää siltä, että vielä on tilaa lisää, ennen kuin saavutetaan laskevan tuoton piste.

Lisää asiakkaita

Viimeinen testisarja testasi laitteistokokoonpanon rajoja. Tämä tehtiin testattavien parametrien ylärajan määrittämiseksi. Tässä testisarjassa käytetään kahta lisäpalvelinta asiakkaiden suorittamiseen. Lisäksi jokaiselta palvelimelta ajetaan kaksi YCSB-asiakasta, mikä sallii kullekin enintään kuusi asiakasta. Jokainen asiakas ajoi 512 säiettä, jolloin yhteensä 4096 säiettä. Luotiin kaksi erilaista taulukkoa. Yksi taulukko, jossa on 4 miljardia riviä, on jaettu 600 alueeseen, ja toinen, jossa on 400 miljoonaa riviä, on jaettu 90 alueeseen.  
Alla olevat kaaviot osoittavat, että taulukon koolla ei ole juurikaan merkitystä tässä testissä. Isilonin lämpökaaviot osoittavat jälleen, että tiedostotoimintojen määrässä on muutama prosentuaalinen ero. Useimmat erot olivat linjassa neljän miljardin rivin taulukon ja 400 miljoonan rivin taulukon erojen kanssa.

Johtopäätös

HBase on hyvä ehdokas käytettäväksi Isilonissa, lähinnä skaalautuvien arkkitehtuurien vuoksi. HBase tekee paljon omaa välimuistiaan ja jakamalla taulukon useille alueille HBase voi skaalautua tietojen kanssa. Toisin sanoen se tekee hyvää työtä huolehtiessaan omista tarpeistaan, ja tiedostojärjestelmä on olemassa sovellusten joustavuutta varten. Testaus ei pystynyt työntämään kuormaa siihen pisteeseen, että asiat rikkoutuisivat. Jos HBase on suunniteltu 800 000 operaatioon alle 3 ms:n viiveellä, tämä arkkitehtuuri tukee sitä. HBase tukee lukemattomia suorituskyvyn säätöjä ja säätöjä sekä asiakaspuolelle että itse HBaselle. Kaikkien näiden säätöjen ja säätöjen testaaminen ei kuulunut tämän testin piiriin.