HPE 3PAR Primera Peer Persistence: Failover Explained

Peer Persistence is the feature that lets a host cluster survive the loss of an entire array without a manual multipath intervention: two arrays hold a synchronously mirrored copy of the same volumes, the host sees paths to both, and a quorum witness decides which array is allowed to keep serving. The value is entirely in the automatic, transparent failover; the risk is that people deploy it and never test the failover path. Here is how the pieces fit together and what to verify.

The three components

• Remote Copy group (RCG) in Synchronous mode — the two arrays stay in lockstep; a write is only acknowledged when it exists on both sides.
• Quorum Witness — a small VM (independent of both arrays and of the host cluster) that arbitrates during a link failure, so both arrays cannot independently decide they are the survivor. This is the piece that prevents a split-brain on the storage layer.
• Host-side multipath — both arrays export the same VLUNs; the host MPIO stack sees paths to the primary and the secondary and switches path state on failover.

HPE’s supported deployments include Active Peer Persistence, 3DC APP and Meshed 3DC. For Windows hosts, HPE requires dummy LUNs to be configured so the host always has at least one active/optimised path to each node — a small detail that causes big failover surprises when missed.

Pre-flight verification

cli% showrcopy -d
cli% showrcopy groups
cli% showvv -s
cli% showhost
cli% showvlun -a

Check that every RCG is Started and Synced, that no active synchronisation task is pending, and that the witness is reachable and reporting both arrays. Never begin host-side work or firmware work while a resync is in flight.

Failover and failback, without drama

1. Planned failover (array firmware work): change the Remote Copy group direction to the standby array, then take the original down. Hosts should continue with no application interruption.
2. After the work, verify state from the primary with showrcopy -d and restart any stopped group: startrcopygroup <group_name>, or in bulk startrcopygroup -pat <pattern>.
3. Failback follows the same path in reverse, with resynchronisation of the delta changes before the host is moved back.
4. Upgrade one array at a time, never both in the same window, and perform the checks after each array rather than after the pair.

What to test before you need it

Pull a path (not a whole array) and confirm the host transparently moves to the peer array; pull the inter-array link and confirm the witness decides correctly instead of both arrays going read/write; then check the host cluster quorum behaviour with the surviving array. Document the expected duration of each step — a Peer Persistence “automatic failover” still costs the time your database takes to re-establish sessions, and that number belongs in the change plan, not in the incident review.

Related reading: HPE 3PAR CLI administration commands, 3PAR controller failure and offline replacement and NetApp SnapMirror configuration for a comparison with async replication.

原文链接：https://support.hpe.com/hpesc/public/docDisplay?docId=sd00002681en_us&docLocale=en_US&page=GUID-97A44D5D-0F9B-4750-8193-F0684E26E8F1.html