SOLVED
I would do it in this Way:
Move the Server to the new Location, Power Up
He should see the LUNs that are still on the Old Location
Power Down the Server
Fail Over one LUN (check if the LUNs are presentet also on the Destination Side)
Power Up the Server, check it he can work with the Failover lUN
If OK, Power Down and Failover all other 3 LUNs.
(In EVA it is the best to Failover only if the Server is Down)
I'm not an HPE employee, so I can be wrong.
Before the server is moved and shut down, do I have to do anything on the Source side regarding the Data Replication Groups?
No
is there a way to suspend them? I imagine I would wait to Delete the DR Groups till after I fail over the Destination DR Groups.
Dont delete the DR Groups, why, simple do a Failover. You can check the LogFile use on the second Tab in the DR Group.
Also, deleting the DR Group would just delete that group NOT the actual luns (on source or destination) under Virtual Disks correct?
CV aks you about, if you want to delete the Destination LUN or not.
If will never delete the Source.
Failing Over (clicking the Failover button on the DR Group under Data Replication folder) just means it will make that DR Group the SOURCE rather than the Destination as it was orginally, is that correct?
Yes, it change the Replicaton.
Finally, on the Destination where the server was moved to, after clicking the Failover button for just the one lun, I would present the recently moved server to that same named LUN (via Vdisk Properties Presentation), and then UNpresent from the original Source side (to ensure the server will ONLY see the now failed over lun (originally destination), and have the server powered up and have him confirm he can see that one newly failed over LUN. Sound about right?
Normaly, you have the Presentation always on both Sides set.
CV automaticly "hides" the presentation for the Destination Array, so You only have to Push the Failover Button.
In real Live I do many time an unsupportet Online Failover, by Simply Push Failover and immediately do an Disk Rescan on the Host.
Single LUN Failover needs an DR Group for every LUN.
Lastly, after all is well, and the Destination is now the Source and he sees all the (destination - newly moved san) luns, I no longer need the Data Replication (I only did this for the physical server move), I can then go under Data Replication folder and "Delete" (via the delete button) on his DR Group which will only delete the Data Replication (not the vdisk either destination or source side). Correct?
Yes, it's your Choice also to delete the LUN on the Old Side, or leave it.
If you decide to leave it for some Days, first Unpresent the LUN, befor delete the DR Group.
If you are unsure, create a smal Test LUN, put it an an Test DR Group, test the Failover, Failback, Delete of DR.
Than you can also present the Test LUN on Source and Destination to any Server and Test again, with an Server attached.
I'm not an HPE employee, so I can be wrong.
>> When the server is powered off, what happens to the Data Replication status?
Nothing
>> What are the issues IF the server was ON and the failover was clicked?
This is unsupportet.
>> Considering the host server will be off when I click the failover button on the destination (now to be the source) side, this should still work even with the DR status marked as "down" correct?
The DR Status is not Down if the Server is Down.
Renember if you have ESX or Hyper-V, you can have multiple Server connected to one LUN at the same Time.
If one of them is Down it does not matter.
>> Finally, how can I be sure/verify the Data Replication has been continously replicating any deltas to the destination? Under Log tab on both source and destination, it says "Capacity: the log file is 0% full" (I designated half the size of the vdisk for logs) however on source side it says Operational state: Logging/Merging. whereas Destination side says Operational state: Not in Use.
If the Log is "Not in use", it means it is not needed. The Log is started and filling Up, if there is Data that can not be replicated to the Destination. So 0% is fine.
---
From: HP P6000 Continuous Access Implementation Guide
Planned Failover Procedure
To execute a planned failover:
1 . Optionally, move storage management to another management server. For instructions, see the HP P6000 Command View User Guide.
2. Ensure that all DR groups have resumed and are fully normalized. ChecktheDRgroupstatususingHPP6000CommandVieworHPP6000ReplicationSolutions Manager. If a DR group is merging or a normalization is in progress, wait for the process to complete.
3. If the write mode is currently set to asynchronous, set it to synchronous. If you are running XCS 6.000 or later, consider the following: ā¢ You must wait for the log to merge after changing the write mode to synchronous and then verify that the actual write mode has changed to synchronous. ā¢ Transitioning to synchronous write mode will impact server I/O performance. For environments running in asynchronous mode on XCS 6.000 or later, it is best to halt all server processing while data in the write history log is draining, as server I/Os will be treated in a synchronous replication manner, resulting in a severe performance impact on server write I/Os. ā¢ When performing a planned site failover, you must put DR groups in synchronous mode beforeperformingtheactualfailoveractivity.Omittingthismodechangebeforeperforming the site failover results in performing an unplanned site failover (and the resulting normalization). Once the site failover has finished, you can change the replication mode back to asynchronous mode again. ā¢ If the intersite link (or links) are broken and the DR group (or groups) has entered logging but has not yet been marked as a normalization (as occurs when the log reaches 100% capacity),alinkisre-establishedandalogmergeshouldbeperformedbeforethefailover is performed. ā¢ If the source site requires maintenance, put the DR groups into synchronous mode, wait for the write history logs to drain, and perform the failover. Once failover occurs, suspend replication and the destination array will start logging. When the primary array returns, re-establish a HP P6000 Continuous Access link, and take one of the following actions: ā¦ Wait for the log to drain. ā¦ Invalidate the log and start a normalization.
4. Properly halt all applications, and then shut down the servers. Ensure that the server has properly flushed all internally cached data. Failure to do this will result in the loss of data cached on the server.
5. Fail over the DR groups.
6. Issue operating system commands for resuming host I/O to the new source disks. For operating-system specifics, see āResuming host I/O after failoverā (page 118).
7 . If you plan to operate for an extended time at the remote site, you can change the write mode to asynchronous after the original primary array is back up and running. a. If the DR group is currently suspended, resume it and wait for log to finish merging. b. Once the log has finished merging, set the write mode to asynchronous. NOTE: Remember to set the write mode back to synchronous and allow the write history log to completely drain before you fail back to the original source.
8. If you plan to operate for an extended time at the remote site and need to enable failsafe mode on a DR group. Make sure the new destination (previous source) and Fibre Channel links are functioning, and then perform the following steps: a. If the DR group is suspended, resume it and wait for the log disk to finish merging. b. Once the log has finished merging, change the DR group to failsafe mode. NOTE: You can enable failsafe mode at the destination array during a merge or normalization.
After resolving the cause of a failover, you have three options: ā¢ Remain failed over on the remote array. ā¢ Return operations to the local array. See āFailback to the original source following a planned or unplanned failoverā (page 110). ā¢ Return operations to new hardware at the local site.
I'm not an HPE employee, so I can be wrong.
The Operational State should be Good.
You dont say if the DR is Scynronous or Async, this is a Big difference.
Can you Post a Screenshoot of the DR Group.
Create a smal 10GB Test LUN put in in a Test DR Group an try Failover/Failback.
It does not Matter if the Host is a ESX or Physical.
I'm not an HPE employee, so I can be wrong.
Create a smal 10GB Test LUN put in in a Test DR Group an try Failover/Failback. Can I do this without presenting to any hosts? If not, I cannot do this as I'm not able to power down any servers to do this without major change control.
The physical server we are moving is a 4U IBM AIX important server. These 4 vdisks and associated DR groups are dedicated to this physical host server alone.
Here is requested screenshots from source side. I have a DR group for each lun/vdisk.
Now for individual properties of each of the 4 DR groups:
#1
#2
#3
#4
(in addition to my above prior post), looks like I need to change my Write mode on all 4 of my DR groups from asynchronous to synchronous. Each DR group is about 300gb. How impactful might this be to the host physical server? I'm not thinking much as it's on the SAN back end but not sure, I know 2 of my 4 DR groups aren't showing much write I/O activity on those associated hard drives/luns.
I just changed write mode on my smallest DR group to synchronous and nothing was noted IO wise on the server so that's good. My log state now states "Operational state: Not in use" with log size editable and under connections Log state: Not in use. Is that normal with synchronous mode?
thanks!
screenshot example of log state now after write mode to synchronuos change (source side):
