1.概述
隨著信息化水平的不斷提高，信息數據的重要性在當今社會日益凸顯。由于信息系統面臨自然災害、硬件失效、戰(zhàn)爭等諸多災難性的風險和威脅，信息系統的可用性和容災能力等問題日益成為人們關注的焦點。平衡數據的可用性、存取的性能以及構建和維護系統的成本是設計容災系統必須考慮的問題。與此同時，數據快照(Snapshot)、持續(xù)數據保護(Continuous Data Protection， CDP)、遠程鏡像等相關技術也得到了廣泛的使用并形成了許多成熟的容災產品或相關開源軟件。但現有的容災系統存在如下缺點：
(1)當對數據量巨大的本地端進行容災保護時，許多容災系統需要將原始數據遷移至容災系統中，從而造成業(yè)務的長時間停滯，因此，容災系統不能保證在不改變本地端存儲架構的前提下對本地端容災保護。雖然利用軟件RAID的鏡像功能與存儲區(qū)域網絡(Storage Area Network, SAN)結合可以構建遠程鏡像系統進行容災，并能將數據動態(tài)地同步到異地容災端，而不會造成業(yè)務的長時間的停滯，但軟件RAID 在對本地端加鏡像保護時會將其超級塊信息寫入本地端存儲設備的末端，從而可能覆蓋本地端存儲設備中的有用數據。類似的還有分布式復制塊設備(Distributed Replicated Block Device, DRBD)，它同樣可以進行動態(tài)構建，但是也會將其超級塊信息寫入到本地端存儲設備。
(2)有的容災系統依賴于特定硬件設備或驅動。例如：EMC 公司的SRDF 必須構建于本公司的Symmetrix 網絡存儲系統之上；SnapMirror依賴于NetAPP 公司的存儲設備以及嵌入在設備底層的WAFL 文件系統。另外，還有許多容災系統要求異地容災端的存儲設備必須和本地端的存儲設備型號一致，因為不同廠家的磁盤陣列產品無法直接做數據同步。
本文運用動態(tài)鏡像加載技術和基于吸拉式日志的異步數據傳輸方法，設計一種基于存儲虛擬化的動態(tài)容災系統。
2.體系結構
2.1 總體架構
動態(tài)容災系統由一系列用戶態(tài)程序和內核驅動組成，包括本地端的管理模塊、通信模塊、鏡像模塊以及塊日志處理模塊，異地端的管理模塊、通信模塊、塊日志解析模塊。體系結構如圖1 所示。
圖1 動態(tài)容災系統的體系結構
2.2 存儲設備
由于Linux 操作系統下各種塊設備驅動都會向用戶層提供通用塊設備接口，這一機制保證了動態(tài)容災系統的通用性和靈活性。存儲池表示數據存儲容器，是各種異構存儲設備的統稱，如硬盤、盤陣、網絡虛擬盤，邏輯卷等。本地存儲池是本地服務器端原始數據的存儲載體，異地存儲池是異地容災端數據的存儲載體，本地存儲池與異地存儲池可以為不同類型的存儲設備。
鏡像/日志存儲池部署于本地，是用于存儲鏡像同步數據以及日志數據的塊設備。它基于存儲虛擬化技術，具體類型(硬盤、邏輯卷或其他塊設備)可以由用戶指定，通過存儲區(qū)域網絡映射到異地端，對本地端跟異地端而言，它是公共的存儲空間，其中可以使用各種協議，如FC、iSCSI等。由于通常情況下對于較遠距離的異地容災而言，網絡數據的傳輸速度遠不及本地的存儲設備，因此在容災系統中鏡像/日志存儲池可以起到很好的緩沖作用。鏡像/日志存儲池具體空間布局如圖2 所示。
圖2 鏡像/日志存儲池空間布局
它的設計借鑒了快照的基本思想，空間分為2 個部分，第1 部分空間為原始數據區(qū)(代號為A)，它與本地存儲池空間大小相等，用于同步模式下保持與本地存儲池完全一致的數據副本，以及開啟異步模式時保存本地存儲池數據的快照；第2 部分空間為日志數據區(qū)(代號為B)起緩沖作用，用于以日志形式記錄開啟異步模式時上層傳下來的寫操作請求拷貝，也就相當于開啟異步模式時生成了快照，B 部分為生成快照后的增量數據日志。
2.3 應用程序部分
管理模塊和通信模塊都為應用程序。本地端的管理模塊負責與內核模塊以及通信模塊的交互，比如管理設備，監(jiān)控并報告設備狀態(tài)等，而本地端的通信模塊負責與異地端的通信模塊的通信，并向異地端的通信模塊傳遞控制信息，接收并向本地端管理模塊報告從異地端傳來的相關反饋信息。
異地端的通信模塊負責檢查網絡是否通暢以及監(jiān)聽來自本地端通信模塊的控制信息、狀態(tài)信息以及日志表頭信息并將接收到的信息傳遞給異地端的管理模塊。異地端管理模塊負責與異地端的塊日志解析模塊的交互，功能包括設備管理，監(jiān)控并報告設備狀態(tài)，向通信模塊反饋相關信息，獲取日志表頭信息傳予日志解析模塊。通過本地端與異地端的交互同時判斷本地端的服務器是否異常，當本地端服務器失效時，系統能在較短時間內將服務從本地端切換至異地端，并在異地端啟動與本地端相同的用戶進程，保證服務的不間斷。
2.4 內核驅動部分
鏡像模塊是容災系統本地端內核驅動的一部分，負責向子設備接收并轉發(fā)從上層傳來的讀寫請求。在同步模式下，鏡像模塊將本地存儲池數據同步到鏡像/日志存儲池，維持本地存儲池和鏡像/日志存儲池A 部分的數據的完全一致性。在異步模式下，鏡像模塊收到上層應用程序傳來的寫請求時，將數據寫入本地存儲池的同時通過塊日志處理模塊將數據以日志形式寫入鏡像/日志存儲池的B 部分。在僅存在本地存儲池故障的情況下，鏡像模塊還能向上層管理模塊反饋相關信息，并且結合塊日志處理模塊分析鏡像/日志存儲池的AB 兩部分來處理上層讀寫請求，從而保證整個系統的正常工作，而無需將服務遷移到異地端。
塊日志處理模塊是容災系統本地端內核驅動的另一部分，負責與鏡像模塊交互。在異步模式下，塊日志處理模塊接收從鏡像模塊傳來的寫請求，然后將每個寫請求轉為日志，以一定的格式寫于鏡像/日志存儲池的B 部分。塊日志處理模塊還配合鏡像模塊向上層提供鏡像服務，如果遇到僅本地存儲池故障的情況，塊日志處理模塊通過日志的記錄和解析處理上層讀寫請求，而不影響服務的持續(xù)性。
鏡像/日志存儲池通過存儲區(qū)域網絡技術映射到異地端，塊日志解析模塊通過讀取并解析鏡像/日志存儲池的映射盤上的數據，并將解析結果發(fā)送給異地存儲池。塊日志的處理是在異步模式下進行的，首先塊日志解析模塊會將鏡像/日志存儲池的A 部分的數據之間拷貝到異地存儲池，然后再解析鏡像/日志存儲池B 部分的塊日志，由日志還原出寫操作并將其發(fā)送到異地存儲池，從而保證數據的嚴格一致性。
3.關鍵技術
本節(jié)將詳細介紹動態(tài)容災系統涉及的2 種關鍵技術，即動態(tài)鏡像加載技術和吸拉式日志技術的具體實現。
3.1 動態(tài)鏡像加載技術
動態(tài)容災系統的突出特點是能夠在本地服務器短暫停服務時進行動態(tài)加載容災保護，而且不改變本地服務原有的存儲架構。要達到這一目的，必須保證數據拷貝和上層來的數據寫請求處理可以同時進行，這就用到了動態(tài)鏡像加載技術。動態(tài)鏡像加載技術是將包含構建容災系統的本地子設備信息的超級塊以文件形式保存于系統盤上，在虛擬塊設備中的鏡像模塊中使用內核多線程來對數據進行處理。以文件形式保存超級塊就不會破壞本地存儲池上的數據。鏡像子模塊的體系結構如圖3 所示。
圖3 鏡像模塊的體系結構
當對本地端加載容災保護時，只需要短暫停服務，期間將鏡像模塊插入，然后就可以啟動本地端原來的服務，此時鏡像模塊就會開始工作，進行同步。同步過程對上層應用而言是透明的。
在同步過程中用到了帶狀態(tài)的位圖機制來記錄數據的非一致性塊。由圖3 可以看出，上層寫請求到來時需要將寫請求拷貝后分發(fā)至2 個子設備，進行同步以及處理上層來寫請求都可以使數據一致化，一旦數據一致，就對位圖進行相應的處理。在內核態(tài)下需要創(chuàng)建2 個線程，一個為同步線程，另一個為管理線程。同步線程負責從本地存儲池讀取數據，將其轉換為寫請求后添加到同步請求鏈表交予管理線程處理。管理線程一方面處理同步請求的提交另一方面處理上層寫請求的提交，并管理位圖。同步過程中有寫請求到來時，大致處理步驟如下：
(1)同步線程從本地存儲池讀取一個數據塊，創(chuàng)建同步寫請求，獲取同步請求鏈表的互斥鎖，將該寫請求添加到同步請求鏈表，釋放互斥鎖。
(2)當上層寫請求到來時，考慮到可能出現對一個子設備寫請求提交完成了而另一個寫請求提交未完成造成不一致的情況，所以需要先將位圖對應的位進行非一致性化處理(這里置為狀態(tài)A)，然后將該寫請求復制并設置成發(fā)往2個子設備的寫請求，獲取寫請求處理鏈表的互斥鎖，將2個寫請求添加到寫請求處理鏈表，釋放互斥鎖。
(3)在管理線程中，將寫請求處理鏈表中的請求提交，查看位圖狀態(tài)，如果位圖一致或為狀態(tài)A，同步請求鏈表中對應的寫請求丟棄，然后將同步請求鏈表中剩余的寫請求提交。每種類型的寫請求提交完成后都對位圖進行相應的一致性化處理。
3.2 吸拉式日志技術
在常規(guī)的異步數據復制中，用的是推送式的數據傳輸方法，這就面臨著許多問題，而這些問題會令系統實現困難并且效率低。其中一個就是本地端內存中數據積壓問題，另一個常見的則是數據一致性問題。用位圖技術以及寫合并技術可以解決本地端數據積壓的問題，但破壞了數據的時序一致性。用一致性組的方法可以保證組內的一致性，但是需要快照技術作為輔助。
然而，網絡吸拉式日志方法可以很好地解決這些問題。由于通常情況下對于較遠距離的異地容災系統而言，網絡數據的傳輸速率并不及硬盤的1/10，因此本地硬盤在異地容災系統中可以作為很好的緩沖設備。
在本地端啟動異步模式后，發(fā)向鏡像/日志存儲池的寫請求以日志的方式寫入其部分B，而與此同時，異地端的日志解析模塊先將鏡像/日志存儲池部分A 的數據(相當于同步模式轉異步模式時生成了快照)直接拷貝至異地存儲池，然后讀取部分B 的日志，并進行解析，得出數據后再寫入異地存儲池。由于本地端負責寫入，異地端負責讀取，這就會出現競爭問題。
日志在鏡像/日志存儲池的B 部分中以雙鏈表的方式進行組織管理。一個鏈表作為讀鏈表，由異地端負責讀取，一個鏈表作為寫鏈表，接收本地端的寫請求日志，當異地端將讀鏈表讀完后，釋放空間，寫鏈表變化角色為讀鏈表，新建的寫鏈表繼續(xù)接收上層傳來的寫請求。鎖由本地端集中管理，通過異地端與本地端的交互是對鏈表頭進行簡單的加鎖/解鎖操作，即解決了競爭問題。
這樣通過日志就將對本地存儲池的數據寫入過程完整地還原到異地存儲池上，保證了數據的嚴格時序一致性。由于鏡像/日志存儲池實際上是本地存儲設備，它與本地存儲池數據的寫入是并行的，因此，并未對原系統性能產生較大影響。
4.性能測試與分析
4.1 測試環(huán)境
本節(jié)介紹系統測試的硬件和軟件環(huán)境，由于本文系統基于軟件實現，不依賴于底層硬件和設備，故測試過程中本地端跟異地容災端選取了不同的硬件環(huán)境。本地端采用的是戴爾T110 工作站，具體配置為：Intel Xeon X3430 四核CPU，4 GB DDR2 667 內存，原始數據盤為160 GB SATA硬盤，日志數據盤為250 GB SATA 硬盤。異地容災端采用的是戴爾Inspiron 530 微型機，具體配置為：Intel Core E4400雙核CPU，2 GB DDR2 667 內存，備份數據盤為160 GB SATA 硬盤。本地端跟異地容災端的操作系統都是采用Linux，內核版本為2.6.18。
4.2 測試結果與分析
本文使用廣泛使用的iozone 測試工具來對本地端不同情況下硬盤讀寫效率進行測試。分別測試了本地存儲池(sdb)、鏡像/日志存儲池(sdc)、同步過程中、同步完成后以及異步狀態(tài)下的隨機讀性能和隨機寫性能。為消除隨機性帶來的誤差，每項測試進行10 次并取平均值。隨機讀性能結果如圖4 所示。
圖4 隨機讀性能
可以看出，無論是在構建容災系統的同步過程中、同步完成后還是在異步模式下，容災系統虛擬塊設備的讀性能都與本地盤的讀性能相差不大，這是因為上層應用程序發(fā)來的讀請求都是直接發(fā)往本地盤，而在同步過程中，本地盤不僅要處理上層應用程序的讀請求還需要處理同步讀請求，所以，其在同步過程中的讀性能相比其他情況下的讀性能要低。
隨機寫性能如圖5 所示。
圖5 隨機寫性能
可以看出，在同步過程中、同步完成后以及在異步模式下，容災系統的虛擬塊設備的隨機寫性能與本地盤相比有所下降，但帶來的寫性能開銷并沒有超過20%。因為在這些情況下，容災系統虛擬塊設備需要將上層傳來的寫請求進行復制，并分發(fā)至本地盤和鏡像/日志盤，當2個盤的寫請求處理完成后，針對上層的寫請求才返回。而在同步過程中，本地盤不僅要處理上層應用程序的寫請求還需要處理同步寫請求，所以，其在同步過程中的寫性能相比其他情況下的寫性能要低。
經過以上比較和分析可以得出以下結論：在同步模式下，本文系統對原系統的性能影響不超過10%；在異步模式下，對原系統的性能影響不超過20%。由此可見，該系統在成功提供對本地數據保護的同時，僅對原系統帶來較小的讀寫性能缺失。
5.結束語
本文基于存儲虛擬化技術，以軟件方式實現一種動態(tài)容災系統，保證了數據一致性和服務的高可用性。實驗結果證明，該系統動態(tài)加載后對原系統帶來較小的性能缺失。此外，下一步針對該系統還可做如下改進：通過本地端對日志數據進行壓縮存放，遠程端讀取后解壓縮可以減小網絡負載，降低災難發(fā)生時數據丟失；通過本地端對日志進行加密，遠程端讀取后解密可以提供系統安全性。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.oesoe.com/
相關文章
