金融行业NAS文件系统迁移停机时长难以准确预估和控制探讨？

NAS文件系统数据迁移确实是一个复杂的过程，其中增量数据停机迁移的时长受元数据扫描和对比所消耗的时间影响比较大。对于这个问题，一些经验和解决方案分享如下：
1、首先要站在业务连续性视角来梳理各应用系统的关联关系，梳理NAS共享卷的挂载关系以及相互依赖关系，还有每个NAS共享卷挂载点的数据读写时间段、读写频率等，形成详细的统计分析表，可以按应用系统及重要程度为维度进行挂载卷的排序，然后跟进应用系统的维护停机窗口制定迁移计划和切换计划。
2、评估老NAS存储的性能情况及业务系统的负载情况，在新NAS存储分配新的共享卷组，然后可以使用一台专用NAS数据迁移服务器，在其上挂载老NAS存储共享卷（只读）和新NAS共享卷（可读写），可使用rsync命令从老NAS存储共享卷将数据同步到新NAS存储共享卷，并记录首次全量数据同步的耗时情况，然后可以再次使用rsync命令同步数据，并记录增量同步数据的耗时情况，将操作步骤和耗时情况登记到统计分析表中，以此类推。
3、根据增量同步数据执行耗时情况以及业务系统停机维护窗口时长，统筹分析关联系统影响情况，在变更窗口期内进行相关应用进程的停止，执行增量数据同步，同时更新/etc/fstab设置，执行umount老挂载点和mount新挂载点的操作，并验证新挂载点的读写权限，核对该NAS共享卷所有挂载点均调整完毕，检查无误后启动应用进程并做好交易验证， 然后对外提供服务。
4、由于NAS共享卷可能很多，且每个共享卷的挂载点也很多，所以可能需要开展很多个批次的变更，务必要提前沟通好各项细节，而且要做好操作培训，执行结果的核对验证，避免遗漏挂载点导致的数据不一致的情况。

     NAS存储的数据迁移，迁移时长主要取决于多个要素，包括存款性能，网络带宽，文件数据总量的大小，数据文件的数量多少等。如果采用同型号的存储来在备份迁移，我以为主要因素是数据总大小和文件总个数。
    对于数据总量较大的数据，应该在日常运维中建立起数据的同步机制，定期全量备份数据文件，如需灾备切换或是发送其他异常情况，只需再同步增量数据，同步时间将会大大缩短。以不久前自身的一次数据迁移为例，只迁移一个文件系统，该文件系统数据数量约1TB，文件数量约在800万个，首次全量同步时间约1小时，停机后增量同步约为20分钟，无论是前两或是增量时间都比较长。
    如果文件数据较多，应该定期按特定规则打包、压缩文件，一是减少数据文件，能释放存储的读文件能力，更重要的是能大大缩短文件的同步时间，还是以工作中的经营为例， 文件系统数据数量约800，文件数量约在600万个，首次全量同步时间约45小时，停机后增量同步约为15分钟。文件打包压缩后400GB，文件数量300万个，全量同步才25分钟，增量同步5分钟，时间大大缩短。

如果是同品牌的，比较好处理，单活 ，买个兼容的双活，自动迁移。
如果不是同品牌的，
NAS不像SAN那样简单，NAS是共享的，金融行业主要用的2种，CIFS和NFS的比较多。
CIFS和NFS比较而言，CIFS相比NFS更复杂和难一些，CIFS一般受用户控制，金融行业客户一般不限制IP地址，NFS主要靠IP地址黑白名单来限制，所以CIFS的客户端统计比较困难，NFS相对容易，因为客户端IP地址可见，好统计，CIFS如果只看用户，客户端难以统计，再加上CIFS还有二次共享等，就更加难以迁移，从历史迁移的经验来看，主要关注以下几点：
①、现状需求统计，CIFS和NFS，分别有多少个文件系统和共享，每个文件系统的名称，大小，用户，权限读写策略，二次共享的信息，用户等；
②、统计完了，写大致的方案，有几种方式，是存储侧迁，还是主机侧迁，迁移工具是；
③、如果需要停业务，预估时间，尽量做的富裕一点；
④、拉上用户，对齐需求，方案，时间，谁验证等等；
对齐后，按计划实施。
迁移不麻烦，统计是问题，只要别统计漏了，用户配合，迁移只是时间问题。

a、通过查看应用历史性能数据和了 解应用作业规律来评估应用对NAS的写入量

b、提前建立迁移关系，在应用闲时完成数据初始同步

c、提前多次进行增量同步，评估准确的停机后数据迁移增量时间（数据对比和数据传输）

d、评估计算应用停机和启动时间、评估应用数据验证时间

e、根据应用停机和启动时间、增量时间、应用数据验证时间和应用可接受的停机窗口申请尽星充裕的停机窗

口己应对突发问题

{针对元数据量大，数据对比时间较长的担忧，建议使用存储底层数据迁移的方式，目前主流NAS厂商的迁

移产品都是基于快照技术 ，数据对比耗时很小，基本无需担心。

​ nas文件是一个共享存储，在nas文件迁移的时候主要考虑以下要素：

1、文件存储类型
2、文件存储大小
3、文件数量/文件每小时存储数量等
4、是否有可停机窗口
5、停机时间
6、业务带宽、文件系统IO等
​ 对于以上要素我们需要主要考虑的是业务系统允许停机以及停机时间较长，我们完全可以考虑使用rsync方式进行第一次全量同步以及增量同步的方式并且记录增量同步时间进行参考。同时rsync自带文件较检功能可减少nas文件系统迁移过程中出现文件损坏的问题。
​ 对于业务停机非常短或无停机窗口的业务环境，我们可以使用rsync + inotify 方式来实现文件的实时复制。从而可以实现nas节点逐步切换的方式。对于此种方案的选择需要考虑文件存储的大小，如果文件大小达到的1GB以上容易出现文件损坏。以上不论是采用哪种方式实现，都必须考虑nas存储文件过程中所占用的带宽问题，建议使用rsync的limit参数对传输速率进行限制以免影响业务的正常运行。

总的说来，停机时长与业务本身有很大的关系，NAS大量读写且没有相对有效空闲期的业务停机时长的预估会更不受控制，比如手机银行，这类系统为了尽量降低停机时长，可在系统设计时就充分引入高可用集群机制，采用NAS节点逐步切换的方式完成。此时唯一的风险点在于主备切换过程有相同应用节点挂载不同NAS存储的问题，会有短暂的部分新生成文件不一致的问题，在快速切换完成后在用rsync做一次同步即可，切记此时需要以不删除目标NAS存储文件的方式同步。这种方式可以大大降低系统停机时间，以笔者最近一次NAS迁移实施的效果看，约500G大小的7*24小时不间断读写的文件系统实际未停机，切换期间有部分交易读写报错，但业务未停机，实现了业务未停机的NAS切换。