After you have set up a basic clustered GroupWise system, you should consider some long-term management issues.
After setting up your GroupWise system in a Heartbeat cluster, while the cluster-specific information is fresh in your mind, you should record the cluster-specific information as part of the GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the information in the GroupWise objects if the configuration of your cluster changes.
To permanently record important cluster-specific information for the domain:
In ConsoleOne, browse to and right-click the Domain object, then click .
In the field of the domain Identification page, provide a cluster-specific description of the domain, including the cluster resource group and shared storage partition where the domain is located.
Click to save the domain description.
Select the Domain object to display its contents.
Right-click the MTA object, then click .
In the field of the MTA Identification page, record the secondary IP address associated with the domain’s cluster resource group.
When the Linux MTA runs with a user interface, this information appears on the MTA server console.
Click to save the description.
Click .
In the field, provide the secondary IP address that you provided in the GroupWise Installation program for use with the --ip switch in the MTA startup file.
Select .
This records this vital information in eDirectory as well as in the MTA startup file.
Click to save the MTA description and secondary IP address.
Continue with Recording Cluster-Specific Information for a Post Office and Its POA.
To permanently record important cluster-specific information for a post office:
In ConsoleOne, browse to and right-click the Post Office object, then click .
In the field of the post office Identification page, provide a cluster-specific description of the post office, including the cluster resource group and shared storage partition where the post office is located.
Click to save the post office description.
Select the Post Office object to display its contents.
Right-click the POA object, then click .
In the field of the POA Identification page, record the secondary IP address associated with the post office’s cluster resource group.
When the Linux POA runs with a user interface, this information appears on the POA server console.
Click to save the description.
Click .
In the field, provide the secondary IP address that you provided in the GroupWise Installation program for use with the --ip switch in the POA startup file.
Select .
This records this vital information in eDirectory as well as in the POA startup file.
Click to save the POA description and secondary IP address.
Continue with Recording Cluster-Specific Information for a Software Distribution Directory.
To permanently record important cluster-specific information about a software distribution directory located on a GroupWise partition:
In ConsoleOne, click .
Select the software distribution directory, then click .
In the field, record the shared storage partition where the software distribution directory resides.
Click , then click to save the software distribution directory description.
Continue with Knowing What to Expect in MTA and POA Failover Situations.
In a failover situation, the agents might need to perform some database repair as they start on the new node. The time required depends on the size of the databases involved.
Typically, the POA returns to full functionality faster than the MTA. This benefits GroupWise client users, who can reconnect to their mailboxes very quickly and probably do not notice if messages to users in other post offices are not delivered immediately. The only time a user needs to restart the GroupWise client is if he or she was actually in the process of sending a message when the POA went down. Notify can continue running even if the connection to the POA becomes unavailable and then it reconnects automatically when the POA is again available.
The MTA typically takes some time reestablishing the links to its post offices, other domains, and gateways, but this situation usually resolves itself in a few minutes without administrator intervention. If it does not, you can manually restart the MTA to speed up the process.
In comparison to failover, migration typically takes longer because the agents methodically terminate their threads and close their databases as part of their normal shutdown procedure. However, as a result, no database repair is required when the agents start up again in their new location.