La réexportation NFS à travers un VPN n'est pas du transfert de paquets

Une machine Linux rejoint un VPN, monte une exportation NFS distante, puis sert ce montage à un autre ensemble de clients. Cette disposition ressemble à du routage avec des étapes en plus, et c'est la première hypothèse fausse. La machine intermédiaire est cliente du serveur amont et serveur pour les clients aval, et elle participe aux deux relations de service de fichiers. Le transfert de paquets n'a pas d'avis sur les handles de fichiers, le verrouillage ou l'identité du système de fichiers ; une réexportation, si.

Commencez par demander si les clients aval pourraient joindre le serveur d'origine directement. S'ils le peuvent, la machine intermédiaire est facultative.

Trois modèles, trois histoires de cohérence

Le montage direct est le plus simple : chaque client monte le serveur d'origine à travers le tunnel, et la politique d'exportation de ce serveur régit l'accès. La réexportation est la machine intermédiaire qui présente une frontière de service différente, ce qui est utile lorsque le réseau côté clients ne doit pas joindre le serveur directement. La réplication est un troisième modèle, et elle déplace la question de la cohérence vers la synchronisation et la résolution des conflits.

Ne décrivez pas une copie répliquée comme s'il s'agissait d'une réexportation en direct. Les modes de défaillance diffèrent, et un utilisateur qui attend que chaque opération atteigne le système de fichiers d'origine sera surpris lors d'une coupure de lien.

L'identité survit à la commande de montage

Les réexportations ont besoin d'un identifiant de système de fichiers explicite, et cette identité doit survivre aux redémarrages et aux reconstructions de configuration. La documentation du noyau est claire sur cette exigence, et elle avertit aussi que crossmnt ne supprime pas la nécessité d'exporter les systèmes de fichiers enfants avec leurs propres identifiants. Une arborescence qui semble continue à un utilisateur peut franchir plusieurs frontières de systèmes de fichiers. Les nfs-utils actuels peuvent allouer des identifiants automatiquement pour les configurations prises en charge, et lorsqu'ils le font, leur base de données fait partie de l'état de la passerelle. Traitez ces identifiants comme une identité de service plutôt que comme des fichiers jetables.

Les handles de fichiers sont l'autre frontière d'identité : une réexportation encapsule le handle d'origine, ce qui le rend plus grand et peut dépasser la limite d'un client. Un montage réussi ne prouve pas que toutes les dispositions d'exportation sont compatibles.

Toutes les fonctionnalités NFS ne survivent pas à la machine intermédiaire

Le guide de réexportation du noyau indique que le serveur qui réexporte ne prend pas en charge le verrouillage ni les demandes de délégation. Les applications qui dépendent de ces opérations ont besoin d'un autre chemin ou d'une conception vérifiée face à elles. Un montage réussi et une liste de répertoire fonctionnelle ne montrent pas que les opérations réelles de l'application fonctionnent.

L'identité utilisateur et la politique d'exportation comptent aussi à chaque saut. Une connexion VPN prouve qu'un participant du réseau s'est authentifié ; elle n'autorise pas un utilisateur NFS et ne transmet pas les identifiants d'un client à travers la passerelle.

La passerelle a deux dépendances en amont

La passerelle dépend du VPN pour le montage en amont et du serveur amont pour le système de fichiers lui-même. Un processus d'exportation local encore en cours d'exécution ne peut pas rendre sain un stockage indisponible. Planifiez l'ordre de démarrage, le comportement de reconnexion et les redémarrages du serveur, y compris ce qui arrive aux handles de fichiers que les clients détiennent déjà. Un client qui a monté via la passerelle et a perdu son handle a besoin d'un remontage, et c'est un événement opérationnel et non une récupération transparente.

Si tout ce dont l'exigence avait besoin était l'accessibilité d'IP privées, le routage direct vers le serveur d'origine est l'architecture la plus simple. La réexportation devrait exister pour une raison qui survit à sa mise par écrit.

Testez la charge de travail, pas le montage

Exercez la charge de fichiers réelle dans un environnement contrôlé : les opérations que l'application effectue, les tailles de fichiers qu'elle utilise et la concurrence qu'elle attend. Surveillez les lacunes fonctionnelles et pas seulement les erreurs de transport. Puis notez le modèle que vous avez choisi et pourquoi, sinon la personne suivante supposera que la passerelle est un routeur.

Une réexportation est légitime lorsqu'elle existe pour une raison délibérée, comme un réseau de clients isolé ou une frontière de version maîtrisée. C'est un mauvais accident, et la différence est de savoir si quelqu'un l'a décidé.