收稿日期:2007-12-18;修回日期:2008-03-14
基金項目:國家自然科學基金資助項目(60573096)
作者簡介: 趙曉南(1979-),女,遼寧清原人(滿族),博士研究生,主要研究方向為海量數據存儲、數據管理(zhaoxn@nwpu.edu.cn);李戰懷(1961-),男,陜西旬邑人,教授,博士,主要研究方向為數據庫、數據挖掘、網絡存儲;曾雷杰(1978-),男,河南平頂山人,博士研究生,主要研究方向為海量數據存儲、數據管理.*
(西北工業大學 計算機學院,西安 710072)
摘 要:提出了一種保證多volume數據一致性的遠程復制機制。其借鑒數據庫系統中事務處理的基本思想,將多個volume中相關聯的更新作為一個原子事件向遠程端復制,分析實現中如數據打包、故障恢復策略、I/O合并等關鍵問題,并給出了具體的實現方法。該遠程復制機制解決了在基于存儲層或基于邏輯卷方式下的大規模數據復制應用中,保證一組具有相關性數據在復制中的一致性和可用性問題。
關鍵詞:原子;一致性;遠程復制
中圖分類號:TP309
文獻標志碼:A
文章編號:1001-3695(2008)10-2951-05
Remote replication mechanism with multi-volume data consistency guarantee
ZHAO Xiao-nan, LI Zhan-huai, ZENG Lei-jie
(School of Computer Science, Northwestern Polytechnical University, Xi’an 710072, China)
Abstract:This paper proposed a remote replication mechanism which could guarantee the consistency of data in multi-volume by leveraging the regulations of transaction processing in the database management system. The system could take several correlated updates in multiple volumes at the primary site as an atomic event, and replicated it to the secondary site. In addition, the paper analyzed the key techniques in this mechanism, such as data packing, policy of fault recovery, I/O merging, and discussed the implementation. With this mechanism, the consistency and availability of data could be guaranteed in a group of volumes which had relevancy and the relevancy had to be maintained during the replication operation. This mechanism can be used to solve the mass data replication problem in a storage system at the block level (includingphysical and logical level).
Key words:atomic; consistency; remote replication
0 引言
隨著各行各業數字化進程的推進,數據的重要性也隨之凸顯。早在2001年有調查顯示,商業數據失效的平均代價為25萬美元/h,其中有8%更達到100萬美元/h,數據丟失的代價甚至更高[1]。因此,有關數據存儲、數據的可用性和安全性的研究也更加活躍。保證數據真實可信、不被惡意竄改,確保數據的私密性等是存儲安全的研究內容,即存儲安全性在于解決人為因素對數據造成的邏輯上的破壞問題。物理上保證數據真正可用,如抵御受地震、洪水、臺風等自然災害或是恐怖襲擊以及存儲設備自身的故障等因素對存儲數據造成的影響,則是數據可用性要研究的問題。為盡量減少、消除這種情況下的數據損失,目前的存儲系統采用了一系列的數據保護和恢復技術,如 RAID磁盤陣列、遠程鏡像、磁帶備份、硬盤備份以及快照技術等。
數據量的膨脹使存儲介質從最初的硬盤發展到磁盤陣列,進而形成了網絡——SAN(storage area network)。“911”事件使人們認識到僅僅簡單保存數據的幾個拷貝還遠遠不夠,需要將數據復制到離業務更遠的地點(即遠程數據復制),才能保證數據更高的可用性。持續遠程復制(continuous remote copy)功能可以確保本地端的更新能夠全部復制到遠程端,是存儲系統實現災難恢復的主要途徑之一。其中,EMC的 symmetrix remote data facility (SRDF)[2]、 IBM的peer-to-peer remote copy (PPRC)[3], 和 VERITAS 的volume replicator (VVR)[4]都偏重于協議方面的問題;Kimberly Keeton等人[5]主要討論在數據恢復調度問題中如何選擇最優或者次優解的一些方法;FDRM[6]則是利用僅向本地端回拷更新塊的方法來提高災難恢復的速度。然而,這些研究中都沒有考慮在本地端當多個volume中的數據內容具有相關性的情況下,如何保證在進行持續遠程復制過程中仍然保持這種相關性,使遠程端的備份數據在災難恢復后,無須驗證其數據的一致性,直接便可重新開展業務。
本文提出的保證多volume數據一致性的遠程復制機制,正是針對這一問題提出的解決方案。它依照事務處理的原則,將具有相關性的幾個volume數據更新作為一個復制事務統一復制,保證遠程端的復制數據在任何時刻都是可用的,從而保證遠程復制數據的一致性。
1背景及基本概念
目前,數據管理中心利用磁盤陣列等存儲設備構建存儲網絡進行數據存儲。數據復制/恢復機制是提高數據安全性和可用性的重要手段,是指將本地端源數據在遠程端保存一個副本,當源數據不可用時,由副本取代源數據或根據副本還原已經失效的源數據,使業務重新正常運轉的過程。遠程復制是數據管理中抗擊大規模物理災害的重要手段,主要包括面向應用的文件級復制和面向磁盤陣列/面向邏輯卷的塊級復制兩大類方法。前者更靠近上層應用,容易實現、控制簡單,但通用性差;后者則由于對應用透明,具有較強的通用性,不影響主機的正常業務,尤其在較大規模數據復制的應用需求中更有優勢。
在Oracle等大中型數據庫應用中,數據和日志、修改信息、控制信息等存儲在磁盤陣列的不同邏輯卷(volume)中,缺少其中一個volume的數據,將導致其他volume中的數據也同時失效,無法使用(圖1)。同時,如果副本不能保持數據更新順序,則造成源數據和副本數據不一致,本地端上的數據是不可恢復的。因此,在對具有相關性的多個volumes中的數據進行遠程復制時,需要將所有相關的volumes作為一個整體,在保證數據復制順序的前提下,要么不復制,要么全部復制,即具有原子性,以保證數據的一致性和完整性。
本文提出了保證多volume數據一致性數據復制機制。其基本思想是將本地端內容相關的一組volume中的各個volume(稱之為BV,basic volume)對應的更新數據以組為單位按照時間戳的先后次序進行打包,將更新數據發送并復制到對應的遠程volume(稱之為RV,replication volume),支持同步和異步兩種模式。其基本過程為:本地端將需要復制的數據由統合器作打包處理,數據量較大時要進行壓縮,經由IP網絡發送到遠程端;遠程端由數據分發器依據數據包的時間戳控制次序,逐次地向本地端各個BV所對應的RV進行更新數據的寫入。該更新過程需要具有事務處理的特性(ACID),實現具有原子性的多個volume的數據更新,即在更新過程中若組中的某對BV/RV的更新發生失敗時,則放棄當前數據包中的所有數據更新,使得登錄到組內的volume數據在進行遠程復制時保持一致。在異步模式下,需要維持一定容量的cache用于I/O合并[7],減少I/O的數目,但要保證I/O更新的次序。
在如圖2所示的原子一致組中,BV和RV之間包含復制、恢復和分離三種關系狀態。其中,復制狀態表示BV的數據向RV拷貝;恢復狀態表示RV上備份的數據向BV回拷;分離狀態表示解除復制或恢復狀態,處于分離狀態的BV/RV之間不能有數據流動,分為正常分離和強制分離兩種,強制分離用于故障恢復(恢復狀態與原子一致組機制不直接相關,故在下文中將不作深入討論)。
下面對本機制中用到的幾個關鍵用語加以說明和描述。
C1:原子一致組(atomic consistency group)。它是管理多個volume進行復制的邏輯概念,保證同一組中volume復制的順序性和各volume中數據的一致性,在發生復制故障時提供原子中斷功能。本地的各volume分別與遠程的一組volume對應形成復制關聯對,本地端的volume由統合器統一管理,遠程端對應的volume則由分散器進行協調控制。
C2:原子中斷。加入到原子一致組的某個volume的I/O由于發生故障不能進行遠程復制,使得該組中所有volume的拷貝異常停止,進而使本地端volume和遠程端volume的數據保持一致的功能稱之為原子中斷。
C3: check roint。類似于數據庫中事務處理的檢查點[8],在數據更新前,保存待更新數據塊當前的數據映像(實現方法類似snapshot,而非數據庫處理中的寫log那樣僅有少量信息),以備更新處理中回滾或是前滾操作使用。
C4:統合器。原子一致組中位于本地端的部分,負責統一組織管理BV的軟件機制。包括對更新數據打包、I/O合并、時序保證等處理。
C5:分發器。位于遠程端對應本地端的部分,對關聯的RV進行統一組織管理的軟件機制。包括解析并分發處理本地端發送來的更新數據包,向RV更新數據、返回結果等。
2 復制機制
在原子一致組遠程復制中,提供了同步和異步兩種復制模式。同步模式即應用程序將數據寫入本地volume的同時也向遠程volume寫入數據,只有遠程系統也成功完成寫操作,才繼續下一步操作。異步模式則是在應用程序的寫請求在向本地寫入數據完成后立即返回,繼續業務,后臺控制向遠程volume復制數據。
21 同步遠程復制過程
同步復制的過程如圖3所示。
a)將應用程序發來的更新數據寫入到本地端對應的BV。具體來說,在對更新的信息寫入之前先作check point,然后并行更新到對應的BV中,成功時刪除先前的check point;如果發生I/O失敗,則回退到先前的check point處。
b)將登錄到該原子一致組的各個BV上的更新數據打包發送給遠程端的分發器(distributor)中。
c)分發器將接收到的數據寫入到遠程端對應的RV中。在寫入前先對要更新的數據塊作check point,然后并行更新到對應的RV中。如果發生某個I/O更新失敗,就恢復(rollback)到先前的check point處,成功時則刪除先前保存的check point。
d) 遠程端將c)執行的結果返回給本地端。
e) 本地端將接收遠程端返回的信息,然后結合遠程端和本地端更新的結果返回給請求者,整個I/O執行完成。
在同步遠程復制的過程中,可能出現各種故障。這些故障有可恢復的也有不可恢復的,對應采取的處理措施如下:
a)若本地端因PD(physical disk)發生硬件故障變得不可訪問,導致無法更新BV,則直接返回I/O失敗,無須向遠程端復制。
b)在通過TCP/IP向遠程端發送數據時由于網絡故障等原因失敗,而本地的BV更新成功,這時仍然返回I/O成功,但由于未能及時有效地進行遠程復制,為便于管理,特為原子一致組引入一個新的關系狀態:異常停止,表示由于某種故障而導致本地端的數據無法更新到遠程端對應的volume中。在這種狀態下,本地端的業務還可以繼續執行,但需要及時告知用戶,要求其盡早解決故障。另外,為了在網絡故障恢復后能夠快速完成遠程備份,本地端要開辟一定的存儲空間來保存位圖(bitmap)信息,用于維持異常停止后的更新差分信息(其中包括本次更新失敗的內容),從而在故障恢復后能夠利用這些位圖信息,通過差分復制迅速地復制。
c)在遠程端的分發器接收到本地端發送的請求后并行更新RV過程中,由于RV存在硬件故障而導致個別RV更新失敗時,遠程端一方面向本地端返回更新失敗以及失敗的具體信息;另一方面,利用先前所保存的check point在故障解決后進行恢復,使RV恢復到更新前的狀態。本地端接收到執行結果后采用類似b)的處理方式,I/O執行成功,但原子一致組的狀態變成異常停止。
d)盡管本地端向遠程端成功發出了數據更新的請求,但在最大的規定時間內未收到遠程端所返回的結果,其原因可能是網路發生故障或者遠程端的業務過于繁忙而導致無法及時響應。這種情況下,采用類似b)的處理方式,I/O執行成功,但復制的狀態變為異常停止。
為保證本地端能夠正確處理接收到分發器端返回的復制結果——由于超時,本地端已將該請求拋棄——需要在傳輸的報文格式中包含一個RequestID字段,來標示傳輸報文所對應的請求序號,保證執行的時序。
表1中總結了在同步復制過程中,針對本地端BV和遠程端RV更新成功與否同兩端數據的一致性、原子一致組和業務執行狀態之間的對應關系。
表1 同步復制下本地、遠程端更新結果與狀態對應關系本地端BV遠程端RV數據一致性關系狀態業務狀態更新成功更新成功一致復制正常運行更新成功更新失敗不一致異常停止正常運行更新失敗—一致復制停止運行22 異步遠程復制過程
異步遠程復制與同步遠程復制主要有兩點區別:異步模式下,I/O執行結果并不等待遠程端的返回信息;本地端要維持一定容量的內存空間(一般采用NVRAM),用于本地更新的I/O合并,以減少兩端點之間的I/O數目。異步復制過程如圖4所示。
a) 將應用程序發來的更新數據寫入本地端對應的BV中。該過程依據事務處理的方式,在寫入前先作check point,然后并行更新到對應的BV中,全部更新成功時,刪除先前的check point。若其間某個BV更新失敗便回退到先前的check point處。
b) 把a)的執行結果返回給請求者。
c) 本地端需在指定的時間內將BV更新的數據進行打包發送給遠程端的分發器。這個過程中在進行I/O合并時必須保持I/O更新的時序。
d) 分發器把接收到的數據寫入遠程端的對應RV中。該過程同樣依據事務處理的方式進行:在寫入前先作check point,然后并行更新到對應的RV中,更新成功則刪除先前的check point,若其間某個更新失敗,則回退到先前的check point處。
e) 遠程端將d)的執行結果發送回本地端。
f) 本地端接收遠程端發送來的消息。若成功則刪除保存的相關信息;否則不消除相關的信息,并暫停所有volume間的復制,根據返回的結果(成功/失敗/超時等)設置原子一致組的狀態。
針對上述異步復制的執行過程,各種故障處理措施如下:
a)當由于PD故障等原因造成本地端的BV更新失敗時,直接返回I/O失敗,無須向遠程端復制。
b)在通過TCP/IP向遠程端發送數據時,若由于網路故障等原因發生失敗,則將原子一致組狀態設置為異常停止,表示由于某種故障而導致本地端各個BV的數據無法更新到遠程端對應的RV中。為了在故障恢復后能夠快速地進行差分遠程復制,實現兩點間的數據一致, 本地端也需要利用位圖來標示異常停止后的更新差分(包括本次更新失敗的差分內容)。
c)遠程端的分發器接收到本地端的請求后,若個別RV發生更新失敗,導致該原子一致組的所有更新內容無法更新到對應的RV中,則向本地端返回更新失敗的結果及失敗原因。當本地端接收到結果后,將原子一致組的狀態設為異常停止,維護更新的差分信息。
本地端向遠程端發出更新請求后,可能由于網路發生故障或者遠程端業務比較繁忙,導致在最大的規定時間內未接收到返回的結果,即發生超時。此時,將原子一致組的狀態設為異常停止。類似同步復制中的超時處理,在結果報文中設有RequestID等字段標志,以確保本地端能夠正確處理接收到由于超時而已經被拋棄的請求所對應的響應結果。
表2中總結了異步復制過程中,針對本地的BV和遠程端RV更新成功與否同兩端數據的一致性、原子一致組和業務執行狀態之間的對應關系。
表2 異步復制下本地、遠程端更新結果與狀態對應關系本地端BV遠程端RV數據一致性關系狀態業務狀態更新成功更新成功一致復制正常運行更新成功更新失敗不一致異常停止正常運行更新失敗—一致復制停止運行23 原子一致組的應用
以上兩節分別討論了原子一致組遠程復制的同步和異步算法,包括相關的故障恢復策略。在利用原子一致組實現遠程復制時,還需要提供如下接口:
a)CreateAtomicConsistencyGroup()創建原子一致組,提供順序保證和原子中斷能力。
b)AddVolumeToACG()向原子組中登錄volume,以增加原子一致組所管理的volume。
c)DelVolumeFromACG()刪除登錄到原子一致組中的vo-lume。
d)DelACG()刪除原子一致組。
e)SetACGMode()改變ACG()的拷貝模式。
f)ACGReplicate()使得原子組進入復制狀態,可設置全復制或者差分復制。
g)ACGSeparate()使得原子組的復制狀態變為正常分離狀態。
h)ACGForcedSeparate()使得原子組從復制狀態變為強制分離狀態。
如圖5所示,原子一致組需要通過軟件接口進行創建,然后根據應用的需要,向該原子一致組中加入一定數量的volu-me,即各BV;由于遠程復制的需要,能夠加入到指定原子一致組中的所有volume,必須在遠程的同一存儲設備中(如磁盤陣列等)具有對應的復制對象volume(RV);原子一致組的復制模式只有當其處于分離狀態下才能通過SetACGMode()設置;ACGReplicate()用于設置復制狀態,ACGForcedSeparate()用于發生復制故障時設置強制分離,ACGSeparate()則用于設置分離狀態;原子一致組可以由于復制中出錯主動遷移到異常停止狀態,也可以通過調用接口ACGForcedSeparate()被動變為強制分離狀態,等待調用軟件接口ACGReplicate()重新開始復制動作。
3 數據一致性和數據可用性保證的關鍵技術
原子一致性復制機制可以視為兩級事務操作,首先在本地原子一致組內部各BV的寫操作及遠程對應組內部各RV的寫操作分別作為微觀的事務處理,必須整體完成;然后分別作為一次原子一致組復制這一宏觀事務動作的組成部件,構成宏觀事務的一個步驟。在實現這種兩級事務中,下列內容的設計和實現是重要的保證。
31 更新數據打包
本地各volume中相關的更新內容,需要作為整體通過網絡傳送到遠程進行復制,因此需要進行打包。若該原子一致組中包含n個BV,則該數據包可以表示為n維向量U=(Γ1,Γ2,…,Γn)T,Γi即是組中BVi對應的需要打包的信息。每一個BV需要打包傳送的信息可構成一個五元組(T,B,O,D,L)。其中:T表示時間戳;B表示更新數據所對應的塊號;O表示更新數據起始地址在塊中的偏移量(offset);D為需要更新的差分數據;L為更新數據的長度。
當然,如何將這種數據元組向量進行分解,通過網絡傳輸到遠程端,甚至在數據量較大時依據一定的算法進行壓縮處理,在實現時有許多細節性的問題需要考慮。時間戳是其中一項重要的內容。它是本地、遠程端之間數據復制順序性的重要保證,同時也是在異步復制模式下,進行I/O合并處理以及判斷遠程端返回信息的有效性所必需的參數。顯然,本地和遠程端在傳輸數據時都需要時間戳,實現時間戳可以采用直接記錄系統時間的方法,也可以簡單地使用整數累加計數來實現。采用系統時間實現時需要考慮本地和遠程設備之間的時鐘同步問題,采用計數器形式實現時,則必須考慮計數的范圍(計數達到最大值后,回零開始計數)對判斷時序正確性的影響。這作為網絡通信的基本問題,在此不作更深入的討論。
32 遠程復制的故障恢復策略
在同步或異步復制過程中,由于各種原因發生故障后,會產生原子中斷。為了繼續完成遠程復制任務,有必要對原子復制組進行恢復處理。這種故障恢復的策略因故障原因的不同而不同。
當由于本地端的BV發生故障而導致業務停止時,在替換掉相應的故障設備后,可直接再次開始業務的執行;當故障為本地端的BV更新成功后,由于網路故障導致原子一致組的狀態變為異常停止時,可在修復發生故障的連接后,再次執行差分遠程復制,以保證兩端數據的一致性;當故障是本地端的BV更新成功后由于RV硬件故障而導致原子一致組的狀態變為異常停止時,本地端的數據較遠程端的數據新,可在RV硬件故障修復后進行差分遠程復制,實現兩端數據的一致性;當本地端由于地震或停電等外因導致本地業務的停止,但遠程端處于正常狀態時,可利用遠程端RV的最新信息重新啟動業務,使業務恢復到失敗前的狀態,但是會有部分數據損失,特別是在本地端更新成功,而遠程端更新失敗或是異步模式下更新的周期設置過長的情況下,數據的損失會相對較大。
在遠程數據復制過程中,不但要求系統具有故障恢復的功能,還必須考慮數據復制順序的保證,在順序保證方面有以下幾種處理模式:
a)沒有保證,可以進行數據更新的合并。
b)不作任何I/O更新的合并,嚴格按照時間先后順序進行傳輸(數據帶寬耗費較大)。
c)更新數據打包后定期更新,但不允許合并。
d)采用日志式合并,但需維持相應的順序信息,遠程端按時間順序進行原子更新。
對于本機制來說,更新數據的順序保證是必需的,而且多volume內容相關的原因,對保證順序處理的要求更嚴格,因此采用模式d)。
33 I/O合并處理
在BV寫入應用數據的更新時,在短時間內向同一個數據塊寫入的情況會比較多;同時,短時間內均被更新的幾個數據塊在時間順序上存在依賴關系的情況并不多見[9]。因此本地端的更新數據在打包處理向遠程端發送前,可以根據更新數據的內容以及位置關系等特點對其進行合并處理,然后再打包發送。這將有助于提高遠程端更新的效率,也可以減輕網絡傳輸的負擔。這種I/O合并的處理在異步復制模式下的效果尤為明顯。
顯然,如果經過合并處理的更新數據沒有完全復制到遠程端時本地端發生致命的錯誤,那么系統恢復后的數據損失量及數據的可用性將直接受到合并策略的影響。因此,在設計合并策略時,需要考慮幾方面的因素:a)同一BV不同數據塊的更新是否存在內容上的依賴關系或是時間順序上的依賴關系。當不存在依賴關系時,則可根據數據傳送的需要以任意順序進行合并;而存在依賴關系的部分,則必須保持應用的原始關系,對數據塊的更新信息進行打包。b)同一數據塊的多次更新是否與同一BV中的其他數據塊的更新具有相關性。當某數據塊的多次更新與其他數據不相關時,只需保留最后一次更新結果打包傳送;否則,必須保留與其他數據塊相關的那一時刻的更新數據映像,并向遠程端更新,以保證遠程端數據的可用性。c)一個BV中的多塊更新數據是否與同一原子一致組中的其他BV的更新數據存在依賴關系。如果存在依賴關系時,在調整單個BV中的更新數據塊時,必須同時考慮與之存在依賴關系的BV中相應數據塊的調整,當兩個BV中的更新數據合并操作發生沖突時,不能作I/O合并處理。最后,要考慮I/O合并操作的數據量(設置數據打包的最大閾值)和時間間隔范圍。對于同步復制模式,時間間隔的要求會比較嚴格(即使允許進行I/O合并,時間間隔也會非常短);而異步復制模式下,則需要在選擇合適的時間間隔的同時,兼顧一次合并處理的數據量。
4結束語
在塊級存儲設備的遠程復制問題中,數據一致性的研究占有重要的一席之地,而對于多volume的數據復制一致性保證更是該研究領域的一大難點。本文通過借鑒事務管理思想,提出了具有原子一致性的遠程復制機制,并結合完備的故障恢復機制較好地保證備份數據的一致性和可用性。當然,由于實現中的數據打包機制,特別是在異步遠程復制的情況下,在故障恢復時根據check point進行回滾處理時,會又一定量以更新數據損失,這是無法回避的。如何將數據損失量降到更低的水平,是下一步深入研究的課題。
參考文獻:
[1] Eagle Rock Alliance Ltd. Online survey results: 2001 cost of downtime [EB/OL]. (2001). http://contingencyplanningresearch.com/2001%20Surv-ey.pdf.
[2]EMC Corporation. Using EMC SnapView and MirrorView for remote backup[EB/OL]. (2002). http://www.virtual.com/whitepapers/EMC_Using_SnapView.pdf.
[3]AZAGURY A C, FACTOR M E, MLCKA W F. Advanced functions for storage subsystems: supporting continuous availability [J]. IBM Systems Journal, 2003,42(2): 268-279.
[4]VERITAS Software Corporation. VERITAS volume replicator 3.5: administrator’s guide (Solaris) [EB/OL]. (2002).http://www.filibeto.org/sun/lib/nonsun/veritas/vxvm/3.5/248606.pdf.
[5]KEETON K, BEYER D, BRAU E, et al. On the road to recovery: restoring data after disasters[C]//Proc of the 1st ACM European Systems Conference. New York: ACM Press, 2006:235-248.
[6]WANG Yan-Long, LI Zhan-huai, LIN Wei. A fast disaster recovery mechanism for volume replication systems[C]//Proc of HPCC 2007. Berlin: Springer, 2007:732-743.
[7]JI Min-wen, VEITCH A, WILKES J. Seneca: remote mirroring done write[C]//Proc of USENIX Technical Conference. San Antonio: [s.n.],2003:253-268.
[8] HECTOR G M, ULLMAN J D, WIDOM J.數據庫系統實現[M].楊冬青,唐世渭,徐其鈞,等譯.北京:機械工業出版社, 2002:311-323.
[9]凌宗虎,李先國,韓志勇. 遠程復制系統數據一致性研究與實現[J].計算機應用, 2005,25(11): 2638-2640.