Zu den Hauptinhalten
  • Bestellungen schnell und einfach aufgeben
  • Bestellungen anzeigen und den Versandstatus verfolgen
  • Profitieren Sie von exklusiven Prämien und Rabatten für Mitglieder
  • Erstellen Sie eine Liste Ihrer Produkte, auf die Sie jederzeit zugreifen können.

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

Zusammenfassung: Referentiearchitectuur voor de oplossing samen met initiële prestatie-evaluatie.

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.

Symptome

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

Ursache

te installeren.

Lösung

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

De huidige HPC-omgevingen hebben hogere eisen gesteld aan zeer snelle storage die ook vaak een 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 gedistribueerd naar meerdere LUN's op verschillende servers.

 

Oplossingsarchitectuur

In deze blog introduceren we de nieuwste toevoeging van Dell EMC aan de PFS-oplossingen (Parallel File System) voor HPC-omgevingen: de Dell EMC Ready oplossing voor HPC PixStor-storage. Afbeelding 1 toont de referentiearchitectuur, die gebruikmaakt van Dell EMC PowerEdge R740 servers en de PowerVault ME4084 en ME4024 storagearrays, met de PixStor-software van ons partnerbedrijf Arcastream.
PixStor omvat het wijdverbreide General Parallel File System, ook wel bekend als Spectrum Scale als de PFS-component, naast Arcastream-softwarecomponenten zoals geavanceerde analyses, vereenvoudigd beheer en monitoring, efficiënt zoeken naar bestanden, geavanceerde gatewaymogelijkheden en vele andere.

SLN318841_en_US__1image (11979)
Figuur 1: Referentiearchitectuur.

 

Onderdelen van de oplossing

Het is de bedoeling dat deze oplossing wordt uitgebracht met de nieuwste Intel Xeon schaalbare Xeon CPU's van de 2e generatie, ook wel Cascade Lake CPU's genoemd, en sommige servers gebruiken het snelste RAM-geheugen dat beschikbaar is (2933 MT/s). Vanwege de hardware die beschikbaar is om prototypes van de oplossing te maken en de prestaties ervan te karakteriseren, zijn servers met Intel Xeon 1e generatie schaalbare Xeon CPU's, ook wel bekend als Er werden Skylake-processors en trager RAM-geheugen gebruikt. Aangezien het knelpunt van de oplossing zich bevindt bij de SAS-controllers van de Dell EMC PowerVault ME40x4 arrays, wordt er geen significant prestatieverschil verwacht zodra de Skylake CPU's en RAM zijn vervangen door de beoogde Cascade Lake CPU's en sneller RAM. Bovendien, zelfs dat de nieuwste versie van PixStor die RHEL 7.6 ondersteunde beschikbaar was op het moment dat het systeem werd geconfigureerd, werd besloten om het QA-proces voort te zetten en Red Hat® Enterprise Linux® 7.5 en de vorige kleine versie van PixStor te gebruiken voor het karakteriseren van het systeem. Zodra het systeem is bijgewerkt naar Cascade Lake CPU's, wordt de PixStor-software ook bijgewerkt naar de nieuwste versie en worden enkele prestatiecontroles steekproefsgewijs uitgevoerd om te controleren of de prestaties binnen de cijfers blijven die in dit document worden vermeld.

Vanwege de eerder beschreven situatie bevat Tabel 1 de lijst met de belangrijkste componenten voor de oplossing. De middelste kolom bevat de geplande componenten die moeten worden gebruikt op het moment van release en dus beschikbaar zijn voor klanten, en de laatste kolom is de componentenlijst die daadwerkelijk wordt gebruikt voor het karakteriseren van de prestaties van de oplossing. De vermelde schijven met data (12 TB NLS) en metadata (960 Gb SSD) worden gebruikt voor prestatie-karakterisering, en snellere schijven kunnen betere willekeurige IOP's bieden en kunnen de bewerkingen voor het maken/verwijderen van metadata verbeteren.

Tot slot is voor de volledigheid de lijst met mogelijke data-HDD's en metadata-SSD's opgenomen, die is gebaseerd op de ondersteunde schijven zoals gespecificeerd op de Dell EMC PowerVault ME4-supportmatrix, die online beschikbaar is.

Tabel 1 Componenten die bij de vrijgave moeten worden gebruikt en componenten die in de testbank worden gebruikt

SLN318841_en_US__2image(12041)
 

Karakterisering van prestaties

Om deze nieuwe Ready Solution te karakteriseren, 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, werden de volgende benchmarks gebruikt:

 
  •     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

    SLN318841_en_US__3image (11984)
    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

    SLN318841_en_US__4image (11985)

    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

    SLN318841_en_US__5image (11987)
    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




    SLN318841_en_US__6image (11988)
    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

    SLN318841_en_US__7image (11989)
    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

     

    SLN318841_en_US__8image (11990)
    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.

    SLN318841_en_US__9image (11993)
    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.

    SLN318841_en_US__10image (11994)
    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.


     

Betroffene Produkte

High Performance Computing Solution Resources, Dell EMC PowerVault ME4012, Dell EMC PowerVault ME4024, Dell EMC PowerVault ME4084
Artikeleigenschaften
Artikelnummer: 000130962
Artikeltyp: Solution
Zuletzt geändert: 23 Sept. 2024
Version:  6
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.