Windows Server 2003 R2 и DFSR: первая репликация без ручного вмешательства за два года

Windows Server 2003 R2 вышел в декабре, и мы его поставили в очередь сразу, потому что одно из главных улучшений там - новый движок репликации DFS, он же DFSR. Для нас это не абстрактный прогресс в changelog'е, а конкретный ответ на конкретную боль, которая тянется уже два года.

Что шло не так с FRS

Есть клиент с двумя офисами - основным и удалённым, связаны каналом. В каждом офисе по контроллеру домена, SYSVOL реплицируется через FRS (File Replication Service), общие папки тоже на DFS с FRS-репликацией. Схема на бумаге нормальная; на практике - раз в несколько недель кто-то из сотрудников в удалённом офисе не может войти, или применяются старые GPO, или в общих папках оказываются файлы двухнедельной давности вместо текущих.

FRS рассинхронизировался, причём тихо. Никакого алерта, никакого события в журнале, которое однозначно говорит «репликация встала». Event ID 13508 в NTFRS-логе появлялся, но нерегулярно и не всегда коррелировал с тем, что реально видели пользователи.

Стандартный способ лечения - принудительная синхронизация через BurFlags в реестре. Ставишь D4 на эталонном контроллере, D2 на остальных, перезапускаешь службу, ждёшь. Срабатывало. Но через три-четыре недели история повторялась. Мы прошли через это, наверное, раз десять. Каждый раз - внеплановый выезд или удалённый сеанс, объяснения клиенту, потерянный час.

Корень проблемы в самом FRS: механизм старый, основан на USN-журнале NTFS и нескольких внутренних базах данных, которые при любых неаккуратных перезагрузках или сбоях канала начинают расходиться. Лечить симптом можно бесконечно.

Что такое DFSR и зачем он лучше

DFSR - это принципиально другой движок. Он появился в Windows Server 2003 R2 как замена FRS для обычных общих папок DFS, а в следующей версии Windows Server (Longhorn) им планируется заменить и FRS для SYSVOL - но пока этого не произошло, на R2 можно уже перевести общие папки.

Главное отличие - репликация на уровне блоков (RDC, Remote Differential Compression). FRS гонял по сети целые файлы при любом изменении. DFSR передаёт только изменённые блоки внутри файла. Для офиса с узким каналом это уже ощутимо. Но важнее другое: внутренняя база данных DFSR (JET, тот же движок что у Active Directory) значительно устойчивее к рассинхронизации. Конфликты DFSR отслеживает явно, помещает конфликтующие версии в специальную папку - никакого молчаливого расхождения.

Управление тоже изменилось: консоль DFS Management в R2 позволяет видеть состояние репликации нормально, а не гадать по Event Log.

Как переводили

Миграция на DFSR для обычных DFS-папок (не SYSVOL) в R2 делается через новую консоль.

Первое - подняли R2 на тестовой виртуалке, прогнали сценарий на копии данных клиента. Убедились, что начальная синхронизация проходит корректно, конфликтов нет, данные совпадают.

Второе - на боевой среде: оба контроллера домена обновили до R2 (один за одним, с паузой на проверку). Схему AD расширять не потребовалось - R2 делает это в рамках обновления леса.

Третье - перенесли общие папки на DFSR через консоль DFS Management. Процесс: создаётся новая группа репликации, добавляются члены, указывается папка, задаётся расписание репликации и полоса пропускания. Начальная синхронизация заняла несколько часов (данных было прилично), канал не забила - RDC работало.

Четвёртое - оставили FRS-репликацию SYSVOL пока на месте. R2 позволяет переводить SYSVOL на DFSR только в домене с функциональным уровнем следующей версии Windows Server (Longhorn), которого у клиента нет. Живём пока с FRS для SYSVOL, но там объём минимальный и рассинхронизация случалась реже.

Что получили

Общие папки реплицируются уже три недели без единого инцидента. Это рекорд за два года обслуживания этого клиента. Консоль DFS Management показывает состояние каждого члена группы репликации: когда последний раз синхронизировался, сколько файлов в очереди, есть ли конфликты. Видно всё, не нужно лезть в Event Log и угадывать.

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

Проблема с SYSVOL теоретически остаётся, но на практике она возникала реже, и сейчас мы мониторим. Если за ближайший месяц рассинхронизируется - будем думать про повышение функционального уровня домена; пока это избыточно.

Для сопровождения инфраструктуры клиентов ситуация с DFSR показательна: иногда правильный ответ на хронический инцидент - не лучший runbook для лечения симптома, а обновление компонента, в котором баг живёт. Жаль, что R2 вышел только сейчас, а не два года назад.