Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Prestazioni FSx di Amazon for Lustre Questo capitolo fornisce argomenti sulle prestazioni di Amazon FSx for Lustre, inclusi alcuni importanti suggerimenti e raccomandazioni per massimizzare le prestazioni del file system. **Topics** + [Panoramica di](#performance-overview) + [Come funzionano i file FSx system di For Lustre](#how-lustre-fs-work) + [Prestazioni dei metadati del file system](#dne-metadata-performance) + [Throughput verso le singole istanze del client](#throughput-clients) + [Layout di storage del file system](#storage-layout) + [Striping dei dati nel file system](#striping-data) + [Monitoraggio delle prestazioni e dell'utilizzo](#performance-monitoring) + [Caratteristiche prestazionali delle classi di storage SSD e HDD](ssd-storage.md) + [Caratteristiche prestazionali della classe di storage Intelligent-Tiering](intelligent-tiering-file-systems.md) + [Suggerimenti per le prestazioni](performance-tips.md) ## Panoramica di Amazon FSx for Lustre, basato sul popolare file system ad alte prestazioniLustre, offre prestazioni di scalabilità orizzontale che aumentano linearmente con le dimensioni di un file system. Lustrei file system si scalano orizzontalmente su più file server e dischi. Questa scalabilità offre a ciascun client l'accesso diretto ai dati archiviati su ciascun disco per eliminare molti dei colli di bottiglia presenti nei file system tradizionali. Amazon FSx for Lustre si basa sull'architettura Lustre scalabile per supportare alti livelli di prestazioni su un gran numero di client. ## Come funzionano i file FSx system di For Lustre Ogni file system FSx for Lustre è costituito dai file server con cui i client comunicano e da un set di dischi collegati a ciascun file server in cui sono archiviati i dati. Ogni file server utilizza una cache veloce in memoria per migliorare le prestazioni dei dati a cui si accede più frequentemente. A seconda della classe di archiviazione, è possibile dotare il file server di una cache di lettura SSD opzionale. Quando un client accede ai dati archiviati nella cache in memoria o SSD, il file server non ha bisogno di leggerli dal disco, il che riduce la latenza e aumenta la quantità totale di throughput che è possibile gestire. Il diagramma seguente illustra i percorsi di un'operazione di scrittura, un'operazione di lettura eseguita dal disco e un'operazione di lettura eseguita dalla cache in memoria o SSD. ![\[FSx per l'architettura ad alte prestazioni Lustre.\]](http://docs.aws.amazon.com/it_it/fsx/latest/LustreGuide/images/LustrePerfDiagram.png) Quando si leggono i dati archiviati nella cache in memoria o SSD del file server, le prestazioni del file system sono determinate dalla velocità di trasmissione della rete. Quando si scrivono dati sul file system o quando si leggono dati che non sono archiviati nella cache in memoria, le prestazioni del file system sono determinate dalla riduzione del throughput di rete e del disco. Per ulteriori informazioni sulla velocità effettiva di rete, sulla velocità effettiva su disco e sulle caratteristiche IOPS delle classi di storage SSD e HDD, consulta e. [Caratteristiche prestazionali delle classi di storage SSD e HDD](ssd-storage.md) [Caratteristiche prestazionali della classe di storage Intelligent-Tiering](intelligent-tiering-file-systems.md) ## Prestazioni dei metadati del file system Le operazioni di I/O al secondo (IOPS) dei metadati del file system determinano il numero di file e directory che è possibile creare, elencare, leggere ed eliminare al secondo. I file system Persistent 2 consentono di effettuare il provisioning dei metadati (IOPS) indipendentemente dalla capacità di storage e offrono una maggiore visibilità sul numero e sul tipo di metadati che le istanze client IOPS generano sul file system. Con i file system SSD, il provisioning degli IOPS dei metadati viene eseguito automaticamente in base alla capacità di storage fornita. La modalità automatica non è supportata sui file system Intelligent-Tiering. FSx Per i file system Lustre Persistent 2, il numero di IOPS di metadati forniti e il tipo di operazione sui metadati determinano la frequenza delle operazioni sui metadati che il file system è in grado di supportare. Il livello di IOPS di metadati fornito determina il numero di IOPS assegnati per i dischi di metadati del file system. | Tipo di operazione | Operazioni che è possibile eseguire al secondo per ogni IOPS di metadati fornito | | --- | --- | | Creazione, apertura e chiusura di file | 2 | | Eliminazione di file | 1 | | Creazione e ridenominazione della cartella | 0.1 | | Eliminazione della directory | 0.2 | Per i file system SSD, puoi scegliere di effettuare il provisioning degli IOPS dei metadati utilizzando la modalità automatica. In modalità Automatica, Amazon effettua FSx automaticamente il provisioning degli IOPS dei metadati in base alla capacità di storage del file system in base alla tabella seguente: | Capacità di storage del file system | Metadati IOPS inclusi in modalità automatica | | --- | --- | | 1200 GiB | 1500 | | 2400 GiB | 3000 | | 4800—9600 GiB | 6000 | | 12000—45600 GiB | 12000 | | ≥48000 GiB | 12000 IOPS per 24000 GiB | In modalità User-provisioned, puoi facoltativamente scegliere di specificare il numero di IOPS di metadati da fornire. I valori validi sono: + Per i file system SSD, i valori validi sono`1500`,, `3000` `6000``12000`, e multipli fino a un massimo di. `12000` `192000` + Per i file system Intelligent-Tiering, i valori validi sono e. `6000` `12000` Per informazioni su come configurare Metadata IOPS, vedere. [Gestione delle prestazioni dei metadati](managing-metadata-performance.md) Tieni presente che paghi per gli IOPS dei metadati assegnati al di sopra del numero predefinito di IOPS di metadati per il tuo file system. ## Throughput verso le singole istanze del client Se stai creando un file system con oltre il 10% GBps della capacità di throughput, ti consigliamo di abilitare Elastic Fabric Adapter (EFA) per ottimizzare il throughput per istanza client. Per ottimizzare ulteriormente il throughput per istanza client, i file system abilitati per EFA supportano anche GPUDirect lo storage per le istanze client basate su GPU NVIDIA abilitate per EFA e ENA Express per le istanze client abilitate per ENA Express. Il throughput che è possibile trasferire a una singola istanza client dipende dalla scelta del tipo di file system e dall'interfaccia di rete dell'istanza client. | Tipo di file system | Interfaccia di rete dell'istanza del client | Velocità effettiva massima per client, Gbps | | --- | --- | --- | | Non abilitato per EFA | Qualsiasi | 100 Gbps\$1 | | Compatibile con EFA | ENA | 100 Gbps\$1 | | Compatibile con EFA | ENA Express | 100 Gb/s | | Abilitato all'EFA | EFA | 700 Gbps | | Compatibile con EFA | EFA con GDS | 1200 Gbps | **Nota** \$1 Il traffico tra una singola istanza client e un singolo server di storage FSx di oggetti Lustre è limitato a 5 Gbps. Fate riferimento al [Indirizzi IP per file system](using-fsx-lustre.md#ip-addesses-for-fs) numero di server di storage di oggetti su cui si basa il file system FSx for Lustre. ## Layout di storage del file system Tutti i dati dei file in Lustre esso contenuti vengono archiviati in volumi di storage denominati *object storage targets* (OSTs). Tutti i metadati dei file (inclusi nomi di file, timestamp, autorizzazioni e altro) vengono archiviati in volumi di archiviazione *denominati metadata* target (). MDTs I file system di Amazon FSx for Lustre sono composti da uno o più MDTs file. OSTs Amazon FSx for Lustre distribuisce i dati dei file su tutti gli elementi OSTs che compongono il file system per bilanciare la capacità di storage con la velocità effettiva e il carico IOPS. Per visualizzare l'utilizzo dello storage dell'MDT e degli elementi OSTs che costituiscono il file system, esegui il comando seguente da un client su cui è montato il file system. ``` lfs df -h mount/path ``` L'output di questo comando è simile al seguente. **Example** ``` UUID bytes Used Available Use% Mounted on mountname-MDT0000_UUID 68.7G 5.4M 68.7G 0% /fsx[MDT:0] mountname-OST0000_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:0] mountname-OST0001_UUID 1.1T 4.5M 1.1T 0% /fsx[OST:1] filesystem_summary: 2.2T 9.0M 2.2T 0% /fsx ``` ## Striping dei dati nel file system È possibile ottimizzare le prestazioni di throughput del file system con lo striping dei file. Amazon FSx for Lustre distribuisce automaticamente i file per garantire che i dati vengano serviti da tutti i server di storage. OSTs Puoi applicare lo stesso concetto a livello di file configurando la modalità di suddivisione dei file su più file. OSTs Lo striping significa che i file possono essere suddivisi in più blocchi che vengono poi archiviati in diversi. OSTs Quando un file viene suddiviso su più file OSTs, le richieste di lettura o scrittura al file vengono distribuite tra queste OSTs, aumentando il throughput aggregato o gli IOPS che le applicazioni possono gestire. Di seguito sono riportati i layout predefiniti per i file system Amazon FSx for Lustre. + Per i file system creati prima del 18 dicembre 2020, il layout predefinito specifica un numero di strisce pari a 1. Ciò significa che, a meno che non venga specificato un layout diverso, ogni file creato in Amazon FSx for Lustre utilizzando strumenti Linux standard viene archiviato su un singolo disco. + Per i file system creati dopo il 18 dicembre 2020, il layout predefinito è un layout di file progressivo in cui i file di dimensioni inferiori a 1 GiB vengono archiviati in un'unica striscia e ai file più grandi viene assegnato un numero di strisce pari a 5. + Per i file system creati dopo il 25 agosto 2023, il layout predefinito è un layout di file progressivo a 4 componenti, come spiegato in. [Layout di file progressivi](#striping-pfl) + Per tutti i file system, indipendentemente dalla data di creazione, i file importati da Amazon S3 non utilizzano il layout predefinito, ma utilizzano invece il layout nel parametro del `ImportedFileChunkSize` file system. I file importati da S3 più grandi di quelli `ImportedFileChunkSize` verranno archiviati su più file OSTs con un numero di strisce pari a. `(FileSize / ImportedFileChunksize) + 1` Il valore predefinito di è 1GiB`ImportedFileChunkSize`. È possibile visualizzare la configurazione del layout di un file o di una directory utilizzando il `lfs getstripe` comando. ``` lfs getstripe path/to/filename ``` Questo comando riporta il numero di strisce, la dimensione e l'offset delle strisce di un file. Il numero di *strisce è il numero di* strisce su cui è suddiviso OSTs il file. La *dimensione dello stripe indica* la quantità di dati continui archiviati su un OST. Lo *stripe offset* è l'indice del primo OST su cui è distribuito il file. ### Modifica della configurazione dello striping I parametri di layout di un file vengono impostati quando il file viene creato per la prima volta. Utilizzate il `lfs setstripe` comando per creare un nuovo file vuoto con un layout specificato. ``` lfs setstripe filename --stripe-count number_of_OSTs ``` Il `lfs setstripe` comando influisce solo sul layout di un nuovo file. Utilizzatelo per specificare il layout di un file prima di crearlo. Puoi anche definire un layout per una directory. Una volta impostato su una directory, tale layout viene applicato a ogni nuovo file aggiunto a quella directory, ma non ai file esistenti. Ogni nuova sottodirectory creata eredita anche il nuovo layout, che viene quindi applicato a qualsiasi nuovo file o directory creato all'interno di quella sottodirectory. Per modificare il layout di un file esistente, utilizzate il comando. `lfs migrate` Questo comando copia il file secondo necessità per distribuirne il contenuto in base al layout specificato nel comando. Ad esempio, i file aggiunti o di dimensioni maggiori non modificano il numero di strisce, quindi è necessario migrarli per modificare il layout del file. In alternativa, è possibile creare un nuovo file utilizzando il `lfs setstripe` comando per specificarne il layout, copiare il contenuto originale nel nuovo file e quindi rinominare il nuovo file per sostituire il file originale. In alcuni casi la configurazione di layout predefinita non è ottimale per il carico di lavoro. Ad esempio, un file system con decine OSTs e un gran numero di file da più gigabyte può ottenere prestazioni migliori suddividendo i file su un numero di stripe superiore al valore predefinito di cinque. OSTs La creazione di file di grandi dimensioni con un basso numero di righe può causare problemi di I/O prestazioni e può anche causare problemi di riempimento. OSTs In questo caso, puoi creare una directory con un numero maggiore di strisce per questi file. La configurazione di un layout a strisce per file di grandi dimensioni (in particolare file di dimensioni superiori a un gigabyte) è importante per i seguenti motivi: + Migliora la velocità effettiva consentendo a più server OSTs e ai relativi server di contribuire con IOPS, larghezza di banda di rete e risorse della CPU durante la lettura e la scrittura di file di grandi dimensioni. + Riduce la probabilità che un piccolo sottoinsieme di sistemi OSTs diventi un punto critico che limita le prestazioni complessive del carico di lavoro. + Impedisce che un singolo file di grandi dimensioni riempia un OST, causando possibili errori di riempimento del disco. Non esiste un'unica configurazione di layout ottimale per tutti i casi d'uso. Per una guida dettagliata sui layout dei file, consulta [Managing File Layout (Striping) and Free Space](https://doc.lustre.org/lustre_manual.xhtml#managingstripingfreespace) nella documentazione di Lustre.org. Le seguenti sono linee guida generali: + Il layout a strisce è particolarmente importante per i file di grandi dimensioni, specialmente per i casi d'uso in cui i file hanno normalmente dimensioni di centinaia di megabyte o più. Per questo motivo, il layout predefinito per un nuovo file system assegna un numero di strisce pari a cinque per i file di dimensioni superiori a 1 GiB. + Il numero di strisce è il parametro di layout da regolare per i sistemi che supportano file di grandi dimensioni. Il numero di strisce specifica il numero di volumi OST che conterranno porzioni di un file a strisce. Ad esempio, con un numero di strisce pari a 2 e una dimensione di 1 MiB, Lustre scrive blocchi di file da 1 MiB alternativi su ciascuno di due. OSTs + Il numero effettivo di strisce è il minore tra il numero effettivo di volumi OST e il valore di conteggio delle strisce specificato. È possibile utilizzare lo speciale valore di conteggio delle strisce `-1` per indicare che le strisce devono essere posizionate su tutti i volumi OST. + L'impostazione di un numero elevato di strisce per file di piccole dimensioni non è ottimale perché per determinate operazioni è Lustre necessaria una connessione di rete a tutte le OST del layout, anche se il file è troppo piccolo per occupare spazio su tutti i volumi OST. + È possibile impostare un layout progressivo dei file (PFL) che consenta di modificare il layout di un file in base alle dimensioni. Una configurazione PFL può semplificare la gestione di un file system con una combinazione di file grandi e piccoli senza dover impostare esplicitamente una configurazione per ogni file. Per ulteriori informazioni, consulta [Layout di file progressivi](#striping-pfl). + La dimensione predefinita di Stripe è 1 MiB. L'impostazione di un offset a strisce può essere utile in circostanze particolari, ma in generale è meglio non specificarlo e utilizzare l'impostazione predefinita. ### Layout di file progressivi È possibile specificare una configurazione PFL (Progressive File Layout) per una directory per specificare diverse configurazioni di stripe per file di piccole e grandi dimensioni prima di popolarla. Ad esempio, è possibile impostare un PFL nella directory di primo livello prima che i dati vengano scritti su un nuovo file system. Per specificare una configurazione PFL, utilizzate il `lfs setstripe` comando con `-E` opzioni per specificare i componenti di layout per file di dimensioni diverse, come il comando seguente: ``` lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname/directory ``` Questo comando imposta quattro componenti di layout: + Il primo componente (`-E 100M -c 1`) indica un valore di conteggio delle strisce pari a 1 per file di dimensioni fino a 100 MiB. + Il secondo componente (`-E 10G -c 8`) indica un numero di strisce pari a 8 per file di dimensioni fino a 10 GiB. + Il terzo componente (`-E 100G -c 16`) indica un numero di strisce pari a 16 per file di dimensioni fino a 100 GiB. + Il quarto componente (`-E -1 -c 32`) indica un numero di strisce pari a 32 per file di dimensioni superiori a 100 GiB. **Importante** L'aggiunta di dati a un file creato con un layout PFL popolerà tutti i relativi componenti di layout. Ad esempio, con il comando a 4 componenti mostrato sopra, se create un file da 1 MiB e poi aggiungete dati alla fine del file, il layout del file si espanderà fino ad avere un numero di strisce pari a -1, vale a dire tutto il sistema. OSTs Ciò non significa che i dati verranno scritti su ogni OST, ma un'operazione come la lettura della lunghezza del file invierà una richiesta in parallelo a ogni OST, aggiungendo un carico di rete significativo al file system. Pertanto, fate attenzione a limitare il numero di strisce per qualsiasi file di piccola o media lunghezza a cui successivamente possono essere aggiunti dati. Poiché i file di log di solito crescono con l'aggiunta di nuovi record, Amazon FSx for Lustre assegna un numero di strisce predefinito pari a 1 a qualsiasi file creato in modalità di aggiunta, indipendentemente dalla configurazione di stripe predefinita specificata dalla directory principale. La configurazione PFL predefinita sui file system Amazon FSx for Lustre creata dopo il 25 agosto 2023 viene impostata con questo comando: ``` lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname ``` I clienti con carichi di lavoro che hanno un accesso altamente simultaneo a file di medie e grandi dimensioni trarranno probabilmente vantaggio da un layout con più strisce OSTs per dimensioni più piccole e striping su tutti i file più grandi, come mostrato nel layout di esempio a quattro componenti. ## Monitoraggio delle prestazioni e dell'utilizzo Ogni minuto, Amazon FSx for Lustre invia ad Amazon i parametri di utilizzo per ogni disco (MDT e OST). CloudWatch Per visualizzare i dettagli aggregati sull'utilizzo del file system, puoi consultare la statistica Sum di ogni metrica. Ad esempio, la somma delle `DataReadBytes` statistiche riporta la velocità di lettura totale registrata da tutti gli utenti di un file system. OSTs Analogamente, la somma delle `FreeDataStorageCapacity` statistiche riporta la capacità di archiviazione totale disponibile per i dati dei file nel file system. Per ulteriori informazioni sul monitoraggio delle prestazioni del file system, vedere[Monitoraggio dei file system Amazon FSx for Lustre](monitoring_overview.md). # Caratteristiche prestazionali delle classi di storage SSD e HDD Il throughput supportato da un file system FSx for Lustre dotato di classe di archiviazione SSD o HDD è proporzionale alla sua capacità di archiviazione. I file system Amazon FSx for Lustre si adattano a più velocità effettiva e milioni TBps di IOPS. Amazon FSx for Lustre supporta anche l'accesso simultaneo allo stesso file o directory da migliaia di istanze di calcolo. Questo accesso consente il checkpoint rapido dei dati dalla memoria dell'applicazione allo storage, una tecnica comune nell'High Performance Computing (HPC). È possibile aumentare la quantità di storage e la capacità di throughput in base alle esigenze in qualsiasi momento dopo la creazione del file system. Per ulteriori informazioni, consulta [Gestione della capacità di archiviazione](managing-storage-capacity.md). FSx i file system for Lustre forniscono una velocità di lettura a raffica utilizzando un meccanismo di I/O credito di rete per allocare la larghezza di banda della rete in base all'utilizzo medio della larghezza di banda. I file system accumulano crediti quando l'utilizzo della larghezza di banda di rete è inferiore ai limiti di base e possono utilizzarli quando eseguono trasferimenti di dati di rete. Le tabelle seguenti mostrano le prestazioni per cui sono progettate le opzioni di implementazione di FSx for Lustre che utilizzano classi di archiviazione SSD e HDD. **Prestazioni del file system per le opzioni di archiviazione SSD** | Tipo di distribuzione | **Throughput di rete (MBps/TiB di storage fornito)** | **IOPS di rete (IOPS/TiB di storage fornito)** | **Archiviazione cache (GiB RAM/TiB di storage forniti)** | **Latenze del disco per operazione su file (millisecondi, P50)** | **Throughput del disco (MBps/TiB di storage o cache SSD fornita)** | | --- |--- |--- |--- |--- |--- | | **** | **Linea di base** | **Scoppio** | **** | **** | **** | **Linea di base** | **Scoppio** | | --- |--- |--- |--- |--- |--- |--- |--- | | GRATTO\$12 | 200 | 1300 | Decine di migliaia di valori baseCentinaia di migliaia sono scoppiate | 6.7 | Metadati: sub-ms Dati: sub-ms | 200 (letto) 100 (scrittura) | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENTE -125 | 320 | 1300 | 3.4 | 125 | 500 | | --- |--- |--- |--- |--- |--- | | PERSISTENTE-250 | 640 | 1300 | 6.8 | 250 | 500 | | --- |--- |--- |--- |--- |--- | | PERSISTENTE-500 | 1300 | ‐ | 13.7 | 500 | ‐ | | --- |--- |--- |--- |--- |--- | | PERSISTENTE - 1000 | 2600 | ‐ | 27,3 | 1000 | ‐ | | --- |--- |--- |--- |--- |--- | **Prestazioni del file system per le opzioni di archiviazione su HDD** | Tipo di distribuzione | **Throughput di rete (MBps/TiB di storage o cache SSD fornita)** | **IOPS di rete (IOPS/TiB di storage fornito)** | **Archiviazione cache (GiB RAM/TiB di storage forniti)** | **Latenze del disco per operazione su file (millisecondi, P50)** | **Throughput del disco (MBps/TiB di storage o cache SSD fornita)** | | --- |--- |--- |--- |--- |--- | | **** | **Linea di base** | **Scoppio** | | **Linea di base** | **Scoppio** | | --- |--- |--- |--- |--- |--- | | PERSISTENTE-12 | | --- | | archiviazione su HDD | 40 | 375\$1 | Decine di migliaia (linea di base) Centinaia di migliaia sono scoppiate | 0,4 memoria | Metadati: sub-ms Dati: ms a una cifra | 12 | 80 (letto) 50 (scrittura) | | --- |--- |--- |--- |--- |--- |--- |--- | | Cache di lettura SSD | 200 | 1.900 | 200 cache SSD | Dati: sub-ms | 200 | - | | --- |--- |--- |--- |--- |--- |--- | | PERSISTENTE-40 | | --- | | archiviazione HDD | 150 | 1.300\$1 | Decine di migliaia di valori di base Centinaia di migliaia sono scoppiate | 1.5 | Metadati: sub-ms Dati: ms a una cifra | 40 | 250 (letto) 150 (scrittura) | | --- |--- |--- |--- |--- |--- |--- |--- | | Cache di lettura SSD | 750 | 6500 | 200 unità di cache SSD | Dati: sub-ms | 200 | - | | --- |--- |--- |--- |--- |--- |--- | **Prestazioni del file system per le opzioni di storage SSD della generazione precedente** | Tipo di distribuzione | **Throughput di rete (MBps per TiB di storage fornito)** | **IOPS di rete (IOPS per TiB di storage fornito)** | **Archiviazione cache (GiB per TiB di storage fornito)** | **Latenze su disco per operazione su file (millisecondi, P50)** | **Throughput del disco (MBps per TiB di storage o cache SSD fornita)** | | --- |--- |--- |--- |--- |--- | | **** | **Linea di base** | **Scoppio** | **** | **** | **** | **Linea di base** | **Scoppio** | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENTE-50 | 250 | 1.300\$1 | Decine di migliaia di valori di baseCentinaia di migliaia sono scoppiate | 2,2 RAM | Metadati: sub-ms Dati: sub-ms | 50 | 240 | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENTE-100 | 500 | 1.300\$1 | 4,4 RAM | 100 | 240 | | --- |--- |--- |--- |--- |--- | | PERSISTENTE-200 | 750 | 1.300\$1 | 8,8 RAM | 200 | 240 | | --- |--- |--- |--- |--- |--- | **Nota** \$1 I file system persistenti nei seguenti paesi Regioni AWS forniscono un'espansione della rete fino a 530 per MBps TiB di storage: Africa (Città del Capo), Asia Pacifico (Hong Kong), Asia Pacifico (Osaka), Asia Pacifico (Singapore), Canada (Centrale), Europa (Francoforte), Europa (Londra), Europa (Milano), Europa (Stoccolma), Medio Oriente (Bahrein), Sud America (San Paolo), Cina e Stati Uniti occidentali (Los Angeles). ## Esempio: velocità effettiva aggregata di base e burst L'esempio seguente illustra in che modo la capacità di storage e la velocità effettiva del disco influiscono sulle prestazioni del file system. Un file system persistente con una capacità di storage di 4,8 TiB e 50 per TiB di throughput MBps per unità di storage fornisce un throughput aggregato del disco di base di 240 e un throughput del disco burst di MBps 1,152. GBps Indipendentemente dalle dimensioni del file system, Amazon FSx for Lustre offre latenze costanti inferiori al millisecondo per le operazioni sui file. # Caratteristiche prestazionali della classe di storage Intelligent-Tiering La classe di storage FSx for Lustre Intelligent-Tiering offre uno storage elastico e ottimizzato in termini di costi per carichi di lavoro che tradizionalmente vengono eseguiti su file system di archiviazione di file ad alte prestazioni basati su HDD o misti HDD/SDD basati su HDD/SDD. I file system che utilizzano la classe di storage Intelligent-Tiering utilizzano uno storage regionale completamente elastico e intelligente su più livelli, che cresce e si riduce automaticamente per adattarsi al carico di lavoro man mano che cambia. Per informazioni su come suddivide i dati su più livelli, consulta. [In che modo la classe di storage Intelligent-Tiering suddivide i dati su più livelli](using-fsx-lustre.md#how-INT-tiering-works) Il throughput supportato da un file system FSx for Lustre con classe di storage Intelligent-Tiering è indipendente dallo storage. I file system Intelligent-Tiering sono scalabili fino a raggiungere livelli multipli di throughput e milioni di IOPS. TBps I file system che utilizzano la classe di storage Intelligent-Tiering forniscono anche una cache di lettura SSD opzionale predisposta per l'accesso a bassa latenza ai dati a cui si accede di frequente. Per impostazione predefinita, Amazon FSx for Lustre fornisce una cache di lettura SSD per i metadati a cui si accede di frequente. Poiché la maggior parte dei carichi di lavoro tende ad essere impegnativa in termini di lettura e funziona attivamente solo con un piccolo sottoinsieme del set di dati complessivo in un dato momento, il modello ibrido di storage Intelligent-Tiering e le cache di lettura SSD consente ai file system che utilizzano la classe di storage Intelligent-Tiering di fornire uno storage con prestazioni paragonabili ai file system SSD per la maggior parte dei carichi di lavoro, garantendo al contempo risparmi sui costi di archiviazione rispetto alle classi di storage SSD e HDD. Durante la lettura e la scrittura di dati su un file system Intelligent-Tiering, in particolare dati a cui non è stato effettuato l'accesso di recente o non è stato effettuato abbastanza frequentemente da trovarsi nella cache in memoria del file server, le prestazioni dipendono dalla dimensione della cache di lettura SSD. L'accesso ai dati dallo storage Intelligent-Tiering ha time-to-first-byte latenze di circa decine di millisecondi e costi per richiesta, mentre gli accessi dalla cache di lettura SSD restituiscono con una latenza inferiore al millisecondo e senza costi per richiesta. Quando si configura la dimensione della cache di lettura SSD per il file system, è necessario considerare sia la dimensione del set di dati a cui si accede di frequente all'interno del carico di lavoro sia la sensibilità del carico di lavoro a una latenza più elevata per le letture di dati a cui si accede meno frequentemente. È possibile passare da una modalità di dimensionamento della cache di lettura SSD all'altra dopo la creazione del file system e aumentare o ridurre la cache. Per ulteriori informazioni su come modificare la cache di lettura dell'SSD, consulta. [Gestione della cache di lettura SSD fornita](managing-ssd-read-cache.md) Una richiesta di scrittura si verifica quando FSx for Lustre scrive un blocco di dati sullo storage Intelligent-Tiering. Quando si scrivono dati sul file system, le richieste di scrittura vengono aggregate e scritte sullo storage Intelligent-Tiering, aumentando la velocità effettiva e riducendo i costi delle richieste. Le letture possono essere eseguite dalla cache in memoria del file server, dalla cache di lettura SSD o direttamente dallo storage Intelligent-Tiering. Quando viene fornita una lettura dallo storage Intelligent-Tiering, viene effettuata una richiesta di lettura per ogni blocco di dati recuperati. Quando leggi i dati in sequenza, FSx for Lustre prerecupererà i dati per migliorare le prestazioni. *I dati della cache in memoria sui file system che utilizzano la classe di storage Intelligent-Tiering vengono forniti direttamente al client richiedente come I/O di rete.* *Quando un client accede a dati che non si trovano nella cache in memoria, questi vengono letti dalla cache di lettura SSD o dallo storage Intelligent-Tiering come I/O su disco e quindi serviti al client come I/O di rete.* ## Prestazioni del file system per Intelligent-Tiering La tabella seguente mostra le prestazioni FSx per cui sono progettati i file system Lustre Intelligent-Tiering. | Capacità di throughput assegnata () MBps | **Throughput di rete () MBps** | **IOPS di rete** | **Archiviazione cache in memoria (GB)** | **Throughput massimo su disco di cache SSD () MBps** | **Numero massimo di IOPS su disco di cache SSD** | | --- |--- |--- |--- |--- |--- | | **** | **Linea di base** | **Scoppio** | **** | **** | **** | **Linea di base** | **Scoppio** | | --- |--- |--- |--- |--- |--- |--- |--- | | Ogni 4000 | 12500 | ‐ | Centinaia di migliaia | 76,8 | 4000 | 160000 | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | # Suggerimenti per le prestazioni Quando usi Amazon FSx for Lustre, tieni a mente i seguenti suggerimenti sulle prestazioni. Per i limiti del servizio, consulta[Quote di servizio per Amazon FSx for Lustre](limits.md). + ** I/O Dimensioni medie**: poiché Amazon FSx for Lustre è un file system di rete, ogni operazione sui file passa attraverso un viaggio di andata e ritorno tra il client e Amazon FSx for Lustre, con un piccolo sovraccarico di latenza. A causa di questa latenza per operazione, la velocità effettiva complessiva generalmente aumenta all'aumentare della I/O dimensione media, poiché il sovraccarico viene ammortizzato su una maggiore quantità di dati. + **Modello di richiesta**: abilitando le scritture asincrone sul file system, le operazioni di scrittura in sospeso vengono memorizzate nel buffer sull'istanza Amazon EC2 prima di essere scritte su Amazon for Lustre in modo asincrono. FSx Le scritture asincrone presentano generalmente delle latenze inferiori. Quando si eseguono delle scritture asincrone, il kernel utilizza della memoria aggiuntiva per la memorizzazione nella cache. Un file system che ha abilitato le scritture sincrone invia richieste sincrone ad Amazon FSx for Lustre. Ogni operazione passa attraverso un viaggio di andata e ritorno tra il cliente e Amazon FSx for Lustre. **Nota** La modalità di richiesta presenta compromessi in termini di consistenza (se si utilizzano molteplici istanze Amazon EC2) e di velocità. + **Limita la dimensione della directory**: per ottenere prestazioni ottimali dei metadati sui file system Persistent 2 FSx for Lustre, limita ogni directory a meno di 100.000 file. La limitazione del numero di file in una directory riduce il tempo necessario al file system per acquisire un blocco sulla directory principale. + **Istanze Amazon EC2: le** applicazioni che eseguono un gran numero di operazioni di lettura e scrittura richiedono probabilmente più memoria o capacità di elaborazione rispetto alle applicazioni che non lo fanno. Quando avvii le istanze Amazon EC2 per un carico di lavoro ad alta intensità di calcolo, scegli i tipi di istanza che hanno la quantità di queste risorse necessaria alla tua applicazione. Le caratteristiche prestazionali dei file system Amazon FSx for Lustre non dipendono dall'uso di istanze ottimizzate per Amazon EBS. + **Ottimizzazione consigliata delle istanze del client per prestazioni ottimali** 1. Per i tipi di istanze client con memoria superiore a 64 GiB, consigliamo di applicare la seguente ottimizzazione: ``` sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs> ``` 1. Per i tipi di istanze client con più di 64 core vCPU, consigliamo di applicare la seguente ottimizzazione: ``` echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf # reload all kernel modules to apply the above two settings sudo reboot ``` Dopo aver montato il client, è necessario applicare la seguente ottimizzazione: ``` sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50 ``` 1. Per ottimizzare le prestazioni per l'elenco delle directory (ls), è necessario applicare la seguente ottimizzazione: ``` sudo lctl set_param llite.*.statahead_max=512 sudo lctl set_param llite.*.statahead_agl=1 if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then sudo lctl set_param llite.*.statahead_xattr=1 else echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning" fi ``` Nota che `lctl set_param` è noto che non persiste dopo il riavvio. Poiché questi parametri non possono essere impostati in modo permanente dal lato client, si consiglia di implementare un boot cron job per impostare la configurazione con le ottimizzazioni consigliate. + **Equilibrio del carico di lavoro OSTs: in** alcuni casi, il carico di lavoro non determina il throughput aggregato che il file system è in grado di fornire (200 per MBps TiB di storage). In tal caso, puoi utilizzare le CloudWatch metriche per risolvere i problemi se le prestazioni sono influenzate da uno squilibrio nei modelli del carico di lavoro. I/O Per identificare se questa è la causa, consulta la CloudWatch metrica Maximum per Amazon FSx for Lustre. In alcuni casi, questa statistica mostra un carico pari o superiore a 240 MBps di throughput (la capacità di throughput di un singolo disco Amazon for Lustre da 1,2 TiB). FSx In questi casi, il carico di lavoro non è distribuito uniformemente sui dischi. In tal caso, puoi utilizzare il `lfs setstripe` comando per modificare lo striping dei file a cui il tuo carico di lavoro accede più frequentemente. Per prestazioni ottimali, suddividete i file con requisiti di throughput elevati in tutto il OSTs file system. Se i tuoi file vengono importati da un archivio di dati, puoi adottare un altro approccio per suddividere i file ad alta velocità in modo uniforme su tutto il tuo. OSTs A tale scopo, puoi modificare il `ImportedFileChunkSize` parametro durante la creazione del tuo prossimo file system Amazon FSx for Lustre. Ad esempio, supponiamo che il carico di lavoro utilizzi un file system da 7,0 TiB (composto da 6 x 1,17 TiB) e debba garantire un throughput elevato su file da 2,4 GiB OSTs. In questo caso, potete impostare il valore in modo che i file siano distribuiti in modo uniforme su tutto il file system`ImportedFileChunkSize`. `(2.4 GiB / 6 OSTs) = 400 MiB` OSTs + **Lustreclient per Metadata IOPS**: se nel tuo file system è specificata una configurazione di metadati, ti consigliamo di installare un client Lustre 2.15 o un client Lustre 2.12 con una di queste versioni del sistema operativo: Amazon Linux 2023; Amazon Linux 2; Red Hat/Rocky Linux 8.9, 8.10 o 9.x; CentOS 8.9 o 8.10; Ubuntu 22\$1 con kernel 6.2, 6.5 o 6.8 o Ubuntu 20. ## Considerazioni sulle prestazioni di Intelligent-Tiering Ecco alcune importanti considerazioni sulle prestazioni quando si lavora con i file system che utilizzano la classe di storage Intelligent-Tiering: + I carichi di lavoro che leggono dati di I/O dimensioni inferiori richiederanno una maggiore concorrenza e comporteranno costi di richiesta maggiori per raggiungere lo stesso throughput dei carichi di lavoro che utilizzano grandi dimensioni a causa della maggiore latenza dei livelli di storage Intelligent-Tiering. I/O Consigliamo di configurare la cache di lettura SSD sufficientemente grande da supportare una concorrenza e un throughput più elevati quando si lavora con I/O di dimensioni inferiori. + Il numero massimo di IOPS su disco che i client possono gestire con un file system Intelligent-Tiering dipende dai modelli di accesso specifici del carico di lavoro e dal fatto che sia stata predisposta una cache di lettura SSD. Per i carichi di lavoro con accesso casuale, i client possono in genere ottenere IOPS molto più elevati se i dati sono memorizzati nella cache di lettura SSD rispetto a quando i dati non sono presenti nella cache. + La classe di storage Intelligent-Tiering supporta il read-ahead per ottimizzare le prestazioni per le richieste di lettura sequenziali. Si consiglia di configurare il modello di accesso ai dati in sequenza, ove possibile, per consentire il recupero anticipato dei dati e prestazioni superiori.