Building Disaster Recovery Serviceguard Solutions Using Metrocluster with Continuous Access for P9000 and XP A.11.00

Troubleshooting the Metrocluster with Continuous Access for P9000 and XP device
group monitor
The following is a guideline to help identify the cause of potential problems with the Metrocluster
with Continuous Access for P9000 and XP device group monitor.
• Problems with email notifications:
Metrocluster with Continuous Access for P9000 and XP device group monitor uses SMTP to
send out email notifications. All email notification problems are logged in the package log
file.
If a warning message in the package log file indicates the monitor is unable to determine the
SMTP port. It is caused by not having the SMTP port defined in the /etc/services file. The
monitor assumes that SMTP port is 25. If a different port number is defined, the monitor must
be restarted in order for it to connect to the correct port.
If an error message in the package control log file states that the SMTP server cannot be found
is caused by not having a mail server configured on the local node, such as sendmail. A mail
server needs to be configured and run in the local node for email notification. Once the mail
server is running in the local node, the monitor will start sending email notifications.
• Problems with Unknown Continuous Access Device Status:
Metrocluster with Continuous Access for P9000 and XP device group monitor relies on the
Raid Manager instance to get the Continuous Access device group state. Under the
circumstances when the local Raid Manager instance fails, the monitor is unable to determine
the status of the Continuous Access device group state. The monitor sends a notification to all
configured destinations, via email, stating that the state has changed to an UNKNOWN
status. Since the monitor does not try to restart the Raid Manager instance, you must restart
the Raid Manager instance before the monitor is able to determine the status of the Continuous
Access device group. Ensure to start Raid Manager instance with the same instance number
that is defined in the package’s environment file.
Troubleshooting Metrocluster SADTA
This section describes the procedures to troubleshoot errors and error messages that occur in a
SADTA environment.
Logs and files
This section describes the guidelines you must consider before working with files that must be
configured for SADTA.
Following are some of the guidelines:
• The Site Controller Package control log file can be specified using the attribute
script_log_file in the Site Controller Package configuration file.
Serviceguard defaults the Site Controller Package logs to the default log destination. The
default log destination for a given Site Controller Package is /var/adm/cmcluster/log
<Site_controller_package_name>.log.
• Specify the Site Controller Package log file under the directory specified for the
dts/dts/dts_pkg_dir attribute in the Site Controller Package configuration file.
• The Metrocluster storage preparation modules will also log to the Site Controller Package log
file.
• The RAC MNP package at every site will log in a file named <RAC MNP package control
script file name>.log under its package directory on the site nodes.
• The CFS MP MNP packages will log to a file named /etc/cmcluster/cfs/<CFS MP
MNP package name>.log on their corresponding CFS sub-cluster nodes.
Troubleshooting Metrocluster SADTA 83