Kaikkien edellä lueteltujen vertailuarvojen osalta testialustalla oli asiakkaat alla olevassa taulukossa 2 kuvatulla tavalla . Koska testattavien laskentasolmujen määrä oli vain 16, kun tarvittiin suurempi määrä säikeitä, 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 käytettävissä olevien laskentasolmujen rajallisella määrällä. Koska jotkin 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 vaikuttamasta suorituskykytuloksiin.

Taulukko 2 Asiakkaan testialusta

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ä 1024 säikeeseen kahden tehon välein.

Palvelimien välimuistiin tallentamisen vaikutukset 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 tämä viritettävä asettaa tietojen välimuistiin tallentamiseen käytettävän muistin enimmäismäärän riippumatta asennetun ja vapaan RAM-muistin määrästä. On myös tärkeää huomata, että aiemmissa DellEMC-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 kirjoitus- ja lukuvertailun suorittamiseen, jossa $Threads oli 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.

Asiakkaiden mahdollisten välimuistivaikutusten välttämiseksi tiedostojen kokonaiskoko oli kaksinkertainen käytettyjen asiakkaiden RAM-muistin kokonaismäärään. Toisin sanoen, koska jokaisella asiakkaalla on 128 GiB RAM-muistia, säikeiden lukumäärälle, joka on yhtä suuri tai suurempi kuin 16 säiettä , tiedostokoko oli 4096 GiB jaettuna säikeiden lukumäärällä (alla olevaa muuttujaa $Size käytettiin tämän arvon hallintaan). Tapauksissa, joissa oli alle 16 säiettä (mikä tarkoittaa, että jokainen säie oli käynnissä eri asiakkaassa), tiedostokooksi vahvistettiin kaksinkertainen muistimäärä asiakasta kohti eli 256 GiB.

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

Kuva 2 N:stä N peräkkäinen suorituskyky

Tuloksista voimme havaita, että kirjoitussuorituskyky nousee käytettyjen säikeiden lukumäärän myötä ja saavuttaa sitten tasangon noin 64 säikeessä kirjoitusten ja 128 säikeen lukemisessa. Sitten myös lukusuorituskyky nousee nopeasti säikeiden lukumäärän myötä ja pysyy sitten vakaana, kunnes IOzonen sallimien säikeiden enimmäismäärä saavutetaan, ja siksi suurten tiedostojen peräkkäinen suorituskyky on vakaa jopa 1024 samanaikaiselle asiakkaalle. Kirjoitusteho laskee noin 10 % 1024 säikeessä. Koska asiakasklusterissa on kuitenkin vähemmän ytimiä, on epävarmaa, johtuuko suorituskyvyn heikkeneminen vaihtamisesta ja vastaavista yleiskustannuksista, joita ei havaita pyörivillä tallennusvälineillä (koska NVMe-viive on hyvin pieni pyöriviin tallennusvälineisiin verrattuna), vai onko RAID 10 -tietojen synkronoinnista tulossa pullonkaula. Tämän asian selventämiseksi tarvitaan lisää asiakkaita. Lukemissa havaittiin poikkeama 64 säikeessä, joissa suorituskyky ei skaalautunut edellisissä datapisteissä havaitulla nopeudella, ja sitten seuraavassa datapisteessä siirtyy arvoon, joka on hyvin lähellä jatkuvaa suorituskykyä. Tällaisen poikkeaman syyn löytämiseksi tarvitaan lisää testausta, mutta se ei kuulu tämän blogin piiriin.

Lukujen suurin lukusuorituskyky oli pienempi kuin NVMe-laitteiden teoreettinen suorituskyky (~102 Gt/s) tai EDR-linkkien suorituskyky, vaikka oletettaisiin, että yhtä linkkiä käytettiin enimmäkseen NVMe:hen kangasliikenteen kautta (4x EDR BW ~ 96 GB/s).
Tämä ei kuitenkaan ole yllätys, koska laitteistokokoonpano ei ole tasapainossa kunkin suoritinkannan NVMe-laitteiden ja IB HCA: iden suhteen. Yksi CX6-sovitin on CPU1: n alla, kun taas CPU2: ssa on kaikki NVMe-laitteet ja toinen CX6-sovittimet. Ensimmäistä HCA:ta käyttävän tallennusliikenteen on käytettävä UPI:itä NVMe-laitteiden käyttämiseen. Lisäksi minkä tahansa käytetyn CPU1:n ytimen on käytettävä CPU2:lle määritettyjä laitteita tai muistia, joten tietojen paikallisuus kärsii ja UPI-linkkejä käytetään. Tämä voi selittää maksimaalisen suorituskyvyn heikkenemisen verrattuna NVMe-laitteiden enimmäissuorituskykyyn tai CX6 HCA:iden linjan nopeuteen. Tämän rajoituksen korjaamisen vaihtoehtona on tasapainoinen laitteistokokoonpano, mikä tarkoittaa tiheyden vähentämistä puoleen käyttämällä R740-mallia, jossa on neljä x16-paikkaa, ja käyttämällä kahta x16 PCIe -laajennuslaitetta NVMe-laitteiden jakamiseen tasaisesti kahdelle suorittimelle ja yhden CX6 HCA:n käyttämistä kunkin suorittimen alla.

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ä 512 säikeeseen, koska ytimiä ei ollut tarpeeksi 1024 tai useammalle säikeelle. Tässä vertailutestissä käytettiin 8 MiB-lohkoa optimaalisen suorituskyvyn saavuttamiseksi. Edellisessä suorituskykytestiosassa on täydellisempi selitys sille, miksi sillä on merkitystä.

Tietojen välimuistivaikutukset minimoitiin asettamalla GPFS-sivuvarannon säädettäväksi 16 GiB: ksi, ja tiedoston kokonaiskoko oli kaksinkertainen käytettyjen asiakkaiden RAM-muistin kokonaismäärään. Toisin sanoen, koska jokaisella asiakkaalla on 128 GiB RAM-muistia, säikeiden määrän ollessa yhtä suuri tai suurempi kuin 16 säiettä, tiedostokoko oli 4096 GiB, ja sama määrä tästä kokonaismäärästä jaettiin säikeiden lukumäärällä (alla olevaa muuttujaa $Size käytettiin tämän arvon hallintaan). Tapauksissa, joissa oli alle 16 säiettä (mikä tarkoittaa, että jokainen säie oli käynnissä eri asiakkaassa), tiedostokoko oli kaksi kertaa käytetyn asiakkaan muistin määrä kerrottuna säikeiden määrällä, toisin sanoen kutakin säiettä pyydettiin käyttämään 256 GiB.

Seuraavia komentoja käytettiin vertailukohdan suorittamiseen kirjoitus- ja lukutoiminnoille, joissa $Threads oli muuttuja käytettyjen säikeiden lukumäärällä (1 - 1024 kahden potenssin lisäyksellä) ja my_hosts.$Threads on vastaava tiedosto, joka allokoi 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 $ G

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 $ G

Kuva 3 N:1 Peräkkäinen suorituskyky

Tuloksista voimme havaita, että luku- ja kirjoitussuorituskyky on korkea riippumatta lukitusmekanismien implisiittisestä tarpeesta, koska kaikki säikeet käyttävät samaa tiedostoa. Suorituskyky nousee jälleen erittäin nopeasti käytettyjen säikeiden lukumäärällä ja saavuttaa sitten tasangon, joka on suhteellisen vakaa lukemiseen ja kirjoittamiseen aina tässä testissä käytettyjen säikeiden enimmäismäärään asti. Huomaa, että suurin lukusuorituskyky oli 51,6 Gt/s 512 säikeessä, mutta suorituskyvyn taso on noin 64 säikeessä. Huomaa myös, että enimmäiskirjoitusteho 34,5 Gt/s saavutettiin 16 säikeen kohdalla ja saavutettiin taso, joka on havaittavissa käytettyjen säikeiden enimmäismäärään asti.

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 kahden tehon välein.

Suoritetut testit vaihtelivat yhdestä säikeestä 512 säikeeseen, koska asiakasytimiä ei ollut tarpeeksi 1024 säikeelle. Jokainen säie käytti eri tiedostoa ja säikeille määritettiin pyöreä punarinta asiakassolmuissa. Tässä vertailutestissä käytettiin 4 KiB-lohkoa pienten lohkojen liikenteen jäljittelemiseen ja jonon syvyyden käyttämiseen 16. Suurikokoisen ratkaisun ja kapasiteetin laajennuksen tuloksia verrataan.

Välimuistivaikutukset minimoitiin jälleen asettamalla GPFS-sivupoolin säädettäväksi 16 GiB:ksi, ja jotta vältettäisiin mahdolliset tietojen välimuistivaikutukset, tiedostojen kokonaiskoko oli kaksinkertainen käytettyjen asiakkaiden RAM-muistin kokonaismäärään verrattuna. Toisin sanoen, koska jokaisella asiakkaalla on 128 GiB RAM-muistia, säikeiden lukumäärälle, joka on yhtä suuri tai suurempi kuin 16 säiettä, tiedostokoko oli 4096 GiB jaettuna säikeiden lukumäärällä (alla olevaa muuttujaa $Size käytettiin tämän arvon hallintaan). Tapauksissa, joissa oli alle 16 säiettä (mikä tarkoittaa, että jokainen säie oli käynnissä eri asiakkaassa), tiedostokooksi vahvistettiin kaksinkertainen muistimäärä asiakasta kohti eli 256 GiB.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Luo tiedostot peräkkäin
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Suorita satunnaiset lukemat ja kirjoitukset.

Kuva 4 N:stä N satunnaissuoritukseen

Tuloksista voimme havaita, että kirjoitussuorituskyky alkaa korkeasta arvosta 6K IOps ja nousee tasaisesti jopa 1024 säikeeseen, missä näyttää saavuttavan tasangon yli 5 miljoonalla IOPS: llä, jos enemmän säikeitä voitaisiin käyttää. Toisaalta lukusuorituskyky alkaa 5K IOPS: sta ja lisää suorituskykyä tasaisesti käytettyjen säikeiden lukumäärän mukaan (muista, että säikeiden määrä kaksinkertaistuu jokaiselle datapisteelle) ja saavuttaa 7.3 miljoonan IOPS: n maksimaalisen suorituskyvyn 1024 säikeellä ilman merkkejä tasangon saavuttamisesta. Useampien säikeiden käyttäminen edellyttää useampaa kuin 16 laskentasolmua, jotta vältetään resurssien nälkä ja liiallinen vaihtaminen, jotka voivat heikentää näennäistä suorituskykyä, jolloin NVMe-solmut voisivat itse asiassa ylläpitää suorituskykyä.

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

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 tiedostoille (ei hakemistojen metatietoja), jolloin saatiin ratkaisun käsittelemien luomien, tilastojen, lukujen ja poistojen määrä, ja tuloksia verrattiin suurikokoiseen ratkaisuun.

Valinnaista suuren kysynnän metatietomoduulia käytettiin, mutta yhdessä ME4024-ryhmässä, vaikka tässä työssä testatussa suuressa kokoonpanossa oli kaksi ME4024-konetta. Metatietomoduulin käyttö johtuu siitä, että tällä hetkellä näitä NVMe-solmuja käytetään tallennuskohteina vain tiedoille. Solmuja voidaan kuitenkin käyttää tietojen ja metatietojen tallentamiseen tai jopa flash-vaihtoehtona suuren kysynnän metatietomoduulille, jos äärimmäiset metatietovaatimukset sitä edellyttävät. Näitä kokoonpanoja ei testattu osana tätä työtä.

Koska samaa suuren kysynnän metatietomoduulia on käytetty aiemmin DellEMC Ready Solution for HPC PixStor Storage -ratkaisun vertailussa, metatietojen tulokset ovat hyvin samankaltaisia verrattuna aiempiin blogituloksiin. Tästä syystä tutkimusta tyhjillä tiedostoilla ei tehty, vaan käytettiin 4 KiB-tiedostoa. Koska 4KiB-tiedostot eivät mahdu inodiin metatietotietojen kanssa, NVMe-solmuja käytetään kunkin tiedoston tietojen tallentamiseen. Siksi MDtest voi antaa karkean käsityksen pienten tiedostojen suorituskyvystä lukemisessa ja muissa metatietotoiminnoissa.

Vertailuarvon suorittamiseen käytettiin seuraavaa komentoa, jossa $Threads oli 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ä round robinia 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 -w 4K -e 4K

Koska suorituskykytuloksiin voi vaikuttaa IOPS:ien kokonaismäärä, tiedostojen määrä hakemistoa kohden ja säikeiden määrä, päätettiin tiedostojen kokonaismäärä pitää 2 MiB-tiedostossa (2^21 = 2097152), tiedostojen määräksi hakemistoa kohden vahvistettiin 1024 ja hakemistojen määrä vaihteli säikeiden määrän muuttuessa taulukossa 3 esitetyllä tavalla.

Taulukko 3: MDtest-hakemistojen tiedostojen jakauma

Kuva 5: Metatietojen suorituskyky – 4 KiB-tiedostoa

Huomaa ensin, että valittu asteikko oli logaritminen kantaluvun 10 kanssa, jotta voidaan verrata operaatioita, joilla on eroja useiden suuruusluokkien kanssa; Muuten osa toiminnoista näyttäisi tasaiselta viivalta, joka on lähellä nollaa lineaarisella asteikolla. Logaritmikuvaaja, jonka kanta on 2, voisi olla sopivampi, koska säikeiden lukumäärää lisätään potenssilla 2, mutta kuvaaja näyttäisi hyvin samanlaiselta ja ihmisillä on taipumus käsitellä ja muistaa parempia numeroita potenssin 10 perusteella.

Järjestelmä saa erittäin hyviä tuloksia, kuten aiemmin on raportoitu, kun tilastotoiminnot saavuttavat huippuarvon 64 säikeellä lähes 6,9 miljoonalla op/s:lla ja sitten sitä pienennetään, kun suuremmat säikemäärät saavuttavat tasangon. Luontitoiminnot saavuttavat 113K op/s -maksimiarvon 512 säikeellä, joten niiden odotetaan lisääntyvän edelleen, jos asiakassolmuja (ja ytimiä) käytetään enemmän. Luku- ja poistotoiminnot saavuttivat maksiminsa 128 säikeessä, saavuttaen huippunsa lähes 705K op/s lukutoiminnoissa ja 370K op/s poistoissa, ja sitten ne saavuttavat tasankoja. Tilastotoiminnoissa on enemmän vaihtelua, mutta kun ne saavuttavat huippuarvonsa, suorituskyky ei laske alle 3,2 miljoonan tilastotoiminnon. Luo ja poista ovat vakaampia, kun ne saavuttavat tasangon, ja pysyvät yli 265K op/s poistossa ja 113K op/s luonnissa. Lopuksi lukemat saavuttavat tasangon, jonka suorituskyky on yli 265K op/s.

Johtopäätökset ja jatkosuunnitelmat

NVMe-solmut ovat tärkeä lisä HPC-tallennusratkaisuun, sillä ne tarjoavat erittäin korkean suorituskykytason, hyvän tiheyden, erittäin suuren satunnaiskäytön suorituskyvyn ja erittäin korkean peräkkäisen suorituskyvyn. Lisäksi ratkaisun kapasiteetti ja suorituskyky skaalautuvat lineaarisesti, kun NVMe-solmumoduuleja lisätään lisää. NVMe-solmujen suorituskykyä voidaan tarkastella taulukossa 4, sen odotetaan olevan vakaa, ja näitä arvoja voidaan käyttää arvioimaan suorituskykyä eri NVMe-solmuille.
Muista kuitenkin, että kukin NVMe-solmupari tuottaa puolet taulukossa 4 esitetystä määrästä.
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: 2 NVMe-solmuparin huippusuorituskyky ja jatkuva suorituskyky

Koska NVMe-solmuja käytettiin vain datan käsittelyyn, mahdollinen tuleva työ voi sisältää niiden käytön tietojen ja metatietojen tallentamiseen, ja niissä voi olla itsenäinen flash-pohjainen taso, jossa on parempi metatietojen suorituskyky, koska NVMe-laitteet ovat suurempia ja viive pienempi kuin RAID-ohjainten takana olevat SAS3 SSD -asemat. Jos asiakkaalla on erittäin suuret metatietovaatimukset ja hän tarvitsee ratkaisun, joka on tiheämpi kuin mitä suuren kysynnän metatietomoduuli pystyy tarjoamaan, joitakin tai kaikkia hajautettuja RAID 10 -laitteita voidaan käyttää metatietoina samalla tavalla kuin ME4024-laitteiden RAID 1 -laitteita nykyään.
Toinen pian julkaistava blogi luonnehtii PixStor Gateway -solmuja, jotka mahdollistavat PixStor-ratkaisun yhdistämisen muihin verkkoihin NFS- tai SMB-protokollien avulla ja voivat skaalata suorituskykyä. Lisäksi ratkaisu päivitetään HDR100: een hyvin pian, ja toisen blogin odotetaan puhuvan tästä työstä.