Migliorare le prestazioni della condivisione file di Azure NFS

Questo articolo illustra come migliorare le prestazioni per le condivisioni file di Azure NFS.

Si applica a

Tipo di condivisione file	SMB	NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona

Aumentare le dimensioni read-ahead per migliorare la velocità effettiva di lettura

Il read_ahead_kb parametro kernel in Linux rappresenta la quantità di dati che devono essere "letti in anticipo" o prelettura durante un'operazione di lettura sequenziale. Le versioni del kernel Linux precedenti alla 5.4 impostano il valore read-ahead sull'equivalente di 15 volte il rsize file system montato (opzione di montaggio lato client per le dimensioni del buffer di lettura). In questo modo il valore read-ahead è sufficientemente elevato per migliorare la velocità effettiva di lettura sequenziale del client nella maggior parte dei casi.

Tuttavia, a partire dal kernel Linux versione 5.4, il client Linux NFS usa un valore predefinito read_ahead_kb di 128 KiB. Questo valore ridotto potrebbe ridurre la quantità di velocità effettiva di lettura per file di grandi dimensioni. I clienti che aggiornano le versioni di Linux con il valore read-ahead più grande a quelli con il valore predefinito di 128 KiB potrebbero riscontrare una diminuzione delle prestazioni di lettura sequenziale.

Per i kernel Linux 5.4 o versioni successive, è consigliabile impostare in modo permanente su read_ahead_kb 15 MiB per migliorare le prestazioni.

Per modificare questo valore, impostare le dimensioni read-ahead aggiungendo una regola in udev, un gestore di dispositivi kernel Linux. Seguire questa procedura:

1. In un editor di testo creare il file /etc/udev/rules.d/99-nfs.rules immettendo e salvando il testo seguente:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. In una console applicare la regola udev eseguendo il comando udevadm come utente con privilegi avanzati e ricaricando i file delle regole e altri database. È necessario eseguire questo comando una sola volta per rendere udev consapevole del nuovo file.

   sudo udevadm control --reload
   

Nconnect

Nconnect è un'opzione di montaggio Linux lato client che aumenta le prestazioni su larga scala consentendo di usare più connessioni TCP tra il client e il servizio File Premium di Azure per NFSv4.1, mantenendo al tempo stesso la resilienza della piattaforma distribuita come servizio (PaaS).

Vantaggi di nconnect

Con nconnectè possibile aumentare le prestazioni su larga scala usando un minor numero di computer client per ridurre il costo totale di proprietà (TCO). Nconnect aumenta le prestazioni usando più canali TCP su una o più schede di interfaccia di rete, usando client singoli o multipli. Senza nconnect, sono necessari circa 20 computer client per raggiungere i limiti di scalabilità della larghezza di banda (10 GiB/s) offerti dalle dimensioni massime del provisioning di condivisioni file di Azure Premium. Con nconnectè possibile raggiungere questi limiti usando solo 6-7 client. Si tratta di una riduzione del 70% dei costi di calcolo, offrendo miglioramenti significativi alle operazioni di I/O al secondo e alla velocità effettiva su larga scala (vedere la tabella).

Metrica (operazione)	Dimensioni di I/O	Miglioramento delle prestazioni
Operazioni di I/O al secondo (scrittura)	64K, 1024K	3x
Operazioni di I/O al secondo (lettura)	Tutte le dimensioni di I/O	2-4x
Velocità effettiva (scrittura)	64K, 1024K	3x
Velocità effettiva (lettura)	Tutte le dimensioni di I/O	2-4x

Prerequisiti

• Le distribuzioni Linux più recenti supportano nconnectcompletamente . Per le distribuzioni Linux precedenti, assicurarsi che la versione del kernel Linux sia 5.3 o successiva.
• La configurazione per montaggio è supportata solo quando viene usata una singola condivisione file per ogni account di archiviazione su un endpoint privato.

Impatto sulle prestazioni di nconnect

Sono stati ottenuti i risultati delle prestazioni seguenti quando si usa l'opzione nconnect di montaggio con condivisioni file di Azure NFS nei client Linux su larga scala. Per altre informazioni su come sono stati ottenuti questi risultati, vedere Configurazione dei test delle prestazioni.

Consigli pernconnect

Seguire queste raccomandazioni per ottenere i risultati migliori da nconnect.

Impostare nconnect=4

Anche se File di Azure supporta l'impostazione nconnect massima di 16, è consigliabile configurare le opzioni di montaggio con l'impostazione ottimale di nconnect=4. Attualmente, non esistono miglioramenti oltre quattro canali per l'implementazione File di Azure di nconnect. Infatti, il superamento di quattro canali a una singola condivisione file di Azure da un singolo client potrebbe influire negativamente sulle prestazioni a causa della saturazione della rete TCP.

Ridimensionare attentamente le macchine virtuali

A seconda dei requisiti del carico di lavoro, è importante ridimensionare correttamente i computer client per evitare di essere limitati dalla larghezza di banda di rete prevista. Non sono necessarie più schede di interfaccia di rete per ottenere la velocità effettiva di rete prevista. Anche se è comune usare macchine virtuali per utilizzo generico con File di Azure, sono disponibili vari tipi di vm a seconda delle esigenze del carico di lavoro e della disponibilità dell'area. Per altre informazioni, vedere Selettore di macchine virtuali di Azure.

Mantenere la profondità della coda minore o uguale a 64

La profondità della coda è il numero di richieste di I/O in sospeso che possono essere eseguite da una risorsa di archiviazione. Non è consigliabile superare la profondità ottimale della coda di 64. In questo caso, non verranno visualizzati altri miglioramenti delle prestazioni. Per altre informazioni, vedere Profondità coda.

Nconnect Configurazione per montaggio

Se un carico di lavoro richiede il montaggio di più condivisioni con uno o più account di archiviazione con impostazioni diverse nconnect da un singolo client, non è possibile garantire che tali impostazioni vengano mantenute durante il montaggio sull'endpoint pubblico. La configurazione per montaggio è supportata solo quando viene usata una singola condivisione file di Azure per ogni account di archiviazione sull'endpoint privato, come descritto nello scenario 1.

Scenario 1: (supportato) nconnect per ogni configurazione di montaggio su endpoint privato con più account di archiviazione

• ArchiviazioneAccount.file.core.windows.net = 10.10.10.10
• ArchiviazioneAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Scenario 2: (non supportato) nconnect per ogni configurazione di montaggio sull'endpoint pubblico

• ArchiviazioneAccount.file.core.windows.net = 52.239.238.8
• ArchiviazioneAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Nota

Anche se l'account di archiviazione si risolve in un indirizzo IP diverso, non è possibile garantire che l'indirizzo venga mantenuto perché gli endpoint pubblici non sono indirizzi statici.

Scenario 3: (non supportato) nconnect per ogni configurazione di montaggio su endpoint privato con più condivisioni in un singolo account di archiviazione

• ArchiviazioneAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Configurazione dei test delle prestazioni

Sono stati usati gli strumenti di benchmark e risorse seguenti per ottenere e misurare i risultati descritti in questo articolo.

• Client singolo: macchina virtuale di Azure (serie DSv4) con una singola scheda di interfaccia di rete
• Sistema operativo: Linux (Ubuntu 20.40)
• Archiviazione NFS: File di Azure condivisione file Premium (con provisioning di 30 TiB, set nconnect=4)

Dimensione	vCPU	Memory	Archiviazione temporanea (SSD)	Numero massimo di dischi dati	Numero massimo di schede di interfaccia di rete	Larghezza di banda di rete prevista
Standard_D16_v4	16	64 GiB	Solo archiviazione remota	32	8	12.500 Mbps

Strumenti e test di benchmarking

È stato usato un tester di I/O flessibile (FIO), uno strumento di I/O su disco open source gratuito usato sia per benchmark che per la verifica hardware/stress. Per installare FIO, seguire la sezione Pacchetti binari nel file FIO README da installare per la piattaforma preferita.

Anche se questi test si concentrano su modelli di accesso di I/O casuali, si ottengono risultati simili quando si usano operazioni di I/O sequenziali.

Operazioni di I/O al secondo elevate: letture al 100%

Dimensioni di I/O 4k - lettura casuale - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Dimensioni di I/O 8k - lettura casuale - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Velocità effettiva elevata: letture al 100%

Dimensioni di I/O 64k - lettura casuale - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Dimensioni di I/O 1024k - Lettura casuale 100% - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Operazioni di I/O al secondo elevate: scritture al 100%

Dimensioni di I/O 4k - Scrittura casuale al 100% - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Dimensioni di I/O 8k - Scrittura casuale al 100% - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Velocità effettiva elevata: 100% scritture

Dimensioni di I/O 64k - Scrittura casuale al 100% - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Dimensioni di I/O 1024k - Scrittura casuale 100% - Profondità coda 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Considerazioni sulle prestazioni per nconnect

Quando si usa l'opzione nconnect di montaggio, è consigliabile valutare attentamente i carichi di lavoro con le caratteristiche seguenti:

• Carichi di lavoro di scrittura sensibili alla latenza che sono a thread singolo e/o usano una profondità bassa della coda (inferiore a 16)
• Carichi di lavoro di lettura sensibili alla latenza che sono a thread singolo e/o usano una profondità bassa della coda in combinazione con dimensioni di I/O inferiori

Non tutti i carichi di lavoro richiedono operazioni di I/O al secondo su larga scala o prestazioni. Per i carichi di lavoro di scalabilità più piccoli, nconnect potrebbe non essere opportuno. Usare la tabella seguente per decidere se nconnect sarà vantaggioso per il carico di lavoro. Gli scenari evidenziati in verde sono consigliati, mentre quelli evidenziati in rosso non sono. Quelli evidenziati in giallo sono neutri.

Vedi anche

• Per istruzioni di montaggio, vedere Montare una condivisione file NFS in Linux.
• Per un elenco completo delle opzioni di montaggio, vedere la pagina di gestione NFS di Linux.
• Per informazioni su latenza, operazioni di I/O al secondo, velocità effettiva e altri concetti relativi alle prestazioni, vedere Informazioni sulle prestazioni File di Azure.