Condividi tramite

Migliorare le prestazioni per le condivisioni file di Azure NFS

  • Articolo

Questo articolo illustra come migliorare le prestazioni per le condivisioni file di Azure NFS (Network File System).

Si applica a

Tipo di condivisione file SMB NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona No, questo articolo non si applica alle condivisioni file di Azure SMB standard con ridondanza locale/archiviazione con ridondanza della zona. Le condivisioni NFS sono disponibili solo nelle condivisioni file di Azure Premium.
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona No, questo articolo non si applica alle condivisioni file standard di Azure SMB di Azure grS/GZRS. NFS è disponibile solo nelle condivisioni file di Azure Premium.
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona No, questo articolo non si applica alle condivisioni file di Azure SMB Premium. Sì, questo articolo si applica alle condivisioni file di Azure NFS Premium.

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 file system montato, che rappresenta l'opzione di montaggio sul lato client per le dimensioni del rsizebuffer 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 per le versioni 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 (Transmission Control Protocol) tra il client e il servizio File Premium di Azure per NFSv4.1.

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, riducendo i costi di calcolo di quasi il 70% fornendo miglioramenti significativi nelle operazioni di I/O al secondo (IOPS) e velocità effettiva su larga scala. Vedi la tabella seguente.

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.

Screenshot che mostra un miglioramento medio delle operazioni di I/O al secondo quando si usa nconnect con condivisioni file di Azure NFS.

Screenshot che mostra un miglioramento medio della velocità effettiva quando si usa nconnect con condivisioni file di Azure NFS.

Raccomandazioni per nconnect

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 le macchine virtuali client per evitare di essere limitate dalla larghezza di banda di rete prevista. Non sono necessari più controller di interfaccia di rete (NIC) 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 perché 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: nconnect configurazione per montaggio su endpoint privato con più account di archiviazione (supportati)

  • StorageAccount.file.core.windows.net = 10.10.10.10
  • StorageAccount2.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: nconnect configurazione per montaggio su endpoint pubblico (non supportato)

  • StorageAccount.file.core.windows.net = 52.239.238.8
  • StorageAccount2.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: nconnect configurazione per montaggio su endpoint privato con più condivisioni in un singolo account di archiviazione (non supportato)

  • StorageAccount.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 è vantaggioso per il carico di lavoro. Gli scenari evidenziati in verde sono consigliati, mentre gli scenari evidenziati in rosso non sono. Gli scenari evidenziati in giallo sono neutri.

Screenshot che mostra vari scenari di I O di lettura e scrittura con latenza corrispondente per indicare quando nconnect è consigliabile.

Vedi anche