Windows Server 2003 R2 и DFS: единое пространство имён вместо алфавита сетевых дисков

У клиента с двумя офисами, связанными VPN, файловая инфраструктура выглядела так: в головном офисе - сервер с расшаренными папками, в филиале - второй сервер с теми же папками, скопированными вручную раз в неделю по расписанию через robocopy. Диски у пользователей подключены буквами: F: - документы головного, G: - локальная копия, H: - архив, который вообще непонятно где физически живёт. Системный администратор на вопрос «а где у нас договор от марта?» каждый раз делал паузу и начинал думать.

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

Именно под эту задачу мы стали смотреть на DFS в Windows Server 2003. А с выходом бета-версии R2 разговор стал предметным.

Что изменилось в R2

DFS в Windows Server 2003 был - но с репликацией там была история отдельная и не очень радостная. Репликация между серверами работала через старый FRS (File Replication Service), который использовался ещё для SYSVOL. FRS известен тем, что при определённых условиях (большие файлы, нестабильный канал, неудачный момент) мог войти в состояние, из которого выходил только ручным вмешательством. Или не выходил.

В R2 Microsoft представила новый движок - DFSR (DFS Replication). Это отдельный сервис с собственной базой данных состояния, дельта-компрессией, дросселированием полосы по расписанию и нормальными журналами. Репликация стала блочно-дельтовой: при изменении большого файла по сети идёт только изменённый блок, не весь файл целиком. Для офиса с каналом 2-4 Мбит/с - это принципиальная разница.

Namespace (пространство имён DFS) - это отдельная тема. Пользователь видит один путь, например \\company\files\contracts, и не знает, где физически лежит папка: на сервере в Москве или в Питере. DFS сам решает, куда направить запрос, основываясь на доступности и настроенных приоритетах.

Что проверить перед включением репликации

Вот здесь начинается то, о чём в пресс-релизах не пишут.

Первое - состояние данных на обеих сторонах. Перед настройкой DFSR нужно убедиться, что реплицируемые папки не содержат конфликтующих версий одного файла. DFSR при первоначальной синхронизации берёт одну сторону как «первичный» член и перезаписывает другую. Если на филиальном сервере накопились локальные правки, которых нет в головном, - они уйдут в специальную папку конфликтов (DfsrPrivate\ConflictAndDeleted), и достать их оттуда можно, но это уже ручная работа.

Второе - часовые пояса и время на серверах. DFSR использует временные метки для разрешения конфликтов: побеждает более поздняя версия. Если на серверах расходятся часы даже на несколько минут - конфликты будут разрешаться непредсказуемо. Синхронизация времени через NTP обязательна, причём ко всем серверам из одного источника.

Третье - размер staging-папки. DFSR хранит файлы в промежуточном хранилище (staging area) до подтверждения успешного приёма на другой стороне. По умолчанию размер этой папки - 4 ГБ. Если реплицируется папка с крупными файлами или первоначальная синхронизация большая, staging переполняется, репликация встаёт и начинает ругаться в журнале. Размер нужно выставить заранее с запасом под максимальный объём реплицируемых изменений.

Четвёртое - дросселирование полосы. DFSR умеет ограничивать скорость репликации по расписанию. Если этого не настроить, первоначальная синхронизация нескольких гигабайт поднимет канал между офисами в максимум и положит VoIP или сделает работу пользователей заметно медленней. Мы делаем так: ночью репликация без ограничений, в рабочее время - не больше 20-30% канала.

Пятое - открытые файлы. DFSR реплицирует файлы через VSS-снапшот, что снимает проблему заблокированных файлов. Но если файл открыт и активно пишется - реплицируется снапшот на момент начала, не актуальное состояние. Для большинства документов это нормально. Для баз данных или файлов приложений, которые работают без закрытия, - нет. Файловый режим 1С через DFS реплицировать не надо - это верный путь к повреждению базы.

Как выглядит пространство имён на практике

После настройки у пользователей в обоих офисах появился один сетевой путь - \\company\share. Внутри - привычная структура папок. Куда физически смотрит каждая папка - пользователю неважно. Пользователи в филиале работают с локальной репликой, без задержки через VPN. Если VPN упал - папки с локальной репликой остаются доступны.

Буква диска осталась одна - Z:. Предыдущие F:, G:, H: убрали через групповые политики. Первые два дня был небольшой хаос - люди привыкли к буквам. Потом привыкли к пути. Потом перестали думать об этом вообще, что и является целью.

Что ещё не проверяли

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

R2 требует, чтобы все серверы в репликационной группе были на R2. Старый WS2003 RTM или SP1 в группу не войдёт - придётся обновлять. Это надо учитывать при планировании, если серверов несколько.

Канал между офисами мы настраивали отдельно. Без стабильного VPN репликация будет вставать и нагонять - это не проблема DFSR, это вопрос к базовой связности.