У нас есть инфраструктура DFS с 3 серверами и 93 реплицированными папками. Когда я запускаю отчет о работоспособности из консоли управления DFS, состояние одной из этих папок отображается как «неинициализировано». Эта папка ранее реплицировалась нормально.
Перезагрузка всех 3-х серверов DFS устраняет состояние «неинициализировано», и папка начинает нормально реплицироваться. Однако он довольно быстро вернется в "неинициализированное" состояние, обычно в течение недели.
Я наблюдал за этой папкой в DFS, и действительно кажется, что огромное количество изменений попадет в эту папку за очень короткие периоды времени - то есть отставание репликации вырастет до более чем 100000 записей ранним утром в будний день. Обычно отставание быстро сокращается в течение следующих нескольких часов, поэтому я не беспокоился об этом.
Однако этот статус «неинициализирован» теперь означает, что репликация вообще не выполняется на серверах, где папка имеет этот статус. Значит, теперь у нас есть проблема. Я не отследил конкретные файлы или причины, но я разослал запросы команде разработчиков настольных компьютеров, чтобы помочь определить причину отставания.
Я не обнаружил ошибок журнала событий, связанных с этой папкой или статусом. Я подумал, что, возможно, большое количество изменений файлов на томе может вызывать ошибки переноса журнала, но я не нашел никаких журналов событий, связанных с переносом журнала USN. В папке действительно есть постоянные нарушения общего доступа, но все они в конечном итоге разрешатся сами собой, как только файлы будут закрыты до этой «неинициализированной» проблемы.
Мое исследование показало ноль, за исключением возможного повреждения конфигурации xml, но в тех случаях проблема была только с репликацией sysvol.
Моя единственная гипотеза состоит в том, что DFSR автоматически устанавливает статус «неинициализирован», когда количество различий превышает определенный порог. Но я не могу проверить эту гипотезу и не могу найти никакой документации, подтверждающей ее. И даже если это правда, я не знаю, как бы я «переинициализировал» папку.
Участвующие серверы:
A: Сервер отправки, 2008r2, промежуточная квота 25 ГБ, статус: Нормальный
B: Принимающий сервер, 2008r2, промежуточная квота 175 ГБ, статус: Неинициализировано
C: Принимающий сервер, 2012r2, промежуточная квота 25 ГБ, статус: Нормальный
Все три сервера выполняют двойную функцию контроллеров домена AD. Все 93 реплицируемых папки находятся в одной группе репликации, поэтому удаление и повторное создание группы RG может занять много времени. Когда эта проблема впервые возникла, небольшая горстка других папок также показывала этот статус, но только в этой папке проблема повторялась после перезагрузки. Затронутая папка размером 202 ГБ с 547 252 файлами.
Что вызывает "неинициализацию" папки и как мне решить эту проблему?
-Редактировать- Еще немного информации. Принимающий сервер перезагрузился вчера в полночь (~ 36 часов назад). Это привело к тому, что папка перешла в состояние «Нормальный», и началось накопление невыполненной работы. Когда я проверил его вчера, в этой папке было 205 662 файла. Когда я сегодня проверил, отставание составляет 579 447 файлов. В настоящее время в папке всего 551 706 файлов. Бэклог больше, чем размер папки. В отчете о работоспособности DFS говорится, что в эту папку было получено 851 592 файла. Пока что ни у одной другой папки нет такой проблемы.
Я не знаю, является ли невыполнение репликации причиной сбоя репликации, или если репликация дает сбой и вызывает отставание, или есть ли какая-то основная база данных или повреждение журнала журнала, вызывающее как неудачную репликацию, так и отставание. Я также не знаю, как решить проблему в любом случае.
Прямо сейчас есть одна группа репликации для 93 папок. Я готов взорвать его и настроить 93 группы репликации. Если это не решит проблему, по крайней мере, упростит устранение неполадок.