Linux物理服务器迁移实战笔记

439次阅读

共计 3339 个字符，预计需要花费 9 分钟才能阅读完成。

两天前我们对生产系统中的两台服务器做了在线迁移，因此在此想总结一下迁移前后发生的一些事情和获得的经验教训。本着专业做事的风格，在此前后我阅读了微软和红帽官方的一些迁移指南，但发现实用的部分并不是特别多，因此在参考了微软和红帽的迁移指南后我决定自己一篇符合当前场景的服务器迁移“指南”，仅供参考。

迁移背景：

两台服务器由于要挪作它用（可以理解为服务器硬件升级，新的服务器硬件比旧的服务器性能要好，如更强劲的 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. 整理迁移列表。

1). 包括源主机操作系统名称，版本，主机名称，环境变量，驱动程序，进程，安装的软件，安装的服务，防火墙，内核参数，安全设置，用户配置，证书密钥，文件权限等系统基础环境
2). 根据进程名、端口号、防火墙配置，或者找到系统维护管理日志，根据文档查找当前服务器正在提供的服务，服务的安装手册、服务依赖的软件环境
3). 根据文档或者源主机当前的网络连接状态，主要是使用源主机的内网地址的相关主机，例如找到代理源服务器的相关主机，留意这些代理主机上的配置，如固定写好内网 IP，域名信息等，需要一起更改，典型的例子就是 nginx、HAProxy 反向代理
4). 一些较为特殊的文件目录，软件编译目录，/etc/profile,~/.bash_profile,/etc/rc.local,~/.profile,~/.ssh,/etc/fstab,/etc/hosts,/etc/sysconfig 等等
5). 如果迁移项目或步骤过多，可以做成相应的列表，便于对照参考，和防止遗漏，可参考附录

2. 准备目标主机。

1). 采用手动（可以逐条操作也可以编写脚本等）的方式，将目标主机配置成与源主机尽可能相同的软件环境测试目标主机

3. 切换网络参数。如果只是切换公网 IP，不切换内网 IP，由于内网 IP 可能会做一些网络内部的耦合，因此需要注意其他相关主机

迁移总结：

1. 文档化标准化的实施很重要，尽管也许很辛苦很累，但要尽可能去做
2. 已经发生的变更需要及时修改相关文档和告知相关人
3. 部署规范化，如固定的编译安装目录，人性化的软链接，严格参照文档
4. 合理利用工具和技巧，减少操作时间
5. 软件设计过程中尽可能的高内聚低耦合，尽可能支持横向扩展，达到无状态的软件设计是一种非常理想化的设计目标
6. 有一些硬件制造商提供了一些迁移工具或者信息收集工具，可以进行参考，如 Dell 的 SystemManager、dset，Cisco 的 UCS Manager 等相关工具

如何避免夜间迁移、升级或业务变更等操作：

1. 要想避免半夜升级，必须采用 HA 的系统架构（无单点故障），即当有一台或多台服务器宕机时，对用户无影响
2. 软件尽可能的松耦合，尽可能支持横向扩展
3. 合理利用自动化、脚本、计划任务等
4. 多写测试多做演练，例如究竟能否正常回滚等
5. 凡事提前沟通，有事好商量，;)

附录：

如“迁移数据收集工作表”“xxx 变更表”等，迁移数据收集工作表可参考如下：