跨存储后台迁移数据的三种方案
在一套IT生产系统中，存储更换的原因，也许是设备过老，买不到备件了，也许是业务增长快，设备性能不够用了等等。当存储要需更换时，就会产生数据迁移的需求。如果旧存储中有CIFS文件这样带状态的数据需要迁移，情况就会更复杂一些。本文记录我所知的在新旧存储之间从后台带权限迁移CIFS文件系统的几种方式。
方案一：传统（一次停机）
对生产系统来说，可能是由多个业务组合起来使用的，下图中假设了两种业务。迁移的时候需要兼顾两者同步进行。共分三个阶段：初次同步 ------》 日常增量 ------》 最后割接。
平时准备，割切切换
说明
-
新存储的安装、Share建立、文件系统使用等操作和旧存储完全独立，不影响旧生产系统。
-
同步技术可以是存储厂商自己的专有拷贝技术（如HDS True Copy、Shadow Image、Netapp的Snapmirror、HP的Business Copy等），也可以是与存储品牌无关的文件层拷贝技术（如Robocopy、Fastcopy、Xcp、CMT等）
-
初始同步时监控设备CPU、磁盘使用率、网络吞吐等重要参数，评估风险和瓶颈因素。（包括底层存储、拷贝虚拟机、NAS网关等整个路径上的所有设备）
-
复制条的宽窄代表时间的长短，如果是存储厂商自己的拷贝技术（只可应用于自家品牌设备，同时隔代设备之间也可能存在兼容性制约），不管是基于FC SAN的还是基于NAS的，速度都会比较快。文件级别拷贝会慢一些。
-
初始复制是最慢的，后续的常规增量比对时间会缩短，频率、次数可以按需自己设定。通过持续地做增量对比，最主要目的是预测割接时最后一次同步需要的时间，和停机窗口时间进行比对。
-
割接时，所有业务要进行最后的同步，确保数据、权限一致。同步较慢的那个业务会成为瓶颈，是重点考量因素。
小结
因为新旧设备IP地址不同，业务端的割接是必要的，目的是告知系统：下一次登录的时候，从新存储的位置取数据。如果存储层面能够实现对于应用无感知——包括网络域名不变化，和底层实际承载对象切换的无感知——业务割接就可以免除。
方案二：虚拟化接管（两次停机）
虚拟化接管一般是同品牌设备之间使用——只有这样才能使用专用拷贝技术。下面以一个存在NAS机头/网关的场景举例，我们用新存储接管旧存储后做数据迁移。仍使用原NAS机头提供服务。如下图所示（红色为新存储、蓝色为旧存储）。
说明
-
存储第一次接入时，需要一次停机。这时新存储会接管旧存储。注意，对NAS网关来说，配置的仍然是旧存储，虚拟化对它是透明的。
-
停机窗口期间只需要完成虚拟化接管，即可恢复业务。此时，实际读写仍然由旧存储提供，但是路径会先经过新存储。在此同时，新存储后台异步拷贝旧存储的数据。注意，即使拷贝完成后，真正在处理IO的仍然是旧存储。使用过程中新产生的数据也会存储在旧存储（并通过同步程序向新存储迁移）。
-
第二次割接窗口，使得存储访问路径改变。IO全部转到新存储。新存储和旧存储之间的虚拟化关系可以保留，也可以终止。
小结
- 很显然，这种方案最大的弊端是割接次数较多。
- 由于是纯粹存储底层实现，对NAS网关透明，业务端可以不需要进行配置变更，继续使用原网络路径，比传统方案变更复杂度降低。
- 值得注意的是，虚拟化接管本身也可能有相当多的操作步骤。（以HDS G系列为例，大约有40条命令）
方案三：虚拟化接管（一次停机）
说明
仍然是存储虚拟化方案。第一步和上一个方案相同，利用一次停机窗口将新存储接入现网。不同点在于，有些存储的软件产品，可以实现虚拟化接管后的新、旧存储同时提供服务。接管完成后，旧存储开始不断地把旧数据向新存储迁移。业务恢复后，处理业务数据遵循以下两个原则：
-
新产生的数据，直接写入新存储。
-
只要需读取的数据在新存储有，就从新存储读取，否则从旧存储读取。
显然，当旧数据全部迁移到新存储后，旧存储上就不再有业务访问了，此时可将其退出环境下线，不需要再次停机。
小结
本方案比上一个方案的优势是少了第二次停机窗口，但是否能采取此方案取决于实际环境中的存储品牌是否支持该技术，以及该技术能否兼容具体新、旧存储型号、微码版本等。
总结
-
生产数据若要迁移到不同存储，停机总是难免的。不是因业务变更停机，就是因设备介入停机。
-
若迁移发生在同品牌存储之间，一定会存在文件复制速度增加和权限易于保留的优势，同时，也存在更多的技术选择——如虚拟化。相应的，商务成本高。
-
本文讨论三种方案都是整体性的后台拷贝割接方案。其实至少还有两种可考虑的其它思路：一是化整为零，在单项业务内再做切分，然后逐个处理，以提升成功率；二是改用前台拷贝——即“硬生生”地拷贝所有文件，并保证权限正确。
