FAQ sur NFS pour Azure NetApp Files

  • Article

Cet article répond aux questions fréquemment posées sur le forum aux questions (FAQ) relatif au protocole NFS d’Azure NetApp Files.

Je veux monter un volume automatiquement lorsqu’une machine virtuelle Azure est démarrée ou redémarrée. Comment configurer mon hôte pour les volumes NFS persistants ?

Pour qu’un volume NFS soit monté automatiquement au moment du démarrage ou du redémarrage de la machine virtuelle, ajoutez une entrée au fichier /etc/fstab sur l’hôte.

Pour plus d’informations, consultez Monter un volume pour des machines virtuelles Windows ou Linux.

Quelle version de NFS Azure NetApp Files prend-il en charge ?

Azure NetApp Files prend en charge NFSv3 et NFSv4.1. Vous pouvez créer un volume à l’aide de l’une de ces versions NFS.

Azure NetApp Files prend-il officiellement en charge NFSv4.2 ?

Actuellement, Azure NetApp Files ne prend pas officiellement en charge NFSv4.2 ni ses fonctionnalités auxiliaires (y compris les opérations sur des fichiers partiellement alloués, les attributs étendus et les étiquettes de sécurité). Toutefois, la fonctionnalité est activée pour le serveur NFS lorsque NFSv4.1 est utilisé, ce qui signifie que les clients NFS peuvent monter un volume avec le protocole NFSv4.2 en utilisant l’une des deux méthodes suivantes :

  • Spécifier explicitement vers=4.2, nfsvers=4.2 ou nfsvers=4,minorversion=2 dans les options de montage.
  • Ne pas spécifier de version NFS dans les options de montage et autoriser le client NFS à négocier avec la version NFS prise en charge la plus élevée autorisée.

Dans la plupart des cas, si un client procède au montage avec NFSv4.2, aucun problème n’est visible. Toutefois, certains clients peuvent rencontrer des problèmes s’ils ne prennent pas entièrement en charge NFSv4.2 ou les fonctionnalités des attributs étendus NFSv4.2. Par ailleurs, NFSv4.2 n’étant pas actuellement pris en charge avec Azure NetApp Files, tous les problèmes liés à NFSv4.2 sont hors propos.

Pour éviter tout problème lié à des clients montant des volumes avec NFSv4.2 et vous conformer à la capacité de prise en charge, vérifiez que la version NFSv4.1 est spécifiée dans les options de montage ou que la configuration NFS du client est définie pour limiter la version de NFS à NFSv4.1.

Comment activer le root squash ?

Vous pouvez spécifier si le compte racine peut accéder ou non au volume à l’aide de la stratégie d’exportation du volume. Pour plus d’informations, consultez Configurer une stratégie d’exportation pour un volume NFS.

Puis-je utiliser le même chemin d’accès de fichier pour plusieurs volumes ?

Vous pouvez utiliser le même chemin d’accès de fichier pour :

  • des volumes déployés dans différentes régions
  • des volumes déployés dans différentes zones de disponibilité au sein de la même région

Si vous utilisez :

  • des volumes régionaux (sans zones de disponibilité) ou
  • des volumes au sein de la même zone de disponibilité,

vous pouvez utiliser le même chemin d’accès de fichier, mais il doit être unique au sein de chaque sous-réseau délégué ou être affecté à différents sous-réseaux délégués.

Pour plus d’informations, consultez Créer un volume NFS pour Azure NetApp Files ou Créer un volume double protocole pour Azure NetApp Files.

Lorsque j’essaie d’accéder à des volumes NFS via un client Windows, pourquoi le client met-il beaucoup de temps à rechercher des dossiers et des sous-dossiers ?

Assurez-vous que CaseSensitiveLookup est activé sur le client Windows pour accélérer la recherche de dossiers et de sous-dossiers :

  1. Utilisez la commande PowerShell suivante pour activer CaseSensitiveLookup :
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Montez le volume sur le serveur Windows.
    Exemple :
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

Comment Azure NetApp Files prend-il en charge le verrouillage de fichiers NFSv 4.1 ?

Pour les clients NFSv 4.1, Azure NetApp Files prend en charge le mécanisme de verrouillage de fichiers NFSv 4.1 qui maintient l’état de tous les verrous de fichier sous un modèle basé sur un bail.

Selon la norme RFC 3530, Azure NetApp Files définit une période de bail unique pour l’ensemble des états conservés par un client NFS. Si le client ne renouvelle pas son bail au cours de la période définie, tous les états associés à son bail sont libérés par le serveur.

Par exemple, si un client montant un volume cesse de répondre ou se bloque au-delà des délais d’attente, les verrous sont libérés. Le client peut renouveler son bail de manière explicite ou implicite en effectuant des opérations telles que la lecture d’un fichier.

Une période de grâce définit une période de traitement spécial durant laquelle les clients peuvent tenter de récupérer leur état de verrouillage lors d’une récupération de serveur. Le délai d’expiration par défaut des baux est de 30 secondes, avec une période de grâce de 45 secondes. Passé ce délai, le bail du client est libéré.

Azure NetApp Files prend également en charge le déverrouillage des fichiers.

Pour en savoir plus sur le verrouillage de fichiers dans Azure NetApp Files, consultez le verrouillage de fichiers.

Pourquoi le répertoire .snapshot n’est-il pas visible dans un volume NFSv4.1 alors qu’il l’est dans un volume NFSv3 ?

Par conception, le répertoire.snapshot n’est jamais visible pour les clients NFSv4.1. Par défaut, le répertoire .snapshot est visible pour les clients NFSv3. Pour masquer le répertoire .snapshot des clients NFSv3, modifiez les propriétés du volume afin de masquer le chemin d’accès de l’instantané.

Oracle dNFS

Des correctifs Oracle doivent-ils être appliqués à dNFS ?

Important

Les clients qui utilisent Oracle 19c et versions ultérieures doivent s’assurer qu’ils disposent du correctif du bogue Oracle 32931941. La plupart des bundles de correctifs actuellement utilisés par les clients Oracle n’incluent pas ce correctif. Celui-ci n’a été inclus que dans un sous-ensemble de bundles de correctifs récents.

Si une base de données est exposée à ce bogue, toute interruption réseau est susceptible d’entraîner une altération des blocs fracturés. Les interruptions réseau englobent les événements tels que le déplacement d’un point de terminaison de stockage ou d’un volume, ainsi que les événements de maintenance du service de stockage. L’altération n’est pas nécessairement détectée immédiatement.

Cette altération n’est ni un bogue sur ONTAP ni un bogue du service Azure NetApp Files, mais le résultat d’un bogue d’Oracle dNFS. La réponse à une entrée/sortie NFS lors d’une interruption réseau ou de certains événements de reconfiguration est mal gérée. La base de données écrit par erreur un bloc qui était en cours de mise à jour au moment de son écriture. Dans certains cas, un remplacement ultérieur de ce même bloc altère silencieusement le bloc altéré. Si ce n’est pas le cas, les processus de base de données Oracle finissent par l’identifier. Une erreur doit être consignée dans les journaux d’alerte et l’instance Oracle est susceptible de s’arrêter. En outre, les opérations dbv et RMAN peuvent détecter l’altération.

Oracle publie le document 1495104.1, qui est continuellement mis à jour avec les correctifs dNFS recommandés. Si votre base de données utilise dNFS, vérifiez que l’équipe DBA recherche les mises à jour dans ce document.

Important

Les clients utilisant Oracle dNFS avec NFSv4.1 sur des volumes Azure NetApp Files doivent veiller à effectuer les actions mentionnées sous Des correctifs sont-ils nécessaires pour utiliser Oracle dNFS avec NFSv4.1 ?.

Des correctifs sont-ils nécessaires pour utiliser Oracle dNFS avec NFSv4.1 ?

Important

Si vos bases de données utilisent Oracle dNFS avec NFSv4.1, les correctifs des bogues Oracle 33132050 et 33676296 doivent y être installés. Vous devrez peut-être demander un rétroportage pour d’autres versions d’Oracle. Par exemple, au moment de la rédaction de cet article, ces correctifs sont disponibles pour la version 19.11, mais pas encore pour la version 19.3. Si vous citez ces numéros de bogues dans la demande d’assistance, les ingénieurs du support technique d’Oracle savent quoi faire.

Cette exigence s’applique aux systèmes et services basés sur ONTAP en général, ce qui inclut à la fois les instances locales d’ONTAP et Azure NetApp Files.

Exemples de problèmes potentiels si ces correctifs ne sont pas appliqués :

  1. La base de données se bloque lors des déplacements du point de terminaison de stockage principal.
  2. La base de données se bloque lors des événements de maintenance du service Azure NetApp Files.
  3. De brefs blocages d’Oracle se produisent pendant le fonctionnement normal, sans que ceux-ci soient forcément perceptibles.
  4. Arrêts lents d’Oracle : si vous surveillez le processus d’arrêt, vous voyez des pauses qui, en s’additionnant, peuvent générer plusieurs minutes de retard à mesure que les entrées/sorties dNFS expirent.
  5. Comportement incorrect de la mise en cache des réponses dNFS lors des lectures, qui bloque une base de données.

Les correctifs incluent une modification de la gestion des sessions dNFS et de la mise en cache des réponses NFS qui résout ces problèmes.

Si vous ne pouvez pas appliquer les correctifs de ces deux bogues, vous ne devez pas utiliser dNFS avec NFSv4.1. Vous pouvez désactiver dNFS ou basculer vers NFSv3.

Puis-je utiliser la gestion multivoie avec Oracle dNFS et NFSv4.1 ?

Lors de l’utilisation de NFSv4.1, dNFS ne fonctionne pas avec plusieurs chemins d’accès. Si vous avez besoin de plusieurs chemins d’accès, vous devez utiliser NFSv3. dNFS nécessite une jonction clientID et sessionID à l’échelle du cluster pour que NFSv4.1 fonctionne avec plusieurs chemins d’accès, ce qu’Azure NetApp Files ne prend pas en charge. Par conséquent, un blocage se produit au démarrage de dNFS.

Étapes suivantes