For this to happen you will need o stop the Failover Service and stop the Volume Replication tasks and switch them there positions from Source to Destination and Destination to Source then proceed with the Failover service to set there positions.
For this to happen you will need o stop the Failover Service and stop the Volume Replication tasks and switch them there positions from Source to Destination and Destination to Source then proceed with the Failover service to set there positions.
So, my VM hosts are connected to DSS, using RoundRobin and virtual IPs. They are and should be in production all the time (this in my target in this debate!).
Before stop the Failover Service, physical IPs of primary DSS must be added on hosts to connect iSCSI targets. In this short time, all paths are active (I/O). It is not safe to configure paths using Virtual and Physical addresses together for longer period, but for this short time, I think, it is “usable”?
After stop the Failover Service, virtual IP addresses are not active, so targets are connected via physical IPs.
If I understand Volume Replication, there is "the very identical" data on Source and Destination Volumes, if they are consistent, of course.
If it is true, physical IPs addresses of Secondary DSS can be added on hosts to connect iSCSI targets. "When running Volume Replication the destination volumes are not available while they are selected as destination volume, so forget all this"
After all paths are active (I/O), paths of the Primary DSS must be removed, ASAP. Hosts are connected only to Secondary DSS, now.
Only now we can switch the Volume Replication tasks off.
Old Secondary DSS “becomes to New Primary” and it is active and connected to VM hosts.
Is there something that I have missed?
Now follows a new Volume Replication and Failover setup.
Must I “clear metadata” on NewPrimary after switch positions from Destination to Source?
Last edited by Toni Bizjak; 02-16-2012 at 03:29 PM.
For clearing the metadata, and changing secondary to be primary, please find the following Forum post that can help you:
http://forum.open-e.com/showthread.php?t=1493
So, there is the problem in "my procedure".
http://kb.open-e.com/entry/147/
When running Volume Replication the destination volumes are not available while they are selected as destination volume.
Before stoping Volume Replication tasks, only paths of source Volumes are active(I/O) and VM hosts can't use (manually entereed) paths to destination Volumes.
I suppose, I'm not fast enought to make switchig procedure and reconnect paths between nodes.
Idea Nr. n+1:
After Manual Failover, Secondary DSS is active. Paths using Virtual IPs are still active (I/O). Can we add paths using Physical addresses of Secondary Node, now?
Better, I try to realise all this on two test DSS servers.
Less damage ...
Last edited by Toni Bizjak; 02-16-2012 at 03:30 PM.
Butler 1.5??? Huh?Originally Posted by Toni Bizjak
I've realised "Idea Nr. n+1:" and, it works.
My demo-system:
Two DSS Nodes with Eth addresses:
PRI (SEC)
192.168.0.115 (113)
192.168.101.115 (113) Virtual IP 20.0.1.13
192.168.102.115 (113) Virtual IP 20.0.2.13
192.168.110.115 (113) for Vol.Replication
ESXi5.0 as client:
Created VMKernel ports:
- 192.168.101.5 and 192.168.102.5 as PingNodes and "assisting ports"
- 20.0.1.5 and 20.0.2.5 for paths to Virtual IP.
All the time, Win VM is occupied with transfer data between two LUNs, created on tested DSS.
Cookbook tips (at your own risk!!!):
1. Setup Failover on both DSS and MPIO connection to ESXi. Test, if all works. Do not use Deny/Allow access for iSCSI targets.
2. Manual Failover PRI.
Virtual IP is still active. On SEC, Volume replication mode is switched to Source, so iSCSI targets are visible from ESXi, now.
3. On ESXi:
Add physical IPs of SEC (192.168.101.113 & 192.168.102.113).
Refresh all paths - 20.0.x.13 and 192.168.10x.113 should be active (I/O).
4. Stop Failover service on PRI.
On ESXi, paths 20.0.x.13 are "dead", but paths 192.168.10x.113 are still active (I/O).
5. Remove Replication tasks, used with Failover services
6. Uncheck "Enable Failover functionality" on PRI and SEC
7. On PRI select "Secondary node on localhost" and enter 192.168.0.113.
8. On SEC select "Primary node on localhost", as "Secondary node IP" enter 192.168.0.115 and as Ping node IP(s) enter 192.168.101.5 and 192.168.102.5
9. Select "Enable Failover functionality" on PRI (now NSEC) and SEC (now NPRI)
10. Create new volume replication tasks on NPRI and start them. In Failover Tasks, move them in the right window. (In my case, works aslo without “clear metadata”).
11. Start Failover on NPRI
12. On ESXi, refresh paths.
Paths 20.0.x.13 are active (I/O), also 192.168.10x.113 are active (I/O).
Remove all 192.168.x.113 paths. Prepare "Deny/Allow access" for iSCSI 20.0.x.13 targets.
13. A little pray during such operations, is said, helps even those who do not believe. Backup before, is said, helps also to those who believe.
Maybe, all this is already written somewhere, but I didn't notice. Someone could prepare Webinar on this topic?
Last edited by Toni Bizjak; 05-23-2012 at 11:00 PM.