Creating Disk Monitoring Requests

Disk Monitoring Request Suggestions

The examples listed in Table 2-8 “Suggestions for Creating Disk Monitor Requests” are valid for both RAID and mirrored configurations.

The following series of screens provide a sample process for creating an HA Disk Monitor request. These samples use the EMS GUI, though the Package Dependency screens in ServiceGuard are similar. Refer to the Using the Event Monitoring Service (HP Part Number B7612-90015) for specific instructions.

Assume you want to be alerted when any disks fail and when they are back up. Figure 2-2 “Example: Selecting All Instances of /system/filesystem/availMb” shows you can select all instances of pv_pvlink, so you only have to enter the parameters once for each volume group. You still need to create multiple pv_pvlink requests, one for each volume group on your system. Click OK to set monitoring parameters.

Figure 2-2 Example: Selecting All Instances of /system/filesystem/availMb

The parameters for the monitoring request in Figure 2-3 “Example: Configuring /vg/vg01/pv_pvlink/status Parameters to Notify When Disks Fail” request an event notification when the resource value is not equal to UP. The polling interval for checking the resources value is 300. The notification method is an SNMP trap with a minor severity level. No initial, repeat or return values are requested.

Figure 2-3 Example: Configuring /vg/vg01/pv_pvlink/status Parameters to Notify When Disks Fail

All requests are created in a similar way. You need to make sure you perform these steps for all instances in all volume groups you want to monitor.

Resources to Monitor for RAID Arrays

These considerations are relevant to all RAID supported configurations listed at the beginning of this chapter. To adequately monitor a RAID system, create requests to monitor at least the following resources for all volume groups on a node:

Figure 2-4 “RAID Array Example” represents a node with two RAID arrays and two PV links.

Figure 2-4 RAID Array Example

Each LUN on the RAID array is in its own volume group: vgdance and vgsing. Assume this is one node in a 2-node cluster and you want to be notified when there is a failover, when any physical device fails, and when any logical volume becomes unavailable.

If you do not have ServiceGuard Manager installed with OpenView, to be notified when a package fails over, you must configure an EMS request that is the same as the package dependency you configured in ServiceGuard. See Using the Event Monitoring Service (HP Part Number B7612-90015). For this example, assume the package UP values were set as UP and PVG_UP.

To configure the EMS alerts, create the following requests:

If pv_summary is SUSPECT, you know a physical device failed. If pv_summary status is SUSPECT, you may want to look at your lv_summary to see if you can still access all data. If lv_summary is DOWN or INACTIVE_DOWN, you do not have a complete copy of data.

Resources to Monitor for Mirrored Disks

This section is valid for mirrored disks created with MirrorDisk/UX. Mirroring is required to be PVG-strict if you are using the HA Disk Monitor. Mirrored configurations that are not PVG-strict will not give you a correct pv_summary.

To adequately monitor mirrored disks, create requests for the following resources for all volume groups on a node:

Figure 2-5 “Mirrored Disks Example” represents two nodes with 2-way mirrored configuration with 10 disks on 2 buses. Both copies are in a single volume group. Assume you want to be notified when:

To configure this last request, you must duplicate your ServiceGuard package dependency.

Figure 2-5 Mirrored Disks Example

To configure the EMS alerts, create the requests listed in Table 2-12 “EMS Alert Requests” on each node:

Alerts need to be interpreted in relation to each other. In the table above, you would get an alert when PVG_UP is true. Although all data is available, the condition PVG_UP implies there are physical volumes that are not functioning and need to be fixed. See Table 2-15 “Root Volumes Monitoring Requests”. You may want to examine lv/copies to see how many copies of data are accessible and determine how urgently you need to repair the failures. For example, if you have 3-way mirroring and only one copy of data is available, you may want to correct the failure immediately to eliminate the single point of failure. Table 2-13 “Example for Interpreting the pv_summary for Mirrored Disks” is an example of how the HA Disk Monitor determines whether data is available in a mirrored configuration with 5 disks on each bus.

Resources to Monitor for Lock Disks

Lock disks are used as a tie-breaker in forming or reforming a cluster. If the lock disk is unavailable during cluster formation, the cluster may fail to reform. If you are using a lock disk with your cluster, you should configure a monitoring request for that disk and send an alert to your system management software if the lock disk is unavailable. Requests to monitor the lock disk might look like those listed in Table 2-14 “Lock Disk Monitoring Requests”:

The Repeat value in the Options will send an alert until the lock disk is available.

You need to create a request on each node in the cluster. Because the bus name and SCSI path to the lock disk may be different on each node, the resource instance may have a different name. It is merely a different path to the same lock disk.

Resources to Monitor for Root Volumes

In a high availability system, it is recommended that you mirror your root volume, and have them on separate links in separate PVGs. Note that the root volume should always be ACTIVE. Requests to monitor the root volume might look like those listed in Table 2-15 “Root Volumes Monitoring Requests”:

If one of the root volumes is unavailable, you are alerted and told which one has failed (pv_pvlink/status). You are alerted if you lose a root disk mirror. With the RETURN option, you are also notified when the mirror is restored.

Excluding Volume Groups from being Monitored

This feature implements an optional config file to the HA Disk Monitor. If the config file is not present when the HA Disk Monitor begins, the HA Disk Monitor processes all volume groups found in /etc/lvmtab. This is the default behavior.

If the HA Disk Monitor config file is present, the HA Disk Monitor reads the config file. Any volume groups in the file that are found are excluded (filtered out) from monitoring by the HA Disk Monitor. The config file must be located in the directory /etc/opt/resmon/monitors and be named diskmond.config. You must create this file in order to enable the filtering-out. There is a sample config file supplied in /etc/opt/resmon/monitors/diskmond.config.sample. The file and format are also documented in the diskmond manpage.

The diskmond.config file contains:

exclude_vg=/dev/vgxx

where—vgxx is the volume group to be excluded.

Add one line for each volume group to exclude. Ownership on the config file should be bin:bin. If the config file is present but empty, HA Disk Monitor assumes the default behavior and monitors all the disks. If there are typographical errors in it, HA Disk Monitor attempts to honor the exclude_vg's that it can find, if any.