服务器数据迁移到新的服务器(服务器数据备份三种方式)-众学网

【摘要】本文主要介绍民生银行的文件服务器系统迁移改造的过程和方案，适合架构规划师、系统管理员、技术开发人员等阅读。文中重点介绍大的思路和方向，读者可以再深入研究技术细节，有助于更加熟悉文件服务器系统。

1前言文件服务器系统以FTP服务为基础，为民生银行两百多套应用系统提供临时文件传输服务功能。自投入生产使用以来，老文件服务器系统已经连续服役运行超过了十年。全行两百多套应用系统的联机和批量文件交互场景强依赖文件服务器系统，每天有几百万次文件的上传、下载传输请求。老文件服务器系统的架构比较传统陈旧，高可用采用HP UNIX的HA主备集群模式，无论是系统的负载能力，还是快速恢复业务已经很难满足需求。文件服务器系统的迁移改造急需完成，自迁移改造项目启动到完成历时两年的时间，期间经历了迁移方案的更换，也遇到了各种复杂的技术难题，最终在主动性维护窗口之内顺利完成新老服务器的迁移切换。本文主要介绍民生银行的文件服务器系统迁移改造的过程和方案，适合架构规划师、系统管理员、技术开发人员等阅读。文中重点介绍大的思路和方向，您可以再深入研究技术细节，相信您会更加熟悉文件服务器系统。2文件服务器系统的业务功能应用系统在文件服务器系统上都有对应的FTP用户名和组，且通常以系统的小写英文名命名。文件服务器系统为应用系统提供公共的FTP目录，存放临时文件用于数据交互。数据文件的交互形式主要有两种：1）系统间交互，即FTP目录上的文件，如系统A将文件放在FTP目录下等待系统B处理，系统B处理完成后将结果文件放回FTP目录待系统A取回。2）公共文件共享，即FTP目录上的文件共享给多个系统使用，如系统A将公共文件放在FTP目录给系统B、C、D等访问。这样一个简单又“免费”的FTP功能，在系统之间实现业务功能的时候，从几KB到几百GB的文件都可以安全的交互使用，便捷的服务性价比非常高。业务场景根据业务需求种类繁多，小到个人客户的某个账户交易明细联机查询，大到企业客户的代发工资文件批量处理，以及银行系统各种贷款批扣、理财申购、对账处理等日终作业的处理等。FTP目录下的文件在不同系统之间流转加工，既要有快速的实时响应速度，又要确保文件内容的完整性。3文件服务器系统老环境的困境文件服务器系统上的文件大规模嵌入到业务流程中，这对文件服务器系统的服务能力提出了很高的要求。几千台应用服务器日均几百万次的文件传输请求，文件服务器系统7*24小时不间断对外服务，大量的FTP连接和传输请求与底层的基础环境和网络稳定性又有着密切依赖，任何环节出现异常，都会影响正常的业务。传统的HA主备集群架构无法横向扩展，集群出现异常的切换时间是分钟级别，如果切换导致文件异常对银行业务的影响范围不可估量。为了支撑未来文件交互的业务增长，以及UNIX小型机下移到Linux开放平台，文件服务器系统的迁移改造正式启动。

图1是文件服务器系统老环境的部署示意图：

图2 文件服务器系统迁移前

图3新老环境并行过渡期

图4 文件服务器系统新环境6数据文件的迁移方案6.1 方案选择测试迁移改造第三、四阶段最关键的环节，是关于历史数据文件的迁移同步，根据现有的技术，制定了下表中的四种方案：

模拟生产环境，分别测试了四种方案的可行性，首先否定了NBU备份恢复和SRDF数据复制的方案。针对shell迁移脚本和rsync也在验证环境分别测试了迁移功能和效率，详细的记录如下表：

图5 通过FTP日志文件重建拷贝文件

图6 rsync命令同步复制目录和文件关于自主设计的shell迁移脚本和rsync命令工具都能够满足我们的迁移需求，但是仍然存在一定的风险和难度，下面简单介绍一下两种方案的思路。6.2 方案对比整合1）Shell迁移脚本：通过NFS技术将老环境的文件系统共享挂载到新环境服务器上，根据FTP日志文件，过滤出每个上传文件的记录，然后提取出文件名、目录、用户名等信息，格式化生成需要迁移的文件列表和目录列表。通过shell脚本提取目录列表，通过操作系统的mkdir、chmod、chown命令在新环境重建目录，再根据文件列表并发批量拷贝（cp）到新环境。2）Rsync命令工具：Rsync是操作系统自带的一个快速、多功能的远程和本地文件拷贝工具，通过递归方式传输文件并保持所有文件的属性，可以支持全量和增量的同步方式。通过NFS技术将老环境的文件系统共享挂载到新环境服务器上，以目录为最小单位，将目录下所有的子目录和文件全部同步拷贝到新环境服务器上。rsync命令简洁明了，除了-av还有几十个参数选项，可以跨平台将目录old_file下所有的数据全部同步拷贝到目录new_file下。

两种迁移方案的对比：

通过对两种方案的对比测试，发现两种方案各有利弊，shell迁移脚本是效率高，但是依赖FTP日志文件并且逻辑处理复杂；rsync命令性能差，但是数据一致性有保证。生产环境上应用系统对文件的处理有操作类型可能有特殊操作，比如重命名文件、更新文件内容、主动删除文件等未记录到FTP日志文件中。为了兼顾迁移性能和数据一致性，最终决定将两种迁移方案结合在一起。主要是将shell迁移脚本中重建目录和拷贝文件的逻辑简化成通过rsync命令来实现。文件服务器系统上两百多套应用系统共分配了480个用户和目录，计划将这480个目录分成10组，每组单独设计shell迁移脚本，10个并发恰好能够将服务器资源利用率最大化。7新老环境迁移切换7.1 迁移切换的过程新老环境的数据迁移切换其实在停机维护窗口前的T-30日已经开始准备了，但是在生产上提前迁移的时候发现迁移时间仍然超过10个小时，瓶颈是rsync命令在执行的过程中会先去递归扫描目录下面所有的目录和文件信息。当单个目录下小文件数量超过100万个，或者单个目录下的嵌套子目录数量超过1万个的时候，再叠加生产环境的文件频繁更新，迁移的性能急剧下降。必须在正式迁移切换之前解决性能问题，否则迁移任务将无法完成。这些问题目录涉及了多套使用文件服务器系统存放文件的应用系统，只能将这些有问题的目录列举出来，逐个去梳理目录的业务场景、清理策略、文件和子目录用途等。在得到每个应用系统负责人的确认后，清理了约800万个历史文件，总容量约500G，删除了约90万个嵌套子目录。这个过程是冒着很高生产操作风险，每一次删除命令都不允许出错！但是，当将问题目录全部处理完成之后，效果也出现了，在线迁移数据只需要1个小时，最终在维护窗口离线迁移数据时只花了30分钟。而且，因为经过“瘦身”之后的系统，也有足够的时间对迁移状态做全量检查，新老环境的文件和目录迁移之后完全一致。除了迁移数据文件之外，新老环境服务器上是完全不同的操作系统，FTP服务的底层实现差异很大，需要将FTP server端的配置参数逐一对比修改。主要是从FTP的传输模式、权限控制、用户控制、连接控制、日志格式等方面考虑，这里不再具体描述，建议系统管理员结合实际的应用需求去修改/etc/vsftpd.conf里面的配置参数。7.2 迁移切换的效果文件服务器系统迁移到新环境之后，由单台服务器变成多台服务器同时对外服务，新环境的架构支持横向扩展，变成了真正意义上的多活架构。从交易性能监控平台的数据（21端口的控制连接）可以看到，文件服务器系统的白天平均交易响应时间由平均约7.9毫秒，下降到了约2毫秒，而且交易高峰时间段的响应时间由起伏波动变成了十分平稳。

图7 老环境的交易性能数据（ 2021.10.11）

解决方案a：该目录下累计存放了20万个左右的历史文件，临时将不再使用的历史文件清理掉，nlist的查询速度恢复到1秒以内。解决方案b：建议应用程序在使用nlist的时候，需要结合应用程序进行性能压测，或者通过其它方式判断文件是否正常上传，规避nlist查询效率慢带来的影响。5）FTP Client端下载文件慢问题现象：某应用系统日终批量作业在老环境上下载机构信息文件时（4MB大小）耗时0.1秒，但是在新环境是下载同样文件时却消耗了700秒，导致了批量作业整体超时失败。原因分析：通过网络抓包分析，客户端到新环境的rtt （网络时延）比老环境快了50倍，达到了0.018毫秒，甚至比java ftp 客户端处理1152字节数据的速度（0.8毫秒）还要快。这导致FTP Server端不断收到来自Client端的zero window ，每收到一次，Server端都需要等待200毫秒后才能发送数据。相当于每200毫秒才发送1152字节的数据，这样发送4MB的数据就需要728秒。

图9 TCP Window Full的网络数据图解决方案：发现问题的应用系统使用的是commons-net-3.2.jar包实现FTP传输功能，默认未设置缓存大小，建议设置成8192或者更大，可以解决该问题。

6）FTP Client端判断FTP返回码异常问题现象：某应用系统日终批量作业下载文件服务器系统上的某个文件，如果该文件不存在，则开始定时轮询，直到查询成功后开始下载该文件，轮询结束。但是文件服务器迁移到新环境后，该日志批量作业查询到文件不存在时，直接退出轮询，导致作业异常失败。原因分析：经测试，在UNIX平台上如果文件不存在则返回FTP 550的报错码，但是，在Linux平台上如果文件不存在，在查询的时候直接返回空信息（FTP返回码226），应用程序FtpUtil.java无法判断返回码226的状态，则跳出定时轮询，导致下载文件失败。解决方案：应用程序对于文件是否存在的判断，需要兼容考虑不同平台的返回码，或者增加对文件数量的判断逻辑，否则会影响正常的业务逻辑判断。

7）FTP Client端未响应Server端的SYN请求问题现象：某应用系统通过FTP命令登录FTP Server，但是在下载数据文件的时候失败，导致后续的交易场景未正常执行完成。原因分析：通过网络抓包分析，该Client端已经建立控制连接，在开始传输数据之前（主动模式），Server端到Client端需要建立数据连接，但是Server端连续发了3次SYN请求，Client端都未正常响应，报错“Failed to establish connection”，最终数据传输失败。（细心读者应该发现7个问题案例中，有4次是“通过网络抓包”，分析了FTP交互数据过程中的每一步操作，才最终找到问题原因。）

图10 FTP Server端连续3次SYN请求解决方案：某应用系统在某个时间段业务繁忙，FTP Client端无法正常响应Server端的数据连接请求，在不调整业务的情况下，临时将传输文件的模式由主动模式调整成被动模式（跟第1个问题案例的模式相反），这样数据连接方向变成了从Client到Server端。9迁移改造的总结和展望文件服务器系统的迁移改造项目时间跨度两年，在多个部门团队的共同合作下，顺利完成。期间遇到过各种技术难题，严重的甚至影响到应用系统的正常运行，上一章节的案例中也简单分享了。回顾整个迁移改造项目过程，总结了一些经验教训。9.1 经验总结1）架构和项目规划系统的架构规划好坏决定了系统的健壮性，项目进度的规划决定了任务完成的技术性。技术方案充分讨论测试，项目任务提前协调考虑，做好充分的准备工作，自然能够顺利完成。2）团队合作文件服务器系统的迁移改造不仅仅是这个系统项目组的任务，整个过程中需要基础环境、网络、应用运维、应用开发等多个技术团队的支持。从底层技术，到应用场景，以及整改优化，团队之间的沟通讨论十分重要。3）测试验证事实上，正式迁移切换到新环境之后，是很难再回退到老环境，切换之后如果在新环境出现异常，影响的范围将非常大，风险很高。但是，所有的迁移改造任务都是在测试环境先验证，在测试环境提前大范围的验证，基本上确保应用系统在新环境能够正常使用文件服务器系统的服务。9.2 后续展望1）文件服务器系统的使用规范FTP技术提供了高性价比的文件传输服务，对于FTP技术在底层代码实现的逻辑需要深入研究分析清楚，再结合应用系统的使用场景，做好文件的正确性校验和传输过程中的异常处理。后续将根据已知的问题，继续更新文件服务器系统的使用规范。2）FTP Client客户端组件封装开发技术人员根据FTP使用规范可以去优化应用系统，但是在实现时每个人的理解可能会有差异，基础技术团队也会统一收集考虑需求，由专业的团队研究FTP Client的技术实现，将FTP的API规范统一封装成FTP组件，集成到TESLA开发平台中。3）应用系统的联机和批量拆分目前，应用系统的联机和批量都会通过文件服务器系统去交互临时文件，但是两种方式对于文件传输服务的要求不同，后续计划将文件服务器系统拆分成联机服务和批量服务的两大模块。另外一方面，随着新技术的发展，非结构化数据平台在管理文本、图片、音视频等数据时，能够提供比FTP更加高可靠、高性能的服务。根据应用系统的场景分类，计划将部分服务尝试迁移到非结构化数据平台。