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

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

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

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

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

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

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

 

 

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

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

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

3. Клиент проверяет свой реферальный кэш на наличие самого длинного совпадения с предыдущей реферальной ссылкой. Это может быть корневая (напр. \\Contoso.com\Public) или обычная реферальная ссылка (напр. \\Contoso.com\Public\Software). Если клиент находит требуемое совпадение, то он переходит к шагу 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, для чего вводит в проводнике адрес, например \\Software\Public\Antivirus.

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

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

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

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

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

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

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

В Active Directory не существуют объекты DFS для этих общих папок, вместо этого контроллер домена просто знает, что он должен отвечать на запросы вида \\DomainName\Sysvol и \\DomainName\Netlogon. Эти ссылки отличаются тем, что, хотя целевые объекты размещены на контроллере домена, сами они не являются корнями 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 истекает срок действия реферальной ссылки и в новой ссылке предыдущий активный целевой объект отсутствует.

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

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

• Отработка отказа 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). Иерархия корневой папки и папок ссылок в локальном хранилище корневого сервера соответствует фактическому пространству имен. Если вы создадите ссылку с помощью формата FolderName\Folder Name\Link 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 \\dfsname\dfsshare /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. Это может привести к тому, что в случае недоступности одного целевого объекта клиент может посчитать недоступным все пространство имен. Например, \\Contoso\Public является доменным корнем DFS с несколькими корневыми целями и многочисленными ссылками, при этом для автономных файлов все это пространство имен считается как один сервер с именем \\Contoso. В результате, если клиент обращается или к целевому объекту в пространстве имен \\Contoso\Public, а цель недоступна, он интерпретирует все пространство имен как недоступное, перейдет в автономный режим и попытается открыть локально кэшированные файлы (если они есть). Клиент не сможет получить доступ ни к одному целевому объекту в пространстве имен, пока он не вернется в оперативный режим. Для этого клиент каждые 10 минут будет проверять доступность ресурса. Для ускорения процесса пользователь может использовать диспетчер синхронизации, чтобы попытаться синхронизировать автономные файлы с файлами, хранящимися в сети, либо вернуться в оперативный режим без синхронизации изменений.

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

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

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

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

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

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

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

 

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