11gR2 clients connect to the database using SCANs
If you’ve extended your RAC cluster on a set of new nodes you already know how painful it can be to have to go through the list of your clients and make sure their SQL*Net configuration is up to date. 11gR2 solves this problem using Single Client Access Name (SCAN).
The single client access name (SCAN) is a hostname used to provide service access for clients to the cluster. Because the SCAN is associated with the cluster as a whole, rather than to a particular node, the SCAN makes it possible to add or remove nodes from the cluster without needing to reconfigure clients. It also adds location independence for the databases, so that client configuration does not have to depend on which nodes are running a particular database. Clients can continue to access the cluster in the same way as with previous releases, but Oracle recommends that clients accessing the cluster use the SCAN.
Reference: 1.3.2.2 IP Address Requirements
How is SCAN implemented?
For high availability purposes the SCAN name should be associated with at least three IP addresses using DNS round-robin resolution. If you opt to use Grid Naming Service then GNS can also be used to manage the SCAN name.
SCAN is configured at a cluster level not at the node level, that’s what makes it so flexible — no mater how many nodes your clusters consists of, your clients can continue to use SCAN to access the services of your cluster utilizing all nodes even if you add or delete them:
The SCAN is a virtual IP name, similar to the names used for virtual IP addresses, such as node1-vip. However, unlike a virtual IP, the SCAN is associated with the entire cluster, rather than an individual node, and associated with multiple IP addresses, not just one address.
SCAN works as an independent handler for the entire cluster — it acts on client’s behalf during connection request since it knows all cluster services and it’s available, least loaded nodes:
The SCAN works by being able to resolve to multiple IP addresses reflecting multiple listeners in the cluster handling public client connections. When a client submits a request, the SCAN listener listening on a SCAN IP address and the SCAN port is contracted on a client’s behalf. Because all services on the cluster are registered with the SCAN listener, the SCAN listener replies with the address of the local listener on the least-loaded node where the service is currently being offered. Finally, the client establishes connection to the service through the listener on the node where service is offered. All of these actions take place transparently to the client without any explicit configuration required in the client.
Bottom line – use SCAN – it simplifies cluster management:
Because the SCAN addresses resolve to the cluster, rather than to a node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.
Reference: D.1.3.5 About the SCAN
Related posts:
October 2nd, 2009 at 4:33 am
Hi,
Is it possible to implement SCAN functionality with using DNS or GNS, I mean over entries in /etc/hosts file ?
If yes, how can we do this ?
Regards
Shine
October 2nd, 2009 at 4:37 am
Sorry for the typo, I mean WITHOUT using DNS or GNS in my last response
October 2nd, 2009 at 10:32 am
For production you will have to use DNS/GNS. If you are just trying to setup a test install then you could simply put ONE scan address into /etc/hosts and make sure your /etc/nsswitch.conf reads “hosts: files dns”. Not sure if it will work but you could try …
November 7th, 2009 at 7:22 pm
If you do not specify the SCAN in DNS, the OUI for grid infrastructure will fail at the end of the installation with:
———————————————-
ERROR:
PRVF-4657 : Name resolution setup check for “vmlinux-cluster-scan” (IP address: 192.168.1.184) failed
ERROR:
PRVF-4664 : Found inconsistent name resolution entries for SCAN name “vmlinux-cluster-scan”
———————————————-
The OUI uses nslookup to validate the SCAN – remember that nslookup is a DNS utility and does not read /etc/hosts so making the change in /etc/nsswitch.conf will have no affect.
As per Metalink Doc ID: 887471.1, you can safely ignore this error and continue with the installation, however, Oracle strongly suggests you configure the SCAN in DNS.
If you want to make it through the grid infrastructure install without receiving the PRVF-4657 / PRVF-4664 failure, perform the following hack before running the OUI on all nodes in the cluster. Note that I am simply defining a single IP address (192.168.1.184) for a scan named vmlinux-cluster-scan and where my DNS server is 24.154.1.34:
———————————————————
mv /usr/bin/nslookup /usr/bin/nslookup.original
cat < /usr/bin/nslookup
#!/bin/bash
HOSTNAME=\${1}
if [[ \$HOSTNAME = "vmlinux-cluster-scan" ]]; then
echo “Server: 24.154.1.34″
echo “Address: 24.154.1.34#53″
echo “Non-authoritative answer:”
echo “Name: vmlinux-cluster-scan”
echo “Address: 192.168.1.184″
else
nslookup.original \$HOSTNAME
fi
EOF
chmod 755 /usr/bin/nslookup
———————————————————
+—————————————————————+
| RUN CLUSTER VERIFICATION UTILITY – PASSED |
+—————————————————————+
[grid@vmlinux1 ~]$ cluvfy comp scan -verbose
Verifying scan
Checking Single Client Access Name (SCAN)…
SCAN VIP name Node Running? ListenerName Port Running?
—————- ———— ———— ———— ———— ————
vmlinux-cluster-scan vmlinux1 true LISTENER 1521 true
Checking name resolution setup for “vmlinux-cluster-scan”…
SCAN Name IP Address Status Comment
———— ———————— ———————— ———-
vmlinux-cluster-scan 192.168.1.184 passed
Verification of SCAN VIP and Listener setup passed
Verification of scan was successful.