Dfs : trucs, astuces et pièges

Dfs. Ainsi, Dfs fonctionne
bien avec des fichiers que les utilisateurs
ouvrent, changent puis ferment,
jusqu’à  ce qu’ils aient à  nouveau besoin
d’accéder à  ces fichiers. Dfs reconnaît
que le fichier a changé et réplique
la nouvelle version du fichier
sur le réseau, selon les besoins. Là  encore,
Dfs réplique tout le fichier, et pas
seulement les changements. Donc, si
l’on met à  jour un grand fichier, Win2K
va copier tout le nouveau fichier sur
chacune des répliques présentes sur le
réseau.
En plus de transférer les fichiers de
données d’une réplique à  une autre,
Win2K réplique également les permissions
entre les répliques que vous définissez
dans la structure Dfs. Si vous
ajoutez ou ôtez des permissions à  un
dossier ou à  un fichier dans un emplacement,
Dfs va répliquer ces changements
dans tout l’environnement.
Les seuls éléments que Dfs ne répliquera
pas sont les verrous de fichiers
– les indicateurs par lesquels
Win2K détermine si quelqu’un d’autre
est en train de travailler sur un fichier.
Cette considération est importante et
affectera probablement la manière
dont vous choisissez de définir les
structures Dfs. Comme Dfs ne réplique
pas les verrous de fichiers, deux utilisateurs
pourraient fort bien travailler sur
le même fichier en même temps, chacun
avec une copie différente du fichier,
et en croyant que c’est la seule.
Si les deux utilisateurs sauvegardent
alors leurs changements sur le réseau
presque en même temps, un mécanisme
last-writer-wins (le dernier qui
écrit gagne) se produit. Par exemple,
les changements d’un utilisateur pourraient
être écrits sur disque et synchronisés,
puis aussitôt écrasés par les
changements sauvegardés par l’autre
utilisateur. Pour éviter cette situation,
je conseille de toujours considérer les
répliques synchronisées comme des
shares de sauvegarde seulement, c’està –
dire des shares auxquels les utilisateurs
ne devraient jamais accéder directement.
L’une de mes méthodes pour synchroniser
les répliques comme shares
de sauvegarde consiste à  définir les
shares en fonction des sites individuels
qui possèdent les documents, puis à 
définir un share de sauvegarde dans un
autre site. Ainsi, un référentiel de documents
de ventes provenant du bureau
de New York pourrait être dans un
share appelé NYSALESDOCS. Pour répliquer
cette information à  Londres, je
créerais un répertoire, le partagerais
comme NYSALESDOCS-BACKUP, puis
le définirais comme une réplique Dfs.
Cette convention de nom clarifie la nature
du share du serveur de Londres.
On s’en doute, s’il n’existe qu’un
share Dfs SALESDOC master pour l’organisation
globale, Dfs aura du mal à 
forcer les utilisateurs dans un share
spécifique sur un serveur spécifique
parce que Dfs utilise les sites AD pour
déterminer si un share est à  proximité.
Comme la réplication Dfs est déclenchée
par un changement de fichier,
Dfs ne fonctionne pas bien avec
des fichiers base de données qui sont
toujours ouverts – les fichiers base de
données ne rencontrent jamais réellement
une opération « close », donc les
données ne sont jamais synchronisées.
De ce fait, Dfs ne vous aidera pas à  répliquer
vos bases de données
Microsoft SQL Server ou Microsoft
Exchange Server.
Gardons à  l’esprit que la réplication
Dfs est similaire au disque miroir
(c’est-à -dire, le système réplique les
données fournies, bonnes ou mauvaises).
Par conséquent, si un virus infecte
la station de travail d’un utilisateur,
corrompt tous les fichiers *.doc,
et si des utilisateurs modifient ces fichiers,
Dfs répliquera ces fichiers corrompus
du moment qu’ils se trouvent
dans la structure Dfs. Ce scénario explique
pourquoi les sauvegardes classiques
restent nécessaires. Enfin, par
défaut, Dfs ne peut pas répliquer certains
fichiers : les fichiers .bak et .tmp
et tout nom de fichier commençant
par un caractère tilde (~).