HPE EVA Storage
1752662 Members
5634 Online
108788 Solutions
New Discussion юеВ

Re: DR Replication - Server moving - How to stop current source DR and have Destination be active co

 
SOLVED
Go to solution
Cali
Honored Contributor

Re: DR Replication - Server moving - How to stop current source DR and have Destination be active co

This look Good.

At this Point you can Shut Down the Server, Failover and restart.

And the Host should see the LUN and work on the other EVA.

(Be sure to thave the LUN also presented to the Host on the other Side.)

ACP IT Solutions AGI'm not an HPE employee, so I can be wrong.
happygrl
Advisor

Re: DR Replication - Server moving - How to stop current source DR and have Destination be active co

Thank you.

I just talked with our previous SAN admin and he did something similar with our other IBM AIX server - where we physically moved this server from one datacenter on one EVA across states to our other datacenter EVA. Only difference is he said he had the write mode as asynchronous not synchronous. he did it this way so it wasn't as server impactful as synchronous would be. As the server will be off, we could click the failover button on all 4 DR Groups one after the other then turn the server on.

Does the write mode of asynchronous or synchronous really matter that much? I know HP guiide recommends synchronous however this is not a live failover or a failover to a 2nd backup server at our 2nd array location (which is how I'm thinking HP is thinking of with the word "failover").

What I am doing is unracking a 4U server from our one location EVA (currently source), literally shipping this server by driving it to our 2nd datacenter EVA (currently destinatino), racking it, plugging in all fiber cables to brocade (already zoned), and while server is still OFF, I will log in to CV, click 'failover' button on all 4 DR Groups then power server ON. In this scenario, wouldn't asynchronous work better as it's less server impactful?

Cali
Honored Contributor

Re: DR Replication - Server moving - How to stop current source DR and have Destination be active co

If you have Sync, the Server get Write OK if the Data is on the Dest. EVA.

If there are latency on the Cable or Second EVA this latency go back to the Server.

Good: All Data is always the same on both Storage.

Bad: This may slow Down the Server if there is latency.

If you choose Async, the Server get Wirte OK if the Data is on the first Storage and than Data is Copyed to the Second.

Good: No Mirror impact to Server performance.

Bad: At Time x the Data may not be the same on both Storage.

I would do as HPE say:

Shut Down Server, switch to Sync, Move Server, Failover, Switch to Async, Power Up

While the Server is Down, there is no Performance Impact to the Server.

But this ensure, that all Data is competly the same (in Sync).

ACP IT Solutions AGI'm not an HPE employee, so I can be wrong.
happygrl
Advisor

Re: DR Replication - Server moving - How to stop current source DR and have Destination be active co

Thank you Cali, you have been extremely helpful throughout all this and all my questions. I cannot tell you enough how much I appreciate it.

All went as planned - the server was moved to the destination array, while it was off I change write mode on DR groups to sync, racked the server at new location, failed over each DR group and changed to async, unpresented the host from other (original source) array to ensure only the new source was seeing the luns, powered server on and all was good.

Now all that I'll need to do next week is delete the DR groups as we won't be needing the data replication to the other original source array. I imagine that is as simple as clicking the Delete button on each DR group on the source side which should just delete the DR groups but not the vdisks.

Thank you much again!

Cali
Honored Contributor

Re: DR Replication - Server moving - How to stop current source DR and have Destination be active co

So happygrl is happy.

That's fine.

cu Cali

ACP IT Solutions AGI'm not an HPE employee, so I can be wrong.