Вопрос: 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-because-it-turns-out-friday-night-was-alright-for-fighting.aspx# DFSR

Любые изменения, которые происходят на сервере BETA, реплицируются на сервер ALPHA очень быстро, поскольку в этом направлении нет отставания. Любые файлы, измененные на BETA, действительно попадают в ALPHA без проблем.

Он реплицирует 24/7 на полной скорости через соединение 50 Мбит / с на один конец до волокна 100 Мбит / с на другом конце. Промежуточная область составляет 100 ГБ на каждом сервере. В журналах событий ничего интересного нет. Существует несвязанное событие с высоким водяным знаком, которое появляется для группы несвязанных реплик, которая не является ни для этой конкретной репликации, ни для этой пары серверов ALPHA / BETA. В частности, нет записей журнала событий для высокого водяного знака или ошибок подключения.

Взгляд ALPHA на группу репликации:

Экономия полосы пропускания: Уменьшение на 99,83% (30,85 МБ, вместо 18,1 ГБ)

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

Реплицированная папка: 1.46TB (фактический размер), 439 387 (файлы), 52 886 (папки)

Конфликт и удаленная папка: 100,00 ГБ (сконфигурированный размер), 34,01 ГБ (фактический размер), 19,620 (файлы), 2,393 (папки)

Простая папка: 200,00 ГБ (сконфигурированный размер), 92,54 ГБ (фактический размер)

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

Отключение антивируса на всех серверах не помогите, хотя я думал, что это немного помогло бы. На данный момент я снова включил антивирус, но установил путь группы репликации для исключения из сканирования, чтобы удалить эту переменную из уравнения.

Есть ли способ ускорить это? Я бы просто сделал это изменение на сервере BETA, но есть файлы, которые были изменены на ALPHA, но не были реплицированы в BETA и, если унаследованные изменения разрешения на BETA будут толкать OLD файлы из BETA в ALPHA (поскольку DFSR, похоже, игнорирует временные метки файла при сравнении, какой файл является победителем при столкновении). И если это произойдет, это будет довольно плохо.

Недостаток медленно уменьшается. Очень, очень медленно. Однако он идет вперед. Но с такой скоростью, за несколько недель до ее завершения. Я созерцаю просто копирование набора данных на диск 3 ТБ и отправку его в удаленный офис. Есть ли способ лучше?

16 мая, 4:00. США: Что могло бы устранить проблему (при условии, что это честно зафиксировано, во всяком случае):

Я сделал несколько изменений в DC, которые должны были быть сделаны давным-давно. Проблема в том, что эта сеть была унаследована от кого-то другого, кто, вероятно, унаследовал ее от кого-то еще и т. Д. Я не могу обещать, какое изменение фиксирует проблему. Здесь они не имеют особого порядка:

  • Все контроллеры домена не были в подразделении «Контроллеры домена». Я никогда не видел домен Windows, в котором есть свои DC в другом месте. Я вернул их туда, где они были. Раньше они были в подразделениях, которые были разделены по имени города, в каждом офисе. (У меня есть чувство, что у меня есть работа по сантехнике, чтобы разобраться с тем, что я переместил их, но все кажется хорошо в настоящее время ...)
  • Антивирус AVG работает на всех серверах, участвующих в DC и DFSR. Я исключил реплицированные папки и промежуточные папки из режима активного сканирования. Я не думаю, что это устранило проблему, и я, скорее всего, проведу эту проблему позже, чтобы увидеть, будет ли отменять это изменение, препятствуя скорости репликации DFSR. Это вызов еще на один день.
  • Dcdiag.exe жаловался на проблему DNS в отношении RODC. Я исправил эту проблему, даже если у нас нет никаких контроллеров домена только для домена. Я в этом сомневаюсь.
  • Одна из записей _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV отсутствовала для одного из DC (не одного из серверов 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, были очень быстрыми и успешными.

EDIT 5/22/2012: Сейчас он в 12000 и должен быть закончен через несколько часов. Я опубликую хороший график прогресса с медленного старта до быстрого завершения. Проблема в том, что единственное, что действительно «фиксировано», это локальное подключение к серверу. В настоящее время я думаю, что, возможно, VPN является частью проблемы. И если это так, я чувствую, что на этот вопрос еще не ответил. После того, как у меня появилось еще какое-то время, чтобы проверить, как вещи реплицируются через VPN и какие-либо сбои, я буду отлаживать и сообщать о прогрессе.

Если что-то изменится, я обновлю здесь.


9
2018-05-12 03:07


Источник


Сколько данных необходимо реплицировать и сколько пропускной способности доступно между вашим сайтом и удаленным сайтом? Кроме того, вы дросселируете репликацию DFS? - MDMarra
Мой ответ на добавление такой же, как MDMarra (проверьте расписание репликации и размер очереди), поэтому я просто оставлю комментарий. Если это было изменение разрешения, то это не фактические данные, которые реплицируются, а атрибуты безопасности для каждого файла. В этих случаях отставание обычно не зависит от полосы пропускания. Вы не упомянули ничего, что показано в журнале событий, но стоит посмотреть. Также запустите отчет DFSR Diagnostic для группы репликации. - Jeff Miles
Кроме того, в Windows Server 2012 есть функция, которая должна устранить эту проблему навсегда: blogs.technet.com/b/askds/archive/2012/04/14/... - Jeff Miles
Я обновил вопрос, чтобы ответить на эти вопросы. - Dusty W
dfsrdiag replicationstate /a показывает, что он отправляет только два файла, но оба имеют одинаковое имя файла. В нем говорится, что у него есть два исходящих соединения с BETA от ALPHA. Файл, который он отправляет, составляет 850 МБ. Как описано выше, я не уверен, что это на самом деле отправка содержимое всего файла, хотя я не уверен какие это было бы сделано, если бы не так, потому что требуется очень много времени, чтобы разобраться с одним файлом. Файл был последним обновлен в 2008 году (на обоих серверах), поэтому нет причин, по которым он должен ничего делать, кроме обновления информации ACL в файле на BETA. - Dusty W


Ответы:


Очень странная проблема, особенно после просмотра редактирования.

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

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

Другие вопросы / предложения:

Есть ли что-то неуместное при просмотре Монитора ресурсов? Превышение жесткого диска или активности процессора за пределами базовой линии?

Если возможно, я перезапустил серверы Alpha и Beta. Если он разрешит вашу проблему, вы, возможно, никогда не узнаете, какова настоящая проблема, но если ее критическая ситуация скоро будет решена, стоит попробовать.

Изменить на основе обновления вопроса

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

Можете ли вы попытаться изменить место постановки на другую папку или диск на каждом сервере? В случае, если файлы, которые в настоящее время проводятся, повреждены или блокируют репликацию каким-либо образом.


2
2018-05-14 02:58



В новейшем файле журнала ничего не найдено «предупреждение», но оно имеет ошибки. Ошибки все точно так же: «20120513 23: 38: 59.198 6592 ASYN 755 [WARN] AsyncUnbufferedFileWriter :: SetFileSizeEstimate [Ошибка: 87 (0x57) FileUtil :: SetFileValidDataLength fileutil.cpp: 1657 6592 W Параметр неверен.]« Я отключил антивирус, а также выяснить, вызывает ли это это ужасное замедление. Я забыл, что av был даже на этих серверах, и это может быть причиной проблемы. : - | - Dusty W
К этому вопросу добавлены антивирусные заметки. Как видно, оно ничего не влияет. - Dusty W
Я много раз перезагружал ALPHA и BETA в ходе отладки этой проблемы. Похоже, что это не повлияло ни на что, кроме соответствующих ошибок в журналах событий на противоположном сервере. Активность процессора на обоих серверах очень низкая. Это вряд ли составляет 20% даже при высокой загрузке в середине дня. То же самое с ОЗУ. Диск-записи очень часты, но он никогда не отображается как привязанный на 100%. Кажется, он не связан с IO. Прямо сейчас я просто должен предположить, что что-то где-то ждет какого-то поиска и времени? Я не вижу других причин такого поведения. Я все еще копаю ... - Dusty W
Мне пришлось перезагрузить BETA снова из-за применения Windows Updates, и он вернулся с 2212, но не вернулся с 2214, так что теперь я жду и жду. Может быть, это знак хорошего будущего. Или это означает, что на BETA есть только что-то напуганное. Серверы: pfft. - Dusty W
... нет кубиков. То же медлительность, те же проблемы. Я буду продолжать нажимать. - Dusty W


Вы можете настроить расписание репликации, чтобы позволить DFS-R реплицироваться на полной скорости в нерабочее время (или даже в часы, если это необходимо).

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

Вы не упомянули, ограничено ли это, но я предполагаю, что это происходит, поскольку у вас есть репликация через глобальную сеть.


5
2018-05-12 03:49



Я обновил вопрос, чтобы ответить на ваш ответ. В частности, он подробно описывает график полнотекстового репликации 24/7 и зону хранения 100 ГБ. То, что вы сказали, было бы полезно, если бы эти предметы еще не были на месте. Я ценю ваше взаимодействие по этому поводу. - Dusty W


Мой опыт в том, что это просто, как это работает.

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

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

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


0
2017-11-15 13:28