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 ?

1voto

Mark Berner Points 42

Nous avons rencontré un problème similaire, où les utilisateurs rencontraient des retards (jusqu'à une minute) entre le clic sur un lecteur cartographié vers un partage DFS, et la possibilité de voir et parcourir les dossiers à l'intérieur du partage.

Les utilisateurs avaient également des lecteurs personnels cartographiés vers un autre partage DFS sur le même volume, et n'avaient aucun retard lors de l'accès aux dossiers là-bas.

La différence entre les deux réside dans l'Énumération basée sur l'accès (ABE) - le partage problématique a cela activé (c'est un lecteur commun pour les utilisateurs, avec des milliers de dossiers - ABE signifie que les utilisateurs voient uniquement les dossiers auxquels ils ont des autorisations).

Désactiver ABE a complètement résolu le problème. Évidemment, ce n'est pas une solution car les utilisateurs voient alors tous les dossiers, ce qui les perturbe. J'ai répliqué le partage DFS sur un serveur avec un peu d'espace disque en tant que mesure temporaire, et même avec ABE activé sur cette nouvelle cible, le retard a disparu.

Le serveur problématique est sur 2k3R2, et a une durée de fonctionnement de plus de 150 jours (!), donc il va être redémarré et CHKDSK va être exécuté sur le volume en question. Je reviendrai ici si cela change quelque chose au problème. La nouvelle cible est sur un serveur 2k8.

1voto

Dfsutil /spcflush et dfsutil /pktflush peuvent également être une solution dans un réseau multi-site, assurez-vous que le lien DFS du site d'origine provient du serveur local et non du cache.

1voto

Smooth Ride Points 9

Je sais que l'auteur original n'utilisait pas WINS, mais je poste pour le bénéfice des autres car nous avons utilisé ce message pour aider à résoudre un problème très similaire. Pour nous, il s'est avéré qu'une personne avait décidé de nommer son poste de travail avec le même nom que le domaine. Ainsi, à chaque fois que le contrôleur de domaine faisait une recherche de nom de domaine pour la référence DFS, il voulait résoudre à ce poste de travail et provoquait un retard considérable de plusieurs dizaines de secondes. Une entrée statique de 20 a été placée dans le WINS pointant vers un contrôleur de domaine et cela a résolu le problème. Si vous n'avez pas de WINS, vous pouvez expérimenter en plaçant le nom de domaine comme nom de machine dans le fichier LMHOSTS pointé vers un contrôleur de domaine pour obtenir la recherche de 20, et définir la priorité pour que LMHOSTS soit le premier endroit où rechercher la résolution des noms NetBIOS.

1voto

Amy Points 11

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Cette page mentionne en fait à la fois les contrôleurs de domaine et DFSN, si cela peut aider.

Entrées de registre DFS Domain Controller et Root Server

Les entrées de registre suivantes se trouvent sous

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

sur les serveurs racines et les contrôleurs de domaine. Toutes les entrées sont de type REG_DWORD.

1voto

David Jenkins Points 11

Donc j'ai utilisé cet article dans ma recherche. J'ai tout configuré et j'ai quand même eu des problèmes. Après avoir passé plusieurs jours à examiner le problème et à exclure tout ce qui concerne 'Microsoft', j'ai deviné que c'était lié au réseau. Il s'avère que notre Accélérateur WAN était le problème. J'ai demandé à nos experts en réseau de désactiver l'accélération pour nos Contrôleurs de Domaine et tout s'est arrangé.

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