RAC: Modifying VIP in 10g

Modifying the VIP or VIP Hostname of a 10g Oracle Clusterware Node

Reference Notes:

Note 283684.1 How to Change Interconnect/Public Interface IP Subnet in a 10g Cluster

For complete srvctl syntax on 10gR1, Refer to Appendix B of the RAC Admin Guide:
http://download-west.oracle.com/docs/cd/B13789_01/rac.101/b10765/toc.htm

Changing the VIP involves modification of the nodeapps, which includes the Virtual IP address, the GSD, the Listener, and Oracle Notification Services (ONS). The VIP can be modified while the nodeapps are running, however changes will not take effect until the VIP, and hence the nodeapps, are restarted.

Depending on the version of Oracle Clusterware that you are running, other resources on a node, such as database instances and ASM instances, are dependent on the VIP, so stopping the nodeapps may cause other resources to be stopped – therefore, this change should be made during a scheduled outage.

In most cases, changing Data Centers or IP addresses within a Data Center will already incur an outage for other reasons, because changes need to be made at the operating system level, and servers may even need to be moved – so there is most likely a scheduled outage for this type of maintenence already.

However, in some cases – for example, if a VIP IP address was perhaps mistyped in DNS and needs to be corrected, you may be able to minimize the downtime by only modifying a single node. Also, as of 10.2.0.3 and higher versions, the ASM instance and DB instances no longer depend on the VIP, so it is possible to stop the nodeapps without bringing down the ASM instance or DB instance – but client connectivity is limited while the VIP is offline.

Verifying Current VIP configuration

1. The first step that should be done is to confirm the current configuration of the VIP. This is most easily accomplished by running the command:

srvctl config nodeapps -n -a

C:>srvctl config nodeapps -n node1 -a
VIP exists.: /node1-v/168.148.44.94/255.255.255.0/Public

These outputs show that:

The VIP Hostname is ‘node1-v’
The VIP IP address is ’168.148.44.94′
The VIP subnet mask is ’255.255.255.0′
The Interface Name used by the VIP is called ‘Public’

Any of the above configuration parameters associated with the VIP can be changed if they were originally input incorrectly, or perhaps they need to be changed due to external reasons (such as a data center move, or IP change as mentioned above).

Note:
In addition, you can also verify the IP address and interface of the VIP by running the ‘ifconfig’ command or ‘ifconfig -a’, and looking for the IP address associated with an interface ending in ‘:1′. The example below, on Linux, shows the interface as ‘eth0:1′

=============================
eth0:1 Link encap:Ethernet HWaddr 00:01:03:2C:69:BB
inet addr:192.168.2.125 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
…
…
=============================

On the Windows platform, run the command ‘ipconfig /all’. This will list all IP addresses bound to a given adapter, including the VIP, but it will not be obvious just from this output which one is the VIP address and which is the actual host IP address. Therefore, using ‘srvctl config nodeapps -n -a’ is the surest bet.

2. Once you have determined what the current configuration of the nodeapps is, be sure to make note of what values will remain unchanged, and what the correct/new values that you need will be. For example, if you are just changing the “Interface Name” you will need to know what the correct interface name is, but you also need to note the VIP hostname, IP address and subnet mask to ensure that this information is re-entered correctly.
Stopping Resources

3. Once you are ready to make the change, stop all resources that are dependent on the VIP on a given node. This includes all RAC database instances on that node, as well as the ASM instance on that node, if it exists and is being used (Note that starting with 10.2.0.3, the dependency between the VIP and the database and ASM instances has been removed):

3a). Stop database instances:
$ srvctl stop instance -d grid -i grid1

Where the database name is specified via the ‘-d’ option, and the instance on the appropriate node is specified with the ‘-i’ option.

Alternatively, to stop the entire database, on all nodes, you can issue the stop database command:

$ srvctl stop database -d grid

3b). To stop the ASM instance on the node, issue the following command:

$ srvctl stop asm -n node1

This command should be issued for each ASM instance using the appropriate node name. Alternatively, it is also possible to stop these resources via SQL*Plus and/or, on the Windows platform by stopping the associated services.

4. Next, stop the nodeapps using srvctl – i.e:

$ srvctl stop nodeapps -n node1

This will stop the VIP, GSD, Listener, and ONS daemon currently running on the nodes specified

Optional you can disable them not to restart just in case

srvctl disable database -d grid
srvctl disable asm -n node1
srvctl disable nodeapps -n node1
etc.

5. Verify that the VIP is no longer running by executing the ‘ifconfig -a’ or ‘ipconfig /all’ command again, and confirm that the IP address is no longer listed as running in the output.

If the interface still shows as online, this may be an indication that a resource which is dependent on the VIP is still running. The crs_stat command can help to show resources that are still online.

6. Change in hosts file

6. To make the actual modification to the nodeapps, the Oracle Clusterware stack must be up on the node where you are running srvctl from. To modify the nodeapps use the ‘srvctl modify nodeapps’ command with the following syntax:

srvctl modify nodeapps -n [-o ] [-A ]

Options Description:
-n Node name.
-o Oracle home for the cluster database.
-A The node level VIP address (/netmask[/if1[|if2|...]]).

$ srvctl modify nodeapps -n node1 -A 192.168.2.125/255.255.255.0/eth0

It should be noted that for the first parameter, you can specify either the hostname associated with the VIP, or the IP address associated with the VIP. Either way, the srvctl command will actually attempt to resolve the IP to a hostname, or the hostname to an IP, and it will store both entries in the OCR. So, assuming that the virtual hostname of ‘node1-v’ resolves to an IP address 192.168.2.125, the below command would have the same effect as the command using the IP address:

$ srvctl modify nodeapps -n node1 -A node1-v/255.255.255.0/eth0

Note that the interface names are case sensitive on all platforms. On some platforms, such as Windows, the Interface Name may have spaces in it – i.e. “Local Area Connection 1″. If that is the case, you must enclose the interface name in double quotes – i.e.

srvctl modify nodeapps -n node1 -A 192.168.2.125/255.255.255.0/”Local Area Connection 1″

On Unix and Linux systems, this command should be run as root. Attempting to run this command as the ‘oracle’ user or software owner will result in the following error:

PRKO-2117 : This command should be executed as the system privilege user.

On Windows systems, this command should be run as the user who did the original installation. This account should be an account with Local Administrator privileges on each node.

7. After making the change, you should verify that it is correct by re-running

‘srvctl config nodeapps -n -a’

Double-check the output to confirm that all parameters are correct.
Starting Resources Back Up

7. Once the modify nodeapps has been executed, you can re-start node-level applications via srvctl with the following syntax:

srvctl start nodeapps -n
i.e.:
$ srvctl start nodeapps -n rnode1

If any resources (such as database or ASM) were previously disabled, then they should now be re-enabled and re-started as well.

Repeat the same steps for all the nodes in the cluster. Since SRVCTL is a cluster wide management tool, you can accomplish these tasks for any specific nodes from one node, without the need to login individually to each of the cluster nodes.

Note: If only the IP address is changed, it should not be necessary to make changes to the LISTENER.ORA and TNSNAMES.ORA, provided they are using the vip hostnames for
the ‘HOST=’ entries.

If changing both the hostname and the VIP for a node, it will be necessary to modify the LISTENER.ORA and change the ‘HOST=’ entries to the new VIP hostname. This can be done manually, or by using the NETCA to reconfigure the listener. In addition, changes may need to be made to the TNSNAMES.ORA of any clients connecting to the old HOSTNAME.

In addition to modifying the nodeapps after an IP address or network change of some type, it may also be necessary to modify the networks that are stored in the OCR. If that is the case, please refer to the following note:

Note 283684.1 How to Change Interconnect/Public Interface IP Subnet in a 10g Cluster

Thanks

Geek DBA