PowerEdge: Dell Ready Solutions til HPC BeeGFS med høj ydeevne

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

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

Dell HPC-teamet er stolte af at kunne annoncere udgivelsen af "Dell EMC Ready Solutions for HPC BeeGFS Storage", som er den seneste tilføjelse til HPC-storageporteføljen. Denne løsning anvender R740xd-servere, som hver har 24 x Intel P4600 1,6 TB NVMe, Express Flash-drev til blandet brug og to Mellanox ConnectX-5 InfiniBand EDR-adaptere. I denne 24 NVMe-drevkonfiguration tilsluttes 12 NVMe-SSD'er til en PCIe-switch, og hver switch er tilsluttet én CPU vha. et x16 PCIe-forlængerkort. Desuden er hver IB-grænseflade forbundet til en CPU. En sådan afbalanceret konfiguration, hvor hver CPU er tilsluttet én InfiniBand-adapter og håndterer 12 NVMe SSD'er, giver maksimal ydeevne ved at sikre, at processorerne er lige beskæftiget med at håndtere I/O-anmodninger til og fra NVMe-drevene.

Fokus for løsningen er high performance I/O, og den er designet som en højhastigheds scratch-løsning. Kernen i løsningen er brugen af højhastigheds NVMe SSD'er, der tilbyder høj båndbredde og lav latenstid ved at fjerne planlæggeren og køflaskehalse fra bloklaget. BeeGFS-filsystemet understøtter også høj samlet I/O-gennemstrømning.

Løsningsreferencearkitektur

Figur 1 viser løsningens referencearkitektur. Administrationsserveren er kun forbundet med Ethernet til metadata- og lagerserverne. Hver metadata- og lagerserver har to InfiniBand-links og er forbundet til det private netværk via Ethernet. Klienterne har ét InfiniBand-link og er forbundet til den private grænseflade via Ethernet.

Figur 1:  Dell Ready Solutions til HPC BeeGFS-storage – referencearkitektur

Hardware- og softwarekonfiguration

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

Oplysninger om løsningskonfiguration

BeeGFS-arkitekturen består af fire hovedtjenester:

• Administrationsservice
• Metadata-service
• Lagerpladsservice
• Kundeservice

Bortset fra klienttjenesten, som er et kernemodul, er administrations-, metadata- og lagringstjenesterne brugerrumsprocesser. Figur 2 illustrerer, hvordan referencearkitekturen i Dell EMC Ready Solutions for HPC BeeGFS Storage er knyttet til den generelle arkitektur i BeeGFS-filsystemet.

Figur 2:  BeeGFS-filsystem på PowerEdge R740xd med NVMe SSD'er

Administrationsservice

Hvert BeeGFS-filsystem eller navneområde har kun én administrationstjeneste. Administrationstjenesten er den første tjeneste, der skal konfigureres, fordi når vi konfigurerer alle andre tjenester, skal de registrere sig hos administrationstjenesten. En PowerEdge R640 bruges som administrationsserver. Ud over at være vært for administrationstjenesten (beegfs-mgmtd.service) er den også vært for overvågningstjenesten (beegfs-mon.service), der indsamler statistikker fra systemet og leverer dem til brugeren ved hjælp af tidsseriedatabasen InfluxDB. Til visualisering af data indeholder beegfs-mon foruddefinerede Grafana-ruder , der kan bruges som standard. Administrationsserveren har 6 x 300 GB harddiske konfigureret i RAID 10 til operativsystemet og InfluxDB.

Metadata-service

Metadatatjenesten er en scale-out-tjeneste, hvilket betyder, at der kan være mange metadatatjenester i et BeeGFS-filsystem. Hver metadatatjeneste har dog nøjagtigt ét metadatamål til lagring af metadata. På metadatadestinationen opretter BeeGFS én metadatafil pr. brugeroprettet fil. BeeGFS-metadata distribueres pr. Mappe. Metadatatjenesten leverer datastripingoplysningerne til klienterne og er ikke involveret i dataadgangen mellem filåbning/-lukning.

En PowerEdge R740xd med 24 Intel P4600 1,6 TB NVMe-drev bruges til metadata-storage. Da kravene til lagerkapacitet for BeeGFS-metadata er meget små, blev kun de 12 drev på NUMA-zone 0 brugt til at være vært for Metadata-T-argets (MDT'er) i stedet for at bruge en dedikeret metadataserver, mens de resterende 12 drev på NUMA-zonen er vært for Storage T-argets(ST'er).

Figur 3 viser metadataserveren. De 12 drev, der er indesluttet i det gule rektangel, er MDT'erne i NUMA-zonen 0, mens de 12 drev, der er indesluttet i det grønne rektangel, er ST'erne i NUMA-zone 1. Denne konfiguration undgår ikke kun NUMA-problemer, men giver også nok metadatalager til at lette skalering af kapaciteten og ydeevnen efter behov.

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.

Figur 4:  Konfiguration af drev i metadataserveren

De 12 drev, der bruges til metadata, er konfigureret som en 6x RAID 1-diskgruppe bestående af to drev, der hver fungerer som en MDT. Der kører seks metadatatjenester, som hver håndterer én MDT. De resterende 12 storagedrev konfigureres i 3x RAID 0-diskgrupper med fire drev hver. Der kører tre lagertjenester i NUMA 1-zonen, en tjeneste for hver ST. Så serveren, der er medvært for metadata og lagermål, har 6 MDT'er og 3 ST'er. Det kører også seks metadatatjenester og tre lagringstjenester. Hver MDT er et ext4-filsystem baseret på en RAID 1-konfiguration. ST'erne er baseret på et XFS-filsystem konfigureret i RAID 0.
 

Lagerpladsservice

Ligesom metadatatjenesten er lagringstjenesten også en skaleringstjeneste. Der kan være mange forekomster af lagringstjenesten i et BeeGFS-filsystem. I modsætning til metadatatjenesten kan der dog være flere lagermål pr. lagertjeneste. Lagringstjenesten gemmer det stribede brugerfilindhold, også kendt som dataklumpfiler.

Figur 5 viser de 5 x PowerEdge R740xd-servere, der bruges som storageservere.

Figur 5:  Dedikerede storageservere

Hver storageserver er konfigureret med 6x RAID 0-grupper, hver af fire drev, og er således vært for 6 ST er pr. server (3 pr. NUMA-zone), som vist i figur 6 nedenfor:

Figur 6:  Konfiguration af drev i storageserverne

I alt er basisreferencearkitekturkonfigurationen vært for 6 MDT'er og 33 ST'er. Fem dedikerede storageservere giver en rå kapacitet på 211 TB og en brugbar kapacitet på 190TiB. Den estimerede brugbare kapacitet i TiB = Antal drev x kapacitet pr. drev i TB x 0,99 (filsystemets faste drev) x (10^12/2^40). Dette ville være ideelt som en mellemklasse ridseløsning med nok metadatalagring til at lette tilføjelse af flere lagerservere, efterhånden som kapacitetskravene stiger.

På baggrund af følgende faktorer blev der valgt en RAID 0-konfiguration til storagemål frem for RAID 10-konfiguration.

1. Skriveydelsen blev målt ved hjælp af kommandoen dd ved at oprette en fil på 10 GB med en blokstørrelse på 1 MB 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-konfigurationen, 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 bruges i en RAID 0-konfiguration

Kundeservice

BeeGFS-klientmodulet skal indlæses på alle de værter, der skal have adgang til BeeGFSs-filsystemet. Når beegfs-klienten indlæses, monterer den de filsystemer, der er defineret i filen/etc/beegfs/beegfs-mounts.conf i stedet for den sædvanlige tilgang baseret på /etc/fstab. Vedtagelse af denne tilgang starter beegfs-klienten som enhver anden Linux-tjeneste gennem servicestartscriptet. Det muliggør også automatisk rekompilering af BeeGFS-klientmodulet efter systemopdateringer. 

Når klientmodulet er indlæst, monterer det de filsystemer, der er defineret i beegfs-mounts.conf. Det er muligt at montere flere beegfs-forekomster på den 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

Ovenstående eksempel viser to forskellige filsystemer monteret på den samme klient. Med henblik på denne test blev 32x C6420-noder brugt som klienter.

R740xd, 24x NVMe-drev, oplysninger om CPU-tilknytning

I 24xNVMe-konfigurationen på PowerEdge R740xd-serveren er der to x16 NVMe-brokort, der leverer PCIe-switch på backplane, som blæser ud og fører drevene (drevene er x4) foran som vist i figur 7 nedenfor:


Figur 7:  R740xd, 24x NVMe Oplysninger om CPU-tilknytning

I ikke-ensartet hukommelsesadgang (NUMA) er systemhukommelsen opdelt i zoner, der kaldes noder, som tildeles CPU'er eller sokler. Adgang til hukommelse, der er lokal i en CPU, er hurtigere end hukommelse, der er tilsluttet eksterne CPU'er på systemet. Et trådet program fungerer typisk bedst, når trådene har adgang til hukommelse på den samme NUMA-node. Præstationseffekten af NUMA-misser er signifikant og starter generelt ved et præstationshit på 10% eller højere. For at forbedre ydeevnen er tjenesterne konfigureret til at bruge specifikke NUMA-zoner for at undgå unødvendig brug af UPI-links på tværs af stikkontakter og derved reducere latenstiden. Hver NUMA-zone håndterer 12 drev og bruger en af de to InfiniBand EDR-grænseflader på serverne. Denne NUMA-adskillelse opnås ved manuelt at konfigurere NUMA-balancering, ved at oprette brugerdefinerede systemd-enhedsfiler og ved at konfigurere multihoming. Derfor er den automatiske NUMA-balancering deaktiveret som vist nedenfor:

# cat /proc/sys/kernel/numa_balancing
0

Figur 8 viser testbænken, hvor InfiniBand-forbindelserne til NUMA-zonen er fremhævet. Hver server har to IP-links, og trafikken gennem NUMA 0-zonen leveres af interface IB0, mens trafikken gennem NUMA 1-zonen håndteres af interface IB1.

Figur 8:  Prøvestandskonfiguration
 

Karakterisering af ydeevne

Dette afsnit præsenterer evalueringen af ydeevnen, der er med til at karakterisere Dell EMC Ready Solution til HPC BeeGFS High-Performance Storage Solution. For yderligere detaljer og opdateringer, se venligst en hvidbog, der vil blive offentliggjort senere. Systemydeevnen blev evalueret ved hjælp af IOzone-benchmarket. Løsningen er testet for sekventiel læse- og skrivehastighed og vilkårlig læse- og skrive-IOPS. Tabel 4 beskriver konfigurationen af de C6420-servere, der blev brugt som BeeGFS-klienter i forbindelse med ydeevneundersøgelserne i denne blog.
 

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 en 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 og 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 poststørrelse på 1 MB 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 og mellem skrive- og læsetest ved at køre kommandoen:

# sync && echo 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. Til 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
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 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 angivet til "Roundrobin" i metadatakonfigurationsfilen 
• tuneNumWorkers Parameteren blev sat til 24 for metadata og 32 for lagring 
• connMaxInternodeNum Parameteren blev indstillet til 32 for metadata og 12 for lagring og 24 for klienter

Figur 9:  Sekventiel IOzone 8TB samlet filstørrelse.

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 lagerserverne 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 otte tråde har vi otte klienter, der skriver otte filer på tværs af 24 mål, hvilket betyder, at ikke alle lagermål bruges 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 udstedes, og den tid, det tager 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 og BeeGFS-klienterne. Kommandoen, der bruges til at udføre tilfældige skrivninger og læsninger, er angivet nedenfor:

Vilkårlig læsning og skrivning: 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 brug af IOzone med en samlet filstørrelse på 8 TB.

De vilkårlige skrivninger topper ved ~3,6 millioner IOPS ved 512 tråde, og de tilfældige læsninger topper ved ~3,5 millioner 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 på over 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 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 metadataydeevnen og N-trådene til en fil-IOR-ydeevne og med yderligere detaljer om designovervejelser, justering og konfiguration.

Referencer

[1] BeeGFS-dokumentation: 
https://www.beegfs.io/wiki/[2] Sådan forbindes to grænseflader på det samme undernet:  https://access.redhat.com/solutions/30564