Creating Disk Monitoring Requests

Disk Monitoring Request Suggestions

The examples listed in Table 2-7 “Suggestions for Creating Disk Monitor Requests” are valid for both RAID and mirrored configurations. For examples on configuring MC/ServiceGuard dependencies, see Chapter 1, "Configuring MC/ServiceGuard Package Dependencies".

The following screens step you through creating a disk monitor request. Assume you want to be alerted when any disks fail and when they are back up. Figure 2-2 “Example: Selecting All Instances of /vg/vgName/pv_pvlink/status” 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 /vg/vgName/pv_pvlink/status

Assume you have a great need to know the status of your system at all times. You would need a short polling interval, perhaps between 30 and 120 seconds. (If you notice the disk monitor consumes too much CPU, you may want to set a longer polling interval.) Assume also that you want an Initial event sent to make sure the request is configured properly. You would want to set the Return option to send an event when disks come back up. You would configure the events to use opcmsg (ITO) protocol because you use HP OpenView IT/Operations as your system management tool. The parameters for your monitoring request would look like Figure 2-3 “Example: Configuring /vg/vgName/pv_pvlink/status Parameters to Notify When Disks Fail”.

Figure 2-3 Example: Configuring /vg/vgName/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 supported RAID 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 to each are

Figure 2-4 RAID Array Example

Each LUN on the RAID array is in it 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.

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 MC/ServiceGuard. See Chapter 1, "Configuring MC/ServiceGuard Package Dependencies". 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 fails. 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 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 busses. Both copies are in a single volume group. Assume you want to be notified when any physical device fails, and when you only have one copy of data, or when there is an MC/ServiceGuard failover. To configure this last request, you must duplicate your MC/ServiceGuard package dependency. See Chapter 1 "Configuring MC/ServiceGuard Package Dependencies".

Figure 2-5 Mirrored Disks Example

To configure the EMS alerts, create the following 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.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. If you have 3-way mirroring and only 1 copy of data is available, for example, you may want to correct the failure immediately to eliminate the single point of failure. Table 2-9 “Example for Interpreting the pv_summary for Mirrored Disks” is an example of how the 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 a forming or reforming cluster, so if you are using a lock disk with your cluster, you should request a monitor for that disk and send an alert to your system management software if the lock disk is unavailable. If the lock disk is unavailable during cluster formation, the cluster may fail to reform. Requests to monitor the lock disk might look like this:

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 this:

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