Windows DFSR - Changement des autorisations de répertoire répliqué et avoir maintenant un backlog de 350 000 pendant plus d'une semaine

Question: Existe-t-il un moyen d'accélérer le traitement de ce dossier de 350 000 fichiers? Pour presque chaque fichier, le seul changement a été une modification de l'ACL pour chaque fichier affecté. Certains fichiers ont changé de contenu, mais ce n'est pas le cas courant dans cette situation.

Cela pourrait être corrigé. Je vais modifier ce texte pour confirmer le succès / l'échec après une période de temps et une vérification. Vers la fin de ce texte de question, j'ai détaillé les modifications apportées récemment qui auraient pu le corriger.

Nous avons un groupe de réplication DFSR avec environ 450 000 fichiers et occupe 1,5 To d'espace. Dans cette situation, deux serveurs Windows Server 2008 R2 sont distants d'environ 500 miles. Il existe d'autres serveurs, mais ils ne sont pas impliqués dans ce groupe de réplication. Le serveur ALPHA est le serveur principal et est celui utilisé par la plupart du personnel. Le serveur BETA est le serveur du bureau distant et est moins occupé.

Voici un graphique du backlog de ce groupe de réplication (PNG hébergé sur Google Drive) montrant la lente progression de la synchronisation.

J'ai dû supprimer une entrée d'autorisation qui se trouvait dans le répertoire racine de ce groupe de réplication, qui bien sûr a été héritée dans la plupart des sous-dossiers. J'ai fait ce changement sur le serveur ALPHA. Immédiatement après cela, DFSR avait un arriéré de 350 000 fichiers. Cela fait plus d'une semaine et elle est maintenant à 267 000. La seule chose qui a changé (initialement) était le changement de permission unique.

C'est ce qui s'est passé (ce n'est pas la solution, juste une autre explication de ce qui est arrivé à provoquer ce problème): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -parce que cela se révèle-vendredi-soir-était-bien-pour-combattre.aspx # dfsr

Toutes les modifications qui se produisent sur le serveur BETA sont répliquées sur le serveur ALPHA très rapidement car il n'y a pas de retard dans cette direction. Tous les fichiers modifiés sur BETA parviennent à ALPHA sans problème.

Il se réplique 24 heures sur 24, 7 jours sur 7, à pleine vitesse sur une connexion à 50 Mbps à une extrémité et sur une fibre à 100 Mbps à l'autre extrémité. La zone de transit est de 100 Go sur chaque serveur. Il n'y a rien d'intéressant dans les journaux d'événements. Il existe un événement de filigrane élevé non lié qui apparaît pour un groupe de réplication non lié qui n'est ni pour cette réplication particulière ni pour cette paire de serveurs ALPHA / BETA. En particulier, il n'y a aucune entrée dans le journal des événements pour le filigrane élevé ni pour les erreurs de connexion.

Vue d'ALPHA sur le groupe de réplication:

Économies de bande passante : réduction de 99,83% (30,85 Mo répliqués au lieu de 18,1 Go)

Je crois que le 30,85 Mo / 18,1 Go s'est produit depuis le dernier redémarrage du service DFSR sur ALPHA et BETA. Si c'est le cas, cela montre que même si cela prend très longtemps (plus longtemps que je ne le pense), il ne transfère pas réellement le contenu du fichier sur le fil.

Dossier répliqué : 1,46 To (taille réelle), 439 387 (fichiers), 52 886 (dossiers)

Conflit et dossier supprimé : 100,00 Go (taille configurée), 34,01 Go (taille réelle), 19 620 (fichiers), 2 393 (dossiers)

Dossier intermédiaire: 200,00 Go (taille configurée), 92,54 Go (taille réelle)

J'ai eu une erreur de filigrane élevé dans les journaux (14 mai, 19 h) et j'ai donc augmenté le quota de mise en scène de 200 Go à 200 Go. Je sais que l'itinéraire approuvé par Microsoft doit augmenter de 20%, mais je ne joue pas là-dessus. Nous avons beaucoup d'espace disque à épargner sur les baies de disques intermédiaires.

La désactivation de l'antivirus sur tous les serveurs n'a pas aidé, même si je pensais que cela aurait aidé un peu. Pour l'instant, j'ai réactivé l'antivirus, mais j'ai défini le chemin du groupe de réplication à exclure de l'analyse afin de supprimer cette variable de l'équation.

Existe-t-il un moyen pour que cela aille plus vite? Je ferais simplement cette modification sur le serveur BETA également, mais il y a des fichiers qui ont changé sur ALPHA mais qui n'ont pas été répliqués sur BETA et en faisant la modification de l'autorisation héritée sur BETA, les anciens fichiers de BETA à ALPHA seront poussés (car DFSR semble ignorer les horodatages des fichiers lors de la comparaison du fichier gagnant dans une collision). Et que cela se produise serait plutôt mauvais.

L'arriéré diminue lentement. Très, très lentement. Cela va de l'avant, cependant. Mais à ce rythme, il faudra des semaines avant de terminer. J'envisage simplement de pousser une copie de l'ensemble de données sur un lecteur de 3 To et de l'envoyer au bureau distant. Y a-t-il une meilleure façon?

16 mai, 4 h 00, heure des États-Unis: qu'est-ce qui aurait pu résoudre le problème (en supposant qu'il soit honnêtement résolu, de toute façon):

J'ai apporté plusieurs modifications aux contrôleurs de domaine qui auraient dû être apportées il y a longtemps. Le problème est que ce réseau a été hérité de quelqu'un d'autre qui l'a probablement hérité de quelqu'un d'autre, etc. Je ne peux pas promettre quel changement a résolu le problème. Les voici sans ordre particulier:

• Tous les contrôleurs de domaine n'étaient pas dans l'unité d'organisation «Contrôleurs de domaine». Je n'ai jamais vu un domaine Windows qui avait ses contrôleurs de domaine ailleurs. Je les ai ramenés là où ils appartenaient. Ils étaient auparavant dans OUs qui ont été séparés par le nom de la ville chaque bureau est. (Je sens que j'ai des travaux de plomberie pour traiter maintenant que je me suis déplacé ceux -ci , mais tout semble bien à l' heure actuelle ...)
• AVG Anti-Virus s'exécute sur tous les contrôleurs de domaine et serveurs DFSR participants. J'ai exclu les dossiers répliqués et les dossiers intermédiaires de l'analyse active / sur accès. Je ne pense pas que cela ait résolu le problème et je suis susceptible de tester ce problème plus tard pour voir si l'annulation de cette modification interfère avec la vitesse de réplication de DFSR. C'est un défi pour un autre jour.
• dcdiag.exe s'est plaint d'un problème DNS concernant les contrôleurs de domaine en lecture seule. J'ai résolu ce problème même si nous n'avons aucun RODC sur le domaine. Je doute que cela fixe quoi que ce soit.
• Un des enregistrements _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV était manquant pour l'un des contrôleurs de domaine (pas un des serveurs DFSR) et j'ai corrigé cela. Je ne pense pas que cela ait aidé non plus.
• Une fois que j'ai redémarré le serveur BETA, il s'est plaint d'un mauvais arrêt de la base de données DFSR (événement 2212) et il a ensuite fallu des heures pour reconstruire la base de données. Une fois terminé, il a signalé l'événement 2214 pour me le signaler. Après cela, la réplication fonctionnait toujours très lentement, mais cela aurait pu aider à décoller tout ce qui était bloqué.
• L'un des contrôleurs de domaine n'avait pas 127.0.0.1 comme serveur DNS secondaire dans sa configuration d'interface. Je l'ai ajouté. Ce n'était pas l'un des serveurs DFSR, donc cela n'avait probablement rien à voir avec cela.
• J'ai suivi le blog TechNet: réglage des performances de réplication dans les paramètres de registre recommandés par DFSR pour les serveurs DFSR. J'ai utilisé toutes les valeurs de "valeur de haute performance testée", à l'exception de AsyncIoMaxBufferSizeBytes qui était réglé sur 4194304, ce qui est un cran plus bas que la valeur élevée. Cela aurait pu aider avec le problème ... ou peut-être pas. Il est difficile de dire quand on change trop de variables.
• dcdiag.exe s'est plaint d'un problème de communication avec le service RPC sur BETA, mais seulement après avoir déjà effectué les modifications ci-dessus. Cela semblait être le problème le plus probable, mais je n'ai rien fait pour le corriger. Le VPN fonctionnait correctement et le pare-feu ne le bloquait pas. Il est possible que l'un des éléments ci-dessus soit à l'origine de la résolution du problème RPC, puis qu'il ait été résolu, ou que ce soit une simple coïncidence. Je n'obtiens pas cette erreur maintenant et la réplication se déroule correctement à l'heure actuelle.

La morale de l'histoire est la suivante: changez une chose à la fois ou vous ne saurez jamais vraiment ce qui l'a fixée. Mais j'étais désespéré et je manquais de temps pour le réparer, alors je viens de tirer un tas de balles sur le problème. Si jamais je trouve le correctif, je le signalerai ici. Ne comptez pas sur moi pour le réduire, cependant.

EDIT 21/05/2012: J'ai résolu cela en conduisant pendant environ sept heures avec un serveur de rechange (GAMMA) au bureau distant hier. GAMMA agit désormais comme leur serveur local principal tandis que leur serveur habituel (BETA) rattrape la réplication. Depuis que je l'ai mis en place, les serveurs ont doublé la vitesse de réplication. Bien que cela m'indique qu'il pourrait s'agir d'un problème lié au VPN, je suis moins enclin à croire que c'est parce que toutes les nouvelles mises à jour semblent se répliquer sur GAMMA à partir d'ALPHA ont été très rapides et se déroulent bien.

EDIT 22/05/2012: Il est à 12 000 en ce moment et devrait être terminé dans quelques heures. Je posterai un joli graphique de la progression du début lent à la fin rapide. Le problème est que la seule chose qui a réellement "corrigé" c'est la connexion au serveur local. Je pense actuellement que le VPN fait peut-être partie du problème. Et si c'est le cas, je pense que cette question n'a pas encore de réponse. Après avoir eu plus de temps pour vérifier comment les choses se répliquent via le VPN et voir les pannes, je déboguerai et signalerai la progression.

Si quelque chose change, je mettrai à jour ici.

Problème très étrange, surtout après avoir révisé le montage.

Je voudrais inspecter le journal de débogage DFSR, qui se trouve ici:% systemroot% \ debug Par défaut, il devrait y avoir 9 fichiers journaux précédents qui ont été archivés GZ, et un qui est actuellement en cours d'écriture.

Ouvrez-le dans un fichier texte et recherchez le texte "avertissement" ou "erreur". Vous pouvez consulter cette série de blogs pour des informations plus détaillées sur les journaux de débogage: http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1- logging-levels-log-format-guid-s.aspx

Autres questions / suggestions:

Y a-t-il quelque chose de déplacé lorsque l'on regarde le moniteur de ressources? Excès d'activité sur le disque dur ou le processeur en dehors d'une ligne de base?

Si possible, je redémarrerais les serveurs Alpha et Bêta. Si cela résout votre problème, vous ne saurez peut-être jamais quel était le véritable problème, mais s'il est essentiel que cela soit résolu rapidement, cela vaut la peine d'essayer.

Modifier en fonction de la mise à jour des questions

Vous avez mentionné deux entrées liées à un fichier de 850 Mo, ainsi qu'une erreur dans le journal de débogage DFSR.

Pouvez-vous essayer de changer l'emplacement de transfert vers un dossier ou un lecteur différent sur chaque serveur? Dans le cas où les fichiers en cours de transfert sont corrompus ou bloquent la réplication d'une manière ou d'une autre.

Vous pouvez modifier le calendrier de réplication pour permettre à DFS-R de se répliquer à pleine vitesse pendant les heures creuses (ou même pendant les heures le cas échéant).

Vous pouvez également essayer d'augmenter la taille de transfert sur le serveur connecté à l'arrière. Il devrait augmenter les performances dans cette situation.

Vous ne mentionnez pas s'il est plafonné ou non, mais je suppose que c'est le cas puisque vous avez une réplication sur un WAN.

D'après mon expérience, c'est comme ça que ça fonctionne.

Je suis tombé sur cela après avoir mis à jour la sécurité sur une assez petite collection de 4 groupes de réplication DFS (550 Go de données, 58k fichiers, 3,4k dossiers au total). Les données réellement transmises sur le câble sont faibles, il ne semble donc pas déplacer des fichiers entiers uniquement pour des modifications de sécurité, mais l'activité du disque semble être recopiée comme toute la hiérarchie - des taux de transfert de disque soutenus entre 60 et 100 Mo / s et des files d'attente de disque de 30, culminant à 500 sur un espace de stockage à plusieurs niveaux SSD.

Mon sentiment est que DFS a beaucoup de désabonnement dans son processus de transfert et de destaging, ce qui entraîne des E / S de disque extrêmes. Un processus de réplication initial entre deux boîtiers connectés au réseau local gigabit prend plusieurs fois plus de temps que les mêmes données simplement copiées entre les boîtiers, ce qui semble indiquer que chaque octet répliqué nécessite plusieurs octets de lecture et d'écriture sur le disque.

Les mises à jour de sécurité ne semblent pas avoir de logique de réplication spéciale interdisant l'utilisation de la sécurité basée sur les revendications 2012 (qui n'est pas largement utilisée AFAICT), ce qui entraîne le même taux de désabonnement que vous obtiendriez pour les modifications de données.