文件服务器系统迁移改造之路 | 最佳实践

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

【作者】刘星

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是文件服务器系统老环境的部署示意图：

图1 文件服务器系统老环境

4迁移改造的挑战

整体的迁移改造整体思路是将当前的主备HA集群架构改造成DNS+F5+GPFS集群架构，服务器由4台HP UNIX更换成5台Suse Linux服务器，其中2台是同城灾备服务器，实际对外服务的服务器由1台变成了3台。老文件服务器系统上默认保留了7天之内的文件，需要将这些存量数据文件同步迁移到新文件服务器系统上。

迁移改造主要面临三方面的挑战：

1）技术方面：新老环境是两套完全不同的环境，操作系统由UNIX更换成Linux，文件系统由单机更换成GPFS共享文件系统，HA主备更换成F5负载均衡集群，FTP功能由UNIX更换成Linux平台的vsftpd。

2）应用方面：两百多套应用系统在老服务器上存放了约1000万个总共1.5T大小的历史文件，120万个文件子目录，所有的用户名密码、文件目录结构权限、历史文件等全部需要迁移到新服务器上。

3）业务方面：应用系统需要提前将通过浮动IP访问修改成通过域名访问文件服务器系统，这样新老环境只需要更换域名下的IP地址就几乎不影响应用系统的正常运行。另外，新老环境迁移历史文件需要离线停机窗口，但是停机窗口的时间又受限于银行系统的日终批量任务。

5迁移改造的四个阶段

文件服务器系统作为基础服务平台，在做迁移改造计划的时候，原则上是不影响应用系统的正常业务。整改的迁移改造计划分成了四大阶段：

第一阶段：测试环境域名改造，入访的应用系统安装DNS解析域名工具，将应用配置由IP访问修改成域名访问。

第二阶段：生产环境域名改造，入访的应用系统安装DNS域名解析工具，按照从低到高的系统优先，将入访的应用系统由IP访问修改成域名访问。

第三阶段：测试环境新老服务器迁移，由HP UNIX更改成Linux操作系统的服务器，同时将历史文件迁移到新服务器，将域名下挂的F5 member指向新服务器。测试环境的应用系统切换之后，验证各种使用FTP服务的场景。

第四阶段：生产环境新老服务器迁移，由HP UNIX更换成Linux操作系统的服务器，操作步骤与测试环境相同，但是只能在有限的维护窗口之内实施。

其中，第一、二阶段涉及到两百多套系统的几千台应用服务器修改配置，分成多个批次在变更窗口实施，时间跨度超过一年，期间遇到了各种应用配置修改的问题，在此不再描述。

下面三张示意图展示了生产环境的不同阶段，最终新环境的服务器代替老环境的服务器对外提供服务。

图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）

图8 新环境的交易性能数据（ 2021.11.01）

8生产问题案例

文件服务器系统提供的FTP服务看似简单，在应用系统调用时如果没有考虑异常处理机制，可能引起交易失败。本章节按照FTP服务异常的分类，简单分享了个关于文件服务器系统的生产案例，供参考学习。

1）FTP Server端的端口被占用

问题现象：某应用系统产品信息发布后，应用本地生成了产品交易状态的文件，通过FTP命令上传到文件服务器系统后，异步通知渠道系统同步文件。渠道系统下载了文件并入库，但是入库后的产品交易状态内容为空，导致所有的产品状态无法在渠道正常展示。

原因分析：通过网络抓包分析，应用系统访问文件服务器系统时，是通过“F5 VIP 地址”映射方式实现，且F5 VIP采用单一SNAT IP进行转换与后端真实文件服务器建立连接。两次文件传输过程中，由于部分客户端拆连接时为按标准控制指令，进行拆连接，导致第1次的数据连接未拆链完成，FTP Server端占用的临时随机端口不释放，此时第2次（与第1次的客户端不同）建立新连接如果也使用相同的端口，导致FTP Server端无法建立数据连接。所以第2次传输的文件在文件服务器上未正常完成,实际上是个空文件。

解决方案a：应用系统连接FTP的方式由被动模式改成主动模式，这样建立数据连接的时候，FTP Server端主动与FTP Client端的随机端口建立连接，相对于被动模式，避免FTP Server端连接数多的情况下，随机端口被占用的情况。

解决方案b：文件服务器系统的F5由SNAP IP修改成透传源IP地址，这样FTP Client端和Server端之间由映射IP对Server IP（一对一）变成Client IP对Server IP（多对一），避免了FTP Server端随机端口被占用的情况。

2）FTP Server端上的连接被reset

问题现象：文件服务器系统在某个时间段，FTP Server端的流量突然下降。当时部分应用系统正在做日终批量处理，由于批量处理的文件需要在贷款系统、公共支付、银行核心等多个系统之间加工交互，作业链条被迫中断，需要人工进入干预。

原因分析：文件服务器系统的FTP服务是正常状态，而且未做任何操作的情况下，流量又恢复了。但是，操作系统日志显示文件服务器系统的服务器（即member）到上层的F5 VIP有大量“lost connection”报错，应用系统Client端到FTP Server端的连接被reset。应用系统访问文件服务器系统时，F5 VIP采用单一SNAT IP进行转换与后端真实文件服务器建立连接，由于部分客户端拆连接时未按标准控制指令进行拆连接，导致F5偶发性与后端FTP Server连接未能正常拆除，当新建连接发起请求时，采用了与异常拆连接同样的SNAT IP+端口时产生了随机端口冲突，F5在端口转换机制上出现了短时间的异常，对于新建连接进行了Reset拆链，导致调用FTP的请求无法正常转发到FTP Member上。

解决方案：文件服务器系统的F5由SNAP IP修改成透传源IP地址，降低由于个别客户端不规范拆除连接，带来单一SNAT IP地址转换机制问题，并且文件服务器由主备HA集群架构改造成DNS+F5+GPFS集群架构，解决FTP server端单点的问题，提升文件服务器FTP整体对外服务能力。

3）FTP Server端和Client端的文件大小不一致

问题现象：某应用系统通过FTP命令传输数据文件和校验文件（filelist）到文件服务器系统，下游数据管理系统（MDS）获取到数据文件和校验文件，但是在通过filelist校验文件时，发现数据文件的实际大小和filelist里面记录的大小不匹配，导致MDS下载数据文件失败。

原因分析：文件服务器系统由HP UNIX迁移到Suse Linux平台后，应用客户端传输文件到文件服务器系统由同平台变成了跨平台传输，在传输文本文件时，系统默认选择文字模式（ASCII）传输，导致文件格式和大小发生变化。

解决方案a：应用客户端在传输文件的时候，显示的指定二进制模式（BIN），这样传输文本文件的时候，格式和大小就不会发生改变。

解决方案b：在文件服务器系统的FTP参数配置文件里面，设置ascii_upload_enable和ascii_download_enable参数，官方文档里面关于这两个参数的解释是设置是否启用ASCII模式上传下载数据，默认值为NO。实际上，根据测试结果，当将两个参数设置成YES后，应用客户端在传输文件的时候，无论以ASCII还是BIN模式传输文件，都不改变文件的格式和大小。

4）FTP nlist命令查询文件慢

问题现象：某应用系统在文件服务器系统迁移到新环境之后，联机交易平均响应时间由0.2秒上升到10秒。应用日志显示，交易耗时主要在应用系统与FTP Server端之间的交互。

原因分析：该应用系统联机交易会先查询（nlist）文件服务器系统目录下的文件，判定是否存在。通过网络抓包分析，再结合vsftpd的代码， Linux平台的vsftpd和UNIX的ftp功能实现有差异，vsftpd里nlist不仅会查询文件，还会对目录下所有文件概要信息做遍历，然后通过filter和sort返回结果到客户端。当目录下的文件越多，nlist的查询效率越慢。当应用系统短时间查询不到结果时，尝试发起重试，应用逻辑处理慢叠加nlist查询效率慢，最终导致联机交易的整体响应时间变长。

解决方案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更加高可靠、高性能的服务。根据应用系统的场景分类，计划将部分服务尝试迁移到非结构化数据平台。

原题：文件服务器系统迁移改造之路 via.民生运维人

觉得本文有用，请转发、点赞或点击在看，让更多同行看到