两天前我们对生产系统中的两台服务器做了在线迁移，因此在此想总结一下迁移前后发生的一些事情和获得的经验教训。本着专业做事的风格，在此前后我阅读了微软和红帽官方的一些迁移指南，但发现实用的部分并不是特别多，因此在参考了微软和红帽的迁移指南后我决定自己一篇符合当前场景的服务器迁移“指南”，仅供参考。
迁移背景：
两台服务器由于要挪作它用（可以理解为服务器硬件升级，新的服务器硬件比旧的服务器性能要好，如更强劲的CPU、内存和存储），因此要把原先的两台服务器迁移到新的两台服务器上。由于白天活动用户数量比较多导致每一台服务器的并发数较高，因此要在夜间进行迁移（后面会讲到如何避免这种情况）
一些迁移的相关概念：
系统的迁移是指把源主机上的操作系统和应用程序移动到目的主机，并且能够在目的主机上正常运行。在没有虚拟机的时代，物理机之间的迁移依靠的是系统备份和恢复技术。在源主机上实时备份操作系统和应用程序的状态，然后把存储介质连接到目标主机上，最后在目标主机上恢复系统。随着虚拟机技术的发展，系统的迁移更加灵活和多样化，因此如果是虚拟化环境，那就简单的多了，因为虚拟机可以认为是无状态的计算。
一些迁移原则：
1. 尽量不中断业务，不影响用户使用，如果影响用户使用，则应该告知用户做好接受和准备
2. 服务器硬件资源要统一，如硬件架构、芯片组、处理器等
3. 系统软件运行环境要尽可能保持一致
4. 用最合适的人去做这件事情，有问题及时沟通
一些迁移指标：
1. 整体迁移时间：从源主机开始迁移到迁移结束的时间
2. 停机时间：迁移过程中，源主机、目的主机同时不可用的时间
3. 对应用程序的性能影响：迁移对于被迁移主机上运行服务性能的的影响程度。
一个优秀的迁移工具，目标是最小化整体迁移的时间和停机时间，并且将迁移对于被迁移主机上运行服务的性能造成的影响降至最低。当然，这几个因素互相影响，实施者需要根据迁移针对的应用的需求在其中进行衡量，选用合适的工具软件。对于Linux系统的迁移，由于是开源系统，因此可以借助一些开源工具和脚本，手动迁移系统，这种方法要求负责实施迁移的管理员必须具有相关经验，并且对物理机中运行的Linux系统非常熟悉。
迁移的整体步骤以及流程：
1. 准备迁移
1). 收集源主机硬件信息与软件环境等信息，准备与源主机的相关软硬件文档
2). 依据上述信息和文档将目标主机配置成与源主机相同的软件环境（服务器硬件资源统一的条件下）
3). 测试上述配置结果（测试方法参考验证迁移）
4). 以上工作在迁移前做好
2. 实施迁移
1). 提前通知相关人员，做好迁移准备
2). 切换网络参数，如切换IP等
3). 关闭源主机上的业务应用程序
4). 启动目标主机上的业务应用程序
5). 重新启动或平滑重启相关主机运行的关联服务
6). 迁移当天完成
3. 验证迁移
1). 自测迁移结果
2). 请其他人员测试迁移结果，如研发团队或测试团队的相关人员
3). 迁移当天完成
4. 迁移后任务
1). 汇报通知到相关负责人
2). 汇报通知到相关用户
3). 更新相关文档和记录
5. 完成迁移（同“迁移后任务”）
6. 回滚
1). 重新切换网络参数，如切换IP等
2). 关闭目标主机上的业务应用程序
3). 启动源主机上的业务应用程序
4). 更新相关主机运行的关联服务的配置文件等，重新启动相关主机运行的关联服务
5). 修正问题，准备下一次迁移
应用切换/迁移的注意点：
1. 有一些应用程序因为实施之前需要测试，但启动后可能跟生产环境中的一些服务器有冲突，例如消息处理应用程序可能会与其他消息处理程序争夺消息队列中的消息，因此测试时需要注意消除这种可能存在的冲突问题，这也要求应用程序需要尽可能的松耦合，尽可能的模块化，以便于更改。
2. 迁移过程中，启动目标主机上的业务应用程序，必须关闭源主机上的业务应用程序，反之亦然
3. 无论哪种切换，尽量做到无遗漏，事事巨细
下面列举一下Linux系统迁移过程中需要注意和考虑的地方：
1. 整理迁移列表。