Dfs сценарии использования

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

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

Принцип работы Dfs

Основным элементом структуры данной службы является общий каталог, который представляет собой корень иерархии Dfs. При помощи Dfs эти сетевые каталоги формируют последовательное отдельное пространство имен. Клиентские системы используют хорошо знакомые понятия, такие как подключенный диск или путь UNC (Universal Naming Convention), для подключения к корню Dfs. После подключения клиента структура Dfs выступает в роли обычного общего каталога, содержащего подкаталоги, по которым пользователи могут перемещаться. Каждый подкаталог, доступный из корня Dfs, на самом деле представляет собой ссылку на общий каталог (источник ссылки) в любой точке сети. Dfs автоматически направляет клиента, который обращается к сетевой папке, к реальному месту расположения данных. Как показано на экране 1, папки, которые видит пользователь, представляют собой переадресацию пользователей службой Dfs к разным общим каталогам на серверах A, Б и В. В роли источника ссылки может выступать любая система, использующая сетевую файловую систему, к которой можно обратиться через путь UNC, например системы с Windows, Novell NetWare и UNIX или Linux (то есть машины с файловой системой NFS).

Экран 1. Перенаправление данных Dfs

Служба Dfs позволяет задействовать корни двух видов: автономные и интегрированные в Active Directory (AD). Они различаются способами хранения данных Dfs. В случае автономных корней иерархия Dfs, состоящая из различных ссылок на сетевые каталоги, хранится в локальном реестре сервера Dfs. Этот способ хранения информации не предполагает возможности ее дублирования на других серверах Dfs, то есть, если единственный сервер Dfs, содержащий корень Dfs, становится недоступен, иерархия Dfs оказывается полностью недоступной для всех клиентов сети. В случае недоступности сервера Dfs клиенты по-прежнему могут обращаться к общим каталогам на серверах напрямую. Они лишь не смогут задействовать службу Dfs для доступа к ресурсам. Придется использовать автономные корни Dfs, если система не содержит службу AD или если администраторы системы Dfs не являются администраторами домена и поэтому не могут получить достаточно прав (то есть получить доступ к объекту DFS-Configuration в контейнере System раздела AD для домена) для управления системой Dfs.

Система Windows 2000 Server и более поздние версии также поддерживают корни Dfs, интегрированные с AD (известные еще как доменные корни Dfs или отказоустойчивые корни Dfs). При использовании интегрированных корней информация Dfs хранится преимущественно в AD, хотя действующие серверы Dfs тоже содержат копии данных в памяти, чтобы минимизировать количество обращений сервера Dfs к контроллерам домена (DC) и таким образом снизить нагрузку на сеть со стороны службы Dfs. Интегрированные в AD корни можно использовать только тогда, когда сервер Dfs является членом домена. Однако сервер Dfs не обязан быть контроллером домена. По существу, следует задействовать автономные корни Dfs в случае отсутствия домена AD, необходимости разместить более 5000 ссылок или же если сеть содержит унаследованные клиентские системы. Более подробная информация о различиях между автономными и интегрированными в AD корнями Dfs приведена во врезке «Такие разные корни».

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

Настройка Dfs

Теперь, когда мы изучили важнейшие понятия системы Dfs, можно приступать к ее настройке. Первая задача — создать корень Dfs. Для этого существует два способа: использование в Microsoft Management Console (MMC) оснастки Distributed File System и запуск приложения dfsutil.exe из командной строки. В данной статье мы рассмотрим оснастки, что чуть проще для новичков по сравнению с dfsutil.exe. Ознакомившись с Dfs, вы, возможно, захотите использовать dfsutil.exe, например, в сценарии, заполняющем ссылками иерархию Dfs. Тогда нужно иметь в виду, что в системах Windows Server 2003, Standard Edition и Windows 2000 Server сервер может содержать лишь один корень Dfs. Серверы Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition могут работать с неограниченным числом корней Dfs.

Чтобы создать новый корень Dfs с помощью оснастки Distributed File System, необходимо выполнить следующие шаги:

Запустить оснастку Distributed File System (пункт находится в папке Administrative Tools меню Start).
Щелкнуть правой кнопкой мыши по заголовку Distributed File System в корне дерева в панели и выбрать пункт New Root (если используется система Windows 2003) или New DFS root (для Windows 2000 Server). Последующие шаги используют диалоговые окна системы Windows 2003, хотя сам процесс почти полностью повторяет процесс для оболочки Windows 2000 Server.
В окне приветствия нажать кнопку Next.
Выбрать тип создаваемого корня (доменный или автономный). Нажать Next.
Если выбран доменный корень Dfs, потребуется ввести имя домена, который будет хранить информацию службы Dfs. Если выбран автономный корень, следует ввести имя сервера, который будет хранить соответствующую информацию. Нажмите Next.
Если на шаге 4 выбран доменный корень, программа попросит выбрать сервер, который будет содержать корень Dfs. Следует указать сервер и нажать кнопку Next.
Ввести имя нового корня и любые комментарии, которые помогут при его идентификации, после чего нажать Next. Введя имя корня, вы увидите, как это имя будет выглядеть в качестве имени общего каталога в формате UNC, как показано на экране 2. Например, для доменного общего каталога Dfs имя пути имеет структуру имя доменаимя каталога. Если на данный момент общего каталога не существует, нужно выбрать локальную папку на системе в качестве общего каталога. Этот каталог не содержит реальных данных; вместо этого он включает объекты-ссылки, указывающие на физическое расположение данных. Необходимо выбрать папку для использования в качестве общего каталога и щелкнуть Next.
В окне подтверждения нажать кнопку Finish.

Экран 2. Указание нового корня Dfs

В этой точке клиенты могут подсоединяться к пространству имен Dfs, используя путь UNC dfstest.testshared. Им не нужно ничего знать о том, какие серверы содержат элементы Dfs. Клиенты, использующие систему Windows NT 4.0+Service Pack 6a (SP6a) или более поздние версии, могут подсоединяться к доменному пространству имен Dfs. Клиенты, использующие оболочку Windows 98, могут обращаться к автономным пространствам имен Dfs, но должны иметь установленное расширение, клиента службы AD, чтобы подключаться к пространству имен домена. Среда загрузки Microsoft Windows Preinstallation Environment (WinPE) может обращаться лишь к автономным пространствам имен Dfs.

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

В оснастке Distributed File System щелкните правой кнопкой по созданному корню и выберите пункт New Root Target.
Введите имя сервера, который послужит дополнительным хостом Dfs для пространства имен. Имейте в виду, что имя общего каталога (например, shared), которое система Dfs будет использовать для содержания этой копии, уже задано и не может быть изменено. Нажмите Next.
Если каталога с таким именем на указанном сервере не существует, система предложит выбрать папку для использования в этом качестве либо можно создать новую папку, а потом выбрать ее. Выберите папку и нажмите Next.
В результирующем окне нажмите кнопку Finish.

Корень Dfs теперь будет отображать множество серверов, которые действуют как корневые объекты пространства имен, как показано на экране 3. Клиенты могут подключаться к пространству имен и направляться на один из его корневых объектов. Однако пользователи, обратившиеся к корневому объекту, увидят лишь пустую папку, так как еще не задано ни одной ссылки. Следующим шагом будет добавление нескольких ссылок и источников ссылок, которые будут направлять клиентов к нужным данным.

Экран 3. Просмотр источников корня Dfs

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

Щелкните правой кнопкой мыши на корне Dfs и выберите пункт New Link из контекстного меню.
Введите имя ссылки (то есть имя папки, которую будет видеть клиент) и имя общего каталога, в который ссылка будет направлять клиента. Это имя можно изменить или добавить позднее. Также можно ввести комментарий и определить период времени, в течение которого клиенты будут хранить информацию по источнику, до повторного обращения к серверу Dfs, как показано на экране 4.
Нажмите кнопку ОК.

Экран 4. Создание новой ссылки

Теперь, когда клиенты попадут в пространство имен Dfs, они будут видеть папку. При открытии этой папки пользователь будет перенаправлен в общий каталог и сможет просмотреть его содержимое.

Предположим, у нас имеется папка с документами на сервере в удаленном офисе. Вместо того чтобы создавать отдельную ссылку на эту папку (например, LondonDocuments), можно добавить еще один источник к существующей ссылке. Настройка множества источников ссылки — еще один способ обеспечить отказоустойчивость. Если один из источников ссылки недоступен, система Dfs может направить пользователя к другой копии данных. Чтобы добавить дополнительный источник к существующей ссылке, следуйте приведенным ниже инструкциям.

Щелкните правой кнопкой мыши по ссылке и выберите пункт New Target из контекстного меню.
Укажите путь к новому каталогу, который также послужит источником для данной ссылки. Можно дополнительно включить дублирование данных, поставив флажок в поле Add this target to the replication set, как показано на экране 5. Дополнительная информация о дублировании приведена во врезке «Настройка дублирования данных на основе службы Dfs».
Нажмите кнопку OK.

Экран 5. Добавление источника ссылки для существующей ссылки

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

Как мы убедились, для одной ссылки может существовать множество источников. Эта возможность вызывает очевидный вопрос: не будет ли наличие разнообразных данных в различных источниках ссылки означать, что система Dfs может произвольным образом направлять клиентов к различным источникам ссылки и клиенты будут видеть различные файлы? Так как источники ссылки представляют собой разные каталоги на отдельных серверах, специального механизма для постоянной синхронизации их содержания не существует. Следовательно, вполне возможна ситуация, когда различные источники ссылки будут иметь разное содержание. В таком случае клиент обратится к папке, получит доступ к данным, но, вернувшись к той же папке позднее, возможно, будет отправлен к другому источнику ссылки и увидит совершенно другой набор данных. Однако этот сценарий маловероятен. Мои пояснения по теме приведены во врезке «Настройка перенаправления в Dfs». К счастью, оболочка Windows 2000 Server и более поздние реализации системы Dfs содержат службу File Replication Service (FRS), которую контроллеры домена задействуют для постоянной синхронизации своих общих каталогов Sysvol. Система Dfs использует службу FRS для синхронизации источников ссылки, которые являются частью доменного пространства имен. Служба FRS предоставляет различные возможности дублирования, такие как непрерывное дублирование, которое позволяет дублировать изменения в режиме, близком к реальному времени, и дублирование в определенное время суток. Система Windows 2003 R2 будет содержать новую версию службы FRS специально для службы Dfs. Инструкции по настройке дублирования файлов на основе системы Dfs приводятся во врезке «Настройка дублирования на основе Dfs». Если используется автономный корень Dfs и требуется синхронизация, для решения этой задачи необходимо средство синхронизации файлов, такое как служба Robocopy из пакета Windows Resource Kit.

Как мы выяснили, система Dfs заметно упрощает доступ к общим ресурсам для конечных пользователей и, при действующей службе AD, предоставляет методы повышения отказоустойчивости. Для оптимальной работы системы Dfs в конкретной компании потребуется решить, какие файлы необходимо дублировать, и, если нужно, отладить механизм перенаправления. Я привел самую существенную информацию, которой следует владеть перед началом работы с Dfs. Дополнительные сведения по этой теме можно найти на Web-сайте Microsoft?s Distributed File System and File Replication Services по адресу http://www.microsoft.com//windowsserver2003/ technologies/fileandprint/file/dfs/default.mspx.

Такие разные корни

Каждый тип корня Dfs имеет свои преимущества и ограничения. Важно помнить, что, в отличие от интегрированной в Active Directory (AD) службы DNS, доменные корни Dfs не обязаны находиться на контроллерах домена (DC); они могут содержаться на любом сервере, который является членом домена и использует Windows 2000 Server или более поздние версии. При запуске и через определенные интервалы времени (по умолчанию один раз в течение часа) серверы Dfs просто обращаются к эмуляторам PDC домена, чтобы получить последние данные о пространстве имен Dfs. Эти периодические запросы могут оказаться узким местом при доступе к ресурсам. Кроме того, они накладывают ограничение в 16 копий корней при реализации Dfs, а значит, нельзя будет иметь более 16 корней для одного пространства имен, так как синхронизация между серверами Dfs становится все более сложной при каждом изменении структуры Dfs (т. е. при добавлении новой ссылки или ее источника). Исключением из этого правила является реализация Dfs в системе Windows Server 2003, которая имеет новый режим масштабирования корней, обычно позволяющий серверам Dfs обращаться к любому DC в домене, а не только к эмулятору PDC.

Другое ограничение доменных корней Dfs заключается в том, что вся структура Dfs (в том числе ссылки, источники ссылок и корневые серверы) хранится в отдельном объекте, который необходимо дублировать на всех контроллерах домена при малейших изменениях в структуре Dfs. Вам это не напоминает дублирование членства в группе в системах Windows 2000 Server? Для корректного выполнения дублирования Microsoft рекомендует иметь максимальный размер объекта Dfs не более 5 Mбайт (около 5000 ссылок). Средняя реализация Dfs имеет около 100. Если требуется разместить более 5000 ссылок, следует обдумать варианты разделения пространства имен Dfs на множество пространств имен или использование автономных корней Dfs, для которых рекомендованный лимит составляет 50 000 ссылок. Другой способ минимизировать объем, используемый системой Dfs в AD, — ограничить число комментариев, приводимых для ссылок, так как они тоже хранятся в объекте Dfs службы AD. Тем не менее нужно помнить, что подобное пространство имен Dfs вряд ли будет часто меняться. После настройки начальной конфигурации системы Dfs она останется достаточно статичной и не будет дублироваться часто.

Настройка дублирования на основе Dfs

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

Щелкнуть правой кнопкой мыши по ссылке и выбрать пункт меню Configure Replication.
На экране приветствия мастера Configure Replication Wizard нажать кнопку Next.
Программа попросит выбрать источник, который станет оригиналом для дублирования. Если имеется общий каталог, содержащий данные, которые необходимо дублировать в другие папки, следует выбрать его в качестве оригинала. Нажмите кнопку Next.
Необходимо будет выбрать топологию, используемую при дублировании. По умолчанию установлена кольцевая топология, которая подходит для большинства сетей. Если сетевое окружение более сложное, можно рассмотреть использование других топологических схем, таких как «издатель — подписчики», взаимная пересылка и схема, настраиваемая пользователем. Выбранная топология должна соответствовать топологии имеющейся глобальной сети; в идеале топология дублирования службы FRS должна соответствовать схеме сети. К примеру, если сеть включает один центральный офис и множество подключенных к нему филиалов, топологическая схема «издатель — подписчики» будет наилучшим выбором. Нажмите Finish.

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

Хочу кое-что пояснить относительно технологии дублирования в Dfs: она не создавалась для работы с данными, которые находятся на множестве серверов и часто обновляются, или для тех случаев, когда файл может обновляться в одно время в различных источниках ссылок. Служба FRS не соединяет все изменения в одном файле; дублируется файл, сохраненный последним. Поэтому стоит задействовать службу FRS только для дублирования статичных данных, таких как шаблоны или политики компании, либо данных, которые будут обновляться лишь в одном месте в один и тот же момент времени. Основное достоинство службы FRS заключается в том, что она предоставляет отказоустойчивый набор данных, чтобы обеспечить надежную защиту в случае сбоя отдельного сервера.

Настройка перенаправления в Dfs

Как было сказано в основной статье, Dfs представляет собой службу установки взаимосвязей между расположением сетевых ресурсов, т. е. если при обращении клиента к ссылке для этой ссылки доступно множество источников, Dfs в первую очередь пытается перенаправить клиента к источнику, размещенному в локальной сети клиента. Если система Dfs не может найти доступный локальный источник, она перенаправляет клиента к другому, случайно выбранному источнику. Стратегия перенаправления в Dfs снижает использование полосы пропускания глобальной сети в том случае, если доступен локальный источник ссылки.

Заданное по умолчанию поведение системы Dfs (перенаправление клиента на произвольный альтернативный источник ссылки), если она не может найти локальный источник, может быть неэффективным. Например, если система Dfs не находит локальный источник в Далласе, она может перенаправить клиента к источнику в Лондоне, хотя в Нью-Орлеане существует еще один источник, соединение с которым реализовано через более быстрый канал. Однако настройки Dfs можно регулировать, обеспечивая более эффективное перенаправление запросов пользователей. Можно настроить Dfs таким образом, что система будет направлять клиентов только к источникам ссылок, размещенным в локальном окружении пользователей. Для активизации этого режима, названного Restricted Same-site Target Selection, следует запустить команду Dfsutil и указать параметр /insite:

dfsutil /root:<имя сервера><имя корня Dfs> /insite /enable

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

С другой стороны, если на контроллерах домена и серверах Dfs используется оболочка Windows 2003, можно задействовать режим Least-Expensive Target Selection. В этом режиме, если локальный источник ссылки недоступен, система Dfs перенаправляет клиента на источник, соединение с которым даст наименьшую нагрузку на полосу пропускания; Dfs использует для этого стоимость межсайтовых соединений, описанных в AD. Режим Least-Expensive Target Selection минимизирует использование медленных соединений и позволяет клиентам быстрее получать доступ к сетевым каталогам. Чтобы активировать режим Least-Expensive Target Selection, нужно запустить команду:

dfsutil /root:<имя сервера>

<имя корня dfs>

/sitecosting /enable

Специалист по продуктам Microsoft в компании Geniant. Имеет сертификат MCSE и звание MVP. john@savilletech.com

Источник

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

Зачем?

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

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

Как?

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Distributed File System. Процессы и взаимодействия

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

Процесс перенаправления (Referral Process)

Процесс перенаправления описывает взаимодействие между клиентскими компьютерами, корневыми серверами и контроллерами домена, в тот момент, когда клиент пытается получить доступ к целевому объекту в пространстве имен DFS. Эти процессы предполагают, что:

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

Рассмотрим шаги, которые выполняются при обращении клиента к доменному или автономному пространству имен. В упрощенном виде процесс перенаправления для доменных пространств имен выглядит следующим образом:

1. Пользователь пытается получить доступ к ссылке в доменном пространстве имен.
2. Клиентский компьютер отправляет запрос к ближайшему контроллеру домена, чтобы получить список корневых целевых объектов для доменного пространства имен.
3. Контроллер домена возвращает список корневых целевых объектов, определенных для запрошенного пространства имен.
4. Клиент выбирает первую корневую цель в списке и отправляет запрос на корневой сервер для запрашиваемой ссылки.
5. Корневой сервер создает список целевых объектов ссылок и отправляет список клиенту. Порядок сортировки целевых объектов ссылок может отличаться в зависимости от настроек DFS.
6. Клиент устанавливает соединение с первой целевой ссылкой в списке.

Теперь разберем процесс более подробно.

1. Пользователь пытается перейти по пути DFS, например, введя в проводнике адрес \Contoso.comPublicSoftware.

2. Клиент DFS на компьютере пользователя проверяет свой доменный кэш на наличие реферальной ссылки для домена Contoso.com. Если ссылка имеется в кэше, то клиент переходит к шагу 3. Если же ссылки нет, то клиент подключается к общей папке IPC$ ближайшего контроллера домена под учетной записью LocalSystem и отправляет запрос на ссылку в виде строки с нулевой длиной. В ответ на этот запрос контроллер домена возвращает клиенту список локальных и доверенных доменов.

3. Клиент проверяет свой реферальный кэш на наличие самого длинного совпадения с предыдущей реферальной ссылкой. Это может быть корневая (напр. \Contoso.comPublic) или обычная реферальная ссылка (напр. \Contoso.comPublicSoftware). Если клиент находит требуемое совпадение, то он переходит к шагу 5 или 6, в зависимости от типа найденной ссылки. Если совпадения не найдено, то переходит к следующему шагу.

4. Клиент проверяет свой доменный кэш на наличие ссылки на контроллер домена для домена Contoso.com. Если ссылка есть, то клиент переходит к шагу 5, если нет. Если ссылки в кэше нет, то клиент подключается к общей папке IPC$ ближайшего контроллера домена под учетной записью LocalSystem и отправляет запрос на ссылку на контроллер домена для доменного имени Contoso.com. Контроллер возвращает список контроллеров домена для указанного домена. Контроллеры домена, находящиеся в одном сайте с клиентом, находятся в верхней части списка. Если включен выбор наименее дорогостоящего целевого объекта, контроллеры домена за пределами целевого сайта сортируются по наименьшей стоимости. Если включен выбор целевого объекта на том же сайте, DFS игнорирует этот параметр и перечисляет остальные контроллеры домена в случайном порядке.

5. Клиент проверяет свой реферальный кэш на наличие корневой ссылки (root referral). Если ссылка находится в кэше, клиент переходит к шагу 6. Если в кэше ссылок нет корневой ссылки на домен, клиент подключается к общей папке IPC$ контроллера домена под LocalSystem и запрашивает корневую ссылку на домен. Контроллер домена определяет сайт клиента и возвращает список корневых целевых объектов. По умолчанию корневые целевые объекты на сайте клиента находятся в верхней части списка, а за ними в произвольном порядке следуют остальные корневые целевые объекты. Если включен выбор наименее дорогих целевых объектов, то остальные объекты упорядочиваются по наименьшей стоимости. Если включен выбор целевого объекта только в том же сайте, то в ссылке будут перечислены только корневые серверы на сайте клиента.

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

7. Клиент проверяет свой реферальный кэш на наличие ссылки. Если эта ссылка находится в кэше, клиентский компьютер подключается к первому целевому объекту ссылки в списке. Если же ссылка-реферал отсутствует в кэше, клиент подключается к общей папке IPC$ корневого сервера под учетной записью LocalSystem и запрашивает ссылку с корневого сервера. Корневой сервер возвращает список целевых объектов ссылок. В верхней части списка целей расположены объекты, которые находятся на том же сайте, что и клиент. Оставшиеся целевые объекты ссылок корневой сервер помещает в список с помощью одного из следующих методов:

• По умолчанию целевые объекты ссылок за пределами клиентского сайта располагаются в произвольном порядке;
• Если включен выбор цели для одного и того же сайта, корневой сервер не добавляет к ссылке цели для внешних ссылок;
• Если включен выбор целевого объекта с наименьшими затратами, корневой сервер проверяет свой кэш стоимости сайта, чтобы определить, существует ли информация о затратах для соединения между клиентским и целевым сайтом. Если данные о стоимости сайта отсутствуют в кэше, корневой сервер связывается с контроллером домена, действующим в качестве генератора межсайтовой топологии (Intersite Topology Generator) и запрашивает у него данных о стоимости межсайтовых соединений (Site link costs). Затем корневой сервер сортирует оставшиеся объекты по наименьшей стоимости.

Для автономных пространств имен процесс перенаправления выглядит несколько иначе:

1. Пользователь пытается получить доступ к пути DFS.
2. Клиентский компьютер отправляет запрос на корневой сервер, на котором размещается автономное пространство имен.
3. Корневой сервер возвращает клиенту корневую ссылку. Корневой реферал содержит единственную корневую цель.
4. Клиент отправляет запрос на корневой сервер для получения запрошенной ссылки.
5. Корневой сервер создает список целевых объектов и отправляет его клиенту.
6. Клиент устанавливает соединение с первой целевой ссылкой в списке.

Более подробно процесс выглядит так:

1. Пользователь пытается получить доступ к пути DFS, для чего вводит в проводнике адрес, например \SoftwarePublicAntivirus.

2. Клиент DFS на компьютере пользователя проверяет свой доменный кэш и определяет, что указанный путь не является доменным путем DFS, поскольку Software не является именем домена.

3. Клиент проверяет свой кэш ссылок, чтобы определить, нет ли в нем автономной корневой реферальной ссылки. Если ссылка находится в кэше, клиент переходит к шагу 5. Если ссылки в кэше нет, клиент подключается к общей папке IPC$ корневого сервера от имени LocalSystem и отправляет запрос. Корневой сервер возвращает корневую ссылку, после чего все последующие запросы направляются через DFS.

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

5. Клиент проверяет свой реферальный кэш на наличие существующей реферальной ссылки. Если ссылка находится в кэше, клиент подключается к первому целевому объекту ссылки в списке. Если ссылка-реферал отсутствует в кэше ссылок, клиент подключается к общей папке IPC$ корневого сервера в контексте учетной записи LocalSystem и запрашивает ссылку-реферал с корневого сервера. Корневой сервер возвращает список целевых объектов ссылок. В верхней части списка целей находятся целевые объекты ссылок, которые находятся на том же сайте, что и клиент. Оставшиеся объекты корневой сервер сортирует по следующим критериям:

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

Вход в систему

Отдельно стоит рассмотреть взаимодействия DFS в процессе входа в систему. Когда клиентский компьютер подключается к домену, он связывается с ближайшим контроллером домена и запрашивает специальные реферальные ссылки SYSVOL и NETLOGON. Эти ссылки необходимы для того, чтобы компьютер смог получить доступ к общим папкам SYSVOL и NETLOGON на контроллерах домена, в которых хранятся скрипты входа и групповые политики. Ссылки сопоставляют пути \DomainNameSysvol и \DomainNameNetlogon со списком общих папок SYSVOL и NETLOGON для всех контроллеров домена. Клиенты хранят эти ссылки в своем реферальном кэше.

В Active Directory не существуют объекты DFS для этих общих папок, вместо этого контроллер домена просто знает, что он должен отвечать на запросы вида \DomainNameSysvol и \DomainNameNetlogon. Эти ссылки отличаются тем, что, хотя целевые объекты размещены на контроллере домена, сами они не являются корнями DFS и не отображаются ни в одном из инструментов DFS, а также не могут содержать ссылки на общие папки SYSVOL и NETLOGON.

Контроллеры домена генерируют ссылки SYSVOL и NETLOGON каждый раз, когда клиент запрашивает ссылку. По умолчанию список контроллеров домена, перечисленных в ссылке SYSVOL или NETLOGON, сортируется следующим образом:

• Все контроллеры домена на сайте клиента сгруппированы в произвольном порядке в верхней части списка.
• Контроллеры домена за пределами сайта клиента перечислены в произвольном порядке.

Можно настроить DFS для сортировки контроллеров домена за пределами сайта клиента в порядке наименьшей стоимости. Эту функцию можно включить, добавив запись реестра SiteCostedReferrals, а затем перезапустив службу DFS на каждом контроллере домена. Затем служба DFS получает информацию о стоимости сайта для всех контроллеров домена и сохраняет эту информацию в своем кэше стоимости сайта.

Определение сайта

Определение сайта, также называемое осведомленностью о сайте — это процесс, используемый службой DFS для определения того, к какому сайту Active Directory принадлежит корневой целевой объект, целевой объект ссылки или клиент. DFS использует информацию о сайте для определения порядка сортировки целевых объектов в ссылке-реферале. Под сайтом Active Directory подразумевается одна или несколько подсетей TCP/IP, определенных в Active Directory.

DFS определяет сайт целевых объектов и клиентов следующим образом:

• При запуске служба DFS определяет текущий сайт каждого целевого объекта, для чего разрешает его имя в IP-адрес, а затем запрашивает Active Directory для преобразования IP-адреса в имя сайта на основе сопоставлений подсети и сайта.
• Когда клиент пытается получить доступ к пространству имен, DFS определяет сайт клиента, запрашивая Active Directory и преобразуя IP-адрес клиента в имя сайта на основе сопоставления подсети с сайтом.

Обнаружение сайтов в Windows Server работает независимо от операционной системы, запущенной на целевом сервере. Например, если целевой объект ссылки не является операционной системой Windows, DFS может определить целевой сайт, используя его IP-адрес. Для кластеров серверов и многосетевых клиентов и целевых объектов обнаружение сайтов работает следующим образом:

• Если целевой объект является членом кластера, DFS использует IP-адрес виртуального сервера для определения целевого сайта.
• Если целевой сервер является многосетевым (то есть сервер имеет несколько IP-адресов), корневой сервер или контроллер домена запрашивает все IP-адреса для имени сервера и первый возвращенный адрес используется для определения сайта.
• Когда многосетевой клиент запрашивает ссылку, корневой сервер или контроллер домена использует исходный IP-адрес из сетевого запроса клиента, который может быть произвольным в зависимости от конфигурации сети клиента. Или, если клиентский запрос проходит через NAT, используется исходный IP-адрес запроса, переписанный шлюзом NAT.

После того как корневые серверы и контроллеры домена получают сведения о клиентских компьютерах и целевых серверах сайта, они хранят эти сведения в своем кэше:

• Целевой кэш сайта. Содержит сопоставления имен целевых серверов с именами сайтов.
• Кэш клиентского сайта. Содержит сопоставления IP-адресов клиентов с именами сайтов.

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

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

Информация о клиентском сайте может устареть, когда клиентский компьютер перемещается на другой сайт, но сохраняет тот же IP-адрес, когда подсеть клиента перемещается на другой сайт или когда имена сайтов меняются. В этих сценариях DFS по умолчанию обнаруживает новую информацию о сайте для клиента в течение 24 часов. До тех пор, пока информация о сайте не будет обновлена в кэше, DFS может сортировать целевые объекты в ссылках на основе устаревшей информации.

Выбор целевого объекта

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

Для примера возьмем следующий рисунок.

В зависимости от настроек DFS объекты могут быть рассортированы тремя различными способами.

По умолчанию

По умолчанию DFS размещает целевые серверы в ссылке в следующем порядке:

• Целевые объекты, находящиеся на том же сайте, что и клиент, перечислены в случайном порядке в верхней части списка.
• Объекты вне сайта клиента перечислены в произвольном порядке.

Так по умолчанию сервера с предыдущего рисунка будут отсортированы в следующем порядке:

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

Выбор в том же сайте

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

Сортировка объектов при этом будет выглядеть так.

Этот способ можно включить в корневом каталоге или отдельных ссылках DFS с помощью Dfsutil.exe с параметром /InSite. Если этот параметр включен в корневом каталоге, то ссылки возвращают только целевые объекты, находящиеся на том же сайте, что и клиент. Если на сайте клиента нет корневых целей или целей ссылок, то ссылка не возвращается, и клиент не может получить доступ к этой части пространства имен. Если этот параметр включен для ссылки и на сайте клиента нет целевых объектов ссылок, то ссылка не возвращается и клиент не может получить к ней доступ.

Выбор с минимальными затратами

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

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

• Целевые объекты на том же сайте, что и клиент, перечислены в случайном порядке в верхней части ссылки.
• Объекты за пределами сайта клиента перечислены в порядке возрастания стоимости. Объекты с одинаковой стоимостью группируются вместе, а внутри группы перечислены в случайном порядке.

Используя предыдущий рисунок в качестве примера, когда включен выбор наименее дорогих целевых объектов, DFS размещает целевые объекты в ссылке в следующем порядке:

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

Выбор с минимальными затратами работает как в автономных, так и в доменных пространствах имен, если все корневые серверы и все контроллеры домена работают под управлением Windows Server 2003 и выше. Эти требования гарантируют, что:

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

Данный способ недоступен в следующих ситуациях:

• Когда автономное пространство имен размещается на корневом сервере, который не является частью какого-либо домена.
• Когда корневой сервер или контроллер домена работает под управлением Windows 2000 Server.
• Отключен параметр Bridge all site links в Active Directory.

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

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

• Целевой объект на том же сайте временно недоступен, например из за проблем с сервером или сетью, и клиент переходит к следующему объекту, который может находиться за пределами сайта клиента.
• Получена неверная информация о сайте, что заставляет DFS интерпретировать объект как находящийся на сайте клиента. Эта проблема может возникнуть, если подсети настроены неправильно.
• Если нужного объекта нет в сайте клиента, и клиент неожиданно выбирает цель с более высокой стоимостью, это может быть вызвано неправильной настройкой стоимости сайта.
• Для IP-адреса клиента не определена подсеть в Active Directory, и поэтому DFS не может получить информацию о сайте клиента.
• Для IP-адреса целевого объекта не определена подсеть в Active Directory, и поэтому DFS не может получить информацию о сайте объекта.
• Клиент использует кэшированную ссылку, содержащую устаревшую информацию о сайте целевого сервера.
• Информация о сайте изменилась, но старая информация по-прежнему кэшируется на корневом сервере или контроллере домена.
• Объект DFS не обновляется, когда корневой сервер опрашивает контроллер домена. Это может быть вызвано задержкой репликации Active Directory или сбоем.
• Отключен параметр Bridge all site links.

Отработка отказа

Отработка отказа DFS (DFS Failover) — процесс, при котором клиенты пытаются получить доступ к следующему целевому объекту в ссылке после того, как предыдущий объект оказался недоступен. Отказ может произойти по разным причинам, например из за сбоя на файловом сервере или контроллере домена. Отработка отказа производится в следующих ситуациях:

• Клиент пытается получить доступ к целевому объекту, полученному в реферальной ссылке, но объект недоступен.
• Клиент обращается к контроллеру домена, чтобы запросить ссылку, но выбранный контроллер домена недоступен.
• Клиент DFS уже имеет активный сеанс с целевым объектом, в процессе которого целевой сервер становится недоступен.
• Клиент DFS уже имеет активный сеанс с целевым объектом, в процессе которого на файловом сервере происходит сбой и общая папка становится недоступной.
• Для клиента DFS истекает срок действия реферальной ссылки и в новой ссылке предыдущий активный целевой объект отсутствует.

При рассмотрении различных типов отказов необходимо обратить внимание внимание на следующие моменты:

• Клиенты должны получить доступ к доменному пространству имен по пути \DomainNameRootName. Если клиент обращается к доменному пространству имен непосредственно на корневом сервере и использует путь \RootServerRootName, отработки отказа для корневого целевого объекта не происходит.

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

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

Недоступен целевой объект (папка)

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

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

Недоступен контроллер домена

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

Недоступен целевой сервер

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

Сбой на целевом сервере

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

Для клиента DFS истекает срок действия ссылки

Этот сценарий актуален для клиентов под управлением ОС Windows XP SP 2 или Windows Server 2003 SP1 и более новых. Эти клиенты не обновляют значение Time To Live каждый раз, когда они обращаются к целевому объекту с помощью кэшированной ссылки. В результате срок действия ссылки истекает сразу по истечении Time To Live независимо от того, обращался ли клиент к целевому объекту раньше или обращается к нему в настоящее время. С точки зрения отработки отказа DFS такое поведение может привести к отказу, если ранее активный целевой объект более не находится в новой реферальной ссылке. Это может произойти, например, при удалении из пространства имен целевого объекта, к которому обращался клиент.

Процесс создания корневой папки и ссылок

При первом создании пространства имен DFS необходимо указать общую папку, которая будет использоваться в качестве корневой папки. При добавлении ссылок в пространство имен DFS для каждой ссылки создает под корневой папкой специальную папку, называемую папкой ссылок (Link Folder). Иерархия корневой папки и папок ссылок в локальном хранилище корневого сервера соответствует фактическому пространству имен. Если вы создадите ссылку с помощью формата FolderNameFolder NameLink Name, DFS создаст иерархию пустых папок, а затем создаст папку ссылок. Корневые папки и папки ссылок показаны на следующем рисунке.

При создании ссылки DFS проверяет, отображается ли папка с тем же именем, что и ссылка, в корневом каталоге. Затем DFS выполняет одно из следующих действий:

• Если папка не существует, DFS создает папку ссылок и устанавливает точку повторного анализа для этой папки.
• Если существует пустая папка с тем же именем, что и ссылка, DFS устанавливает точку повторного анализа для этой папки.
• Если существует непустая папка с тем же именем, что и ссылка, DFS переименовывает непустую папку, создает новую папку ссылок и устанавливает точку повторного анализа в этой папке. Переименование происходит в в DFS.GUIDLinkName, например DFS.cf13c05f-5c10-4879-9acb-04ced8f46c7aTemplates, где cf13c05f-5с10-4879-9acb-04ced8f46c7a — это GUID и Templates — имя ссылки.

Точки повторного анализа, установленные в папках ссылок, препятствуют хранению данных в папках ссылок и не позволяют администраторам удалять папки ссылок с помощью традиционных методов, таких как проводник Windows или командная строка. Если администратору необходимо удалить папку ссылок, он может использовать Dfsutil.exe, чтобы удалить все точки повторного анализа DFS в указанной корневой папке, а затем удалить ссылку с помощью инструментов DFS. При запуске службы DFS она проверяет правильность настройки папок ссылок и при необходимости повторно создает папки ссылок и точки повторного анализа. Также она очищает устаревшие точки повторного анализа, которые больше не являются частью какого-либо пространства имен.

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

Как DFS обнаруживает изменения

Чтобы обеспечить клиентам актуальное представление пространства имен, служба DFS должна поддерживать единую версию пространства имен на всех корневых серверах. Изменение пространства имен может включать в себя:

• Добавление, изменение или удаление корневых объектов, ссылок и целевых объектов.
• Изменение параметров пространства имен, включая время жизни корней и ссылок, метод выбора цели (например, переход на наименее дорогой или односайтовый выбор цели), включение режима масштабируемости корня и т. д.
• Включение или отключение ссылки на целевой объект.

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

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

Изменения, внесенные в автономное пространство имен, немедленно обновляются в метаданных DFS в реестре корневого сервера и в кэше метаданных в памяти корневого сервера. Поэтому автономные корневые серверы всегда предоставляют клиентам обновленные ссылки.

С клиентами ситуация сложнее. Они не запрашивают новые реферальные ссылки до тех пор, пока срок действия старых не истечет или они не будут принудительно удалены из кэша. Для автономных пространств имен срок жизни (Time to Live) корневой реферальной ссылки составляет 5 минут, обычной — 30 минут. Это значения по умолчанию, при необходимости их можно изменить в настройках пространства имен.

До выхода Windows XP SP2 и Windows Server 2003 SP1 в работе клиента DFS присутствовал баг: срок жизни для реферальной ссылки определял время до момента, когда клиент запросит новую ссылку, но только в том случае, если срок действия существующей ссылки истекал до повторного обращения к целевому объекту. В результате клиенты, использующие кэшированную ссылку, постоянно продлевали ее время жизни и, таким образом, могли использовать ссылку практически бесконечно. Для обновления ссылки необходимо было либо принудительно очистить кэш клиента, либо перезапустить сам клиент DFS.

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

В доменном пространстве имен

Для доменных пространств имен процедура изменения является более сложной, поскольку метаданные DFS хранятся в нескольких расположениях. Метаданные DFS хранятся в объекте DFS в Active Directory на каждом контроллере домена, а также в кэше на корневых серверах. Чтобы убедиться, что все корневые серверы вовремя обнаруживают изменения в пространстве имен, DFS использует два метода поддержания корневых серверов в актуальном состоянии:

• Уведомление корневого сервера.
• Периодический опрос контроллера домена с ролью эмулятора PDC.

Уведомление корневого сервера

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

Уведомление корневого сервера работает следующим образом:

Администратор запускает инструмент администрирования DFS (графическую оснастку, утилиту командной строки или командлет PowerShell) и вносит изменения в пространство имен. Инструмент, используемый администратором, подключается к ближайшему корневому серверу этого пространства имен. Корневой сервер обращается к контроллеру домена с ролью эмулятора PDC и обновляет метаданные DFS в Active Directory, а затем отправляет уведомление об изменении всем остальным корневым серверам, на которых размещается пространство имен.

Когда корневые сервера получают уведомление, они запрашивают с эмулятора PDC обновленную версию метаданных DFS. Если же корневой сервер не получит сразу уведомления об изменении, к примеру из за временной недоступности, то он запросит изменения с эмулятора PDC в следующем интервале опроса (по умолчанию каждый час).

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

Периодический опрос эмулятора PDC

По умолчанию корневые сервера опрашивают контроллера домена с ролью эмулятора PDC во время следующих событий:

• При запуске корневого сервера или перезапуске службы DFS.
• При вызове API DFS. Например команда Dfscmd /view \dfsnamedfsshare /full заставляет корневой сервер опрашивать мастера эмулятора PDC.
• Периодически, с интервалом, указанным в записи реестра SyncIntervalInSeconds на корневом сервере, который по умолчанию равен одному часу.

Если эмулятор PDC недоступен, то корневой сервер обратится к ближайшему контроллеру домена. И если объект DFS уже реплицировался с эмулятора PDC, то корневой сервер получит обновленную версию метаданных.

Когда изменения в доменных пространствах имен отражаются в ссылках

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

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

Где хранится	Тип реферала	Период по умолчанию	Где хранится значение периода
Контроллер домена	Корневой (Root)	15 минут	Параметр реестра RootReferralTimeoutInSeconds
Корневой сервер	Корневой (Root) l	15 минут	Параметр реестра RootReferralTimeoutInSeconds
Клиент DFS	Корневой (Root)	5 минут	Настройка DFS Time to Live of root
Клиент DFS	Ссылочный (Link)	30 минут	Настройках DFS Time to Live of link

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

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

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

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

Режим масштабируемости корня (Root Scalability Mode)

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

Режим масштабируемости уменьшает сетевой трафик к эмулятору PDC за счет более быстрого обновления всех корневых серверов. Обновления по-прежнему вносятся в объект DFS в Active Directory на эмуляторе PDC, но корневые сервера не получают эти изменения до тех пор, пока обновленный объект DFS не реплицируется на ближайший (для каждого корневого сервера) контроллер домена. После включения режима масштабируемости клиенты могут иметь несогласованное представление пространства имен до тех пор, пока самая последняя версия объекта DFS не будет реплицирована на все контроллеры домена, а корневые серверы DFS не опросят ближайшие контроллеры домена, чтобы получить изменения.

Режим масштабируемости корня не полностью исключает трафик на эмулятор PDC. Он используется следующим образом:

• Изменения в пространстве имен по-прежнему вносятся на эмуляторе PDC.
• Если ближайшим контроллером домена является эмулятор PDC, то корневой сервер будет запрашивать изменения с него.
• Когда служба DFS запускается на корневом сервере (например, при перезагрузке), первоначально она опрашивает эмулятор PDC, и только на следующем интервале опроса обращается к ближайшему контроллеру домена, чтобы получить начальную копию метаданных DFS. Это происходит потому, что параметр масштабируемости корня хранится в объекте DFS в Active Directory, поэтому при первом запуске корневого сервера он опрашивает эмулятор PDC, определяет, что включен режим масштабируемости, и тогда начинает регулярно опрашивать ближайший контроллер домена.

DFS и автономные файлы

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

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

• Только файлы и программы, указанные пользователями, будут доступны в автономном режиме.
• Все файлы и программы на общей папке будут доступны в автономном режиме.
• Никакие файлы или программы на общей папке не будут доступны в автономном режиме.

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

Как функция автономных файлов интерпретирует пути DFS

Важно знать, что функция автономных файлов не отличает пути DFS от UNC. Это может привести к тому, что в случае недоступности одного целевого объекта клиент может посчитать недоступным все пространство имен. Например, \ContosoPublic является доменным корнем DFS с несколькими корневыми целями и многочисленными ссылками, при этом для автономных файлов все это пространство имен считается как один сервер с именем \Contoso. В результате, если клиент обращается или к целевому объекту в пространстве имен \ContosoPublic, а цель недоступна, он интерпретирует все пространство имен как недоступное, перейдет в автономный режим и попытается открыть локально кэшированные файлы (если они есть). Клиент не сможет получить доступ ни к одному целевому объекту в пространстве имен, пока он не вернется в оперативный режим. Для этого клиент каждые 10 минут будет проверять доступность ресурса. Для ускорения процесса пользователь может использовать диспетчер синхронизации, чтобы попытаться синхронизировать автономные файлы с файлами, хранящимися в сети, либо вернуться в оперативный режим без синхронизации изменений.

Процессы DFS на клиентах

Ну и в заключение рассмотрим процессы DFS на клиентах.

Обновление кэша домена

Клиенты DFS периодически обнаруживают новые домены в своем лесу и в доверенных лесах Active Directory. Для этого клиент каждые 15 минут (по умолчанию) обращается к ближайшему контроллеру своего домена (домена, в котором размещена учетная запись компьютера клиента). Чтобы не перегружать контроллеры домена излишними запросами, ссылки, полученные в процессе обнаружения, хранятся в специальной таблице, называемой кэшем домена или кэшем SPC. Этот процесс позволяет клиентам отличать запросы для полных доменных имен от имен компьютеров.

Процесс обновления доменного кэша на клиентах DFS выглядит следующим образом:

• При запуске клиента DFS служба Workstation вызывает драйвер клиента DFS (Mup.sys) с информацией о NetBIOS и DNS-именах домена, к которому присоединен клиент. Служба также предоставляет имя одного контроллера домена в этом домене. Для примера предположим, что контроллер домена называется ClientDC. Клиент сохраняет информацию о домене, открывает соединение к общей папке IPC$ на контроллере домена (\ClientDCIPC$) и отправляет запрос с пустым именем на получение списка доверенных доменов.

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

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

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

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

Клиенты DFS по умолчанию запрашивают новые ссылки на доменные имена и контроллеры доменов каждые 15 минут. Этот интервал можно настроить с помощью записи реестра DfsDcNameDelay на клиенте. Ссылки на доменные имена и контроллеры домена остаются в кэше домена клиента до тех пор, пока клиент не получит обновленные ссылки или клиентский компьютер не будет перезапущен.

Примечание. Без актуальных ссылок на доменные имена и контроллеры домена клиенты не смогут получить доступ к доменным пространствам имен. Эта проблема может возникнуть, когда клиенты входят в систему с помощью кэшированных учетных данных. Проблемы DNS также могут привести к отсутствию у клиента ссылок.

Если организация имеет большое количество доверенных доменов и лесов, возможно, что клиенты не смогут получить доступ ко всем доменным пространствам имен. Если клиент может получить доступ к целевому объекту в другом доверенном домене или доверенном лесу по пути UNC целевого, то он должен получить доступ к целевому объекту по пути DFS, но только в том случае, если список доменов помещается в буфер клиента. По умолчанию клиенты DFS отправляют 4-килобайтный буфер (2048 символов Юникода) контроллеру домена при запросе ссылок на доменные имена. Если список доменов слишком велик, чтобы поместиться в 4КБ, клиенты автоматически увеличивают размер буфера, максимум до 56КБ.

Если список доменов превышает 56 КБ, DFS помещает в буфер столько доменов, сколько сможет. Затем DFS записывает запись с ID 14536 в системный журнал контроллера домена, предоставившего ссылку на домен. При заполнении буфера DFS отдает предпочтение локальным и явно доверенным доменам, заполняя буфер сначала их именами. Следовательно, создавая явные доверительные отношения с доменами, в которых размещаются важные пространства имен DFS, можно свести к минимуму вероятность того, что эти доменные имена могут быть удалены из списка, возвращаемого клиенту.

Примечание. Чтобы убедиться, что клиенты могут получить доступ к целевым объектам в других доверенных доменах и лесах, используйте DNS-имена для всех целевых объектов и настройте DFS на использование полных доменных имен в ссылках.

Обновление кэша MUP

Когда клиент под управлением Windows пытается перейти по пути UNC, система отправляет запрос драйверу Mup.sys, чтобы определить, кто из перенаправителей должен обрабатывать путь. Когда Mup.sys получает запрос, он определяет, находится ли путь в пространстве имен DFS и если это так, то передает запрос в DFS. Если путь является общей папкой или, например, папкой WebDAV, Mup.sys проверяет свой внутренний кэш, известный как кэш MUP, чтобы определить, были ли по этому пути соединения раньше. Затем Mup.sys отправляет каждому перенаправителю запрос. Перенаправители пытаются идентифицировать в сети ресурс, соответствующий этому пути, и возвращают ответ. Получив ответы Mup.sys выбирает тот перенаправитель, который будет использоваться приложением для доступа к объекту.

Обновление кэша ссылок

Когда пользователь пытается получить доступ к корневой или обычной ссылке DFS, клиент запрашивает реферальную ссылку на сервере DFS или контроллере домена, в зависимости от типа ссылки. Сервер DFS помещает ссылку в буфер размером 4 КБ (2048 символов Юникода) и возвращает буфер клиенту. Если пути целевых объектов настолько длинны, что буфер объемом 4 КБ не может вместить даже один целевой объект, DFS устанавливает для запроса клиента больший лимит ответа (до 56 КБ).

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

• Клиентский компьютер будет перезагружен, что приведет к очистке кэша ссылок.
• Пользователь вручную очистит кэш ссылок, например командой Dfsutil.exe с параметром /pktflush.
• Целевой сервер станет недоступным.
• Истекает время жизни реферальной ссылки. По умолчанию Windows использует значение времени жизни, равное 300 секундам (5 минутам) для корневых и 1800 секундам (30 минутам) для обычных ссылок.

После любого из этих событий клиент получит новую ссылку при следующей попытке доступа. Если клиент осуществляет доступ к целевому объекту в течение времени жизни ссылки, то ее время жизни продлевается и клиент не запрашивает новую ссылку. Если же значение времени жизни не обновляется, то оно уменьшается на 4 минуты (240 секунд) до тех пор, пока не достигнет нуля. Если значение времени жизни установлено меньше 240 секунд, срок действия ссылки не истечет в течение 240 секунд.

На этом закончим с процессами. Надеюсь получилось не очень скучно 🙂 А в следующей статье приступим к использованию полученных знаний на практике.

Источник

Введение

Поскольку в сетях широко распространены общие файлы, администраторы все чаще сталкиваются с проблемами при предоставлении доступа пользователям к необходимым им данным. В операционной системе Windows 2000 распределенная файловая система предоставляет администраторам механизм для создания логических представлений каталогов и файлов независимо от того, где эти файлы физически находятся в сети. Кроме того, благодаря использованию DFS обеспечивается отказоустойчивость сетевых ресурсов хранения. В этом руководстве описано, как использовать мастер создания нового корня DFS (New DFS Root Wizard), а также другие средства для работы с DFS.

Предварительные условия

В примерах, приведенных в этом документе, подразумевается, что уже сконфигурирована и используется служба каталогов Active Directory, и у Вас имеются права администратора домена и сервера, на котором будет конфигурироваться DFS. Для этой цели Вы можете воспользоваться базовой инфраструктурой, описанной в
Пошаговом руководстве по развертыванию базовой инфраструктуры Windows 2000 Server (Step-by-Step Guide to a Common Infrastructure for Windows 2000 Server Deployment)
http://www.microsoft.com/windows2000/techinfo/planning/server/serversteps.asp
(EN).

Использование оснастки Распределенная файловая система DFS

В этом пошаговом руководстве описывается, как использовать оснастку
Распределенная файловая система DFS (Distributed File System). Хотя установка службы DFS производится автоматически при установке ОС Windows 2000 Server, Вы должны сконфигурировать DFS для обеспечения доступа клиентов к общим сетевым ресурсам. Для выполнения этих процедур Вам необходимо войти на контроллер домена под учетной записью администратора домена.

В операционной системе Windows 2000 распределенная файловая система может быть интегрирована со службой каталогов Active Directory для обеспечения отказоустойчивости корней DFS, располагающихся как на контроллерах домена Windows 2000 так и на рядовых серверах. Если в Вашем домене Windows 2000 имеется несколько серверов, любое количество этих серверов может использоваться в качестве хостов для обеспечения отказоустойчивости конкретного корня DFS. Служба каталогов Active Directory используется для обеспечения совместного использования контроллеров домена в общей топологии DFS, обеспечивая таким образом избыточность и отказоустойчивость.

Вы можете также создать изолированный сервер DFS, однако, при этом Вы не получите преимуществ службы каталогов Active Directory, и не будет обеспечена отказоустойчивость корневого уровня. Контроллер домена может быть несущим только для одного корня DFS, но в действительности нет ограничений на количество корней DFS в каждом домене. Каждый корень DFS могут поддерживать до 32 контроллеров домена. В домене может поддерживаться несколько корневых томов DFS. Дополнительные компьютеры, которые поддерживают корневые или дочерние узлы (ссылки), позволяют улучшить распределение нагрузки, повысить отказоустойчивость и обеспечить обслуживание сетевых клиентов на основе их принадлежности определенным сайтам сети. Ссылки DFS, указанные в корне, задаются с помощью UNC-пути, доступного для сервера и клиентов DFS.

В этом руководстве Вам будет предложено создать отказоустойчивый корень DFS.

Начало работы с DFS

1.	Нажмите кнопку Пуск (Start), выберите Программы (Programs), перейдите в раздел Администрирование (Administrative Tools) и выберите Распределенная файловая система DFS (Distributed File System).
2.	Щелкните правой кнопкой мыши на корневом элементе Распределенная файловая система DFS (Distributed File System), расположенном на левой панели, и нажмите Создать корень DFS (New DFS Root). Отобразится Мастер создания нового корня DFS (New DFS Root Wizard). Для продолжения нажмите кнопку Далее (Next).
3.	Убедитесь, что переключатель установлен в позицию Создание корень DFS в домене (Create a domain DFS root), и нажмите кнопку Далее (Next) для продолжения.
4.	Выберите несущий домен для корня DFS (в нашем примере это домен reskit.com) и нажмите кнопку Далее (Next) для продолжения. Рисунок 1 – Выбор несущего домена для корня DFS
5.	Выберите несущий сервер для этого корня DFS. В нашем примере это сервер HQ-RES-DC-01.Reskit.com. Нажмите кнопку Далее (Next) для продолжения.
6.	Укажите общую папку, которая будет использоваться в качестве целевой для этого корня DFS. Установите переключатель в положение Создать новый общий ресурс (Create a new share), введите путь к этой общей папке (в нашем случае это c:dfsbooks) и укажите имя этой общей папки – Books. Оснастка Распределенная файловая система DFS (Distributed File System) позволит Вам создать новый каталог и настроить для него общий доступ, если ранее это не было сделано. Рисунок 2 – Выбор общей папки для корневого тома DFS
	Нажмите кнопку Далее (Next). Если указанная папка не существует, то Вам будет задан вопрос о необходимости ее создания. Нажмите кнопку Да (Yes) для продолжения. По желанию Вы можете ввести комментарий с описанием этого корня. Для продолжения нажмите кнопку Далее (Next).
8.	Нажмите кнопку Готово (Finish) для создания корня DFS. После завершения работы мастера создания нового корня DFS (Create New DFS Root Wizard) Вы можете приступать к администрированию Вашего корня DFS.

Если у Вас имеется несколько контроллеров домена, обеспечивающих отказоустойчивость DFS, помните, что для отказоустойчивости DFS используется служба каталогов Active Directory, которая хранит сведения о топологии. Следовательно, необходимо, чтобы сведения о топологии реплицировались между контроллерами домена. Обновление конфигурации DFS изначально производится на одном из серверов домена Windows 2000, который содержит корень DFS. Различные контроллеры домена могут содержать различные данные о текущем состоянии конфигурации DFS, пока мастером репликации не будут реплицированы сведения об изменениях конфигурации DFS между всеми контроллерами доменов. Корень DFS и все его ссылки хранятся в виде единого элемента, имеющего тип – большой бинарный объект (Binary Large Object, BLOB). После осуществления изменений в этом большом бинарном объекте, необходимо выполнение репликации всего бинарного объекта целиком так, чтобы эти изменения были отражены на всех контроллерах домена в домене.

Репликация данных между двумя контроллерами домена, расположенными в пределах одного сайта занимает около пяти минут, и как минимум 15 минут для контроллеров домена, находящихся в различных сайтах. Пока репликация не будет выполнена, конфигурация DFS , отображаемая с помощью оснастки Распределенная файловая система DFS (Distributed File System)на различных клиентах, может различаться. Вы можете воспользоваться кнопкой
Обновить (Refresh) для обновления отображаемых сведений о текущем состоянии хоста DFS.

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

Для публикации нелокальной общей папки

1.	Щелкните правой кнопкой мыши на созданном Вами корневом объекте DFS и затем нажмите Создать ссылку DFS (New DFS Link).
2.	Щелкните правой кнопкой мыши на объекте \Reskit.comBooks.
3.	Нажмите Создать ссылку DFS (New DFS Link).
4.	Определите каталог для данной ссылки. В нашем примере названием ссылки будет ART. Укажите действительный UNC-адрес общей папки Windows 2000, находящейся в Вашей сети, в поле Переадресовать пользователя на эту общую папку (Send the user to this network path). Для этих целей можно также воспользоваться кнопкой Обзор (Browse). В нашем примере используется общая папка Architecture, расположенная на сервере BR3-VAN-SRV-01, который входит в домен Vancouver. Примечание. Эта общая папка была предварительно создана для этого упражнения. Рисунок 3 – Выбор общей папки
5.	Нажмите кнопку OK. Вы можете опционально указать комментарий и значение таймаута. Значение таймаута определяет число секунд, на которое клиентами кэшируется указатель, и по истечении которого они должны будут обновить указатель с одного из несущих DFS-серверов. Рисунок 4 – Добавление второй DFS-ссылки
6.	Если имеется несколько серверов для конфигурирования (например, на двух серверах, один из которых находится в Хартфорде, а второй – в Сиэтле, содержится идентичная информация), то Вы можете добавить их для этого набора реплик. Для этого на значке общей папки, опубликованной в корневом DFS, щелкните правой кнопкой мыши и нажмите Создать реплику (New Replica).
7.	Выберите общую папку \ReskitBR2-RES-SRV-01Engineering Diagrams и нажмите кнопку OK.
8.	Нажмите OK еще разок.
9.	Щелкните правой кнопкой мыши на подключенной ссылке и нажмите Политика репликации (Replication Policy). Выберите каждую общую папку и нажмите кнопку Подключить (Enable), затем нажмите кнопку OK.

Примечание
. Для возможности использования репликации общие папки корня или ссылок DFS должны располагаться на томах NTFS 5.0, находящихся на контроллере домена Windows 2000 или на рядовых серверах. Флагом
Основной (Primary) помечены конкретные файлы и папки серверов, указанные для принудительной начальной репликации, после выполнения которой будут осуществляться штатные репликации.

alt
Рисунок 5 – Политика репликации

На рисунке, представленном ниже, изображена оснастка DFS после выполнения описанных процедур.

alt
Рисунок 6 – Корень DFS

Проверка механизма DFS

Любой пользователь, вошедший в домен Windows 2000, теперь сможет получить доступ к отказоустойчивой распределенной файловой системе. Полагая, что у него имеются соответствующие права, он может настроить индивидуальные подключения, выполнив следующую процедуру:

Нажмите
Пуск (Start), выберите
Выполнить (Run), в текстовом поле
Открыть (Open) введите
cmd и затем нажмите
OK.

Затем введите следующую команду:

NET USE driveletter:
\имя
_Вашего_доменаимя_Вашей_общей_папки_DFS

Для примера, рассматриваемого в этом документе, необходимо выполнить следующие команды:

NET USE J: \RESKIT.COMBOOKS J: DIR

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

Чтобы получить доступ к корню DFS с помощью Проводника (Windows Explorer)

Нажмите
Пуск (Start), нажмите
Выполнить (Run) и введите

\reskit.combook в текстовом поле
Открыть (Open) и нажмите
OK.

Щелкнув правой кнопкой мыши по отображенной на панели обозревателя ссылке, выбрав
Свойства (Properties), Вы можете перейти на вкладку
DFS диалогового окна
Свойства (Properties) для просмотра следующей информации:

•	Список серверов, поддерживающих корень DFS или ссылку.
•	Сервер, к которому подключен DFS-клиент.
•	Кнопка Очистить журнал (Clear History) позволяет сбросить таблицу PKT (Partition Knowledge Table), чтобы в следующий раз заново получить сведения о доступной части пространства имен DFS.

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

Примечание
. В данное время, DFS поддерживает службу кластеров (Microsoft Cluster Service), используя только DFS на основе отдельных компьютеров, поэтому Вы не можете создать отказоустойчивую топологию DFS, работающую в кластере, поскольку кластер выступает в роли единого компьютера.

Репликация

Если Вы используете отказоустойчивую распределенную файловую систему в окружении, в котором имеется множество контроллеров домена, важно определить время, которое необходимо для выполнения репликации данных между контроллерами домена, требуемое для конкретной конфигурации DFS. Для немедленной репликации Вам понадобиться инструмент
REPLMon, который Вы можете установить из папки
supporttools, находящейся на компакт-диске Windows 2000 Server.

Клиенты, которые до сих пор используют ранние версии операционных систем (например, Windows NT 4.0), и которым необходимо использовать возможности DFS, не смогут воспользоваться отказоустойчивостью корня DFS. Однако, такие клиенты могут напрямую подключаться к конкретным корням DFS, которые входят в состав отказоустойчивой распределенной файловой системы. В таком случае при использовании команды
Net use необходимо заменить имя домена на имя конкретного компьютера.

Рабочие станции, работающие под управлением Windows NT и использующие DFS, могут также определить, какую общую папку они используют в текущий момент. Для этого необходимо воспользоваться вкладкой
DFS, находящейся в диалоговом окне
Свойства (Properties) общей папки в проводнике (Windows Explorer).

Примечание.
Большинство административных функций могут быть выполнены из командной строки или с помощью файла-сценария с использованием утилиты DFSCMD.EXE. Введите в командной строке
DFSCMD /? для получения краткой справки по команде.

alt

Рисунок 7 – Просмотр свойств DFS

При необходимости Вы всегда можете изменить свойства этого объекта.

Также Вы можете опубликовать Ваш отказоустойчивый DFS корень, как общую папку в Active Directory, и получать к ней доступ с использованием обозревателя службы каталогов. Откройте оснастку
Active Directory – пользователи и компьютеры (Active Directory Users and Computers), щелкните правой кнопкой мыши на объекте Вашего домена, нажмите
Создать (New) , выберите опцию
Общие папки (Shared Folders) и введите соответствующую информацию.

Автор: Александр Пидодня aka Архимед
Иcточник: (переведено с англ.)
Microsoft Technet

Взято с:
oszone.ru

Внимание!

Читайте другие интересные статьи на эту тему в разделе ‘Статьи и Книги’.

Так же в разделе ‘Полезное’ много интересной информации

Оцените статью: Голосов

Источник

Распределенная файловая система 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

RSAT-DFS-Mgmt-Con– mmc консоль управления службами DFS — DFS Management Tools (также входит в состав Remote Server Administration Tools для Windows 10)

Настройка пространства имен 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 каталогам видели только те каталоги, к которым у них имеется доступ, включим для данного пространства DFS Access-Based Enumeration (подробнее о данной технологии в статье Access-Based Enumeration в Windows). Для этого откройте окно свойств созданного пространства имен.

И на вкладке 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 (файловые системы ReFS и FAT не поддерживаются). Также не поддерживается репликация данных, хранящихся на on Cluster Shared Volumes

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

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

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

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

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

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

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

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

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

Источник

Технологии 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-R:

1. DFS Replication: Frequently Asked Questions (FAQ)

2. Microsoft’s Support Statement Around Replicated User Profile Data

3. Документация http://technet.microsoft.com/en-us/library/jj127250.aspx

4. DFS Replication Improvements in Windows Server 2012

Filed under: Windows | Tagged: DFS, DFS-R, Distributed File System, Windows |

Источник

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

Принцип работы Dfs

Настройка Dfs

Такие разные корни

Настройка дублирования на основе Dfs

Настройка перенаправления в Dfs

Зачем?

Как?

Процесс перенаправления (Referral Process)

Вход в систему

Определение сайта

Выбор целевого объекта

Отработка отказа

Процесс создания корневой папки и ссылок

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" loading="lazy" src="https://windowsnotes.ru//wp-content/uploads/2020/06/dfs18.png" alt="процесс создания ссылок" width="720" height="210" />

Как DFS обнаруживает изменения

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

В доменном пространстве имен

Режим масштабируемости корня (Root Scalability Mode)

DFS и автономные файлы

Процессы DFS на клиентах

Обновление кэша MUP

Обновление кэша ссылок

Введение

Предварительные условия

Использование оснастки Распределенная файловая система DFS

Начало работы с DFS

Проверка механизма DFS

Репликация

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

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

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

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

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

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

Репликация

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