海量小文件，例如2000萬數(shù)據(jù)量，如何確保復制數(shù)據(jù)在主備兩端的一致性？傳統(tǒng)的災(zāi)備方式，在第一次全鏡像的同時，如何確保鏡像過程中增量部分的同步？

數(shù)據(jù)存儲是門大學問，比如用戶的關(guān)鍵業(yè)務(wù)數(shù)據(jù)存儲，通常是在大型數(shù)據(jù)庫的基礎(chǔ)上進行存儲與管理，其相應(yīng)的數(shù)據(jù)存儲形式主要是數(shù)據(jù)塊(Block)，中小型數(shù)據(jù)庫則可能會采用文件形式(file)。

但是作為辦公自動化OA、卷宗類海量內(nèi)部文檔管理、多集群前端業(yè)務(wù)平臺、互聯(lián)網(wǎng)業(yè)務(wù)平臺、財務(wù)系統(tǒng)、工資系統(tǒng)等需要文件級(file)的集中存儲與共享時，則有更專業(yè)的需求：一是充分利用現(xiàn)有的網(wǎng)絡(luò)資源；二是提供強勁的存儲容量的擴展；三是多臺服務(wù)器對海量文件級的數(shù)據(jù)讀寫；四是降低存儲資源開銷及整體擁有的成本。

如何解決上述文件級（file）數(shù)據(jù)集中存儲與共享的用戶需求，NAS網(wǎng)絡(luò)共享存儲給出了漂亮的解決方案，并且順利解決企業(yè)用戶海量數(shù)據(jù)文件(file)與數(shù)據(jù)塊(Block)兩種形式并存的難題。因此，很多像互聯(lián)網(wǎng)這樣對外提供服務(wù)的多集群前端互聯(lián)網(wǎng)業(yè)務(wù)平臺，以及公檢法擁有海量卷宗文件的用戶，會欣然接受NAS存儲架構(gòu)作為文件的存儲形式。

比如用戶有基于互聯(lián)網(wǎng)業(yè)務(wù)的平臺，用戶的基數(shù)非常大，因此前端就要做負載均衡和多集群業(yè)務(wù)。在這樣背景下，如何解決海量非結(jié)構(gòu)化數(shù)據(jù)在多臺節(jié)點中保持數(shù)據(jù)的一致性，困難相當大。

那么用戶大多使用的方案是多個前端業(yè)務(wù)的集群，共享同一個NAS存儲的目錄，它們擁有共同寫與讀的機制，確保不會寫沖突。這樣的讀寫機制確保了文件的唯一性，這個方案可以快捷擴展前端集群節(jié)點的數(shù)量，以增加用戶對實際的訪問量的需求。

NAS存儲架構(gòu)下的數(shù)據(jù)容災(zāi)難題

從數(shù)據(jù)安全管理角度來看，從NAS上復制文件是一件讓人頭痛的事情。如果使用NAS廠商的相關(guān)復制功能，那么就必須有一套相同的NAS系統(tǒng)復制。而現(xiàn)有的NAS系統(tǒng)只能在文件管理系統(tǒng)層次進行復制。這決定了要么就全部復制，要么就什么都不復制。但是在實際環(huán)境中，用戶更希望針對特定文件進行相應(yīng)的管理。比如，對相關(guān)的文件進行實時的備份，但是因為前端業(yè)務(wù)集群服務(wù)器主機可能會同時讀寫同一個NAS文件夾中的數(shù)據(jù)，造成無法實現(xiàn)數(shù)據(jù)的實時保護。

另外，海量小文件，例如2000萬數(shù)據(jù)量，如何確保復制數(shù)據(jù)在主備兩端的一致性？傳統(tǒng)的災(zāi)備方式，在第一次全鏡像的同時，如何確保鏡像過程中增量部分的同步？這些都是困擾整個NAS架構(gòu)下海量小文件進行數(shù)據(jù)容災(zāi)的難題。

基于NAS的定時同步方案

從下面定時同步方案的拓撲圖來看，它是在基于NAS存儲集群架構(gòu)拓撲圖上增加了一個備份節(jié)點。數(shù)據(jù)復制的流程首先是將業(yè)務(wù)端的NFS共享存儲目錄掛載至災(zāi)備機，提供只讀機制，其次，通過英方控制臺，下發(fā)定時復制的策略，通過英方將災(zāi)備機上的生產(chǎn)目錄數(shù)據(jù)復制至災(zāi)備目錄里，進行一致性比對或執(zhí)行復制規(guī)則，定時或手動執(zhí)行。

該方案的優(yōu)點是對源端的業(yè)務(wù)架構(gòu)沒有任何的改變，它只是把目錄映射到災(zāi)備服務(wù)器上，災(zāi)備服務(wù)器同時掛載一個映射的只讀目錄，另外還有一個存儲數(shù)據(jù)的災(zāi)備目錄。它要做的就是把生產(chǎn)數(shù)據(jù)產(chǎn)生變化的目錄的數(shù)據(jù)進行定時的比對，并且將缺少的文件同步到備端的存儲上去。

由于該方案需要定時做掃描的差異對比，因此數(shù)據(jù)同步需要時間，所以無法做到實時的數(shù)據(jù)同步，只能做到定時的數(shù)據(jù)同步。那么隨著NAS存儲數(shù)據(jù)的大量增加，可能僅就掃描和差異對比，就耗費大量時間。目前這種解決方案，主要是針對用戶數(shù)據(jù)量不是特別大的NAS目錄，例如數(shù)據(jù)文件的數(shù)量在百萬級別，并且用戶讀寫不是很頻繁，可以把定時的時間縮短即可實現(xiàn)。

基于NAS的實時同步方案

在實時同步方案中，數(shù)據(jù)復制的流程首先是在3臺前端業(yè)務(wù)服務(wù)器上面都安裝英方軟件客戶端；其次是單獨使用1臺服務(wù)器只讀該NAS存儲中對應(yīng)文件夾，命名“英方NAS監(jiān)控服務(wù)器”；最后是當這3臺服務(wù)器有任何1臺服務(wù)器對NAS數(shù)據(jù)進行修改時，英方客戶端會將修改的文件名和該文件的存儲路徑發(fā)送給“英方NAS監(jiān)控服務(wù)器”，由該服務(wù)器實時讀取數(shù)據(jù)，并發(fā)送給容災(zāi)端。

英方i2COOPY實時復制在一般服務(wù)器下能夠做到毫秒級數(shù)據(jù)同步，在NAS服務(wù)器集群環(huán)境下，i2COOPY通過在生產(chǎn)端指定一個服務(wù)器作為其他服務(wù)器IO變化的合并節(jié)點，能夠在備端的服務(wù)器達到秒級同步讀寫的目的。

該解決方案是旁路監(jiān)聽，因此對主業(yè)務(wù)的節(jié)點變化是安裝客戶端，但是客戶端本身不產(chǎn)生性能開銷，只是監(jiān)控對應(yīng)服務(wù)器會對目錄當中的某個文件進行修改。比如集群中有三臺服務(wù)器，第一臺修改完了，會傳輸?shù)接⒎絅AS監(jiān)控服務(wù)器上，然后會優(yōu)先進行傳輸，當?shù)诙_修改完后，就會進入文件隊列傳輸?shù)牡却^程，依次類推……英方監(jiān)控服務(wù)器得到更改確定的指令后，會第一時間去讀對應(yīng)目錄下的名稱，然后經(jīng)過TCP/IP網(wǎng)絡(luò)發(fā)送到容災(zāi)端的服務(wù)器。

該方案既解決了實時同步的問題，又解決了海量數(shù)據(jù)情況下數(shù)據(jù)復制時間窗口的問題，確保當生產(chǎn)環(huán)境NAS存儲出現(xiàn)故障時，數(shù)據(jù)安全，業(yè)務(wù)連續(xù)。

實時同步方案的六大優(yōu)勢

這兩個方案均能滿足不同用戶NAS存儲數(shù)據(jù)容災(zāi)的需求，具體的方案選擇要根據(jù)用戶的生產(chǎn)環(huán)境與數(shù)據(jù)量進行綜合分析判斷。不過，在NAS存儲架構(gòu)下的海量文件的數(shù)據(jù)容災(zāi)，英方股份高級售前技術(shù)顧問李毅總結(jié)了六大優(yōu)勢：

1)、無備份窗口，可實現(xiàn)實時的數(shù)據(jù)傳輸；

2)、對用戶現(xiàn)有的業(yè)務(wù)架構(gòu)無調(diào)整，只增加同步主機、災(zāi)備主機，同時在客戶的業(yè)務(wù)環(huán)境上安裝客戶端，如果使用存儲級的復制，需要對存儲本身進行調(diào)整；

3)、對用戶的資源系統(tǒng)沒有多余的開銷，因為去同步主機才會產(chǎn)生數(shù)據(jù)的讀取，對源端的業(yè)務(wù)沒有壓力，對I/O的消耗比較?。?/p>

4)、備端數(shù)據(jù)可見，因為主備端的數(shù)據(jù)與文件目錄同樣，可隨時查看數(shù)據(jù)的一致性；

5)、當用戶需要容災(zāi)演練，查看備端海量的數(shù)據(jù)的啟動時間非常短；

6)、彌補現(xiàn)有解決方案中無法針對使用NAS作為存儲冗余架構(gòu)的不足，英方提供全場景解決方案，能夠滿足用戶同時做實時數(shù)據(jù)復制備份、非結(jié)構(gòu)數(shù)據(jù)同步、高可用等容災(zāi)備份的綜合需求，而之前很多對NAS存儲數(shù)據(jù)做復制都是定時的。

實戰(zhàn)：海量文件的數(shù)據(jù)容災(zāi)落地方案

1、某金融用戶前端業(yè)務(wù)集群案例

某金融用戶異地容災(zāi)拓撲圖

該用戶擁有大量的互聯(lián)網(wǎng)業(yè)務(wù)平臺，用戶希望實現(xiàn)本地到同城災(zāi)備機房的實時數(shù)據(jù)復制。

實際上用戶的業(yè)務(wù)運行在本地的IDC機房，在本地建有容災(zāi)的機房，中間通過千兆網(wǎng)絡(luò)進行數(shù)據(jù)的傳輸。用戶平時就有很多的數(shù)據(jù)要進行復制備份，同時也要實現(xiàn)NAS存儲架構(gòu)下的數(shù)據(jù)復制，據(jù)統(tǒng)計，用戶在NAS存儲下的數(shù)據(jù)量是1.6T，海量文件的數(shù)量在2000萬左右。在生產(chǎn)業(yè)務(wù)方面，用戶實際的運行業(yè)務(wù)一共有10個，有8個業(yè)務(wù)因為數(shù)據(jù)量沒有達到千萬級別，所以英方通過定時同步的方案，實現(xiàn)增量數(shù)據(jù)的比對；另外核心業(yè)務(wù)是2個互聯(lián)網(wǎng)業(yè)務(wù)的集群，集群服務(wù)器一共有7臺，共享同一個目錄，寫入數(shù)據(jù)非常頻率，每天大約以20萬的數(shù)據(jù)在增加。

在這樣的生產(chǎn)環(huán)境下，用戶通過英方實時同步的方案，非常好地實現(xiàn)了基于NAS下的廣域網(wǎng)的數(shù)據(jù)的快速復制。經(jīng)過現(xiàn)場的實時測算，用戶的延遲大部分時間是在5秒以下，這其中要考慮用戶的業(yè)務(wù)量非常頻繁，另外用戶的部分業(yè)務(wù)數(shù)據(jù)放在本地，所以千兆網(wǎng)絡(luò)不僅要進行異地的數(shù)據(jù)傳輸，還要支持本地業(yè)務(wù)的運行，整個網(wǎng)絡(luò)的日常生產(chǎn)占用率非常高，能達到秒級同步在業(yè)內(nèi)已經(jīng)無人能敵。

2、某廳級檢察院海量小文件案例

該檢察院用戶是典型的卷宗類海量小文件容災(zāi)場景，用戶小文件數(shù)量在8000萬左右，數(shù)據(jù)量約7T，前端業(yè)務(wù)集群共有7臺服務(wù)器，共享同一個目錄，進行電子化檔案的存儲。用戶不會對數(shù)據(jù)進行修改和刪除，但是數(shù)據(jù)量會持續(xù)地增加，另外數(shù)據(jù)是電子性的檔案，每份檔案都是非常關(guān)鍵，不能出現(xiàn)任何的丟失。

該檢察院用戶已經(jīng)在本地進行容災(zāi)保護，希望通過英方的方案實現(xiàn)異地的容災(zāi)級別的保護。用戶生產(chǎn)中心與災(zāi)備中心相隔幾百公里，通過專線連接，巨大的數(shù)據(jù)量使得用戶第一次的數(shù)據(jù)同步就花費了一個星期。同時通過英方基于NAS的實時同步方案，在每臺服務(wù)器上安裝客戶端，監(jiān)控服務(wù)器會觀察生產(chǎn)端不斷發(fā)生的數(shù)據(jù)變化，將截獲到的數(shù)據(jù)變化同步到災(zāi)備服務(wù)器中。

這些擁有海量小文件的用戶，要實現(xiàn)基于NAS存儲架構(gòu)下的異地定時或?qū)崟r同步數(shù)據(jù)容災(zāi)，目前業(yè)內(nèi)的解決方案鳳毛麟角。英方在備端同步在時間上達到秒級別的容災(zāi)要求，已經(jīng)成功應(yīng)用于公檢法、互聯(lián)網(wǎng)多集群前端業(yè)務(wù)平臺、電信運營商等領(lǐng)域，并且英方能夠提供全場景的容災(zāi)需求，擁有很多典型的定制化的容災(zāi)備份的解決方案。