Dell EMC-färdig lösning för lagring med HPC PixStor

Artikel skriven av Mario Gallegos från HPC och AI Innovation Lab i oktober 2019

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

Lösningsarkitektur

Lösningens komponenter

Karakterisering av prestanda

•     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

  
  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

  
  
  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

  
  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

  
  
  
  
  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

  
  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

   

  
  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.
  
  
  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.
  
  
  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.

  ---