Vanliga frågor och svar om NFS för Azure NetApp Files

  • Artikel

Den här artikeln besvarar vanliga frågor och svar om NFS-protokollet för Azure NetApp Files.

Jag vill ha en volym monterad automatiskt när en virtuell Azure-dator startas eller startas om. Hur gör jag för att konfigurera min värd för beständiga NFS-volymer?

För att en NFS-volym ska monteras automatiskt vid start eller omstart av den virtuella datorn lägger du till en post i /etc/fstab filen på värden.

Mer information finns i Montera en volym för virtuella Windows- eller Linux-datorer .

Vilken NFS-version stöder Azure NetApp Files?

Azure NetApp Files stöder NFSv3 och NFSv4.1. Du kan skapa en volym med någon av NFS-versionerna.

Har Azure NetApp Files officiellt stöd för NFSv4.2?

För närvarande har Azure NetApp Files inte officiellt stöd för NFSv4.2 eller dess underordnade funktioner (inklusive glesa filåtgärder, utökade attribut och säkerhetsetiketter). Funktionen är dock aktiverad för NFS-servern när NFSv4.1 används, vilket innebär att NFS-klienter kan montera med NFSv4.2-protokollet på något av två sätt:

  • vers=4.2Ange uttryckligen , nfsvers=4.2eller nfsvers=4,minorversion=2 i monteringsalternativen.
  • Anger inte en NFS-version i monteringsalternativen och tillåter att NFS-klienten förhandlar till den högsta tillåtna NFS-versionen.

I de flesta fall kan inga problem visas om en klient monteras med NFSv4.2. Vissa klienter kan dock få problem om de inte helt stöder NFSv4.2 eller funktionerna för utökade attribut för NFSv4.2. Eftersom NFSv4.2 för närvarande inte stöds med Azure NetApp Files är eventuella problem med NFSv4.2 utanför omfånget.

För att undvika problem med klienter som monterar NFSv4.2 och för att uppfylla supporten kontrollerar du att NFSv4.1-versionen anges i monteringsalternativ eller att klientens NFS-klientkonfiguration är inställd på NFS-versionen på NFSv4.1.

Hur gör jag för att aktivera rot squash?

Du kan ange om rotkontot kan komma åt volymen eller inte med hjälp av volymens exportprincip. Mer information finns i Konfigurera exportprincip för en NFS-volym .

Kan jag använda samma filsökväg för flera volymer?

Samma filsökväg kan användas för:

  • volymer som distribuerats i olika regioner
  • volymer som distribuerats till olika tillgänglighetszoner inom samma region

Om du använder:

  • regionala volymer (utan tillgänglighetszoner) eller
  • volymer inom samma tillgänglighetszon.

samma filsökväg kan användas, men filsökvägen måste vara unik inom varje delegerat undernät eller tilldelas till olika delegerade undernät.

Mer information finns i Skapa en NFS-volym för Azure NetApp Files eller Skapa en volym med dubbla protokoll för Azure NetApp Files.

Varför tar det lång tid att söka i mappar och undermappar när jag försöker komma åt NFS-volymer via en Windows-klient?

Kontrollera att CaseSensitiveLookup är aktiverat på Windows-klienten för att påskynda uppslag av mappar och undermappar:

  1. Använd följande PowerShell-kommando för att aktivera CaseSensitiveLookup:
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Montera volymen på Windows-servern.
    Exempel:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

Hur stöder Azure NetApp Files fillåsning i NFSv4.1?

För NFSv4.1-klienter stöder Azure NetApp Files fillåsningsmekanismen NFSv4.1 som upprätthåller tillståndet för alla fillås under en lånebaserad modell.

Enligt RFC 3530 definierar Azure NetApp Files en enda låneperiod för alla tillstånd som innehas av en NFS-klient. Om klienten inte förnyar sitt lån inom den definierade perioden släpps alla tillstånd som är associerade med klientens lån av servern.

Om en klient som monterar en volym till exempel inte svarar eller kraschar utöver tidsgränserna släpps låsen. Klienten kan förnya lånet explicit eller implicit genom att utföra åtgärder som att läsa en fil.

En respitperiod definierar en period av särskild bearbetning där klienter kan försöka återta sitt låstillstånd under en serveråterställning. Standardtimeouten för lånen är 30 sekunder med en respitperiod på 45 sekunder. Därefter släpps klientens lån.

Azure NetApp Files stöder även icke-bakåtkompatibla fillås.

Mer information om fillåsning i Azure NetApp Files finns i fillåsning.

Varför visas .snapshot inte katalogen på en NFSv4.1-volym, men den visas i en NFSv3-volym?

Av design är .snapshot-katalogen aldrig synlig för NFSv4.1-klienter. Som standard .snapshot är katalogen synlig för NFSv3-klienter. Om du vill dölja .snapshot katalogen från NFSv3-klienter redigerar du volymens egenskaper för att dölja sökvägen till ögonblicksbilden.

Oracle dNFS

Finns det några Oracle-korrigeringar som krävs med dNFS?

Viktigt!

Kunder som använder Oracle 19c och senare måste se till att de korrigeras för Oracle-buggar 32931941. De flesta korrigeringspaket som för närvarande används av Oracle-kunder innehåller den här korrigeringen. Korrigeringen har bara inkluderats i en delmängd av de senaste korrigeringspaketen.

Om en databas exponeras för den här buggen är det mycket troligt att nätverksavbrott leder till skadade block. Nätverksavbrott omfattar händelser som flytt av lagringsslutpunkter, volymflytt och underhållshändelser för lagringstjänsten. Skadan kanske inte nödvändigtvis identifieras omedelbart.

Den här skadan är varken en bugg på ONTAP eller själva Azure NetApp Files-tjänsten, utan resultatet av en Oracle dNFS-bugg. Svaret på en NFS-I/O under ett visst nätverksavbrott eller omkonfigurationshändelser hanteras felaktigt. Databasen skriver felaktigt ett block som uppdaterades när det skrevs. I vissa fall kommer en senare överskrivning av samma block att tyst skada det skadade blocket. Annars identifierar Oracle-databasprocesserna det. Ett fel ska loggas i aviseringsloggarna och Oracle-instansen kommer sannolikt att avslutas. Dessutom kan dbv- och RMAN-åtgärder identifiera skada.

Oracle publicerar dokument 1495104.1, som uppdateras kontinuerligt med rekommenderade dNFS-korrigeringar. Om databasen använder dNFS kontrollerar du att DBA-teamet söker efter uppdateringar i det här dokumentet.

Viktigt!

Kunder som använder Oracle dNFS med NFSv4.1 på Azure NetApp Files-volymer måste se till att vidta åtgärder som nämns under Finns det några korrigeringar som krävs för användning av Oracle dNFS med NFSv4.1?.

Finns det några korrigeringar som krävs för användning av Oracle dNFS med NFSv4.1?

Viktigt!

Om dina databaser använder Oracle dNFS med NFSv4.1 måste de korrigeras för Oracle-buggar 33132050 och 33676296. Du kan behöva begära en backport för andra versioner av Oracle. I skrivande stund är dessa korrigeringar till exempel tillgängliga för 19.11, men ännu inte 19.3. Om du citerar dessa felnummer i supportärendena vet Oracles supporttekniker vad de ska göra.

Detta krav gäller för ONTAP-baserade system och tjänster i allmänhet, vilket omfattar både lokala ONTAP- och Azure NetApp Files.

Exempel på potentiella problem om dessa korrigeringar inte tillämpas:

  1. Databasen låser sig vid flytt av serverdelslagringsslutpunkter.
  2. Databasen låser sig på underhållshändelser för Azure NetApp Files-tjänsten.
  3. Kort Oracle låser sig under normal drift som kanske eller kanske inte är märkbar.
  4. Långsamma Oracle-avstängningar: Om du övervakar avstängningsprocessen ser du pauser som kan ge upp till minuter av fördröjningar när dNFS I/O överskrider tidsgränsen.
  5. Felaktigt beteende för cachelagring av dNFS-svar på läsningar som låser en databas.

Korrigeringarna innehåller en ändring i dNFS-sessionshantering och NFS-svarscachelagring som löser dessa problem.

Om du inte kan korrigera för dessa två buggar får du inte använda dNFS med NFSv4.1. Du kan antingen inaktivera dNFS eller växla till NFSv3.

Kan jag använda multipathing med Oracle dNFS och NFSv4.1?

När du använder NFSv4.1 fungerar inte dNFS med flera sökvägar. Om du behöver flera sökvägar måste du använda NFSv3. dNFS kräver klusteromfattande clientID och sessionID trunkering för att NFSv4.1 ska fungera med flera sökvägar, vilket Azure NetApp Files inte stöder. Som ett resultat av detta kommer du att uppleva en hängning under dNFS-start

Nästa steg