容災(zāi)系統(tǒng)的數(shù)據(jù)共享模型

容災(zāi)系統(tǒng)的數(shù)據(jù)共享模型

1數(shù)據(jù)安全塊級(jí)遠(yuǎn)程數(shù)據(jù)重復(fù)傳輸是實(shí)現(xiàn)數(shù)據(jù)容災(zāi)的主要方法，數(shù)據(jù)傳輸是遠(yuǎn)程數(shù)據(jù)重復(fù)傳輸?shù)暮诵?。RVR(RemoteVolumeReplicator)是一個(gè)基于遠(yuǎn)程數(shù)據(jù)復(fù)制的容災(zāi)系統(tǒng),如圖1所示。與現(xiàn)有的容災(zāi)系統(tǒng)相比,RVR不需要額外的專用設(shè)備,并且具有較好的容災(zāi)性能。從圖1可以看到,RVR存在于操作系統(tǒng)內(nèi)核中,用戶發(fā)出對(duì)磁盤數(shù)據(jù)塊級(jí)的寫請(qǐng)求被系統(tǒng)截獲、分析、處理。在RVR系統(tǒng)中,若干個(gè)磁盤組成一組RVG(ReplicationVolumeGroup),每一組的RVG包含一個(gè)LV(LogVolume)和若干個(gè)DV(DataVolume),當(dāng)且僅當(dāng)請(qǐng)求目標(biāo)地址屬于RVG包含的磁盤(DV)時(shí),RVR才可以在相應(yīng)請(qǐng)求更新主服務(wù)器磁盤的同時(shí),把請(qǐng)求的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸發(fā)送到一個(gè)或多個(gè)數(shù)據(jù)備份從端。備份端也執(zhí)行主服務(wù)器端相同的請(qǐng)求。RVR在LV上建立起一個(gè)循環(huán)隊(duì)列用來記錄請(qǐng)求,日志卷既是主服務(wù)器端設(shè)備所接收請(qǐng)求的記錄者,也是進(jìn)行遠(yuǎn)程復(fù)制的數(shù)據(jù)源。RVR不論在寫主服務(wù)器端的DV還是進(jìn)行向備份端的數(shù)據(jù)傳輸都嚴(yán)格執(zhí)行循環(huán)隊(duì)列記錄的請(qǐng)求順序。對(duì)于每一個(gè)用戶請(qǐng)求,主服務(wù)器端的寫磁盤順序是這樣的:首先在LV上記錄請(qǐng)求,記錄完成后,在寫入主服務(wù)器端DV的同時(shí),將數(shù)據(jù)傳輸?shù)絺浞荻?通常情況,備份端只需要把數(shù)據(jù)寫入本端的DV。這樣,主服務(wù)器端和備份端應(yīng)用磁盤上的數(shù)據(jù)完全一致。2數(shù)據(jù)傳輸模式在RVR的數(shù)據(jù)傳輸中分同步和異步兩種模式。2.1器端下請(qǐng)求的發(fā)送在同步模式下,RVR確保應(yīng)用請(qǐng)求在返回前被記錄到LV請(qǐng)求隊(duì)列,并更新到主服務(wù)器端的DV,發(fā)送到備份服務(wù)器,如圖2所示。主服務(wù)器端先將請(qǐng)求記錄在LV上(1),然后并行地將請(qǐng)求寫入主服務(wù)器端(2)和發(fā)送到備份服務(wù)器端的DV(3),備份端接收到請(qǐng)求后,會(huì)立刻向主服務(wù)器端發(fā)送一個(gè)接收確認(rèn)報(bào)文(4),通知主服務(wù)器端可以向上層返回請(qǐng)求,主服務(wù)器端就可以處理下一個(gè)請(qǐng)求。當(dāng)寫備份端的DV(5)完成后,會(huì)向主端發(fā)送一個(gè)寫DV完成報(bào)文,這時(shí),主端就會(huì)將記錄在LV(1)上已在從端執(zhí)行過的寫請(qǐng)求刪除。2.2rvr的rvr請(qǐng)求在異步模式下,只要把請(qǐng)求記錄到LV請(qǐng)求隊(duì)列并更新到主服務(wù)器端的DV之后,即可以讓應(yīng)用請(qǐng)求返回,如圖3所示。RVR把請(qǐng)求記錄到LV(1),同步地進(jìn)行寫主端的DV(2)和向從端發(fā)送請(qǐng)求(3),完成對(duì)主端DV的更新后,(2)即可向上層返回請(qǐng)求,而不需要等待備份服務(wù)器端確認(rèn)收到對(duì)應(yīng)的請(qǐng)求。與同步傳輸一樣的是:備份端完成對(duì)寫DV操作(5),會(huì)向主端發(fā)送一個(gè)寫DV的報(bào)文,主端就會(huì)將記錄在LV(1)上的請(qǐng)求刪除。3基于業(yè)務(wù)系統(tǒng)的特殊通訊數(shù)據(jù)傳輸是RVR的核心部分,它主要負(fù)責(zé)主從兩端之間的通訊,負(fù)責(zé)在遠(yuǎn)程復(fù)制過程中的數(shù)據(jù)傳輸和數(shù)據(jù)還原所需要進(jìn)行的災(zāi)難預(yù)恢復(fù)。我們建立了正常的傳輸模型、災(zāi)難預(yù)恢復(fù)的傳輸模型和進(jìn)行控制的報(bào)文模型。3.1創(chuàng)建聽線程plt、正交接口線程,創(chuàng)建監(jiān)聽線在正常狀況下,系統(tǒng)通過主端連接模塊、從端連接模塊和監(jiān)聽模塊來完成正常數(shù)據(jù)的發(fā)送。我們?cè)O(shè)計(jì)三個(gè)線程分別實(shí)現(xiàn)模塊的功能,參見圖4。RVR初始化的時(shí)候,在主端創(chuàng)建主端連接線程PLT(PrimaryLinkThread),在從端創(chuàng)建監(jiān)聽線程LT(ListenThread);PLT向LT發(fā)送連接請(qǐng)求,建立連接后,PLT會(huì)向LT發(fā)送Identity報(bào)文;Identity報(bào)文包含著合法性信息;LT通過檢測(cè),判斷其如果合法,LT就啟動(dòng)從端連接線程SLT(SecondaryLinkThread),建立起PLT和SLT的連接,開始進(jìn)行正常的消息傳遞和數(shù)據(jù)發(fā)送。3.2基于災(zāi)難預(yù)恢復(fù)的主服務(wù)器策略災(zāi)難預(yù)恢復(fù)是將發(fā)生災(zāi)難時(shí)主服務(wù)器端和備份端所記錄的信息進(jìn)行分析整合,得到最完整的數(shù)據(jù)信息,這是進(jìn)行災(zāi)難恢復(fù)的必要條件,也是RVR的一項(xiàng)重要工作。當(dāng)主服務(wù)器癱瘓后,某個(gè)備份端立刻通過切換擔(dān)當(dāng)起主服務(wù)器的角色,如果需要重新建立主服務(wù)器,就要執(zhí)行災(zāi)難恢復(fù)業(yè)務(wù)。實(shí)施災(zāi)難預(yù)恢復(fù)策略的程序參見圖5。通過命令方式在舊的主服務(wù)器端(也就是發(fā)生災(zāi)難端)開始策略,啟動(dòng)預(yù)恢復(fù)發(fā)送線程PST(Pre-restoreSendThread),這時(shí)新服務(wù)器端的LT處于監(jiān)聽狀態(tài),PST向LT發(fā)送Pre-restore的連接請(qǐng)求,LT通過驗(yàn)證合法后,啟動(dòng)新服務(wù)器端的預(yù)恢復(fù)接收線程PRT(Pre-restoreReceiveThread)與PST建立連接,進(jìn)行DCM(見第四部分的DCM)數(shù)據(jù)操作,執(zhí)行災(zāi)難預(yù)恢復(fù)。當(dāng)災(zāi)難預(yù)恢復(fù)完成后,PST和PRT退出,啟動(dòng)PLT和SLT進(jìn)行災(zāi)難恢復(fù)。3.3報(bào)文的數(shù)據(jù)接收端平臺(tái)根據(jù)RVR的需要,我們?cè)O(shè)計(jì)出各種數(shù)據(jù)報(bào)文以方便數(shù)據(jù)的傳輸和控制。一個(gè)報(bào)文由報(bào)文頭(Header)和要傳輸?shù)臄?shù)據(jù)(Data)兩部分組成。不同類型的報(bào)文所需要的信息是不同的,我們?cè)谠O(shè)計(jì)過程中統(tǒng)一了報(bào)文的長度,用于存放報(bào)文的共同信息和某些報(bào)文特有的信息,這樣可以方便讀取數(shù)據(jù)。接收端通過報(bào)文頭里的信息對(duì)報(bào)文的數(shù)據(jù)信息進(jìn)行操作。報(bào)文頭里存放了報(bào)文的類型,當(dāng)接收端接收到報(bào)文后,讀取報(bào)文頭的報(bào)文類型,再根據(jù)報(bào)文類型作相關(guān)的處理和操作。4第二,主從端數(shù)據(jù)共享定義:用時(shí)間戳τP(t)和τB(t)分別代表主服務(wù)器端系統(tǒng)(DV)和備份從端系統(tǒng)(DV)在時(shí)刻t的數(shù)據(jù)映像,如果在時(shí)刻t,存在t’≤t,使得τP(t’)=τB(t),則認(rèn)為主從系統(tǒng)滿足數(shù)據(jù)一致性。數(shù)據(jù)一致性是衡量備份容災(zāi)系統(tǒng)的關(guān)鍵因素。如果經(jīng)過數(shù)據(jù)傳輸,主服務(wù)器端和備份端的數(shù)據(jù)出現(xiàn)了不一致,將無法進(jìn)行災(zāi)難恢復(fù)。為了實(shí)現(xiàn)主從端數(shù)據(jù)一致性,主端把對(duì)DV的每個(gè)請(qǐng)求按照其到達(dá)的順序保存到LV隊(duì)列中。日志隊(duì)列中的所有請(qǐng)求將被按照到達(dá)的順序發(fā)送到從端并在從端數(shù)據(jù)盤上執(zhí)行。盡管如此,在一些不確定的因素影響下,仍然會(huì)出現(xiàn)數(shù)據(jù)不一致的情況,需要通過一些特殊的操作使其保持一致。4.1當(dāng)方案1.2—原子操作若復(fù)制模式是異步的,用戶的請(qǐng)求1到請(qǐng)求5是對(duì)數(shù)據(jù)塊1,2和3的操作,請(qǐng)求1,2,3是寫數(shù)據(jù)塊1,2和3,請(qǐng)求4和5是對(duì)數(shù)據(jù)快1和3進(jìn)行修改,數(shù)據(jù)請(qǐng)求1到5已經(jīng)全部發(fā)送到了從端,若出現(xiàn)網(wǎng)絡(luò)故障,從端發(fā)送給主端的數(shù)據(jù)確認(rèn)丟失,這種情況參見圖6。當(dāng)網(wǎng)路恢復(fù)后,由于主端沒有接收到從端的確認(rèn),按照原先請(qǐng)求1到5的數(shù)據(jù)重新發(fā)送。當(dāng)數(shù)據(jù)1發(fā)送到從端后,主端的數(shù)據(jù)就是修改后的1,2和修改后的3,而從端是1,2和修改后的3,出現(xiàn)了數(shù)據(jù)不一致的情況。針對(duì)這種情況,系統(tǒng)從沒有接收到從端返回確認(rèn)的用戶請(qǐng)求開始到當(dāng)前時(shí)刻所有已經(jīng)發(fā)送的用戶請(qǐng)求做原子操作,見圖7。主服務(wù)器端要么將這五個(gè)數(shù)據(jù)請(qǐng)求在從端全部執(zhí)行,要么一個(gè)也不執(zhí)行,等從端完全執(zhí)行后(將數(shù)據(jù)寫入從端的DV),從端向主端返回確認(rèn),整個(gè)原子操作完成。整個(gè)原子操作過程中LINK會(huì)標(biāo)識(shí)為inconsistent,當(dāng)整個(gè)原子過程完成后,LINK才標(biāo)識(shí)為consistent,主從端的數(shù)據(jù)就會(huì)重新成為一致。主端恢復(fù)到正常方式發(fā)送數(shù)據(jù)。4.2存儲(chǔ)的存儲(chǔ)一致性dcm日志隊(duì)列LV的長度是有限的,所以它是以循環(huán)列表的方式實(shí)現(xiàn)的。日志隊(duì)列有四個(gè)指針,分別記錄已寫入主服務(wù)器日志隊(duì)列的LvIndex、主服務(wù)器數(shù)據(jù)盤的DvIndex、已發(fā)送至從端的RepIndex、已接收到從端確認(rèn)的AckIndex。四個(gè)指針有其先后的順序,LvIndex是不能超越AckIndex的。在異步傳輸模式下,LvIndex有可能到AckIndex后并和AckIndex重合,出現(xiàn)記錄請(qǐng)求的數(shù)據(jù)區(qū)不足的情況,這稱之為日志溢出。當(dāng)日志溢出時(shí),如果讓記錄請(qǐng)求直接覆蓋前面的數(shù)據(jù),則會(huì)引起主從數(shù)據(jù)不一致。這時(shí)采用DCM(DataChangeMaps)策略可保持?jǐn)?shù)據(jù)一致性。DCM是以位圖方式記錄改變過的數(shù)據(jù)塊位置,而不記錄具體數(shù)據(jù)塊的內(nèi)容,RVG內(nèi)每一個(gè)DV都設(shè)置一個(gè)對(duì)應(yīng)的DCM。DCM的信息記錄在LV頭部的信息控制區(qū),當(dāng)日志溢出時(shí),首先暫停接收請(qǐng)求直到LvIndex和DvIndex重合,主服務(wù)器端的日志和數(shù)據(jù)盤均已完成請(qǐng)求;然后記錄AckIndex和LvIndex之間數(shù)據(jù)內(nèi)容對(duì)應(yīng)的DV數(shù)據(jù)塊所在DCM中映射的位,構(gòu)建日志位圖表;完成DCM構(gòu)建后,將AckIndex、RepIndex調(diào)至DvIndex、LvIndex所在位置,繼續(xù)接受上層請(qǐng)求,同時(shí)將DCM所標(biāo)記的數(shù)據(jù)發(fā)送至從端。雖然DCM操作會(huì)暫停用戶寫請(qǐng)求,但由于寫主服務(wù)器的日志設(shè)備和數(shù)據(jù)設(shè)備均是本地I/O操作,所以等待LvIndex和DvIndex重合耗時(shí)很短。DCM操作執(zhí)行的另外一種情況是在進(jìn)行Pre-restore時(shí),通過舊主端刷新發(fā)送DCM位圖的信息,將發(fā)生災(zāi)難時(shí)主服務(wù)器端的數(shù)據(jù)對(duì)應(yīng)信息發(fā)送到備份端,再和新主端的DCM位圖信息進(jìn)行對(duì)比或操作,進(jìn)而發(fā)送所對(duì)應(yīng)的數(shù)據(jù),完成Pre-restore。5物理設(shè)備的占用RVR的數(shù)據(jù)復(fù)制不需專用設(shè)備,可以和其他的系統(tǒng)共享已有的物理設(shè)備,這就需要在傳輸中盡可能地占用少的資源,以便其他設(shè)備正常的工作。在優(yōu)化時(shí),RVR采用了合并請(qǐng)求的策略,以減少網(wǎng)絡(luò)帶寬,提高傳輸速度。5.1多次對(duì)進(jìn)程的更新文件系統(tǒng)的請(qǐng)求操作往往有在短期內(nèi)重復(fù)寫同一個(gè)塊的現(xiàn)象,其中一個(gè)原因是數(shù)據(jù)文件的修改為增長的、漸進(jìn)的。上層的請(qǐng)求可能在不斷地修改和保存某個(gè)塊的數(shù)據(jù),如果在后臺(tái)的復(fù)制中,能夠把請(qǐng)求進(jìn)行分析合并,就可以在保證數(shù)據(jù)一致性的前提下提高傳輸?shù)男阅?。磁盤塊的更新操作采用的是完全覆蓋的形式,對(duì)于單個(gè)磁盤塊,多次對(duì)其更新相當(dāng)于最后一次更新。假如在主服務(wù)器端的日志隊(duì)列中記錄著請(qǐng)求序列U={R1,R2…Rn},隊(duì)列中的請(qǐng)求是按連續(xù)到達(dá)的順序排列的,在優(yōu)化前,這n個(gè)請(qǐng)求需要按照順序發(fā)送到備份端。按照優(yōu)化的策略,如果在這n個(gè)請(qǐng)求中,對(duì)應(yīng)操作的是m個(gè)不同地址(m一定不大于n),這些不同的地址用A1,A2…Am表示,U中的請(qǐng)求就可以表示為m個(gè)地址不同的請(qǐng)求的集合,我們稱這個(gè)集合為BRS(BlockUpdateSet),BRSk表示為{Ri|Ri屬于U且Ri對(duì)應(yīng)操作的地址等于Ak},U就相應(yīng)地表示為{BRS1,BRS2…BRSm}。令Mk代表BRSk中請(qǐng)求編號(hào)最大的一個(gè)編號(hào)(最后的一個(gè)請(qǐng)求的編號(hào))、請(qǐng)求隊(duì)列U*={RM1,RM2,…RMm},RVR執(zhí)行完請(qǐng)求隊(duì)列U,和隊(duì)列U*的數(shù)據(jù)映象是一致的。因此,通過優(yōu)化,對(duì)于請(qǐng)求隊(duì)列U,我們找到所對(duì)應(yīng)的U*來執(zhí)行,這就能保證在數(shù)據(jù)映象相同的條件下提高傳輸性能。5.2計(jì)算處理能力的要求除上述的方法外,數(shù)據(jù)壓縮也是一種常見的提高傳輸性能的方法。壓縮算法一般需要比較大的計(jì)算量,RVR的設(shè)計(jì)目標(biāo)對(duì)系統(tǒng)的計(jì)算處理能力要求不是很高,在計(jì)算處理能力較低的系統(tǒng)使用數(shù)據(jù)壓縮策略來進(jìn)行優(yōu)化,可能會(huì)降低系統(tǒng)的響應(yīng)時(shí)間。壓縮算法是一種通用的算法,一般基于數(shù)據(jù)流本身,在系統(tǒng)資源允許的情況下,很容易將壓縮算法實(shí)施到傳輸當(dāng)中,至于算法的本身,超出了本文的討論范圍,在這里不做詳述。6請(qǐng)求合并策略在新刑罰執(zhí)行系統(tǒng)中所使用的差異在相同的硬件環(huán)境、網(wǎng)絡(luò)資源和數(shù)據(jù)塊的大小的條件下進(jìn)行實(shí)驗(yàn)對(duì)比,傳輸模式均為異步傳輸。系統(tǒng)優(yōu)化前和優(yōu)化后的性能指標(biāo)見表1。從表1可以看到,在新數(shù)據(jù)拷貝的時(shí)候,系統(tǒng)在優(yōu)化后的性能并無提高,反而有降低的情況,這說明在新拷貝數(shù)據(jù)請(qǐng)求時(shí)所對(duì)應(yīng)的地址均是不同