Dell EMC Ready -ratkaisut tehokkaseen HPC BeeGFS -tallennukseen

Artikkelin on kirjoittanut Nirmala Sundararajan Dell EMC:n HPC and AI Innovation Labista marraskuussa 2019

Dell EMC Ready -ratkaisut tehokkaseen HPC BeeGFS -tallennukseen

Sisällysluettelo

1. Johdanto
2. Ratkaisun viitearkkitehtuuri
3. Laitteisto- ja ohjelmistokokoonpano
4. Ratkaisun määritystiedot
   • Hallintapalvelu
   • Metatietopalvelu
   • Tallennustilapalvelu
   • Asiakaspalvelu
5. R740xd, 24x NVMe-asemaa, tietoja suorittimen kartoituksesta
6. Suorituskyvyn karakterisointi
   • Peräkkäinen lukee ja kirjoittaa N-N
   • Satunnainen lukee ja kirjoittaa N-N
7. Päätelmät ja tuleva työ
    

Johdanto

Ratkaisun viitearkkitehtuuri

Laitteisto- ja ohjelmistokokoonpano

Taulukoissa 1 ja 2 kuvataan hallintapalvelimen ja metatieto-/tallennuspalvelimen laitteiston tekniset tiedot. Taulukossa 3 kuvataan ratkaisussa käytetyt ohjelmistoversiot.

Ratkaisun määritystiedot

• Hallintapalvelu
• Metatietopalvelu
• Tallennustilapalvelu
• Asiakaspalvelu

Hallintapalvelu

Metatietopalvelu

Kuva 3:  Metatietopalvelin

Kuvassa 4 näkyy metatietopalvelimen raid-määritys. Se korostaa, kuinka metatietopalvelimessa NUMA-vyöhykkeen 0 asemat isännöivät MDT: itä ja NUMA-vyöhykkeen 1 asemat isännöivät tallennustietoja, kun taas tallennuspalvelimet isännöivät ST: itä molemmilla NUMA-vyöhykkeillä.

Tallennustilapalvelu

1. Kirjoitustehoa mitattiin dd-komennolla luomalla 10 GiB:n tiedosto, jonka lohkokoko oli 1 MiB ja suora I/O datalle. RAID 0 -laitteiden keskiarvo oli noin 5,1 Gt/s kullekin laitteelle, kun taas RAID 10 -laitteiden keskiarvo oli 3,4 Gt/s kullekin laitteelle.
2. StorageBench-vertailutestit osoittivat, että RAID 0 -kokoonpanon enimmäissiirtonopeus oli 5,5 Gt/s, kun se RAID 10 -kokoonpanossa on 3,4 Gt/s. Tulokset muistuttavat dd-komennoilla saatuja tuloksia.
3. RAID 10 vähentää levyn kapasiteettia 50 % ja kirjoitussuorituskykyä vastaavasti 50 %. RAID 10:n käyttäminen on kallis tapa varmistaa tallennuksen vikasietoisuus.
4. NVMe-asemat ovat kalliita ja tarjoavat nopeampia ominaisuuksia, joita voidaan parhaiten hyödyntää RAID 0 -kokoonpanossa

Asiakaspalvelu

$ kissa /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd, 24x NVMe-asemaa, tietoja suorittimen kartoituksesta

# kissa /proc/sys/ydin/numa_balancing
0

Suorituskyvyn karakterisointi

Peräkkäinen kirjoitus ja lukeminen N-N

Peräkkäisten lukujen ja kirjoitusten arvioimiseksi IOzone-vertailuarvoa käytettiin peräkkäisessä luku- ja kirjoitustilassa. Nämä testit suoritettiin useilla säikeillä, jotka alkoivat 1 säikeestä ja lisäsivät tehoa 2, jopa 1024 säiettä. Jokaisella säikemäärällä luotiin yhtä monta tiedostoa, koska tämä testi toimii yhdessä tiedostossa säiettä kohti tai N asiakasta N-tiedostoon (N-N) -tapauksessa. Prosessit jaettiin 32 fyysiseen asiakassolmuun round robin- tai syklisesti siten, että pyynnöt jakautuvat tasaisesti ja kuormitus tasapainotetaan. Kokonaistiedostokooksi valittiin 8 Tt, joka jaettiin tasan säikeiden lukumäärälle kussakin testissä. Kokonaistiedostokoko valittiin riittävän suureksi minimoimaan välimuistiin tallentamisen vaikutukset palvelimilta sekä BeeGFS-asiakkailta. IOzone suoritettiin yhdistetyssä kirjoitustilassa ja luettiin sitten (-i 0, -i 1), jotta se pystyi koordinoimaan toimintojen välisiä rajoja. Tässä testauksessa ja tuloksissa käytimme 1MiB-tietuekokoa jokaiselle ajolle. Peräkkäisissä N-N-testeissä käytetyt komennot ovat alla:

Peräkkäiset kirjoitukset ja lukemat: iozone -i 0 -i 1 -c -e -w -r 1m -i -s $Size -t $Thread -+n -+m /path/to/threadlist

Käyttöjärjestelmän välimuistit myös poistettiin tai puhdistettiin asiakassolmuissa iteraatioiden välillä sekä kirjoitus- ja lukutestien välillä suorittamalla komento:

# synkronointi ja kaiku 3 > / proc / sys / vm / drop_caches

Beegfs-arvon raitojen oletusmäärä on 4. Tiedoston koko ja kohteiden määrä voidaan kuitenkin määrittää hakemistokohtaisesti. Kaikissa näissä testeissä BeeGFS-raidan kooksi valittiin 2 Mt ja raitojen määräksi 3, koska meillä on kolme kohdetta NUMA-aluetta kohden alla olevan kuvan mukaisesti:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metatietosolmu: node001-numa0-4 [ID: 4]
Raitakuvion tiedot:
+ Tyyppi: RAID0
+ Chunksize: 2M
+ Tallennuskohteiden määrä: toivottu:
3+ Tallennusvaranto: 1 (oletus)
Inode-hajautuspolku: 7/5E/0-5D9BA1BC-1

Läpinäkyvät valtavat sivut poistettiin käytöstä, ja seuraavat viritysvaihtoehdot ovat käytössä metatieto- ja tallennuspalvelimilla:

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

Edellä mainittujen lisäksi käytettiin seuraavia BeeGFS-viritysvaihtoehtoja: 

• tuneTargetChooser-parametriksi asetettiin metatietojen määritystiedostossa "roundrobin" 
• tuneNumWorkers-parametriksi määritettiin 24 metatiedoille ja 32 tallennukselle 
• connMaxInternodeNum-parametriksi asetettiin 32 metatiedoille, 12 tallennukselle ja 24 asiakkaille

Kuvassa 9 nähdään, että huippulukusuorituskyky on 132 Gt/s 1024 säikeessä ja huippukirjoitus 121 Gt/s 256 säikeessä. Kumpikin asema voi tarjota 3,2 Gt/s:n huippulukusuorituskyvyn ja 1,3 Gt/s:n huippukirjoitussuorituskyvyn, mikä mahdollistaa teoreettisen huipputason 422 Gt/s lukutoiminnoissa ja 172 Gt/s kirjoituksissa. Tässä verkko on kuitenkin rajoittava tekijä. Meillä on yhteensä 11 InfiniBand EDR -linkkiä kokoonpanon tallennuspalvelimille. Kunkin linkin teoreettinen huippusuorituskyky voi olla 12,4 Gt/s, jolloin teoreettinen huippusuorituskyky on 136,4 Gt/s. Saavutettu huippuluku- ja kirjoitussuorituskyky on vastaavasti 97 % ja 89 % teoreettisesta huippusuorituskyvystä.

Yksittäisen säikeen kirjoitustehon havaitaan olevan ~ 3 Gt/s ja lukunopeus ~ 3 Gt/s. Havaitsemme, että kirjoitussuorituskyky skaalautuu lineaarisesti, saavuttaa huippunsa 256 säikeessä ja alkaa sitten laskea. Pienemmillä säikeiden määrillä luku- ja kirjoitussuorituskyky on sama. Koska 8 säiettä asti meillä on 8 asiakasta, jotka kirjoittavat 8 tiedostoa 24 kohteeseen, mikä tarkoittaa, että kaikkia tallennuskohteita ei hyödynnetä täysimääräisesti. Meillä on järjestelmässä 33 tallennuskohdetta, joten kaikkien palvelimien täysimääräiseen hyödyntämiseen tarvitaan vähintään 11 säiettä. Lukusuorituskyky rekisteröi tasaisen lineaarisen kasvun samanaikaisten säikeiden määrän kasvaessa, ja havaitsemme lähes samanlaisen suorituskyvyn 512 ja 1024 säikeessä.

Huomaamme myös, että lukusuorituskyky on alhaisempi kuin säikeiden määrän kirjoitusmäärät 16: sta 128: een, ja sitten lukusuorituskyky alkaa skaalautua. Tämä johtuu siitä, että vaikka PCIe-lukutoiminto on kirjaamaton toiminto, joka edellyttää sekä pyyntöä että valmistumista, PCIe-kirjoitustoiminto on tulipalo ja unohdus -toiminto. Kun tapahtumakerroksen paketti on luovutettu tiedonsiirtokerrokselle, toiminto on valmis. Kirjoitustoiminto on kirjattu toiminto, joka koostuu vain pyynnöstä.

Lukunopeus on yleensä pienempi kuin kirjoitusnopeus, koska lukemiseen tarvitaan kaksi tapahtumaa yhden kirjoituksen sijaan samalle tietomäärälle. PCI Express käyttää lukemiseen jaettua tapahtumamallia. Luettu tapahtuma sisältää seuraavat vaiheet:

• Pyytäjä lähettää muistin lukupyynnön (MRR).
• Täydentäjä lähettää kuittauksen MRR:lle.
• Täydentäjä palauttaa Valmistuminen tiedoilla -merkinnän.

Lukunopeus riippuu viiveestä lukupyynnön lähettämisen ja tietojen palauttamisen välillä. Kun sovellus kuitenkin lähettää riittävän määrän lukupyyntöjä tämän viiveen kattamiseksi, siirtonopeus maksimoidaan. Tästä syystä, vaikka lukusuorituskyky on pienempi kuin kirjoitusten 16 säikeestä 128 säikeeseen, mittaamme lisääntynyttä läpäisykykyä, kun pyyntöjen määrä kasvaa.  Pienempi määrä mitataan, kun pyytäjä odottaa valmistumista ennen seuraavien pyyntöjen lähettämistä. Suurempi suorituskyky rekisteröidään, kun lähetetään useita pyyntöjä viiveen poistamiseksi ensimmäisten tietojen palautusten jälkeen.

Satunnainen kirjoittaa ja lukee N-N

Satunnaisen IO-suorituskyvyn arvioimiseksi IOzonea käytettiin satunnaistilassa. Kierremääriä testattiin alkaen 4 säikeestä jopa 1024 säikeeseen. Suoraa IO-vaihtoehtoa (-I) käytettiin IOzonen suorittamiseen niin, että kaikki toiminnot ohittavat puskurivälimuistin ja siirtyvät suoraan levylle. BeeGFS-raitojen lukumääräksi käytettiin 3 ja palan kokoa 2 Mt. IOzonessa käytetään 4 KiB: n pyyntökokoa. Suorituskykyä mitataan I/O-operaatioina sekunnissa (IOPS). Käyttöjärjestelmän välimuistit pudotettiin ajojen välillä sekä BeeGFS-palvelimilla että BeeGFS-asiakkailla. Satunnaisten kirjoitusten ja lukujen suorittamiseen käytetty komento on alla:

Satunnainen lukee ja kirjoittaa: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /polku/to/threadlist

Kuva 10:  Satunnainen luku- ja kirjoitussuorituskyky käyttämällä IOzonea ja 8 Tt:n kokonaistiedostokokoa

Satunnaiskirjoitushuippu ~3,6 miljoonaa IOPS:ää 512 säikeessä ja satunnaislukuhuippu ~3,5 miljoonaa IOPS:ää 1024 säikeessä, kuten kuvassa 10 esitetään. Sekä kirjoitus- että lukusuorituskyky on parempi, kun IO-pyyntöjä on enemmän. Tämä johtuu siitä, että NVMe-standardi tukee jopa 64 Kt:n I/O-jonoa ja jopa 64 Kt:n komentoja jonoa kohden. Tämä suuri NVMe-jonojen joukko tarjoaa korkeamman I/O-rinnakkaisuuden tason, ja siksi havaitsemme IOPS: n ylittävän 3 miljoonaa.

Päätelmät ja tuleva työ

Tässä blogissa ilmoitetaan Dell EMC High Performance BeeGFS -tallennusratkaisun julkaisusta ja korostetaan sen suorituskykyominaisuuksia. Ratkaisun peräkkäisten luku- ja kirjoitustehojen huippu on ~132 Gt/s ja ~121 Gt/s, ja satunnaiskirjoitusten huippu on ~3,6 miljoonaa IOPS:ää ja satunnaislukujen huippu ~3,5 miljoonaa IOPS:ää.

Tämä blogi on ensimmäinen osa "BeeGFS Storage Solution" -ratkaisua, joka on suunniteltu keskittyen korkean suorituskyvyn raaputustilaan. Pysy kuulolla blogisarjan osasta 2, jossa kuvataan, miten ratkaisua voidaan skaalata lisäämällä palvelimien määrää suorituskyvyn ja kapasiteetin lisäämiseksi. Blogisarjan osassa 3 käsitellään BeeGFS:n lisäominaisuuksia ja korostetaan "StorageBenchin", BeeGFS:n sisäänrakennetun tallennustavoitteiden vertailuarvon, käyttöä.

Osana seuraavia vaiheita julkaisemme myöhemmin white paper -raportin, joka sisältää metatietojen suorituskyvyn ja N threads to 1 file IOR -suorituskyvyn sekä lisätietoja suunnittelunäkökohdista, hienosäädöstä ja kokoonpanosta.

Viitteet