Réplication DFS sur un VPN : le verrouillage n’est pas ce que vous obtenez
Un VPN de site transporte le trafic, mais n’ajoute aucun verrouillage de fichiers. Concevez le modèle de cohérence, l’espace de staging et la fenêtre de réplication avant d’amorcer.
Le lien est chiffré, toujours actif et assez rapide, donc le dossier partagé devrait se comporter comme un seul dossier sur les deux sites. C’est l’hypothèse derrière la plupart des conceptions de réplication DFS qui surprennent les gens plus tard. DFSR est multi-maître et asynchrone : chaque réplique suit les versions indépendamment, et rien dans le protocole ne maintient un verrou entre les serveurs. Le VPN transporte le trafic entre eux et n’ajoute rien de la coordination dont cette hypothèse a besoin. Planifiez le schéma d’écriture et le modèle de capacité, sinon le premier vrai conflit deviendra un incident de support.
Le mythe : un VPN fait des répliques un seul système de fichiers
Un tunnel est un transport. Il vous donne un chemin autorisé entre deux serveurs et masque les sauts intermédiaires. Il ne dit rien sur qui peut modifier un fichier, dans quel ordre les versions arrivent, ni ce qui se passe quand deux modifications se disputent la même chose.
Le chiffrement et la disponibilité sont des propriétés du lien ; la cohérence est une propriété du moteur de réplication et de votre flux de travail.
Ce que DFSR réplique réellement
Chaque serveur conserve sa propre copie et ses propres métadonnées de version. Les modifications se propagent lorsque la connexion et la planification le permettent, et le moteur utilise la compression différentielle distante pour n’envoyer que les parties du fichier qui ont changé. Lorsque deux répliques modifient le même fichier avant l’arrivée de l’une des mises à jour, une version gagne et l’autre est écartée comme copie de conflit. Aucun serveur n’a bloqué la seconde modification, car bloquer exigerait le verrou distribué que DFSR ne fournit pas.
Un chemin d’espace de noms rend les copies faciles d’accès, et il ne les rend pas cohérentes.
L’espace de staging est une capacité de travail, pas une sauvegarde
Le staging est la zone de travail que la réplication utilise pendant qu’elle assemble les modifications. Les recommandations de dimensionnement de Microsoft prennent la taille combinée des 32 plus gros fichiers du dossier répliqué comme minimum, avec de la place supplémentaire utile pendant la réplication initiale. Une arborescence de petits documents et un dossier contenant plusieurs archives volumineuses ont donc besoin de formes de staging différentes. Quand le staging est épuisé, la réplication se bloque d’une manière qui ressemble à une panne réseau. Dimensionnez-le à partir des données, puis continuez à surveiller à mesure que les données changent.
Le staging n’est pas une sauvegarde, et propager des modifications n’est pas un historique de versions.
Le préamorçage est une optimisation, pas un raccourci
Pour une grande arborescence existante, le préamorçage pris en charge avec Robocopy peut réduire ce qui doit traverser le lien pendant la synchronisation initiale, et les recommandations de Microsoft couvrent la conservation des informations de fichier et le traitement des fichiers verrouillés ou ignorés. C’est une optimisation, pas la promesse que la destination est déjà correcte, donc la réplication initiale doit encore se terminer et être vérifiée. C’est en sautant cette vérification qu’un site finit par servir des fichiers qui n’ont jamais fait partie de l’ensemble répliqué.
Vérifiez l’état initial avant que les utilisateurs dépendent de la destination, pas après la première plainte.
Choisissez la fenêtre et définissez ce que veut dire à jour
Le calendrier de réplication et les limites de bande passante décident quand les partenaires peuvent échanger des données. Une fenêtre étroite en dehors des heures ouvrées est une conception légitime qui laisse un arriéré pendant la journée, à condition que tous aient convenu que la copie distante n’a besoin d’être à jour que le matin.
Écrivez cette phrase, car « l’arriéré est de quarante minutes » n’est alarmant que si personne n’a défini la cible.
Validez avec le flux de travail, pas avec un seul fichier
Testez avec les fichiers que les gens utilisent réellement : un gros document, une modification de routine, une suppression et une modification simultanée délibérée sur les deux sites. Confirmez que le comportement en cas de conflit correspond à ce que vous avez dit à l’entreprise et que le chemin de restauration depuis la sauvegarde est distinct des répliques. Surveillez ensuite le volume de modifications, la croissance de la file d’attente et la marge de staging par rapport à la fenêtre de service pendant quelques semaines. La capacité du VPN est une limite parmi d’autres, et c’est rarement la première que vous atteignez.
Une conception qui documente son retard et ses règles de modification est bien plus facile à supporter qu’une qui promet des copies identiques.