SCAN:-
Single Client Access Name (SCAN) is a feature used in Oracle RAC environments that provides a single name for clients to access any Oracle Database running in a cluster.The main benefit is that the client’s connect information does not need to change if you add or remove nodes or databases in the cluster.
In versions prior to Oracle 11.2, an entry in the tnsnames.ora file for a n-node RAC database always referenced all
nodes in the ADDRESS_LIST section, as in the listing that follows:
TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(LOAD_BALANCE = ON)
(FAILOVER = ON)
(ADDRESS = (PROTOCOL = tcp)(HOST = rac1-vip.localdomain)(PORT =1521))
(ADDRESS = (PROTOCOL = tcp)(HOST = rac2-vip.localdomain)(PORT =1521))
(ADDRESS = (PROTOCOL = tcp)(HOST = rac3-vip.localdomain)(PORT =1521))
(ADDRESS = (PROTOCOL = tcp)(HOST = rac4-vip.localdomain)(PORT =1521))
)
(CONNECT_DATA =
(SERVICE_NAME = testing)
)
)
The use of a SCAN address removes this problem, instead of addressing every single node as before, the SCAN virtual IP addresses refer to the cluster. Using the SCAN, the preceding connection entry is greatly simplified. Instead of listing each node’s virtual IP address, all we need to do is enter the SCAN rac-scan.localdomain.com. Here’s the simplified version:
TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = tcp)(HOST = rac-scan.localdomain)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = testing)
)
)
Now in the following post we’ll understand how this SCAN concept manages the connections internally, for that we first need to understand the set-up of SCAN.
SCAN configuration using DNS (Domain Name Service)
For this you need to have a DNS entry with one single name that resolves to 3 IP addresses using a round robin algorithm. The IP addresses must be on the same subnet as your default public network in the cluster (In 12c R1 SCAN would support multiple subnets).
SCAN configuration using GNS (Grid Name Service)
In this case Oracle assumes you use some form of dynamic IP assignment on your public network, so you just need to mention the SCAN name and 3 IPs will be acquired from either a DHCP service or SLAAC when using IPv6 based IP address.
Round Robin Algorithm
Round-robin on DNS level allows for a connection request load balancing across SCAN listeners floating in the cluster. If your DNS is set up to provide round-robin access to the IPs resolved by the SCAN entry, then run the “nslookup” command at least twice to see the round-robin algorithm work. The result should be that each time, the “nslookup” would return a set of three IPs in a different order.
1) nslookup rac-scan
Server: 192.168.46.1
Address: 192.168.46.1#53Non-authoritative answer:
Name: rac-scan.localdomain
Address: 192.168.46.30
Name: rac-scan.localdomain
Address: 192.168.46.31
Name: rac-scan.localdomain
Address: 192.168.46.322) nslookup rac-scan
Server: 192.168.46.1
Address: 192.168.46.1#53Non-authoritative answer:
Name: rac-scan.localdomain
Address: 192.168.46.31
Name: rac-scan.localdomain
Address: 192.168.46.32
Name: rac-scan.localdomain
Address: 192.168.46.30
Three IP addresses are recommended considering load balancing and high availability requirements regardless of the number of servers in the cluster.
SCAN (Single Client Access Name)
The CRSd process starts orarootagent & oraagent processes, orarootagent is responsible for starting Node VIP, SCAN VIP and oraagent process is responsible for starting SCAN Listener and Node Listener.
For each of the 3 IP addresses that the SCAN resolves to, a SCAN VIP resource is created and a SCAN Listener is created. The SCAN Listener is dependent on the SCAN VIP and the 3 SCAN VIPs (along with their associated listeners) will be dispersed across the cluster.REMOTE_LISTENER parameter is set to the SCAN by default this allows the instances to register with the SCAN Listeners as remote listeners to provide information on what services are being provided by the instance, the current load and a recommendation on how many incoming connections should be directed to the instance.
The LOCAL_LISTENER parameter is set to the node-VIP, the node listener run out of the Oracle Grid Infrastructure home and listens on the node-VIP using the specified port (default port is 1521).
So up till now we understood, SCAN configuration, SCAN IPs, SCAN Listener & Node Listener and how the Instances provide relevant information to SCAN Listeners, now we’ll understand the Client Side Load balancing in RAC using SCAN which would further explain another major benefit of using SCAN.
Connection Load Balancing
Client Side Load Balancing – For clients connecting using Oracle SQL*Net 11g Release 2 and above, 3 IP addresses will be received by the client by resolving the SCAN name through DNS. The client will then go through the list it receives from the DNS and try connecting through one of the IPs received. If the client receives an error, it will try the other addresses before returning an error to the user or application. This is similar to how client connection failover works in previous releases when an address list is provided in the client connection string.
Server Side Load Balancing – When a SCAN Listener receives a connection request, the SCAN Listener will check for the least loaded instance providing the requested service. It will then re-direct the connection request to the local listener on the node where the least loaded instance is running. Subsequently, the client will be given the address of the local listener. The local listener will finally create the connection to the database instance.
HOW CONNECTION LOAD BALANCING WORKS USING SCAN
For clients connecting using Oracle SQL*Net 11g Release 2, three IP addresses will be received by the client by resolving the SCAN name through DNS as discussed. The client will then go through the list it receives from the DNS and try connecting through one of the IPs received.
If the client receives an error, it will try the other addresses before returning an error to the user or application. This is similar to how client connection failover works in previousreleases when an address list is provided in the client connection string.
When a SCAN Listener receives a connection request, the SCAN Listener will check for the least loaded instance providing the requested service. It will then re-direct the connection request to the local listener on the node where the least loaded instance is running. Subsequently, the client will be given the address of the local listener. The local listener will finally create the connection to the database instance.
Note: This example assumes an Oracle 11g Release 2 client using a default TNSNAMES. ora:
Default Oracle 11g Release 2 TNSNAMES.ora using SCAN – Example
| ORCLSERVICE= (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=sales1-scan.example.com) (PORT=1521) ) (CONNECT_DATA= (SERVER=dedicated) (SERVICE_NAME=MyORCLservice) ) ) |
VERSION AND BACKWARD COMPATIBILITY
The successful use of SCAN to connect to an Oracle RAC database in the cluster depends on the ability of the client to understand and use the SCAN as well as on the correct configuration of the REMOTE_LISTENER parameter setting in the database.
If the version of the Oracle Client connecting to the database as well as the Oracle Database version used are both Oracle Database 11g Release 2 and the default configuration is used as described in this paper, no changes to the system are typically required.
The same holds true, if the Oracle Client version and the version of the Oracle Database that this client is connecting
to are both pre-11g Release 2 version (e.g. Oracle Database 11g Release 1 or Oracle Database 10g Release 2, or older).
In this case, the pre-11g Release 2 client would use a TNS connect descriptor that resolves to the node-VIPs of the cluster, while the Oracle pre-11g Release 2 database would still use a REMOTE_LISTENER entry pointing to the node-VIPs. The disadvantage of this configuration is that SCAN would not be used and hence the clients are still exposed to changes every time the cluster changes in the backend.
Similarly, if an Oracle Database 11g Release 2 is used, but the clients remain on a former version. The solution is to change the Oracle client and / or Oracle Database REMOTE_LISTENER settings accordingly. The following cases need to be considered:
| Oracle Client Version | Oracle Database Version | Comment |
| Oracle Database 11g Release 2 | Oracle Database 11g Release 2 | No change required. |
| Oracle Database 11g Release 2 | Pre- Oracle Database 11g Release 2 | Add the SCAN VIPs as hosts to the REMOTE_LISTENER parameter. |
| Pre- Oracle Database 11g Release 2 | Oracle Database 11g Release 2 | Change the client TNSNAMES.ora to include the SCAN VIPs |
| IF the database was upgraded using the DBUA from a pre-11g Rel. 2 | ||
| database, the DBUA will configure the REMOTE_LISTENER | ||
| parameter to point to the node-VIPs as well as the SCAN. | ||
| Pre- Oracle Database 11g Release 2 | Pre- Oracle Database 11g Release 2 | If you want to make use of SCAN (recommended): |
| add the SCAN VIPs as hosts to the REMOTE_LISTENER parameter. | ||
| AND | ||
| Change the client TNSNAMES.ora to include the SCAN VIPs (* see below). | ||
| Otherwise, no change required. |
Note: If using a pre-11g Release 2 client (Oracle Database 11g Release or Oracle Database 10g Release 2, or older) you will not fully benefit from the advantages of SCAN. Reason: The Oracle Client will not be able to handle a set of three IPs returned by the DNS for SCAN. Hence, it will try to connect to only the first address returned in the list and will more or less ignore the others. If the SCAN Listener listening on this specific IP is not available or the IP itself is not available, the connection will fail. In order to ensure load balancing and connection failover with pre-11g Release 2 clients, you will need to change the TNSNAMES.ora of the client so that it would use 3 address lines, where each address line resolves to one of the SCAN VIPs.
Sample TNSNAMES.ora for Oracle Database pre- 11g Release 2 Clients
| SALES.EXAMPLE.COM= (DESCRIPTION= (ADDRESS_LIST= (FAILOVER=on) (LOAD_BALANCE=on) (ADDRESS= (PROTOCOL=TCP) (HOST=133.22.67.192) (PORT=1521) ) (ADDRESS= (PROTOCOL=TCP) (HOST=133.22.67.193) (PORT=1521) ) (ADDRESS= (PROTOCOL=TCP) (HOST=133.22.67.194) (PORT=1521) ) ) (CONNECT_DATA= (SERVICE_NAME=salesservice.example.com) ) ) |
USING SCAN IN A MAXIMUM AVAILABILITY ARCHITECTURE ENVIRONMENT
If you have implemented a Maximum Availability Architecture (MAA) environment, in which you use Oracle RAC for both your primary and standby database (in both, your primary and standby site), which are synchronized using Oracle Data Guard, using SCAN provides a simplified TNSNAMES configuration that a client can use to connect to the database independently of whether the primary or standby database is the currently active (primary) database.
In order to use this simplified configuration, Oracle Database 11g Release 2 introduces two new SQL*Net parameters that can be used on for connection strings of individual clients. The first parameter is CONNECT_TIMEOUT. It specifies the timeout duration (in seconds) for a client to establish an Oracle Net connection to an Oracle database.
This parameter overrides SQLNET.OUTBOUT_CONNECT_TIMEOUT in the SQLNET.ORA. The second parameter is RETRY_COUNT and it specifies the number of times an ADDRESS_LIST is traversed before the connection attempt is terminated.
Using these two parameters, both, the SCAN on the primary site and the standby site, can be used in the client connection strings. Even, if the randomly selected address points to the site that is not currently active, the timeout will allow the connection request to failover before the client has waited unreasonably long (the default timeout depending on the operating system can be as long as 10 minutes).
Sample TNSNAMES.ORA entry for MAA environment
| SALES.EXAMPLE.COM= (DESCRIPTION= (CONNECT_TIMEOUT=10)(RETRY_COUNT=3) (ADDRESS_LIST= (FAILOVER=on) (LOAD_BALANCE=on) (ADDRESS= (PROTOCOL=TCP) (HOST=sales1-scan) (PORT=1521) ) (ADDRESS= (PROTOCOL=TCP) (HOST=sales2-scan) (PORT=1521) ) ) (CONNECT_DATA= (SERVICE_NAME=salesservice.example.com) ) ) |
USING SCAN WITH ORACLE CONNECTION MANAGER
If you use Oracle Connection Manager (CMAN) with your Oracle RAC Database, the REMOTE_LISTENER parameter for the Oracle RAC instances should include the CMAN server so that the CMAN server will receive load balancing related information and can therefore load balance connections across the available instances. The easiest way to achieve this would be to add the CMAN-server as an entry to the REMOTE_LISTENER of the databases that clients want to connect to via CMAN as shown in figure 10. Note also that you will have to remove the SCAN from the TNSNAMES connect descriptor of the clients and further configurations will be required for the CMAN server.
Server side TNSNAMES.ora example entry when using CMAN
SQL> show parameters listener
NAME TYPE VALUE
listener_networks string
local_listener string (DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)
(HOST=148.87.58.109)(PORT=1521))))
remote_listener string stscan3.oracle.com:1521,(DESCRIPTION=
(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
(HOST=CMANserver)(PORT=1521))))
==============================================================
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.
The SCAN works by being able to resolve to multiple IP addresses 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 made available to a client. 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.
During installation listeners are created. They listen on the SCAN IP addresses provided on nodes for the SCAN IP addresses. Oracle Net Services routes application requests to the least loaded instance providing the service. 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.
The SCAN should be configured so that it is resolvable either by using Grid Naming Service (GNS) within the cluster, or by using Domain Name Service (DNS) resolution. For high availability and scalability, Oracle recommends that you configure the SCAN name so that it resolves to three IP addresses. At a minimum, the SCAN must resolve to at least one address.
If you specify a GNS domain, then the SCAN name defaults to clustername-scan.GNS_domain. Otherwise, it defaults to clustername-scan.current_domain. For example, if you start Oracle grid infrastructure installation from the server node1, the cluster name is mycluster, and the GNS domain is grid.example.com, then the SCAN Name is mycluster-scan.grid.example.com.
GNS:
The GNS virtual IP address is a static IP address configured in the DNS. The DNS delegates queries to the GNS virtual IP address, and the GNS daemon responds to incoming name resolution requests at that address.
Within the subdomain, the GNS uses multicast Domain Name Service (mDNS), included with Oracle Clusterware, to enable the cluster to map hostnames and IP addresses dynamically as nodes are added and removed from the cluster, without requiring additional host configuration in the DNS.
To enable GNS, you must have your network administrator provide a set of IP addresses for a subdomain assigned to the cluster (for example, grid.example.com), and delegate DNS requests for that subdomain to the GNS virtual IP address for the cluster, which GNS will serve. The set of IP addresses is provided to the cluster through DHCP, which must be available on the public network for the cluster.
SCAN Listener
SCAN Concepts
- Single client access name (SCAN) is the virtual hostname to provide for all clients connecting to the cluster (as opposed to the vip hostnames in 10g and 11gR1).
- SCAN is a domain name registered to at least one and up to three IP addresses, either in the domain name service (DNS) or the Grid Naming Service (GNS).
- By default, the name used as the SCAN is also the name of the cluster and must be globally unique throughout your enterprise. The default value for the SCAN is based on the local node name. SCAN name must be at least one character long and no more than 15 characters in length, must be alphanumeric – cannot begin with a numeral and may contain hyphens (-). If you require a SCAN that is longer than 15 characters, then select an Advanced installation.
- For installation to succeed, the SCAN must resolve to at least one address.
- SCAN VIP addresses must be on the same subnet as virtual IP addresses and public IP addresses.
- Oracle strongly recommends that you do not configure SCAN VIP addresses in the hosts file. But if you use the hosts file to resolve SCAN name, you can have only one SCAN IP address.
- If hosts file is used to resolve SCAN hostname, you will receive Cluster Verification Utility failure at end of installation
- For high availability and scalability, Oracle recommends that you configure the SCAN to use DNS Round Robin resolution to three addresses.
- 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. Clients using the SCAN can also access the cluster using EZCONNECT.
- Grid Infrastructure will start local listener LISTENER on all nodes to listen on local VIP, and SCAN listener LISTENER_SCAN1 (up to three cluster wide) to listen on SCAN VIP(s); 11gR2 database by default will set local_listener to local LISTENER, and remote_listener to SCAN listener.
- SCAN listener will be running off GRID_HOME, and by default, in 11gR2 local listener will be running off GRID_HOME as well.
NETWORK REQUIREMENTS FOR USING SCAN
During the Installation phase of the Oracle Grid Infrastructure installation, you will be prompted to provide a SCAN name. There are 2 options for defining the SCAN:
- Define the SCAN in your corporate DNS (Domain Name Service)
- Use the Grid Naming Service (GNS)
For Option 1-
you must ask your network administrator to create a single name that resolves to 3 IP addresses using a round-robin algorithm. Three IP addresses are recommended considering load balancing and high availability requirements regardless of the number of servers in the cluster. The IP addresses must be on the same subnet as your public network in the cluster. The name must be 15 characters or less in length, not including the domain, and must be resolvable without the domain suffix
kracnode-scan 192.168.1.72 192.168.1.70 192.168.1.71 [root@kracnode2 ~]# nslookup kracnode-scan Server: 192.168.1.100 Address: 192.168.1.100#53 Name: kracnode-scan.india.com Address: 192.168.1.72 Name: kracnode-scan.india.com Address: 192.168.1.70 Name: kracnode-scan.india.com Address: 192.168.1.71
IF YOU DO NOT HAVE A DNS SERVER AVAILABLE AT INSTALLATION TIME
However, in order to overcome the installation requirement without setting up a DNS-based SCAN resolution, you can use a hosts-file based workaround. In this case, you would use a typical hosts-file entry to resolve the SCAN to only 1 IP address and one IP address only. It is not possible to simulate the round-robin resolution that the DNS server does using a local host file. The host file look-up the OS performs will only return the first IP address that matches the name. Neither will you be able to do so in one entry (one line in the hosts-file). Thus, you will create only 1 SCAN for the cluster. (Note that you will have to change the hosts-file on all nodes in the cluster for this purpose.)
Local Listener Configuration for SCAN
In this context, the LOCAL_LISTENER parameter must be considered. The LOCAL_LISTENER parameter should be set to the node-VIP. If you need fully qualified domain names, ensure that LOCAL_LISTENER is set to the fully qualified domain name (e.g. node-VIP.example.com). By default, a node listener is created on each node in the cluster during cluster configuration. With Oracle Grid Infrastructure 11g Release 2 the node listener run out of the Oracle Grid Infrastructure home and listen on the node-VIP using the specified port (default port is 1521).
Unlike in former database versions, it is not recommended to set your REMOTE_LISTENER parameter to a server side TNSNAMES alias that resolves the host to the SCAN (HOST=kracnode-scan for example) in the address list entry, but use the simplified “SCAN:port”
SQL> show parameter listener
NAME TYPE VALUE
———————————— ———– ——————————
listener_networks string
local_listener string (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=kracnode1-vip)(PORT=1521))))
remote_listener string kracnode-scan.india.com:1521
HOW CONNECTION LOAD BALANCING WORKS USING SCAN
For clients connecting using Oracle SQL*Net 11g Release 2, three IP addresses will be received by the client by resolving the SCAN name through DNS as discussed. The client will then go through the list it receives from the DNS and try connecting through one of the IPs received. If the client receives an error, it will try the other addresses before returning an error to the user or application. This is similar to how client connection failover works in previous releases when an address list is provided in the client connection string.
When a SCAN Listener receives a connection request, the SCAN Listener will check for the least loaded instance providing the requested service. It will then re-direct the connection request to the local listener on the node where the least loaded instance is running. Subsequently, the client will be given the address of the local listener. The local listener will finally create the connection to the database instance.
Ref:Oracle Blogs
New SRVCTL Command | What it does |
srvctl config scan | Shows the current SCAN configuration |
srvctl config scan_listener | Shows the existence and port numbers for the SCAN listeners |
srvctl add scan -n cluster01-scan | Adds new SCAN information for a cluster |
srvctl remove scan -f | Removes SCAN information |
srvctl add scan_listener | Adds a new SCAN listener for a cluster on the default port of 1521 |
srvctl add scan_listener -p 65001 ## non default port number ## | Adds a new SCAN listener on a different port |
srvctl remove scan_listener | Removes the SCAN listener |
srvctl modify scan -n cluster_scan | Modifies SCAN information (used when changing SCAN to DNS after initially using /etc/hosts) |
srvctl modify scan_listener -u | Modifies the SCAN listener information to match the new SCAN VIP information from the modify scan command |
No comments:
Post a Comment