Dell EMC Ready oplossing voor HPC PixStor-storage - capaciteitsuitbreiding (in het Engels)

Geen

Inhoudsopgave

1. Inleiding
   1. Oplossingsarchitectuur
   2. Oplossingscomponenten
2. Prestatiepersonalisatie
   1. Sequentiële IOzone Performance N-clients naar N-bestanden
   2. Sequentiële IOR Performance N-clients naar 1 bestand
   3. Willekeurige kleine blokken IOzone Performance N-clients naar N-bestanden
   4. Metadataprestaties met MDtest met lege bestanden
   5. Metadataprestaties met MDtest met 4 KiB-bestanden
3. 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

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.