Un serveur d’un pool DFSR n’est plus synchronisé avec les autres

Tout d’abord, la résolution du Staging Quota et une
rapide explication de ce que c’est. Il s’agit d’un espace dont a besoin DFSR
pour opérer proprement la réplication, en fait DFSR s’en sert comme file
d’attente par rapport aux changements qui vont être propagés par la suite sur
tout le pool. La préconisation de Microsoft (voir ce
lien) est d’avoir une taille au minimum équivalente aux 32 plus gros
fichiers du partage répliqué. DFSR fait régulièrement du nettoyage dans cette
file d’attente mais il se peut qu’avec la croissance du partage, le Staging
Quota décidé au départ ne soit pas suffisant. Cette alerte est remontée
dans le journal d’événements (Source : DFSR, Event ID : 4206). J’ai donc
dû l’agrandir ; rien de complexe, cela peut être réalisé en pleine journée car
cela ne nécessite pas de redémarrer le service DFSR. 

Dans dfsmgmt.msc (ou via le Server Manager), on
déroule les réplications, puis en sélectionnant celle qui nous intéresse, on
aura les partages et les serveurs qui constituent ce pool.

L’accès au réglage du Staging Pool s’obtient avec un simple
clic-droit sur le partage, puis Staging.

Maintenant que ce problème est réglé, j’ai réalisé quelques tests
pour d’abord confirmer que le serveur ayant un nombre incohérent de fichiers
dans son partage par rapport aux autres était bien désynchronisé. Un simple
fichier unique créé chacun des 4 serveurs s’est retrouvé propagé sur tous les
autres… sauf un, et celui placé sur le serveur hors synchronisation ne s’est
pas propagé, ce qui signifie que le serveur est désynchronisé à la fois en
envoi comme en réception. Dans la suite de l’exemple, je vais appeler D le serveur
désynchronisé et S le serveur lié qui est en bon état de marche.

D et S sont
deux serveurs Windows 2008 R2 hébergeant un partage DFSR nommé partage ; D et S
doivent avoir les mêmes fichiers (sauf .BAK, .TMP et fichiers commençant par
une tilde car non répliqués par DFSR) et l’un et l’autre opèrent les
transactions en envoi comme en réception. J’ai vérifié si des fichiers
étaient programmés en envoi ou en réception avec cette instruction :

dfsrdiag ReplicationState

Rien. Je vérifie si il reste des fichiers en attente de synchronisation, autrement appelés backlog :

dfsrdiag backlog /SendingMember:D /ReceivingMember:S /RGName:partage
/RFName:partage

Et en effet, de nombreux fichiers étaient en attente de synchronisation, et dans les deux sens ; un état des lieux des fichiers a confirmé cette différence.

Il a donc été décidé de procéder à la suppression et
recréation des liens du serveur D au niveau DFSR. Tout d’abord, on procèdera à
la désactivation du partage dans la console DFS avant de procéder à sa suppression.

En choisissant la première option, non seulement on indique
que l’on ne souhaite plus que le serveur D ne se réplique plus, mais en plus,
on supprime ses liens avec le serveur S (ou le reste du pool, le cas échéant).
En choisissant la deuxième option, on pourrait toujours tomber sur le serveur D
en appelant le partage, ce qui n’est pas souhaitable.

Une fois la suppression effectuée, on procède au rajout de D
comme membre du pool DFS aux côtés de S, en prenant bien soin d’y appliquer les
mêmes paramètres. Rien de complexe, je lie le serveur D à S (qui lui-même peut
être relié à d’autres serveurs du pool), dans les deux sens (envoi et
réception). Quelques captures d’écran du wizard à titre d’exemple :

Un petit tour dans le journal d’événements de S m’indique
qu’il arrête la communication avec son partenaire D à cause d’une erreur
(Source : DFSR, Event ID : 5014).

Je dois donc attendre la réplication entre les ActiveDirectory pour qu’ils enregistrent tous la suppression du membre et son retour dans le pool. Ensuite, cette instruction exécutée sur D et S me permet de les forcer à bien actualiser les informations DFSR afin qu’ils soient totalement à jour.

dfsrdiag pollad

Tout ça, pour rien. Toujours pas une trace de
synchronisation entre D et S. Et dans le journal d’événements de D, je trouve une entrée
m’indiquant qu’il communique bien avec S ; mais ce n’est pas réciproque puisque
S me dit que D n’est plus membre du pool DFS. Je décide donc de regarder au
niveau ActiveDirectory pour voir si je peux y trouver les paramètres DFS. Le
journal d’évènements permet de savoir avec quel DC les serveurs communiquent (Event
ID : 1206).

Un petit coup d’ADSI Edit sur chaque DC sur lequel un
serveur est connecté permet d’en savoir plus : les informations propres à DFSR
se trouvent dans l’objet du serveur. Les réplications sont bonnes car les mêmes
objets sont disponibles sur le DC où D et S sont connectés. A noter que cette
référence au DC ne change que lorsque le service DFSR démarre ; si le DC en
question est arrêté ou supprimé, il faut redémarrer le service DFSR pour que la
prise en compte soit effective et cela peut occasionner des désynchronisations
si ce n’est pas fait.

 

Par acquis de conscience, je vérifie tout de même mes
réplications : repadmin /showrepl * ne me renvoie rien de particulier, toutes
les réplications sont valides et datent de 30 minutes tout au plus. Par ailleurs, le bilan de santé effectué à partir de la
console d’administration DFSR m’indique toujours le même message : « This member is
waiting for initial replication for replicated folder partage and is not
currently participating in replication. This delay can occur because the member is waiting for the DFS
Replication service to retrieve replication settings from Active Directory Domain
Services. After the member detects that it is part of replication group, the
member will begin initial replication.« 

Il est possible d’avoir ce message lorsqu’il n’y a plus de
membre primaire sur le pool DFS ; le membre principal étant celui qui sert
de maître par rapport aux fichiers et qui écrasera les autres lors de la
réplication initiale seulement. Je ne trouve aucune trace dans les journaux
d’évènements (Event ID à chercher : 4002 puis 4112). Je décide alors de
faire du serveur DFS principal le membre primaire :

Je force une réplication sur tous les contrôleurs de domaine
afin que l’information se propage sur tous les sites et ensuite je demande aux
serveurs DFS de requêter l’AD pour obtenir le nouveau serveur primaire. Toujours pas mieux.

Finalement, j’ai décidé de supprimer complètement mon partage DFSR, liens et namespace et je l’ai recréé de zéro : les serveurs se synchronisent désormais proprement.