阿里云文件存儲(Network Attached Storage，簡稱NAS)是面向阿里云ECS實例、HPC和Docker的文件存儲服務，提供標準的文件訪問協議，用戶無需對現有應用做任何修改，即可使用具備***容量及性能擴展、單一命名空間、多共享、高可靠和高可用等特性的分布式文件系統。相比于傳統的存儲設備，NAS所具有的高容量、高可靠、多共享等特性是現在諸多企業迫切需要的，能夠解決他們對現有系統在性能、擴展性方面的需求。傳統解決方案如何上云，***步就是原始數據的搬遷問題，如何做到不停服無縫搬遷，在很多場景下是非常棘手的問題，下面做簡單介紹。

[[207236]]

具體的場景是用戶的數據在某種存儲設備上，我們要將數據搬遷至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.

以上是數據遷移中幾個簡單的例子，實際的情況要更復雜一些，比如如何實現斷點續傳，流量控制，文件名編碼問題，權限問題等。如果對這些問題有興趣或者對文章有疑問，歡迎探討。