Выполнение репликации DFS. Страж файлового дерева: развертываем распределенную файловую систему DFS

Технологии 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 (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 более подробно.

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

Назначение и возможности DFS

Распределенная файловая система DFS (Distributed File System ) появилась как
стандартный компонент еще в Win2k. Ее задача — облегчить управление, доступ и
поиск данных в сети. Для этого файловые ресурсы, находящиеся на разных
компьютерах, объединяются в единое логическое пространство имен. Пользователь,
вместо того чтобы запоминать имена всех общих сетевых ресурсов (Universal Naming
Convention, UNC), вроде \\Server\Folder, будет обращаться к единому пространству
UNC-имен, в котором объединены все серверы и общие ресурсы сети. А на каком
конкретно компьютере находится запрашиваемый файл, уже забота DFS , пользователю
не нужно беспокоиться о реальном расположении файла. При обращении клиента он
просто перебрасывается на нужный ему каталог. На месте источника, на который
указывает ссылка, может быть любая операционная система, к ресурсам которой
можно обратиться, используя UNC (Windows, Linux, xBSD, NetWare). Физические
объекты, связанные ссылками с DFS , называются целевыми объектами (targets) или
репликами (replics).

Но удобство для пользователей и администраторов — далеко не самое важное из
основных преимуществ DFS . Дело в том, что с одним логическим именем может быть
связано несколько общих ресурсов, в которых хранится идентичная информация.
Такой набор альтернативных общих ресурсов, связанных с одним логическим именем
DFS , называется набором реплик. И если общие ресурсы находятся в одном
пространстве доменного корня DFS и располагаются на серверах Win2k или Win2k3,
есть возможность настроить автоматическую синхронизацию информации между ними.
Пользователь, обратившийся к DFS , обычно перенаправляется к ближайшей реплике, и
если она не доступна, он будет перенаправлен к альтернативному ресурсу. Для
уменьшения нагрузки на сервер DFS на стороне клиента данные кэшируются, поэтому
при частом обращении к одному и тому же ресурсу каждый запрос к DFS не
производится. Таким образом, автоматическое резервирование важной информации ,
реализованное в DFS , еще и повышает отказоустойчивость всей системы (выход
одного сервера или дискового устройства не повлияет на работу пользователей).
Хотя следует помнить, что DFS не создавалась для работы часто с обновляющимися
данными, и особенно для тех случаев, когда файл одновременно может обновляться в
нескольких местах (в DFS остается та версия файла, где были внесены последние
изменения).

В реализации DFS в Win2k можно было разместить только одно пространство имен,
в Win2k3 их может быть уже несколько. В Win2k3 R2 появилась новая версия этой
системы — DFS Namespaces , в которой многие вопросы уже решены. За репликацию
данных в Win2k3 SP1 и SP2 отвечает FRS (File Replication Server ), в Win2k3 R2 —
DFS Replicatio n. Главным их отличием является то, что в FRS самым маленьким
объектом, подлежащим репликации, является файл, в DFS Replication используется
более развитая технология RDC (Remote Differential Compression ), которая умеет
копировать только изменившиеся части файла, а функция cross-file RDC меньше
нагружает канал при копировании новых файлов. Таким образом, использование DFS
еще и уменьшает нагрузку на сеть, что особенно актуально для удаленных офисов с
недостаточной пропускной способностью. В службе DFS не используется никаких
дополнительных средств обеспечения безопасности. При обращении к targets
проверяются только права доступа файловой системы и установленные для этих
объектов разрешения в каталоге Active Directory.

Эти разные корни

Начальной точкой для всех имен дерева DFS служит корень распределенной
файловой системы. Фактически корень — это некоторый общий ресурс, находящийся на
сервере, все остальные логические имена системы DFS будут подключаться как
следующий иерархический уровень. Корни в DFS могут быть двух видов, каждый
отличается способами хранения данных и возможностями. Изолированный (автономный)
корень (Standalone DFS ) не связан с Active Directory, и все ссылки на сетевые
ресурсы хранятся в реестре самого сервера DFS . Такой корень не использует
DFS
Replication , то есть не предполагает дублирование информации на другие ресурсы,
и поэтому не обеспечивает отказоустойчивость. При выходе из строя сервера DFS
вся иерархия становится не доступной, хотя пользователи могут обращаться к
ресурсам напрямую. К слову, несколько Standalone DFS серверов способны работать
в кластере, поэтому эта проблема может быть решена. Если сервер DFS является
членом домена, используется доменный корень (Domain-based DFS ). При таком
варианте можно подключать несколько реплик и использовать DFS Replication для
репликации как самого корня, так и ссылок DFS . Если в Domain-based DFS корни
находятся на компьютерах под управлением Win2k и Win2k3, то такой корень
называется "Mixed mode domain DFS ".

При доменном DFS вся информация о пространстве имен находится на контроллере
домена, к которому периодически обращается сервер DFS . Учитывая синхронизацию
между DFS в домене, которая становится все более сложной при каждом изменении
структуры, эти запросы могут быть узким местом в системе, поэтому в этом случае
также есть некоторые ограничения. Так в Win2k существовало ограничение на 16
корней для одного пространства имен. В Win2k3 это ограничение снято, так как
сервер DFS теперь может обращаться к любому DC, а не только к эмулятору PDC.
Второе ограничение доменных корней связано с тем, что вся структура хранится в
специальном объекте, который также необходимо дублировать на всех DC при любом
малейшем изменении в структуре DFS . В документации рекомендуется ограничивать
максимальный размер объекта 5-тью Мб, что приблизительно соответствует 5000
ссылкам (каталогам). Эта величина зависит от многих параметров, длины имени
ссылок, наличия и размера комментариев, которые также хранятся в этом объекте.
Но в среднем DFS редко когда превышает 50-100 ссылок, и после первоначальной
настройки она остается в основном статичной, а значит, часто дублироваться не
будет, и этих ограничений достигнуть просто не удастся. Кстати, в будущей
Windows 2008 ограничение в 5000 ссылок уже снято, но для этого все серверы
должны работать под управлением Longhorn. Для Standalone DFS рекомендованный
лимит ссылок на порядок выше и составляет 50000 ссылок .

Настройка DFS

Для примера настроим DFS на компьютере под управлением Win2k3 с SP2, все
настройки в SP1 аналогичны. В настройках DFS в R2 и Win2k есть некоторые
отличия, но не настолько глобальные, чтобы не разобраться самостоятельно. Все
управление распределенной файловой системой выполняется централизованно с
помощью оснастки MMC "Распределенная файловая система DFS ", которую можно
вызвать во вкладке "Администрирование" Панели управления Windows. С ее помощью
можно создавать и удалять корни, подключаться к любым корням DFS . Удобно, что в
одной вкладке может отображаться несколько корней DFS . В случае работы корня в "Mixed
mode domain DFS ", то есть когда реплики и корни DFS располагаются на компьютерах
под управлением разных версий Windows, управление DFS необходимо производить с
компьютера, работающего под Win2k3. Как вариант, можно установить пакет Win2k3 Administration Tools Pack (adminpak.msi), который лежит в свободном доступе на
сайте корпорации. В этом случае для управления можно использовать и компьютеры с
WinXP. Информацию по этому пакету найдешь по адресу

support.microsoft.com/kb/304718 . Кроме этого, для работы с DFS также можно
использовать утилиты командной строки dfscmd.exe и dfsutil.exe. Последняя имеет
больше возможностей, но по умолчанию не включена в состав операционной системы,
чтобы ее использовать, необходимо установить пакет Win2k3 Support Tools. Обрати
внимание, что для успешной установки Support Tools требуется скачать два файла:
suptools.msi и support.cab.

Для создания нового корня вызываем оснастку, щелкаем мышкой по заголовку и в
контекстном меню выбираем "Создать корень" (New Root), как вариант, можно
выбрать аналогичный пункт в меню "Действие". Появляется Мастер создания нового
корня (New Root Wizard), следуем его подсказкам. На втором шаге выбираем тип
создаваемого корня (доменный или изолированный), указываем несущий домен и
сервер. После проверки соединения с выбранным сервером вводим имя корня. Обрати
внимание, как будет выглядеть UNC путь к новому корню, по умолчанию \\server\nameshare.
Так как на данный момент общего каталога не существует, на следующем шаге нужно
выбрать локальный каталог, который будет использоваться в качестве общего. Этот
каталог не содержит реальных данных, в нем будут находиться ссылки, указывающие
на физическое расположение данных. Мастер создает ресурсы, разрешающие чтение и
выполнение членам группы Пользователи. При необходимости следует скорректировать
разрешения. Теперь нажимаем кнопку Готово, новый корень появится в окне консоли.
Если сервер работает под управлением Win2k3, аналогичным образом создаем и
другие корни. С помощью команды Проверить статус (Check Status), вызываемую из
меню консоли или контекстного меню, можно проверить состояние реплики. Состояние
будет указано в одноименном столбце и рядом с именем появится кружок с отметкой.
Если она зеленого цвета, значит, все нормально. Для проверки можно зайти по
указанному UNC или использовать на локальном компьютере команду «net share» или
«net view computer_name» с удаленного. Команда «dfsutil /Root:\\server\share /View»
покажет информацию о DFS .

>dfsutil /Root:\\server.com\first /View
DFS Utility Version 5.2 (built on 5.2.3790.3959)
Domain Root with 0 Links
Root Name="\\SERVER\first" Comment="first Root" State="1" Timeout="300"
Target Server="GRINDERS" Folder="first" State="2"

После создания корня его можно опубликовать в Active Directory. Для этого в
контекстном меню выбираем Свойства, переходим на вкладку Публикация и
устанавливаем флажок "Опубликовать этот корень в Active Directory". Доменные
корни публикуются автоматически и в обязательном порядке.

Создание ссылок

После создания корня можно начинать подключать общие ресурсы. Для чего в том
же контекстном меню выбираем пункт Создать ссылку (New Link). В появившемся окне
"Новая ссылка", в поле "Имя ссылки", вводим имя ссылки, под которым она будет
доступна в DFS, затем чуть ниже UNC-путь к целевому каталогу (должен уже
существовать). Для поиска общих ресурсов можно использовать кнопку Обзор, чуть
ниже можно изменить время кэширования этой ссылки для клиентов DFS (по умолчанию
1800 сек). По окончании нажимаем кнопку ОК. Команда «dfsutil /view» должна
показать состояние всех подключенных ссылок и их свойства. Если в сети работает
несколько серверов, есть возможность добавить реплику, указывающую на
альтернативную ссылку. Реплика на корень или отдельный объект создается
аналогично, только в первом случае в контекстном меню выбираем пункт "Создать
корневую целевую папку", а во втором – "Создать папку".

Общие ресурсы, с которыми будет производиться репликация, должны
располагаться в разделах с файловой системой NTFS на компьютерах, работающих под
управлением серверных версий Windows от 2000 (лучше 2003). В поле "Путь к
целевой общей папке" появившегося окна вводим или при помощи кнопки Обзор
указываем общий ресурс, располагающийся на другом компьютере. В том случае если
для синхронизации информации между этими ресурсами планируется использовать
альтернативные программы (или синхронизация будет производиться вручную),
следует снять флажок "Добавить эту целевую папку к набору репликации" (Add this
target to the replication set). Нажимаем ОК, и появляется Мастер настройки
репликации (Configure Replication Wizard), который поможет выбрать
мастер-реплику и топологию репликации. На первом шаге указываем каталог, который
будет использоваться в качестве основного целевого, вся информация из этого
каталога затем будет скопирована в другую папку. Последняя должна быть пустой,
если в ней есть файлы, они будут скопированы во временный каталог, а затем
удалены. Если общий ресурс по каким-либо причинам не подходит для репликации
(например, расположен не в разделе с NTFS), он будет отмечен красным крестиком,
при попытке перейти к следующему шагу мастер предложит указать другую ссылку или
закончить работу.

Нажатием кнопки "Промежуточное хранение " (Staging Folder ) можно изменить
расположение каталога, который будет использоваться для временного хранения
реплицируемых данных. По умолчанию этот каталог размещается в разделе, отличном
от того, на котором находится общий ресурс, связанный с DFS . Далее мастер
предложит выбрать топологию репликации. Необходимо будет указать один из
следующих вариантов:

Кольцо (Ring) - все реплики обмениваются информацией с двумя соседними;
Звезда (Hub and spoke) - указывается основная ссылка, с которой и будут
обмениваться информацией все остальные реплики;
Полная сетка (Mesh) - все реплики обмениваются друг с другом;
Особая (Custom) - позднее администратор самостоятельно настроит репликацию
для каждой пары серверов.

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

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

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

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

Для принудительной репликации информации, хранящейся на определенном сервере,
можно воспользоваться утилитой NtfrsUtl.exe, которая входит в состав пакета
Support Tools . Команда проста: «ntfrsutl poll /now server.com». Чтобы увидеть
установленные временные интервалы, через которые производится репликация,
следует ввести «ntfrsutl poll». Все установки доступны по команде «ntfrsutl sets
server.com».

В окне свойств общего ресурса, представленного в службе DFS , появится еще
одна вкладка – DFS . Открыв ее, пользователь может просмотреть, с какими общими
папками сопоставлена эта ссылка, проверить состояние реплики, выбрать активную
реплику, к которой он будет перенаправляться в первую очередь.

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

Чем хорошо использование пространства имен 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.

ReiserFS

Транзакции (журнализируемые файловые системы)

Обычно для увеличения скорости работы используются специальные механизмы кэширования операций чтения и записи.

Применяя в ОС оба типа кэширования позволяет разработчикам ЗНАЧИТЕЛЬНО ускорить операции ввода-вывода. Например, кэширование операций записи позволяет «собрать» множество операций ввода-вывода в единый пакет изменений и за одно-два обращения к диску (в моменты меньшей загрузки) их записать.

Однако хранение в памяти незаписанной на диск информации в памяти опасно – в случае сбоя потеряется информация и нарушится логическая структура файловой системы. Проверка файловой системы после сбоя может занять много времени. Например, проверка 8 гигабайт файловой системы ext2fs занимает 15-20 минут (тестовое оборудование 1999г.в.).

Поэтому используют специальные журналы операций – в них записывается информация сразу. Если происходит сбой, то происходит проверка на основании этого журнала, при этом обеспечивается высокая скорость проверки и восстановления – в среднем не более 30 секунд(на примере раздела в 12Гб, оборудование 2003-2006г.в.).

Файловая система ReiserFS оказалась для Linux исторически первой - она поддерживается ядром, начиная с первых версий ветви 2.4.x и была единственной, разработанной "с нуля" специально для этой ОС Хансом Райзером. Как и в большинстве таких систем здесь осуществляется журналирование только операций над метаданными файлов. Кроме этого, ReiserFS обладает уникальной возможностью оптимизации дискового пространства, занимаемого мелкими файлами - они целиком хранятся в своих inode, без выделения блоков в области данных и вместе с экономией места это способствует и росту производительности, так как данные и метаданные хранятся в непосредственной близости и могут быть считаны одной операцией ввода/вывода. Другая особенность ReiserFS - хвосты файлов меньше чем один блок могут быть подвергнуты упаковке (режим тайлинга). Это обеспечивает около 5% экономии дискового пространства.

В отличие от ReiserFS, ext3fs - не более чем журналируемая надстройка над классической ext2fs, разработанная в компании Red Hat и поддерживаемая ядром Linux, начиная с 2.4.16. Как следствие такого происхождения, она сохраняет со своей прародительницей полную совместимость, в том числе и на уровне утилит обслуживания. Другое преимущество - чуть ли не максимальная надежность: ext3fs является системой, в которой возможно журналирование операций не только с метаданными, но и с данными.

В ext3fs предусмотрено три режима работы: полное журналирование (full data journaling), журналирование с обратной записью (writeback), а также задействуемое по умолчанию последовательное (ordered). В первом случае все новые данные сначала пишутся в файл журнала и только после этого фиксируются на диске. В случае аварийного отказа можно повторно перечитать журнал, приведя данные и метаданные в непротиворечивое состояние. Этот механизм практически гарантирует от потерь данных, однако является наиболее медленным. В режиме с обратной записью в файл журнала записываются только изменения метаданных и никакой гарантии сохранности данных он не предоставляет, однако обеспечивает наибольшее (в рамках ext3fs) быстродействие. В последовательном режиме также физически журналируются только метаданные файлов, однако, связанные с ними блоки данных логически группируются в единый модуль, называемый транзакцией. И эти блоки сохраняются перед записью на диск новых метаданных, что, хотя и не гарантирует полной сохранности, но весьма способствует ей.

Файловая система XFS, в отличие от «молодых» ReiserFS и ext3fs, развивается на протяжении более десяти лет - впервые она появилась для версии Irix 5.3 в 1994 г. XFS - 64-разрядная файловая система. Особенностями XFS являются:

механизм allocation group - деление единого дискового раздела на несколько равных областей, имеющих собственные списки inodes и свободных блоков, для распараллеливания дисковых операций;
логическое журналирование только изменений метаданных, но с частым сбросом их на диск для минимизации возможных потерь при сбоях;
механизм delayed allocation - ассигнование дискового пространства при записи файлов не во время журналирования, а при фактическом сбросе их на диск, что, вместе с повышением производительности, предотвращает фрагментацию дискового раздела;
списки контроля доступа (ACL, Access Control List) и расширенные атрибуты файлов (extended attributes) .

XFS очень сбалансированная файловая система - она почти столь же надежна, как ext3fs, и не уступает ReiserFS в быстродействии на большинстве файловых операций. А при манипуляциях с очень большими файлами XFS вне конкуренции. Не отмечалось для нее и проблем с совместимостью.

NTFS является восстанавливаемой (recoverable) файловой системой. Она гарантирует согласованность данных тома, используя стандартную процедуру регистрации транзакций. Каждая операция ввода-вывода, которая изменяет файл на томе NTFS, рассматривается файловой системой как транзакция.

При модификации файла специальная компонента файловой системы - сервис регистрации файлов (Log File Service) - фиксирует всю информацию, необходимую для повторения или отката транзакции в специальном файле с именем $LogFile. Если транзакция не завершается нормально, то NTFS пытается закончить транзакцию (повторить) или производит ее откат. Этот метод обеспечивает минимальное время восстановления, однако восстанавливаются только системные данные (метаданные), пользовательские же данные могут быть утеряны.

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

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

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

Есть три варианта репликации показанные на рисунке:

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

б) Ленивая репликация файла. Здесь создается только одна копия каждого файла на некотором сервере. Позже сервер сам автоматически выполнит репликации на другие серверы без участия программиста. Эта система должна быть достаточно быстрой для того, чтобы обновлять все эти копии, если потребуется.

в) Репликация файла, использующая группу. В этом методе все системные вызовы ЗАПИСАТЬ передаются одновременно на все серверы, таким образом копии создаются одновременно с созданием оригинала.

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

Существует проблема отслеживания изменений и репликация их на другие сервера. Существует несколько хорошо известных алгоритма решения этой проблемы:

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

Чтобы предотвратить ситуацию, когда из-за отказа первичный сервер не успевает оповестить об изменениях все вторичные серверы, изменения должны быть сохранены в постоянном запоминающем устройстве еще до изменения первичной копии. В этом случае после перезагрузки сервера есть возможность сделать проверку, не проводились ли какие-нибудь обновления в момент краха. Недостаток этого алгоритма типичен для централизованных систем - пониженная надежность.

Чтобы избежать его, используется метод, предложенный Гиффордом и известный как "голосование". Пусть имеется n копий, тогда изменения должны быть внесены в любые W копий. При этом серверы, на которых хранятся копии, должны отслеживать порядковые номера их версий. В случае, когда какой-либо сервер выполняет операцию чтения, он обращается с запросом к любым R серверам. Если R+W > n, то, хотя бы один сервер содержит последнюю версию, которую можно определить по максимальному номеру. Этот метод требует наличия у каждого файла специального числа – «версия».

Интересной модификацией этого алгоритма является алгоритм "голосования с приведениями". В большинстве приложений операции чтения встречаются гораздо чаще, чем операции записи, поэтому R обычно делают небольшим, а W - близким к N. При этом выход из строя нескольких серверов приводит к отсутствию кворума для записи. Голосование с приведениями решает эту проблему путем создания фиктивного сервера без дисков для каждого отказавшего или отключенного сервера. Фиктивный сервер не участвует в кворуме чтения (прежде всего, у него нет файлов), но он может присоединиться к кворуму записи, причем он просто записывает в никуда передаваемый ему файл. Запись только тогда успешна, когда хотя бы один сервер настоящий.

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