11.2 Grid Infrastructure networking enhancements

This note is an attempt to summarize some of the 11gR2 facilities that allow for greater virtualization of resources, reducing reliance on networking facilities supplied by the operating system. All corrections welcome.

Name resolution enhancements
The only requirements from your existing network is that one static IP address should be assigned to the Oracle GNS (Grid Naming Service), and that a delegated domain should be defined for the entire cluster. For example, consider these entries in the /etc/named.conf file of your corporate DNS :

# send all requests for the cluster1 subdomain to cluster1-gns
cluster1.example.com	NS	cluster1-gns.example.com 
# resolve the GNS name to this virtual IP address
cluster1-gns.example.com	10.10.10.10

The address of the GNS is a VIP (virtual IP address), statically coded in the DNS. So that whatever node the GNS happens to be running on, the DNS will be able to find it. Whenever the DNS receives a request for an address in the subdomain, it will forward the request to the GNS. When a node in the cluster starts up, the Grid infrastructure will use DHCP to obtain all the addresses it needs (there are several) and register these with the GNS.

Already, one can see how much simpler this makes the configuration: your network administrators need do nothing more than assign a subdomain and one static address. Everything else will be managed by the Grid and DHCP.

The SCAN (Single Client Access Name)
The SCAN is is a single domain name used by all clients for connecting to database services. It is dynamically assigned to three VIPs, issued by the corporate DHCP server and registered in the GNS. When a client requests a connection to the SCAN, the DNS will forward the request to the GNS. The GNS will return the three VIPs currently hosting a SCAN listener to te DNS, and DNS (using a round-robin algorithm) returns one to the client. In addition to the three SCAN listeners (one per VIP), there is a node listener on every node hosting a database instance.
The purpose of using two layers of listeners (SCAN listeners and node listeners) is to separate the two functions of listeners in a RAC: to load balance connections, and to spawn-and-bequeath sessions. The SCAN listeners will receive connection requests from clients, randomly distributed by the GNS. The SCAN listener will then use load balancing metrics to redirect the request intelligently to the node listener on the node best able to offer the requested service. Database instances register with the SCAN listeners as remote listeners, and with the node listeners as local listeners.
The client needs nothing more than a TNS names entry such as this:

s1=(description=(address=(protocol=tcp)(host=cluster1-scan.cluster1.example.com)(port=1521))
(connect_data=(service_name=s1)))

and the Grid will do the rest.

To conclude
The combination of GNS and SCAN, implemented using VIPs and DHCP, makes the Grid almost completely independent of network resources administered by third parties. Adding and removing nodes, or relocating services, requires no network configuration at all.