Condividi tramite

Domande frequenti su NFS per Azure NetApp Files

  • Articolo

Questo articolo risponde alle domande frequenti (FAQ) sul protocollo NFS di Azure NetApp Files.

Montare automaticamente un volume all'avvio o al riavvio di una macchina virtuale di Azure. Come si configura l'host per i volumi NFS permanenti?

Per montare automaticamente un volume NFS all'avvio o al riavvio della macchina virtuale, aggiungere una voce al file /etc/fstab dell'host.

Per informazioni dettagliate, vedereMontare un volume per le macchine virtuali Windows o Linux.

Quale versione NFS supporta Azure NetApp Files?

Azure NetApp Files supporta NFSv3 e NFSv4.1. È possibile creare un volume usando una delle due versioni NFS.

Azure NetApp Files supporta ufficialmente NFSv4.2?

Azure NetApp Files non supporta NFSv4.2 né le sue funzionalità ausiliarie (incluse le operazioni su file sparse, gli attributi estesi e le etichette di sicurezza). Sebbene sia possibile montare un volume NFS4.1 in Azure NetApp Files con il protocollo NFSv4.2, l'uso di NFSv4.2 non è supportato.

I volumi di Azure NetApp Files possono essere montati usando il protocollo NFSv4.2 in uno dei due modi seguenti:

  • Specificare in modo esplicito vers=4.2, nfsvers=4.2 o nfsvers=4,minorversion=2 nelle opzioni di montaggio.
  • Non specificare una versione NFS nelle opzioni di montaggio e consentire al client NFS di negoziare con la versione NFS più elevata consentita. A seconda della distribuzione Linux è possibile che venga usato NFSv4.2 come protocollo NFS più elevato disponibile.

Molti client possono avere problemi se non supportano completamente NFSv4.2 o la funzionalità degli attributi estesi di NFSv4.2. Poiché NFSv4.2 non è supportato da Azure NetApp Files, eventuali problemi con NFSv4.2 non rientrano nell'ambito del supporto. Per evitare problemi con il montaggio di NFSv4.2 su client e per garantire la compatibilità, assicurarsi che la versione NFSv4.1 sia specificata nelle opzioni di montaggio o che la configurazione client NFS del client sia impostata per limitare la versione NFS alla NFSv4.1.

Per altre informazioni, vedere Informazioni sui protocolli NAS in Azure NetApp Files.

Come si abilita il root squashing?

È possibile specificare se l'account radice può accedere al volume o meno usando i criteri di esportazione del volume. Per maggiori dettagli, vedere Configurare i criteri di esportazione per un volume NFS.

È possibile usare lo stesso percorso del file per più volumi?

Lo stesso percorso del file può essere usato per:

  • volumi distribuiti in aree diverse
  • volumi distribuiti in zone di disponibilità diverse all'interno della stessa area

Se si usa:

  • volumi regionali (senza zone di disponibilità) o
  • volumi all'interno della stessa zona di disponibilità,

È possibile usare lo stesso percorso del file, ma il percorso file deve essere univoco all'interno di ogni subnet delegata o assegnato a subnet delegate diverse.

Per altre informazioni, vedere Creare un volume NFS per Azure NetApp Files o Creare un volume a doppio protocollo per Azure NetApp Files.

Quando si tenta di accedere ai volumi NFS tramite un client Windows, perché il client impiega molto tempo per cercare le cartelle e le sottocartelle?

Assicurarsi che CaseSensitiveLookup sia abilitato nel client Windows per velocizzare la ricerca di cartelle e sottocartelle:

  1. Usare il comando di PowerShell seguente per abilitare CaseSensitiveLookup:
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Montare il volume nel server Windows.
    Esempio:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

In che modo Azure NetApp Files supporta il blocco dei file NFSv4.1?

Per i client NFSv4.1, Azure NetApp Files supporta il meccanismo di blocco dei file NFSv4.1 che mantiene lo stato di tutti i blocchi di file in un modello basato su lease.

In base a RFC 3530, Azure NetApp Files definisce un singolo periodo di lease per tutto lo stato mantenuto da un client NFS. Se il client non rinnova il lease entro il periodo definito, tutti gli stati associati al lease del client verranno rilasciati dal server.

Ad esempio, se un client che monta un volume non risponde o si arresta in modo anomalo oltre i timeout, i blocchi verranno rilasciati. Il client può rinnovare il lease in modo esplicito o implicito eseguendo operazioni come la lettura di un file.

Il periodo di tolleranza definisce un periodo di elaborazione speciale in cui i client possono provare a recuperare il loro stato di blocco durante un ripristino del server. Il timeout predefinito per i lease è di 30 secondi con un periodo di tolleranza di 45 secondi. Dopo tale periodo, il lease del client verrà rilasciato.

Azure NetApp Files supporta anche blocchi di file che causano interruzioni.

Per altre informazioni sul blocco dei file in Azure NetApp Files, vedere Blocco dei file.

Perché la directory .snapshot non è visibile in un volume NFSv4.1, ma è visibile in un volume NFSv3?

Per impostazione predefinita, la directory .snapshot non è mai visibile ai client NFSv4.1. Per impostazione predefinita, la .snapshot directory è visibile ai client NFSv3. Per nascondere la directory .snapshot dai client NFSv3, modificare le proprietà del volume per nascondere il percorso dello snapshot.

Oracle dNFS

Sono necessarie patch Oracle con dNFS?

Importante

I clienti che usano Oracle 19c e versioni successive devono assicurarsi di aver applicato la patch per il bug Oracle 32931941. La maggior parte dei bundle di patch attualmente in uso dai clienti Oracle *non* includono questa patch. La patch è stata inclusa solo in un subset di bundle di patch recenti.

Se un database è esposto a questo bug, è molto probabile che le interruzioni di rete provochino la corruzione dei blocchi danneggiati. Le interruzioni di rete includono eventi come la rilocazione degli endpoint di archiviazione, la rilocazione dei volumi e gli eventi di manutenzione del servizio di archiviazione. Il danneggiamento potrebbe non essere necessariamente rilevato immediatamente.

Questo danneggiamento non è un bug di ONTAP o del servizio Azure NetApp Files, ma il risultato di un bug di Oracle dNFS. La risposta a un I/O NFS durante una determinata interruzione della rete o eventi di riconfigurazione viene gestita in modo non corretto. Il database scriverà erroneamente un blocco che è stato aggiornato durante la scrittura. In alcuni casi, la sovrascrittura successiva dello stesso blocco danneggerà automaticamente il blocco danneggiato. In caso contrario, i processi di database Oracle lo rileveranno. Nei log degli avvisi dovrebbe essere registrato un errore ed è probabile che l'istanza Oracle venga terminata. Inoltre, le operazioni dbv e RMAN possono rilevare il danneggiamento.

Oracle pubblica il documento 1495104.1, che viene continuamente aggiornato con le patch dNFS consigliate. Se il database usa dNFS, assicurarsi che il team DBA verifica la presenza di aggiornamenti in questo documento.

Importante

I clienti che usano Oracle dNFS con NFSv4.1 nei volumi di Azure NetApp Files devono assicurarsi di eseguire le azioni indicate in Sono necessarie patch per l'uso di Oracle dNFS con NFSv4.1?.

Sono necessarie patch per l'uso di Oracle dNFS con NFSv4.1?

Importante

Se i database usano Oracle dNFS con NFSv4.1, è necessario applicare patch ai bug Oracle 33132050 e 33676296. Potrebbe essere necessario richiedere un backport per altre versioni di Oracle. Ad esempio, al momento della pubblicazione, queste patch sono disponibili per la versione 19.11, ma non ancora per la 19.3. Se si citano questi numeri di bug nel caso di supporto, i tecnici del supporto di Oracle sapranno cosa fare.

Questo requisito si applica ai sistemi e ai servizi basati su ONTAP in generale, che includono sia ONTAP locale che Azure NetApp Files.

Esempi di potenziali problemi se queste patch non vengono applicate:

  1. Il database si blocca durante gli spostamenti dell'endpoint di archiviazione del back-end.
  2. Il database si blocca durante gli eventi di manutenzione del servizio Azure NetApp Files.
  3. Brevi blocchi di Oracle durante il normale funzionamento, che potrebbero essere o meno evidenti.
  4. Arresti lenti di Oracle: se si monitora il processo di arresto, si notano pause che potrebbero comportare ritardi di diversi minuti, in quanto si verifica il timeout di I/O dNFS.
  5. Comportamento di memorizzazione nella cache delle risposte dNFS non corretto nelle letture che bloccano un database.

Le patch includono una modifica nella gestione delle sessioni dNFS e nella memorizzazione nella cache delle risposte NFS che risolve questi problemi.

Se non è possibile applicare patch per questi due bug, non si deve usare dNFS con NFSv4.1. È possibile disabilitare dNFS o passare a NFSv3.

È possibile usare il multipathing con Oracle dNFS e NFSv4.1?

Quando si usa NFSv4.1, dNFS non funziona con percorsi multipli. Se sono necessari più percorsi, è necessario usare NFSv3. dNFS richiede clientID a livello di cluster e il trunking sessionID per NFSv4.1 per funzionare con percorsi multipli, che Azure NetApp Files non supporta. Di conseguenza, si verificherà un blocco durante l'avvio di dNFS

Passaggi successivi