HP LeftHand P4000 SAN Solutions - Manual (Page 5)

the SRM to manage. Volumes that are being remote copied only manually are not updated
consistently enough to be useful for disaster recovery and the SRM.
If a volume has scheduled remote snapshots, and you create an ad hoc manual remote snapshot
of that volume, then the SRA will recognize the manual remote snapshot along with the scheduled
remote snapshots. Such ad hoc remote snapshots may be useful to test failover with a more recent
copy than the schedule has, or to push the latest updates to the remote site before a foreseeable
disaster occurs.
IMPORTANT: A volume in the protected site should not have two or more schedules going to
multiple volumes on the same remote management group.
Volumes ignored by the SRA
Remote snapshots within the same HP StoreVirtual Storage management group are ignored. These
snapshots are not considered disaster recovery copies since they are usually created to clone a
volume in the HP StoreVirtual Storage, and copies that reside on the same SAN are not useful for
disaster recovery.
Testing failover at the recovery site
The SRM performs test failovers at the recovery site when requested. When test failovers are
requested, the SRA performs the following steps:
1.
Select the replicated volumes.
2. Identify the latest complete Remote Copy snapshot.
3. Delete any temporary writable space on that snapshot to ensure an unedited snapshot is
presented to ESX servers.
Use this snapshot to create a SmartClone volume.
4. Configure authentication for ESX servers to directly mount SmartClone volumes.
5. When testing stops, to conserve space on the SAN, delete the temporary writable space that
was used during the test.
Actual failover at the recovery site
In the event of a disaster, the SRM can perform actual failover when requested to. When actual
failover is requested, the SRA performs the following steps:
1.
Select the replicated volumes.
2. Identify and remove any incomplete remote copies that are in progress and present the most
recent completed Remote Copy as a primary volume.
3. Convert remote volumes into primary volumes and configure authentication for ESX servers to
mount them.
If an actual failover does not run completely for any reason, the failover can be called many times
to try to complete the run. If, for example, only one volume failed to restore and that was due to
a normal snapshot being present, the snapshot could be manually deleted and the failover be
requested again.
Reprotect at the recovery site
After a failover, the SRM can perform reprotect when requested to. When actual reprotect is
requested, the SRA performs the following steps:
1. On the original protected site (which will become recovery site after reprotect is executed)
a.
Pause any schedules going from the primary volume to the remote volume.
b. Remove any ESX Server assignments.
c. Change the primary volume to the backup volume.
How the SRA works with VMware SRM 5.x 5