EVA SAN controlled failover

[Phil Gaunt]

As part of our disaster recovery plan we are organising a controlled failover having recently upgraded our HP Storage Works Enterprise Virtual array to 3.110over the weekend of 4th Oct. Does anyone have any instructions or know of any procedures/ documents that would help us fail from one to the other without us missing anything? Once completed we will fail back to the primary node.

[Steven Clementi]

Phil:

We will need a bit more information about the environment...

1. Do you have a second EVA in a local/remote datacenter that you will be failing over to?

2. What Operating System(s) are running on your servers?

3. What are you looking to failover? Storage Array's? Servers? Clusters? any combo of these three(assuming you have a 2nd storage array and/or clusters)?



Steven

[Phil Gaunt]

We have two identical mirrored EVA's and although in seperate locations they reside on the same site and are attached via a fibred network.

We actually run Windows 2003 server/ESX/Tru64 Unix and Win 2000 cluster!
Within 2003/ESX all LUNS are presented off the primary EVA and the secondary EVA is maintained using CA. The ESX has aproximately 30 virtual servers running various flavours of windows. Would it be possible to create a dos script to shutdown these 30 servers rather than going onto each one and shutting down individually?

The Tru64 luns are mirrored across both EVA's using LSM

We are looking to failover the storage arrays, proceed testing applications then once complete failback to the primary EVA.

Regards
Phil

[Steven Clementi]

Phil:

The way a failover happens is, and assuming all your your vdisks are presented properly...

From Command View, you can "failover" DR Groups which basically swaps the roles of the replication source and target. The targets become the "live" luns that the servers can physically see

Now, assuming you have some control over the environment, you can pause cluster nodes and take other precautions so that you don't actually force a cluster node failover.

For Tru64, it should not matter since the servers are utilizing both EVA's already.

For ESX, I am not to sure. There is a Storage vMotion option, but not sure if/how that applies here.


Steven

[Uwe Zessin]

> For Tru64, it should not matter since the servers are utilizing both EVA's already.

No problem as long as the LUN WWN does not change.
If you use boot-from-SAN, you will have to configure new boot paths with WWIDMGR.


> For ESX, I am not to sure.

ESX is pretty picky. A simple change in the inquiry string (e.g. HSV200 to HSV300) and the VMFS will not be mounted. You either have to resignature or work around with LVM.DisallowSnashotLUN.

> There is a Storage vMotion option, but not sure if/how that applies here.

Does not apply for CA environments. It's a hot migration of VM configuration files and VMDK containers.

-----

No offense meant, but I really recommend spending some time with the CA documentation if you have not done, yet. The manuals contain pretty good information:
http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=SupportManual〈=en&cc=us&docIndexId=64179&taskId=101&prodTypeId=18964&prodSeriesId=471572