LoadBalance distributes the load evenly to each node in the cluster, thereby improving the overall throughput. Oracle 10g RAC provides two different ways to spread the load:
1. Through Connection Balancing, users are allocated to different nodes according to a certain algorithm. It can also be thought of as a purely technical scatter load.
2. Dispersing on the application layer through the Service can also be considered as the distributed load of the face-to-face business.
[@more@]
一．Connection Balancing
Connection Balancing This load balancing is performed at the level of user connection, that is, when the user requests to establish a connection, which instance to assign the connection to is determined according to the load of each node, and once the connection is established, all operations of the session are performed. Done on this instance without dispatching to other nodes.
Connection Balancing has two implementation methods: client and server.
1.1 Client-Side Balance (Client-Side LB)
Client-side balancing (Client-Side LB) is the method used by Oracle 8. The configuration method is to add to the tnsnames.ora file of the client:
LOAD_BALANCE=YES entry. When a client initiates a connection, it randomly selects one from the address list, and uses a random algorithm to allocate connection requests to each instance.
The TNS configuration file of a Clint-Side LB is as follows:
RAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(LOAD_BALANCE = YES)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RAC)
)
)
)
Note: rac1-vip needs to be added to the hosts file.
The disadvantage of this method is obvious, because the real load of each node is not considered when allocating connections, and the final distribution result is not necessarily balanced; and the random algorithm needs a long time slice, if Multiple connections are initiated at the same time in a short period of time, and these connections may all be allocated to a node, or even worse, the connection may be allocated to a faulty node. Therefore, Oracle introduced the server-side balancing (Sevice-Side LB) method.
1.2 Server-Side LB
Server-Side LB was introduced from Oracle 9. Its implementation relies on the Listener to collect load information. During the operation of the database, the PMON background process will collect the load information of the system, and then register it in the Listener. At least 1 minute and at most 10 minutes, PMON needs to do an information update, and if the load of the node is higher, the update frequency will be higher to ensure that the Listener can grasp the accurate load situation of each node. If the Listener is closed, the PMON process will check whether the Listener is restarted every 1 second. In addition to this automatic, scheduled update task, the user can also use the alter system register command to perform the process manually.
This automatic update action can be seen from the Listener's log. For example, the following Listener log fragment clearly records these actions. Note that the first registration process performed by the PMON process when the instance is started is called Server-register, and the subsequent update process is called service-update.
[root@rac1 log]# pwd
/u01/app/oracle/product/10.2.0/db_1/network/log
[root@rac1 log]# more *.log
.....
27-FEB-2010 02:15:10 * service_register * rac1 * 0
27-FEB-2010 02:15:11 * service_update * rac1 * 0
27-FEB-2010 02:15:11 * service_update * rac1 * 0
27-FEB-2010 02:15:23 * service_update * +ASM1 * 0
27-FEB-2010 02:15:32 * service_update * +ASM1 * 0
.....
Although the Listener log records the registration and update actions of the PMON process, the registered content is not reflected. To obtain these content, you can obtain it by tracking the time of 10257. This event is to track the PMON activity.
Event="10257 trace name context forever,levl 16" The
PMON process will not only register with the local Listener, but also with the Listeners on other nodes. But where to register is determined by the two parameters Remote_Listeners and Local_Listener. Local_Listener does not need to be set, while Remote_Listener needs to be set, and the parameter value is a tnsnames item.
[oracle@rac1 ~]$ set ORACLE_SID=RAC1
[oracle@rac1 ~]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Mar 5 00:52:19 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> show parameter listener
NAME TYPE VALUE
local_listener string
remote_listener string LISTENERS_RAC
SQL>
The corresponding LISTENERS_RAC content in the tnsnames.ora of this machine is as follows:
LISTENERS_RAC =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
)
With the automatic registration mechanism of PMON, the Listener of each node in the cluster knows the load of all nodes. When receiving a client connection request, it will transfer the connection to the node with the least load, which may be itself There may also be other nodes, that is, the Listener that will forward the user's request.
The node selection method of the Listener varies according to the connection method requested by the user:
1). If the user requests a Delicate dedicated connection, the Listener first selects the node with the least load, and if multiple nodes have the same load, the instance with the least load is selected from the node.
2). If the user requests a Shre Server shared function connection, in addition to comparing the node load and instance load, it is also necessary to select the Dispatcher with the smallest load on the lock selection instance for forwarding.
Server-Side LB and Client-Side LB are not mutually exclusive, they can work together, that is, the user's connection request will first randomly select an address from the address list, and then send a request to the Listener whose address is changed; after the Listener receives the request , select the most suitable node to forward the connection request according to the load of each node.
1.3 Two LB configuration methods
For Client-Side LB, you need to add LOAD_BALANCE=YES to the client's tnsnames entry. For Server-side LB, you need to configure the parameter REMOTE_LISTENER. ,
Note: When configuring LB, you need to delete the default generated listener.ora file from the listener.ora file of each node instance.
SID_LIST_LISTENER_NodeName entry, so as to ensure that the information obtained by the Listener is dynamically registered, rather than static information read from a file.
We want to delete:
SID_LIST_LISTENER_RAC1 =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(PROGRAM = extproc)
)
)
Keep only:
LISTENER_RAC1 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521)(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.85.10.119)(PORT = 1521)(IP = FIRST))
)
)
2. Use Service to spread the load
Let's first analyze the shortcomings of the Connection Balancing method. Oracle's cluster is a "shared everything" architecture, where all nodes share a copy of disk data. Data synchronization is performed between instances through the Cache Fusion mechanism, so the performance of RAC is largely limited by the performance of Cache Fusion. Therefore, to improve the performance of RAC, we can start from two aspects:
1. Improve the capability of Cache Fusion, which can use better interconnection equipment, such as G-class private network, or use DRA technology such as Infiniband.
2. It can minimize the traffic of Cache Fusion and reduce the interdependence between instances. And Service is developed based on the latter idea.
Let's take a look at the Partition technology that is very similar to Service. If the number in a table is huge, Oracle recommends using Partition Table to distribute the data to multiple physical segments according to certain rules (such as time), so that data access is limited to some local Segments.
To further improve the idea of "decentralized data", in the RAC environment, if the data can be separated according to the application. For example: An ERP application includes multiple modules of production, sales, and supply chain management. Assuming that this database uses RAC with two nodes, before the "distributed data", both users use the sales module, then these two users may be assigned to two nodes. During the operation, the sales data It is necessary to continuously transfer between two bytes under the action of Cache Fusion. If there are two other users of the production module, the two users are assigned to the two nodes. During the operation, the production part needs to be synchronized between the two instances with the assistance of Cache Fusion.
It can be seen that if there is only one mechanism of Connection Balancing, it seems that users are distributed to different Instances, and it seems that the load is distributed. However, this decentralization is carried out without combining the business needs of each user, and is a purely technical means. This dispersion may in turn increase the burden on the systems.
In another way of thinking, if users of the sales module are allocated to node 1, and users of the production module are allocated to node 2, it is assumed that the data between the two modules does not cross. At this time, the data of the sales module is concentrated on node 1, and the data of the production module is concentrated on node 2, the workload of Cache Fusion will be drastically reduced, and the performance problem can be fundamentally solved.
9irac seems to have
(LOAD_BALANCE=ON)
(FAILOVER=ON）
10gr2有(LOAD_BALANCE = yes)