Résolution I/O des erreurs et des échecs de restauration du verrouillage NFS - FSx pour ONTAP
Erreurs d'E/S lors des basculementsNFSv4 solutions de rechange

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution I/O des erreurs et des échecs de restauration du verrouillage NFS

Cette section décrit les problèmes liés aux I/O erreurs et aux échecs de restauration du verrouillage NFS lors d'événements de basculement sur des systèmes de fichiers ONTAP, ainsi que FSx les solutions pour chacun d'entre eux.

Vous rencontrez des I/O erreurs lors d'événements de basculement

Lors du basculement des systèmes FSx de fichiers ONTAP mono-AZ, les clients NFS peuvent rencontrer des erreurs transitoires I/O ou des pauses prolongées. Pour les clients NFSv4 +, vous pouvez voir des messages du journal du noyau tels que :

NFS: __nfs4_reclaim_open_state: Lock reclaim failed!

Ces messages indiquent que le client n'a pas réussi à récupérer les verrous NFS pendant la fenêtre de basculement.

Pour réduire les I/O erreurs lors d'événements de basculement

Sous Linux, vous pouvez configurer les paramètres réseau de vos clients afin de réduire le temps de détection du basculement de 55 à 60 secondes à 15 à 20 secondes.

Important

Testez toujours d'abord ces configurations dans un environnement hors production. Ces paramètres augmentent le trafic ARP (Address Resolution Protocol), qui est utilisé pour mapper les adresses IP aux adresses physiques (MAC) d'un réseau local, et peuvent ne pas convenir aux environnements limités par le réseau.

Pour configurer des paramètres réseau optimisés pour les clients NFS

  1. Créez un fichier de configuration sysctl sur chaque client NFS. L'exemple suivant permet default d'appliquer des paramètres à toutes les interfaces réseau. Si votre instance possède plusieurs interfaces réseau, vous pouvez les remplacer par default le nom d'interface spécifique (par exemple, eth0 ouens5) utilisé pour vous connecter à votre système de fichiers mono-AZ FSx for ONTAP :

    $ sudo tee /etc/sysctl.d/99-fsx-failover.conf > /dev/null << 'EOF'
# NFS client optimizations for faster failover detection
# Replace 'default' with your interface name (e.g., eth0, ens5) to target a specific interface
net.ipv4.neigh.default.base_reachable_time_ms=5000
net.ipv4.neigh.default.delay_first_probe_time=1
net.ipv4.neigh.default.ucast_solicit=0
net.ipv4.tcp_syn_retries=3
EOF

  2. Appliquez les paramètres immédiatement :

    $ sudo sysctl -p /etc/sysctl.d/99-fsx-failover.conf

  3. Vérifiez que la configuration est active. Si vous l'avez utilisédefault, vous pouvez le vérifier à l'aide des commandes suivantes. Si vous avez spécifié une interface spécifique, remplacez-la default par le nom de votre interface (par exemple, eth0 ouens5) :

    $ sysctl net.ipv4.neigh.default.base_reachable_time_ms
$ sysctl net.ipv4.neigh.default.delay_first_probe_time
$ sysctl net.ipv4.neigh.default.ucast_solicit
$ sysctl net.ipv4.tcp_syn_retries

Assurez-vous que ces paramètres sont appliqués de manière cohérente à tous les clients NFS qui se connectent à votre système de fichiers FSx for ONTAP au sein de la même zone de disponibilité. Lorsque vous utilisez ces optimisations du réseau, gardez à l'esprit les points suivants :

  • base_reachable_time_ms=5000 — Réduit la validité des entrées dans le cache ARP de 30 secondes à 5 secondes, ce qui permet aux clients de détecter plus rapidement les changements de propriété IP lors d'un événement de basculement.

  • delay_first_probe_time=1 — Réduit le délai avant de tester une entrée réseau périmée de 5 secondes à 1 seconde.

  • ucast_solicit=0 — Ignore les sondes voisines à diffusion unique et émet immédiatement des requêtes ARP de diffusion, accélérant ainsi la redécouverte du serveur de fichiers actif.

  • tcp_syn_retries=3 — Réduit la durée des tentatives de connexion TCP de 127 secondes à 15 secondes.

Une fois les paramètres réseau définis, vous devez surveiller votre environnement pour valider les modifications. Vous pouvez tester un événement de basculement en modifiant la capacité de débit de votre système de fichiers. Pour de plus amples informations, veuillez consulter Test du basculement sur un système de fichiers.

Surveillance de votre environnement après l'application des modifications

  • Surveillez les journaux système pour détecter les erreurs NFS afin de consulter les messages du journal du noyau relatifs au NFS.

    $ sudo journalctl -f | grep -i nfs

    Vérifiez qu'il y a moins d'occurrences de messages tels queLock reclaim failed.

  • Surveillez les journaux des applications pour vérifier qu'il y a moins de I/O délais, d'erreurs de connexion et d'échecs liés aux nouvelles tentatives lors d'événements de basculement.

  • Validez l'impact sur le réseau pour vous assurer que l'augmentation du trafic ARP n'affecte pas les performances du réseau dans votre environnement.

Approches alternatives pour les NFSv4 environnements

Dans NFSv4 les environnements où il n'est pas possible de modifier la configuration côté client, envisagez les alternatives suivantes :

  • Prolongez les délais de NFSv4 location. Collaborez avec votre administrateur de stockage pour augmenter les délais d'expiration des NFSv4 baux. L'allongement de ces délais donne aux clients plus de temps pour récupérer les verrous en cas de basculement. Pour plus d'informations, voir Spécifier le délai de grâce de NFSv4 verrouillage dans la NetApp ONTAP documentation.