Novell Doc: OES 1 - Understanding DFS

20.1 Understanding DFS

20.1.1 Benefits of DFS

Novell Distributed File Services for NetWare helps you modify the underlying physical organization of data on NSS volumes to maximize the use and performance of available storage resources.

Data Distribution

DFS preserves the logical file organization from the user perspective by maintaining a Volume Location Database (VLDB) for all volumes in a DFS management context. When you move an NSS volume to a new volume in a different pool, the VLDB helps redirect queries to the new location.

When you split an NSS volume to relocate a directory’s data to a newly created NSS volume, DFS places a junction file in place of the directory at the source location. The junction contains a hint about the destination location of the data. When a user attempts to access the data, DFS uses that information to look up the location of the destination volume in the VLDB, then automatically redirects queries so that the session connection can be made transparently from the user’s point of view by going directly to the data. After the connection is made, the junction itself is no longer involved in the session.

Using junctions and the VLDB eliminates the user’s need to know the path to the physical location of the data. Not only does it decrease administration costs by allowing you to move a volume to a different server without making any announcements or needing to reeducate users, but it also simplifies the number of paths a user needs to remember if the data is spread among different volumes or servers.

For example, if John’s data is located on servers X, Y, and Z, you can create junctions on server X that point to all of his data on servers Y and Z. That way, John only needs to remember the path to server X, because with junctions, it appears as if the data is all located in one place.

Backup

DFS provides a solution to the common problem of storage volumes growing too big to back up within the desired or required time period. A too-large volume can be split into two (or more) volumes, and the resulting volumes backed up separately as required. You can split a volume at any directory to a new NSS volume without changing the logical path to files. You and your users can continue to use the logical paths when mapping network drives or creating login scripts. The physical location of data can change over time, and that change is completely transparent to the end user.

Data Migration

DFS can also provide a migration path for customers moving NSS volumes from NetWare to OES Linux. File data on NSS volumes can be moved from the NetWare servers to OES Linux servers without requiring that the customer commit to a full-scale change to an OES Linux environment. For an example, see Section 20.1.4, Migrating Data from NetWare 6.5 to OES2 Linux Servers.

20.1.2 Components of DFS

DFS Management Context

DFS operates within a management context. The management context is a preexisting container that you choose from your Novell eDirectory™ tree. The management context can have one or two VLDB services replicas. The NetWare 6.5 or OES NetWare servers that host replicas of the Volume Location Database (VLDB) services can exist anywhere in the management context, as shown below.

Figure 20-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 repsonsible for only those NSS volumes that are in its subtree but are not in a lower-level management context.

Figure 20-2 Multiple DFS Management Contexts in the Same Subtree

For an explanation of these management contexts and for more examples, see Section 20.1.3, Examples of DFS Management Contexts.

Volume Location Database

The Volume Location Database provides a mapping of the NSS volumes in its DFS management context. When you create a management context, DFS walks the subtree to locate the Volume objects for NSS volumes, assigns DFS GUIDs to them, then populates the VLDB with this information. The VLDB tracks NSS volumes on the following platforms in its management context:

NetWare 6.5
OES NetWare
OES Linux (target volume only)

Any NSS volume with a Volume object in the container belongs to the management context, unless it belongs to a management context that is defined at a lower level in the container. By default, NSS creates Volume objects in eDirectory when you create a volume with NSS tools.

Volume Location Database Services

The Volume Location Database services provide the framework for locating volumes in the management context. VLDB services involve the creation, day-to-day management, maintenance, and repair of the VLDB.

Replica Sites

A replica site is the server that hosts VLDB services and the VLDB file. Each management context has one or two replicas. When two replica sites are deployed for the management context, the VLDB services are equal replicas that automatically synchronize their data with each other. The servers can be any NetWare 6.5 and OES NetWare servers that are 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.

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 or with the VLDB management interfaces in ConsoleOne®.

DFS Junctions

A DFS junction is a logical placeholder for data that is stored on a different NSS volume. It is a virtual directory that points to the root of a target NSS volume.

To the user, a DFS junction appears to be a normal subdirectory in the NetWare file system; only its directory properties identify it as a junction. 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 junction itself can be located anywhere in the source NSS volume, including the root of the volume. Multiple levels of junctions are allowed. A junction can point to a volume that contains one or more additional junctions.

IMPORTANT:DFS junctions cannot be created on NSS volumes on OES Linux, but junctions can point to them from an NSS volume on NetWare 6.5 or OES NetWare. For information, see Section 20.2.2, Prerequisites for Target NSS Volumes on OES Linux.

When you split a volume, DFS copies the data to a newly created volume, creates a junction to replace the directory, and deletes the old data. For instructions on how to split a volume, see Section 20.14, Splitting Volumes.

You can also create a junction manually in ConsoleOne. The following tables describe the rules for manually creating junctions. For instructions on how to manually create a junction, see Section 20.18, Creating a DFS Junction Manually with ConsoleOne.

Table 20-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 NetWare 6.5 or OES NetWare It must be in the same eDirectory tree as the target volume.	None required. It can be in any management context in the eDirectory tree, or it can be in none.	An existing NSS volume on NetWare 6.5, OES NetWare, or OES Linux. It must be in the same eDirectory tree as the source volume.	Required. It can be in any management context in the eDirectory tree.

Source Volume

Source Volume’s DFS Management Context

Target Volume

Target’ Volume’s DFS Management Context

An existing NSS volume on NetWare 6.5 or OES NetWare

It must be in the same eDirectory tree as the target volume.

None required.

It can be in any management context in the eDirectory tree, or it can be in none.

An existing NSS volume on NetWare 6.5, OES NetWare, or OES Linux.

It must be in the same eDirectory tree as the source volume.

Required.

It can be in any management context in the eDirectory tree.

Move Volume Jobs

A Move Volume job helps you to do the following:

Move a crowded volume to a newly created volume in a different pool that has space available or that is expandable.
Move volumes to different servers in the same context to balance associated traffic and workload across multiple servers.
Move data between volumes faster than with a normal copy.

Use the Move Volume function 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 so that junctions that pointed to the old volume are not broken. The new volume’s name must be different if the new volume resides on the same server as the original volume. If the new volume’s name is different than the old volume, you must modify scripts and mappings to point to the new volume.

The following table describes the rules for moving volumes with DFS. For instructions, see Section 20.13, Moving Volumes.

Table 20-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 NetWare 6.5 or OES NetWare server that is also a replica server for the DFS management context NOTE:The replica server restriction will be removed in NetWare 6.5 SP7.	Required. The source and target volume must be in the same management context.	A newly created NSS volume on NetWare 6.5, OES NetWare, or OES Linux.	Required. The source and target volume must be in the same management context.

Source Volume

Source Volume’s DFS Management Context

Target Volume

Target’ Volume’s DFS Management Context

NSS volume on a NetWare 6.5 or OES NetWare server that is also a replica server for the DFS management context

NOTE:The replica server restriction will be removed in NetWare 6.5 SP7.

Required.

The source and target volume must be in the same management context.

A newly created NSS volume on NetWare 6.5, OES NetWare, or OES Linux.

Required.

The source and target volume must be in the same management context.

Split Volume Jobs

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 directory. 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 20.14, Splitting Volumes.

Table 20-3 Rules for Splitting Volumes

Source Directory	Source Volume’s DFS Management Context	Target Volume	Target’ Volume’s DFS Management Context
Any directory in an NSS volume on a NetWare 6.5 or OES NetWare server that is also a replica server for the DFS management context NOTE:The replica server restriction will be removed in NetWare 6.5 SP7.	Required. The source and target volume must be in the same management context.	The root of a newly created NSS volume on NetWare 6.5, OES NetWare, or OES Linux.	Required. The source and target volume must be in the same management context.

Source Directory

Source Volume’s DFS Management Context

Target Volume

Target’ Volume’s DFS Management Context

Any directory in an NSS volume on a NetWare 6.5 or OES NetWare server that is also a replica server for the DFS management context

NOTE:The replica server restriction will be removed in NetWare 6.5 SP7.

Required.

The source and target volume must be in the same management context.

The root of a newly created NSS volume on NetWare 6.5, OES NetWare, or OES Linux.

Required.

The source and target volume must be in the same management context.

DFS Management Tools

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

Distributed File Services: This plug-in allows you to create or delete DFS contexts, manage VLDB replica sites, manage VLDB services, and control move and split volume jobs. For an overview of the available tasks, see Section 3.1.9, Understanding the Distributed File Services Plug-In (NetWare 6.5 SP6).
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 3.1.8, Understanding the Storage Plug-In.

For more information about using iManager, see Section 3.1, Novell iManager and Storage-Related Plug-Ins.

You can also use ConsoleOne to manually create junctions. For information about accessing ConsoleOne, see Section 3.7, ConsoleOne.

20.1.3 Examples of DFS Management Contexts

This section describes multiple examples of DFS management contexts. The following icons represent eDirectory containers and objects in the examples.

Figure 20-3 Icons for eDirectory Containers and Objects

A Single DFS Management Context

In the following example, a single DFS management context is shown by a shaded box.

Figure 20-4 A Single DFS Management Context

Feature	Description
	The management context is defined at the eDirectory container called west.company (ou=west.o=company). Junctions can point to any NSS volume in the management context.
	Two replica servers host the VLDB services for the management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container west.company.
	Volume objects in the east.company (ou=east.o=company) subtree are not in a management context in this example, so it is not possible to create a junction to any NSS volumes in this part of the tree.

Feature

Description

The management context is defined at the eDirectory container called west.company (ou=west.o=company).

Junctions can point to any NSS volume in the management context.

Two replica servers host the VLDB services for the management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container west.company.

Volume objects in the east.company (ou=east.o=company) subtree are not in a management context in this example, so it is not possible to create a junction to any NSS volumes in this part of the tree.

Multiple DFS Management Contexts in Different Subtrees

In the following example, two management contexts in different subtrees are shown by shaded boxes.

Figure 20-5 DFS Management Contexts in Different Subtrees

Feature	Description
	The management context defined at west.company (ou=west.o=company) functions in a different subtree than the management context defined at east.company (ou=east.o=company). Replica sites for their VLDB services must reside within their respective management context. Junctions can point to any NSS volumes in either of the management contexts. Move volume and split volume jobs can be defined only for source and target volumes within the same management context.
	Two replica servers host the VLDB services for the west.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container west.company. In this example, the replicas are located in different organizational units in the subtree, but they could be in the same one.
	A single replica server hosts the VLDB services for the east.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container east.company.

Feature

Description

The management context defined at west.company (ou=west.o=company) functions in a different subtree than the management context defined at east.company (ou=east.o=company).

Replica sites for their VLDB services must reside within their respective management context.

Junctions can point to any NSS volumes in either of the management contexts.

Move volume and split volume jobs can be defined only for source and target volumes within the same management context.

Two replica servers host the VLDB services for the west.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container west.company. In this example, the replicas are located in different organizational units in the subtree, but they could be in the same one.

A single replica server hosts the VLDB services for the east.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container east.company.

Multiple DFS Management Contexts in the Same Subtree

In the following example, a second management context is added at a lower level in the same subtree. The two management contexts are shown by shaded boxes in the After figure.

Figure 20-6 Adding a DFS Management Contexts at a Lower Level in the Subtree

Feature	Description
	The management context is defined at west.company (ou=west.o=company). One of its two replica servers resides in the subtree legal.west.company where you want to create a second DFS management context. You must delete this replica from the west.company management context before you create the DFS management context for legal.west.company. If the replica in legal.west.company is the only replica server for west.company, you must create a second replica server in a different subtree of west.company, synchronize the VLDB on the second replica server, delete the replica in legal.west.company, then create the second DFS management context.
	The management context defined at west.company (ou=west.o=company) does not contain legal.west.company (ou=legal.ou=west.o=company). A single replica server hosts the VLDB services for the west.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container west.company, except for those NSS volumes in the legal.west.company subtree. You can optionally add a second replica in the subtree, but not under the legal.west.company subtree. Replica sites for their VLDB services must reside within their respective management context. Junctions can point to any NSS volumes in either of the management contexts. Move volume and split volume jobs can be defined only for source and target volumes within the same management context.
	The management context defined at legal.west.company (ou=legal.ou=west.o=company) functions independently of the management context defined above it. A single replica server hosts the VLDB services for the legal.west.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container legal.west.company. You can optionally add a second replica in the legal.west.company subtree.
	Volume objects in the east.company (ou=east.o=company) subtree are not in a management context in this example, so it is not possible to create a junction to any NSS volumes in this part of the tree.

In the following example, a second management context is added at a higher level in the same subtree. The two management contexts are shown by shaded boxes in the After figure.

Figure 20-7 Adding a DFS Management Contexts at a Higher Level in the Subtree

Feature	Description
	The management context is defined at legal west.company (ou=legal.ou=west.o=company). Its replica server is not affected by the management context you want to add at a higher level in the eDirectory tree.
	Volume objects in the east.company (ou=east.o=company) subtree are not in a management context in this example, so it is not possible to create a junction to any NSS volumes in this part of the tree.
	The management context defined at west.company (ou=west.o=company) does not contain legal.west.company (ou=legal.ou=west.o=company). A single replica server hosts the VLDB services for the west.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container west.company, except for those NSS volumes in the legal.west.company subtree. You can optionally add a second replica in the subtree, but not under the legal.west.company subtree. Replica sites for their VLDB services must reside within their respective management context. Junctions can point to any NSS volumes in either of the management contexts. Move volume and split volume jobs can be defined only for source and target volumes within the same management context.
	The management context defined at legal.west.company (ou=legal.ou=west.o=company) functions independently of the management context defined above it. A single replica server hosts the VLDB services for the legal.west.company management context. Its VLDB maps the location of the NSS volumes at all levels in the subtree defined by the eDirectory container legal.west.company. You can optionally add a second replica in the legal.west.company subtree.
	The east.company subtree is not affected by the addition of a DFS management context in a different subtree even though it is at the same level in the tree.

In both of the same-subtree examples, if you delete the higher-level DFS management context (west.company), the VLDB services on its replica server (svr2.servers.west.company) are stopped and its VLDB is deleted. Any junctions that point to NSS volumes in the deleted management context are broken. Deleting the west.company management context has no effect on the lower-level DFS management context at legal.west.company.

In both of the same-subtree examples, if you delete the lower-level DFS management context (legal.west.company), the VLDB services on its replica server (svr52.servers.legal.west.company) are stopped and its VLDB is deleted. The higher-level management context automatically expands to include the lower-level subtree. A VLDB repair adds the NSS volumes in the subtree to the VLDB. When the repair is completed, junctions that point to volumes in the legal.west.company subtree continue to work normally.

20.1.4 Migrating Data from NetWare 6.5 to OES2 Linux Servers

Assumptions:

Users have mapped drive letters to the NSS volumes on a NetWare 6.5 or later server.
Users/applications have scripts that map drive letters to the NSS volumes on a NetWare 6.5 or later server.
NSS volumes are on a NetWare 6.5 or later server and the admin wants to gradually migrate them to one or more OES2 Linux servers.
With OES2 Linux, the NSS volumes will support DFS junctions that might be present in the NSS volume after it is migrated.

For NSS volumes on a NetWare 6.5 or later server, you can use the Move option (under Storage>Volumes>Move Volume) to move a single volume at a time from the NetWare server to an NSS volume on an OES2 Linux server. The Move Volume command moves data, trustees, and quotas. It uses Novell Storage Management Services™ as the tool underneath to move the data. When the split is complete, the Volume Location Data Base automatically changes the location of the volume to its new location. The relocation of the data is transparent to all the users' and scripts' drive mappings. Before allowing users to access the volume, make sure its users are Linux-enabled eDirectory users on the new server so that NSS can enforce any user quotas you might have in place on the volume. For an explanation of why this is necessary, see Section 6.3, Access Control Issues for NSS on OES Linux.

For NSS volumes on a NetWare 6.5 or later server, you can use the Split Volume option (under Storage>Volumes>Split Volume) to move the contents of a directory on the volume to a new NSS volume on an OES2 Linux server. The Split Volume command moves the data, trustees, and quotas of the data beneath that directory to the new volume. When the move is complete, DFS replaces the old directory with a DFS junction that points to the new volume on the OES2 Linux server. You can relocate the data in a single volume to multiple volumes on one or more servers in this way so that data is gradually migrated to the OES Linux environment. However, you must keep the NetWare server running with the old junction-filled volume. Otherwise, you would need to create an OES2 Linux server with the same name as the old server and mount the old volume on it, remove the old server from the network, and rebuild the VLDB to recognize the new server instead of the old one. (You might also need to update its Volume object in eDirectory.) The relocation of the data is transparent to all the users' and scripts' drive mappings. Before allowing users to access the volume, make sure its users are Linux-enabled eDirectory users on the new server so that NSS can enforce any user quotas you might have in place on the volume. For an explanation of why this is necessary, see Section 6.3, Access Control Issues for NSS on OES Linux.

You can schedule any combination of up to four Move Volume or Split Volume jobs to run at any given time. They are usually scheduled for non-peak hours. For more information, see the following: