Comment réorganiser des ensembles de données NFS sans modifier les chemins d’exportation visibles par les clients

Les jeux de données NFS peuvent être réorganisés sans laisser de descripteurs obsolètes côté client, à condition que l’espace de noms des exports visible par les clients reste stable tandis que le stockage est déplacé en arrière-plan.

La conception préventive consiste à séparer le chemin monté par les clients du nom physique du jeu de données que vous pourrez modifier ultérieurement. Créez une arborescence d’exports stable, mappez-y volontairement les jeux de données, préservez autant que possible l’identité du système de fichiers, arrêtez les clients avant tout remplacement destructif et vérifiez que le même chemin d’export fonctionne après la bascule. Si le serveur doit supprimer puis recréer le système de fichiers sous-jacent, considérez cela comme un changement d’identité et planifiez un remontage coordonné côté client au lieu de promettre une continuité invisible.

Créez un espace de noms d’exports stable au-dessus des jeux de données

Utilisez une racine d’export NFS dédiée dont les noms visibles par les clients ne reprennent pas nécessairement chaque nom interne de jeu de données ZFS ou Btrfs. Les administrateurs du stockage peuvent ainsi réorganiser les jeux de données principaux sans imposer un nouveau chemin de montage à chaque client.

Une discussion sur la conception de NFSv4 explique comment les montages bind créent des exports stables sous un pseudo-système de fichiers géré volontairement.

Documentez le chemin client comme contrat de compatibilité. Les noms internes des jeux de données peuvent changer ultérieurement, mais uniquement après le remappage de la couche d’export et les tests effectués avec le même chemin.

Fixez l’identité de l’export au lieu de dépendre de l’ordre de découverte

Notez l’UUID du système de fichiers, le chemin d’export, la version de NFS et les paramètres fsid explicites utilisés par le serveur actuel. Un même nom de répertoire visible ne suffit pas lorsque le serveur NFS identifie différemment le système de fichiers sous-jacent après un déplacement.

SUSE indique que NFS identifie chaque système de fichiers exporté au lieu de considérer un export comme un simple alias de chemin.

Utilisez des identifiants explicites uniquement lorsque votre implémentation NFS les prend en charge et veillez à ce que chaque valeur soit unique. Ne copiez pas un fsid sur deux systèmes de fichiers exportés simultanément dans le seul but de les faire apparaître comme identiques.

Placez le nouveau jeu de données derrière le même chemin d’export

Créez ou recevez le jeu de données de remplacement dans un chemin temporaire côté serveur, copiez ou répliquez son contenu, vérifiez les autorisations, puis mappez-le dans l’arborescence d’exports stable pendant une fenêtre de maintenance. Conservez l’ancien jeu de données pour permettre un retour arrière, mais ne l’activez pas avec la même identité d’export.

Un exemple d’export NFS montre comment les sous-arborescences montées nécessitent des exports explicites lorsque plusieurs systèmes de fichiers apparaissent sous un même espace de noms NFS.

La bascule doit modifier un seul mappage côté serveur, et non simultanément la définition du montage client et l’identité du jeu de données. Le dépannage conserve ainsi des éléments de comparaison si la nouvelle arborescence ne fonctionne pas correctement.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Arrêtez les écritures avant de remplacer le système de fichiers sous-jacent

Arrêtez ou mettez en pause les services qui écrivent activement via le montage NFS, puis vérifiez qu’aucun client important n’effectue une opération longue sur un fichier pendant la bascule. Effectuez la dernière synchronisation uniquement après la mise en pause des processus d’écriture.

IBM explique que l’état NFSv4 nécessite un stockage stable, car l’état des clients fait partie de la continuité du service, et pas seulement le contenu des fichiers côté serveur.

Sur un serveur domestique, l’objectif est plus simple qu’avec un basculement en cluster : évitez de modifier l’identité des fichiers pendant que des applications les utilisent. Une courte pause contrôlée est plus sûre que de forcer des clients de bases de données, de médias ou de sauvegarde à gérer le remplacement à chaud d’un système de fichiers.

Sachez quand le remontage d’un client est inévitable

Si la réorganisation détruit puis recrée le système de fichiers, restaure un instantané sous la forme d’un nouveau système de fichiers ou modifie l’identité du descripteur de fichier côté serveur, planifiez un démontage et un remontage coordonnés après stabilisation du chemin côté serveur.

Un guide actuel de dépannage NFS indique que les changements d’identité du serveur rendent les descripteurs obsolètes et recommande de vérifier la stabilité de l’identité du serveur lorsque le problème réapparaît.

N’annoncez pas une maintenance « sans remontage » lorsque l’identité sous-jacente change réellement. Une fenêtre de remontage documentée vaut mieux que de laisser les applications découvrir l’erreur ESTALE pendant des écritures normales.

Testez le chemin client avant de retirer l’ancien jeu de données

Montez l’export depuis un client neuf et depuis un client existant non critique, puis comparez l’identité des répertoires, les autorisations, des lectures représentatives, une écriture réversible et le chemin attendu par l’application. Redémarrez un client pour vérifier que la configuration persistante du montage n’a pas changé.

Un cas Arch Linux a montré qu’une racine NFS stable évite l’erreur ESTALE après des modifications du système de fichiers principal.

La réorganisation est terminée lorsque les clients utilisent toujours le chemin exporté d’origine et que l’ancien jeu de données peut être retiré sans références cachées. L’article ZimaSpace associé sur les descripteurs obsolètes après le changement de nom d’un jeu de données constitue la procédure de récupération si l’erreur ESTALE est déjà apparue.