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-färdig lösning för lagring med HPC PixStor

Zusammenfassung: Referensarkitektur för lösningen tillsammans med inledande prestandautvärdering.

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 skriven av Mario Gallegos från HPC och AI Innovation Lab i oktober 2019

Ursache

.

Lösung

Innehållsförteckning

  1. Introduktion
    1. Lösningsarkitektur
    2. Lösningens komponenter
  2. Karakterisering av prestanda
    1. Sekventiell IOzone-prestanda N klienter till N-filer
    2. Sekventiell IOR-prestanda N-klienter till 1 fil
    3. Slumpmässiga små block IOzone Performance N klienter till N filer
    4. Metadataprestanda med MDtest med tomma filer
    5. Metadataprestanda med MDtest med 4 KiB-filer
    6. Metadataprestanda med MDtest med 3K-filer
  3. Avancerad analys
  4. Slutsatser och framtida arbete


 


Introduktion

Dagens HPC-miljöer har ökade krav på lagring med mycket hög hastighet som också ofta kräver hög kapacitet och distribuerad åtkomst via flera standardprotokoll som NFS, SMB med flera. Dessa HPC-krav med höga krav täcks vanligtvis av parallella filsystem som ger samtidig åtkomst till en enda fil eller en uppsättning filer från flera noder, vilket på ett mycket effektivt och säkert sätt distribuerar data till flera LUN över flera servrar.

 

Lösningsarkitektur

I den här bloggen presenterar vi Dell EMC:s senaste tillskott till PFS-lösningar (Parallel File System) för HPC-miljöer, Dell EMC Ready Solution för HPC PixStor-lagring. Bild 1 visar referensarkitekturen, som utnyttjar Dell EMC PowerEdge R740-servrar och PowerVault ME4084- och ME4024-lagringsmatriser, med programvaran PixStor från vårt partnerföretag Arcastream.
PixStor inkluderar det utbredda General Parallel File System, även känt som Spectrum Scale, som PFS-komponenten, förutom Arcastream-mjukvarukomponenter som avancerad analys, förenklad administration och övervakning, effektiv filsökning, avancerade gateway-funktioner och många andra.

SLN318841_en_US__1image(11979)
Figur 1: Referensarkitektur.

 

Lösningens komponenter

Denna lösning är planerad att släppas med de senaste Intel Xeon 2:a generationens skalbara Xeon CPU:er, även kallade Cascade Lake CPU:er och några av servrarna kommer att använda det snabbaste RAM-minnet som är tillgängligt för dem (2933 MT/s). På grund av hårdvaran som finns tillgänglig för att skapa en prototyp av lösningen och karakterisera dess prestanda måste servrar med Intel Xeon 1:a generationens skalbara Xeon-processorer, även kallade Skylake-processorer och långsammare RAM-minne användes. Eftersom flaskhalsen i lösningen finns vid SAS-styrenheterna i Dell EMC PowerVault ME40x4-disksystemen förväntas inga betydande prestandaskillnader när Skylake-processorerna och RAM-minnet har ersatts med de tänkta Cascade Lake-processorerna och snabbare RAM-minne. Dessutom, även om den senaste versionen av PixStor som stödde RHEL 7.6 var tillgänglig vid tidpunkten för konfigurationen av systemet, beslutades det att fortsätta QA-processen och använda Red Hat® Enterprise Linux® 7.5 och den tidigare mindre versionen av PixStor för att karakterisera systemet. När systemet har uppdaterats till Cascade Lake-processorer kommer PixStor-programvaran också att uppdateras till den senaste versionen och vissa prestandakontroller kommer att göras för att verifiera att prestandan förblev stängd för de siffror som rapporteras i detta dokument.

På grund av den tidigare beskrivna situationen innehåller tabell 1 en lista över lösningens huvudkomponenter. Den mellersta kolumnen innehåller de planerade komponenterna som ska användas vid lanseringstillfället och därför är tillgängliga för kunder, och den sista kolumnen är den komponentlista som faktiskt används för att karakterisera lösningens prestanda. De angivna enheterna eller data (12 TB NLS) och metadata (960 Gb SSD) är de som används för prestandakarakterisering, och snabbare enheter kan ge bättre slumpmässiga IOPS och kan förbättra åtgärderna för att skapa/ta bort metadata.

För fullständighetens skull inkluderades slutligen en lista över möjliga data-HDD:er och metadata-SSD:er, vilken baseras på de enheter som stöds enligt specifikationerna i Dell EMC PowerVault ME4-stödmatrisen som finns tillgänglig online.

Tabell 1 Komponenter som ska användas vid frisläppning och de som används i testbädden

SLN318841_en_US__2image(12041)
 

Karakterisering av prestanda

För att karakterisera denna nya Ready Solution använde vi den hårdvara som anges i den sista kolumnen i Tabell 1, inklusive tillvalet High Demand Metadata Module. För att utvärdera lösningens prestanda användes följande prestandatest:

 
  •     IOzon N till N sekventiell
  •     IOR N till 1 sekventiell
  •     IOzone slumpmässigt
  •     MDtest

    För samtliga riktmärken som listas ovan hade testbädden de kunder som beskrivs i tabell 2 nedan. Eftersom antalet beräkningsnoder som var tillgängliga för testning var 16, när ett högre antal trådar krävdes, fördelades dessa trådar jämnt på beräkningsnoderna (dvs. 32 trådar = 2 trådar per nod, 64 trådar = 4 trådar per nod, 128 trådar = 8 trådar per nod, 256 trådar = 16 trådar per nod, 512 trådar = 32 trådar per nod, 1 024 trådar = 64 trådar per nod). Avsikten var att simulera ett högre antal samtidiga klienter med det begränsade antalet beräkningsnoder. Eftersom prestandatesten stöder ett stort antal trådar användes ett maxvärde upp till 1024 (anges för varje test), samtidigt som man undvek överdriven kontextväxling och andra relaterade sidoeffekter från att påverka prestandaresultaten.

    Tabell 2 Testbädd för kunder

    Antal klientnoder

    16

    Klientnod

    C6320

    Processorer per klientnod

    2 x Intel(R) Xeon(R) Gold E5-2697v4, 18 kärnor @ 2,30 GHz

    Minne per klientnod

    12 × 16 GiB 2 400 MT/s RDIMM

    BIOS

    2.8.0

    OS-kärna

    3.10.0-957.10.1

    GPFS-version

    5.0.3

     

    Sekventiell IOzone-prestanda N klienter till N-filer

    Prestanda för sekventiella N-klienter till N-filer mättes med IOzone version 3.487. Testerna som utfördes varierade från en enda tråd upp till 1024 trådar. 
    Cachningseffekterna minimerades genom att ställa in GPFS-sidpoolen som var inställbar till 16GiB och använda filer som var större än två gånger den storleken. Det är viktigt att notera att för GPFS ställer den inställbara in den maximala mängden minne som används för cachelagring av data, oavsett hur mycket RAM-minne som är installerat och ledigt. Det är också viktigt att notera att medan blockstorleken för stora sekventiella överföringar i tidigare Dell EMC HPC-lösningar är 1 MiB, formaterades GPFS med 8 MiB-block och därför används det värdet i prestandatestet för optimal prestanda. Det kan se för stort ut och tydligen slösa för mycket utrymme, men GPFS använder subblockallokering för att förhindra den situationen. I den aktuella konfigurationen var varje block indelat i 256 underblock med 32 KiB vardera. 
    Följande kommandon användes för att köra riktmärket för skrivningar och läsningar, där Threads var variabeln med antalet trådar som användes (1 till 1024 ökat i potenser av två) och threadlist var filen som allokerade varje tråd på en annan nod, med resursallokering för att sprida dem homogent över de 16 beräkningsnoderna.

    ./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)
    Bild 2:  N till n sekventiell prestanda


    Från resultaten kan vi observera att prestandan stiger mycket snabbt med antalet klienter som används och sedan når en platå som är stabil tills det maximala antalet trådar som IOzone tillåter uppnås, och därför är stor filsekventiell prestanda stabil även för 1024 samtidiga klienter. Observera att den maximala läsprestandan var 23 Gbit/s vid 32 trådar och flaskhalsen var troligen InfiniBand EDR-gränssnittet, medan ME4-disksystemen fortfarande hade lite extra prestanda tillgänglig. På samma sätt märker att den maximala skrivprestandan på 16,7 nåddes lite tidigt vid 16 trådar och det är tydligen lågt jämfört med ME4-matrisernas specifikationer.
    Här är det viktigt att komma ihåg att GPFS föredragna driftsätt är utspritt, och lösningen formaterades för att använda det. I det här läget allokeras block från början på ett pseudoslumpmässigt sätt, vilket sprider data över hela ytan på varje hårddisk. Även om den uppenbara nackdelen är en mindre initial maximal prestanda, bibehålls den prestandan ganska konstant oavsett hur mycket utrymme som används i filsystemet. Detta till skillnad från andra parallella filsystem som initialt använder de yttre spåren som kan innehålla mer data (sektorer) per diskvarv och därför har den högsta möjliga prestanda som hårddiskarna kan tillhandahålla, men eftersom systemet använder mer utrymme används inre spår med mindre data per varv, vilket leder till minskad prestanda. 

     

    Sekventiell IOR-prestanda N-klienter till 1 fil

    Prestanda för sekventiella N-klienter till en enda delad fil mättes med IOR version 3.3.0, med hjälp av OpenMPI v4.0.1 för att köra prestandatestet över de 16 beräkningsnoderna. Testerna som utfördes varierade från enkel tråd upp till 1024 trådar.
    Cachningseffekterna minimerades genom att ställa in GPFS-sidpoolen som var inställbar till 16GiB och använda filer som var större än två gånger den storleken. I dessa prestandatest användes 8 MiB-block för optimal prestanda. I det tidigare avsnittet om prestandatest finns en mer fullständig förklaring av dessa frågor. 
    Följande kommandon användes för att köra riktmärket för skrivningar och läsningar, där Threads var variabeln med antalet trådar som användes (1 till 1024 ökat i potenser av två) och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med resursallokering för att sprida dem homogent över de 16 beräkningsnoderna.

    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)

    Bild 3: N till 1 sekventiell prestanda

    Från resultaten kan vi observera att prestandan ökar igen mycket snabbt med antalet klienter som används och sedan når en platå som är halvstabil för läsningar och mycket stabil för skrivningar hela vägen till det maximala antalet trådar som används i det här testet. Därför är sekventiella prestanda för stora enskilda delade filer stabila även för 1024 samtidiga klienter. Observera att den maximala läsprestandan var 23,7 GB/s vid 16 trådar och flaskhalsen var troligen InfiniBand EDR-gränssnittet, medan ME4-disksystemen fortfarande hade lite extra prestanda tillgänglig. Dessutom minskade läsprestandan från det värdet tills den nådde platån vid cirka 20,5 GB/s, med en tillfällig minskning till 18,5 GB/s vid 128 trådar. På samma sätt kan du lägga märke till att den maximala skrivprestandan på 16,5 nåddes vid 16 trådar och att den tydligen är låg jämfört med specifikationerna för ME4-disksystemen.
     

    Slumpmässiga små block IOzone Performance N klienter till N filer

    Prestanda för slumpmässiga N klienter till N-filer mättes med IOzone version 3.487. Testerna som utfördes varierade från enkel tråd upp till 1024 trådar. I det här benchmark-testet användes 4 KiB-block för att emulera trafik med små block.
    Cachningseffekter minimerades genom att ställa in GPFS-sidpoolen som kan ställas in på 16GiB och använda filer som är dubbelt så stora. Det första avsnittet om prestandatest har en mer fullständig förklaring till varför detta är effektivt på GPFS. 
    Följande kommando användes för att köra riktmärket i slumpmässigt I/O-läge för både skrivningar och läsningar, där Threads var variabeln med antalet trådar som användes (1 till 1024 ökat i potenser av två) och threadlist var filen som allokerade varje tråd på en annan nod, med resursallokering för att sprida dem homogent över de 16 beräkningsnoderna.

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

    SLN318841_en_US__5image(11987)
    Bild 4:  N till N Slumpmässig prestanda

    Från resultaten kan vi se att skrivprestandan börjar med ett högt värde på nästan 8,2 K IOPS och stiger stadigt upp till 128 trådar där den når en platå och förblir nära det maximala värdet på 16,2K IOPS. Läsprestanda å andra sidan börjar mycket litet på över 200 IOPS och ökar prestandan nästan linjärt med antalet klienter som används (tänk på att antalet trådar fördubblas för varje datapunkt) och når maximal prestanda på 20,4 K IOPS vid 512 trådar utan tecken på att nå det maximala. Att använda fler trådar på de aktuella 16 beräkningsnoderna med två processorer vardera och där varje processor har 18 kärnor har dock begränsningen att det inte finns tillräckligt med kärnor för att köra det maximala antalet IOzone-trådar (1024) utan att det uppstår kontextväxling (16 x 2 x 18 = 576 kärnor), vilket begränsar prestandan avsevärt. Ett framtida test med fler beräkningsnoder kan kontrollera vilken slumpmässig läsprestanda som kan uppnås med 1024 trådar med IOzone, eller så kan IOR användas för att undersöka beteendet med mer än 1024 trådar.

     

    Metadataprestanda med MDtest med tomma filer

    Metadataprestanda mättes med MDtest version 3.3.0, med hjälp av OpenMPI v4.0.1 för att köra prestandatestet över de 16 beräkningsnoderna. Testerna som utfördes varierade från enkel tråd upp till 512 trådar. Riktmärket användes endast för filer (inga katalogmetadata), vilket ger det antal skapanden, statistik, läsningar och borttagningar som lösningen kan hantera.
    För att utvärdera lösningen ordentligt i jämförelse med andra Dell EMC HPC-lagringslösningar användes tillvalet High Demand Metadata Module som tillval, men med ett enda ME4024-disksystem. Även den stora konfiguration som testades i detta arbete var avsedd att ha två ME4024. 
    Denna efterfrågade metadatamodul har stöd för upp till fyra ME4024-disksystem, och vi rekommenderar att du ökar antalet ME4024-disksystem till 4 innan du lägger till ytterligare en metadatamodul. Ytterligare ME4024-matriser förväntas öka metadataprestandan linjärt med varje ytterligare matris, förutom kanske för Stat-operationer (och läsningar för tomma filer), eftersom siffrorna är mycket höga kommer processorerna vid någon tidpunkt att bli en flaskhals och prestandan kommer inte att fortsätta att öka linjärt.
    Följande kommando användes för att köra prestandatestet, där Threads var variabeln med antalet trådar som användes (1 till 512 ökade i potenser av två) och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med resursallokering för att sprida dem homogent över de 16 beräkningsnoderna. På samma sätt som med det slumpmässiga IO-riktmärket begränsades det maximala antalet trådar till 512, eftersom det inte finns tillräckligt med kärnor för 1024 trådar och kontextväxling skulle påverka resultatet och rapportera ett tal som är lägre än lösningens verkliga prestanda.

    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


    Eftersom prestandaresultaten kan påverkas av det totala antalet IOPS, antalet filer per katalog och antalet trådar, beslutades det att behålla det totala antalet filer till 2 MiB-filer (2^21 = 2097152), antalet filer per katalog som fastställts till 1024 och antalet kataloger varierade när antalet trådar ändrades, vilket visas i tabell 3.

    Tabell 3:  MDtest-distribution av filer på kataloger

    Antal trådar

    Antal kataloger per tråd

    Totalt antal filer

    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)
    Bild 5: Metadataprestanda – tomma filer

    Lägg först märke till att den valda skalan var logaritmisk med basen 10, för att möjliggöra jämförelse av operationer som har skillnader flera storleksordningar; Annars skulle vissa av åtgärderna se ut som en platt linje nära 0 i ett normalt diagram. Ett logaritmiskt diagram med bas 2 kan vara lämpligare, eftersom antalet trådar ökas i potenser av 2, men grafen skulle se ganska likadan ut, och folk tenderar att hantera och komma ihåg bättre siffror baserat på potenser av 10.


    Systemet får mycket bra resultat med Stat- och Read-åtgärder som når sitt toppvärde vid 64 trådar med 11,2 M op/s respektive 4,8 M op/s. Borttagningsåtgärder uppnådde maximalt 169,4 K op/s vid 16 trådar och Create-åtgärder nådde sin topp vid 512 trådar med 194,2 K op/s. Stats- och läsåtgärder har större variabilitet, men när de når sitt högsta värde sjunker prestandan inte under 3 miljoner op/s för statistik och 2 miljoner op/s för läsningar. Skapa och ta bort är mer stabila när de når en platå och förblir över 140 000 op/s för borttagning och 120 000 op/s för att skapa.
     

    Metadataprestanda med MDtest med 4 KiB-filer

    Det här testet är nästan identiskt med det föregående, förutom att små filer med 4KiB användes i stället för tomma filer. 
    Följande kommando användes för att köra prestandatestet, där Threads var variabeln med antalet trådar som användes (1 till 512 ökade i potenser av två) och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med resursallokering för att sprida dem homogent över de 16 beräkningsnoderna.

    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)
    Bild 6:  Metadataprestanda – små filer (4K)

    Systemet får mycket bra resultat för statistik- och borttagningsåtgärder som når sitt toppvärde vid 128 trådar med 7,7 miljoner op/s respektive 1 miljon op/s. Borttagningsåtgärder uppnådde maximalt 37,3 K op/s och Create-åtgärder uppnådde sin topp med 55,5 K op/s, båda vid 512 trådar. Statistik- och borttagningsåtgärder har större variation, men när de når sitt högsta värde sjunker prestandan inte under 4 miljoner op/s för statistik och 200 000 op/s för borttagning. Skapa och läsa har mindre variation och fortsätter att öka i takt med att antalet trådar växer.
    Eftersom dessa siffror är för en metadatamodul med en enda ME4024 kommer prestandan att öka för varje ytterligare ME4024-array, men vi kan inte bara anta en linjär ökning för varje operation. Om inte hela filen får plats inuti inoden för en sådan fil, kommer datamål på ME4084s att användas för att lagra 4K-filerna, vilket begränsar prestandan till viss del. Eftersom inodstorleken är 4KiB och den fortfarande behöver lagra metadata får endast filer runt 3 KiB plats inuti och alla filer som är större än så använder datamål.
     


    Metadataprestanda med MDtest med 3K-filer

    Det här testet är nästan exakt identiskt med de tidigare, förutom att små filer med 3KiB användes. Den största skillnaden är att dessa filer passar helt inuti inoden. Därför används inte lagringsnoderna och deras ME4084s, vilket förbättrar den totala hastigheten genom att endast använda SSD-media för lagring och mindre nätverksåtkomst. 
    Följande kommando användes för att köra prestandatestet, där Threads var variabeln med antalet trådar som användes (1 till 512 ökade i potenser av två) och my_hosts.$Threads är motsvarande fil som allokerade varje tråd på en annan nod, med resursallokering för att sprida dem homogent över de 16 beräkningsnoderna.

    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)
    Bild 7: Metadataprestanda – små filer (3K)

    Systemet får mycket bra resultat för statistik- och läsåtgärder som når sitt högsta värde vid 256 trådar med 8,29 miljoner op/s respektive 5,06 miljoner op/s. Borttagningsåtgärder uppnådde maximalt 609 000 op/s vid 128 trådar och Create-åtgärder nådde sin topp med 78 K op/s vid 512 trådar. Statistik- och läsåtgärder har större variabilitet än Skapa och Ta bort. Borttagningen har en liten minskning av prestanda för de två högre trådpunkterna, vilket tyder på att den varaktiga prestandan efter 128 trådar kommer att vara något över 400 K op/s. Skapar fortsatte att öka upp till 512 trådar, men ser ut att nå en platå så den maximala prestandan kan fortfarande vara under 100K op/s.
    Eftersom små filer som dessa lagras helt på den SSD-baserade metadatamodulen kan program som kräver överlägsen prestanda för små filer använda en eller flera valfria metadatamoduler med hög efterfrågan för att öka prestandan för små filer. Filer som passar i inoden är dock små med nuvarande standarder. Eftersom metadatamålen använder RAID1 med relativt små SSD-enheter (maxstorleken är 19,2 TB) är kapaciteten begränsad jämfört med lagringsnoderna. Därför måste man vara försiktig så att man undviker att fylla upp metadatamål, vilket kan orsaka onödiga fel och andra problem.
     


    Avancerad analys

    Bland PixStors funktioner kan övervakning av filsystemet via avancerad analys vara avgörande för att avsevärt förenkla administrationen, hjälpa till att proaktivt eller reaktivt hitta problem eller potentiella problem. Nu ska vi kort gå igenom några av dessa funktioner.
    I bild 8 visas användbar information baserat på filsystemets kapacitet. På vänster sida visas det totala lagringsutrymmet som används i filsystemet och de tio främsta användarna baserat på den filsystemkapacitet som används. Till höger en historisk vy med kapacitet som använts under många år, sedan de tio främsta filtyperna som används och de tio främsta filuppsättningarna, båda baserade på kapacitet som används, i ett format som liknar paretodiagram (utan raderna för kumulativa summor). Med den här informationen kan det vara enkelt att hitta användare som får mer än sin beskärda del av filsystemet, trender för kapacitetsanvändning för att underlätta beslut om framtida tillväxt för kapacitet, vilka filer som använder det mesta av utrymmet eller vilka projekt som tar det mesta av kapaciteten.

    SLN318841_en_US__9image(11993)
    Bild 8:  PixStor Analytics - Kapacitetsvy

    I bild 9 visas en vy över filantal med två mycket användbara sätt att hitta problem. Den första halvan av skärmen har de tio främsta användarna i ett cirkeldiagram och de tio främsta filtyperna och de tio främsta filmängderna (tänk projekt) i ett format som liknar pareto-diagram (utan raderna för kumulativa summor), allt baserat på antalet filer. Denna information kan användas för att besvara några viktiga frågor. Till exempel vilka användare som monopoliserar filsystemet genom att skapa för många filer, vilken typ av fil som skapar en metadatamardröm eller vilka projekt som använder de flesta resurserna.
    Den nedre halvan har ett histogram med antal filer (frekvens) för filstorlekar med 5 kategorier för olika filstorlekar. Detta kan användas för att få en uppfattning om de filstorlekar som används i filsystemet, vilket koordinerat med filtyper kan användas för att avgöra om komprimering kommer att vara fördelaktigt.

    SLN318841_en_US__10image(11994)
    Bild 9:  PixStor Analytics - Vy över antal filer



     


    Slutsatser och framtida arbete

    Den nuvarande lösningen kunde leverera ganska bra prestanda, som förväntas vara stabil oavsett använt utrymme (eftersom systemet var formaterat i spritt läge), vilket kan ses i tabell 4. Dessutom skalas kapacitet och prestanda linjärt när fler lagringsnodmoduler läggs till, och en liknande prestandaökning kan förväntas från den valfria metadatamodulen med hög efterfrågan. Den här lösningen ger HPC-kunder ett mycket tillförlitligt parallellt filsystem som används av många av de 500 främsta HPC-klustren. Dessutom ger den exceptionella sökfunktioner, avancerad övervakning och hantering, och genom att lägga till valfria gateways kan fildelning via allestädes närvarande standardprotokoll som NFS, SMB och andra till så många klienter som behövs.

    Tabell 4  Topprestanda och bibehållen prestanda

     

     

    Prestanda i toppklass

    Bibehållen prestanda

    Skriva

    Läsa

    Skriva

    Läsa

    Stora sekventiella N-klienter till N-filer

    16,7 GB/s

    23 GB/s

    16,5 GB/s

    20,5 GB/s

    Stora sekventiella N-klienter till en enda delad fil

    16,5 GB/s

    23,8 GB/s

    16,2 GB/s

    20,5 GB/s

    Slumpmässiga små block N klienter till N filer

    15,8 KIOps

    20,4 KIOps

    15,7 KIOps

    20,4 KIOps

    Metadata Skapa tomma filer

    169,4 K IOps

    127,2 K IOps

    Metadata Stat tomma filer

    11,2 miljoner IOps

    3,3 miljoner IOps

    Metadata Läsa tomma filer

    4,8 miljoner IOps

    2,4 miljoner IOps

    Metadata Ta bort tomma filer

    194,2 K IOps

    144,8 K IOps

    Metadata Skapa 4KiB-filer

    55,4 K IOps

    55,4 K IOps

    Metadata Stat 4KiB-filer

    6,4 miljoner IOps

    4 månaders IOps

    Metadata Läsa 4KiB-filer

    37,3 K IOps

    37,3 K IOps

    Metadata: Ta bort 4KiB-filer

    1 miljon IOps

    219,5 K IOps



    Eftersom lösningen är avsedd att släppas med Cascade Lake-processorer och snabbare RAM-minne kommer vissa prestandakontroller att göras när systemet har den slutliga konfigurationen. Och testa den valfria High Demand Metadata Module med minst 2x ME4024s- och 4KiB-filer för att bättre dokumentera hur metadataprestanda skalas när datamål är inblandade. Dessutom kommer prestanda för gatewaynoderna att mätas och rapporteras tillsammans med eventuella relevanta resultat från stickprovskontrollerna i en ny blogg eller ett white paper. Slutligen planeras fler lösningskomponenter att testas och släppas för att ge ännu fler funktioner.


     

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.