Служба репликации dfs. Управление репликацией DFS. Сведения об исправлении

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

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

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

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

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

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

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

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

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

Рис. 10.2. Настройка графика репликаций 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 Replication . И хотя сам рассматриваемый вопрос не нов, набить на нем шишки могут многие.

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

Для примера я сделал тестовую среду, в которой всего два сервера - LAB-DC1 и LAB-FS1 . На каждом из них есть папка C:\DFSR , между которыми и должна проходить репликация.

Копируем в эту папку на LAB-DC1 два тестовых файла и видим, что на второй сервер отреплицировался только один.

Почему?

Потому что механизм DFS Replication устроен так, что by design не копирует файлы, у которых установлен атрибут Temporary . Воспользуемся командой fsutil и посмотрим, какие атрибуты имеют оба наших файла.

Файл not-a-temporary-file.txt имеет атрибуты 0x20 :

Файл temporary-file.txt имеет атрибуты 0x120 :

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

Снять данный атрибут со всех вложенных файлов и папок очень просто с помощью маленького PowerShell -скрипта:
Get-ChildItem C:\DFSR -recurse | ForEach-Object -process {if (($_.attributes -band 0x100) -eq 0x100) {$_.attributes = ($_.attributes -band 0xFEFF)}}

Снимаем атрибут и вуаля! Наш «проблемный» файл temporary-file.txt успешно скопировался на удаленный сервер:

Откуда в сети берутся «временные» файлы - история умалчивает. У меня откуда-то появились. Для того, чтобы поэкспериментировать, можно установить для файла атрибут «Temporary» руками. Для этого тоже можно воспользоваться простым PowerShell -скриптом:
$file = Get-Item C:\DFSR\temporary-file.txt $file.Attributes = 0x120

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

Напоследок хочется сказать спасибо Крэгу Лэндису, который в далеком 2008-м году опубликовал у себя в блоге исчерпывающую

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 пытается закончить транзакцию (повторить) или производит ее откат. Этот метод обеспечивает минимальное время восстановления, однако восстанавливаются только системные данные (метаданные), пользовательские же данные могут быть утеряны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Распределенная файловая система DFS (Distributed File System) – это технология, обеспечивающая возможности упрощения доступа к общим файловым ресурсам и глобальной репликации данных. Благодаря DFS распределённые по различным серверам общие ресурсы (каталоги и файлы) можно объединить в единую логическую UNC структуру, которая для пользователя выглядит, как единый сетевой ресурс. Даже при изменении физического местоположения целевой папки, это не влияет на доступ пользователя к ней.

Реализация служб DFS в Windows Server 2012 отличается от предыдущих версиях Windows. В первую очередь отметим, что технологии DFS в Windows Server 2012 реализованы в виде двух отдельных, независимых друг от друга служб — DFS Namespaces и DFS Replication , включенных в роль файлового сервера (File and Storage Services ).

• DFS Namespaces (DFSN или DFS-N) – пространство имен DFS. Позволяет объединять в единую логическую структуру общие папки, расположенные на различных серверах организации. Каждое пространство имен для пользователя выглядит как единая сетевая папка с подкаталогами. Реальная структура данного пространства имен DFS является скрытой от пользователя, и может включать в себя различные сетевые папки, расположенные на различных серверах и сайтах.
• DFS Replication (DFSR или DFS-R) — служба DFS репликации. Позволяет организовать эффективную службу репликации каталогов (в том числе включенных в пространство имен DFS) между различными серверами и сайтами AD. Данная служба для репликации использует специальный алгоритм удаленного разностного сжатия – RDC- remote differential compression. Благодаря RDC, которая отслеживает изменения в файлах, при репликации копируются не файлы целиком (как в случае с FRS репликацией), а только их блочные изменения.

Установка служб DFS в Windows Server 2012

Установить службы DFS можно с помощью консоли Server Manager или же при помощи Windows PowerShell.

Как мы уже говорили, службы DFS являются элементами роли Files and Storage Services :

Но проще и быстрее установить все DFS службы и консоль управления DFS с помощью PowerShell:

Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con

Совет . Естественно, службы и консоль управления DFS можно установить и по отдельности.

Где FS-DFS-Namespace – служба DFS Namespaces

FS-DFS-Replication – служба репликации DFS Replication

Настройка пространства имен DFS в Windows Server 2012

Перейдем к описанию процедуры настройки пространство имен DFS, для чего необходимо открыть панель управления DFS Management tool .

Создадим новое пространство имен (New Namespace ).

Необходимо указать имя сервера, который будет содержать пространство имен (это может быть как контроллер домена, так и рядовой сервер).

Затем следует указать имя создаваемого пространства имен DFS и перейти в расширенные настройки (Edit Settings).

Здесь следует указать имя пространства имен DFS и права доступа к данному каталогу. Обычно рекомендуется указать, что доступ к сетевой папке разрешен Всем (Everyone), в этом случае права доступа проверяются на уровне файловой системы NTFS.

Далее мастер предложит указать тип создаваемого пространства имен. Это может быть Domain-based namespace (доменное пространство имен) или Stand-alone namespace (отдельное пространство имен). Domain-based namespace обладает ряд преимуществ, но для его работы нужен, собственно домен Active Directory и права администратора домена (либо наличие делегированных прав на создание доменных пространств имен DFS).

После окончания работы мастера в ветке Namespaces консоли управления DFS появится созданное нами новое пространство имен DFS. Чтобы пользователи при доступе к DFS каталогам видели только те каталоги, к которым у них имеется доступ, включим для данного пространства DFSAccess-Based Enumeration (подробнее о данной технологии в статье ). Для этого откройте окно свойств созданного пространства имен.

И на вкладке Advanced включите опцию Enable access-based enumeration for this namespace .

Чтобы посмотреть содержимое нового пространства DFS, просто наберите в окне проводника UNC путь: \\имя_домена_или_сервера\DFS

Добавление дополнительного DFS сервера

В доменное пространство имен DFS можно добавить дополнительный сервер (пункт меню Add Namespace Server), который его будет поддерживать. Делается это для увеличения доступности пространства имен DFS и позволяет разместить сервер пространства имен в том же сайте, в котором находится пользователи.

Примечание . Отдельно стоящие пространства имен DFS поддерживают только один сервер.

Добавление нового каталога в существующее пространство имен DFS

Теперь нужно добавить новый сетевой каталог в иерархию созданного нами пространства имен DFS. Нажмите кнопку Add Folder Target .

Укажите наименование каталога в DFS пространстве и его реальное местоположение на существующем файловом сервере (Folder targets ).

Настройка DFS-репликации на Windows Server 2012

Технология репликации DFS-R предназначена для организации отказоустойчивости пространства имен DFS и балансировки нагрузки между серверами. DFS-R автоматически балансирует трафик между репликами в зависимости от их загрузки и в случае недоступности одного из серверов перенаправляет клиентов на другой сервер-реплику. Но прежде, чем говорить о DFS репликации и ее настройке в Windows Server 2012перечислим основные системные требования и ограничения:

• Служба DFS Replication должна быть установлена на всех серверах, которые планируется включить в группу репликации
• Все сервера в группе репликации должны находиться в одном лесу AD
• Уровень леса Active Directory должен быть как минимум Windows Server 2003 R2 (при установке первого домена контроллера на Windows Server 2012 ).
• Функциональный уровень домена — как минимум Windows Server 2008
• Необходимо убедиться, что антивирусное обеспечение на файловых серверах совместимо с технологией репликации DFS
• Реплицируемые каталоги должны располагаться на томах с файловой системой NTFS (файловые системы и FAT не поддерживаются). Также не поддерживается репликация данных, хранящихся на on Cluster Shared Volumes

В консоли DFS Managment выберите нужный вам DFS Namespace и щелкните ПКМ по каталогу, для которого необходимо создать реплику и выберите пункт Add Folder Target .

И укажите полный (UNC) путь к сетевому каталогу другого сервера, в котором и будет храниться реплика.

На вопрос хотите ли вы создать группу репликации отвечаем Yes.

Запускается мастер настройки репликации. Проверяем имя группы репликации и каталог.

Указываем первичный (Primary ) сервер. Именно этот сервер будет источником данных при инициальной (первичной) репликации.

Затем выбираем тип топологии (соединения) между членами группы репликации. В нашем примере выбираем Full Mesh (все со всеми).

И, наконец, указываем расписание репликации и параметры bandwidth throttling – ограничение доступной для репликации полосы пропускания.

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

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