Considerazioni sul traffico dei file system
I valori rilevanti sono i numeri relativi a operazioni di I/O al secondo, velocità effettiva e latenza. Per ottimizzare le prestazioni, è tuttavia necessario determinare anche il modo in cui i carichi di lavoro HPC interagiscono con il file system. Il passaggio successivo consiste nel quantificare la scalabilità le combinazioni di traffico che devono essere supportate dal file system.
Considerazioni sulle combinazioni di traffico
Con combinazioni di traffico si indicano gli elementi che costituiscono il traffico di un carico di lavoro HPC a livello di:
- Rapporto tra traffico per operazioni di lettura e traffico per operazioni di scrittura. Ad esempio, 100% di lettura, 50% di lettura e 50% di scrittura, 100% di scrittura.
- Confronto tra operazioni di lettura/scrittura casuali e sequenziali.
- Checkpoint e snapshot.
- Concorrenza.
- Quantità e dimensioni dei file.
Nel resto di questa unità verrà illustrato in che modo questa combinazione di tipi di traffico influisce sulle opzioni relative all'archiviazione.
Confronto tra traffico per operazioni di lettura, traffico per operazioni di scrittura e operazioni di creazione/eliminazione
Le operazioni di lettura e scrittura utilizzano in modo uniforme le operazioni di I/O al secondo. È tuttavia possibile che il file system scelto applichi la disponibilità elevata al traffico in ingresso, generando quindi una velocità effettiva di scrittura più bassa ma resiliente.
È possibile che si verifichi un impatto sulle prestazioni se il carico di lavoro HPC esegue un numero elevato di operazioni con uso elevato dei metadati, ad esempio creazione di file, ridenominazione di strutture di directory o eliminazione di file. La creazione di un file potrebbe utilizzare molte operazioni per verificare l'esistenza del file, creare l'handle di file, aggiornare la voce della directory e così via.
È possibile che il carico di lavoro HPC sia incentrato principalmente sulla trasformazione dei dati e che quindi la quantità di traffico per operazioni di scrittura sia significativa. In tale caso è consigliabile assegnare la priorità all'ottimizzazione delle prestazioni.
Confronto tra traffico casuale e sequenziale
L'accesso alle applicazioni determina il tipo di criteri di traffico per operazioni di lettura e scrittura che potrebbero essere necessari per il carico di lavoro.
È possibile che i carichi di lavoro HPC siano altamente parallelizzati, con molti computer che richiedono gli stessi dati da un file system condiviso, oppure che siano univoci e serializzati, con criteri di accesso ai dati univoci e casuali. Le prestazioni del traffico sequenziale sono superiori rispetto a quelle del traffico casuale. Un esempio di traffico sequenziale è costituito dal caricamento di una libreria binaria o di un file di immagine o video di grandi dimensioni da parte di uno o più computer. Un esempio di traffico casuale è costituito da richieste per diversi intervalli di byte in un singolo file o in più file, invece della lettura di un intero file.
Checkpoint e snapshot
I carichi di lavoro includono spesso checkpoint. Quando vengono creati checkpoint, lo stato dell'applicazione e dei rispettivi dati viene copiato in una risorsa di archiviazione durevole e quindi il carico di lavoro continua l'esecuzione. La creazione di checkpoint viene usata per riprendere carichi di lavoro a esecuzione prolungata senza che sia necessario un riavvio completo del processo. La creazione di checkpoint può essere usata anche con gli snapshot. Gli snapshot sono copie di sola lettura del file system create in un determinato momento. I checkpoint possono essere considerati come specifici dell'applicazione o dipendenti dall'applicazione, ma gli snapshot sono rilevanti a livello di file system.
I checkpoint e gli snapshot utilizzano operazioni di I/O al secondo e risorse di archiviazione. Influiscono quindi sulle prestazioni complessive del file system, in base alla rispettiva frequenza e alla quantità di dati interessati.
Concorrenza
Il numero di client e thread simultanei è un altro fattore da valutare quando si seleziona il file system. Molti carichi di lavoro HPC richiedono una concorrenza significativa durante l'avvio del processo e le fasi relative ai risultati, possibilmente fino a centinaia o migliaia di thread. È ad esempio possibile che un processo venga avviato in cento computer a 16 core e che ogni core gestisca uno o due thread simultanei. La concorrenza dei thread in tale caso potrebbe essere compresa tra 1.600 e 3.200 thread. È possibile che tutti questi thread leggano file binari (librerie, toolchain e così via) necessari prima che sia possibile continuare l'esecuzione del processo. Per ridurre al minimo il tempo di esecuzione del processo, è necessario che il sistema di archiviazione sottostante sia in grado di fornire risposte rapide a queste richieste di lettura.
Lo stesso processo potrebbe non richiedere più alcun accesso simultaneo. In alternativa, è possibile che richieda l'accesso con burst per più dati del file oppure che scriva risultati intermedi per altri thread nel processo da leggere.
Numero e dimensioni dei file
Quando si seleziona l'archiviazione file, è necessario prendere in considerazione anche il numero e le dimensioni medie dei file. Un carico di lavoro che utilizza 2 TB di dati ha caratteristiche diverse in termini di prestazioni se tali 2 TB sono costituiti da 100 file da 20 GB invece che da 10.000 file da 200 MB, in particolare se i 10.000 file sono annidati in strutture profonde della directory.
È consigliabile identificare i working set più probabili dei dati. Un working set indica il numero massimo e le dimensioni massime potenziali del file richiesti. Provare a identificare le definizioni massime e medie del working set e usare tali valori massimi per guidare la pianificazione.
La definizione di un working set non è sempre facile, in particolare per un ambiente invece che per un singolo carico di lavoro HPC. È ad esempio possibile che in un giorno specifico risulti necessario creare una piccola simulazione relativa a un set statico di dati. Il giorno successivo potrebbe essere necessario aumentare le prestazioni per eseguire un'analisi più ampia con output e checkpoint intermedi.