Назначение и вероятности 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 Replication. Главным их различием является то, что в 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 [Blob Size: 284 bytes]
Root Name="\\SERVER\first" Comment="first Root" State="1" Timeout="300"
Target Server="GRINDERS" Folder="first" State="2" [Site: Default-First-Site-Name]

После основания корня его можно опубликовать в 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.