使用 WebSphere Application Server V8.5 的动态集群功能提高资源利用率并改善性能

引言

随着业务规模的增长，现代企业的 IT 系统部署着越来越多的应用。每个应用对计算资源有着不同的需求，并且在不同时间有不同的访问量。如何建立灵活的基础架构，根据各个应用的需求来动态分配资源，有效提高资源利用率，是企业面临的重大挑战。

WebSphere Application Server V8.5 中整合了智能管理（Intelligent Management）组件，该组件也就是以前版本中称为 WebSphere Virtual Enterprise 或 WebSphere Extended Deployment 的产品。它为中间件服务器（WebSphere Application Server 或 Oracle WebLogic Server 等）提供了完整的应用基础架构虚拟化平台，使得企业能够灵活、动态地适应业务需求的变化。

动态集群（Dynamic Cluster）是其中的重要功能。它是一种虚拟化的集群技术，能根据请求负载的变化，在不同集群间自动进行资源分配，从而提高计算资源的利用率并改善应用的性能。本文将介绍动态集群及相关功能的使用场景。

回页首

传统应用基础架构的局限性

在传统的 IT 应用基础架构中，为了减少单点故障并实现资源的高可用性，企业通常会将一组服务器节点集中起来作为集群，将应用部署在集群上。这种集群可以称为静态集群，因为它的规模是创建的时候就确定好的。这种架构带来了一个问题，就是很难找到合理的方式划分每个集群的大小，利用有限的资源满足全部应用需求。

通常情况下，每个应用对计算资源的需求，是随着时间和访问量的变化而变化的，各有各的忙闲时间。我们考虑图 1 所示的场景：数据中心里划分了三个集群，每个集群上部署的应用，在不同时间的访问量有很大差异。由于架构的限制，虽然数据中心的整体资源利用率并未饱和，但每个时间都有某个集群不堪重负，无法满足全部应用的需求。该问题的根本原因，不是计算资源不足，而是不同集群之间无法共享资源来取长补短，造成总体资源利用率低下。

图 1. 传统的数据中心


现代企业需要建立更灵活的基础架构来解决这样的问题。动态集群就是为此而诞生的。

回页首

利用动态集群提高资源利用率和应用的性能

动态集群的工作原理和优势

与传统的静态集群不同，动态集群是一种虚拟化的集群。它允许用户将一组服务器节点组成一个称为节点组（Node Group）的资源池。用户在资源池中创建动态集群并部署应用。这种方式将应用与物理基础架构完全分开，应用不再被固定部署到集群里的某些节点上。动态集群会根据应用的访问情况，判断它的资源需求，自动启动（或停止）该集群中更多的服务器来运行该应用，从而允许应用在资源池中动态放置并随时迁移工作负载，适应业务需求。通过这种不同集群间共享并自动分配资源的方式，动态集群能够提高计算资源的利用率，从而改善应用的整体性能。

我们将上面场景中的数据中心重新构建，创建三个动态集群，如图 2 所示。它们会自动根据每个时刻各自的资源需求，来协调资源在各个节点组（资源池）中的分配，提高资源利用率。

图 2. 用动态集群构建的数据中心

典型场景性能比较

本节我们建立了一个有四台服务器（四个节点）的数据中心，在上面分别采用静态集群和动态集群，各部署两个 web 应用，在不同压力负载下对比它们的响应速度。

首先我们建立两个静态集群，各自横跨两个不同的节点。其中一个集群部署名为 DayTrader 的应用，另一个部署名为 veApp 的应用。在集群前面用 IHS（IBM HTTP Server）作为访问这些应用的 web 服务器。

图 3. 测试场景拓扑结构 – 静态集群


启动压力测试，模拟其中一个应用负载较重（忙时），而另一个负载较轻（闲时）的情况，得到以下结果。负载较重的应用性能下降很大。

表 1. 静态集群响应时间 – DayTrader 应用忙时

应用	并发用户数	平均响应时间（毫秒）
DayTrader	100	5131
veApp	10	12

表 2. 静态集群响应时间 – veApp 应用忙时

应用	并发用户数	平均响应时间（毫秒）
DayTrader	10	1152
veApp	200	238.1

之后我们将全部四个节点加入到同一个节点组中，并建立两个动态集群，分别部署这两个应用。动态集群需要用 WebSphere Application Server 中的 ODR（On Demand Router）组件作为访问这些应用的代理。请参考相关文档中的具体步骤，来

建立动态集群 并
创建 ODR。另外在本例中我们没有定义服务策略或使用 CPU 过载保护功能，此时可以禁用“ARFM 队列”功能，来提高 ODR 的性能。禁用它的方法是执行 <WAS_HOME>/bin 目录中的 disableARFM.py wsadmin 脚本，这点在

其它文章 里也有讲述。

图 4. 测试场景拓扑结构 – 动态集群


每个动态集群建立时，会默认在每个节点上创建一个服务器，默认情况下只有一台服务器处于启动状态。启动同样的测试，随着压力的增长，动态集群能够自动判断出当前的计算资源（一台服务器的处理能力）满足不了需求，于是生成一个任务，启动集群中的更多服务器实例：（严格地说，这些判断和动作是由 WebSphere Application Server 中的 Application Placement Controller 组件进行的，简称 APC）

图 5. 动态集群启动新的服务器实例


这两个动态集群共享节点组中的资源，当某个集群或应用的负载较重时，它会启动集群中越来越多的服务器，从而该集群分配到更多的计算资源。通过这种方式，资源在不同动态集群之间进行动态分配，得到了充分的利用，从而获得了比静态集群更好的平均性能。

表 3. 动态集群响应时间 – DayTrader 应用忙时

应用	并发用户数	平均响应时间（毫秒）
DayTrader	100	2543
veApp	10	14

图 6. 运行 DayTrader 应用的动态集群启动了更多服务器


表 4. 动态集群响应时间 – veApp 应用忙时

应用	并发用户数	平均响应时间（毫秒）
DayTrader	10	1170
veApp	200	167

图 7. 运行 veApp 应用的动态集群启动了更多服务器

构建动态集群之前应该考虑的事情

通常我们在每个动态集群上面只部署一个应用。上节中我们创建了两个动态集群一起共享整个资源池，这是一种简单的用法，但很多时候这并非最佳实践。规划动态集群前，需要分析每个应用的需求和特点（重要性，忙闲时间，峰值负载，安全需求等），了解当前的资源利用情况，进行全盘考虑，来规划整个拓扑结构，例如数据中心一共需要多少个动态集群，每个集群的规模，哪些集群共享资源等。下面是一些建议：

1. 对于那些总是很忙的关键应用，或者有明确安全隔离需求的应用，考虑单独划分一些节点到一个节点组来建立动态集群，因为这类应用对资源的要求较高，很难共享资源或通过资源共享获得好处。划分独立的节点组也可以保证应用的安全需求。

2. 对于一些访问量不稳定，或者忙闲时间互不相同的应用，可以考虑让它们共享资源，即在有重叠的节点组中创建多个动态集群，部署这些应用。这样它们可以互相取长补短，根据需求合理共享资源。如果需要保证某个应用对资源的独占，还可以考虑配置动态集群隔离特性。后文会有讲述。

3. 对于没有安全隔离需求、负载较轻的一般应用，或者负载曲线相似的一类应用，也可以考虑安装到同一个动态集群上，因为他们的需求特性相似，一荣俱荣，一损俱损，没有必要为每个应用都创建一个动态集群。

回页首

集成 IBM Workload Deployer 及其弹性模式进一步实现资源动态分配

动态集群提供了弹性、灵活的应用基础架构，不过仍然有一个限制——它只能启动节点组中已有的应用服务器，因此最大计算能力仍然受节点组规模的制约。当节点组之外有额外的计算资源可用时（比如购买了新的服务器），需要手工配置它并添加到节点组中。另一方面，当动态集群的计算资源富余时，它也只能停掉应用服务器，而不是缩减动态集群的规模，彻底回收闲置的资源。

IBM Workload Deployer（下文简称 IWD）产品为应用程序的部署提供了易于管理的云环境。它的弹性模式（Elastic Mode）特性允许动态集群根据资源需求，自动扩展或收缩集群的规模，分配合理数量的资源，进一步完善资源的动态分配。

在用 IWD 构建的基础架构中，用户只需提供物理资源（磁盘空间、IP 地址等），所有的节点都是由 IWD 创建的虚拟机。配置弹性模式的步骤参见
这里。我们建立一个动态集群，让它只包含一个节点，并安装一个应用到该集群。

图 8. 只包含一个节点的动态集群


我们开始测试，随着压力的增长，唯一的一台服务器使用率接近饱和，动态集群的计算能力已达上限，不足以处理全部请求。但由于弹性模式的启用，系统此时会自动生成一个任务，告诉 IWD 创建新的虚拟机，在它上面创建并启动应用服务器，加到动态集群里，从而自动扩展了该动态集群的规模，分配了更多的资源。

图 9. 弹性模式下的动态集群自动扩展规模


登录 IWD 控制台，可以看到一个新的虚拟机正在被建立。

图 10. IWD 创建了新的虚拟机


另一方面，当请求减少，动态集群的资源过剩时，它也会自动判断出来，生成一个任务来移除该集群中的服务器，并彻底删除该节点（虚拟机），从而缩减动态集群的规模，释放资源（磁盘空间、IP 地址等）以供其它用途。

图 11. 弹性模式下的动态集群自动缩减规模


登录 IWD 控制台，可以看到该虚拟机已被彻底删除。

图 12. IWD 彻底移除了虚拟机


回页首

动态集群的其它特性及其对性能的影响

为了满足各种各样的应用需求，动态集群还提供了其它特性。本节介绍动态集群的隔离（Isolation）和延迟启动（Lazy Start）这两个特性，以及它们对于整体性能的影响。

隔离功能

很多企业既要支持供外部访问的应用，同时也要支持其它内部应用。由于外部应用更为重要，加上安全性的考虑，企业通常希望把它和内部应用的运行环境隔离开，运行在独立的物理节点中。动态集群的隔离特性就是为了满足这类需求而产生的。设置了隔离特性的动态集群将独占节点上的全部计算资源，即只要该集群的某个应用服务器启动，那么同一节点上其它集群的应用服务器一定不会同时被启动。它的配置步骤请参见

这里。

我们的场景中有两个动态集群，MyDC1 和 MyDC2。我们把 MyDC1 设置隔离，重新进行压力测试。一段时间后可以看到，MyDC1 在前三个节点上的服务器被启动，而这三个节点上 MyDC2 的服务器都不会被启动，从而确保了 MyDC1 上的应用独占前三个节点。

图 13. 动态集群隔离功能


需要注意的是，设置了隔离特性的动态集群，并不会去抢占其它动态集群的资源。例如，MyDC2 已经在两个节点上启动了服务器，则 MyDC1 不会把它们挤掉，而只会启动其余节点上的服务器。因此，配置隔离特性并不能确保提高该动态集群的性能。事实上，隔离特性降低了动态集群之间资源共享的程度，以此换来资源的独占和安全性的提升，因此使用前需要合理规划。

延迟启动功能

有的应用优先级很低且很少被访问，该应用所处的动态集群可能多数时间处于闲置状态。用户希望当资源缺乏时，能自动停掉该集群中所有的应用服务器，直到有请求到来时才启动，从而节省出资源给其它动态集群和应用。延迟启动就是起这个作用的，它的详细说明和配置步骤见

这里。

我们将动态集群 MyDC1 设置延迟启动，时间为 10 分钟，并设置 proactiveIdleStop 参数为 true。这种情况下，如果 10 分钟内 MyDC1 上的应用没有任何请求到达，该集群的所有应用服务器会自动停止。之后如果有请求到达，动态集群会生成一个任务，来启动其中的一个应用服务器，运行该应用。

图 14. 动态集群延迟启动功能


这种方式能够最大限度地节省计算资源，保证其它更重要的动态集群及其应用获得尽可能多的资源。不过在延迟启动期间，该应用的请求会返回 HTTP 503 (Service Unavailable) 信息，因此使用时需要权衡利弊。建议仅在资源非常紧张的情况下使用。

回页首

结论

WebSphere Application Server V8.5 中的动态集群功能实现了应用基础架构的虚拟化。不同集群之间可以共享资源，根据应用的需求自动进行资源分配，从而提高了资源利用率并改善应用的性能。动态集群还提供了隔离和延迟启动等特性，满足更多需求。

通过集成 IBM Workload Deployer 及其弹性模式，能够根据应用的资源需求，自动扩展或收缩动态集群，分配合理数量的资源，进一步完善资源的动态分配。

动态集群还可以和服务策略结合使用，来根据每个应用的重要性和预期响应时间分配不同的资源，满足不同的服务目标。我们将在另一篇文章中介绍。

参考资料

访问
WebSphere Application Server V8.5 信息中心 了解更多信息。
IBM developerWorks 中国，WebSphere 专区：为使用 WebSphere 产品的开发人员准备的技术信息和资料。这里提供产品下载、how-to 信息、支持资源以及免费技术库，包含 2000 多份技术文章、教程、最佳实践、IBM Redbook 和在线产品手册。
最受欢迎的 WebSphere 试用软件下载：下载关键 WebSphere 产品的免费试用版。
IBM developerWorks 软件下载资源中心：IBM developerWorks 最新的软件下载。
加入
developerWorks 中文社区：developerWorks 社区是一个面向全球 IT 专业人员，提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
加入
IBM 软件下载与技术交流群组，参与在线交流。
IBM developerWorks 工具包：下载关键 WebSphere 最新的产品工具包。