阿里云文件存储(Network Attached Storage，简称NAS)是面向阿里云ECS实例、HPC和Docker的文件存储服务，提供标准的文件访问协议，用户无需对现有应用做任何修改，即可使用具备***容量及性能扩展、单一命名空间、多共享、高可靠和高可用等特性的分布式文件系统。相比于传统的存储设备，NAS所具有的高容量、高可靠、多共享等特性是现在诸多企业迫切需要的，能够解决他们对现有系统在性能、扩展性方面的需求。传统解决方案如何上云，***步就是原始数据的搬迁问题，如何做到不停服无缝搬迁，在很多场景下是非常棘手的问题，下面做简单介绍。
具体的场景是用户的数据在某种存储设备上，我们要将数据搬迁至NAS文件系统。这里还分为静态迁移和动态迁移，静态迁移是指原始数据在迁移期间不会改变，而动态迁移是原始数据一直在更新。相对来说，静态迁移要比动态迁移容易很多。
静态迁移的主要步骤如下：
1. 将原始数据拷贝到NAS。
2. 分别计算原始数据和NAS上数据每个文件的MD5值，全部匹配就结束，如果哪些文件不匹配，重新拷贝之后再进行第2步。
动态迁移的主要步骤如下：
1. 设定一个时间点T1，一般为当前之间。把***修改时间在T1之前的数据全部拷贝到NAS。
2. 像静态迁移一样，计算MD5值，确保T1之前的文件全部迁移完毕。第二步完工的时间点为T2。根据搬迁的复杂性，T1和T2间隔可能几小时，长的可能数天。
3. 获取***修改时间在T1和T2之间的所有文件，将这部分文件拷贝到NAS，并做MD5校验。这步完工的时间点为T3。
理想的状态，如果上述动态迁移T2和T3之间的时间非常短的话(比如10分钟)，可以考虑在凌晨业务量比较小的时候把业务迁移上云。但在一些特殊场景下，比如原始数据文件特别多(几千万，上亿的小文件)，这个时候遍历扫描所有文件的meta信息，获取T1之后修改过的文件就很慢了，比较差的情形T2和T3的差距会有两三天。
如何解决这个问题呢?linux内核从2.6.13版本开始提供一个叫inotify的功能，可以监控文件系统目录级别的改动。在centos下面直接安装inotify-tool这个工具就好了，yum install inotify-tools。要想监控/aaa/bbb目录下面所有的文件改动只需要执行inotifywait -rm /aaa/bbb/ 就可以了，所有的改动都会打印出来。 不过这个又引入了另外一个问题，inotify的内核支持是非常消耗资源的，在64bit系统下面，监控一个目录需要消耗1kB的内存资源，也就是监听1000万的目录就需要10GB的内存。因此在目录特别多的情况下，要合理的控制inotify的监控目录数，必要情况下需要综合运用inotify+目录文件扫描的方法来缩短T2和T3的时间间隔。
下面针对NAS的特性讲讲具体应该怎么拷贝数据。NAS目前支持NFSv3、NFSv4.0和SMB协议(***一个目前正在公测中)，这些协议都是标准的文件访问协议，即只要用上述协议挂载上了NAS之后，就和读写本地盘没有差别了。NAS和本地盘***的区别在于支持高并发、多共享，所以如果条件允许，数据上传需要做到多线程、多机并发拷贝。
下面通过几个例子，简单介绍在目前的条件限制下如何快速迁移数据到NAS：
Case 1: 原始数据在ECS的云盘上
这种情况是所有数据搬迁中最简单的，由于数据已经在云上，只不过是把他们从云盘搬到NAS。***步挂载NAS文件系统，第二步多线程并发拷贝。SSD云盘的读取速度能够到300MB/s，NAS根据所购买的存储包和实际使用容量，带宽从100MB/s到560MB/s不等。
Case 2: 原始数据在阿里云OSS上
这种情况需要借助OSS提供的SDK，移步这里。主要思路也是并发拷贝，一个线程把oss一个bucket下面的object的key列出来，然后同时起多个线程读取oss的object写入nas。
Case 3: 数据在客户IDC，NAS在阿里云VPC
这种情况下IDC的服务器跟阿里云vpc内的ecs是网络不通的，而且目前NAS还不支持http协议的访问。因此解决方案一种方式是拉专线，直接连通IDC服务器和阿里云ECS服务器，先把数据上传ECS，再上传到NAS。第二种方案，不用专线直接走公网，中间转接用OSS，用户先把数据通过http推到阿里云OSS上，再把OSS上的数据拷贝到NAS。参考case2.
以上是数据迁移中几个简单的例子，实际的情况要更复杂一些，比如如何实现断点续传，流量控制，文件名编码问题，权限问题等。如果对这些问题有兴趣或者对文章有疑问，欢迎探讨。
