Недавно мы перевели нашу сеть Windows на использование DFS для общих файлов. DFS работает хорошо, за исключением одной досадной проблемы: пользователи испытывают значительную задержку при попытке доступа к пространству имен DFS, к которому они не обращались в течение некоторого времени. Я попытался устранить проблему, но до сих пор не добился успеха, и я надеялся, что у кого-то здесь могут быть некоторые указатели, которые помогут решить проблему.
Во-первых, немного предыстории нашей сети:
В сети используется домен Active Directory функционального уровня Windows 2008 с двумя контроллерами домена Windows 2008 и двумя серверами DNS (по одному на каждом контроллере домена). Сеть только DNS - без WINS. Все компьютеры расположены в одном месте и подключены через Gigabit Ethernet. У нас есть примерно 20 доменных пространств имен DFS в режиме Windows 2008, и каждое пространство имен DFS имеет два сервера пространства имен Windows 2008 DFS (те же два сервера для всех пространств имен). Все серверы пространства имен находятся в режиме FQDN, и все целевые папки указываются с использованием их FQDN. На всех компьютерах установлены последние обновления с пакетами обновлений и исправлениями.
Фактические целевые папки (т.е. 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 минут.
Пытаясь решить проблему, я уже пробовал / проверял следующее (безуспешно):
Вот где я задумал - и у меня нет идей. Может ли кто-нибудь подсказать, что может быть причиной задержек и / или что мне следует попробовать дальше?
Ну мы Ну наконец то похоже, решили эту проблему в нашей среде. В интересах других вот что мы обнаружили и как решили проблему:
Чтобы попытаться лучше понять, что происходило до / во время / после задержек, мы использовали Wireshark на клиентском компьютере для захвата / анализа сетевого трафика, пока этот клиент пытался получить доступ к общему ресурсу DFS.
Эти записи показали что-то странное: всякий раз, когда происходила задержка, между запросом DFS, отправленным от клиента к DC, и обращением к корневому серверу DFS, возвращающимся от DC к клиенту, DC отправлял несколько широковещательных имен поиск в сети.
Во-первых, DC будет транслировать поиск NetBIOS для DOMAIN (где DOMAIN - это наше доменное имя Active Directory до Windows 2000). Через несколько секунд будет транслироваться LLMNR поиск DOMAIN. За этим последует еще один широковещательный поиск NetBios для DOMAIN. После широковещательной передачи этих трех запросов (и я предполагаю, что истекло время ожидания) контроллер домена, наконец, ответил клиенту (правильной) ссылкой на корневой сервер DFS.
Эти поисковые запросы широковещательного имени для DOMAIN отправлялись только тогда, когда происходила длительная задержка открытия общего ресурса DFS, и мы могли ясно видеть из захвата Wireshark, что контроллер домена не возвращал ссылку на корневой сервер DFS, пока не были отправлены все три запроса ( и прошло ~ 7 секунд). Итак, эти поиски имени трансляции были довольно очевидной причиной наших задержек.
Теперь, когда мы знали, в чем проблема, мы начали пытаться выяснить, почему происходит поиск этих широковещательных имен. После небольшого количества запросов в Google и некоторых проб и ошибок мы нашли ответ: мы не установили для ключа реестра DfsDnsConfig на наших контроллерах домена значение 1, как это требуется при использовании DFS в среде только с DNS.
Когда мы изначально устанавливали DFS в нашей среде, мы сделал прочтите различные статьи о том, как настроить DFS для среды только с DNS (например, Microsoft KB244380 и другие) и знали об этом разделе реестра, но неверно истолковали инструкции о том, когда и как его использовать.
KB244380 говорит:
Раздел реестра DFSDnsConfig необходимо добавить на каждый сервер, который будет участвовать в пространстве имен DFS, чтобы все компьютеры понимали полностью определенные имена.
Мы думали, что это означает, что ключ реестра должен быть установлен в DFS. серверы пространства имен только, не понимая, что это также требовалось на контроллерах домена. После того как мы установили для DfsDnsConfig значение 1 на наших контроллерах домена (и перезапустили службу «Пространство имен DFS»), проблема исчезла.
Очевидно, мы довольны таким результатом, но я бы добавил, что я все еще не на 100% уверен, что это наша единственная проблема - мне интересно, сработало ли добавление DfsDnsConfig = 1 в наши DC только для решения проблемы, а не для ее решения. . Я не могу понять, почему контроллеры домена пытались найти DOMAIN (само доменное имя, а не сервер в домене) во время процесса перенаправления DFS, даже в среде, отличной от DNS, и я также знаю, что не устанавливали DfsDnsConfig = 1 на контроллерах домена в других (по общему признанию, гораздо меньших / более простых) средах только для DNS и не имели такой же проблемы. Тем не менее, мы решили нашу проблему, поэтому очень довольны.
Я надеюсь, что это будет полезно для других, которые сталкиваются с подобной проблемой - и еще раз спасибо тем, кто предлагал свои предложения по ходу дела.
В блоге группы разработчиков 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-сервера. Мы столкнулись с этим недавно в Server 2003. Это зависит от вашей текущей подсети.
Пример.
Сайт 1: IP-подсеть 10.0.0.0/24 Сайт 2: IP-подсеть 10.0.1.0/24
Клиент на сайте 2 выполняет DNS-запрос для вашего доменного пространства имен, и по умолчанию ему будет предоставлен сервер DFS на сайте 1, поскольку DNS-сервер не знает границ IP-адреса сайта. Вам необходимо указать вашим DNS-серверам, какую маску подсети использовать, чтобы определить, с какими IP-адресами следует отвечать.
Пахнет проблемой 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 на том же томе, и у них не было задержки при доступе к папкам там.
Разница между ними заключается в перечислении на основе доступа (ABE) - эта проблемная общая папка включена (это обычный диск для пользователей с тысячами папок - ABE означает, что пользователи видят только те папки, к которым у них есть разрешения).
Отключение ABE полностью устранило проблему. Очевидно, это не решение, поскольку пользователи затем видят все папки, сбивая их с толку. Я реплицировал общий ресурс DFS на сервер с некоторым запасным диском в качестве временной меры, и даже с включенным ABE на этой новой цели задержка исчезла.
Проблемный сервер - 2k3R2, время безотказной работы - более 150 дней (!), Поэтому он будет перезагружен и CHKDSK будет запущен на проблемном томе. Я отправлю сюда ответ, если это повлияет на проблему. Новая цель находится на сервере 2k8.
dfsutil / spcflush и dfsutil / pktflush могут быть решением также в многосайтовой сети. Убедитесь, что ссылка DFS на домашний сайт идет с локального сервера, а не из кеша.
Я знаю, что исходный плакат не использовал WINS, но я публикую его для других, поскольку мы использовали этот пост больше всего, чтобы помочь решить очень похожую проблему. Для нас это закончилось тем, что кто-то решил назвать свою рабочую станцию тем же именем, что и домен. Таким образом, каждый раз, когда контроллер домена выполнял поиск по доменному имени для ссылки DFS, он хотел разрешить эту рабочую станцию и вызывал значительную задержку в несколько десятков секунд. В WINS была помещена статическая запись 20, указывающая на DC, и это решило проблему. Если бы у вас не было WINS, вы могли бы поэкспериментировать с размещением доменного имени в качестве имени машины в файле LMHOSTS, указывающем на контроллер домена, чтобы получить поиск 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 \ sizes. В 2008/2012 вы можете указать в расширенных разрешениях, что он применяется к «Только этой папке», чтобы им не разрешалось перечислять содержимое любых подпапок, которые могут наследовать разрешения.