PowerEdge: Dellin valmiit ratkaisut HPC BeeGFS -tehokkaaseen tallennukseen

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

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

Dell HPC -tiimi ylpeänä julkistaa Dell EMC Ready Solutions for HPC BeeGFS Storage -palvelun, joka on uusin lisäys HPC-tallennusportfolioon. Tämä ratkaisu käyttää R740xd-palvelimia, joissa kummassakin on 24 x Intel P4600 1,6 Tt:n NVMe-asemaa, Mixed-Use Express Flash -asema ja kaksi Mellanox ConnectX-5 InfiniBand EDR -sovitinta. Tässä 24 NVMe -asemakokoonpanossa 12 x NVMe SSD -levyä liitetään PCIe-kytkimeen, ja kukin kytkin yhdistetään yhteen suorittimeen x16 PCIe -laajennuskortilla. Lisäksi jokainen IB-liitäntä on kytketty yhteen CPU: han. Tällainen tasapainotettu kokoonpano, jossa jokainen suoritin on kytketty yhteen InfiniBand-sovittimeen ja jossa käsitellään 12 NVMe SSD -asemaa, tarjoaa maksimaalisen suorituskyvyn varmistamalla, että suorittimilla on yhtä paljon aikaa käsitellä I/O-pyyntöjä NVMe-asemille ja NVMe-asemista.

Ratkaisun painopiste on suorituskykyisessä I/O:ssa, ja se on suunniteltu nopeaksi raaputusratkaisuksi. Ratkaisun ytimessä on käyttää nopeita NVMe SSD -asemia, jotka tarjoavat suuren kaistanleveyden ja pienen viiveen poistamalla ajastimen ja jonottamisen pullonkaulat lohkokerroksesta. BeeGFS-tiedostojärjestelmä tukee myös suurta I/O-aggregaattisiirtonopeutta.

Ratkaisun viitearkkitehtuuri

Kuvassa 1 on esitetty ratkaisun viitearkkitehtuuri. Hallintapalvelin on yhteydessä vain metatieto- ja tallennuspalvelimiin Ethernet-yhteyden avulla. Jokaisella metatieto- ja tallennuspalvelimella on kaksi InfiniBand-linkkiä, ja ne on yhdistetty yksityiseen verkkoon Ethernetin kautta. Asiakkailla on yksi InfiniBand-linkki ja ne on yhdistetty yksityiseen rajapintaan Ethernetin kautta.

Kuva 1:  Dellin valmiit ratkaisut HPC BeeGFS -tallennukseen – 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

BeeGFS-arkkitehtuuri koostuu neljästä pääpalvelusta:

• Hallintapalvelu
• Metatietopalvelu
• Tallennustilapalvelu
• Asiakaspalvelu

Lukuun ottamatta asiakaspalvelua, joka on ydinmoduuli, hallinta-, metatieto- ja tallennuspalvelut ovat käyttäjätilan prosesseja. Kuvassa 2 esitetään, miten Dell EMC Ready Solutions for HPC BeeGFS Storage -viitearkkitehtuuri yhdistyy BeeGFS-tiedostojärjestelmän yleiseen arkkitehtuuriin.

Kuva 2:  BeeGFS-tiedostojärjestelmä PowerEdge R740xd:ssä, jossa NVMe SSD -levyt

Hallintapalvelu

Jokaisella BeeGFS-tiedostojärjestelmällä tai nimitilalla on vain yksi hallintapalvelu. Hallintapalvelu on ensimmäinen palvelu, joka on määritettävä, koska kun määritämme kaikki muut palvelut, niiden on rekisteröidyttävä hallintapalveluun. Hallintapalvelimena käytetään PowerEdge R640:aa. Hallintapalvelun (beegfs-mgmtd.service) isännöinnin lisäksi se isännöi myös seurantapalvelua (beegfs-mon.service), joka kerää tilastoja järjestelmästä ja toimittaa ne käyttäjälle käyttämällä aikasarjatietokantaa InfluxDB. Tietojen visualisointiin beegfs-mon tarjoaa ennalta määritettyjä Grafana-ruutuja , joita voidaan käyttää valmiina. Hallintapalvelimessa on 6 x 300 Gt:n kiintolevyä, jotka on määritetty RAID 10 -ratkaisuun käyttöjärjestelmälle ja InfluxDB:lle.

Metatietopalvelu

Metatietopalvelu on skaalautuva palvelu, mikä tarkoittaa, että BeeGFS-tiedostojärjestelmässä voi olla monia metatietopalveluita. Jokaisella metatietopalvelulla on kuitenkin tasan yksi metatietokohde metatietojen tallentamiseen. Metatietokohteessa BeeGFS luo yhden metatietotiedoston käyttäjän luomaa tiedostoa kohden. BeeGFS-metatiedot jaetaan hakemistokohtaisesti. Metatietopalvelu tarjoaa tietojen raidoitustiedot asiakkaille eikä osallistu tietojen käyttöön tiedostojen avaamisen ja sulkemisen välillä.

PowerEdge R740xd:ssä on 24x Intel P4600 1,6 Tt:n NVMe-asemaa, ja asemia käytetään metatietojen tallentamiseen. Koska BeeGFS-metatietojen tallennuskapasiteettivaatimukset ovat hyvin pienet, erillisen metatietopalvelimen käyttämisen sijaan vain NUMA-vyöhykkeen 0 12 asemaa käytettiin Meta-DataT-argettien (MDT) isännöintiin, kun taas loput 12 NUMA-vyöhykkeen asemaa isännöivät S-vääntömomentin Targetteja (ST).

Kuvassa 3 on metatietopalvelin. Keltaiseen suorakulmioon suljetut 12 asemaa ovat NUMA-vyöhykkeen 0 MDT:itä, kun taas vihreään suorakulmioon suljetut 12 asemaa ovat NUMA-vyöhykkeen 1 ST:itä. Tämä kokoonpano ei ainoastaan estä NUMA-ongelmia, vaan tarjoaa myös tarpeeksi metatietojen tallennustilaa kapasiteetin ja suorituskyvyn skaalaamisen helpottamiseksi tarpeen mukaan.

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ä.

Kuva 4:  Asemien määrittäminen metatietopalvelimessa

Metatietojen tallennukseen käytetyt 12 asemaa on määritetty kuudeksi RAID 1 -levyryhmäksi, jossa on kaksi asemaa, joista kumpikin toimii MDT:nä. Käynnissä on kuusi metatietopalvelua, joista jokainen käsittelee yhtä MDT:tä. Loput 12 tallennusasemaa on määritetty 3x RAID 0 -levyryhmään, joissa kussakin on neljä asemaa. NUMA 1 -vyöhykkeellä on käynnissä kolme tallennuspalvelua, yksi palvelu kullekin ST: lle. Metatietoja ja tallennuskohteita isännöivällä palvelimella on 6 MDT:tä ja 3 ST:tä. Se ylläpitää myös kuutta metatietopalvelua ja kolmea tallennuspalvelua. Jokainen MDT on RAID 1 -kokoonpanoon perustuva ext4-tiedostojärjestelmä. ST:t perustuvat RAID 0:ssa määritettyyn XFS-tiedostojärjestelmään.
 

Tallennustilapalvelu

Kuten metatietopalvelu, myös tallennuspalvelu on skaalautuva palvelu. Tallennuspalvelun esiintymiä voi olla useita BeeGFS-tiedostojärjestelmässä. Toisin kuin metatietopalvelussa, tallennuspalvelussa voi kuitenkin olla useita tallennuskohteita. Tallennuspalvelu tallentaa raidoitetun käyttäjätiedoston sisällön eli datalohkotiedostot.

Kuvassa 5 esitetään viisi PowerEdge R740xd -palvelinta tallennuspalvelimina.

Kuva 5:  Dedikoidut tallennuspalvelimet

Kukin tallennuspalvelin on määritetty kuudella RAID 0 -ryhmällä, joista jokaisella on neljä asemaa, joten niissä on 6 ST:tä palvelinta kohti (3 NUMA-aluetta kohti), kuten alla olevassa kuvassa 6 esitetään:

Kuva 6:  Tallennuspalvelimien

asemien määrittäminen Perusviitearkkitehtuurin kokoonpanossa on yhteensä 6 MDT:tä ja 33 ST:tä. Viiden erillisen tallennuspalvelimen raakakapasiteetti on 211 Tt ja käytettävissä oleva kapasiteetti 190 TiB. Arvioitu käytettävissä oleva kapasiteetti TiB = asemien lukumäärä x kapasiteetti asemaa kohti TB x 0,99 (tiedostojärjestelmän yleiskustannukset) x (10^12/2^40). Tämä olisi ihanteellinen keskitason raaputusratkaisu, jossa on tarpeeksi metatietojen tallennustilaa, jotta tallennuspalvelimia voidaan lisätä kapasiteettivaatimusten kasvaessa.

Seuraavien tekijöiden vuoksi RAID 10 -kokoonpanoa käyttäville tallennuskohteille valittiin RAID 0 -kokoonpano.

1. Kirjoitustehoa mitattiin dd-komennolla luomalla 10 Gt:n lohkokokoinen tiedosto, jossa oli 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 nopeuksia, joita käytetään parhaiten RAID 0 -kokoonpanossa

Asiakaspalvelu

BeeGFS-asiakasmoduuli on ladattava kaikkiin isäntiin, joiden on käytettävä BeeGFS-tiedostojärjestelmää. Kun beegfs-client on ladattu, se liittäätiedostojärjestelmät tiedostoon /etc/beegfs/beegfs-mounts.conf tavallisen / etc/fstab-pohjaisen lähestymistavan sijaan. Tämän lähestymistavan omaksuminen käynnistää beegfs-asiakkaan kuten minkä tahansa muun Linux-palvelun palvelun käynnistyskomentosarjan kautta. Se mahdollistaa myös BeeGFS-asiakasmoduulin automaattisen uudelleenkääntämisen järjestelmäpäivitysten jälkeen. 

Kun asiakasmoduuli on ladattu, se liittää beegfs-mounts.conf-tiedostossa määritetyt tiedostojärjestelmät. Samaan asiakasohjelmaan voi asentaa useita beegfs-esiintymiä alla kuvatulla tavalla:

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

Edellä olevassa esimerkissä näkyy kaksi eri tiedostojärjestelmää, jotka on liitetty samaan työasemaan. Tässä testauksessa asiakkaina käytettiin 32 x C6420-solmua.

R740xd, 24x NVMe-asemaa, tietoja suorittimen kartoituksesta

PowerEdge R740xd -palvelimen 24xNVMe-kokoonpanossa on kaksi x16 NVMe -siltauskorttia, jotka syöttävät PCIe-kytkintä taustalevyllä. Ne puhaltavat ulos ja syöttävät etuosan asemia (asemat ovat x4) alla olevan kuvan 7 mukaisesti:


Kuva 7:  R740xd, 24x NVMe Tietoja suorittimen kartoituksesta

NUMA (Non-Uniform Memory Access) -järjestelmässä järjestelmämuisti on jaettu vyöhykkeisiin, joita kutsutaan solmuiksi ja jotka on varattu suorittimille tai kannoille. Paikallisen suorittimen muistin käyttö on nopeampaa kuin järjestelmän etäsuorittimiin yhdistetyn muistin. Kierteinen sovellus toimii yleensä parhaiten, kun säikeet käyttävät saman NUMA-solmun muistia. NUMA-ohjusten suorituskykyvaikutus on merkittävä, yleensä alkaen 10%: n suorituskykyosumasta tai korkeammasta. Suorituskyvyn parantamiseksi palvelut on määritetty käyttämään tiettyjä NUMA-vyöhykkeitä, jotta UPI-ristikantalinkkejä ei käytetä tarpeettomasti, mikä vähentää viivettä. Jokainen NUMA-alue käsittelee 12 asemaa ja käyttää toista palvelimien kahdesta InfiniBand EDR -liitännästä. Tämä NUMA-erottelu saavutetaan konfiguroimalla NUMA-tasapainotus manuaalisesti luomalla mukautettuja systemd-yksikkötiedostoja ja konfiguroimalla multihoming. Siksi automaattinen NUMA-tasapainotus on poistettu käytöstä, kuten alla on esitetty:

# cat /proc/sys/kernel/numa_balancing
0

Kuvassa 8 on testialusta, jossa InfiniBand-yhteydet NUMA-vyöhykkeeseen on korostettu. Jokaisella palvelimella on kaksi IP-linkkiä, ja NUMA 0 -vyöhykkeen läpi kulkeva liikenne käsitellään rajapinnalla IB0, kun taas NUMA 1 -vyöhykkeen läpi kulkeva liikenne hoidetaan rajapinnalla IB1.

Kuva 8:  Testipenkin kokoonpano
 

Suorituskyvyn karakterisointi

Tässä osassa esitellään suorituskyvyn arviointi, joka auttaa luonnehtimaan Dell EMC Ready Solution for HPC BeeGFS High Performance Storage Solution -ratkaisua. Lisätietoja ja päivityksiä saat tutustumalla white paper -raporttiin, joka julkaistaan myöhemmin. Järjestelmän suorituskyky arvioitiin IOzone-vertailuarvolla. Ratkaisua testataan peräkkäisten luku- ja kirjoitussuoritusten sekä satunnaisen luku- ja kirjoitustehon IOPS:n suhteen. Taulukossa 4 kuvataan niiden C6420-palvelimien kokoonpano, joita käytettiin BeeGFS-asiakkaina tämän blogin suorituskykytutkimuksissa.
 

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 yhdestä 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ä. Tiedoston koostekoko valittiin riittävän suureksi palvelimien ja BeeGFS-asiakkaiden välimuistiin tallentamisen vaikutusten minimoimiseksi. 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 1 Mt:n tietuekokoa jokaiselle ajolle. Peräkkäisissä N-N-testeissä käytetyt komennot ovat alla:

Peräkkäiset kirjoitus- ja lukutoiminnot: 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:

# sync && echo 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 2MB ja raitojen määräksi 3, koska meillä on kolme kohdetta NUMA-aluetta kohti, kuten alla on esitetty:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 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 oli asetettu "roundrobin" metatietojen määritystiedostossa 
• tuneNumWorkers Parametriksi asetettiin 24 metatiedoille ja 32 tallennukselle 
• connMaxInternodeNum Parametriksi asetettiin 32 metatiedoille, 12 tallennukselle ja 24 asiakkaille

Kuva 9:  Peräkkäinen IOzone 8TB -koostetiedostokoko.

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ä asennusohjelman 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 kahdeksaan säikeeseen asti meillä on kahdeksan asiakasta, jotka kirjoittavat kahdeksan tiedostoa 24 kohteessa, mikä tarkoittaa, että kaikkia tallennuskohteita ei käytetä täysimääräisesti. Järjestelmässä on 33 tallennuskohdetta, joten kaikkien palvelimien täysimääräiseen käyttöön 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 BeeGFS-palvelimien ja BeeGFS-asiakkaiden ajojen välillä. 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 /path/to/threadlist

Kuva 10:  Satunnainen luku- ja kirjoitussuorituskyky käytettäessä IOzonea, jonka koottu tiedostokoko on 8 Tt.

Satunnaiskirjoitushuippu ~3,6 miljoonaa IOPS:ää 512 säikeessä ja satunnaislukuhuippu ~3,5 miljoonassa IOPS:ssa 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, 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 valkoisen kirjan, joka sisältää metatietojen suorituskyvyn ja N-säikeet yhteen tiedostoon IOR-suorituskyvystä sekä lisätietoja suunnittelunäkökohdista, virityksestä ja kokoonpanosta.

Viitteet

[1] BeeGFS-dokumentaatio: 
https://www.beegfs.io/wiki/[2] Kahden liitännän liittäminen samaan aliverkkoon:  https://access.redhat.com/solutions/30564