Comprendre le basculement des DC

à  fonctionner
normalement (en cas, par exemple, d’un disjoncteur défaillant
ou d’une panne de climatisation). Comme de telles situations
sont rares, il n’est pas financièrement justifié de
prévoir ce genre de basculement.
Mais alors, que se passe-t-il dans une topologie de sites
classique quand un basculement de DC se produit ? Si
SPOKE1-DC1 est indisponible, le client tente de s’adresser
au DC suivant dans la liste des DC. Rappelons que la liste est
constituée des DC pour l’ensemble du site et des DC pour
l’ensemble du domaine. Comme le site Spoke1 ne contient
qu’un DC et parce que ce DC ne répond
pas aux pings de LDAP (Lightweight
Directory Access Protocol) sur UDP du
client, ce dernier commence à  interroger
les DC de l’ensemble du domaine sur la
liste. Les autres DC de la liste apparaissent
en ordre aléatoire, donc le DC suivant
que le client interroge peut se trouver
n’importe où dans le domaine. Le
client va explorer cette liste jusqu’à  ce
qu’un DC réponde à  ses requêtes.
Le fait d’interroger les DC de tous les
domaines sur la liste diminue pour le
client les chances d’obtenir le meilleur
DC possible, parce qu’aucun DC n’est favorisé
par rapport à  un autre, quelle que
soit la proximité de tel ou tel DC par rapport
au client. L’intervalle de requête des
DC Windows 2003 et Win2K – l’intervalle
d’attente du client entre les requêtes
avant de passer au prochain DC sur la
liste – vient aussi aggraver la situation.
Dans Windows NT 4.0, l’OS envoyait ces
requêtes immédiatement sans aucune
pause entre elles. Par conséquent, le DC
le plus rapide à  répondre (probablement
le plus proche) gagnait l’établissement
de la session avec le client. Dans Win2K,
le client attend 100 millisecondes (ms)
entre les requêtes de DC. Dans Windows
2003, le client attend 400 millisecondes
entre les requêtes pour les cinq premiers
DC, puis 200 ms entre les cinq suivants,
puis 100 ms entre les DC restants. Dans
Windows 2003 ou Win2K, cet intervalle
permet facilement au client de choisir un
DC inadéquat.
La figure 2 montre comment ce comportement
va influencer le choix des DC.
Supposons que la latence du réseau
entre le client et les DC dans Spoke3 soit
de 150 ms. Les DC situés dans le site Hub
le plus proche ne sont qu’à  75 ms du
client. Comme SPOKE3-DC2 est en haut
de la liste des DC, le client lui envoie un ping en premier.
Dans un réseau Win2K, SPOKE3-DC2 ne peut pas répondre
dans l’intervalle de 100 ms et donc le client passe au DC suivant
sur la liste et envoie un ping à  HUB-DC2, un choix plus
approprié. Mais, avant que HUB-DC2 puisse répondre, la réponse
de SPOKE3-DC2, qui a une avance de 100 ms, revient au client et celui-ci établit une session avec ce DC. Dans un
réseau Windows 2003, SPOKE3-DC2 a largement le temps de
répondre avant que l’intervalle de 400 ms n’ait expiré et que
le client ne tente de contacter le DC suivant dans la liste.
Dans l’une ou l’autre des configurations, si votre client ne
peut pas trouver un DC dans son propre site et si vous
n’influencez pas manuellement la liste des DC de tout le
domaine, vous risquez de ne pas obtenir le DC le plus
approprié.