Inhoudsopgave
- Inleiding
- Oplossingsarchitectuur
- Oplossingscomponenten
- Prestatiepersonalisatie
- Sequentiële IOzone Performance N-clients naar N-bestanden
- Sequentiële IOR Performance N-clients naar 1 bestand
- Willekeurige kleine blokken IOzone Performance N-clients naar N-bestanden
- Metadataprestaties met MDtest met lege bestanden
- Metadataprestaties met MDtest met 4 KiB-bestanden
- Conclusies en toekomstig werk
Inleiding
De huidige HPC-omgevingen hebben de vraag naar zeer snelle storage verhoogd die vaak ook hoge capaciteit en gedistribueerde toegang vereist via verschillende standaardprotocollen zoals NFS, SMB en andere. Deze veeleisende HPC-vereisten worden doorgaans gedekt door parallelle bestandssystemen die gelijktijdige toegang bieden tot één bestand of een set bestanden van meerdere knooppunten, waardoor data zeer efficiënt en veilig worden verspreid naar meerdere LUN's over meerdere servers.
Oplossingsarchitectuur
Deze blog is een vervolgoplossing voor Parallel File System (PFS) voor HPC-omgevingen, de DellEMC Ready oplossing voor HPC PixStor Storage, waar PowerVault ME484 EBOD-arrays worden gebruikt om de capaciteit van de oplossing te vergroten. Afbeelding 1 toont de referentiearchitectuur die de sas-toevoegingen van capaciteitsuitbreiding aan de bestaande PowerVault ME4084 storagearrays weergeeft.
De PixStor-oplossing omvat het wijdverbreide General Parallel File System, ook wel spectrumschaal genoemd als pfs-component, naast vele andere Lockerstream-softwarecomponenten zoals geavanceerde analytics, vereenvoudigd beheer en controle, efficiënt zoeken van bestanden, geavanceerde gatewaymogelijkheden en vele andere.
Afbeelding 1: Referentiearchitectuur.
Oplossingscomponenten
Deze oplossing zal naar verwachting worden uitgebracht met de nieuwste Schaalbare Xeon CPU's van de Intel Xeon 2e generatie, ook bekend als Cascade Lake CPU's. Sommige servers gebruiken het snelste RAM-geheugen dat voor hen beschikbaar is (2933 MT/s). Vanwege de huidige hardware die beschikbaar is om te werken aan het prototype van de oplossing om prestaties te kenmerken, servers met Intel Xeon schaalbare Xeon CPU's van de 1e generatie, ook wel bekend als Skylake-processors en in sommige gevallen trager RAM werden gebruikt om dit systeem te kenmerken. Aangezien het knelpunt van de oplossing zich bevindt bij de SAS-controllers van de DellEMC PowerVault ME40x4 arrays, wordt er geen significante prestatiedispariteit verwacht zodra de Skylake CPU's en RAM worden vervangen door de voorgenomen Cascade Lake CPU's en sneller RAM. Bovendien is de oplossing bijgewerkt naar de nieuwste versie van PixStor (5.1.1.4) die RHEL 7.7 en OFED 4.7 ondersteunt voor het karakteriseren van het systeem.
Vanwege de eerder beschreven situatie bevat Tabel 1 de lijst met belangrijkste componenten voor de oplossing, maar wanneer discrepanties zijn geïntroduceerd, bevat de eerste beschrijvingskolom componenten die worden gebruikt op de releasetijd en dus beschikbaar voor klanten, en de laatste kolom zijn de componenten die daadwerkelijk worden gebruikt voor het karakteriseren van de prestaties van de oplossing. De schijven die worden vermeld voor data (12 TB NLS) en metadata (960 Gb SSD), zijn de schijven die worden gebruikt voor prestatie-karakterisering, en snellere schijven kunnen betere random IOP's bieden en kunnen de metadatabewerkingen voor het maken/verwijderen verbeteren.
Ten slotte is, voor volledigheid, de lijst met mogelijke data-HDD's en metadata-SSD's opgenomen, die is gebaseerd op de schijven die worden ondersteund zoals geïnventariseerd in de DellEMC PowerVault ME4 supportmatrix, die online beschikbaar is.
Tabel 1 Componenten die worden gebruikt bij de releasetijd en die in de testbed worden gebruikt
Oplossingscomponent |
Bij release |
Testbed |
Interne connectiviteit |
Dell Networking S3048-ON Gigabit Ethernet |
Datastoragesubsysteem |
1x tot 4x Dell EMC PowerVault ME4084 1 x tot 4 x Dell EMC PowerVault ME484 (één per ME4084) 80 – 12 TB 3,5" NL SAS3 HDD-schijven Opties 900 GB @15K, 1,2 TB @10K, 1,8 TB @10K, 2,4 TB @10K, 4 TB NLS, 8 TB NLS, 10 TB NLS, 12 TB NLS. 8 LUN's, lineair 8+2 RAID 6, segmentgrootte 512KiB. 4 x 1,92 TB SAS3 SSD's voor metadata – 2x RAID 1 (of 4 - algemene HDD-spares, als de optionele High Demand Metadata Module wordt gebruikt) |
Optioneel metadatastoragesubsysteem met hoge vraag |
1x tot 2x Dell EMC PowerVault ME4024 (4x ME4024 indien nodig, alleen grote configuratie) 24 x 960 GB 2,5" SSD SAS3-schijven (opties 480 GB, 960 GB, 1,92 TB) 12 LUN's, lineaire RAID 1. |
RAID-storagecontrollers |
12 Gbps SAS |
Capaciteit zoals geconfigureerd |
Raw: 8064 TB (7334 TiB of 7,16 PiB) geformatteerd ~ 6144 GB (5588 TiB of 5,46 PiB) |
Processor |
Gateway |
2x Intel Xeon Gold 6230 2,1G, 20C/40T, 10,4GT/s, 27,5M cache, Turbo, HT (125 W) DDR4-2933 |
N.v.t. |
Metadata met hoge vraag |
2 x Intel Xeon Gold 6136 bij 3,0 GHz, 12 cores |
Storageknooppunt |
2 x Intel Xeon Gold 6136 bij 3,0 GHz, 12 cores |
Beheerknooppunt |
2x Intel Xeon Gold 5220 2,2 G, 18C/36T, 10,4GT/s, 24,75M cache, Turbo, HT (125 W) DDR4-2666 |
2x Intel Xeon Gold 5118 bij 2,30 GHz, 12 cores |
Geheugen |
Gateway |
12 x 16GiB 2933 MT/s RDIMM's (192 GiB) |
N.v.t. |
Metadata met hoge vraag |
24 x 16GiB 2666 MT/s RDIMM's (384 GiB) |
Storageknooppunt |
24 x 16GiB 2666 MT/s RDIMM's (384 GiB) |
Beheerknooppunt |
12 x 16 GB DIMM's, 2666 MT/s (192GiB) |
12 x 8GiB 2666 MT/s RDIMM's (96 GiB) |
Besturingssysteem |
Red Hat Enterprise Linux 7.6 |
Red Hat Enterprise Linux 7.7 |
Kernelversie |
3.10.0-957.12.2.el7.x86_64 |
3.10.0-1062.9.1.el7.x86_64 |
PixStor-software |
5.1.0.0 |
5.1.1.4 |
Spectrumschaal (GPFS) |
5.0.3 |
5.0.4-2 |
Krachtige netwerkconnectiviteit |
Mellanox ConnectX-5 Dual-Port InfiniBand EDR/100 GbE en 10 GbE |
Mellanox ConnectX-5 InfiniBand EDR |
Switch met hoge prestaties |
2x Mellanox SB7800 (HA – redundant) |
1x Mellanox SB7700 |
OFED-versie |
Mellanox OFED-4.6-1.0.1.0 |
Mellanox OFED-4.7-3.2.9 |
Lokale schijven (OS en analyse/bewaking) |
Alle servers behalve beheerknooppunt 3 x 480 GB SSD SAS3 (RAID1 + HS) voor os PERC H730P RAID-controller Beheerknooppunt 3 x 480 GB SSD SAS3 (RAID1 + HS) voor os PERC H740P RAID-controller |
Alle servers behalve beheerknooppunt 2 x 300 GB 15.000 RPM SAS3 (RAID 1) voor os PERC H330 RAID-controller Beheerknooppunt 5 x 300 GB 15.000 RPM SAS3 (RAID 5) voor besturingssysteem en analyse/bewaking PERC H740P RAID-controller |
Systeembeheer |
iDRAC 9 Enterprise + DellEMC OpenManage |
iDRAC 9 Enterprise + DellEMC OpenManage |
Prestatiepersonalisatie
Om deze nieuwe Ready Oplossing te kenmerken, hebben we de hardware gebruikt die is gespecificeerd in de laatste kolom van Tabel 1, inclusief de optionele High Demand Metadata Module. Om de prestaties van de oplossing te beoordelen, zijn de volgende benchmarks gebruikt:
- IOzone N naar N sequentiële
- IOR N naar 1 sequentiële
- Willekeurige IOzone
- MDtest
Voor alle hierboven genoemde benchmarks bevatte het testbed de clients zoals beschreven in de tabel 2 hieronder. Aangezien het aantal computeknooppunten dat beschikbaar was voor testen slechts 16 was, werden deze threads, wanneer een hoger aantal threads vereist was, gelijk verdeeld over de computeknooppunten (d.w.w. 32 threads = 2 threads per knooppunt, 64 threads = 4 threads per knooppunt, 128 threads = 8 threads per knooppunt, 256 threads =16 threads per knooppunt, 512 threads = 32 threads per knooppunt, 1024 threads = 64 threads per knooppunt). De bedoeling was om een hoger aantal gelijktijdige clients te simuleren met het beperkte aantal computeknooppunten. Aangezien de benchmarks een groot aantal threads ondersteunen, is een maximale waarde tot 1024 gebruikt (gespecificeerd voor elke test), terwijl buitensporige contextwisselingen en andere gerelateerde neveneffecten van invloed zijn op de prestatieresultaten worden vermeden.
Tabel 2 Testbed voor klanten
Aantal clientknooppunten |
16 |
Clientknooppunt |
C6320 |
Processoren per clientknooppunt |
2 x Intel(R) Xeon(R) Gold E5-2697v4 18 cores bij 2,30 GHz |
Geheugen per clientknooppunt |
12 x 16GiB 2400 MT/s RDIMM's |
BIOS |
2.8.0 |
OS-kernel |
3.10.0-957.10.1 |
GPFS-versie |
5.0.3 |
Sequentiële IOzone Performance N-clients naar N-bestanden
Sequentiële N-clients naar N-bestanden werden gemeten met IOzone versie 3.487. De uitgevoerde tests variëren van enkele thread tot 1024 threads en de resultaten van de capaciteitsuitbreidingsoplossing (4x ME4084s + 4x ME484s) staan tegenover de oplossing van grote grootte (4x ME4084s). Cache-effecten zijn geminimaliseerd door de GPFS-paginapool in te stellen op 16GiB en bestanden groter dan twee keer die grootte te gebruiken. Het is belangrijk om te weten dat voor GPFS de maximale hoeveelheid geheugen die wordt gebruikt voor cachedata wordt ingesteld, ongeacht de hoeveelheid RAM die is geïnstalleerd en vrij is. Belangrijk om te weten is ook dat in eerdere DellEMC HPC-oplossingen de blokgrootte voor grote sequentiële overdrachten 1 MiB is, GPFS is geformatteerd met 8 MiB-blokken en daarom wordt die waarde gebruikt in de benchmark voor optimale prestaties. Dat ziet er mogelijk te groot uit en verspilling van te veel ruimte, maar GPFS gebruikt subblocktoewijzing om die situatie te voorkomen. In de huidige configuratie werd elk blok onderverdeeld in 256 subblocks van elk 32 KiB.
De volgende opdrachten werden gebruikt om de benchmark uit te voeren voor schrijf- en leesbewerkingen, waarbij threads de variabele waren met het aantal gebruikte threads (1 tot 1024 verhoogd in vermogens van twee), en threadlist was het bestand waarmee elke thread aan een ander knooppunt werd toegewezen, met behulp van round robin om ze homogene over de 16 computeknooppunten te verspreiden.
./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./iozone -i1 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
Afbeelding 2: N naar N sequentiële prestaties
Uit de resultaten kunnen we zien dat de prestaties zeer snel stijgen met het aantal gebruikte clients en vervolgens een platform bereiken dat stabiel is totdat het maximumaantal threads dat IOzone toestaat is bereikt, en daarom zijn de grote sequentiële bestandsprestaties stabiel, zelfs voor 1024 gelijktijdige clients. Merk op dat zowel lees- als schrijfprestaties profiteerden van de verdubbeling van het aantal schijven. De maximale leesprestaties zijn beperkt door de bandbreedte van de twee IB EDR-koppelingen die worden gebruikt op de storageknooppunten vanaf 8 threads, en ME4-arrays hebben mogelijk wat extra prestaties beschikbaar. Merk ook op dat de maximale schrijfprestaties zijn toegenomen van maximaal 16,7 naar 20,4 GB/s bij 64 en 128 threads en dichter bij de maximale specificaties van de ME4-arrays (22 GB/s).
Hier is het belangrijk om te onthouden dat de GPFS-voorkeursmodus van bewerking verstrooid is en dat de oplossing is geformatteerd om een dergelijke modus te gebruiken. In deze modus worden blokken vanaf het begin van de bewerking op een pseudo-willekeurige manier toegewezen, waarbij data over het hele oppervlak van elke HDD worden verspreid. Hoewel het duidelijke nadeel een kleinere initiële maximale prestaties is, worden die prestaties vrij constant gehouden, ongeacht hoeveel ruimte wordt gebruikt op het bestandssysteem. Dat in tegenstelling tot andere parallelle bestandssystemen die in eerste instantie gebruikmaken van de buitenste tracks die meer data (sectoren) per schijfrevolutie kunnen bevatten en daarom de hoogst mogelijke prestaties leveren die de HDD's kunnen leveren, maar naarmate het systeem meer ruimte gebruikt, worden binnen tracks met minder data per revolutie gebruikt, met als gevolg een vermindering van de prestaties.
Sequentiële IOR Performance N-clients naar 1 bestand
Sequentiële N-clients naar een enkele gedeelde bestandsprestaties werden gemeten met IOR versie 3.3.0, geassisteerd door OpenMPI v4.0.1 om de benchmark uit te voeren over de 16 computeknooppunten. De uitgevoerde tests varieerden van één thread tot 512 threads (omdat er niet genoeg cores waren voor 1024 threads), en de resultaten staan tegenover de oplossing zonder de capaciteitsuitbreiding.
Cache-effecten zijn geminimaliseerd door de GPFS-paginapool in te stellen op 16GiB en bestanden groter dan twee keer die grootte te gebruiken. Deze benchmarktests gebruikten 8 MiB-blokken voor optimale prestaties. Het gedeelte voor de vorige prestatietest bevat een meer volledige verklaring voor deze zaken.
De volgende opdrachten werden gebruikt om de benchmark uit te voeren voor schrijf- en leesbewerkingen, waarbij threads de variabele waren met het aantal gebruikte threads (1 tot 1024 verhoogd in twee vermogens), en my_hosts.$Threads is het bijbehorende bestand dat elke thread toewijst aan een ander knooppunt, met behulp van round robin om ze gelijkmatig over de 16 computeknooppunten te verspreiden.
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b 128G
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --mca btl_openib_allow_ib 1 --mca pml ^ucx --oversubscribe --prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b 128G
Afbeelding 3: N tot 1 sequentiële prestaties
Uit de resultaten kunnen we nogmaals zien dat de extra schijven de lees- en schrijfprestaties ten goede komen. De prestaties nemen weer zeer snel toe met het aantal gebruikte clients en bereikt vervolgens een platform dat vrij stabiel is voor lees- en schrijfbewerkingen tot het maximale aantal threads dat in deze test wordt gebruikt. De maximale leesprestaties waren 24,8 GB/s bij 16 threads en het knelpunt was de InfiniBand EDR-interface, met ME4-arrays hadden nog wat extra prestaties beschikbaar. Vanaf dat punt verlaagden de leesprestaties van die waarde tot het bereiken van het platform ongeveer 23,8 GB/s. Merk ook op dat de maximale schrijfprestaties van 19.3 bij 8 threads zijn bereikt en een platform bereiken.
Willekeurige kleine blokken IOzone Performance N-clients naar N-bestanden
De prestaties van willekeurige N-clients naar N-bestanden werden gemeten met FIO versie 3.7 in plaats van de traditionele Iozone. De bedoeling, zoals vermeld in de vorige blog, was om te profiteren van een grotere wachtrijdiepte om de maximaal mogelijke prestaties te onderzoeken die ME4084 arrays kunnen leveren (uit eerdere tests voor verschillende ME4-oplossingen bleek dat de ME4084 arrays meer I/O-druk nodig hebben die Iozone kan leveren om hun willekeurige I/O-limieten te bereiken).
De uitgevoerde tests varieerden van enkele threads tot 512 threads, omdat er niet genoeg clientcores voor 1024 threads was. Elke thread gebruikte een ander bestand en de threads werden toegewezen round robin aan de clientknooppunten. Deze benchmarktests gebruikten 4 KiB-blokken voor het emuleren van kleine blokken verkeer en het gebruik van een wachtrijdiepte van 16. Resultaten van de oplossing met grote grootte en de capaciteitsuitbreiding worden vergeleken.
Cache-effecten werden opnieuw geminimaliseerd door de GPFS-paginapool in te stellen op 16GiB en bestanden twee keer zo groot te gebruiken. Het eerste gedeelte over prestatietest bevat een meer volledige uitleg over waarom dit effectief is voor GPFS.
Afbeelding 4: N tot N Willekeurige prestaties
Uit de resultaten kunnen we zien dat schrijfprestaties beginnen bij een hoge waarde van 29,1K IOps en geleidelijk toeneemt tot maximaal 64 threads, waarbij het een platform lijkt te bereiken op ongeveer 40K IOps. Leesprestaties daarentegen beginnen bij 1,4K IOps en verhogen de prestaties bijna lineair met het aantal gebruikte clients (houd er rekening mee dat het aantal threads is verdubbeld voor elk datapunt) en bereikt de maximale prestaties van 25,6K IOPS bij 64 threads, waar het lijkt te dicht bij het bereiken van een platform. Het gebruik van meer threads vereist meer dan de 16 computeknooppunten om te voorkomen dat resources verhongeren en een lagere, zichtbare prestaties, waarbij de arrays in feite de prestaties kunnen handhaven.
Metadataprestaties met MDtest met lege bestanden
Metadataprestaties werden gemeten met MDtest versie 3.3.0, geassisteerd door OpenMPI v4.0.1 om de benchmark uit te voeren over de 16 computeknooppunten. Uitgevoerde tests varieerden van enkele thread tot 512 threads. De benchmark is alleen gebruikt voor bestanden (geen metadata van mappen), waarbij het aantal aanmaakten, statistieken, leesbewerkingen en verwijderingen van de oplossing kan worden verwerkt, en de resultaten werden in contrast gebracht met de oplossing met grote grootte.
Om de oplossing correct te evalueren in vergelijking met andere DellEMC HPC-storageoplossingen en de vorige blogresultaten, werd de optionele High Demand Metadata Module gebruikt, maar met een enkele ME4024 array, zelfs dat de grote configuratie en getest in dit werk twee ME4024's hebben. Deze High Demand Metadata Module kan maximaal vier ME4024 arrays ondersteunen en het wordt voorgesteld om het aantal ME4024 arrays te verhogen naar 4, voordat u een andere metadatamodule toevoegt. Extra ME4024-arrays zullen naar verwachting de metadataprestaties lineair verhogen met elke extra array, behalve mogelijk voor Stat-bewerkingen (en Reads voor lege bestanden), omdat de cijfers zeer hoog zijn, zullen de CPU's op een bepaald moment een knelpunt worden en zullen de prestaties niet lineair blijven toenemen.
De volgende opdracht is gebruikt om de benchmark uit te voeren, waarbij threads de variabele was met het aantal gebruikte threads (1 tot 512 verhoogd in de machten van twee), en my_hosts.$Threads is het bijbehorende bestand dat elke thread toewijst aan een ander knooppunt, met behulp van round robin om ze op dezelfde manier over de 16 computeknooppunten te verspreiden. Vergelijkbaar met de Random IO-benchmark, was het maximale aantal threads beperkt tot 512, omdat er niet genoeg cores zijn voor 1024 threads en contextwisseling de resultaten zou beïnvloeden, waardoor een aantal lager wordt gerapporteerd dan de werkelijke prestaties van de oplossing.
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F
Omdat de prestatieresultaten kunnen worden beïnvloed door het totale aantal IOP's, het aantal bestanden per directory en het aantal threads, is besloten om het totale aantal bestanden vast te houden in 2 MiB-bestanden (2^21 = 2097152), het aantal bestanden per map dat is opgelost op 1024 en het aantal directory's varieert naarmate het aantal threads werd gewijzigd, zoals weergegeven in Tabel 3.
Tabel 3: MDtest-distributie van bestanden in mappen
Aantal threads |
Aantal directory's per thread |
Totaal aantal bestanden |
1 |
2048 |
2,097,152 |
2 |
1024 |
2,097,152 |
4 |
512 |
2,097,152 |
8 |
256 |
2,097,152 |
16 |
128 |
2,097,152 |
32 |
64 |
2,097,152 |
64 |
32 |
2,097,152 |
128 |
16 |
2,097,152 |
256 |
8 |
2,097,152 |
512 |
4 |
2,097,152 |
1024 |
2 |
2,097,152 |
Afbeelding 5: Metadataprestaties - lege bestanden
Merk eerst op dat de gekozen schaal logaritair was met basis 10, om bewerkingen met verschillende groottes te kunnen vergelijken; anders zien sommige bewerkingen eruit als een platte lijn dicht bij 0 in een normale grafiek. Een logboekgrafiek met basis 2 kan geschikter zijn, omdat het aantal threads wordt verhoogd in vermogens van 2, maar de grafiek er zeer vergelijkbaar uitziet en mensen de neiging hebben om betere cijfers te verwerken en te onthouden op basis van vermogens van 10.
Het systeem krijgt zeer goede resultaten met Stat- en Read-bewerkingen die hun piekwaarde bereiken op respectievelijk 64 threads met respectievelijk bijna 11M op/s en 4,7M op/s. Verwijderingsbewerkingen bereikten het maximum van 170,6K op/s bij 16 threads en create-bewerkingen bereikten hun piek op 32 threads met 222,1K op/s. Stat- en Read-bewerkingen hebben meer variabiliteit, maar zodra ze hun piekwaarde hebben bereikt, worden de prestaties niet lager dan 3M op/s voor Stats en 2M op/s voor leesbewerkingen. Maken en verwijderen zijn stabieler zodra ze een platform bereiken en hoger blijven dan 140K op/s voor verwijdering en 120K op/s voor create. Let op: de extra schijven hebben geen invloed op de meeste metadatabewerkingen op lege bestanden zoals verwacht.
Metadataprestaties met MDtest met 4 KiB-bestanden
Deze test is bijna identiek aan de vorige, behalve dat in plaats van lege bestanden kleine bestanden van 4KiB werden gebruikt.
De volgende opdracht is gebruikt om de benchmark uit te voeren, waarbij threads de variabele was met het aantal gebruikte threads (1 tot 512 verhoogd in de machten van twee), en my_hosts.$Threads is het bijbehorende bestand dat elke thread toewijst aan een ander knooppunt, met behulp van round robin om ze op dezelfde manier over de 16 computeknooppunten te verspreiden.
mpirun --allow-run-as-root -np $Threads --hostfile my_hosts.$Threads --prefix /mmfs1/perftest/ompi --mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d /mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K
![SLN321192_en_US__6image011](https://supportkb.dell.com/img/ka06P000000cIQcQAM/ka06P000000cIQcQAM_nl_NL_6.jpeg)
Afbeelding 6: Metadata-prestaties - Kleine bestanden (4K)
Het systeem krijgt zeer goede resultaten voor Stat- en verwijderingsbewerkingen die hun piekwaarde bereiken op respectievelijk 256 threads met respectievelijk 8,2 M op/s en 400K op/s. Leesbewerkingen bereikten het maximum van 44,8K op/s en Create-bewerkingen bereikten hun piek met 68,1K op/s, beide bij 512 threads. Stat- en verwijderingsbewerkingen hebben meer variabiliteit, maar zodra ze hun piekwaarde hebben bereikt, worden de prestaties niet lager dan 3M op/s voor Stats en 280K op/s voor verwijdering. Maken en lezen hebben minder variabiliteit en blijven toenemen naarmate het aantal threads toeneemt. Zoals kan worden waargenomen, bieden de extra schijven van de capaciteitsuitbreidingen slechts marginaal wijzigingen in de metadataprestaties.
Aangezien deze cijfers gelden voor een metadatamodule met één ME4024, zullen de prestaties voor elke extra ME4024 arrays toenemen, maar we kunnen niet alleen een lineaire verhoging voor elke bewerking aannemen. Tenzij het hele bestand in de inode voor een dergelijk bestand past, worden datadoelen op de ME4084s gebruikt om de 4K-bestanden op te slaan, waardoor de prestaties tot op zekere hoogte worden beperkt. Aangezien de grootte van de inode 4KiB is en nog steeds metadata moet opslaan, passen alleen bestanden rond 3 KiB in elk bestand dat groter is dan dat datadoelen zal gebruiken.
Conclusies en toekomstig werk
De oplossing met meer capaciteit kon de prestaties verbeteren, niet alleen voor willekeurige toegangen, maar zelfs voor opeenvolgende prestaties. Dat werd verwacht omdat de verstrooide modus zich gedraagt als gerandomiseerde toegangen en het hebben van meer schijven de verbetering mogelijk maakt. Die prestaties, die in tabel 4 kunnen worden weergegeven, zullen naar verwachting stabiel zijn vanaf een leeg bestandssysteem totdat ze bijna vol zijn. Bovendien schaalt de oplossing lineair in capaciteit en prestaties naarmate er meer modules voor storageknooppunten worden toegevoegd, en kan een vergelijkbare prestatieverhoging worden verwacht van de optionele metadatamodule met hoge vraag. Deze oplossing biedt HPC-klanten een zeer betrouwbaar parallel bestandssysteem dat wordt gebruikt door veel Top 500 HPC-clusters. Bovendien biedt het uitzonderlijke zoekmogelijkheden, geavanceerde bewaking en beheer en het toevoegen van optionele gateways maken het delen van bestanden via alomtegenwoordige standaardprotocollen zoals NFS, SMB en andere toe aan zo veel clients als nodig is.
Tabel 4 Piek- en aanhoudende prestaties
|
Topprestaties |
Aanhoudende prestaties |
Schrijven |
Lezen |
Schrijven |
Lezen |
Grote sequentiële N-clients naar N-bestanden |
20,4 GB/s |
24,2 GB/s |
20,3 GB/s |
24 GB/s |
Grote sequentiële N-clients naar één gedeeld bestand |
19,3 GB/s |
24,8 GB/s |
19,3 GB/s |
23,8 GB/s |
Willekeurige kleine blokken N-clients naar N-bestanden |
40KIOps |
25,6KIOps |
40,0KIOps |
19,3KIOps |
Metadata Maak lege bestanden |
169,4K IOps |
123,5K IOps |
Metadata Stat lege bestanden |
11M IOps |
3,2 M IOps |
Metadata Lees lege bestanden |
4,7 M IOps |
2,4 M IOps |
Metadata Lege bestanden verwijderen |
170,6K IOps |
156,5K IOps |
Metadata 4KiB-bestanden maken |
68,1K IOps |
68,1K IOps |
Metadata Stat 4KiB-bestanden |
8,2 M IOps |
3M IOps |
Metadata lezen 4KiB-bestanden |
44,8K IOps |
44,8K IOps |
Metadata 4KiB-bestanden verwijderen |
400K IOps |
280K IOps |
Aangezien de oplossing is bedoeld om te worden vrijgegeven met Cascade Lake CPU's en sneller RAM, worden er, zodra het systeem de definitieve configuratie heeft, enkele prestatiepuntcontroles uitgevoerd. En test de optionele High Demand Metadata Module met ten minste 2x ME4024s- en 4KiB-bestanden om beter te documenteert hoe de metadataprestaties schalen wanneer datadoelen worden betrokken. Bovendien worden de prestaties voor de gatewayknooppunten gemeten en gerapporteerd, samen met eventuele relevante resultaten van de controlepunten in een nieuwe blog of whitepaper. Tot slot zijn er meer oplossingscomponenten gepland om te worden getest en uitgebracht om nog meer mogelijkheden te bieden.