Résolution des problèmes de performances

vos délais de réponse DNS. Si vous êtes un adepte des scripts et souhaitez vous faire votre idée sans ces outils tiers, vous pouvez écrire un script avec une requête DNS incorporée qui enregistre un horodatage (timestamp) avant et après la fin d’une requête DNS, afin d’évaluer les temps de réponse de requêtes spécifiques. Ayez à l’esprit que, bien souvent, d’autres facteurs peuvent dégrader les performances du service DNS.

Par exemple, un processus défaillant peut consommer des ressources processeur et donner une impression de « lenteur » du serveur DNS. Il ne s’agit pas d’un problème lié directement au service DNS, mais plutôt au processus défaillant affectant le service en question. Il est tout aussi important de considérer l’interdépendance des composants et des réactions en chaîne provoquées par des problèmes de performances d’un composant. Par exemple, si le système n’a plus suffisamment de mémoire, il commence à paginer beaucoup plus, d’où des E/S disques plus élevées. La connaissance et la prise en compte de ces interactions sur le serveur et ses services sont critiques pour la résolution des problèmes de performances de DNS.

Vous trouverez une liste complète des compteurs importants pour le dépannage de DNS dans l’article Microsoft « Monitoring DNS server performance ». Résolution des problèmes. Lors du dépannage de problèmes liés au processeur, il est essentiel d’examiner les requêtes reçues. Un nombre anormalement élevé de requêtes TCP ou UDP peut entraîner des problèmes de processeur. Comme indiqué précédemment dans cet article, les requêtes UDP émanent généralement de votre client moyen, alors que les requêtes TCP sont employées par Exchange. Par exemple, un nombre important de requêtes TCP invite à se pencher sur les requêtes liées à Exchange au lieu de dépanner des simples recherches de noms d’hôte.

D’autre part, les requêtes à transfert de zone peuvent solliciter fortement le processeur. Un nombre anormalement élevé de transferts de zone complets peut occasionner fréquemment des problèmes de performances si les zones sont mal configurées. Certains serveurs Exchange demanderont des transferts de zones complets au lieu de transferts incrémentiels si les serveurs sont désynchronisés. Si le nombre de requêtes de transfert de zone est supérieur aux habitudes de votre organisation Exchange, examinez les serveurs DNS placés en aval et servant de cibles à ces transferts. Ils peuvent être la cause des problèmes. Vous pouvez identifier les problèmes de mémoire utilisée pour les messages TCP et UDP, ce qui facilite l’identification du type de client incriminé. Par exemple, comme nous savons que les requêtes DNS TCP émanent des serveurs Exchange, des problèmes liés exclusivement à TCP nous amènent à examiner les serveurs Exchange comme clients DNS. Une mise en cache ou une mémoire de base de données anormales peuvent indiquer des problèmes de mémoire du service DNS.

Les problèmes d’E/S disque sont généralement liés directement à des problèmes de processeur ou de mémoire entraînant l’écriture par le disque de plus d’informations qu’à l’accoutumée. Par conséquent, lors de l’examen d’un problème d’E/S disque, pensez à étudier en parallèle les problèmes de processeur et de mémoire. Une cause fréquente des problèmes de performances de DNS dans les environnements de grande taille est la répartition inégale de la charge des clients. Dans les environnements plus petits, les problèmes de performances de DNS peuvent provenir d’autres charges placées sur un serveur exécutant à la fois DNS et de nombreuses autres applications. Il est crucial que votre infrastructure DNS soit évolutive et que les clients soient configurés pour utiliser les serveurs DNS de manière distribuée. Autrement dit, au lieu d’avoir un serveur DNS « primaire » et un serveur DNS « secondaire » dans votre organisation, envisagez une architecture avec un serveur traitant les requêtes d’une moitié des clients de l’organisation et un autre serveur traitant l’autre moitié. Ainsi, la charge est distribuée uniformément entre les deux serveurs DNS.

Cela évitera les situations ou le serveur primaire est surchargé alors que le serveur secondaire interviendra uniquement si le premier ne répond pas. Selon la taille de votre environnement, vous pouvez adopter différentes approches pour aboutir à une répartition plus équilibrée des serveurs DNS pour vos postes client. En fait, dans les organisations relativement petites, cela ne pose aucun problème. Toutefois, si vous décidez de distribuer plus uniformément la charge DNS, vous devez utiliser plusieurs étendues DHCP. Celles-ci répartissent différentes données DNS sur les postes client et font en sorte que les serveurs avec des entrées DNS statiques soient configurés de manière à répartir également leur charge sur les serveurs DNS.