1.2 DFS Components

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:

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:

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:

Target volumes can reside on the following operating systems:

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.

A Move Volume job helps you to do the following:

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.

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.

The primary management tool for Distributed File Services is iManager. Use the following plug-ins:

For more information about using iManager, see Section 8.1, iManager and DFS-Related Plug-Ins.