Ajuster la réplication

réplication PDC/BDC de NT ne soient pas suffisants pour empêcher les problèmes de bande passante. Dans des réseaux de taille petite et moyenne, NT garde parfaitement les BDC à  jour, sans engorger le réseau. Mais, cela ne vaut pas pour de plus grands réseaux. Pourtant il ne faut pas que cela vous empêche de mettre en oeuvre le modèle qui sécurise le mieux le réseau. Vous pouvez régler finement les paramètres de réplication de NT et optimiser le processus de réplication pour empêcher, ou en tout cas réduire, les ennuis liés à  la réplication. Les paramètres apparaissent dans l’enregistrement (registry) comme des valeurs sous la sous-clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. (Pour plus d’informations sur ces valeurs d’enregistrement, visitez le site http://www.microsoft.com/technet/winnt/winntas/technote/implemntintegra/ntopt4.asp.)

  Chaque ordinateur maintient un compte machine dans le domaine. Par défaut, le mot de passe de ce compte change tous les 7 jours. La valeur MaximumPasswordAge contrôle la fréquence du changement. Quand un domaine contient de nombreux ordinateurs membres, ces changements peuvent occuper le PDC et immobiliser de la bande passante pendant que le PDC réplique les changements sur chaque BDC. Pour réduire cette charge de réplication, on peut augmenter la valeur MaximumPasswordAge des ordinateurs membres. La valeur minimale et maximale en nombre de jours est de 1 et de 1.000.000, respectivement. Vous pouvez aussi désactiver les changements de mots de passe des comptes machines. Pour cela, donnez la valeur 1 à  RefusePasswordChange. Malheureusement, cette modification n’empêche pas les systèmes de harceler régulièrement le PDC avec des demandes de changement de mot de passe.

  Pour empêcher les ordinateurs de faire de telles demandes, donnez la valeur 1 à  DisablePasswordChange sur chaque ordinateur membre. (Je déconseille de mettre cette valeur à  1 sur vos serveurs parce qu’elle risquerait de les exposer davantage à  un pirate qui utiliserait un autre ordinateur pour se faire passer pour le serveur.) Par défaut, le PDC examine sa base de données toutes les 5 minutes (300 secondes) pour voir si des changements ont été apportés aux utilisateurs, groupes, ou politiques des domaines. S’il constate un changement, il envoie un message à  chaque BDC pour l’informer que de nouvelles informations sont disponibles pour réplication. Les BDC contactent alors le PDC et demandent la réplication. La valeur Pulse sur le PDC permet de déterminer la fréquence avec laquelle le PDC examine les changements et en informe les BDC.

  Pour empêcher que tous les BDC ne réclament les changements en même temps et surchargent ainsi le PDC, ce dernier ne notifie qu’un certain nombre de BDC à  la fois. La valeur PulseConcurrency (10, par défaut) contrôle ce nombre. S’il y a de nombreuses mises à  jour toutes les minutes et de nombreux DC, il vaut mieux augmenter cette valeur afin que les BDC reçoivent les mises à  jour selon une bon rythme. Ce faisant, on augmente bien sûr la charge du PDC. Après avoir envoyé une impulsion à  un BDC, le PDC attend pendant un certain temps la réponse du BDC. La valeur PulseTimeout1 sur le PDC contrôle cette durée. Elle peut aller de 1 à  120 (secondes) et est de 10 par défaut. Un BDC sans réaction n’entre pas dans le nombre de BDC que la valeur PulseConcurrency spécifie. Par conséquent, le PDC peut passer à  un BDC opérationnel et prêt pour la réplication. Dans un environnement de réseau lent, où les connexions WAN sont lentes ou encombrées, il peut être judicieux d’augmenter la valeur PulseTimeout1 sur le PDC afin qu’il ne juge pas prématurément qu’un BDC est sans réaction. Faute de quoi, le PDC pourrait fort bien répliquer sur trop de BDC à  la fois.

  Une fois que le PDC a déclenché la réplication, le BDC dirige les opérations en demandant répétitivement au PDC la prochaine tranche de données de réplication. Au milieu de ce processus, un BDC peut fort bien « crasher » ou s’arrêter ; la valeur PulseTimeOut2 sur le PDC contrôle la durée pendant laquelle le PDC attend que le BDC demande la prochaine tranche. La valeur (en secondes) peut aller de 60 à  3.600 ; elle est de 300 par défaut. Si elle est trop basse, on risque de voir trop de BDC demander des changements au PDC en même temps. Le PDC est alors débordé. Il vaut mieux choisir une valeur plus haute afin que le PDC puisse traiter la charge et assurer la réplication en bon ordre et dans les temps.

  Le PDC envoie périodiquement des impulsions aux BDC même quand aucun changement ne s’est produit. Ces impulsions peuvent entraîner un trafic superflu si l’on a de nombreux DC disséminés sur un réseau étendu (WAN). La valeur PulseMaximum sur le PDC contrôle ce comportement : elle est par défaut de 7.200 (secondes – c’est-à -dire 2 heures). Cette valeur peut aller de 60 (1 minute) à  86.400 (24 heures). Le PDC découpe les changements des réplications en blocs et envoie chaque bloc au BDC dès que celui-ci exprime la demande. En modifiant la valeur de ReplicationGoverner sur les BDC, on peut contrôler la quantité de bande passante utilisée par la réplication. ReplicationGoverner est spécifié en pourcentage (100, par défaut) et contrôle le rythme auquel les BDC demandent des blocs de données.

  Le PDC conserve dans un journal les changements apportés à  la base de données des domaines. La valeur ChangeLogSize sur le PDC contrôle la taille du journal (par défaut : 65.536 octets, c’est-à -dire 64 Ko). Dans de vastes domaines subissant de nombreux changements simultanés, le journal peut se remplir. Dans ce cas, le PDC ne peut plus y enregistrer aucun changement et ne garde plus aucune trace des changements reçus par les BDC. Le PDC doit alors répliquer toute la base de données vers les BDC – créant ainsi encore plus de trafic sur le réseau. La taille du journal peut être portée au maximum de 4.194.304 (c’est-à -dire, 4 Mo), mais au prix d’une plus grande consommation d’espace disque et de RAM.