APPLIES TO:
Oracle Database - Enterprise Edition - Version 11.2.0.1 and laterInformation in this document applies to any platform.
GOAL
During the Grid Infrastructure installation, the (default) node VIP listener is always created referencing the public network.
However, some systems may be attached to more than 1 public network, so there may be a need to create a second listener for this second public network.
The purpose of this note is to explain how to add/create/configure a second listener on a second network in an 11.2 Grid Infrastructure environment.
SOLUTION
Assume the following names are defined for two nodes cluster (DNS or /etc/hosts):
racnode1 10.10.10.1
racnode1-vip 10.10.10.11
racnode2 10.10.10.2
racnode2-vip 10.10.10.22
# scan name
racscan 10.10.10.41
10.10.10.42
10.10.10.43
# host name for the 2nd public network and associated VIP on eth2
node1n2 20.20.20.1
node1n2-vip 20.20.20.11
node2n2 20.20.20.2
node2n2-vip 20.20.20.22
A listener has already been created on 10.10.10.x network, we are going to create a 2nd listener on 20.20.20.x network.
1. Ensure a VIP address is defined for the 2nd public network
In this example it's node1n2-vip and node2n2-vip (see above).
2. Create the CRS resource for the 2nd network
A new network and new vip resources for the 2nd network are created by using the '-k' switch (Please note: the <node_name> should be supplied in lowercase):
# srvctl add vip -n <node_name> -k <network_number> -A <name|ip>/<netmask>/[if1[|if2...]] [-v]
eg:
# srvctl add vip -n racnode1 -k 2 -A 20.20.20.11/255.255.255.0/eth2
# srvctl add vip -n racnode2 -k 2 -A 20.20.20.22/255.255.255.0/eth2
This command will implicitly create the dependent network resource.
From 11.2.0.2+, network resource can be created explicitly:
# srvctl add network [-k <net_num>] -S <subnet>/<netmask>/[if1[|if2...]] [-w <network_type>] [-v]
eg:
# srvctl add network -k 2 -S 20.20.20.0/255.255.255.0/eth2
Then add vip resource for the 2nd network:
# srvctl add vip -n racnode1 -k 2 -A 20.20.20.11/255.255.255.0/eth2
# srvctl add vip -n racnode2 -k 2 -A 20.20.20.22/255.255.255.0/eth2
The CRS resource 'ora.net2.network' and 2nd network vip should now have been created, they are both required for the 2nd listener, run the following command to verify:
ora.net1.network
ora.net2.network
ora.racnode1.vip
ora.node1n2-vip.vip
ora.racnode2.vip
ora.node2n2-vip.vip
...
3. Create a new RAC listener using 'netca'
As the grid user invoke "netca" from the 11.2 GRID_HOME, the select "Listener configuration" -> "Add", enter Listener name as required. For example: "LISTENER_2".
On the next page, "Select Subnet", the 2nd subnet will appear in the drop down list. For example:
1 10.10.10.0/255.255.255.0
Select subnet 2 , select the protocol and define the Listener port as desired to complete the listener creation.
$ ./srvctl add listener -l LISTENER_2 -p 1521 -k 2
PRCN-2061 : Failed to add listener ora.LISTENER_2.lsnr
PRCN-2065 : Port(s) 1521 are not available on the nodes given
PRCN-2067 : Port 1521 is not available across node(s) "racnode1"
The workaround is to use "-s" option:
$ ./srvctl add listener -l LISTENER_2 -s -p 1521 -k 2
4. Verify the new RAC listener
The new listener will be started at the end of netca. This listener will listen on the IP address 20.20.20.11 (or 20.20.20.22 for node 2) associated with the 2nd network. To check:
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 08-FEB-2010 16:10:23
Copyright (c) 1991, 2009, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_2)))
STATUS of the LISTENER
------------------------
Alias LISTENER_2
Version TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date 08-FEB-2010 16:10:20
Uptime 0 days 0 hr. 0 min. 2 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u02/app/11.2.0/grid/network/admin/listener.ora
Listener Log File /u02/app/oragrid/diag/tnslsnr/racnode1/listener_2/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_2)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.10.10.1)(PORT=1588)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST= 20.20.20.11)(PORT=1588)))
The listener supports no services
The command completed successfully
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER_2)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=20.20.20.11)(PORT=1588)))
5. Prepare the database instance for the new listener
To ensure that connections to the remote listener are only redirected to the local listener on the same network, LISTENER_NETWORKS parameter needs to be set in the pfile or spfile for the database instance.
Assuming the RDBMS $ORACLE_HOME/network/admin/tnsnames.ora (or the $TNS_ADMIN/tnsnames.ora) has the following local and remote listener defined, prepare similar content for each node using node specific VIP name (or VIP IP adddress). For example, on node1:
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 20.20.20. 11)(PORT = 1588))
)
remote_net2 =
(DESCRIPTION_LIST =
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 20.20.20.11)(PORT = 1588)))
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 20.20.20.22)(PORT = 1588)))
)
On node 2:
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 20.20.20. 22)(PORT = 1588))
)
remote_net2 =
(DESCRIPTION_LIST =
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 20.20.20.11)(PORT = 1588)))
(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 20.20.20.22)(PORT = 1588)))
)
The database parameter LISTENER_NETWORKS needs to be set to:
Without using sid="<inst>', above change will be applied to all instances. The local_listener defined with host VIP(if it is defined, it is not required and will be set automatically by CRS upon instance startup) and the remote_listener defined with SCAN name should remain unchanged.
1. Listeners specified by the LISTENER_NETWORKS parameter should not be used in the LOCAL_LISTENER and REMOTE_LISTENER parameters. Otherwise, cross registration will happen and connections will be redirected cross networks.
2. Due to unpublished bug 8678541 INCORRECT ENDPOINTS OF LISTENER ON THE SECOND NETWORK, the 2nd listener by default will also listen on the IP address associated with the host name of the node (in this example 10.10.10.1). Although it is invalid, it should not cause any issue. This has been fixed in 11.2.0.2.
3. Only 1 SCAN name is defined for a RAC cluster, the 2nd network can not use the same SCAN name.