How can one connect to an Exadata? In our example we will assume a half rack Exadata, which means that at the database layer we have a 4-node database RAC.
At the server side, we need to install a local listener on each database node. So we have 4 listeners "listening" for Exadata connections.
At the client side we assume the so-called "Local Naming Method" for name resolving, which simply means that we have at the client side a tnsnames.ora file with an appropriate tns entry. But what should be an appropriate tns entry for connecting to our Exadata?
Oracle Exadata from a database connection perspective is just an Oracle RAC. In 11gR2 there is a new method for connecting to an Oracle RAC, but lets first see how we used to connect to an Oracle RAC in 10g (the following works of course also with Exadata which runs 11gR2). For example, we need the following tns entry in the tnsnames.ora in order to do name resolving.
EXA_DWHPRD_10G =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ex101-vip.ote.gr)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ex102-vip.ote.gr)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ex103-vip.ote.gr)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ex104-vip.ote.gr)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DWHPRD)
)
)
Lets examine it carefully:
the net service name is "EXA_DWHPRD_10G"
In the ADDRESS_LIST section we note the addresses of the listeners (i.e., the host where the listener runs, the protocol it uses and the port it "listens" for connections). In this case as you can see, we have four different listeners installed on our 4 separate nodes (our Exadata is a 4-node RAC). We have used the LOAD_BALANCE option, which means that each time we try to connect to one listener chosen at random, in order to balance the load on the 4 listeners.
Note that the host names specified refer to "VIPs", which are "Virtual IPs". This simply means that these are not the actual physical IPs of the nodes but are special IPs, which in the case of a node failure, will guarantee routing to another node (failover).
With the above tns entry, each time we change our configuration of the available nodes we have to remember to update the tnsnames.ora configuration file. Let's see the new way to connect to a 11gR2 RAC and thus also to Exadata. In this case, we need the following tns entry:
At the server side, we need to install a local listener on each database node. So we have 4 listeners "listening" for Exadata connections.
At the client side we assume the so-called "Local Naming Method" for name resolving, which simply means that we have at the client side a tnsnames.ora file with an appropriate tns entry. But what should be an appropriate tns entry for connecting to our Exadata?
Oracle Exadata from a database connection perspective is just an Oracle RAC. In 11gR2 there is a new method for connecting to an Oracle RAC, but lets first see how we used to connect to an Oracle RAC in 10g (the following works of course also with Exadata which runs 11gR2). For example, we need the following tns entry in the tnsnames.ora in order to do name resolving.
EXA_DWHPRD_10G =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ex101-vip.ote.gr)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ex102-vip.ote.gr)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ex103-vip.ote.gr)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = ex104-vip.ote.gr)(PORT = 1521))
(LOAD_BALANCE = yes)
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DWHPRD)
)
)
Lets examine it carefully:
the net service name is "EXA_DWHPRD_10G"
In the ADDRESS_LIST section we note the addresses of the listeners (i.e., the host where the listener runs, the protocol it uses and the port it "listens" for connections). In this case as you can see, we have four different listeners installed on our 4 separate nodes (our Exadata is a 4-node RAC). We have used the LOAD_BALANCE option, which means that each time we try to connect to one listener chosen at random, in order to balance the load on the 4 listeners.
Note that the host names specified refer to "VIPs", which are "Virtual IPs". This simply means that these are not the actual physical IPs of the nodes but are special IPs, which in the case of a node failure, will guarantee routing to another node (failover).
With the above tns entry, each time we change our configuration of the available nodes we have to remember to update the tnsnames.ora configuration file. Let's see the new way to connect to a 11gR2 RAC and thus also to Exadata. In this case, we need the following tns entry:
EXA_DWHPRD_11G=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=ex1-scan)
(PORT=1521)
)
(CONNECT_DATA=
(SERVER=dedicated)
(SERVICE_NAME=DWHPRD)
)
)
As you can see the entry is no different with an entry connecting to a single (non-RAC) database. So, the client does not need to know that is connecting to a RAC (or an Exadata). Also, there is no need to update the tnsnames.ora configuration file in the case of change in the node configuration. Lets see how this is possible:
Check out the host specification, it refers to a "scan" address. Single Client Access Name (SCAN) provides a single name to the clients connecting to Oracle RAC that does not change throughout the life of the cluster, even if you add or remove nodes from the cluster. Clients connecting with SCAN can use a simple connection string, and still achieve the load balancing and client connection failover.
The SCAN is a new feature that simplifies access to a clustered database. 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 example above that we had to mentioned the addresses of all 4 nodes, where a local listener is running. Adding and deleting nodes from the cluster required changes in the ADDRESS_LIST. 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.
Behind the SCAN address lies at least one but but preferably three previously unused IP addresses in the same subnet as the public network. E.g.,
--scan (front layer for routing to the appropriate virtual IP)
ex1-scan (10.101.16.173)
ex1-scan (10.101.16.174)
ex1-scan (10.101.16.175)
ex1-scan (10.101.16.173)
ex1-scan (10.101.16.174)
ex1-scan (10.101.16.175)
Oracle Universal Installer will create new entities called SCAN listeners, along with the SCAN virtual IP addresses. The SCAN listeners will register with the local database listeners. A SCAN listener and a SCAN virtual IP address form a resource pair—both will be relocated to a different cluster node if a node fails. In case you ever need to, you can use the server control utility (srvctl) to administer the SCAN listener and IP.
The SCAN listeners are responsible for connect time load balancing, and they will hand off
connections to the least loaded node offering the service the client requested.
So we have the following configuration:
CLIENTS --> SCAN LISTENERS --> LOCAL LISTENERS --> ORACLE RAC (EXADATA)
The clients connect to the SCAN scanname.examle.com. A DNS server is contacted to resolve the SCAN, and it will return one of the three IP addresses defined; this helps when spreading the load to all three SCAN
listeners. The SCAN listener in turn will redirect the request to the local listener of the least loaded node,
offering the service requested by the client. At this stage, the process is no longer different from the pre-
SCAN era: the client resolves the virtual IP address of the node and establishes the connection.
The transition to the use of SCAN addresses is not mandatory—you can continue to use the old connection strings.
Cheers,
OL
References
1. Pro Oracle Database 11g RAC on Linux, Martin
Bach , Steve
Shaw:
2. Oracle® Real Application Clusters Administration and Deployment Guide 11g Release 2 (11.2) Part Number E16795-07
No comments:
Post a Comment