虚拟化建设方案

第1章 项目需求分析

1.1 项目建设目标

服务器资源主要为消防总队各应用系统配置计算存储资源，保证消防总队业务系统平稳高效运行。项目建设，要求满足各业务的部署策略，要能适应应用业务需求扩充与资源部署变更的发展需要，充分保证计算存储资源的高可用性、可靠性和良好的可扩充性，科学发挥计算存储资源的利用效率与可管理效能。

计算存储和网络项目的建设目标为：

1、建设能够满足消防总队各应用系统运行要求的计算存储资源基础设施系统，满足业务系统平稳高效地运行。

2、建设有充分扩展性能的计算存储资源基础设施系统。

3、运用各种先进的信息技术，为建立现代化的消防业务系统提供先进稳定可靠的计算存储资源。

1.2 项目建设原则

消防总队计算存储建设坚持一体化原则，做到合理化、规范化和科学化，以应用为先导、统一规划，集中管理，在满足应用系统架构设计需求和业务数据对计算存储资源功能和性能需求的前提下，结合信息化技术的发展趋势，通过资源的统一分配和部署，适度通过虚拟化，最大化的提高资源的利用率和复用率，满足应用业务需求扩充与资源部署变更的发展需要。

项目须遵循如下设计原则：

1、满足金消防总队业务系统运行需要

这是项目设计的根本原则，也是技术和设备选择的最重要依据，任何技术、设备的采用都不应偏离这一原则。

2、支持计算存储资源动态管理和扩展

按照应用系统的需求，提供动态可调整的计算存储资源，通过合理规划、技术集成，将纯技术的设备分配转化为建设能够适应业务发展的资源池。

3、兼顾成熟性和先进性

规划设计时应采用成熟的主流技术，保证系统投入运行后的稳定性、高可靠性、安全性，以此降低系统建设的风险，同时适当采用先进技术，以应对业务技术不断发展变化的需要。

4、开放性

在消防总队基础设施规划中，采用的各类技术和设备要符合开放性要求，并提供较好的易用性、可维护性。

5、兼容性

计算存储系统对通用的硬件设备、软件产品应具有较强的兼容性。

6、降低运行维护成本

规划设计不仅要考虑初期的一次性投资，也要考虑后续的运行维护费用，使总体费用控制在一个合理的水平，保证系统的持续运行。要具有良好的性能价格比，以保护和节约投资。

1.3 项目建设规模

按照虚拟化刀片服务器数量，配备所有CPU的虚拟化软件产品使用许可。包括防火墙、灾难恢复、容量规划管理、工作流和自动化平台、虚拟机基础门户平台等组件许可。

虚拟化资源整合全部软件必须支持Windows Server 2012数据中心版、MS Windows Sever 2008数据中心版(32位和位)、MS Windows Sever 2003(32位和位)、和SUSE Linux 11.0、RedHat 6.0、Oracle Enterprise Linux 6.0以上位操作系统。

第2章 虚拟化资源规划方案

2.1 虚拟化产品概述

虚拟化内核平台

运行在基础设施层和上层操作系统之间的“元”操作系统，用于协调上层操作系统对底层硬件资源的访问，减轻软件对硬件设备以及驱动的依赖性，同时对虚拟化运行环境中的硬件兼容性、高可靠性、高可用性、可扩展性、性能优化等问题进行加固处理。

虚拟化管理系统

主要实现对数据中心内的计算、网络和存储等硬件资源的软件虚拟化，形成虚拟资源池，对上层应用提供自动化服务。其业务范围包括：虚拟计算、虚拟网络、虚拟存储、高可靠性（HA）、动态资源调度（DRS）、云主机容灾与备份、云主机模板管理、集群文件系统、虚拟交换机策略等。

采用虚拟化平台对多台服务器虚拟化后，连接到共享存储，构建成计算资源池，通过网络按需为用户提供计算资源服务。同一个资源池内的云主机可在资源池内的物理服务器上动态漂移，实现资源的动态调配。

建成后的虚拟化系统，虚拟机之间安全隔离；虚拟机可以实现物理机的全部功能；兼容主要服务器厂商的主流X86服务器、主流存储阵列产品、运行在X86服务器上的主流操作系统，并支持主流应用软件的运行。

2.2 裸金属架构设计

∙X86服务器虚拟化技术是在一个物理服务器上并行运行具有不同操作系统的虚拟机，而每个虚拟机都拥有一套的虚拟硬件（如CPU、内存、网卡、磁盘等）。其原理是把PC服务器资源转化成逻辑计算资源，通过对物理计算资源的逻辑划分，使应用系统安全、高效、隔离的运行，提高资源利用率。

∙

∙虚拟化对传统的物理服务器而言，在以下三个方面突破了传统的应用模式：

∙1）它是一个抽象层，它将物理硬件和操作系统分离，从而提供更高的IT资源利用率和灵活性。

∙2）虚拟化允许具有不同操作系统的多个虚拟机在同一实体机上并行运行。每个虚拟机都有自己的一套虚拟硬件，可以在这些虚拟硬件上加载操作系统和应用程序。无论实际采用了什么物理硬件组件，操作系统都将它们视为一组标准化的硬件。

∙3）虚拟机被封装在文件中，因此可以快速对其进行保存、复制和部署。可在几秒钟内将整个系统（完全配置的应用程序、操作系统、BIOS和虚拟硬件）从一台物理服务器迁移至另一台物理服务器，以实现零停机维护和连续的工作负载整合。

∙由于虚拟架构使操作系统摆脱了和底层硬件驱动之间的紧耦合关系，操作系统和上层应用可在计算资源池内平滑迁移，为应用系统提供具有高性能计算能力、安全稳定、灵活的硬件承载平台。X86服务器虚拟化体系结构主流的有两种：寄居架构和裸金属架构，其架构如下图所示：

∙寄居架构就是在操作系统之上安装和运行虚拟化程序，依赖于主机操作系统对设备的支持和物理资源的管理。因为虚拟化软件运行在主机操作系统之上，因此效率低、可靠性不高，主要应用于桌面级应用。

∙裸金属架构是直接在硬件上面安装虚拟化软件，再在其上安装虚拟机的操作系统和应用。虚拟化软件本身就是一个微内核，因为直接运行在主机硬件之上，效率高、可靠性高。

∙虚拟化管理平台采用裸金属架构 ，同时借助硬件辅助虚拟化（Intel VT或AMD V的技术），可以充分发挥服务器CPU、内存、IO性能，虚拟化管理平台的服务器性能消耗不超过1%。

2.3 结构化资源池设计

∙为了提升虚拟化系统的可靠性，在虚拟化平台的计算资源池建设时，可以将多个物理主机合并为一个具有共享资源池的集群。虚拟化软件管理系统的HA功能组件会监控该集群下所有的主机和物理主机内运行的虚拟机。当物理主机发生故障，出现宕机时，HA功能组件会立即响应并在集群内另一台主机上重启该物理主机内运行的虚拟机。当某一虚拟服务器发生故障时，HA功能也会自动的将该虚拟机重新启动来恢复中断的业务。

∙在搭建服务器资源池之前，首先应该确定资源池的数量和种类，并对服务器进行归类。归类的标准通常是根据服务器的CPU类型、型号、配置、物理位置来决定。对云计算平台而言，属于同一个资源池的服务器，通常就会将其视为一组可互相替代的资源。所以，一般都是将相同处理器、相近型号系列并且配置与物理位置接近的服务器——比如相近型号、物理距离不远的机架式服务器或者刀片服务器。在做资源池规划的时候，也需要考虑其规模和功用。如果单个资源池的规模越大，可以给云计算平台提供更大的灵活性和容错性：更多的应用可以部署在上面，并且单个物理服务器的宕机对整个资源池的影响会更小些。但是同时，太大的规模也会给出口网络吞吐带来更大的压力，各个不同应用之间的干扰也会更大。如果有条件的话，通常推荐先审视一下自身的业务应用。可以考虑将应用分级，将某些级别高的应用尽可能地放在某些而规模较小的资源池内，辅以较高级别的存储设备，并配备高级别的运维值守。而那些级别比较低的应用，则可以被放在那些规模较大的公用资源池（群）中。

∙初期的资源池规划应该涵盖所有可能被纳管到云计算平台的所有服务器资源，包括那些为搭建云计算平台新购置的服务器、内部那些目前闲置着的服务器以及那些现有的并正在运行着业务应用的服务器。在云计算平台搭建的初期，那些目前正在为业务系统服务的服务器并不会直接被纳入云计算平台的管辖。但是随着云计算平台的上线和业务系统的逐渐迁移，这些服务器也将逐渐地被并入云计算平台的资源池中。

∙虚拟化管理平台体系将云计算资源池的物理服务器资源以树形结构进行组织管理，云资源中的被管理对象之间的关系可以用下图描述：

∙虚拟化管理平台能够将资源池的物理服务器或虚拟服务器进一步按资源池划分，一个资源池可包含多个子资源池和/或虚拟机，便于分级分层结构化管理虚拟化资源。

2.4 虚拟化高可靠设计

2.4.1 虚拟化集群HA设计

∙高可用性包括两个方面：

1.虚拟机之间的隔离：每个虚拟机之间可以做到隔离保护，其中一个虚拟机发生故障不会影响同一个物理机上的其他虚拟机；

2.物理机发生故障不会影响应用：故障物理机上运行的虚拟机可被自动迁移接管，即虚拟机可以在同一集群内的多台服务器之间进行迁移，从而实现多台物理服务器的之间的相互热备，实现当其中一个物理服务器发生故障时，自动将其上面的虚拟机切换到其他的服务器，应用在物理机宕机情况下保证零停机。虚拟机的迁移需要依赖共享存储。

∙

2.4.2 虚拟化在线迁移设计

∙在同一个集群下的物理服务器之间可进行虚拟机的在线迁移，即将正在运行中的虚拟机从一台物理机器或存储设备上搬移到另一台，而业务不中断；迁移方式分手动迁移与自动迁移，手动迁移及在物理服务器均在线情况下进行虚拟机的迁移工作，而自动迁移是指在集群内出现故障宕机情况下系统自行调配，已下对两种手段的范围、内容及赢下加以分析：

2.4.3 虚拟化在线热添加设计

∙对于对外提供服务的虚拟机，虚拟化管理平台能够根据业务需要在线不宕机的情况下调整虚拟机的CPU、内存、网卡、磁盘，从而保证更优的性能进行稳定支撑。

2.4.4 虚拟化动态资源调配设计

∙动态资源调度功能可以持续不断地监控计算资源池的各物理主机的利用率，并能够根据用户业务的实际需要，智能地在计算资源池各物理主机间给虚拟机分配所需的计算资源。通过自动的动态分配和平衡计算资源，动态资源调整特性能够：整合服务器，降低IT成本，增强灵活性；减少停机时间，保持业务的持续性和稳定性；减少需要运行服务器的数量，提高能源的利用率。

∙动态资源调度功能组件可以自动并持续地平衡计算资源池中的容量，可以动态的将云主机迁移到有更多可用计算资源的主机上，以满足虚拟机对计算资源的需求。即便大量运行SQL Server的虚拟机，只要开启了动态资源调整功能，就不必再对CPU和内存的瓶颈进行一一监测。全自动化的资源分配和负载平衡功能，也可以显著地提升数据中心内计算资源的利用效率，降低数据中心的成本与运营费用。

∙

∙如上图所示，动态资源调整功能通过心跳机制，定时监测集群内主机的CPU利用率，并根据用户自定义的规则来判断是否需要为该主机在集群内寻找有更多可用资源的主机，以将该主机上的云主机迁移到另外一台具有更多合适资源的服务器上。

2.4.5 虚拟化动态资源扩展DRX设计

∙DRX解决方案依托虚拟化管理平台实现。虚拟化管理平台监控承载特定业务虚拟服务器组的负载状况，并根据业务负载的状况联动虚拟化管理平台实现资源的动态扩展与伸缩。

∙DRX解决方案主要提供以下关键功能：

∙用户业务的负载监控

∙通过基础业务负载监控模块监控运行于其虚拟化平台上的虚拟服务器的实际资源负载状况；

∙用户通过虚拟化管理平台创建资源扩展业务时，可以设定好业务负载的上下限阀值；

∙当业务负载超出用户事先设定的阀值后，业务负载监控模块给业务资源调度模块上报资源扩展事件，以触发业务资源的弹性扩展（包括资源的动态伸缩）；

∙基于用户业务负载的动态资源扩展

∙虚拟化管理平台上可以创建业务动态资源扩展业务，支撑该业务的所有虚拟服务器进行统一的集中管理；

∙为了防止同一个业务无限占用云平台内的资源，DRX解决方案将同一个业务的资源扩展范围限定在一个特定的物理资源池内（包括服务器和存储资源），即后续虚拟服务器的增加和回收均在该物理资源池内进行；

∙接收到业务负载监控模块上报的资源扩展事件后，业务资源调度模块会在限定的物理资源池内选择负载最轻的一台物理服务器上通过启动当前已经存在的虚拟服务器或者克隆创建一台新的虚拟服务器的方式，以扩展该业务的支撑资源；

∙业务负载自动分发

∙通过集成的负载均衡设备可以将业务请求分发到新创建的虚拟服务器中，以实现对业务负载的分担；

∙动态资源扩展业务信息展示

∙虚拟化管理平台上提供丰富的动态资源扩展业务的各种信息展示，以便于运维人员掌握当前某特定业务的资源部署状况和各虚拟服务器的运行状况（如“业务资源CPU使用状况”、“TOP 5虚拟服务器CPU利用率”等）。

∙DRX解决方案整合了基础业务负载监控平台、资源调度平台、业务分发系统和展示平台，可以针对用户业务负载的变化自动的增减相应IT资源。从而较有效的实现信息中心业务访问量的突发性变化和对应的信息中心IT资源的供给的动态平衡，提升IT基础架构的有效使用率和调度灵活性。其具有以下功能特点。

面向业务：基于用户业务承载状况实现业务实际所需资源的动态调度。

业务资源的动态弹性扩展：支持业务资源的动态弹性伸缩，实现IT资源供给和业务需求的动态平衡。

统一的资源扩展业务展示平台：统一的资源扩展业务展示，方便运维人员掌握当前资源部署和运行状况。

∙面向应用的云动态资源扩展解决方案和用户业务更加紧密的融合，可以更有效的实现用户业务突发性需求和信息中心IT资源供给的动态平衡。希望通过整合更丰富的业务负载监控平台和业务负载分发平台来增强对用户业务实际负载的识别感知能力和业务负载分发的准确度，从而进一步增强整体解决方案的适用范围和效果。

2.4.6 虚拟机关联与反关联设计

∙虚拟化管理平台支持在同一个物理机或跨物理机的虚拟机集群，支持虚拟机-虚拟机、虚拟机-主机的关联与反关联功能，能够保证在一个负载均衡/故障转移组内的不同虚拟机运行在不同的物理主机上，同时也支持将特定虚拟机群组固定运行与特定的物理服务器上。

2.5 虚拟机资源分配设计

1.虚拟机CPU分配原则：

♦尽量使用最少的vCPUs，如果是单线程应用，无需多线程处理。

♦虚拟CPU数量不要等于或超过物理CPU核数，如双路双核的服务器配置，虚机最多使用两个虚拟CPU

2.内存分配原则：

♦内存总量为在资源评估后，计算虚拟机评估结果所需实际内存尽量避免大于物理内存的总和。因为应用程序而产生的更多内存需要用磁盘内存来解决，会导致系统性能下降。

∙如需要P2V迁移，在进行虚拟化迁移之前，应对每个应用系统虚拟化迁移后所需的虚拟计算进行合理的评估和计算，以确保迁移后应用系统的可用性、可靠性和各项性能指标可满足业务目标。

∙虚拟资源计算的原则是，如果客户希望业务系统迁移后，业务系统能够保持与原系统一致的体验，我们建议虚拟机的计算能力与原物理服务器的计算能力保持一致；如果客户希望通过P2V的迁移，提高资源的利用率，我们建议虚拟机的计算能力可以相比原先进行一定程度的压缩，具体的压缩计算方式如下图所示。

第3章 虚拟化实施与迁移方案

3.1 新应用系统建设与部署

∙新建业务系统上线部署之前，需要进行充分的评估和分析，以确认最合适的部署方式，具体评估流程如下图所示。

图表91 新业务系统建设与部署评估流程图

∙流程说明：

1.是否对硬件有特殊需求：IT 系统需采用加密机等特殊硬件。

2.是否对操作系统有特殊需求：IT 系统需采用除UNIX、Linux、Windows 之外的特殊操作系统平台。

3.是否能够共享已有的平台：系统可以与已有系统共享已分配的虚拟化资源，且资源需求能够满足。

4.选择相应的操作系统镜像：根据IT 系统需求选择操作系统，包括UNIX、Linux、Windows。

5.虚拟化适用性矩阵：评估IT 系统是否适合运行在虚拟化环境，对于不同的服务器可参考下图来评估其是否适合虚拟化，对于给定的应用，可以根据系统预期的硬件利用率和需求以及用户的数量决定是否适合虚拟化。

6.虚拟化整合指标：对于IT系统的虚拟化而言，业务压力、系统I/O 吞吐量、系统资源利用率是服务器虚拟化比例( 虚拟机与物理机之比)的主要参考依据：

a)高整合比例(如10:1) ：对业务压力小的服务器，例如非实时数据采集服务器、防病毒服务器、接口服务器、备份服务器等。

b)中等整合比例(如4:1) ：对业务压力中等的服务器，例如中小型IT 系统的数据库服务器、应用服务器(安全接入认证服务器、系统监控服务器等)、邮件服务器等。

c)低整合比例(如2:1) ：对业务压力较大且内容敏感类应用的服务器，例如大型数据库服务器数据传输服务器、高性能运算服务器、业务逻辑复杂的应用服务器、安全性要求高的服务器、对物理隔离有特殊要求的服务器等。

7.物理平台适用性矩阵：对于的IT 系统而言，可以按下图选择最佳的技术配置方案。

3.2 老应用系统迁移建设咨询

∙为帮助客户顺利的实现应用系统的虚拟化建设，我们提供专业的虚拟化咨询服务。对当前运行在传统架构下的应用系统及IT基础架构现状进行充分的调研和分析，并提供云化IT基础架构的规划与设计。为客户将业务系统从传统架构转移至云架构提供有效的技术支撑。

∙咨询服务主要包含如下内容：

3.3.1 应用迁移方法

∙应用迁移是为了将现有应用平滑迁移到虚拟化平台，应分三个步骤来实施：

1.分析、设计及建设阶段

∙收集基础设施新建、改造、扩容需求。

∙识别和定义必需的运维、技术架构功能组件：包括技术规范、服务器架构、数据库服务/ 基础服务、并发处理能力、存储容量及增长趋势、SLA、故障响应时间、变更管理等等。

∙快速建设支持测试验证的环境，包括基础网络、存储和服务器环境。

2.测试阶段

∙包括组件功能性测试、组件集成性测试和组件性能测试。

∙功能型测试：包括应用功能模块测试、高可靠性测试、数据备份测试等；

∙组件集成性测试：包括系统各模块间数据交互，与其他系统间数据交互，系统安全保障要求，设备故障恢复时间等；

∙组件性能测试：包括系统响应测试，负荷峰值，数据交换吞吐量等。

3.迁移及扩展

∙制定完善的迁移方案、充分的实施方案、良好的应急预案等，最后实施迁移。

3.3.2 应用迁移流程

∙已有应用要迁移到虚拟化平台需要各个线条对应用系统进行梳理，具体梳理的主要内容如下表所示：

∙具体流程图的说明如下：

1.迁移到云平台：将IT 系统迁移到云平台，使用虚拟化资源或物理资源( 例如虚拟服务器、虚拟存储、虚拟网络)，并采用统一运营管理平台进行管理。

2.改造后迁移：对系统架构、运行环境、接口等进行改造，使其满足迁移到云平台的技术要求，然后再迁移到云平台。

3.保持现状：继续保持IT 系统当前的运行环境，包括基础设施直至IT 系统退役。

4.系统是否会长期使用：该系统是否还将继续长期使用，如是否还会继续使用超过一年。

5.系统是否存在故障隐患：该系统是否存在验证的故障隐患，如数据安全、架构缺陷等。

6.设备利用率是否在60% 与80% 之间：该系统是否能够有效的利用基础设施硬件资源，如CPU 利用率、存储利用率过低或过高。

7.同时在线用户比例是否大于等于50% ：该系统用户的平均使用率(平均使用率指总体而言，同时在线的用户占全部预期用户的比例)大于等于50%。

8.系统是否随着压力增长而扩展：该系统是否能够进行平滑扩展以满足预期内或预期外的业务需求。

9.系统是否能够移植：该系统是否能够消除隐患以进行移植，并满足业务使用需求。

10.是否有能力进行系统迁移及测试：该系统维护团队是否有足够的能力对系统进行测试及迁移。

11.系统是否近期停用：该系统是否由于技术原因或业务的原因在近期将被停用。

12.是否有业务驱动力进行系统迁移：该系统是否有足够的业务驱动力进行系统移植。

13.是否能够进行虚拟化：该系统平台是否有合适的技术支持虚拟化。

14.是否有业务驱动力进行虚拟化：该系统是否有足够的业务驱动力对基础设施( 服务器或存储) 进行虚拟化。

15.系统是否支持快速移植：该系是否能够进行快速移植。

16.是否有业务驱动力进行系统移植：该系统是否有足够的业务驱动力进行应用移植。

17.是否有业务驱动力进行平台转换：该系统是否有足够的业务驱动力进行平台转换。

3.3.3 应用迁移方式选型

∙应用系统迁移需要根据系统类型和重要性选择合适的迁移方式，而对于复杂系统的迁移，需要根据实际情况采用定制化的迁移技术及方法：

1.重新安装：IT 系统相关文档、安装流程齐全，在虚拟化环境中重新部署IT 系统再进行数据迁移。

2.镜像快照：在某个时间点对系统进行快照，在虚拟化环境中恢复快照。

3.虚拟化迁移：物理服务器到虚拟机的实时迁移(P2V)。

∙通过网络设备将需要迁移的业务网络与云平台实现二层的互通。有选择的分批次的迁移服务器，将业务从原物理服务器迁移到新平台的虚拟机上。

∙在业务迁移后，服务器网络属性配置保持不变(如IP 地址/VLAN 等等)，业务依然通过老平台承载。通过依次迁移服务器的网关，防火墙的安全策略，以及在云平台发布相应的路由，最终实现业务通过云平台承载。

∙整个的迁移过程对业务来说几乎是透明的，应用不需要修改任何参数。

∙虚拟化迁移是指把源主机上的操作系统和应用程序通过离线或在线的方式移动到目标虚拟化主机上，并且能够在目标虚拟化主机上正常运行。

∙在实施虚拟化迁移的过程中，我们除了要关注迁移过程的可靠性，还需要关注迁移的性能，即迁移的时间和对业务系统的影响，虚拟化迁移的性能指标包括以下三个方面：

⏹整体迁移时间：从源主机开始迁移到迁移结束的时间

⏹业务停机时间：迁移过程中，源主机、目标主机同时不可用的时间

⏹对应用程序的性能影响：迁移对于源主机上运行服务性能的影响程度。

∙虚拟化迁移的目标是最小化整体迁移的时间和业务停机时间，并且将迁移对于源主机上运行服务的性能造成的影响降至最低。在迁移过程中，这几个因素互相影响，我们将针对不同的业务场景和客户需求，进行充分和专业的评估与分析，并设计合理的和定制化的迁移方案，以达到预期的目标。