Тривала пауза під час доступу до простору імен DFS

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

По-перше, деякий фон в нашій мережі:

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

Фактичні цілі папок (тобто SMB, на які вказують наші папки DFS), розкидані по декількох серверах файлів і додатків, на яких працює панель Windows 2008, два сервери додатків, на яких працює Windows 2003 R2, без налаштування реплікації взагалі (наприклад, усі папки DFS в даний час лише одна ціль папки).

Ще кілька деталей щодо проблеми:

Затримка доступу до простору імен зазвичай триває від 1 до 10 секунд і, здається, виникає, коли певний комп'ютер не має доступу до потрібного простору імен протягом приблизно п'яти хвилин або більше.

Наприклад, якщо користувач не звертався до \\ domain.name \ namespace1 \ протягом більше п'яти хвилин і намагається отримати доступ до \\ domain.name \ namespace1 \ через Провідник Windows, вікно Explorer застигне на 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 надсилався від клієнта до постійного струму, і перенаправленням на кореневий сервер DFS, що повертався з постійного струму до клієнта, постійний струм висилав декілька імен трансляції пошук у мережі.

По-перше, 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 KB244380 і інші) і були в курсі цього розділу реєстру, але misintepreted інструкції про те, коли / як використай це.

KB244380 говорить:

Ключ реєстру DFSDnsConfig повинен бути доданий до кожного сервера, який братиме участь у просторі імен DFS для всіх комп'ютерів, щоб зрозуміти повноцінні імена.

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

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

Я сподіваюся, що це корисно для інших, хто стикається з подібною проблемою - і ще раз дякую тим, хто запропонував пропозиції по дорозі.

Це може бути викликано замовленням мережевої маски сервера DNS. Ми нещодавно зустріли це на сервері 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, але все йде. Я набагато віддав перевагу старій ФРС, тому що такі інструменти діагностики, як УЗД, були настільки корисними: 7

Чи отримуєте ви щось у журналі подій реплікації DFS про цілі? (Звіт охорони здоров’я DFS отримає свої попередження з журналу подій)

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

Клієнт кешує реферал DFS, тобто коли ви вводите \ 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, але я публікую на користь інших, оскільки ми використовували цю публікацію найбільше, щоб допомогти вирішити дуже подібну проблему. Для нас це виявилося тим, що хтось вирішив назвати свою робочу станцію тим же ім'ям, що і домен. Отже, кожного разу, коли DC робив пошук доменного імені для перенаправлення DFS, він хотів перейти на цю робочу станцію і призведе до значної затримки в 10 секунд. Статичний 20 запис був розміщений у WINS, що вказує на постійний струм, і це вирішило проблему. Якщо у вас не було 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 був проблемою. У мене хлопці з Мережі вимкнули прискорення для наших контролерів домену, і все стало краще.

Мало багато контролерів, так само і сценарій ( 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 \ Маркетинг, тоді користувачеві знадобиться дозвіл у списку для \ domain.local \ відділів. У 2008/2012 році ви можете вказати в розширених дозволах, що воно застосовується до "Тільки цієї папки", щоб їм не дозволялося перелічувати вміст будь-яких підпапок, які можуть успадковувати дозволи.