it-swarm-ru.tech

Длинная пауза при доступе к пространству имен 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
  • Отключен антивирус на клиентах и ​​серверах
  • Удаление одного из серверов пространства имен из пары пространств имен - без разницы

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

22
Matt

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

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

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

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

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

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

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

KB244380 говорит:

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

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

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

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

28
Matt

Это может быть вызвано порядком маски сети 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

3
Chris

В блоге группы 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, Даниэль

3
Daniel B

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

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

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

2
Oskar Duveborn

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

1
David Jenkins

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

1
Parag DJ

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

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

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

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

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

1
slag

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

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

Клиент кэширует ссылку 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, которая открывает первый найденный файл и сразу же закрывает его. Я не пробовал и не проверял это, и вам определенно нужно было бы внимательно рассмотреть, если вы собираетесь это сделать.

1
Maximus Minimus

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

1
newguy

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

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

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

1
Amy

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

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

0
Ishmael

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

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

0
Bryan