EV 9.0.4 DR scenario

[Rocketball]

Guys - we're trying to perform a read-only DR on our EV 9.0.4 production implementation. We have the following:

production -

2+1 MSCS with archiving and journaling (We do not use archiving and has been disabled)

DA/CA

DR -

1 stand alone server to recover Journaling

DA/CA

- Different SQL server

We have all of the data replicated via centera/SAN replication. Do we just follow the Data-only recovery to recover only the Journaling server in DR without the MSCS?

Anyone have any insight on any specific updates we have to make for non-clustering DR? We really just want a read only DR and run some sample searches in DR to make sure it recovered but we will not be writing anything in the DR site.

Any help would be appreciated.

[TheEmptyMind]

I am not too familiar with a clustering setup for EV, but I would assume that the EV server is reachable using an alias/CNAME.  We did the DR experiment and Read-Only setup just a week ago and we were able to make it functional in DR (which I guess is a good thing :=)).  As long as the EV server i.e., on the cluster is reachable via an alias, you would just change the alias to point to your DR server and run USL (Update Service Locations), assuming you plan to do the Building blocks failover/failback.  Also, you would need to put your Indexes and Storage in Backup mode, just to be absolutely sure, that you are not writing anything to the DR storage.

Good luck!

[Rocketball]

Thanks for the info. So few  questions -

1.Did you put EV in backkup mode immediately after performing the USL?

2. We have a different exchange server as well in DR, when would we apply the changes to point to the new SQL server in DR with different name?

[TheEmptyMind]

1) We put EV in backup mode after performing USL.  USL doesn't start the Storage and Indexing services on the server being failed over to, at least it behaved that way for us, so you can take your time.  If you don't trust it so much, you can simply opt to not mount the storage on the DR server until the EV services have been failed over, mount the storage, put EV in backup mode (the last two steps are interchangeable though as the ability to put the Index/Storage in backup mode is independent of the service running) and start services.  You could potentially put the services in Backup mode before failing over to DR, assuming the DR event is a planned one (in our case, it wasn't, and intentionally :=)).

2) Regarding SQL, we changed the IP address of the SQL server in DNS to point to the DR server -- did not deal with changing SQL server name within EV.

Hope it helps!

[John_Santana]

ok, does the SAN array based replication software is needed here to replicate the LUN to the DR site ?

[TheEmptyMind]

SAN based replication isn't mandatory, although it makes the failover easy. You could use, say, DFS-R.

[John_Santana]

Cool, thanks for the advice man,

I am now in the stage of implementing the SAN-SAN replication with EMC SnapView and then I was thinking if this is needed or not.

[TheEmptyMind]

I couldn't type much from my phone earlier, but I wanted to clarify a few things with DFS-R based on my experience.  We used DFS-R for more than 5 years to replicate to our DR site and recently switched from DFS-R to SAN based replication because ensuring DFS-R is replicating 100% of the data proved somewhat challenging for us.  You'll need to monitor DFS-R event logs either via SCOM/something else and need to act on the reports whereas Storage replication needed (so far) minimal intervention.  Moreover, we used DFS-R to replicate a few TBs of data and should there be an issue with DFS-R (and we have seen a few), re-syncing with DFS-R takes extremely long.  Given the size of our data, Storage replication made more sense than DFS-R, so we just switched to Storage replication model.

Hope it helps!

[John_Santana]

yes it helps for sure in terms of the size to replicate ~ 11 TB !

many thanks for your clarification.