Offrir la fonction de basculement des DC

proche de celui du client peuvent
s’enregistrer automatiquement dans le site dépourvu de
DC. En réalité, ces DC n’assurent la couverture que si aucun
DC n’est enregistré dans le site du client. Comme Auto-
SiteCoverage ne fonctionne pas si un DC existe dans le site
du client mais ne répond pas, AutoSiteCoverage n’est d’aucune
aide quant au basculement des DC. Mais on peut forcer
manuellement un DC à  s’enregistrer lui-même pour fournir
les services DC ou GC pour un autre site. Pour cela, il faut
ajouter les noms des sites (séparés par des espaces) à  la valeur
de registre SiteCoverage du type REG_DWORD à  la
sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\Netlogon\Parameters et effectuer
des opérations supplémentaires que nous verrons plus
loin, pour que l’enregistrement fonctionne correctement.
Vous avez le choix entre trois techniques principales
pour doter votre réseau de la fonction basculement des DC.
Selon vos besoins, vous utiliserez ces techniques individuellement
ou combinées.

Méthode 1 : Enregistrement SRV sélectif. Comme on l’a
vu plus haut, en contrôlant le contenu de la liste des DC, on
contrôle le comportement du basculement des DC du client.
Dans notre exemple, la section pour l’ensemble du domaine
de la liste des DC contient des DC provenant des sites
Spoke2 et Spoke3 distants ainsi que du site Hub plus proche.
Et si l’on pouvait empêcher DNS d’ajouter les DC Spoke2 et
Spoke3 tout en continuant à  ajouter les DC Hub à  la liste des
DC? On le peut, par une technique qui empêche les DC du
site-spoke d’inscrire leurs enregistrements SRV pour l’ensemble
du domaine. En d’autres termes, si les sites spoke
n’inscrivent pas leurs enregistrements SRV pour l’ensemble
du domaine (_ldap._ tcp.dc._msdcs.domain.name, par
exemple), DNS les exclura de la section
pour l’ensemble du domaine de la liste
des DC. En conséquence, la section pour
l’ensemble du domaine ne contiendra
que les DC du site Hub comme le montre
la figure 3. Toutefois, cette technique
n’empêche pas les DC du site-spoke
d’inscrire les enregistrements SRV spécifiques
au site. Parce que les DC du sitespoke
inscrivent leurs enregistrements
SRV spécifiques au site, quand un client
du site-spoke demande une liste de DC,
les DC du site-spoke apparaissent dans la
section DC pour l’ensemble du site de la
liste.

Pour plus de détails sur la manière
d’empêcher les DC d’inscrire certains enregistrements
SRV dans DNS, voir le
Microsoft Active Directory Branch Office
Guide Series : Planning Guide, chapitre 2, « Structural
Planning for Branch Office Environments » (http:// www.microsoft.
com/technet/treeview/default.asp?url=/technet/pr
odtechnol/ad/windows 2000/deploy/adguide/default.asp).

Méthode 2 : Priorité DNS. Il existe un autre moyen de
s’assurer que les sites spoke basculent vers le hub plutôt que
vers d’autres spokes : en manipulant la priorité DNS de l’enregistrement
SRV d’un DC. La priorité est une composante
de l’enregistrement SRV. C’est un nombre arbitraire qui est
d’autant plus bas que la priorité est haute. Par défaut, la priorité
DNS d’un DC est zéro. Tous les autres facteurs étant
égaux, les DC avec un chiffre de priorité inférieur se trouveront
plus haut dans la liste des DC que les DC dont le chiffre
de priorité est supérieur. On peut donc tout à  fait utiliser le
champ priorité de l’enregistrement SRV pour influencer
l’ordre de la liste des DC.
La figure 4 montre notre exemple hub-and-spoke auquel ont été ajoutées les priorités RSV. Les DC du site hub ont une
haute priorité de 10, tandis que les sites Spoke1, Spoke2 et
Spoke3 ont des priorités moindres de 20. Comme ces priorités
influencent la liste des DC, les DC du site hub de haute
priorité précèdent toujours les DC des sites Spoke2 et
Spoke3 de basse priorité. Bien que le DC dans le site
(Spoke1) du client ait aussi une basse priorité, le DC Spoke1
précède les DC hub de haute priorité dans la liste des DC,
parce que les DC dans le site d’un client apparaissent toujours
avant tous les autres DC de la liste. Pour contrôler le
champ priorité de l’enregistrement SRV d’un DC, il faut ajouter
la valeur de registre LdapSrvPriority de type REG-DWORD
à  la sous-clé de registre HKEY_LOCAL_MACHINE\SYSTEMCurrentControlSet\Services\Netlogon\Parameters. Si
l’on veut que tous les DC d’un site reçoivent le même traitement
dans la liste des DC, ils doivent avoir la même priorité.

Méthode 3 : Couverture forcée du site soeur. La méthode
du site soeur, que l’on peut combiner aux deux méthodes
précédentes, permet de créer un basculement de DC
en deux étapes pour des topologies plus complexes. Par
exemple, comme on le voit figure 5, les sites Spoke1 et
Spoke3 sont physiquement voisins et connectés par un circuit
WAN à  haute bande passante. Un circuit à  faible bande
passante connecte le site hub au site Spoke3. (Par souci de
simplicité, j’ai laissé le site Spoke2 hors de l’exemple, tout en
laissant son DC dans la liste des DC.) Cette topologie est courante
pour des entreprises américaines opérant dans la région
Asie-Pacifique, où deux emplacements proches sont
connectés entre eux par un circuit à  haute bande passante,
mais reliés à  l’Amérique du Nord par un circuit dont la bande
passante est relativement faible.
Dans une telle situation, le basculement doit se produire
d’abord vers un site soeur proche et ne se produire vers un
site hub des Etats-Unis que si le site soeur est indisponible.
Pour créer ce genre de basculement, il faut utiliser la clé de
registre SiteCoverage pour attribuer un DC comme appartenant
à  un site. Avant de commencer, il faut réfléchir à  la manière
dont vous empêcherez les clients de choisir le DC de
couverture (qui se trouve dans un lieu différent et est probablement
plus lent à  répondre) aussi souvent qu’ils choisissent
les DC locaux – du point de vue du client, les deux DC
sont dans le site du client et sont par conséquent d’intérêt
égal. La réponse consiste à  utiliser la priorité DNS pour
rendre les DC du site soeur un peu moins désirables que le
DC local, en mettant la priorité DNS de Spoke1 à  15 et celle
du site soeur Spoke3 à  20. Avec cette configuration, le DC local
apparaîtra toujours premier dans la section DC sur site de
la liste des DC.
Nous allons suivre un scénario de basculement de DC
pour tester la configuration. Quand tous les DC seront disponibles,
Client1 choisira toujours SPOKE1-DC1 parce qu’il
se trouve sur le site et a la plus haute priorité. Si SPOKE1-
DC1 n’est pas disponible, Client1 choisira SPOKE3-DC1 ou
SPOKE3-DC2 parce que le client les voit comme étant sur le
site ; leur priorité plus faible n’a pas d’importance parce que
le SPOKE1-DC1 de priorité supérieure est indisponible. Si
SPOKE1-DC et les DC Spoke3 sont tous deux indisponibles,
Client1 choisira l’un des DC du site hub parce qu’ils ont la
plus faible priorité des DC pour l’ensemble du domaine disponibles.
Si Spoke1 et Spoke3 sont tous deux indisponibles,
il est clair que Client1 aura des soucis bien plus graves que
ceux-là .
Cette méthode du site soeur offre une possibilité de basculement
de DC à  la fois robuste et multicouche, convenant
à  de nombreux genres de topologies de sites. Mais ce modèle
ne va pas sans inconvénients : il est complexe à  configurer,
compliqué à  maintenir et difficile à  expliquer.