Длинная пауза при доступе к пространству имен DFS

Недавно мы перенесли нашу сеть Windows для использования DFS для общих файлов. DFS работает хорошо, за исключением одной досадной проблемы: пользователи испытывают значительную задержку при попытке получить доступ к пространству имен DFS, к которому они некоторое время не обращались. Я пытался решить проблему, но пока не добился успеха, и я надеялся, что кто-то здесь может иметь некоторые указатели, которые помогут решить проблему.

Во-первых, некоторые сведения о нашей сети:

В сети используется домен Active Directory функционального уровня Windows 2008 с двумя контроллерами домена Windows 2008 и двумя DNS-серверами (по одному на каждом контроллере домена). Сеть только DNS - без WINS. Все компьютеры расположены на одном сайте и подключены через Gigabit Ethernet. У нас есть приблизительно 20 доменных пространств имен DFS в режиме Windows 2008, и каждое пространство имен DFS имеет два сервера пространства имен Windows 2008 DFS (те же два сервера для всех пространств имен). Все серверы пространства имен находятся в режиме полного доменного имени, а все целевые папки указываются с использованием их полного доменного имени. Все компьютеры обновлены с пакетами обновления и исправлениями.

Фактические целевые папки (то есть SMB-ресурсы, на которые указывают наши папки DFS) разбросаны по нескольким файловым серверам и серверам приложений, причем все они работают под управлением Windows 2008, а два сервера приложений работают под управлением Windows 2003 R2, при этом настройка репликации вообще отсутствует (например, все папки DFS в настоящее время). только одна папка цели).

Еще несколько подробностей по проблеме:

Задержка доступа к пространству имен обычно длится 1-10 секунд и, по-видимому, возникает, когда конкретный компьютер не обращается к запрошенному пространству имен в течение приблизительно пяти минут или более.

Например, если пользователь не обращался к \\ domain.name \ namespace1 \ более пяти минут и пытается получить доступ к \\ domain.name \ namespace1 \ через проводник Windows, окно проводника будет зависать на 1–10 секунд, прежде чем, наконец, возобновление и отображение папок, которые существуют в \\ domain.name \ namespace1. Если они затем закроют окно Проводника и попытаются снова получить доступ к \\ domain.name \ namespace1 \ в течение пяти минут, содержимое будет отображаться практически мгновенно - если они будут ждать дольше пяти минут, оно снова пройдет через 1 - 10-секундную паузу.

Как только «внутри» пространства имен все хорошо и быстро, это просто начальное соединение с пространством имен, которое является медленным.

Задержки просмотра, похоже, влияют на все варианты Windows, которые мы используем (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - это, возможно, немного хуже в Windows XP / 2003, чем в Windows 2008, но я Я не уверен, что разница не просто психологическая.

Прямой доступ к целевым папкам напрямую не задерживается - т. Е. Если к ресурсам SMB, на которые указывает DFS, осуществляется прямой доступ (в обход DFS), паузы нет.

Во время устранения неполадок я заметил, что «длительность кэша» для всех наших корней DFS установлена ​​на 300 секунд - 5 минут. Учитывая, что это такое же количество времени, которое требуется для запуска паузы, я предполагаю, что это кэширование каким-то образом связано, хотя я не уверен точно, что кэшируется на клиенте и, следовательно, что нужно искать снова по истечении 5 минут.

Пытаясь решить проблему, я уже попробовал / проверил следующее (без успеха):

• Запустите dcdiag на обоих контроллерах домена - проблем не найдено
• Выполнены некоторые базовые проверки DNS-сервера без каких-либо проблем - я не знаю, как подробно проверить DNS-серверы, но я бы добавил, что в сети не проявляется какое-либо другое странное поведение, которое может указывать на проблему DNS
• Отключен антивирус на клиентах и ​​серверах
• Удаление одного из серверов пространства имен из пары пространств имен - без разницы

Так вот, где я до ... и у меня нет идей. Кто-нибудь может подсказать, что может быть причиной задержки и / или что я должен попробовать дальше?

Что ж, мы наконец- то решили, что решили эту проблему в нашей среде. Для пользы других, вот что мы обнаружили и как мы решили проблему:

Чтобы попытаться получить более полное представление о том, что происходило до / во время / после задержек, мы использовали Wireshark на клиентском компьютере для захвата / анализа сетевого трафика, пока этот клиент пытался получить доступ к общему ресурсу DFS.

Эти записи показывали нечто странное: всякий раз, когда происходила задержка, между запросом DFS, отправляемым от клиента к DC, и передачей корневого сервера DFS, возвращающегося с DC к клиенту, DC отправлял несколько широковещательных имен. поиск в сети.

Во-первых, DC будет транслировать поиск NetBIOS для DOMAIN (где DOMAIN - это наше доменное имя до Windows 2000 Active Directory). Через несколько секунд он будет транслировать поиск LLMNR для DOMAIN. За этим последует еще один широковещательный поиск NetBios для DOMAIN. После того, как эти три поиска были переданы (и я предполагаю, что время ожидания истекло), DC наконец-то ответит клиенту (правильным) обращением к корневому серверу DFS.

Эти поиски имен широковещательной рассылки для DOMAIN отправлялись только тогда, когда произошла длительная задержка открытия общего ресурса DFS, и из перехвата Wireshark мы могли четко видеть, что контроллер домена не возвращал ссылку на корневой сервер DFS, пока не были отправлены все три поиска ( и прошло ~ 7 секунд). Таким образом, эти поиски имени вещания были, очевидно, причиной наших задержек.

Теперь, когда мы знали, в чем проблема, мы начали пытаться выяснить, почему происходили эти широковещательные поиски имен. Немного погуглив и проб и ошибок, мы нашли наш ответ: мы не установили ключ реестра DfsDnsConfig на наших контроллерах домена в 1, как это требуется при использовании DFS в среде только с DNS.

Когда мы первоначально настройки DFS в нашей среде мы так прочитать различные статьи о том , как настроить DFS для DNS-только среды (например , Microsoft KB244380 и другие) и были в курсе этого раздела реестра, но misintepreted инструкции о том, когда / как используй это.

KB244380 говорит:

Раздел реестра DFSDnsConfig должен быть добавлен на каждый сервер, который будет участвовать в пространстве имен DFS, чтобы все компьютеры могли понимать полные имена.

Мы думали, что это означает, что ключ реестра должен быть установлен только на серверах пространства имен DFS , не понимая, что он также необходим на контроллерах домена. После того, как мы установили DfsDnsConfig на 1 на наших контроллерах домена (и перезапустили службу «Пространство имен DFS»), проблема исчезла.

Очевидно, что мы довольны этим результатом, но я хотел бы добавить, что я все еще не уверен на 100%, что это наша единственная проблема - мне интересно, если добавление DfsDnsConfig = 1 в наши контроллеры домена только обошло проблему, а не решило ее , Я не могу понять, почему контроллеры домена пытаются искать DOMAIN (само доменное имя, а не сервер в домене) во время процесса обращения к DFS, даже в среде, отличной от DNS, и я также знаю, что не устанавливали DfsDnsConfig = 1 на контроллерах домена в других (по общему признанию, намного меньших / простых) средах только для DNS и не имели такой же проблемы. Тем не менее, мы решили нашу проблему, поэтому мы счастливы.

Я надеюсь, что это будет полезно для других, кто сталкивается с подобной проблемой - и еще раз спасибо тем, кто предложил предложения по пути.

Это может быть вызвано порядком маски сети DNS-сервера. Мы столкнулись с этим недавно в Server 2003. Это зависит от вашей текущей подсети.

Пример.

Сайт 1: IP-подсеть 10.0.0.0/24 Сайт 2: IP-подсеть 10.0.1.0/24

Клиент на сайте 2 выполняет DNS-запрос для вашего пространства имен на основе домена и по умолчанию получает сервер DFS на сайте 1, так как DNS-сервер не знает границ IP сайта. Вы должны указать своим DNS-серверам, какую маску подсети использовать для определения того, с каких IP-адресов нужно отвечать.

См. Http://support.microsoft.com/kb/842197

В блоге группы Active Directory есть статья из трех частей, ВСЕ о задержках DFS.

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

В нем рассматриваются основы процесса перехода, а затем показано, как использовать различные инструменты, включая dfsUtil и dfsDiag, для выявления фактической причины задержек.

Это помогло мне найти мою проблему. Оказалось, что нет прав на чтение в каталоге общего доступа для пользователей домена.

HTH, Даниэль

Пахнет проблемой DNS, но все идет. Я предпочел старый FRS, потому что такие инструменты диагностики, как Ультразвук, были очень полезны: 7

Получаете ли вы что-нибудь в журнале событий репликации DFS на цели? (отчет о работоспособности DFS будет извлекать свои предупреждения из журнала событий)

Запуск без WINS - хорошая цель и достойная восхищения, хотя я в значительной степени против этого, если есть какие-либо системы Windows до Vista / 2008, так как не всегда все работает так, как ожидалось, или не так быстро без WINS - хотя это действительно не должно иметь значения.

Клиент кэширует ссылку DFS, т. Е. Когда вы вводите \ domain.name \ namespace, он будет кэшировать, на какой реальный сервер ссылается domain.name. По истечении срока действия реферала из кэша клиент в основном должен снова «обнаружить» вашу топологию DFS, отсюда и задержка.

Посмотрите здесь: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx и здесь http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx для получения дополнительной информации о том, как это работает.

Возможные решения? Хакерский способ сделать это - написать небольшую программу, которая «поддерживает жизнь» каждые несколько минут; например, программа на C, которая открывает первый найденный файл и сразу же закрывает его. Я не пробовал и не проверял это, и вам определенно нужно было бы внимательно рассмотреть, если вы собираетесь это сделать.

У нас была похожая проблема, когда пользователи сталкивались с задержками (до минуты) между нажатием на диск, подключенный к общему ресурсу DFS, и возможностью просмотра и просмотра папок в общем ресурсе.

Пользователи также имели домашние диски, сопоставленные с другим общим ресурсом DFS на том же томе, и не имели задержки при доступе к папкам там.

Разница между ними заключается в Access-Based Enumeration (ABE) - у проблемного общего ресурса это включено (это общий диск для пользователей с тысячами папок - ABE означает, что пользователи видят только те папки, на которые у них есть разрешения).

Отключение ABE полностью устранило проблему. Очевидно, что это не решение, поскольку пользователи видят все папки, сбивая их с толку. Я реплицировал общий ресурс DFS на сервер с некоторым запасным диском в качестве временной меры, и даже с включенным ABE для этой новой цели задержка прошла.

Проблемный сервер - 2k3R2, и время его работы превышает 150 дней (!), Поэтому он будет перезагружен и запустит CHKDSK на томе, который нарушает работу. Я отправлю сюда, если это как-то повлияет на проблему. Новая цель находится на сервере 2k8.

dfsutil / spcflush и dfsutil / pktflush могут быть решением также в многосайтовой сети. Убедитесь, что ссылка DFS домашнего сайта поступает с локального сервера, а не из кэша.

Я знаю, что оригинальный постер не использовал WINS, но я публикую пост в интересах других, так как мы использовали этот пост чаще всего, чтобы помочь решить очень похожую проблему. Для нас это закончилось тем, что кто-то решил назвать свою рабочую станцию ​​тем же именем, что и домен. Таким образом, каждый раз, когда DC выполнял поиск доменного имени для ссылки DFS, он хотел разрешить эту рабочую станцию ​​и вызывал бы значительную задержку в несколько десятков секунд. Статическая запись 20 была помещена в WINS, указывающую на DC, и это решило проблему. Если у вас не было WINS, вы могли бы поэкспериментировать с размещением имени домена в качестве имени машины в файле LMHOSTS, указывающем на DC, чтобы получить 20-кратный поиск, и установить приоритет, чтобы LMHOSTS был первым местом, где нужно искать разрешения имен netbios.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx На этой странице на самом деле упоминаются как контроллеры домена, так и DFSN, если это поможет.

Контроллер домена DFS и записи реестра корневого сервера

Следующие записи реестра расположены под

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

на корневых серверах и контроллерах домена. Все записи являются REG_DWORD.

Поэтому я использовал эту статью в своем поиске. Я все настроил и все еще были проблемы. Потратив несколько дней на изучение проблемы и исключение всего «Microsoft», я догадался, что это связано с сетью. Оказывается, наш WAN Accelerator был проблемой. Я заставил наших ребят из сети отключить ускорение для наших контроллеров домена, и все стало лучше.

Было много контроллеров, так же как и скрипт ( dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

Вы упоминаете, что у вас есть 20 серверов DFS, но не упоминаете, находятся ли все серверы в одном помещении.

Если эти серверы не находятся в одном и том же объекте, и у каждого сайта есть свой собственный домен, вы можете убедиться, что отработка отказа клиента включена.

Для тех, кто попал сюда через поиск в Google и у кого такая же проблема ...

Сначала убедитесь, что все ссылки в вашем пространстве имен доступны и исправны. Именно это и произошло в моем случае: в пространстве имен все еще была ссылка на неработающий сервер, поэтому долгая пауза при открытии DNS была из-за того, что он искал этот сервер и не работал. Как только я отключил эту ссылку в DFS, долгая пауза прошла.

Убедитесь, что группа «Прошедшие проверку» имеет доступ к списку содержимого корневого каталога, к которому вы подключены. Например, если диск x: сопоставлен с \ domain.local \ departents \ Marketing, тогда пользователю потребуется разрешение списка для \ domain.local \ департаментов. В 2008/2012 вы можете указать в разделе расширенных разрешений, что он применяется к «Только этой папке», чтобы им не разрешалось перечислять содержимое любых подпапок, которые могут наследовать разрешения.