Dell EMC-färdiga lösningar för lagring med höga prestanda med HPC BeeGFS

Artikel skriven av Nirmala Sundararajan från Dell EMC HPC och AI Innovation Lab i november 2019

Dell EMC-färdiga lösningar för lagring med höga prestanda med HPC BeeGFS

Innehållsförteckning

1. Introduktion
2. Lösningsreferensarkitektur
3. Maskin- och programvarukonfiguration
4. Information om lösningskonfiguration
   • Hanteringstjänst
   • Metadatatjänst
   • Lagringstjänst
   • Kundtjänst
5. R740xd, 24x NVMe-enheter, information om CPU-mappning
6. Karakterisering av prestanda
   • Sekventiella läsningar och skrivningar N-N
   • Slumpmässiga läsningar och skrivningar N-N
7. Slutsats och framtida arbete
    

Introduktion

Lösningsreferensarkitektur

Maskin- och programvarukonfiguration

I tabell 1 och 2 beskrivs maskinvaruspecifikationerna för hanteringsservern respektive metadata/lagringsservern. I tabell 3 beskrivs de programvaruversioner som används för lösningen.

Information om lösningskonfiguration

• Hanteringstjänst
• Metadatatjänst
• Lagringstjänst
• Kundtjänst

Hanteringstjänst

Metadatatjänst

Bild 3:  Metadataserver

Bild 4 visar RAID-konfigurationen för metadataservern. Den visar hur enheterna i NUMA-zon 0 är värdar för MDT:erna på metadataservern och de i NUMA-zon 1 är värdar för lagringsdata, medan lagringsservrarna är värdar för ST:erna i båda NUMA-zonerna.

Lagringstjänst

1. Skrivprestanda mättes med dd-kommandot genom att skapa en 10 GiB-fil med 1 MiB-blockstorlek och direkt I/O för data. För RAID 0-enheter var genomsnittet cirka 5,1 GB/s för varje enhet medan genomsnittet för RAID 10-enheter var 3,4 GB/s för varje enhet.
2. StorageBench-prestandatest visade att maximal genomströmning var 5,5 Gbit/s för RAID 0-konfiguration medan den är 3,4 Gbit/s för en RAID 10-konfiguration. Dessa resultat liknar de som erhölls med dd-kommandon.
3. RAID 10 ger 50 % utnyttjande av diskkapaciteten och en liknande 50 % minskning av skrivprestanda. Att använda RAID 10 är ett dyrt sätt att få lagringsredundans.
4. NVMe-enheter är dyra och erbjuder högre hastigheter som bäst utnyttjas i en RAID 0-konfiguration

Kundtjänst

$ 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-enheter, information om CPU-mappning

# cat /proc/sys/kernel/numa_balancing
0

Karakterisering av prestanda

Sekventiella skrivningar och läsningar N-N

För att utvärdera sekventiella läsningar och skrivningar användes IOzone-riktmärket i sekventiellt läs- och skrivläge. Dessa tester utfördes på flera trådantal som började med 1 tråd och ökade i styrkor på 2, upp till 1024 trådar. Vid varje trådantal genererades lika många filer eftersom det här testet fungerar på en fil per tråd eller N klienter till N-fil (N-N) ärendet. Processerna distribuerades över 32 fysiska klientnoder på ett resursallokerings- eller cykliskt sätt så att begärandena distribueras jämnt och det finns belastningsutjämning. En aggregerad filstorlek på 8 TB valdes som var jämnt fördelad mellan antalet trådar i ett visst test. Den aggregerade filstorleken valdes tillräckligt stor för att minimera effekterna av cachning från servrarna såväl som från BeeGFS-klienterna. IOzone kördes i ett kombinerat skrivläge och lästes sedan (-i 0, -i 1) så att den kunde koordinera gränserna mellan operationerna. För dessa tester och resultat använde vi en 1MiB-rekordstorlek för varje körning. Kommandona som används för sekventiella N-N-tester ges nedan:

Sekventiella skrivningar och läsningar: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

OS-cacheminnen togs också bort eller rensades på klientnoderna mellan iterationer samt mellan skriv- och lästester genom att köra kommandot:

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

Standardantalet ränder för Beegfs är 4. Segmentstorleken och antalet mål per fil kan dock konfigureras per katalog. För alla dessa tester valdes BeeGFS-stripe-storleken till 2 MB och stripe-antalet till 3 eftersom vi har tre mål per NUMA-zon som visas nedan:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
Överordnat ID: nod för rotmetadata
: node001-numa0-4 [ID: 4]
Stripe mönsterdetaljer:
+ Typ: RAID0
+-segmentstorlek: 2M
+ Antal lagringsmål: önskas:
3+ Lagringspool: 1 (Standard)
Inod-hashsökväg: 7/5E/0-5D9BA1BC-1

De genomskinliga enorma sidorna har inaktiverats och följande justeringsalternativ finns på metadata- och lagringsservrarna:

• 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

Utöver ovanstående användes följande BeeGFS-inställningsalternativ: 

• Parametern tuneTargetChooser var inställd på "roundrobin" i metadatakonfigurationsfilen 
• Parametern tuneNumWorkers var inställd på 24 för metadata och 32 för lagring 
• connMaxInternodeNum-parametern var inställd på 32 för metadata och 12 för lagring och 24 för klienter

I bild 9 ser vi att högsta läsprestanda är 132 GB/s vid 1 024 trådar och högsta skrivning är 121 GB/s vid 256 trådar. Varje enhet kan ge 3,2 GB/s högsta läsprestanda och 1,3 GB/s högsta skrivprestanda, vilket ger en teoretisk topp på 422 GB/s för läsning och 172 GB/s för skrivning. Här är dock nätverket den begränsande faktorn. Vi har totalt 11 InfiniBand EDR-länkar för lagringsservrarna i konfigurationen. Varje länk kan ge en teoretisk topprestanda på 12,4 GB/s, vilket ger en teoretisk topprestanda på 136,4 GB/s. Den uppnådda maximala läs- och skrivprestandan är 97 % respektive 89 % av den teoretiska topprestandan.

Skrivprestanda för enskild tråd observeras vara ~3 GB/s och läsas vid ~3 GB/s. Vi ser att skrivprestandan skalas linjärt, toppar på 256 trådar och sedan börjar minska. Vid lägre trådantal är läs- och skrivprestandan densamma. Fram till 8 trådar har vi 8 klienter som skriver 8 filer över 24 mål, vilket innebär att inte alla lagringsmål används fullt ut. Vi har 33 lagringsmål i systemet och därför behövs minst 11 trådar för att fullt ut utnyttja alla servrar. Läsprestandan registrerar en stadig linjär ökning med ökningen av antalet samtidiga trådar och vi observerar nästan liknande prestanda vid 512 och 1024 trådar.

Vi ser också att läsprestandan är lägre än skrivningar för trådantal från 16 till 128 och sedan börjar läsprestandan skalas. Det beror på att medan en PCIe-läsåtgärd är en icke-bokförd åtgärd, som kräver både en begäran och ett slutförande, är en PCIe-skrivåtgärd en fire and forget-åtgärd. När transaktionsskiktspaketet har överlämnats till datalänklagret slutförs åtgärden. En skrivåtgärd är en "bokförd" åtgärd som endast består av en begäran.

Läsdataflödet är vanligtvis lägre än skrivdataflödet eftersom läsningar kräver två transaktioner i stället för en enda skrivning för samma mängd data. PCI Express använder en delad transaktionsmodell för läsningar. Lästransaktionen innehåller följande steg:

• Beställaren skickar en begäran om minnesläsning (MRR).
• Slutföraren skickar ut bekräftelsen till MRR.
• Slutföraren returnerar en Slutförande med data.

Läsdataflödet beror på fördröjningen mellan den tidpunkt då läsbegäran utfärdas och den tid det tar för slutföraren att returnera data. Men när programmet utfärdar tillräckligt många läsbegäranden för att täcka den här fördröjningen maximeras dataflödet. Det är anledningen till att även om läsprestandan är lägre än för skrivningar från 16 trådar till 128 trådar, mäter vi ett ökat dataflöde när antalet begäranden ökar.  Ett lägre dataflöde mäts när beställaren väntar på slutförande innan efterföljande begäranden utfärdas. Ett högre dataflöde registreras när flera begäranden utfärdas för att amortera fördröjningen efter att de första data returneras.

Slumpmässiga skrivningar och läsningar N-N

För att utvärdera slumpmässig IO-prestanda användes IOzone i slumpmässigt läge. Tester utfördes på trådantal från 4 trådar till upp till 1024 trådar. Direct IO-alternativet (-I) användes för att köra IOzone så att alla åtgärder kringgår buffertcachen och går direkt till disken. BeeGFS stripe count på 3 och chunk size på 2MB användes. En begärandestorlek på 4KiB används på IOzone. Prestanda mäts i I/O-åtgärder per sekund (IOPS). OS-cacheminnena togs bort mellan körningarna på BeeGFS-servrarna och BeeGFS-klienterna. Kommandot som används för att köra slumpmässiga skrivningar och läsningar anges nedan:

Slumpmässiga läsningar och skrivningar: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Bild 10:  Prestanda för slumpmässig läsning och skrivning med IOzone med en aggregerad filstorlek

på 8 TB De slumpmässiga skrivningarna toppar vid ~3,6 miljoner IOPS vid 512 trådar och de slumpmässiga läsningarna toppar vid ~3,5 miljoner IOPS vid 1024 trådar som visas i bild 10. Både skriv- och läsprestanda visar högre prestanda när det finns ett högre antal I/O-begäranden. Det beror på att NVMe-standarden stöder upp till 64K I/O-kö och upp till 64K kommandon per kö. Den här stora poolen med NVMe-köer ger högre nivåer av I/O-parallellitet och därför ser vi att IOPS överskrider 3 miljoner.

Slutsats och framtida arbete

I den här bloggen tillkännager vi lanseringen av Dell EMC High Performance BeeGFS-lagringslösningen och lyfter fram dess prestandaegenskaper. Lösningen har en högsta sekventiell läs- och skrivprestanda på ~132 GB/s respektive ~121 GB/s och slumpmässiga skrivningar toppar på ~3,6 miljoner IOPS och slumpmässiga läsningar på ~3,5 miljoner IOPS.

Den här bloggen är del ett av "BeeGFS Storage Solution" som har utformats med fokus på skraputrymme med hög prestanda. Håll ögonen öppna för del 2 i bloggserien som beskriver hur lösningen kan skalas genom att öka antalet servrar för att öka prestanda och kapacitet. Del 3 av bloggserien kommer att diskutera ytterligare funktioner i BeeGFS och kommer att belysa användningen av "StorageBench", det inbyggda riktmärket för lagringsmål för BeeGFS.

Som en del av nästa steg kommer vi att publicera ett informationsdokument senare med prestanda för metadata och N-trådar till 1-fil-IOR-prestanda och med ytterligare information om designöverväganden, justering och konfiguration.

Referenser