How to Modify Public Network Information including VIP in Oracle Clusterware

g87616758

　　How to Modify Public Network Information including VIP in Oracle Clusterware

　　(Doc>　　-----------------------------------------------------------------------------
　　---
　　In this Document
　　Purpose
　　Scope
　　Details
　　Case I.   Changing public hostname
　　Case II.  Changing public IP only without changing interface, subnet or
　　netmask
　　Case III. Changing public network interface, subnet or netmask
　　Case IV. Changing VIPs associated with public network change
　　Planning for VIP changes
　　Gathering Current VIP Configuration
　　Stopping Resources
　　Modifying VIP and Its Associated Attributes
　　Restarting Resources
　　Others
　　Case V. Change SCAN VIP associated with public network change
　　References
　　-----------------------------------------------------------------------------
　　---
　　Applies to:
　　Oracle Database - Enterprise Edition - Version 10.1.0.2 to 12.1.0.2 [Release
　　10.1 to 12.1]
　　Information in this document applies to any platform.
　　Purpose
　　The purpose of this note is to illustrate how to change a public hostname,
　　public IP, a Virtual IP Address (VIP), VIP hostname or other VIP attributes
　　in an Oracle Clusterware/Grid Infrastructure environment.
　　Scope
　　Oracle Database 10g and 11g use VIPs (Virtual IP) in clustered environments
　　for clients to connect to the database. These VIPs are static IP addresses
　　associated with (virtual) hostnames and resolved through DNS (except when
　　using 11gR2 GNS).
　　During the installation of the Oracle Clusterware users are prompted to
　　enter a Virtual IP and Virtual hostname for each of the node in the cluster.
　　These are stored within the OCR (Oracle Cluster Registry) and different
　　components within the HA framework depend on these VIPs. If for some reason
　　the need arises to change either the VIP, the VIP hostname, or the subnet,
　　netmask etc, this procedure should be followed.
　　For changes associated with private network/cluster interconnect, please
　　refer to Note 283684.1
　　Details
　　Case I.   Changing public hostname
　　Public hostname is recorded in OCR, it is entered during installation phase.
　　It can not be modified after the installation. The only way to modify public
　　hostname is by deleting the node, then add the node back with a new hostname,
　　or reinstall the clusterware.
　　Case II.  Changing public IP only without changing interface, subnet or
　　netmask
　　If the change is only public IP address and the new ones are still in the
　　same subnet, nothing needs to be done on clusterware layer, all changes need
　　to be done at OS layer to reflect the change.
　　1. Shutdown Oracle Clusterware stack
　　2. Modify the IP address at network layer, DNS and /etc/hosts file to
　　reflect the change
　　3. Restart Oracle Clusterware stack
　　Above change can be done in rolling fashion, eg: one node at a time.
　　Case III. Changing public network interface, subnet or netmask
　　If the change involves different subnet(netmask) or interface, delete the
　　existing interface information from OCR and add it back with the correct
　　information is required.  In the example here, the subnet is changed from
　　10.2.156.0  to 10.2.166.0 via two separate commands - first a 'delif'
　　followed by a 'setif':
　　% $CRS_HOME/bin/oifcfg/oifcfg delif -global [/]
　　% $CRS_HOME/bin/oifcfg/oifcfg setif -global /:public
　　For example:
　　% $CRS_HOME/bin/oifcfg delif -global eth0/10.2.156.0
　　% $CRS_HOME/bin/oifcfg setif -global eth0/10.2.166.0:public
　　Then make the change at OS layer. There is no requirement to restart Oracle
　　clusterware unless OS change requires a node reboot. This can be done in
　　rolling fashion.
　　Once public network is changed, its associated VIP and SCAN VIP are also
　　required to change, refer to CASE IV and CASE V.
　　Note: for 11gR2, above command requires clusterware RUNNING on ALL nodes,
　　otherwise PRIF-33 and PRIF-32 will be reported, i.e.
　　[grid@racnode1 bin]$ ./oifcfg delif -global eth0/192.168.1.0
　　PRIF-33: Failed to set or delete interface because hosts could not be
　　discovered
　　CRS-02307: No GPnP services on requested remote hosts.
　　PRIF-32: Error in checking for profile availability for host racnode2
　　CRS-02306: GPnP service on host "racnode2" not found.
　　Case IV. Changing VIPs associated with public network change
　　Planning for VIP changes

　　In general, a complete outage is only required for pre-10.2.0.3>　　10.2.0.3 onwards, the ASM/database instance dependency on the VIP resource is
　　removed, so the VIP could be modified without having to take down the
　　ASM/database instance, only client connections to the database will be
　　affected when VIP is down. If the modification is a node specific, then only
　　connection to that node will be affected during the time of change.
　　Please follow Case III to ensure public network changes are made first. If
　　there is a node reboot or Clusterware restart after the OS network change,
　　vip will not start, please skip to step "Modifying VIP and its Associated
　　Attributes".
　　Gathering Current VIP Configuration
　　1. Gather the existing setup
　　for 10g and 11gR1, as Oracle Clusterware owner:
　　$ srvctl config nodeapps -n  -a
　　eg:
　　$ srvctl config nodeapps -n racnode1 -a
　　VIP exists.: /racnode1-vip/101.17.80.184/255.255.254.0/eth1
　　for 11gR2, as Grid Infrastructure owner:
　　$ srvctl config nodeapps -a
　　eg:
　　$ srvctl config nodeapps -a
　　Network exists: 1/101.17.80.0/255.255.254.0/eth1, type static
　　VIP exists: /racnode1-vip/101.17.80.184/101.17.80.0/255.255.254.0/eth1,
　　hosting node racnode1
　　VIP exists: /racnode2-vip/101.17.80.186/101.17.80.0/255.255.254.0/eth1,
　　hosting node racnode2
　　2. Verify VIP status
　　10.2 and 11.1:
　　$ crs_stat -t
　　11.2:
　　$ crsctl stat res -t
　　- it should show VIPs are ONLINE
　　$ ifconfig -a
　　(netstat -in for HP and ipconfig /all for Windows)
　　- VIP logical interface is bound to the public network interface
　　Stopping Resources
　　3. Stop the nodeapps resources (and all dependent resources ASM/DB only if
　　required):
　　10g and 11gR1, as Oracle Clusterware owner:
　　$ srvctl stop instance -d  -i    (optional for 10.2.0.3+)
　　$ srvctl stop asm -n                      (optional for
　　10.2.0.3+)
　　$ srvctl stop nodeapps -n
　　eg,
　　$ srvctl stop instance -d RACDB -i RACDB1
　　$ srvctl stop asm -n racnode1
　　$ srvctl stop nodeapps -n racnode1
　　11gR2, as Grid Infrastructure owner:
　　$ srvctl stop instance -d  -n     (optional)
　　$ srvctl stop vip -n  -f
　　eg,
　　$ srvctl stop instance -d RACDB -n racnode1
　　$ srvctl stop vip -n racnode1 -f
　　Note 1: The -f option is required for 11gR2 to stop listener resource,
　　otherwise following error will occur:
　　PRCR-1014 : Failed to stop resource ora.racnode1.vip
　　PRCR-1065 : Failed to stop resource ora.racnode1.vip
　　CRS-2529: Unable to act on 'ora.racnode1.vip' because that would require

　　stopping or>　　specified
　　...
　　4. Verify VIP is now OFFLINE and the interface is no longer bound to the
　　public network interface
　　$ crs_stat -t (or $ crsctl stat res -t for 11gR2)
　　$ ifconfig -a
　　(netstat -in for HP and ipconfig /all for windows)
　　Modifying VIP and Its Associated Attributes
　　5. Determine the new VIP IP/subnet/netmask or VIP hostname, make the network
　　change on OS first, ensure the new VIP is registered in DNS or modified in
　　/etc/hosts (for Unix/Linux) and \WINDOWS\System32\drivers\etc\hosts file (for
　　Windows). If the network interface is changed, ensure the new interface is
　　available on the server before proceeding with the modification.
　　For example:
　　New VIP is: 110.11.70.11 racnode1-nvip
　　new subnet is 110.11.70.0
　　new netmask is 255.255.255.0
　　new interface is eth2
　　6. Modify the VIP resource, as root user:
　　# srvctl modify nodeapps -n  -A //
　　eg:
　　# srvctl modify nodeapps -n racnode1 -A racnode1-nvip/255.255.255.0/eth2
　　Note 1: Starting with 11.2, the VIPs depend on the network resource
　　(ora.net1.network), the OCR only records the VIP hostname or the IP address
　　associated with the VIP resource. The network attributes
　　(subnet/netmask/interface) are recorded with the network resource. When the
　　nodeapps resource is modified, the network resoure(ora.net1.network)
　　attributes are also modified implicitly.
　　From 11.2.0.2 onwards, if only subnet/netmask/interface change is required,
　　network resource can be modified directly via srvctl modify network command.
　　as root user:
　　# srvctl modify network -k ] [-S /[/if1[|
　　if2...]]
　　eg:
　　# srvctl modify network -k 1 -S 110.11.70.0/255.255.255.0/eth2
　　There is no need to modify VIP or SCAN if other attributes are not changed.

　　Note 2: For 12.1.0.1>　　SECOND PUBLIC INTERFACE IN ORACLE 12.1, the srvctl modify network command
　　fails with:
　　# srvctl modify network -k 1 -S 110.11.70.0/255.255.255.0/eth2
　　PRCT-1305 : The specified interface name "eth2" does not match the existing
　　network interface name "eth1"
　　Workaround is to modify network resource with an empty interface name, then
　　modify it again with the desired interface name, eg:
　　# srvctl modify network -k 1 -S 110.11.70.0/255.255.255.0
　　# srvctl modify network -k 1 -S 110.11.70.0/255.255.255.0/eth2
　　The bug has been fixed in 12.1.0.2 and above.
　　* A special case for 11gR2 modifying the VIP hostname only without changing
　　the IP address.
　　For example: only VIP hostname changes from racnode1-vip to racnode1-nvip, IP
　　and other attributes remain the same.
　　If IP address is not changed, above modify command will not change the
　　USR_ORA_VIP value in 'crsctl stat res ora.racnode1.vip -p' output. Please use
　　the following command:
　　# crsctl modify res ora.racnode1.vip -attr USR_ORA_VIP=racnode1-nvip
　　Verify the changes for USR_ORA_VIP field:
　　# crsctl stat res ora.racnode1.vip -p |grep USR_ORA_VIP
　　Note: For Windows platform, the interface name needs to be in quote (") if
　　there is a space in between, eg:
　　As administrator user or software install user:
　　> srvctl modify nodeapps -n racnode1 -A 110.11.70.11/255.255.255.0/"Local
　　Area Connection 1"
　　7. Verify the change
　　$ srvctl config nodeapps -n  -a (10g and 11gR1)
　　$ srvctl config nodeapps -a (11gR2)
　　eg:
　　$ srvctl config nodeapps -n racnode1 -a
　　VIP exists.: /racnode1-nvip/110.11.70.11/255.255.255.0/eth2
　　Restarting Resources
　　8. Start the nodeapps and the other resources
　　10g and 11gR1, as Oracle Clusterware owner:
　　$ srvctl start nodeapps -n
　　$ srvctl start asm -n                (optional for 10.2.0.3+)
　　$ srvctl start instance -d  -i    (optional for 10.2.0.3+)
　　eg:
　　$ srvctl start nodeapps -n racnode1
　　$ srvctl start asm -n racnode1
　　$ srvctl start instance -d RACDB -i RACDB1
　　11gR2, as Grid Infrastructure owner:
　　$ srvctl start vip -n
　　$ srvctl start listener -n
　　$ srvctl start instance -d  -n       (optional)
　　eg,
　　$ srvctl start vip -n racnode1
　　$ srvctl start listener -n racnode1
　　$ srvctl start instance -d RACDB -n racnode1
　　Note: if the network attributes are changed, i.e. netmask changed, restart
　　the nodeapps
　　9. Verify the new VIP is ONLINE and bind to the public network interface
　　$ crs_stat -t (or $ crsctl stat res -t for 11gR2)
　　$ ifconfig -a
　　(netstat -in for HP or ipconfig /all for windows)
　　10. Repeat the same steps for the rest nodes in the cluster only if the
　　similar change is required.
　　Others
　　11. Modify listener.ora,  tnsnames.ora and LOCAL_LISTENER/REMOTE_LISTENER
　　parameter to reflect the VIP change if necessary.