HP StorageWorks SAN Virtualization Services Platform Administrator Guide (5697-0934, May 2011)

build of your destination virtual disks. This procedure requires you to be able to bring your DR
storage equipment to your main site before you install the equipment at your DR site.
To establish a DR site with minimal performance penalty:
1. Temporarily install the DR storage equipment at the same site as your main storage equipment.
2. Bring the DR storage equipment under the management of a new SVSP domain. The SVSP
domain name and the computer names of the VSM server appliances must be set to their final
value. Contact HP services if this name must be changed.
3. Expose the main site's SVSP domain and the DR SVSP domain to each other with a local
Ethernet connection.
4. Create async mirror groups to mirror the virtual disks on your main site to the DR SVSP domain.
5. Wait until the initial build of every destination virtual disk is complete.
6. Suspend the groups.
7. Disconnect the DR SVSP domain from the main site's SVSP domain. Each SVSP domain now
appears in the other SVSP domain with status absent.
8. Reinstall the DR SVSP domain at the DR site.
9. Establish connection between the SVSP domains over iSCSI. Verify that the SVSP domains
once again recognize each other.
10. Resume the async mirror tasks. The tasks now resynchronize and resume.
11. Each SVSP domain now sees the VSM servers of the other SVSP domain with status degraded
because the FC HBAs that previously used to connect the SVSP domains are no longer used.
Delete the FC HBAs that previously used to connect the SVSP domains from the HBA lists on
both SVSP domains. You can access the HBA list from the HBA node in the tree.
Testing or validating your ability to recover from a DR site without detaching
or splitting the async mirror group
The objective is to verify that the DR site has data from which you can recover. This can be achieved
by creating snapshots on the mirror PiTs of the destination element and presenting them to a test
server. During this process, all mirror service tasks remain operational, and none of the PiTs that
were created is modified. All the data modifications which the application does on the snapshot
are written aside to a dedicated temporary virtual disk which makes the snapshot writable. When
the test is complete, the snapshot is no longer needed, and should be deleted in order to allow
the PiT from which it was created to be deleted as part of the regular mirror process of deleting
older PiTs to maintain the user defined limit on the total number of PiTs.
To test/validate the data on the DR site:
1. Log in to the DR site's SVSP domain.
2. Create a snapshot from a PiT of the destination element that you want to validate, and present
it to a test server.
3. Test the application against the snapshot that was presented to a test server, and make sure
the snapshot is usable. There is a chance that the application will not be able to use the
snapshot as it is. This is because mirror standard PiTs are taken at times which are asynchronous
to the application state and capture only the data on back-end LU, whereas the application,
may, at that time, have some data in the host cache that was not yet committed to back-end
LU. You may need to run some application specific recovery procedures to bring the application
online. By definition, the problem should not affect user PiTs that were taken while all
application data was fully committed to back-end LU.
4. When the test is completed, stop the test application, unmount the snapshot, and delete the
snapshot from the SVSP domain.
Testing or validating your ability to recover from a DR site without detaching or splitting the async mirror group 81