Gérer la charge de vos contrôleurs de domaine

Envoyer

Sommaire

 

 

Introduction

Dans cet article nous allons voir comment assurer la priorité d'un contrôleur de domaine pour les ouvertures de sessions clients.

Afin de pouvoir étayer nos propos, nous partons d'une architecture composée d’un contrôleur de domaine sous 2003 R2 disposant des rôles FSMO et portant le nom de W2K3, d’un contrôleur de domaine additionnel sous 2008 R2 nommé W2K8 et d’un poste client sous Windows XP. Le domaine est « domaine.local ».

 

 

Comment est localisé un contrôleur de domaine?

Cette section est rédigée à partir des documents Microsoft « How Domain Controllers Are Located in Windows » et « Domain Controller Locator ».  Nous vous engageons à les consulter.

Pour commencer, les clients utilisent deux types de localisation : DNS ou NetBIOS. Bien entendu, NetBIOS est toujours présent pour assurer une compatibilité descendante aux versions antérieures à Windows 2000. Nous ne traiterons pas ici de la recherche basée sur NetBIOS.

Le client débute une communication RPC via le service Netlogon pour localiser un contrôleur à sa disposition.  Ce dernier recueille un ensemble d’information pour arriver à ses fins grâce à la fonction implémentée DsGetDcName. Nous pouvons simuler cette requête grâce à l’outil « NLTEST » (disponible depuis le pack support tools pour un 2003 ou intégrer avec le rôle AD DS de 2008). Dans l’exemple ci-dessous, nous lançons la commande « nltest /dsgetdc:[MONDOMAINE] /force » afin de vérifier les informations retournées. Nous constatons que la commande retourne en alternance les contrôleurs disponibles.

 

 

 

 

 

 

Un autre paramètre de « NLTEST » (/DSGETSITE), nous permet également de connaitre le site d’appartenance du poste. Dans notre exemple, nous ne disposons que d’un seul site Active Directory cependant ceci pourrait vous être utile si nécessaire. Nous lançons donc la commande « nltest /dsgetsite » pour connaître le nom du site.

 

 

 

 

 

 

Le moyen de localisation préféré pour Active Directory est le service DNS ce qui en fait d’ailleurs un composant crucial pour l’annuaire. DNS dispose des enregistrements de ressources (emplacements de services SRV)  pour localiser un contrôleur de domaine. Ces enregistrements sont sous la forme « _service._protocol._sites.dc._msdcs.DnsDomainName » ou « _service._protocol.dc.msdsc.DnSDomainName ». Ils sont  accessibles depuis « Démarrer » | « Outils d’administration » | « Gestionnaire DNS ». Le client contactera en priorité les enregistrements concernant son site sinon il attaquera les enregistrements du domaine dans son ensemble. Les clients cherchent à contacter en premier le service LDAP, l’enregistrement utilisé sera  donc  « _ldap ».

 

 

 

 

 

 

 

 

Le service Netlogon envoie donc à partir des informations récupérées un datagramme LDAP sur le réseau. L’ensemble des serveurs disponibles répondent à cette requête pour signaler leur présence mais seul le plus rapide sera sélectionné par Netlogon. En conclusion, selon la charge des contrôleurs et la qualité du réseau au moment du déclenchement du processus  Netlogon, l’interlocuteur du client pourra être différent. Il n’y a donc pas de priorité préétablie. De plus, la fonctionnalité DNS Round Robin (tourniquet) assure que les contrôleurs seront interrogés chacun leur tour par un même client. Elle assure une répartition de charge. Cela explique, entre autres,  pourquoi vous avez des enregistrements DNS identiques pointant sur différents serveurs.  Cette option est activée par défaut sur un contrôleur de domaine. Pour le vérifier, faire un clic droit sur votre serveur depuis « Gestionnaire DNS », choisir « Propriétés » et se rendre dans l’onglet « Avancé ».

 

 

 

 

 

 

 

 

 

 

Comment gérer les priorités?

Maintenant que nous avons vu la manière dont est localisé un contrôleur de domaine par un client, il est facile de comprendre que la gestion des priorités passera par la gestion de vos enregistrements DNS.

Nous avons souligné que les enregistrements utilisés par un client sont localisés à deux endroits:

« _service._protocol._sites.dc._msdcs.DnsDomainName »  pour les clients d’un même site et en ayant connaissance. « _service._protocol.dc.msdsc.DnSDomainName » pour les clients du domaine n’ayant soit plus de contrôleur à disposition sur leur site où n’ayant pas connaissance de leur site.

Nous avons également vu que Netlogon recherche exclusivement le service « _ldap ».

Désormais et en vue de ces éléments, nous allons donc nous focaliser sur ces enregistrements. En effet, il y a autant d’enregistrement de ressource SRV « _ldap » que de contrôleur de domaine et, comme nous l’expliquons plus haut, c’est la technologie Round Robin qui le permet. Nous allons accéder aux propriétés d’un de ces enregistrements et voir de quoi il est composé. Il faut donc se rendre dans « Zones de recherche directes » | « _msdsc.DnsDomainName » | « dc » | « _sites » | « [SITE] » | « _tcp », faire un clic droit sur un enregistrement de type « _ldap » et sélectionner « propriétés ».

 

 

 

 

 

 

 

 

 

Nous découvrons deux champs sur lesquels nous allons nous pencher. Il s’agit de « Priorité » et « Poids ». Par défaut ils ont tous les deux les valeurs respectives  « 0 » et « 100 ». C’est ces deux valeurs qui vont nous permettre de privilégier le serveur LDAP sur notre site Active Directory.

Priorité : son nom est explicite. Elle va permettre de donner l’exclusivité à un de vos contrôleurs. Cela veut dire que le serveur disposant de la valeur la plus basse sera toujours contacté en premier. Il n’y aura pas de répartition de charge par contre les autres serveurs seront utilisés en cas d’indisponibilité. La valeur peut-être comprise en 0 et 65535.

Poids : elle est un peu plus complexe. Elle va permettre d’affiner la répartition de charge par défaut qui est réalisée par la fonctionnalité Round Robin. Le poid d’un enregistrement est proportionnel à la somme des poids total des enregistrements similaires. Par défaut, la valeur du poids pour chacun des enregistrements est de 100. Si vous disposez de deux serveurs, la somme total des poids sera de 200. Les  deux serveurs seront donc contactés chacun leur tour (1 fois sur 2). Si vous avez 10 contrôleurs et que nous restons sur la valeur par défaut, alors chaque contrôleur devrait être contacté en moyenne 1 fois sur 10. Si nous voulons réduire par deux la charge d’un contrôleur par rapports à ses pairs, il nous suffira alors de passer cette valeur à 50. Il traitera deux fois moins de demande que les autres. La valeur peut-être comprise en 0 et 65535.

 

 

La gestion des priorités par l'exemple

Dans cet article, le serveur W2K3 est celui qui détient les 5 rôles FSMO. C’est donc lui qui est susceptible d'assumer la plus grande charge dans notre domaine Active Directory. Nous allons donc faire en sorte que son service LDAP ne soit plus contacter par les clients sauf en cas d’avarie du second contrôleur W2K8.

Nous allons déjà vérifier de base quel est le serveur qui gère l’ouverture sur une station de travail à l’aide de la commande « echo %logonserver% » qui nous donnera le nom du serveur sur lequel nous avons ouvert une session. Dans l’exemple ci-dessous, nous voyons que suite au redémarrage d’un poste client, le serveur d’ouverture de session change et il y a une alternance.

 

 

 

 

 

 

Maintenant, nous allons augmenter la valeur de priorité du serveur W2K3 afin qu’il ne soit plus sélectionner par le client. Cependant, nous n'allons pas réaliser l'opération depuis le gestionnaire DNS en modifiant directement l'enregistrement. En effet, l'enregistrement _ldap est créé  automatiquement par le service netlogon lorsqu'il démarre. Si vous modifiez l'enregistrement _ldap depuis le gestionnaire, lors du redémarrage du service netlogon, vous vous retrouverez avec un doublon comme dans l'exemple ci-dessous.

 

 

 

 

 

 

 

 

Pour mettre à jour la priorité du serveur et que la modification soit prise en compte de façon permanente, il va falloir passer par la clé de registre LdapSrvPriority de type DWORD depuis HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters que nous allons créer.

 

 

 

 

 

 

 

 

Afin de voir si la clé de registre a bien été prise en compte, redémarrer le service netlogon à l'aide de la commande  « NET STOP NETLOGON » et « NET START NETLOGON ». Vérifier enfin la mise à jour des enregistrements depuis les deux zones.

 

 

 

 

 

 

 

 

Les enregistrements _ldap sont modifiés mais également les enregistrements _kerberos (service pour la gestion des authentifications). Tous vos postes clients se connecteront  désormais sur le serveur ayant la plus faible valeur de priorité. Vous pouvez le vérifier bien entendu grâce à la variable %logonserver%.

Vous pourrez enfin augmenter la sollicitation de certains contrôleurs en rapport à d’autres grâce à la notion de poids en passant cette fois-ci par la valeur de registre LdapSrvWeight.

 

 

Conclusion

Vous êtes désormais prêt à gérer au mieux la charge de vos contrôleurs de domaine en fonction des tâches à réaliser. Ceci peut être intéressant si vous désirez gagner en performance sur des contrôleurs disposant des rôles FSMO et en particulier le PDC emulator qui nécessite une bonne réactivité.

Nous vous conseillons aussi de prendre connaissance de l'article technet « How DNS Support for Active Directory Works » afin de comprendre au mieux l'interaction DNS/AD.

Mise à jour le Vendredi, 27 Août 2010 18:15