Recently, a student of mine wanted me to demonstrate failover of VIP.
Here is the demonstration:
Current scenario:
2 node 11.2.0.1 RAC cluster with SCAN and GNS
nodes : host01, host02
Overview:
– check that VIP’s of both the nodes are running on respective nodes
— Stop clusterware on host01
— check that VIP of host01 has failed over to host02
— Trace route of request to connect to VIP of host01 and verify that connection is not made as listener on host02 accepts requests to its own VIP only
— Trace route of request to connect to VIP of host02 and verify that connection is made as listener on host02 accepts requests to host02’s VIP
— start clusterware on host01
— check that host01 vip is running on host01 again
— Trace route of request to connect to VIP of host01 and verify that connection is made as listener on host01 accepts requests to its own VIP
Implementation :
- check that VIP’s of both the nodes are running on respective nodes
[root@host02 ~]# srvctl status nodeapps -n host01 VIP 192.9.201.247 is enabled VIP 192.9.201.247 is running on node: host01 Network is enabled Network is running on node: host01 [root@host02 ~]# srvctl status nodeapps -n host02 VIP 192.9.201.235 is enabled VIP 192.9.201.235 is running on node: host02 Network is enabled Network is running on node: host02
- Stop clusterware on host01
[root@host01 ~]# crsctl stop crs
- check that VIP of host01 (192.9.201.247) has failed over to host02
[root@host02 ~]# srvctl status nodeapps -n host01
VIP 192.9.201.247 is enabled
VIP 192.9.201.247 is running on node: host02
Network is enabled
Network is not running on node: host01
– Trace route of request to connect to VIP of host01 i.e. 192.9.201.147
– It can be seen there is no listener as listener on host02 accepts requests to host02’s VIP (192.9.201.235) only
[root@host02 ~]# trcroute 192.9.201.247 Route of TrcRoute: ------------------ Node: Client Time and address of entry into node: ------------------------------------------------------------- 08-JAN-2014 14:14:39 ADDRESS= PROTOCOL=TCP HOST=192.9.201.247 PORT=1521 TNS-12224: TNS:no listener TNS-12541: TNS:no listener TNS-12560: TNS:protocol adapter error TNS-03601: Failed in route information collection
– Trace route of request to connect to VIP of host02 i.e. 192.9.201.235
– It can be seen that connection is made as listener on host02 accepts requests to host02’s VIP
[root@host02 ~]# trcroute 192.9.201.235 Route of TrcRoute: ------------------ Node: Client Time and address of entry into node: ------------------------------------------------------------- 08-JAN-2014 14:14:51 ADDRESS= PROTOCOL=TCP HOST=192.9.201.235 PORT=1521 Node: Server Time and address of entry into node: ------------------------------------------------------------- 08-JAN-2014 14:14:52 ADDRESS= PROTOCOL=TCP HOST=192.9.201.235 PORT=1521
– start clusterware on host01
[root@host01 ~]# crsctl start crs
– check that host01 vip (192.9.201.147) is running on host01 again
[root@host02 ~]# srvctl status nodeapps -n host01
VIP 192.9.201.247 is enabled
VIP 192.9.201.247 is running on node: host01
Network is enabled
Network is running on node: host01
– Trace route of request to connect to VIP of host01 i.e. 192.9.201.247
– It can be seen that connection is made as listener on host01 accepts requests to its own VIP
[root@host02 ~]# trcroute 192.9.201.247 Route of TrcRoute: ------------------ Node: Client Time and address of entry into node: ------------------------------------------------------------- 08-JAN-2014 14:23:00 ADDRESS= PROTOCOL=TCP HOST=192.9.201.247 PORT=1521 Node: Server Time and address of entry into node: ------------------------------------------------------------- 08-JAN-2014 14:23:00 ADDRESS= PROTOCOL=TCP HOST=192.9.201.247 PORT=1521
I hope this post was useful.
Your comments and suggestions are always welcome.
—————————————————————————————-
Related LInks:
————————————————————————————–
Excellent. Thank You
Hi,
Thanks for the explanation. it was helpful indeed. One doubt here comes to my mind. once we have restarted the host01, what will happen to the sessions already running on host02, which were made due to failover.
Hi,
Thanks for your time and feedback.
The sessions already running on host02, which were made due to failover will continue on host02.
Hope it helps.
regards
Anju
I have question here… Our current version is 11.2.0.4.. 2 node rac. since we don’t have DNS in our network so we are using old method of connecting database using VIPs.
Question : What is the drawback of using VIPs instead of SCAN IPs?
Question : In case of Failover which one is more effective VIPs or SCAN IPs?
Hi Sunil,
1.SCAN enables the clients to use a single host name to access oracle databases running in the cluster. Clients using SCAN do not need to change their TNS configuration if you add or remove nodes in the cluster.
2. With SCAN, the parameter REMOTE_LISTENER of all the instances is set to SCAN listener. When a node is added, its local listener gets automatically registered with SCAN listener and we need not modify the parameter REMOTE_LISTENER.
3. Failover is equally effective whether using VIPs or SCAN.
Hope it helps.
Your comments and suggestions are always welcome.
Regards
Anju Garg
Your demonstration is good! May you tell me how to fail over the listener on node1 to node2 automatically when i fail over the VIP on node1 to node2 as you demonstration.
I really appreciate if you could reply to me.
Hi,
When both the nodes are functioning properly, each VIP is running on its assigned node, and connections are directed to the appropriate listener and service. When a node, say node1, fails, the VIP for node1 will failover to node2 but VIP for node1 will not be accepting connections to the database at this time because node2 is listening on its own VIP, not the VIP of node1. However, since the IP address of node2 is available for VIP of node1, an attempt by the client to connect to VIP of node1 will immediately get the response that no listener is available. The client, on receiving the message that there is no listener, will then immediately retry, using the next VIP in the ADDRESS_LIST, rather than waiting for TCP timeout of up to 2 minutes. Thus, a connect-time failover takes place and the connection attempt succeeds within a second or even faster.
Hope it helps.
Your comments and suggestions are always welcome!
Regards
Anju Garg