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
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 |
Eksemplet ovenfor viser to forskjellige filsystemer montert på samme klient. For formålet med denne testingen ble 32x C6420-noder brukt som klienter.$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf
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.# cat /proc/sys/kernel/numa_balancing
0
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 |
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:
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:
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.
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.
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.