NAS資料遷移初探

阿里雲檔案儲存（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.

以上是資料遷移中幾個簡單的例子，實際的情況要更復雜一些，比如如何實現斷點續傳，流量控制，檔名編碼問題，許可權問題等。如果對這些問題有興趣或者對文章有疑問，歡迎聯絡王俊俏（巨饃）探討。