VIP FAILOVER DEMONSTRATION

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:

Home

11g R2 RAC INDEX

Need For VIP In RAC

————————————————————————————–

 

7 thoughts on “VIP FAILOVER DEMONSTRATION

  1. 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.

    1. 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

  2. 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?

    1. 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

  3. 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.

    1. 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

Your comments and suggestions are welcome!