内容


在复杂 WebSphere Application Server 拓扑中集成 WebSphere Virtual Enterprise

Comments

简介

IBM WebSphere Virtual Enterprise 帮助最优化 IBM WebSphere Application Server Network Deployment(此后称为 Network Deployment)环境,智能地管理 Network Deployment 拓扑中的工作负载。此外,WebSphere Virtual Enterprise 提供了轻松管理 Network Deployment 应用程序的部署和健康状况的功能,因此形成了一个更加弹性和有效的 WebSphere Application Server 环境。

WebSphere Virtual Enterprise 主要用于为现有的 Network Deployment 增强服务质量(Quality of Service,QoS)。WebSphere Virtual Enterprise 对 QoS 进行增强的其中一个方面就是描述和增强服务水平协议。WebSphere Virtual Enterprise 中引入了一个按需供应的路由器(ODR)组件,可以充当一个智能反转代理(reverse proxy),用于管理通信流。ODR 还可以帮助增强为应用程序定义的服务水平协议。

WebSphere Virtual Enterprise 改善了 Network Deployment 环境的效率,它在一个单元(cell)中的多个节点之间转移容量,从而满足工作负载需求。该特性使 WebSphere Virtual Enterprise 能够利用闲置节点上的未使用的容量,并将这些空闲的容量动态用于那些需要 CPU 资源来满足其服务水平协议的应用程序 —— 从而提高您的硬件投资回报(ROI)。

WebSphere Virtual Enterprise 还提供了可以在最小化宕机的同时轻松管理 Network Deployment 应用程序的新特性。一个应用程序版本管理器可以管理一个 Network Deployment cell 中同一个应用程序的多个版本,并跨整个 Network Deployment cell 管理应用程序更新的首展,同时可以感知传入的通信流和应用程序的服务水平协议。

WebSphere Virtual Enterprise 中的健康管理特性改善了应用服务器环境的弹性。WebSphere Virtual Enterprise 可以自动检测健康条件(例如内存泄漏)并采取自动化操作,比如通知管理员或在检测到一个健康情形后,使通信量跳过不健康的服务器。

WebSphere Virtual Enterprise V6.1 通常部署在 WebSphere Application Server Network Deployment V6.1 或 7.0 上,但是它也能够管理其他中间件服务器。利用 WebSphere Virtual Enterprise 特性不需要对现有 Network Deployment 应用程序执行任何代码修改,并且应用程序不需要实现任何新的 API 就能够从 WebSphere Virtual Enterprise 的 QoS 特性收益。

本文描述了从许多已经将 WebSphere Virtual Enterprise 部署到现有 Network Deployment 基础设施上的用户身上学到的最佳实践和限制。参见 参考资料,获得有关 WebSphere Virtual Enterprise 功能的更多信息。

应用程序需求

首先,需要理解将要部署到 WebSphere Virtual Enterprise 中的动态集群上的应用程序的需求。这里列出的其中一些需求需要有将应用程序部署到集群中的能力。通常,迁移到 WebSphere Virtual Enterprise 的用户已经在集群中运行了他们的应用程序。如果您属于这种情况,那么您的应用程序已经满足了大部分这些需求。

应用程序稳定性和性能测试

有关 WebSphere Virtual Enterprise 的常见误区之一就是它能够改善应用程序的性能特征。事实并非如此。比如,假设一个应用程序被分配了一个不符合实际的服务水平参数,比如一个过于积极的响应时间。WebSphere Virtual Enterprise 无法让应用程序的响应速度超过它的固有限制,因此设置一个过于积极的响应时间会导致环境效率低下。相反地,如果响应时间的目标设得太低的话,WebSphere Virtual Enterprise 在将资源分配给目标应用程序时就无法保持较好的响应性。这是因为 WebSphere Virtual Enterprise 通过形成通向 Network Deployment cell 的通信流来调整可用于应用程序的资源。通过对进入 cell 的请求流划分优先级,WebSphere Virtual Enterprise 可以控制某个应用程序获得的与其他应用程序有关的 CPU 和内存资源的数量。

此外,WebSphere Virtual Enterprise 可以利用 Network Deployment cell 中未充分利用的节点来满足应用程序的工作负载要求,方法就是启动额外的用于托管应用程序实例的 JVM(这是 WebSphere Virtual Enterprise 动态集群的一个特性)。

然而,如果应用程序是非性能的(non-performant)或定义了不符合实际的服务水平协议,那么将没有足够的资源来使它达到理想的水平。事实上,它将导致环境变得低效,因为 WebSphere Virtual Enterprise 将扩展资源来尝试实现这个不可能实现的目标。

因此,将应用程序部署到 WebSphere Virtual Enterprise 并不意味着可以免于对应用程序执行负载测试,或者确保应用程序的可伸缩性和稳定性。事实上,具有已知的、得到良好理解的性能特征的稳定应用程序是执行 WebSphere Virtual Enterprise 部署的最佳候选。此外,不太稳定的应用程序可以通过 WebSphere Virtual Enterprise Health Management 子系统进行更好的管理。

来自性能测试的可靠数据,以及收集自实时运行的应用程序的历史统计数据,这两者结合起来可以提供准确的输入来为部署在 WebSphere Virtual Enterprise 上的应用程序定义切合实际的服务水平协议。

会话故障转移

Network Deployment 通过其对分布式系统的支持提供了会话故障转移功能。您可以为运行在集群中的应用程序选择数据库会话持久化或内存到内存的会话复制。(还可以使用 IBM WebSphere eXtreme Scale 来提供高度可伸缩的、经济有效的 会话持久性机制)。当从 Network Deployment 集群环境迁移到一个 WebSphere Virtual Enterprise 动态集群环境中时,会话故障转移成为了一项更加重要的需求。在 WebSphere Virtual Enterprise 环境中,应用程序位置控制器(placement controller)可以就需要运行多少动态集群成员以及在哪里运行制定运行时决策。当动态集群在自动模式下运行时,应用程序位置控制器将在管理员不直接参与的情况下停止一个集群成员。因为 WebSphere Virtual Enterprise 环境中的应用程序在没有显式应用服务器故障的情况下会因此丢失它们的会话,因此会话丢失的频率会高很多。

尽管这是一项重要的观察,但是要记住并非所有的应用程序都使用会话。大多数 Web 服务应用程序是无状态的并且不依赖会话;这使它们非常适合部署到 WebSphere Virtual Enterprise 环境中。

自包含的 EAR 文件

自包含 EAR 是指在安装后不需要进行任何修改的 EAR 文件。一些用户在完成应用程序安装后会对 installedApps 目录中的 EAR 的扩展工件(例如属性文件)进行直接修改。虽然不推荐这样做,但是在 Network Deployment 环境中有时也可以这样做。

然而,在 WebSphere Virtual Enterprise 动态集群环境中,对扩展 EAR 文件的这些手动修改变得难以管理。WebSphere Virtual Enterprise 通常将应用程序二进制文件安装到目标动态集群的每一个节点成员的相应概要文件中。将一个新的节点联合到 cell 中会使该节点成为动态集群的一个新成员(假设满足成员关系策略)。WebSphere Virtual Enterprise 将自动把应用程序部署到新节点,但是不会对扩展的 EAR 文件做任何手动修改。考虑到这种情况,一定要在 WebSphere Virtual Enterprise 环境中只使用自包含的 EAR 文件。

特定于应用程序的资源在节点中的可用性

依赖特定资源(比如特定的共享文件系统或资源管理器定义)的应用程序必须使这些资源可用于所有构成动态集群成员策略的节点中。当新的节点由于成员关系策略修改而被引入动态集群时,这一点变得尤为重要。例如,如果一个应用程序连接到 IBM WebSphere MQ 或 IBM CICS® Transaction Gateway,那么 WebSphere MQ 客户机库或 CICS Resource Adapter 各自都必须可用于应用程序的目标动态集群中的每一个节点。

WebSphere Application Server 资源定义,比如数据源和 JDBC 提供者,可以在 cell 或集群级别定义,这非常适合动态集群。然而,一些应用程序依赖于一些外部资源,这些资源将用于应用程序所运行的节点。这样的例子包括用于访问 IBM DB2® 或 WebSphere MQ 的本地库的安装,但是也包括应用程序所需的共享应用程序库。系统管理员需要确保匹配动态集群成员策略的所有节点都安装了这些资源。

尽管 WebSphere Virtual Enterprise 不会自动执行这个过程,但是您应当为外部资源设置自定义的节点属性。动态集群的成员关系策略随后可以进行修改,以确保只有满足这些自定义属性集的节点会匹配成员关系策略。这将确保不会对那些未安装所需外部资源的节点定义动态集群成员。

拓扑考虑

硬件虚拟化支持

如今,WebSphere 产品通常被部署到虚拟化硬件上。即使 WebSphere Virtual Enterprise 通过应用程序虚拟化提供了不同的服务质量,许多用户仍然希望将应用程序部署到虚拟化的硬件平台上。在这种情况下,一定要理解 WebSphere Virtual Enterprise 为虚拟化硬件提供的支持。

  • AIX/system p:WebSphere Virtual Enterprise V6.1.1 及更高版本为该平台提供了充分支持,包括支持使用微分区的无上限(uncapped)LPAR。
  • VMware:WebSphere Virtual Enterprise V6.1 使用 VMware Infrastructure SDK (VI SDK) 通过 Web 服务与 VMware Infrastructure 3 平台通信。因此,任何将 VI SDK 公开为 Web 服务的平台都可以处理 WebSphere Virtual Enterprise。例子包括 VMware ESX Version 3.5、Virtual Center 2.5 和 vSphere 4.0。

在信息中心中查看 受支持的服务器虚拟化环境 列表。

大型 cell 的诱惑

在 WebSphere Virtual Enterprise 环境中以 cell 为单位实现应用程序虚拟化是最有效的,这要求 WebSphere Virtual Enterprise 管理大型 cell。例如,划分应用程序优先级和应用程序位置布置将在一个 cell 上下文中执行。因此,要从受目标驱动的应用程序虚拟化(以及提高的硬件 ROI)中获得最大的受益,往往会跨越常见硬件将大量的应用程序部署到一个大型 cell 中。然而,不应该忽略有关操作风险的一些基本规律。大型 cell 会增加操作风险并使位于 cell 中的组件或应用程序出现单点故障。

要降低大型 cell 的风险,用于实现高可用性和灾难恢复的典型 Network Deployment 技巧也应当应用到 WebSphere Virtual Enterprise 中。例如,如果多个相同的 cell 成为 Network Deployment 环境的高可用性计划的一部分,那么相同的技巧也应当应用到 WebSphere Virtual Enterprise 环境中。

核心组考虑

默认情况下,单个 cell 中的所有 WebSphere Application Server 流程都属于同一个核心组的成员。应用到 Network Deployment 的核心组最佳实践也适用于 WebSphere Virtual Enterprise。在部署(相对而言)大型 Network Deployment 或 WebSphere Virtual Enterprise cell 时需要考虑的关键点包括:

  • 单个核心组中的流程总数不要超过 50 个。如果需要在 Network Deployment 或 WebSphere Virtual Enterprise cell 中使用更多的流程,那么应当定义额外的核心组并在所有核心组中分布流程。
  • 属于某个集群(或动态集群)的流程不能跨越多个核心组。换言之,集群的所有成员也应当成为同一个核心组的成员。
  • 每个核心组应当至少包含一个 WebSphere Application Server 管理流程;例如,一个节点代理或部署管理器流程。

在 WebSphere Virtual Enterprise V6.1.1 之前还有一个额外的要求,那就是同一个 cell 中的所有核心组连接在一起。WebSphere Virtual Enterprise V6.1.1 引入了一个选项来在 Service Overlay Network (BBSON) 实现之上使用 Bulletin Board。尽管不是默认选择,您应当使用 BBSON,因为它可以极大地减少 WebSphere Virtual Enterprise 的 CPU 开销,并且它能够避免将核心组连接在一起,这简化了 WebSphere Virtual Enterprise 部署。

避免将 cell 跨越到两个数据中心

从拓扑的角度来看,Network Deployment 拓扑的最佳实践也适用于 WebSphere Virtual Enterprise。对于跨越数据中心的 Cell,不推荐使用 Network Deployment。Tom Alcott 在其 WebSphere Application Server 常见问题解答系列文章的 第 3第 5 篇文章中详细解释了原因。

同样,您不应当让 WebSphere Virtual Enterprise cell 跨越多个数据中心。图 1 展示的拓扑提供了最好的稳定性并减少了数据中心宕机中涉及到的的操作风险。注意,cell 是完全独立的;在 cell 之间没有建立任何核心组连接。因此,ODR 层将只请求路由到各自数据中心的应用服务器中。

在这个拓扑中,显然一个数据中心的应用程序位置控制器无法利用其他数据中心中的空闲容量。然而,不应该低估在发生数据中心宕机时改进后的解决方案的弹性。

图 1. 避免跨越两个数据中心的 WebSphere Virtual Enterprise cell
图 1. 避免跨越两个数据中心的 WebSphere Virtual Enterprise cell
图 1. 避免跨越两个数据中心的 WebSphere Virtual Enterprise cell

用户考虑的另一个选择是跨数据中心路由。也就是说,HTTP 插件只应当路由到同一个数据中心的 ODR,还是应当允许它们路由到外面的 ODR?

就数据中心的操作独立性而言,HTTP 插件不应当被路由到外部 ODR。然而,在某些情况下,这样做是有益的。例如,如果 HTTP 服务器的数据中心的所有本地 ODR 被停止,那么外部 ODR 则可以作为一个有效的目标,用于故障转移到一个正常的数据中心。因此,路由到外部 ODR 可以被视为一个例外,用于在数据中心内的所有 ODR 全部故障的情况下保持应用程序高可用性。这可以通过在 HTTP 插件中将外部 ODR 用作备用目标来实现。

路由到外部 ODR 的另一个理由也许是会话相关性(affinity)。一些用户会遇到这样的情况,即对会话敏感的通信到达错误数据中心中的 HTTP 服务器(也就是说,会话存在于另一个数据中心)。在这种情况下,插件需要将通信路由到外部 ODR,以维护会话相关性。

避免涉及跨 cell 连接的拓扑

尽管 ODR 跨多个 cell 路由通信在技术上是可行的,但是不要创建这种拓扑。在实践中,这种跨 cell 连接常常导致产生不稳定的解决方案,并且增加了复杂性。当 ODR 路由到一般的服务器集群 —— 即非 WebSphere Application Server 集群或外部 WebSphere Application Server 集群,且 ODR 所在的 cell 没有对这些集群的生命周期进行完全的管理 —— 那么就不需要跨 cell 连接。事实上,如果目标服务器被定义为通用服务器集群,那么最好路由到多个 cell。

避免 ODR 和应用服务器共存

尽管技术上对共存的 ODR 和应用服务器没有限制,如果共享机器没有足够的 CPU 资源来处理最高 ODR 和最高应用程序负载,那么您不应当实现这种配置。

ODR 运行应用程序请求流管理器(ARFM),后者使用的 CPU 资源永远不会被用于共存的应用服务器。同时,ARFM 从共享机器中收集 CPU(和内存)统计数据来制定有关流控制的决策。由于由 ODR 消耗的处理能力会随着工作负载而呈现出显著的变化,因此共享机器上的 CPU 消耗也将会随着 ODR 的工作负载变化。换句话说,共存应用服务器的 ARFM 统计数据会被 ODR 工作负载影响。ARFM 将 ODR 工作负载视为共享应用服务器机器上高度不同的环境噪音,如果共享机器没有 CPU 资源来处理 ODR 负载和应用程序负载的话,这会导致应用服务器通信出现波动。然而,如果共享机器可以适当地调整大小,那么这种场景也可以很好地工作。

对管理通信使用专用 ODR

WebSphere Virtual Enterprise 提供了一个开箱即用的高度可用的部署管理器特性。它作用于一个活动/被动(active/passive)模型,在这个模型中,如果活动部署管理器出现故障的话,那么一个热备用部署管理器将接管工作。

在一个高度可用的部署管理器设置中,管理通信应当流经一个 ODR。原因是 ODR 能够感知在一个给定时刻哪个部署管理器处于活动状态;因此,一个管理客户机(比如管理控制台用户或 wsadmin 脚本)只需要知道 ODR 地址,而 ODR 将管理请求转发给活动部署管理器。

下一个问题是:应用程序和管理通信应该共享 ODR 么?

答案视具体情况而定。一些用户认为让管理请求和应用程序请求通过同一个 JVM 存在安全风险;出于安全原因,他们不希望包含管理凭证的线程和包含非管理的或特定于应用程序的权限的线程位于同一个 JVM 中。如果是这种情况的话,那么对管理通信使用专用的 ODR 就可以解决问题。如图 2 所示,至少需要使用两个 ODRs 实现高可用性。

图 2. 在 HA 部署管理器环境中对管理通信使用专用的 ODR 层
图 2. 在 HA 部署管理器环境中对管理通信使用专用的 ODR 层
图 2. 在 HA 部署管理器环境中对管理通信使用专用的 ODR 层

cell 整合带来的挑战

跨组织整合 cell

在迁移到虚拟化基础设施后,应用程序团队或组织将进行资源共享。特别是,多个团队将共享同一个 WebSphere Application Server cell。这将带来下面这些挑战:

  • 由于多个团队将共享同一个 cell,管理职责将发生变化。如果 cell 管理没有被集中化(通过一个中央操作团队),那么来自每个组织的管理员将可以完全访问每个其他组织的应用程序,而这并不总是允许的。例如,来自组织 A 的管理员可以停止组织 B 的应用服务器。

    WebSphere Application Server Network Deployment V7.0 对这种情况提供了一个局部解决方案,其形式是一个细粒度的安全模型,使管理角色能够在 cell、节点、节点组、集群、服务器和应用程序的级别设置。这一特性可用于禁止来自其他组织的人员控制您的应用服务器或应用程序。有关该特性的文档可以在 WebSphere Application Server Information Center 中找到。

    记住,只有 WebSphere Virtual Enterprise V6.1.1.0 和 V6.1.0.5 在 Network Deployment V7.0 中受支持。查看 受支持的软件 的完整列表,获得更多细节。

  • WebSphere Virtual Enterprise 中的服务策略(服务水平协议)的其中一个组成部分就是相对业务优先权(relative business priority)。在整合后的 cell 中,服务水平协议确定哪些应用程序获得对共享环境的优先权。确定应用程序的相对业务优先权是一项策略挑战。要处理这个问题,服务水平协议应当由业务团队决定,而不是应用程序团队,因此,优先权可以由业务决策的制定者根据不同业务部分的相对优先权确定。

大型整合 cell 的安全考虑

许多组织拥有多个用户库(比如 LDAP)。这是应用技术战略的直接结果,或者,是与其他公司进行早期合并而产生的副作用。在 cell 整合的上下文中,多个用户库会成为一个问题。

通过使用 Network Deployment V6.1 的联合库特性,可以将多个库联合起来并视作一个单个库。在尝试整合多个 cell 时,这将提供一个解决方案。然而,问题在于对于一个联合库,只能存在一个安全域,这是不能接受的。例如,如果您为不同用户群维护用户隔离和不同的安全策略,那么您希望有两个独立的安全域,一个用于内部用户(员工),另一个用于外部用户(客户)。

Network Deployment V7.0 为此提供了解决方案,它的一个特性支持将多个独立的用户库连接到同一个 cell,并且具备独立的安全域。如果两个域之间的应用程序需要进行通信,那么可以在这两个安全域之间建立信任。该特性支持对具有两个独立库的 cell 进行整合 —— 同时仍然维护用户行为和安全策略隔离。

有关更多信息,请参见 WebSphere Application Server V7.0 信息中心

大型整合 cell 中的应用程序部署

Cell 整合通常导致更多的应用程序共享相同 cell。需要部署或更新大量应用程序的用户会发现应用程序部署成为一个瓶颈,因为 Network Deployment 只允许一次部署一个应用程序。

要实现这一点,您必须进行折中,将并行部署减至最低程度;例如,您的应用程序团队可能会对一个部署调度达成一致意见。在最坏的情况下,那些在同一时间进行更新或部署的应用程序需要被放置在不同的 cell 中,这样才能满足隔离需求。

WebSphere Virtual Enterprise 部署的其他考虑

处理通过 ODR 路由的备用请求

如今的企业应用程序在处理单个请求时往往会涉及多个组件或服务。例如,一个客户机(浏览器)可能会执行 HTTP POST,它将首先触发 Web 容器中的一个 servlet,后者又对独立应用服务器或集群中托管的应用程序发出一个 Web 服务调用。图 3 解释了这个例子。

图 3. 在 Network Deployment 环境中路由的 HTTP 请求
图 3. 在 Network Deployment 环境中路由的 HTTP 请求
图 3. 在 Network Deployment 环境中路由的 HTTP 请求

当在 WebSphere Virtual Enterprise 环境中执行部署时,该示例将类似于图 4 所示。客户机触发 ODR,后者将请求路由到托管 Web 应用程序的应用服务器中。Web 应用程序对 Web 服务应用程序(在其中被称为备用请求)发出调用。

图 4. 在 WebSphere Virtual Enterprise 环境中通过 ODR 路由 HTTP
图 4. 在 WebSphere Virtual Enterprise 环境中通过 ODR 路由 HTTP
图 4. 在 WebSphere Virtual Enterprise 环境中通过 ODR 路由 HTTP

在部署 WebSphere Virtual Enterprise 时,往往会在独立的动态集群中部署 Web 应用程序和 Web 服务应用程序。这使与 Web 服务应用程序的通信能够获得优先权和负载平衡。然而,这将要求所有备用请求通过 ODR 路由,如图 5 所示。

图 5. 在 WebSphere Virtual Enterprise 环境中通过 ODR 路由备用 HTTP 请求
图 5. 在 WebSphere Virtual Enterprise                     环境中通过 ODR 路由备用 HTTP 请求
图 5. 在 WebSphere Virtual Enterprise 环境中通过 ODR 路由备用 HTTP 请求

不推荐使用这种架构,并且应当避免使用它。实现这种配置要求所有备用请求与它们各自的服务策略相关联,Web 服务应用程序运行在其自己的集群中,且将服务策略配置为最高优先权。然而,即使是在最好的情况下,这个架构仍然会引起死锁问题。

自动请求流管理器拒绝策略

自动请求流管理器 (ARFM) 负责确保在将请求发送给它们的目标应用服务器前,对它们进行分类、优先化和排队。ARFM 尝试使运行这些应用程序的动态集群的节点避免出现超载。然而,在一些出现峰值负载的场景中,ARFM 无法满足服务策略目标以及避免节点超载。WebSphere Virtual Enterprise 提供了各种拒绝策略,可以确定 ARFM 在这种情况下的行为。您可以在 Integrated Solutions 控制台的 Operational Policies > Autonomic Managers > Autonomic Request Flow Manager 下找到这些策略。

图 6. 在启用了 WebSphere Virtual Enterprise 的管理控制台中的 ARFM 设置面板
图 6.在启用了                     WebSphere Virtual Enterprise 的管理控制台中的 ARFM 设置面板
图 6.在启用了 WebSphere Virtual Enterprise 的管理控制台中的 ARFM 设置面板

两个基本的拒绝策略分别为:

  • 不拒绝任何传入的请求,不管它们会对服务水平协议产生什么影响。

    当工作负载足够多,以至于系统逼近配置的 CPU 阈值且引起事务类之间出现资源争用时,服务策略将受到违反。ARFM 将继续接受请求,不管会对这些策略产生什么影响;换句话说,您有可能会违背自己的应用程序服务水平协议。

    然而,ARFM 确保低优先级的服务策略的违背程度总是大于高优先级的服务策略的违背程度。也就是说,低优先级工作受到的影响总是要多于高优先级的工作。ARFM 还遵守已配置的 CPU 阈值。

  • 如果接受传入的请求会对服务水平协议产生负面影响,那么就拒绝这些请求。

    当工作负载足够多,以至于系统逼近配置的 CPU 阈值且开始出现服务策略违背时,那么 ARFM 将开始拒绝那些不属于现有会话的请求。通过拒绝某些特定请求,ARFM 确保具有充足的容量来在满足服务策略目标的情况下处理未拒绝的请求。

    这种拒绝策略的一个关键的副作用就是它可以拒绝那些与最高优先级服务策略相关的请求。虽然被 ARFM 拒绝的低优先级请求要多于高优先级请求,许多业务场景仍然不允许拒绝与最高优先级服务策略有关的请求。不幸的是,目前没有一项 ARFM 策略可以确保最高优先级请求永远不会被拒绝。因此,ARFM 拒绝策略只有在企业允许拒绝高优先级请求的情况下使用。

使用 ODR 处理定制的错误页面

WebSphere Virtual Enterprise 中的 ODR 能够拦截标准的 HTTP 错误代码(这些代码可以由 ODR 生成或接收自目标应用服务器),然后将 HTTP 错误代码和错误 URL 转发到一个定制错误页面。定制错误页面可以被部署到应用服务器或 Web 服务器;后者如图 7 所示。

图 7. 位于 ODR 层之后托管在 Web 服务器上的定制错误页面
图 7. 位于 ODR 层之后托管在 Web 服务器上的定制错误页面
图 7. 位于 ODR 层之后托管在 Web 服务器上的定制错误页面

如果您已经在您的 Web 服务器中提供了静态定制错误页面,或者已经具有了一个定制错误页面策略,那么使用这个 ODR 特性不会获得太大的好处

使用 Edition Manager 更新应用程序

WebSphere Virtual Enterprise Edition Manager 的 rollout 特性是一个非常强大的工具,可以将更新部署到应用程序中。可以在不中断服务的情况下部署一个更新后的应用程序,这意味着应用程序具有持续的可用性。

然而,应用程序更新有时需要同时对外部资源进行修改,比如数据库模式修改、一个新的共享库,或者对队列管理器定义的修改。在这些情况下,Edition Manager 无法提供持续的应用程序可用性,因为这些是发生在应用程序 EAR 文件以外的修改。然而,Edition Manager 提供了一个简单的机制来回滚到早前的版本,因此简化了这一过程。Edition Manager 还可以用于在生产环境中将新的版本推出到测试集群,这增加了成功升级应用程序的机率。

监视 WebSphere Virtual Enterprise 环境

WebSphere Virtual Enterprise 的其他功能要求您彻底地了解如何监视新环境。图 8 展示了 WebSphere Virtual Enterprise 解决方案中提供的不同类型的监视功能。您将会注意到,其中一些是 WebSphere Virtual Enterprise 环境特有的功能(蓝色),其他功能还可以在 Network Deployment 环境中找到(蓝色)。

图 8. WebSphere Virtual Enterprise 环境中的监视功能
图 8. WebSphere Virtual Enterprise 环境中的监视功能
图 8. WebSphere Virtual Enterprise 环境中的监视功能
  • 端到端应用程序监视

    WebSphere Application Server 管理员经常监视应用程序的可用性和响应时间。这帮助您比客户早一步检测到问题。尽管 WebSphere Virtual Enterprise 的健康管理功能可以检测响应时间违背,但是端到端的监视功能显然涵盖了基础设施的其他部分(比如,防火墙、负载均衡器等等)。因此,您应该对 WebSphere Virtual Enterprise 解决方案继续使用端到端监视。

  • 资源监视

    Network Deployment 中的 IBM Tivoli® Performance Viewer 使您能够监视许多 WebSphere Application Server 资源。您应当使用一个更健壮的解决方案,可以在更长的时间内存储数据,比如 IBM Tivoli Composite Application Manager。

  • 操作系统监视

    考虑到 WebSphere Virtual Enterprise 的动态特性,仅仅监视操作系统进程是不够的。进程监视对于那些不在应用程序位置控制器控制下的组件是有益的,比如节点代理、ODR,可能还有部署管理器进程。此外,仍然强烈建议您在 WebSphere Virtual Enterprise 环境中监视系统资源(比如 CPU 利用率、磁盘和网络 I/O 和文件系统)

  • WebSphere Virtual Enterprise 运行时任务

    当 WebSphere Virtual Enterprise 生成运行时任务时,您应当对它有所了解。与登录到 Integrated Solutions Console 并等待任务出现相反,您可以配置 WebSphere Virtual Enterprise 来在任务生成时发送电子邮件通知。SNMP 等其他接口目前暂不支持。

  • WebSphere Virtual Enterprise 健康管理

    WebSphere Virtual Enterprise 中的健康管理组件使您能够在健康策略中定义特定的条件和动作。在运行时期间,健康管理组件将根据您定义的条件自动监视系统并在需要时采取必要的动作。这个过程可以被配置为完全自动化,这样就无需任何管理员介入。WebSphere Virtual Enterprise 将在健康管理器执行一个特定动作时生成一个运行时任务。如果将健康策略配置为自动采取动作,那么运行时任务将充当对所采取的动作的通知;如果将健康策略配置为在采取动作前要求系统管理员批准动作(称为 supervised 模式),那么运行时任务将在执行动作之前等待管理员的批准。

    健康策略非常有助于优雅地管理一些已知的健康问题(比如在指定的时间间隔自动重启服务器),以及管理一些意外的问题(比如在新部署的应用程序中检测内存泄漏以及在 JVM 反应变慢之前生成堆转储)。

有关 WebSphere Virtual Enterprise 健康管理策略的更多信息,参见 WebSphere Virtual Enterprise Information Center

结束语

IBM WebSphere Virtual Enterprise 提供了功能强大的特性,可以帮助您优化 IBM WebSphere Application Server Network Deployment 环境。本文总结了有关如何使用这些特性的技巧和最佳实践、成功部署所需的环境和应用程序先决条件,以及在考虑 WebSphere Virtual Enterprise 部署时需要制定的架构决策。

致谢

作者感谢 Brian K. Martin、Keith B. Smith 和 John P. Cammarata,他们为本文提供了资料和反馈。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=490078
ArticleTitle=在复杂 WebSphere Application Server 拓扑中集成 WebSphere Virtual Enterprise
publish-date=05202010