20 votos

Larga pausa cuando el acceso a espacio de nombres DFS

Recientemente hemos migrado nuestra red de Windows para utilizar DFS para los archivos compartidos. DFS está funcionando bien, salvo por un molesto problema: los usuarios experimentar un retraso significativo cuando se intenta obtener acceso a un espacio de nombres DFS que no han accedido durante algún tiempo. He intentado solucionar el problema pero no han tenido éxito hasta el momento, y estaba esperando que alguien aquí tiene algunos consejos para ayudar a resolver el problema.

En primer lugar, algunos antecedentes en nuestra red:

La red utiliza un Windows 2008 nivel funcional de dominio de Active Directory, con dos Ventanas De 2008, los países en desarrollo y dos servidores DNS (uno en cada uno de los países en desarrollo). La red es el DNS solo - no GANA. Todos los equipos están ubicados en el mismo sitio y conectado por Ethernet Gigabit. Tenemos aproximadamente 20 basada en el Dominio de los espacios de nombres DFS en Windows 2008 modo, y cada espacio de nombres DFS tiene dos Ventanas de 2008, de espacio de nombres DFS servidores (el mismo de las dos servidores para todos los espacios de nombres). Todos los servidores de espacio de nombres están en el FQDN modo y todos los destinos de carpeta se especifican a través de su nombre de dominio. Todos los equipos están actualizados con los Service Packs y parches.

El real destinos de carpeta (es decir, los recursos compartidos SMB nuestras carpetas DFS punto a) se encuentran dispersos en varios archivos y servidores de aplicación, a todos los que ejecutan Windows 2008 de la barra de dos servidores de aplicaciones que se ejecutan en Windows 2003 R2, sin replicación de configuración (por ejemplo, todas las carpetas DFS actualmente solo tiene una carpeta de destino).

Algo más de detalle en el problema:

El espacio de nombres acceso retraso es generalmente de 1 a 10 segundos de duración y se parece ocurrir cuando un equipo en particular, no ha accedido a la solicitada espacio de nombres durante aproximadamente cinco minutos o más.

Por ejemplo, si el usuario no tiene acceso a \\dominio.nombre\namespace1\ por más de cinco minutos y los intentos de obtener acceso a \\dominio.nombre\namespace1\ través del Explorador de Windows, la ventana del Explorador se congela por 1 - 10 segundos antes de que finalmente la reanudación y la visualización de las carpetas que existen en \\dominio.nombre\namespace1. Si, a continuación, cierre la ventana del Explorador y el intento de obtener acceso a \\dominio.nombre\namespace1\ nuevamente dentro de los cinco minutos en los que el contenido se mostrará casi al instante - si tienen que esperar más de cinco minutos que se va a ir a través de la 1 - 10 segundos de pausa de nuevo.

Una vez "dentro" del espacio de nombres de todo lo que es agradable y ágil, es sólo la conexión inicial con el espacio de nombres que es lento.

La exploración de los retrasos parece afectar a todas las variantes de Windows que usamos (Windows 2008 x64 SP2, Windows 2003 R2 SP2 x86, Windows XP Pro x86 SP3) - es, posiblemente, un poco peor en Windows XP / 2003 que en Windows 2008, pero no estoy seguro de si la diferencia no es sólo psicológico.

Acceder a la carpeta subyacente se dirige directamente no presenta retraso en todos - es decir, si los recursos compartidos SMB señalado por la que se accede directamente (sin DFS), entonces no hay pausa.

Durante la solución de problemas me di cuenta de que la "duración de la Caché" para todas nuestras root DFS es 300 segundos (5 minutos. Dado que esta es la misma cantidad de tiempo que se requiere para activar la pausa supongo que esta caché está de algún modo relacionado, aunque no estoy seguro exactamente lo que se almacena en caché en el cliente y, por tanto, lo que necesita ser mirado de nuevo después de 5 minutos han transcurrido.

En el intento de resolver el problema, ya he probado / verificado lo siguiente (sin éxito):

  • Ejecutar dcdiag en ambos Controladores de Dominio - no se encontraron problemas
  • Hace algunos básica del servidor DNS cheques sin encontrar ningún problema - no sé cómo comprobar el estado de los servidores DNS en detalle, pero me gustaría añadir que la red no está exhibiendo cualquier otro comportamiento extraño que puede apuntar a un problema de DNS
  • Movilidad Anti-virus en los clientes y servidores
  • La eliminación de uno de los servidores de espacio de nombres de un par de espacios de nombres - no hay diferencia

Así que es de donde soy a - y estoy sin ideas. Puede alguien sugerir lo que puede ser la causa de los retrasos y/o lo que debería intentar ser el siguiente?

3voto

Daniel B Puntos 53

El Equipo de Active Directory Blog tiene Tres partes artículo DFS Retrasos.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

Cubre los conceptos básicos en el Proceso de Referencia y, a continuación, muestra cómo utilizar las distintas herramientas, entre las que dfsUtil y dfsDiag para descubrir la verdadera causa de los retrasos.

Me ayudó a encontrar mi problema. Que resultó ser no hay permisos de Lectura en el directorio compartido para los Usuarios del Dominio.

HTH, Daniel

2voto

Guy Puntos 16718

Huele a un problema de DNS pero nada pasa. Yo lo prefería el antiguo FRS porque las herramientas de diagnóstico como la Ecografía fue tan útil :7

¿Puede conseguir cualquier cosa en la Replicación DFS Registro de Eventos en los objetivos? (la DFS, informe sobre la Salud en sacará sus advertencias de que el registro de eventos)

Se ejecutan sin que GANA es un buen objetivo y admirable, a pesar de que estoy bastante en contra de esto si no hay ningún pre-Vista/2008 sistemas Windows en torno a como las cosas no siempre funcionan como se esperaba o como rápido sin TRIUNFOS en mi experiencia - a pesar de que realmente no importa.

1voto

BlankVerse Puntos 85

El cliente almacena en caché una referencia DFS, es decir, cuando se enter \dominio.nombre\espacio de nombres se caché del servidor real de dominio.el nombre se refiere. Una vez que la referencia caduca de la caché, el cliente tiene, básicamente, a "descubrir" su topología DFS todo de nuevo, de ahí el retraso.

Echa un vistazo aquí: http://technet.microsoft.com/en-us/library/cc758234(LR.10).aspx y aquí http://blogs.technet.com/filecab/archive/2006/01/20/417832.aspx para más información sobre cómo funciona esto.

Posibles soluciones? Un hacky manera de ir sobre la que podría ser la de escribir un pequeño programa que hace un "keep alive" cada pocos minutos; por ejemplo, un programa en C que fopen es el primer archivo que se encuentra y de inmediato fclose. No he probado o probado esto, y que sin duda necesita para dar una cuidadosa consideración de si se va a hacer.

0voto

Sara Puntos 16

Bueno, nosotros finalmente parecen haber resuelto este problema en nuestro medio ambiente. Para el beneficio de otros, he aquí lo que hemos descubierto y cómo se ha solucionado el problema:

Para intentar obtener una mayor comprensión de lo que estaba ocurriendo antes/durante/después de los retrasos que hemos utilizado Wireshark en una máquina del cliente/captura de analizar el tráfico de la red, mientras que el cliente intenta acceder a un recurso compartido DFS.

Estas capturas mostró algo extraño: cada vez que se ha producido un retraso en la solicitud DFS enviados desde el cliente a un DC, y la remisión a un servidor root DFS de regresar de la DC para el cliente, la DC fue el envío de varios nombre de difusión búsquedas en la red.

En primer lugar, la DC sería la emisión de NetBIOS de búsqueda del DOMINIO (donde DOMINIO es nuestro pre-Windows 2000 Active Directory domain name). Unos segundos más tarde, sería la emisión de LLMNR de búsqueda para su DOMINIO. Esto sería seguido por otra emisión de NetBios de búsqueda para su DOMINIO. Después de estas tres búsquedas se había emitido (y supongo tiempo de espera agotado) la DC finalmente responder al cliente con un (correcto) la remisión a un servidor de root DFS.

Estos difusión de las búsquedas de nombres de DOMINIO fueron sólo se envían cuando el tiempo de retardo de la apertura de un recurso compartido DFS ocurrido, y podemos ver claramente a partir de la captura de Wireshark que la DC no devolver una referencia a un servidor de root DFS hasta que los tres búsquedas sido enviado (y ~7 segundos pasó). Así, estos nombres de difusión de las búsquedas eran bastante, obviamente, la causa de nuestro retraso.

Ahora que se sabía cuál era el problema, empezamos tratando de averiguar por qué estos nombres de difusión de las búsquedas que se producen. Después de un poco más de Google y un poco de ensayo y error, hemos encontrado nuestra respuesta: no habíamos establecer la clave de registro DfsDnsConfig en nuestros controladores de dominio a 1, como es requerido cuando el uso de DFS en un entorno sólo DNS.

Cuando nos originalmente el programa de instalación de DFS en nuestro entorno nos hizo leer los diferentes artículos acerca de cómo configurar DFS para un sólo DNS de entorno (por ejemplo, Microsoft KB244380 y otros) y eran conscientes de esta clave del registro, pero había misintepreted las instrucciones sobre cuándo y cómo usarlo.

KB244380 dice:

La clave DFSDnsConfig debe ser agrega a cada servidor que se participar en el espacio de nombres DFS para todos los equipos para comprender plenamente nombres completos.

Pensamos que esto significaba que la clave del registro se establece en el DFS servidores de espacio de nombres solamente, no darse cuenta de que también era necesario en los controladores de dominio. Después de establecer DfsDnsConfig a 1 en nuestros controladores de dominio (y reiniciado el "espacio de Nombres DFS" servicio), el problema desapareció.

Obviamente estamos contentos con este resultado, pero me gustaría añadir que todavía no estoy 100% convencido de que este es nuestro único problema - me pregunto si la adición de DfsDnsConfig=1 para nuestro DCs solo ha trabajado todo el problema en lugar de resolverlo. No puedo entender por qué la Dc estaría tratando de búsqueda del DOMINIO (el nombre de dominio de sí mismo, en lugar de un servidor en el dominio) durante la DFS proceso de referencia, incluso en no-DNS-entorno único, y también sé que no he fijado DfsDnsConfig=1 en los controladores de dominio en otro (evidentemente, mucho más pequeño / más simple) sólo DNS entornos y no he tenido el mismo problema. Aún así, hemos solucionado nuestro problema, así que estamos felices.

Espero que esto sea útil para los demás que están experimentando un problema similar - y de nuevo gracias a los que ofrecen sugerencias a lo largo del camino.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: