24 votes

Longue pause lors de l'accès à l'espace de noms DFS

Nous avons récemment migré notre réseau Windows pour utiliser DFS pour les fichiers partagés. DFS fonctionne bien, sauf pour un problème ennuyeux : les utilisateurs rencontrent un retard significatif lorsqu'ils essaient d'accéder à un espace de noms DFS auquel ils n'ont pas accédé depuis un certain temps. J'ai essayé de résoudre le problème, mais sans succès jusqu'à présent, et j'espérais que quelqu'un ici pourrait avoir des conseils pour aider à résoudre le problème.

Tout d'abord, quelques informations sur notre réseau :

Le réseau utilise un domaine Active Directory Windows 2008 avec un niveau fonctionnel 2008 avec deux DC Windows 2008 et deux serveurs DNS (un sur chacun des DC). Le réseau est uniquement DNS - pas de WINS. Tous les ordinateurs sont situés sur le même site et connectés par Ethernet Gigabit. Nous avons environ 20 espaces de noms DFS basés sur des domaines en mode Windows 2008, et chaque espace de noms DFS a deux serveurs d'espaces de noms DFS Windows 2008 (les mêmes deux serveurs pour tous les espaces de noms). Tous les serveurs d'espaces de noms sont en mode FQDN et toutes les cibles de dossier sont spécifiées en utilisant leur FQDN. Tous les ordinateurs sont à jour avec les Service Packs et correctifs.

Les cibles de dossier réelles (c'est-à-dire les partages SMB sur lesquels pointent nos dossiers DFS) sont réparties sur plusieurs serveurs de fichiers et d'applications, tous fonctionnant sous Windows 2008 sauf deux serveurs d'applications qui exécutent Windows 2003 R2, sans configuration de réplication du tout (par exemple, tous les dossiers DFS ont actuellement une seule cible de dossier).

Un peu plus de détails sur le problème :

Le retard d'accès à l'espace de noms est généralement de 1 à 10 secondes et semble se produire lorsqu'un ordinateur particulier n'a pas accédé à l'espace de noms demandé depuis environ cinq minutes ou plus.

Par exemple, si l'utilisateur n'a pas accédé à \\domain.name\namespace1\ depuis plus de cinq minutes et tente d'accéder à \\domain.name\namespace1\ via l'Explorateur Windows, la fenêtre Explorer se fige pendant 1 à 10 secondes avant de finalement reprendre et d'afficher les dossiers qui existent dans \\domain.name\namespace1. S'ils ferment ensuite la fenêtre de l'Explorateur et tentent d'accéder à nouveau à \\domain.name\namespace1\ dans les cinq minutes, le contenu s'affichera presque instantanément - s'ils attendent plus de cinq minutes, une pause de 1 à 10 secondes se produira à nouveau.

Une fois "à l'intérieur" de l'espace de noms, tout est réactif, c'est juste la connexion initiale à l'espace de noms qui est lente.

Les retards de navigation semblent affecter toutes les variantes de Windows que nous utilisons (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - c'est peut-être un peu pire sous Windows XP / 2003 que sous Windows 2008, mais je ne suis pas sûr si la différence n'est pas simplement psychologique.

Accéder directement aux cibles de dossiers sous-jacents n'expose aucun retard du tout - c'est-à-dire si les partages SMB pointés par DFS sont accédés directement (en contournant DFS), il n'y a pas de pause.

Pendant le dépannage, j'ai remarqué que la "Durée du cache" pour toutes nos racines DFS est réglée sur 300 secondes - 5 minutes. Étant donné que c'est le même laps de temps nécessaire pour déclencher la pause, je suppose que ce cache est d'une manière ou d'une autre lié, bien que je ne sois pas sûr de ce qui est mis en cache sur le client et donc ce qui doit être recherché après que 5 minutes se soient écoulées.

Pour tenter de résoudre le problème, j'ai déjà essayé / vérifié ce qui suit (sans succès) :

  • Exécuter dcdiag sur les deux contrôleurs de domaine - aucun problème trouvé
  • Effectuer quelques vérifications de base sur les serveurs DNS sans trouver de problèmes - je ne sais pas comment vérifier les serveurs DNS en détail, mais je préciserais que le réseau ne présente aucun autre comportement étrange qui pourrait indiquer un problème DNS
  • Désactiver l'antivirus sur les clients et les serveurs
  • Supprimer l'un des serveurs d'espaces de noms de quelques espaces de noms - aucune différence

C'est là où j'en suis - et je suis à court d'idées. Quelqu'un peut-il suggérer ce qui pourrait causer les retards et/ou ce que je devrais essayer ensuite ?

30voto

Sara Points 31

Eh bien, nous avons enfin résolu ce problème dans notre environnement. Pour bénéficier des autres, voici ce que nous avons découvert et comment nous avons résolu le problème :

Pour essayer d'obtenir une meilleure compréhension de ce qui se passait avant / pendant / après les retards, nous avons utilisé Wireshark sur une machine cliente pour capturer / analyser le trafic réseau pendant que ce client tentait d'accéder à un partage DFS.

Ces captures ont montré quelque chose d'étrange : chaque fois que le retard se produisait, entre la demande DFS envoyée par le client à un DC et la référence à un serveur racine DFS revenant du DC au client, le DC envoyait plusieurs recherches de noms de diffusion sur le réseau.

Tout d'abord, le DC diffusait une recherche NetBIOS pour DOMAIN (où DOMAIN est notre nom de domaine Active Directory pré-Windows 2000). Quelques secondes plus tard, il diffusait une recherche LLMNR pour DOMAIN. Cela était suivi par une autre recherche NetBIOS de diffusion pour DOMAIN. Après que ces trois recherches eurent été diffusées (et je suppose expirées), le DC répondait enfin au client avec une référence (correcte) à un serveur racine DFS.

Ces recherches de noms de diffusion pour DOMAIN étaient envoyées uniquement lorsque le long retard lors de l'ouverture d'un partage DFS se produisait, et nous pouvions clairement voir dans la capture Wireshark que le DC ne renvoyait pas une référence à un serveur racine DFS avant que les trois recherches aient été envoyées (et ~7 secondes se sont écoulées). Ainsi, ces recherches de noms de diffusion étaient très clairement la cause de nos retards.

Maintenant que nous savions quel était le problème, nous avons commencé à essayer de comprendre pourquoi ces recherches de noms de diffusion se produisaient. Après un peu plus de recherches sur Google et quelques essais et erreurs, nous avons trouvé notre réponse : nous n'avions pas défini la clé de registre DfsDnsConfig sur nos contrôleurs de domaine à 1, comme cela est nécessaire lors de l'utilisation de DFS dans un environnement DNS uniquement.

Lorsque nous avons initialement configuré DFS dans notre environnement, nous avons bien lu les différents articles sur la manière de configurer DFS pour un environnement DNS uniquement (par exemple, Microsoft KB244380 et d'autres) et étions conscients de cette clé de registre, mais avions mal interprété les instructions sur quand/comment l'utiliser.

KB244380 indique :

La clé de registre DFSDnsConfig doit être ajoutée à chaque serveur qui participera à l'espace de noms DFS pour que tous les ordinateurs comprennent les noms pleinement qualifiés.

Nous pensions que cela signifiait que la clé de registre devait être définie uniquement sur les serveurs d'espace de noms DFS, sans réaliser qu'elle était également requise sur les contrôleurs de domaine. Après avoir défini DfsDnsConfig sur 1 sur nos contrôleurs de domaine (et avoir redémarré le service "Espace de noms DFS"), le problème a disparu.

Évidemment, nous sommes satisfaits de ce résultat, mais j'ajouterais que je ne suis toujours pas convaincu à 100% que c'est notre seul problème - je me demande si l'ajout de DfsDnsConfig=1 sur nos DC n'a pas simplement contourné le problème, plutôt que de le résoudre. Je ne comprends pas pourquoi les DC essaieraient de rechercher DOMAIN (le nom de domaine lui-même, plutôt qu'un serveur dans le domaine) pendant le processus de référence DFS, même dans un environnement non-DNS seulement, et je sais aussi que je n'ai pas défini DfsDnsConfig=1 sur les contrôleurs de domaine dans d'autres environnements DNS uniquement (certes beaucoup plus petits / plus simples) et n'ai pas eu le même problème. Néanmoins, nous avons résolu notre problème donc nous sommes satisfaits.

J'espère que cela sera utile à ceux qui rencontrent un problème similaire - et merci encore à ceux qui ont proposé des suggestions en cours de route.

3voto

Cela pourrait être causé par l'ordonnancement du masque de sous-réseau du serveur DNS. Nous sommes récemment tombés sur ce problème dans Server 2003. Cela dépend de votre découpage actuel du sous-réseau.

Exemple.

Site 1 : plage d'adresses IP 10.0.0.0/24 Site 2 : plage d'adresses IP 10.0.1.0/24

Un client du site 2 fait une requête DNS pour votre espace de noms basé sur le domaine et se verra donner par défaut le serveur DFS du site 1 car le serveur DNS n'est pas conscient des limites IP du site. Vous devez indiquer à vos serveurs DNS quel masque de sous-réseau utiliser pour identifier sur quels adresses IP répondre.

Voir http://support.microsoft.com/kb/842197

3voto

Nick Matteo Points 101

L'équipe du blog Active Directory a rédigé un article en trois parties ENTIEREMENT consacré aux retards de DFS.

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/o-8217-dfs-shares-where-art-thou-8211-part-1-3/ba-p/397167 (https://archive.is/OeRqo)

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/o-8217-dfs-shares-where-art-thou-8211-part-2-3/ba-p/397171 (https://archive.is/cojW4)

https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/o-8217-dfs-shares-where-art-thou-8211-part-3-3/ba-p/397175 (https://archive.is/E9Dov)

Il explique les bases du processus de Référencement, puis montre comment utiliser divers outils tels que dfsUtil et dfsDiag pour découvrir la cause réelle des retards.

Cela m'a aidé à trouver mon problème. Qui s'est avéré être des autorisations de lecture inexistantes sur le répertoire partagé pour les utilisateurs du domaine.

À votre service, Daniel

2voto

Guy Points 16718

Ça sent un problème de DNS mais tout est possible. Je préférais beaucoup l'ancien FRS car les outils de diagnostic comme Ultrasound étaient tellement utiles :7

Trouvez-vous quelque chose dans le journal d'événements de réplication DFS sur les cibles? (le rapport Santé DFS tirera ses avertissements du journal d'événements)

Fonctionner sans WINS est un bel objectif et admirable, bien que je sois plutôt contre cela s'il y a des systèmes Windows pré-Vista/2008 autour car les choses ne fonctionnent pas toujours comme prévu ou aussi rapidement sans WINS dans mon expérience - même si cela ne devrait vraiment pas importe.

1voto

Maximus Minimus Points 8917

Le client met en cache une référence DFS, c'est-à-dire que lorsque vous entrez \ nom de domaine\namespace, il met en cache vers quel serveur réel le domaine nom se réfère. Une fois que la référence expire du cache, le client doit en quelque sorte "découvrir" à nouveau votre topologie DFS, d'où le retard.

Jetez un coup d'œil ici : http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx et ici http://blogs.technet.com/filecab/archive/2006/01/20/417832.aspx pour plus d'informations sur le fonctionnement de ceci.

Des solutions possibles ? Une façon bricolée de le faire pourrait être d'écrire un petit programme qui envoie un "keep alive" toutes les quelques minutes ; par exemple, un programme C qui ouvre le premier fichier qu'il trouve avec fopen et le referme immédiatement avec fclose. Je n'ai pas essayé ou testé cela, et vous devriez certainement y réfléchir attentivement si vous devez le faire.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X