OFM系统高可用性总体框架设计

高可用性通常用来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。一个高可用性HA框架是每个系统架构设计的重要考究部分。高可用性一般使用正常服务时间与运行总时间百分比进行测量，以下提供了一些参考数据：

可用性百分比	全年停机时间
95%	18 天
99%	4 天
99.9%	9 小时
99.99%	1 小时
99.999%	5 分钟

计划性停机（日常维护升级）和计划外的宕机（系统崩溃）是评估系统可用性的两种不同停机情况。一个系统通常需要非常严格的对待未计划宕机，但是又需要一个灵活设计处理计划性停机。你需要选择不同的高可用性方案来处理这些不同的可用性失效切入点。Oracle Fusion Middleware拥有一系列高可用设计特性，可以保护组件和应用发生计划外的宕机故障，并且尽量缩短因日常维护操作所消耗的计划内停机时间。OFM的这些高可用HA设计主要表现为以下几点：

心跳检测与自动重启

对于运行于WebLogic Server上的Java EE组件，Node Manager监听着Managed Server，一旦发现Managed Server无响应，Node Manager会根据预先配置的次数重启Managed Server实例；

对于系统System组件，OPMN监听其运行进程，一旦发现该进程无响应，OPMN会根据预先配置的次数重启该系统组件；

集群

OFM通过WebLogic Server所构建的强大集群特性提供集群支持。这些集群特性包括冗余保护、失效转移、Session复制、JNDI服务集群、服务实例迁移等，详细说明参考文档http://docs.oracle.com/cd/E23943_01/core.1111/e10106/aa.htm

状态复制与路由

Oracle WebLogic Server能够配置为在应用之间复制状态，使用集群环境下的Managed Server维护备份应用状态信息。OFM对于状态复制主要有以下三种类型：

有状态组件，如：ADF 、WebCenter

无状态组件，如：Internet Directory、Oracle HTTP Server、Oracle Web Cache

有状态但没有复制特性组件，如：Oracle Forms 、Oracle Reports。这些组件由C语言编写，需要通过失效转移支持高可用性。

失效转移

在学习失效转移时，先了解两个概念。Session复制（Session replication）和Session粘性（Sessionsticky）。前者基于request的负载均衡的方案。负载均衡器根据每个node节点的状况，将每个request进行分发，多个node节点之间保持整个cluster的用户状态同步。后者基于用户的负载均衡，当用户发出第一个request后，负载均衡器动态的把该用户分配到多个node节点中的某一个，并记录该分配路由规则，后续该用户的所有request都将于这个node绑定，用户只会与该服务实例发生交互。前者的优点在与集群环境中只要有一个node存活，用户用户状态都不会丢失，cluster都能够继续工作；而缺点是

集群node之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。后者的优点是响应速度快，多个节点之间无须通信；而缺点是当这个被绑定粘住的node挂掉，那么与之相粘的用户Session状态也随之丢失。

在OFM的集群架构设计中，Managed Server作为Java EE的容器组件，通常有一个Web服务器，如Oracle HTTP Server。它们设计为集群架构运行于Managed Server的前端，通过Web服务代理的插件（mod_wl_ohs）为Managed Server在运行期间提供复制均衡的作用。当一个Managed Server不可用时， mod_wl_ohs会将请求路由分发到另外一个维护了同样Session的Managed Server中，在失效转移的过程中保证了会话状态的同步迁移。对于OFM有状态组件均是使用Session复制的架构设计；而对于OFM无状态组件一般通过负载均衡器完成请求分发，负载均衡器被配置为拥有心跳测试机制，当侦听到一个Managed Server不可用时，负载均衡器将会路由选择另外一个Managed Server，由于不关注状态，因此此项技术相关成熟，可以准确无误的处理高并发请求；而对于OFM有状态但没有复制特性组件一般设计为Session粘性的价格，一旦与用户粘性的node节点不可用，用户的请求将会转移到一个新的node节点进行处理，用户需要在该节点重建会话状态。

服务迁移

在WebLogic Server集群，大多数服务组件均匀部署在集群中的所有服务器实例，使得发生故障时可以透明的从一台服务器的转移到另一个。 而一些“固定服务”，如JMS和JTA事务，WebLogic Server支持故障恢复 ，而不是进行故障转移。

根据迁移的不同级别，OFM拥有不同的策略。对于整个的服务器迁移级别，发生故障的WebLogic Server服务器的所有集群实例或组件可以迁移到另外不同的物理机器上；对于服务迁移级别，服务或组件可以迁移到集群环境中的另外一个node节点实例；对于JMS和JTA事务这样特殊的服务，OFM提供了自动和手动两种方式迁移。当故障发生时，OFM会首先尝试在部署这些特殊服务的设备上重启服务，若重启服务失败，这些服务将会转移到另外的设备节点实例运行。另外，也允许手动初始化这些服务。

集成高可用

Oracle融合中间件有一个全面的功能，围绕利用Oracle RAC数据库的可用性和伸缩性的负载平衡和故障转移设置。

对于XA兼容的应用程序，如Oracle SOA组件，WebLogic服务器作为一个事务协调员，并确保分布式事务处理都运行于一个Oracle RAC实例。

当事务服务在托管的服务器出现故障的情况下自动迁移到集群中的另一个节点，并执行事务恢复。

对于Web服务器和应用服务器之间的通信，代理插件（如mod_wl_ohs）有一个内置的负载均衡和故障切换功能，可以将request请求准确无误的重新路由到可用的群集成员node节点实例中。

滚动式补丁升级修复

Oracle WebLogic服务器允许滚动的方式进行补丁升级，而不必关闭整个群集进行修补。集群的滚动修补期间，服务器集群中的每个单独修补和重新启动，而在集群中的其他服务器继续托管您的应用程序。 

配置管理

大多数OFM的组件都可以配置为集群级别。 OFM使用WebLogic Server的集群管理的配置管理提供组件集群选项。如数据源、EJB、JMS、应用程序构件、ADF和WebCenter自定义应用程序等。

另外，还有一个中央MDS存储信息库，它为集群的所有组件成员提供额外的应用程序级组件配置。 这些组件成员包括：Oracle SOA、Oracle WebCenter、应用程序构件、SOA组件（BAM、BPM、OSB）等。

备份与恢复

OFM的备份与恢复是基于中间层组件的文件系统复制的一个简单易用的解决方案。 RMAN用于Oracle数据库。 OFM也支持为在线联机备份，可以整合现有的备份和恢复工具，或通过使用OFM企业管理器 Enterprise Manager Tools或计划作业排定的备份任务。

 

在处理高可用性带来的问题时，往往需要很多技术方案和最佳实践。其中，最为重要的便是冗余保护机制。在OFM很多组件都有自身冗余保护的设计，你可以应用以下两种解决方案为应用实现高可用。

Active-Active 方案：部署两个或两个以上系统实例，可通过水平升级增加系统实例的方式提供高可用。在此方案中，所有系统实例都同时受理请求，通过负载均衡算法承担请求执行。

Active-Passive 方案：部署一个处于激活状态的系统实例处理用户请求，另外再部署一个处于就绪状态的系统实例作为备选。在两个实例之间建立心跳检查，但发现心跳测试失败或处理请求响应失效，则主从两个实例进行相互状态切换，以保证新的系统实例接管响应用户请求，旧的实例进入自我修复进程。

对于大多数应用场景，并且外部环境允许的条件下，强烈推荐使用Active-Active方案。该方案可以提供快速的失效转移、伸缩扩展性等特性最大化保障系统高可用性。而扩展性是非常重要的一个高可用性解决方案的设计，在Active-Active方案随着负载压力的上升，可以通过增加更多的服务实例或组件实现水平升级。而对于某些特殊场景，比如应用只允许有且仅有一个单例的服务实例存在，那么就应该使用Active-Passive方案。以下是一个Active-Passive方案的参考架构：

在参考架构中，激活实例与就绪实例通过共享存储的方式，对Web、应用、安全等Session会话进行复制和同步，同时使用了ORACLE DATA GUARD作为容灾备份方案。对于ORACLE DATA GUARD的详细介绍参考文档http://docs.oracle.com/cd/E17904_01/doc.1111/e15250/intro.htm。

从上述的参考架构中可以看出，OFM内置设计了很多负载均衡的特性，比如Web服务器到应用服务器、应用服务器到数据库服务器的路由。但OFM并没有提供容器外的负载均衡器，为了确保外部的负载均衡器可以与OFM集成应用，必须确保外部负载均衡器满足下述要求：

需求	描述
虚拟服务器和端口配置	可以在外部负载均衡器配置虚拟服务器名称和端口信息。虚拟服务器名称和端口必须满足以下要求： 1.   负载均衡器应该允许多个虚拟服务器的配置； 2.   对于每一个虚拟服务器，负载均衡器可以管理多个端口的通信。例如对于Identity Management，负载均衡器需要能够配置HTTP / HTTPS的通信，LDAP/LDAPS的通信； 3.   虚拟服务器的名称必须与IP地址关联，并作为整个DNS的一部分； 4.   客户端可以通过虚拟服务器名称访问负载均衡器；
持久性/粘性	一些OFM组件使用外部负载均衡器的持久性或粘性。如果外部负载均衡器不容许你在URI级别设置Cookie持久性，为所有的HTTP通信设置​​Cookie持久性。在任何情况下，设置cookie的浏览器会话结束时到期。
资源监测/端口监控/过程的故障检测	配置外部负载均衡器进行服务服务和节点故障检测（例如通过通知或其他方式），并停止对失败节点的路由通信。你的外部负载均衡器需要具备自动检测故障的能力.
Network Address Translation (NAT)网络地址转换（NAT）	负载均衡器应该有能力执行网络地址转换（NAT），从客户端请求转换传送到OFM组件节点实例。
容错模式	强烈建议配置负载均衡器处于一个健康的容错模式，否则负载均衡器成为系统的单点故障。大多数软件负载均衡器实现该模式是基于可靠的解决方案作为一个单一的过程/拦截。
其他	强烈建议将虚拟服务器的负载均衡器配置为立即返回客户端请求的响应，并将后台运行的服务只为不可用。此项配置是基于客户端服务器在TCP/IP 设置的范围内，发生请求等待超时导致连接丢失，从而失去接收响应的机会。