记一次普通应用和数据的迁移
- 2024-10-06 21:05:00
- 丁国栋
- 原创 73
很久之前同事在客户那边部署了一套应用程序因为信创的原因需要迁移到新的服务器上，这是一个简单的记录，和大家分享。
之所以写下这篇文章纯属是巧合也是为了方便，因为客户要求在迁移之前需要确定一下迁移的方案，但客户要求填写的模板文件并不在这个电脑上，所以我打算把它写进博客里，既能把内容写下来传输过去，也可能给大家一些参考。
迁移的原则：
- 保证业务连续性，尽量减少对用户的中断，和需要用户做额外的工作；
- 尽量不更改之前的配置，包括系统架构、部署方式、配置参数等等（发生改变的称之为“升级”或者“变更”，而不是“迁移”）；
- 减少不必要的修改，原先什么样迁移后是什么样；
- 和相关人员做好沟通，防止沟通不到位造成误会等不必要的麻烦；
- 正式迁移之前一定要和客户确认好时间，尽可能的提醒1-2次，防止遗忘或者信息不同步；
本次要迁移的服务是典型的LNMP服务，即应用是PHP语言写的，运行在Linux上，使用MySQL数据库，采用Nginx和php-fpm方式运行。这次的系统也不是高可用，最多只能算是是冷备。
Nginx承担所有的服务入口，因此只有个机器是对外提供服务的，其他机器不对外提供服务。
之前部署方式是这样：
- 业务系统部署在客户内部，不访问Internet，仅内部使用
- 使用虚拟机的方式部署，不使用容器以及其他解决方案
- 部署是手动完成的，不是程序控制或者其他部署控制器控制
- 一共有6台虚拟机，两个nginx，两个php-fpm，两个数据库服务器做主从
- 虽然每个角色都有两台，但只能使用其中之一，所以每个角色都存在单点故障
- 由于nginx和php-fpm分开部署，所以还需要文件共享服务，这样nginx和php-fpm才能协同工作
新的部署方式1：
- nginx和php-fpm部署在同一个虚拟机，部署两套共2个虚拟机，减少2个虚拟机
- 两套web服务器需要文件共享服务共享数据，客户端把服务端数据实时复制到本地，便于故障切换
- 两套web服务器本质还是冷备，一台故障后需要手动切换到另一台
- 故障后需要重建文件共享，切换主备
- 其他保持不变
新的部署方式2：
- 使用虚拟机搭建容器化部署，兼容性和可移植性更好，便于迁移和扩容，也可以为迁移到云原生平台使用
- 除了数据库，各个角色都可以容器化
- 容器化部署需要注意容器CPU内存等资源上限的配置，需要考虑高可用，两个虚拟机之间要实现文件共享
- 容器化部署只能选择一个虚拟机部署，故障后需要在另一台虚拟机重建容器
- 故障后需要重建
- 其他保持不变
关于网络和安全策略：
有时客户的网络特别复杂，有各种安全策略要求，导致网络访问有各种阻碍，例如需要提前申请调整网络策略。在我看来，这个问题可以提早检测和判断，以免在最后切换阶段才出现。
1. 不管这里面网络多复杂，我们只需要保证原来使用服务的人员能访问到新环境里的服务。
2. 采用对比的方法，先把网络调通，比如现在我的身份是一个VPN用户，可以通过 域名 或者 IP 都能访问到，那么现在我们就去把网络打通，让用户可以通过 IP 访问到新环境里的服务。
3. 为了消除VPN用户身份的影响，在上面第2点完成后，我们要找一个实际的用户在他们的网络里能访问通过 IP 访问到新环境里的服务，注意，这里仅测试能否打开，其他的不需要测试。如果有条件，可以在PC本地添加一条hosts配置，将hosts配置 'IP 域名' 添加到/etc/hosts或者 C:\Windows\System32\drivers\etc\hosts 中再测试是否可以打开。
4. 在完成上面第2、3点，就基本可以保证我们需要的网络策略和配置是没问题的了。
其他注意事项：
- 我们在迁移之前，一定要对原有的系统的运行方式、部署方式和维护等心中了如指掌，不能遗漏，做到一对一完全映射；例如一些计划任务就容易被遗漏，需要仔细检查。
- 迁移的方案需要经过设计、编写、评审，确认无误后再进行；
- 一定要做好记录，整理好文档，便于后续维护者维护；
- 做好应急回退方案，保证随时可以回退；
- 在新旧系统切换时，往往会需要修改DNS解析，因为DNS缓存的原因，在迁移时，旧的系统一定要彻底关闭，如果因为要对比新旧系统，那么一定要设置仅允许指定的用户才可以登录；
迁移流程
- 根据源系统架构复制一套新的系统，原来的服务器、网络以及应用组织形式、配置参数等保持不变；
- 将数据从源服务器复制到新服务器，在新服务器上测试和验证功能；
- 乙方实施人员进行新系统功能验证，如果有问题则修复问题；注意整理有哪些需要验证的点；
- 甲方运维人员进行系统功能验证；注意整理有哪些需要验证的点；
- 在上一步验证没问题后，选择合适的时间节点进行服务切换；
- 关闭监控项，防止发送不必要的告警；
- 在源服务器上关闭负载均衡器，即不再接受新的请求；如有必要设置仅允许指定用户登录，便于后面新旧系统数据和功能对比；
- 将源服务器上的数据同步到新服务器；
- 注意修改那些迁移后新系统中的特有的配置参数，例如数据库服务器、NFS服务器等地址。
- 乙方实施人员进行新系统功能验证，如果有问题则继续修复问题；
- 甲方业务人员进行业务功能验证，如果有问题则选择继续修复问题或者回退；
- 在上一步验证没问题后，通过变更域名解析将流量发送到新服务器；
- 启用监控项，正常检查健康状态；
- 备份和关闭源系统；
检验对象（系统功能验证的验证点）
- 系统整体可访问性，确定新系统可以使用；
- 验证系统中的核心组件的功能是否可用，包括系统的各个组件的提供的功能至少要检验1项；
- 观测系统的负载情况；
整个迁移过程中还是发现了不少的问题。
- 由于项目周期较长，甲乙双方对接人员都有更换，同时甲方在同时进行多个系统的切换，增加了沟通和迁移复杂度；
- 本次实施不够标准化，手动操作的过程特别多，需要改进为自动化部署或者把操作用快速命令表示出来；
- 因为甲方安全策略要求，账户和权限等申请流程等待时间较长，没有一开始准备好，耽误了较多的时间；
- 由于文档的不完整或者沟通不充分或者限于双方人员的技术水平，直到做到某项工作才发现或没有权限或者不知道某项细节，导致频繁的沟通和申请某项资源。
- 在单人操作时有时会因为文档或者自身技术原因突然遇到一些短时间无法解决的问题，容易心浮气躁，需要自身克服（对比法、问他人或GPT等，能自己解决是最好的，对自己是一种提升），在解决后做好文档记录；
实施迁移的准备工作：
- 提前规划迁移方案，并确认好，在实施过程中可以补充和优化；
- 为实施迁移的人员准备VPN和堡垒机等账户，此账户可以登录到客户的VPN，进而登录堡垒机（建议给启用短信验证或者TOTP登录等MFA方式），确保该账户能连接到源服务器和新服务器。
- 源服务器和新服务器的网络需要联通，如果需要变更网络安全策略需要提前申请，以免耽误进度；
迁移过程中一些技巧和实施最佳实践：
- 服务涉及的所有服务器节点均要设置SSH互信，实现节点免密互联，在迁移后可以禁用这些设置，SSH的Hostname名称命名尽可能精简，比如n01和o01分别代表新旧服务器的第一个节点；
- 清晰准确地记录所有节点运行的服务细节、实施文档等等，便于日后查看（这是很多实施人员所欠缺的部分或者不愿去做的部分，作为甲方应该尽可能要求和仔细检验乙方的这些文档）；
--
