Вопрос: Есть ли способ ускорить завершение этой 350 000 файловой очереди? Почти для каждого файла единственным изменением было изменение ACL для каждого затронутого файла. В некоторых файлах изменилось содержимое, но в данной ситуации это нечасто.
Это можно исправить. Я отредактирую этот текст, чтобы подтвердить успех / неудачу после определенного периода времени и проверки. Ближе к концу текста этого вопроса я подробно описал внесенные недавно изменения, которые могли его исправить.
У нас есть группа репликации DFSR, которая содержит около 450 000 файлов и занимает 1,5 ТБ места. В этой ситуации два сервера Windows Server 2008 R2 находятся на расстоянии около 500 миль друг от друга. Есть и другие серверы, но они не участвуют в этой группе репликации. Сервер ALPHA - это главный сервер, которым пользуется большинство сотрудников. БЕТА-сервер - это сервер в удаленном офисе, который менее загружен.
Вот график отставания для этой группы репликации (PNG, размещенный на Google Диске), показывающий медленный процесс синхронизации.
Мне нужно было удалить запись о разрешении, которая была в корневом каталоге этой группы репликации, которая, конечно, была унаследована от большинства подпапок. Я внес это изменение на сервере ALPHA. Сразу после этого у DFSR накопилось 350 000 файлов. Прошло больше недели, и сейчас он составляет 267 тысяч. Единственное, что изменилось (изначально), - это изменение одного разрешения.
Вот что произошло (это не решение, просто еще одно объяснение того, что стало причиной этой проблемы): 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, поскольку в этом направлении нет отставания. Любые файлы, измененные в БЕТА-версии, без проблем переводятся в АЛЬФА.
Он реплицирует 24/7 на полной скорости через соединение 50 Мбит / с на одном конце с оптоволоконным кабелем 100 Мбит / с на другом конце. Промежуточная область составляет 100 ГБ на каждом сервере. В журналах событий вообще ничего интересного нет. Существует несвязанное событие с высоким уровнем водяного знака, которое обнаруживается для несвязанной группы репликации, которая не предназначена ни для этой конкретной репликации, ни для этой пары серверов АЛЬФА / БЕТА. В частности, нет записей в журнале событий для высокого уровня или ошибок соединения.
Взгляд 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 мая, 19:00), и поэтому увеличил промежуточную квоту до 200 ГБ с 100 ГБ. Я знаю, что одобренный Microsoft маршрут должен увеличиться на 20%, но я не играю с этим. У нас есть достаточно свободного места на промежуточных дисковых массивах.
Отключение антивируса на всех серверах сделало не помогите, хотя я думал, что это немного помогло бы. На данный момент я повторно включил антивирус, но установил, что путь группы репликации будет исключен из сканирования, чтобы удалить эту переменную из уравнения.
Есть ли способ сделать это быстрее? Я бы просто сделал это изменение на сервере BETA, но есть файлы, которые были изменены на ALPHA, но не реплицированы в BETA, и изменение унаследованных разрешений на BETA подтолкнет Старый файлы из BETA в ALPHA (потому что DFSR, похоже, игнорирует временные метки файлов при сравнении, какой файл является победителем в конфликте). И это было бы очень плохо.
Задержки медленно сокращаются. Очень-очень медленно. Однако он идет вперед. Но при таких темпах до завершения будут недели. Я собираюсь просто засунуть копию набора данных на диск емкостью 3 ТБ и отправить ее в удаленный офис. Есть ли способ лучше?
16 мая, 4:00 (тихоокеанское время), США: что могло бы решить проблему (в любом случае, если она действительно исправлена):
Я внес несколько изменений в контроллеры домена, которые должны были быть внесены давным-давно. Проблема в том, что эта сеть была унаследована от кого-то другого, кто, вероятно, унаследовал ее от кого-то другого и т. Д. Я не могу обещать, какое изменение устранило проблему. Вот они в произвольном порядке:
Мораль этой истории такова: меняйте одну вещь за раз, иначе вы никогда не узнаете, что это исправило. Но я был в отчаянии, и у меня не хватало времени, чтобы исправить это, поэтому я просто выпустил кучу пуль по проблеме. Если я когда-нибудь определю исправление, я сообщу об этом здесь. Однако не рассчитывайте на то, что я сужу его.
РЕДАКТИРОВАТЬ 21.05.2012: Я решил эту проблему, вчера проехав около семи часов с запасным сервером (GAMMA) в удаленный офис. GAMMA теперь действует как их основной локальный сервер, в то время как их обычный сервер (BETA) догоняет репликацию. С тех пор, как я поставил его на место, скорость репликации серверов увеличилась вдвое. Хотя это говорит мне, что это может быть проблема, связанная с VPN, я менее склонен полагать, что это так, поскольку все новые обновления, похоже, реплицируются в GAMMA из ALPHA, были очень быстрыми и успешно развивались.
РЕДАКТИРОВАТЬ 22.05.2012: Сейчас он на 12000 и должен быть закончен через несколько часов. Я выложу красивый график прогресса от медленного старта до быстрого финиша. Проблема в том, что единственное, что действительно «исправило», - это подключение к локальному серверу. В настоящее время я думаю, что, возможно, проблема заключается в VPN. И если это так, я чувствую, что на этот вопрос еще нет полного ответа. После того, как у меня будет еще немного времени, чтобы проверить, как происходит репликация через VPN, и увидеть какие-либо сбои, я отлажу и сообщу о ходе выполнения.
Если что-то изменится, обновлю здесь.
Вы можете настроить расписание репликации, чтобы позволить DFS-R реплицироваться на полной скорости в нерабочее время (или даже в часы, если это необходимо).
Вы также можете попробовать увеличить размер промежуточного хранилища на сервере с обратным журналом. Это должно повысить производительность в этой ситуации.
Вы не упоминаете, ограничен ли он, но я предполагаю, что это связано с тем, что у вас есть репликация через WAN.
Очень странная проблема, особенно после просмотра правки.
Я бы проверил журнал отладки 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.
Можете ли вы попробовать изменить промежуточное местоположение на другую папку или диск на каждом сервере? Если файлы, которые в настоящее время находятся в стадии подготовки, повреждены или каким-либо образом блокируют репликацию.
По моему опыту, это именно так.
Я наткнулся на это после обновления безопасности для довольно небольшой коллекции из 4 групп репликации DFS (550 ГБ данных, 58 тыс. Файлов, всего 3,4 тыс. Папок). Объем данных, фактически передаваемых по сети, невелик, поэтому кажется, что перемещаются не целые файлы только для изменения безопасности, но при работе с диском создается впечатление, что вся иерархия копируется - постоянная скорость передачи диска между 60-100 МБ / с и дисковые очереди из 30, достигая максимального значения 500 на многоуровневом хранилище SSD.
Я чувствую, что DFS имеет много оттока в процессе постановки и отключения, что приводит к экстремальным дисковым операциям ввода-вывода. Начальный процесс репликации между двумя блоками, подключенными к гигабитной локальной сети, занимает в несколько раз больше времени, чем одни и те же данные, просто копируемые между блоками, что, казалось бы, указывает на то, что для каждого реплицированного байта требуется несколько байтов чтения и записи на диск.
Обновления безопасности, похоже, не имеют какой-либо специальной логики репликации, запрещающей использование безопасности на основе утверждений 2012 года (которая не так широко используется AFAICT), что приводит к тому же оттоку этапов / удалений, который вы получили бы при изменении данных.