第二章 WebSphere的集群可靠性和可靠性管理2. WebSphere应用服务器容错和恢复

第二部分 WebSphere的集群可靠性和可靠性管理

 

2. WebSphere应用服务器容错和恢复

WebSphere应用服务器容错和恢复是通过WebSphere Application Server NetworkDeployment V6提供的负载管理机制（WLM），来实现的。如果你的应用服务器不使用WLM（也不使用其他的集群软件），你的系统将不能提供容错处理，这种情况下一但你的应用服务器down机你Web和Javaclient也会放生错误。

这一章将对WLM和WasND版的容错能力做一个介绍。关于这个话题更多的信息请见《IBM WebSphere scalability and Performance Handbook》

 

本章讨论的话题如下：

Ø        可靠性介绍

Ø        Was应用服务器集群

Ø        Was负载管理定义

Ø        服务器之间的session状态管理

Ø        Web container集群和容错

Ø        备份集群支持

2.1    可靠性的介绍

众所周知可靠性是系统对不论在何种情况下对请求的响应能力。可靠性需要拓扑提供一定程度的处理冗余，以消除单点故障。但是垂直部署（同一系统上部署多个应用服务器）可以通过建立多个处理提供这种能力，但是物理机器就变成了单点故障，基于这个原因高可靠系统拓扑包括通常是跨多个机器和LPAR的水平部署。

2.1.1.    基于硬件的高可靠性

使用Was多台机器和LPAR配置可以消除单个应用服务器处理的单点故障。在WAS ND V6中通常不会对管理服务器的安全、命名和transaction的依赖，所以一个交易处理故障通常不会对应用处理产生干扰。

实际上，Was Cell中一个唯一的单点故障是Deployment Manager，一个Was的DM错误会影响备份cluster的配置cell configration的能力、执行tivoli的观察器、EJB的容错处理。有几种替代的方案来为DM的提供高可靠性，包括扩展的高可靠性方案。尽管这新对DM最小影响的方案通常不会使用。有的用户甚至在他们的生产系统中不使用DM系统。更多第三方软件的信息请见第五部分“using exteral clustering softwar”

2.1.2.    负载管理

Was ND v6版的workload management以最优的方式在可用的应用服务器之间分配请求。Workload manager技术是基于多台应用服务器集群（也就是所谓的集群成员）。一个应用部署于一个集群成员就会同时运行于所有的集群成员之上，Workload基于权重将请求分配给每一个集群成员，所以处理能力较强的机器将比处理能力较弱的机器收到更多的请求。

Workload management（WLM）也负责将现有的用户请求容错到其他仍然工作的应用服务器上（P59），and of directing new requests only to available processes should an application server in the cluster fail.另外，WLM可以使应用服务器在用户服务不停止的情况下透明的进行升级和维护。如果一个环境无法负载更多的请求，你可以在任何节点添加成员到集群中。更详细的信息请见2.3“WebSphere workload managaement defined”

2.1.3.    Failover

拥有多台应用服务器（通常是多台互相不关联的机器）自然会想到系统容错能力，也就是系统中任何一台机器或者服务器不论什么原因发生故障系统能够通过剩下的服务器和机器继续运行。负载均衡的特性是保证用户端的负载能够分配到剩下的服务器，每台服务器根据能力负载一定比例的负载，当然这样的方案要求系统被设计成具备一定冗余处理能力的系统以保证剩余的服务器可以更有效率处理客户端的负载。

理想的情况下，容错对于客户端来说应该是透明的。当一个服务器发生错误时，所有当前同客户端进行交互的服务器自动的被定向到一个健康的服务器上，不会发生服务的中断也不需要客户端作任何的特殊处理。然而实际上多数的容错方案并不能够完全的透明。比如说，一个客户端在处理交易的过程中服务器发生错误，客户端会收到错误并且需要客户单重试（应该有可用服务器接管交易）；再或者客户端交易在服务器容错请求之前发生停顿或者速度较慢。容错的关键点是一个客户端或者一组客户端利用容错系统的特性在系统发生错误或者变得不可用是最终能够收到服务。反而言之，当之前的一个错误的服务器再次变得可用，系统能够自动的重新向该服务器分配一定比例的负载。

Faiover有时也被称作是容错，因为他允许系统发生多种的错误或者故障。应该注意到的是Failover是众多容错领域中的一种技术，并且没有哪种技术能够保证系统100％的安全，Failover的目标是最大程度的减少系统发生故障的可能性，但是需要明确的是尽可能减少并不能全部消除系统故障。

提示：在上文关于failover的讨论中，术语server通常指的是一台物理机器，websphere也允许同一台机器上存在多个独立处理，同一台机器也可以作failover。

2.1.4.    HAManager

Was V6中引入一个关于高级failover和高可靠性的概念称之为High available Manager(HAManager).HAMangager提高了Was的单个服务的能力，比如事务服务和消息服务。HAManager作为一个服务运行在WebSphere应用服务器中以监控集群的健康程度，一但服务器发生错我，HaManager将failover这个服务并恢复“飞行中(in-flight)”中的事务”。具体请见第六章“WebSphere HaManager”。

2.1.5.    Session Management

除非你只有一个应用服务器或者你的应用是完全的无状态的，否则维持HTTP用户请求的状态是决定你的配置的一个重要环节，然而使用session信息需要在开发者的便利、系统性能、系统分布之间进行平衡。实践中还没有完全实现session data的使用，但是应该减少session data的使用。Persistence（固化）机制降低了这个系统的处理能力，或者引致增加处理能力的成本和增加额外的服务器，所以在设计你的WebSphere化境时要尽可能的减少session的需求。

在Was v6中有两种在多台服务器中共享session数据的方法，一种是将session数据存贮于数据库中，另一种是使用memory-to-memory的数据复制功能，这项技术在v5中以内部消息的方式实现的。Memory-to-memeory数据复制（有时候也被称作是in－memory－replication）消除数据库存储session的单点故障（如果该数据库没有进行Ha建设）。

你可以在2.4“managing session state among servers”中找到更多的信息。

2.2    WebSphere Application Server clustering

一个集群是一组受负载均衡管理器管理的应用服务器，应用服务器可以是一个节点也可以是多个节点的。一个ND额Cell可以根据cell的管理需要包含多个集群或者不使用集群。集群是多个应用服务器的逻辑体现，和节点没有关系，也不和任何一个真实的server通讯。一个集群只是包含应用服务器以及和这些应用服务器处理能力相关的负载权重。

当创建一个集群时，一个可行的做法是选择一个已经存在的应用服务器作模板（被选择的服务器仅仅是作为一个模板不会受到影响）。所有其他的成员都可以根据最初的模板来创建。

集群成员可以以以下几种方式添加到集群中：

创建集群时或者创建集群之后；创建集群的过程中，一个已经存在的应用服务器或者新建的应用服务器都可以加入到集群中；也可以后续将额外的成员加入到集群中。根据你的系统的负载能力，你可以为集群成员定义不同的权重。

集群成员需要相同的应用组件，但是他们可以被设置不同的期限权重、堆大小、以及其他的环境因素，你必须小心谨慎的修改任何配置，这些配置在不同的集群成员会导致不同的行为。这样的概念允许集群既可以包含比较大的企业级的机器也可以包含比较小的类似运行在windows平台的服务器。启动和停止集群会自动的启动和停止整个集群成员，修改应用也会扩展到整个集群应用服务器。

图2－1展示了服务器集群的配置，集群1只包含了B节点的两个集群成员，集群2完全独立于集群1包含A节点的连个成员和B节点的3个成员，最后A节点包含一个自由的不属于任何集群的应用服务器。

2.2.1.    Clustering for scalability and failover

Clustering 是一个运行垂直和水平发布应用服务器的有效的方法。

 

垂直发布

图2－2展示了垂直发布，多个集群成员被定义在同一台机器上（节点），这种方式允许机器的处理能力被有效分配。

即使单个的JVM可以充分的利用机器的处理能力，你也许还会因为其他原因建立多个集群成员，比如利用垂直发布提高集群的可靠性，如果一个jvm达到了表或者内存的限制（或者相似的问题），另一个可以提供容错能力。

我们建议你尽量避免对给定的机器毫无依据的决定集群成员的数量，唯一的方法是先调试一个应用服务器的实例的吞吐量和性能，然后把它加入集群，其他的成员也采用同样方法逐一的加入集群中。每个成员都加入集群后测试性能和吞吐量。当你配置了一个垂直部署的拓扑结构要时常监控内存的使用，不要超过物理机器的可用内存。通常情况下一个大的sever的cpu利用率如果达到了85％，那么添加额外的集群成员可获得的性能空间并不大。（指的是在垂直发布的情况下）

 

水平部署

图2－3展示的水平部署集群成员在不同的机器（或者LPAR）上创建，这样作允许一个应用可以运行在几台机器上，对外展现一个系统映像最大限度的使用分布计算环境的资源。水平部署对于包含多台低处理能力服务器环境是比较有效率的。集中访问一台机器的客户请求能够被分布到系统中的多台机器。

容错处理是水平部署的另一个重要的优点，如果机器变得不可用，他的负载将被路由到集群中的其他机器。

水平部署能够处理应服务器处理错误和硬件错误（或者系统维护）而不用明显的中断客户端的服务。

提示：Was v5以上版本提供跨平台和操作系统的集群。

 

联合垂直部署和水平部署

WebSphere应用可以联合水平和垂直两种部署方式，从而获得两种部署的技术的益处。如图2－4所示：

 

保护应用服务集群成员的安全

Workload management 服务内建安全服务，该服务和WebSphere应用服务器的安全服务协同工作保护集群成员的资源。如果你的生产环境需要安全管理，那么你应该在建立集群之前使安全管理可用，安全管理对所有的集群成员都可用。

EJB方法权限，we资源安全约束，以及安全角色定义在企业应用中被应用于保护EJB和SERVLET。更多信息请见“WebSphere Application Server V6：Security Handbaook,SG24-6316”。

2.3    WebSphere 压力管理的定义

在Was Nd V6中实现了负载管理器供应用服务器集群和集群成员使用。这些成员可以存在于一个单个节点或者部署于不同的节点（LPARs）。

你可能使用Web client或者厚Java/C++客户端。当使用集群的应用服务器，如果一个server发生错误，你的客户端可以自动或者手动的定向到另一个健康的server。

WLM是was提供的用以在一个集群的WebSphere环境中提供压力均衡和偏好均衡，它在集群环境中优化处理任务的分配，用户请求被分配到系统中最有效率的服务器。

WLM也是一个提高应用性能、稳定性、可靠性的程序，当服务器发生错误提供容错。WebSphere使用WLM发送请求到集群中的替代成员。WebSphere也路由用户当前的请求到第一次提供服务的应用服务器，像EJB calls、session state都将存储于服务器的内存中。

当发布部署拓扑包含多台机器多个应用服务器时WLM是最有效率的，因为这样的结构即提供容错也提供稳定性；当高性能单台机器包含多个server的环境中它也能够用于提高稳定性；此外他还能使系统更加高效率的使用系统的可用计算资源。

有两种类型的请求可以被Was ND V6处理：

Ø        HTTP请求可以跨多个WebContainer分配，当一个http请求到达httpServer，应该马上做出分配策略。有些请求是静态内容的请求可以被HTTP服务器直接处理，动态内容的请求将被发送到运行于WebSphere服务器中的WebContainer，Web Server的plug－in将决定该请求由HTTPServer处理还是由WebSphere的web容器处理，我们称之为plug－in WLM。对于这些WebSphere请求，Web容器的高可靠性是容错方案中的关键部分。2．5“Web container clustering and failover”有详细描述。

Ø        EJB请求可以跨多个EJB容器，当一个EJB客户端从Webcontainer中或者从外面请求服务，该请求将被集群中一个Server处理，如果这个server发生故障，客户端的请求将被重定向到另外一个可用的服务器，我们称之为EJS WLM。

2.3.1.    负载分配

负载均衡是一种能够把用户端的请求分发到一组被集群的sever，使得多个server共同工作提高系统吞吐量，客户段请求会被均匀的分发到服务器以防止负载的不均衡出现某些服务器空闲或者工作量较低而另外一些服务器超负荷工作。这种负载均衡就是负载管理的好处之一。

所以规划的配置应该确认配置中的每一台机器和服务器能够平均的处理整个系统请求的一部分，换句话说如果一台机器超负荷工作而另外的机器多数时间是空闲的这样的系统是没有效率的。假如所有的机器都具备相同的处理能力（比如说cpu），那么每台机器都应该均等处理总得负载。除此之外负载应该有比例的分配到有处理能力的机器。

采用的对集群中机器分配权重的方法可以让具备不同硬件资源的机器参与到集权中来，权重分配可以明确处理速度快的机器可以分配更多的请求，负载管理器会分配更加频繁的分配请求给它。

集群情况下集群成员的错误不会危及到整个系统的吞吐量和可靠性，整个集群成员被分配到多个节点，一台机器发生故障不会影响整个应用，请求可以被路由到其他节点，集群可以做到在不停机的情况下进行系统维护。

本节只是对WebSphereWLM做一个介绍，WLM策略以及请求如何在可用server之间进行分配的细节信息在第六章以及第七章中予以描述。

2.3.2.    Workload management优点

WorkLoad management为websphere应用提供以下好处：

Ø        能够根据WLM的选择策略均衡客户端的请求。

Ø        当集群中的sever发生故障时能够提供容错能力，提高了应用服务和管理服务的可靠性。

Ø        集群能够使系统比普通配置处理更多的客户负载，可以很容易的把应用的实例加入到集群中。

Ø        集群能够在不停止客户服务的情况下对服务器进行升级和维护。

Ø        集群集中管理应用服务器和其他配置。

2.4    管理服务器之间的Session状态。

本书中所讨论的所有的负载分配技术都是建立于于集群的多个应用服务器副本以及客户端请求可以连续的被不同的应用服务器所服务。

如果每一个客户端请求都完全不依赖于其他客户端请求，那么它就不用关心这两个请求是否是由同一个服务器来处理的。然而现实的情况，多数请求都不是完全独立的，通常是一个客户段发出请求等待结果，然后会根据结果发出更多的请求。

这些请求可以归为两类：

Ø        无状态的：服务器完全根据客户端请求自身的信息来处理请求，而不用记忆该请求之前的请求信息。换句话说服务器不用维护两个请求之间的状态信息。

Ø        有状态的：服务器依赖先前的请求信息来处理当前的请求。在无状态的交互情况下，不同的请求由不同的服务器来处理不会造成不良影响。然而在有状态的交互情况下，我们必须确保哪台服务器处理请求时访问了状态信息还要有那台服务器处理请求。为了访问的正确性要么有一台服务器处理所有统一客户端的请求要么在所有的服务器之间共享状态信息。在后一种情况下多数需要共享状态信息的请求都是由同一台机器来处理请求以减少共享状态在多台服务器之间复制。

2.4.1.    Http session和session管理工具

在一个http client和一个servlet交互的情况下，和一系列请求有关的状态信息都被保存在http session中，每个session都会有一个sessionID来标识。Servlet2.3规范中规定多有的用户请求在服务器创建了session之后必须访问同一台服务器。但是在集群化境中存在多个server可以同时提供服务，所有plug－in必须得到一个请求并决定由哪个服务器来处理它，session标识符被用来判断哪台服务器和web容器来找回session对象。

Session管理器模块是web容器的一部分，负责管理http session，提供session数据存储，分配session id，跟踪session id和每一个客户端的联系。

Session管理器提供session相关信息的存储，有三种存储方式：一是存储于应用服务器的内存中，不被其他的服务器所共享。其次存放于数据库中可以被所有的应用服务器所共享。最后采用memory－to－memory复制技术。

 

数据库存储

将信息存储于数据库中是一种集群成员访问session信息的方法。这种方式不论哪台服务器得到一个带有session id的请求，如果内存中没有都可以从后台数据库中得到session数据进而对该请求进行服务。如果这一选项没有起作用其他的集群机制也没有起作用，负载分配机制随机的分配请求到一台没有该session信息的服务器上，该服务器就无法获取session数据也就无法对该请求做出正确的服务。数据库方案的缺点和应用数据的缺点一样都造成一个单点故障，数据库单点故障可以通过硬件集群来解决入IBM HACMP，TSA或者是数据库复制技术。另一个缺点是点击性能，主要是由磁盘IO和网络通讯引起的。

 

MEMEORY－TO－MEMORY session复制

这种方式可以是应用服务器不用数据库也能共享session数据，它使用websphere内建的数据复制服务（TRS）来在集群成员之间复制内存的数据。采用这种方式可以消除数据库方式的单点故障。共享session数据可以通过创建共享复制域的方式来实现，创建时可以配置可以共享的web容器的数量。管理员可以定义域中的副本的个数。

这种方式和数据库一样也会导致性能问题，主要是应为过多的网络访问。此外由于副本贮存于应用服务器的内存中会引起jvm的heap的减少也会引起jvm的垃圾收集次数的增加。

 

提示：决定于你的应用和你的硬件资源，内存复制或者数据库方式对于你的环境来说或许是比较好的方案。具体信息见“WebSphere v6 scalability and performance hand book”

结论：采取数据库或者内存复制技术存储session信息对应用提供了一定程度的容错能力，如果一台应用服务器发生故障那么session数据或者保存于数据库或者保存于另外一台服务器的内存中，所以其他的服务器可以接管该请求以及与该session相关联的后继请求。你可以在2.5“Webcontainer clustering and failover“中找到更多详细信息。

2.4.2.    EJB sessions or transactions（用的较少不作翻译）

2.4.3.    Sever afinity（服务器偏好）

在以上的讨论中负载分配工具转发请求时并不是随意选择一个可用的服务器：

Ø        在有状态session bean或者实体bean驻留于交易上下文时只有一个可用的服务器。WML会总是转发请求到包含该bean的服务器实例。如果转发错误要么发生错误要么以更高的性能代价将请求转发到其他的服务器。

Ø        集群HTTP session或者实体bean交易之间的session，基础数据库必须保证任意服务器能够正确的处理每个请求，但是每次都要访问数据库代价是比较昂贵的，一个好的办法是通过服务器的数据库数据缓存来提高访问的性能，这样如果多个连续的请求被发送到同一个服务器，服务器可以从缓存中获取所需要的数据从而减少对基础数据库的过度访问。

 

我们应该认真考虑每一种负载分配工具的具体约束，他们通常被称为服务器偏好。负载均衡工具对于给定的请求需要识别多个服务器中哪个服务器是可用，同时要决定该请求应该发送到哪个特殊的服务器才能更好更高效的被处理。

我们在几种负载工具的讨论中会遇到服务器偏好这个概念，特别是我们会遇到session affinity（session偏好）这个概念，负载均衡工具会根据session偏好决定将同一session的请求发到同一台服务器。我们的讨论也会碰到tansaction affinity（交易偏好）的概念，服务器用于辨别是哪一个交易，其处理流程同session偏好类似。

一个特别的服务器偏好机制有可能导致系统更弱或者更强，在一个导致衰弱的偏好机制中大多数时间系统会试图加强期望偏好，但是并不能保证这样的偏好是期望的。在一个加强的偏好机制中，

2.5    Web容器的集群和容错

一个完整的WebSphere环境可以包括多个Web服务器实例和多个WebSpere应用服务器实例，每个Web服务器实例都被配制成运行WebServer插件。所有的集群成员可以配置在一个节点也可以分布于WebSphere cell的多个节点上（垂直和水平分布）。

每个请求进入WebServer都要经过Plug－in的处理，plug-in会根据自己的配置信息来决定哪个请求路由到那个WebSphere服务器，应用服务器和plug-in的通讯可以采用HTTP方式或者是HTTPS方式。Plug－in插件在集群成员之间分配请求。

Plug-in运行于webserver中，负责决定请求分配到那个Web容器中。它使用以下机制来作负载管理和系统容错。

Ø        应用服务器集群建立冗余的服务支持系统容错。集群内的所有服务器成员共同处理相同应用的请求或者不同应用的请求。

Ø        负载路由技术内建于Was的plug-in中，它控制客户端请求在冗余的服务器之间的络由，这种路由的基础是集群成员之间的权重。在没有session偏好的情况下，如果集群成员具有相同的权限，plug－in发送同样数目的请求到每个成员，如果权重不同，plug-in会发送更多请求到权重值比较大的服务器。

Ø        Session管理和容错机制为冗余的服务器交易处理提供session数据。

所以一个比较好的容错处理应该对三种机制都支持。

2.5.1.    Plug-in的Session管理和容错处理

Plug－in总是会把包含session数据的请求路由到上一请求的处理服务器上，但是如果服务器包含的session对于plug－in不可用，plug-in会把它路由到一个替代的服务器，替代服务器可以以数据库或者memory-to-memory的方式获取session数据。

有三种方式来决定用户的session到应用服务器的路由：cookie，URL重写以及sslID。实例2－1中现实一个sessionID的cookie包含四部分：

四位cache id（0000） sessionid（23位）分隔符（：） cloneID（8位）。

系统容错时，容错服务器的cloneID的被附加在最后以一个逗号分割，当原始的服务器变得可用时，请求被退回该请求由原始的服务器来处理。

图2－6将一步步向你展示plug－in如何进行容错处理。

如图2－6应用服务器容错时包含以下步骤：

1.        Plug－in处理A用户的请求转发到http://httpl/snoop.请求中包含一个session cookie，包含session id 和v544d031的cloneID。

2.        Plug－in会匹配虚拟主机和URI到集群wascluster01（包含wasmember01和wasmember03，配置在不同的机器上）

3.        Plug－In检查session偏好，并从session中查找V544d031。

4.        Plug-in从plug－in.xml中的列表中主服务器中匹配CloneID到wasmember01应用服务器

5.        Plugin检测wasmemeber01是否表示为可用，在我们的例子中它已经被标识为不可用。

6.        Plug－in会试图得到一个到wasmemeber01的流，当发现服务器没有响应时，Web1被标识为不可用并再次发起尝试。

7.        Plug－in检查再次检查session标识符。

8.        Plug－in检查servers。当交易可以到达wasmember01时，当它发现被标识为不可用并且重试次数不为0就跳过该服务器检查下一个服务器列表成员。

9.        Plug－in选择wasmember03（cloneID v544d0o0）并尝试获取一个流，plug－in要么打开一个流要么从现有的队列中获取一个。

10.    Wasmember03成功接收一个请求（从数据库和memeory中获取session数据）并把处理结果返回给用户A。

更多关于plug－in的容错处理细节请参照《IBM WebSphereV6部署和性能手册》第六章“WebSphere plug－in behavior”。

2.5.2.    Web容器错误

在一个集群的环境中，一个应用服务器错误并不意味着服务的中断，当plug－in已经选择了一个集群成员来处理请求时，它会尝试和该成员进行通讯。当plug－in无法和应用服务器通讯时会有好几种情形，当通讯不成功或者中断时，plug－in标识该成员不可用，并试图尝试其他成员来完成请求。Web容器错误的诊断是基于tcp应答以及plug－in请求的应答缺失。

集群成员被标识为不可用意味这该成员是否还作为负载管理和session偏好的一部分，plug－in将不再试图连接它，plug－in将视其为不可用并忽略它。

下面是plug－in连接失败时的一些情况

Ø        预期的应用服务器失败（集群在维护时主动停止）

Ø        非预期的应用服务器失败（应用服务器JVM瘫痪）

Ø        Plug－in和应用服务器之间的网络错误。

Ø        系统错误（不论是否是预期的），系统停机或者电源故障

Ø        集群成员超负荷不能处理请求（系统能力太低无法处理大量的客户请求，或者服务器的权重设置不合理）

在描述中的前两个情形中，web容器的运行的物理机器仍然运行，但是Inbound Chain已经不可用。当plug－in试图连接webcontainer处理请求时物理机器将拒绝服务并导致plug－in标识该应用服务器不可用。

第三和第四种情况物理机器已经不能提供任何的响应，在这种情况之下如果非阻塞的连接不能建立，plug-in将等待本地操作系统超时，然后将该服务器标识为不可用。在plug-in等待超时期间，所有发往服务器的请求将被挂起。Tcp超时的缺省值是由操作系统来设定的，这些值的设定可以在操作系统级别来设定，修改这些设定要倍加小心，错误的设置会引起应用服务器和其他网络应用的不可预知结果。这种问题可以采用非阻塞的连接予以解决。相关信息请见“connection timeout setting”

第五种情况，过载会引起健康的服务器变得不可用。通过定义httpserver的最大连接数可以避免机器的过载，在“Maximum number of connections” 中会给予详细的解释。

2.5.3.    Web server plug-in容错调整

Web server plug-in使用XML配置文件决定WebSphere cell服务的相关信息，有一些选项直接影响到plug－in在负载管理的环境中的工作。在v6中可以通过管理控制台来修改。相关的plugin标签如下：

你可以修改重试失败服务器连接的间隔时间。见“retry interval“

你可以为每个服务器添加connectTimeout属性。

你可以分配一天服务器到主服务器列表或者到备份服务器列表，这个特性从v5开始支持，也被称作是两层容错支持。

你可以修改plugin到服务器的最大连接数。这个值可以设置为0或者-1从而放开对连接数的限制，缺省值是－1。相关信息见“maximum number of conncetion”

 

重试间隔

在plug-in的配置文件中有一项设置允许你修改plug－in插件到不可用服务器的重试连接时间间隔，这项设置在避免不必要的尝试非常有用，缺省值是60秒，这意味着一但服务器被标识为不可用plug－in会每隔60秒尝试连接一次，如果你打开plug－in跟踪选项，在log文件中可以看到集群成员的重试时间间隔。

这项设置在每个webserver的配置的retry interval项下。修改间隔值路径为 servers->webservers->web server_Name->plugin properties->request routing.

 

查找正确的设置

还没有办法推荐一个规范的数值，具体的数值要视具体的环境而定，比如说集群环境中的成员数。

将重试间隔设置成较小的值可以让应用服务器在可用后更快的服务请求，然而设置过小会导致严重的性能问题，甚至导致你的plug－in停止服务，特别是存在机器损耗的情况下。

举例来说，你有几个集群成员如果其中一个不可用了而不会影响你的整个应用的性能，那么你可以很安全的将这项设置调大。相应的如果你的最优负载量已经计算出来的要所有的集群成员都要参与服务，并且你也没有更多的服务器加入那么你应该应该让集群成员更多的重试，重启服务器的时间也要考虑在内，如果你服务器花费较长的时间启动和装入应用那么你应该将重试时间设的大一点。

最优时间间隔的另一个因素是你操作系统的tcp/ip超时时间。为了解释这两个值之间的关系，让我们来看一下A机器和B机器的配置。每台机器都运行这两台集群的应用服务器（CM1、CM2在A机器上，CM3、CM4在B机器上）。HttpServer和plug－in都运行于Aix上，tcp超时设置为75秒重试时间设置为60秒，权重算法为round－robin。如果A机器发生故障，不论是预期还是非预期的，当一个请求发上来时会发生一下动作：

Plug－in从httpserver接收请求并决定负责处理的集群成员。

Plug－in决定将请求路由到A机器的CM1。

Plug－in尝试连接A机器的CM1，因为物理机器不可用。Plug－in在等到75秒tcpip超时只有判定CM1不可用。

Plug－in尝试将相同的请求路由到另一个集群成员A机器的CM2，因为A机器仍然故障，75秒后判定CM2也为不可用。

Plug－in根据算法尝试将相同的请求络由的B的CM3上，CM3在客户提交了150秒之后才成功的给出了应答，

 

连接超时设置

当一个集群成员的机器从网络中移出了（网线没有插上或者掉电了），plug－in在tcp/ip超时之前没有办法确定该集群成员的状态。修改timeout值不可避免的会引起不可预测的影响，比如说把这个值修改的低一点plug－in可以更快的进行容错，但是这一选项不但是发送请求使用（web服务器到app 服务器）而且接收请求也要使用，这意味这这一数值的修改也将影响客户到web服务器的连接，如果客户使用拨号或者其他的慢速设备，你的设置太低他们将无法连接上来。

为了解决这个问题，websphere v6提供了一个plug－in配置允许你修改Web服务器和应用服务器之间的连接超时时间，允许plug－in使用非阻塞的连接。配置这个选项，请到Application servers_>->WebServer plug-in properties.

将connect timeout 属性设置为0（缺省值）相当于没有设置，plug－in会以阻塞连接的方式处理请求直到操作系统的超时。将该值设置为一个大于0的整数值将决定plug－in到应用服务器的超时时间，比如将值设为10意味这plug－in将会等待10秒钟的超时时间。

 

寻找最优的超时设置

决定最优的超时设置取决于你的网络和服务器有躲开，网络测试应该考虑你的网络堵塞情况和网络内性能较弱服务器的使用。如果服务器未在网络超时之前给予应答，plug－in就会将该服务器标识为不可用。这项设置是应用服务器的属性所以每台服务器都可以单独设置。比如说你有一个系统包含四个集群成员，有两个成员在远程的节点上，网络堵塞时交易要花费较长的时间才能到达，这种情况下你就需要将集群成员设置成不同的连接超时时间。

如果使用非阻塞连接，你将会看到跟踪日志稍微有些不一样。

主服务器和备份服务器

从V5开始，websphere服务器实行了一个称作主服务器和备份服务器的新特性，当plugin－cfg.xml被生成时，所有的服务器都在PrimaryServer标签中初始化，服务器列表顺序就是plugin发送请求的顺序。

还有一个称之为BackupServer的可选标签，备份标签的服务器顺序是当PrimaryServer标签中的服务器发生错误时，plugin向备份server发送请求的顺序。

Plugin会根据session偏好以及服务器权重来分配交易请求，当主服务器没有发生故障时plugin是不会发送请求到备份服务器的，只有当所有的主服务器的所有的都不可用时，plugin将路由请求到备份服务器的可用服务器上。Plugin将逐一测试备份服务器直到交易成功。基于权重的round－robin算法在备份服务器上不会使用。

重点提示：在v6版本中只要partitionID逻辑不使用是，主服务器和备份服务器的方式才会使用，换句话说如果partition id加入，那么主从服务器的方式就不再使用了。有关于partition ID 参考 V6 scalability and performance handbook.。

 

你可以通过以下方式修改服务器成员的角色（主服务器或者从服务器），进入管理控制台。选择servers->application servers->->Web Server plug-in properties下拉选择服务器角色。

所有的主服务器和备份服务器都在ServerCluster标签中配置，如示例2－3所示

备份服务器列表只有在组服务器发生故障是才会使用。

 

最大连接数

Web容器可以同时处理多个请求，同时处理的请求数决定于最大可用线程数（10个线程意味着可以同时处理10个请求），但是一个请求并不代表一个用户请求(一个用户的请求可以有多个请求组成，用户在发出请求后浏览器可以发出多个请求。当连接到达web容器时，Inbound chain负责将请求转发到线程。如果连接超过线程的可用数，连接将存入backlog并等待空闲的线程。

如果连接成功正在等待web容器的可用线程处理，这是plug－in等待应答（客户端也是相同的情形），如果backlog满了plug－in将不再向该端口发送请求，类似于发生故障集群成员的处理。插件会跳过该集群成员并选择另外一个集群成员，因为plugin不再发送请求，集群服务器会减少它的连接backlog，plugin会定期的检查server的最大连接数，如果低于最低设置plugin就会再次发送请求。

每个应用服务器都可以设置不同的最大连接数。改变设置到Server->Application servers->AppserverName->Web Server plug-in properties.缺省的设置没有限制，设置成0或者－1也可以达到同样的效果，你可以任意的设置该值。例如两台运行IBM HTTP服务器的如果最大连接数设置成10那么潜在的处理能为20个连接。如果请求数达到应用服务器设置的上限，该服务器将不再被选为处理请求的对象，如果没有其他的可用服务器，插件将向用户返回503错误（服务不可用）。

通过压力测试工具（如：ApacheBench、Jmeter）可以观测到应用服务器满负荷的工作情况（查看plugin日志、Http 访问日志）。

为了测试以上情况我们将wasmember05的最大连接数配置成3，wasmember06的最大连接数配置为4，应用服务器之前配置一台http服务器，运行压力工具建立30个并发用户，使两台服务器的连接数达到最大，这时用户会得到503错误。

当plugin插件检测到没有可用的应用服务器来服务请求，http将返回503（服务不可用）错误。这个错误也会在http服务器的access日志中出现。

继续向下查找你会发现当两个server的backlog减少时，又恢复了服务。

这个特性可以使你更好的通过前端的plugin进行负载的均衡，如果应用服务器的负载过大，plugin会跳过该服务器选择选择并尝试可用的应用服务器。

一个好的解决方案是拥有一个能够处理所有负载的环境并且能该环境能够被正确的配置。这些设置包括与系统处理能力相适应的权重，集群成员能够拥有正确的负载，设置正确对的请求和连接队列。

2.6    EJB container clustering and failover

目前不用不做翻译。

2.7    备份集群支持

WebSphere v6支持映像集群，当主集群发生错误时，Ejb请求能够从从一个cell中的集群容错到另一cell中的备份集群。当主集群故障恢复后Fail back将自动使能主集群。

有一种情形使你自然的使用备份集群支持而不是其他的Ha方案，所有的方案都要处理IIOP通讯，请求发起方可能是servlet、java应用、客户端容器、或者其他通讯。把两个cells配置成映像的应用，当一个放生灾难是备份集群能够发挥作用。

在你使能备份集群支持之前，你需要在另外一个cell上建立备份的集群。备份集群应该和主集群具有相同的名字；发布相同的应用，具备相同的资源。备份主机的启动主机和端口决定了哪个cell包含备份集群。The backup cluster bootstrap host and port determine which cell contains the backup cluster.[u1] 

备份集群能够正常工作需要Deployment Managerers的运行以实现容错和Failback。在v6中，备份集群的通讯已经不再完全依赖Deployment Manager，尽管容错仍然依赖Deployment Manager（因为它存储着备份集群的位置），核心组和核心组桥允许备份集群通过多个桥进行通讯。

核心组桥服务被配置用于核心组之间的通讯，该服务用户主集群和备份集群的通讯。你可以在Deployment Manager、Node agent、应用服务器之间配置核心桥服务以预防单点通讯故障。一个集群只能拥有一个备份集群，主集群和备份集群要配置对方为failback对象。

2.7.1.    备份集群的运行行为

放生容错后如果主集群再次变为可用，镜像的备份集群尝试将请求failback到主集群，这种failback是自动的，为了让failback工作主集群要定义为备份集群的备份，换句话说两个集群要实现互备。

提示：镜像的集群容错不是cell和node agent级别的容错。大部分而言备份集群的支持依赖与Deployment Manager的运行并且仅仅限于集群级别。举例来说，如果主集群的整个cell发生故障停止服务，那么一个到主集群的新的客户请求将发生错误也不会发送到备份集群上，这是因为备份集群关心的信息无法从主集群cell中获得，换句话说如果主集群的cell Deployment Manager,Node Agent 和应用服务器停止服务，客户端已经直到备份集群从而可以发送请求到备份集群。

2.7.2.    方案以及配置描述

配置备份集群的主要步骤是添加备份集群设置和建立核心组桥。配置步骤如下：

1.        WebSphere cell和集群设置

2.        安全考虑。你需要导入和导出LTPA key以处理跨cell的安全保证。

3.        备份集群设置。

4.        核心组桥的配置（可选）。

我们使用 IBM Trade Performance Benchmark例子作为WebSphere备份集群应用服务的例子程序，你可以在以下网址下载该程序：

http://www.ibm.com/software/webservers/appserv/was/performance.html

表2－3列出了我们在例子中使用的配置包括：主机名、节点名、以及端口号。我们的域名为ibmredbook.com

2.8    WebSphere cell和集群设置

这一节我们将描述WebSphere集群配置。因为性能的原因我们不推荐将web和EJB分开部署，但是为了让我们的例子能够运行（需要分离的jvm环境），我分别部署Web和EJB模块于不同的集群。步骤如下：

1.        建立两个至少包含一个节点的cells

－cell名字：wascell02 and wascell03

2.        在每个cell中建立一个集群。两个集群需要有相同的名字，如果你应用的Web和EJB安装在分离的多个集群上，也同样创建相同的集群。

– Trade 6 EJB modules cluster: wascluster01

– Trade 6 Web modules cluster: wascluster02

提示：你可以使用trade.jacl脚本来创建集群和集群成员，该脚本在下一步中用来设置Trade 6的资源。我们设置好的分离的jvm环境可以通过管理台很容易的创建集群。The trade.jacl script. asks for cluster and cluster member names and only creates a new cluster and cluster members if they do not exist in the cell yet.

3．以configure选项运行trade.jacl脚本设置trande6的资源，在主cell和备份cell上运行该脚本。

提示: Follow the directions that are included in the Trade6 download package for setup and installation, or see Chapter8 of IBM WebSphere V6 Scalability and Performance Handbook, SG24-6392 for instructions on how to use the trade.jacl script

4．.通过管理控制台安装Trade6.注意以下问题：

在模块到server的映射步骤（Step2），映射EJB module到wascluster01 映射TrandeWeb到wascluster02

在EJB发布的步骤中确认在提供的选项中选择了正确的数据库。

映射EJB到beans的定义，更新EJB定义，这将联系安装在EJB集群上的EJBs，你必须更改ejb/Trade定义JNDI名字，该JNDI以jndi的全名绑定在TradeWeb模块内，比如：

cell/clusters//ejb/TradeEJB

在我们的环境中，正确的JNDI的全名是：

Cell/clusters/wascluster01/ejb/TradeEJB

所以你必须在ejb/Trande,ejb/Quote,ejb/LocalQuote,ejb/LocalAccountHome的设置开始处添加cell/clusters/wascluster01。

2.8.1.    安全考虑

如果你的应用需要在web模块和EJB模块之间考虑安全设置，通过以下步骤可以达到该目的。

查看所有cell机器的日期、时间以及时间区，主cell和备份cell的机器时间误差需要保持5分钟的以内。

Configure a user registry with an LDAP server,OS security,or a custom user registry.

1.        在主cell中，security->Global security.在Authentation项下，选择Authentation mechanisms->LTPA.在LTPA认证页输入一个LTPA密码，随后备份的集群中要用到该密码，所以一定要记住该密码。点击apply，保存更改。

2.        在LTPA的认证页面，在Key文件名输入域输入路径和文件名，点击Export Keys导出LTPA权限key，稍后它们将被导入到备份的cell中。

3.        Key file name: WebSphereKeys/primarycell.keys

4.        将LTPA key文件导入到备份的集群管理器的机器上。

5.        回到管理控制台，还是在LTPA认证页面，在Additional properties项下，选择Single signon(SSO)。输入一个正确的域名。

6.        配置所有的必须的安全选项。

7.        在全局安全配置页，勾选全局安全。保存并同步更改项。更改全局安全选项时要确保NodeAgent已经启动并且运行。

8.        重启主cell

9.        在备份的cell，配置相同的用户配置。

10.    在备份cell的管理控制台上进入Security->Global security。在Authentation项下的Authentation mechanisms->LTPA。在密码域和确认密码域输入主cell的密码，点击Apply保存设置。

11.    输入导出的LTPA key文件的路径和文件名，点击import。

如果密码错误，你会在WebSphere的控制台内看到错误信息，纠正密码点击Apply重复步骤。

12.    在同一面板的Additional Properties下选择Single signon（SSO），输入正确的域名（和主cell的一样）。Domain name:ibmredbook.com

13.    配置其他必要的安全选项。

14.    在全局安全配置页内，勾选enable global security，保存并同步你的更改。

15.    重启备份cell。

16.    安全token会在主cell和备份cell之间交换。

2.8.2.    备份集群配置

设置备份集群，你需要知道主机名、主cell和备份cell管理控制台启动端口。

1.        进入主cell的管理控制台，点击System administrator->Deployment amnager->ports，记录BOOTSTRAP_ADDRESS port 主机名和端口:

–Host: washost01.ibmredbook.com

–Port: 9809

2.        进入备份cell的管理控制台，点击System administration->Deployment manager->Ports 记录BOOTSTRAP_ADDRESS port 主机名和端口：

–Host: washost02.ibmredbook.com

–Port: 9810

3.        返回主cell的管理控制台。点击Servers->clusters->cluster_name->Backup cluster,确认备份集群的名字同主集群的名字相同。

提示如果使用分离的JVM环境，确认你已经修改了集群使之包含EJB模块。在我们的例子中，这个集群是wascluster01。

4.        点击Domain bootstrap address。输入你第二步记录下的主机名和端口，点击OK保存设置。

5.        返回备份的cell的管理控制台，点击Server->Clusters->Cluster_name->Backup cluster。

6.        点击Domain bootstrap address.指定第一步中记录的主机名和端口号，点击OK保存设置。

7.        重启两个集群。

The EJB clusters in the primary cell and backup cell should point to each other’s Deployment Manager in their backup cluster configuration. Also, refer to the InfoCenter article Creating backup clusters available at:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp

2.8.3.    核心组桥的配置

提示：v6.0.2中提供了一个补丁允许你不用核心组桥就能设置备份集群，这项配置功能同先前的版本相比，使用核心组桥时通讯不再像前一个版本那样单纯的依赖Deployment manager，通讯可以对等的通讯。

因为你正在设置备份集群，如果你不打算创建核心组桥，你可以跳过这一节。记住，为了让备份集群能够容错，Deployment manager必须运行。

如果你想使用核心组桥，两个cell都必须配置核心组桥。This requires access point groups and peer access points between one or more processes in each cell. 在我们的例子中，我们将按照一下步骤在Deployment manager和一个node agent之间配置桥点：

1．进入主cell控制台，Servers->core groups->core group bridge setting->access point groups->defaultAccessPointGroup->Core group access points.

2．在core group access point页，选择CGAP_1/DefaultCoreGroup 点击Show detail

3．在CGAP_1页，选择Bridge interface。

4．在Bridge interface页点击 NEW。

5．在Bridgeinterface下选择Deployment Manager wasdmgr02/dmgr/DCS 点击OK

6．在 the Bridge interfaces 页, 点击 New创建第二个 bridge interface.

7．在Bridge interface 菜单, 选择一个Node Agent (wasna01/nodeagent/DCS). 点击 OK.

8．保存你的设置

9．切换到备份cell的管理控制台进入到Servers ->Core groups ->Core group bridge settings ->Access point groups-> DefaultAccessPointGroup->Core group access points。

10．            在Core group access points 页, 选择 CGAP_1/DefaultCoreGroup, 点击 Show Detail.

11．            在CGAP_1 页, 选择 Bridge interfaces.

12．            在Bridge interfaces 页, 点击 New.

13．            在Bridge interface 菜单, 选择 Deployment Manager (wasdmgr03/dmgr/DCS). 点击OK。.

14．            点击 New创建第二个bridge interface.

15．            从Bridge interface 菜单, 选择一个 Node Agent (wasna01/nodeagent/DCS). 点击 OK.

16．            保存你的设置.

17．            收集主cell的以下信息:

a. Deployment Manager 的DCS端口。进入System administration->  Deployment manager-> Ports->DCS_UNICAST_ADDRESS. 记下该端口:

DCS_UNICAST_ADDRESS: 9352

 

b. wasna01 nodeagent 的DCS端口. 进入System administration->Node agents-> nodeagent->Ports->DCS_UNICAST_ADDRESS. 记下该端口。

DCS_UNICAST_ADDRESS: 9353

 

c.EJB所属的 core group 名字. 点击 Servers->Core groups->Core group settings. 选择你的core group (多数情况下是缺省的 DefaultCoreGroup), 然后选择Core group servers. 确认你服务器在所选的core group 服务器中。Core group: DefaultCoreGroup

d.cell的名字. 点击 System administration ->Cell. 记录cell名字: wascell02

e. core group access point 名字. 进入Servers ->Core groups->Core group bridge settings. 展开 DefaultAccessPointGroup. 展开步骤c中的core group我们的例子是展开DefaultCoreGroup. 记录Core Group Access Point:

Core Group Access Point: CGAP_1

18.在备份cell中记录相同的信息。:

a.Find the DCS port for the Deployment Manager on the backup cell. Go to

System administration  Deployment manager  Ports 

DCS_UNICAST_ADDRESS. Write down the port number:

DCS_UNICAST_ADDRESS: 9353

b.Find the DCS port for the wasna01 nodeagent on the backup cell. Go to

System administration  Node agents  nodeagent  Ports 

DCS_UNICAST_ADDRESS. Write down the port number:

DCS_UNICAST_ADDRESS: 9454

c.Find the name the of the core group that the EJB cluster belongs to in the cell. Click Servers  Core groups  Core group settings. Select your core group and select Core group servers. Verify that your servers are in the selected core group and write down the core group name:

Core group: DefaultCoreGroup

 

d.Find the name of the cell. Click System administration  Cell. Look at

the Name field:

Cell name: wascell03

e.Find the core group access point name. Go to Servers  Core groups 

Core group bridge settings. Expand DefaultAccessPointGroup.

Expand your core group as found in stepc on page95, in our case we

expand DefaultCoreGroup. Write down the value after Core Group

Access Point:

Core Group Access Point: CGAP_1

19.返回主cell的管理管理控制台建立一个指向备份cell的Access Group.进入 Servers ->Core groups->Core group bridge settings->Access point groups->DefaultAccessPointGroup->Peer access points.。 点击新建

20.在新建第一页，需要输入以下域值

 Name, Cell, Core group 和 Core group access point 。 输入收集的备份cell的信息

–Name: BackupCellGroup

– Cell: wascell03

– Core group: DefaultCoreGroup

– Core group access point: CGAP_1

点击next

21.第二页你需要输入Peer端口. 选择 Use peer ports, 然后输入备份cell的

Deployment Manager主机名字和DCS 端口:

–Host: washost02

–Port: 9353

点击下一步。

22.第三步确认新的 peer access point并点击完成.

23.为NodeAgent创建peer 端口.

24.在 Peer access points 页，选择刚创建的access point,

BackupCellGroup/wascell03/DefaultCoreGroup/CGAP_1, 点击 Show

Detail.

25.在 BackupCellGroup 页, 在Peer addressability box中选择Peer ports.

26.在Peer ports 页, 点击 New.

27.输入备份cellNode Agent 主机名和DCS 端口:

–Host: washost04

–Port: 9454

Click OK.

28.在主cell中保存设置.

29.Switch to the backup cell’s Administrative Console to create a peer access

group to point to the primary cell. Go to Servers  Core groups  Core

group bridge settings  Access point groups 

DefaultAccessPointGroup  Peer access points. Click New.

30.On the Create new peer access point, Step1 page, you need to enter values

into the Name, Cell, Core group and Core group access point fields. Enter any

desired name plus the information gathered for the primary cell:

–Name: PrimaryCellGroup

– Cell: wascell02

– Core group: DefaultCoreGroup

– Core group access point: CGAP_1

Click Next.

31.On the Step 2 page, you need to specify either a peer port or a proxy peer

access point. Select Use peer ports, then enter the primary cell’s

Deployment Manager host name and DCS port:

–Host: washost02

–Port: 9352

Click Next.

32.On the Step 3 page, confirm the new peer access point and click Finish.

33.Create a second peer port for the Node Agent.

On the Peer access points page, select the access point just created,

PrimaryCellGroup/wascell02/DefaultCoreGroup/CGAP_1, and click Show

Detail.

34.On the PrimaryCellGroup page, select Peer ports in the Peer addressability

box.

35.Click New.

36.Enter the primary cell’s Node Agent host name and DCS port:

–Host: washost02

–Port: 9353

Click OK.

37.Save the changes to the backup cell.

两个cell的核心组桥都配置完了，查看详细信息可以Servers->Core group bridge settings.展开DefaultAccessPointGroup所有的子项，你会看到所有的group名，主机名以及端口，如图2－12。你可以在两个cell中添加额外的核心组桥。更多的信息可以在InfoCente的文章《Configuring the core group bridge between core groups that are in the same cell and Configuring the core group bridge between core groups that are in different cells》中找到。

（这张图中实际是一条路线，Access point group为本地通讯服务代理，而Peer Access point为远程在本地的stub，个人理解。见第19步）

2.8.4.    测试备份集群配置

在Trade6中我们将TradeEJB的EJB模块和TradeWEb的web模块分离到两个集群中发布。在配置完备份集群支持和核心组桥服务之后，我们就可以运行一个简单的测试来检验我们的工作：

1.        启动所有主cell和备份cell中的集群。

2.        在主cell中的server上访问网站地址：

http://wascell02_server_name:9080/trade

3.        登录并买一些股票

4.        在主cell的管理控制台上停止EJB模块

5.        打开一个新的浏览器访问主cell服务器上的网址。

6.        登录并买一些股票。这个时候应该还可以成功，如果失败请见trouble shooting一节。

Additional tests include killing processes that you have assigned to be core group bridges. 只要还有一个核心组桥，就可以继续通讯，你可以kill掉主server或者关掉他们运行的机器只要运行Web模块的集群仍然健康，就不会死机。

为了测试failback，重启主服务器，停止备份的集群确保请求不再转发给它，如果Failback没有放生，检查主cell中的备份集群信息是否指向backup集群并且有一个核心组桥或者Deployment Manager是启动的。重新查看trouble shooting一节。

2.8.5.    Troubleshooting

一些TroublesShooting的提示：

Ø        backup集群配置最容易发生配置错误的是核心组桥。有几个设置项必须从其他集群来填写。再来看一次核心组桥的所有配置，Servers->Core group bridge setting，展开所有的defaultAccessPointGroup下所有所有栏目查看group 名字、主机名字、端口。从主cell和从cell较差对比检查对方机器的访问点信息。

Ø        在主cell和从cell中检查备份集群设置的主机名以及引导地址。再次确认caluster名字是一样的。

Ø        确认应用在备份集群上正确的进行了镜像。你也许要在相同的应用和配置下好要设置相同的资源。（如果没有使用相同的数据库，就要用镜像的资源）。

Ø        在没有failover机制下，主cell和从cell上应用是否工作。

Ø        检查两个cell的机器是否能够正常通讯，如果中间有防火墙，检查防火墙是否把WebSphere的相关端口已经打开。

Ø        如果主EJB集群down掉，尝试用新的客户端或者新开一个浏览器进行访问，新连接会访问备份的集群。

 

查看Logs

如果Failover没有发生，你可以在Web的日志或者客户端看到一个CORBA.NO_RESPONSE错误，如图2－14所示。

另外一个是CORBA.COMM_FAILURE错误，如图2－15所示。

如果你启动了核心组桥，又收到了这些信息，你需要检查一下你收到加入核心组桥的信息如2－16所示。如果没有收到这些信息，你需要检查一下核心组桥的配置。

 

安全

如果你哟安全相关的问题，检查以下相关项：

1.        应用服务器日志中的安全信息。

2.        在两个cell中有相同用户注册信息

3.        从主cell导出的LTPA token，在从cell中已经导入。

4.        在启动安全或者变更安全配置，cell是否同步和重启。

5.        两个cell的机器时间是否同步。

6.        应用装在一个单一的集群上，安全是否起作用。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24830066/viewspace-676941/，如需转载，请注明出处，否则将追究法律责任。