Технологии Distributed File System (DFS) Replication (она же DFS-R, она же DFSR) уже много лет. Тем не менее в наших головах о ней существует множество мифов заблуждений. Как только речь заходит о DFS, сразу кто-то что-то да скажет этакое, и начинается спор: это не работает, это не поддерживается, то глючит.

И как всегда истина в простоте: чем более замысловатый сценарий мы выдумываем, тем больше шансов получить проблемы.

По сути путаница происходит из-за того, что за DFS-R скрывается две основные технологии: первая – виртуальное пространство имен и вторая – репликация.

Виртуальное пространство имен

1. Это очень удобно. Множество файловых шар можно объединить в единое дерево имен. Если нужно заменить сервер или перенести шару в другое место, для пользователей ничего не меняется, а у администратора практически развязаны руки. К тому же упрощаются процессы организационного характера: единый ресурс, единый хозяин, единая политика управления.

2. Это надежно. Корень DFS может располагаться на нескольких домен-контроллерах. Фактически в этом моменте DFS можно считать абсолютно не убиваемой: если уж откажут все основные домен-контроллеры, то не только DFS, но и вообще ничего не будет работать.

Репликация

Репликация работает не только вместе с DFS, но и самостоятельно: ничто не мешает реплицировать информацию с одного сервера на другой или на несколько.

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

Сценариев использования репликации может быть много, но именно понимание работы BITS является ключевым при использовании репликации в DFS-R.

Добавляем репликацию к DFS

1. Пока у виртуальной папки существует только один таргет (Target), т.е. реплика одна – абсолютно все технологии поддерживают работу в DFS. Это касается перемещаемых профилей (roaming profiles), домашних папок (Home folders), офлайн файлов (Offline files) и переадресации папок (Redirection Folders).

2. Если виртуальная папка имеет не одну реплику, а две или несколько, то вот тут и начинаются ограничения, а при их несоблюдении – появляются ошибки, глюки и всяческие «чудеса». Все перечисленные выше технологии не поддерживаются в подобном сценарии.

Обычная ошибка в использовании DFS-R – сделать несколько реплик и разрешить редактирование файлов. В этом случае есть несколько копий одного файла и копии могут редактироваться одновременно. Это не всегда ошибка, но чаще всего это все же ошибка. Не ошибка, когда допускается независимое редактирование частей файла – это встречается редко и должно быть хорошо продумано перед использованием. Например, обычный текстовый файл такое переживет. А вот любой документ Office это zip-архив, и невозможно реплицировать изменения его содержания: кто последним сохранит изменения, тот и победит. Еще худший вариант, когда частичная репликация файла может вообще нарушить целостность данных. Аналогичная ситуация с перемещаемыми профилями: они не поддерживают частичную репликацию изменений DFS-R.

Так что же DFS-R не совместима с Office документами? Нет, просто надо выбрать правильный сценарий. Вот пример.

Делаем центральный хаб-сервер и собираем на него с других файловых серверов-источников информацию. В виртуальное пространство имен включаем несколько реплик: одна на хабе, другая на файловом сервере-источнике, но все шары являются Read Only.

Как же редактировать информацию? Очень просто: надо сделать на каждом сервере-источнике еще шару на те же папки с файлами, но уже с разрешением на редактирование. Такие шары можно использовать непосредственно, либо включить в отдельную ветку виртуального пространства имен, но только как одну реплику.

Существуют другие нюансы при работе с DFS-R, большинство из них хорошо описаны в документации.

Как уже говорилось, структуру DFS можно сделать отказоустойчивой. Каждую ссылку можно продублировать, создав вторую ссылку на аналогичный сетевой ресурс на другом компьютере. В результате при недостижимости одного ресурса клиенты будут автоматически перенаправлены к функционирующему компьютеру. Причем система может автоматически синхронизировать эти ресурсы. Если данные будут изменены в папке по одной ссылке, то в папке по другой ссылке они будут продублированы.

Реплицируемые ресурсы должны быть расположены в папках с NTFS 5.0, поскольку система использует систему протоколирования этой файловой структуры для отслеживания изменений.

Примечание Если необходимо использовать ограничения прав доступа к документам в папках DFS, то эти настройки следует применить только к папкам сервера (\\<имя_сервера>\ <имя_папки>). Иначе при создании ссылки DFS по новому месту репликации папка унаследует права родительской структуры.

По умолчанию репликация не включена. Чтобы организовать синхронизацию данных нескольких серверов, необходимо выделить соответствующие ссылки на ресурсы и выбрать команду Синхронизовать. При создании репликации требуется указать, какой ресурс будет являться основным (мастером). Когда первоначальная репликация завершится, все ссылки станут равнозначными: изменение в одном месте повлечет изменение по другой ссылке.

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

Автоматически синхронизируются не все файлы. Из репликации исключаются временные файлы (список расширений можно просмотреть в настройках). Сами файлы реплицируются только после того, как с ними завершена работа пользователя. Иными словами, если пользователь открыл файл и работает с ним в течение всего дня, то копия файла по реплицируемой ссылке изменится только после завершения работы - вечером.

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

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

Настраивается график репликации в задаче AD Пользователи и компьютеры. Открыв оснастку, следует включить отображение дополнительных функций (Вид | Дополнительные функции) и найти необходимый корень DFS. Открыв его свойства на вкладке Набор репликации, нужно нажать кнопку Изменить расписание и отредактировать график (рис. 10.2).

Рис. 10.2. Настройка графика репликаций DFS

Чем хорошо использование пространства имен DFS? Тем, что все ресурсы для пользователей лежат в одном едином каталоге, который не привязан к именам серверов и все вопросы касающиеся физического расположения файловых ресурсов не касаются пользователей. Для них путь до рабочей папки всегда остается неизменным. Еще DFS позволяет использовать репликацию данных между несколькими сетевыми папками и равномерное распределение пользователей между файловыми серверами.

Есть некая программа, которая использует базу данных и файловую папку. В базе – пути до файлов, файлы соответственно, в сетевой папке.

Папка суммарно размером более терабайта, файлов много. Файлы являют собой сжатый звук и иногда имеют не маленькие размеры.

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

Отказоустойчивость базы данных достигнута посредством использования функционала Always On Availability Groups на MS SQL 2012.

Отказоустойчивость сетевой папки проще всего достигнуть посредством репликации папки средствами DFS.

Отдельно хочу заметить, что коренную папку пространства имен DFS (DFS root) тоже необходимо защитить от отказа. В Windows Server 2008 и выше это достигается без использования технологий кластеризации. Просто после создания корня, добавляем еще один сервер пространства имен. Например – два контроллера домена, они же серверы пространства имен DFS. В случае перезагрузки или поломки одного из них, пользователи продолжат пользоваться пространством имен DFS и ни чего не заметят.

И так, создаем коренную папку DFS. Создаем виртуальную структуру папок для отделов компании. В папках отделов создаем папки указывающие на конечные файловые ресурсы на файловых серверах.

Теперь переходим к настройке репликации DFS для нужной нам папки.

Для включения репликации нам нужно заранее установить на сервера где будет находиться папка, роль “Репликация DFS” (DFS replication) и Компонент “Удаленное разностное сжатие” (Remote Differential Compression).

Затем, заходим в MMC консоль “Управление DFS” (DFS Management), выбираем папку и запускаем мастер репликации:
Указываем сервер:

Папку назначения:
Создаем группу репликации:

Выбираем сервер с основной копией данных (это актуально на время первичной репликации):

Выбираем топологию (если сервера два, то вариантов нет):
Можем выбрать скорость репликации и расписание:

Заканчиваем:
Теперь ждем завершения первичной синхронизации.

И так, репликация настроена, потираем руки и в течение суток получаем жалобу, что папки на серверах отличаются, а значит репликация не работает.

Тратим кучу времени на сравнение папок и копируем вручную отличающиеся куски информации.

Собственно поэтому не любят использовать репликацию DFS.

Всё произошло потому, что ни кто не читал руководство настройке DFS. Как я сказал, папка занимает около терабайта. Там множество файлов, с которыми работают пользователи посредством программы.

Репликация папки происходит путем использования скрытого каталога DfsrPrivate\Staging, а там задействован механизм квот. Квота кэша репликации (Staging Folder) или “Промежуточной квоты” по умолчанию равна 4 гигабайта, что катастрофически мало при объемах данных указанных выше. Потому не работает репликация.

Как повышать? Гадать не наш метод. Смотрим что пишут на Technet .

2003 сервер – Staging quota должна быть размером в девять самых больших файлов в папке репликации.

2008 и 2008 R2 – Staging quota должна быть размером в 32 самых больших файлов в папке репликации.

Тут нам поможет PowerShell.

Пишем команду (заменяем <путь> на путь до нужной папки):

“{0:N0}” -f((get-childitem <ПУТЬ> -recurse | sort-object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb)

Получаем суммарный объем 32-х самых больших файлов в гигабайтах, округленный до целого. Идем в настройки репликации:

Применяем. Как вариант, увеличиваем еще и квоту для конфликтов и удаленных файлов.

Не забываем повторить настройку для второго сервера.

P.S: В моём случае, DFSR оказалась не применима, так как приложение выбирает мастера из рабочих машин, где запущено, путём изменения определенного файла, который лежит в файловом хранилище, вместе с данными приложения. Файл обновляется чаще чем раз в секунду незначительной информацией. В файл пишется время и имя машины-мастера. В итоге файл обновляется одновременно на всех серверах и репликация его не проходит, так как DFSR не может определить какая версия файла правильная. В добавок несколько машин одновременно считают себя мастером операций, что приводит к проблемам в приложении.
Если бы разработчики придерживались идеи “сервер-свидетель” и вынесли файл на отдельный ресурс, не совмещая его с данными приложения, то смогли бы сэкономить десятикратно на упрощении аппаратной инфраструктуры.
В итоге придется держать папку с помощью MSFT-кластера или Fault Tolerance в VSphere.

Набор альтернативных общих ресурсов, связанных с одним логическим именем DFS, называется набором реплик. В зависимости от того, в каких условиях работает распределенная файловая система, синхронизация реплик в наборе осуществляется различными методами. Распределенная файловая система сама не пытается проанализировать, отличаются ли данные, находящиеся на различных репликах. Их идентичность должна быть достигнута с помощью сторонних средств. Если альтернативные общие ресурсы созданы в файловой структуре с автономным корнем DFS, автоматическая репликация становится невозможна. В этом случае синхронизация данных между членами набора реплик должна выполняться вручную. Если альтернативные общие ресурсы находятся в пространстве имен доменного корня DFS и располагаются на серверах Windows 2000 или Windows Server 2003, то для них можно настроить автоматическую синхронизацию (репликацию) информации.

Для того чтобы настроить репликацию между альтернативными ресурсами (репликами), связанными с доменным корнем или ссылками DFS:

Рис. 8.33. Окно настройки репликации альтернативных общих ресурсов

2. Нажав кнопку Customize, вы сможете перейти в окно настройки топологии репликации, где можно управлять соединениями между серверами и их приоритетами.
3. Кнопка Schedule позволяет открыть окно, в котором указывается время репликации. По умолчанию репликация разрешена круглосуточно 7 дней в неделю.
4. В поле File filter перечислены (групповые) имена файлов, которые исключены из процесса репликации. Нажав кнопку Edit, можно изменить этот перечень.
5. В поле Subfolder filter перечислены папки, не участвующие в репликации. Если вам нужно запретить репликацию для каких-то папок, нажмите кнопку Edit и введите нужные имена.
По завершении конфигурации репликации данные, находящиеся на общих ресурсах, входящих в набор реплик, будут периодически синхронизироваться. По умолчанию период синхронизации равен 15 мин. Настроив репликацию, можно проверить ее текущее состояние с помощью команды Check status из контекстного меню. Результат проверки может зафиксировать одно из трех состояний:

• процесс репликации завершен нормально - на значке ссылки DFS и на значках реплик появятся зеленые галочки (см. рис. 8.31);
• реплика недоступна - около имени реплики появляется крестик в красном кружке (статус - Offline) (рис. 8.34);
• некоторые альтернативные реплики проверяемой ссылки недоступны - на значке ссылки DFS появляется характерный восклицательный знак в желтом треугольнике.

Решил немного обобщить опыт использования этой технологии(в нескольких частях).

Зачем?

DFS (Distributed File System) — распределенная файловая система, компонент Microsoft Windows Server, использующийся для упрощения доступа и управления файлами, физически распределёнными по сети. При её использовании файлы, распределённые по серверам, представляются пользователям находящимися в одном месте. Это служба, которая позволяет решить несколько задач:

• Упростить доступ к файлам и папкам, которые находятся в разных местах, на разных серверах, в разных офисах. Это самая главная функция DFS. С помощью т.н. «корня» пользователи не задумываются, где находятся те или иные данные, а просто вводят одно и то же имя, например \\hq.com\doc.
• Несмотря на единый «корень», разные или одни и те же данные можно сгруппировать с помощью нескольких адресных пространств. Например, пути \\hq.com\docs или \\hq.com\branchdocs могут содержать как разные, так и повторяющиеся данные.
• Повысить отказоустойчивость, за счет репликации корня на несколько серверов, использования AD как места хранения корня и репликации самих данных между разными серверами.
• Понизить нагрузку на конкретный файловый сервер, распределив данные и доступ к часто используемым ресурсам между несколькими серверами.
• Облегчить резервное копирование и поиск данных. Например, администратор может создать пространство имен \\hq.com\backups, где будут находиться все сетевые каталоги для резервного копирования. И путь в DFS можно указывать как программам резервного копирования, так и для поиска данных. При поиске в DFS не нужно искать файл на каждом сервере отдельно.

Как?

Для решения этих задач DFS использует:

• DFS-N (Namespace) – служба пространства имен DFS
• DFS-R (Replication)- служба репликация DFS.

DFS-N — служба поддерживающая виртуальное дерево каталогов, которые ссылаются на реальные сетевые каталоги(целевые каталоги или target ). Эта наиболее «полезная» служба DFS, предоставляющая возможность использовать единый корень для доступа к данным. DFS-N возвращает клиенту UNC-ссылку на реальный сетевой ресурс(\\имя сервера\имя сетевого каталога), просто пользователь этого не видит и не задумывается, где находятся файлы. Возвращаемая UNC-ссылка зависит от местоположения пользователя, и если он вдруг переместился в филиал, то DFS автоматически выдаст ссылку на «местный» сервер.

Пространство имен DFS может быть реализовано двумя способами:

• Распределенная файловая система с изолированным корнем(Standalone);
• Доменная распределенная файловая система(Domain- based);

В случае Standalone (замечу, что такой вариант может быть и в домене AD) доступ к пространству имен осуществляется через путь \\Server_name\DFS_root, данные хранятся в реестре и поддерживается только одно пространство имен(корень), AD не требуется.

DFS-R — это служба предоставляющая репликацию данных между серверами. Т.е. если задана репликация какой либо сетевой папки между ServerA и ServerB, то служба будет с заданным интервалом реплицировать данные между папками. В конечном итоге все файлы измененные или созданные на ServerA будут прореплицированны в соответствующую папку на ServerB(и наоборот). Данная служба вызывает самое большое количество недопонимания среди новичков. DFS-R может быть полезна только в нескольких сценариях, таких как:

• Совместная работа с данными в филиале и головном офисе.
• Создание копии документов филиала в головном офисе.

Служба DFS-R — не замена резервному копированию или кластеру!!! Поэтому не используйте ее в таком качестве и у вас не будет проблем с DFS-R. Не располагайте базы данных в реплицируемых папках! Однако вы можете объединить папки с базы данных в одном корне.

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

Реплицировать можно отдельные папки или корень целиком(и даже целые диски, если сделать их общими). Корень лучше не реплицировать, поскольку вы потеряете в функциональности и гибкости. DFS-R хорошо использовать для данных, которые не изменяются(PDF-файлы, программы). Или для отказоустойчивости, когда один партнер по репликации работает в режиме «только чтение». Т.е. если основной файловый сервер вышел из строя, то пользователи смогут открыть документы и работать с ними. Сохранить документы на этот сервер они не смогут, но и работа в офисе не остановится.

В следующей части мы рассмотрим терминологию DFS более подробно.