Configuring Asynchronous Volume Replication Between Two HPE Nimble Arrays for Disaster Recovery

The Problem and the Takeaway

When a primary HPE Nimble array suffers an outage, rebuilding lost LUNs from backup can take hours or days. Configuring asynchronous volume replication between two Nimble arrays keeps a near-real-time copy of critical volumes on a second array, so you can promote the replica and bring applications back with bounded data loss instead of a full restore.

Asynchronous vs. Synchronous

Asynchronous replication ships changes on a configurable interval (15 minutes to 24 hours) and tolerates higher-latency links, making it suitable for geographically separated sites. Synchronous replication delivers RPO=0 but requires round-trip latency under 5 ms; exceeding that degrades source-array I/O. Validate the link with ping and iperf3 before committing to sync mode.

Prerequisites

• Both arrays run NimbleOS 6.x or later, with versions differing by at most one minor release (a larger gap blocks partnership creation).
• An active replication license on each system; verify with license --list.
• Network connectivity between management and replication interfaces, 1 GbE minimum, 10 GbE recommended.
• Clocks synchronized via NTP with offset under 10 ms; check with ntpstat.
• Enough pool capacity on the target for retention snapshots; low free space can suspend replication.

Step 1: Create the Replication Partnership

In the source array GUI, go to Protection > Replication > Partnerships and add a partnership: enter the target array management IP, admin credentials, and choose the type (async for longer distances, sync only if the latency requirement is met). Record the partnership ID returned. You must be logged in as a user with replication administration privileges.

Step 2: Configure the Schedule

For asynchronous mode, set the replication interval (15 minutes to 24 hours) and the retention count for snapshots on the target. If you enable a bandwidth throttle, note that it applies per partnership, not per volume: all volumes in the partnership share the limit, so an aggressive throttle slows every stream. For synchronous mode, enable continuous replication instead of an interval.

Step 3: Assign Volumes

Under Protection > Volumes > Replicate, select the volumes to protect, choose the partnership, and optionally set a throttle. Batch-assign related LUNs together so they fail over as a consistent set.

Step 4: Verify Initial Synchronization

From the array CLI (SSH as admin), run:

replication --list --detail

For each volume, confirm State=InSync, Lag within your configured RPO (or 0 for sync), and a recent LastSuccess timestamp. Also confirm ntpstat shows synchronized with offset under 10 ms on both arrays. If a volume stays out of sync, check network throughput, throttle settings, and license status before proceeding.

Step 5: Test Failover Without Touching Production

On the target array, use Protection > Replication > Failover > Test Failover. This mounts read-write snapshots of the replicated volumes without disrupting the source. Mount them, run application read/write validation to confirm data integrity and acceptable performance, then delete the test snapshots to reclaim space.

Unplanned Failover and Recovery

If the source becomes unreachable, use Force Failover on the target to promote replicas to primary, then update DNS or host mappings to the target array's data IPs. Be aware of the consequences:

• Force Failover breaks the partnership; it is not automatically restored.
• After the source recovers, use Reverse Replication to incrementally resync changes back to the original array.
• If metadata divergence exceeds the system threshold, a full resync is required, which retransfers all data.
• Volume-level granular failback is possible by reassigning individual volumes to a new partnership on the original array.

Limitations and Verification Checklist

• Sync mode: latency above 5 ms round-trip degrades source performance.
• Async RPO is bounded by your interval; a 1-hour interval means up to 1 hour of potential data loss.
• Retention snapshots consume target pool capacity; monitor free space.

Final checks:

1. replication --list --detail on both arrays shows InSync, acceptable lag, recent LastSuccess.
2. ntpstat offset under 10 ms on both arrays.
3. license --list shows Replication as Active on both.
4. Test failover completed with successful application validation, snapshots cleaned up.
5. InfoSight > Protection > Replication dashboard shows green health with no unresolved alerts.