课题概要

本研究旨在深入探讨中小银行NAS存储迁移项目的关键重点和面临的主要难点。本次探讨是深入解析NAS数据迁移过程可能遇到的困难及一些同行的见解，通过对一些实施案例的总结和探讨以形成一个可实施的方案，以确保数据的安全、可用性和合规性，同时降低运营成本，提高业务效率。

课题主持

程宗憬 某城商行系统工程师
目前主要负责小型机、存储、国产化等方面的运维及管理工作。银行从业多年，对存储双活、系统高可用等方面有丰富的经验。

课题指导：

twt社区存储领域专业委员—— 中原银行系统架构师 朱向东
twt社区存储领域专业委员 ——某农商银行存储架构师袁宏松
twt社区存储领域专业委员 ——某金融企业存储架构师徐志国
twt社区专家 ——某股份制银行存储架构师李铭
twt社区专家 ——某银行技术经理 高晓峰
twt社区专家 —— 张文正

课题协作：

twt社区专家 ——某省农信存储架构师康建国

背景：

随着金融业日益数字化，中小银行不仅积累了大量客户数据、交易记录和业务报告等各类数据，还需要应对不断增加的合规性要求。同时，既有的存储设备和基础架构可能面临着性能下降、安全漏洞和高维护成本等问题。为了满足业务发展及客户需求、确保数据安全性，并满足监管机构的合规性要求，中小银行势必面临基础设备迭代更新的过程，其中NAS数据迁移到现代化、高性能、安全性和可扩展性的存储，是绝大部分数据迁移实施中经常碰到的场景。

在这个背景下，本研究旨在深入探讨中小银行NAS存储迁移项目的关键重点和面临的主要难点。本次探讨是深入解析NAS数据迁移过程可能遇到的困难及一些同行的见解，通过对一些实施案例的总结和探讨以形成一个可实施的方案，以确保数据的安全、可用性和合规性，同时降低运营成本，提高业务效率。

一、NAS文件系统迁移停机时长的预估和控制

NAS文件系统迁移包括存量数据在线迁移+增量数据停机迁移两大步，增量数据停机迁移的时长受元数据扫描和对比所消耗的时间影响，即使最后的增量数据变化很小，也可能由于基础元数据太大而消耗很大对比时间。因此一般NAS文件系统过程中普通存在停机时长难以预估和控制的难题。

NAS存储的数据迁移，迁移时长主要取决于多个要素，包括存款性能，网络带宽，文件数据总量的大小，数据文件的数量多少等。如果采用同型号的存储来在备份迁移，比较好处理，主要因素是数据总大小和文件总个数，买个兼容的双活，即可实现自动迁移。主要难点在异构的非同类存储。

NAS不像SAN那样简单，NAS是共享的，金融行业主要用的2种，CIFS和NFS的比较多。CIFS和NFS比较而言，CIFS相比NFS更复杂和难一些，CIFS一般受用户控制，金融行业客户一般不限制IP地址，NFS主要靠IP地址黑白名单来限制，所以CIFS的客户端统计比较困难，NFS相对容易，因为客户端IP地址可见，好统计，CIFS如果只看用户，客户端难以统计，再加上CIFS还有二次共享等，就更加难以迁移，因此更多时候金融行业选择NAS较多。针对这个问题，结合各个同行的经验，一般建议以下的方式。

1、首先要站在业务连续性视角来梳理各应用系统的关联关系，梳理NAS共享卷的挂载关系以及相互依赖关系，还有每个NAS共享卷挂载点的数据读写时间段、读写频率等，形成详细的统计分析表，可以按应用系统及重要程度为维度进行挂载卷的排序，然后跟进应用系统的维护停机窗口制定迁移计划和切换计划。

2、评估老NAS存储的性能情况及业务系统的负载情况，在新NAS存储分配新的共享卷组，然后可以使用一台专用NAS数据迁移服务器，在其上挂载老NAS存储共享卷（只读）和新NAS共享卷（可读写），使用rsync + inotify 方式来实现文件的实时复制。对于此种方案的选择需要考虑文件存储的大小，如果文件大小达到的1GB以上容易出现文件损坏。以上不论是采用哪种方式实现，都必须考虑nas存储文件过程中所占用的带宽问题。建议使用rsync的limit参数对传输速率进行限制以免影响业务的正常运行。

3、根据增量同步数据执行耗时情况以及业务系统停机维护窗口时长，统筹分析关联系统影响情况，在变更窗口期内进行相关应用进程的停止，执行增量数据同步，同时更新/etc/fstab设置，执行umount老挂载点和mount新挂载点的操作，并验证新挂载点的读写权限，核对该NAS共享卷所有挂载点均调整完毕，检查无误后启动应用进程并做好交易验证， 然后对外提供服务。

4、由于NAS共享卷可能很多，且每个共享卷的挂载点也很多，所以可能需要开展很多个批次的变更，务必要提前沟通好各项细节，而且要做好操作培训，执行结果的核对验证，避免遗漏挂载点导致的数据不一致的情况。

总的来说停机时长与业务本身有很大的关系，NAS大量读写且没有相对有效空闲期的业务停机时长的预估会更不受控制，比如手机银行，这类系统为了尽量降低停机时长，可在系统设计时就充分引入高可用集群机制，采用NAS节点逐步切换的方式完成。此时的风险点在于主备切换过程有相同应用节点挂载不同NAS存储存在短暂的部分新生成文件不一致的问题，在快速切换完成后在用rsync做一次同步即可。可在日常运维中建立起数据的同步机制，定期全量备份数据文件，如需灾备切换或是发送其他异常情况，只需再同步增量数据，同步时间将会大大缩短。如果文件数据较多，应该定期按特定规则打包、压缩文件，一是减少数据文件，能释放存储的读文件能力，更重要的是能大大缩短文件的同步时间。

二、NAS文件系统迁移完成后的数据如何校验

1、NAS文件系统迁移完成后的数据校验基本依赖于操作系统COPY或者rsync命令，也就是只能信任系统是正常工作的。人工无法进行完整的校验，只能抽查。因此数据校验也是一个需要重要关注的问题。一般来说，文件系统的校验有以下常用的方法。

2、采用shell/python脚本计算md5值进行较检，也可以通过使用一些文件比较工具来实现，例如Beyond Compare、WinMerge等。这些工具可以快速比较两个文件夹或文件的内容，以确定它们是否一致。如果校验和不一致，则说明文件可能已经被损坏或篡改，这个方法高耗资源、时间长，实际生产不推荐。

3、文件系统使用率，文件系统inode值，如果是专用nas存储之间的迁移，存储一般带有自动检查inode的功能来判断文件是否有差异，但是操作相对繁琐，且存在操作风险。这种方法属于目测类别，对于不同的文件系统使用率、inode都不准，同样不建议使用。

4、nas存储底层同步。专用nas存储之间的迁移，存储一般带有自动检查inode的功能来判断文件是否有差异，但是操作相对繁琐，且存在操作风险。在nas存储设备允许的情况该方式推荐，属于文件块级别复制，安全可靠。

5、rsync方式同步，且rsync在NAS切换完成后仍然可继续以不删除目标端的方式同步。同时，可以搭配人工统计源端和目的端的迁移数据容量字节数和文件个数来作为辅助验证。支持全量、增量复制、支持文件较检功能，推荐使用。

6、随机抽查较检，可以随机抽查一些文件进行校验，以确保它们已经成功迁移。可以选择一些关键的文件或者文件夹进行抽查，例如财务报表、客户数据等。如果抽查的文件一致，则可以认为整个文件系统已经成功迁移。实际很少使用。

7、定期备份校验：可以定期备份迁移后的文件系统，并将备份文件进行校验。如果备份文件与源文件一致，则可以认为迁移后的文件系统已经成功备份。同时，备份文件也可以作为恢复数据的来源，以防止数据丢失。

综上：nas文件迁移的较检可选的方式还是较多，主要是依赖文件系统的迁移方式。对于存储级复制的迁移是最稳妥也最安全。如在不同的存储进行迁移建议采用rsync方式，命令自带文件较检算法，以多次同步的方式完成校验。

三、NAS数据迁移实现方式

通过存储端复制的技术迁移速度更快，但是对源端和目标端NAS设备有品牌、型号和版本的要求，为了满足这个要求可能要对老NAS设备进行版本升级。在这个时候NAS数据迁移是选择使用客户端进行迁移还是通过存储端进行数据迁移,同样是需要考虑的问题。主要的考虑因素如下。

1、存储端的迁移方式

存储端迁移更多依赖存储厂商和存储设备自身的功能，借助存储底层的数据同步功能完成数据迁移，这种方案速度最快相对也最安全稳定，不用担心操作系统和文件系统对存储文件的影响。缺点是源端和目标端NAS设备的要求相同，且都支持存储端复制的技术。价格高同时要考虑设备兼容性。但存储端迁移的收益也比较明显，因为存储端数据迁移的整个过程几乎可以做到用户无感知，业务无感知。且仅在初始数据同步时占用部分存储带宽，后续增量数据的复制数据可以做到实时同步，且可以保证目录及文件的权限无变化。最后仅需要在存储切割时影响业务访问。

2、主机端的迁移方式

一般情况都是主机端进行迁移，因为一般都不是同一品牌的，即使是统一品牌，估计新旧存储的双活兼容也不容易。为了尽量减小对生产环境的影响，在实施过程中尽量避免安装额外的工具客户端，使用系统自带的rsync工具文件同步的方式完成迁移。rsync同步过程需要考虑的因素包括文件权限、网络带宽占用、增量同步的时间间隔，NAS存储切割时间点的数据校验等。总体需要人工控制的因素较多，因此实施过程会相对复杂，且对生产环境带来一定影响。有实施案例中，rsync同步过程因为碎文件较多，在未限制同步带宽的情况下因长时间占用带宽影响其他业务系统访问性能的问题，后续通过带宽限制解决，带宽限速又会大大延长同步的时间。

综合以上，在有条件选择存储端同步的情况下有限选择存储端同步。如若不可，在主机端同步需要充分考虑同步过程数据的一致性、文件及目录的权限、对生产环境带来的可能影响等，做好应急预案。避免出现问题时，长时间影响业务的情况发生。在进行数据迁移之前，需要进行充分的备份和测试，以确保数据的完整性和可靠性。同时也需要注意数据的安全性和隐私保护，避免数据泄露和丢失。

四、不停服的NAS数据迁移如何实现

NAS存储是否有在线迁移方案，如根据不同挂载目录IO监控情况，在无IO窗口进行切换。停服对我们系统可用性指标影响比较大，我们现在都是严控停服时间窗口，其实不仅仅是NAS存储，包含底层其他平台或设备，能做到在线不停服是最好的方案。但在实现上要求较多，实施也较复杂。

NAS存储迁移是否需要停止服务主要取决于你们所采用的NAS存储替换方案和应用架构以及对NAS共享卷的读写频度。

如果通过存储底层数据复制且同一种型号存储可实现切换后保持NAS服务IP地址切换不变，可以实现应用端无需应用启停，无需手动对文件系统进行卸载挂载操作，几乎可以做到对应用无感知不停服务，这种情况对底层环境要求较高，且对基础环境要求较高。

更多时候我们是通过客户端方式进行同步的情况，这时候无需停服的NAS迁移方案很大程度取决于业务系统的类型及应用系统的高可用架构。 NAS的切换过程一般都涉及到节点应用的启停，只有在停掉应用及文件系统读写操作时才有可能对文件系统进行umount及mount的操作，才能进行新老NAS存储的切换。
（1）业务系统的高可用架构是实现不停服务切换NAS的先决条件，只有在具备多节点提供服务的前提下，才能在单节点进行NAS文件系统umount及mount时，其他节点可以继续提供服务，同时先切换节点恢复服务后可实施下一节点的NAS切换。
（2）在切换过程中，存在先后切换的节点挂载不同NAS存储的过度时间，因此如果是7*24小时业务，则需要选择IO负载和NAS文件系统读写最为空闲的时间段实施，否则过度时间内大量读写容易造成数据不一致，给后续同步带来困难。
（3）在完成所有节点的切换后，需要对NAS文件系统作一次同步，且需以不删除目标端文件的方式进行，以防在同步时删除在切换的过度时间内新NAS存储中生产的文件，造成数据丢失。这里讨论的情况也有一定的局限性，如果NAS文件系统文件的缺失影响生产交易，则还是存在业务短暂停服的可能。

NAS迁移不停机，是整个存储产业的追求，可是到目前为止，也就Netapp在自家同构存储换代的时候实现了这个能力，特性叫Volume Move，就是按照租户粒度迁移数据到不同的阵列，然后IP跟着租户最后漂移，但是一旦更换为第三方异构阵列，就无法实现。客观讲，金融行业都强调不停机，但是从实际操作看，短周期停机更具备实操性。基本上可见的NAS迁移工具都是Rsync的各种变更版本，优化版本，扫描的过程时长，往往远大于数据真正传输的时长。同时，从存储到主机，再到存储的折线形传输过程，也是造成数据同步慢的问题之一。这些年。客观讲，眼下还做不到无中断迁移，或者说无中断迁移条件比较苛刻，还只是通过迁移路径和方式的优化，把迁移数据的速度提升了几倍甚至十倍，可以接管第三方NAS存储，这样可以实现较短中断，原理是，优先接管第三方NAS存储，这中间要做配置和映射，这期间需要几分钟的中断时长，但是一旦完成接管配置，所有后续的操作都是后台业务流，不再需要中断。客观讲，这也是目前业界在迁移第三方异构NAS的方案中，中断时长最短的。一方面有初期接管，就规避了二次增量传输所需要的文件扫描，另一方面，阵列对传，绕开了主机这一中间媒介，大大提升了速度。

五、小结

以上我们对NAS存储迁移过程需要考虑的核心问题进行了探讨，并结合了同行实际的实施经验。总体来说NAS迁移对不同存储类型，不同基础环境，不同业务类型等等都有不同实施方式。在基础环境允许的情况下，通过存储端对端的复制迁移方式是首选，可基本实现不停服的NAS迁移，影响最小，对于数据校验及停服时间也基本可预期，同时操作相对简单，但对应成本较大。更多情况优先选择rsync方式，以中间服务器初始同步加增量同步的方式实现客户端侧的数据迁移，在充分考虑业务类型及架构特征的基础下，做好充分的测试验证及预案，基本可实现在影响可接受的范围实现NAS的迁移。