Array, Replication Network, and Site Failures

Local HA controller failover in one array.

After short pause for the duration of the local HA failover, host I/O will continue to both arrays without losing RPO-Zero.

Async Replication source transfers may resume from a different array than before the failover.

Replication link failure.

After short pause, host IO continues to volumes only on the array that contacts the mediator first. This is per pod.

Failover is automatic and transparent and no administrator intervention is necessary.

Uniformly connected hosts:

• after a short pause in IO, continue IO to the array that won the race to the mediator.
• experience some storage path failures for paths to the array that lost the race to the mediator.
• in the mediator losing site will maintain access to volumes remotely across stretched SAN to the mediator winning site.

Non-uniformly connected hosts:

• in the mediator winning site will maintain access to volumes with no more than a pause in IO.
• in the mediator losing site will experience total loss of access to volumes.
• use host cluster software to recover the apps to a host in the mediator winning site. This may be automatic depending on the type of cluster.

Mediator failure or access to mediator fails.

No effect. Host IO continues through all paths on both arrays as normal.

Entire single array failure.

After short pause, Host IO automatically continues on surviving array.

Failover is automatic and transparent and no administrator intervention is possible or necessary.

Uniformly connected hosts:

• in the surviving array site, after a short pause in IO, continue IO to the surviving array that was able to reach the mediator.
• experience some storage path failures for paths to the failed array.
• in the site where the array failed will do IO to volumes remotely across the stretched SAN to the surviving array.

Non-uniformly connected hosts:

• in the surviving array site, after a short pause in IO, continue IO to the surviving array that was able to reach the mediator.
• in the failed array site will experience total loss of access to volumes.
• use host cluster software to recover the apps to a host in the other site. This may be automatic depending on the type of cluster.

Entire site failure.

After short pause, Host IO automatically continues on surviving array.

Failover of the array is automatic & transparent and no administrator intervention is possible or necessary.

Uniformly connected hosts:

• in the surviving array site, after a short pause in IO, continue IO to the surviving array that was able to reach the mediator.
• experience some storage path failures for paths to the array in the failed site.
• use host cluster software to recover the apps to hosts in the surviving site. This may be automatic depending on the type of cluster.

Non-uniformly connected hosts:

• in the surviving site, after a short pause in IO, continue IO to the surviving array that was able to reach the mediator.
• in the surviving site will maintain access to local volumes with no more than a pause in IO.
• use host cluster software to recover the apps to hosts in the surviving site. This may be automatic depending on the type of cluster.

Mediator failure followed by a second failure of replication link under 5 minutes from mediator failure, or failure of one array, or failure of one site.

(2nd failure occurs while mediator is unavailable)

Host IO access is lost to sync rep volumes on both arrays.

This is a double failure scenario; data service is not maintained through failure of either array if the mediator is unavailable.

Options to recover:

1. Restore access to either the mediator or replication interconnect and the volumes will automatically come back online, as per above scenarios.
2. Clone a pod create new volumes with different LUN serial numbers. New LUN serial numbers will prevent hosts from automatically connecting to and using the volumes, avoiding split-brain. Then re-identify and reconnect all LUNs on all hosts.

Mediator failure or access to mediator fails; 5 minutes or more later, replication network fails.

Pre-election will be used to keep the stretched pod volumes online on the FlashArray pre-determined by the pod failover preference.