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 Solution per HPC nello storage PixStor (in inglese)

Zusammenfassung: Architettura di riferimento per la soluzione insieme alla valutazione iniziale delle prestazioni.

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

Articolo scritto da Mario Gallegos di HPC and AI Innovation Lab nel mese di ottobre 2019

Ursache

.

Lösung

Sommario

  1. Introduzione
    1. Architettura della soluzione
    2. Componenti della soluzione
  2. Caratterizzazione delle prestazioni
    1. Prestazioni IOzone sequenziali da N client a N file
    2. Prestazioni IOR sequenziali da N client a 1 file
    3. Prestazioni IOzone per piccoli blocchi casuali da N client a N file
    4. Prestazioni dei metadati con MDtest utilizzando file vuoti
    5. Prestazioni dei metadati con MDtest con file da 4 KiB
    6. Prestazioni dei metadati utilizzando MDtest con file 3K
  3. Advanced Analytics
  4. Conclusioni e lavoro futuro


 


Introduzione

Gli ambienti HPC odierni hanno aumentato la domanda di storage ad altissima velocità che spesso richiede anche capacità elevata e accesso distribuito tramite diversi protocolli standard come NFS, SMB e altri. Questi requisiti HPC high-demand sono in genere coperti da file system paralleli che forniscono l'accesso simultaneo a un singolo file o a un set di file da più nodi, distribuendo in modo molto efficiente e sicuro i dati su più LUN di più server.

 

Architettura della soluzione

In questo blog presentiamo l'ultima aggiunta di Dell EMC alle soluzioni Parallel File System (PFS) per ambienti HPC: Dell EMC Ready Solution for HPC PixStor Storage. La Figura 1 presenta l'architettura di riferimento, che sfrutta i server Dell EMC PowerEdge R740 e gli array di storage PowerVault ME4084 e ME4024 con il software PixStor della nostra azienda partner Arcastream.
PixStor include il diffuso General Parallel File System, noto anche come Spectrum Scale, come componente PFS, oltre a componenti software Arcastream come analisi avanzata, amministrazione e monitoraggio semplificati, ricerca efficiente di file, funzionalità avanzate di gateway e molti altri.

SLN318841_en_US__1image(11979)
Figura 1: Architettura di riferimento.

 

Componenti della soluzione

Questa soluzione è prevista per il rilascio con le più recenti CPU Xeon scalabili Intel Xeon di seconda generazione, ovvero CPU Cascade Lake e alcuni server utilizzeranno la RAM più veloce disponibile (2.933 MT/s). Tuttavia, a causa dell hardware disponibile per prototipare la soluzione e caratterizzarne le prestazioni, i server con CPU Intel Xeon scalabili di prima generazione, ovvero Sono stati utilizzati processori Skylake e RAM più lenta. Poiché il collo di bottiglia della soluzione è nei controller SAS degli array Dell EMC PowerVault ME40x4, non è prevista alcuna disparità significativa di prestazioni una volta sostituite le CPU e la RAM Skylake con le CPU Cascade Lake e la RAM più veloce. Inoltre, anche se al momento della configurazione del sistema era disponibile l'ultima versione di PixStor che supportava RHEL 7.6, si è deciso di continuare il processo di controllo qualità e di utilizzare Red Hat® Enterprise Linux® 7.5 e la precedente versione secondaria di PixStor per caratterizzare il sistema. Una volta che il sistema viene aggiornato alle CPU Cascade Lake, anche il software PixStor verrà aggiornato alla versione più recente e verranno eseguiti alcuni controlli a campione delle prestazioni per verificare che le prestazioni rimangano vicine ai valori riportati in questo documento.

A causa della situazione descritta in precedenza, nella tabella 1 è riportato l'elenco dei componenti principali della soluzione. La colonna centrale contiene i componenti pianificati da utilizzare al momento del rilascio e quindi disponibili per i clienti, e l'ultima colonna è l'elenco dei componenti effettivamente utilizzati per caratterizzare le prestazioni della soluzione. Le unità o i dati (NLS da 12 TB) e i metadati (SSD da 960 Gb) elencati sono quelli utilizzati per la caratterizzazione delle prestazioni e le unità più veloci possono fornire IOPS casuali migliori e possono migliorare le operazioni di creazione/rimozione dei metadati.

Infine, per completezza, è stato incluso l'elenco dei possibili HDD di dati e SSD di metadati, basato sulle unità supportate come specificato nella Support Matrix di Dell EMC PowerVault ME4, disponibile online.

Tabella 1 Componenti da utilizzare al momento del rilascio e quelli utilizzati nel banco di prova

SLN318841_en_US__2image(12041)
 

Caratterizzazione delle prestazioni

Per caratterizzare questa nuova Ready Solution, abbiamo utilizzato l'hardware specificato nell'ultima colonna della Tabella 1, incluso il modulo opzionale High Demand Metadata Module. Per valutare le prestazioni della soluzione, sono stati utilizzati i seguenti benchmark:

 
  •     IOzone sequenziale da N a N
  •     IOR sequenziale da N a 1
  •     IOzone casuale
  •     MDtest

    Per tutti i benchmark elencati in precedenza, il banco di prova aveva i client come descritto nella Tabella 2 riportata di seguito. Poiché il numero di nodi di calcolo disponibili per il test era 16, quando era necessario un numero maggiore di thread, tali thread erano distribuiti equamente sui nodi di calcolo (ad esempio, 32 thread = 2 thread per nodo, 64 thread = 4 thread per nodo, 128 thread = 8 thread per nodo, 256 thread =16 thread per nodo, 512 thread = 32 thread per nodo, 1024 thread = 64 thread per nodo). L'intenzione era quella di simulare un numero più elevato di client simultanei con il numero limitato di nodi di elaborazione. Poiché i benchmark supportano un numero elevato di thread, è stato utilizzato un valore massimo fino a 1024 (specificato per ogni test), evitando al contempo un eccessivo cambio di contesto e altri effetti collaterali correlati che influiscano sui risultati delle prestazioni.

    Tabella 2 Banco di prova del cliente

    Numero di nodi client

    16

    Nodo client

    C6320

    Processori per nodo client

    2 Intel(R) Xeon(R) Gold E5-2697v4 18 core a 2,3 GHz

    Memoria per nodo client

    12 RDIMM da 16 GiB e 2.400 MT/s

    BIOS

    2.8.0

    OS Kernel

    3.10.0-957.10.1

    Versione di GPFS

    5.0.3

     

    Prestazioni IOzone sequenziali da N client a N file

    Le prestazioni sequenziali da N client a N file sono state misurate con IOzone versione 3.487. I test eseguiti variavano da un singolo thread fino a 1024 thread. 
    Gli effetti di memorizzazione nella cache sono stati ridotti al minimo impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando file di dimensioni due volte superiori. È importante notare che per GPFS tale tunable imposta la quantità massima di memoria utilizzata per la memorizzazione nella cache dei dati, indipendentemente dalla quantità di RAM installata e libera. Inoltre, è importante notare che, mentre nelle precedenti soluzioni HPC Dell EMC la dimensione dei blocchi per i trasferimenti sequenziali di grandi dimensioni era di 1 MiB, GPFS era formattato con blocchi di 8 MiB e quindi tale valore viene utilizzato nel benchmark per ottenere prestazioni ottimali. Potrebbe sembrare troppo grande e apparire come un eccessivo spreco di spazio, ma GPFS utilizza l'allocazione dei sottoblocchi per evitare questa situazione. Nella configurazione corrente, ogni blocco era suddiviso in 256 sottoblocchi da 32 KiB ciascuno. 
    I comandi seguenti sono stati usati per eseguire il benchmark per scritture e letture, dove Threads era la variabile con il numero di thread usati (da 1 a 1024 incrementati in potenze di due) e threadlist era il file che allocava ogni thread in un nodo diverso, usando round robin per distribuirli in modo omogeneo tra i 16 nodi di calcolo.

    ./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)
    Figura 2.  Prestazioni


    sequenziali da N a N
    Dai risultati possiamo osservare che le prestazioni aumentano molto velocemente con il numero di client utilizzati e quindi raggiungono un plateau stabile fino a raggiungere il numero massimo di thread consentiti da IOzone, e quindi le prestazioni sequenziali dei file di grandi dimensioni sono stabili anche per 1024 client simultanei. Si noti che le massime prestazioni di lettura erano di 23 GB/s a 32 thread e molto probabilmente il collo di bottiglia era l'interfaccia EDR InfiniBand, mentre gli array ME4 avevano ancora alcune prestazioni aggiuntive disponibili. Allo stesso modo, si noti che le massime prestazioni di scrittura di 16,7 sono state raggiunte un po' presto a 16 thread ed è apparentemente bassa rispetto alle specifiche degli array ME4.
    In questo caso è importante ricordare che la modalità di funzionamento preferita di GPFS è distribuita e che la soluzione è stata formattata per utilizzarla. In questa modalità, i blocchi vengono allocati fin dall'inizio in modo pseudo-casuale, distribuendo i dati sull'intera superficie di ciascun HDD. Sebbene l'ovvio svantaggio sia una riduzione delle prestazioni massime iniziali, tali prestazioni vengono mantenute piuttosto costanti indipendentemente dalla quantità di spazio utilizzato nel file system. Quindi, a differenza di altri file system paralleli che inizialmente utilizzano le tracce esterne in grado di contenere più dati (settori) per rivoluzione del disco e pertanto hanno le massime prestazioni possibili che gli HDD possono fornire, a mano a mano che il sistema utilizza più spazio, vengono utilizzate tracce interne con meno dati per rivoluzione, con la conseguente riduzione delle prestazioni. 

     

    Prestazioni IOR sequenziali da N client a 1 file

    Le sequenziali da N client a un singolo file condiviso sono state misurate con IOR versione 3.3.0, assistita da OpenMPI v4.0.1, per eseguire il benchmark sui 16 nodi di elaborazione. I test eseguiti variavano da un singolo thread fino a 1024 thread.
    Gli effetti di memorizzazione nella cache sono stati ridotti al minimo impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando file di dimensioni due volte superiori. Questo test di benchmark ha utilizzato block da 8 MiB per prestazioni ottimali. La precedente sezione relativa al test delle prestazioni fornisce una spiegazione più completa di tali questioni. 
    I seguenti comandi sono stati usati per eseguire il benchmark per scritture e letture, dove Threads era la variabile con il numero di thread usati (da 1 a 1024 incrementati in potenze di due) e my_hosts.$Threads è il file corrispondente che ha allocato ogni thread in un nodo diverso, usando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di calcolo.

    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)

    Figura 3. Prestazioni

    sequenziali da N a 1 Dai risultati possiamo osservare che le prestazioni aumentano di nuovo molto velocemente con il numero di client utilizzati e quindi raggiungono un plateau che è semi-stabile per le letture e molto stabile per le scritture, fino al numero massimo di thread utilizzati in questo test. Pertanto, le prestazioni sequenziali di un singolo file condiviso di grandi dimensioni sono stabili anche per 1.024 client simultanei. Si noti che le massime prestazioni di lettura erano di 23,7 GB/s a 16 thread e molto probabilmente il collo di bottiglia era l'interfaccia EDR InfiniBand, mentre gli array ME4 avevano ancora alcune prestazioni aggiuntive disponibili. Inoltre, le prestazioni di lettura sono diminuite da tale valore fino a raggiungere il plateau a circa 20,5 GB/s, con una diminuzione momentanea a 18,5 GB/s a 128 thread. Allo stesso modo, si noti che le massime prestazioni di scrittura di 16,5 sono state raggiunte a 16 thread e sono apparentemente basse rispetto alle specifiche degli array ME4.
     

    Prestazioni IOzone per piccoli blocchi casuali da N client a N file

    Le prestazioni da N client casuali a N file sono state misurate con IOzone versione 3.487. I test eseguiti variavano da un singolo thread fino a 1024 thread. Questo test di benchmark ha utilizzato blocchi da 4 KiB per emulare il traffico di blocchi di piccole dimensioni.
    Gli effetti di memorizzazione nella cache sono stati ridotti al minimo impostando il pool di pagine GPFS regolabile su 16 GiB e utilizzando file di dimensioni due volte superiori. La prima sezione del test delle prestazioni ha una spiegazione più completa del motivo per cui questo è efficace su GPFS. 
    Il comando seguente è stato utilizzato per eseguire il benchmark in modalità I/O casuale sia per le scritture che per le letture, dove Threads era la variabile con il numero di thread usati (da 1 a 1024 incrementati in potenze di due) e threadlist era il file che allocava ogni thread in un nodo diverso, usando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di calcolo.

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

    SLN318841_en_US__5image(11987)
    Figura 4.  Prestazioni

    casuali da N a N Dai risultati si può osservare che le prestazioni di scrittura partono da un valore elevato di quasi 8.200 IOPS e aumentano costantemente fino a 128 thread, dove raggiungono un plateau e rimangono vicine al valore massimo di 16.200 IOPS. Le prestazioni di lettura, d'altra parte, partono da dimensioni molto ridotte a oltre 200 IOPS e aumentano quasi linearmente con il numero di client utilizzati (tenere presente che il numero di thread viene raddoppiato per ogni data point) e raggiungono le prestazioni massime di 20,4K IOPS a 512 thread senza segni di raggiungere il massimo. Tuttavia, l'utilizzo di più thread sui 16 nodi di calcolo correnti con due CPU ciascuno e in cui ogni CPU ha 18 core, presenta la limitazione che non sono presenti core sufficienti per eseguire il numero massimo di thread IOzone (1024) senza incorrere nel cambio di contesto (16 x 2 x 18 = 576 core), il che limita notevolmente le prestazioni. Un test futuro con più nodi di calcolo potrebbe verificare le prestazioni di lettura casuale che è possibile ottenere con 1024 thread con IOzone, oppure IOR potrebbe essere utilizzato per analizzare il comportamento con più di 1024 thread.

     

    Prestazioni dei metadati con MDtest utilizzando file vuoti

    Le prestazioni dei metadati sono state misurate con MDtest versione 3.3.0, assistita da OpenMPI v4.0.1, per eseguire il benchmark sui 16 nodi di elaborazione. I test eseguiti variavano da un singolo thread fino a 512 thread. Il benchmark è stato utilizzato solo per i file (senza metadati di directory), ottenendo il numero di creazioni, statistiche, letture e rimozioni che la soluzione è in grado di gestire.
    Per valutare correttamente la soluzione rispetto ad altre soluzioni di storage HPC Dell EMC, è stato utilizzato il modulo di metadati High Demand opzionale, ma con un singolo array ME4024, anche la configurazione di grandi dimensioni testata in questo lavoro è stata designata per avere due ME4024. 
    Questo modulo metadati high demand può supportare fino a quattro array ME4024 e si consiglia di aumentare il numero di array ME4024 a 4 prima di aggiungere un altro modulo metadati. Si prevede che gli array ME4024 aggiuntivi aumentino le prestazioni dei metadati in modo lineare con ogni array aggiuntivo, ad eccezione forse delle operazioni Stat (e delle letture per i file vuoti). Poiché i numeri sono molto alti, a un certo punto le CPU diventeranno un collo di bottiglia e le prestazioni non continueranno ad aumentare in modo lineare.
    Il comando seguente è stato utilizzato per eseguire il benchmark, dove Threads era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenze di due) e my_hosts.$Threads era il file corrispondente che allocava ogni thread in un nodo diverso, utilizzando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione. Analogamente al benchmark di IO casuale, il numero massimo di thread è stato limitato a 512, poiché non sono presenti core sufficienti per 1024 thread e il cambio di contesto avrebbe influito sui risultati, riportando un numero inferiore rispetto alle prestazioni reali della soluzione.

    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


    Poiché i risultati delle prestazioni possono essere influenzati dal numero totale di IOPS, dal numero di file per directory e dal numero di thread, si è deciso di mantenere fisso il numero totale di file a 2 MiB (2^21 = 2097152), il numero di file per directory fisso a 1024 e il numero di directory variava al variare del numero di thread, come illustrato nella Tabella 3.

    Tabella 3.  Distribuzione MDtest dei file nelle directory

    Numero di thread

    Numero di directory per thread

    Numero totale di file

    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)
    Figura 5. Prestazioni dei metadati - File

    vuoti Innanzitutto, si noti che la scala scelta era logaritmica con base 10, per consentire di confrontare operazioni che presentano differenze di diversi ordini di grandezza; In caso contrario, alcune operazioni apparirebbero come una linea piatta vicina a 0 su un grafico normale. Un grafico logaritmico in base 2 potrebbe essere più appropriato, dal momento che il numero di thread è aumentato in potenze di 2, ma il grafico sarebbe abbastanza simile e le persone tendono a gestire e ricordare numeri migliori basati su potenze di 10.


    Il sistema ottiene ottimi risultati con le operazioni Stat e Read che raggiungono il loro valore di picco a 64 thread con 11,2 milioni di op/s e 4,8 milioni di op/s rispettivamente. Le operazioni di rimozione hanno raggiunto il massimo di 169,4K op/s a 16 thread e le operazioni di creazione hanno raggiunto il picco a 512 thread con 194,2K op/s. Le operazioni di statistica e lettura hanno più variabilità, ma una volta raggiunto il valore di picco, le prestazioni non scendono al di sotto di 3 milioni op/s per le statistiche e di 2 milioni op/s per le letture. La creazione e la rimozione sono più stabili una volta raggiunto un plateau e rimangono al di sopra di 140.000 operazioni/s per la rimozione e 120.000 operazioni/s per la creazione.
     

    Prestazioni dei metadati con MDtest con file da 4 KiB

    Questo test è quasi identico al precedente, tranne per il fatto che, anziché file vuoti, sono stati utilizzati file vuoti di piccole dimensioni da 4 KiB. 
    Il comando seguente è stato utilizzato per eseguire il benchmark, dove Threads era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenze di due) e my_hosts.$Threads era il file corrispondente che allocava ogni thread in un nodo diverso, utilizzando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione.

    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)
    Figura 6.  Prestazioni dei metadati - File di piccole dimensioni (4K)

    Il sistema ottiene ottimi risultati per le operazioni di statistica e rimozione, raggiungendo il loro valore di picco a 128 thread con 7,7 milioni di op/s e 1 milione di op/s rispettivamente. Le operazioni di rimozione hanno raggiunto il massimo di 37,3K op/s e le operazioni di creazione hanno raggiunto il picco con 55,5K OP/s, entrambe a 512 thread. Le operazioni di statistiche e rimozioni hanno una maggiore variabilità, ma una volta raggiunto il loro valore massimo, le prestazioni non scendono al di sotto di 4 milioni di operazioni/s per le statistiche e 200.000 operazioni/s per la rimozione. La creazione e la lettura hanno meno variabilità e continuano ad aumentare al crescere del numero di thread.
    Poiché questi numeri si riferiscono a un modulo di metadati con un singolo ME4024, le prestazioni aumenteranno per ogni array ME4024 aggiuntivo, tuttavia non possiamo semplicemente ipotizzare un aumento lineare per ogni operazione. A meno che l'intero file non si adatti all'interno dell'inode per tale file, le destinazioni dei dati sui sistemi ME4084s verranno utilizzate per archiviare i file 4K, limitando in qualche modo le prestazioni. Poiché la dimensione degli inode è di 4 KiB e deve comunque archiviare i metadati, solo i file intorno a 3 KiB si adattano all'interno e qualsiasi file di dimensioni superiori utilizzerà le destinazioni di dati.
     


    Prestazioni dei metadati utilizzando MDtest con file 3K

    Questo test è quasi identico ai precedenti, tranne per il fatto che sono stati utilizzati piccoli file da 3KiB. La differenza principale è che questi file si inseriscono completamente all'interno dell'inode. Pertanto, gli storage node e i rispettivi ME4084 non vengono utilizzati, migliorando la velocità complessiva utilizzando solo supporti SSD per lo storage e meno accessi alla rete. 
    Il comando seguente è stato utilizzato per eseguire il benchmark, dove Threads era la variabile con il numero di thread utilizzati (da 1 a 512 incrementati in potenze di due) e my_hosts.$Threads era il file corrispondente che allocava ogni thread in un nodo diverso, utilizzando Round Robin per distribuirli in modo omogeneo tra i 16 nodi di elaborazione.

    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)
    Figura 7. Prestazioni dei metadati - File di piccole dimensioni (3K)

    Il sistema ottiene ottimi risultati per le operazioni Stat e Read, raggiungendo il valore di picco a 256 thread rispettivamente con 8,29 milioni di op/s e 5,06 milioni di op/s. Le operazioni di rimozione hanno raggiunto il massimo di 609.000 operazioni/s a 128 thread e le operazioni di creazione hanno raggiunto il picco con 78.000 operazioni/s a 512 thread. Le operazioni di statistica e lettura presentano una variabilità maggiore rispetto alla creazione e alla rimozione. La rimozione ha un piccolo calo delle prestazioni per i due punti di thread più alti, suggerendo che le prestazioni sostenute dopo 128 thread saranno leggermente superiori a 400.000 op/s. Le creazioni hanno continuato ad aumentare fino a 512 thread, ma sembra che stiano raggiungendo un plateau, quindi le prestazioni massime potrebbero essere ancora inferiori a 100K op/s.
    Poiché file di piccole dimensioni come questi vengono archiviati completamente nel modulo di metadati basato su SSD, le applicazioni che richiedono prestazioni superiori per i file di piccole dimensioni possono utilizzare uno o più moduli di metadati opzionali con elevata richiesta per aumentare le prestazioni dei file di piccole dimensioni. Tuttavia, i file che si adattano all'inode sono minuscoli per gli standard attuali. Inoltre, poiché le destinazioni dei metadati utilizzano RAID1 con SSD relativamente piccoli (la dimensione massima è 19,2 TB), la capacità sarà limitata rispetto agli storage node. Pertanto, è necessario prestare attenzione per evitare di riempire le destinazioni dei metadati, che possono causare errori non necessari e altri problemi.
     


    Advanced Analytics

    Tra le funzionalità di PixStor, il monitoraggio del file system tramite analisi avanzate può essere essenziale per semplificare notevolmente l'amministrazione, contribuendo a trovare problemi o potenziali problemi in modo proattivo o reattivo. Successivamente, esamineremo brevemente alcune di queste funzionalità.
    La Figura 8 mostra informazioni utili in base alla capacità del file system. Sul lato sinistro, lo spazio totale utilizzato dal file system e i primi dieci utenti in base alla capacità del file system utilizzata. Sul lato destro, una vista cronologica con la capacità utilizzata per molti anni, quindi i primi dieci tipi di file utilizzati e i primi dieci fileset, entrambi basati sulla capacità utilizzata, in un formato simile ai grafici di Pareto (senza le linee per i totali cumulativi). Con queste informazioni, può essere facile trovare gli utenti che ottengono più della loro giusta quota di file system, le tendenze di utilizzo della capacità per aiutare le decisioni sulla futura crescita della capacità, quali file utilizzano la maggior parte dello spazio o quali progetti richiedono la maggior parte della capacità.

    SLN318841_en_US__9image(11993)
    Figura 8.  PixStor Analytics - Vista

    Capacità La Figura 9 fornisce una vista di conteggio dei file con due modi molto utili per individuare i problemi. La prima metà della schermata mostra i primi dieci utenti in un grafico a torta e i primi dieci tipi di file e i primi dieci fileset (si pensi ai progetti) in un formato simile ai grafici di Pareto (senza le righe per i totali cumulativi), il tutto basato sul numero di file. Queste informazioni possono essere utilizzate per rispondere ad alcune domande importanti. Ad esempio, gli utenti che monopolizzano il file system creando troppi file, il tipo di file che crea un incubo dei metadati o i progetti che utilizzano la maggior parte delle risorse.
    La metà inferiore contiene un istogramma con il numero di file (frequenza) per le dimensioni dei file utilizzando 5 categorie per le diverse dimensioni dei file. Questo può essere utilizzato per avere un'idea delle dimensioni dei file utilizzate nel file system, che coordinate con i tipi di file possono essere utilizzate per decidere se la compressione sarà vantaggiosa.

    SLN318841_en_US__10image(11994)
    Figura 9.  PixStor Analytics - Vista conteggio file



     


    Conclusioni e lavoro futuro

    La soluzione attuale è stata in grado di fornire prestazioni abbastanza buone, che dovrebbero essere stabili indipendentemente dallo spazio utilizzato (poiché il sistema è stato formattato in modalità sparsa), come si può vedere nella Tabella 4. Inoltre, la soluzione è scalabile in modo lineare in termini di capacità e prestazioni a mano a mano che vengono aggiunti più moduli di storage node e si può prevedere un aumento delle prestazioni simile dal modulo metadati high demand opzionale. Questa soluzione fornisce ai clienti HPC un file system parallelo molto affidabile utilizzato da molti dei primi 500 cluster HPC. Inoltre, fornisce eccezionali funzionalità di ricerca, monitoraggio e gestione avanzati e l'aggiunta di gateway opzionali consente la condivisione di file tramite protocolli standard onnipresenti come NFS, SMB e altri a tutti i client necessari.

    Tabella 4  Prestazioni di picco e sostenute

     

     

    Prestazioni di picco

    Prestazioni sostenute

    Scrittura

    Lettura

    Scrittura

    Lettura

    Sequenziali di grandi dimensioni da N client a N file

    16,7 GB/s

    23 GB/s

    16,5 GB/s

    20,5 GB/s

    Sequenziali di grandi dimensioni da N client a file singolo condiviso

    16,5 GB/s

    23,8 GB/s

    16,2 GB/s

    20,5 GB/s

    Blocchi casuali di piccole dimensioni da N client a N file

    15.8KIOps

    20.4KIOps

    15.7KIOps

    20.4KIOps

    File vuoti per creazione di metadati

    169.400 IOPS

    127,2K IOps

    File vuoti per statistiche di metadati

    11,2 milioni di IOps

    3,3 milioni di IOps

    File vuoti per lettura di metadati

    4,8 milioni di IOps

    2,4 milioni di IOPS

    File vuoti per rimozione di metadati

    194,2.200 IOps

    144,8K IOps

    File da 4KiB per creazione di metadati

    55,4K IOps

    55,4K IOps

    File da 4KiB per statistiche di metadati

    6,4 milioni di IOps

    4 milioni di IOps

    File da 4KiB per lettura di metadati

    37.300 IOps

    37.300 IOps

    File da 4KiB per rimozione di metadati

    1 milione di IOps

    219.500 IOps



    Poiché la soluzione è destinata al rilascio con CPU Cascade Lake e RAM più veloce, una volta completata la configurazione finale del sistema, verranno eseguiti alcuni controlli a campione delle prestazioni. Inoltre, il test del modulo opzionale di metadati high demand con almeno 2 ME4024s e file da 4KiB è necessario per documentare meglio il modo in cui le prestazioni dei metadati vengono scalate quando sono coinvolti destinazioni di dati. In più, le prestazioni per i nodi gateway verranno misurate e segnalate insieme a eventuali risultati pertinenti dai controlli a campione in un nuovo blog o in un white paper. Infine, è previsto il test e il rilascio di un maggior numero di componenti della soluzione per fornire funzionalità ancora maggiori.


     

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.