应用系统迁移方案
（大纲）
修订版
建设单位：
编制单位：
文档时间:
1.文档说明
本文档的目的在于为应用系统设计的一个迁移和数据处理方案，并对实际操作进行指导，给予建议。
1.1系统迁移需求分析
按照要求，此次系统迁移具体需求分析如下：
将原有能迁移的应用系统将全部迁移至机房，迁移期间必须保证工作不能中断，历史数据不能损失。
2.系统迁移方法
2.1应用迁移和数据处理方法
根据以往丰富的项目经验，结合应用系统的具体业务特点，定制了一套数据迁移和整合的方法。本迁移与整合方法分为6个阶段，分别为系统评估与分析、方案设计、虚拟化环境准备、应用移植、测试验证和业务割接。
?评估与分析
在系统评估与分析阶段，应确定迁移范围和目标，利用调查问卷、系统评估工具和会议等评估方式，对应用系统进行评估，分析和汇总系统需求，形成调研报告。
?方案设计
在方案设计阶段，针对项目范围内的物理服务器进行虚拟化适用性分析，设计迁移场景和数据处理方案。在此基础上，进行迁移顺序、迁移方法等内容的设计，形成总体迁移方案。
?虚拟化环境准备
在虚拟化环境准备阶段，应判断所迁移过去环境是否能容纳被迁移的所有对象，以及，具体应检查计算机资源、存储资源、网络资源、以及数据库资源等，建立迁移所需的环境准备，如虚拟机、虚拟化网络等。
?应用迁移
在系统迁移阶段，应根据既定的迁移方案严格的执行应用系统迁移，将物理机的应用系统移植到虚拟机内。
?迁移测试
在所迁移过去应用系统进行功能测试、性能测试、安全测试、和稳定性测试，并进行应用系统验证，以便预先排除隐患，使得应用系统成功的在所迁移过去的机房中运行。
2.2应用迁移设计的相关部门
业务迁移进行中，会涉及到如下各部门：
?应用开发商：负责应用系统日常的7×24小时故障响应处理工
作，为应用系统的维护支撑提供技术支持。
?迁移实施方：
1）对应用系统进行评估与分析；
2）根据需求设计迁移方案，如迁移方式、迁移工具等，设计数据处理方案；
3）进行应用系统迁移，将应用系统从物理机上移植到虚拟机上；
4）与应用开发商一起进行测试验证；
3.系统评估与分析
迁移前，对迁移方案进行评估，以确保迁移成功。首先需要勘察现有系统的架构个资源使用情况，评估过程需包含以下信息和内容：
1.现有系统支撑的服务器数量以及在服务器中的分布情况；
2.现有物理服务器资源占用情况，包括CPU、内存、磁盘和网络连接情况，
为保证迁移成功，目标虚拟机规格应不低于原物理机标准；
3.统计物理服务器部署位置，分析是否支持虚拟化，是否支持资源扩展；
4.对当前存储容量和资源利用率进行评估，需在目标系统中规划好迁移需
要的存储空间。需明确现有存储如何利用。
4.迁移计划
通过对现有网络环境的评估，我们对现有资源利用率，服务以及系统需求非常清晰并进行评估后，才能开始对迁移进行计划，步骤如下：
1.确定迁移步骤，包括所有需要迁移的应用系统迁移先后顺序，其顺序按风险的高低降序排列；
2.确定备份方案；
3.确定并准备好迁移所需的工具，包括工具在迁移中必备的一系列功能和使用工具所需具备的网络环境；
4.在实际迁移开始前，确定额外的测试环境，该测试环境能够引导测试从而
确保迁移成功。因此，测试环境需明确设计的服务器和存储数量。
5.规划网络环境，由于网络中的服务器各处位置不同，因此在迁移中需考虑到网络连接情况，数据备份方式，以及网络流量来源，确定网络流量是否会引发网络拥塞；
6.确定迁移周期以及参与人员，包括迁移起止时间，团队能力建设以及团队成员的角色。
4.1进度安排
迁移实施时间安排计划表如下所示：
4.2测试计划
迁移计划后，执行小批量的测试迁移方案，在这里会涉及到首批的测试和审核，步骤如下：
1.准备用于测试迁移的测试系统环境，在测试时，第一批服务器将会迁移到该系统环境中；
2.安装并核实迁移工具，此时要执行第一批服务器的P2V迁移
3.对第一批服务器，需分析存储系统，不管该服务器在存储迁移中采用本
地磁盘存储还是远端存储系统。
5.应用迁移
应用系统迁移首先将应用系统从物理服务器移植到虚拟机上，可直接在虚拟机上重新部署或者移植应用系统，也可将物理机用迁移工具转换为虚拟机。5.1环境准备
1.应用系统迁移前，相关人员应准备就绪：
?迁移实施方：负责具体迁移工作；
?应用系统开发商：负责具体应用的部署和测试；
?网络系统管理员：负责网络的通信和连接情况；
?系统管理员：负责虚拟化环境的准备和资源提供，原服务器密码等信息提供；
?备份管理员：对重要的数据和应用进行迁移前备份；
2.确认服务器具有足够的cpu、内存、存储和网络资源满足被迁
移应用系统的需求。
3.迁移前，对重要的数据和应用系统进行必要的备份，以防迁移过程中有
意外情况的出现。
5.2系统环境配置
以下数据为所需迁移系统的软硬件环境配置情况；详细的系统网络要求，以及系统部署的软件环境由各个公司负责部署维护。
5.2.1.**********管理平台
1.**********管理平台（服务）
硬件环境
软件环境
5.3迁移要求
在实施迁移之前，我们需进行如下的确认工作：
?需保证机房服务器已到位；
?相比较迁移前，迁移后的服务器软硬件配置、网络环境比迁移前更加优良
?各个系统开发部署人员已到位，并已做好相应的数据，代码备份工作
5.4迁移流程
迁移的具体流程及描述如下所示：
1.在评估阶段，虚拟化和迁移之前需收集服务器信息如下：
性能统计：包括cpu使用率，内存使用率，硬盘使用情况；物理服务器
配置：包括cpu规格，内存容量，硬盘容量。
统计物理服务器部署位置，分析是否支持虚拟化，累计支持虚拟化的服
务器数量，并规划处虚拟化中需新增的硬件情况；
通过上述无代理收集和代理收集两种场景手机当前系统的使用和配置情况。
2.分析现有服务的依赖条件，对当前系统进行备份。
确定应用系统对服务器的依赖关系，可作为迁移参考，确定服务器的迁移优先级顺序。
在确定各服务器的依赖条件后，对需进行虚拟化的服务器进行备份。
3.容量规划和虚拟化执行
根据当前的资源使用和需求情况，计算虚拟化所需的容量。
4.在拟化解决方案中，同类虚拟机部署在同一个计算资源池中，可相互共
享存储/计算资源，一个集群的故障不会影响到其他资源池。
5.虚拟化规划和虚拟机分配
建立虚拟化平台后，准备最终迁移资源；迁移前，如果服务器a具备双核CPU和2G内存，那么在虚拟化平台中就创建一个双核，2G内存的虚拟机，并分配相应的硬盘。
6.规划迁移工具
采用迁移工具从物理或虚拟的服务器向最终的虚拟化系统中进行磁盘复制。
7.通过工具执行在线迁移
准备好源系统，目标虚拟机以及目标系统后，决定迁移时所需使用的迁移工具和迁移策略。
8.迁移测试
迁移后，需进行系统的测试来验证迁移是否成功，测试场景如下：
应用系统迁移后的资源监控；
迁移后应用系统功能是否正常，与之前一致；
迁移后系统性能，安全测试。
6.数据迁移
针对本项目数据库迁移，需将中心积累的历史数据文件搬迁到服务器，并且要求最小宕机时间，同时面临数据库类型不同，且数据库不止分布在同一个服务器上。
6.1数据现状和问题
目前数据来源多样化，如一些数据来自CAD以及表格等不同数据，由工作人员导入系统；每个系统所采用的数据库类型不一致，例如有的是用的是oracle、
SQL Server,Gbase等，而按照要求使用的为oracle数据库，我们需要对后期数据的存储、管理与对接工作做一个重新的梳理工作。
6.2主要工作内容
6.2.1数据整理
数据整理就是将原系统数据整理为系统转换程序能识别的数据。整理大致分两个阶段：第一阶段就是将不同类型来源数据采集备份到统一的数据库中；第二阶段就是将原始数据进行整理，按照不同的要求分类进入不同的中间数据库，为数据转换提供中间数据。整理采用以下方法：
1.确保原始数据的完整性
在进行数据整理之间，我们先需要对原始数据进行备份。备份目的有两个：一是统一数据库。便于数据转换，另一个就是为以后数据追根溯源提供参考依据。
2.数据分级过滤策略
数据分级过滤就是把数据按照不同的数据级别进行分类整理，进入不同的中间数据库中。我们把数据分为三个级别：废弃数据、待调整数据、可转换数据。废弃数据就是该部分数据的存在会对系统资源造成浪费的数据，并且会影响以后系统的运行。待调整数据就是该部分数据严重影响新系统的运行，必须进行人工调整后，方可进行数据转换。可转换数据就是该部分数据不需做任何处理，基本满足数据转换的要求。
3.借助数据整理相关工具
数据整理非常艰巨，涉及的数据量很大，通过人工检查是不可能完成的，因此需编写相关的数据整理工具完成数据整理。包括数据整理工具和数据纠错工具。数据整理工具负责将原始备份数据库中的数据进行分类进入不同的中间数据
库；数据纠错工具负责提供友好、方便的工具界面提供用户方相关人员完善和纠正错误数据。
4.利用中间库作为桥梁
由于原系统和迁移后的数据库类型结果不一样，所以采用中间库作为衔接系统数据的重要桥梁，对于迁移前后系统的对照关系很重要。一旦业务人员对迁移后系统某项数据存在疑问，就可通过中间库的关联，顺利找出原数据。
6.2.2数据转换
数据转换就是将整理后的数据，依照表的要求进行转换，并存入新的数据库。
6.2.3系统切换
第一步：编写系统切换方案。
系统切换方案包括系统切换方法、系统切换计划等内容。
第二步：组织相关人员对系统切换方案进行评审，如未通过则需要调整系统切换方案。
第三步：进行系统业务数据转换。
第四步：迁移后系统运行监控及数据整理。
在所有迁移后的系统平稳运行后，还需进行定期的运行监控以及部分数据进行调整。对于那些对系统运行未造成影响的在数整理过程中，没有进行数据修正，所以在系统运行平稳运行后，需要对这些数据进行调整。
6.2.4系统切换保障措施
1）数据备份
在进行迁移前后系统数据转换时，对原系统数据进行备份，以保证历史数据
的可追溯性。一旦在迁移后的系统中出现问题，则可通过追溯历史数据来判断是数据转换错误还是系统程序BUG。
2）数据测试
数据测试分为两个层次测试，一个是数据监测性测试，就是在数据转换完成后，测试数据的转换正确性；二是验证性测试，验证性测试通过使用已经通过功能测试的迁移后系统办理实际业务来验证数据转换的正确性。
3）切换点选择
系统在什么时候进行切换，也是一个很关键的问题。一般情况下，我们都选择一个业务周期结束，下一个业务周期开始的时候进行切换。
4）切换方式的选择
系统切换方式有两种，一种是迁移前后同时运行，一种是迁移后的系统单独运行。对于第一种方式以迁移前系统为主，迁移后系统为辅，在时机成熟的时候在切换到甲方系统运行；第二种方式是以迁移后的系统为主，迁移前系统为辅，迁移前系统知识验证迁移后系统业务办理的正确与否。第一种方式安全系数高，但是过渡期会很长，业务人员工作量大，而第二种存在一定的粉线，但是我们可以加大测试力度来降低风险，综上，我们建议采用第二种方式。