Database Reference
In-Depth Information
A Clusterware resource is employed to monitor the private network with the HAIP feature. The resource
ora.cluster_interconnect.haip
implements the HAIP feature for cluster interconnect, and an oraroot agent
monitors these private network interfaces.
$ crsctl stat res ora.cluster_interconnect.haip -init -p |more
NAME=ora.cluster_interconnect.haip
...
START_DEPENDENCIES=hard(ora.gpnpd,ora.cssd)pullup(ora.cssd)
START_TIMEOUT=60
STATE_CHANGE_TEMPLATE=
STOP_DEPENDENCIES=hard(ora.cssd)
...
USR_ORA_IF_GROUP=cluster_interconnect
Resource ora.cluster_interconnect.haip is also dependent upon CSSD and GPNP resource. So, this resource is
started after CSSD startup. Also, notice that USE_ORA_IF_GROUP is specified as cluster_interconnect, referring to the
network interface details stored in the GPNP profile.
The following output is taken from orarootagent_root log files. As you see in the following, the HAIP resource is
configuring link local IP addresses on the interfaces designated for cluster_interconnect. The agent monitors these
network interfaces too. If any interface fails, then the link local IP addresses are reconfigured to an available interface,
thus providing high availability.
[ USRTHRD][16] {0:0:2} HAIP: initializing to 2 interfaces
[ USRTHRD][16] {0:0:2} HAIP: configured to use 2 interfaces
[ USRTHRD][16] {0:0:2} HAIP: Updating member info HAIP1;172.18.1.0#0
[ USRTHRD][16] {0:0:2} InitializeHaIps[ 0] infList 'inf eth3, ip 172.18.1.0, sub 172.18.1.0'
[ USRTHRD][16] {0:0:2} HAIP: starting inf 'eth3', suggestedIp '169.254.28.111', assignedIp ''
[ USRTHRD][16] {0:0:2} Thread:[NetHAWork]start {
[ USRTHRD][16] {0:0:2} Thread:[NetHAWork]start }
[ USRTHRD][17] {0:0:2} [NetHAWork] thread started
[ USRTHRD][16] {0:0:2} HAIP: starting inf 'eth4', suggestedIp '169.254.78.111', assignedIp ''
Prior to 11g, private network details were stored in OCR only. Changing the private network details was easier.
From 11g onward, since private network configuration is stored in OCR, OLR, and profile.xml file, you need to pay
special attention to the sequence of steps to modify the private network configuration. Incorrect sequencing of steps
will lead to hung Clusterware startup. The high-level sequence of steps is as follows: 1) add private network interface
using
oifcfg add if
command, 2) shut down the Clusterware, 3) change the interface details in the database node, 4)
restart Clusterware, and then 5) delete old private network details. As the oifcfg command updates the profile.xml
file and OLR, change using oifcfg command is the correct way to modify network configuration. If you have modified
the private network in the OS without modifying the Clusterware, then a special procedure is needed to update the
profile.xml file. Profile.xml files are signed XML files; you should not update profile.xml file directly either.
Database instance and ASM instance query Clusterware to identify the private network details and use that
configuration for private network traffic. For example, the gv$cluster_interconnects view shows the interface and IP
address used for private interconnect traffic. Notice that the SOURCE column is null, indicating that this is queried
from Clusterware processes.
