HPE 3PAR checkhealth: Troubleshooting Storage Alerts - 夜莺博客

HPE 3PAR checkhealth: Troubleshooting Storage Alerts

On an HPE 3PAR StoreServ system, checkhealth is the fastest way to turn a vague "array is degraded" report into a specific component list. It checks and displays the status of storage system hardware and software components — unresolved alerts, failing hardware, virtual volumes that are not optimal — and prints either a healthy verdict or a set of exception messages you can work through one at a time. This article covers how to run it, how to read the output, and which follow-up command each component class needs.

The command itself

cli% checkhealth
cli% checkhealth -list
cli% checkhealth alert
cli% checkhealth cabling
cli% checkhealth vlun
cli% checkhealth vv
cli% checkhealth ao

Run without arguments to check every component the tool can analyse. With no faults it prints each check followed by System is healthy:

cli% checkhealth
Checking alert
Checking cabling
...
Checking vlun
Checking vv
System is healthy

The command authority is Super or Service, so a read-only account will be rejected — use the service account rather than assuming something is broken. checkhealth -list enumerates every component name the tool supports on your code version, which is how you find the specifier for a component you have not seen before.

Reading alert exception messages

Alerts are the starting point, and their codes are structured: seven digits in the form AAABBBB, where the first three digits are the major code and the last four a sub-code. Two ways to see the full text:

cli% showalert
cli% showalert -d

Use the GUI (SSMC) or showalert -d for the detailed description and recommended action — the one-line showalert output rarely contains enough context to act on. HPE maintains a guided troubleshooting tool keyed on the alert code for the same purpose.

Component-specific follow-ups

Component What checkhealth looks for Follow-up commands
alert Unresolved alerts and their severity showalert -d, SSMC alert view
cabling Missing or single-pathed connections between nodes and cages showcage, showport, checkport
vv Virtual volumes not in optimal state showvv, showvv -s, checkvv
vlun VLUN export inconsistencies (host sees no path) showvlun, showhost
ao Adaptive Optimization: physical disk classes missing on a node pair showpd, showpd -p -devtype NL, showpd -p -devtype NL -nodes 0,1, showcage
pd Failed or degraded physical disks showpd -s, checkpd
ld Logical disk consistency showld -s, checkld
port Host and remote-copy port state showport, checkport

The Adaptive Optimization example

The ao check exists because AO can only move data between tiers that are present on all node pairs. A typical exception reads that a number of NL (nearline) physical disks are attached to one node pair with none attached to another. The response is to inspect disk distribution, not to add capacity blindly:

cli% showpd
cli% showpd -p -devtype NL
cli% showpd -p -devtype NL -nodes 0,1
cli% showcage cage6 cage7

In the documented example, 72 NL disks are attached to nodes 2 and 3 while nodes 0 and 1 have none. The immediate trap is to assume a cable or port failure: verify with showcage that both cages are visible through two ports before accepting the cable replacement that the alert message suggests. An alert that names a cable is a hypothesis, not a diagnosis.

Cabling checks and the two-path rule

The cabling check flags drive enclosures that are reachable through only one path. Every cage should be visible through two ports so that a single HBA, cable, port or cage failure does not remove the enclosure. Because the check reports a symptom rather than a failed part, work in this order: confirm both controllers can see the cage, confirm both paths are in the expected state with showport, and only then replace hardware.

General operational discipline

  1. Run checkhealth before and after every maintenance action — opening a case with a "before" snapshot is far more useful to support than a single failing output.
  2. Treat a clean checkhealth as evidence the array has no known exception conditions, not as proof that performance is good; use it together with performance data.
  3. Do not run destructive commands (checkvv, checkld with repair semantics) as a first response — they can make virtual volumes and logical disks consistent at the cost of data.
  4. For system-level recovery decisions such as setsysmgr wipe, treat the CLI reference as the authority and escalate before running it: it can start the system in a new-system state that removes system state and loses configuration.

For day-to-day capacity reporting on the same platform see HPE 3PAR thin provisioning and space reporting commands; for host-side path redundancy to the same array see RHEL DM-Multipath troubleshooting.

原文链接:https://zhiliao.h3c.com/EnclosureTechDoc/ziliao/15996156703656.pdf