Printable View
Is there a procedure described, how to switch two failover servers (active/pasive to pasive/active), without disconect virtual IP addresses?
Disk array on secondary server will be upgraded with SSD “cache” and this array will be (I suppose) much faster, so it should be better as primary server array.
You can do a manual failover to have status like this:
Primary /Passive; Secondary /Active
OK, there is a mistake in my question.
Better is: how to change nodes between two failover servers (Primary/Secundary to Secundary/Primary).
Is it possible without disconect virtual IP addresses?
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?
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 ...
Butler 1.5??? Huh?Quote:
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?
Hi Toni,
How did you go with your method in production?
Have you done it? and if so did it work?
Cheers
Ad
Now, I'm back from winter hollidays and I'm planning to realize "my" method in real word.
(never start tasks like this before hollidays, if you don't want to ruin them)....
....month or two later...
It works with some small corrections (now edited in original cookbook).