最新云平台应用系统迁移方案大纲资料.doc

《最新云平台应用系统迁移方案大纲资料.doc》由会员分享，可在线阅读，更多相关《最新云平台应用系统迁移方案大纲资料.doc（25页珍藏版）》请在三一办公上搜索。

1、Gan sentence the 細鎬 Hui Hai 鍝 ?The 鎷呬繚鏈熼棿Xuan 嵏The Lu 繍鍗曞彿The 鍐涗簨鐗祦鏍囩The Yue 氱墝鍖呰Does the 鍐 go crazy 棌鍖 ?The Ma 愬姏鍒嗘瀽The 鑳屾寕闆 happy 鐩 ? 文件编号： 密级： 项目ID： 项目编号： 中国移动广东公司UAP云平台应用迁移方案（大纲）版本 拟制沈志华日期20140716审核日期批准日期目录1文档说明42应用系统迁移方法42.1应用迁移与整合方法42.2应用迁移涉及的相关部门53系统评估与分析63.1系统评估和分析流程73.2评估准备83.2.1迁移范围确定83.2.

2、2评估方法与准备93.2.3评估环境的准备93.3系统调研与评估93.3.1物理基础架构调研与评估93.3.2应用系统调研与评估103.3.3迁移对应用系统的影响113.4需求分析及汇总113.4.1基础架构需求分析与汇总113.4.2应用系统需求分析和汇总114方案设计114.1方案设计流程124.2云平台方案设计134.3迁移方案设计134.3.1虚拟化适用性分析134.3.2迁移场景设计144.3.3资源映射分析154.3.4服务器放置设计164.3.5资源竞争关系设计174.3.6迁移顺序设计175虚拟化环境准备185.1虚拟化环境准备步骤195.2虚拟化环境准备与方案设计195.2.

3、1环境确认195.2.2实施规划与设计方案195.3UAP云平台实施205.3.1虚拟化系统设置与调试205.3.2虚拟机系统设置206应用迁移206.1迁移实施流程216.2迁移环境准备216.3迁移执行226.4迁移后虚拟机的优化227测试验证227.1应用系统测试验证流程227.2应用系统测试验证内容237.3应用系统测试237.4系统优化237.5应用系统验证248应用系统割接248.1应用系统割接流程248.2割接评估248.3割接准备258.4割接操作258.5回退机制258.6割接后观察258.7原系统删除269附录269.1MAP性能评估工具实施文档269.2典型案例261 文

4、档说明本文档的目的在于为UAP云平台地市应用系统设计的一个迁移与整合方法，并对实际操作有指导和建议。本文档主要针对广东移动UAP的地市应用系统迁移到UAP云平台。2 应用系统迁移方法2.1 应用迁移与整合方法根据以往丰富的项目经验，结合UAP云平台的具体业务特点，定制了一套数据迁移与整合的方法。本迁移与整合方法分为6个阶段，分别为系统评估与分析、方案设计、虚拟化环境准备、应用移植、测试验证和业务割接。图2-1 应用迁移与整合方法 评估与分析在系统评估与分析阶段，应确定迁移范围和目标，利用调查问卷、系统评估工具（MAP）和访谈等评估形式，对应用系统进行评估，分析和汇总系统需求，形成调研报告。 方

5、案设计在方案设计阶段，针对项目范围内的物理服务器进行虚拟化适用性分析，设计迁移场景和云平台架构方案。在云平台方案设计的基础上，进行迁移顺序、迁移方法等内容的设计，形成总体迁移方案。 虚拟化环境准备在虚拟化环境准备阶段，应判断现有的UAP云平台环境是否能容纳被迁移的所有对象，以及，具体应检查计算资源、存储资源、网络资源以及数据库资源等，建立迁移所需的环境准备，如虚拟机、虚拟化网络等。 应用移植在系统移植阶段，应根据既定的迁移方案严格的执行应用系统迁移，将物理机的应用系统移植到虚拟机内，有工具移植和手工部署两种方式。 测试验证对云平台上的应用系统进行功能性测试、性能测试和稳定性测试，并进行应用验证

6、，以便预先排除隐患，使得应用系统成功的运行在云平台环境下。 业务割接制定割接方案，依照割接方案进行割接操作，割接完成后进入割接后观察期，通过割接验收后将原系统下线。应用系统在UAP云平台上线1个月后，提供性能分析报告。2.2 应用迁移涉及的相关部门业务迁移进行中，会涉及如下各部门，其具体职责如下： 省公司信息系统部：； 地市公司： 应用开发商：负责实施UAP平台各应用系统日常的724小时故障响应处理工作，为UAP平台各应用系统的维护支撑提供技术支持。 迁移实施方：1) 对应用系统进行评估和分析；2) 根据需求设计云平台方案，或者评估现有云平台方案是否满足需求；3) 设计应用系统迁移方案，如迁移

7、方式、迁移工具等；4) 进行应用系统迁移，将应用系统从物理机上移植到虚拟机上；5) 与应用开发商一起进行测试验证；6) 进行业务割接。3 系统评估与分析如何对被迁移系统进行有效的系统评估，为迁移和整合提供有效的支撑数据，是迁移前重要的工作，也是迁移和整合过程中的一个难点。系统评估分析，将使用调查问卷、自动化评估工具或访谈等形式对系统的基础架构层和应用层进行系统评估。3.1 系统评估和分析流程图3-1 评估和分析流程应用系统迁移评估与分析流程描述如下：表3-1 系统评估和分析流程编号步骤名称责任人说明3.1确定迁移范围q 确定要迁移的应用系统，及未来的数据中心等内容3.2选择评估方法q 选择自动

8、化工具评估（MAP）、问卷调查、访谈等评估方法3.3准备评估环境和内容q 准备好被评估系统的网络、MAP服务器等内容q 准备好调查问卷的调查问题和访谈的具体内容3.4系统评估迁移实施方q 对系统进行评估，使用问卷调研、自动化工具评估、访谈等形式3.5问卷调研迁移实施方q 采用调查问卷的方式进行调研3.6自动化工具评估迁移实施方q 采用自动化评估工具进行系统评估3.7访谈迁移实施方q 采用访谈的方式进行调研3.8需求分析迁移实施方q 对应用系统进行整体需求分析3.9基础架构层评估迁移实施方q 对被评估系统进行基础架构层面的具体评估和信息汇总3.10应用层面评估迁移实施方q 对被评估系统进行应用层

9、面评估和信息汇总3.11业务层信息汇总迁移实施方q 对被评估系统进行业务层信息汇总3.12运维层信息汇总迁移实施方q 对被评估系统进行运维信息需求汇总3.13现状调研及需求分析报告迁移实施方q 根据调研内容，撰写现状调研及需求分析报告3.14调研报告审核q 对现状调研及需求分析报告进行审核3.15判断是否通过审核q 如通过审核，则结束调研和分析流程结束q 如未通过审核，则返回3.23.2 评估准备3.2.1 迁移范围确定应用系统迁移，首先要确定迁移范围，如： 哪些应用系统需求从哪些服务器上迁移到UAP云平台虚拟机上； 哪些应用系统需要进行解耦和整合等操作； 迁移前后机房环境的变化确认等。3.2

10、.2 评估方法与准备采用调查问卷方式、评估工具自动化评估或访谈等方法对UAP应用系统进行评估和分析，从不同的维度获得全面的信息，为迁移工作提供有力依据。调查问卷可以大规模的进行信息采集，收集各个层面的信息，范围较广，但是由于需要人工填写，人为因素将导致准确率不高。自动化评估工具可准确的对系统进行性能等方面的评估，准确率高，可信度大，但是适用范围有限，比如有些服务器由于客观原因无法被自动化工具评估。对于一些比较复杂的问题，可以采用深度访谈的方式，形成访谈报告，补充到文档中。3.2.3 评估环境的准备使用具体评估工具进行自动化评估时，需要准备好相关主机、网络、以及MAP工具包等内容，以便顺利开展系

11、统评估工作，详见附录中的具体评估工具需求。3.3 系统调研与评估3.3.1 物理基础架构调研与评估在物理基础架构信息收集和评估中，计算容量、存储容量和网络容量以及相关的利用率和性能是重要的评估内容。自动化评估工具MAP可帮忙得出比较客观的物理架构的容量和性能，调查问卷也可协助完成信息收集。物理基础架构的评估中，应完成如下内容的评估： 在基础架构硬件的CPU评估中，应收集CPU的型号、主频、内核数、颗数，应评估CPU的利用率。 在基础架构硬件的内存评估中，应收集内存的容量以及使用率。 在基础架构硬件的磁盘评估中，应收集磁盘的数量、RAID方式、文件系统类型、文件系统总容量、磁盘IO性能等。 在基

12、础架构硬件的网络评估中，应收集物理服务器的网卡容量、数量及网络性能，网络交换机的型号、网口数、数量，基础架构的网络拓扑图等。3.3.2 应用系统调研与评估在应用系统层面，至少应评估业务的重要性、业务成熟度、应用系统逻辑架构等内容，从而为迁移提供重要的参考依据。3.3.2.1 业务重要性在评估阶段，应评估应用系统的重要程度，利用应用系统的重要程度设置相关的资源竞争策略，并且对重要的应用系统采用相应的技术方案进行保护，如重要的应用系统可使用HA等技术方案保证业务连续性。业务的重要性可作为虚拟机发生竞争时如何争取资源的一个重要输入。在虚拟机的资源竞争机制中，有最低占用资源设置、最高占用资源设置和相对

13、权重。可根据业务的重要性设置相关的权重，比如可以设置重要业务权重为200，比较重要业务的权重是150，不重要的业务权重是100。需要注意的是具体虚拟机权重设计的时候一定要遵循一个统一的标准，保持前后连贯性。3.3.2.2 业务生命周期按照不同的业务成熟度为相关的虚拟机来预留资源，来满足业务发展所带来的需求。业务成熟度分为业务投入期、成长期、成熟期、衰退期，可按不同的成熟度为不同的业务系统进行预留空间等内容的设置。在评估阶段，应评估业务的成熟度，业务成熟度可作为应用系统资源预留的一个重要衡量指标。可针对不同成熟度的业务提供不同的资源预留策略，比如成熟业务预留50%资源，衰退业务预留25%，成长的

14、业务预留75%资源，投入期业务预留50%资源。3.3.2.3 应用系统逻辑架构评估中，应对应用系统间的逻辑架构进行分析，从而判断各应用系统间的依赖关系和应用系统间的逻辑关系。应用系统的逻辑架构可为确定迁移依赖关系、迁移顺序和迁移后位置提供的有力参考。3.3.3 迁移对应用系统的影响将应用系统从物理服务器迁移到虚拟化，从一个机房迁移到另外一个机房，这种迁移会对应用系统本身产生不同程度的影响。在评估的内容中，还要注意一起其他内容的分析，如硬件依赖关系，即那些服务器依赖于某种特定的硬件。大部分的虚拟化环境无法满足特殊硬件的需求，如视频卡、音频卡、加密卡等硬件。3.4 需求分析及汇总基于对基础架构和应

15、用系统现状的评估，结合业务的发展需要，对具体应用系统进行基础架构和应用系统两个层面的需求分析和汇总。3.4.1 基础架构需求分析与汇总基础架构需求分析，需要整理所有应用系统的基础架构层面的需求，汇总整个所有业务系统所需要的基础架构需求，如网络、服务器、存储等，可用表格等形式汇总整个基础架构的需求。3.4.2 应用系统需求分析和汇总在系统调研中，基于调查问卷和访谈的方式对应用系统进行调研与评估，对应用系统层面的需求进行需求分析和汇总，常见的应用层面需求分析如无单点故障、高可用性等，在评估阶段需要分析和汇总所有这些应用层面的需求进行汇总，以及业务的成熟度、重要性等内容，以便后续为后期云平台架构设计

16、提供依据。4 方案设计在对物理应用系统进行评估后，进一步的工作是迁移到什么地方，目标平台是否满足迁移需求，如何进行迁移等。4.1 方案设计流程图4-1 方案设计阶段流程图方案设计的流程描述如下：表4-1方案设计阶段流程图说明编号步骤名称责任人说明4.1虚拟化适用性分析迁移实施方q 依据系统调研与需求分析报告，对物理服务器进行虚拟化筛选4.2迁移场景设计迁移实施方q 依据系统调研与需求分析报告，进行云平台系统迁移场景设计4.3判断是否存在现有环境迁移实施方q 如存在现有云环境，则进入4.4q 如不存在云环境，则进入4.64.4判断现有环境是否满足需求迁移实施方q 如满足，则进入4.9q 如不满足

17、，则进入4.54.5云平台整改方案迁移实施方q 根据实际业务需求，对现有环境进行方案整改设计4.6云平台建设方案迁移实施方q 根据实际业务需求，设计云平台建设方案4.7方案审核q 对云平台整改方案或云平台建设方案进行审核4.8判断方案是否通过审核q 如通过，则进入到4.9q 如未通过，则回退到4.14.9资源映射分析迁移实施方q 将应用系统对物理资源的需求映射为对虚拟系统的资源需求，具体到需要几个vCPU等内容4.10服务器放置设计迁移实施方q 设计将迁移后的虚拟机如何放置在不同的云平台服务器上4.11迁移顺序设计迁移实施方q 设计应用系统具体的迁移顺序4.12迁移技术手段选择迁移实施方q 依

18、据应用系统的各自特点，选择合适的技术手段，如使用手工迁移还是使用工具进行迁移4.13迁移方法选择迁移实施方q 选择合适的迁移工具及迁移方式4.14迁移方案迁移实施方q 设计总体的迁移方案，形成文档4.15迁移方案审核q 对迁移方案进行审核4.16判断迁移方案是否通过审核q 如通过审核，则结束方案设计q 如未通过审核，则回退到4.84.2 云平台方案设计在云平台的方案设计中，主要要考虑服务器、存储和网络基础架构的设计，要详细考虑具体架构、容量和性能的设计因素。4.3 迁移方案设计4.3.1 虚拟化适用性分析在系统评估后，进一步细化了可迁移的服务器范围。虚拟化适用性判断阶段，应参考基础架构层和应用

19、层的评估指标，明确哪些应用适用于虚拟化技术，哪些应用系统不适合虚拟化技术。具体的指标如下但不限于以下指标：q 基础架构层的评估指标 u 不适合虚拟化的典型对象 平均使用率高于70%的双处理器系统或平均使用率高于45%的四处理器系统 需要特殊硬件(目前主流Hypervisor软件能够模拟的硬件只有CPU、内存、网卡、硬盘等，对于其他需要直接使用的PCI、PCI-x、PCI-E、AGP设备均无法正常支持，包括窄带卡、中继卡、3D卡、显卡、加密卡、磁带机、infiniband、电信业务中特有的语音E1板卡等)的系统 平均网络带宽在600Mbps以上、平均IO在50MB/s以上、内存占有8GB以上的系

20、统u 适合虚拟化的典型对象 硬件配置较低(1.5GHz)的系统 硬件配置相对较高、平均使用率一直偏低(小于 20%)的系统q 应用层的评估指标u 不适合虚拟化的典型对象 运行CAD、CAM、PRoE等工程设计应用程序的系统 运行音视频流媒体引用程序的系统 大型数据库系统，如Oracle、DB2数据库软件u 适合虚拟化的应用类型 在不同的时间达到峰值使用率的应用4.3.2 迁移场景设计在迁移方案设计时，应依据源迁移对象、目标场所等因素来设计迁移阶段的相关场景。 过渡环境：进行应用系统的初步迁移，将数据中心的服务器首先迁移到本地的资源池，利用P2V、V2V和New VM等迁移方式； 测试环境：将本

21、地资源池的业务服务器虚拟机迁移到测试环境，完成功能性和初步压力测试，利用虚拟机文件拷贝、V2V或自动化工具等迁移方式； 验证环境：将云平台的业务服务器虚拟机迁移到验证环境，完成近似真实环境的压力测试，利用虚拟机文件拷贝、V2V或自动化工具等迁移方式； 生产环境：将验证环境平台虚拟机迁移到生产云平台环境，云平台环境中承载应用系统运行，利用虚拟机文件拷贝、V2V或自动化工具等迁移方式；不同平台有各自的用途，各自的设计需求也不同： 过渡环境，临时性迁移场所； 测试环境，主要进行业务功能、性能等方面的压力测试的场所，不需要虚拟化高级功能，虚拟化单机版软件即可满足 验证环境，将采用与生产云近似的技术，进

22、行上线前的真实场景模拟测试 生产环境，未来应用系统的生产环境，需要使用高级的技术手段来保证实际业务系统的连续性、可扩展性等功能，从而使得业务系统能健康运行。4.3.3 资源映射分析在迁移后的资源需求设计中，即对物理资源的需求映射为对虚拟资源的需求，应具体到CPU、内存、硬盘和网络细颗粒度级别。 对于CPU资源，虚拟机CPU的主频与物理机主频一样大，一个虚拟机vCPU对应一个物理机CPU的核，而一个物理CPU的核可以供多个虚拟机vCPU使用。物理CPU到虚拟机CPU的转换性能损耗很小，大概5%以内。 对于内存资源，物理机内存到虚拟机内存的转换损耗较小，不同的虚拟化软件有不同的内存管理方式，有些使

23、用内存固定分配机制，有些使用内存过量分配机制（overcommit，即虚拟机的内存容量可超过物理机的内存容量）。 对于存储资源，物理系统到虚拟系统的损耗较大，设计虚拟系统请尽量加大物理系统的带宽，对于虚拟机的磁盘容量可选取按需分配模式。 对于网络资源，物理机网络性能到虚拟机系统的损耗较小，但是设计时应充分考虑到网络复用，以及虚拟化系统中网络的资源竞争设置较弱等因素。4.3.4 服务器放置设计源物理服务器到目标虚拟机的映射关系是将应用系统物理服务器与UAP云平台的物理机进行映射，从而确定应用系统整合后所寄宿的物理主机。设计一个好的映射关系可以保证应用系统具有充足的物理资源的容量和性能，并保证业务

24、应用系统具有良好的高可用性等高级功能，是应用系统迁移重要的一环。设计应用系统到服务器映射关系应遵从如下原则： 性能均衡原则，将低性能和高性能的服务器组合放在一台物理服务器内，比如低IO与高IO服务器搭配，低CPU使用率与高CPU使用率搭配 容量均衡原则，将低容量和高容量的应用系统组合放置在一台服务器内 业务重要性均衡原则，即将低重要性的应用系统和高重要性的应用系统组合放置在一台服务器内，从而保证重要的应用系统在资源发生竞争的时候仍然能获得足够的资源（本生产环境的云平台系统中，所有物理服务器具有相同的重要级别，故可按业务重要性均衡原则。如在其他系统中，云平台服务器有重要级别差异，则将业务重要性高

25、的应用系统放置在重要性高的服务器上。） 同一业务的应用系统尽量放置于一台服务器上，从而减少物理网络带宽的占用，并保持网络的稳定性 不同业务高峰的应用系统组合放置于一台物理服务器内4.3.5 资源竞争关系设计虚拟机资源竞争策略取决于两个因素，第一因素是资源设置，第二因素是资源控制。资源设置层面设置虚拟CPU、内存、网卡容量等。资源控制分为如下几个部分： CPU资源控制 最小保留（百分比或者Hz） 最大限制（百分比或者Hz） 相对权重（具体数字，如100、150、200等） 内存资源控制 最小保留（百分比或者GB） 最大限制（百分比或者GB） 相对权重（相对具体数字，如100、150、200等）

26、磁盘IO性能资源控制 相对权重（相对具体数字，如100、150、200等） 网络IO性能资源控制 相对权重（相对具体数字，如100、150、200等）在相对权重设计中，应考虑全局，根据业务系统的重要性设置应用系统的权重，以便迁移后虚拟机可按相对权重获得相应的资源竞争机会。4.3.6 迁移顺序设计根据业务应用系统间的依赖关系及应用系统本身的特性设计整个系统的迁移顺序。对P2V迁移过程，被迁移应用系统可分为独立应用系统、被依赖的应用系统、堆叠应用系统： 独立应用系统，是指该物理主机上只有一个应用系统，并且与其他应用系统没有任何依赖关系。 被依赖应用系统，是指该应用系统被其他应用系统所依赖，如数据库

27、等。 依赖应用系统，是指该应用系统依赖于其他应用系统。 堆叠应用系统，是指物理主机上有多个应用系统，这些应用系统间或者有依赖关系或者没有依赖关系。在实际迁移中，建议应由难而易，由复杂到简单，从而能更好的完成所有的迁移工作。建议遵从如下迁移顺序： 被依赖的应用系统优先，数据库等被迁移系统先进行迁移 应用依赖关系系统 独立应用的系统 应用堆叠的应用系统5 虚拟化环境准备根据需求进行虚拟环境的准备，为应用移植搭建好环境，从而更顺利的进行应用系统迁移。5.1 虚拟化环境准备步骤图5-1 虚拟化环境准备步骤5.2 虚拟化环境准备与方案设计5.2.1 环境确认在环境确认中，应确认如下环境是否准备就位，以便

28、顺利进行项目实施。 确认需要的网络资源是否就绪； 确认需要的存储资源是否就绪； 确认需要的计算资源是否就绪； 确认需要的数据库资源是否就绪5.2.2 实施规划与设计方案项目实施前应制定详细的实施规划与设计方案，包括但不限于如下内容： UAP云平台及业务系统组网设计 UAP云平台及业务系统存储系统设计 UAP云平台实施详细规划及具体参数设计 虚拟机设置参数，如虚拟机硬盘等 外围环境设计，如域控制等5.3 UAP云平台实施依据云平台实施规划与设计方案进行项目实施，严格遵从中国移动相关标准及广东移动相关标准，严格按照项目管理的要求。5.3.1 虚拟化系统设置与调试在虚拟化系统配置与调试中，包括如下内

29、容： Hyper-V管理软件的高级功能配置，如HA、动态迁移等高级功能，以满足业务的具体需要 存储的相应配置 网络虚拟化的相应配置，建立虚拟交换机，并与物理网卡及物理网络联调5.3.2 虚拟机系统设置云平台物理和虚拟环境搭建好后，应创建相应的虚拟机，安装操作系统，按需安装相应的应用系统软件，制作相关的模板。6 应用迁移应用系统迁移首先将应用系统从物理服务器移植到虚拟机上，可直接在虚拟机上重新部署或者移植应用系统，也可将物理机利用迁移工具转换为虚拟机。6.1 迁移实施流程图6-1 应用系统迁移实施流程6.2 迁移环境准备迁移环境准备是迁移前最重要的工作，包括人员、网络环境、迁移技术手段、迁移工具

30、等内容的准备。1，应用系统迁移前，相关人员应准备就绪 迁移实施方：负责具体迁移工作 应用系统开发商：负责具体应用的部署和测试 网络系统管理员：负责网络的通信和连接情况 系统管理员：负责虚拟化环境的准备和资源提供，原物理服务器的密码等信息提供； 备份管理员：对重要的数据和应用进行迁移前备份；2，确认UAP云平台具有足够的CPU、内存、存储和网络资源满足被迁移系统的需求。3，迁移前，对重要的数据和应用系统进行必要的备份，以防迁移过程中有意外的情况发生。6.3 迁移执行在迁移执行阶段，须严格执行制定的迁移方案和迁移流程。6.4 迁移后虚拟机的优化在应用系统迁移到云平台环境后，应对虚拟机作出相关的设置

31、调整，以满足更好的业务服务需求，具体调整可参考如下几点（不限于）： 消除不必要的虚拟硬件设备 按需求适当增加或者减少虚拟资源配置，比如调整或者减少处理器和内存等设置 设置资源竞争相关参数，如设置虚拟机最小、最大CPU可用资源，及发生竞争时的竞争权重等 调整虚拟机磁盘空间大小，满足应用系统的发展需求7 测试验证应用系统应该做好充分的测试与验证，为业务割接做好准备工作。7.1 应用系统测试验证流程图7-1 应用系统迁移测试流程7.2 应用系统测试验证内容首先测试在UAP平台虚拟机上的应用系统是否具有与物理服务器相同的功能，然后对应用系统进行功能性测试、性能测试、稳定性测试，并对有问题的地方进行初步

32、优化，最后进行应用系统验证，保证应用系统顺利割接。7.3 应用系统测试对被迁移的应用系统通过创建测试用例和测试脚本，选择合适的测试数据和测试样例，确认迁移数据在应用系统迁移到云平台环境后的有效性，进行有计划的测试，并在测试结果基础上生成报告。功能性测试对云平台的业务应用系统进行功能性测试，并与物理服务器进行对比，确保应用系统在平台迁移后所有功能工作正常，可采用手工测试或者自动化测试工具。对于迁移后应用系统，重点测试虚拟环境下对应用业务的影响，对于新的业务系统，需要进行完整的业务逻辑性测试。在性能测试中，主要采用压力软件在压力机上对应用系统进行压力测试，或者采用人工脚本进行压力性测试，从而衡量应

33、用系统对虚拟机系统的资源消耗及由此产生的对物理机的资源消耗，从而更好的掌握应用系统的性能需求，验证云平台是否能满足业务系统的性能需求。7.4 系统优化对测试过程中发现的系统问题，进行系统优化，达到比较优化的运行状态。系统调优中，建议考虑如下因素： 从整体考虑资源组的资源保留情况，整体考虑资源组内的虚拟机的资源保留和竞争情况 充分利用性能测试结果，找出系统性能的短板，从物理基础架构和虚拟基础架构两个层次进行调优7.5 应用系统验证应用系统验证是指在验证环境中，利用接近生产云平台的真实环境，对业务应用系统进行验证，从而更加准确的衡量云平台环境中的业务应用系统是否满足真实环境的需求，为应用系统割接做

34、好准备。8 应用系统割接应用系统割接是在UAP云平台中完成应用系统的上线割接，原系统停止对外服务，UAP云平台上的应用系统开始提供对外服务。8.1 应用系统割接流程图8-1 应用系统迁移割接流程8.2 割接评估在进行系统割接前，首先对系统进行割接评估，包括但不局限于如下内容： 应用系统在云平台中的测试是否满足需求 应用系统对用户感知的影响是否很大 对现有业务产生的影响是否很大 应用系统的割接是否会影响具体业务运行 是否具备割接的具体条件8.3 割接准备应根据业务的特点制定合适的割接方案，为割接操作提供切实可行的依据。割接操作前，应做好割接准备。割接准备分为两个层面，管理层面准备和技术层面准备。

35、管理层面的准备如割接前的系统公告、割接后客户回访等；技术层面的割接准备，如准备好云平台相关硬件设备和功能等。8.4 割接操作在应用系统割接中，割接操作应包含但不限于如下几个步骤： 原系统停用将原系统中止对外服务，停止数据访问，保持数据的完整性。中止服务时，请不要关闭原有系统，而是简单地将网络断开，这样，如果迁移后的虚拟机不能正常使用，可在最短时间内启用原系统。 最终的数据同步将原生产系统内的数据与生产云平台内的新系统进行最终的数据同步，以便平滑迁移。 新系统上线寄宿于云平台的应用系统上线，开始对外提供服务。8.5 回退机制由于应用系统割接后，地点和配置都可能发生变化，一些因素有可能导致割接失败

36、。应用系统割接应在规定的时间窗口内完成，如规定时间内无法完成，或者割接后运行不稳定，则需考虑回退应用系统，拨回配置信息，启用原系统。8.6 割接后观察当云平台上的应用系统上线后，应成立专门的监护小组对割接后的系统进行观察。在割接后观察期中，遇到不稳定运行的系统，要考虑是否回退。如可以解决，在进行问题解决及优化，如需要回退，则启动回退流程。观察期周期设置取决于具体的应用系统特点，建议观察期在三个完整的业务周期以上。8.7 原系统删除当应用系统成功割接，并且在割接后观察期正常工作后，可考虑将原系统删除，释放物理资源，完成整个应用系统迁移。9 附录9.1 MAP性能评估工具实施文档9.2 典型案例三个典型案例