Oracle数据库GridLink Data Sources配置Oracle RAC高可用特性

OFM自身的组件需要持久化保存数据，部署应用也需要持久化保存数据。因此，考虑数据库高可用是一个恒久不变的架构设计元素。OFM对于数据库高可用的设计有很多方案，例如Cold Failover Clusters、 Oracle Real Application Clusters、 Oracle Data Guard、 Oracle Streams机制，详细参考http://docs.oracle.com/cd/E11882_01/server.112/e17157/toc.htm。本文对Oracle Real Application Clusters的高可用特性进行学习介绍。更多信息参考http://docs.oracle.com/cd/E11882_01/rac.112/e16795/toc.htm。

Oracle Real Application Clusters（Oracle RAC）是一个利用多个互连的计算单元的处理能力。RAC协调这些计算单元的聚集（硬件服务器、软件集群）成为一个更为强大的计算环境，使得Oracle RAC可以为OFM系统组件、系统服务或应用程序提供一个高度可扩展和高度可用的数据库存储服务。在这些计算单元的一个节点如果发生故障，虽然会对整体性能产生一定影响，但不会对整个服务产生可用性影响，剩下的节点仍然可用，仍然可以向外提供服务。

为Oracle数据库配置启用RAC主要有两种方式： Multi Data Sources和GridLink Data Sources。

Multi Data Sources提供了两种方式的高可用性：FailOver（故障转移）与Load Balancing（负载均衡），两种方式分别对应前面学习的Active-Passive  方案和Active-Active方案。FailOver保持一个主要实例激活提供服务，备份实例实时监听其状态，当发现激活主数据不再可用时，及时进行接管；而Load Balancing则是多实例同时运行，共同承担工作负荷，但一个节点出现故障时，将自动退出负载队列直到故障修复，实现数据库云服务的架构。

GridLink Data Sources同样提供了上述两种方式保证高可用特性，但是却给出了更多优化方面的惊喜。对于FailOver，如果使用Multi Data Sources方式，那么当应用向一个Data Source申请获取Connection时，WebLogic需要测试这个Connection是否可用，如果可用顺利返回；否则，首先将该Data Source标识dead，再从下一个Data Source获取Connection，然后每隔一定固定时间（缺省120秒）检查该Data Source是否正常，正常可以获取Connection后，再重启该Data Source。对于GridLink Data Sources，其机制使用Oracle Notification Service（ONS）与后台RAC数据库实例群进行通信，这大大提高了Connection可用性检测的效率，当ONS发现有不可用的数据库实例时，马上将其从RAC数据库实例群中移除；当发现有不可用的Connectio时，马上将其从Data Source中移除；随需可用的扩展机制，无需修改任何配置即可实现高扩展，包括新增节点和移除节点；而这些特性都要归功于GridLink Data Sources的Fast Connection Failover特点。

对于Load Balancing在Multi Data Sources方式下，只是根据请求数量实现了简单的Round-Robin的平均轮询调度方式，均匀分配请求处理数，但却无法均匀分配各节点的工作负载；而在GridLink Data Sources的配置方式下，进行了相当智能的优化改进工作，其方式叫做Runtime Connection Load Balancing（RCLB）。RCLB可以实时运行期间，根据RAC数据库实例群各节点的工作负载情况进行动态调度，比如通过侦听其CPU、内存、可用性、响应时间等情况再决定路由的目标节点，一个耗费资源严重的执行请求可能分配给一个节点，而很多耗费资源微小的执行请求可能分配给另外一个节点，根据节点的工作负载情况分配，而不是根据请求数量的分配。如图所示：

 

GridLink Data Sources除了优化了Multi Data Sources所拥有的FailOver和Load Balancing特性外，还在Graceful Handling for Oracle RAC Outages与 GridLink Affinity有良好表现。

Graceful Handling for Oracle RAC Outages是指如何以优雅的方式处理计划内的停机维护升级与计划外宕机故障。
计划内的停机维护升级处理方案：数据源Data Source将允许还在执行中的事务结束后再关闭数据库连接Connection，对于后续的请求将路由转发至仍然处于激活服务的数据库中，保障单个节点虽然停机，但整体数据库服务不停机的可用状态；

计划外宕机故障处理方案：数据源Data Source将对还在执行中的事务进行完美回滚后再关闭数据库连接Connection，对于后续的请求将路由转发至仍然处于激活服务的数据库中，同样保障单个节点虽然停机，但整体数据库服务不停机的可用状态；

GridLink Affinity被设计用于最大化提高RAC的集群能力。当第一个请求到达RCLB时，在路由转发到一个RAC实例前，它将会得到一个Affinity上下文标识，后续该请求的连接请求将会路由到相同的RAC实例，直到该会话结束或事务结束，从而提高缓存的可能、减少数据一致性同步的开销等特点。GridLink Affinity主要有两种策略：

Session Affinity Policy当Web应用程序的用户在进行在线交易处理（OLTP）的处理时，对于相同的记录或反复操作若交由同一个RAC实例处理，将会得到很好的处理表现。如在线购物车或银行事务处理的应用场景。其原理如图所示：

 

XA Affinity Policy  XA Affinity 可以确保在全局事务控制中，将所有的数据基本操作都分发到一个相同的Oracle RAC集群实例中进行处理。其原理如图所示：

 

总结：通过以上学习和介绍，相信在关于Oracle Real Application Clusters的选择方案上，启用GridLink Data Sources绝对是一个不错的决定。更多资料参考

http://docs.oracle.com/cd/E21764_01/web.1111/e13737/gridlink_datasources.htm