Please see my other blog for Oracle EBusiness Suite Posts - EBMentors

Search This Blog

Note: All the posts are based on practical approach avoiding lengthy theory. All have been tested on some development servers. Please don’t test any post on production servers until you are sure.

Tuesday, October 25, 2011

VIP Concept

1- The system shown here is 2 node RAC


On each node there are two interfaces, one for public network connection and second one used for private interconnect traffic.
2- Before you configure RAC VIPs, new IP addresses are required: One for each node in cluster:
VIPCA manages your RAC VIP configuration during Oracle Clusterware installation. RAC VIPs should
also be registered in DNS and must be on the same subnet as public IP addresses. If not in DNS, then they should be at least in the /etc/hosts file for all nodes in cluster and any client node accessing the cluster.
This is the situation in the below example where we use hosts file. It is assumed the /etc/hosts file is common to both nodes, and any client accessing the cluster.
3- crs_stat -t (assume that your RAC VIP applications are not started in you environment.

Now start your RAC VIP applications on both nodes.
srvctl start nodeapps -n node1
srvctl start nodeapps -n node2
4-
The RAC VIP application automatically starts a new interface(ETH0:1 in Pic ) to declare the corresponding node1-vip IP address. In unix you can use ifconfig command to list defined interfaces and in windows ipconfig.

From and Oracle Clusterware perspective, both RAC VIP applications are started. One on each node. The goal of these applications is to monitor the existance of the ETH0:1 interface at regular intervals. When a failure occurs on a node (ie; node down or public network interface down), the Oracle Clusterware will relocate the VIP to another node in the cluster.

Let us see what happens when you start the listeners on both nodes.
srvctl start listener -n node1
srvctl start listener -n node2



The listener on each node reads its listener.ora file. RAC forces the listener to listen only on three end points in the example above (although we don't show the one for EXTPROC): The extproc, the node1-vip address and public IP address. This is enforced by using the IP=FIRST entry for the last two addresses. If not used, problems can occur during failure and recovery situations.
in addition the listener.ora file should either put an IPC=EXTPROC entry first, or the host IP entry first. Otherwise if the VIP fails over, the lsnrctl stop command used by the listener stop action script will try and contact the listener using the VIP and time out.
The result is that the listener only listen on two end points (as in our example on node1: 138.20.147.110 and 138.20.147.111)

what happens when a client tries to connet using VIP names.


As mentioned in the pic above, suppose first address tried in node1-vip. The connection is routed to node that has the node1-vip configured, in this case, node1. The connection request is processed by the local listener.
Suppose the Node1 is down now. Oracle clusterware automatically relocates the VIP application from node 1 to node2. The effect is to start the definition of a new interface (ETH0:2) associated with the node1-vip.



You start to understand why we are using VIPs. This allows an IP address to be always available on on of your cluster nodes. Without this design in place, if a node goes down, and its corresponding IP address is no longer available on the network, clients attempting to connect through  this IP address will end up awaiting for a TCP/IP timeout that could be as long as 10 minutes before realizing that the address is no longer reachable.

However, this is only relevant when clients attempt to connect, or when starting to execute a new SQL statement. Once executing a SQL statement, if the corresponding nodes goes down, we need another mechanism to make sure clients are aware of the disruption quickly. The mecahism used in this case is called Fast Application Notification (FAN).


If now first node comes backup. The interfaces are defined again. The RAC VIP application for the first node is failed back to its originating node. This forces the corresponding  interface to be removed from the second node and redefined on the first node. The listener is restarted too.

what happens to RAC VIP in case of a network failure.
Suppose there  is network failure on public interface on node1. It will stop the corresponding RAC VIP application and it is restarted automatically on the second node.

Suppose now network is fixed. However, the RAC VIP application on node1 is not relocated automatically. We have to manually restart the VIP application on the first node to force the VIP application to relocate its originating node. You could also force the relocation by restarting any dependant resource like the ASM or Database instance.
srvctl start nodeapps -n node1
You local RAC VIP application is now restarted on its original node.
another possible configuration for your RAC VIP applications


In this case you have another interface (ETH2) used for the redundancy purpose in case of  interface failure. In case first public interface goes down. The local RAC VIP application is  relocated on the surviving interface. In case last public interface goes down. The RAC VIP application is then failed over to the
surviving node.

2 comments:

super said...

Hello. Thank you very much. One question: If I have only node1-vip IP Address up all the time, why we need to add node2-vip also in tnsnames.ora ?

DBMentor said...

You can have one VIP in your tnsnames.ora but node2-vip is used for load balancing and failover.