中间件虚拟化平台方案

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

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

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

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

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

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

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

8、别管理，支持基于服务级别的计算资源调度；l 提供对系统的实时监控及自动化管理，实现对系统异常的自动化处理；l 提供运行状况报告及应用系统对计算资源的使用状况报告。3 应用服务器虚拟化平台功能及逻辑架构3.1 功能及架构概述本方案提供了完整的应用服务器虚拟化平台环境，包括了统一接入客户端请求的负载均衡设备，管理控制节点，应用路由控制层，计算资源池以及由其承载的应用/动态集群组，应用服务器动态集群环境逻辑架构示意图如下：l 负载均衡设备：作为统一的客户端请求接入点，负责对应用路由控制层的多台应用路由器进行请求分发，确保应用路由器间的负责均衡，支持应用路由器的水平扩展，消除应用路由控制层的单点故障。

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

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

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

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

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

14、述WebSphere Virtual Enterprise（以下简称WVE）是WebSphere产品家族中提供Java EE应用动态虚拟化计算环境的核心产品。该产品基于WebSphere应用服务器，其部署方式是在WebSphere应用服务器环境下，基于现有WebSphere应用服务器组件安装相应的WVE组件，对WebSphere应用服务器原有功能进行扩展与增强。WVE包括如下组件：l On Demand Router：以下简称ODR，实现应用路由控制节点的核心组件；l WVE Deployment Manager：以下简称WVE Dmgr，实现管理控制节点的核心组件，该组件基于WebSpher

15、e应用服务器的Deployment Manager；l WVE Node Agent：WVE Dmgr通过WVE Node Agent与WVE App Server进行通讯，发布各种管理命令，WVE Node Agent也负责监控每个节点中应用服务器的状态等。该组件基于WebSphere应用服务器的Node Agent；l WVE App Server：增加了WVE功能特性的WebSphere应用服务器。4.2 基于WVE方案的物理架构基于WVE的应用服务器虚拟化平台方案物理架构示意图如下，应用路由控制层由一组ODR实现，管理控制节点由WVE Dmgr实现；动态集群由WVE Dynamic C

16、luster实现。l WVE组件部署WVE的组件部署需要基于WebSphere应用服务器，因此在ODR、WVE Dmgr以及动态集群的节点上首先安装WebSphere应用服务器，再安装WVE组件。然后，在WVE Dmgr节点上创建WVE Dmgr类型的概要表（profile），在ODR及动态集群节点上创建用户自定义类型的概要表，并将这些节点加入到WVE Dmgr的管理单元中。之后，用户可通过WVE Dmgr的管理控制台在ODR节点上创建ODR Server，在动态集群节点上创建动态集群。l 动态集群的构建通过WVE Dmgr管理控制台，用户可以灵活的定义动态集群。每个加入WVE Dmgr管理单

17、元的节点对应了一台硬件服务器，这些服务器构成了动态集群所等利用的计算资源池。通常，创建动态集群时，用户主要需指定动态集群对应的节点组（节点组中的每个节点通常对应一台物理服务器）以及在每个节点允许启动的应用服务器实例数量。这些信息定义了该动态集群在计算资源池中能够利用的计算资源的最大范围，之后，动态集群环境会依据该定义自动在节点上创建的应用服务器实例。当在该动态集群部署应用后，该集群中的应用服务器并不一定全部启动，动态集群环境在运行时会依据服务策略及物理主机的负载情况动态决定该集群中启动的应用服务器数量，从而实现计算资源的动态调度。4.3 应用部署及服务策略定义对于Java EE的应用程序，其在

18、动态集群上的部署过程基本上与在WebSphere应用服务器上的部署过程一致，区别仅在指定应用程序的映射目标时，将目标指定为动态集群即可。WVE使用服务策略来对客户端请求进行分类和优先级划分。分类方式包括客户请求的URI，客户端IP地址/端口，请求到达时间，HTTP Header信息，Cookie等等。优先级包括从最低到最高，共七种。同时，服务策略是用户定义的业务目标，目标类型可以是任意、平均响应时间、百分点响应时间或排队等待时间等。完整的服务策略将客户端请求进行分类、优先级划分与业务目标关联起来，该策略将在ODR节点和WVE的动态工作负载管理组件和自主请求流管理器得到执行。策略定义通常需要基于

19、对应用程序及硬件计算资源的评估，来确定策略中的具体配置。用户可以通过WVE Dmgr提供的管理控制台进行应用程序的部署和服务策略的定义。4.4 系统管理及监控WVE Dmgr提供的管理功能基于WebSphere应用服务器Dmgr，因为可以实现WebSphere应用服务器Dmgr的全部管理功能，提供统一的基于Web的管理控制台，在此基础上WVE Dmgr还提供实现WVE特性的管理功能支持，包括创建并维护动态集群、定义服务策略以及运行时动态监控等。管理通过管理控制台可以完成对整个动态集群环境的管理和监控。通过管理控制台，WVE可将动态集群设置为：手工、受控和自动等三种操作方式。其中，手工方式等同于

20、静态集群；受控方式是指WVE在计划动态调度计算资源时，会将动态调度任务提交给管理员，由管理员决策是否执行该任务；自动方式是指完全依托WVE实现系统资源分配。管理员可以依据动态集群部署应用的实际情况选择所需的操作方式。WVE Dmgr提供了自动化的运行状况管理，可以持续地监视环境中服务器的状态以及由这些服务器执行的工作。通过WVE Dmgr，用户可以定义运行状况策略，该策略规定了环境中需要监视的运行状况条件，以及在这些条件未得到满足时要执行的运行状况操作。典型的条件包括：内存消耗、响应时间、请求超时、服务器完成的工作量、堵塞检测以及、服务器的时效等。运行状况操作定义运行状况条件未得到满足时，WV

21、E可以执行如下操作：重新启动服务器、执行线程转储、执行 Java 虚拟机（JVM）堆转储、将服务器置于维护方式、将服务器置于维护方式并中断 HTTP请求与服务器的亲缘关系以及使服务器脱离维护方式。通过自动化的运行状况管理可以大大简化运维工作。WVE Dmgr提供的管理控制台包含和WebSphere应用服务器管理控制台内置的Tivoli PerformanceViewer，同时WVE Dmgr管理控制台还可以通过实时、有意义的可视化工具来管理复杂的系统操作并进行监控。通过运作警报工具，可向用户通知环境中的任何问题，以便用户在必要时可以采取相应的措施。报告工具提供了定制制图功能，支持诸如服务策略的

22、执行状态、可用性、响应时间、流量和吞吐量这样的统计信息。还提供了多种选项，用户可以根据这些选项来创建各种图表，对系统进行实时的监控。同时，监控到的数据可以记录在文本文件中，以便供其他制图程序复用，并可以根据这些历史数据执行容量规划和计算资源试用的度量。此外，WVE提供的监控功能还可以ITCAM进行集成。4.5 可用性、扩展性及持久服务本方案具备良好的可用性及较高的可扩展性，按照应用路由控制层及动态集群分别详述如下：l 应用路由控制层应用路由控制层由一组ODR实现，负载均衡设备可以感知ODR的运行状况，当某一ODR出现故障时，负载均衡设备可自动将接收到的请求转发至其他ODR，消除单点故障，并实现

23、故障转移，同时ODR支持水平及垂直扩展，在运行时可以按需增加ODR节点或单一节点上ODR的实例数。l 动态集群对于动态集群，ODR以及WVE Node Agent会感知每个应用服务器实例的运行状态，当某一应用服务器实例出现故障时，一方面ODR会自动将接收到的请求转发至其他应用服务器实例，另一方面，基于健康检查策略，WVE会自动将出现故障的应用服务器移出生产环境，进行相应的处理，确保消除单点故障，实现故障转移，并降低异常状况对整个生产环境的影响。同时，动态集群支持水平及垂直扩展，每个动态集群对应一个节点组，节点组中的每个节点通常对应一台物理服务器，动态集群在创建时，其规模已经扩展到了节点组的每个

24、节点上，在运行时，如需增加节点，仅需要将已部署WVE并创建了自定义类型概要表的节点加入到节点组中即可，WVE将自动在该节点上创建应用服务器实例，部署应用并控制启动/停止，从而实现无缝的水平扩展。通过修改在每个服务器上允许启动的应用服务器实例数，可实现应用服务器的垂直扩展。此外，WVE还提供了基于动态集群的“不间断服务”的应用版本变更管理，是动态集群更好地实现持久服务。4.6 安全性本方案的安全性依托于WebSphere应用服务器，即全部支持WebSphere应用服务器提供的安全性功能。5 方案实施建议5.1 实施原则l 本方案要平衡业务稳定运行和创新的关系；l 本方案建设要遵循利用现有硬件设备

25、，并和现有系统软件平台密切结合的原则；l 本方案和现存的管理制度和运维方式的实际相结合；l 本方案的实施要遵循整体规划，分步骤实施，分阶段、有选择地推进该方案的应用范围。5.2 实施步骤建议l 阶段一：方案验证及准备阶段本阶段的目标：通过概念验证，使用户深入了解并验证WVE动态集群的功能和管理方式，同时为下一阶段的实施做必要的准备。本阶段的执行方式包括IBM和用户的技术交流会、demo演示、技术验证 Workshop以及概念验证测试。由此，用户可以清晰地认识到WVE动态集群的优势，以及WVE与现有环境的切合点。在此基础上，IBM和用户将对现有应用系统进行梳理，选择适于下一阶段实施的应用系统，并

26、计划准备相应的硬件环境。l 阶段二：试应用阶段本阶段的目标：通过动态集群小规模的应用，在实际生产环境中，实践并深入验证WVE动态集群方案，解决实际应用中的意外问题，初步体现方案价值，并使用户熟练掌握WVE动态集群的管理与维护。在本阶段，在保持原有静态集群环境不变的前提下，建议采用新购或原有的服务器3-4台组成计算资源池，在所有服务器上部署WebSphere应用服务器及WVE，创建动态集群基础环境。同时，在做好计算容量估算的提前下，选择稳定性较好、关键性相对较低、访问峰值时间窗口和优先级各异的应用程序23个作为试用应用程序。在计算资源池内，为每个应用程序建立独立的动态集群，并部署应用，定义应用的

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

28、定资源池划分策略，完善应用优先级评估，服务策略及运行控制策略制定的方法，构建统一的动态集群环境，实现计算资源最大化的共享，实现业务需求导向的计算资源分配，并大幅简化运维工作。在本阶段，建议将全部应用迁移至动态集群环境需要根据实际情况进行补充5.3 计算资源池规划建议计算资源指的是物理主机的逻辑组合，通常在动态集群环境下，通常一个计算资源池会支持一组应用的运行，并且这一组应用仅仅运行与该计算资源池上。因此，通过划分计算资源池，用户可以定义应用/动态集群可以利用的计算资源范围，即明确了应用/动态集群可获得的计算能力，同时也实现了一定粒度的应用隔离。在规划计算资源池时，可以考虑如下划分标准：l 基于

29、应用程序的稳定性在大规模应用动态集群的环境中，很难确保所有的应用程序都具备很高的稳定性，通过依据应用的不同稳定性等级划分资源池，有助于确保核心应用的稳定性。例如，现有计算资源可划分为三个资源池，资源池一部署稳定的应用程序，资源池二部署次稳定应用程序，资源池三部署“相对不稳定”或刚投入生产的应用程序。此外，资源池的规模和部署的应用可以基于WVE的功能灵活调整，例如，当“不稳定”应用经过修改运行趋于稳定后，可将其转到资源池一或二，该过程仅需要通过配置即可完成。l 基于应用所属的业务部门依据不同的应用所属业务部门划分资源池，可以在部门间的应用之间进行隔离，也可以明确各个部门最大使用的计算资源数量。当

30、业务部门较多时，不易划分过多的资源池，因为当资源池过多、粒度过细时，将影响计算资源的共享。因此，也可将各个部门的应用分组进行部署。l 基于应用的重要性依据应用的重要性划分资源池，可以确保重要应用系统获得足够的计算资源，并避免其他应用的影响。例如，现有计算资源可按照重要应用、次要应用和一般应用划分为三资源池，重要应用分配的计算资源最多，其他两个依次递减，该方式有助于确保重要应用的服务质量和运行的稳定性。5.4 应用部署建议应用部署时，其发布的目标是动态集群，而不在对应具体的物理服务器，在运行时，动态集群将依据预设策略及运行时的状态动态决定应用运行状态，包括应用驻留的服务器和支持应用运行的应用服务器实例数等。在应