Dell EMC Ready -ratkaisu HPC PixStor -tallennukseen

Artikkelin on kirjoittanut Mario Gallegos HPC:stä ja AI Innovation Labista lokakuussa 2019

Sisällysluettelo

1. Johdanto
   1. Ratkaisuarkkitehtuuri
   2. Ratkaisun osat
2. Suorituskyvyn karakterisointi
   1. Peräkkäinen IOzone-suorituskyky N-asiakkaista N-tiedostoihin
   2. Peräkkäinen IOR Performance N -asiakkaat 1 tiedostoon
   3. Satunnaiset pienet lohkot IOzone-suorituskyky N-asiakkaista N-tiedostoihin
   4. Metatietojen suorituskyky MDtestillä tyhjiä tiedostoja käytettäessä
   5. Metatietojen suorituskyky MDtestillä käyttäen 4 KiB-tiedostoa
   6. Metatietojen suorituskyky MDtestillä 3K-tiedostoilla
3. Edistynyt analysointi
4. Johtopäätökset ja jatkosuunnitelmat

Johdanto

Ratkaisuarkkitehtuuri

Ratkaisun osat

Suorituskyvyn karakterisointi

•     IOzone N:stä N:ään peräkkäin
•     IOR N - 1 peräkkäin
•     IOzone satunnainen
•     MDtest
  
  Kaikkien edellä lueteltujen vertailuarvojen osalta testialustalla oli asiakkaat alla olevassa taulukossa 2 kuvatulla tavalla. Koska testattavia laskentasolmuja oli 16, kun tarvittiin suurempi säikeiden määrä, nämä säikeet jakautuivat tasaisesti laskentasolmuille (ts. 32 säiettä = 2 säiettä solmua kohti, 64 säiettä = 4 säiettä solmua kohti, 128 säiettä = 8 säiettä solmua kohti, 256 säiettä = 16 säiettä solmua kohti, 512 säiettä = 32 säiettä solmua kohti, 1024 säiettä = 64 säiettä solmua kohti). Tarkoituksena oli simuloida suurempaa määrää samanaikaisia asiakkaita rajoitetulla määrällä laskentasolmuja. Koska vertailuarvot tukevat suurta määrää säikeitä, käytettiin enimmäisarvoa 1024 asti (määritetty kullekin testille) välttäen samalla liiallista kontekstin vaihtamista ja muita siihen liittyviä sivuvaikutuksia, jotka vaikuttavat suorituskykytuloksiin.
  
  Taulukko 2 Asiakkaan testialusta

  Asiakassolmujen määrä	16
  Asiakassolmu	C6320
  Suorittimet asiakassolmua kohden	2 x Intel(R) Xeon(R) Gold E5-2697v4, 18 ydintä @ 2,30 GHz
  Muistia asiakassolmua kohden	12 x 16 GiB 2 400 MT/s RDIMM
  BIOS	2.8.0
  Käyttöjärjestelmän ydin	3.10.0-957.10.1
  GPFS-versio	5.0.3

   

  ---

  Peräkkäinen IOzone-suorituskyky N-asiakkaista N-tiedostoihin

  Peräkkäisten N-asiakkaiden ja N-tiedostojen suorituskyky mitattiin IOzone-versiolla 3.487. Suoritetut testit vaihtelivat yhdestä säikeestä jopa 1024 säikeeseen. 
  Välimuistivaikutukset minimoitiin asettamalla GPFS-sivuvarannon säädettäväksi 16 GiB ja käyttämällä yli kaksi kertaa suurempia tiedostoja. On tärkeää huomata, että GPFS: lle, joka viritetään, asettaa tietojen välimuistiin tallentamiseen käytettävän muistin enimmäismäärän asennetun ja vapaan RAM-muistin määrästä riippumatta. On myös tärkeää huomata, että aiemmissa Dell EMC:n HPC-ratkaisuissa suurten peräkkäisten siirtojen lohkokoko on 1 MiB, kun taas GPFS:ssä oli 8 MiB-lohkoa, joten tätä arvoa käytetään vertailukohtana optimaalisen suorituskyvyn saavuttamiseksi. Se voi näyttää liian suurelta ja ilmeisesti tuhlata liikaa tilaa, mutta GPFS käyttää alalohkojen allokointia estääkseen tämän tilanteen. Nykyisessä kokoonpanossa kukin lohko jaettiin 256 32 KiB: n alilohkoon. 
  Seuraavia komentoja käytettiin kirjoitusten ja lukujen vertailuarvon suorittamiseen, jossa säikeet olivat muuttuja käytettyjen säikeiden lukumäärällä (1–1024 kahden potenssin lisäyksellä) ja säieluettelo oli tiedosto, joka jakoi jokaisen säikeen eri solmuun käyttämällä pyöreää punarintaa jakamaan ne homogeenisesti 16 laskentasolmuun.

  ./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
  ./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist

  
  Kuva 2:  N:stä N:ään peräkkäinen suorituskyky
  
  
  Tuloksista voimme havaita, että suorituskyky nousee erittäin nopeasti käytettyjen asiakkaiden lukumäärän myötä ja saavuttaa sitten tasangon, joka on vakaa, kunnes IOzonen sallimien säikeiden enimmäismäärä saavutetaan, ja siksi suurten tiedostojen peräkkäinen suorituskyky on vakaa jopa 1024 samanaikaiselle asiakkaalle. Huomaa, että suurin lukusuorituskyky oli 23 Gt/s 32 säikeellä ja hyvin todennäköisesti pullonkaula oli InfiniBand EDR -liitäntä, kun taas ME4-järjestelmissä oli vielä jonkin verran ylimääräistä suorituskykyä. Huomaa myös, että suurin kirjoitussuorituskyky 16,7 saavutettiin hieman aikaisin 16 säikeen kohdalla ja se on ilmeisesti alhainen verrattuna ME4-levyjärjestelmien teknisiin tietoihin.
  Tässä on tärkeää muistaa, että GPFS: n ensisijainen toimintatapa on hajallaan ja ratkaisu alustettiin käyttämään sitä. Tässä tilassa lohkot jaetaan alusta alkaen pseudo-satunnaisesti levittämällä tietoja kunkin kiintolevyn koko pinnalle. Vaikka ilmeinen haittapuoli on pienempi alkuperäinen maksimisuorituskyky, tämä suorituskyky säilyy melko vakiona riippumatta siitä, kuinka paljon tilaa tiedostojärjestelmässä käytetään. Toisin kuin muut rinnakkaiset tiedostojärjestelmät, jotka käyttävät alun perin ulompia raitoja, joihin mahtuu enemmän dataa (sektoreita) levyn kierrosta kohden ja joilla on siksi korkein mahdollinen suorituskyky, jonka kiintolevyt voivat tarjota, mutta koska järjestelmä käyttää enemmän tilaa, käytetään sisäraitoja, joissa on vähemmän dataa kierrosta kohti, mikä heikentää suorituskykyä. 
  
   

  ---

  Peräkkäinen IOR Performance N -asiakkaat 1 tiedostoon

  Peräkkäisten N-asiakkaiden suorituskyky yhteen jaettuun tiedostoon mitattiin IOR-versiolla 3.3.0, jota OpenMPI v4.0.1 avusti vertailuarvon suorittamiseksi 16 laskentasolmussa. Suoritetut testit vaihtelivat yhdestä säikeestä 1024 säikeeseen.
  Välimuistivaikutukset minimoitiin asettamalla GPFS-sivuvarannon säädettäväksi 16 GiB ja käyttämällä yli kaksi kertaa suurempia tiedostoja. Tässä vertailutestissä käytettiin 8 MiB-lohkoa optimaalisen suorituskyvyn saavuttamiseksi. Edellisessä suorituskykytestiosassa on täydellisempi selitys näistä asioista. 
  Kirjoitus- ja lukuvertailun suorittamiseen käytettiin seuraavia komentoja, joissa säikeet olivat muuttuja käytettyjen säikeiden lukumäärällä (1–1024 kahden potenssin lisäyksellä) ja my_hosts.$Threads on vastaava tiedosto, joka jakoi jokaisen säikeen eri solmuun käyttämällä round robinia jakamaan ne homogeenisesti 16 laskentasolmuun.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --etuliite /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G 

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --etuliite /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G

  
  
  Kuva 3: N - 1 peräkkäinen suorituskyky
  
  Tuloksista voimme havaita, että suorituskyky nousee jälleen erittäin nopeasti käytettyjen asiakkaiden lukumäärän myötä ja saavuttaa sitten tasangon, joka on puolistabiili lukemiseen ja erittäin vakaa kirjoituksiin aina tässä testissä käytettyjen säikeiden enimmäismäärään asti. Siksi suurten yksittäisten jaettujen tiedostojen peräkkäinen suorituskyky on vakaa jopa 1024 samanaikaiselle asiakkaalle. Huomaa, että suurin lukusuorituskyky oli 23,7 Gt/s 16 säikeellä ja hyvin todennäköisesti pullonkaula oli InfiniBand EDR -liitäntä, kun taas ME4-järjestelmissä oli vielä jonkin verran ylimääräistä suorituskykyä. Lisäksi lukusuorituskyky heikkeni tästä arvosta tasangolle noin 20,5 Gt/s:n nopeuteen asti, ja hetkellinen lasku oli 18,5 Gt/s 128 säikeessä. Huomaa myös, että enimmäiskirjoitussuorituskyky 16,5 saavutettiin 16 säikeessä ja se on ilmeisesti alhainen verrattuna ME4-levyjärjestelmien teknisiin tietoihin.
   

  ---

  Satunnaiset pienet lohkot IOzone-suorituskyky N-asiakkaista N-tiedostoihin

  Satunnaisten N-asiakkaiden ja N-tiedostojen suorituskyky mitattiin IOzone-versiolla 3.487. Suoritetut testit vaihtelivat yhdestä säikeestä 1024 säikeeseen. Tässä vertailutestissä käytettiin 4 KiB-lohkoa pienten lohkojen liikenteen jäljittelemiseen.
  Välimuistivaikutukset minimoitiin asettamalla GPFS-sivuvaranto säädettäväksi 16 GiB:ksi ja käyttämällä kaksi kertaa suurempia tiedostoja. Ensimmäisessä suorituskykytestiosiossa on kattavampi selitys siitä, miksi tämä on tehokasta GPFS:ssä. 
  Seuraavaa komentoa käytettiin vertailuarvon suorittamiseen satunnaisessa IO-tilassa sekä kirjoitus- että lukutoiminnoissa, joissa säikeet olivat muuttuja käytettyjen säikeiden lukumäärällä (1–1024 kahden potenssin lisäyksellä) ja säieluettelo oli tiedosto, joka jakoi jokaisen säikeen eri solmuun käyttämällä round robinia levittämään ne homogeenisesti 16 laskentasolmuun.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Kuva 4:  N - N satunnainen suorituskyky
  
  Tuloksista voimme havaita, että kirjoitussuorituskyky alkaa korkeasta arvosta, lähes 8.2K IOPS, ja nousee tasaisesti jopa 128 säikeeseen, missä se saavuttaa tasangon ja pysyy lähellä maksimiarvoa 16.2K IOP. Toisaalta lukusuorituskyky alkaa hyvin pienestä, yli 200 IOPS: sta, ja lisää suorituskykyä lähes lineaarisesti käytettyjen asiakkaiden lukumäärän kanssa (muista, että säikeiden määrä kaksinkertaistuu kutakin datapistettä kohti) ja saavuttaa 20.4K IOPS: n maksimisuorituskyvyn 512 säikeellä ilman merkkejä maksimin saavuttamisesta. Jos kuitenkin käytetään enemmän säikeitä nykyisissä 16 laskentasolmussa, joissa kussakin on kaksi suoritinta ja joissa kussakin suorittimessa on 18 ydintä, on rajoitus, että ytimiä ei ole tarpeeksi IOzone-säikeiden enimmäismäärän suorittamiseen (1024) ilman kontekstin vaihtamista (16 x 2 x 18 = 576 ydintä), mikä rajoittaa suorituskykyä huomattavasti. Tuleva testi, jossa on enemmän laskentasolmuja, voisi tarkistaa, mikä satunnainen lukusuorituskyky voidaan saavuttaa 1024 säikeellä, joissa on IOzone, tai IOR: ää voitaisiin käyttää tutkimaan käyttäytymistä yli 1024 säikeellä.
  
   

  ---

  Metatietojen suorituskyky MDtestillä tyhjiä tiedostoja käytettäessä

  Metatietojen suorituskykyä mitattiin MDtest-versiolla 3.3.0, jota OpenMPI v4.0.1 avusti vertailuarvon suorittamiseksi 16 laskentasolmussa. Suoritetut testit vaihtelivat yksittäisestä säikeestä 512 säikeeseen. Vertailuarvoa käytettiin vain tiedostoihin (ei hakemistojen metatietoja), jolloin saatiin ratkaisun käsittelemien luomien, tilastojen, lukujen ja poistojen määrä.
  Jotta ratkaisua voitaisiin verrata asianmukaisesti muihin Dell EMC HPC -tallennusratkaisuihin, käytettiin valinnaista suuren kysynnän metatietomoduulia, mutta siinä käytettiin yhtä ME4024-järjestelmää, vaikka tässä työssä testatussa suuressa kokoonpanossa oli kaksi ME4024-konetta. 
  Tämä suuren kysynnän metatietomoduuli voi tukea enintään neljää ME4024-levyjärjestelmää, ja ME4024-levyjärjestelmien määrää suositellaan lisättäväksi neljään ennen uuden metatietomoduulin lisäämistä. Muiden ME4024-taulukoiden odotetaan parantavan metatietojen suorituskykyä lineaarisesti jokaisen lisätaulukon kanssa, paitsi ehkä tilasto-operaatioissa (ja tyhjien tiedostojen luvuissa), koska luvut ovat erittäin suuria, jossain vaiheessa suorittimista tulee pullonkaula ja suorituskyky ei jatka lineaarisuutta.
  Vertailuarvon suorittamiseen käytettiin seuraavaa komentoa, jossa säikeet olivat muuttuja käytettyjen säikeiden lukumäärällä (1 - 512 kahden potenssin lisäyksellä) ja my_hosts.$Threads on vastaava tiedosto, joka allokoi jokaisen säikeen eri solmuun käyttämällä pyöreää punarintaa levittämään ne homogeenisesti 16 laskentasolmuun. Samoin kuin Random IO -vertailuarvo, säikeiden enimmäismäärä rajoitettiin 512: een, koska ytimiä ei ole tarpeeksi 1024 säikeelle ja kontekstin vaihtaminen vaikuttaisi tuloksiin, raportoimalla luvun pienemmäksi kuin ratkaisun todellinen suorituskyky.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --etuliite /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F

  
  Koska suorituskykytuloksiin voivat vaikuttaa IOP:iden kokonaismäärä, tiedostojen määrä hakemistoa kohden ja säikeiden määrä, päätettiin pitää tiedostojen kokonaismääräksi 2 MiB tiedostoa (2^21 = 2097152), tiedostojen määräksi hakemistoa kohden vahvistettiin 1024 ja hakemistojen määrä vaihteli säikeiden määrän muuttuessa taulukon 3 mukaisesti.
  
  Taulukko 3:  MDtestaa hakemistoissa olevien tiedostojen jakelu

  Säikeiden määrä	Hakemistojen määrä säiettä kohden	Tiedostojen kokonaismäärä
  1	2048	2,097,152
  2	1024	2,097,152
  4	512	2,097,152
  8	256	2,097,152
  16	128	2,097,152
  32	64	2,097,152
  64	32	2,097,152
  128	16	2,097,152
  256	8	2,097,152
  512	4	2,097,152
  1024	2	2,097,152

  
  
  
  
  Kuva 5: Metatietojen suorituskyky - tyhjät tiedostot
  
  Huomaa ensin, että valittu asteikko oli logaritminen kantaluvun 10 kanssa, jotta voidaan verrata operaatioita, joilla on eroja useita suuruusluokkia; Muuten osa operaatioista näyttäisi tasaiselta viivalta, joka on lähellä nollaa normaalissa kuvaajassa. Logaritmikuvaaja, jonka kanta on 2, voisi olla sopivampi, koska säikeiden lukumäärää lisätään potenssilla 2, mutta kuvaaja näyttäisi melko samanlaiselta, ja ihmisillä on taipumus käsitellä ja muistaa parempia numeroita potenssin 10 perusteella.
  
  
  Järjestelmä saa erittäin hyviä tuloksia, kun tilasto- ja lukutoiminnot saavuttavat huippuarvonsa 64 säikeellä 11,2 miljoonalla operaatiolla / s ja 4,8 miljoonalla operaatiolla / s. Irrotustoiminnot saavuttivat maksimiarvon 169,4K op/s 16 säikeellä ja Create-toiminnot saavuttivat huippunsa 512 säikeessä 194,2K op/s:lla. Tilasto- ja lukutoiminnoissa on enemmän vaihtelua, mutta kun ne saavuttavat huippuarvonsa, suorituskyky ei laske alle 3 miljoonaan op/s tilastoihin ja 2 miljoonaan op/s lukuihin. Luo ja poista ovat vakaampia, kun ne saavuttavat tasangon, ja pysyvät yli 140K op/s poistossa ja 120K op/s luonnissa.
   

  ---

  Metatietojen suorituskyky MDtestillä käyttäen 4 KiB-tiedostoa

  Tämä testi on lähes identtinen edellisen kanssa, paitsi että tyhjien tiedostojen sijasta käytettiin pieniä 4KiB-tiedostoja. 
  Vertailuarvon suorittamiseen käytettiin seuraavaa komentoa, jossa säikeet olivat muuttuja käytettyjen säikeiden lukumäärällä (1 - 512 kahden potenssin lisäyksellä) ja my_hosts.$Threads on vastaava tiedosto, joka allokoi jokaisen säikeen eri solmuun käyttämällä pyöreää punarintaa levittämään ne homogeenisesti 16 laskentasolmuun.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --etuliite /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

  
  Kuva 6:  Metatietojen suorituskyky – pienet tiedostot (4K)
  
  Järjestelmä saa erittäin hyviä tuloksia tilasto- ja poistotoiminnoissa, saavuttaen huippuarvonsa 128 säikeellä 7,7 miljoonalla operaatiolla / s ja 1 miljoonalla op / s: llä. Poistotoiminnot saavuttivat maksimiarvon 37,3K op/s ja luontitoiminnot saavuttivat huippunsa 55,5K op/s:llä, molemmat 512 säikeellä. Tilasto- ja poistotoiminnoissa on enemmän vaihtelua, mutta kun ne saavuttavat huippuarvonsa, suorituskyky ei laske alle 4 miljoonaan toiminto/s tilastoihin ja 200 000 toimintoon poistossa. Luominen ja lukeminen vaihtelevat vähemmän, ja ne kasvavat jatkuvasti säikeiden määrän kasvaessa.
  Koska nämä luvut koskevat metatietomoduulia, jossa on yksi ME4024, suorituskyky kasvaa jokaisen uuden ME4024-ryhmän kohdalla, mutta emme voi vain olettaa lineaarista kasvua jokaiselle toiminnolle. Ellei koko tiedosto mahdu tällaisen tiedoston inodin sisään, ME4084s:n datakohteita käytetään 4K-tiedostojen tallentamiseen, mikä rajoittaa suorituskykyä jossain määrin. Koska inodikoko on 4KiB ja sen on vielä tallennettava metatietoja, vain noin 3 KiB: n tiedostot mahtuvat sisälle ja kaikki sitä suuremmat tiedostot käyttävät datakohteita.
   

  ---

  Metatietojen suorituskyky MDtestillä 3K-tiedostoilla

  Tämä testi on lähes täsmälleen identtinen edellisten kanssa, paitsi että käytettiin pieniä 3KiB-tiedostoja. Suurin ero on, että nämä tiedostot sopivat kokonaan inoden sisään. Siksi tallennussolmuja ja niiden ME4084-laitteita ei käytetä, mikä parantaa kokonaisnopeutta käyttämällä vain SSD-levyä tallennukseen ja vähemmän verkkoyhteyksiä. 
  Vertailuarvon suorittamiseen käytettiin seuraavaa komentoa, jossa säikeet olivat muuttuja käytettyjen säikeiden lukumäärällä (1 - 512 kahden potenssin lisäyksellä) ja my_hosts.$Threads on vastaava tiedosto, joka allokoi jokaisen säikeen eri solmuun käyttämällä pyöreää punarintaa levittämään ne homogeenisesti 16 laskentasolmuun.

  mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --etuliite /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 3K -e 3K

   

  
  Kuva 7: Metatietojen suorituskyky - pienet tiedostot (3K)
  
  Järjestelmä saa erittäin hyviä tuloksia tilasto- ja lukutoiminnoille, saavuttaen huippuarvonsa 256 säikeessä 8,29 miljoonalla op/s ja 5,06 miljoonalla op/s:lla. Poistotoiminnot saavuttivat maksimiarvon 609K op/s 128 säikeellä ja luontitoiminnot saavuttivat huippunsa 78K op/s 512 säikeellä. Tilasto- ja lukutoiminnoissa on enemmän vaihtelua kuin luonti- ja poistotoiminnoissa. Poistolla on pieni suorituskyvyn lasku kahden korkeamman säikeen pisteessä, mikä viittaa siihen, että jatkuva suorituskyky 128 säikeen jälkeen on hieman yli 400K op/s. Luo kasvaa jatkuvasti jopa 512 säiettä, mutta näyttää saavuttavan tasangon, joten suurin suorituskyky voi silti olla alle 100K op/s.
  Koska tällaiset pienet tiedostot tallennetaan kokonaan SSD-pohjaiseen metatietomoduuliin, sovellukset, jotka vaativat erinomaista pienten tiedostojen suorituskykyä, voivat käyttää yhtä tai useampaa valinnaista suuren kysynnän metatietomoduulia pienten tiedostojen suorituskyvyn parantamiseksi. Inodiin sopivat tiedostot ovat kuitenkin pieniä nykyisten standardien mukaan. Koska metatietokohteissa käytetään RAID1-järjestelmiä, joissa SSD-asemat ovat suhteellisen pieniä (enimmäiskoko on 19,2 Tt), kapasiteetti on rajallinen tallennussolmuihin verrattuna. Siksi on varottava metatietokohteiden täyttämistä, mikä voi aiheuttaa tarpeettomia vikoja ja muita ongelmia.
   

  ---

  Edistynyt analysointi

  PixStor-ominaisuuksien joukossa tiedostojärjestelmän seuranta edistyneen analytiikan avulla voi olla välttämätöntä hallinnan yksinkertaistamiseksi huomattavasti, mikä auttaa löytämään ongelmia tai mahdollisia ongelmia ennakoivasti tai reaktiivisesti. Seuraavaksi tarkastelemme lyhyesti joitakin näistä ominaisuuksista.
  Kuvassa 8 on hyödyllisiä tietoja tiedostojärjestelmän kapasiteetin perusteella. Vasemmalla puolella tiedostojärjestelmän kokonaistila ja kymmenen yleisintä käyttäjää käytetyn tiedostojärjestelmän kapasiteetin perusteella. Oikealla puolella historiallinen näkymä, jossa kapasiteettia on käytetty useiden vuosien ajan, sitten kymmenen tärkeintä käytettyä tiedostotyyppiä ja kymmenen parasta tiedostojoukkoa, jotka molemmat perustuvat käytettyyn kapasiteettiin, paretokaavioiden kaltaisessa muodossa (ilman kumulatiivisten summien rivejä). Näiden tietojen avulla voi olla helppo löytää käyttäjiä, jotka saavat enemmän kuin kohtuullisen osuutensa tiedostojärjestelmästä, kapasiteetin käytön suuntauksia, jotka auttavat tekemään päätöksiä kapasiteetin tulevasta kasvusta, mitkä tiedostot käyttävät suurimman osan tilasta tai mitkä projektit vievät suurimman osan kapasiteetista.
  
  
  Kuva 8:  PixStor-analytiikka – kapasiteettinäkymä
  
  Kuvassa 9 on tiedostojen laskentanäkymä, jossa on kaksi erittäin hyödyllistä tapaa etsiä ongelmia. Näytön ensimmäisellä puoliskolla on ympyräkaavion kymmenen parasta käyttäjää ja kymmenen parasta tiedostotyyppiä ja kymmenen parasta tiedostojoukkoa (ajattele projekteja) paretokaavioiden kaltaisessa muodossa (ilman kumulatiivisten summien rivejä), kaikki tiedostojen määrän perusteella. Näitä tietoja voidaan käyttää vastaamaan joihinkin tärkeisiin kysymyksiin. Esimerkiksi mitkä käyttäjät, jotka monopolisoivat tiedostojärjestelmää luomalla liian monta tiedostoa, minkä tyyppinen tiedosto luo metatietojen painajaisen tai mitkä projektit käyttävät suurimman osan resursseista.
  Alaosassa on histogrammi, jossa on tiedostojen määrä (taajuus) tiedostokokoja varten käyttäen 5 luokkaa eri tiedostokokoille. Tätä voidaan käyttää saamaan käsitys tiedostojärjestelmässä käytetyistä tiedostokokoista, joita voidaan käyttää tiedostotyyppien kanssa koordinoituna päättämään, onko pakkaamisesta hyötyä.
  
  
  Kuva 9:  PixStor Analytics – tiedostomääränäkymä

  
  
   

  ---

  Johtopäätökset ja jatkosuunnitelmat

  Nykyinen ratkaisu pystyi tuottamaan melko hyvän suorituskyvyn, jonka odotetaan olevan vakaa käytetystä tilasta riippumatta (koska järjestelmä alustettiin hajallaan), kuten taulukosta 4 voidaan nähdä. Lisäksi ratkaisun kapasiteetti ja suorituskyky skaalautuvat lineaarisesti, kun tallennussolmumoduuleja lisätään, ja valinnaiselta suuren kysynnän metatietomoduulilta voidaan odottaa samanlaista suorituskyvyn paranemista. Tämä ratkaisu tarjoaa HPC-asiakkaille erittäin luotettavan rinnakkaisen tiedostojärjestelmän, jota monet Top 500 -HPC-klusterit käyttävät. Lisäksi se tarjoaa poikkeukselliset hakuominaisuudet, edistyneen valvonnan ja hallinnan, ja valinnaisten yhdyskäytävien lisääminen mahdollistaa tiedostojen jakamisen kaikkialla läsnä olevien vakioprotokollien, kuten NFS: n, SMB: n ja muiden, kautta niin monelle asiakkaalle kuin tarvitaan.
  
  Taulukko 4  Huippusuoritus ja kestävä suorituskyky
  
   

  	Huippusuorituskyky		Jatkuva suorituskyky
  	Kirjoittaa	Read	Kirjoittaa	Read
  Suuri peräkkäinen N-asiakas N-tiedostoon	16,7 Gt/s	23 Gt/s	16,5 Gt/s	20,5 Gt/s
  Suuret peräkkäiset N-asiakkaat yhteen jaettuun tiedostoon	16,5 Gt/s	23,8 Gt/s	16,2 Gt/s	20,5 Gt/s
  Satunnainen pieni lohko N asiakasta N tiedostoon	15.8KIOps	20.4KIOps	15.7KIOps	20.4KIOps
  Metatiedot Tyhjien tiedostojen luominen	169,4K IOps		127,2 tuhatta IO:ta sekunnissa
  Metatietojen tilasto: tyhjät tiedostot	11,2 miljoonan IOps		3,3 miljoonan IOps
  Metatiedot Tyhjien tiedostojen lukeminen	4,8 miljoonan IOps		2,4 miljoonan IOps
  Metatiedot Poista tyhjät tiedostot	194,2 tuhatta IO:ta sekunnissa		144,8 tuhatta IOps:ää
  Metatiedot 4KiB-tiedostojen luominen	55,4K IOps		55,4K IOps
  Metadata Stat 4KiB-tiedostot	6,4 miljoonan IOps		4 kk:n IOps
  Metatiedot Lue 4KiB-tiedostoja	37,3 tuhatta IOps:ää		37,3 tuhatta IOps:ää
  Metatiedot Poista 4KiB-tiedostot	1 kk:n IOps		219,5 tuhatta IO:ta sekunnissa

  
  
  Koska ratkaisu on tarkoitus julkaista Cascade Lake -suorittimilla ja nopeammalla RAM-muistilla, kun järjestelmä on saanut lopullisen kokoonpanon, tehdään joitain suorituskyvyn pistokokeita. Testaa myös valinnaista suuren kysynnän metatietomoduulia, jossa on vähintään 2 x ME4024s- ja 4KiB-tiedostoa, jotta voidaan dokumentoida paremmin, miten metatietojen suorituskyky skaalautuu, kun tietokohteita on mukana. Lisäksi yhdyskäytäväsolmujen suorituskykyä mitataan ja siitä raportoidaan yhdessä pistokokeiden asiaankuuluvien tulosten kanssa uudessa blogissa tai raportissa. Lisäksi suunnitteilla on uusia testattavia ja julkaistavia ratkaisukomponentteja, jotta saadaan entistä enemmän ominaisuuksia.

  ---