mercredi 13 juin 2018

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

J'ai rencontré depuis quelques temps des soucis par rapport à un partage réseau porté par DFSR sur 4 serveurs 2008 R2. Tout d'abord, un premier dysfonctionnement concernant le Staging Quota plutôt simple à résoudre, et ensuite un des 4 serveurs qui n'était plus synchronisé avec les 3 autres, résultant en des différences notables entre les répertoires et les fichiers.

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 :
dfsradmin Membership Set /RGname:partage /RFName:partage /MemName:ServPrim /IsPrimary:True

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.

Aucun commentaire:

Enregistrer un commentaire