IBM PureApplication System 的高可用性拓扑结构

客户针对 IBM® PureApplication System 常提出的问题是,“如何设置它以实现高可用性”。本文将提供有关此主题的概述和建议。

Kyle Brown, 杰出工程师, IBM

Kyle Brown 的照片Kyle Brown 是 IBM Software Services for WebSphere 的一名杰出工程师,精通 SOA 和各种新兴技术。Kyle 为 Fortune 500 客户提供关于 SOA、面向对象的主题和 J2EE 技术方面的咨询服务、教育和指导。他是 Java Programming with IBM WebSpherePersistence in the Enterprise 的合著者。他还经常在 SOA、Enterprise Java、OO 设计和设计模式的主题会议上发言。


developerWorks 专家作者

Andre Tost, 高级技术员, IBM

Andre Tost 的照片Andre Tost 是 IBM Software Services for WebSphere 组织的高级技术员,他帮助 IBM 客户建立面向服务的架构。他尤其关注 Web 服务和 Enterprise Service Bus 技术。在担任目前的职位以前,他在 IBM 软件开发方面担任过各种合作伙伴支持、开发和架构师角色,最近还从事过 WebSphere Business Development 小组的工作。Andre 出生在德国,现在居住在明尼苏达的罗彻斯特。在闲暇时间,他喜欢与家人在一起,喜欢踢足球和看足球比赛。


developerWorks 大师作者

Rohith Ashok, 高级技术研究员, IBM

Rohith Ashok 的照片Rohith Ashok 是 IBM Software Group 的一名首席架构师,主要从事于 PureApplication System 和 PureSystems 产品系列的工作。在研究集成系统之前,Rohith 主要是研究 IBM Workload Deployer 和 WebSphere Cloudburst Appliance。他花了 10 年时间研究了各个系统,从 zSeries 到 Power 系统,再到高度集成的系统。在业余时间里,Rohith 喜欢陪伴在家人身边,观看技术在日常生活中的应用。



2012 年 8 月 13 日

简介

我们从客户那里最常听到有关于 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 管理员在某种程度上进行手动干预。不同组件需要的手动干预量不同。

需要检查两种不同的场景:

  1. 第一种场景在数据中心内,我们在其中尝试跨两个(或者可能更多)PureApplication System 机架提供 HA。
  2. 第二种场景跨越两个在地域上分散的数据中心。

数据中心内

在第一种场景中,您要避免的是整个 PureApplication System 发生故障。由于机架中的所有组件都具有冗余性,所以发生此情况的可能性很小。但是,这么做的合理性还有其他原因,比如可能很快产生无法承受一个机架(甚至一个高性能机架)流量的情形。图 1 显示了您希望实现的最终系统配置。

图 1. DC 中一个具有单一共享单元的 HA 配置
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 单元
两个主动-主动 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)的方法。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, Cloud computing
ArticleID=830200
ArticleTitle=IBM PureApplication System 的高可用性拓扑结构
publish-date=08132012