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

Artikel geschreven door Mario Gallegos van HPC en AI Innovation Lab in oktober 2019

Inhoudsopgave

1. Inleiding
   1. Oplossingsarchitectuur
   2. Onderdelen van de oplossing
2. Karakterisering van prestaties
   1. Sequentiële IOzone-prestaties N-clients naar N-bestanden
   2. Sequentiële IOR-prestaties N-clients naar 1 bestand
   3. Willekeurige kleine blokken IOzone Prestaties N clients naar N bestanden
   4. Metadataprestaties met MDtest met lege bestanden
   5. Metadataprestaties met MDtest met 4 KiB-bestanden
   6. Metadataprestaties met MDtest met 3K-bestanden
3. Geavanceerde analyses
4. Conclusies en toekomstig werk

Inleiding

Oplossingsarchitectuur

Onderdelen van de oplossing

Karakterisering van prestaties

•     IOzone N naar N sequentieel
•     IOR N naar 1 sequentieel
•     IOzone willekeurig
•     MDtest
  
  Voor alle hierboven genoemde benchmarks had de testbank de clients zoals beschreven in tabel 2 hieronder. Aangezien het aantal rekenknooppunten dat beschikbaar was voor testen 16 was, werden deze threads, wanneer een hoger aantal threads vereist was, gelijkmatig verdeeld over de rekenknooppunten (d.w.z. 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 groter aantal gelijktijdige clients te simuleren met het beperkte aantal compute nodes. Aangezien de benchmarks een groot aantal threads ondersteunen, werd een maximale waarde van maximaal 1024 gebruikt (gespecificeerd voor elke test), terwijl overmatige contextwisseling en andere gerelateerde bijwerkingen van invloed op de prestatieresultaten werden vermeden.
  
  Tabel 2 Testbank voor clients

  Aantal clientknooppunten	16
  Clientknooppunt	C6320
  Processoren per clientknooppunt	2 x Intel(R) Xeon(R) Gold E5-2697v4 18 cores @ 2,30 GHz
  Geheugen per clientknooppunt	12 x 16 GiB 2400 MT/s RDIMM's
  BIOS	2.8.0
  Kernel van besturingssysteem	3.10.0-957.10.1
  GPFS-versie	5.0.3

   

  ---

  Sequentiële IOzone-prestaties N-clients naar N-bestanden

  De prestaties van sequentiële N-clients naar N-bestanden werden gemeten met IOzone versie 3.487. De uitgevoerde tests varieerden van een enkele thread tot 1024 threads. 
  Caching-effecten werden geminimaliseerd door de GPFS-paginapool afstembaar in te stellen op 16GiB en bestanden te gebruiken die twee keer zo groot waren. Het is belangrijk op te merken dat voor GPFS die afstembaarheid de maximale hoeveelheid geheugen instelt die wordt gebruikt voor het cachen van gegevens, ongeacht de hoeveelheid geïnstalleerd en vrij RAM. Belangrijk om op te merken is ook dat, terwijl in eerdere Dell EMC 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 op de benchmark voor optimale prestaties. Dat lijkt misschien te groot en verspilt blijkbaar te veel ruimte, maar GPFS gebruikt subblock-toewijzing om die situatie te voorkomen. In de huidige configuratie was elk blok onderverdeeld in 256 subblokken van elk 32 KiB. 
  De volgende opdrachten werden gebruikt om de benchmark voor schrijf- en leesbewerkingen uit te voeren, waarbij Threads de variabele was met het aantal gebruikte threads (1 tot 1024 verhoogd in machten van twee), en threadlist het bestand was dat elke thread op een ander knooppunt toewees, met behulp van round robin om ze homogeen te verdelen over de 16 rekenknooppunten.

  ./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 tot N sequentiële prestaties
  
  
  Uit de resultaten kunnen we opmaken dat de prestaties zeer snel toenemen met het aantal gebruikte clients en vervolgens een plateau bereiken dat stabiel is totdat het maximale aantal threads dat IOzone toestaat is bereikt, en daarom zijn de sequentiële prestaties van grote bestanden stabiel, zelfs voor 1024 gelijktijdige clients. Merk op dat de maximale leesprestaties 23 GB/s waren bij 32 threads en dat het knelpunt zeer waarschijnlijk de InfiniBand EDR-interface was, terwijl ME4-arrays nog steeds wat extra prestaties beschikbaar hadden. Merk ook op dat de maximale schrijfprestaties van 16,7 een beetje vroeg werden bereikt op 16 threads en het is blijkbaar laag in vergelijking met de ME4 arrays specs.
  Hier is het belangrijk om te onthouden dat de GPFS-voorkeursmodus verspreid is en dat de oplossing is geformatteerd om deze te gebruiken. In deze modus worden blokken vanaf het begin op een pseudo-willekeurige manier toegewezen, waarbij de gegevens over het hele oppervlak van elke HDD worden verspreid. Hoewel het voor de hand liggende nadeel is dat de initiële maximale prestaties kleiner zijn, blijven die prestaties redelijk constant, ongeacht hoeveel ruimte er op het bestandssysteem wordt gebruikt. Dat in tegenstelling tot andere parallelle bestandssystemen die in eerste instantie de buitenste sporen gebruiken die meer gegevens (sectoren) per schijfomwenteling kunnen bevatten, en daarom de hoogst mogelijke prestaties hebben die de HDD's kunnen leveren, maar naarmate het systeem meer ruimte gebruikt, worden binnenste sporen met minder gegevens per omwenteling gebruikt, met als gevolg een vermindering van de prestaties. 
  
   

  ---

  Sequentiële IOR-prestaties N-clients naar 1 bestand

  De prestaties van sequentiële N-clients naar één gedeeld bestand werden gemeten met IOR versie 3.3.0, bijgestaan door OpenMPI v4.0.1 om de benchmark uit te voeren op de 16 rekenknooppunten. De uitgevoerde tests varieerden van single thread tot 1024 threads.
  Caching-effecten werden geminimaliseerd door de GPFS-paginapool afstembaar in te stellen op 16GiB en bestanden te gebruiken die twee keer zo groot waren. In deze benchmarktests zijn 8 MiB-blokken gebruikt voor optimale prestaties. In het vorige gedeelte over de prestatietest wordt een uitgebreidere uitleg gegeven over die zaken. 
  De volgende opdrachten werden gebruikt om de benchmark voor schrijf- en leesbewerkingen uit te voeren, waarbij Threads de variabele was met het aantal gebruikte threads (1 tot 1024 verhoogd in machten van twee), en my_hosts.$Threads het overeenkomstige bestand is dat elke thread op een ander knooppunt heeft toegewezen, met behulp van round robin om ze homogeen te verdelen over de 16 rekenknooppunten.

  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 op 1 sequentiële prestaties
  
  Uit de resultaten kunnen we opmaken dat de prestaties weer zeer snel toenemen met het aantal gebruikte clients en vervolgens een plateau bereiken dat semi-stabiel is voor leesbewerkingen en zeer stabiel voor schrijfbewerkingen tot aan het maximale aantal threads dat in deze test wordt gebruikt. Daarom zijn de sequentiële prestaties van grote afzonderlijke gedeelde bestanden stabiel, zelfs voor 1024 gelijktijdige clients. Merk op dat de maximale leesprestaties 23,7 GB/s waren bij 16 threads en zeer waarschijnlijk was het knelpunt de InfiniBand EDR-interface, terwijl ME4-arrays nog steeds wat extra prestaties beschikbaar hadden. Bovendien daalden de leesprestaties vanaf die waarde tot het bereiken van het plateau bij ongeveer 20,5 GB/s, met een tijdelijke afname tot 18,5 GB/s bij 128 threads. Merk ook op dat de maximale schrijfprestaties van 16,5 werden bereikt bij 16 threads en dat deze blijkbaar laag is in vergelijking met de specificaties van de ME4-arrays.
   

  ---

  Willekeurige kleine blokken IOzone Prestaties N clients naar N bestanden

  De prestaties van willekeurige N-clients naar N-bestanden werden gemeten met IOzone versie 3.487. De uitgevoerde tests varieerden van single thread tot 1024 threads. In deze benchmarktests zijn 4 KiB-blokken gebruikt voor het emuleren van verkeer met kleine blokken.
  Caching-effecten werden geminimaliseerd door de GPFS-paginapool afstembaar in te stellen op 16GiB en bestanden te gebruiken die twee keer zo groot waren. In het eerste deel van de prestatietest wordt uitgebreider uitgelegd waarom dit effectief is op GPFS. 
  De volgende opdracht werd gebruikt om de benchmark uit te voeren in willekeurige IO-modus voor zowel schrijf- als leesbewerkingen, waarbij Threads de variabele was met het aantal gebruikte threads (1 tot 1024 verhoogd in machten van twee), en threadlist het bestand was dat elke thread op een ander knooppunt toewees, met behulp van round robin om ze homogeen te verdelen over de 16 rekenknooppunten.

  ./iozone -i2 -c -O -w -r 4K -s 32G -t $Threads -+n -+m ./threadlist

  
  Afbeelding 4:  N tot N willekeurige prestaties
  
  Uit de resultaten kunnen we opmaken dat schrijfprestaties beginnen bij een hoge waarde van bijna 8,2K IOPS en gestaag oplopen tot 128 threads waar het een plateau bereikt en dicht bij de maximale waarde van 16,2K IOP's blijft. De leesprestaties beginnen daarentegen zeer klein bij meer dan 200 IOPS en verhogen de prestaties bijna lineair met het aantal gebruikte clients (houd er rekening mee dat het aantal threads voor elk datapunt wordt verdubbeld) en bereikt de maximale prestaties van 20,4K IOPS bij 512 threads zonder tekenen dat het maximum wordt bereikt. Het gebruik van meer threads op de huidige 16 rekenknooppunten met elk twee CPU's en waarbij elke CPU 18 cores heeft, heeft echter de beperking dat er niet genoeg cores zijn om het maximale aantal IOzone-threads (1024) uit te voeren zonder te maken met contextwisseling (16 x 2 x 18 = 576 cores), wat de prestaties aanzienlijk beperkt. Een toekomstige test met meer rekenknooppunten zou kunnen nagaan welke willekeurige leesprestaties kunnen worden bereikt met 1024 threads met IOzone, of IOR zou kunnen worden gebruikt om het gedrag met meer dan 1024 threads te onderzoeken.
  
   

  ---

  Metadataprestaties met MDtest met lege bestanden

  Metadataprestaties werden gemeten met MDtest versie 3.3.0, bijgestaan door OpenMPI v4.0.1 om de benchmark uit te voeren op de 16 rekenknooppunten. De uitgevoerde tests varieerden van single thread tot 512 threads. De benchmark werd alleen gebruikt voor bestanden (geen directory's metadata), het verkrijgen van het aantal creaties, statistieken, leesbewerkingen en verwijderingen dat de oplossing aankan.
  Om de oplossing goed te kunnen vergelijken met andere Dell EMC HPC-storageoplossingen, werd de optionele High Demand Metadata Module gebruikt, maar met een enkele ME4024 array, zelfs de grote configuratie die in dit werk werd getest, was toegewezen aan twee ME4024's. 
  Deze veeleisende metadatamodule ondersteunt maximaal vier ME4024-arrays en er wordt voorgesteld om het aantal ME4024-arrays te verhogen naar 4, voordat u een andere metadatamodule toevoegt. Van extra ME4024-arrays wordt verwacht dat ze de metadataprestaties lineair verhogen bij elke extra array, behalve misschien voor STAT-bewerkingen (en leesbewerkingen voor lege bestanden), aangezien de aantallen erg hoog zijn, zullen de CPU's op een gegeven moment een knelpunt worden en zullen de prestaties niet lineair blijven toenemen.
  De volgende opdracht werd gebruikt om de benchmark uit te voeren, waarbij Threads de variabele was met het aantal gebruikte threads (1 tot 512 verhoogd in machten van twee), en my_hosts.$Threads het corresponderende bestand is dat elke thread op een ander knooppunt heeft toegewezen, met behulp van round robin om ze homogeen over de 16 rekenknooppunten te verspreiden. Net als bij de benchmark voor willekeurige IO was het maximale aantal threads beperkt tot 512, omdat er niet genoeg cores zijn voor 1024 threads en contextwisseling de resultaten zou beïnvloeden, omdat een getal lager zou zijn 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

  
  Aangezien de prestatieresultaten kunnen worden beïnvloed door het totale aantal IOP's, het aantal bestanden per map en het aantal threads, werd besloten om het totale aantal bestanden vast te houden op 2 MiB-bestanden (2^21 = 2097152), het aantal bestanden per map vast te stellen op 1024 en het aantal mappen te variëren naarmate het aantal threads veranderde, zoals weergegeven in tabel 3.
  
  Tabel 3:  MDtest-distributie van bestanden op mappen

  Aantal threads	Aantal mappen 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 logaritmisch was met grondtal 10, om bewerkingen met verschillen van verschillende ordes van grootte te kunnen vergelijken; Anders zouden sommige bewerkingen eruitzien als een vlakke lijn in de buurt van 0 in een normale grafiek. Een loggrafiek met grondtal 2 zou geschikter kunnen zijn, omdat het aantal threads wordt verhoogd in machten van 2, maar de grafiek zou er ongeveer hetzelfde uitzien, en mensen hebben de neiging om betere getallen te hanteren en te onthouden op basis van machten van 10.
  
  
  Het systeem behaalt zeer goede resultaten met stat- en leesbewerkingen die hun piekwaarde bereiken bij 64 threads met respectievelijk 11,2 miljoen op/s en 4,8 miljoen op/s. Verwijderingsbewerkingen bereikten het maximum van 169,4K op/s bij 16 threads en Create-bewerkingen bereikten hun piek bij 512 threads met 194,2K op/s. Statistieken en leesbewerkingen hebben meer variabiliteit, maar zodra ze hun piekwaarde hebben bereikt, dalen de prestaties niet onder 3 miljoen op/s voor statistieken en 2 miljoen bewerkingen voor leesbewerkingen. Maken en Verwijderen zijn stabieler zodra ze een plateau hebben bereikt en blijven boven de 140K op/s voor Verwijdering en 120K op/s voor Maken.
   

  ---

  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 werd gebruikt om de benchmark uit te voeren, waarbij Threads de variabele was met het aantal gebruikte threads (1 tot 512 verhoogd in machten van twee), en my_hosts.$Threads het corresponderende bestand is dat elke thread op een ander knooppunt heeft toegewezen, met behulp van round robin om ze homogeen over de 16 rekenknooppunten 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:  Metadataprestaties - Kleine bestanden (4K)
  
  Het systeem behaalt zeer goede resultaten voor stat- en verwijderingsbewerkingen en bereikt zijn piekwaarde bij 128 threads met respectievelijk 7,7 miljoen op/s en 1 miljoen op/s. Verwijderingsbewerkingen bereikten het maximum van 37,3K op/s en Create-bewerkingen bereikten hun hoogtepunt met 55,5K op/s, beide bij 512 threads. Statistieken en verwijderingsbewerkingen hebben meer variabiliteit, maar zodra ze hun piekwaarde hebben bereikt, dalen de prestaties niet onder de 4 miljoen op/s voor statistieken en 200.000 op/s voor verwijdering. Maken en lezen hebben minder variabiliteit en blijven toenemen naarmate het aantal threads toeneemt.
  Aangezien deze cijfers voor een metadatamodule met één ME4024 zijn, zullen de prestaties toenemen voor elke extra ME4024-arrays, maar we kunnen niet zomaar aannemen dat er voor elke bewerking een lineaire toename is. Tenzij het hele bestand in de inode voor een dergelijk bestand past, worden gegevensdoelen op de ME4084's gebruikt om de 4K-bestanden op te slaan, waardoor de prestaties tot op zekere hoogte worden beperkt. Aangezien de inodegrootte 4 KiB is en er nog steeds metadata moeten worden opgeslagen, passen er alleen bestanden van ongeveer 3 KiB in en elk bestand dat groter is, gebruikt datadoelen.
   

  ---

  Metadataprestaties met MDtest met 3K-bestanden

  Deze test is bijna exact identiek aan de vorige, behalve dat er kleine bestanden van 3KiB zijn gebruikt. Het belangrijkste verschil is dat deze vijlen volledig in de inode passen. Daarom worden de storageknooppunten en hun ME4084's niet gebruikt, wat de algehele snelheid verbetert door alleen SSD-media te gebruiken voor storage en minder netwerktoegang. 
  De volgende opdracht werd gebruikt om de benchmark uit te voeren, waarbij Threads de variabele was met het aantal gebruikte threads (1 tot 512 verhoogd in machten van twee), en my_hosts.$Threads het corresponderende bestand is dat elke thread op een ander knooppunt heeft toegewezen, met behulp van round robin om ze homogeen over de 16 rekenknooppunten 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 3K -e 3K

   

  
  Afbeelding 7: Metadataprestaties - Kleine bestanden (3K)
  
  Het systeem behaalt zeer goede resultaten voor Stat- en Read-bewerkingen en bereikt zijn piekwaarde bij 256 threads met respectievelijk 8,29 M op/s en 5,06 M op/s. Verwijderingsbewerkingen bereikten het maximum van 609K op/s bij 128 threads en Create-bewerkingen bereikten hun hoogtepunt met 78K op/s bij 512 threads. Statistieken en leesbewerkingen hebben meer variabiliteit dan maken en verwijderen. Verwijdering heeft een kleine daling van de prestaties voor de twee hogere threadpunten, wat suggereert dat de aanhoudende prestaties na 128 threads iets meer dan 400K op/s zullen zijn. Het aantal creaties bleef toenemen tot 512 threads, maar het lijkt erop dat het een plateau bereikt, dus de maximale prestaties kunnen nog steeds onder de 100K op/s liggen.
  Aangezien kleine bestanden zoals deze volledig worden opgeslagen op de SSD-gebaseerde metadatamodule, kunnen applicaties die superieure prestaties van kleine bestanden vereisen, een of meer optionele veeleisende metadatamodules gebruiken om de prestaties van kleine bestanden te verbeteren. Vijlen die in de inode passen, zijn echter naar huidige maatstaven klein. Omdat de metadatadoelen RAID1's gebruiken met SSD's die relatief klein zijn (maximale grootte is 19,2 TB), is de capaciteit beperkt in vergelijking met de storageknooppunten. Daarom moet ervoor worden gezorgd dat metadatadoelen niet worden opgevuld, wat onnodige storingen en andere problemen kan veroorzaken.
   

  ---

  Geavanceerde analyses

  Een van de mogelijkheden van PixStor is het bewaken van het bestandssysteem via geavanceerde analytics om het beheer sterk te vereenvoudigen en proactief of reactief problemen of potentiële kwesties op te sporen. Vervolgens zullen we enkele van deze mogelijkheden kort bespreken.
  Afbeelding 8 toont nuttige informatie op basis van de capaciteit van het bestandssysteem. Aan de linkerkant de totale gebruikte ruimte van het bestandssysteem en de top tien gebruikers op basis van de gebruikte capaciteit van het bestandssysteem. Aan de rechterkant een historische weergave met de capaciteit die gedurende vele jaren is gebruikt, vervolgens de top tien van gebruikte bestandstypen en de top tien van bestandssets, beide gebaseerd op de gebruikte capaciteit, in een indeling die vergelijkbaar is met pareto-diagrammen (zonder de lijnen voor cumulatieve totalen). Met deze informatie kan het gemakkelijk zijn om gebruikers te vinden die meer dan hun deel van het bestandssysteem krijgen, trends in capaciteitsgebruik om te helpen bij beslissingen over toekomstige groei van de capaciteit, welke bestanden het grootste deel van de ruimte gebruiken of welke projecten het grootste deel van de capaciteit in beslag nemen.
  
  
  Afbeelding 8:  PixStor Analytics - Capaciteitsweergave
  
  Figuur 9 biedt een weergave van het aantal bestanden met twee zeer nuttige manieren om problemen op te sporen. De eerste helft van het scherm heeft de top tien gebruikers in een cirkeldiagram en top tien bestandstypen en top tien bestandssets (denk aan projecten) in een formaat dat vergelijkbaar is met pareto-diagrammen (zonder de lijnen voor cumulatieve totalen), allemaal gebaseerd op het aantal bestanden. Deze informatie kan worden gebruikt om enkele belangrijke vragen te beantwoorden. Bijvoorbeeld welke gebruikers het bestandssysteem monopoliseren door te veel bestanden te maken, welk type bestand een metadata-nachtmerrie creëert of welke projecten de meeste bronnen gebruiken.
  De onderste helft heeft een histogram met het aantal bestanden (frequentie) voor bestandsgroottes met behulp van 5 categorieën voor verschillende bestandsgroottes. Dit kan worden gebruikt om een idee te krijgen van de bestandsgroottes die in het bestandssysteem worden gebruikt, die kunnen worden gecoördineerd met bestandstypen om te beslissen of compressie nuttig zal zijn.
  
  
  Afbeelding 9:  PixStor Analytics - Weergave aantal bestanden

  
  
   

  ---

  Conclusies en toekomstig werk

  De huidige oplossing leverde vrij goede prestaties, die naar verwachting stabiel zullen zijn, ongeacht de gebruikte ruimte (aangezien het systeem is geformatteerd in verspreide modus), zoals te zien is in tabel 4. Bovendien schaalt de oplossing lineair in capaciteit en prestaties naarmate er meer storageknooppuntmodules worden toegevoegd, en een vergelijkbare prestatieverbetering kan worden verwacht van de optionele veeleisende metadatamodule. Deze oplossing biedt HPC-klanten een zeer betrouwbaar parallel bestandssysteem dat door veel Top 500 HPC-clusters wordt gebruikt. Daarnaast biedt het uitzonderlijke zoekmogelijkheden, geavanceerde bewaking en beheer, en het toevoegen van optionele gateways maakt het delen van bestanden mogelijk via alomtegenwoordige standaardprotocollen zoals NFS, SMB en andere naar zoveel 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	16,7 GB/s	23 GB/s	16,5 GB/s	20,5 GB/s
  Grote sequentiële N-clients naar één gedeeld bestand	16,5 GB/s	23,8 GB/s	16,2 GB/s	20,5 GB/s
  Willekeurige kleine blokken N clients naar N bestanden	15,8 KIOps	20,4 KIOps	15,7 KIOps	20,4 KIOps
  Metadata: Maak lege bestanden	169,4K IOps		127,2K IOps
  Metadata Stat lege bestanden	11,2 miljoen IOps		3,3 miljoen IOps
  Metagegevens Lege bestanden lezen	4,8 miljoen IOps		2,4 miljoen IOps
  Metagegevens Lege bestanden verwijderen	194,2K IOps		144.8K IOps
  Metadata 4KiB-bestanden maken	55.4K IOps		55.4K IOps
  Metadata Stat 4KiB-bestanden	6,4 miljoen IOps		4 miljoen IOps
  Metagegevens 4KiB-bestanden lezen	37.3K IOps		37.3K IOps
  Metadata 4KiB-bestanden verwijderen	1 miljoen IOps		219.500 IOps

  
  
  Aangezien de oplossing bedoeld is om te worden uitgebracht met Cascade Lake CPU's en sneller RAM, zullen enkele prestatiecontroles worden uitgevoerd zodra het systeem de definitieve configuratie heeft. En test de optionele High Demand Metadata Module met ten minste 2x ME4024s- en 4KiB-bestanden die nodig is om beter te documenteren hoe de metadataprestaties worden geschaald wanneer er datadoelen bij betrokken zijn. Daarnaast worden de prestaties voor de gatewayknooppunten gemeten en gerapporteerd, samen met eventuele relevante resultaten van de steekproefsgewijze controles in een nieuwe blog of een whitepaper. Tot slot zijn er meer oplossingscomponenten gepland om te worden getest en uitgebracht om nog meer mogelijkheden te bieden.

  ---