Concevoir la topologie d’un site

exemple,
le nombre de comptes d’utilisateurs créés par jour, la fréquence des changements
de mots de passe, le nombre moyen d’utilisateurs dans les groupes d’utilisateurs
et leur fréquence de connexion. Seules les contraintes de trafic devraient jouer
sur la conception d’une topologie de site.

Microsoft indique le nombre d’octets de données généré sur le réseau lors de la
création d’un nouvel utilisateur ou lors des changements de mots de passe (ces
informations sont données par des ressources comme AD Sizer et le Kit de ressources
Microsoft Windows 2000). Mais vous seul savez à  quelle fréquence vous créez de
nouveaux utilisateurs et à  quelle fréquence ils changent leurs mots de passe.
La duplication AD peut avoir lieu au niveau des attributs (par exemple quand un
utilisateur change de mot de passe, AD ne duplique que l’attribut mot de passe,
pas l’objet utilisateur tout entier). Toutefois il fournit beaucoup plus d’attributs
par objet que la SAM de Windows NT 4.0, et, selon l’utilisation des objets, AD
pourrait générer plus ou moins de trafic que la SAM.

La conception de la topologie de votre site doit répondre aux questions suivantes
:

· A quels moments ai-je besoin d’établir des limites de sites ?

· Combien de bande passante me faut-il pour garantir un temps d’attente faible
à  la duplication AD ?

· A quel moment ai-je besoin de déployer un contrôleur de domaines local au lieu
d’obliger les utilisateurs à  s’authentifiant à  distance ?

Nous avons vu plus haut que les sites contrôlent à  quel moment et à  quelle fréquence
a lieu la duplication AD. (Toutes les 5 minutes pour la duplication intra-sites;
toutes les 15 minutes ou plus pour la duplication inter-sites). On demande souvent
à  partir de quel moment une liaison réseau devient trop lente entre deux contrôleurs
de domaines pour que chacun ait besoin d’avoir son propre site. Il n’existe pas
de règle fixe ou simple. Lorsqu’une liaison avec un lieu distant arrive à  saturation
de duplication AD intra-sites et d’autre trafic, créez un nouveau site pour l’un
des contrôleurs de domaines et planifiez la duplication à  un intervalle plus long.
La duplication inter-sites utilise la compression lorsqu’une transaction dépasse
32 Ko. Cette compression peut être très efficace, atteignant une réduction de
90 pour cent de la taille des données (les changements de mots de passe ne profitent
pas beaucoup de la compression parce qu’ils sont cryptés).

Après avoir grossièrement calculé la quantité de données qui sera dupliquée par
AD à  travers le réseau, vous pouvez définir la fréquence de duplication pour vos
liaisons de sites. Souvenez-vous qu’il s’agit là  de regroupements de sites dans
lesquels les sites sont connectés par des liaisons réseau de bande passante approximativement
égale. Ainsi, si les sites A, B et C se trouvent dans une liaison de sites, ils
se dupliquent tous selon le programme défini pour cette liaison de site. Ce programme
de duplication doit être élaboré pour tirer profit de la compression inter-sites
tout en minimisant le temps d’attente entre les contrôleurs de domaines. Vous
allez peu-être être tenté de définir toutes les liaisons de sites pour qu’elles
dupliquent à  un intervalle minimum – toutes les 15 minutes – afin de réduire au
maximum le temps d’attente. Mais si vous ne générez pas beaucoup de changements,
la quantité de données transmises dans chaque duplication risque de ne pas être
suffisante pour déclencher la compression et, en définitive, vous enverrez plus
de données par duplication qu’avec des duplications plus espacées.

Outre le trafic de duplication provoqué par les changements de contextes de nommage
des domaines AD, il faut également tenir compte d’autres consommateurs de bande
passante dans une conception de topologie de sites. Voici certains des plus évidents.

Les serveurs de CG. Les serveurs désignés comme serveurs CG reçoivent
les changements de chaque domaine d’une forêt. Le nombre de données qu’ils reçoivent
est légèrement inférieure à  celui des changements de chaque domaine individuel,
puisque le CG ne contient qu’une copie partielle du contexte de nommage des domaines
de chaque domaine.

Les partages SYSVOL. Les partages SYSVOL sont dupliqués entre
les contrôleurs de domaines d’un domaine. Les GPO (Group Policy Objects) conservent
aussi des données dans SYSVOL. Le service de duplication de fichiers de NT duplique
les données entre tous les contrôleurs de domaines d’un domaine. Le service de
duplication utilise le site et la topologie de duplication existants pour propager
ces changements.

Les enregistrements des zones DNS. Si vous utilisez le DNS intégré
à  AD, celui-ci conserve les enregistrements de zones dans le contexte de nommage
du domaine dans lequel les serveurs DNS tournent. Les données des zones DNS peuvent
changer fréquemment – par exemple, si vous avez un grand nombre d’utilisateurs
mobiles dont les postes de travail changent d’adresses IP régulièrement.

Les groupes de membres. Les objets Groupes d’AD stockent leurs
membres comme un attribut multi-valeur. Ainsi, lorsque vous changez un utilisateur
dans une liste de 500, AD doit dupliquer la totalité de l’attribut. En fait, Microsoft
recommande de ne pas dépasser les groupes de 5.000 utilisateurs, parce qu’au-dessus
de ce chiffre, il devient difficile de dupliquer la totalité de l’attribut dans
un événement de duplication unique. Si vous devez supporter plus d’utilisateurs
ou d’ordinateurs dans un groupe, utilisez des groupes imbriqués.

Faire passer AD de la théorie à  la pratique exige une planification soigneuse
et une conception judicieuse

Enfin, il faut se fier au cas par cas, si vous voulez placer un contrôleur de
domaine physiquement à  proximité d’une station de travail cliente dans un lieu
distant. Généralement, si le trafic généré par AD et ses services vers un contrôleur
de domaine local est plus important que celui que génèrent les postes de travail
distants pour s’authentifier sur le réseau, il vaudra sans doute mieux ne pas
placer de contrôleur de domaine à  proximité des postes de travail distants. Sachez
aussi que si vous créez un site autour d’un groupe d’utilisateurs distants et
que vous mettez un contrôleur de domaine dans ce site, vous devrez probablement
faire aussi de ce contrôleur de domaine un serveur CG. Cette action augmentera
immédiatement vos besoins en bande passante vers ce site. (Pour en savoir plus
sur la mise en oeuvre des sites AD, voir l’article de Sean Deuby  » Les sites Active
Directory, 2e Partie  » du numéro 40 de Windows 2000 Magazine).

Comme on peut le constater, faire passer AD de la théorie à  la pratique exige
une planification soigneuse et une conception judicieuse. Bon nombre des décisions
de conception doivent se fonder sur des facteurs spécifiques à  l’environnement
et au réseau concernés. Mais en s’aidant du Kit de ressources et d’outils comme
AD Sizer, la mise en oeuvre d’AD n’est pas complètement de la magie noire. L’essentiel
est de comprendre parfaitement comment utiliser AD et jusqu’où…, puis de doubler
tous les chiffres et de s’y tenir, juste par sécurité.