Novell is now a part of Micro Focus

Making Your SYS Volumes Fault Tolerant

Novell Cool Solutions: Trench
By Carl Whitbeck, Tony Nero

Digg This - Slashdot This

Posted: 24 Jun 2002

Carl and Tony came up with a solution to the problem of losing your SYS drive mapping when a server fails, even though that server is part of a cluster. At the urging of a few cluster gurus at Novell they sent it to us for publication. (We're glad they did.)

In the current NetWare 5.1 clustered environment we are able to make any volume fault tolerant, with the obvious exception of the SYS volume. The SYS volume, by nature can not be clustered because it is located on the servers' internal hard drives. This presents the problem that if the server the user authenticates to and receives SYS volume mappings and/or search drives from fails, those mapping will fail too.

To provide a fault tolerant SYS volume we took advantage of the base NetWare technology of assigning servers a secondary IP address. This is used in Novell Cluster Services to allow the user (mapping) to follow the volume location by where the IP address currently resides.


Servers: NetWare 5.1 running NW51SP4 and CS1SP3 (Qty. 4)
Workstations: Windows NT / 98 / XP using the latest client versions.


  1. Create a NSS volume of one of the servers in the cluster using minimum disk space (i.e. 10MB) - we called our CLUSTERSYS. The size of the volume is not of importance since the volume will never be mounted. We used our primary cluster server for this because it's the server that will usually have the volume mounted.

  2. Create a New Cluster Volume object with a unique IP address that references the CLUSTERSYS volume created in step 1.

  3. Create a New Cluster Resource object using the Generic IP Service template.

  4. Copy the load script from the CLUSTERSYS Volume object and place it into the load script of the CLUSTERSYS Resource object.

  5. Modify the load scripts for the Resource object to NOT mount the volumes by remarking all lines EXCEPT those shown below:

    add secondary ipaddress
  7. Modify the unload scripts for the resource object to NOT dismount the volumes by remarking all lines EXCEPT those shown below:

    del secondary ipaddress
  9. Assign node fail over priority on the CLUSTERSYS Cluster Resource object.

  10. Delete all load and unload scripts from the CLUSTER SYS Volume object. Also remove all assigned nodes.
    NOTE: The reason we remove all scripts and node assignments from the Volume object is to ensure the Volume object never gets mounted or failed over.

  11. Online the Resource object to make the secondary IP address and the virtual NCP server active.

  12. Create a DNS "A" record that points to the IP address assigned to Resource object. We called our DNS object "server". If you have a large enterprise with multiple locations (clusters) you will need to create this record in each DNS zone pointing to the CLUSTERSYS Resource object ipaddress used for that cluster.

  13. Modify your login scripts (user, container, external, etc.) to use the DNS object to map to the SYS volume of your server. See following example:
  14. MAP ROOT S1:=\\server\sys\public
  15. In the event of a failure, the ipaddress for CLUSTESYS will fail to the next node in the Resource objects list and the mapping, having been done via IP, will follow that address. Unless a task was being performed at the time of failure, the move will be totally transparent to the user.

  16. To make sure the user does not experience a delay in logging into the network because their Default Server is not available, we set the user Default Server to the NCP server object that is created by default with the CLUSTERSYS Resource object.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates