Detailed explanation of load balancing (LB)

2. LB

LoadBalance is to distribute the load balance to each node of the cluster, thereby improving the overall throughput. Oracle 10g RAC provides two means to achieve load, one is to allocate users to different nodes according to a certain algorithm through Connection Balancing; the other is to decentralize at the application level through service.

Connection Balancing

Connection Balancing load balancing is performed at the level of user connection, that is, when a user requests to establish a connection, it is determined which instance to allocate the connection to according to the load of each. Once the connection is established, all operations of the session are completed on this strength and will not be allocated to other instances.

Client balancing (Client-Side LB)
Client balancing (Client-Side LB) is the method used by oracle 8i. The configuration method is to add the LOAD_BALANCE=YES entry to the tnsnames.ora file of the client. When the client initiates a connection, it will randomly select one from the address list, and then use a random algorithm to distribute the connection request to each instance.

An example of TNS configuration for a Client-Side LB is as follows:

TAF_SERVER =

(DESCRIPTION =

(ADDRESS= (PROTOCOL = TCP)(HOST = felix1-vip)(PORT = 1521))

(ADDRESS= (PROTOCOL = TCP)(HOST = felix2- vip)(PORT = 1521))

(LOAD_BALANCE= yes)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = taf_server)

(FAILOVER_MODE =

(TYPE = SELECT)

(METHOD = BASIC)

(RETRIES = 180)

(DELAY = 5)

)

)

)

The disadvantage of this approach is obvious because each node's It is really a load, and the final distribution result is not necessarily balanced; and the random algorithm requires a long time slice. If multiple connections are initiated at the same time in a short period of time, these connections may be allocated to one node; even worse, Connections may be distributed to failed nodes. Therefore, Oracle has introduced the server-side (Server-Side LB) method.

Summary: The biggest disadvantage of client-side balancing is that it cannot distribute user connections according to the actual load of each instance

. Server-side balancing (Server-Side)
The implementation of server-side load balancing depends on the load information of the listener (listening) mobile phone. During the operation of the database, the PMON background process will obtain the load information of the mobile phone system, and then register it in the Listener. At least one minute, at most ten minutes, PMON needs to update the information, and if the load of the node is higher, the update frequency is 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 minute. In addition to this automatic and timed update task, the user can also use the altersystem register command to perform this process manually. This automatic update action can be seen from the listener's log. Note: The first registration process performed by the PMON process when the instance starts is called Server-Rgister, and the subsequent update process is called service-update;

TNSLSNR for Linux: Version 10.2.0.5.0 - Productionon 03-JUN-2014 11:51:54

Copyright (c) 1991, 2010, Oracle. All rights reserved.

System parameter file is/u01/oracle/10.2.0/db_1/network/admin/listener.ora

Log messages written to/u01/oracle/10.2.0/db_1/network/log/listener.log

Trace information written to/u01/oracle/10.2.0/db_1/network/trace/listener.trc

Trace level is currently 0

Started with pid=25371

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=felix1)(PORT=1521)))

Listener completed notification to CRS on start

TIMESTAMP * CONNECT DATA [* PROTOCOL INFO] * EVENT[* SID] * RETURN CODE

03-JUN-2014 11:51:54 *(CONNECT_DATA=(CID=(PROGRAM=)(HOST=felix1)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=LISTENER)(VERSION= 169870592))* status * 0

03-JUN-2014 11:52:15 * service_register * felix2 * 0

03-JUN-2014 11:52:15 * service_register * felix1 * 0

03-JUN-2014 11:52:15 * service_update * felix1 * 0

03-JUN-2014 11:52:15 * service_register * +ASM1 *0

Although the Listener log records the registration and update actions of the PMON process, the registered contents are not reflected. To obtain these contents, you can Obtained through various 1025 events, this time is related to the activities of PMON.

SQL> alter session set events '10257 trace namecontext forever, level 16';

Session altered.

SQL>

get trace file:

CREATE OR REPLACE FUNCTION get_trace return varchar is

Resultvarchar2(4000);

begin

dbms_output.enable(1000000);

begin

for x in(SELECT d.VALUE

||'/'

||LOWER (RTRIM (i.INSTANCE, CHR (0)))

||'_ora_'

||p.spid

||'.trc'

trace_file_name

FROM (SELECT p.spid

FROM v$mystat m, v$session s,v$process p

WHERE m.statistic# = 1 AND s.SID= m.SID AND p.addr = s.paddr) p,

(SELECT t.INSTANCE

FROM v$thread t, v$parameter v

WHERE v.NAME = 'thread'

AND (v.VALUE = 0 OR t.thread# = TO_NUMBER (v.VALUE))) i,

(SELECT VALUE

FROM v$parameter

WHERE NAME = 'user_dump_dest')d) loop

Result:= Result || x.trace_file_name;

End loop;

End;

return(substr(Result, 1, 4000));

end get_trace;

select get_trace from dual;

GET_TRACE

----------------------------- -------------------------------------------------- -

/u01/oracle/admin/felix/udump/felix1_ora_27465.trc

The PMON process not only recalls the local Listener registration, but can also register with the listeners of other nodes. But where to register is determined by the two parameters remote_listener and local_listener. Local_Listener does not need to be set, while remote needs to be set. The parameter value is a tnsnames item.

SQL> show parameter listener

NAME TYPE VALUE

------------------------------------ ------ -----------------------------------

local_listener string LISTENER_FELIX1

remote_listener string LISTENERS_FELIX

SQL>

corresponding LISTENERS_FELIX in Tnsnames.ora The content is as follows:

LISTENERS_FELIX =

(ADDRESS_LIST=

(ADDRESS= (PROTOCOL = TCP)(HOST = felix1-vip)(PORT = 1521))

(ADDRESS= (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521))

)

with PMON After the automatic registration mechanism, the Listener of each node in the cluster grasps the load status of all nodes. When receiving a connection request from the client, it will transfer the connection to the node with the least load, which may be itself or other nodes. The node, that is, the Listener will forward the user's connection request. The listener's node selection method will be different according to the connection method requested by the user:

a. If the user requests a Dedicate dedicated connection, the Listener first selects the node with the least load, and if multiple nodes have the same load, selects the instance with the least load;

b. If the user requests a shared server connection, in addition to node load comparison and instance load comparison, the smallest Dispatcher should be selected for forwarding on the selected instance.

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, the parameter REMOTE_LISTENER needs to be configured.

One thing to note when configuring LB: you need to remove the default SID_LIST_LISTENER_NAME entry from the listener file of each instance, so as to ensure that the information obtained by the Listener is dynamically registered, not static information read from the file.

Before modification:

[oracle@felix2 admin]$ cat listener.ora

# listener.ora.felix2 Network Configuration File:/u01/oracle/10.2.0/db_1/network/admin/listener.ora.felix2

# Generated by Oracle configuration tools.

LISTENER_FELIX2 =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521)(IP = FIRST))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.102)(PORT = 1521)(IP =FIRST))

)

)

----------------------------------------

SID_LIST_LISTENER_FELIX2 =

(SID_LIST=

(SID_DESC =

(SID_NAME = PLSExtProc)

(ORACLE_HOME = /u01/oracle/10.2.0/db_1)

(PROGRAM = extproc)

)

)

[oracle@felix2 admin]$

修改后配置如下：

[oracle@felix2 admin]$ catlistener.ora

# listener.ora.felix2 Network Configuration File:/u01/oracle/10.2.0/db_1/network/admin/listener.ora.felix2

# Generated by Oracle configuration tools.

LISTENER_FELIX2 =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = felix2-vip)(PORT = 1521)(IP = FIRST))

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.102)(PORT = 1521)(IP =FIRST))

)

)

[oracle@felix2 admin]$

利用service分散负载

The disadvantage of the Connection Balancing method is that Oracle's cluster is a "shared everything" architecture, and all nodes share a 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. On the one hand, we can improve the ability of cache fusion, which can be achieved through better interconnected devices, such as G-class Private network, or the use of DRA technologies such as Infiniband; on the other hand, we can try our best to Reduce the traffic of cache fusion and reduce the interdependence between instances. The service is developed on the basis of the latter idea.

Let's first look at the Partition technology that is very similar to service. If the amount of data in a table is huge, Oralce recommends using a Partition Table to distribute the data into multiple physical segments (Segments) according to certain rules, so that data access is limited to some local segments.

To improve the idea of ​​"decentralized data", in the RAC environment, if the data can be separated according to the application, consider the following scenario: an ERP application includes multiple modules of production, sales, and supply chain management. Assuming that this database uses a 2-node RAC, before the "data dispersion", both users use the sales module, then these two users may be assigned to two nodes. During the operation, the sales data will be Under the action of cache fusion, it is continuously transmitted between two nodes. If there are users of two other production modules, these two users are assigned to two nodes. During the operation, the data of the production part is It is necessary to synchronize between the two powers with the help of Cache fusion.

It can be seen that if there is only one mechanism of connection balance, it seems that users are allocated to different instances, and it seems that the load is distributed. But this kind of decentralization is not carried out in combination with the business needs of each user, and is a pure technical means (so it can be called pure technical means decentralization).

If there is another solution, if all users of the sales module are allocated to node 1, and users of the production module are allocated to node 2, assuming that there is not much data crossover between these two modules, this is the problem of the sales module. The data is concentrated on node 1, and the data of the production library module is concentrated on node 2, and the workload of cachefusion will be drastically reduced, which fundamentally solves the performance problem.

This idea is the basic idea of ​​distributing the load with the help of service. By dividing the application into services according to functional modules, and then fixing each service on some RAC nodes, the performance of the system is fundamentally provided. This method of distributing the load can not be completed only by the DBA's configuration. It requires the cooperation of the DBA and the developer to see the effect after understanding the characteristics of the business data.

In the RAC environment, service is not necessary, but if the application is divided by service, it is believed to be of great benefit to the improvement of the performance of the entire system. There is another advantage of using service: TAF parameters of Service can be created inside the database. If the client connects to the database through the service, many settings of FAIL-OVER are no longer required in the client tnsnames.ora.

If using the service method, the client configuration needs to use the service_name entry, such as the red letter part below:

TAF_SERVER =

(DESCRIPTION =

(ADDRESS= (PROTOCOL = TCP)(HOST = felix1-vip)(PORT = 1521))

(ADDRESS= (PROTOCOL ) = TCP)(HOST = felix2-vip)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = taf_server)

)

)

For a detailed study, refer to Zhang Xiaoming p238~242 of "Dahua RAC", which is very good! ! ! !