Oracle RAC LoadBalance

LoadBalance 就是把负载平均的分配到集群中的各个节点，从而提高整体的吞吐能力。 Oracle 10g RAC 提供了两种不同的方法来分散负载：

1.  通过Connection Balancing，按照某种算法把用户分配到不同的节点。也可认为是纯技术的分散负载。
2.  通过Service，在应用层上进行分散，也可认为是面象业务的分散负载。

一．Connection Balancing

　　Connection Balancing 这种负载均衡是在用户连接这个层次进行的，也就是在用户请求建立连接时，根据每个节点的负载决定把连接分配给哪个实例，而一旦连接建立之后，会话的所有操作就都在这个实例上完成，而不会再分派给其他节点了。Connection Balancing 有客户端和服务端两种实现方法。

1.1 客户端均衡（Client-Side LB）

　　客户端均衡（Client-Side LB）是Oracle 8 使用的方法，配置方法是在客户端的tnsnames.ora 文件中加入：LOAD_BALANCE=YES 条目。当客户端发起连接时，会从地址列表中随机的选取一个，在使用随机算法把连接请求分配到各个实例。

一个Clint-Side LB的TNS 配置文件如下：

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)
      )
    )
  )
注： rac1-vip 需要添加到hosts 文件中

　　这种方法缺点很明显，因为在分配连接时没有考虑每个节点的真实负载，最后分配结果不一定是平衡的；并且随即算法需要长时间片，如果在短时间内同时发起多个连接，这些连接有可能都被分配到一个节点上，甚至更坏的情况下，连接可能被分配到故障节点上。因此Oracle 引入了服务端均衡(Sevice-Side LB)方式。

1.2 服务器端均衡（Server-Side LB）

　　Server-Side LB 是从Oracle 9引入的。 它的实现依赖于Listener收集负载信息。 在数据库运行过程中，PMON后台进程会收集系统的负载信息，然后登记到Listener中。 最少1分钟，最多10分钟PMON就要做一个信息更新，并且如果节点的负载越高，更新频率就越高，以保证Listener能掌握每个节点准确的负载情况。如果Listener关闭了，PMON进程会每隔1秒钟检查Listener是否重启。除了这个自动的，定时的更新任务外，用户也可以使用alter system register 命令来手工进行这个过程。

　　这个自动更新动作，可以从Listener的日志中看到，比如下面这个Listener日志片段很清楚的记录了这些动作。注意，实例启动时PMON进程进行的第一次登记过程叫作Server-register，而后的更新过程叫作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

　　Listener 日志虽然记录了PMON 进程的注册和更新动作，但是注册的内容却没有体现，要想获得这些内容，可以通过跟踪10257 事件来获得，这个事件就是跟踪PMON活动。Event="10257 trace name context forever,levl 16"

　　PMON 进程不仅会向本地的Listener注册，还可以向其他节点上的Listener注册。但到底要向何处注册，是由Remote_Listeners 和Local_Listener 两个参数决定。 Local_Listener 不用设置，而Remote_Listener 需要设置，参数值是一个tnsnames项。

SQL> conn / as sysdba
Connected.
SQL> show parameter listener
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
local_listener                       string
remote_listener                      string      LISTENERS_RAC
SQL>

节点的tnsnames.ora 中对应的LISTENERS_RAC 内容如下：

LISTENERS_RAC =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
  )

有了PMON的自动注册机制后，集群的每个节点的Listener都掌握所有节点的负载情况，当收到客户端连接请求时，就会把连接转给负载最小的节点，这个节点有可能是自己也有可能是其他节点，也就是Listener 会转发用户的请求。

Listener的节点选择方法根据用户所请求的连接方式会有所不同：

1.  如果用户请求的是Delicate 专有连接，Listener首先选择负载最小的节点，如果多个节点负载相同，则从节点选择负载最小的实例。
2.  如果用户请求的是Shre Server共享功能连接，除了做节点负载比较和实例负载比较之外，还要在锁选择实例上，选择负载最小的Dispatcher进行转发。

　　Server-Side LB 和Client-Side LB 不是互斥的，它们可以一起工作，这是用户的连接请求会先从地址列表中随机选取一个地址，然后向改地址的Listener 发出请求；Listener 接到请求后，根据各节点负载情况挑选出最合适的节点转发连接请求。

1.3 两种LB 的配置方法

　　对于Client-Side LB，需要在客户的tnsnames条目中加入LOAD_BALANCE=YES；对于Server-side LB，需要配置REMOTE_LISTENER这个参数。
　　注意事项：在配置LB时，需要从各个节点实例的listener.ora文件中删除缺省产生的SID_LIST_LISTENER_NodeName条目，这样才能保证Listener获得的信息是动态注册的，而不是从文件中读取的静态信息。

我们要删除：
SID_LIST_LISTENER_RAC1 =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
      (PROGRAM = extproc)
    )
  )
 
仅保留：
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))
    )
  )

二. 利用Service分散负载

　　先来分析下Connection Balancing 方法的不足之处。 Oracle 的集群是"共享一切"的架构，所有的节点都共享一份磁盘数据。实例间通过Cache Fusion机制进行数据同步，所以RAC的性能在很大程度上受限于Cache Fusion的性能。 因此，要提高RAC的性能，可以从两方面入手：

1. 提高Cache Fusion的能力，这个可以使用更好的互联设备，比如G级的private network，或者使用Infiniband等DRA技术。
2. 可以尽量减少Cache Fusion的流量，减少实例间的互相依赖。而Service就是后一种思路基础删发展出来的。

　　先看一下与Service非常类似的Partition技术。如果一个表中的数量巨大，Oracle会建议采用Partition Table，把数据按照一定的规律（比如时间）分散到多个物理段上，这样访问数据时就限制在某些局部的Segment上。

　　把"分散数据"的思想进一步提升，在RAC环境上，如果能够把数据按照应用进行分离。比如： 一个ERP 应用包括生产，销售，供应链管理多个模块。假设这个数据库采用了2个节点的RAC，在没有进行“分散数据”之前，两个用户都使用销售模块，那么这两个用户就可能被分配到两个节点上，在操作过程中，销售数据就要在Cache Fusion的作用下，不断在两个字节间传递。如果又来了另外两个生产模块的用户，在两个用户被分配到两个节点上，在操作过程中，生产部分又要在Cache Fusion的协助下在两个实例间同步。　　

　　可见，如果仅有Connection Balancing一种机制，表面上看起来用户是被分散到了不同的Instance上，似乎负载被分散了。 但是这种分散是没有结合每个用户的业务需求下进行的，是一种纯技术手段。这种分散反而可能加重了系统间的负担。

　　如果换一种思路，假如把销售模块的用户都分配到节点1上，生产模块的用户都分配到节点2上，在假设这两个模块之间的数据交叉不。 这时销售模块的数据都集中在节点1上，生产模块的数据都集中在节点2上， Cache Fusion的工作量就会急剧较少，就能从根本上解决了性能问题。

　　Service分散负载的中心思想：通过把应用按照功能模块进行划分成Service，进而把每个Service固定在某个RAC 节点上，从而从根本减少Cache Fusion的流量，减少实例间的互相依赖。 这种分散负载的方法不是仅靠DBA进行配置就能完成的，需要DBA 和开发人员合作，在了解业务数据特点之后才可能看到效果。

　　注：Service-Side TAF有一个Instance Role(实例角色)的概念。 所谓的实例角色，就是当有多个Instance 参与一个Service时，可以配置优先使用哪一个Instance为用户提供服务。参考： Oracle RAC Failover

　　在RAC环境下，Service 并不是必须的，但是如果能借助Service 对应的划分，相信对整个系统性能的提升是有很大好处的。使用Service还有另一个好处：可以在数据库内部创建Service TAF参数，如果客户通过Service 连接数据库，客户端的tnsnames.ora 中就不再需要FAIL-OVER 的许多设置。只需要添加如下条目即可：

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)
      )
    )
  )

--整理自《大话 oracle rac》