Windows DFSR - изменены разрешения для реплицированного каталога, и теперь они имеют 350 000 резервов на срок более недели

Вопрос: Есть ли способ ускорить заполнение этого журнала из 350 000 файлов? Почти для каждого файла единственным изменением было изменение ACL для каждого затронутого файла. Некоторые файлы изменили содержимое, но это не распространенный случай в этой ситуации.

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

У нас есть группа репликации DFSR с около 450 000 файлов и занимающая 1,5 ТБ пространства. В этой ситуации два сервера Windows Server 2008 R2 находятся на расстоянии около 500 миль. Есть другие серверы, но они не участвуют в этой группе репликации. Сервер ALPHA является основным сервером и используется большинством сотрудников. Сервер BETA является сервером в удаленном офисе и менее загружен.

Вот график отставания для этой группы репликации (PNG, размещенный на Google Диске), показывающий медленную синхронизацию.

Мне нужно было удалить запись разрешения, которая была в корневом каталоге этой группы репликации, которая, конечно, была унаследована в большинстве подпапок. Я сделал это изменение на сервере АЛЬФА. Сразу после этого у DFSR было 350 000 файлов. Прошло больше недели, а сейчас 267 000. Единственное, что изменилось (изначально), было единственное изменение разрешения.

Вот что произошло (это не решение, просто еще одно объяснение того, что стало причиной этой проблемы): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -наличие-он-витки-из-пятницу вечером-был-хорошо-для-fighting.aspx # DFSR

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

Он реплицируется 24/7 на полной скорости через соединение 50 Мбит / с с одного конца на оптоволокно 100 Мбит / с с другого конца. Площадь подготовки составляет 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 (файлы), 2 393 (папки)

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ 21.05.2012. Я решил эту проблему, проехав около семи часов с запасным сервером (GAMMA) вчера в удаленном офисе. Теперь GAMMA выступает в качестве основного локального сервера, а их обычный сервер (BETA) догоняет репликацию. С тех пор, как я поставил его на место, серверы удвоили скорость репликации. Хотя это говорит о том, что это может быть проблема, связанная с VPN, я менее склонен полагать, что это так, поскольку все новые обновления, похоже, реплицируются на GAMMA от ALPHA, были очень быстрыми и идут хорошо.

РЕДАКТИРОВАТЬ 22/22/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- лесозаготовительных-уровни-лог-формат-справ-s.aspx

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

Есть ли что-то неуместное при просмотре монитора ресурсов? Избыточная активность жесткого диска или процессора, выходящая за пределы базовой линии?

Если возможно, я бы перезапустил как Альфа, так и Бета серверы. Если это решит вашу проблему, вы, возможно, никогда не узнаете, в чем заключалась настоящая проблема, но если критично, что эта проблема скоро будет решена, стоит попробовать.

Редактировать на основе обновления вопроса

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

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

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

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

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

Мой опыт показывает, что именно так и работает.

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

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

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