Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are adding an extra interface on our nodes and we are going to bond these so the VIP interface will change from eth5 to bond3.

Can someone point on documentation on what to do to reconfigure the interface name in a RAC?

Or simply give a procedure to do so.

share|improve this question
    
I don't know RAC very well at all, but it doesn't sound right to me that RAC would even know about the interface name - surely routing IP traffic is handled at a lower level than RAC? My guess is that it will 'just work'. – Jack Douglas May 12 '12 at 20:23
    
More information required - Grid (11g) or ClusterWare(10g)? – Ohadi May 16 '12 at 13:59
    
No. RAC works at a very low level. Before you install your application, you install a layer called CRS (cluster software) on ever node. You will configure 3 IPs, a public, a private for interconnect info and a VIP to which your applications will connect. The VIPs can failover to the over node, that is if a server goes down, the IP become available to the other node. RAC achives this by bounding this IP to your public interface ethx like this: ethx:1 (essentially splitting your NIC in 2 streams). RAC is quite awesome. Just damn painful to manage. – Nicolas de Fontenay Jul 16 '12 at 14:41
    
note: clusterware 10g. – Nicolas de Fontenay Jul 16 '12 at 14:42

If the NIC has changed for the Public / private NIC:

Modify the Public NIC information like so:

$CRS_HOME/bin/oifcfg/oifcfg delif -global <if_name>[/<subnet>]
$CRS_HOME/bin/oifcfg/oifcfg setif -global <if_name>/<subnet>: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.

It can be done one node at a time so there's no down time unless the OS requires it.

Once the public network is changed, the VIP needs to be modified like so:

View the VIP information:

$ srvctl config nodeapps -n racnode1 -a
VIP exists.: /racnode1-vip/101.17.80.184/255.255.254.0/eth1

Stop the nodeapps resources

$ srvctl stop instance -d <db_name> -i <inst_name>   (optional for 10.2.0.3+)
$ srvctl stop asm -n <node_name>                     (optional for 10.2.0.3+)
$ srvctl stop nodeapps -n <node_name>

eg, 
$ srvctl stop instance -d RACDB -i RACDB1
$ srvctl stop asm -n racnode1
$ srvctl stop nodeapps -n racnode1

Verify that the VIP is offline:

$ crs_stat -t

Modify VIP like so:

# srvctl modify nodeapps -n <node> -A <new_vip_address or new_vip_hostname>/<netmask>/<[if1[if2...]]>

eg:
# srvctl modify nodeapps -n racnode1 -A racnode1-nvip/255.255.255.0/eth2

Verify the change:

$ srvctl config nodeapps -n <node> -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

Restart nodeapps:

$ srvctl start vip -n <node_name> 
$ srvctl start listener -n <node_name>
$ srvctl start instance -d <db_name> -n <node_name>      (optional)

eg,
$ srvctl start vip -n racnode1 
$ srvctl start listener -n racnode1
$ srvctl start instance -d RACDB -n racnode1

Verify the VIP is online

$ crs_stat -t (or $ crsctl stat res -t for 11gR2)
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.