中间件虚拟化平台方案

1、基于 WVE 的应用服务器虚拟化平台方案1 应用服务器虚拟化平台概述1.1 应用服务器虚拟化平台的构成应用服务器虚拟化平台是以中间件技术为基础，基于虚拟化、自动化和自 优化等技术实现的新一代中间件运行管理平台。应用服务器虚拟化平台实现了 应用程序与计算资源的解偶，提供了更灵活的应用部署和运行方式，由此，实 现了对工作负荷以及计算资源的动态管理，确保了计算资源有效合理的分配， 确保了应用程序的服务水平，并提供了更高的可用性，同时简化了运维工作。相对对于传统的应用服务器件平台，应用服务器虚拟化平台以应用服务器 动态集群（以下简称动态集群）为核心，为应用程序运行提供一个具备更高共 享度和灵活性的运行

2、环境，其解决方案应主要包括三部分：动态应用服务器集群组 ：一组基于由多台物理服务器组成的计算资源池 构建的、具备动态特性（详见 1.2）的服务器集群，是提供应用运行环 境的主体；应用路由控制节点 ：作为客户端请求的统一接入层， 实现对动态集群成 员间的负载均衡和路由；管理控制节点 ：动态集群环境的管理和监控工具， 通过该工具可定义和 配置动态集群和应用路由控制节点的各种相关参数， 包括运行时的动态 集群需要遵循的各种策略，并可监控这个环境的运行状态。1.2 应用服务器虚拟化平台的特性1.2.1 虚拟化特性单个或一组计算机与应用程序之间不再存在紧密绑定或一对一的关系，动 态集群成为物理计算资源的

3、 “逻辑表示”，应用程序通过动态集群来消费物理的 计算资源，从而简化了对物理计算资源的访问和管理。1.2.2 运行时动态特性动态的规模 ：动态集群的规模不固定， 是由相应的预定义策略和应用的 运行时状态等因素动态决定；动态的负载分配 ：动态集群的每个成员分担负载的比例不再是通过静态定义的权重决定， 而依据运行时每个成员所在物理服务器的实际负载动 态计算而来；动态的应用部署 ：当多个应用部署在一个统一的资源池上时， 动态集群 环境会依据预定义的策略和应用的运行时状态， 动态决定应用运行于哪 些物理服务器上；动态的请求路由 ：基于动态的负载分配和动态应用部署， 以及预订的策 略，应用路由控制节点对

4、接入的请求动态地确定路由目标；1.2.3 自动化特性应用服务器虚拟化平台可以自动化地对应用程序的运行状况、负载状况以 及资源利用状况进行监控， 并可以基于预定义的策略， 自动化地调度计算资源， 控制应用请求流量，处理运行时异常。2 应用服务器虚拟化平台方案价值及设计目标2.1 方案的核心价值相对与传统中间件方案实现的基本功能，应用服务器虚拟化平台提升应用 运行基础设施的如下能力：提供动态、共享的计算环境，提升计算资源的利用率应用服务器虚拟化平台将多个应用系统原有独立并隔离的计算资源进行整 合，形成统一的计算资源池，在将多个应用分别部署与计算资源池承载的多个 动态集群之上，使动态集群能够共享整个

5、资源池的计算能力，在运行时，基于 预订的性能目标（例如，平均响应时间） ，自动控制动态集群的规模，实现计算 资源的动态调度。例如，动态集群支持的应用当其访问峰值到达时，动态集群 环境以满足预定义的性能指标为导向进行计算资源的动态调度，自动扩展集群 规模，即启动更多的应用服务器实例来满足当前的性能需求。 当访问峰值过后， 其负载较小时，动态集群环境还会缩小规模，并释放计算资源，供其他应用使 用，从而实现计算资源的高效共享与利用。支持应用服务级别的管理，实现面向业务需求的动态计算资源分配 在应用服务器虚拟化平台上，用户可以定义应用的优先级，在动态调度计 算资源时，如果同一计算资源池中的动态集群之间

6、发生资源竞争，动态集群环 境将优先为承载优先级高的应用的动态集群提供计算资源，另一方面，通过应 用路由控制节点，还可以控制客户端访问流量，应用路由控制节点将优先通过 对优先级高的应用的访问请求，当有资源竞争时，应用路由控制节点可以暂缓 发送对优先级较低的应用的访问请求，确保优先级较高的应用的服务质量。此 外，基于应用路由控制节点流量控制，用户可以灵活制定对不同的客户端（例 如，来源不同 IP 地址的客户端），不同的访问用户，以及不同的访问 URL 的服 务级别，从而实现真正面向业务需求的动态计算资源分配。提供自动化的健康检查及异常处理能力，简化运行维护工作 应用服务器虚拟化平台提供了自动化的健

7、康检查机制，用户可以定义系统 健康状态的边界条件，包括计算资源消耗状态、应用响应时间以及产生错误数 量等，动态集群环境会依据这些条件对动态集群的每个成员进行实时监控，当 系统超越边界条件处于异常状态时，可以进行告警。同时用户还可以定义自动 化的异常处理动作，包含隔离异常应用服务器，自动记录诊断信息以及自动重 启应用服务器等，在发生异常状态时，这些处理动作将被自动执行，从而使用 户可以有效制定应对系统异常的应急预案，由此大大简化系统管理员的运维工 作。2.2 方案的设计目标本方案通过构建应用服务器虚拟化平台，力图实现如下设计目标； 构建具有高可用性、 高扩展性的动态应用运行环境， 实现应用系统之

8、间 计算资源的有效共享；实现运行时应用系统间计算资源的动态调度，提高资源利用率； 实现对应用系统的服务级别管理，支持基于服务级别的计算资源调度; 提供对系统的实时监控及自动化管理，实现对系统异常的自动化处理; 提供运行状况报告及应用系统对计算资源的使用状况报告。3应用服务器虚拟化平台功能及逻辑架构3.1功能及架构概述本方案提供了完整的应用服务器虚拟化平台环境，包括了统一接入客户端 请求的负载均衡设备，管理控制节点，应用路由控制层，计算资源池以及由其 承载的应用/动态集群组，应用服务器动态集群环境逻辑架构示意图如下：负载均衡设备App Router 1App Router 2App Router

9、 m应用路由控制层A ppi I DC1App1 J DC1App3 / DCSApp3 / DC3AppS I DCSApp2 f DC2App Srv&r Mode 1App Sarver NodeS计贰瓷源池App2 / DC2J1 JrMana-gemenitNods7气t j,7App Server Node 4App S&rver Node nApp41 DC 4Anp4f DC4App3 / DC3负载均衡设备：作为统一的客户端请求接入点，负责对应用路由控制 层的多台应用路由器进行请求分发，确保应用路由器间的负责均衡， 支持应用路由器的水平扩展，消除应用路由控制层的单点故障。管理

10、控制节点：是独立的节点，提供对整个动态集群环境（包括应用 路由层和动态集群）的管理配置及监控工具。应用路由控制层：由多台对等的应用路由器(App Router 1-m)组成。计算资源池：是由多台物理服务器(App Server Node 1-n)组成的共享计 算环境，上图中，该池中部署了 5 个动态集群( DC1 -DC5 ) ，并分别支 持5个应用(App1-App5)的运行。每个动态集群的实例数量不等。以下将详细阐述应用路由控制层和动态集群的主要功能3.2 应用路由控制层功能描述应用路由器前端采用负载均衡器统一接入客户端的请求，并分发到多个对 等的应用路由器实例。应用路由器实例可以了解到后

11、端动态集群环境中的应用 相关信息，包括应用的URL,起停状态，应用部署状况，支持应用运行的应用 服务器实例的相关信息等，这些信息是应用路由器进行路由的基础。对于接入的请求，应用路由器可以依据应用 U R L 、请求用户以及请求客户 端 IP 等对请求进行分类， 并能够能接收后端动态集群环境报告的应用服务器运 行状况，包括 CPU 和内存的利用率等，而且还可以记录请求的响应时间。基于 上述信息和动态集群环境中定义的服务级别管理策略，动态计算动态集群环境 中各个应用服务器的权重， 并基于请求对应的 URL 实现请求路由及动态负载均 衡，最后将动态集群环境返回的处理结果转发给其前端的负载均衡器。当不

12、同服务级别或优先级的请求出现资源竞争时，应用路由器基于流量的 控制，将优先通过服务级别或优先级高的请求，同时将服务级别或优先级相对 较低的请求缓存在相应的请求队列中， 待计算资源竞争解除后再进行路由转发。3.3 动态集群功能描述与静态集群相比，动态集群仅仅需定义集群包含的物理服务器，而无需定 义具体实例及固定的负载均衡权重。应用部署时，其发布的目标是动态集群， 而不在对应具体的物理服务器，在运行时，动态集群将依据预设策略及运行时 的状态动态决定应用运行状态，包括应用驻留的服务器和支持应用运行的应用 服务器实例数等。从而实现虚拟的运行环境，实现应用与运行环境之间的松耦 合。动态集群环境支持服务级

13、别的定义， 应包括基于响应时间和优先级的定义。 在运行时，动态集群环境将自动监控服务级别的策略的执行情况，并基于服务 级别，决定运行时，支持应用运行所启动的应用服务器实例数量，在系统计算 容量范围内，当支持的应用运行所启动的应用服务器实例不能满足服务级别要 求时，动态集群环境将自动为该应用启动额外的应用服务器实例；当支持应用 运行所启动的应用服务器实例在一定时间内（用户可自定义）处于不活动状态 时，动态集群环境将自动停止其服务， 以释放计算资源供其他应用使用。 由此， 通过自动化地控制支持应用运行的应用服务器实例的启动 /停止， 实现运行时计 算资源的动态调度。动态集群环境支持对应用服务器实例

14、运行状态健康性的定义，可以基于响 应时间、内存消耗以及处理请求数量等定义系统的健康状况，动态集群环境在 运行时将会基于这些预设的健康条件，监控应用服务器实例的运行状态，当应 用服务器实例出现违背健康性的定义的异常状况时，动态集群环境可以做出预 订的自动化响应，包括发 email 通知管理员，自动获取诊断信息、自动重启服 务器以及执行定制的任务 （如执行自定义的脚本） 。由此实现自动化的异常状况 处理。动态集群环境提供综合的日志记录，包括应用、资源以及工作负载等。通 过这些日志记录，可以进行应用运行趋势分析，同时可以统计出应用对计算资 源的利用率。4 基于 WebSphere Virtual E

15、nterprise 的应用服务器虚拟化平台方案4.1 WebSphere Virtual Enterprise 概述WebSphere Virtual Enterprise（以下简称 WVE）是 WebSphere产品家族中提 供Java EE应用动态虚拟化计算环境的核心产品。该产品基于WebSphere应用服务器，其部署方式是在 WebSphere应用服务器环境下，基于现有 WebSphere 应用服务器组件安装相应的 WVE组件，对WebSphere应用服务器原有功能进行扩展与增强。WVE包括如下组件:On Dema nd Router :以下简称ODR,实现应用路由控制节点的核心组 件；

16、WVE Deployment Manager:以下简称 WVE Dmgr，实现管理控制节点 的核心 组件，该组 件基于 WebSphere应用服 务器的 DeploymentMan ager；WVE Node Age nt: WVE Dmgr 通过 WVE Node Age nt 与 WVE AppServer进行通讯，发布各种管理命令， WVE Node Age nt也负责监控每 个节点中应用服务器的状态等。该组件基于 WebSphere应用服务器的Node Age nt;WVE App Server：增加了 WVE功能特性的 WebSphere应用服务器4.2基于 WVE方案的物理架构基于

17、WVE的应用服务器虚拟化平台方案物理架构示意图如下，应用路由控制层由一组ODR实现，管理控制节点由 WVE Dmgr实现；动态集群由WVEDynamic Cluster 实现。WVE组件部署WVE 的组件部署需要基于 WebSphere 应用服务器，因此在 ODR、WVEDmgr以及动态集群的节点上首先安装 WebSphere应用服务器，再安装WVE组 件。然后，在 WVE Dmgr节点上创建 WVE Dmgr类型的概要表（profile），在 ODR 及动态集群节点上创建用户自定义类型的概要表，并将这些节点加入到WVE Dmgr 的管理单元中。 之后，用户可通过 WVE Dmgr 的管理控制

18、台在 ODR 节点上创建ODR Server，在动态集群节点上创建动态集群。动态集群的构建通过 WVE Dmgr 管理控制台，用户可以灵活的定义动态集群。每个加入WVE Dmgr 管理单元的节点对应了一台硬件服务器，这些服务器构成了动态集 群所等利用的计算资源池。通常，创建动态集群时，用户主要需指定动态集群 对应的节点组（节点组中的每个节点通常对应一台物理服务器）以及在每个节 点允许启动的应用服务器实例数量。这些信息定义了该动态集群在计算资源池 中能够利用的计算资源的最大范围，之后，动态集群环境会依据该定义自动在 节点上创建的应用服务器实例。当在该动态集群部署应用后，该集群中的应用 服务器并不

19、一定全部启动，动态集群环境在运行时会依据服务策略及物理主机 的负载情况动态决定该集群中启动的应用服务器数量，从而实现计算资源的动 态调度。4.3 应用部署及服务策略定义对于 Java EE 的应用程序，其在动态集群上的部署过程基本上与在WebSphere应用服务器上的部署过程一致，区别仅在指定应用程序的映射目标 时，将目标指定为动态集群即可。WVE 使用服务策略来对客户端请求进行分类和优先级划分。 分类方式包括 客户请求的URI，客户端IP地址/端口，请求到达时间，HTTP Header信息， Cookie 等等。优先级包括从最低到最高，共七种。同时，服务策略是用户定义 的业务目标，目标类型可

20、以是任意、平均响应时间、百分点响应时间或排队等 待时间等。完整的服务策略将客户端请求进行分类、优先级划分与业务目标关 联起来，该策略将在 ODR 节点和 WVE 的动态工作负载管理组件和自主请求流 管理器得到执行。策略定义通常需要基于对应用程序及硬件计算资源的评估，来确定策略中的具体配置。用户可以通过 WVE Dmgr 提供的管理控制台进行应用程序的部署和服务策 略的定义。4.4 系统管理及监控WVE Dmgr提供的管理功能基于 WebSphere应用服务器Dmgr，因为可以 实现WebSphere应用服务器Dmgr的全部管理功能，提供统一的基于 Web的管 理控制台，在此基础上 WVE Dm

21、gr 还提供实现 WVE 特性的管理功能支持，包 括创建并维护动态集群、定义服务策略以及运行时动态监控等。管理通过管理 控制台可以完成对整个动态集群环境的管理和监控。通过管理控制台， WVE 可将动态集群设置为： 手工、受控和自动等三种操 作方式。其中，手工方式等同于静态集群；受控方式是指 WVE 在计划动态调 度计算资源时，会将动态调度任务提交给管理员，由管理员决策是否执行该任 务；自动方式是指完全依托 WVE 实现系统资源分配。管理员可以依据动态集 群部署应用的实际情况选择所需的操作方式。WVE Dmgr 提供了自动化的运行状况管理，可以持续地监视环境中服务器 的状态以及由这些服务器执行的

22、工作。通过 WVE Dmgr ，用户可以定义运行状 况策略，该策略规定了环境中需要监视的运行状况条件，以及在这些条件未得 到满足时要执行的运行状况操作。典型的条件包括：内存消耗、响应时间、请 求超时、服务器完成的工作量、堵塞检测以及、服务器的时效等。运行状况操 作定义运行状况条件未得到满足时， WVE 可以执行如下操作：重新启动服务器、 执行线程转储、执行 Java 虚拟机（ JVM ）堆转储、将服务器置于维护方式、 将服务器置于维护方式并中断 HTTP 请求与服务器的亲缘关系以及使服务器脱 离维护方式。通过自动化的运行状况管理可以大大简化运维工作。WVE Dmgr提供的管理控制台包含和Web

23、Sphere应用服务器管理控制台内 置的Tivoli PerformanceViewer，同时 WVE Dmgr管理控制台还可以通过实时、 有意义的可视化工具来管理复杂的系统操作并进行监控。通过运作警报工具， 可向用户通知环境中的任何问题，以便用户在必要时可以采取相应的措施。报 告工具提供了定制制图功能，支持诸如服务策略的执行状态、可用性、响应时 间、流量和吞吐量这样的统计信息。还提供了多种选项，用户可以根据这些选 项来创建各种图表，对系统进行实时的监控。同时，监控到的数据可以记录在 文本文件中，以便供其他制图程序复用，并可以根据这些历史数据执行容量规 划和计算资源试用的度量。此外， WVE

24、提供的监控功能还可以 ITCAM 进行集 成。4.5 可用性、扩展性及持久服务本方案具备良好的可用性及较高的可扩展性，按照应用路由控制层及动态 集群分别详述如下：应用路由控制层应用路由控制层由一组 ODR 实现，负载均衡设备可以感知 ODR 的运行状 况，当某一 ODR 出现故障时，负载均衡设备可自动将接收到的请求转发至其他 ODR，消除单点故障，并实现故障转移，同时ODR支持水平及垂直扩展，在运行时可以按需增加 ODR 节点或单一节点上 ODR 的实例数。动态集群对于动态集群， ODR 以及 WVE Node Agent 会感知每个应用服务器实例的 运行状态， 当某一应用服务器实例出现故障时

25、， 一方面 ODR 会自动将接收到的 请求转发至其他应用服务器实例， 另一方面， 基于健康检查策略， WVE 会自动 将出现故障的应用服务器移出生产环境， 进行相应的处理， 确保消除单点故障， 实现故障转移，并降低异常状况对整个生产环境的影响。同时，动态集群支持 水平及垂直扩展，每个动态集群对应一个节点组，节点组中的每个节点通常对 应一台物理服务器，动态集群在创建时，其规模已经扩展到了节点组的每个节 点上，在运行时，如需增加节点，仅需要将已部署 WVE 并创建了自定义类型 概要表的节点加入到节点组中即可， WVE 将自动在该节点上创建应用服务器实 例，部署应用并控制启动 /停止，从而实现无缝的

26、水平扩展。通过修改在每个服 务器上允许启动的应用服务器实例数，可实现应用服务器的垂直扩展。此外， WVE 还提供了基于动态集群的 “不间断服务” 的应用版本变更管理， 是动态集群更好地实现持久服务。4.6 安全性本方案的安全性依托于WebSphere应用服务器，即全部支持WebSphere应 用服务器提供的安全性功能。5 方案实施建议5.1 实施原则本方案要平衡业务稳定运行和创新的关系； 本方案建设要遵循利用现有硬件设备， 并和现有系统软件平台密切结合 的原则；本方案和现存的管理制度和运维方式的实际相结合； 本方案的实施要遵循整体规划， 分步骤实施， 分阶段、有选择地推进该 方案的应用范围。5

27、.2 实施步骤建议阶段一：方案验证及准备阶段本阶段的目标：通过概念验证，使用户深入了解并验证 WVE 动态集群的 功能和管理方式，同时为下一阶段的实施做必要的准备。本阶段的执行方式包括 IBM 和用户的技术交流会、 demo 演示、技术验证 Workshop 以及概念验证测试。由此，用户可以清晰地认识到 WVE 动态集群的 优势，以及 WVE 与现有环境的切合点。在此基础上， IBM 和用户将对现有应 用系统进行梳理，选择适于下一阶段实施的应用系统，并计划准备相应的硬件 环境。阶段二：试应用阶段 本阶段的目标：通过动态集群小规模的应用，在实际生产环境中，实践并 深入验证 WVE 动态集群方案，

28、解决实际应用中的意外问题，初步体现方案价 值，并使用户熟练掌握 WVE 动态集群的管理与维护。在本阶段，在保持原有静态集群环境不变的前提下，建议采用新购或原有的服务器3-4台组成计算资源池，在所有服务器上部署 WebSphere应用服务器 及WVE，创建动态集群基础环境。同时，在做好计算容量估算的提前下，选择 稳定性较好、关键性相对较低、访问峰值时间窗口和优先级各异的应用程序 2 3 个作为试用应用程序。在计算资源池内，为每个应用程序建立独立的动态 集群，并部署应用，定义应用的优先级，制定相对简单的服务策略（例如仅基 于平均相应时间的服务策略）。同时，基于WVE Dmgr的监控功能，对集群的

29、运行状况进行监控，并依据结果反复调整服务策略，使之不断优化。在此过程 中，还需要着重解决产生的实际问题，深入了解并掌握 WVE 的管理操作，并 积累相关经验。阶段三：静态集群与动态集群并行阶段本阶段的目标：通过进一步推进 WVE 的应用范围，显著提高系统的资源利用率，使服务级别管理得到更广泛应用，重要应用服务质量得到提高，同时针对“不稳定”应用进行运行状况监控及异常自动处理，实现简化运维工作。需要根据实际情况进行补充阶段四：统一的动态集群阶段本阶段的目标：在总结前三阶段经验的基础上，确定资源池划分策略，完善应用优先级评估，服务策略及运行控制策略制定的方法，构建统一的动态集群环境，实现计算资源最

30、大化的共享，实现业务需求导向的计算资源分配，并大幅简化运维工作。在本阶段，建议将全部应用迁移至动态集群环境 需要根据实际情况进行补充5.3 计算资源池规划建议计算资源指的是物理主机的逻辑组合，通常在动态集群环境下，通常一个 计算资源池会支持一组应用的运行，并且这一组应用仅仅运行与该计算资源池 上。因此，通过划分计算资源池，用户可以定义应用 /动态集群可以利用的计算 资源范围，即明确了应用 /动态集群可获得的计算能力，同时也实现了一定粒度的应用隔离。在规划计算资源池时，可以考虑如下划分标准：基于应用程序的稳定性在大规模应用动态集群的环境中，很难确保所有的应用程序都具备很高的 稳定性，通过依据应用

31、的不同稳定性等级划分资源池，有助于确保核心应用的 稳定性。例如，现有计算资源可划分为三个资源池，资源池一部署稳定的应用 程序，资源池二部署次稳定应用程序，资源池三部署“相对不稳定”或刚投入 生产的应用程序。此外，资源池的规模和部署的应用可以基于 WVE 的功能灵 活调整，例如，当“不稳定”应用经过修改运行趋于稳定后，可将其转到资源 池一或二，该过程仅需要通过配置即可完成。基于应用所属的业务部门依据不同的应用所属业务部门划分资源池，可以在部门间的应用之间进行 隔离，也可以明确各个部门最大使用的计算资源数量。当业务部门较多时，不 易划分过多的资源池，因为当资源池过多、粒度过细时，将影响计算资源的共 享。因此，也可将各个部门的应用分组进行部署。基于应用的重要性依据应用的重要性划分资源池，可以确保重要应用系统获得足够的计算资 源，并避免其他应用的影响。例如，现有计算资源可按照重要应用、次要应用 和一般应用划分为三资源池，重要应用分配的计算资源最多，其他两个依次递 减，该方式有助于确保重要应用的服务质量和运行的稳定性。5.4 应用部署建议应用部署时，其发布的目标是动态集群，而不在对应具体的物理服务器， 在运行时，动态集群将依据预设策略及运行时的状态动态决定应用运行