Dell EMC Ready oplossingen voor HPC BeeGFS High Performance Storage (in het Engels)

Artikel geschreven door Nirmala Sundararajan van het Dell EMC HPC en AI Innovation Lab in november 2019

Dell EMC Ready oplossingen voor HPC BeeGFS High Performance Storage (in het Engels)

Inhoudsopgave

1. Inleiding
2. Referentiearchitectuur voor oplossingen
3. Hardware- en softwareconfiguratie
4. Details configuratie oplossing
   • Beheerservice
   • Metadataservice
   • Storage-service
   • Klantenservice
5. R740xd, 24x NVMe-schijven, details over CPU-toewijzing
6. Karakterisering van prestaties
   • Sequentieel lezen en schrijven N-N
   • Willekeurige lees- en schrijfbewerkingen N-N
7. Conclusie en toekomstig werk
    

Inleiding

Referentiearchitectuur voor oplossingen

Hardware- en softwareconfiguratie

Tabel 1 en 2 beschrijven de hardwarespecificaties van respectievelijk de beheerserver en de metadata-/storageserver. Tabel 3 beschrijft de softwareversies die voor de oplossing worden gebruikt.

Details configuratie oplossing

• Beheerservice
• Metadataservice
• Storage-service
• Klantenservice

Beheerservice

Metadataservice

Afbeelding 3:  Metadataserver

Afbeelding 4 toont de RAID-configuratie van de metadataserver. Het laat zien hoe in de metadataserver de stations in de NUMA-zone 0 de MDT's hosten en die in NUMA-zone 1 de opslaggegevens, terwijl de opslagservers de ST's hosten in beide NUMA-zones.

Storage-service

1. Schrijfprestaties werden gemeten met behulp van de dd-opdracht door een 10 GiB-bestand te maken met een blokgrootte van 1 MiB en directe I/O voor data. Voor RAID 0-apparaten was het gemiddelde ongeveer 5,1 GB/s voor elk apparaat, terwijl voor RAID 10-apparaten het gemiddelde 3,4 GB/s voor elk apparaat was.
2. Benchmarktests van StorageBench toonden aan dat de maximale doorvoer 5,5 GB/s was voor een RAID 0-configuratie, terwijl dit 3,4 GB/s is voor een RAID 10-configuratie. Deze resultaten zijn vergelijkbaar met wat werd verkregen met behulp van dd-opdrachten.
3. RAID 10 biedt 50% gebruik van de schijfcapaciteit en een vergelijkbare vermindering van 50% in schrijfprestaties. Het gebruik van RAID 10 is een dure manier om storageredundantie te verkrijgen.
4. NVMe-schijven zijn duur en bieden versnellingen die het beste kunnen worden gebruikt in een RAID 0-configuratie

Klantenservice

$ 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-schijven, details over CPU-toewijzing

# cat /proc/sys/kernel/numa_balancing
0

Karakterisering van prestaties

Sequentieel schrijven en lezen N-N

Om sequentiële lees- en schrijfbewerkingen te evalueren, werd de IOzone-benchmark gebruikt in de sequentiële lees- en schrijfmodus. Deze tests werden uitgevoerd op meerdere threadtellingen, beginnend bij 1 thread en oplopend in machten van 2, tot 1024 threads. Bij elk aantal threads is een gelijk aantal bestanden gegenereerd, aangezien deze test werkt op één bestand per thread of in het geval van N-N-bestand van N-clients naar N-bestand. De processen werden op een round robin of cyclische manier verdeeld over 32 fysieke client nodes, zodat de aanvragen gelijkmatig verdeeld zijn en er sprake is van load balancing. Er is een totale bestandsgrootte van 8 TB geselecteerd, die gelijkmatig is verdeeld over het aantal threads binnen een bepaalde test. De totale bestandsgrootte is groot genoeg gekozen om de effecten van caching van zowel de servers als van BeeGFS-clients te minimaliseren. IOzone werd uitgevoerd in een gecombineerde schrijfmodus en vervolgens lezen (-i 0, -i 1) om het mogelijk te maken de grenzen tussen de bewerkingen te coördineren. Voor deze tests en resultaten hebben we voor elke run een recordgrootte van 1MiB gebruikt. De opdrachten die worden gebruikt voor sequentiële N-N-tests worden hieronder gegeven:

Sequentiële schrijf- en leesbewerkingen: iozone -i 0 -i 1 -c -e -w -r 1m -i -s $Size -t $Thread -+n -+m /path/to/threadlist

OS-caches werden ook verwijderd of opgeschoond op de clientknooppunten tussen iteraties en tussen schrijf- en leestests door de volgende opdracht uit te voeren:

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

Het standaard aantal strepen voor Beegfs is 4. De grootte van de brokken en het aantal doelen per bestand kunnen echter per map worden geconfigureerd. Voor al deze tests is de BeeGFS-stripegrootte gekozen op 2 MB en het aantal strepen op 3, omdat we drie doelen per NUMA-zone hebben, zoals hieronder weergegeven:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
De details van het streeppatroon:
+ Type: RAID0
+ Chunksize: 2M
+ Aantal storagedoelen: gewenst:
3 okt.+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

De transparante enorme pagina's zijn uitgeschakeld en de volgende afstemmingsopties zijn aanwezig op de metadata- en opslagservers:

• 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

Naast het bovenstaande zijn de volgende BeeGFS-tuningopties gebruikt: 

• De parameter tuneTargetChooser is ingesteld op "roundrobin" in het metadataconfiguratiebestand 
• De parameter tuneNumWorkers is ingesteld op 24 voor metadata en 32 voor storage 
• De parameter connMaxInternodeNum is ingesteld op 32 voor metagegevens en 12 voor opslag en 24 voor clients

In afbeelding 9 zien we dat de maximale leesprestaties 132 GB/s zijn bij 1024 threads en de maximale schrijfprestaties 121 GB/s bij 256 threads. Elke schijf kan 3,2 GB/s piekleesprestaties en 1,3 GB/s piekschrijfprestaties leveren, wat een theoretische piek van 422 GB/s voor leesbewerkingen en 172 GB/s voor schrijfbewerkingen mogelijk maakt. Hier is het netwerk echter de beperkende factor. We hebben in totaal 11 InfiniBand EDR-koppelingen voor de storageservers in de set-up. Elke koppeling kan een theoretische piekprestatie leveren van 12,4 GB/s, wat een theoretische piekprestatie van 136,4 GB/s mogelijk maakt. De maximale lees- en schrijfprestaties zijn respectievelijk 97% en 89% van de theoretische piekprestaties.

De schrijfprestaties van de single-thread zijn ~3 GB/s en worden gelezen met ~3 GB/s. We zien dat de schrijfprestaties lineair schaalt, piekt bij 256 threads en vervolgens begint af te nemen. Bij lagere aantallen threads zijn de lees- en schrijfprestaties hetzelfde. Omdat we tot 8 threads 8 clients hebben die 8 bestanden schrijven voor 24 doelen, wat betekent dat niet alle storagedoelen volledig worden benut. Het systeem heeft 33 storagedoelen en daarom zijn er minstens 11 threads nodig om alle servers volledig te benutten. De leesprestaties vertonen een gestage lineaire toename met de toename van het aantal gelijktijdige threads en we zien bijna vergelijkbare prestaties bij 512 en 1024 threads.

We zien ook dat de leesprestaties lager zijn dan schrijfbewerkingen voor threadtellingen van 16 tot 128 en dat de leesprestaties vervolgens beginnen te schalen. Dit komt omdat, terwijl een PCIe-leesbewerking een niet-geboekte bewerking is, die zowel een aanvraag als een voltooiing vereist, een PCIe-schrijfbewerking een fire and forget-bewerking is. Zodra het Transaction Layer Packet is overgedragen aan de Data Link Layer, is de bewerking voltooid. Een schrijfbewerking is een "Geboekte" bewerking die alleen uit een aanvraag bestaat.

De leesdoorvoer is doorgaans lager dan de schrijfdoorvoer, omdat voor leesbewerkingen twee transacties nodig zijn in plaats van één schrijfbewerking voor dezelfde hoeveelheid data. PCI Express gebruikt een gesplitst transactiemodel voor leesbewerkingen. De leestransactie omvat de volgende stappen:

• De aanvrager verzendt een Memory Read Request (MRR).
• De completer stuurt de bevestiging naar MRR.
• De voltooiing retourneert een Voltooiing met gegevens.

De leesdoorvoer is afhankelijk van de vertraging tussen het moment waarop de leesaanvraag wordt uitgevoerd en de tijd die de completer nodig heeft om de gegevens te retourneren. Wanneer de applicatie echter voldoende leesverzoeken geeft om deze vertraging te dekken, wordt de doorvoer gemaximaliseerd. Dat is de reden waarom, hoewel de leesprestaties minder zijn dan die van de schrijfbewerkingen van 16 threads naar 128 threads, we een verhoogde doorvoer meten wanneer het aantal aanvragen toeneemt.  Een lagere doorvoer wordt gemeten wanneer de aanvrager wacht op voltooiing voordat volgende aanvragen worden ingediend. Een hogere doorvoersnelheid wordt geregistreerd wanneer er meerdere aanvragen worden gedaan om de vertraging af te schrijven nadat de eerste data zijn geretourneerd.

Willekeurige schrijf- en leesbewerkingen N-N

Om de willekeurige IO-prestaties te evalueren, werd IOzone gebruikt in de willekeurige modus. Er werden tests uitgevoerd op het aantal threads vanaf 4 threads tot maximaal 1024 threads. De directe IO-optie (-I) werd gebruikt om IOzone uit te voeren, zodat alle bewerkingen de buffercache omzeilen en rechtstreeks naar de schijf gaan. Er werd een aantal BeeGFS-strepen van 3 en een brokgrootte van 2 MB gebruikt. Een aanvraaggrootte van 4KB wordt gebruikt op IOzone. De prestaties worden gemeten in I/O-bewerkingen per seconde (IOPS). De OS-caches werden gedropt tussen de runs op de BeeGFS-servers en BeeGFS-clients. De opdracht die wordt gebruikt voor het uitvoeren van de willekeurige schrijf- en leesbewerkingen wordt hieronder gegeven:

Willekeurige lees- en schrijfbewerkingen: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Afbeelding 10:  Willekeurige lees- en schrijfprestaties met behulp van IOzone met een totale bestandsgrootte

van 8 TB De willekeurige schrijfbewerkingen pieken bij ~3,6 miljoen IOPS bij 512 threads en de willekeurige leesbewerkingen pieken bij ~3,5 miljoen IOPS bij 1024 threads, zoals weergegeven in afbeelding 10. Zowel de schrijf- als de leesprestaties laten hogere prestaties zien wanneer er een hoger aantal IO-aanvragen is. Dit komt omdat NVMe standaard tot 64K I/O-wachtrij en tot 64K opdrachten per wachtrij ondersteunt. Deze grote groep NVMe-wachtrijen biedt hogere niveaus van I/O-parallellisme en daarom zien we IOPS van meer dan 3 miljoen.

Conclusie en toekomstig werk

In deze blog wordt de release van de Dell EMC High Performance BeeGFS storageoplossing aangekondigd en worden de prestatiekenmerken ervan belicht. De oplossing heeft een piek sequentiële lees- en schrijfprestaties van respectievelijk ~132 GB/s en ~121 GB/s en de willekeurige schrijfbewerkingen pieken bij ~3,6 miljoen IOPS en willekeurige leesbewerkingen bij ~3,5 miljoen IOPS.

Deze blog is deel één van "BeeGFS Storage Solution" die is ontworpen met een focus op scratch space met hoge prestaties. Deel 2 van de blogserie waarin wordt beschreven hoe de oplossing kan worden geschaald door het aantal servers te verhogen om de prestaties en capaciteit te verhogen. In deel 3 van de blogserie worden extra functies van BeeGFS besproken en wordt het gebruik van StorageBench, de benchmark voor ingebouwde storagedoelen van BeeGFS, belicht.

Als onderdeel van de volgende stappen zullen we later een whitepaper publiceren met de metadataprestaties en de prestaties van de N-threads naar 1-bestand IOR-bestand en met aanvullende details over ontwerpoverwegingen, afstemming en configuratie.

Verwijzingen