![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
我们从客户那里最常听到有关于 IBM PureApplication System 的问题是 “如何设置它以实现高可用性”。本文简短介绍了此主题并提供了一些建议。请注意，本文未 涉及与 持续可用性 相关的问题。这些问题较为复杂，我们将在以后分别对其进行介绍。此外，我们仅考虑构建于 WebSphere® Application Server（以下简称 Application Server）和 DB2® 之上的虚拟系统的高可用性 (HA) 情形。未来的文章将针对虚拟应用程序的 HA 情形进行介绍，尤其是机架内情形和其他 IBM 中间件选项，比如 WebSphere MQ 和 WebSphere Message Broker。
请注意，这是一篇介绍性文章，主要介绍所描述问题的总体解决方案。在未来的一些文章将提供有关实现本文所述的可用性级别的详细示例。
我们需要考虑两个可实现高可用性的机制。第一个是机架内 机制，这些机制内置于 PureApplication System 的固件和硬件中。管理环境本身在机架内也是冗余的，因为每个 PureApplication System 设备包含两个管理节点，其中一个节点是另一个节点的备份。
PureApplication System 经过了谨慎设计，以避免 在每个机架中引入任何单一故障点。因此，如果考虑这样的 WebSphere 和 DB2 虚拟系统，它有多个完全运行于机架内的 WebSphere Application Server 成员，则此内置于机架中的冗余性会帮助您避免计算节点、硬盘驱动器或者甚至是机架顶部 (TOR) 交换机等任何硬件所引起的故障。如果一个计算节点发生故障，则 WebSphere HTTP Server 插件本身会注意到，因为在它之上运行的 JVM 将消失，并且所有流量将无缝地重新路由到其他集群成员。
接着，PureApplication System 本身会注意到该计算节点关闭，并将虚拟机转移到同一个云组中的另一个计算节点，该节点最终会通过插件重新联结到集群中并再次开始接受流量。类似地，如果有一个完全内置于机架中的 DB2 HA/DR 系统，并且主要数据库发生故障，则系统会开始无缝地将请求定向到备份数据库。最后，PureApplication System 的放置算法非常聪明，它在大部分情况下都会尽力避免将两个集群成员放在一个计算节点上，只要云组的配置和云组中的计算资源可用性允许这么做即可。
这些机制可能满足了所有故障转移需求的 90%。但是，尽管这一比例很高，但对我们的许多客户而言，这还不足以涵盖它们所说的 “HA”。他们具体指的是机架间 机制，如何应对由于某种灾难性故障导致的整个机架崩溃（例如，当水冷门中的管道发生故障，并将水喷得满机架都是时）？这时可以再次利用 WebSphere、DB2 和 IBM Workload Deployer 中的标准工具来提供这一级别的高可用性。
您能做的是，首先使用标准 DB2 HADR 模式在一个机架上设置一个主要数据库，在另一个机架上设置备份数据库。这提供了处理数据库请求的能力，甚至是在主要数据库由于机架内某一个硬件故障（一个计算节点故障）或整个机架故障（损坏的管道示例）而发生故障时。同样地，您可以利用 Application Server 中的传统 HA 机制来提供两种不同的故障转移机制。既可在 “第二个” 机架中创建 Application Server 实例并将它们与 “第一个” 机架中的 Deployment Manager (DMgr) 联合起来，您也可以创建两个独立的单元（每个机架一个）并在机架外部管理单元之间的负载分配（比如一个使用 Application Optimization 负载平衡功能的外部 DataPower 设备）。所有这些机制将需要创建系统的 PureApplication System 管理员在某种程度上进行手动干预。不同组件需要的手动干预量不同。
需要检查两种不同的场景：
- 第一种场景在数据中心内，我们在其中尝试跨两个（或者可能更多）PureApplication System 机架提供 HA。
- 第二种场景跨越两个在地域上分散的数据中心。
在第一种场景中，您要避免的是整个 PureApplication System 发生故障。由于机架中的所有组件都具有冗余性，所以发生此情况的可能性很小。但是，这么做的合理性还有其他原因，比如可能很快产生无法承受一个机架（甚至一个高性能机架）流量的情形。图 1 显示了您希望实现的最终系统配置。
图 1. DC 中一个具有单一共享单元的 HA 配置
在此场景中（称为 “单个单元” 模型），首先在第一个机架（图 1 中的 IPAS A）中创建一个虚拟系统模式来定义一个单元，该单元包含一个 DMgr、IBM HTTP Server (IHS) 节点和 WebSphere Application Server 节点。然后在 IPAS Rack B 上创建第二个虚拟系统模式，该模式仅包含了 IHS 节点和您随后需要手动关联到您之前创建单元的 WebSphere Application Server 节点中。这定义了跨越两个机器的单元边界，如图 1 所示。同样地，为 IPAS A 中的主要 DB2 HADR 节点创建一个虚拟系统模式，并且为 IPAS B 中的辅助 DB2 HADR 节点创建第二个虚拟系统模式。请注意，为了让此配置生效，您需要配置一个外部负载平衡器来了解两个机架中的所有 IHS 实例。您还需要考虑跨两个机架的 HTTP 会话管理。此方法中最简单的情形是在共享数据库中启用数据库会话持久性。
在此配置中，您现在能容忍两个机架其中一个完全崩溃。如果机架 A 崩溃，那么机架 B 上的 IHS 实例和 WebSphere Application Server 节点会继续从外部负载平衡器获取请求，DB2 HADR 辅助节点接管发生故障的主要节点的工作。惟一损失的功能是将更改部署到机架 B 上集群成员的能力，因为 DMgr 不再可用。如果机架 B 发生故障，那么机架 A 会继续正常运行，像平常一样从外部负载平衡器获取请求。
在地域上分散的两个 PureApplication System 机架的情形更加复杂。在此场景中（我们将称之为 “双单元” 模型），您需要使用一个共享数据库创建至少两个不同的单元，如图 2 所示。
可以通过共享数据库跨两个单元使用 HTTP 会话复制，但很少这么做。在大部分情况下，会话亲缘性在外部负载平衡器中配置。换句话说，在特定单元中启动的会话请求始终会路由到该单元。如果可容忍在故障转移时丢失会话数据，则您可设置一个独立的本地数据库来实现会话持久性。
图 2. 两个主动-主动 WebSphere 单元
请注意此单元的配置，如图 2 所示。在此场景中，您在每个 PureApplication System 中创建独立但却相同的单元。前面已提到，单元边界完全包含在每个系统中。这样，WebSphere 单元在一种主动-主动模式中进行配置，但 DB2 HADR 数据库是在一种主动-被动模式中进行配置（就像前面的场景一样）。这里的区别在于，单元彼此独立。两个机架的 WebSphere Application Server 节点之间没有通信。
或许实现此方法的最简单方式是使用 IPAS A 中的一个虚拟系统创建第一个单元，导出该虚拟系统模式并将它导入 IPAS B 中，最后在 IPAS B 中创建该模式的一个新实例。同样地，您需要使用 IPAS A 中的一个虚拟系统模式创建一个 DB2 HADR 主要节点，然后像前一个示例一样，使用 IPAS B 中的另一个虚拟系统模式创建它的辅助节点。在此情形下，设置外部负载平衡器来再次将流量提供给两个单元中的所有 IHS 实例。如果一个机架完全崩溃，那么另一个机架会无中断地继续接受流量。
您希望在此示例中创建两个单元，而不是像前一个示例一样将所有示例联接到一个单元中，其第一个原因在于您一般不希望将一个集群成员与其 DMgr 在地域上分散。DMgr 与其集群成员（用于管理和代码分配等）之间的必要通信无法通过广域网有效提供，所以我们不建议将跨越长距离连锁单元作为一种最佳实践。
在单个单元场景中，所有 WebSphere 服务器实例从一个中央位置进行管理。也就是说，有一个 Deployment Manager，还有一个管理控制台来将更改应用到跨两个机架的环境中。而且，两个机架上的 IHS 插件提供了更多负载平衡和服务器亲缘性设置，可确保资源得到有效利用。在本质上，您使用两个独立机架的事实对您的 WebSphere 设置是透明的。
但是，这些好处的代价是更复杂的初始设置。机架 B 上的节点是通过独立的模式进行配置，该模式将它们连接到机架 A 上的 DMgr。所有这些 IHS 实例必须配置到外部负载平衡器中，并且在机架上创建和启动新 IHS 实例时必须重复执行该步骤。另外，从虚拟系统的角度讲，您有两个不同的虚拟系统，每个机架上一个，并且所有需要的更改都必须（最好是同时）应用到两个机架上。最后，机架之间还有一个额外的（最好是非常快的）网络层，这增加了成本，举例而言需要从第二个机架调用第一个机架上的数据库，或者在一个机架上的 IHS 节点与另一个机架上的集群成员 JVM 之间的传递请求，或者在 DMgr 与第二个机架上的各个节点代理之间通信。但是再一次假设您已在两个机架之间建立了非常快的网络连接，所以此开销是可容忍的。
在双单元场景中，设置较简单。事实上，您可以在一个数据中心轻松执行此场景。无论是从 WebSphere 管理控制台角度，还是从 PureApplication System 管理角度看，两个单元都独立管理。例如，这意味着您可充分利用 PureApplication System 机制，比如路由和扩展策略，而无需考虑跨机架影响。这允许在每个机架上部署相同的模式，每种模式利用不同的 IP 地址。
与此同时，存在一个不足，那就是所有管理性更改都需要通过两个不同的控制台对两个 WebSphere 单元执行。您需要手动配置外部负载平衡器，就像第一种场景中一样。而且在两种场景中，任何给定的时刻只有一个数据库服务器是活动的，这意味着第二个包含辅助数据库的机架上至少有部分资源未在正常操作条件下使用。
本文介绍了如何使用单个单元或双单元方法在一个数据中心间环境中的 WebSphere Application Server 和 DB2 应用程序中实现高可用性，以及如何使用双单元方法在数据中心内环境中实现高可用性。
请注意，可以执行其他配置，尤其是在有多于两个机架的情形中。例如，可为每个数据中心配置两个机架，在每个机架上定义一个单元，总共得到 4 个单元。或者可为每个机架定义多于一个单元。而且，您的单元内可以有不同数量的集群。
但是，所有这些情形都可使用非 PureApplication 环境中使用的相同步骤和最佳实践。我们只是添加了一些在运行 PureApplication System 时适用的注意事项，并且在该上下文中，上述场景包含了这些替代的设置。我们特意未介绍的一个场景是跨两个数据中心运行一个 WebSphere 单元，因为我们强烈反对这么做。
尽管我们讨论的示例仅限于 WebSphere Application Server 和 DB2 应用程序，但您可以一种有限的方式将这些方法推广到其他产品配置上。未来的文章中将探讨用于其他企业解决方案（比如 WebSphere MQ 和 WebSphere Message Broker）的方法。
学习
-
Maintain continuous availability while updating WebSphere Application
Server enterprise applications
-
高可用性（重申）与持续可用性
-
IBM PureSystems 主页
-
IBM PureSystems 中心
-
developerWorks 上的 IBM PureSystems 资源
-
IBM 红皮书：IBM PureSystems 概述
-
IBM developerWorks 中国 WebSphere 专区：为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库，包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。
获得产品和技术
-
试用：试用 IBM
PureSystems
- 最受欢迎的 WebSphere 试用软件下载：下载关键 WebSphere 产品的免费试用版。
- IBM developerWorks 软件下载资源中心：IBM deveperWorks 最新的软件下载。
- IBM developerWorks 工具包：下载关键 WebSphere 最新的产品工具包。
讨论
- 加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
- 加入 IBM 软件下载与技术交流群组，参与在线交流。
Kyle Brown 是 IBM Software Services for WebSphere 的一名杰出工程师，精通 SOA 和各种新兴技术。Kyle 为 Fortune 500 客户提供关于 SOA、面向对象的主题和 J2EE 技术方面的咨询服务、教育和指导。他是 Java Programming with IBM WebSphere 和 Persistence in the Enterprise 的合著者。他还经常在 SOA、Enterprise Java、OO 设计和设计模式的主题会议上发言。
