WebLogic Server 高可用特性

zyh3033

什么是WebLogic服务器集群
WebLogic Server集群包括多个WebLogic Server服务器实例同时运行并一起工作提供强大的可伸缩性和可靠性。 构成集群的服务器实例可以运行在同一系统上，或位于不同的系统上。 可以通过添加额外的逻辑服务实例，或物理服务器实现现有系统的集群能力的扩展。但集群中的每个服务器实例必须运行同一版本的WebLogic Server。
什么是WebLogic服务器域
集群是WebLogic服务器域的一个组成部分。WebLogic服务器域是WebLogic的管理组织单元，它将很多WebLogic的服务实例组织起来形成一个逻辑单元。这些服务实例可以是集群协作的，也可以不是。一个域可以包含多个集群，在每一个服务器域中，有一个特殊的服务实例扮演Administration Server的角色，这个特殊的Administration Server维护了其他所有服务实例的资源、配置、管理和监控等信息，一个Administration Server只能管理一个服务器域。因此，如果一个服务器域拥有多个集群，那么这些集群拥有相同的一个Administration Server。
服务器集群的关键特点
1)         应用故障失效转移
故障转移意味着，当一个应用程序组件做某项工作的时候，因为一些原因出现故障导致该组件不可用时，失败对象的副本转移到其他组件完成这项工作。
为了完成失效转移，必须有如下机制保证新对象可以继续完成已失败的任务：
ü  已失败任务中的对象数据和状态能够拷贝至新对象；
ü  能够提供发生故障是失效对象的位置和运行信息，以便可以诊断发生故障时的执行计划；
ü  能够提供发生故障是执行任务进程的进展情况，以便可以诊断发生故障时失效对象已经成功完成的任务信息和执行程度。例如多少数据状态发生变化，整个过程完成了多少步骤等。
2)         服务迁移
WebLogic的服务实例支持自动或手动的方式将集群环境下的一个服务实例迁移到另外一个环境。这项技术在下述高可用性的需求应用场景中非常有用：
ü  可以确保一个单实例服务的不中断的情况下可靠运行，阻止单点故障发生的破坏性。比如JMS和JTA服务故障恢复，当这些单实例服务服务发生故障时，运行这些服务的 Managed Server可以自动迁移至一个可用的Managed Server；
ü  作为计划内的迁移方案，例如主机维护升级切换等。此项任务可以通过WebLogic管理控制台或命令行的方式操作服务实例间迁移，保障服务不间断的随时可用。
3)         负载均衡
负载均衡可以通过计算和网络资源的通信，使得分布式环境的任务协同工作。作为负载均衡的对象需要具备如下特性：
ü  一个对象拥有多份拷贝，可以协同完成相同的特定工作；
ü  所有对象的状态和运行信息可以共享使用；
可以作为服务器集群管理的对象类型
一个应用程序或者组件可以在一个集群环境下的多个服务器实例中运行，享有负载均衡、失效转移等集群高可用性冗余保护方案。Web应用由多种类型的对象组成，例如EJB、Servlet、JSP等，每类对象都拥有自己特殊的配置要求、调用方式、运行行为和功能维护等管理方式。因此，针对不同类型的对象，WebLogic集群技术也有不同的技术方案，可以支持集群技术的对象类型如下：
Servlet、JSP、EJB、RMI Objects、JMS Objects。其中有些对象之间拥有相同的特点行为，因此他们拥有相同的集群管理方案，如以下两组：Servlet和JSP；EJB和RMI Objects。
集群环境下的服务器间通信
集群环境下的服务器间通信方式主要基于如下两种网络技术:
ü  IP Socket，这是群集服务器实例之间的点对点的通信管道。
ü  IP 单播或组播，服务器实例使用的广播服务和心跳通信，表明持续可用性。 当创建一个新的集群，Oracle建议使用集群内的单播消息。 对于与WebLogic Server的早期版本的向后兼容版本，必须使用组播集群之间的通信。
群集范围内的JNDI命名服务
在WebLogic Server群集范围外的客户端通过使用标准的JNDI命名服务访问服务器实例。 WebLogic Server实例提供了一个服务器名字绑定到JNDI树，并表示为服务。  JNDI命名服务组成一个与服务器实例绑定的服务器名称树列表。客户端通过JNDI服务获得该树，并根据树上该服务器名称的绑定关系获得服务器实例。
集群中的每个WebLogic Server实例的创建和维护一个JNDI树，大多数情况下这个JNDI看上去像是一个单独的WebLogic Server实例树，然而有时候这个JNDI树也可以存储来自集群内其他服务器实例提供的集群对象的服务，例如EJB、RMI对象。 
群集范围的每个WebLogic Server实例都在本地维护了一份集群JNDI树的拷贝，一旦实例重启（或者新的服务部署到正在运行的实例时），WebLogic Server实例首先将这些服务对象绑定到本地的JNDI树拷贝中，并将这些服务对象的存根发送到集群环境中其他的WebLogic Server实例感知。其他的WebLogic Server实例成员将通过组播或者单播地址检查该实例提供的这些服务对象是否可用。
群集范围内的故障检测和会话复制
1)     故障检测
为群集提供高可用性，它必须是能够从失败服务中恢复。 集群中的WebLogic Server实例通过监测，观察他们的同行服务器实例是否发生故障：
ü  Socket实时点对点及时通信
WebLogic Server实例监控使用IP套接字网络连接的方法，实时检测对等服务器实例是否发生故障。 如果一个服务器实例通过Socket连接另外一个服务器实例进行数据通信时，由于网络中断或不可用故障发生时，那么将与这个不可用服务器实例相关的所有服务对象将从JNDI命名树中删除。
ü  定期的服务器心跳检测
如果集群环境下的服务器实例不开发实时的点对点及时通信，出现故障的服务器实例仍然能够被WebLogic Server通过心跳检测发现，并 组播或单播到集群中的其他成员分发这个心跳消息。
每个心跳消息包含数据的唯一标识该服务器实例消息。 服务器自身在10秒一个周期定时播出他们自己的心跳消息。 同时，每个服务器也在这个周期进行监控，以确保所有同行服务器的心跳消息正在发送组播或单播其心跳消息。一个服务器如果三次以上心跳检测失败（或30秒内未发出心跳消息），该服务器实例将被认为出现故障不可用，此时将与这个不可用服务器实例相关的所有服务对象将从JNDI命名树中删除。
2)     会话复制
在标准Java EE的应用程序规范体系中，对于用户会话Session的保存方法有两个标准实现：Stateful Session EJB 或者 HTTP Session。 如果你同时拥有Java EE应用程序中的Web组件和EJB组件，那么你应该将用户会话Session信息存储于HTTP Session中，原因如下：
ü  HTTP Session管理为故障转移提供了更多的选择，如Session复制，数据库持久管理或文件存储；
ü  极好的可扩展性；
ü  复制HTTP Session状态往往发生在事务外，而Stateful Session EJB往往发生在事务内，因此Stateful Session EJB需要考虑更多的关联元素；
ü  两种复制方式，HTTP Session相对Stateful Session EJB有更多优化的空间和广泛的应用案例
服务迁移
在WebLogic Server集群，大多数服务组件均匀部署在集群中的所有服务器实例，使得发生故障时可以透明的从一台服务器的转移到另一个。 而一些“固定服务”，如JMS和JTA事务，WebLogic Server支持故障恢复 ，而不是进行故障转移。
根据迁移的不同级别，OFM拥有不同的策略。对于整个的服务器迁移级别，发生故障的WebLogic Server服务器的所有集群实例或组件可以迁移到另外不同的物理机器上；对于服务迁移级别，服务或组件可以迁移到集群环境中的另外一个node节点实例；对于JMS和JTA事务这样特殊的服务组件，OFM提供了自动和手动两种方式迁移。当故障发生时，OFM会首先尝试在部署这些特殊服务的设备上重启服务，若重启服务失败，这些服务将会转移到另外的设备节点实例运行。另外，也允许手动初始化这些服务。更多资料请参考http://docs.oracle.com/cd/E11035_01/wls100/cluster/migration.html
Administration Server 和 Node Manager 的高可用
当一个服务器域下的Administration Server不再可用发生故障时，这个Administration Server所管理的集群下的Managed Server或者非集群下的Managed Server仍然可以运行。并且，即便在Administration Server已经完全挂掉的情况下，配置在服务器域集群下的服务器实例仍然支持负载均衡和故障转移的高可用特性。
如果一个Node Manager不可用，或者将它重启、停机等操作，那么Node Manager会诊断它所控制的的服务器实例，Node Manager可以在任何情况下重启所需要的服务器实例。因此，强烈建议装机时将Node Manager作为一个操作系统服务，以便机器重启时，Node Manager可以自动重启。
GridLink数据源
GridLink数据源提供了针对Oracle RAC数据库与WebLogic Server之间的连接功能。如图所示：


GridLink很大程度上借助了数据库的功能，它利用数据库RAC端的ONS服务采集RAC结点的运行数据，并这些数据传给Gridlink Data Source的ONS监听客户端，使得WebLogic Server获得了更多高效的高可用性特性，如：快速获取失效连接、运行时负载均衡、优化计划内与计划外的数据库停机事件处理等，详细资料请参考
http://docs.oracle.com/cd/E23943_01/web.1111/e13737/gridlink_datasources.htm#JDBCA373
关于单例服务
有一些特殊服务职能运行于一个单独的服务器实例中，例如JMS和JTA，如果是服务本身逻辑不可用，那么将会启动故障恢复系统进行处理，若故障恢复系统依旧不能恢复，则会进行服务迁移。但如果是这些服务的宿主服务器本身实例不可用发生故障，那么会从集群中另外配置一个Managed Server进行自动迁移，并启动这些单例服务。
 
OFM组件中WebLogic Server的主要高可用性（HA）设计详细文档参考 http://docs.oracle.com/cd/E23943_01/web.1111/e13709/toc.htm