基于公有云TB級文件保護系統

　　企業業務稍微上點規模的，IT系統產生的數據很容易就超過TB級，并且資料文檔等很容易超過億級別的規模，如果用手動復制的方案來備份，基本是非常困難的;這種情況下，即使購買一些專業系統，隨著數據量日益增大，跑起來也非常吃力。本文重點討論如何基于云平臺，來實現對應的解決方案。

　　TB級海量文件場景特點

　　文件規模大，動作上規模

　　文件目錄結構多，層次多

　　文件大小從KB 到MB，GB，甚至百GB級別分布

　　文件變化快，或者有批量增加的場景

　　無用的，有用的，混在一起

　　時間分布久，跨度大

　　文件類型文本，視頻，圖片，壓縮等都有

　　單個節點的數據量上TB級

　　總量上TB級，但分布在多個節點

　　面對如此特點，如果按照目前的設備+軟件方案，在以下幾點有非常大的缺陷：

　　1.升級擴展復雜，預先估計容量，后續擴展起來相當麻煩，必須的改變存儲策略，或重新離線做數據遷移分布。如果初始購買的存儲擴展有限，后期還不能很好的升級擴展。

　　2.3-5年左右的生命周期，也就是說，數據經過幾年后，改造升級，購買新的方案是必須的，這樣當數據上到百TB級別，整個工程實施也是相當復雜了。

　　3. 一次投入特別的貴，如果對原始TB級數據做專業備份保護，投入得數十萬，具體到不同的行業，性能和保護窗口參數稍微提升，投入立即上升到。

　　隨著數據量的增長，超過一個量級，比如10TB級別，其實這類方案已經難于勝任了。

　　破解思路

　　基本上來說，要破解海量數量，以及TB級增長的難題，基于云的方案是目前zui有前途的思路，云有4個核心好處：

　　1.存儲和計算能力按需擴展

　　2.可靠，云的計算和存儲分布特點，使得系統在計算和存儲都具備傳統結構不具備的數倍的可靠性

　　3.安全，基礎云服務商自身在安全方面不計成本，比起自己構建IT設施，來得更加專業

　　4.擴展，開放性更好，使得構建的服務，更容易外部系統對接

　　目前在國內以及其他地區，都有成熟的云平臺可以作為構建基礎。當然，除了明顯的優點外，也有1個缺點是，云畢竟在異地，速度方面沒有本地來得快，所以在設計系統的時候，要充分考慮到此處特點。以此為基礎，考慮構思如下備份系統的設計目標：

　　zui高性價比的TB級海量小文件備份服務

　　支持分布式，多節點集中管理監控

　　備份容易且快速恢復

　　結合云平臺的優缺點，基本的設計思路大體如下：

　　規模上量：單點TB突破，分布式上量

　　zui小空間占用：zui大化變小數據

　　平衡性能開銷：IO掃描和效益平衡

　　不做無用功：特征類型自適應處理

　　zui近zui快，zui遠zui可靠：多級模式結合，平衡速度和可靠性

　　以下將圍繞以上5個點展開，看一個專業級別的備份保護系統如何打造。

　　TB級突破

　　實現TB級突破，重點思路在于如何解決備份和恢復的速度，以及海量規模的數據塊存儲。而解決數據備份和恢復速度的關鍵在于組織好數據索引;我們日常看到的網盤備份是簡單的同步模型，很難勝任連續的數據塊版本影射關系。而一個專業的備份系統，此處是必須要解決好。

　　架構上要突破純云的方案，本地和云結合

　　純云的方案，用了云的幾個優勢點，但也同時受云天生異地的特點影響，在傳輸效率方面是必定落后本地的方案，在強調速度的備份和恢復場景下，只有壓縮數據，加大帶寬。因此，更好的專業級方案是兼顧云和本地的優勢進行設計。

　　以下黃色部分，就是加的一層本地存儲;本地客戶端將以分塊的形式把數據寫入本地客戶端，同時啟動同步邏輯，把數據從本地同步到云存儲。

　　TB級數據重點在索引管理上要下功夫，索引分為本地和云端兩級

　　本地索引采用分段分布設計，突破傳統RDB單庫數量過大，查詢過慢的瓶頸。本地索引模型讀寫相對簡單，可以采用自己研發或開源的本地數據存儲方案，Sparkey, levelDB，BDB，甚至MongoDB等都可以，實現索引庫理論支持TB級以上的的索引大小，具體到文件為每條索引可做到100字節以內

　　索引容量： TB/0.1KB > 100億條索引

　　按照簡單的順序存取模型，海量的目錄，文件索引，這種分級模型的索引框架，可以輕松解決TB級數據與海量小文件場景的管理。

　　當然，如果離開了異地配合，這種方案還是不完整的。因此在云上，要支持更大規模的索引容器。幸運的是，在云上，我們可以選擇的方案還比較多。可以基于MongoDB，LevelDB等的列模型數據庫，也可以基于云平臺本身的分布式KV數據庫來保存索引。

　　設備通過調度中心定位到云索引中心 ; 單個云索引中心采用NO-SQL DB分布式設計，具體按照任務ID進行分布。關于具體的索引容器，可以選擇云平臺提供的KV數據庫，如果要更多靈活的控制，也可以自己選用專業的KV 數據庫來構建。理論上云端可以管理索引的數量無限。

　　數據按系列段分塊存儲，提升混合云模型的速度參數

　　普通的量級數據讀寫，無所謂要不要分塊了，但一旦規模上到TB級別，特別在文件量變化快的場景，要盡可能縮短備份窗口，必要的數據存儲組織就顯得非常的關鍵。其數據存儲分為兩部分，本地和云。

　　本地數據存儲設計，可采用N *KB – N *MB 相對固定系列段的分塊設計，兼顧讀寫效率與空間平衡分塊采用期望分塊方案，盡可能讓分塊分布在1個區間，保證去重效果的同時，減低分塊對索引記錄數占用的數量。本文按照64KB 到 4MB的經驗值方案來計算.

　　總可索引數據量區間：理論zui小管理數據 100億* 64KB = 600+TB ， 理論zui大管理數據 100億* 4MB = 40+ PB 這么大的規模，理論上已經遠遠滿足數據存儲管理需要。

　　對于數據上云，初始化系統這里可以把設備定位到不同的云數據中心，與索引位于同1個中心內;上傳的數據異步化存儲到云存儲，或可同時異步到特定的塊存儲設備;對于塊存儲，提供合并機制，將小塊進行合并存儲，提高存儲讀寫效率。所以，理論上云端冗余管理的數據量受限于云存儲空間提供商的。

　　本地和云的數據存儲組織方案，在本地通過相對分塊序列的方案，在云采用云存儲的方案，從KB-MB級的小數據塊文件都可以輕松管理起來。

　　上圖是基于索引和塊存儲結合的增量應用。任何一個數據塊的變化都會*時間，通過本地的索引塊簽名快速判斷是否需要上傳備份 ; 如果本地的索引無法啟動，將從云端獲取簽名進行比對。任何一個需要備份的數據塊，可以快速通過分塊序列存儲方案，保存在對應的數據塊文件中。

　　通過并行冗余通道，提升上下云的速度、穩定和可靠性

　　互聯網絡本身是一個質量無法端到端保證的的一個網絡，傳輸的穩定性會又多個環節影響。包括運營商網絡，平臺的網絡，以及用戶接入的網絡等。對于一個專業級的備份系統，必須要考慮網絡通道的連續、穩定運行。

　　以上，在任何一次客戶端注冊期間，一旦認證通過后，可以根據系統資源情況，分配合適的數據節點給客戶端。 客戶端可以根據情況，正常情況下，多通道并行傳送 ; 一旦檢測到通道出現問題，自動摘除 ;各個節點會上報數據到調度中心; 同時當鏈路恢復的時候，自動接入到系統中。下圖就是示意多通道在同步到云，以及從云恢復或下載數據。

　　采用端到端加密數據塊設計，結合數據塊垮云分布機制，可靠保存備份到本地和云的數據

　　在備份體系中，數據保密性設計不依賴于人，從機制上保證數據備份到云是機密的。zui常用的一種方案就是采用對稱加密，具體可以采用AES，3DES 等算法。目前比較常用AES256位，而key的產生可以在客戶端產生。Key一旦丟失，數據將無法恢復和使用。因此key的妥善保護，也是非常重要。

　　在基于塊的加密設計中，結合云分布特征，數據被打散在不同的存儲位置，因此在數據安全方面進一步增加了強度。基于目前的公有云平臺的情況，在國內和國外都有幾大主流的云存儲平臺，分布在。理論上，數據可以分步在任何一個地方。*考慮的是數據如何跨地區進行同步和分布; 當然這里可以先寫入本地云中心，冗余塊通過高速通道，再同步其他云中心，這里可以是同構的云，也可以是異構的云。

　　引入自動適應方案，提升海量文件和應用場景的適應能力

　　在海量文件情況下，由幾種系統因素影響備份的效率和資源開銷。備份系統如果全速開進，會消耗過多的計算和IO資源，如果是生產系統，勢必也會帶來沖突。以下是幾種典型的需要規避的：

　　壓縮比例和CPU消耗的沖突

　　磁盤IO和小文件隨機分布的沖突

　　強加密和CPU需求的沖突

　　實時檢測和系統資源的沖突

　　文件類型和壓縮效果的沖突

　　備份帶寬消耗

　　通過對帶寬，壓縮算法，文件類型定義等預定義策略，可以快速平衡好系統資源。這種適合在確定判斷系統場景的情況啟用。

　　對于無法預知的情況，啟動自動監測機制，包括壓縮比，是否硬件加密加速，是否需要啟動實時或批量掃描等。