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.
dfsrdiag replicationstate /amontre qu'il n'envoie que deux fichiers, mais les deux ont le même nom de fichier. Il dit qu'il a deux connexions sortantes vers BETA d'ALPHA, de toute façon. Le fichier qu'il envoie est de 850 Mo. Comme décrit précédemment, je ne suis pas convaincu qu'il envoie réellement le contenu complet du fichier, bien que je ne sois pas sûr de ce qu'il ferait sinon, car cela prend très longtemps juste pour traiter un seul fichier. Le fichier a été mis à jour pour la dernière fois en 2008 (sur les deux serveurs), il n'y a donc aucune raison de devoir faire autre chose que de mettre à jour les informations ACL du fichier sur BETA.