Procedure consigliate per le opzioni di montaggio NFS di Linux per Azure NetApp Files

  • Articolo

Questo articolo illustra le opzioni di montaggio e le procedure consigliate per l'uso con Azure NetApp Files.

Nconnect

L'uso dell'opzione nconnect di montaggio consente di specificare il numero di connessioni (flussi di rete) che devono essere stabilite tra il client NFS e l'endpoint NFS fino a un limite di 16. In genere, un client NFS usa una singola connessione tra se stessa e l'endpoint. Aumentando il numero di flussi di rete, i limiti superiori di I/O e velocità effettiva sono aumentati significativamente. I test hanno scoperto nconnect=8 di essere i più efficienti.

Quando si prepara un ambiente GRID di firma di accesso condiviso a più nodi per la produzione, è possibile notare una riduzione del 30% ripetibile in fase di esecuzione da 8 ore a 5,5 ore:

Opzione di montaggio Tempi di esecuzione del processo
No nconnect 8 ore
nconnect=8 5,5 ore

Entrambi i set di test hanno usato la stessa macchina virtuale E32-8_v4 e RHEL8.3, con read-ahead impostato su 15 MiB.

Quando si usa nconnect, tenere presenti le regole seguenti:

  • nconnect è supportato da Azure NetApp Files in tutte le principali distribuzioni Linux, ma solo nelle versioni più recenti:

    Versione di Linux NFSv3 (versione minima) NFSv4.1 (versione minima)
    Redhat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 o SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    Nota

    SLES15SP2 è la versione minima su edizione Standard in cui nconnect è supportata da Azure NetApp Files per NFSv4.1. Tutte le altre versioni specificate sono le prime versioni che hanno introdotto la nconnect funzionalità.

  • Tutti i montaggi da un singolo endpoint erediteranno l'impostazione nconnect della prima esportazione montata, come illustrato negli scenari seguenti:

    Scenario 1: nconnect viene usato dal primo montaggio. Di conseguenza, tutti i montaggi sullo stesso endpoint usano nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Scenario 2: nconnect non viene usato dal primo montaggio. Di conseguenza, nessun montaggio sullo stesso endpoint viene usato nconnect anche se nconnect può essere specificato.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Scenario 3: nconnect le impostazioni non vengono propagate tra endpoint di archiviazione separati. nconnect viene utilizzato dal montaggio proveniente da 10.10.10.10 ma non dal montaggio proveniente da 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect può essere usato per aumentare la concorrenza di archiviazione da qualsiasi client specificato.

Per informazioni dettagliate, vedere Procedure consigliate per la concorrenza linux per Azure NetApp Files.

Nconnect Considerazioni

Non è consigliabile usare nconnect e sec=krb5* montare insieme le opzioni. La riduzione delle prestazioni è stata osservata quando si usano le due opzioni in combinazione.

L'API GSS (Generic Security Standard Application Programming Interface) consente alle applicazioni di proteggere i dati inviati alle applicazioni peer. Questi dati potrebbero essere inviati da un client in un computer a un server in un altro computer. 

Quando nconnect viene usato in Linux, il contesto di sicurezza GSS viene condiviso tra tutte le nconnect connessioni a un determinato server. TCP è un trasporto affidabile che supporta la distribuzione di pacchetti non ordinati per gestire i pacchetti non ordinati in un flusso GSS, usando una finestra scorrevole di numeri di sequenza. Quando i pacchetti non presenti nella finestra di sequenza vengono ricevuti, il contesto di sicurezza viene rimosso e viene negoziato un nuovo contesto di sicurezza. Tutti i messaggi inviati con nel contesto ora rimosso non sono più validi, quindi richiedono di nuovo l'invio dei messaggi. Un numero maggiore di pacchetti in un'installazione nconnect causa pacchetti out-of-window frequenti, attivando il comportamento descritto. Con questo comportamento non è possibile dichiarare percentuali di riduzione specifiche.

Rsize e Wsize

Gli esempi in questa sezione forniscono informazioni sull'approccio all'ottimizzazione delle prestazioni. Potrebbe essere necessario apportare modifiche in base alle esigenze specifiche dell'applicazione.

I rsize flag e wsize impostano le dimensioni massime di trasferimento di un'operazione NFS. Se rsize o wsize non sono specificati sul montaggio, il client e il server negoziano le dimensioni maggiori supportate dai due. Attualmente, sia Azure NetApp Files che le distribuzioni Linux moderne supportano dimensioni di lettura e scrittura fino a 1.048.576 byte (1 MiB). Tuttavia, per una migliore velocità effettiva e latenza complessiva, Azure NetApp Files consiglia di impostare sia rsize che wsize non superiore a 262.144 byte (256 K). È possibile osservare che sia una maggiore latenza che una velocità effettiva ridotta quando si usano rsize e wsize superano i 256 KiB.

Ad esempio, Distribuire un sistema di scalabilità orizzontale di SAP HANA con nodo standby in macchine virtuali di Azure usando Azure NetApp Files in SU edizione Standard Linux Enterprise Server mostra 256-KiB rsize e wsize il massimo come indicato di seguito:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

Ad esempio, SAS Viya consiglia una dimensione di lettura e scrittura di 256 KiB e GRIGLIA di firma di accesso condiviso limita r/wsize a 64 KiB, aumentando al contempo le prestazioni di lettura con un aumento del read-ahead per i montaggi NFS. Per informazioni dettagliate, vedere Procedure consigliate per NFS read-ahead per Azure NetApp Files .

Le considerazioni seguenti si applicano all'uso di rsize e wsize:

  • Le dimensioni delle operazioni di I/O casuali sono spesso inferiori alle rsize opzioni di montaggio e wsize . Di conseguenza, in effetti, non saranno vincolati.
  • Quando si usa la cache del file system, le operazioni di I/O sequenziali si verificheranno con le dimensioni predicate dalle rsize opzioni di montaggio e wsize , a meno che le dimensioni del file non siano inferiori rsize a e wsize.
  • Le operazioni che ignorano la cache del file system, anche se ancora vincolate dalle rsize opzioni di montaggio e wsize , non verranno necessariamente eseguite fino al valore massimo specificato da rsize o wsize. Questa considerazione è importante quando si usano generatori di carichi di lavoro che hanno l'opzione directio .

Come procedura consigliata con Azure NetApp Files, per ottenere una velocità effettiva e una latenza ottimali, impostare rsize e wsize non superare i 262.144 byte.

Timer di coerenza e attributi della cache da vicino a aperti

NFS usa un modello di coerenza debole. La coerenza è debole perché l'applicazione non deve passare alla risorsa di archiviazione condivisa e recuperare i dati ogni volta per usarla, uno scenario che avrebbe un impatto notevole sulle prestazioni dell'applicazione. Esistono due meccanismi che gestiscono questo processo: timer degli attributi della cache e coerenza da vicino all'apertura.

Se il client ha la proprietà completa dei dati, ovvero non viene condiviso tra più nodi o sistemi, esiste una coerenza garantita. In tal caso, è possibile ridurre le getattr operazioni di accesso all'archiviazione e velocizzare l'applicazione disattivando la coerenza () da vicino all'apertura (cto) (nocto come opzione di montaggio) e attivando i timeout per la gestione della cache degli attributi (actimeo=600 poiché un'opzione di montaggio modifica il timer su 10m rispetto alle impostazioni predefinite acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). In alcuni test, nocto riduce circa il getattr 65-70% delle chiamate di accesso e la regolazione actimeo riduce queste chiamate un altro 20-25%.

Funzionamento dei timer della cache degli attributi

Gli attributi acregmin, acregmaxacdirmin, e acdirmax controllano la coerenza della cache. I due attributi precedenti controllano per quanto tempo gli attributi dei file sono attendibili. Gli ultimi due attributi controllano per quanto tempo gli attributi del file di directory sono attendibili (dimensioni della directory, proprietà della directory, autorizzazioni di directory). Gli min attributi e max definiscono la durata minima e massima in base alle quali gli attributi di una directory, gli attributi di un file e il contenuto della cache di un file vengono considerati attendibili, rispettivamente. Tra min e max, viene usato un algoritmo per definire la quantità di tempo in cui una voce memorizzata nella cache è attendibile.

Si considerino ad esempio i valori predefiniti acregmin e acregmax rispettivamente 3 e 30 secondi. Ad esempio, gli attributi vengono valutati ripetutamente per i file in una directory. Dopo 3 secondi, viene eseguita una query sul servizio NFS per l'aggiornamento. Se gli attributi sono considerati validi, il client raddoppia il tempo attendibile a 6 secondi, 12 secondi, 24 secondi, quindi come massimo è impostato su 30, 30 secondi. Da quel momento in poi, fino a quando gli attributi memorizzati nella cache non vengono considerati obsoleti (a quel punto il ciclo inizia), la attendibilità viene definita come 30 secondi essendo il valore specificato da acregmax.

Esistono altri casi che possono trarre vantaggio da un set simile di opzioni di montaggio, anche quando non esiste una proprietà completa da parte dei client, ad esempio se i client usano i dati come di sola lettura e l'aggiornamento dei dati viene gestito tramite un altro percorso. Per le applicazioni che usano griglie di client come EDA, hosting Web e rendering di film e hanno set di dati relativamente statici (strumenti o librerie EDA, contenuto Web, dati di trama), il comportamento tipico è che il set di dati viene in gran parte memorizzato nella cache nei client. Ci sono poche letture e nessuna scrittura. Ci saranno molte getattrchiamate /access che tornano alla risorsa di archiviazione. Questi set di dati vengono in genere aggiornati tramite un altro client che monta i file system e esegue periodicamente il push degli aggiornamenti del contenuto.

In questi casi, è presente un ritardo noto nella raccolta di nuovi contenuti e l'applicazione funziona ancora con dati potenzialmente non aggiornati. In questi casi nocto e actimeo può essere usato per controllare il periodo in cui è possibile gestire i dati non aggiornati. Ad esempio, in strumenti ed librerie EDA funziona actimeo=600 bene perché questi dati vengono in genere aggiornati raramente. Per un hosting Web di piccole dimensioni in cui i client devono visualizzare tempestivamente gli aggiornamenti dei dati quando stanno modificando i siti, actimeo=10 potrebbe essere accettabile. Per i siti Web su larga scala in cui è stato eseguito il push di contenuto in più file system, actimeo=60 potrebbe essere accettabile.

L'uso di queste opzioni di montaggio riduce significativamente il carico di lavoro all'archiviazione in questi casi. Ad esempio, un'esperienza EDA recente ha ridotto gli I/O al volume degli strumenti da >150 K a ~6 K. Le applicazioni possono essere eseguite in modo molto più rapido perché possono considerare attendibili i dati in memoria. Il tempo di accesso alla memoria è nanosecondi rispetto a centinaia di microsecondi per getattr/access in una rete veloce.

Coerenza close-to-open

La coerenza da vicino a aperta (opzione cto di montaggio) garantisce che, indipendentemente dallo stato della cache, all'apertura dei dati più recenti per un file venga sempre presentata all'applicazione.

  • Quando viene eseguita una ricerca per indicizzazione di una directory (lsls -lad esempio) viene eseguito un determinato set di RPC (chiamate di routine remote).
    Il server NFS condivide la visualizzazione del file system. cto Se usato da tutti i client NFS che accedono a una determinata esportazione NFS, tutti i client visualizzeranno lo stesso elenco di file e directory. L'aggiornamento degli attributi dei file nella directory è controllato dai timer della cache degli attributi. In altre parole, purché cto venga usato, i file vengono visualizzati nei client remoti non appena viene creato il file e il file si trova nella risorsa di archiviazione.
  • Quando un file viene aperto, il contenuto del file viene garantito aggiornato dal punto di vista del server NFS.
    Se si verifica una race condition in cui il contenuto non ha terminato lo scaricamento dal computer 1 quando un file viene aperto nel computer 2, il computer 2 riceverà solo i dati presenti nel server al momento dell'apertura. In questo caso, il computer 2 non recupererà più dati dal file fino a quando non viene raggiunto il acreg timer e il computer 2 controlla nuovamente la coerenza della cache dal server. Questo scenario può essere osservato usando una parte finale -f del computer 2 quando il file viene ancora scritto nel computer 1.

Nessuna coerenza da vicino a aperta

Quando non viene usata alcuna coerenza da vicino a aperta (nocto), il client considererà attendibile l'aggiornamento della visualizzazione corrente del file e della directory fino a quando i timer degli attributi della cache non sono stati violati.

  • Quando viene eseguita una ricerca per indicizzazione di una directory (lsls -lad esempio) viene eseguito un determinato set di RPC (chiamate di routine remote).
    Il client emetterà una chiamata al server solo per un elenco corrente di file quando il valore timer della acdir cache è stato violato. In questo caso, i file e le directory creati di recente non verranno visualizzati e i file e le directory rimossi di recente verranno comunque visualizzati.

  • Quando un file viene aperto, purché il file sia ancora nella cache, il contenuto memorizzato nella cache (se presente) viene restituito senza convalidare la coerenza con il server NFS.

Passaggi successivi