OFM自身的组件需要持久化保存数据,部署应用也需要持久化保存数据。因此,考虑数据库高可用是一个恒久不变的架构设计元素。OFM对于数据库高可用的设计有很多方案,例如Cold Failover Clusters、Oracle Real ApplicationClusters、Oracle Data Guard、
Oracle Real ApplicationClusters(Oracle RAC)是一个利用多个互连的计算单元的处理能力。RAC协调这些计算单元的聚集(硬件服务器、软件集群)成为一个更为强大的计算环境,使得Oracle RAC可以为OFM系统组件、系统服务或应用程序提供一个高度可扩展和高度可用的数据库存储服务。在这些计算单元的一个节点如果发生故障,虽然会对整体性能产生一定影响,但不会对整个服务产生可用性影响,剩下的节点仍然可用,仍然可以向外提供服务。
为Oracle数据库配置启用RAC主要有两种方式:
Multi Data Sources提供了两种方式的高可用性:FailOver(故障转移)与Load Balancing(负载均衡),两种方式分别对应前面学习的Active-Passive
GridLink Data Sources同样提供了上述两种方式保证高可用特性,但是却给出了更多优化方面的惊喜。对于FailOver,如果使用Multi Data Sources方式,那么当应用向一个Data
对于Load Balancing在Multi Data Sources方式下,只是根据请求数量实现了简单的Round-Robin的平均轮询调度方式,均匀分配请求处理数,但却无法均匀分配各节点的工作负载;而在GridLink Data Sources的配置方式下,进行了相当智能的优化改进工作,其方式叫做RuntimeConnection Load Balancing(RCLB)。RCLB可以实时运行期间,根据RAC数据库实例群各节点的工作负载情况进行动态调度,比如通过侦听其CPU、内存、可用性、响应时间等情况再决定路由的目标节点,一个耗费资源严重的执行请求可能分配给一个节点,而很多耗费资源微小的执行请求可能分配给另外一个节点,根据节点的工作负载情况分配,而不是根据请求数量的分配。如图所示:
GridLink Data Sources除了优化了Multi Data Sources所拥有的FailOver和Load Balancing特性外,还在GracefulHandling for Oracle RAC Outages与GridLinkAffinity有良好表现。
GracefulHandling 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
总结:通过以上学习和介绍,相信在关于Oracle Real ApplicationClusters的选择方案上,启用GridLink Data Sources绝对是一个不错的决定。更多资料参考
http://docs.oracle.com/cd/E21764_01/web.1111/e13737/gridlink_datasources.htm