Windows DFSR - Змінено реплікацію дозволів для каталогу та тепер має 350 000 відстань більше тижня

Питання: Чи є спосіб швидше завершити цей відстань на 350 000 файлів? Практично для кожного файлу єдиною зміною було зміна ACL для кожного файлу, який стосується. Деякі файли змінили вміст, але це нечастий випадок у цій ситуації.

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

У нас є група реплікацій DFSR з близько 450 000 файлів і займає 1,5 ТБ місця. У цій ситуації є два сервери Windows Server 2008 R2, які розташовані приблизно на відстані 500 миль. Є й інші сервери, але вони не задіяні в цій групі реплікацій. Сервер ALPHA - це основний сервер, який використовується більшою частиною персоналу. Сервер BETA - це сервер у віддаленому офісі і менш зайнятий.

Ось графік відставання для цієї групи реплікацій (PNG, розміщений на Диску Google), який показує повільний хід синхронізації.

Мені потрібно було видалити запис дозволу, який знаходився в кореневій директорії тієї групи реплікацій, яка, звичайно, була успадкована у більшості підпапок. Я вніс цю зміну на сервер ALPHA. Відразу після цього у DFSR було відстало 350 000 файлів. Пройшло більше тижня, а зараз це 267 000. Єдине, що змінилося (спочатку) - це зміна єдиного дозволу.

Так сталося (це не рішення, просто чергове пояснення того, що сталося, щоб викликати цю проблему): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -або-це-вивертається в п'ятницю-ніч-було-добре-для-бою.aspx # dfsr

Будь-які зміни, які відбуваються на сервері BETA, реплікуються на сервер ALPHA дуже швидко, оскільки немає відставання в цьому напрямку. Будь-які файли, змінені на BETA, роблять ALPHA без проблем.

Це реплікація 24/7 на повній швидкості через 50Mbps з'єднання з одного кінця на волокно 100Mbps на іншому кінці. Область постановки - 100 Гб на кожному сервері. У журналах подій взагалі немає нічого цікавого. Існує неспоріднена подія з високим водяним знаком, яка відображається для непов'язаної групи реплікацій, яка не є ні для цієї конкретної реплікації, ні для цієї серверної пари ALPHA / BETA. Зокрема, немає записів журналу подій для високих водяних знаків, а також для помилок підключення.

Погляд ALPHA на групу реплікацій:

Економія пропускної здатності : зменшення на 99,83% (копіювання 30,85 МБ замість 18,1 ГБ)

Я вважаю, що 30,85 Мб / 18,1 ГБ сталося з моменту останнього перезапуску служби DFSR на ALPHA та BETA. Якщо це так, це свідчить про те, що, хоча це займає дуже багато часу (більше, ніж я вважаю, це повинно зайняти), це фактично не передає вміст файлу через провід.

Повторена папка : 1,46 ТБ (фактичний розмір), 439,387 (файли), 52,886 (папки)

Папка конфліктів та видалених : 100,00 ГБ (налаштований розмір), 34,01 Гб (фактичний розмір), 19 620 (файли), 2393 (папки)

Постановочна папка : 200,00 ГБ (налаштований розмір), 92,54 ГБ (фактичний розмір)

Я отримав одну помилку у водяних знаках у журналах (14 травня, 7 вечора), і тому я збільшив квоту на 200 ГБ із 100 ГБ. Я знаю, що схвалений Майкрософт маршрут повинен збільшитися на 20%, але я в цьому не граю. У нас є багато дискового простору, щоб запастися на інтенсивних дискових масивах.

Відключення антивірусу на всіх серверах не допомогло, хоча я подумав, що це трохи допомогло б. Наразі я знову ввімкнув антивірус, але встановив шлях групи реплікацій виключити зі сканування, щоб видалити цю змінну з рівняння.

Чи є спосіб змусити це йти швидше? Я б просто вніс цю зміну і на BETA-сервер, але є файли, які змінилися на ALPHA, але не реплікувались на BETA, і, внісши спадкове зміна дозволу на BETA, підштовхне старі файли з BETA до ALPHA (тому що, здається, DFSR ігноруйте часові позначки файлів при порівнянні, який файл переможець у зіткненні). І мати це було б досить погано.

Відставання зменшується повільно. Дуже, дуже повільно. Хоча все-таки йде вперед. Але з такою швидкістю пройде кілька тижнів, перш ніж вона закінчиться. Я маю намір просто перенести копію набору даних на привід 3 ТБ і відправити її у віддалений офіс. Чи є кращий спосіб?

16 травня, 4 години ранку в США: що могло вирішити проблему (якщо все-таки її чесно виправити):

Я вніс кілька змін в постійні струми, які мали бути зроблені давно. Проблема полягає в тому, що ця мережа була успадкована від когось іншого, хто, ймовірно, успадкував її від когось іншого і т. Д. Я не можу обіцяти, які зміни вирішили проблему. Ось вони не в конкретному порядку:

• Усі постійні токи не були в ОУ «Контролери домену». Я ніколи не бачив домену Windows, в якому були свої постійні токи деінде. Я перемістив їх туди, куди вони належали. Раніше вони були в ОУ, які були відокремлені назвою міста, в якому знаходиться офіс. (У мене таке відчуття, що я маю справу з сантехнікою, з якою зараз переїхав, але зараз все здається нормальним ...)
• Антивірус AVG працює на всіх DC та DFSR-серверах. Я виключав копії папок і папок, що інсценіруються, із активного сканування / доступу. Я не думаю, що це вирішило проблему, і я, швидше за все, перевіряю цю проблему пізніше, щоб побачити, чи скасування цієї зміни буде заважати швидкості реплікації DFSR. Це виклик для іншого дня.
• dcdiag.exe поскаржився на проблему DNS стосовно RODC. Я усунув цю проблему, навіть якщо у нас взагалі немає RODC в домені. Я сумніваюся, що це щось виправляло.
• Один із записів SRV-файлів _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET відсутній для одного з постійного струму (не одного з серверів DFSR), і я усунув це. Я не думаю, що це теж не допомогло.
• Одного разу, коли я перезавантажував сервер BETA, він скаржився на погане відключення бази даних DFSR (подія 2212), а потім тривав години, щоб відновити базу даних. Коли я закінчив, він повідомив про подію 2214, щоб повідомити про закінчення. Після цього реплікація все ще працювала надзвичайно повільно, але це могло б допомогти розстебнути все, що застрягло.
• В одному з DC не було 127.0.0.1 як вторинний DNS-сервер у своїй інтерфейсі. Я додав його. Це був не один із серверів DFSR, так що, мабуть, нічого спільного з цим не було.
• Я стежив за блогом TechNet: Налаштування продуктивності реплікації в рекомендованих DFSR налаштуваннях реєстру для серверів DFSR. Я використав усі значення "перевіреного високої продуктивності", за винятком AsyncIoMaxBufferSizeBytes, встановленого на 4194304, що на один вищий показник нижче високого значення. Це могло б допомогти з проблемою ... а може й ні. Важко сказати, коли змінюється занадто багато змінних.
• dcdiag.exe поскаржився на проблему зв’язку зі службою RPC на BETA, але лише після внесення вищезазначених змін. Це, здавалося, було найбільш вірогідним питанням, але я нічого не зробив, щоб його виправити. VPN працював належним чином, і брандмауер не блокував його. Можливо, що один із перерахованих вище пунктів - це те, що спричинило, а потім усунуло проблему RPC або це могло бути простим збігом обставин. Я не отримую цієї помилки зараз, і реплікація працює безперебійно.

Мораль історії полягає в тому, щоб змінити одну за одною, інакше ви ніколи не дізнаєтесь, що це виправило. Але я був відчайдушним і не вистачало часу, щоб виправити це питання, тому я просто вистрілив купу куль при проблемі. Якщо я коли-небудь точно визначу виправлення, повідомлю про це тут. Хоча не приділяйте мені звуження.

EDIT 5/21/2012: Я вирішив це, проїхавши близько семи годин із запасним сервером (GAMMA) до віддаленого офісу. GAMMA тепер виступає основним локальним сервером, тоді як їх звичайний сервер (BETA) наздоганяє реплікацію. Оскільки я поставив це на місце, сервери збираються приблизно вдвічі швидкістю реплікації. Хоча це говорить мені, що це може бути проблема, пов’язана з VPN, я менш схильний вважати, що це так, оскільки всі нові оновлення, схоже, повторюються на GAMMA від ALPHA, були дуже швидкими та йшли добре.

РЕДАКЦІЯ 22.05.2012: Зараз він о 12000, і його слід закінчити через кілька годин. Я опублікую хороший графік прогресу від повільного старту до швидкого завершення. Проблема полягає в тому, що єдине, що насправді "фіксується" - це локальне підключення до сервера. Я зараз думаю, що, можливо, VPN є частиною проблеми. І якщо це так, я вважаю, що на це питання ще не досить відповіли. Після того, як у мене з’явиться ще деякий час, щоб перевірити, як все повторюється через VPN, і побачити будь-які збої, я налагоджуватиму повідомлення та повідомляю про хід.

Якщо щось зміниться, я тут оновлю.

Дуже дивна проблема, особливо після перегляду правки.

Я б перевірив журнал налагодження DFSR, який знаходиться тут:% systemroot% \ debug За замовчуванням має бути 9 попередніх файлів журналів, які були заархівовані GZ, і один, до якого записується зараз.

Відкрийте це у текстовому файлі та виконайте пошук тексту «попередження» чи «помилка». Ви можете ознайомитися з цією серією блогу для отримання більш детальної інформації про журнали налагодження: http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1- logging-level-log-format-guide-s.aspx

Інші питання / пропозиції:

Чи є щось поза місцем, дивлячись на монітор ресурсів? Надмірна активність жорсткого диска або процесора, що знаходиться поза базовою лінією?

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

Редагувати на основі оновлення запитань

Ви згадали дві записи, пов’язані з файлом 850 Мб, а також помилку в журналі налагодження DFSR.

Чи можете ви спробувати змінити місце розташування в іншу папку або диск на кожному сервері? У випадку, якщо файли, які наразі ставлять, пошкоджуються або блокують реплікацію якимось чином.

Ви можете налаштувати графік реплікації, щоб дозволити DFS-R копіювати на повній швидкості в неробочий час (або навіть у години, якщо це необхідно).

Ви також можете спробувати збільшити розмір інсценізації на сервері, що реєструється назад. Це повинно підвищити результативність у цій ситуації.

Ви не згадуєте, чи є це обмеження чи ні, але я припускаю, що це так, оскільки у вас є реплікація через WAN.

Мій досвід полягає в тому, що це просто як це працює.

Я натрапив на це після оновлення безпеки на досить невеликій колекції з 4 груп реплікацій DFS (дані 550 ГБ, файли 58k, папки 3.4k загалом). Дані, фактично передані по дроту, є низькими, тому, здається, вони не переміщують цілі файли, а лише зміни безпеки, але дискова активність відчуває, що вся ієрархія відновлюється - стійкі швидкості передачі диска між 60-100 Мб / сек та дискові черги 30, максимум 500 на багаторівневому просторі для зберігання SSD.

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

Оновлення безпеки, схоже, не мають жодної спеціальної логіки реплікації, яка забороняла б використання захисту на основі претензій 2012 року (яка широко не використовується AFAICT), що призводить до того ж етапу / децензування, який ви отримали б для зміни даних.