第一章 理解HA的概念

第一章 理解HA的概念

 

维护复杂环境下的高水平信息访问,没有丰富的用户经验,对任何IT组织都是一种挑战。这一章将介绍一些WebSphere的不同水平的端到端的高可靠性概念以及WebSphere高水平的方案计划。

1.1    过程高可靠性和数据高可靠性

可靠性包括两种：处理高可靠性和数据高可靠性。

在WebSphere中你可以碰到以下几种处理。

1.         WebSphere Deployment Manager process，WebSphere发布管理

2.         WebSphere Node Agent process(es)，WebSphere节点代理

3.         WebSphere Application Server process(es)，WebSphere应用服务器

4.         HTTP server process(es)，HTTP服务器

5.         Load Balancer process(es)，负载均衡

6.         Database server processes，数据库

7.         Firewall processes，防火墙

8.         LDAP server process(es)，目录服务器

9.         WebSphere MQ process(es)，WebSphereMQ

10.     Networked file system (for example NFS, AFS®) process，网络文件系统

11.     Operation system processes，操作系统

即使以上所有处理你都做到了高可靠性，WebSphere仍有可能因为数据的可靠性而面临失败，没有数据的可靠性WebSphere无法作任何有意义的工作。所以本书将对数据的可靠性作一个简短的讨论。

数据管理是websphere产品组的一个重要部分，被广泛的用于数据存储，如：

1.         Application data for the application servers. 应用服务器的应用数据。

2.         The administrative repository for the WebSphere administrative servers (in

3.         the form. of XML files). 管理服务器的数据存储。

4.         Persistent session data for WebSphere HTTP sessions if not using.http session的持久session数据

5.         memory-to-memory session replication.内存session复制。

6.         Persistent data for Entity EJBs.Ejb持久数据。

7.         The default messaging provider data store.缺省消息服务的数据存储。

8.         WebSphere security data for the LDAP servers.LDAP服务器的安全数据。

9.         Transaction log files and other log files.事务日志文件以及其他的日志文件

10.     WebSphere system and application binaries.WebSphere以及应用的二进制文件。

11.     HTML and image files.HTML文件以及图像文件

12.      

用集群作高可靠

集群是是实现高可靠性的一种基本方法。WAS v6提供内建的应用服务器集群和HAManger，用以保护单例服务。集群服务器提供独立的负载均衡管理器。详细的服务器集群和容错请见第二章，WebSphere服务器容错和恢复。另外，其他的集群技术也可以应用于WebSphere的端到端的系统高可靠性建设。WebSphere系统可以包含一个数据库，一个Ldap服务器，多套防火墙，一个缓存代理，一个或多个负载均衡，多个HttpServer ，多个应用服务器。更多信息请参考第十五章组件的高可靠性。数据访问是多数应用的一个重要部分，特别是交易系统。对于关键的交易为了达到99.X%的可靠性要求，我们需要将系统特殊性和应用特殊性集成到集群方案中。但是一个基于ip的数据库容错集群几分钟就可以完成。当使用WebSphere Nd版时，webshpere部件的错误不能归因于客户端请求错误数，因为websphere的容错处理是瞬时的。值得注意的是数据库集群的容错需要花费几分钟的时间。为了减少潜在的停机时间，可以使用平行的数据库服务器，Database Partitioning for DB2 UDB Enterprise Server Edition V8 或者Oracle Real Application Clusters(RAC)都提供了这样的功能。通常有两种方式的容错方法：

 

ü        基于IP的集群容错处理，IBM High Availability Cluster Multi-Processing for AIX® 5L™ (HACMP), IBM Tivoli System Automation (TSA), Sun Cluster, and VERITAS Cluster Server.都是基于这种技术。

ü        非IP的集群容错处理WebSphere WLM and WebSphere HAManager。

 

通常基于IP的集群容错处理要慢一些（1到5分钟），非IP集群处理非常快（瞬时的）。但是

Was6的HAManager 不需要额外的软件。大多数的非ip集群仍然依赖于集群软件，如HACMP, TSA, Sun Cluster, or VERITAS，集群软件提供集群信息。更多信息请见

第五章 使用额外的集群软件。

第九章 为第三方集群软件配置WebSphere。

第十一章 WebSphere和IBMHACMP

第十章 Tivoli自动化

第十二章 WebSphere veritas cluster Server

第十三章 WebSphere and Sun Cluster

 

1.2    高可靠性的定义

在我们讲解webshpere的不同级别的靠行性之前，我们首先需要对可靠性进行定义并且讨论以下如何测量高可靠性。可靠性是指系统正常服务时间的度量，就像是对系统down掉后系统恢复时间的度量。系统停机时间包括计划和非计划停机时间。

假设A是系统可用性的百分比指标，MTBF错误之间的平均处理时间，MTTR系统恢复的最大时间。这样我们就得到公式如下：

A=MTBF/(MTBF + MTTR)

当MTBF变大时，A会变大MTTR会对A的影响减小，当MTTR接近于零，A接近于100％。这意味着如果我们能从错误中快速恢复我们就能得到一个高可用系统。系统恢复时间包括错误诊断时间和错误恢复时间。所以集群软件使用错误诊断机制并且自动将服务容错到健康的主机，以减少错误诊断和系统恢复的时间。错误诊断时间的减少并且没有系统修复时间，MTTR也就被最小化了。所以A显著的增长了，任何坏节点的修复以及软、硬件的升级都不会影响服务的可用性。这就是所谓的热替换或者滚动升级。可用性并不像我们上面公式讨论的那么简单，首先，MTBF只是一个趋势，比如说假如一个cpu有一个500,000.00小时MTBF，这不以为着这个cpu只能用57年。实际上这个cup可能随时会down掉。第二，一个系统中会包含许多组件，每个组件都包含不同MTBF和MTTR，这些多样性使得系统的可用性不能使用上面的公式来预测。我们可以对Was6的高可用性建立一个模拟模型，该模型是以随机处理理论来建立的（例如：Markov chain），这样的topic超出了本书的范围。

由于Was的产品组包括更多的组件，可用性变得更复杂。比如：防火墙、负载均衡器、web服务器、应用服务器以及管理服务器（Node Agent和Deployment Manager），管理库，日志文件、回话持久数据库、应用数据库、ldap目录服务。系统的可用性取决于was环境的最容易出现问题的组件。通常冗余的硬件和集群软件被用来实现高可用性。我们的目标是通过HA技术减小MTTR，也就是说如果MTTR＝0，不管MTBF是多少A＝100％，用这种方法系统可用性变得可预测和可管理。

1.2.1.    可用性的级别

首先可用性和成本密切相关，就像图1－1所示，在成本和停机之间进行平衡很重要。通常你投资越多你的停机时间越小，所以你要评估一下was短暂的停机对你的损失，不同的业务有不同的停机成本，比如金融服务一小时的停机可能造成百万美元的损失。停机损失不仅包含直接损失。

冗余的硬件和集群软件可以提供较高的可用性。

我们将可用性分为以下几个级别：

1．基本系统：尽管定期的作备份，但是基本系统不部署任何的措施保护数据和服务，当故障发生支持人员从系统本分中恢复系统。

2．冗余数据。磁盘冗余和磁盘镜像被用于保护数据防止硬盘的损毁。全磁盘镜像比Raid－5提供更多的保护。

3．组件容错。作为基础设施，像websphere，通常会有很多组件，就像先前讨论的任何组件发生错误都会导致服务的中断。为实现可用性的目的可部署多线程多实例技术。例如如果你不没有部署防火墙的容错，你可能导致整个系统崩溃甚至更糟，可能会把整个系统暴露给黑客，尽管应用服务器是高可用的。WasND v6通过垂直部署的应用集群提供处理高可用性以及通过水平部署集群提供节点高可用性，数据的高可靠性对于交易系统是至关重要的。所以部件可用性的平时非常的重要，即不能在一个部件上投资过度也不能在另外一个部件上投资过度。

4．系统容错。如果主系统发生错误，备份系统就接管主系统。原则上任何类型的应用都可以通过系统容错技术做到高可用。但是如果软件是主机依赖的硬编码，容错技术就不能起作用了。系统容错，集群软件监控网络、硬件、以及软件的健康程度，诊断并且交流所有错误，自动的容错并把资源关联到健康的主机上。所以坏掉的系统恢复之前你仍然可以提供服务。

 

你可以将系统配置成active/active方式，或者active/passive方式。尽管active/active方式会增加硬件的使用同时也会增大中断的可能性，所以可用性会减弱。将单一组件纳入集群系统是没有效率的，你可以拥有一个防火墙集群、ladp集群、WebSphere集群、和数据库集群。

5．灾难恢复。这种方式采用不同的站点来备份主站点，当主站点因为灾难发生错误，备份站点会将变成营业站点。这种方式可以通过定期的手工数据备份或者以地理集群软件自动完成。

1.2.2.    可用矩阵

我们总在谈论健康时间，每个人都想要系统100％的健康。但是现实是100％健康系统是昂贵和难以实现的。对于一些应用平均每天14分钟的停机，99％的健康时间就足够了。对于有些应用需要99.9%或者更高健康时间。人们通常会将99％、99.9％、99.99％、99.999％简称2九、3九、4九、5九。5九是在合理成本内可达成的可用系统，许多提供商可以提供这样的方案。

ü         IBM with WebSphere WLM and clustering, WebSphere MQ Cluster, HACMP on AIX, TSA, or the Database Partitioning feature in DB2 UDB EnterpriseServer Edition

ü         _ Sun Microsystems with Sun Cluster on Solaris™

ü        _ VERITAS with VERITAS Cluster Server

在表中你可以看到，5九可用系统允许每天864毫秒、每周6秒、每年5.3分钟的的停机时间。对于所有的ip容错方式比如数据库通常要花费2到3分钟，这意味着MTTR为2.5分钟，所以如果要达成5九的可用性需要183天的MTBF，这意味着每年只有两次出错。

有些业务需要7×24×365可用性，有些需要6×20或者5×12的可用性。如果最后一种业务需要营业期间保持最小的中断时间，那么该业务不会减少对高可用性的需求。因为我们并不知道故障什么时候发生，即使该业务只需要5×12小时集群也需要保持最短的MTTR时间，保持最长的可用时间。

因此我们建议采用以下三种指标来描述可用性：

ü        系统健康时间百分比

ü        业务营业生活间和模式

ü        性能可用性的需求

为了满足营业时间的健康需求和性能的可用性你应该设计一个高可用性系统。绝大多数业务系统并不需要7×24小时，所以硬件和软件的升级可以安排在维护时间完成。为了提供7×24小时服务，集群技术可以通过手动从一个系统到另一个系统容错提供滚动升级（热替换）。

见 第四章 高可用性系统管理 第五章 高可用应用管理

1.2.3.    停机原因

停机的原因可以是可以预见事件也可以是不可预见事件。可预见的因素大概占停机原因的30％，就像前面提到的，滚动开发和热替换可以减少可预见的停机时间。但是最重要的问题是减少不可预见的停机时间，因为没有人知道非预见的事件什么时间发生并且所有业务都需要营业时间保持健康。

研究表明软件错误和人为错误是非预见因素停机的主要原因。软件错误包括网络软件错误、服务器软件错误、客户端软件错误。人为错误主要是因为技能缺乏，管理系统难以使用也是一个主要原因。尽管不像其他停机因素那么多，硬件错误和环境问题也会导致非预见的停机。采用LPAR的自优化资源调整、容量按需调整技术以及硬件冗余（减少单点故障），硬件错误可以大幅度减少。你可以在以下连接找到更多的关于Iseries和Pseries LPAR信息。

ü         _ Logical Partitions on the IBM PowerPC: A Guide to Working with LPAR on POWER5 for IBM Eserver i5 Servers, SG24-8000

ü        _ Advanced POWER Virtualization on IBM Eserver p5 Servers: Introduction and Basic Configuration, SG24-7940

以下连接有更多关于按需容量的信息

http://www.ibm.com/servers/eserver/about/cod/

很多环境问题和数据集中相关。仅仅作本地的standby系统是不够的，因为整个站点环境都有可能受到影响，地理集群和数据复制可以减少此类的环境问题。

端到端的websphere可靠系统可以消除所有的单点故障，不论是可预见还是不可预见的停机。我们将在这本书中描述可靠系统的实现。

表1－2 WebSphere可能的单点故障点

故障点	解决方案
客户端访问	多ISP
防火墙	防火墙集群，firewall sprayer，HA防火墙
缓存代理	备份缓存代理系统
Http负载均衡器（如WebSphere Edge component 负载均衡）	HA解决方案，入备份负载均衡服务器
Web服务器	基于网络多服务器、硬件集群
WebSphere配置数据、log文件	HA共享文件系统，网络文件系统、基于硬件的集群。
WebSphere应用服务器	WebSphere网络部署。 应用服务器集群： ü        水平 ü        垂直 ü        联合 EJB：备份CLUSTER
WebSphere node agent	集群中的多节点代理、OS服务、基于硬件的集群。 注意：节点代理在V6中不在作为单点故障。节点代理在该节点启动应用服务器时必须运行，应用服务器可以向服务定位进程注册（LSD），在WAS6中LSD是HA的，所以在V6中你只需要一个节点代理用以提供LSD服务。在更新与安全相关的配置时必须运行节点代理，否则你将再也无法通过Deployment manager进行同步。 更多信息请参见第三章 websphere管理错误。
WebSphere deployment manager	OS服务、基于硬件的集群、备份WebSphere cell。 在was v6中，DM不再看作是单点故障。你可以用它来配置was环境、监控性能、使用Tivoli性能监控观察器来监控系统性能
Eintity EJBS,application DB	高可靠dbs，平行db2 提示：确认你的应用能够catches StaleConnectionException and retries.请见574页15.4 “database Server” 查询更多的信息。
Default messageing provider 缺省的报文提供者	WebSphere application server clustering: HAManager provides failover. Websphere 应用集群：高可靠管理。
缺省的消息提供者数据存储	集群、数据复制、平行数据库
应用数据库	集群、数据复制、平行数据库
Session数据库	Memory-to-Memory数据复制，数据库集群、平行数据库
事务Logs	Was应用服务器集群：高可靠性容错，在平行的集群中共享文件系统。
WebSphere Mq	WebSphere Mq集群，websphere集权和clustering
LDAP	Master-replica,sprayer(喷射)，HA LDAP(集群)
Internal network	双中心网络，Dual internal networks.
Hubs	多个互联网络路径
Disk failure,disk bus failure,disk controller failure	磁盘镜像、raid－5，多总线、多磁盘控制器
Network service failure（DNS,ARP,DHCP,and so forth）	多网络服务
OS or other software crashes	集群，自动转发到健康的节点
Host dies（死机）	WAS集群，硬件集群：自动转发到健康节点
电源损坏	UPS，双电源系统
房间/地板灾难（着火、水淹等等）	将系统存放与不同的房屋、不同的楼层
建筑性灾难（着火、水淹、龙卷风 等等）	将系统存于不同的建筑
城市性灾难（地震，洪水等等）	远程镜像、系统复制、地理集群
区域性灾难	在地理集群或者远程集群存放数据中心
人为错误	员工培训、简化系统管理、使用集群以及冗余硬件软件
软件和硬件升级	通过集群会滚，或者WLM 7×24，可计划的维护

 

1.2.4.    Webpshere组件的高可靠性技术

正向你在表1－2中所看到，有许多不同的选择使你的WebShere系统达到高可靠。图1－3是对client层、DMZ、应用服务器（硬件错误或者前面提到的灾难不包含在内）可能的选择的图示。

提示：WebSphere MQ可部署于应用层或者EIS层，或者EIS和应用层都可以部署。

 

图1－4对EIS层提供了同样图示。该图提供的相同应用层以便于理解。

1.2.5.    Websphere系统高可靠性的层次

我们可以将WebSphere系统部署在冗余的硬件、软件、网络、处理器以及组件上。为了方便我们的讨论，我们硬性的将其划分几个层次。对其中一个层次的讨论也同样适用于其他更高层次。

提示：

1.        在webshpere HA level 1到4中没有展示DMZ。如果你想建立一个DMZ，我们建议你将HTTP server移到一个隔离系统中，不建议将HTTPSERVER和应用服务器放在一起。

2.        为了简单起见，我们没有将LDAP目录服务器放到LEVEL1到LEVEL4的图示中。你可以将你的LDAP放进系统中，或者添加一个单独的系统。

3.        对HA的四个层次我们都使用数据库。该数据库包含应用数据库、session数据、ME数据存储等等。所以一个数据库错误可以影响Websphere环境多个区域。Refer to the “possible single points of failure” section of each HA level for the list of data that can become a single point of failure for this configuration.

事务日志保存于文件系统中。当使用水平集群时（HA levels 3 或者更高），该文件系统应该是共享的文件系统，能够通过锁机制允许其他集群成员恢复一个错误的应用服务器事务。更多信息请见“WebSpheee System HA level 3 “ and 6.7 “transaction Manager high availability”

 

WebSphere System Ha level 1

如图1－5所示 websphere ha level1中HTTP SERVER、Was服务器、数据库服务器都安装在一个单独的系统中。只有一个应用服务器对用户请求进行服务，如果主机死机或者瘫痪了，所有的应用服务将变得不可用。任何一个部件的一个错误都会导致应用服务的不可用。

这一level用于用户开发或者用于对于停机无关紧要的网站。

该level包含以下单点故障：

Ø        http server

Ø        应用服务器

Ø        数据库服务器

Ø        防火墙、ldap（图中没有展示）

Ø        硬件，包括系统中任一硬件组件比如网卡、网线、电源等等

 

WebSphere System HA level 2

你可以创建一个集群（包含两个或者更多的集群成员）以避免应用服务器处理错误。应用服务器发生错误时，Hamanager确认错误服务器的事务日志已经被集群中的其他成员所恢复。所有的应用服务器都在同一个系统中，可以共享可用的磁盘空间，没有必要增加额外的硬件，比如SAN。

如果你的系统使用缺省的消息服务，HAManager也会确认消息引擎被其他的集群成员重新启动。

重要提示：你需要确认你的系统能够负担额外的应用服务器，比如额外的管理服务器（发布管理和节点代理）。参考“vertical scaling”获得更多信息。

可能的单点故障：

HTTP server

管理Server

数据库（应用数据、session数据）

防火墙、LDAP（没有在图中展示）

硬件

提示：使用memory-to-memory session复制技术代替数据库存储数据可以消除session数据的单点故障点。

参考第一章、第六章获取更多的信息

 

WebSphere system HA level 3

如图1－7所示，Level3包含一个负载均衡、多个HTTP Server、websphere垂直和水平分布、一个数据库服务器服务数据库、加上一个支持文件锁协议的共享的文件系统（该文件系统用于事务日志）。

提示：对于2PC来说，事务日志是唯一的一个问题点。如果你没有2pc事务你就不需要一个共享的文件系统。

对于上一个例子，当应用服务器的ME服务失败时，HAManager 会自动重启在另一个应用服务器上ME（消息服务器引擎）。

使用IBM WAS6网络部署版，你可以运行混合版本的ceslls，它允许你逐一的升级cells中的websphere应用服务器代码而不用中断服务。

另外你可以利用应用的rollout升级特性，它允许你升级一个应用而不用打断整个集群，它可以对节点逐一升级。这种升级先停掉一个节点的服务然后升级服务再重启应用服务器，然后重复下一个节点。所以，rollout升级只能应用于水平集群而不能应用于像LEVEL2那样的垂直集群方式。该项功能也不适用于所有类型的应用和环境，更多的信息请见5.4.2 “ROLLOUT update(was6的新特性)。

可能的单点故障：

Ø        HTTP 喷射器（例如：WebSphere 均衡负载服务器）

Ø        管理服务器

Ø        数据库服务器（应用数据、session数据）

Ø        防火墙、LDAP（图中没有展示）

Ø        硬件

重点提示：

因为HTTP Sprayer/Load balance 是整个系统的入口点，我们强烈建议使用高可靠性方式。一个节省成本和有效率的方案是在HTTPserver上创建一个备份的负载均衡。

图1－7显示一个基于共享文件系统的可恢复性事务日志的高级用法。如果你的文件系统不支持这种方式，你需要作下面的一个步骤：

Ø        使用自动、手动或者集群软件重新启动应用服务器。见第五部分，“Using external clustering software”

Ø        手动执行恢复

Ø        在事务日志中去锁功能；防止系统过载；network partitioning。

 

更多信息请见Transactional high availability and deployment

considerations in WebSphere Application Server V6 at:

http://www.ibm.com/developerworks/websphere/techjournal/0504_beaven/0504_be

aven.html

 

WebSphere system HA level 4

如图1－8所示的HA LEVEL4大部分的单点故障组件在该例子中都已经消除了。

Ø        就像早先提到的有一个备份的均衡负载服务器，备份的均衡负载服务器存放才其中一个HTTP SERVER上

Ø        有两个活动的HTTP Server

Ø        服务器部署联合水平和垂直方式，不论是处理错误还是硬件错误都能提供容错能力。

Ø        数据库（session 数据、ME数据、应用数据等等）能够通过数据库集群方式提供容错能力，如IBM HACMP，IBM TSA，Sun cluster，Veritas cluster Server等。

Ø        事务日志以数据库的形式存在于同一个系统中，但是实际上它们保存在一个基于锁机制的共享的文件系统中，可以被备份的数据库系统所复制，基于以上机制事务日志可以通过第二系统进行容错。

管理服务器（Node agent and deployment Manager）是唯一可能放生单点故障的部件。

一个Deployment Manager错误意味着你将无法使用tivoli performance view（包含在v6的管理控制台中）和改变配置，虽然在生产环境中很少这样作。Deployment Manager也需要通过集群功能作备份（更多内容见2.7 “backup cluster support”）。所以Deployment manager的一个临时错误对于生产环境来说通常不是一个大问题（有的客户在生产环境上甚至不使用Deployment Manager）.

一个简单的做法是在一个错误处理之后自动启动Deployment manager或者作为os服务的形式在系统启动是自动启动。更多信息见第三章“websphere adminitrative process failures“

Node agent的错误是一个稍微高级别的影响，3.3中会进行讨论。

请见第5部分“Using external clustering software” 有更多关于使用第三方集群软件的信息。那一章节将向你解释如何通过第三方软件使WebSphere达到高可用性。

重点提示：我们没有在这一级别的方案中图示DMZ和Ldap服务。如果你想你的系统环境中避免任何的单点故障，你应该记得要在系统中对DMZ和Ldap进行高可靠性建设。你将在第15章“WebSphere end to end high availability” 中找到更多关于该组件的HA方案。

这一级别的HA方案无法避免洪水、火灾、地震的损害。唯一的办法办法是HA level5中通过备份数据中心的方式达到以上保护目的。

 

WebSphere System HA Level 5

在WebSphere HA level5中两个数据中心被用于灾难恢复。如图1－9所示，一个数据中心存在于主服务站，另一个服务中心作备份。当主站发生故障，备份站点将视具体配置应答请求一个小时乃至几个小时。

重点提示：负载均衡和容错管理无法支持不同的cells，所以主站和备份站点的切换需要用户的干预。

备份数据中心以相同的配置存在于第二个ceslls，备份cells不服务任何请求。备份cells配置成相同的cslls 名字、node名字、cluster和应用服务器名字、同样的资源名字、相同应用部署等等，在系统中只有IP是不同的。当主数据中心无法服务时，DNS会变更至备份的环境中。

启动和运行备份系统可能要花费你几分钟的时间，时间的长短实际上依赖于你的设置，比如如果你的系统没有加电，那么加电会花费你更长的时间。另一个选择是保持系统的运行，但是软件并不启动。

最优的耗时最短的选择是热启动，这意味着你所有的系统和应用都启动并且运行，应服务器以应用日志和Mes无操作权限（NoOP）的方式启动，具体的信息请见第9章，“configuration websphere application server for external clustering software”.在这个例子中，为了能够改变DNS你需要作以下工作：

1.        Mount文件系统。

2.        发布一个脚本将事务日志和Mes的操作权限变更为常用权限。

在图1－9中图示了所有的环境，包括DMZ、LDAP服务器、WebSphereMQ等等。

 

重点提示：图中的一个方框并必然的表示一个系统（一组硬件）。多个组件可以存在于一个系统或者一台物理设备的不同Lpars上。

该方案有以下特点：

所有的防火墙都有备份

负载均衡都配有备份系统

有两个（或者更多的）Http Server

水平部署和垂直部署联合使用对处理错误和硬件错误提供容错能力

使用集群软件如IBM HACMP、IBM TSA,数据库可以通过第二系统进行容错，Mq和LDAP也能通过集群软件得以保护。

数据（Was管理库、session数据、事务日志、ME数据存储、应用数据、ＭＱ数据等）存储于ＳＡＮ系统中。所有数据都是一致数据组的一部分，一致数据组通过点对点的方式同步到备份的SAN系统中，PPRC（点对点数据复制）技术确保生产数据一致以备容错时使用。

Was二进制文件也被安装在ＳＡＮ中，但是需要进行数据同步，因为安装文件很少发生变动不用像事务日志和应用数据要保持数据同步。

 

提示：你可以使用FlashCopy功能将二进制文件备份于SAN系统中。使用这种方法允许你升级WebSphere到一个新的版本，如果你发现错误你可以回退到原有的版本。如果新的版本成功通过测试，你可以发布FlashCopy并确认你的备份的cesll是最新的，通过FalshCopy无需要安装新的补丁或者补丁。

 

Ø        LDAP数据也可以存储于SAN中并可以被同步到备份的SAN系统中，和WebSpher的二进制文件一样，LDAP数据也不建议被同步（很少放生变动），所以可以存储在同步数据组之外。

Ø        你可以在共享磁盘中增加跟踪日志，以便在放生错误时诊断错误。

1.2.6.    计划和评估你的WebSphere HA方案

我们建议你在规划WebSphere HA方案时遵循以下步骤

1.        分析你的需求。

－你需要持续的营业吗？大多数客户不需要持续的营业，所以硬件和软件的升级可以在离线的状态下完成。

－在营业状态下你需要哪种类型的可用性。

－在发生故障时你需要怎样的性能需求？比如在一个节点或者服务器发生故障时只有少数的节点和服务器可以服务用户端的请求，

2.        分析成本因素。在你发生灾难时你会损失多少、你准本投资多少到你的系统可用性上?如果停机是有成本的你准备投资多少以提高你的系统可用性。

3.        估计你的设置和管理复杂度。复杂的系统就需要更多高技能人员和更多的管理工作。

4.        考虑整个WebSphere系统中所有的组件。通常整个WebSphere系统的可靠性决定于整个WebSphere系统链条中的某个薄弱环节。考虑每个组件发生错误的可能性，评估其容错时间。

5.        分析容错时间。包括主要的错误诊断时间和恢复时间。对于不同的容错机制和技术，容错时间是不同的。

6.        分析事发地点，也就是发生故障你进行恢复的地方。它直接关系到恢复运行期间你的工作量的大小。

7.        理解程序模型。这关系到容错对于客户和其他组件来说在整个WebSphere系统中是否是透明的。有些服务因为从应用中做了屏蔽，因而有能力执行透明的容错，其他服务可以添加代码在发生错误必要的情况下执行重试。

8.        对于给定的错误通常会有多个解决方案。有的解决方案会有比较特殊的限制，分析不同的方案之间的不同点。

1.3    容错术语和机制

就像前面提到的，一个对象或者一个应用包括两个比较清楚的方面：功能和数据。所以可靠性包括处理可靠性和数据可靠性。一个应用如果没有和私有数据和状态相关联，那么如果发生错误就可以通过简单的重启应用的方式来达到高可靠性。然而现实是功能都会和私有数据和状态关联，通常会固化数据于数据库或者文件中，比如像EJB。我们必须保证数据管理系统对所有的处理的高可靠性，以确保数据的可靠性，因为错误的处理会损坏数据。

 

人们会使用容错这个术语来表述不同容错和不同的容错机制，我们有必要对以下的容错机制做一个澄清：

Ø        Failover

Ø        Fail back，fallback

Ø        Fail fast

Ø        Fail transparent

 

Failover

容错是指一个集群中处理可以从主系统移动到备份系统中。一个容错处理在诊断后会耗时几分钟。这种方法可以应用于功能集中或者数据集中的系统应用，不论是主动/被动方式配置的应用，还是主动/主动方式配置的应用。你也可以采用相互容错机制，这意味着两台主机运行不同应用，可以相互向对方提供容错。

Fail back,fallback

Fail back和fallback对failover来说很行，但它发生于主系统恢复正常后，从备份系统向主系统切换。对于相互容错系统来说，因为备份节点也有自己的原始应用在运行，failing back 将会提高两方应用的性能。

 

提示：有关于failover和failback更多的信息请见第九章“configuring WebSphere Application Server for external clustering software”

 

Fail fast

Fail fast指的是一对不协调的服务。如图1－10所示，备份的服务是pre-existent。

注意以下几个关键点：

Ø        所有交易都属于同一个应用

Ø        所有交易都不是协调一致的，换句话说所有的交易都不知道其他交易的状态。

Ø        所有交易都是主机预先存在的，和failover的情形不同。Failover是原始交易发生错误后由新启动的交易接管其资源。

Ø        这些交易不会从其他交易中接管资源。

就像前面提到的，fail fast交易不能用于数据集中类型的交易。它依赖于1－n的映射（就像喷头）来处理客户端的阻塞和处理错误。调整connection和tcp/ip的超时时间是这种容错性能的关键,你需要平衡平常运行性能和容错性能,缩短connection和tcp/ip超时时间可以提高容错的性能，但是会危及到平常的运行性能。

对于你的http server、Caching Proxies，目录服务器等等组件来说，Fail fast是一个比较好的方案，它不仅提供高可靠性同时确保服务器的性能和稳定。更多信息请见第15章“webSphere end－to－end high availability”

 

Fail transparent

Fail transparent被定义为一对协调的处理：我们拥有一个主交易和一个备份交易运行在两个分离的处理器上，见图1－11。主交易会发送一个检查点给备份交易，假如主交易失败备份交易将接管处理。这种机制的原理是备份交易参与主交易的失败处理，接管交易的同时不影响既有处理步骤和用户session。这种办法需要每一个交易都知道另外一个交易的处理状态以及环境状态。所以需要一个集群管理层参与管理，应用可以从集群管理层查询交易的状态，换句话说交易是被协调的，错误被透明的处理。

总结：

总之，我们有三种方法达到高可靠性：

Ø        交易和依赖资源组的接管

这种方法需要集群信息，能应用于数据集中和服务集中两种应用，这种实现比较困难。

Ø        多个非协调交易处理

这种方法不需要集群信息，但是这种方法不能应用于数据集中的应用，因为它不支持资源组的概念。

 Ø    多个协调交易

这种方法需要集群信息，实现起来非常困难。可以用于数据集中和服务集中两种应用，它可以非中断的方式透明的实现容错。

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

转载于:http://blog.itpub.net/24830066/viewspace-676932/