Opzioni di montaggio e configurazioni delle macchine virtuali client

Completato

In questo modulo verranno illustrate opzioni di montaggio e configurazioni delle macchine virtuali client in grado di migliorare le prestazioni quando si eseguono applicazioni HPC o EDA in Azure NetApp Files.

Nota

Le procedure consigliate per i client NFS dipendono dalle applicazioni in uso. I suggerimenti seguenti non sono imperativi e possono essere sostituiti da raccomandazioni dell'applicazione o da test sul carico di lavoro. È pertanto altamente consigliabile testare queste procedure prima di distribuirle in produzione.

Usare opzioni di montaggio actimeo e nocto per migliorare le prestazioni

Per migliorare le prestazioni in set di dati relativamente statici e scenari di lettura di grandi dimensioni è possibile usare le opzioni di montaggio seguenti:

• actimeo: controlla che il client NFS memorizzi nella cache gli attributi di una directory. Se non viene specificato, il client NFS usa il valore massimo predefinito pari a 60 secondi.
• nocto: è l'acronimo di "no close-to-open", che significa che un file può essere chiuso prima del completamento di una scrittura per risparmiare tempo. Per impostazione predefinita, l'opzione nocto non viene impostata nelle opzioni di montaggio NFS. questo significa che tutti i file attendono il completamento delle scritture prima di consentire la chiusura.

La maggior parte delle applicazioni HPC, inclusa l'analisi esplorativa dei dati in questo scenario, include set di dati relativamente statici, ovvero non soggetti a modifiche frequenti. In tal caso, è possibile usare nocto e actimeo per ridurre le operazioni getattr o di accesso all'archiviazione e questo può essere utile per velocizzare l'applicazione.

Ad esempio, è consigliabile impostare "nocto,actimeo=600" (600 secondi o 10 minuti) per gli strumenti di analisi esplorativa dei dati e i volumi della libreria. Poiché questi file non cambiano, non è necessario mantenere la coerenza della cache. L'impostazione di queste opzioni di montaggio consente di ridurre le chiamate ai metadati, migliorando le prestazioni complessive.

Ottimizzare i parametri di sistema per ottenere prestazioni ottimali

Tuned è un daemon che può essere usato per monitorare e configurare i dispositivi connessi nei client Linux. Nella maggior parte dei casi tuned è installato per impostazione predefinita. Se non è installato, può essere aggiunto e abilitato per semplificare i parametri di ottimizzazione lato client con i modelli predefiniti integrati.

Eseguire i comandi seguenti per applicare l'ottimizzazione di base del server e della latenza tipica per le macchine virtuali client:

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

Alcuni o tutti i parametri di sistema seguenti (/etc/sysctl.conf) possono essere utili nelle macchine virtuali client di Linux per ottenere prestazioni ottimali. Se si dispone di macchine virtuali client con grandi quantità di RAM o con una larghezza di banda di rete superiore, ad esempio InfiniBand, è possibile impostare alcuni valori anche maggiori di quelli mostrati nell'esempio seguente.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Per rendere persistenti queste ottimizzazioni, eseguire:

sudo sysctl -P

Usare l'opzione di montaggio nconnect per espandere le connessioni di rete quando possibile

L'opzione di montaggio NFS nconnect ha introdotto la disponibilità generale nel kernel Linux 5.3 o versione successiva. Per controllare il kernel Linux della macchina virtuale client:

uname -r

Lo scopo di nconnect è offrire più connessioni di trasporto per ogni connessione TCP o punti di montaggio in un client. Questa tecnica consente di aumentare il parallelismo e le prestazioni per i montaggi NFS.

Minore è il numero di client, maggiore è il valore offerto da nconnect per migliorare le prestazioni, perché può potenzialmente utilizzare tutta la larghezza di banda di rete disponibile. Il suo valore diminuisce gradualmente all'aumentare del numero di client. Dal momento che è disponibile solo una certa larghezza di banda totale e il numero massimo di connessioni TCP può esaurirsi più rapidamente, questo può causare la negazione del servizio finché non si liberano connessioni TCP.

Azure NetApp Files consente un massimo di 128 richieste in elaborazione simultanee per ogni connessione TCP prima che venga applicata una limitazione (in cui le nuove richieste vengono accodate finché non vengono rese disponibili risorse), di conseguenza nconnect può essere utile per ampliare il numero di richieste in elaborazione consentite aumentando le connessioni TCP disponibili per punto di montaggio. Ad esempio, se nconnect è impostato per l'uso di otto connessioni TCP, il cliente ha potenzialmente a disposizione 1.024 (8x128) richieste.

I client Linux moderni consentono fino a 65.535 richieste per connessione (valore dinamico). Questo può potenzialmente sovraccaricare una coda di richieste in elaborazione disponibile di un volume di Azure NetApp Files e comportare risultati indesiderati in termini di prestazioni, in cui i client inviano più richieste di quelle che possono essere soddisfatte in un determinato momento. Per ridurre il rischio di impatto sulle prestazioni causato da questo comportamento, è consigliabile impostare sunrpc.tpc_max_slot_table_entries=256, o 512 se si usa nconnect=8 o 16, su un valore statico inferiore. Usa la tabella seguente come riferimento.

Nota

Questo valore può essere impostato in modo diverso a seconda del tipo di sistema operativo client Linux. Per informazioni dettagliate, vedere la documentazione del sistema operativo.

Valore nconnect	Numero massimo consigliato di voci della tabella di slot per TCP
0-1	128
2-4	256
6-8	512
>8	Nessuna modifica necessaria

Nota

L'opzione nconnect è disponibile solo per macchine virtuali con kernel Linux 5.3 o versione successiva. Durante l'aggiornamento del kernel potrebbe essere necessario riavviare la macchina virtuale. Ciò significa che questo potrebbe non essere applicabile in alcuni casi.

Usare NFSv3 invece di NFSv4.1 quando si considerano solo le prestazioni

NFSv3 è un protocollo senza stato. Questo significa che il client e il server non comunicano tra loro in merito ai file in uso. Il blocco viene attuato al di fuori dello stack di protocollo da NLM (Network Lock Manager), e questo pone alcuni problemi quando i blocchi diventano obsoleti e devono essere eliminati manualmente. I blocchi vengono attuati solo su richiesta dall'applicazione, pertanto in alcuni scenari potrebbe non essere necessario negoziare i blocchi. Dal momento che non sono presenti ID client, ID stato, ID sessione, stati di blocco e così via di cui tenere traccia, le prestazioni di NFSv3 tendono a essere migliori rispetto a NFSv4.1 in alcuni carichi di lavoro, in particolare in quelli che contano un numero di file elevato o molti metadati, come quelli di analisi esplorativa dei dati e sviluppo di software.

NFSv4.1 tiene traccia degli stati dei file, inclusi i blocchi. Quando in NFSv4.1 vengono usati molti file contemporaneamente, ogni file ottiene un ID stato e riceve un blocco. I file con stato comportano un sovraccarico per il carico di lavoro in termini di prestazioni, perché ogni stato e ogni blocco devono essere elaborati dal server NFS. In alcuni carichi di lavoro, come quello di analisi esplorativa dei dati, l'impatto sulle prestazioni di NFSv4.1 può essere compreso tra il 25% e il 75%. Con altri carichi di lavoro, ad esempio file di grandi dimensioni, operazioni di I/O di flusso o database, non si riscontra una riduzione delle prestazioni quando si usa NFSv4.1 e tali carichi possono addirittura beneficiare dei vantaggi offerti dalle operazioni composte usate dal protocollo.

Azure NetApp Files supporta sia NFSv3 che NFSv4.1. È consigliabile verificare quale sia la versione richiesta dall'applicazione, confrontando le somiglianze e le differenze tra le versioni di NFS (nonché eseguendo dei test) e creando il volume con la versione appropriata. Se necessario, è possibile configurare i volumi di Azure NetApp Files per una versione del protocollo diversa dopo la creazione.

Scegliere i valori corretti per le opzioni di montaggio rsize e wsize

Le opzioni di montaggio rsize (dimensioni di lettura) e wsize (dimensioni di scrittura) determinano la quantità di dati inviati tra il client NFS e il server per ogni pacchetto inviato. Ad esempio, se si imposta rsize o wsize su 65.536, è possibile inviare fino a 64 K di dati per ogni pacchetto. Se un'applicazione invia dati in blocchi più piccoli (ad esempio 8 K), la quantità di dati inviati dipende dalle opzioni di montaggio usate (ad esempio sync).

La procedura consigliata per Azure NetApp Files consiste nell'impostare lo stesso valore per rsize e wsize. In genere è consigliabile impostare entrambi i valori rsize e wsize come 262144 (256 K) nelle opzioni di montaggio.

Informazioni sulle opzioni di montaggio sync e async

Se si usa sync, ogni chiamata WRITE viene inviata con un comando FILE_SYNC. Questo significa che ogni chiamata WRITE deve essere riconosciuta dal server e sottoposta a commit sul disco prima che sia possibile avviare la chiamata WRITE successiva. L'opzione Sync viene usata quando un'applicazione deve garantire che tutti i dati vengono sottoposti a commit sul disco. Le chiamate WRITE inviano solo la quantità di dati specificata dalle dimensioni dei blocchi dell'applicazione. Questo significa che dimensioni dei blocchi più piccole generano maggiore traffico NFS indipendentemente dai valori wsize e rsize del montaggio, influendo negativamente sulle prestazioni.

Se si usa l'operazione di montaggio async (impostazione predefinita), un client può inviare più chiamate WRITE tramite NFS con il comando UNSTABLE. In questo scenario, i dati vengono scaricati su disco dopo un periodo di timeout. Il client NFS non è sempre in attesa che il server esegua il commit dei dati su disco prima di avviare la chiamata WRITE successiva, di conseguenza i tempi di completamento del processo per le operazioni di scrittura in montaggi con l'opzione async sono molto inferiori rispetto a quelli in montaggi con l'opzione sync. Quando si usano dimensioni dei blocchi inferiori usate con valori di rsize e wsize più elevati, le chiamate WRITE inviano tutti i dati consentiti in una singola chiamata NFS. Ad esempio, se si usano dimensioni dei blocchi da 8 K con un'opzione wsize/rsize impostata su 64 K, a ogni chiamata WRITE NFS verranno inviati otto blocchi per pacchetto (64 K/8 K). Quando l'operazione di scrittura viene scaricata sul disco, il server NFS invia una risposta FILE_SYNC al client NFS. In questo modo si riduce il numero totale di chiamate e risposte WRITE in una rete necessarie per completare un processo, con conseguente miglioramento delle prestazioni.

Ad esempio, in un test in cui è stato creato un file da 1 GiB specificando dimensioni dei blocchi da 8 K e l'opzione di montaggio sync sono state generate 262.144 chiamate e risposte WRITE e l'operazione è stata completata in 70 secondi. Creando lo stesso file con dimensioni dei blocchi da 8 K e l'opzione di montaggio async, sono state inviate solo 16.384 chiamate e risposte WRITE e l'operazione è stata completata in sei secondi.

Azure NetApp Files usa l'archiviazione NVRAM con alimentazione a batteria come cache del buffer per le operazioni di scrittura NFS in ingresso. I dati in NVRAM vengono scaricati sul disco ogni 10 secondi o fino al riempimento della cache del buffer (a seconda della circostanza che si verifica per prima). Poiché NVRAM è alimentata da una batteria, può far fronte a interruzioni impreviste e continuare a conservare i dati per un minimo di 72 ore, ad esempio nell'improbabile evento in cui un data center di Azure rimanga senza corrente. La combinazione di resilienza dei dati offerta da Azure NetApp Files e impatto sulle prestazioni associato all'uso dell'opzione di montaggio sync rende l'opzione async la scelta preferita in quasi tutti i casi d'uso.

Informazioni sull'impatto dei valori di wsize e rsize

Quando si effettua il montaggio tramite NFS, i valori di wsize e rsize determinano la quantità di dati che è possibile inviare a un server NFS per ogni chiamata NFS. Se non sono specificati nelle opzioni di montaggio, i valori vengono impostati su qualsiasi server NFS configurato. Azure NetApp Files usa dimensioni massime di trasferimento di 1 MB (1.048.576) per wsize e rsize. Questo valore non può essere modificato in Azure NetApp Files. Questo significa che se per i montaggi NFS non specificano i valori wsize e rsize, l'impostazione predefinita è 1 MB. I valori di wsize e rsize consigliati per i montaggi NFS nei carichi di lavoro di analisi esplorativa dei dati sono di 256 K.

Se un'applicazione deve creare un file da 1 GiB in un montaggio NFS di Azure NetApp Files, deve scrivere 1.048.576 KiB nell'archiviazione. Un esercizio matematico consente di dimostrare perché le prestazioni potrebbero migliorare se si impostano valori più efficienti per wsize e rsize.

• Se l'opzione wsize è impostata su 64 K, il numero di operazioni/pacchetti necessari per scrivere il file da 1 GiB è 1.048.576/64=16.384.
• Se l'opzione wsize è impostata su 256 K, il numero di operazioni/pacchetti necessari per scrivere il file da 1 GiB è 1.048.576/256=4.096.

Un minor numero di pacchetti/operazioni si traduce in una latenza di rete (che incide sul tempo di round trip) con un impatto minore sui carichi di lavoro e questo può essere un fattore critico nelle implementazioni cloud. Tuttavia, se l'applicazione scrive file di dimensioni inferiori ai valori di wsize/rsize, i valori più elevati di wsize/rsize non influiscono sulle prestazioni.

Blocchi di dati di dimensioni maggiori implicano un aumento dei cicli di elaborazione nel client e nel server, ma le CPU più moderne sono sufficientemente preparate per gestire tali richieste in modo efficiente.

La procedura consigliata per Azure NetApp Files consiste nell'impostare lo stesso valore per rsize e wsize. È consigliabile impostare entrambi i valori di rsize e wsize su 262.144 (256 K) nelle opzioni di montaggio. Questa impostazione riguarda una matrice di valori delle dimensioni di lettura e scrittura dell'applicazione.

Scegliere le impostazioni appropriate per le opzioni di montaggio hard, soft e intr

Le opzioni di montaggio hard e soft specificano se il programma che usa un file che si avvale di NFS debba eseguire una delle azioni seguenti:

• Se il server NFS non è disponibile, arrestarlo e attendere (hard) che torni online. Questa opzione sembra un blocco di montaggio sul client, ma garantisce che le operazioni in elaborazione non vadano perse in caso di interruzioni di rete. Al contrario, il client continuerà a ripetere la richiesta finché il server non risulta disponibile o fino al timeout dell'applicazione.
• Segnalare un errore (soft). I montaggi non si bloccano, ma le operazioni in elaborazione potrebbero andare perse.

L'opzione di montaggio intr consente l'interruzione dei processi NFS quando un montaggio viene indicato come montaggio hard, ad esempio CTRL+C. Quando applicabile, è consigliabile usare intr con montaggi hard per una combinazione ottimale di affidabilità e gestibilità dei dati.

Non prendere in considerazione la modifica delle unità massime di trasmissione

Le unità massime di trasmissione predefinite per le macchine virtuali di Azure sono 1.500 byte. Non è consigliabile aumentare il numero di unità massime di trasmissione delle macchine virtuali.

Esempio di montaggio

Il codice di esempio seguente monta un volume di Azure NetApp Files usando le procedure consigliate in precedenza per actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcp e MTU predefinite (1.500):

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

Nota

Async non viene specificato, perché l'impostazione predefinita per i montaggi NFS è async.