Distributed File System. Architecture and basic concepts. Physical structure

Distributed File System. Architecture and basic concepts. Physical structure

Distributed File System (DFS) Microsoft server technology designed to simplify access to shared file resources distributed over a network. With DFS, file shares physically located on different servers can be combined into a single logical structure and replicated between them.

DFS – Not new technology is as old as mammoth shit, it has been known since the days of Windows NT. Although the terms DFS and Distributed File System came a little later and refer to Windows 2000 and 2003. And with Windows 2003 R2, Microsoft introduced a new DFS namespace and an improved replication mechanism. The new DFS-N space is called DFS-N (DFS-Namespace) and the new replication mechanism is DFS-R (DFS-Replication). It is these two components that currently form the DFS functionality.



DFS physical structures and caches

.
Now let’s dig deeper and look at the physical structures and caches on domain controllers, root servers and DFS clients.

Root Servers

.
Physical structures and caches on the root server differ depending on the type of namespace in which the root server is hosted (domain or standalone). Servers running Windows Server may contain several autonomous and domain roots.

The following figure shows the physical structure and DFS cache on the root servers.



.

.
Stand-Alone DFS Metadata in the Registry.

DFS standalone metadata contains information about the root, root target, link objects and parameters defined for each standalone namespace. This metadata is stored in the root server registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Standalone.

The root servers of a domain name space have a registry entry for each root in KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\Domain, but these entries do not contain domain-based DFS metadata. When running DFS on a root server, the service checks this path for registry entries corresponding to the roots of the domain. If these records exist, the root server polls a domain controller with the PDC emulator role to obtain DFS metadata for each domain namespace and stores this metadata in memory.

DFS Registry Entries

DFS supports multiple registry entries to configure DFS behavior on root servers. DFS registry entries are located in the registry under the following subsections:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS

HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services\DFS\Parameters

Root and Link Folders (Link Root and Folders)

Each root and link in a namespace has a physical representation on an NTFS volume on each root server hosting that namespace. The DFS root corresponds to a public folder known as the Root Folder on the root server. When using DFS tools to add links to the root directory, DFS creates special folders under each root folder. These folders, called Link Folders, are actually reanalysis points, and if you try to access them on the local server you will get an error message. DFS clients that access link folders across the network are redirected to the corresponding target object.

.

.
DFS Metadata Cache (DFS Metadata Cache)

The DFS metadata cache on the root servers contains information about the root, root target objects, links, target reference objects and parameters defined in the namespace. For domain namespaces, this metadata is stored in a DFS object in Active Directory, and for offline namespaces, it is stored in the root server registry.

This cache is stored in RAM and is updated whenever the root server polls a DFS object in Active Directory (for domain namespaces) or registry (for standalone namespaces).

Domain-based Root Referral Cache.

When a client accesses a domain root server directly, at \\ServerName\RootName, the root server provides the client with a list of domain root objects (Domain-based Root Referral) for that namespace.

By default, the root servers store these domain root links in memory for 15 minutes. This period is defined by the registry entry RootReferralTimeoutInSeconds on the root server. Restarting the DFS service on the root server will clear this cache. If root targets are added or removed, or if settings are changed in the root, these changes are reflected in the domain root links provided by the root servers after 15 minutes or after cache cleanup.

The domain root referral cache does not store the target objects in any particular order. Target objects are sorted according to the method of selecting target objects on client request. In addition, these references are based on DFS metadata stored on the nearest domain controller, not only the PDC emulator.

Client Site Cache (Client Site Cache)

A site in Active Directory determines its physical location. When a client requests a DFS link from a root server, the DFS service on the root server uses information about the Active Directory site to determine the client’s site based on its IP address. DFS stores this information in a cache of the root server’s client site, which contains mappings of client IP addresses to site names. This cache is used to quickly identify the site to which the client belongs.

By default, the root servers store records in the client site’s cache for up to 24 hours. This period is determined by the registry entry SiteSupportIntervalInSeconds (12 hours) on the root server, multiplied by two. If a site name changes or a client moves from one site to another and uses the same IP address, the site information in this cache will be up to twice as old as the SiteSupportIntervalInSeconds registry entry (24 hours) or until the DFS service is restarted on the root server.

When the cleanup process starts after a specified time interval, the records are processed as follows: if the client specific site name has been available since the last cleanup process, the record is updated, and if the client specific site name has not been available since the last cleanup process, the record is deleted.

By default, DFS can store 200,000 records in the cache of a client site. This limitation is determined by the MaxClientsToCache registry entry.

Target Site Cache.

When the DFS service runs on the root server, it collects information about the Active Directory site for all target link objects based on the current IP address of each target object. The DFS service also gets site information when new target link objects are added. DFS caches this information in the target site cache on the root server, which contains mappings of the target link server names to the site names. DFS uses this information to quickly determine the site to which the target link belongs.

By default, the root servers store records in the cache of the target site for up to 24 hours. This interval is determined by the Registry entry SiteSupportIntervalInSeconds (12 hours) on the root server multiplied by two. After a specified interval, DFS updates the site information in this cache. If the site name changes or the destination link server moves from one site to another, the site information in this cache will be up to twice the value of the SiteSupportIntervalInSeconds registry entry (24 hours) or until the DFS service is restarted.

Site Cost Cache (SiteSupportIntervalInSeconds Cache)

In Active Directory, there is a concept of site links, which is a logical connection between two or more sites, corresponding to the physical communication channels between sites. Each connection has its own cost, which determines the bandwidth of the communication channel and, consequently, the cost of data transfer between sites. This information is used in Active Directory replication to determine the best route.

The cost cache of a site on the DFS root servers contains a comparison of sites with the corresponding cost information defined in Active Directory. The Site Value Cache is used to quickly determine the connection costs associated with the link targets so that DFS can sort the link targets in the order of lowest cost.

The DFS service receives information about the cost of the site for the target link objects as needed, when executing requests to refer clients. By default, root servers store records in a cache of site cost up to 12 hours. This period is determined by the Registry entry SiteSupportIntervalInSeconds (12 hours) on the root server. If Active Directory changes the cost of communication between two sites, the cost information for the site in this cache will become obsolete at most during the SiteSupportIntervalInSeconds registry entry (12 hours) or until the DFS service is restarted.

The registry entry QuerySiteCostTimeoutinSeconds on the root servers is also used for this cache to specify the waiting period for site cost queries. When the wait period expires, the request for site cost information in Active Directory will end with an error. The default timeout is 30 seconds. If DFS cannot determine the cost of the target site within 30 seconds, the maximum possible cost for the target server is accepted.

Domain Controllers

.
Domain controllers play an important role for domain namespaces. They store DFS metadata for domain namespaces and provide links to DFS clients to help them access domain namespaces. There are several physical structures and caches that support these processes; these structures and caches are shown in the following figure.

.

.
DFS Object in Active Directory

The DFS object in Active Directory stores DFS metadata for the domain namespace. The DFS object is created when the domain root directory is created and the Active Directory replicates the entire DFS object to all domain controllers in the domain. When a client requests a link for a domain namespace, the domain controller first checks its domain root cache of links (described later in this section) for an existing link. If it does not exist, the domain controller finds a DFS object for that namespace and uses the metadata in the object to create the link.

The following figure shows the location of DFS objects in Active Directory. Each DFS object (FTDFS object) corresponds to a domain name space.

.
Each DFS object has the following four important attributes:

pKT – binary representation of DFS metadata for this root.

– pKTGuid is the global unique identifier (GUID) of DFS metadata.

remoteServerName – lists the root target objects for the root.

– Security descriptor is a security descriptor, controls access and determines who is allowed to modify the DFS object.

Regarding the size of the DFS object. When writing metadata, approximately 400 bytes per DFS link are used. Any change in namespace causes the entire DFS object to be replicated to all domain controllers in the domain. To reduce network traffic that occurs when namespace changes, it is recommended that the DFS object for a domain namespace be limited to 5MB (approximately 5000 references).

DFS Registry Entries

DFS supports multiple registry entries to configure DFS behavior on domain controllers. DFS registry entries are located in the registry in the following subsections:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFS

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs\Parameters

Domain Name Referral Cache (Domain Name Reference Cache)

Domain name link contains NetBIOS and local domain DNS names, all trusted domains in the forest and domains in trusted forests. The DFS client requests the domain name link from the domain controller to identify domains where clients can access the domain namespaces.

By default, domain controllers store links to domain names in a memory cache for 12 hours; this period is determined by the registry entry DomainNameIntervalinSeconds on the domain controller. Restarting the DFS service on the domain controller will clear this cache. If a domain name is changed or domains are added to or removed from the forest or trusted forests, these changes are reflected in the links to domain names after 12 hours or after clearing this cache.

Domain Controller Referral Cache.

The link to the domain controller contains the NetBIOS and DNS names of the domain controllers for the list of domains that it cached. The DFS client requests the link to the domain controller from the domain controller

to determine which domain controllers can provide a link for the domain namespace.

Domain controllers store these links in the memory cache for 10 minutes, this value cannot be changed. Restarting the DFS service on the domain controller will clear this cache. If the name of a domain controller changes or if domain controllers are promoted or demoted, these changes are reflected in the links to the domain controllers after 10 minutes or after clearing this cache.

Domain-based Root Referral Cache

A root link to a domain contains a list of root target objects that host the domain namespace in question. Domain controllers provide domain-based root links to customers who are trying to access the domain namespace.

By default, domain controllers store domain-based root links in a memory cache for 15 minutes; this period is defined by the registry entry RootReferralTimeoutInSeconds on the domain controller. Restarting the DFS service on the domain controller will clear this cache. If root target objects are added or removed, or if there are changes to the root settings, these changes are reflected in the domain root links after 15 minutes or after clearing this cache.

Client Site Cache (Client site cache)

When a client requests a link from a domain controller, the DFS service on the domain controller uses the site information defined in Active Directory to determine the client site based on its IP address. DFS stores this information in a client site cache that maps client IP addresses to site names and uses this cache to quickly determine the site the client belongs to.

By default, domain controllers store records in the client site’s cache for up to 24 hours. This period is determined by the Registry entry SiteSupportIntervalInSeconds (12 hours) on the domain controller, multiplied by two. If a site name changes or a client moves from one site to another and uses the same IP address, the site information in this cache will be up to twice as old as the SiteSupportIntervalInSeconds registry entry (24 hours) or until the DFS service is restarted on the domain controller.

When the cleanup process starts after a specified time interval, the records are processed as follows: if the client specific site name has been available since the last cleanup process, the record is updated, and if the client specific site name has not been available since the last cleanup process, the record is deleted.

By default, DFS can store 200,000 records in the cache of a client site. This limitation is determined by the MaxClientsToCache registry entry.

Target Site Cache.

The DFS service on domain controllers uses site information defined in Active Directory (through the DSAddressToSiteNames API) to define a site for the root target domain objects and domain controllers based on their current IP addresses. DFS stores this information in its target site cache, which maps the names of the root servers and domain controllers to site names. DFS uses this information to quickly determine the site to which the root server or domain controller belongs.

By default, domain controllers store records in a cache of the target site for up to 24 hours. This interval is determined by the Registry entry SiteSupportIntervalInSeconds (12 hours) on the domain controller, multiplied by two. After a specified time interval, DFS updates the site information in this cache. If the site name changes or the root target object moves from one site to another, the site information in this cache will become up to twice as old as the SiteSupportIntervalInSeconds registry entry (24 hours) or until the DFS service is restarted on the domain controller.

Site Cost Cache (SiteSupportIntervalInSeconds Cache)

The site cost cache on the domain controllers contains a mapping of sites to their associated cost information defined in Active Directory. DFS uses the Site Value Cache to quickly determine the connectivity costs associated with domain controllers and the root domain goals, so that DFS can sort the target objects in order of least cost.
The DFS obtains information about the cost of the site for domain controllers and domain-based root target objects, which is necessary to fulfill requests for referral to clients. By default, entries in the site cost cache are saved for 12 hours. This period is determined by the value of the registry entry SiteSupportIntervalInSeconds (12 hours) on the local domain controller. If Active Directory changes the cost of connecting between two sites, the cost information for the site in this cache will become obsolete at most during the SiteSupportIntervalInSeconds registry entry (12 hours) or until the DFS service is restarted.

The registry entry QuerySiteCostTimeoutinSeconds on domain controllers is also used for this cache to specify the waiting period for site cost queries. At the end of the waiting period, a site cost query in Active Directory will end with an error. The default timeout is 30 seconds. If DFS cannot determine the cost of a site within 30 seconds, DFS will accept the maximum possible cost for that site.

DFS Clients

DFS clients under management store links from domain controllers and root servers for improved performance. The client can use the links in its cache when accessing the target object in the namespace, rather than re-connecting the domain controllers and root servers for the links. DFS clients also have registry entries used to configure DFS behavior on the client.

The following figure shows the physical structures and caches on the DFS clients.

.

.

DFS Registry Entries

DFS registry entries are located in the DFS client registry in the following sections:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanWorkstation

HKEY_LOCAL_MACHINE\Software\Policies\System\DFSClient

Domain cache (Domain cache on clients)

Domain cache on clients contains two types of links:

– Domain Name Links – NetBIOS and DNS domain names for the client’s local domain, trusted domains in the forest and domains in trusted forests.

– Domain Controller Links – Mappings of domain names to the domain controllers that host these domains.

You can view the contents of the domain cache on a client computer from the command line using the Dfsutil /spcinfo command.

.

.

.
This example output can be interpreted as follows:

Records starting with [ * ] are provided by the workstation service.

[+] Next to the domain controller named DC-01 in [contoso.com] and [CONTOSO] indicates that it is an active domain controller for this domain. The client will contact DC-01 as needed to get links to domain names, domain controller links and domain root links.

Customer has already contacted DC-01 to obtain domain name links for Contoso.com, Europe.Contoso.com and Africa.Contoso.com.

The customer has already contacted DC-01 to obtain links to domain controllers for Contoso.com.

MUP Cache (MUP Cache)

The Multiple UNC Path Provider (MUP) cache stores information about which redirection (e.g. DFS, SMB or WebDAV) is required for each UNC path that a client computer attempts to access. Records in the MUP cache are stored for 15 minutes. You can use Dfsutil /PurgeMupCache to clear this cache. This may be necessary when changing the folder type, for example from an SMB public folder to the WebDAV or DFS root folder, or vice versa.

Referral Cache (Customer Link Cache)

DFS clients store root referrals and references to referrals in a referral cache, also called the PKT cache. These links allow clients to access the root directory and links in the namespace. You can view the contents of the referral cache on the client using the command Dfsutil /pktinfo.

.

.

.
The figure shows four types of referrals:

(1) referrals NETLOGON and SYSVOL;

(2) domain root referrals;

(3) autonomous root referrals;

(4) reference referrals.

Each of these referrals contains the following information:

Entry and ShortEntry

Entry specifies a full name, ShortEntry specifies a short name (eight characters followed by a dot and three other characters) of the path. Windows Server Root Servers and Domain Controllers use the full name when filling out Entry and ShortEntry.

Expires in seconds.

Indicates the lifetime of the referrals. Zero (0) seconds means that the link has expired and that the client will receive a new link the next time they try to access the target server.

UseCount and Type

Quantity and type of users. UseCount – number of open connections and files for this path. If the client has a disk connected to the DFS path, the number of its use is increased by 1. Type indicates the type of referral. Some common types include:

Type 0x81 (REFERRAL_SVC DFS) – indicates the root link.

Type 0x1 (DFS) – points to a referral link that has physical shared folders as target link objects.

Type 0x10 (OUTSIDE_MY_DOM) – points to a referral link that targets the path in the domain namespace.

Target list

The list of targets contains root targets or reference targets corresponding to the paths indicated in the input field. The target objects are listed in order according to the method of target selection configured for the root or reference. The target object marked as active indicates that the client has either used this target object or will use it next time the user tries to access this part of the namespace.

 

Taken from this pages.



WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


13 Views

0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments


Do NOT follow this link or you will be banned from the site!
0
Would love your thoughts, please comment.x
()
x

Spelling error report

The following text will be sent to our editors: