Dell EMC Ready Solution til HPC BeeGFS lagring med højydelse

Artikel skrevet af Nirmala Sundararajan fra Dell EMC HPC and AI Innovation Lab i november 2019

Dell EMC Ready Solution til HPC BeeGFS lagring med højydelse

Indholdsfortegnelse

1. Indledning
2. Løsningsreferencearkitektur
3. Hardware- og softwarekonfiguration
4. Oplysninger om løsningskonfiguration
   • Administrationsservice
   • Metadata-service
   • Lagerpladsservice
   • Kundeservice
5. R740xd, 24x NVMe-drev, oplysninger om CPU-tilknytning
6. Karakterisering af ydeevne
   • Sekventiel læser og skriver N-N
   • Vilkårligt læser og skriver N-N
7. Konklusion og fremtidigt arbejde
    

Indledning

Løsningsreferencearkitektur

Hardware- og softwarekonfiguration

Tabel 1 og 2 beskriver hardwarespecifikationerne for henholdsvis administrationsserveren og metadata/storageserveren. Tabel 3 beskriver de softwareversioner, der anvendes til løsningen.

Oplysninger om løsningskonfiguration

• Administrationsservice
• Metadata-service
• Lagerpladsservice
• Kundeservice

Administrationsservice

Metadata-service

Figur 3:  Metadataserver

Figur 4 viser RAID-konfigurationen for metadataserveren. Det fremhæver, hvordan drevene i NUMA-zone 0 i metadataserveren er vært for MDT'erne, og dem i NUMA-zone 1 er vært for lagerdataene, mens lagerserverne er vært for ST'erne i begge NUMA-zoner.

Lagerpladsservice

1. Skriveydelsen blev målt ved hjælp af kommandoen dd ved at oprette en 10 GiB-fil med en 1MiB-blokstørrelse og direkte I/O for data. For RAID 0-enheder var gennemsnittet ca. 5,1 GB/s for hver enhed, mens gennemsnittet for RAID 10-enheder var 3,4 GB/s for hver enhed.
2. StorageBench-benchmarktest viste, at den maksimale overførselshastighed var 5,5 GB/s for RAID 0-konfiguration, mens den er 3,4 GB/s for en RAID 10-konfiguration. Disse resultater svarer til det, der blev opnået ved hjælp af dd-kommandoer.
3. RAID 10 giver 50 % udnyttelse af diskkapaciteten og en tilsvarende 50 % reduktion i skriveydeevnen. Brug af RAID 10 er en dyr måde at opnå storageredundans på.
4. NVMe-drev er dyre og tilbyder hastigheder, som bedst udnyttes i en RAID 0-konfiguration

Kundeservice

$ kat /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-drev, oplysninger om CPU-tilknytning

# kat /proc/sys/kernel/numa_balancing
0

Karakterisering af ydeevne

Sekventiel skrivning og læsning N-N

For at evaluere sekventielle læsninger og skrivninger blev IOzone-benchmarket brugt i sekventiel læse- og skrivetilstand. Disse tests blev udført på flere trådtællinger, der startede ved 1 tråd og steg i kræfter på 2, op til 1024 tråde. Ved hvert trådantal blev der genereret et lige antal filer, da denne test fungerer på en fil pr. tråd eller sagen N-klienter til N-fil (N-N). Processerne blev fordelt på 32 fysiske klientnoder på en round robin eller cyklisk måde, så anmodningerne fordeles ligeligt, og der er belastningsbalancering. Der blev valgt en samlet filstørrelse på 8 TB, som blev ligeligt fordelt mellem antallet af tråde inden for en given test. Den samlede filstørrelse blev valgt stor nok til at minimere virkningerne af caching fra serverne såvel som fra BeeGFS-klienter. IOzone blev kørt i en kombineret skrivetilstand og derefter læst (-i 0, -i 1) for at gøre det muligt at koordinere grænserne mellem operationerne. Til denne test og resultater brugte vi en 1MiB-rekordstørrelse til hver kørsel. De kommandoer, der anvendes til sekventielle N-N-tests, er angivet nedenfor:

Sekventielle skrivninger og læsninger: iozone -i 0 -i 1 -c -e -w -r 1m -i -s $Size -t $Thread -+n -+m /path/to/threadlist

OS-cacher blev også tabt eller renset på klientnoderne mellem iterationer samt mellem skrive- og læsetest ved at køre kommandoen:

# synkronisering &&; ekko 3 > / proc / sys / vm / drop_caches

Standardantallet af striber for Beegfs er 4. Blokstørrelsen og antallet af mål pr. fil kan dog konfigureres pr. mappe. For alle disse tests blev BeeGFS stripe-størrelse valgt til at være 2MB, og stripe-antallet blev valgt til at være 3, da vi har tre mål pr. NUMA-zone som vist nedenfor:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
Overordnet ID: rodmetadatanode
: node001-numa0-4 [ID: 4]
Detaljer om stribemønster:
+ Type: RAID0
+-stykkestørrelse: 2M
+ Antal storagemål: ønsket:
3+ Opbevaringspulje: 1 (Standard)
Inode hash-sti: 7/5E/0-5D9BA1BC-1

De gennemsigtige enorme sider blev deaktiveret, og følgende indstillingsmuligheder er på plads på metadata- og lagerserverne:

• 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

Ud over ovenstående blev følgende BeeGFS tuning muligheder brugt: 

• tuneTargetChooser-parameteren blev indstillet til "roundrobin" i metadatakonfigurationsfilen 
• tuneNumWorker-parameteren blev indstillet til 24 for metadata og 32 for lagring 
• connMaxInternodeNum-parameteren blev indstillet til 32 for metadata og 12 for lagring og 24 for klienter

I figur 9 ser vi, at maksimal læseydelse er 132 GB/s ved 1024 tråde, og spidsværdien er 121 GB/s ved 256 tråde. Hvert drev kan levere en maksimal læseydeevne på 3,2 GB/s og en maksimal skriveydeevne på 1,3 GB/s, hvilket giver mulighed for en teoretisk spidsbelastning på 422 GB/s for læsninger og 172 GB/s for skrivninger. Men her er netværket den begrænsende faktor. Vi har i alt 11 InfiniBand EDR links til storageserverne i opsætningen. Hvert link kan give en teoretisk topydelse på 12,4 GB/s, hvilket giver mulighed for en teoretisk topydelse på 136,4 GB/s. Den opnåede maksimale læse- og skriveydelse er henholdsvis 97% og 89% af den teoretiske topydelse.

Den enkelttrådede skriveydelse observeres at være ~3 GB/s og læses ved ~3 GB/s. Vi observerer, at skriveydelsen skaleres lineært, topper ved 256 tråde og derefter begynder at falde. Ved lavere trådantal er læse- og skriveydelsen den samme. Fordi indtil 8 tråde har vi 8 klienter, der skriver 8 filer på tværs af 24 mål, hvilket betyder, at ikke alle lagermål udnyttes fuldt ud. Vi har 33 storagemål i systemet, og derfor skal der mindst 11 tråde til for at udnytte alle serverne fuldt ud. Læseydelsen registrerer en støt lineær stigning med stigningen i antallet af samtidige tråde, og vi observerer næsten ens ydeevne ved 512 og 1024 tråde.

Vi bemærker også, at læseydelsen er lavere end skrivninger for trådtællinger fra 16 til 128, og derefter begynder læseydelsen at skalere. Dette skyldes, at mens en PCIe-læsehandling er en ikke-bogført handling, der kræver både en anmodning og en færdiggørelse, er en PCIe-skrivehandling en brand- og glemningshandling. Når transaktionslagpakken er overdraget til datalinklaget, fuldføres handlingen. En skrivehandling er en "Bogført" handling, der kun består af en anmodning.

Læsegennemstrømningen er typisk lavere end skrivegennemløbet, fordi læsninger kræver to transaktioner i stedet for en enkelt skrivning for den samme mængde data. PCI Express bruger en opdelt transaktionsmodel til læsninger. Læsetransaktionen omfatter følgende trin:

• Anmoderen sender en MRR (Memory Read Request).
• Fuldføreren sender bekræftelsen til MRR.
• Fuldførelsen returnerer fuldførelsen med data.

Læsehastigheden afhænger af forsinkelsen mellem det tidspunkt, hvor læseanmodningen udsendes, og den tid, det tager for fuldførelsen at returnere dataene. Men når programmet udsteder et tilstrækkeligt antal læseanmodninger til at dække denne forsinkelse, maksimeres gennemløbet. Det er grunden til, at mens læseydelsen er mindre end skrivningerne fra 16 tråde til 128 tråde, måler vi en øget gennemstrømning, når antallet af anmodninger stiger.  Et lavere gennemløb måles, når anmoderen venter på færdiggørelse, før der sendes efterfølgende anmodninger. Et højere gennemløb registreres, når der udstedes flere anmodninger om at afskrive forsinkelsen efter de første datareturneringer.

Vilkårligt skriver og læser N-N

For at evaluere tilfældig IO-ydeevne blev IOzone brugt i tilfældig tilstand. Test blev udført på trådtællinger startende fra 4 tråde til op til 1024 tråde. Direkte IO-indstilling (-I) blev brugt til at køre IOzone, så alle operationer omgår buffercachen og går direkte til disken. BeeGFS stripe count på 3 og chunk størrelse på 2MB blev brugt. En 4KiB-anmodningsstørrelse bruges på IOzone. Ydeevne måles i I/O-handlinger pr. sekund (IOPS). OS-cacherne blev droppet mellem kørslerne på BeeGFS-serverne såvel som BeeGFS-klienterne. Kommandoen, der bruges til at udføre tilfældige skrivninger og læsninger, er angivet nedenfor:

Vilkårligt læser og skriver: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Figur 10:  Vilkårlig læse- og skriveydeevne ved hjælp af IOzone med en samlet filstørrelse

på 8 TB De vilkårlige skrivninger topper ved ~3,6 mio. IOPS ved 512 tråde, og de vilkårlige læsninger topper ved ~3,5 mio. IOPS ved 1024 tråde, som vist i figur 10. Både skrive- og læseydeevnen viser en højere ydeevne, når der er et større antal IO-anmodninger. Det skyldes, at NVMe-standarden understøtter op til 64K I/O-kø og op til 64K kommandoer pr. kø. Denne store pulje af NVMe-køer giver højere niveauer af I/O-parallelitet, og derfor observerer vi IOPS, der overstiger 3 millioner.

Konklusion og fremtidigt arbejde

Denne blog annoncerer udgivelsen af Dell EMC BeeGFS-storageløsningen med høj ydeevne og fremhæver dens ydeevneegenskaber. Løsningen har en maksimal sekventiel læse- og skriveydeevne på henholdsvis ~132 GB/s og ~121 GB/s, og de vilkårlige skrivninger topper ved ~3,6 millioner IOPS og vilkårlige læsninger ved ~3,5 millioner IOPS.

Denne blog er en del af "BeeGFS Storage Solution", som er designet med fokus på ridseplads med høj ydeevne. Hold øje med del 2 af blogserien, der beskriver, hvordan løsningen kan skaleres ved at øge antallet af servere for at øge ydeevnen og kapaciteten. Del 3 af blogserien vil diskutere yderligere funktioner i BeeGFS og vil fremhæve brugen af "StorageBench", det indbyggede benchmark for lagringsmål for BeeGFS.

Som en del af de næste trin udgiver vi en hvidbog senere med metadata-ydeevnen og N-trådene til 1-fil-IOR-ydeevnen og med yderligere detaljer om designovervejelser, finindstilling og konfiguration.

Referencer