云平台应用系统迁移办法大纲

中国移动广东公司

UAP 云平台应用迁移方案

（大纲） 版本 目录

4.3.3

资源映射分析 .................................................................................................. 错误!未指定书签。

拟制 沈志华 日期 2014．07．16 审核 日期 批准 日期

6.4迁移后虚拟机的优化.............................................................................................. 错误!未指定书签。

1文档说明

本文档的目的在于为UAP云平台地市应用系统设计的一个迁移与整合方法，并对实际操作有指导和建议。

本文档主要针对广东移动UAP的地市应用系统迁移到UAP云平台。

2应用系统迁移方法

2.1 应用迁移与整合方法

根据以往丰富的项目经验，结合UAP云平台的具体业务特点，定制了一套数据迁移与整合的方法。本迁移与整合方法分为6个阶段，分别为系统评估与分析、方案设计、虚拟化环境准备、应用移植、测试验证和业务割接。

图2-1应用迁移与整合方法

?评估与分析

在系统评估与分析阶段，应确定迁移范围和目标，利用调查问卷、系统评估工具（MAP）和访谈等评估形式，对应用系统进行评估，分析和汇总系统需求，形成调研报告。

?方案设计

在方案设计阶段，针对项目范围内的物理服务器进行虚拟化适用性分析，设计迁移场景和云平台架构方案。在云平台方案设计的基础上，进行迁移顺序、迁移方法等内容的设计，形成总体迁移方案。

?虚拟化环境准备

在虚拟化环境准备阶段，应判断现有的UAP云平台环境是否能容纳被迁移的所有对象，以及，具体应检查计算资源、存储资源、网络资源以及数据库资源等，建立迁移所需的环境准备，如虚拟机、虚拟化网络等。

?应用移植

在系统移植阶段，应根据既定的迁移方案严格的执行应用系统迁移，将物理机的应用系统移植到虚拟机内，有工具移植和手工部署两种方式。

?测试验证

对云平台上的应用系统进行功能性测试、性能测试和稳定性测试，并进行应用验证，以便预先排除隐患，使得应用系统成功的运行在云平台环境下。

?业务割接

制定割接方案，依照割接方案进行割接操作，割接完成后进入割接后观察期，通过割接验收后将原系统下线。

应用系统在UAP云平台上线1个月后，提供性能分析报告。

2.2 应用迁移涉及的相关部门

业务迁移进行中，会涉及如下各部门，其具体职责如下：

?省公司信息系统部：；

?地市公司：

?应用开发商：负责实施UAP平台各应用系统日常的7×24小时故障响应处理工作，为UAP平台各应用系统的维护支撑提供技术支持。

?迁移实施方：

1)对应用系统进行评估和分析；

2)根据需求设计云平台方案，或者评估现有云平台方案是否满足需

求；

3)设计应用系统迁移方案，如迁移方式、迁移工具等；

4)进行应用系统迁移，将应用系统从物理机上移植到虚拟机上；

5)与应用开发商一起进行测试验证；

6)进行业务割接。

3系统评估与分析

如何对被迁移系统进行有效的系统评估，为迁移和整合提供有效的支撑数据，是迁移前重要的工作，也是迁移和整合过程中的一个难点。系统评估分析，将使用调查问卷、自动化评估工具或访谈等形式对系统的基础架构层和应用层进行系统评估。

3.1系统评估和分析流程

图3-1评估和分析流程

应用系统迁移评估与分析流程描述如下：

表3-1系统评估和分析流程

3.2评估准备

3.2.1迁移范围确定

应用系统迁移，首先要确定迁移范围，如：

?哪些应用系统需求从哪些服务器上迁移到UAP云平台虚拟机上；

?哪些应用系统需要进行解耦和整合等操作；

?迁移前后机房环境的变化确认等。

3.2.2评估方法与准备

采用调查问卷方式、评估工具自动化评估或访谈等方法对UAP应用系统进行评估和分析，从不同的维度获得全面的信息，为迁移工作提供有力依据。

调查问卷可以大规模的进行信息采集，收集各个层面的信息，范围较广，但是由于需要人工填写，人为因素将导致准确率不高。自动化评估工具可准确的对系统进行性能等方面的评估，准确率高，可信度大，但是适用范围有限，比如有些服务器由于客观原因无法被自动化工具评估。对于一些比较复杂的问题，可以采用深度访谈的方式，形成访谈报告，补充到文档中。

3.2.3评估环境的准备

使用具体评估工具进行自动化评估时，需要准备好相关主机、网络、以及MAP工具包等内容，以便顺利开展系统评估工作，详见附录中的具体评估工具需求。

3.3系统调研与评估

3.3.1物理基础架构调研与评估

在物理基础架构信息收集和评估中，计算容量、存储容量和网络容量以及相关的利用率和性能是重要的评估内容。自动化评估工具MAP可帮忙得出比较客观的物理架构的容量和性能，调查问卷也可协助完成信息收集。

物理基础架构的评估中，应完成如下内容的评估：

?在基础架构硬件的CPU评估中，应收集CPU的型号、主频、内核数、颗数，应评估CPU的利用率。

?在基础架构硬件的内存评估中，应收集内存的容量以及使用率。

?在基础架构硬件的磁盘评估中，应收集磁盘的数量、RAID方式、文件系统类型、文件系统总容量、磁盘IO性能等。

?在基础架构硬件的网络评估中，应收集物理服务器的网卡容量、数量及网络性能，网络交换机的型号、网口数、数量，基础架构的网络拓扑图等。

3.3.2应用系统调研与评估

在应用系统层面，至少应评估业务的重要性、业务成熟度、应用系统逻辑架构等内容，从而为迁移提供重要的参考依据。

3.3.2.1 业务重要性

在评估阶段，应评估应用系统的重要程度，利用应用系统的重要程度设置相关的资源竞争策略，并且对重要的应用系统采用相应的技术方案进行保护，如重要的应用系统可使用HA等技术方案保证业务连续性。

业务的重要性可作为虚拟机发生竞争时如何争取资源的一个重要输入。在虚拟机的资源竞争机制中，有最低占用资源设置、最高占用资源设置和相对权重。可根据业务的重要性设置相关的权重，比如可以设置重要业务权重为200，比较重要业务的权重是150，不重要的业务权重是100。需要注意的是具体虚拟机权重设计的时候一定要遵循一个统一的标准，保持前后连贯性。

3.3.2.2 业务生命周期

按照不同的业务成熟度为相关的虚拟机来预留资源，来满足业务发展所带来的需求。业务成熟度分为业务投入期、成长期、成熟期、衰退期，可按不同的成熟度为不同的业务系统进行预留空间等内容的设置。

在评估阶段，应评估业务的成熟度，业务成熟度可作为应用系统资源预留的一个重要衡量指标。可针对不同成熟度的业务提供不同的资源预留策略，比如成

熟业务预留50%资源，衰退业务预留25%，成长的业务预留75%资源，投入期业务预留50%资源。

3.3.2.3 应用系统逻辑架构

评估中，应对应用系统间的逻辑架构进行分析，从而判断各应用系统间的依赖关系和应用系统间的逻辑关系。应用系统的逻辑架构可为确定迁移依赖关系、迁移顺序和迁移后位置提供的有力参考。

3.3.3迁移对应用系统的影响

将应用系统从物理服务器迁移到虚拟化，从一个机房迁移到另外一个机房，这种迁移会对应用系统本身产生不同程度的影响。

在评估的内容中，还要注意一起其他内容的分析，如硬件依赖关系，即那些服务器依赖于某种特定的硬件。大部分的虚拟化环境无法满足特殊硬件的需求，如视频卡、音频卡、加密卡等硬件。

3.4 需求分析及汇总

基于对基础架构和应用系统现状的评估，结合业务的发展需要，对具体应用系统进行基础架构和应用系统两个层面的需求分析和汇总。

3.4.1基础架构需求分析与汇总

基础架构需求分析，需要整理所有应用系统的基础架构层面的需求，汇总整个所有业务系统所需要的基础架构需求，如网络、服务器、存储等，可用表格等形式汇总整个基础架构的需求。

3.4.2应用系统需求分析和汇总

在系统调研中，基于调查问卷和访谈的方式对应用系统进行调研与评估，对应用系统层面的需求进行需求分析和汇总，常见的应用层面需求分析如无单点故障、高可用性等，在评估阶段需要分析和汇总所有这些应用层面的需求进行汇总，以及业务的成熟度、重要性等内容，以便后续为后期云平台架构设计提供依据。4方案设计

在对物理应用系统进行评估后，进一步的工作是迁移到什么地方，目标平台是否满足迁移需求，如何进行迁移等。

4.1方案设计流程

图4-1方案设计阶段流程图

方案设计的流程描述如下：

表4-1方案设计阶段流程图说明

4.2云平台方案设计

在云平台的方案设计中，主要要考虑服务器、存储和网络基础架构的设计，要详细考虑具体架构、容量和性能的设计因素。

4.3迁移方案设计

4.3.1虚拟化适用性分析

在系统评估后，进一步细化了可迁移的服务器范围。虚拟化适用性判断阶段，应参考基础架构层和应用层的评估指标，明确哪些应用适用于虚拟化技术，哪些应用系统不适合虚拟化技术。

具体的指标如下但不限于以下指标：

?基础架构层的评估指标

◆不适合虚拟化的典型对象

?平均使用率高于70%的双处理器系统或平均使用率高于45%的四处理器系统

?需要特殊硬件(目前主流Hypervisor软件能够模拟的硬件只有CPU、内存、网卡、硬盘等，对于其他需要直接使用的PCI、PCI-x、PCI-E、AGP设备均无法正常支持，包括窄带卡、中继卡、3D卡、显卡、加

密卡、磁带机、infiniband、电信业务中特有的语音E1板卡等)的系

统

?平均网络带宽在600Mbps以上、平均IO在50MB/s以上、内存占有8GB以上的系统

◆适合虚拟化的典型对象

?硬件配置较低(<1.5GHz)的系统

?硬件配置相对较高、平均使用率一直偏低(小于20%)的系统

?应用层的评估指标

◆不适合虚拟化的典型对象

?运行CAD、CAM、PRoE等工程设计应用程序的系统

?运行音视频流媒体引用程序的系统

?大型数据库系统，如Oracle、DB2数据库软件

◆适合虚拟化的应用类型

?在不同的时间达到峰值使用率的应用

4.3.2迁移场景设计

在迁移方案设计时，应依据源迁移对象、目标场所等因素来设计迁移阶段的相关场景。

?过渡环境：进行应用系统的初步迁移，将数据中心的服务器首先迁移到本地的资源池，利用P2V、V2V和NewVM等迁移方式；

?测试环境：将本地资源池的业务服务器虚拟机迁移到测试环境，完成功能性和初步压力测试，利用虚拟机文件拷贝、V2V或自动化工具等迁移方式；

?验证环境：将云平台的业务服务器虚拟机迁移到验证环境，完成近似真实环境的压力测试，利用虚拟机文件拷贝、V2V或自动化工具等迁移方式；

?生产环境：将验证环境平台虚拟机迁移到生产云平台环境，云平台环境中承载应用系统运行，利用虚拟机文件拷贝、V2V或自动化工具等迁移方式；

不同平台有各自的用途，各自的设计需求也不同：

?过渡环境，临时性迁移场所；

?测试环境，主要进行业务功能、性能等方面的压力测试的场所，不需要虚拟化高级功能，虚拟化单机版软件即可满足

?验证环境，将采用与生产云近似的技术，进行上线前的真实场景模拟测试?生产环境，未来应用系统的生产环境，需要使用高级的技术手段来保证实际业务系统的连续性、可扩展性等功能，从而使得业务系统能健康运行。

4.3.3资源映射分析

在迁移后的资源需求设计中，即对物理资源的需求映射为对虚拟资源的需求，应具体到CPU、内存、硬盘和网络细颗粒度级别。

?对于CPU资源，虚拟机CPU的主频与物理机主频一样大，一个虚拟机

vCPU对应一个物理机CPU的核，而一个物理CPU的核可以供多个虚拟机vCPU使用。物理CPU到虚拟机CPU的转换性能损耗很小，大概5%以内。

?对于内存资源，物理机内存到虚拟机内存的转换损耗较小，不同的虚拟化软件有不同的内存管理方式，有些使用内存固定分配机制，有些使用内存过量分配机制（overcommit，即虚拟机的内存容量可超过物理机的内存容量）。

?对于存储资源，物理系统到虚拟系统的损耗较大，设计虚拟系统请尽量加大物理系统的带宽，对于虚拟机的磁盘容量可选取按需分配模式。

?对于网络资源，物理机网络性能到虚拟机系统的损耗较小，但是设计时应充分考虑到网络复用，以及虚拟化系统中网络的资源竞争设置较弱等因

素。

4.3.4服务器放置设计

源物理服务器到目标虚拟机的映射关系是将应用系统物理服务器与UAP云平台的物理机进行映射，从而确定应用系统整合后所寄宿的物理主机。设计一个好的映射关系可以保证应用系统具有充足的物理资源的容量和性能，并保证业务应用系统具有良好的高可用性等高级功能，是应用系统迁移重要的一环。

设计应用系统到服务器映射关系应遵从如下原则：

?性能均衡原则，将低性能和高性能的服务器组合放在一台物理服务器内，比如低IO与高IO服务器搭配，低CPU使用率与高CPU使用率搭配

?容量均衡原则，将低容量和高容量的应用系统组合放置在一台服务器内

?业务重要性均衡原则，即将低重要性的应用系统和高重要性的应用系统组合放置在一台服务器内，从而保证重要的应用系统在资源发生竞争的时候仍然能获得足够的资源（本生产环境的云平台系统中，所有物理服务器具有相同的重要级别，故可按业务重要性均衡原则。如在其他系统中，云平台服务器有重要级别差异，则将业务重要性高的应用系统放置在重要性高的服务器上。）

?同一业务的应用系统尽量放置于一台服务器上，从而减少物理网络带宽的占用，并保持网络的稳定性

?不同业务高峰的应用系统组合放置于一台物理服务器内

4.3.5资源竞争关系设计

虚拟机资源竞争策略取决于两个因素，第一因素是资源设置，第二因素是资源控制。资源设置层面设置虚拟CPU、内存、网卡容量等。资源控制分为如下几个部分：

?CPU资源控制

?最小保留（百分比或者Hz）

?最大限制（百分比或者Hz）

?相对权重（具体数字，如100、150、200等）

?内存资源控制

?最小保留（百分比或者GB）

?最大限制（百分比或者GB）

?相对权重（相对具体数字，如100、150、200等）

?磁盘IO性能资源控制

?相对权重（相对具体数字，如100、150、200等）

?网络IO性能资源控制

?相对权重（相对具体数字，如100、150、200等）

在相对权重设计中，应考虑全局，根据业务系统的重要性设置应用系统的权重，以便迁移后虚拟机可按相对权重获得相应的资源竞争机会。

4.3.6迁移顺序设计

根据业务应用系统间的依赖关系及应用系统本身的特性设计整个系统的迁移顺序。对P2V迁移过程，被迁移应用系统可分为独立应用系统、被依赖的应用系统、堆叠应用系统：

?独立应用系统，是指该物理主机上只有一个应用系统，并且与其他应用系统没有任何依赖关系。

?被依赖应用系统，是指该应用系统被其他应用系统所依赖，如数据库等。

?依赖应用系统，是指该应用系统依赖于其他应用系统。

?堆叠应用系统，是指物理主机上有多个应用系统，这些应用系统间或者有依赖关系或者没有依赖关系。

在实际迁移中，建议应由难而易，由复杂到简单，从而能更好的完成所有的迁移工作。建议遵从如下迁移顺序：

?被依赖的应用系统优先，数据库等被迁移系统先进行迁移

?应用依赖关系系统

?独立应用的系统

?应用堆叠的应用系统

5虚拟化环境准备

根据需求进行虚拟环境的准备，为应用移植搭建好环境，从而更顺利的进行应用系统迁移。

5.1虚拟化环境准备步骤

图5-1虚拟化环境准备步骤

5.2虚拟化环境准备与方案设计

5.2.1环境确认

在环境确认中，应确认如下环境是否准备就位，以便顺利进行项目实施。

?确认需要的网络资源是否就绪；

?确认需要的存储资源是否就绪；

?确认需要的计算资源是否就绪；

?确认需要的数据库资源是否就绪

5.2.2实施规划与设计方案

项目实施前应制定详细的实施规划与设计方案，包括但不限于如下内容：?U AP云平台及业务系统组网设计

?U AP云平台及业务系统存储系统设计

?U AP云平台实施详细规划及具体参数设计

?虚拟机设置参数，如虚拟机硬盘等

?外围环境设计，如域控制等

5.3UAP云平台实施

依据云平台实施规划与设计方案进行项目实施，严格遵从中国移动相关标准及广东移动相关标准，严格按照项目管理的要求。

5.3.1虚拟化系统设置与调试

在虚拟化系统配置与调试中，包括如下内容：

?H yper-V管理软件的高级功能配置，如HA、动态迁移等高级功能，以满足业务的具体需要

?存储的相应配置

?网络虚拟化的相应配置，建立虚拟交换机，并与物理网卡及物理网络联调5.3.2虚拟机系统设置

云平台物理和虚拟环境搭建好后，应创建相应的虚拟机，安装操作系统，按需安装相应的应用系统软件，制作相关的模板。

6应用迁移

应用系统迁移首先将应用系统从物理服务器移植到虚拟机上，可直接在虚拟机上重新部署或者移植应用系统，也可将物理机利用迁移工具转换为虚拟机。

6.1迁移实施流程

图6-1应用系统迁移实施流程

6.2迁移环境准备

迁移环境准备是迁移前最重要的工作，包括人员、网络环境、迁移技术手段、迁移工具等内容的准备。

1，应用系统迁移前，相关人员应准备就绪

?迁移实施方：负责具体迁移工作

?应用系统开发商：负责具体应用的部署和测试

?网络系统管理员：负责网络的通信和连接情况

?系统管理员：负责虚拟化环境的准备和资源提供，原物理服务器的密码等信息提供；

?备份管理员：对重要的数据和应用进行迁移前备份；

2，确认UAP云平台具有足够的CPU、内存、存储和网络资源满足被迁移系统的需求。

3，迁移前，对重要的数据和应用系统进行必要的备份，以防迁移过程中有意外的情况发生。

6.3迁移执行

在迁移执行阶段，须严格执行制定的迁移方案和迁移流程。

6.4迁移后虚拟机的优化

在应用系统迁移到云平台环境后，应对虚拟机作出相关的设置调整，以满足更好的业务服务需求，具体调整可参考如下几点（不限于）：

?消除不必要的虚拟硬件设备

?按需求适当增加或者减少虚拟资源配置，比如调整或者减少处理器和内存等设置

?设置资源竞争相关参数，如设置虚拟机最小、最大CPU可用资源，及发生竞争时的竞争权重等

?调整虚拟机磁盘空间大小，满足应用系统的发展需求

7测试验证

应用系统应该做好充分的测试与验证，为业务割接做好准备工作。

7.1应用系统测试验证流程

图7-1应用系统迁移测试流程

7.2应用系统测试验证内容

首先测试在UAP平台虚拟机上的应用系统是否具有与物理服务器相同的功能，然后对应用系统进行功能性测试、性能测试、稳定性测试，并对有问题的地方进行初步优化，最后进行应用系统验证，保证应用系统顺利割接。

7.3应用系统测试

对被迁移的应用系统通过创建测试用例和测试脚本，选择合适的测试数据和测试样例，确认迁移数据在应用系统迁移到云平台环境后的有效性，进行有计划的测试，并在测试结果基础上生成报告。

功能性测试对云平台的业务应用系统进行功能性测试，并与物理服务器进行对比，确保应用系统在平台迁移后所有功能工作正常，可采用手工测试或者自动化测试工具。对于迁移后应用系统，重点测试虚拟环境下对应用业务的影响，对于新的业务系统，需要进行完整的业务逻辑性测试。

在性能测试中，主要采用压力软件在压力机上对应用系统进行压力测试，或者采用人工脚本进行压力性测试，从而衡量应用系统对虚拟机系统的资源消耗及由此产生的对物理机的资源消耗，从而更好的掌握应用系统的性能需求，验证云平台是否能满足业务系统的性能需求。