Novell Documentation: GroupWise 6.5 - Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise

Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise

Cluster-enabling the shared volumes where domains and post offices reside greatly simplifies GroupWise administration. If you are creating a new GroupWise system, you might also want to cluster-enable shared volumes for the GroupWise administration snap-ins to ConsoleOne and for the GroupWise software distribution directory so that these locations are always available within the cluster. To review the concept of cluster-enabled shared volumes, see the applicable section of Novell Cluster Services Overview and Installation for your version of NetWare:

NetWare 6.x: "Cluster Enable Pools and Volumes"
NetWare 5.1: "Cluster-Enable Volumes "

The advantages of cluster-enabling GroupWise volumes include:

Drive mappings always occur through the virtual server associated with the cluster-enabled volume, rather than through a physical server. This guarantees that you will always be able to map a drive to the domain or post office database no matter which node it is currently located on.
The GroupWise snap-ins to ConsoleOne will always work no matter which node is running ConsoleOne.
Cluster-enabling the domain volume and installing the GroupWise agents to this volume guarantees that the GroupWise snap-ins to ConsoleOne will always be able to find the configuration files that they need to access.
When you rebuild a domain database or a post office database, you do not need to determine which node the database is currently located on.
Help desk personnel do not need to be trained to determine where GroupWise is running before they connect to a domain to create a new GroupWise user.

When you cluster-enable a volume, additional eDirectory objects will be created:

eDirectory Object	Object Name and Description
	clustername_volumename (default object name) A new Volume object will represent the cluster-enabled volume. It will be created by renaming the original Volume object that was tied to a physical server and associating it with a virtual server instead. For example, if your cluster name is GWCLUSTER and your original volume name is gwvol1, the new Volume object representing the cluster-enabled volume would be named gwcluster_gwvol1.
	clustername_volumename_SERVER (default object name) A new Server object will represent the virtual server to which the new cluster-enabled volume is tied. Continuing with the above example, the new Server object representing the virtual server would be named GWCLUSTER_GWVOL1_SERVER.
	volumename_SERVER.clustername (default object name) A new Volume Resource object will store property information for the cluster-enabled volume, such as start, failover, and failback mode information and load/unload scripts. These modes and scripts enable the cluster-enabled volume to function much like an independent server; hence, the SERVER portion of its name. The Volume Resource object is created in the Cluster container object. Continuing with the above example, the new Volume Resource object would be named GWVOL1_SERVER.GWCLUSTER.

eDirectory
Object

Object Name and Description

New Volume object

clustername_volumename (default object name)
A new Volume object will represent the cluster-enabled volume. It will be created by renaming the original Volume object that was tied to a physical server and associating it with a virtual server instead.

For example, if your cluster name is GWCLUSTER and your original volume name is gwvol1, the new Volume object representing the cluster-enabled volume would be named gwcluster_gwvol1.

New Server object

clustername_volumename_SERVER (default object name)
A new Server object will represent the virtual server to which the new cluster-enabled volume is tied.

Continuing with the above example, the new Server object representing the virtual server would be named GWCLUSTER_GWVOL1_SERVER.

New Volume Resource object

volumename_SERVER.clustername (default object name)
A new Volume Resource object will store property information for the cluster-enabled volume, such as start, failover, and failback mode information and load/unload scripts. These modes and scripts enable the cluster-enabled volume to function much like an independent server; hence, the SERVER portion of its name. The Volume Resource object is created in the Cluster container object.

Continuing with the above example, the new Volume Resource object would be named GWVOL1_SERVER.GWCLUSTER.

IMPORTANT: Notice that the default object names include the underscore (_) character. Some DNS name servers cannot resolve object names that include underscore characters. If you have met the system requirements described in Meeting Software Version Requirements, you will be able to rename these objects as needed when you cluster enable the volume.

Cluster-enabling the shared volumes used by GroupWise is highly recommended. Throughout the rest of this document, the term "GroupWise volume" means "a cluster-enabled shared volume used by GroupWise."

SYSTEM CLUSTERING WORKSHEET
Under Item 6: Shared Volumes for GroupWise Administration, list any shared volumes you want to use for GroupWise administration purposes. For example, you might have a shared pub: volume with a public directory where you install the GroupWise snap-ins to ConsoleOne instead of installing them on multiple administrator workstations. You might have a shared apps volume where you create the GroupWise software distribution directory. Mark whether or not you want to cluster-enable the GroupWise administration volumes. Under Item 7: Shared Volume for Domain, specify the name of the shared volume where you will create the domain. Mark whether or not you want to cluster-enable the domain volume. Also mark whether you will place the post office on the same volume with the domain. If you want the post office on a different volume from where the domain is located, under Item 8: Shared Volume for Post Office, specify the name of the shared volume where you will create the post office. Mark whether or not you want to cluster-enable the post office volume.

SYSTEM CLUSTERING WORKSHEET

Under Item 6: Shared Volumes for GroupWise Administration, list any shared volumes you want to use for GroupWise administration purposes. For example, you might have a shared pub: volume with a public directory where you install the GroupWise snap-ins to ConsoleOne instead of installing them on multiple administrator workstations. You might have a shared apps volume where you create the GroupWise software distribution directory. Mark whether or not you want to cluster-enable the GroupWise administration volumes.

Under Item 7: Shared Volume for Domain, specify the name of the shared volume where you will create the domain. Mark whether or not you want to cluster-enable the domain volume. Also mark whether you will place the post office on the same volume with the domain.

If you want the post office on a different volume from where the domain is located, under Item 8: Shared Volume for Post Office, specify the name of the shared volume where you will create the post office. Mark whether or not you want to cluster-enable the post office volume.

IMPORTANT: Because cluster-enabling the volumes where domains and post offices reside is so strongly recommended, this documentation does not include the steps for setting up domains and post offices on non-cluster-enabled volumes. If you decide not to cluster-enable GroupWise volumes, you will need to adjust the steps presented in this documentation for your system's specialized needs. Novell Cluster Services does provide a GroupWise Mail Server template for use when creating GroupWise Cluster Resource objects instead of cluster-enabled Volume Resource objects.