Active Directory – Sinistre de réplication

Notre premier cas concerne un architecte d’une topologie AD qui souhaitait instaurer une topologie multiniveaux calquée sur son réseau.

Il disposait de trois sites centraux à New York et Los Angeles, lesquels étaient interconnectés par une liaison réseau dédiée à haut débit. Le niveau suivant comportait quatre sites régionaux à Omaha, Dallas, Atlanta et Providence. Chacune des régions avait deux sites sous-régionaux. Le plan visait à créer trois niveaux, central, régional et sous-régional, afin de permettre la réplication des sous-régions vers les sites régionaux, lesquels devaient répliquer au niveau central, les sites centraux se répliquant les uns vers les autres. Cette approche était censée tirer parti de la topologie du réseau.

Active Directory – Comment gérer le Sinistre de réplication ?

Malheureusement, la topologie ne pouvait pas fonctionner. Une des règles de la conception de réplication stipule que les liaisons doivent avoir des sites communs à répliquer. Par exemple, il est impossible d’avoir une liaison de site entre Washington, D.C. et Raleigh, et une autre entre Dallas et Topeka. Il aurait fallu ajouter une liaison avec Raleigh et Dallas. Dans notre scénario, les informaticiens placèrent les sites de siège régionaux d’Omaha (OMH), de Dallas (DAL), d’Atlanta (ATL) et de Providence (PRO) sur les liaisons de niveaux deux et trois (cf. figure 1). Par exemple, le site OMH faisait partie des liaisons Midwest Link et West Link. De même, le site central Los Angeles était rattaché aux liaisons de site East Region Link et Core Link. Cela devait fournir le ciment pour permettre à la réplication de passer des sites de niveau trois aux sites centraux.

Figure 1. La topologie initiale présentée ici est finalement tombé en panne.

Cette conception a effectivement fonctionné jusqu’à ce qu’un DC du site OMH connaisse une défaillance de disque. Notez qu’il s’agissait du site « ciment » qui rattachait les autres sites aux sites East Region. Avec la passerelle de liaison de sites activée, l’outil KCC (Knowledge Consistency Checker) a été en mesure de rétablir les choses après la perte du DC OMH. Toutefois, une fois le DC OMH restauré, le KCC a sélectionné le DC de Tucson (TUS) comme cible de la réplication pour le second niveau. Dans ce cas, cela a amené tous les DC Midwest Link à répliquer vers le DC TUS au lieu du DC OMH. Cela a complètement désorganisé la conception de réplication, laquelle était basée sur la vitesse du réseau et sa fiabilité.

Le seul moyen pour les informaticiens de rétablir les flux de réplication a été d’effacer et de réinstaller le DC OMH. Quelques semaines plus tard, le DC ATL est tombé en panne et le KCC a sélectionné le DC de Richmond (RCH) comme cible de réplication des DC de la liaison ATL. Encore une fois, le seul moyen de rétablir la réplication conformément au design souhaité a consisté à réinstaller le DC ATL. Bien évidemment, les informaticiens se sont inquiétés du fait de devoir, à chaque fois, réinstaller un DC placé hors ligne pendant quelques jours. Par ailleurs, certains DC d’autres régions ont commencé à répliquer vers tous les DC de la forêt. Cela a entraîné des erreurs de réplication et certains DC ont enregistré des pics de trafic réseau considérables, d’où une véritable pagaille.

Je n’ai pas eu vraiment d’autre explication à ce comportement que le fait que le KCC sélectionnait le GUID le plus petit. Les informaticiens ont laissé trop de latitude de choix au KCC en plaçant plus de deux sites sur une liaison de site. La solution a consisté à supprimer toutes les liaisons de sites et à les récréer avec pas plus de deux sites par liaison. La liaison Midwest Link a été remplacée par la liaison OMH-FTC, la liaison OMH-TUS, etc. (cf. figure 2). La liaison West Region Link a laissé la place à la liaison OMH-LAX, ainsi qu’à des liaisons individuelles entre chaque site de siège régional et le site LAX ou NYC, en fonction de leur implantation géographique.

Figure 2. La solution au problème de réplication a consisté à simplifier la conception —création d’une relation 1:1 entre le site OMH à l’échelon de réplication de niveau 2 et les sites de 3e niveau FTC, SBD, TUS et LAS. Cela force le KCC à répliquer uniquement entre deux sites à la fois et à ne pas avoir à effectuer une décision.

L’administrateur a décidé de ne reconfigurer qu’une seule région. Pour la tester, il a supprimé un DC puis l’a réintégré et la réplication a continué sans incident. Il a reconfiguré le reste de la forêt et tous les problèmes de réplication ont disparu. Le point important ici est qu’il a effectué ces opérations pendant les heures de bureau. Evidemment, la réplication a été probablement interrompue pendant quelques cycles, mais cela n’a pas eu d’incidence dommageable. La réplication a été relativement robuste. Aucun redémarrage n’a été nécessaire et les utilisateurs n’ont connu aucune interruption.

SOLUTION : Faites attention à la conception de la topologie AD et respectez les règles notées ici. Mais n’oubliez pas que même une conception erronée peut facilement être corrigée.

Active Directory, Armageddon, exemple de sinistre

Active Directory, Armageddon, exemple de sinistre