メイン コンテンツに進む
  • すばやく簡単にご注文が可能
  • 注文内容の表示、配送状況をトラック
  • 会員限定の特典や割引のご利用
  • 製品リストの作成とアクセスが可能

Dell EMC Ready-løsninger for HPC BeeGFS-lagring med høy ytelse

概要: PowerEdge R740xd, PowerEdge R640, PowerSwitch S3048-ON, Mellanox SB7890, BeeGFS v7.1.3, HPC og AI Innovation Lab, HPC, BeeGFS lagringsløsning med høy ytelse, IOzone, sekvensiell lese- og skriveytelse, tilfeldig lese- og skriveytelse ...

この記事は次に適用されます: この記事は次には適用されません: この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。

現象

Artikkel skrevet av Nirmala Sundararajan i Dell EMC HPC and AI Innovation Lab i november 2019

原因

Dell EMC Ready-løsninger for HPC BeeGFS-lagring med høy ytelse

解決方法

Innholdsfortegnelse

  1. Innledning
  2. Arkitektur for løsningsreferanse
  3. Maskinvare- og programvarekonfigurasjon
  4. Detaljer om løsningskonfigurasjon
  5. R740xd, 24x NVMe-disker, detaljer om CPU-tilordning
  6. Karakterisering av ytelse
  7. Konklusjon og videre arbeid
     

Innledning

Dell EMC HPC-teamet er stolte av å lansere "Dell EMC Ready Solutions for HPC BeeGFS Storage", som er det nyeste tilskuddet til HPC-lagringsporteføljen. Denne løsningen bruker R740xd-servere, hver med 24x Intel P4600 1,6 TB NVMe, Mixed Use Express Flash-stasjoner og to Mellanox ConnectX-5 InfiniBand EDR-adaptere. I denne 24 NVMe-stasjonskonfigurasjonen kobles 12 NVMe SSD-er til en PCIe-svitsj, og hver svitsj er koblet til én CPU via et x16 PCIe-utvidelseskort. Videre er hvert IB-grensesnitt koblet til en CPU. En slik balansert konfigurasjon med hver CPU koblet til én InfiniBand-adapter og håndtering av 12 NVMe SSD-er gir maksimal ytelse ved å sikre at prosessorene er like opptatt med å håndtere I/O-forespørsler til og fra NVMe-diskene.

Fokuset på løsningen er I/O med høy ytelse, og den er designet som en høyhastighets ripeløsning.  Kjernen i løsningen er bruken av høyhastighets NVMe SSD-er som tilbyr svært høy båndbredde og lav ventetid ved å fjerne planleggeren og køflaskehalser fra blokklaget. BeeGFS-filsystemet støtter også høy samlet I/O-gjennomstrømming

Arkitektur for løsningsreferanse

Figur 1 viser referansearkitekturen til løsningen. Administrasjonsserveren er bare koblet via Ethernet til metadata- og lagringsserverne. Hver metadata- og lagringsserver har to InfiniBand-koblinger og er koblet til det private nettverket via Ethernet. Klientene har en InfiniBand-kobling og er koblet til det private grensesnittet via Ethernet.
Dell EMC Ready Solutions for HPC BeeGFS-lagring – referansearkitektur
Figur 1:  Dell EMC Ready Solutions for HPC BeeGFS-lagring – referansearkitektur

Maskinvare- og programvarekonfigurasjon

Tabell 1 og 2 beskriver maskinvarespesifikasjonene for henholdsvis administrasjonsserver og metadata/lagringsserver. Tabell 3 beskriver programvareversjonene som brukes for løsningen.

 

Tabell 1 Konfigurasjon av PowerEdge R640 (administrasjonsserver)
Server Dell EMC PowerEdge R640
Prosessor 2 2,3 GHz Intel Xeon Gold 5218, 16 kjerner
Minne 12 x 8 GB DDR4 2666 MT/s DIMM-er – 96 GB
Lokale disker 6 x 300 GB SAS 2,5-tommers SAS-disker med 15 000 RPM
RAID-kontroller PERC H740P integrert RAID-kontroller
Administrasjon utenfor bånd iDRAC9 Enterprise med livssykluskontroller
Strømforsyninger To strømforsyningsenheter på 1100 W
BIOS-versjon 2.2.11
Operativsystem CentOS™ 7.6
Kjerneversjon 3.10.0-957.27.2.el7.x86_64

 

Tabell 2 PowerEdge R740xd-konfigurasjon (metadata og lagringsservere)
Server Dell EMC PowerEdge R740xd
Prosessor 2x Intel Xeon Platinum 8268 CPU @ 2,90 GHz, 24 kjerner
Minne 12 x 32 GB DDR4 2933 MT/s DIMM-er – 384 GB
BOSS-kort 2 x 240 GB M.2 SATA SSD-er i RAID 1 for operativsystemet
Lokale disker 24x 2,5" Dell Express Flash NVMe P4600 1,6 TB 2,5" U.2
Mellanox EDR-kort 2x Mellanox ConnectX-5 EDR-kort (spor 1 og 8)
Administrasjon utenfor bånd iDRAC9 Enterprise med livssykluskontroller
Strømforsyninger To 2000 W strømforsyningsenheter

 

Tabell 3 Programvarekonfigurasjon (metadata og lagringsservere)
BIOS 2.2.11
CPLD 1.1.3
Operativsystem CentOS™ 7.6
Kjerneversjon 3.10.0-957.el7.x86_64
iDRAC 3.34.34.34
Verktøy for systemadministrasjon OpenManage Server Administrator 9.3.0-3407_A00
Mellanox OFED 4.5-1.0.1.0
NVMe SSD-disker QDV1DP13
*Intel Data Center-verktøy ®  3.0.19
BeeGFS 7.1.3
Grafana 6.3.2
InfluxDB 1.7.7
IOzone Benchmark 3.487
*For administrasjon og fastvareoppdatering av Intel P4600NVMe SSD-er

Detaljer om løsningskonfigurasjon

BeeGFS-arkitekturen består av fire hovedtjenester:
  • Administrasjonstjeneste
  • Metadatatjeneste
  • Lagringstjeneste
  • Kundeservice
Med unntak av klienttjenesten som er en kjernemodul, er administrasjons-, metadata- og lagringstjenestene brukerplassprosesser. Figur 2 illustrerer hvordan referansearkitekturen til Dell EMC Ready Solutions for HPC BeeGFS-lagring tilordnes til den generelle arkitekturen til BeeGFS-filsystemet.
BeeGFS-filsystem på PowerEdge R740xd med NVMe SSD-disker
Figur 2:  BeeGFS-filsystem på PowerEdge R740xd med NVMe SSD-disker

Administrasjonstjeneste

Hvert BeeGFS-filsystem eller -navneområde har bare én administrasjonstjeneste. Administrasjonstjenesten er den første tjenesten som må settes opp, fordi når vi konfigurerer alle andre tjenester, må de registrere seg hos administrasjonstjenesten.  PowerEdge R640 brukes som administrasjonsserver. I tillegg til å være vert for administrasjonstjenesten (beegfs-mgmtd.service), er den også vert for overvåkingstjenesten (beegfs-mon.service) som samler statistikk fra systemet og gir dem til brukeren ved hjelp av tidsseriedatabasen InfluxDB. For visualisering av data gir beegfs-mon forhåndsdefinerte Grafana-ruter som kan brukes som standard. Administrasjonsserveren har 6 x 300 GB HDD-er konfigurert i RAID 10 for operativsystemet og InfluxDB.

Metadatatjeneste

Metadatatjenesten er en utskaleringstjeneste, noe som betyr at det kan være mange metadatatjenester i et BeeGFS-filsystem. Hver metadatatjeneste har imidlertid nøyaktig ett metadatamål for å lagre metadata.  På metadatamålet oppretter BeeGFS én metadatafil per brukeropprettet fil. BeeGFS-metadata distribueres per katalog. Metadatatjenesten gir datastripeinformasjonen til klientene og er ikke involvert i datatilgangen mellom filåpning/lukking.

A PowerEdge R740xd med 24x Intel P4600 1,6 TB NVMe, disker brukes til metadatalagring. Siden kravene til lagringskapasitet for BeeGFS-metadata er svært små, ble bare de 12 stasjonene på NUMA-sone 0 brukt til å være vert for Meta D ata Targets (MDT-er), mens de resterende 12 stasjonene påNUMA-sonener vert for Storage T-argets (ST-er).

Figur 3 viser metadatatjeneren. De 12 stasjonene i det gule rektangelet er MDT-ene i NUMA-sonen 0, mens de 12 stasjonene i det grønne rektangelet er ST-ene i NUMA-sonen 1. Denne konfigurasjonen unngår ikke bare NUMA-problemer, men gir også nok metadatalagring for å lette skalering av kapasitet og ytelse etter behov.

Metadataserver

Figur 3:  Metadata Server

Figur 4 viser RAID-konfigurasjonen for metadataserveren. Det fremhever hvordan stasjonene i NUMA-sonen 0 i metadataserveren er vert for MDT-ene og de i NUMA-sone 1 er vert for lagringsdataene, mens lagringsserverne er vert for ST-ene i begge NUMA-sonene.

Konfigurasjon av stasjoner i Metadata Server

Figur 4:  Konfigurering av stasjoner i Metadata Server

De 12 diskene som brukes for metadata er konfigurert som 6 RAID 1 diskgruppe med 2 stasjoner, hver fungerer som en MDT. Det er 6 metadatatjenester som kjører som hver håndterer en MDT. De resterende 12 lagringsdiskene er konfigurert i 3 RAID 0 diskgrupper med 4 disker hver. Det er tre lagringstjenester som kjører på NUMA 1-sonen, en tjeneste for hver ST. Så serveren som er vert for metadataene og lagringsmålene, har 6 MDT-er og 3 ST-er. Det kjører også 6 metadatatjenester og tre lagringstjenester. Hver MDT er et ext4-filsystem basert på en RAID 1-konfigurasjon. ST-ene er basert på XFS-filsystemet som er konfigurert i RAID 0.
 

Lagringstjeneste

I likhet med metadatatjenesten er lagringstjenesten også en utskalert tjeneste. Det kan være mange forekomster av lagringstjenesten i et BeeGFS-filsystem. I motsetning til metadatatjenesten kan det imidlertid være flere lagringsmål per lagringstjeneste.  Lagringstjenesten lagrer innholdet i den stripede brukerfilen, også kjent som datasegmentfiler

Figur 5 viser de 5 x PowerEdge R740xd-serverne som brukes som lagringsservere.
Dedikerte lagringsservere
Figur 5:  Dedikerte lagringsservere

Hver lagringsserver er konfigurert med 6x RAID 0-grupper, hver på 4 stasjoner, og er dermed vert for 6 STs per server (3 per NUMA-sone), som vist i figur 6 gitt nedenfor:

Konfigurasjon av disker i lagringsservereFigur 6:  Konfigurering av disker i lagringsservere Totalt

er basereferansearkitekturkonfigurasjonen vert for 6 MDT-er og 33 ST-er. Å ha fem dedikerte lagringsservere gir en ukomprimert kapasitet på 211 TB og en brukbar kapasitet på 190 TiB. Beregnet brukbar kapasitet i TiB = antall disker x kapasitet per disk i TB x 0,99 (filsystemkostnader) x (10^12/2^40). Dette vil være ideelt som en løsning for kloder i mellomklassen med nok metadatalagring til å legge til flere lagringsservere etter hvert som kapasitetskravene øker.

Med tanke på følgende faktorer ble en RAID 0-konfigurasjon valgt for lagringsmål fremfor RAID 10-konfigurasjon.
  1. Skriveytelsen ble målt ved hjelp av dd-kommandoen ved å opprette en 10 GiB-fil med 1 MiB blokkstørrelse og direkte I/O for data. For RAID 0-enheter var gjennomsnittet omtrent 5,1 GB/s for hver enhet, mens for RAID 10-enheter var gjennomsnittet 3,4 GB/s for hver enhet.
  2. Ytelsestester for StorageBench viste at maksimal gjennomstrømning var 5,5 GB/s for RAID 0-konfigurasjon, mens den er 3,4 GB/s for en RAID 10-konfigurasjon. Disse resultatene er som det som ble oppnådd ved hjelp av dd-kommandoer.
  3. RAID 10 gir 50 % utnyttelse av diskkapasiteten og tilsvarende 50 % reduksjon i skriveytelse. Bruk av RAID 10 er en kostbar måte å oppnå lagringsredundans på.
  4. NVMe-disker er dyre og tilbyr hastighetsøkninger som utnyttes best i en RAID 0-konfigurasjon
 

Kundeservice

BeeGFS-klientmodulen må lastes inn på alle verter som trenger tilgang til BeeGFS-filsystemet. Når beegfs-klienten er lastet, vil den montere filsystemene definert i/etc/beegfs/beegfs-mounts.conf-filen i stedet for den vanlige tilnærmingen basert på /etc/fstab.  Ved å ta i bruk denne tilnærmingen starter beegfs-klienten som enhver annen Linux-tjeneste gjennom tjenestens oppstartsskript. Det muliggjør også automatisk rekompilering av BeeGFS-klientmodulen etter systemoppdateringer. 

Når klientmodulen er lastet, vil den montere filsystemene definert i beegfs-mounts.conf. Det er mulig å montere flere beegfs-forekomster på samme klient som vist nedenfor:

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

Eksemplet ovenfor viser to forskjellige filsystemer montert på samme klient. For formålet med denne testingen ble 32x C6420-noder brukt som klienter.

R740xd, 24x NVMe-disker, detaljer om CPU-tilordning


I 24xNVMe-konfigurasjonen til PowerEdge R740xd-serveren er det to x16 NVMe-brokort som mater PCIe-svitsj på bakplanet som vifter ut og mater stasjonene (stasjonene er x4) foran, som vist i figur 7 nedenfor:


R740xd, 24x NVMe Informasjon om CPU-tilordningFigur 7:  R740xd, 24x NVMe Detaljer om CPU-tilordning

I Non-Uniform Memory Access (NUMA) er systemminnet delt inn i soner som kalles noder, som er allokert til CPUer eller stikkontakter. Tilgang til minne som er lokalt for en CPU, er raskere enn minne som er koblet til eksterne CPUer på systemet. En trådet applikasjon fungerer vanligvis best når trådene har tilgang til minne på samme NUMA-node. Ytelseseffekten av NUMA-savner er betydelig, og starter vanligvis med en 10% ytelseshit eller høyere. For å forbedre ytelsen er tjenestene konfigurert til å bruke spesifikke NUMA-soner for å unngå unødvendig bruk av UPI-krysskoblinger og dermed redusere ventetiden. Hver NUMA-sone håndterer 12 stasjoner og bruker ett av de to InfiniBand EDR-grensesnittene på serverne. Denne NUMA-separasjonen oppnås ved å konfigurere NUMA-balansering manuelt ved å opprette tilpassede systemd-enhetsfiler og ved å konfigurere multihoming. Derfor er den automatiske NUMA-balanseringen deaktivert, som vist nedenfor:

# cat /proc/sys/kernel/numa_balancing
0

Figur 8 viser testmiljøet der InfiniBand-tilkoblingene til NUMA-sonen er uthevet.  Hver server har to IP-koblinger og trafikken gjennom NUMA 0-sonen leveres av grensesnitt IB0 mens trafikken gjennom NUMA 1-sonen håndteres av grensesnitt IB1.
Testmiljø-konfigurasjon
Figur 8:  Testmiljø-konfigurasjon
 

Karakterisering av ytelse

Denne delen inneholder ytelsesevaluering som bidrar til å karakterisere Dell EMC Ready Solution for HPC BeeGFS-lagringsløsning med høy ytelse. For ytterligere detaljer og oppdateringer, se etter en hvitbok som vil bli publisert senere. Systemytelsen ble evaluert ved hjelp av IOzone-referansen. Løsningen er testet for sekvensiell lese- og skrivegjennomstrømning og tilfeldig lese- og skrive-IOPS. Tabell 4 beskriver konfigurasjonen av C6420-servere som ble brukt som BeeGFS-klienter for ytelsesstudiene som presenteres i denne bloggen.
 
Tabell 4 Klientkonfigurasjon
Klienter 32x Dell EMC PowerEdge C6420-beregningsnoder
BIOS 2.2.9
Prosessor 2 x Intel Xeon Gold 6148-prosessor ved 2,40 GHz med 20 kjerner per prosessor
Minne  12 x 16 GB DDR4 2666 MT/s DIMM-er – 192 GB
BOSS-kort 2 x 120 GB M.2-oppstartsdisker i RAID 1 for operativsystem
Operativsystem Red Hat Enterprise Linux Server-versjon 7.6
Kjerneversjon 3.10.0-957.el7.x86_64
Interconnect 1 Mellanox ConnectX-4 EDR-kort
OFED Version (BIOS-versjon) 4.5-1.0.1.0

Sekvensiell skriver og leser N-N

For å evaluere sekvensiell lesing og skriving ble IOzone-referansen brukt i sekvensiell lese- og skrivemodus. Disse testene ble utført på flere tråder som startet ved 1 tråd og økte i potenser på 2, opptil 1024 tråder. Ved hver trådtelling ble det generert like mange filer siden denne testen fungerer på én fil per tråd eller tilfellet N klienter til N-fil (N-N). Prosessene ble fordelt på 32 fysiske klientnoder på en rund robin- eller syklisk måte, slik at forespørslene fordeles likt og det er belastningsbalansering. En samlet filstørrelse på 8 TB ble valgt, som ble delt likt mellom antall tråder i en gitt test. Den samlede filstørrelsen ble valgt stor nok til å minimere effekten av hurtigbufring fra serverne så vel som fra BeeGFS-klienter. IOzone ble kjørt i en kombinert skrivemodus og deretter lest (-i 0, -i 1) for å tillate den å koordinere grensene mellom operasjonene. For denne testingen og resultatene brukte vi en 1 MiB poststørrelse for hver løp. Kommandoene som brukes for sekvensielle N-N-tester er gitt nedenfor:

Sekvensiell skriver og leser: iozone -i 0 -i 1 -c -e -w -r 1m -i -s $Size -t $Thread -+n -+m / path / to / threadlist

Hurtigbuffere ble også fjernet eller renset på klientnodene mellom gjentakelser og mellom skrive- og lesetester ved å kjøre kommandoen:

# sync &&; echo 3 > / proc / sys / vm / drop_caches

Standard stripeantall for Beegfs er 4. Størrelsen på segmentet og antall mål per fil kan imidlertid konfigureres basert på katalogbasis. For alle disse testene ble BeeGFS-stripestørrelsen valgt til å være 2 MB og stripeantallet ble valgt til å være 3 siden vi har tre mål per NUMA-sone som vist nedenfor:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe mønster detaljer:
+ Type: RAID0
+ Chunksize: 2M
+ Antall lagringsmål: ønsket:

3+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

De gjennomsiktige store sidene ble deaktivert, og følgende innstillingsalternativer er på plass på metadata- og lagringsserverne:

  • 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

I tillegg til det ovennevnte ble følgende BeeGFS-innstillingsalternativer brukt: 

  • parameteren tuneTargetChooser ble satt til "roundrobin" i metadatakonfigurasjonsfilen 
  • tuneNumWorkers-parameteren ble satt til 24 for metadata og 32 for lagring 
  • connMaxInternodeNum-parameteren ble satt til 32 for metadata og 12 for lagring og 24 for klienter

Sekvensiell IOzone-filstørrelse på 8 TB
Figur 9:  Sekvensiell IOzone-filstørrelse på 8 TB


I figur 9 ser vi at høyeste leseytelse er 132 GB/s ved 1024 tråder og topp skriving er 121 GB/s ved 256 tråder. Hver stasjon kan gi 3,2 GB/s topp leseytelse og 1,3 GB/s topp skriveytelse, noe som gir en teoretisk topp på 422 GB/s for leseoperasjoner og 172 GB/s for skriving. Men her er nettverket den begrensende faktoren. Vi har totalt 11 InfiniBand EDR-koblinger for lagringsserverne i oppsettet. Hvert ledd kan gi en teoretisk toppytelse på 12,4 GB/s, noe som gir en teoretisk toppytelse på 136,4 GB/s. Den oppnådde høyeste lese- og skriveytelsen er henholdsvis 97 % og 89 % av den teoretiske toppytelsen.

Skriveytelsen med én tråd observeres å være ~3 GB/s og leses ved ~3 GB/s. Vi observerer at skriveytelsen skalerer lineært, topper ved 256 tråder og deretter begynner å avta. Ved lavere antall tråder er lese- og skriveytelsen den samme. Fordi inntil 8 tråder, har vi 8 klienter som skriver 8 filer på tvers av 24 mål, noe som betyr at ikke alle lagringsmål blir fullt utnyttet. Vi har 33 lagringsmål i systemet, og derfor trengs det minst 11 tråder for å utnytte alle serverne fullt ut. Leseytelsen registrerer en jevn lineær økning med økningen i antall samtidige tråder, og vi observerer nesten lik ytelse på 512 og 1024 tråder.

Vi observerer også at leseytelsen er lavere enn skriving for trådantall fra 16 til 128, og deretter begynner leseytelsen å skalere. Dette skyldes at mens en PCIe-leseoperasjon er en ikke-postert operasjon som krever både en forespørsel og en fullføring, er en PCIe-skriveoperasjon en brann og glem-operasjon. Når transaksjonslagpakken er overlevert til datalinklaget, fullføres operasjonen. En skriveoperasjon er en postert operasjon som bare består av en forespørsel.

Lesegjennomstrømming er vanligvis lavere enn skrivegjennomstrømningen fordi lesing krever to transaksjoner i stedet for én enkelt skriving for samme mengde data. PCI Express bruker en delt transaksjonsmodell for lesing. Den leste transaksjonen inkluderer følgende trinn:

  • Anmoderen sender en minneleseforespørsel (MRR).
  • Fullføreren sender ut bekreftelsen til MRR.
  • Fullfører returnerer en fullføring med data.

Gjennomlesingen avhenger av forsinkelsen mellom tidspunktet da leseforespørselen utstedes og tiden det tar å returnere dataene. Men når programmet utsteder nok antall leseforespørsler til å dekke denne forsinkelsen, maksimeres gjennomstrømmingen. Det er grunnen til at mens leseytelsen er mindre enn skriveytelsen fra 16 tråder til 128 tråder, måler vi en økt gjennomstrømning når antall forespørsler øker.  En lavere gjennomstrømning måles når bestilleren venter på ferdigstillelse før han utsteder påfølgende forespørsler. En høyere gjennomstrømning registreres når flere forespørsler utstedes for å amortisere forsinkelsen etter at de første dataene returneres.


Tilfeldige skriver og leser N-N

For å evaluere tilfeldig I/O-ytelse ble IOzone brukt i tilfeldig modus. Tester ble utført på gjengetall fra 4 tråder til opptil 1024 tråder. Direkte I/O-alternativ (-I) ble brukt til å kjøre IOzone slik at alle operasjoner omgår bufferbufferen og går direkte til disken. BeeGFS stripe teller på 3 og blings størrelse på 2MB ble brukt. En forespørselsstørrelse på 4KiB brukes på IOzone. Ytelsen måles i I/O-operasjoner per sekund (IOPS). OS-cachene ble droppet mellom kjøringene på BeeGFS-serverne og BeeGFS-klientene. Kommandoen som brukes til å utføre tilfeldige skriver og leser er gitt nedenfor:

Tilfeldig leser og skriver: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m / path / to / threadlist


Tilfeldig lese- og skriveytelse ved bruk av IOzone med 8 TB samlet filstørrelse
Figur 10:  Tilfeldig lese- og skriveytelse ved hjelp av IOzone med 8 TB samlet filstørrelse

Den tilfeldige skrivingen topper seg ved ~ 3,6 millioner IOPS ved 512 tråder, og de tilfeldige leser topp på ~ 3,5 millioner IOPS ved 1024 tråder som vist i figur 10. Både skrive- og leseytelsen viser høyere ytelse når det er et høyere antall I/O-forespørsler. Dette skyldes at NVMe-standarden støtter opptil 64K I/O-kø og opptil 64K-kommandoer per kø. Dette store bassenget av NVMe-køer gir høyere nivåer av I / O-parallellitet, og derfor observerer vi IOPS som overstiger 3 millioner.


Konklusjon og videre arbeid

Denne bloggen kunngjør lanseringen av Dell EMC High Performance BeeGFS-lagringsløsning og fremhever ytelsesegenskapene. Løsningen har en topp sekvensiell lese- og skriveytelse på henholdsvis ~132 GB/s og ~121 GB/s, og den tilfeldige skrivefunksjonen når en topp på ~3,6 millioner IOPS og tilfeldige lesinger ved ~3,5 millioner IOPS.

Denne bloggen er del en av "BeeGFS Storage Solution" som er designet med fokus på kladdeplass med høy ytelse. Følg med for del 2 av bloggserien som beskriver hvordan løsningen kan skaleres ved å øke antall servere for å øke ytelsen og kapasiteten. Del 3 av bloggserien vil diskutere flere funksjoner i BeeGFS og vil markere bruken av "StorageBench", den innebygde lagringsmål benchmark av BeeGFS.

Som en del av de neste trinnene vil vi publisere en hvitbok senere med metadataytelsen og N-trådene til 1-filen IOR-ytelse og med ytterligere detaljer om designhensyn, justering og konfigurasjon.


Referanser

[1] BeeGFS-dokumentasjon: 
https://www.beegfs.io/wiki/[2] Slik kobler du sammen to grensesnitt på samme delnett:  https://access.redhat.com/solutions/30564

対象製品

PowerSwitch S3048-ON, Mellanox SB7800 Series, PowerEdge R640, PowerEdge R740XD
文書のプロパティ
文書番号: 000130963
文書の種類: Solution
最終更新: 25 3月 2024
バージョン:  7
質問に対する他のDellユーザーからの回答を見つける
サポート サービス
お使いのデバイスがサポート サービスの対象かどうかを確認してください。