Zu den Hauptinhalten
  • Bestellungen schnell und einfach aufgeben
  • Bestellungen anzeigen und den Versandstatus verfolgen
  • Profitieren Sie von exklusiven Prämien und Rabatten für Mitglieder
  • Erstellen Sie eine Liste Ihrer Produkte, auf die Sie jederzeit zugreifen können.

Dell EMC Ready -ratkaisu HPC PixStor -tallennukseen

Zusammenfassung: Ratkaisun viitearkkitehtuuri ja alustava suorituskyvyn arviointi.

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Symptome

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

Ursache

.

Lösung

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

Nykypäivän HPC-ympäristöt ovat lisänneet erittäin nopean tallennuksen vaatimuksia, mikä edellyttää usein myös suurta kapasiteettia ja hajautettua käyttöä useiden vakioprotokollien, kuten NFS:n ja SMB:n, kautta. Nämä suuren kysynnän suurteholaskentavaatimukset katetaan yleensä rinnakkaisilla tiedostojärjestelmillä, jotka tarjoavat samanaikaisen pääsyn yhteen tiedostoon tai tiedostojoukkoon useista solmuista ja jakavat tietoja erittäin tehokkaasti ja turvallisesti useisiin LUN-levyihin useissa palvelimissa.

 

Ratkaisuarkkitehtuuri

Tässä blogikirjoituksessa esittelemme Dell EMC:n uusimman lisäyksen HPC-ympäristöjen Parallel File System (PFS) -ratkaisuihin, Dell EMC Ready Solution for HPC PixStor Storage. Kuvassa 1 on viitearkkitehtuuri, joka hyödyntää Dell EMC PowerEdge R740 -palvelimia sekä PowerVault ME4084- ja ME4024-tallennusjärjestelmiä kumppaniyrityksemme ArcastreaminPixStor-ohjelmistolla.
PixStor sisältää laajalle levinneen General Parallel File Systemin, joka tunnetaan myös nimellä Spectrum Scale PFS-komponenttina, Arcastream-ohjelmistokomponenttien, kuten edistyneen analytiikan, yksinkertaistetun hallinnan ja seurannan, tehokkaan tiedostohaun, edistyneiden yhdyskäytäväominaisuuksien ja monien muiden lisäksi.

SLN318841_en_US__1image (11979)
Kuva 1: Viitearkkitehtuuri.

 

Ratkaisun osat

Tämä ratkaisu on tarkoitus julkaista uusimpien Intel Xeon 2. sukupolven skaalautuvien Xeon-suorittimien eli Cascade Lake -suorittimien kanssa, ja jotkut palvelimet käyttävät nopeinta saatavilla olevaa RAM-muistia (2 933 MT/s). Ratkaisun prototyyppien luomiseen ja sen suorituskyvyn karakterisoimiseen käytettävissä olevan laitteiston ansiosta palvelimet, joissa on 1. sukupolven Intel Xeon Scalable Xeon -suorittimet, alias Käytettiin Skylake-prosessoreita ja hitaampaa RAM-muistia. Koska ratkaisun pullonkaula on Dell EMC PowerVault ME40x4 -järjestelmien SAS-ohjaimissa, merkittäviä suorituskykyeroja ei ole odotettavissa, kun Skylake-suorittimet ja RAM-muisti korvataan suunnitelluilla Cascade Lake -suorittimilla ja nopeammalla RAM-muistilla. Lisäksi, vaikka RHEL 7.6: ta tukevan PixStorin uusin versio oli saatavilla järjestelmän konfiguroinnin yhteydessä, päätettiin jatkaa laadunvarmistusprosessia ja käyttää Red Hat® Enterprise Linux® 7.5: tä ja PixStorin edellistä pientä versiota järjestelmän karakterisointiin. Kun järjestelmä on päivitetty Cascade Lake -suorittimiin, myös PixStor-ohjelmisto päivitetään uusimpaan versioon ja tehdään joitakin suorituskyvyn pistokokeita sen varmistamiseksi, että suorituskyky pysyy tässä asiakirjassa ilmoitettujen lukujen ulkopuolella.

Edellä kuvatun tilanteen vuoksi taulukossa 1 on luettelo ratkaisun pääkomponenteista. Keskimmäisessä sarakkeessa on suunnitellut komponentit, joita käytetään julkaisuhetkellä ja jotka ovat siten asiakkaiden käytettävissä, ja viimeinen sarake on komponenttiluettelo, jota käytetään tosiasiallisesti ratkaisun suorituskyvyn kuvaamiseen. Suorituskyvyn karakterisointiin käytetään lueteltuja asemia tai tietoja (12 Tt Maanmittauslaitosta) ja metatietoja (960 Gt:n SSD), ja nopeammat asemat voivat tarjota parempia satunnaisia IOP:itä ja parantaa luonti-/poistometatietojen toimintoja.

Lopuksi lisättiin täydellisyyden vuoksi luettelo mahdollisista SSD-levyistä ja metatieto-SSD-levyistä, jotka perustuvat tuettuihin asemiin, jotka on määritetty Dell EMC PowerVault ME4 -tukitaulukossa, joka on saatavilla verkossa.

Taulukko 1 Vapautumishetkellä käytettävät komponentit ja testipenkissä käytettävät komponentit

SLN318841_en_US__2image(12041)
 

Suorituskyvyn karakterisointi

Tämän uuden valmiin ratkaisun luonnehtimiseen käytimme taulukon 1 viimeisessä sarakkeessa määritettyä laitteistoa, mukaan lukien valinnainen suuren kysynnän metatietomoduuli. Ratkaisun suorituskyvyn arvioimiseksi käytettiin seuraavia vertailuarvoja:

 
  •     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

    SLN318841_en_US__3image(11984)
    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

    SLN318841_en_US__4image(11985)

    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

    SLN318841_en_US__5image(11987)
    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




    SLN318841_en_US__6image (1988)
    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

    SLN318841_en_US__7image (11989)
    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

     

    SLN318841_en_US__8image(11990)
    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.

    SLN318841_en_US__9image(11993)
    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ä.

    SLN318841_en_US__10image(11994)
    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.


     

Betroffene Produkte

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Artikeleigenschaften
Artikelnummer: 000130962
Artikeltyp: Solution
Zuletzt geändert: 23 Sept. 2024
Version:  6
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.