Dell EMC Ready Solutions per HPC nello storage ad alte prestazioni BeeGFS

Articolo scritto da Nirmala Sundararajan di Dell EMC HPC e AI Innovation Lab nel mese di novembre 2019

Dell EMC Ready Solutions per HPC nello storage ad alte prestazioni BeeGFS

Sommario

1. Introduzione
2. Architettura di riferimento della soluzione
3. Configurazione hardware e software
4. Dettagli della configurazione della soluzione
   • Servizio di gestione
   • Servizio metadati
   • Storage Services
   • Client Services
5. R740xd, 24 unità NVMe, dettagli sulla mappatura della CPU
6. Caratterizzazione delle prestazioni
   • Letture e scritture sequenziali N-N
   • Letture e scritture casuali N-N
7. Conclusioni e lavoro futuro
    

Introduzione

Architettura di riferimento della soluzione

Configurazione hardware e software

Le tabelle 1 e 2 descrivono rispettivamente le specifiche hardware del server di gestione e dei metadati/storage server. La Tabella 3 descrive le versioni software utilizzate per la soluzione.

Dettagli della configurazione della soluzione

• Servizio di gestione
• Servizio metadati
• Storage Services
• Client Services

Servizio di gestione

Servizio metadati

Figura 3.  Server metadati

La Figura 4 mostra la configurazione RAID del server di metadati. Evidenzia il modo in cui nel server di metadati, le unità nella zona NUMA 0 ospitano gli MPT e quelle nella zona 1 NUMA ospitano i dati di storage, mentre gli storage server ospitano le ST in entrambe le zone NUMA.

Storage Services

1. Le prestazioni di scrittura sono state misurate utilizzando il comando dd creando un file da 10 GiB con dimensione block di 1MiB e I/O diretto per i dati, per i dispositivi RAID 0 la media era di circa 5,1 GB/s per ogni dispositivo, mentre per i dispositivi RAID 10 la media era di 3,4 GB/s per ogni dispositivo.
2. I test di benchmark StorageBench hanno mostrato un throughput massimo di 5,5 GB/s per la configurazione RAID 0, mentre è di 3,4 GB/s per una configurazione RAID 10. Questi risultati sono simili a quanto ottenuto utilizzando i comandi dd.
3. RAID 10 fornisce un utilizzo del 50% della capacità del disco e una riduzione simile del 50% delle prestazioni di scrittura. L'utilizzo di RAID 10 è un modo costoso per ottenere la ridondanza dello storage.
4. Le unità NVMe sono costose e offrono velocità che vengono utilizzate al meglio in una configurazione RAID 0

Client Services

$ cat /etc/beegfs/beegfs-mounts.conf
/mnt/beegfs-medium /etc/beegfs/beegfs-client-medium.conf
/mnt/beegfs-small /etc/beegfs/beegfs-client-small.conf

R740xd, 24 unità NVMe, dettagli sulla mappatura della CPU

# cat /proc/sys/kernel/numa_balancing
0

Caratterizzazione delle prestazioni

Scritture e letture sequenziali N-N

Per valutare le letture e scritture sequenziali, il benchmark IOzone, è stato utilizzato nella modalità di lettura e scrittura sequenziale. Questi test sono stati condotti su un numero di thread a partire da 1 in potenza di 2, fino a 1024 thread. In ciascun thread è stato generato un numero uguale di file, poiché questo test funziona su un file per thread o su un caso N-N. I processi sono stati distribuiti su 32 nodi client fisici in modo round robin o ciclico in modo tale che le richieste siano equamente distribuite e vi sia bilanciamento del carico. È stata selezionata una dimensione di file aggregata pari a 8 TB, divisa equamente tra il numero di thread all'interno di un determinato test. La dimensione del file aggregato è stata scelta in modo sufficientemente grande da ridurre al minimo gli effetti della memorizzazione nella cache dai server e dai client BeeGFS. IOzone è stato eseguito in modalità combinata di scrittura e lettura (-i 0, -i 1) per consentire di coordinare i limiti tra le operazioni. Per questo test e i risultati, abbiamo utilizzato una dimensione record di 1MiB per ogni esecuzione. Di seguito sono riportati i comandi utilizzati per i test N-N sequenziali:

Scritture e letture sequenziali: iozone -i 0 -i 1 -c -e -w -r 1m -I -s $Size -t $Thread -+n -+m /path/to/threadlist

Le cache del sistema operativo sono state eliminate o pulite sui nodi client tra le iterazioni e tra i test di scrittura e lettura eseguendo il comando:

# sync & echo 3 > /proc/sys/vm/drop_caches

Il numero di stripe predefinito per Beegfs è 4. Tuttavia, le dimensioni del blocco e il numero di destinazioni per file possono essere configurate in base alla directory. Per tutti questi test, è stata scelta la dimensione di stripe BeeGFS da 2 MB e il conteggio degli stripe è stato scelto come 3 in quanto abbiamo tre destinazioni per zona NUMA, come mostrato di seguito:

$ beegfs-ctl --getentryinfo --mount=/mnt/beegfs /mnt/beegfs/benchmark --verbose
EntryID: 0-5D9BA1BC-1
ParentID: root
Metadata node: node001-numa0-4 [ID: 4]
Stripe pattern details:
+ Type: RAID0
+ Chunksize: 2M
+ Number of storage targets: desired: 3
+ Storage Pool: 1 (Default)
Inode hash path: 7/5E/0-5D9BA1BC-1

Le enormi pagine trasparenti sono state disabilitate e sono disponibili le seguenti opzioni di tuning sui metadati e sugli storage server:

• vm.dirty_background_ratio = 5 
• vm.dirty_ratio = 20 
• vm.min_free_kbytes = 262144 
• vm.vfs_cache_pressure = 50
• vm.zone_reclaim_mode = 2 
• kernel.numa_balancing = 0

Oltre a quanto sopra, sono state utilizzate le seguenti opzioni di tuning BeeGFS: 

• il parametro tuneTargetChooser è stato impostato su "roundrobin" nel file di configurazione dei metadati 
• il parametro tuneNumWorkers è stato impostato su 24 per i metadati e 32 per lo storage 
• Il parametro connMaxInternodeNum è stato impostato su 32 per i metadati e 12 per lo storage e 24 per i client

Nella Figura 9, vediamo che il picco delle prestazioni di lettura è 132 GB/s a 1024 thread e il picco di scrittura è 121 GB/s a 256 thread. Ogni unità può fornire prestazioni di lettura di picco di 3,2 GB/s e prestazioni di scrittura di picco di 1,3 GB/s, che consentono un picco teorico di 422 GB/s per le letture e 172 GB/s per le scritture. Tuttavia, qui la rete è il fattore limitante. Abbiamo un totale di 11 link EDR InfiniBand per gli storage server nella configurazione. Ogni link può fornire prestazioni di picco teoriche di 12,4 GB/s che consente un picco teorico delle prestazioni di 136,4 GB/s. Il picco di prestazioni di lettura e scrittura raggiunto è rispettivamente del 97% e dell'89% delle prestazioni di picco teoriche.

Si osserva che le prestazioni di scrittura a thread singolo sono di circa 3 GB/s e di lettura a circa 3 GB/s. Si osserva che le prestazioni di scrittura sono scalabili in modo lineare, picchi di 256 thread e poi inizia a diminuire. Con un numero inferiore di thread, le prestazioni di lettura e scrittura sono le stesse. Perché fino a 8 thread, abbiamo 8 client che scrivono 8 file su 24 destinazioni, il che significa che non tutte le destinazioni di storage vengono completamente utilizzate. Abbiamo 33 destinazioni di storage nel sistema e quindi sono necessari almeno 11 thread per utilizzare completamente tutti i server. Le prestazioni di lettura registrano un costante aumento lineare con l'aumento del numero di thread simultanei e osserviamo prestazioni quasi simili a 512 e 1024 thread.

Si osserva inoltre che le prestazioni di lettura sono inferiori alle scritture per i conteggi di thread da 16 a 128 e quindi le prestazioni di lettura iniziano a scalare. Ciò è dovuto al fatto che, mentre un'operazione di lettura PCIe è un'operazione non pubblicata, che richiede sia una richiesta che un completamento, un'operazione di scrittura PCIe è un'operazione fire and forget. Una volta che Transaction Layer Packet viene consegnato al livello di collegamento dati, l'operazione viene completata. Un'operazione di scrittura è un'operazione "Posted" costituita solo da una richiesta.

Il throughput di lettura è in genere inferiore rispetto al throughput in scrittura perché le letture richiedono due transazioni anziché una singola scrittura per la stessa quantità di dati. PCI Express utilizza un modello di transazione suddivisa per le letture. La transazione di lettura include i seguenti passaggi:

• Il richiedente invia una memory read request (MRR).
• Il completer invia la conferma all'MRR.
• Il completamento restituisce un completamento con i dati.

Il throughput di lettura dipende dal ritardo tra il tempo di emissione della richiesta di lettura e il tempo impiegato dal completer per restituire i dati. Tuttavia, quando l'applicazione genera un numero sufficiente di richieste di lettura per coprire questo ritardo, il throughput viene ottimizzato. Questo è il motivo per cui, sebbene le prestazioni di lettura siano inferiori a quelle delle scritture da 16 thread a 128 thread, valutiamo un aumento del throughput quando aumenta il numero di richieste.  Un throughput inferiore viene misurato quando il richiedente attende il completamento prima di emettere richieste successive. Viene registrato un throughput più elevato quando vengono inviate più richieste per ritardare il ritardo dopo la restituzione dei primi dati.

Scritture e letture casuali N-N

Per valutare le prestazioni I/O casuali, IOzone è stato utilizzato in modalità casuale. I test sono stati condotti su conteggi di thread a partire da 4 a un massimo di 1024 thread. L'opzione I/O diretta (-I) è stata utilizzata per eseguire IOzone in modo che tutte le operazioni bypassano la cache del buffer e passano direttamente al disco. È stato utilizzato il numero di stripe BeeGFS di 3 e la dimensione del blocco di 2 MB. Una dimensione della richiesta da 4 KiB viene utilizzata su IOzone. Le prestazioni sono misurate in operazioni di I/O al secondo (IOPS). Le cache del sistema operativo sono state eliminate tra le esecuzioni sui server BeeGFS e sui client BeeGFS. Il comando utilizzato per l'esecuzione di scritture e letture casuali è indicato di seguito:

Letture e scritture casuali: iozone -i 2 -w -c -O -I -r 4K -s $Size -t $Thread -+n -+m /path/to/threadlist

Figura 10.  Prestazioni di lettura e scrittura casuali utilizzando IOzone con dimensioni di file aggregate di8 TB

Il picco di scritture casuali a ~3,6 milioni di IOPS a 512 thread e il picco di letture casuali a ~3,5 milioni di IOPS a 1024 thread, come illustrato nella Figura 10. Sia le prestazioni di scrittura che di lettura mostrano prestazioni più elevate in caso di un numero più elevato di richieste I/O. Ciò è dovuto al fatto che lo standard NVMe supporta fino a 64.000 code di I/O e fino a 64.000 comandi per coda. Questo ampio pool di code NVMe fornisce livelli più elevati di parallelismo I/O e quindi osserviamo IOPS superiori a 3 milioni.

Conclusioni e lavoro futuro

Questo blog annuncia il rilascio della soluzione di storage Dell EMC High Performance BeeGFS e ne evidenzia le caratteristiche prestazionali. La soluzione offre prestazioni di lettura e scrittura sequenziali di picco rispettivamente di circa 132 GB/s e ~121 GB/s e il picco di scritture casuali a ~3,6 milioni di IOPS e letture casuali a ~3,5 milioni di IOPS.

Questo blog fa parte di "BeeGFS Storage Solution", progettata con particolare attenzione allo spazio scratch con prestazioni elevate. Restate sintonizzati per la seconda parte della serie di blog che descriverà in che modo la soluzione può essere dimensionata incrementando il numero di server per aumentare le prestazioni e la capacità. Nella parte 3 della serie di blog verranno illustrate le funzionalità aggiuntive di BeeGFS e verrà evidenziato l'utilizzo di "StorageBench", il benchmark degli obiettivi di storage integrato di BeeGFS.

Come parte dei passaggi successivi, pubblicheremo un white paper più tardi con le prestazioni dei metadati e i thread N a 1 file IOR e con ulteriori dettagli sulle considerazioni di progettazione, sul tuning e sulla configurazione.

Riferimenti