Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания.
Возникает вопрос- чем же эта функция по сути отличается от пространства имен DFS? Основное ее отличие- это наличие функции Алгоритма дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации. Тем самым наиболее предпочтительней использовать репликацию DFS в медленных сетях, например для репликации одной (нескольких) папок между удаленно расположенными офисами с медленными каналами.
Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась.
Рассмотрим пошаговую инструкцию настройки репликации DFS. Первое что необходимо сделать - .
После этого создаем группу репликации (группа репликации - это набор серверов, именуемых членами, которые участвуют в репликации одной или нескольких реплицируемых папок. Реплицируемая папка - это папка, для которой поддерживается синхронизация на каждом из членов), для этого нажимаем правой кнопкой мыши на «Репликации»
, выбираем «Новая группа репликации…»
В типе реплицируемой группе репликации, рекомендую указать «Универсальная группа репликации»
, поскольку этот тип является более гибким в использовании в дальнейшем.
В следующем окне указываем имя группы репликации, пишем комментарий (по желанию) и смотрим тот ли домен используется (если в вашей организации используется несколько доменов).
Для того что бы запустить репликацию вручную, необходимо нажать на репликацию, в данном примере "Сommon" , затем зайти во вкладку "Подключения" и нажав правой кнопкой на любом подключении выбрать "Реплицировать сейчас" .
Технологии 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, большинство из них хорошо описаны в документации.
Q зачем нужна DFS?
A для организации единого структурированного отказоустойчивого файлопомоечного пространства в организации. вместо зоопарка непонятных шар и дисков имеем единый корень (который можно мапить пользователям как диск, например), в котором мы можем создавать удобную нам структуру в виде виртуальных папок (хоть вложенных, хоть вперемешку с реальными), к которым, в удобном нам виде, мы и цепляем сетевые шары, физически расположенные на разных серверах. люди, человеки, один сетевой диск - это пипец как удобно по сравнению с колхозом, что есть у большинства!
Q интегрировать ли пространство имен в Active Directory (Domain Based DFS Namespace) или использовать автономные (stand-alone DFS namespace)?
A
интегрированное пространство имен DFS хранится в AD (бэкапится, соответственно, "за компанию". вы ведь делаете резервные копии Active Directory? ;) и позволяет иметь несколько namespace серверов, т.е. имеет встроенный механизм отказоустойчивости (fault tolerance). Stand Alone DFS NS встроенных механизмов не имеет (отказоустойчивость в них достигается с помощью использования кластеризации). Microsoft рекомендует использовать domain based DSF в случае, если количество линков (виртуальных папок) не больше 5,000. Stand Alone DFS же рекомендуют ограничивать 50,000 линков. это не жесткое ограничение, это рекомендации (после превышения цифры, вроде как должна начать падать производительность). т.е. в итоге получаем, что stand alone выгодно использовать в маленькой сети, например, если нет AD или, наоборот, в случае экстремально большой файлопомойки, в остальных же случаях выгоднее использовать интегрированное пространство имен DFS.
PS: еще некоторые несознательные буржуи пишут "Standalone DFS root do not have any DFS shared folders in the root level and only one level of DFS link is possible", но я не совсем понимаю что это означает.
Q какие механизмы отказоустойчивости в domain based DFS?
A информация корня DFS хранится в Active Directory (в случае, если у вас нескольких контроллеров домена резервирование получается и тут) и реплицируется на серверы пространств имен DFS (которых тоже может быть много). линки (вируальные папки, которые вы создаете в DFS Root и к которым монтируете физические шары) могут иметь несколько (не обязательно 2, можно и больше) источников-шар, данные в которых реплицируются между собой.
Q что такое репликация DFS и какая она бывает
A
механизм синхронизации содержимого нескольких источников DFS.
бывает: FRS
(File Replication Service) - обычная репликация;)
DFSR
(Distributed File System Replication) - модная репликация, появившаяся в Windows Server 2003R2 и 2008. использует RDC (разностное сжатие, т.е. передается только изменения в файле, а не изменившийся файл целиком, как это было в FRS. в общем, для наших дохлых каналов очень полезная штука). замечу, что репликация DFS асинхронная, т.е. некоторое время источники не согласованы.
Q на что нужно обратить внимание после развертывания DFS
A на расположение и безопасность папки DFSRPrivate в каждом источнике (служит для хранения реплицируемой информации, удаленных и конфликтных с точки зрения репликации файлов). по умолчанию хранится в самой папке-источнике с правами, наследуемыми "сверху" (вообще странно, на technet"е написано, что только администраторы будут иметь доступ. может в 2008R2 что-то поправили). если у вас в пределах папки-источника права безопасности разные (что само по себе с точки зрения архитектуры файлопомойки несколько коряво), то люди могут получить доступ туда, куда не надо. плюс, шаловливые ручонки кулибиных радости не добавят.
Q что за папка "DFSRPrivate\Staging" и как правильно выбрать ее размер?
A это папка, где хранятся временные копии файлов для репликации, через которую они, по сути, передаются. есть во всех источниках. размер, хотя бы на время первичной репликации, лучше выставить чуть больше размера максимального встречающегося файла в реплицируемой папке (если у вас нет экстремалов, хранящих гигазы вареза одним терабайтным архивом, конечно). важно: файл, больший по размеру, чем Staging-папка нормально реплицируется и нигде не застрянет, как думают некоторые, просто процесс репликации пройдет в несколько этапов (файл будет резаться на несколько частей и передаваться по частям), что несколько замедлит процесс.
Q что за папка "DFSRPrivate\Conflict and Deleted"
A так как одновременно несколько пользователей могут изменить один и тот же файл, работает принцип "кто последний записал файл, того и тапки". файл-неудачник отправляется в эту папку, а в ConflictandDeletedManifest.xml появится соответствующая запись. так же, при наличии галки "хранить удаленные файлы в папке конфликтов" там будут храниться файлы удаленные пользователями (очень удобно восстанавливать). так что на размер я бы не скупился.
Q какие основные проблемы с репликацией DFS?
A Большинство проблем с репликацией DFS у меня возникали из-за File Screening (ограничение на разрешенные расширения файлов) и Disk Quotas (ограничение на размер папки). особенно в случае первичной репликации. с дисковыми квотами всё понятно, за ними надо следить (учитывая что директория DFSRPrivate вместе со "Staging" и "Conflict and Deleted" по умолчанию находится в самой папке источнике), то с File Screening полный гемор - нужно или выносить папку DFSRPrivate в место, где нет ограничений (что не удобно) или пытаться делать исключения на папки "DFSRPrivate" (а она скрытая. гыгы) или временно отключать запреты (в первичном источнике тоже! иначе файл не попадет в Staging на источнике и не реплицируется) или удалять все файлы пользователей, попадающие под запрещающие фильтры (напомню, что файл скрининг запрещает только создание новых файлов определенных расширений, а не их наличие. т.е. если файлы уже есть и мы включаем запрещающие правила в screening, то файлы, подпадающие под фильтры, нельзя создать-изменять, но можно читать-удалять. вот мы и получим при попытке репликации ошибку, когда служба попытается записать в папку Staging запрещенный реплицируемый файл, file screening ругнется ошибкой "нет места на диске", на чем вся репликация и встанет).
Q где хранятся подробные логи репликации?
A кроме eventlog"a в %windir%\debug\DFSR*.log.gz - архивные, и %windir%\debug\DFSR*.log - актуальный.
Q Какие есть тонкости в работе DFS?
A1 хотя и допускается монтировать одно пространство имен, как папку в другое пространстве имен, на практике при монтировании stand alone DFS Windows Server 2003 в папку другого, интегрированного в AD DFS Windows Server 2008, сей авангардизм приводил к BSOD"у при заходе в такую папку с компа с Windows XP ;) видимо, буржуи имели в виду, что можно сращивать только разные domain based DFS namespaces.
A2 когда выпадает первичный из источников папки в DFS, при заходе на него с Windows XP происходит задержка, равная времени кэширования структуры DFS (по дефолту 300 секунд, насколько я помню). если зайти с Windows Vista/7/2008, то задержки нет. как пишут буржуи, связанно с переписанными в новых windows"ах сетевых протоколах. так что полноценный auto failover, при наличии клиентов XP, не получится, нужно пользоваться немножко другими средствами или отключать источники вручную (например, на случай плановой остановки одного из серверов).
A3 так как репликация в DFS асинхронная, какие-либо базы данных держать в папке с двумя и более реплицируемыми источниками не стОит. в момент перехода между источниками она рассинхронизируется.
Q что бы еще такого сделать с DFS?
A включить ABE (Access Based Enumeration) в свойствах каждой шары - эта технология позволяет скрыть от пользователя папки, к которым у него нет доступа. полезно по многим причинам - и не раздражаем пользователя кучей папок, в которые он не сможет зайти (у него будут видны только те папки, к которым у него есть доступ), и не выдаем какую-либо косвенную информацию (мало кого не насторожит папка "План сокращения персонала в три раза") и делает навигацию по файлопомойке удобнее.
Q как вообще войти в DFS после создания? ;)
A в случае Doman Based DFS Namespace - "\\DomainName\DFSRootName" в адресной строке Explorer"a, в случае Stand Alone - как в обычную шару - "\\ServerName\DFSRootName". мапить можно как обычную шару - "net use Z: \\DOMAIN.Local\MyCoolDFS\" и "net use Z: \\Server\MyCoolDFS\" соответственно.
Ну а теперь пост про одну из самых важных новых технологий в релизе Windows Server 2003 R2.
Как известно, администраторы файловых серверов тратят много усилий на синхронизацию Фазиловых серверов в организации. Какие только приемы не используются – от ручного копирования новых файлов или xcopy, до скриптов, которые выполняются по определенному расписанию.
Представьте, что есть возможность автоматизировать этот процесс, и сделать его более удобным для администратора. Звучит заманчиво, не так ли? В Windows Server R2, такая возможность есть – все это можно сделать с помощью DFS Replication.
DFS Replication позволяет синхронизировать реплицируемые файловые директории (replicated folders) между серверами, которые входят в репликационную группу (replication group). Серверы в репликационной группе связаны между собой соединениями (connections), так что существует путь между любыми двумя серверами.
Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания. Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась. Поэтому DFSR – это очень полезный инструмент для синхронизации данных между дата-центром компании и удаленными офисами в регионах.
К тому же репликация может происходить в удобное для организации время, чтобы не занимать сеть тогда, когда она нужна для других целей. Для этого можно устанавливать расписание синхронизации, и для каждого слота в расписании можно существовать лимит использования сети. Например: днем передавать данные со скоростью не более 128Кб/сек, а ночью передавать данные со скоростью 1Мб/сек.
DFSR это мульти-мастерная система репликации. Это означает, что реплицируемый файл может быть изменен на любой машине, и эти изменения будут распостранены на все машины, участвующие в репликации.
Одним из главных достоинств DFSR является компрессия данных при репликации. Используется два вида компрессии:
Обычное сжатие данных, похожее на то, которое применяется в архиваторах
Алгоритм дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации.
Кроме того, модификация алгоритма RDC, cross-file RDC, используется и для репликации различных файлов, похожих между собой. Например, если у нас есть текстовый документ, который получен путем изменения другого документа, то cross-file RDС перешлет по сети ссылку на исходный файл вместе с информацией о различиях между файлами.
Таким образом, во многих ситуациях DFSR дает значительную экономию сетевого трафика, по сравнению с обычным копированием, за счет выигрыша от компрессии данных.
Хотя в названии технологии DFSR присутствует упоминание распределенной файловой системы, репликация может использоваться и без добавления реплицируемых директорий в пространство имен какого-либо DFS корня. Однако в большинстве случаев, DFSR используется вместе с пространством имен 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
на компьютере под управлением 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
. Далее мастер
предложит выбрать топологию репликации. Необходимо будет указать один из
следующих вариантов:
Кольцевая топология установлена по умолчанию и подходит для большинства
случаев. В идеале выбранная топология репликации должна соответствовать схеме
сети. Например, если есть центральный офис, где располагаются основные ресурсы,
а многочисленные филиалы подключаются к ним по мере необходимости, то в этом
случае больше подойдет схема Звезда. Если ничего из предустановок не подходит,
следует обратиться к пункту Особая.
После создания реплики для ссылки соответствующий ей значок в окне оснастки
изменится. В контекстном меню также появятся два новых пункта: Отобразить/Скрыть
статус репликации и Остановить репликацию. В поле статуса репликации может быть
один из трех результатов. Если процесс репликации завершен нормально, на значках
будут зеленые флажки. Красный крестик на значке реплики укажет, что она в данный
момент недоступна, в поле Состояние подпись изменится на Автономный. Если в
проверяемой ссылке недоступны лишь некоторые реплики, в значке появится желтый
восклицательный знак.
Перед удалением одной из альтернативных реплик сначала следует запретить
репликацию. При возобновлении репликации тебя встретит тот же мастер. Если
сервер является контроллером домена, вместе со всеми данными DFS
будет
реплицировать и содержимое тома SYSVOL. Поэтому следует помнить, что до тех пор,
пока не произойдет полная репликация всех реплик, начинать любые изменения в
конфигурации DFS
очень рискованно, это может нарушить работоспособность всего
домена.
Если выбранный вариант топологии репликации по каким-либо причинам не
подошел, топологию репликации впоследствии можно легко изменить, выбрав окно
свойств соответствующей ссылки и перейдя на вкладку Репликация. Здесь находятся
еще несколько полезных настроек. По умолчанию репликация выполняется постоянно,
нажав кнопку Расписание, можно изменить расписание репликаций для всех
подключений. Чуть ниже указываются фильтры для файлов и подпапки, которые не
будут реплицироваться. Для этого нажимаем Изменить и вводим шаблоны файлов или
подкаталогов.
Для принудительной репликации информации, хранящейся на определенном сервере,
можно воспользоваться утилитой NtfrsUtl.exe, которая входит в состав пакета
Support Tools
. Команда проста: «ntfrsutl poll /now server.com». Чтобы увидеть
установленные временные интервалы, через которые производится репликация,
следует ввести «ntfrsutl poll». Все установки доступны по команде «ntfrsutl sets
server.com».
В окне свойств общего ресурса, представленного в службе DFS
, появится еще
одна вкладка – DFS
. Открыв ее, пользователь может просмотреть, с какими общими
папками сопоставлена эта ссылка, проверить состояние реплики, выбрать активную
реплику, к которой он будет перенаправляться в первую очередь.
Администратору для контроля следует почаще заглядывать в журнал
"Администрирование – Просмотр событий – Служба репликации файлов", где можно
найти информацию обо всех событиях, происходящих со службой FRS.
