From Wikipedia, the free encyclopedia
This article is about Microsoft’s implementation of DFS. For general discussion of the concept and other implementations, see Distributed file system.
Distributed File System (DFS) is a set of client and server services that allow an organization using Microsoft Windows servers to organize many distributed SMB file shares into a distributed file system. DFS has two components to its service: Location transparency (via the namespace component) and Redundancy (via the file replication component). Together, these components enable data availability in the case of failure or heavy load by allowing shares in multiple different locations to be logically grouped under one folder, the «DFS root».
Microsoft’s DFS is referred to interchangeably as ‘DFS’ and ‘Dfs’ by Microsoft and is unrelated to the DCE Distributed File System, which held the ‘DFS’ trademark[1] but was discontinued in 2005.
It is also called «MS-DFS» or «MSDFS» in some contexts, e.g. in the Samba user space project.[2]
Overview[edit]
There is no requirement to use the two components of DFS together; it is perfectly possible to use the logical namespace component without using DFS file replication, and it is perfectly possible to use file replication between servers without combining them into one namespace.
A DFS root can only exist on a server version of Windows (from Windows NT 4.0 and up) and OpenSolaris[3] (in kernel space) or a computer running Samba (in user space.) The Enterprise and Datacenter Editions of Windows Server can host multiple DFS roots on the same server. OpenSolaris intends on supporting multiple DFS roots in «a future project based on Active Directory (AD) domain-based DFS namespaces».[4]
There are two ways of implementing DFS on a server:
- Standalone DFS namespace — allows for a DFS root that exists only on the local computer, and thus does not use Active Directory. A Standalone DFS can only be accessed on the computer on which it is created. It does not offer any fault tolerance and cannot be linked to any other DFS. This is the only option available on Windows NT 4.0 Server systems. Standalone DFS roots are rarely encountered because of their limited utility.
- Domain-based DFS namespace — stores the DFS configuration in Active Directory, making the DFS namespace root accessible at
\\<domainname>\<dfsroot>
or
\\<FQDN>\<dfsroot>
The namespace roots can reside on a domain controller or a domain member server. If domain controllers are not used as the namespace root servers, multiple member servers should be used to provide full fault tolerance.
DFS namespaces[edit]
Traditional file shares, associated with a single server, have SMB paths of the form
\\<SERVER>\<path>\<subpath>
Domain-based DFS file share paths are distinguished by using the domain name in place of the server name, in the form
\\<DOMAIN.NAME>\<dfsroot>\<path>
When a user accesses such a share, either directly or by mapping a drive, their computer will access one of the available servers associated with that share, following rules which can be configured by the network administrator. For example, the default behaviour is that users will access the closest server to them; but this can be overridden to prefer a particular server.
If a server fails, the client can select a different server transparently to the user. One major caveat regarding this flexibility is that currently-open files will potentially become unusable, as open files cannot be failed-over.
DFS replication[edit]
Early versions of DFS used Microsoft’s File Replication Service (FRS) which provides basic file replication capability between servers. FRS identifies changed or new files, and copies the latest version of the entire file to all servers.
Windows Server 2003 R2 introduced «DFS Replication» (DFSR) which improves on FRS by only copying those parts of files which have changed (remote differential compression), by using data compression to reduce network traffic, and by allowing administrators flexible configuration options for limiting network traffic with a customizable schedule.
History[edit]
The server component of Distributed File System was first introduced as an add-on to Windows NT 4.0 Server, called «DFS 4.1»,[5] and was later included as a standard component of all editions of Windows 2000 Server.
Client-side support is included in Windows NT 4.0 and later versions of Windows.
Linux kernels 2.6.14 and later[6] come with an SMB client VFS called «cifs» that supports DFS.
On Mac OS X DFS is supported natively in Mac OS X 10.7 («Lion») onward.[7]
Specifications[edit]
There are a number of specifications that are relevant to DFS, they are available through the Microsoft Open Specifications program:[8]
- [MS-DFSC]: Distributed File System (DFS): Referral Protocol
- Specifies the Distributed File System (DFS): Referral Protocol, which enables file system clients to resolve names from a namespace distributed across many servers and geographies into local names on specific file servers.
- [MS-DFSNM]: Distributed File System (DFS): Namespace Management Protocol
- Specifies the Distributed File System (DFS): Namespace Management Protocol, which provides an RPC interface for administering DFS configurations. The client is an application that issues method calls on the RPC interface to administer DFS. The server is a DFS service that implements support for this RPC interface for administering DFS.
- [MS-DFSRH]: DFS Replication Helper Protocol
- Specifies the DFS Replication Helper Protocol, which is made up of a set of distributed component object model (DCOM) interfaces for configuring and monitoring DFS Replication Helper Protocols on a server.
See also[edit]
- List of Microsoft Windows components
- Comparison of distributed file systems
References[edit]
- ^ «Dfs vs. DFS». Archived from the original on 2016-03-03. Retrieved 2014-02-02.
- ^ «smb.conf man page, section host msdfs». Retrieved 2018-03-07.
- ^ «PSARC/2009/534 SMB/CIFS Standalone DFS». Archived from the original on 2010-06-15. Retrieved 2010-03-27.
- ^ Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Micro-systems
- ^ «DFS: When, Why, and How». Archived from the original on August 25, 2005.
- ^ «LinuxCIFS utils — SambaWiki». Wiki.samba.org. Retrieved 2013-07-08.
- ^ «OS X Lion: Guidelines for connecting to a DFS namespace via SMB». 2014-07-15. Retrieved 2016-12-06.
- ^ «[MS-OPENSPECLP]: Open Specifications | Microsoft Docs». Microsoft. Retrieved 2020-10-22.
External links[edit]
- How DFS Works: Remote File Systems
Распределенная файловая система 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. Архитектура и базовые понятия
Распределенная файловая система (Distributed File System, DFS) — серверная технология Microsoft, предназначенная для упрощения доступа к общим файловым ресурсам, распределенным по сети. С помощью DFS можно объединять в единую логическую структуру файловые ресурсы, физически находящиеся на различных серверах, а также производить между ними репликацию.
DFS — технология не новая древняя как говно мамонта, она известна еще со времен Windows NT. Хотя термины DFS и Distributed File System появились несколько позднее и относятся к Windows 2000 и 2003. А в Windows 2003 R2 компания Microsoft представила новое пространство DFS-имен, а также улучшенный механизм репликации. Новое пространство DFS-имен называется DFS-N (DFS-Namespace), а новый механизм репликации — DFS-R (DFS-Replication). Именно эти две составляющих и образуют на данный момент функционал DFS.
При правильном использовании DFS позволяет решить огромное количество задач. Но технология довольно специфическая, и если не учитывать эту специфику, то можно получить кучу проблем. Поэтому, не откладывая в долгий ящик, приступим к изучению особенностей DFS. Начнем с базовых понятий.
Базовые понятия
Чтобы понимать, как работает пространство имен DFS, разберем основные понятия DFS на следующем примере.
DFS namespace (Пространство имен DFS)
Единый виртуальный каталог, содержащий ссылки на общие папки, расположенные на разных файловых серверах. Пространство имен состоит из корня (root), ссылок (folders) и целевых объектов (folder targets). Пространство имен DFS может быть двух типов: автономное (Standalone) и доменное (Domain-based).
У Standalone DFS namespace сведения о конфигурации хранятся локально на корневом сервере, в системном реестре. Путь для доступа к корневому каталогу или ссылке начинается с имени корневого сервера. Автономное пространство имен располагается только на одном сервере и не является отказоустойчивым. Если корневой сервер недоступен, все пространство имен DFS также становится недоступным.
У Domain-based DFS namespace конфигурация хранится в Active Directory. Путь для доступа к корневому каталогу или ссылке начинается с имени домена. Несмотря на то, что в нашем примере показан только один сервер пространства имен, доменное пространство имен можно размещать на нескольких серверах, чтобы повысить доступность пространства имен. Это позволяет обеспечить отказоустойчивость и распределить нагрузку между серверами.
Namespace root (Корень пространства имен)
Базовая или начальная точка, от которой начинается отсчет пространства имен. В зависимости от типа корень доступен по адресу \\ServerName\RootName (Standalone) или \\DomainName\RootName (Domain-based). В нашем примере корень DFS доступен по адресу \\Contoso\Public.
Namespace server (Сервер пространства имен)
Сервер пространства имен (или корневой сервер) — физический сервер, на котором содержится пространство имен DFS. Сервер пространства имен может быть как рядовым сервером, на котором установлена роль DFS Namespace, так и контроллером домена.
Folder (Папка)
Ссылка в пространстве имен DFS, указывающая на целевую папку (или папки). Папки без конечных объектов (напр. папка Software) образуют структуру и иерархию в пространстве имен, а папки с целевыми объектами-папками (напр. папка Training Guides) предоставляют пользователям доступ к фактическому содержимому. Когда пользователь открывает папку, содержащую конечные объекты-папки в пространстве имен, клиентский компьютер получает направление (referral), которое прозрачно перенаправляет клиентский компьютер к одному из целевых объектов.
Folder targets (Целевой объект-папка)
Ссылка на общий файловый ресурс, находящийся на определенном файловом сервере и доступный по пути UNC (Universal Naming Convention). Например общая папка \\FS2\Training на сервере FS2.
Именно целевой объект-папка является конечной целью пользователя, поскольку в нем находятся нужные ему данные. Одна ссылка может указывать как на один, так и на несколько целевых объектов. К примеру, папка с именем Training Guides имеет один целевой объект-папку, а папке Tools соответствуют два целевых объекта на разных серверах. И при обращении к папке Tools пользователь, в зависимости от своего местонахождения, будет перенаправляться в общую папку \\FS1\Tools или \\FS2\Tools.
Как видно из примера, распределенная файловая система позволяет группировать общие папки, расположенные на различных физических серверах, подключая их к общему пространству имен. С помощью DFS администратор выбирает, какие общие папки должны быть представлены в пространстве имен, формирует иерархию, в которой эти папки отображаются, и определяет имена, отображаемые общими папками в пространстве имен.
Когда пользователь просматривает пространство имен, папки для него отображаются так, как будто все они находятся на одном большом диске большой, и он может свободно перемещаться по ним без необходимости знать имена серверов или адреса общих папок, в которых хранятся данные. Для пользователя весь этот процесс происходит абсолютно прозрачно.
Роли клиента и сервера
Помимо основных понятий DFS важно понимать роли клиента и сервера, участвующие в DFS.
Клиенты DFS
Клиент DFS — это компьютер, использующийся для доступа к пространству имен. Как правило, клиентами являются пользовательские рабочие станции, хотя и компьютеры, работающие под управлением серверных операционных систем Windows, также могут выступать в роли клиента DFS.
Корневые сервера
Корневые сервера, также называемые корневыми целями (Root targets) — физические сервера, на которых хранятся доменные или автономные пространства имен. В качестве корневого сервера DFS может выступать компьютер с серверной ОС, клиентские операционные системы могут быть только клиентами. Корневые серверы играют в DFS следующие роли:
• Для автономных пространств имен метаданные файловой системы DFS хранятся в реестре корневых серверов. Метаданные DFS состоят из информации обо всем пространстве имен, включая корневой каталог, корневые целевые объекты, ссылки, целевые объекты ссылок и параметры. Для доменных пространств имен метаданные DFS хранятся в Active Directory, однако на корневых серверах метаданные DFS также хранятся в оперативной памяти.
• На корневых серверах размещаются корневые папки (root folders) и подпапки (folders), соответствующие ссылкам в пространстве имен DFS.
• Когда клиент пытается получить доступ к корневому каталогу или ссылке в автономном пространстве имен или ссылке в доменном пространстве имен, корневой сервер предоставляет клиенту ссылку.
Контроллеры домена
Контроллеры домена играют важнейшую роль в функционировании DFS:
• Клиенты DFS обращаются к контроллерам домена, чтобы получить список доверенных доменов и контроллеров домена для этих доменов.
• Когда клиент DFS впервые пытается получить доступ к доменному пространству имен DFS, контроллер домена предоставляет клиенту список корневых серверов. Этот список корневых серверов известен как корневое направление (root referral).
• Контроллеры домена хранят метаданные доменных пространств имен. По умолчанию корневые серверы, на которых размещаются доменные пространства имен, периодически опрашивают контроллер домена с ролью PDC Emulator, чтобы получить обновленную версию метаданных DFS и сохранить эти метаданные в памяти.
• Всякий раз, когда администратор вносит изменения в доменное пространство имен DFS, это изменение выполняется на контроллере домена с ролью PDC Emulator, а затем с помощью репликацию Active Directory реплицируется на другие контроллеры домена.
• На контроллерах домена хранится информация о сайтах Active Directory и межсайтовых связях (site links). DFS использует эту информацию при сортировке целевых объектов в порядке наименьшей стоимости. Так в нашем примере папка Tools находится на двух разных серверах, расположенных в двух разных сайтах (London и New York). В зависимости от того, где находится клиент, он получит ссылку на ближайший к нему сервер.
Целевые объекты-папки
Целевые объекты-папки являются ссылками на общие папки (или подпапки внутри общих папок) на файловом сервере. В роли источника ссылки может выступать любая ОС с сетевой файловой системой, к которой можно обратиться через путь UNC, например Windows (SMB) или Linux (NFS). Путь UNC, указанный в ссылке, может вести к общим папкам в любой рабочей группе, общим папкам в том же домене, что и пространство имен, общим папкам в доверенных доменах и общим папкам в доверенных лесах. Также целевой объект может быть путем DFS в другом пространстве имен.
Сами общие папки, указанные в качестве целевых объектов, не имеют специальных параметров, указывающих на то, что они являются частью пространства имен DFS. Все существующие разрешения общей папки и разрешения NTFS на общую папку по-прежнему применяются, когда пользователи получают доступ к общей папке через пространство имен.
Архитектура DFS
С ролями все более менее понятно, переходим к их взаимодействию.
Компоненты архитектуры DFS на клиентах DFS, корневых серверах и контроллерах домена, а также их взаимодействие показаны на следующих рисунках.
На первом рисунке архитектура DFS контроллера домена упрощена, чтобы показать только объект DFS.
На втором рисунке показана архитектура DFS контроллера домена и упрощенное представление архитектуры клиента и корневого сервера DFS.
Обратите внимание, что контроллеры домена и корневые сервера используют похожую архитектуру DFS. Это связано с тем, что контроллеры домена играют определенную роль в направлении клиентских компьютеров к корневым серверам домена. Кроме того, контроллеры домена могут размещать пространства имен и выполнять роль корневого сервера. В этом случае контроллер домена также размещает кэш метаданных DFS (независимо от типа пространства имен) и автономные метаданные DFS в своем реестре (для автономных пространств имен).
Dfssvc.exe
Служба DFS, является ключевым компонентом архитектуры DFS, работает на корневых серверах и контроллерах домена. Основными функциями службы DFS являются обработка ссылок, управление пространствами имен и взаимодействие с драйвером DFS.
DFS Metadata
Метаданные DFS — cведения о пространстве имен DFS. Состоят из информации обо всем пространстве имен, включая корневой каталог, корневые целевые объекты, ссылки, целевые объекты ссылок и параметры. Для доменного DFS метаданные хранятся в Active Directory, в специальном объекте DFS, соответствующем пространству имен. Для автономного пространства имен DFS метаданные хранятся в реестре корневого сервера.
DFS Metadata cache
Кэш метаданных DFS — копия метаданных DFS в оперативной памяти, хранящаяся в Dfssvc.exe на корневых серверах.
Domain-based root referral cache and site caches
Кэш доменных корневых ссылок и сведений о сайте. Содержит копии доменных корневых ссылок и сведений о сайте, хранящиеся в оперативной памяти сервера. Позволяет службе DFS осуществлять быстрый поиск.
Dfs.sys
Драйвер DFS, имеется только в серверных ОС Windows. Он работает в режиме ядра (Kernel Mode) и служит для перенаправления клиентских запросов к службе DFS, работающей в пользовательском режиме (User Mode). Также драйвер обрабатывает ссылки DFS, когда они встречаются во время доступа к файловой системе.
Srv.sys
Драйвер службы SMB. В архитектуре DFS служит для передачи запросов от клиентов DFS к драйверу Dfs.sys.
I/O Manager
Менеджер ввода-вывода отвечает за обработку операций с файлами при перенаправлении UNC-путей в Mup.sys. Является частью ядра ядра (Ntoskrnl.exe) операционной системы.
Mup.sys
Mup (multiple UNC provider) в переводе означает множественный поставщик путей UNC. Mup.sys является сетевым драйвером, который обрабатывает запросы ввода-вывода (I/O) для файла или устройства, доступного по пути UNC. Если UNC путь является ссылкой DFS, Mup.sys разрешает его в физический путь UNC. После разрешения пути Mup.sys выбирает локальный перенаправитель, который будет обрабатывать путь UNC.
Mrxsmb.sys
Для реализации службы предоставления общего доступа в Windows используется протокол CIFS (Common Internet File System). Перенаправитель Mrxsmb.sys обеспечивает взаимодействие между корневыми серверами, контроллерами домена и файловыми серверами Windows, использующими протокол CIFS.
Nwrdr.sys и Mrxdav.sys
Перенаправители для Netware и Web Distributed Authoring and Versioning (WebDAV), соответственно.
Workstation service (Wkssvc.dll)
Передает информацию о контроллере домена и доменном имени в Mup.sys. Эту информацию Mup.sys использует для создания ссылок в доменном кэше клиента. Также Workstation service является компонентом клиента SMB и обеспечивает управление Mrxsmb.sys.
Ntlanman.dll
Сетевой поставщик Windows. Служит для создания и поддержки клиентских сетевых подключений к удаленным файловым ресурсам.
Referral cache
Кэш ссылок, хранит ссылки, полученные клиентом при обращении к пространству имен. Кэш ссылок (также известный как кэш PKT) поддерживается в Mup.sys.
Domain cache
Доменный кэш содержит ссылки на доменные имена и ссылки на контроллеры домена, которые хранятся в памяти на каждом клиентском компьютере. В кэше домена хранятся NetBIOS-и DNS-доменные имена для локального домена, все доверенные домены в лесу, домены в доверенных лесах и сопоставления доменных имен с контроллерами домена. Домен кэша (SPC кэш) также хранится в Mup.sys.
DFS Tools
Основные инструменты для администрирования пространства имен DFS. Сюда входит графическая оснастка Dfsgui.msc, утилита командной строки Dfscmd.exe и утилита Dfsutil.exe, используемая для выполнения расширенных задач DFS.
Netapi32.dll
Содержит API NetDFSxxx, используемые для администрирования удаленных корневых серверов. Также содержит API, используемые для просмотра и очистки кэша ссылок (кэш PKT), кэша домена (кэш SPC) и кэша MUP на клиентах.
Физические структуры DFS и кэши
Теперь копнем поглубже и рассмотрим физические структуры и кэши на контроллерах домена, корневых серверах и клиентах DFS.
Корневые сервера
Физические структуры и кэши на корневом сервере различаются в зависимости от типа пространства имен, в котором размещается корневой сервер (доменный или автономный). Серверы под управлением Windows Server могут содержать несколько автономных и доменных корней.
На следующем рисунке показаны физическая структура и кэш DFS на корневых серверах.
Stand-Alone DFS Metadata in the Registry (Автономные метаданные DFS в реестре)
Автономные метаданные DFS содержат информацию о корне, корневой цели, ссылках, целевых объектах ссылок и параметрах, определенных для каждого автономного пространства имен. Эти метаданные хранятся в реестре корневого сервера по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone.
Корневые серверы доменного пространства имен имеют запись реестра для каждого корня в разделе KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Domain, но эти записи не содержат метаданных DFS на основе домена. При запуске службы DFS на корневом сервере служба проверяет этот путь на наличие записей реестра, соответствующих корням домена. Если эти записи существуют, корневой сервер опрашивает контролллер домена с ролью эмулятора PDC, чтобы получить метаданные DFS для каждого доменного пространства имен и сохраняет эти метаданные в памяти.
DFS Registry Entries (Записи реестра DFS)
DFS поддерживает несколько записей реестра для настройки поведения DFS на корневых серверах. Записи реестра службы DFS находятся в реестре в следующих подразделах:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS\Parameters
Root and Link Folders (Корень и папки ссылок)
Каждый корень и ссылка в пространстве имен имеют физическое представление на томе NTFS на каждом корневом сервере, на котором размещается это пространство имен. Корень DFS соответствует общей папке, известной как корневая папка (Root Folder) на корневом сервере. При использовании инструментов DFS для добавления ссылок в корневой каталог DFS создает специальные папки под каждой корневой папкой. Эти папки, называемые папками ссылок (Link Folders), на самом деле являются точками повторного анализа, и если вы попытаетесь получить к ним доступ на локальном сервере, то получите сообщение об ошибке. Клиенты DFS, которые получают доступ к папкам ссылок по всей сети, перенаправляются на соответствующий целевой объект.
DFS Metadata Cache (Кэш метаданных DFS)
Кэш метаданных DFS на корневых серверах содержит информацию о корне, корневых целевых объектах, ссылках, целевых объектах ссылок и параметрах, определенных в пространстве имен. Для доменных пространств имен эти метаданные хранятся в объекте DFS в Active Directory, для автономных — в реестре корневого сервера.
Этот кэш хранится в оперативной памяти и обновляется каждый раз, когда корневой сервер опрашивает объект DFS в Active Directory (для доменных пространств имен) или реестр (для автономных пространств имен).
Domain-based Root Referral Cache (Корневой реферальный кэш на основе домена)
Когда клиент обращается к доменному корневому серверу напрямую, по адресу \\ServerName\RootName, корневой сервер предоставляет клиенту список корневых объектов домена (Domain-based Root Referral) для данного пространства имен.
По умолчанию корневые серверы хранят эти доменные корневые ссылки в памяти в течение 15 минут. Этот период определяется записью реестра RootReferralTimeoutInSeconds на корневом сервере. Перезапуск службы DFS на корневом сервере приводит к очистке этого кэша. Если корневые целевые объекты добавляются или удаляются, или если в корне изменяются настройки, эти изменения отражаются в доменных корневых ссылках, предоставляемых корневыми серверами, через 15 минут или после очистки кэша.
Корневой реферальный кэш домена не хранит целевые объекты в каком-либо определенном порядке. Целевые объекты сортируются в соответствии с методом выбора целевых объектов по запросу клиента. Кроме того, эти ссылки основаны на метаданных DFS, хранящихся на ближайшем контроллере домена, не только на эмуляторе PDC.
Client Site Cache (Кэш сайта клиента)
Сайт в Active Directory определяет физическое расположение. Когда клиент запрашивает ссылку DFS с корневого сервера, служба DFS на корневом сервере использует информацию о сайте Active Directory, чтобы определить сайт клиента на основе его IP-адреса. DFS хранит эту информацию в кэше клиентского сайта корневого сервера, который содержит сопоставления IP-адресов клиентов с именами сайтов. Этот кэш используется для быстрого определения сайта, к которому принадлежит клиент.
По умолчанию корневые серверы хранят записи в кэше клиентского сайта до 24 часов. Этот период определяется записью реестра SiteSupportIntervalInSeconds (12 часов) на корневом сервере, умноженной на два. Если имя сайта изменяется или клиент перемещается с одного сайта на другой и использует один и тот же IP-адрес, информация о сайте в этом кэше будет устаревать максимум в два раза больше значения записи реестра SiteSupportIntervalInSeconds (24 часа) или до тех пор, пока служба DFS не будет перезапущена на корневом сервере.
Когда процесс очистки начинается после заданного интервала времени, записи обрабатываются следующим образом: если имя сайта, соответствующее клиенту, было доступно с момента последнего процесса очистки, запись обновляется, а если имя сайта, соответствующее клиенту, не было доступно с момента последнего процесса очистки, запись будет удалена.
По умолчанию DFS может хранить 200 000 записей в кэше клиентского сайта. Это ограничение определяется записью реестра MaxClientsToCache.
Target Site Cache (Кэш целевого сайта)
Когда служба DFS запускается на корневом сервере, она собирает сведения о сайте Active Directory для всех целевых объектов-ссылок на основе текущего IP-адреса каждого целевого объекта. Служба DFS также получает информацию о сайте при добавлении новых целевых объектов ссылок. DFS кэширует эту информацию в кэше целевого сайта корневого сервера, который содержит сопоставления имен целевых серверов ссылок с именами сайтов. DFS использует эту информацию для быстрого определения сайта, к которому относится целевая ссылка.
По умолчанию корневые серверы хранят записи в кэше целевого сайта до 24 часов. Этот интервал определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на корневом сервере, умноженным на два. После заданного интервала времени DFS обновляет информацию о сайте в этом кэше. Если имя сайта изменяется или целевой сервер ссылок перемещается с одного сайта на другой, информация о сайте в этом кэше будет устаревать максимум в два раза больше значения записи реестра SiteSupportIntervalInSeconds (24 часа) или до тех пор, пока служба DFS не будет перезапущена.
Site Cost Cache (Кэш стоимости сайта)
В Active Directory есть понятие связи сайтов (site links), которое представляет из себя логическую связь двух или более сайтов, соответствующую физическим каналам связи между сайтами. У каждой связи есть своя стоимость (cost), которая определяет пропускную способность канала связи и, соответственно, затраты на передачу данных между сайтами. Эта информация используется при репликации Active Directory для определения наилучшего маршрута.
Кэш стоимости сайта на корневых серверах DFS содержит сопоставление сайтов с соответствующими сведениями о стоимости, определенными в Active Directory. Кэш стоимости сайта используется для быстрого определения стоимости подключения, связанной с целевыми объектами ссылок, чтобы DFS могла сортировать целевые объекты ссылок в ссылках в порядке наименьшей стоимости.
Служба DFS получает информацию о стоимости сайта для целевых объектов ссылок по мере необходимости, при выполнении запросов на направление клиентов. По умолчанию корневые серверы хранят записи в кэше стоимости сайта до 12 часов. Этот период определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на корневом сервере. Если в Active Directory изменена стоимость связи между двумя сайтами, информация о стоимости сайта в этом кэше будет устаревать максимум в течение записи реестра SiteSupportIntervalInSeconds (12 часов) или до тех пор, пока служба DFS не будет перезапущена.
Запись реестра QuerySiteCostTimeoutinSeconds на корневых серверах также используется для этого кэша, чтобы указать период ожидания для запросов стоимости сайта. По истечении периода ожидания запрос информации о стоимости сайта в Active Directory завершится ошибкой. По умолчанию тайм-аут составляет 30 секунд. Если DFS не может определить стоимость целевого сайта в течение 30 секунд, принимается максимально возможная стоимость для целевого сервера.
Контроллеры домена
Контроллеры домена играют важную роль для доменных пространств имен. Они хранят метаданные DFS для доменных пространств имен и предоставляют ссылки клиентам DFS, чтобы помочь им получить доступ к доменным пространствам имен. Существует ряд физических структур и кэшей, поддерживающих эти процессы; эти структуры и кэши показаны на следующем рисунке.
DFS Object in Active Directory
Объект DFS в Active Directory хранит метаданные DFS для доменного пространства имен. Объект DFS создается при создании корневого каталога домена и Active Directory реплицирует весь объект DFS на все контроллеры домена в домене. Когда клиент запрашивает ссылку для доменного пространства имен, контроллер домена сначала проверяет свой доменный корневой кэш ссылок (описанный далее в этом разделе) на наличие существующей ссылки. Если таковой не существует, контроллер домена находит объект DFS для этого пространства имен и использует метаданные в объекте для создания ссылки.
На следующем рисунке показано расположение объектов DFS в Active Directory. Каждый объект DFS (FTDFS object) соответствует доменному пространству имен.
Каждый объект DFS имеет следующие четыре важных атрибута:
• pKT — двоичное представление метаданных DFS для этого корня.
• pKTGuid — лобальный уникальный идентификатор (GUID) метаданных DFS.
• remoteServerName — перечисляет корневые целевые объекты для корня.
• Security descriptor — дескриптор безопасности, контролирует доступ и определяет, кому разрешено изменять объект DFS.
По поводу размера объекта DFS. При записи метаданных используется приблизительно 400 байт на одну ссылку DFS. Любое изменение пространства имен приводит к тому, что весь объект DFS реплицируется на все контроллеры домена в домене. Для снижения сетевого трафика, возникающего при изменении в пространстве имен, рекомендуется объект DFS для доменного пространства имен ограничить размером в 5МБ (приблизительно 5000 ссылок).
DFS Registry Entries (Записи реестра DFS)
DFS поддерживает несколько записей реестра для настройки поведения DFS на контроллерах домена. Записи реестра DFS находятся в реестре в следующих подразделах:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters
Domain Name Referral Cache (Кэш ссылок доменных имен)
Ссылка на доменное имя содержит NetBIOS и DNS-имена локального домена, все доверенные домены в лесу и домены в доверенных лесах. Клиент DFS запрашивает ссылку на доменное имя у контроллера домена, чтобы определить домены, в которых клиенты могут получить доступ к доменным пространствам имен.
По умолчанию контроллеры домена хранят ссылки на доменные имена в кэше памяти в течение 12 часов; этот период определяется записью реестра DomainNameIntervalinSeconds на контроллере домена. Перезапуск службы DFS на контроллере домена приведет к очистке этого кэша. Если доменное имя изменяется или домены добавляются или удаляются из леса или доверенных лесов, эти изменения отражаются в ссылках на доменные имена через 12 часов или после очистки этого кэша.
Domain Controller Referral Cache (Кэш ссылок контроллера домена)
Ссылка на контроллер домена содержит NetBIOS и DNS-имена контроллеров домена для списка доменов, которые он кэшировал. Клиент DFS запрашивает ссылку на контроллер домена у контроллера домена 🙂 чтобы определить, какие контроллеры домена могут предоставить ссылку для доменного пространства имен.
Контроллеры домена хранят эти ссылки в кэше памяти в течение 10 минут, это значение изменить нельзя. Перезапуск службы DFS на контроллере домена приведет к очистке этого кэша. Если имя контроллера домена изменяется или если контроллеры домена повышаются или понижаются в должности, эти изменения отражаются в ссылках на контроллеры домена через 10 минут или после очистки этого кэша.
Domain-based Root Referral Cache (Корневой реферальный кэш на основе домена)
Корневая ссылка на домен содержит список корневых целевых объектов, в которых размещается данное доменное пространство имен. Контроллеры домена предоставляют корневые ссылки на основе домена клиентам, которые пытаются получить доступ к доменному пространству имен.
По умолчанию контроллеры домена хранят корневые ссылки на основе домена в кэше памяти в течение 15 минут; этот период определяется записью реестра RootReferralTimeoutInSeconds на контроллере домена. Перезапуск службы DFS на контроллере домена приведет к очистке этого кэша. Если корневые целевые объекты добавляются или удаляются, или если в корне изменяются настройки, эти изменения отражаются в доменных корневых ссылках через 15 минут или после очистки этого кэша.
Client Site Cache (Кэш сайта клиента)
Когда клиент запрашивает ссылку от контроллера домена, служба DFS на контроллере домена использует сведения о сайте, определенные в Active Directory, чтобы определить сайт клиента на основе его IP-адреса. DFS хранит эту информацию в кэше клиентского сайта, который содержит сопоставления IP-адресов клиентов с именами сайтов и использует этот кэш для быстрого определения сайта, к которому принадлежит клиент.
По умолчанию контроллеры домена хранят записи в кэше клиентского сайта до 24 часов. Этот период определяется записью реестра SiteSupportIntervalInSeconds (12 часов) на контроллере домена, умноженной на два. Если имя сайта изменяется или клиент перемещается с одного сайта на другой и использует один и тот же IP-адрес, информация о сайте в этом кэше будет устаревать максимум в два раза больше значения записи реестра SiteSupportIntervalInSeconds (24 часа) или до тех пор, пока служба DFS не будет перезапущена на контроллере домена.
Когда процесс очистки начинается после заданного интервала времени, записи обрабатываются следующим образом: если имя сайта, соответствующее клиенту, было доступно с момента последнего процесса очистки, запись обновляется, а если имя сайта, соответствующее клиенту, не было доступно с момента последнего процесса очистки, запись будет удалена.
По умолчанию DFS может хранить 200 000 записей в кэше клиентского сайта. Это ограничение определяется записью реестра MaxClientsToCache.
Target Site Cache (Кэш целевого сайта)
Служба DFS на контроллерах домена использует сведения о сайте, определенные в Active Directory (через API DSAddressToSiteNames), чтобы определить сайт для корневых целевых объектов домена и контроллеров домена на основе их текущих IP-адресов. DFS хранит эту информацию в своем целевом кэше сайтов, который содержит сопоставления имен корневых серверов и контроллеров домена с именами сайтов. DFS использует эту информацию для быстрого определения сайта, к которому принадлежит корневой сервер или контроллер домена.
По умолчанию контроллеры домена хранят записи в кэше целевого сайта до 24 часов. Этот интервал определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на контроллере домена, умноженным на два. После заданного интервала времени DFS обновляет информацию о сайте в этом кэше. Если имя сайта изменяется или корневой целевой объект перемещается с одного сайта на другой, информация о сайте в этом кэше будет устаревать максимум в два раза больше значения записи реестра SiteSupportIntervalInSeconds (24 часа) или до тех пор, пока служба DFS не будет перезапущена на контроллере домена.
Site Cost Cache (Кэш стоимости сайта)
Кэш стоимости сайта на контроллерах домена содержит сопоставление сайтов с их связанной информацией о стоимости, определенной в Active Directory. DFS использует кэш стоимости сайта для быстрого определения стоимости подключения, связанной с контроллерами домена и корневыми целями домена, чтобы DFS могла сортировать целевые объекты в порядке наименьшей стоимости.
Служба DFS получает сведения о стоимости сайта для контроллеров домена и корневых целевых объектов на базе домена, необходимые для выполнения запросов на направление клиентов. По умолчанию записи в кэше затрат сайта сохраняются в течение 12 часов. Этот период определяется значением записи реестра SiteSupportIntervalInSeconds (12 часов) на локальном контроллере домена. Если в Active Directory изменена стоимость подключения между двумя сайтами, информация о стоимости сайта в этом кэше будет устаревать максимум в течение записи реестра SiteSupportIntervalInSeconds (12 часов) или до тех пор, пока служба DFS не будет перезапущена.
Запись реестра QuerySiteCostTimeoutinSeconds на контроллерах домена также используется для этого кэша, чтобы указать период ожидания для запросов стоимости сайта. По истечении периода ожидания запрос стоимости сайта в Active Directory завершится ошибкой. По умолчанию тайм-аут составляет 30 секунд. Если DFS не может определить стоимость сайта в течение 30 секунд, DFS принимает максимально возможную стоимость для этого сайта.
Клиенты DFS
Клиенты DFS под управлением хранят ссылки с контроллеров домена и корневых серверов для повышения производительности. Клиент может использовать ссылки в своем кэше при обращении к целевому объекту в пространстве имен, а не повторно подключать контроллеры домена и корневые серверы для ссылок. Клиенты DFS также имеют записи реестра, используемые для настройки поведения DFS на клиенте.
На следующем рисунке показаны физические структуры и кэши на клиентах DFS.
DFS Registry Entries (Записи реестра DFS)
Записи реестра DFS находятся в реестре клиента DFS в следующих разделах:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\System\DFSClient
Domain cache (Кэш домена на клиентах)
Кэш домена на клиентах содержит два типа ссылок:
• Ссылки на доменные имена — доменные имена NetBIOS и DNS для локального домена клиента, доверенные домены в лесу и домены в доверенных лесах.
• Ссылки на контроллеры домена — сопоставления доменных имен с контроллерами домена, на которых размещены эти домены.
Просмотреть содержимое доменного кэша на клиентском компьютере из командной строки можно с помощью команды Dfsutil /spcinfo.
Данный пример вывода может быть интерпретирован следующим образом:
Записи, начинаюшиеся с [ * ] предоставляются службой рабочей станции.
[+] Рядом с контроллером домена с именем DC-01 в разделах [contoso.com] и [CONTOSO] указывает, что он является активным контроллером домена для этого домена. Клиент будет обращаться к DC-01 по мере необходимости для получения ссылок на доменные имена, ссылок на контроллеры домена и корневых ссылок на домены.
Клиент уже связался с DC-01, чтобы получить ссылки на доменные имена для Contoso.com, Europe.Contoso.com и Africa.Contoso.com.
Клиент уже связался с DC-01, чтобы получить ссылки на контроллеры домена для Contoso.com.
MUP Cache (Кэш MUP)
Кэш множественного поставщика путей UNC (MUP) хранит информацию о том, какой перенаправитель (напр. DFS, SMB или WebDAV) требуется для каждого пути UNC, к которому клиентский компьютер пытается получить доступ. Записи в кэше MUP хранятся в течение 15 минут. Для очистки этого кэша можно использовать команду Dfsutil /PurgeMupCache. Это может потребоваться при изменении типа папки, например из общей папки SMB в корневую папку WebDAV или DFS, или наоборот.
Referral Cache (Кэш ссылок на клиентах)
Клиенты DFS хранят корневые рефералы и ссылки на рефералы в кэше рефералов, также называемом кэшем PKT. Эти ссылки позволяют клиентам получить доступ к корневому каталогу и ссылкам в пространстве имен. Вы можете просмотреть содержимое реферального кэша на клиенте с помощью команды Dfsutil /pktinfo.
На рисунке показаны четыре типа рефералов:
(1) рефералы NETLOGON и SYSVOL;
(2) доменные корневые рефералы;
(3) автономные корневые рефералы;
(4) ссылочные рефералы.
Каждый из этих рефералов содержит следующую информацию:
Entry and ShortEntry
Entry указывает полное имя, ShortEntry задает краткое имя (восемь символов, за которыми следует точка и еще три символа) пути. Корневые серверы и контроллеры домена под управлением Windows Server используют полное имя при заполнении Entry и ShortEntry.
Expires in seconds
Указывает время жизни реферала. Ноль (0) секунд означает, что срок действия ссылки истек и что клиент получит новую ссылку при следующей попытке доступа к целевому серверу.
UseCount and Type
Количество и тип пользователей. UseCount — количество открытых соединений и файлов для этого пути. Если клиент имеет подключенный диск к пути DFS, то количество его использования увеличивается на 1. Type указывает тип реферала. Некоторые распространенные типы включают в себя:
Type 0x81 (REFERRAL_SVC DFS) — указывает на корневую ссылку.
Type 0x1 (DFS) — указывает на ссылку-реферал, которая имеет физические общие папки в качестве целевых объектов ссылок.
Type 0x10 (OUTSIDE_MY_DOM) — указывает на ссылку-реферал, целью которой является путь в доменном пространстве имен.
Target list
Список целей содержит корневые цели или цели ссылок, соответствующие пути, указанному в поле ввода. Целевые объекты перечислены по порядку, в соответствии с методом выбора целевого объекта, настроенным для корня или ссылки. Целевой объект, помеченный как активный, указывает, что клиент либо использовал этот целевой объект, либо будет использовать его в следующий раз, когда пользователь попытается получить доступ к этой части пространства имен.
На этом закончим с архитектурой DFS. В следующей части расмотрим основные процессы и взаимодействия между серверами.
Search code, repositories, users, issues, pull requests…
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
Skip to content
DFS Replication: Requirements and Configuration
Quick Bites
- The blog discusses the concept of Distributed File System (DFS) and its implementation in Windows Server 2016
- DFS is a method of organizing files across multiple servers, allowing users to access and share files as if they were on a single file server
- DFS consists of two main components: DFS Namespace, which provides a unified view of all DFS folders, and DFS Replication, which allows for the synchronization of DFS data between multiple servers
- The article explains how to set up DFS Namespace and DFS Replication in Windows Server 2016 and provides step-by-step instructions
- The blog concludes by highlighting the benefits of using DFS along with an efficient Backup & Disaster recovery solution like BDRSuite
One of the basic functions provided by enterprise IT is the hosting of file services in an organization. Since the early days of computer networks, having shared network locations to store and edit documents and other file resources has been a basic requirement.
As the need for file and network shares gain more and more momentum, IT admins in many enterprise IT environments found themselves managing numerous file shares, server names, network resources and such simply to manage files and network share resources across the organization. The management of a large number of network shares across different server resources can become very labor-intensive.
Microsoft introduced a solution to help organizations deal with and manage file shares across their organization to logically group them into a single hierarchical structure. The technology introduced is known as Distributed File System or DFS.
In this post, we will take a look at what DFS is, how it works, requirements and considerations, best practices, and finally, how it is configured.
Table of Contents
- What is a Distributed File System (DFS)?
- Domain-based DFS Namespaces
- How Distributed File System (DFS) Works
- Distributed File System (DFS) Requirements
- What are the requirements to host a DFS namespace?
- Considerations in Using Distributed File System (DFS) with Azure
- Configuring Distributed File System (DFS)
- Creating a DFS Namespace
- Adding a DFS Target to a Namespace
- Creating a New Replication Group
- DFS Does Not Replace Backups
- Wrapping Up
What is a Distributed File System (DFS)?
Distributed File System or DFS as touched on in the introduction provides the ability to logically group shares found on multiple servers and to transparently link shares into a single hierarchical namespace. This is organized in a treelike structure. DFS supports multiple modes including both stand-alone and domain-based DFS services.
Usage of domain-based namespaces is required when you want to provide high availability of the namespace. As with other Microsoft technologies that are replicated along with Active Directory, with DFS, the topology data for a DFS namespace is stored in Active Directory.
DFS uses the Windows Server file replication service to copy changes between replicated targets. When users modify files stored on one target, DFS replication propagates the changes across to the other designated targets in the DFS infrastructure. The most recent changes are preserved.
DFS is an interesting technology that abstracts the underlying physical file servers where the actual shares reside, from the namespace of how the shares are accessed. In situations where there may be tens or hundreds of file servers and shares, this can become a management nightmare. The DFS namespace aggregates and abstracts this underlying complexity from the end-users.
This is not only beneficial from the end-user perspective but also the IT admin who, with DFS, has greater flexibility to manage the underlying physical storage backing the DFS hosted shares. If more storage is needed, the IT admin can add a new storage device and share, copy over the files and synchronize them from the old device to the new device, and simply retarget the DFS link to point to the new share on the backend.
Does DFS only work with Microsoft Windows Servers?
A share that is published on a server that is running on a non-Windows Server cannot host a DFS root or provide referrals to other DFS targets. However, non-Windows backed shares can be published for which client redirectors are available in a DFS namespace. This can include any SMB-compatible device such as network-attached storage (NAS) devices from many different vendors as well as Samba shares. It does not work with NFS or HDFS.
How are DFS namespaces organized?
This is really up to the needs of the business. Common DFS organization may be related to the business organizational unit, the geographical location, combinations of both, or perhaps other custom business entities to define a DFS namespace.
What is included with the DFS topology data?
Components of the DFS tree structure include:
- DFS Root – This is a DFS server running the DFS service
- DFS links – DFS links point to network shares consolidated in DFS
- DFS Targets – The targets are the actual network shares the DFS links point to
The components making up a DFS namespace include the following:
- Namespace server – This is the DFS server that hosts a namespace. This can be a member server or a domain controller.
- Namespace root – This is the starting point of the DFS namespace tree. In the case of a domain-based DFS topology, it will start with the domain name. With domain-based DFS topologies, the DFS metadata is stored in Active Directory and replicated between the ADDS servers. You can have multiple namespace servers hosting the DFS namespace.
- Folder – There are two types of folders in the DFS namespace – folders without targets and folders with targets. The folders without targets are simply for the organization of the structure. Folders with targets link to the actual content that end users can access.
- Folder targets – Folder targets are the actual UNC paths to a shared folder associated with the folder in a DFS namespace. The folder target is where data is actually found. The great thing about domain-based DFS namespaces, the DFS namespace is Active Directory Site aware. If a user in one geographic location accesses the same DFS namespace folder target, they will be directed to the server hosting the data in the same site which enhances the user experience and prevents unnecessary WAN traffic traversing across.
High-level overview of the DFS namespace components (Image courtesy of Microsoft)
Below are the feature characteristics of the Distributed File System (DFS)
| Feature | Details |
| Type | Windows Server host service |
| Synchronous | Yes |
| Asynchronous | Yes |
| Storage hardware agnostic | Yes |
| Replication unit | Volume (Partition) |
| Windows Server Stretched cluster creation | Yes |
| Server-to-server replication | Yes |
| Cluster-to-cluster replication | Yes |
| Non-Windows File Shares | Yes |
| Transport | SMB3 |
| Network | TCP/IP or RDMA |
| Network constraint support | Yes |
| RDMA | iWARP, InfiniBand, RoCEv2 |
| Replication network port | TCP 445 or 5445 |
| Multipath | Yes (SMB3) |
| Kerberos support | Yes (SMB3) |
| Overwrite encryption and signing | Yes (SMB3) |
| Per-volume failovers allowed | Yes |
| Thin-provisioned storage support | Yes |
| Management Tools | PowerShell, Failover Cluster Manager |
Domain-based DFS Namespaces
There are a couple of use cases for using the domain-based DFS namespaces.
We have already touched briefly on why a domain-based DFS namespace would be beneficial, however, choose domain-based DFS namespaces for the following:
- Is the high-availability for the DFS namespace needed? Use domain-based in this case. By replicating the namespace between DFS namespace servers, HA is achieved.
- Domain-based DFS namespaces also provide a really easy way to abstract the underlying DFS server name by simply presenting the share in the \\< Domain Name >\namespace format. Coupled with Access-based Enumeration or ABE, users are only presented with the files in a namespace that they have access to.
To use the domain-based DFS namespace topology:
- Make sure your Active Directory forest functional level is Windows 2008 or higher
- Domain functional level needs to be at Windows Server 2008 or higher
- Namespace servers must be running Windows Server 2008 or higher
How Distributed File System (DFS) Works
A key component to the DFS working is DFS Replication.
DFS Replication in Windows Server is a role service that allows replicating the folders referred to by a DFS namespace path across multiple servers and sites. DFS replication is configured as a multi-master replication technology meaning any member of the DFS replication group can make changes to the data.
DFS replication makes use of an efficient compression algorithm called Remote Differential Compression (RDC) to detect changes to data. RDC is extremely efficient in that it can detect changes to a file and only copy the changed file blocks instead of recopying the entire file.
A DFS replication group mentioned earlier is a group of servers that participates in the replication of one or more replicated folders. A replicated folder stays synchronized between the members included in the DFS replication group. The communication between the various DFS replication group members forms the DFS replication topology.
The settings for the replication group including its topology, schedule, and bandwidth throttling are applied to the replicated folders contained in the DFS replication group.
DFS Replication Group (Image courtesy of Microsoft)
Each replicated folder in the DFS replication group has unique settings including the file and subfolder filters to filter out different files and subfolders for each replicated folder. Replicated folder can be located on different volumes in the member and do not need to be shared folders or part of a namespace. DFS Replication can be managed by using the DFS Management console, DfsrAdmin and Dfsrdiag commands or scripts that call WMI.
An important note to consider when looking at how DFS replication works is that DFS replicates a file only after it is closed. This means that it is not a suitable solution for replicating files that may constantly be in use like database files or other files that are open for an extended period of time. For documents or other files that need to be worked on in parallel with other users, you may want to look into other technologies like Storage Replica that was introduced in Windows Server 2016.
Distributed File System (DFS) Requirements
There are a few requirements and considerations to make note of when thinking of deploying a Distributed File System (DFS).
Servers that are running the following operating systems can host multiple domain-based namespaces in addition to a single stand-alone namespace.
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 Datacenter and Enterprise Editions
- Windows Server (Semi-Annual Channel)
Servers that are running the following operating systems can host a single stand-alone namespace:
- Windows Server 2008 R2 Standard (Windows Server 2008/R2 are at end of extended support.
What are the requirements to host a DFS namespace?
| Server Hosting Stand-Alone Namespaces | Server Hosting Domain-Based Namespaces |
| An NTFS is required to host a DFS namespace | Must contain an NTFS volume to host the namespace. |
| Either member servers or domain controllers can be used | Must be a member server or domain controller in the domain in which the namespace is configured. (This requirement applies to every namespace server that hosts a given domain-based namespace.) |
| Failover clusters can be used for high availability to host the DFS namespace for resiliency | The namespace cannot be a clustered resource in a failover cluster. However, you can locate the namespace on a server that also functions as a node in a failover cluster if you configure the namespace to use only local resources on that server. |
What are the requirements to deploy DFS replication?
- Update the Active Directory Domain Services (ADDS) schema to include Windows Server 2003 R2 or later schema additions. No read-only replicated folders with the Windows Server 2003 R2 or older schema additions.
- All servers in a DFS replication group must be located in the same Active Directory forest. You cannot enable replication across servers in different AD forests.
- Install DFS Replication on all servers that will act as members of a replication group.
- Ensure you have the proper antivirus exceptions in place for DFS replication as these can trigger false positives in many antivirus solutions.
- Locate folders that you want to replicate with DFS on NTFS formatted volumes. As of yet, DFS Replication does not support the Resilient File System (ReFS) or the FAT file system. DFS Replication also does not support replicating content stored on Cluster Shared Volumes.
Considerations in Using Distributed File System (DFS) with Azure
DFS can be used in conjunction with Azure, but there are a few considerations that you will want to make in using the two together. It has been tested as documented by Microsoft to use DFS with Azure virtual machines.
Below are a few points to note with DFS and Azure:
- No clustering of stand-alone namespaces in Azure VMs
- Domain-based namespaces can be run on Azure VMs, including Azure environments running Azure Active Directory
- Using snapshots or saved states to restore VMs DFS Replication causes DFS Replication to fail, which can require special database recovery steps.
- Don’t export, copy, or clone DFS Replication VMs
- Use backup software from within the guest virtual machine
- You will need to have a site-to-site VPN connection between your on-premises replication group members and members hosted in Azure VMs with appropriate firewall port exceptions for communication between them. This includes RPC Endpoint Mapper (port 135) and randomly assigned ephemeral ports.
Configuring Distributed File System (DFS)
Let’s take a look at how to configure Distributed File System in Windows Server 2019.
To install the Distributed File System DFS on a Windows Server, it involves adding a role to your servers. The DFS roles are actually a subcomponent of the File and Storage Services role.
Installing the DFS Namespaces and DFS Replication roles
Below is a look at the available DFS roles when using the Get-WindowsFeature PowerShell cmdlet.
Using PowerShell to view the available DFS roles
You can install the DFS roles by using either the Server Manager console or using PowerShell.
Installing DFS roles using Server Manager
PowerShell is a great way to install DFS roles quickly and easily. This is also great for the automation and mass installation of roles across many servers.
- Install-WindowsFeature -name “FS-DFS-Namespace” -IncludeManagementTools
- Install-WindowsFeature -name “FS-DFS-Replication” -IncludeManagementTools
Using PowerShell to install the DFS roles on a Windows Server
Creating a DFS Namespace
You can launch the DFS Management Console by using the command dfsmgmt.msc.
As you can see the management console is fairly straightforward. Under the Actions pane, you can click the New Namespace button to begin creating a new DFS namespace.
Launching the DFS console and beginning to create a new DFS namespace
The New Namespace Wizard launches. The first step is entering the name of the server that will host the namespace. You can either enter the server name or click Browse and find the server name.
Enter the Namespace server
Enter the Namespace Name and Settings. As noted, the name you choose is the name that appears after the server or domain name in the namespace path. You can also click the Edit Settings button and get more granular with the local path and settings.
Enter the name for the namespace
The next step is choosing a Namespace Type. This is where you can choose between a domain-based and a standalone namespace server. Also, you can choose the Enable Windows Server 2008 mode (enabled by default) which sets up the namespace with increased scalability and access-based enumeration ABE. ABE means that end users only see the files presented which they have access to.
Choose stand-alone namespace, if:
- Your organization does not use Active Directory Domain Services (AD DS).
- You use the failover cluster to increase the availability of the namespace.
- You want to create a single namespace with more than 5,000 DFS folders in a domain if you don’t meet the requirements for a domain-based namespace(Windows Server 2008 mode).
The following minimum requirements to the Windows Server 2008 mode
- The forest uses the Windows Server 2003 or higher forest functional level.
- The domain uses the Windows Server 2008 or higher domain functional level.
- All namespace servers are running Windows Server 2008 and later.
Choose domain-based namespace, if:
- You use multiple namespace servers to ensure the availability of the namespace.
- You want to hide the name of the namespace server from users.
Choosing the Namespace Type
Review the settings and create the namespace.
Reviewing DFS Namespace settings and completing the configuration
The create namespace wizard completes successfully.
Finishing the new namespace wizard
Adding a DFS Target to a Namespace
Next, we need to add a target to the DFS namespace. Right-click the namespace and choose New Folder.
Adding a new folder to a DFS namespace
Click Add.
Adding a folder to the namespace
You can enter either a UNC path for a remote server share, or you can click the Browse button and select a local server folder.
Adding a folder target to the DFS namespace
Here, we have added a local folder.
Adding a local folder target to a DFS namespace
Creating a New Replication Group
Finally, let’s walk through creating a replication group that will replicate the source DFS housed folder to the target server. This will copy the data from the source to the destination.
***Note*** files are not replicated until they are closed.
Creating a New Replication Group
Choose the Replication Group Type.
Choose the ‘Multipurpose replication group’ if you would like to configure custom replication topologies. It also allows you to create a custom replication topology by first adding a set of servers to the replication group and then configuring custom connections between them to achieve the desired custom replication topology.
There are three options available under the Multipurpose replication group: Hub and spoke, Full mesh and No topology.
Hub and spoke
It can be used with three or more servers. Each spoke can use one or more hub members to replicate data. Multiple hubs can be used for redundancy in case any one of them becomes unavailable. Hubs should host the same replication data.
Full mesh
It can be used between two or more servers. In a full mesh topology, data is replicated between all replication members. It’s recommended that you always use this topology if the DFS replication group is composed of less than 10 servers.
No topology
You will be able to enable DFS connections once the wizard is completed. No replication will occur until the connections are configured.
Choose the ‘Replication group for data collection’, if you want to add two servers to a replication group in such a way that a hub (destination) server can be configured to collect data from another branch server. You cannot keep on adding new members to a data collection replication group, but you can keep on creating additional replication groups that all have the same hub server, to make up a kind of hub and spoke topology if you had multiple ‘branch offices.’
Multipurpose Replication Group is a more versatile setup and can operate in hub or mesh mode. If you’re not sure what to pick, pick a Multipurpose Replication Group.
Here we are choosing a Multipurpose replication group. This option configures replication between two or more servers for publication content sharing and other scenarios.
Choosing the Replication Group Type
Choose the Name and Domain.
Choosing Name and Domain
Choose the Replication Group Members. Here we have selected the two DFS servers we want to include in the Replication Group.
Choosing the Replication Group Members
Next, you choose the Replication Topology. If you have only two servers, the Hub and Spoke option is greyed out. By default, with two servers, you will see Full Mesh selected.
Choosing the replication topology for DFS replication
With DFS Replication, you can choose the replication schedule and the bandwidth you want to allocate to the DFS replication process.
Replication Group Schedule and Bandwidth configuration
Select the Primary Member for the DFS Replication group.
Selecting the Primary Member for the DFS Replication Group
Choose your folders to replicate to the replication members. Click the Add button to add these folders.
Add Folders to Replicate
Choose the local path on the replication members where the replicated folder will be replicated.
Configuring the local path of replicated folders on other members
Review the Replication Settings and click Create to create the replication group.
Reviewing and creating the replication group
Replication group is created successfully.
Creating the replication group
You will see an informational message about the possible replication delay.
Informational message about DFS replication delay
After only a few moments, the source file is replicated to the DFS replication member. Below, a file was created on the source server and within a few moments, the file had replicated to the DFS replication group member, with the same contents.
Replication target receives the file from the DFS replication process
DFS Does Not Replace Backups
There could be a misconception about DFS and its use cases to assume that DFS would serve as a form of backup since data can be replicated between a number of replication members in the DFS replication group. However, keep in mind, while the replication process can replicate data that would serve to create additional copies of data on additional servers, this does not protect from data loss as a result of end-user mistakes and security threats like ransomware.
Due to the replication process, changes made by end-users or ransomware would be replicated to the other servers in the DFS replication group. Businesses still need to backup their data and keep multiple restore points aligning with business needs, to truly protect their data.
BDR Suite provides a great solution for businesses and their data. It allows granular restores of data down to individual files and folders.
Additionally, it globally protects your data by creating backups of VMs as well as physical machines that may be backing business-critical services.
Be sure to download a fully-featured trial version of BDR Suite here.
Wrapping Up
Windows Distributed File System (DFS) is a great way to scale many Windows Server file shares across a network. It allows easily aggregating file shares logically and abstracting the namespace from the actual underlying network share name. This can make it much easier for end-users to reach resources and for IT admins to perform maintenance on the underlying storage contributing to the shares.
The process to create a DFS namespace, add target shares/folders, and create replication groups is very straightforward using either GUI or command-line options including PowerShell to control DFS. DFS is not a backup solution for your data. While it can replicate data to multiple servers, this does not protect your business from end-user related data loss or data loss as a result of cybersecurity threats like ransomware.
Using a modern backup solution like BDRSuite is a great way to ensure your data is safe and protected from the end user or cybersecurity threats. Using tools like DFS combined with a backup solution that can properly protect your data, you can be confident in the security, resiliency, and recoverability of data despite any threats that may come along.
Embark on an Unparalleled Journey: Discover the Ultimate Windows Backup Marvel!
Empower your critical data with secure and seamless Windows backup, forging a fortress of protection. Unleash the full potential of your digital domain, preserving your invaluable information with unwavering confidence. This thrilling opportunity awaits — explore limitless possibilities of safeguarding your data with a free trial today!
Ready to embark on this captivating adventure? Download BDRSuite now and take the first stride towards securing your Windows environment. Embrace tranquility and immerse yourself in the realm of unparalleled Windows backup excellence!
Curious to explore more about Windows backup solutions? Visit here to unlock the power of Windows backup with BDRSuite! Unleash the true potential of your digital realm and shield it from any unforeseen challenges!
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
