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

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
   • Administrasjonstjeneste
   • Metadatatjeneste
   • Lagringstjeneste
   • Kundeservice
5. R740xd, 24x NVMe-disker, detaljer om CPU-tilordning
6. Karakterisering av ytelse
   • Sekvensiell leser og skriver N-N
   • Tilfeldige leser og skriver N-N
7. Konklusjon og videre arbeid
    

Innledning

Arkitektur for løsningsreferanse

Maskinvare- og programvarekonfigurasjon

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

Detaljer om løsningskonfigurasjon

• Administrasjonstjeneste
• Metadatatjeneste
• Lagringstjeneste
• Kundeservice

Administrasjonstjeneste

Metadatatjeneste

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.

Lagringstjeneste

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

$ cat /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-disker, detaljer om CPU-tilordning

# cat /proc/sys/kernel/numa_balancing
0

Karakterisering av ytelse

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

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

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