Liste de contrôle de migration NFS pour les jeux de données renommés et les descripteurs de fichiers stables

L’approche sûre consiste à traiter une migration d’exportation mise en pause, qui préserve autant que possible l’espace de noms visible par les clients et remonte délibérément les clients lorsque l’identité des handles change, comme une séquence de contrôles observables, et non comme une commande unique.

Sur un serveur NFS Linux migrant un jeu de données NAS utilisé par des clients de serveur domestique, le risque pratique est que le renommage ou le déplacement d’un jeu de données exporté laisse les clients avec des handles de fichiers NFS obsolètes ou provoque des échecs de remontage. Enregistrez l’identité actuelle et le point de reprise, commencez par le discriminateur le moins invasif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risquerait d’être exposée. Le flux de travail ci-dessous ne s’achève qu’une fois la charge de travail d’origine fonctionnelle ou lorsque les éléments recueillis atteignent un seuil nécessitant une escalade.

Inventorier les dépendances de l’exportation et des handles de fichiers

Enregistrez l’identité du système de fichiers ou du jeu de données source, le chemin côté serveur, la pseudo-racine NFSv4, les options d’exportation, les valeurs fsid explicites, les chemins de montage des clients, les unités autofs ou systemd, ainsi que chaque conteneur ou application utilisant le montage. Capturez les montages actifs et les fichiers ouverts avant de planifier l’interruption.

Les handles de fichiers NFS encodent l’identité des objets choisie par le serveur ; une chaîne de chemin inchangée ne garantit donc pas un handle stable après le déplacement d’un système de fichiers. Cet article indépendant sur les mécanismes des handles de fichiers NFS obsolètes explique comment des exportations supprimées, recréées ou remappées produisent des handles obsolètes, même lorsque le répertoire est toujours visiblement présent.

Déterminez si l’objectif est la stabilité de l’espace de noms ou la continuité des handles actifs. Préserver le chemin visible par les clients réduit les changements de configuration, mais le déplacement des données vers un autre système de fichiers peut malgré tout nécessiter que chaque client démonte le partage et obtienne de nouveaux handles.

Préparer la cible pendant que les clients restent sur la source

Créez le jeu de données cible, copiez les données en préservant les ACL, les propriétaires, les attributs étendus, les liens physiques, les fichiers creux et les horodatages, puis comparez les quantités et les hachages représentatifs. Alignez la sécurité de l’exportation et le mappage des identités avant d’exposer la cible aux clients de production.

Utilisez le guide ZimaSpace sur le mappage des identités NFSv4 pour aligner les identités NFSv4 entre les serveurs Linux. Des handles de fichiers stables ne résolvent pas les différences de propriété numérique ou de domaine de noms ; validez donc séparément la couche d’identité des fichiers et celle des utilisateurs.

Effectuez une synchronisation initiale pendant que la source est active uniquement si la méthode de copie le permet, puis planifiez une dernière synchronisation différentielle après l’arrêt. N’exportez pas les deux copies en lecture-écriture sous le même espace de noms client, car les écritures pourraient diverger sans échec évident.

Mettre les clients en pause et basculer l’exportation

Arrêtez les applications qui écrivent, les conteneurs et les tâches planifiées sur chaque client, puis vérifiez qu’aucun processus important ne conserve de fichiers ouverts sous le point de montage. Démontez proprement les clients. Après la synchronisation finale, retirez l’exportation source ou rendez-la accessible en lecture seule, basculez le montage ou l’exportation côté serveur vers la cible, puis rechargez les exportations.

Le récit d’une équipe d’ingénierie GitLab consacré à un cas de renommage NFS et d’état obsolète montre que le comportement des renommages et des délégations peut produire des observations obsolètes ou incohérentes côté client. La réponse opérationnelle sûre consiste à planifier la mise en pause et le remontage, et non à répéter des commandes de vidage du cache pendant que les applications continuent d’écrire.

Si la cible change d’identité de système de fichiers, prévoyez de nouveaux handles et remontez les clients depuis zéro. Gardez l’exportation d’origine disponible sous un nom de récupération hors production, mais ne laissez jamais les anciennes et les nouvelles arborescences accepter des écritures concurrentes.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Remonter chaque client et vérifier la nouvelle identité

Remontez d’abord un client témoin et testez l’énumération, la lecture, la création, le renommage, la suppression, le verrouillage des fichiers et la propriété. Redémarrez son application dépendante et vérifiez la charge de travail d’origine. Procédez ensuite avec les autres clients, en consignant la source du montage, la version NFS et l’absence d’erreurs de handles obsolètes.

Redémarrez ou relancez l’automontage sur un client témoin afin de vérifier que la configuration persistante pointe vers l’espace de noms client stable. Consultez les journaux du serveur, les noyaux des clients, les tâches de sauvegarde et les conteneurs pour repérer les anciens chemins dissimulés. Un montage manuel réussi ne prouve pas que l’ordre de démarrage ou les dépendances entre services sont corrects.

Ne retirez la source qu’après le remontage de tous les clients, la réussite des tâches normales, l’exécution d’une sauvegarde et le test d’une restauration. Revenez en arrière avant d’accepter de nouvelles écritures si le client témoin échoue ; une fois les écritures commencées sur la cible, arrêtez-vous et réconciliez délibérément les données plutôt que de basculer les exportations dans un sens puis dans l’autre.