Adding an additional listener to ODA

After deploying an Oracle Database Appliance, a standard set of production listeners are configured on bond0. This includes one listener on each of the virtual ip interfaces, and two SCAN listeners.

In my environment, I would very much like to have additional listeners on bond1. I use this as a management network, and find it convenient to let DBAs and operators run their tools over this network.

According to Oracle Support, there should not be any special considerations on ODA, and thus we can follow support note ID 1063571.1 just like we would with any other 11gR2 RAC infrastructure.

In my humble opinion, this particular support note isn’t too clear even if you have access to My Oracle Support, so I’ll describe the steps I used for my setup:

Production network on bond0 is 10.20.30.0/24
Management network on bond1 is 192.168.0.0/24

First out we need host file entries on both nodes for the new VIP interfaces:

/etc/hosts:

# VIP HOSTNAMES
10.20.30.42 oda1-vip.dolicapax.org oda1-vip
10.20.30.43 oda2-vip.dolicapax.org oda2-vip

192.168.0.23 oda1m-vip.dolicapax.org oda1m-vip
192.168.0.24 oda2m-vip.dolicapax.org oda2m-vip

Next we add the virtual ip interfaces to CRS. The network resource (specified with the -k 2 option) should be create implicitly:

 

su – root
cd /u01/app/11.2.0.3/grid/bin/
./srvctl add vip -n oda1 -k 2 -A 192.168.0.23/255.255.255.0/bond1
./srvctl add vip -n oda2 -k 2 -A 192.168.0.24/255.255.255.0/bond1

We can verify that the network resource and the virtual ip interfaces have been created with crsctl:

[root@oda1 bin]# ./crsctl stat res -t |grep -E ‘net|vip’
ora.net1.network
ora.net2.network
ora.oda1.vip
ora.oda1m-vip.vip
ora.oda2.vip
ora.oda2m-vip.vip
ora.scan1.vip
ora.scan2.vip

The final step is to create the actual listener. Oracle reccomends that you do this with the  network configuration assistant netca. The command must be run from the grid user.

roy@kayna:~$ ssh oda1 -l grid -X
grid@oda1′s password:
Last login: Tue Oct 23 22:15:41 2012 from 192.168.0.46
/usr/bin/xauth: creating new authority file /home/grid/.Xauthority
[grid@oda1 ~]$ netca

Just select Listener confguration and then Add and walk through the wizard, selecting the correct network resource (subnet) along the way. Note that netca sees the original listener on  default port of 1521, and will not allow another on the same port. I went with a name of LISTENER_M and a port of 1522 for my configuration.

This will take care of both listener.ora and OCR configuration.

However, I really do want the new listener to be listening the default port of 1521. netca complains that another listener is already configured on this port, even though it’s not on the same interface. The workaround is to manually remove and recreate the listener with srvctl using the -s option.

su – grid
srvctl stop listener -l LISTENER_M
srvctl remove listener LISTENER_M
srvctl add listener -l LISTENER_M -s -p 1521 -k 2
srvctl start listener -l LISTENER_M

We’re all set, and can now see the new listener (along with the default listeners) on the correct interface and port using netstat.

[grid@oda1 ~]$ netstat -ln | grep 1521
tcp 0 0 192.168.0.23:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.32:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.30:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.34:1521 0.0.0.0:* LISTEN
[grid@oma1 ~]$ ssh oma2
[grid@oma2 ~]$ netstat -ln | grep 1521
tcp 0 0 192.168.0.24:1521 0.0.0.0:* LISTEN 
tcp 0 0 10.20.30.33:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.31:1521 0.0.0.0:* LISTEN
tcp 0 0 10.20.30.35:1521 0.0.0.0:* LISTEN

or with lsnrctl

[grid@oda2 ~]$ lsnrctl status LISTENER_M

LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 23-OCT-2012 22:47:00

Copyright (c) 1991, 2011, Oracle. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_M)))
STATUS of the LISTENER
————————
Alias LISTENER_M
Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production
Start Date 23-OCT-2012 22:36:49
Uptime 0 days 0 hr. 10 min. 13 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/11.2.0.3/grid/network/admin/listener.ora
Listener Log File /u01/app/11.2.0.3/grid/log/diag/tnslsnr/oda2/listener_m/alert/log.xml
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_M)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.0.24)(PORT=1521)))
The listener supports no services
The command completed successfully

As you can see, the listener is up but supporting no services. Unless we want this to be a static listener, we need to tell the database to make it’s presence known.

We accomplish this by using the new LISTENER_NETWORKS parameter.

SQL> alter system set listener_networks = ‘((NAME=MGMT_NET)(LOCAL_LISTENER=oda1m-vip:1521)(REMOTE_LISTENER=oda2m-vip:1521))’ SID=’testdb1′ SCOPE=both;

System altered.

SQL> alter system set listener_networks = ‘((NAME=MGMT_NET)(LOCAL_LISTENER=oda2m-vip:1521)(REMOTE_LISTENER=oda1m-vip:1521))’ SID=’testdb2′ scope=both;

System altered.

A new look at the listener status will show that the instances are now properly registered:

Services Summary…
Service “TESTDB” has 2 instance(s).
Instance “TESTSB1″, status READY, has 1 handler(s) for this service…
Instance “TESTDB2″, status READY, has 1 handler(s) for this service…
The command completed successfully

 

 

This entry was posted in ODA, Oracle, Technical and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>