DFS operates within a management context. The management context is a preexisting O or OU container that you choose from your eDirectory tree. When you define the management context, two attributes are added to the O or OU container object that you select:
DFS-VLDB-Hosts: A multiple-valued attribute that contains the distinguished names of the one or two servers that host the VLDB service replica for this management context.
VLDB-BackEnd-ID: The name of the back-end database plug-in for this management context. Currently, this is vdqad, and the plug-in is not modifiable.
The presence of these attributes is what indicates to the DFS software that the container is a DFS management context.
The management context can have one or two Volume Location Database services replicas. The servers that host replicas of the VLDB service can exist anywhere in the management context, as shown below.
Figure 1-1 A Single DFS Management Context
Multiple management contexts can be defined in a single eDirectory tree. The management contexts function independently. If the management contexts are defined in different subtrees, adding and removing one of the contexts has no effect on the other one. If a management context is defined at a different level in the tree, the higher-level management context does not include the subtree of the lower-level management context, as shown below. Each management context is responsible for only those volumes that are in its subtree but are not in a lower-level management context.
Figure 1-2 Multiple DFS Management Contexts in the Same Subtree
For an explanation of these management contexts and for more examples, see Section 1.4, Examples of DFS Management Contexts.
The Volume Location Database provides a mapping of the physical location of all volumes within a DFS management context that have an object in eDirectory. Typically, this includes NSS volumes and NCP volumes. When you create a management context, DFS walks the subtree to locate the Volume objects for NSS volumes to add an entry to the VLDB.
Each volume has a DFS GUID (globally unique identifier) that junctions use when targeting a volume. Whenever you create an NSS volume, NSS automatically creates a DFS GUID for the volume, and writes it as an attribute of the Volume object. In order to allow a VLDB repair to correct the information in eDirectory if the Volume object is lost, the volume’s DFS GUID is also stored in the ~DFSINFO.8-P file in the root directory of the volume. For an NCP volume on Linux that might be a junction target, the DFS GUID is generated by DFS whenever you add the volume entry to the VLDB or if you run a VLDB repair. The NCP volume’s DFS GUID only exists in the eDirectory Volume object; the ~DFSINFO.8-P file does not exist on an NCP volume. DFS automatically generates a DFS GUID for a Volume object only if the DFS GUID does not exist in the Volume object or in the ~DFSINFO.8-P file. If the eDirectory Volume object for an NCP volume is lost, VLDB repair generates a new DFS GUID for that volume.
The VLDB tracks volumes on the following platforms in its management context:
OES 23.4
OES 2023
OES 2018 SP3
OES 2018 SP2
OES 2018 SP1
OES 2018
OES 2015 SP1
OES 2015
OES 11 SP2
OES 11 SP1
OES 2 SP3
NetWare 6.5 SP8
Any volume that has a Volume object in the O or OU container belongs to the management context, unless the volume belongs to a management context that is defined at a lower level in the container. NSS automatically creates a Volume object in eDirectory when you create a volume with NSS tools. NCP Server automatically creates a Volume object in eDirectory when you create the NCP share for an NCP volume (an NCP share on a Linux POSIX volume).
The Volume Location Database service provides the framework for locating volumes in the management context. Managing the VLDB service involves the creation, day-to-day management, maintenance, and repair of the VLDB.
A replica site is the server that hosts an instance of the VLDB service and its VLDB file for a DFS management context. Each management context has one or two replicas. The replicas can be on any combination of operating platforms that support DFS. The servers can be at the same level or below the management context in the eDirectory tree, but they must not be in a lower-level DFS management context.
When two replica sites are deployed for the management context, each instance of the VLDB service is an equal replica that automatically synchronizes its data with the other replica site. The two instances exchange databases (the entire database, not just the changes) any time a change is made to an instance. Upon receipt of the other replica's database, each replica merges the received database with its own, determining which entries have been added, deleted, or modified.
Use the Distributed File Services > Manage Replica Sites task in iManager to configure replica sites, monitor their status, and repair the VLDB as needed. You can also manage the VLDB service from the server console with VLDB commands.
A DFS junction is a logical placeholder for data that is stored on a different NSS volume. One junction points to only one target location. A junction is a virtual directory that points to the root of a target NSS volume. In some configurations, the junction can point to a subdirectory on the target volume. For details, see Section 9.1.1, Supported Combinations for Junctions.
The DFS junction stores the DFS GUID of the target volume, not its physical location. This allows volumes to be moved without rectifying the change in every junction. The VLDB contains information about the physical location of volumes. When the junction receives a query, DFS-aware client (Client for Open Enterprise Server, CIFS server, or NetStorage) presents the target DFS GUID to the VLDB to get the physical location of the volume, and the query is transparently redirected to the target location.
To the user, a DFS junction appears to be a normal subdirectory; only its directory properties identify it as a junction. Users can continue to access their data without modifying the familiar logical paths.
DFS supports junctions for NSS volumes. The junction can be located anywhere in the source NSS volume, including the root of the volume. Multiple levels of junctions are allowed when a junction points to the root of a target volume and the file access protocol supports multiple levels of junctions. For details of supported relationships, see Section 9.1, Guidelines for Combining Platforms, Volumes, and Protocols.
A junction can point to a target location on the following types of volumes that are in the same DFS Management Context. File access is controlled by file system trustees and trustee rights:
NSS volumes
The source server and target server must have the same communication protocol configured for file access, such as NCP to NCP, NetWare CIFS to NetWare CIFS, OES CIFS to OES CIFS, or NetWare CIFS to Samba.
IMPORTANT:Samba does not support DFS junctions themselves, so if the target volume contains junctions, they do not work.
NCP volumes (NCP shares on Linux POSIX volumes)
This requires the NCP Server to be running on the source and target servers.
Target volumes can reside on the following operating systems:
OES 23.4
OES 2023
OES 2018 SP3
OES 2018 SP2
OES 2018 SP1
OES 2018
OES 2015 SP1
OES 2015
OES 11 SP2
OES 11 SP1
OES 2 SP3
NetWare 6.5 SP8
When you split an NSS volume, DFS copies the data to a newly created volume, creates a junction to replace the directory, and deletes all content below that point in the original volume. For instructions on how to split a volume, see Section 13.0, Using DFS to Split NSS Volumes.
You can also create a junction manually. The following tables describe the rules for manually creating junctions.
Table 1-1 Rules for Manually Creating Junctions
Source Volume |
Source Volume’s DFS Management Context |
Target Volume |
Target Volume’s DFS Management Context |
---|---|---|---|
An existing NSS volume on a supported system. It must be in the same eDirectory tree as the target volume. |
None required. It must be in the same eDirectory tree as the target volume, but is not required to be in the target’s DFS management context. |
An existing volume on a supported system. It must be in the same eDirectory tree as the source volume. |
Required. It can be in any management context in the same eDirectory tree as the source volume. |
A Move Volume job helps you to do the following:
Move an NSS volume to a newly created NSS volume in a different pool that has space available or that is expandable.
Move NSS volumes to different servers in the same DFS management context to balance associated traffic and workload across multiple servers.
Move data between volumes faster than with a normal copy because it uses Storage Management Services to transfer the data.
Use the Move Volume task in the Storage plug-in to iManager to define Move Volume jobs.
After a successful move, the physical location of the volume is automatically updated in the VLDB. If the volume is on a different server, existing junctions that point to the source volume are not broken. They simply point to the new volume location by using the updated VLDB mapping. Scripts need to be modified in order to access the volume by its new pathname if you move the volume to a different server or rename it.
The following table describes the rules for moving volumes with DFS. For instructions, see Section 12.0, Using DFS to Move NSS Volumes.
Table 1-2 Rules for Moving Volumes
Source Volume |
Source Volume’s DFS Management Context |
Target Volume |
Target Volume’s DFS Management Context |
---|---|---|---|
NSS volume on a supported system. |
Required. The source and target volume must be in the same management context. |
A newly created volume on a supported system |
Required. The source and target volume must be in the same management context. |
With DFS, you can split an NSS volume at a specified directory and relocate the directory contents to a new volume on the same server, or to a different server anywhere in the same eDirectory management context. The new volume typically resides in a different pool. After a successful relocation of directory contents, DFS automatically creates a DFS junction at the split point, which replaces the original directory and its content. The DFS junction contains information used to redirect queries to the new location. Users can continue to access their data on the new volume, without modifying the familiar logical paths.
The following table describes the rules for splitting volumes. For instructions, see Section 13.0, Using DFS to Split NSS Volumes.
Table 1-3 Rules for Splitting Volumes
Source Directory |
Source Volume’s DFS Management Context |
Target Location |
Target Volume’s DFS Management Context |
---|---|---|---|
Any directory in an NSS volume on a supported system. |
Required. The source and target volume must be in the same management context. |
A newly created NSS volume on a supported system. The target location must be at the root of the volume. |
Required. The source and target volume must be in the same management context. |
The primary management tool for Distributed File Services is iManager. Use the following plug-ins:
Distributed File Services: This plug-in allows you to create or delete DFS contexts, manage VLDB replica sites and their VLDB service, and control move and split volume jobs. For an overview of the available tasks, see Section 8.1.5, Distributed File Services Plug-In.
Storage: This plug-in allows you to define Move Volume jobs and Split Volume jobs from its Volumes page. For an overview of the available tasks, see Section 8.1.6, Storage Plug-In.
For more information about using iManager, see Section 8.1, iManager and DFS-Related Plug-Ins.