1.1.1.1.1 迁移方案总体思路
中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，
在迁移方案设计中，我们重点考虑几个问题。
保障业务中断停机时间最小化
业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时间最小，能否实现0 停机的建设目标？
1、对于服务器操作系统而言，我们可以采用P2V 的方式，利用操作系统的Volume Shadow Copy 卷影副本复制服务作为基础，来实现在旧系统环境下的系统无修改，无停机的情况下，将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。
2、对于应用中间件和其他应用服务器来说，我们可以基于应用服务器的动态业务扩展集群方式，来实现服务器不停机环境下的增加业务节点操作，这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中，在部分应用服务中我们可以使用session 会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时，我们可以采用会话内存复制，考虑到会话复制和状态的安全性，我们可以采用会话数据库复制管理。
3、对于数据库而言，我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建，数据库镜像技术可以让我们不但保证数据库迁移的不停机，而且还可以保证万一迁移中出现停机故障也不影响源数据库，而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行，这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。
业务切割时间节点优化
针对现有系统需要对外提供服务的应用，需要通过对用户历史应用进行分析，
选择最优的的切割时间节点，并提切割期间的备份链路、人工受理手段
迁移后完整性测试
迁移涉及到应用、实例、数据库的操作以外，还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话
状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。
1.1.1.1.2 服务器硬件环境迁移方案
按照用户招标要求，本次项目建设的服务硬件环境主要是从原有服务器向北京政务云平台的迁移。首先需向北京市政务云服务平台咨询其对原有服务器硬件环境和操作系统环境虚拟的支持程度，可以降低迁移的难度。
迁移评估
迁移前，我公司将对迁移方案进行评估以确保迁移成功。首先我公司将派工程师勘察现有系统的架构和资源使用状况，评估过程必须包含以下信息和内容：现有系统支撑的服务数量以及在服务器中的分布情况；
现有物理服务器资源占用状况，包括CPU、内存、磁盘和网络连接状况，
为保证迁移成功，目标虚拟机规格应不低于原物理机标准；
当前的物理环境是否支持虚拟化，是否支持资源扩展，因为在迁移之前须在物理服务器上完成虚拟化；
对当前的存储容量和资源利用率进行评估，需在目标系统中规划好迁移需要的存储空间。需明确现有存储如何利用，比如有些服务器是在本地磁盘上创建系统盘和用户盘，有些服务器则在本地磁盘上创建系统盘而在SAN/NAS 上创建用户盘。
迁移计划
通过对现有网络环境的评估，我们对现有资源利用率，服务以及系统需求非常清晰并进行评估后才能开始对迁移进行计划，步骤如下：
1、确定迁移步骤，包括所有服务器的迁移先后顺序，其顺序按风险的高低降序排列。
2、确定备份方案，由于现有系统会被加固，某些服务器通过虚拟化重复利
用，而在虚拟化前需要清除所有的数据，因此需要对这些服务器进行备份保证服
务的连续性
3、确定并准备好迁移所需的工具，包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境。
4、在实际迁移开始之前确定额外的测试环境，该测试环境能够引导测试从而确保迁移成功。因此，测试环境需明确设计的服务器和存储数量。
5、规划网络环境，由于网络中的服务器各处不同位置，因此在迁移中需考虑到网络连接情况、数据备份方式，以及网络流量来源，确定网络流量是否会引发网络拥塞
6、确定迁移周期以及参与人员，包括迁移起止时间，团队能力建设以及团队成员的角色。
测试计划
迁移计划后，执行小批量的测试迁移方案，这里会涉及到首批迁移的测试和审核，步骤如下：
准备用于测试迁移的测试系统环境，在测试时，第一批服务器将会迁移到该系统环境中。
安装并核实迁移工具，此时要执行第一批服务器的迁移。对第一批服务器，需分析存储系统，不管该服务器在存储迁移中采用本地磁盘存储还是远端SAN/NAS 存储系统。
迁移测试
在第一批服务器和服务的小批量测试迁移后，需对迁移后的服务器进行测试，
包括单元测试和性能测试。
迁移实施
在迁移实施过程中，所有的服务器都会被迁移到虚拟化系统下。执行步骤如下：
确保批量迁移的整个网络环境已准备完毕，并通过迁移工具完成源系统和目标系统之间的连通。此处的目标系统属于中转系统。
对迁移系统进行性能审核和健康检查，如果系统状态监视则停用旧系统并将其服务暂时转移到新的虚拟化系统中。
进行利旧，对于一部分可用的旧硬件可在服务器虚拟化中重新再利用，一
些软件资源需扩展，如内存和硬盘。这些服务器构成最终的虚拟化基础设施，即最终系统。
最后，在目标系统和最终系统之间进行迁移。
1.1.1.1.3 迁移的详细操作步骤
迁移的具体步骤及描述如下:
1、在评估阶段，虚拟化和迁移之前需收集的信息如下：
性能统计：包括CPU使用率，内存使用率，硬盘IOPS和硬盘使用情况；
物理服务器配置：包括CPU 规格，内存容量，硬盘容量统计物理服务器部署位置，分析是否支持虚拟化，累计支持虚拟化的服务器数量，并规划出虚拟化中需新增的硬件情况；
通过上述无代理收集和代理收集两种场景收集当前系统的使用和配置情况。可采用信息收集工具。
2、分析现有服务的依赖条件，对当前系统进行备份。确定应用系统对服务器的
依赖关系，可作为迁移参考，确定所有服务器的迁
移优先级顺序。
在确定各服务的依赖条件后，对需进行虚拟化的服务器进行备份。
3、容量规划和虚拟化执行
根据当前的资源使用和需求情况，计算虚拟化所需的容量。
4、规划应用服务
在拟化解决方案中，同类虚拟机部署在同一个计算资源池中，在同一个池中可相互共享存储/计算资源，一个集群的故障不会影响其他资源池。
5、虚拟化规划和虚拟机分配
建立虚拟化平台后，要准备最终的迁移资源。迁移前，如果服务器 a 具备双核CPU和2G内存，那么在虚拟化平台中就创建一个2核/2G内存的虚拟机，并分配相应的硬盘。
6、规划迁移工具采用迁移工具从物理或虚拟的服务器向最终的虚拟化系统中进
行磁盘复制。
7、通过工具执行在线迁移
准备好源系统，目标虚拟机以及目标系统后，决定迁移时需使用的迁移工具和迁移策略。
8、迁移测试迁移后，需进行测试来验证迁移是否成功，测试场景如下：应用服
务迁移后对虚拟化基本功能的监测；迁移前后应用服务的特性功能是否几乎相同；
虚拟化系统的性能监控；
9、停用旧系统截至目前现有的服务器已经被虚拟化和重复使用，其他一些不支持虚拟化的服务器上对应的服务也已经迁移到虚拟化平台，那么现在可将应用服务切换到虚拟系统并停用旧系统。
1.1.1.1.4 应用系统和数据库迁移方案
针对本项目建设，我们将在应用系统和数据库迁移前，在北京市政务云平台中部署与原应用一样的操作系统、中间件、服务器管理平台软件环境，确保迁移的环境变化风险最低。
应用服务器迁移
针对本项目应用系统迁移，原系统全部是基于多种应用环境、多种应用程序框架。本方案计划对应用环境以及应用程序框架提出构建NLB群集，将当前系统不停机加入到NLB群集中，使之成为群集中的一个节点，而新环境则为另外一个节点。实施完成后再退出此迁移群集，将新环境加入到新的构建的NLB群集。
NLB不但能实现均衡负载，而且还能实现多种形式的冗余。NLB主要用于那些文件改动不大，并且不常驻内存的环境，比如WEB艮务、FTP服务、和VPN服务等。
当用户访问集群的时候，集群能将访问请求分摊到集群中的每个服务器上，以达到均衡负载的效果。这些服务器被称为集群节点。在负载平衡中，每个节点的文件一般都要求是一样的。这样每个节点返回给客户的结果都是一致的。一般来说组建一个NLB要求至少两个节点，其中一个节点不能使用，这全部负载将落入到剩下的那个节点上，即全载。NLB能提供三种冗余功能，软件冗余、硬件冗余、站点冗余。
数据库迁移实施
针对本项目数据库迁移，需要将中心积累的历史数据文件搬迁到北京市政务云平台，并且要求最小宕机时间，同时面临的难点还包括服务器并不在同一个一个机房。
1、分析与设计思路
针对本项目数据库搬迁环境特点：第一个是数据库文件比较大；第二是传送文件的速度可能会比较慢(广域网传输) 。初步解决方案如下。
为了使宕机时间最短，我们这里使用完整备份和差异备份来迁移数据库，在白天的时候对需要迁移的数据库进行一次完整备份( XXX_full.bak )，并把备份文件拷贝(这里可以使用FTP软件进行断点续传)到目标服务器进行还原，等到下班时间之后再进行一次差异备份( XXX_diff.bak )，再把这个差异备份拷贝到目标服务器，在完整还原的基础上再进行差异还原。
这里的宕机时间=差异备份时间+传送差异备份文件时间+还原差异备份文件时间，不存在宕机时间。
2、保证数据迁移过程中的安全性和操作可审计性数据迁移中的安全性不可忽略，本方案设计基于多重数据审计功能实现迁移安全性和操作审计性。
1.1.1.1.5 系统迁移的具体组织实施方案
针对本项目建设，涉及中心生产系统的搬迁，上述系统具有停机时间要求短、
系统结构复杂、测试时间长、设备繁多、使用人员多、层次复杂等特点。本项目搬迁，时间非常紧, 且设备间的稳定性也是一个考验。因此，必须协调好各单位人员的关系，齐心协力才可能在预定时间内完成搬迁工程。
本项目搬迁组织以尽量不影响日常工作或将影响降低到最低为前提的情况下制定，即在保障内容最少日的最少时间节点开始搬迁，尽快完成必须搬迁的服务器、网络设备的搬迁、安装及测试。并且在开机以后，继续跟踪系统的运行情况，随时处理系统运行的异常情况。搬迁需要原系统建设公司人员的充分协调及
配合下才能完成本次搬迁任务。
搬迁规划
实施流程：
罚拐圳炭 ? 与XXX 技术人员 ―亠 询宀骨谕甘安
现场勘条 -------- 莎 现场交流 ”确疋实施万案 流程主要根据搬迁前的需要制定，主要详细了解当前系统设备情况，系统运 行情况。针对所了解情况制定详细搬迁方案以及应急方案。
专业工程师了解用户现在机房的现状以及搬迁后的具体要求。 充分考虑在实 施过程中可能出现的各种情况，定制详细可行性的迁移实施计划， 将机房迁移工 作对用户的影响降至最小。
编制搬迁前及搬迁后的物理布置表、连接表、线缆号表。可根据用户情况分 为多个系统进行分类。
在搬迁过程中需要XXX 技术人员密切配合。
为保证搬迁工作顺利、有序、安全的进行将制定详细的搬迁流程，进行细致 的分工，具体工作安排到人，责任到人。
搬迁工作中的每项工作原则最少安排（2）人，以保证工作的准确性。 详细实施方案
为了搬迁能按时顺利进行，并且在搬迁后能够保证设备正常运行， 我们制定 了一系列简单明了的工作表，帮助工程实施人员确定各种搬迁工作中要执行的工 作是否完成。避免工作失误，避免造成搬迁工作的延误。
实施流程: 对所有设备进行 分析，制定应急
1.1.1.1.1迁移方案总体思路 中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，在迁移方案设计中，我们重点考虑几个问题。 保障业务中断停机时间最小化 业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时间最小，能否实现0停机的建设目标？ 1、对于服务器操作系统而言，我们可以采用P2V的方式，利用操作系统的V olume Shadow Copy卷影副本复制服务作为基础，来实现在旧系统环境下的系统无修改，无停机的情况下，将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。 2、对于应用中间件和其他应用服务器来说，我们可以基于应用服务器的动态业务扩展集群方式，来实现服务器不停机环境下的增加业务节点操作，这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中，在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时，我们可以采用会话内存复制，考虑到会话复制和状态的安全性，我们可以采用会话数据库复制管理。 3、对于数据库而言，我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建，数据库镜像技术可以让我们不但保证数据库迁移的不停机，而且还可以保证万一迁移中出现停机故障也不影响源数据库，而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行，这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。 业务切割时间节点优化 针对现有系统需要对外提供服务的应用，需要通过对用户历史应用进行分析，选择最优的的切割时间节点，并提切割期间的备份链路、人工受理手段。
中国移动广东公司 UAP云平台应用迁移方案 （大纲） 版本
目录 1文档说明 (4) 2应用系统迁移方法 (4) 2.1应用迁移与整合方法 (4) 2.2应用迁移涉及的相关部门 (5) 3系统评估与分析 (6) 3.1系统评估和分析流程 (7) 3.2评估准备 (8) 3.2.1迁移范围确定 (8) 3.2.2评估方法与准备 (9) 3.2.3评估环境的准备 (9) 3.3系统调研与评估 (9) 3.3.1物理基础架构调研与评估 (9) 3.3.2应用系统调研与评估 (10) 3.3.3迁移对应用系统的影响 (11) 3.4需求分析及汇总 (11) 3.4.1基础架构需求分析与汇总 (11) 3.4.2应用系统需求分析和汇总 (11) 4方案设计 (11) 4.1方案设计流程 (12) 4.2云平台方案设计 (13) 4.3迁移方案设计 (13) 4.3.1虚拟化适用性分析 (13) 4.3.2迁移场景设计 (14) 4.3.3资源映射分析 (15) 4.3.4服务器放置设计 (16) 4.3.5资源竞争关系设计 (17) 4.3.6迁移顺序设计 (17) 5虚拟化环境准备 (18) 5.1虚拟化环境准备步骤 (19) 5.2虚拟化环境准备与方案设计 (19) 5.2.1环境确认 (19) 5.2.2实施规划与设计方案 (19) 5.3UAP云平台实施 (20) 5.3.1虚拟化系统设置与调试 (20) 5.3.2虚拟机系统设置 (20) 6应用迁移 (20)
6.1迁移实施流程 (21) 6.2迁移环境准备 (21) 6.3迁移执行 (22) 6.4迁移后虚拟机的优化 (22) 7测试验证 (22) 7.1应用系统测试验证流程 (23) 7.2应用系统测试验证内容 (23) 7.3应用系统测试 (23) 7.4系统优化 (24) 7.5应用系统验证 (24) 8应用系统割接 (24) 8.1应用系统割接流程 (25) 8.2割接评估 (25) 8.3割接准备 (25) 8.4割接操作 (26) 8.5回退机制 (26) 8.6割接后观察 (26) 8.7原系统删除 (26) 9附录 (27) 9.1MAP性能评估工具实施文档 (27) 9.2典型案例 (27)
华云迁移方案 1概述 对于使用华云平台的用户而言，会面临多种需要业务迁移的场景，可以分为三种情况：用户进行华云部署，需要将业务从原有云平台迁移到华云平台，原有的业务可能使用物理机承载，也有可能使用了第三方的云平台；用户在使用华云的过程中，需要将虚机从一台物理机迁移到另外一台物理机，也就是在华云系统内进行虚机的迁移；第三种情况是用户配置了伸缩策略，华云监控引擎根据资源的使用情况在集群内进行自动迁移。下面按照虚拟机到虚拟机（V2V）迁移、物理机到虚拟机（P2V）迁移两种使用模式来描述华云的迁移实施方案。 2 V2V迁移 2.1华云内部迁移 典型的华云部署构架如图1所示，云区域1为承载kvm类型虚机的集群，云区域2为承载xen类型虚机的集群，云区域3承载了ESXI类型的虚机。 图1 华云典型构架
以图1的部署构架为例，云区域1和云区域2内部的虚机迁移通过华云内置的迁移功能就能够完成，其它形式的迁移，比如异构（云区域1 和云区域2 ）区域间的迁移，以及云区域3 内部的迁移需借助第三方工具来执行。 2.1.1云区域内部迁移 对于kvm或xen类型的云区域内部迁移，通过华云内置的迁移功能完成，分为两个步骤执行：步骤1，如图2所示，在资源管理界面中选择需要迁移的虚机（这里是centos1 ），点击迁移，弹出迁移界面，如图3所示。 图2 迁移目标选择 步骤2，在弹出的迁移界面中选择迁移的目的地，这里选择node4，点击保存，出现迁移状态，如图4所示。图中会显示迁移的总体进度，并且展示当前所处的迁移状态，迁移过程中有虚机磁盘迁移、虚机状态迁移、虚机网络迁移三个状态。迁移完成后，在物理节点node4中可以看到被迁移的虚机，如图5所示。
系统迁移云端服务方案 目录 一.方案背景 原xx 系统集约化平台定于 2018年6月30日关停。平台关闭后，相关单位可能开展的工作包括： 1、关停系统，系统上无xx 应用； 2、关停系统，系统上存在关联应用，需要迁移应用； 3、不关停系统，需要迁移整个系统。 二."问题及需求 原xx 系统集约化平台关停，相关单位本身缺少机房、技术人员、日常维护人员的情况下，会对后续工作的开展造成以下几个方面的困扰： 1、由谁来提供新的机房环境和网络基础环境； 2、由谁来对新的网络基础环境提供维护； 3、如何保证整个迁移过程的安全性、可靠性； 4、迁移完成后，由谁来负责整体系统的安全运维，保证系统的安全性。 如果由各单位自行负责本单位系统、应用系统的整合、迁移，就需要各单位投入大量的人力、物力解决新机房、网络、迁移、运维多方面的问题，而且无法保证系统后续的安全性。 三.方案思路 在当前的情况下，采用集中管理的方式是比较适合的，帮助相关单位统一解决机房、设备、人员等多方面的问题，同时能够降低成本。 1、由xx 统一提供机房和基础网络环境，可以是自建模式，也可以考虑采用整体迁移到公有云的模式。相关系统在从XX机房迁出后均由XX托管，和统一部
xx 署在一套系统系统上 2、 由xx 负责系统具体迁移工作与后续基础网络维护工作，可委托安全服 务公 司负责系统的迁移协调、迁移风险控制； 3、 委托服务公司统一负责系统后续的整体安全运维，包括日常的安全检 测、 加固及应急等。 本方案优势： 1、节省成本： 相比各单位自行解决机房、网络、迁移、运维、安全等问题，此方案更加 的节省费用； 2、节省人员： 各单位不需要再额外招聘、培训技术人员，将精力集中在核心业务上； 3、 保障 XX ： 专业的安全服务团队提供日常安全运维，保证系统的可靠性和安全性； 4、 更专业的技术服务： 让专业的团队来负责日常的运行、维护，解决日常运维过程中的各种问 题。 四． "方案设计 本方案以xx 第一批需迁移的系统（不包含门户系统下链接的应用系统，女口 有按单个系统计算）为统计基础， 4.1 资源需求 一、计算资源需求
应用系统迁云实施方案编制指南 贵州省大数据发展管理局 2017年6月
目录 一、格式和提纲 (1) 二、编制内容要求 (3) 前言 (3) 第一章项目概述 (3) 第二章现状调研及分析 (3) 第三章迁云总体规划 (4) 第四章迁云实施管理 (5) 第五章资金概算 (5) 第六章效益分析 (5) 附件1：7月应用系统迁云工作推进表（样表） (6) 附件2：应用系统迁云工作确认报告（模板） (7) 附件2：数据资源共享开放工作确认报告 (10) 附表1：应用系统详细信息表 (12) 附表2：云资源测算清单 (13) 附表3：项目投资估算表 (14) 附表4：数据资源目录梳理计划表 (14) 附表5：数据共享计划表 (16) 附表6：数据开放计划表 (17) 附表7：数据需求表 (18)
一、格式和提纲 应用系统迁云实施方案参考如下格式和提纲进行编制：（一）封面格式： ××××（项目全称） 项目建设单位：×××××（盖章） 编制单位：××××× 编制日期：××××年××月 项目建设单位联系人：×××× 联系方式：×××××（电话、传真、电子邮件）（二）扉页格式： 编制单位：××××（盖章） 编制单位负责人：×××（签章) 编制单位项目负责人：××× (职称) 主要编制人员：×××（职称) （三）应用系统迁云实施方案编制提纲： 目录 前言 第一章项目概述 1．项目名称 2．项目背景 3．项目建设单位概况 4．项目建设目标 5．项目建设内容 6．项目建设周期 7．项目投资及资金来源 8．方案编制依据
第二章现状调研及分析 1.信息化现状调研 2.存在问题 3.需求分析 第三章迁云总体规划 1．迁云原则 2．迁云目标 3．技术架构设计 4．数据处理及存储 5．网络建设规划 6．系统安全规划 7．迁云改造 8．云上贵州系统平台云资源选型及清单 9．运维规划 第四章迁云实施管理 1．实施计划 2．保障措施 第五章资金概算 1．投资概算 2．资金筹措 第六章效益分析 项目的经济效益和社会效益分析 附表：1．应用系统详细信息表 2．云资源测算清单 3．项目投资估算表 4．数据开放计划表 5．数据共享需求表 6.数据开放计划表 7.数据需求表
XXX公司应用系统迁云方案 XXX公司： 为加快XXXX企业服务器迁云的速度，确保上云过程系统运行不间断，联通特制定以下方案： 一、迁移方案总体思路 新旧系统的迁移是一个整体系统工程。迁移必须保证系统建设的相关要求，在迁移过程中，需要重点考虑以下问题： 1.1数据迁移如何保障业务运行不间断； 1.2迁移涉及到应用迁移、数据库迁移以外，还要考虑到迁移前的 数据备份、迁移后运行测试以及迁移完系统的培训等内容，只 有这样才能保证迁移的安全性和有效性。 二、迁移实施分工 本次系统的迁云主要有四方参与，具体分工如下： XXX公司：负责项目总协调、费用缴纳、监督； 联通：协助XX集团与XX开发方、XXX软件开发方协商制定迁云计划，负责基础云环境的开通，同时配合解决迁云过程中存在问题； XX开发方：负责XXX系统的数据备份、上传以及云服务器软件环境的搭建，系统数据导入及运行测试； XXX软件开发方：负责XXX的数据备份、上传以及云服务器软件环境的搭建，系统数据导入及运行测试； 三、服务器迁移方案
数据迁移计划分为七个步骤，具体如下： 3.1迁移评估（1天） 迁移前，对迁移方案进行评估以确保迁移成功。 由两家软件公司现有系统的架构和资源使用状况进行勘察，评估过程必须包含以下信息和内容： 现有系统支撑的服务数量以及在服务器中的分布情况，现有物理服务器资源占用状况，包括CPU、内存、磁盘和网络连接状况。 对当前的存储容量和资源利用率进行评估，需在目标系统中规划好迁移需要的存储空间。 3.2联通阿里云服务器开通（1天）（与数据清理、备份同步进行）根据评估所确认的信息，由联通负责开通需求配置的阿里云服务器，XX企业财务负责费用缴纳（因阿里均为在线缴费，需财务在线缴纳） 3.3数据清理、备份（1天） 原服务器数据备份，由对应软件公司进行数据备份； 3.4云服务器环境搭建、软件调测（2天） 在阿里云服务器上搭建环境，包括FTP的上传软件、相关数据库及页面服务器软件，XX及XXX软件安装，XX及XXX软件数据通道调试； 3.5系统运行测试（3天） 数据迁移，由两家软件服务商分别将实体服务器的数据库上传至云服务器；XX及XXX软件系统运行测试；
VMWARE云平台升级及迁移参考实施方案
————————————————————————————————作者：————————————————————————————————日期：
VMWARE云平台升级及迁移 参 考 方 案
目录 1.原系统4.X到5.X的升级 (2) 2.新部署分方式 (2) 2.1.交叉模式 2 2.2.重新挂载 2 2.3.迁移软件迁移 3 3.迁移工具介绍 (3) 4.迁移方法介绍 (5) 4.1.热克隆简介 5 4.1.1.热克隆准备条件 5 4.1.2.热克隆优点 5 4.1.3.热克隆缺点 6 4.1.4.热克隆适用场景： 6 4.1. 5.热克隆不适用的场景 6 4.1.6.热克隆流程图解 7 4.1.7.热克隆完成后的虚机处理 8 4.2.冷克隆 8 4.2.1.冷克隆准备条件 9 4.2.2.冷克隆优点 9 4.2.3.冷克隆缺点 9 4.2.4.适用环境 9 4.2. 5.不适用的环境 9
4.3.手动部署 10 4.3.1.优点 10 4.3.2.适用场景 10 1.原系统4.X到5.X的升级 4.x版本直接升级到 5.x版本，理论上可以，但版本差异大应用容易出问题， 因此厂家不建议此种升级方式，建议新部署的方式升级 2.新部署分方式 2.1.交叉模式 两套虚拟化连接相同的存储交换机，分别识别两套存储，采用storage vMotion功能迁移虚拟机文件 但是rdm挂载盘如果选择了物理模式这就不支持了。 2.2.重新挂载 旧存储在原有虚拟化系统中卸载（不是删除），再在新虚拟化上重新挂载
中国移动广东公司 UAP 云平台应用迁移方案 （大纲） 版本
6.4迁移后虚拟机的优化.............................................................................................. 错误!未指定书签。
1文档说明 本文档的目的在于为UAP云平台地市应用系统设计的一个迁移与整合方法，并对实际操作有指导和建议。 本文档主要针对广东移动UAP的地市应用系统迁移到UAP云平台。 2应用系统迁移方法 2.1 应用迁移与整合方法 根据以往丰富的项目经验，结合UAP云平台的具体业务特点，定制了一套数据迁移与整合的方法。本迁移与整合方法分为6个阶段，分别为系统评估与分析、方案设计、虚拟化环境准备、应用移植、测试验证和业务割接。 图2-1应用迁移与整合方法 ?评估与分析 在系统评估与分析阶段，应确定迁移范围和目标，利用调查问卷、系统评估工具（MAP）和访谈等评估形式，对应用系统进行评估，分析和汇总系统需求，形成调研报告。 ?方案设计 在方案设计阶段，针对项目范围内的物理服务器进行虚拟化适用性分析，设计迁移场景和云平台架构方案。在云平台方案设计的基础上，进行迁移顺序、迁移方法等内容的设计，形成总体迁移方案。 ?虚拟化环境准备 在虚拟化环境准备阶段，应判断现有的UAP云平台环境是否能容纳被迁移的所有对象，以及，具体应检查计算资源、存储资源、网络资源以及数据库资源等，建立迁移所需的环境准备，如虚拟机、虚拟化网络等。
信息系统上云迁移服务流程 设计方案
目录 第一章服务流程图 (3) 第二章系统调研与评估 (3) 2.1迁移范围确定 (3) 2.2物理基础架构调研与评估 (3) 2.3应用系统调研与评估 (4) 2.3.1业务重要性评估 (4) 2.3.2业务生命周期评估 (5) 2.3.3应用系统逻辑架构 (5) 2.4其他内容调研与评估 (6) 第三章需求分析及汇总 (6) 3.1基础架构需求分析与汇总 (6) 3.2应用系统需求分析和汇总 (6) 第四章迁移实施 (7) 4.1迁移实施流程 (7) 4.2迁移环境准备 (8) 4.2.1人员准备 (8) 4.2.2网络环境准备 (8) 4.2.3计算资源准备 (8) 4.2.4重要数据和应用的备份 (9) 4.3迁移执行 (9) 4.3.1迁移失败分析 (9) 4.3.2迁移后云主机的优化 (10) 4.4测试验证 (11) 第五章确认交割 (12)
第一章服务流程图 第二章系统调研与评估 2.1 迁移范围确定 首先要确定迁移范围： （1）哪些应用系统需求从哪些服务器上迁移到云平台上； （2）哪些应用系统需要进行解耦和整合等操作； （3）迁移前后机房环境的变化确认等。 2.2 物理基础架构调研与评估 在物理基础架构信息收集和评估中，利用自动化评估工具和调查问卷的方式完成计算容量、存储容量和网络容量以及相关的利用率和性能数据等评估内容的收集。 物理基础架构的评估中，完成如下内容的评估：
（1）在基础架构硬件的CPU评估中，收集CPU的型号、主频、内核数、颗数，评估CPU的利用率。 （2）在基础架构硬件的内存评估中，收集内存的容量、型号以及使用率。 （3）在基础架构硬件的磁盘评估中，收集磁盘的数量、RAID方式、文件系统类型、文件系统总容量、磁盘IO 性能等； （4）在基础架构硬件的网络评估中，收集物理服务器的网卡容量、数量及网络性能，网络交换机的型号、网口数、数量、基础架构的网络拓扑图等。 2.3 应用系统调研与评估 在应用系统层面，评估业务的重要性、业务成熟度、应用系统逻辑架构等内容，为迁移提供重要的参考依据。 2.3.1 业务重要性评估 在评估阶段，评估应用系统的重要程度，利用应用系统的重要程度设置相关的资源竞争策略，并且对重要的应用系统采用相应的技术方案进行保护，如重要的应用系统可使用HA等技术方案保证业务连续性。 业务的重要性可作为云主机发生竞争时如何争取资源的一个重要输入。在云主机的资源竞争机制中，有最低占
. .. . 中国移动公司 UAP云平台应用迁移方案 （大纲） 版本
目录 1文档说明 (4) 2应用系统迁移方法 (4) 2.1 应用迁移与整合方法 (4) 2.2 应用迁移涉及的相关部门 (5) 3系统评估与分析 (5) 3.1 系统评估和分析流程 (6) 3.2 评估准备 (7) 3.2.1迁移围确定 (7) 3.2.2评估方法与准备 (7) 3.2.3评估环境的准备 (7) 3.3 系统调研与评估 (7) 3.3.1物理基础架构调研与评估 (7) 3.3.2应用系统调研与评估 (8) 3.3.3迁移对应用系统的影响 (8) 3.4 需求分析及汇总 (8) 3.4.1基础架构需求分析与汇总 (8) 3.4.2应用系统需求分析和汇总 (8) 4方案设计 (9) 4.1 方案设计流程 (9) 4.2 云平台方案设计 (10) 4.3 迁移方案设计 (10) 4.3.1虚拟化适用性分析 (10) 4.3.2迁移场景设计 (11) 4.3.3资源映射分析 (12) 4.3.4服务器放置设计 (12) 4.3.5资源竞争关系设计 (13) 4.3.6迁移顺序设计 (13) 5虚拟化环境准备 (14) 5.1 虚拟化环境准备步骤 (14) 5.2 虚拟化环境准备与方案设计 (14) 5.2.1环境确认 (14) 5.2.2实施规划与设计方案 (15) 5.3 UAP云平台实施 (15) 5.3.1虚拟化系统设置与调试 (15) 5.3.2虚拟机系统设置 (15) 6应用迁移 (15)
6.1 迁移实施流程 (16) 6.2 迁移环境准备 (16) 6.3 迁移执行 (16) 6.4 迁移后虚拟机的优化 (16) 7测试验证 (17) 7.1 应用系统测试验证流程 (17) 7.2 应用系统测试验证容 (17) 7.3 应用系统测试 (17) 7.4 系统优化 (18) 7.5 应用系统验证 (18) 8应用系统割接 (18) 8.1 应用系统割接流程 (18) 8.2 割接评估 (18) 8.3 割接准备 (19) 8.4 割接操作 (19) 8.5 回退机制 (19) 8.6 割接后观察 (19) 8.7 原系统删除 (19) 9附录 (20) 9.1 MAP性能评估工具实施文档 (20) 9.2 典型案例 (20)
UAP云平台应用迁移方案 （大纲） 版本
目录 1文档说明 (4) 2应用系统迁移方法 (4) 2.1应用迁移与整合方法 (4) 2.2应用迁移涉及的相关部门 (5) 3系统评估与分析 (6) 3.1系统评估和分析流程 (7) 3.2评估准备 (8) 3.2.1迁移范围确定 (8) 3.2.2评估方法与准备 (9) 3.2.3评估环境的准备 (9) 3.3系统调研与评估 (9) 3.3.1物理基础架构调研与评估 (9) 3.3.2应用系统调研与评估 (10) 3.3.3迁移对应用系统的影响 (11) 3.4需求分析及汇总 (11) 3.4.1基础架构需求分析与汇总 (11) 3.4.2应用系统需求分析和汇总 (11) 4方案设计 (11) 4.1方案设计流程 (12) 4.2云平台方案设计 (13) 4.3迁移方案设计 (13) 4.3.1虚拟化适用性分析 (13) 4.3.2迁移场景设计 (14) 4.3.3资源映射分析 (15) 4.3.4服务器放置设计 (16) 4.3.5资源竞争关系设计 (17) 4.3.6迁移顺序设计 (17) 5虚拟化环境准备 (18) 5.1虚拟化环境准备步骤 (19) 5.2虚拟化环境准备与方案设计 (19) 5.2.1环境确认 (19) 5.2.2实施规划与设计方案 (19) 5.3UAP云平台实施 (20) 5.3.1虚拟化系统设置与调试 (20) 5.3.2虚拟机系统设置 (20) 6应用迁移 (20)
6.1迁移实施流程 (21) 6.2迁移环境准备 (21) 6.3迁移执行 (22) 6.4迁移后虚拟机的优化 (22) 7测试验证 (22) 7.1应用系统测试验证流程 (23) 7.2应用系统测试验证内容 (23) 7.3应用系统测试 (23) 7.4系统优化 (24) 7.5应用系统验证 (24) 8应用系统割接 (24) 8.1应用系统割接流程 (25) 8.2割接评估 (25) 8.3割接准备 (25) 8.4割接操作 (26) 8.5回退机制 (26) 8.6割接后观察 (26) 8.7原系统删除 (26) 9附录 (27) 9.1MAP性能评估工具实施文档 (27) 9.2典型案例 (27)
1.1.1.1.1 迁移方案总体思路 中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求， 在迁移方案设计中，我们重点考虑几个问题。 保障业务中断停机时间最小化 业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时间最小，能否实现0 停机的建设目标？ 1、对于服务器操作系统而言，我们可以采用P2V 的方式，利用操作系统的Volume Shadow Copy 卷影副本复制服务作为基础，来实现在旧系统环境下的系统无修改，无停机的情况下，将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。 2、对于应用中间件和其他应用服务器来说，我们可以基于应用服务器的动态业务扩展集群方式，来实现服务器不停机环境下的增加业务节点操作，这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中，在部分应用服务中我们可以使用session 会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时，我们可以采用会话内存复制，考虑到会话复制和状态的安全性，我们可以采用会话数据库复制管理。 3、对于数据库而言，我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建，数据库镜像技术可以让我们不但保证数据库迁移的不停机，而且还可以保证万一迁移中出现停机故障也不影响源数据库，而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行，这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。 业务切割时间节点优化 针对现有系统需要对外提供服务的应用，需要通过对用户历史应用进行分析， 选择最优的的切割时间节点，并提切割期间的备份链路、人工受理手段 迁移后完整性测试 迁移涉及到应用、实例、数据库的操作以外，还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话
1 云化迁移模式 1.1 基于基础设施即服务IaaS 迁移上云 将系统原有的硬件设备纳入云平台的资源池，在云平台的IaaS 上重新构建服务于自有业务系统研发的自用支撑平台。该策略的优点在于以自用平台的形式保留了熟悉的业务应用研发环境、满足了系统整合中基础设施共享的后向兼容需求。该策略的缺点在于自用支撑平台对于自有业务的针对性较强，缺少对于行业间、部门间交互业务的支撑。 1.2 基于平台即服务PaaS 迁移上云 在系统原有硬件设备纳入云平台资源池的基础上，以云平台的PaaS 为基础重新建立业务的解决方案和系统架构，原有业务系统的架构性代码将被舍弃、功能性代码将选择性保留。该策略的优点在于业务逻辑和业务系统的研发将直接基于PaaS 实现，开发人员只需要关注业务流程信息化、无需再从事业务平台的研发运维工作。该策略的缺点在于业务系统研发将受到平台能力的制约，原有业务系统的框架作废。 1.3 基于软件即服务SaaS 迁移上云 在系统原有硬件设备纳入云平台资源池的基础上，不再自行实现业务逻辑或者业务系统，而是直接调用云平台的SaaS 所提供的软件服务来组织形成自有业务、实现信息化应用，原有业务系统的软件实现将被舍弃。该策略的优点在于行业内工作人员只需调用成熟软件和应用来开展自有业务和服务。该策略的缺点在于业务数据没有本地留存，业务操作受SaaS 制约。 1.4 基于对云平台的改进实施 对云平台原有的代码库进行修改或扩展，将自建代码库部署到云环境中去，以达到支持自有业务系统研发的目的。该策略的缺点在于行业信息化建设的前期投入比较大，而在后续阶段需要对云平台代码库的升级更新持续跟进。 1.5 基于系统的硬件部署实施 把业务系统简单的部署到云平台的若干硬件设备上，仅止于改变业务系统的硬件基础设施配置参数，而并非是将业务系统部署到云平台的硬件环境中。 2 云化迁移策略设计 综合上述IaaS、PaaS、SaaS 三种云迁移策略，既能发挥云计算技术的资源调度优势，又具备落地的实施可行性和可操作性，适合作为已建政务系统云迁移可选策略。 （1）基于IaaS 的上云 此迁移策略较为适合面向高并发、业务逻辑紧密的联机事物处理类（OLTP）政务应用，其拥有自成体系的业务逻辑关系和业务应用环境，不同业务子系统或者不同功能模块之间存在复杂的内在通信联系和交互关系，其政务应用覆盖领域内不同行政管理和公共服务方向的多项业务操作和管理流程。 （2）基于PaaS 的上云 此策略一方面，适合于业务功能简单且独立性强的简单事务处理类政务系统，其业务逻辑针对性强、专业性强，不可能基于SaaS 直接调用，需要根据基础支撑平台的能力进行单独开发。另一方面，面向决策的联机分析类（OLTP）政务应 Key words : Government cloud;Government system;Cloud migration
精心整理 1.1.1.1.1 迁移方案总体思路 中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，在迁移方案设计中，我们重点考虑几个问题。 保障业务中断停机时间最小化 业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时1、2式，到新环境我们 3而针对现有系统需要对外提供服务的应用，需要通过对用户历史应用进行分析，选择最优的的切割时间节点，并提切割期间的备份链路、人工受理手段。 迁移后完整性测试 迁移涉及到应用、实例、数据库的操作以外，还涉及到迁移前规划、迁移后测试的完整性测试。这些测试包括但不限于数据一致性测试、数据完整性测试、应用会话状态完整性测试、连接中断测试、数据恢复测试。只有这样才能保证迁移的安全性和有效性。
1.1.1.1.2服务器硬件环境迁移方案 按照用户招标要求，本次项目建设的服务硬件环境主要是从原有服务器向北京政务云平台的迁移。首先需向北京市政务云服务平台咨询其对原有服务器硬件环境和操作系统环境虚拟的支持程度，可以降低迁移的难度。 迁移评估 迁移前，我公司将对迁移方案进行评估以确保迁移成功。首先我公司将派工程师勘察现有系统的架构和资源使用状况，评估过程必须包含以下信息和内容： 虚拟化； 需明迁移计划 1 2 3 4、在实际迁移开始之前确定额外的测试环境，该测试环境能够引导测试从而确保迁移成功。因此，测试环境需明确设计的服务器和存储数量。 5、规划网络环境，由于网络中的服务器各处不同位置，因此在迁移中需考虑到网络连接情况、数据备份方式，以及网络流量来源，确定网络流量是否会引发网络拥塞 6、确定迁移周期以及参与人员，包括迁移起止时间，团队能力建设以及团队成员的角色。 测试计划 迁移计划后，执行小批量的测试迁移方案，这里会涉及到首批迁移的测试和审核，步骤如下：?准备用于测试迁移的测试系统环境，在测试时，第一批服务器将会迁移到该系统环境中。
系统云迁移-上云方案
1.1.1.1.1迁移方案总体思路 中心系统迁移是一个整体系统工程。迁移必须保证用户系统建设的相关要求，在迁移方案设计中，我们重点考虑几个问题。 保障业务中断停机时间最小化 业务中断对于用户无论是运行环境还是测试环境均存在较大的恢复风险，这样的风险特别对于时间敏感型数据和数据完整性业务都是不可以接受的。我们基于这样的要求，考虑到如何将停机时间最小，能否实现0停机的建设目标？ 1、对于服务器操作系统而言，我们可以采用P2V的方式，利用操作系统的V olume Shadow Copy卷影副本复制服务作为基础，来实现在旧系统环境下的系统无修改，无停机的情况下，将数据和应用软件、操作系统环境、系统环境变量等全部以“快照”形式迁移到新服务器中。由此实现服务器环境的整体迁移。 2、对于应用中间件和其他应用服务器来说，我们可以基于应用服务器的动态业务扩展集群方式，来实现服务器不停机环境下的增加业务节点操作，这样可以实现应用服务器“热添加”到新环境中的故障转移/负载均衡集群系统中，在部分应用服务中我们可以使用session会话复制来实现旧系统的全局环境变量和会话请求状态也迁移到新环境中来。考虑到会话复制和状态的快速实时，我们可以采用会话内存复制，考虑到会话复制和状态的安全性，我们可以采用会话数据库复制管理。 3、对于数据库而言，我们可以基于数据库本身自带的数据库镜像技术、数据库日志传递技术来实现各自的分库、迁移库的构建，数据库镜像技术可以让我们不但保证数据库迁移的不停机，而且还可以保证万一迁移中出现停机故障也不影响源数据库，而日志传递技术构建的迁移可以保证系统数据库迁移以异步方式进行，这样可以让我们的系统环境在网络出现故障的情况依然可以进行迁移任务窗口的正常工作。 业务切割时间节点优化 针对现有系统需要对外提供服务的应用，需要通过对用户历史应用进行分