- 相關(guān)推薦
探討自適應(yīng)協(xié)同流水線的遠(yuǎn)程復(fù)制系統(tǒng)
1 引言
一直以來，數(shù)據(jù)保護(hù)都是IT 行業(yè)和工業(yè)中的熱門話題。特別是近幾年，經(jīng)歷過幾次大的災(zāi)難之后，一些具備完善的數(shù)據(jù)保護(hù)機(jī)制的企業(yè)能夠很快恢復(fù)，但是許多其他的企業(yè)則由于數(shù)據(jù)丟失而破產(chǎn)。因此，數(shù)據(jù)保護(hù)技術(shù)受到人們越來越多的關(guān)注。遠(yuǎn)程復(fù)制是一種流行的數(shù)據(jù)保護(hù)技術(shù)。它通過維護(hù)主站點(diǎn)與地域上相隔的遠(yuǎn)端站點(diǎn)的實(shí)時鏡像，實(shí)現(xiàn)對本地的自然或人為的災(zāi)難的容災(zāi)。目前，有兩種典型的遠(yuǎn)程鏡像策略：同步方式和異步方式[1]。因?yàn)橥椒绞綄TT[2]（Round Trip Time）極為敏感，所以異步方式更受人們的喜愛。
本文中，我們提出了一個新的協(xié)同流水線模型來描述遠(yuǎn)程復(fù)制系統(tǒng)�！皡f(xié)同”的意思是流水線跨越主站點(diǎn)，網(wǎng)絡(luò)和遠(yuǎn)程復(fù)制站點(diǎn)。因?yàn)槊總�子任務(wù)都有相應(yīng)的“所有者”，所以我們不能任意地分裂它們來平衡流水線的各個階段。為此，我們提出了自適應(yīng)成組傳輸策略。寫請求被成組傳輸?shù)竭h(yuǎn)程站點(diǎn)，而且每個組的大�。ńM與組之間的時間間隔）會根據(jù)主站點(diǎn)和遠(yuǎn)程備份站點(diǎn)的處理速度動態(tài)調(diào)整。在我們設(shè)計的模型中，實(shí)現(xiàn)了數(shù)據(jù)壓縮和加密，分別用來降低網(wǎng)絡(luò)傳輸壓力和增強(qiáng)安全性。這些操作給CPU 帶來了大量的負(fù)荷。因此，我們設(shè)計了三種加速方法：細(xì)粒度流水線、多線程流水線和混合流水線。
論文后面的篇幅組織如下：在第2 節(jié)中我們重點(diǎn)介紹近年來的相關(guān)工作。在第3 節(jié)，我們將詳細(xì)闡釋我們系統(tǒng)的基礎(chǔ)架構(gòu)，并提出自適應(yīng)協(xié)同流水線。在第4 節(jié)，我們將從大量實(shí)驗(yàn)結(jié)果中介紹該系統(tǒng)的實(shí)現(xiàn)并對其的測試。最后，在第5 節(jié)我們將作2 出結(jié)論并展望下一步的工作。
2 相關(guān)工作
EMC Symmetrix Remote Data Facility（SRDF）[3]應(yīng)用了塊級的同步遠(yuǎn)程復(fù)制技術(shù)，但是如果設(shè)備的性能降到閾值一下，它將切換到半同步模式。Veritas Volume Replicator（VVR）[4]是一種邏輯卷級別的遠(yuǎn)程復(fù)制系統(tǒng)。它支持多遠(yuǎn)程復(fù)制，并應(yīng)用日志和事務(wù)機(jī)制實(shí)現(xiàn)異步遠(yuǎn)程復(fù)制。Dot Hill 的成組遠(yuǎn)程復(fù)制服務(wù)[5]，源卷采用即時快照，然后向一個或多個遠(yuǎn)程復(fù)制系統(tǒng)傳輸傳輸快照數(shù)據(jù)更新。
網(wǎng)絡(luò)應(yīng)用的快照鏡像[1]使用快照保證備份卷的更新。WAFL 文件系統(tǒng)習(xí)慣于跟蹤已經(jīng)更新的數(shù)據(jù)塊。Seneca[6]延遲向遠(yuǎn)程站點(diǎn)發(fā)送成組更新來期待發(fā)生寫結(jié)合。寫操作僅在組中結(jié)合，并且在遠(yuǎn)程站點(diǎn)，每個組必須被原子地操作以防止數(shù)據(jù)不一致的事件發(fā)生。
類似于VVR 和Dot Hill 的遠(yuǎn)程復(fù)制服務(wù)，我們的原型也在邏輯卷層實(shí)現(xiàn)。像Seneca 一樣，更新操作被成組發(fā)送到遠(yuǎn)程站點(diǎn)提高性能。我們的原型中還采用了自適應(yīng)機(jī)制。然而，這種自適應(yīng)是基于異步模式和流水線階段平衡而不是網(wǎng)絡(luò)條件的自適應(yīng)。
還有許多其他的遠(yuǎn)程復(fù)制產(chǎn)品，例如IBM 的Extended Remote Copy （XRC）[7]，HPContinuous Access Storage Appliance （CASA）[8]等等。在近幾年的學(xué)術(shù)研究中，[9] 又提出了一種新的模型，在該模型中同步和異步模式由上層應(yīng)用程序或系統(tǒng)指定。[2]并使用ForwardError Correction （FEC）和“回調(diào)”機(jī)制來實(shí)現(xiàn)高可靠性。
3 自適應(yīng)協(xié)同流水線
顯示了我們原型的架構(gòu)。它是一個在Linux 的LVM2[10]上實(shí)現(xiàn)的異步遠(yuǎn)程鏡像系統(tǒng)。NBD（網(wǎng)絡(luò)塊設(shè)備，Network Block Device）[11]用于主從站點(diǎn)間的數(shù)據(jù)傳輸。當(dāng)一個寫請求到達(dá)時就被復(fù)制。原始請求被放到本地隊列，復(fù)制的請求被放到遠(yuǎn)程隊列。在遠(yuǎn)程隊列中的請求在一定時間間隔內(nèi)被成組發(fā)送到備份站點(diǎn)。因?yàn)镹BD 通過TCP 協(xié)議傳輸消息，所以只要每個組都能夠原子地傳輸?shù)絺浞菡军c(diǎn)就能保證一致性。為了減輕網(wǎng)絡(luò)傳輸壓力，請求在發(fā)送前先進(jìn)行壓縮。然后進(jìn)行加密操作來報證安全性。從計算復(fù)雜性上考慮，先壓縮后加密明顯優(yōu)于先加密后壓縮。因此，在備份站點(diǎn)，請求在被提交前先解密再解壓。
3.1 協(xié)同流水線
為了保證最大吞吐量，一個顯而易見的方法是主從站點(diǎn)的操作并行進(jìn)行，即當(dāng)一個組被發(fā)送出去后并不等待，而是主站點(diǎn)繼續(xù)處理下一個組，備份站點(diǎn)處理前一個。所以我們可以用兩階段（stage）流水線模型來描述請求處理的過程。我們分別叫這兩階段為主階段和備份階段。這是一個“協(xié)同”流水線，每個組被主從站點(diǎn)協(xié)作處理。我們知道，對于一個已知任務(wù)，階段越多，每階段的大小越接近，流水線的性能就越好。然而。協(xié)同流水線的一些特殊屬性與之相悖。
對于傳統(tǒng)流水線而言，要提高單一流水線的速度，必須把任務(wù)劃分成很小的單元。例如：
現(xiàn)代CPU 的流水線通常有超過20 個階段。然而，協(xié)同流水線一般由8 個子任務(wù)組成。包括把 bio 集合成組，壓縮，加密，成組傳輸，解密，解壓，寫磁盤和回應(yīng)。因?yàn)樗且粋�軟件流水線，進(jìn)一步的任務(wù)分解會導(dǎo)致交互開銷過大。更何況我們不能準(zhǔn)確地預(yù)知一些階段的執(zhí)行時間（主要是磁盤操作和網(wǎng)絡(luò)傳輸，它們的性能很大程度上依賴系統(tǒng)的當(dāng)前狀態(tài)）。對于高效率的流水線來說，這是一個嚴(yán)重的阻礙。
一些典型的分布式流水線模型，例如流水線的高斯估測法[12]，將任務(wù)分解成相同大小的子任務(wù)，并把它們分發(fā)到合適的處理器上。然而在協(xié)同流水線中，每個子任務(wù)都有特定的“主人”，所以不能把它們?nèi)我夥峙浣o其他的處理器。例如：備份站點(diǎn)不能進(jìn)行數(shù)據(jù)壓縮，而必須有主站點(diǎn)完成。這個繼承下來的不可變的任務(wù)映射使平衡負(fù)載變得困難。而且，即便我們把任務(wù)分成相同大小的子任務(wù)，處理器仍然會有空閑。此外，如果我們想通過加深流水線的深度來提高性能，我們就必須同等地進(jìn)一步分解主站點(diǎn)和備份站點(diǎn)。
3.2 自適應(yīng)成組傳輸
就像上面所提到的，在發(fā)送完前一個組后，主站點(diǎn)可以立即處理下一個組。在單用戶系統(tǒng)中，這種“盡力而為”的策略保證了最優(yōu)性能，但是它也有一些缺點(diǎn)。
如果兩個站點(diǎn)的速度不同，例如，主站點(diǎn)比備份站點(diǎn)快，在“盡力而為”策略下，兩個站點(diǎn)將會不同步。如果應(yīng)用程序?qū)毫釉诖鎯ψ酉到y(tǒng)上，主從站點(diǎn)之間的裂隙將會越來越大，直到主站點(diǎn)用盡系統(tǒng)資源。然后主站點(diǎn)會放慢速度來等待備份站點(diǎn)的應(yīng)答，好釋放足夠的資源。這樣使用戶體驗(yàn)很不穩(wěn)定（主站點(diǎn)的應(yīng)答時間）。此外，對于多用戶系統(tǒng)來說，一個處理器用盡所有系統(tǒng)資源不是好方法。這會嚴(yán)重影響系統(tǒng)的穩(wěn)定性和其他處理器的性能。
總而言之，盡力而為的策略不能很好地協(xié)調(diào)主從站點(diǎn)的關(guān)系。或者，它通過用盡系統(tǒng)資源來“協(xié)調(diào)”兩個站點(diǎn)。所以我們介紹一個自適應(yīng)成組算法進(jìn)行協(xié)調(diào)工作。當(dāng)系統(tǒng)初始化時我們設(shè)置一個組間隔。這個間隔明確了請求積累和成組處理的時間段。即前一階段積累的請求在下一階段被成組處理。每完成一個組的操作，我們就會調(diào)整組時間間隔，使主從站點(diǎn)的執(zhí)行時間接近。因此，當(dāng)組間時間間隔最終達(dá)到穩(wěn)定時，主從站點(diǎn)將有相同的執(zhí)行時間（都和組間時間間隔相同）。值得注意的是磁盤操作和網(wǎng)絡(luò)傳輸?shù)膱?zhí)行時間不和組大小成比例。所以，雖然兩個站點(diǎn)的時間間隔都變長或變短，但是增加迅速的那一方（通常是主站點(diǎn)）會比增長慢的那一方（通常是備份站點(diǎn)，包括磁盤操作和網(wǎng)絡(luò)傳輸）時間間隔長，所以組間時間間隔是收斂的。
不同于盡力而為的策略，當(dāng)主從站點(diǎn)步調(diào)不一致時，自適應(yīng)成組算法使較快的站點(diǎn)睡眠一段時間而不立即處理下一個組，即減慢較快的站點(diǎn)的速度來促使兩站點(diǎn)間保持平衡。這樣做的優(yōu)點(diǎn)是顯而易見的：執(zhí)行速度快的站點(diǎn)不會耗盡系統(tǒng)資源，因此不會系統(tǒng)中其他的處理器。另一個優(yōu)勢是自適應(yīng)成組傳輸對網(wǎng)絡(luò)狀況有很好的適應(yīng)性。如果網(wǎng)絡(luò)波動，由于時間間隔的調(diào)整，主從站點(diǎn)可以自動并及時地適應(yīng)網(wǎng)絡(luò)速度。下面的自適應(yīng)公式用來調(diào)整組間間隔。
公式中curr T 和next T 分別表示當(dāng)前和下一個時間間隔， pri T 和back T 分別表示主階段和備份階段的執(zhí)行時間。在我們的實(shí)現(xiàn)中， pri T 包括成組，壓縮，加密和發(fā)送組花費(fèi)的時間，back T包括傳輸分組，解密，解壓，寫磁盤和應(yīng)答所需時間。α 和β 是值在0 和1 之間的調(diào)整因子。它們決定了組間間隔接近真實(shí)處理時間的快慢和流水線適應(yīng)網(wǎng)絡(luò)改變的快慢。面對持續(xù)的繁重的負(fù)荷，我們使用組大小的閾值來控制一個組中最大請求數(shù)目：
其中total N 表示已經(jīng)被處理的總的請求數(shù)量；total T 表示總的處理時間；也就是說，統(tǒng)計量評估處理能力，并且用來設(shè)置下一個閾值next N 。說明了自適應(yīng)成組算法。當(dāng)主階段完成后，公式(1)用來調(diào)整組間間隔。如果住階段時間比當(dāng)前時間間隔短，主站點(diǎn)將會睡眠一段時間。當(dāng)主站點(diǎn)接收到應(yīng)答時使用公式(2)。
自適應(yīng)成組算法有不同的變體用于不同的用途。例如，我們可以將組間間隔設(shè)置的較短或較長。這些暗示了RPO 的可接受范圍（恢復(fù)點(diǎn)對象[13]）。此外，組大小的閾值可以用于提供QoS。我們可以調(diào)整組大小的閾值和時間間隔的比例來合理安排資源的占有。
3.3 加速技術(shù)
數(shù)據(jù)壓縮/解壓和加密/解密給CPU 帶來了大量的壓力�？紤]到多核系統(tǒng)的普遍性，可以利用并行技術(shù)實(shí)現(xiàn)自適應(yīng)協(xié)同流水線的加速。我們設(shè)計了兩種加速方案：細(xì)粒度流水線和多線程流水線。把這兩種方法相結(jié)合形成了混合流水線。
細(xì)粒度流水線加速單一流水線的通用方法是加深流水線的層次，即把任務(wù)分成更小的單元，是流水線變長，增加執(zhí)行的并行度。然而，就像我們在上面提到的，對于協(xié)同流水線，我們不能任意重分解流水線。從而，我們必須將主階段和備份階段分成相同數(shù)量，相同大小的小階段。很難將現(xiàn)存的兩個階段分成完全相同的小階段，我們采取以下兩種策略：
——我們根據(jù)經(jīng)驗(yàn)手動將這兩個現(xiàn)存的階段分解。在我們的實(shí)現(xiàn)方式里，主階段被分成兩個子階段：壓縮階段包括成組和數(shù)據(jù)壓縮；加密階段包括數(shù)據(jù)加密和成組發(fā)送。備份階段也相應(yīng)地分成兩個階段：計算階段包括接收組，數(shù)據(jù)解密和解壓；I/O 處理階段包括寫磁盤和發(fā)送應(yīng)答信息。主從站點(diǎn)均調(diào)用兩個線程。每個線程負(fù)責(zé)一個子階段。
——很明顯，經(jīng)驗(yàn)僅僅保證四個階段近似相等。為了使它們更接近，也要面對動態(tài)地改變，自適應(yīng)成組算法又一次被用到。每個階段完成后，就應(yīng)用相應(yīng)地自適應(yīng)公式來調(diào)整組間時間間隔。
多線程流水線另一種直觀的加速方法是把每個階段并行地分解成子階段而不是分成更多的小階段。因?yàn)槊總�組中包括成百上千的請求，簡單有效的分解技術(shù)是數(shù)據(jù)劃分。在我們的實(shí)現(xiàn)中，每個組被分成兩個相同大小的子組，且主從站點(diǎn)各調(diào)用兩個線程。每個線程負(fù)責(zé)一個子組。它們并行地處理子組之后出于一致性地考慮，串行地發(fā)送出去。
類似于細(xì)粒度流水線，多線程流水線也面臨著負(fù)載平衡的問題。幸運(yùn)的是，在這種方式下，問題解決起來容易得多。注意，請求的計算時間和數(shù)據(jù)大小是成比例的。如果負(fù)載中包括的請求都有相同的大�。ɡ�，在我們的實(shí)驗(yàn)中，由Iometer 生成負(fù)載），那么如果根據(jù)請求數(shù)量來分割子組將很容易保證負(fù)載平衡。此外，我們可以根據(jù)字節(jié)總數(shù)分割子組。
串行網(wǎng)絡(luò)傳輸似乎是多線程流水線的一個阻礙。但是花在這上面的時間只是總執(zhí)行時間的一小部分，因此串行網(wǎng)絡(luò)傳輸并沒有對系統(tǒng)的性能造成很大影響。我們的實(shí)驗(yàn)結(jié)果也證實(shí)了這一點(diǎn)。
此外，多線程流水線比細(xì)粒度流水線更靈活。它甚至可以用來處理不對等的協(xié)同流水線。
例如，如果備份站點(diǎn)是主站點(diǎn)的兩倍，備份站點(diǎn)可以用主站點(diǎn)的兩倍的線程數(shù)來達(dá)到它們之間的執(zhí)行時間的平衡。
混合流水線我們的實(shí)驗(yàn)結(jié)果顯示，不論是四階段流水線還是雙線程流水線都完全占用CPU。理論上，加深流水線或用更多的線程都能充分利用CPU 的能力。然而，像我們上面提到的，太深的流水線會導(dǎo)致嚴(yán)重的交互負(fù)擔(dān)。后一個策略，把一個組分成若干小組可能導(dǎo)致負(fù)載不平衡。而太多的線程也會增加交互負(fù)擔(dān)，所以我們結(jié)合這兩個策略。主從階段都分成兩個子階段，并且每個子階段用多線程技術(shù)進(jìn)一步加速。我們可以稱這種方法為混合流水線。
事實(shí)上，細(xì)粒度流水線是組間并行，即同一時刻，每個組僅由一個處理器處理，幾個組同時由多個處理器處理。多線程流水線是組內(nèi)并行，即各個組一個接一個地被處理，每個組被多個處理器同時處理。混合流水線是二維并行。
4 實(shí)驗(yàn)評估
4.1 原型實(shí)現(xiàn)
自適應(yīng)成組算法是在Linux 的LVM2 下作為“遠(yuǎn)程復(fù)制”實(shí)現(xiàn)的。類似于LVM2 下的快照模型，我們的模型把遠(yuǎn)程鏡像當(dāng)做本地卷的附加卷，并實(shí)現(xiàn)了三種加速算法。底層的操作系統(tǒng)是RedHat AS server 5（內(nèi)核版本是2.6.18-128.el5）。并使用LVM2 2.02.39，device mapper1.02.28 和NBD 2.8.8。壓縮/解壓算法用的是LZW 算法[14]，加密/解密算法用的是AES 算法[15]。為保證組的自動提交，備份站點(diǎn)使用了日志機(jī)制。
4.2 實(shí)驗(yàn)建立
所有的實(shí)驗(yàn)都在2.66GHz 的英特爾雙核Xeon 節(jié)點(diǎn)下進(jìn)行的。一個作為主站點(diǎn)，另一個作為備份站點(diǎn)。每臺機(jī)器有2GB 的內(nèi)存和由6 個37GB 的SAS 硬盤組成的RAID-5 硬件。
兩個節(jié)點(diǎn)由千兆以太網(wǎng)相連。為了測試三種并行的模型，我們將備份站點(diǎn)的日志機(jī)制關(guān)閉來讓CPU 承受更多的負(fù)載。α 和β 均被置成0.5。組間間隔初始化為30 毫秒。我們用Iometer[16]
來產(chǎn)生負(fù)載。由于寫請求觸發(fā)了遠(yuǎn)程復(fù)制模型，我們僅需要測試寫負(fù)載。不像其他專門的狀態(tài)，順序?qū)懾?fù)載也被使用。為了評估異步模式在性能上的影響，我們記錄經(jīng)過一段時間Iometer 顯示的性能曲線趨于穩(wěn)定時的實(shí)驗(yàn)結(jié)果。每個數(shù)據(jù)點(diǎn)都是三個樣本的平均值。
4.3 實(shí)驗(yàn)結(jié)果
我們首先進(jìn)行基準(zhǔn)線測試。顯示出了結(jié)果。“pri”主站點(diǎn)中的RAID-5 設(shè)備，“back”代表備份站點(diǎn)中的RAID-5 設(shè)備。“LVM”代表主站點(diǎn)的源卷，“Async”代表沒有自適應(yīng)成組算法的異步遠(yuǎn)程復(fù)制系統(tǒng)�！皊imple batch”代表有自適應(yīng)成組算法但是沒有數(shù)據(jù)壓縮和加密。
我們可以看出，自適應(yīng)成組算法的性能很好，盡管和純磁盤操作還有一定差距。
顯示了數(shù)據(jù)壓縮和加密在性能上的影響�！癱ompression”表示僅進(jìn)行壓縮，不進(jìn)行加密；“encryption”表示僅加密不壓縮；“batch”表示既壓縮又加密。和我們預(yù)期的一樣，引入壓縮很大程度上提高了性能，因?yàn)榫W(wǎng)絡(luò)傳輸壓力減少；而由于復(fù)雜的計算度使加密嚴(yán)重影響了性能。而最終版本的性能在這兩者之間。
顯示出3 種并行模型很大程度上提高了性能。我們可以看到三種模型均明顯加速了流水線。細(xì)粒度流水線和多線程流水線顯示出幾乎相同的性能�；旌狭魉�提供了更好的性能。因?yàn)镃PU 沒有過載——在混合流水線測試中CPU 只有87%的占用率。
我們也跟蹤了組間間隔（組大�。�。結(jié)果顯示在中。組間間隔分別被初始化為30毫秒和15 毫秒。請求大小是4KB。我們記錄了前20 個時間段的組大小�？梢钥闯鲎赃m應(yīng)成組算法確實(shí)是主從站點(diǎn)協(xié)作很好。組間間隔迅速趨向穩(wěn)定。
我們還測試了隨機(jī)寫的性能。所示，與順序?qū)懴啾龋S機(jī)寫性能在串行和并行版本之間的差距在減小。原因是I/O 部分在整個運(yùn)行時間中的比例增加了，而且三種并行模型僅加速了計算部分。
5 結(jié)論和進(jìn)一步工作
本文中，我們展示了一種新型的遠(yuǎn)程復(fù)制系統(tǒng)的協(xié)同流水線模型。不同于傳統(tǒng)的流水線模型，這種新的模型充分利用了處理器的計算能力。為了解決主從階段的不平衡性，我們提出了自適應(yīng)成組算法。為了減輕由于壓縮，加密和TCP/IP 協(xié)議棧造成的CPU 高負(fù)載的情況，我們設(shè)計了三種并行的模型：細(xì)粒度流水線，多線程流水線和混合流水線。在我們的原型中實(shí)現(xiàn)了這些技術(shù)。實(shí)驗(yàn)結(jié)果表明，自適應(yīng)協(xié)同流水線模型有效地平衡了主從階段，三種并行方式提供了更好的性能。
我們所有的實(shí)驗(yàn)都是基于局域網(wǎng)環(huán)境。在廣域網(wǎng)環(huán)境下測試我們的模型是下一步我們要進(jìn)行的重要工作。用有效的糾刪碼進(jìn)行進(jìn)一步容錯（Error Correcting）也是我們的下一步計劃研究的內(nèi)容。
中國碩士論文網(wǎng)提供大量免費(fèi)碩士畢業(yè)論文,如有業(yè)務(wù)需求請咨詢網(wǎng)站客服人員！
參考文獻(xiàn)
[1] Patterson, R.H., Manley, S., Federwisch, M., Hitz, D., Kleiman, S., Owara, S.: SnapMirror:
File-System-Based Asynchronous Mirroring for Disaster Recovery. In:Proceedings of the 1st USENIX Conference
on File and Storage Technologies, FAST 2002, Monterey, California, USA (Jan 2002) 117–129
[2] Weatherspoon, H., Ganesh, L., Marian, T., Balakrishnan, M., Birman, K.: Smoke and Mirrors: Reflecting
Files at a Geographically Remote Location Without Loss of Performance. In: Proceedings of the 7th USENIX
Conference on File and Storage Technologies, FAST 2012, San Francisco, California, USA (Feb 2012) 211–224
[3] EMC SRDF - Zero Data Loss Solutions for Extended Distance Replication. Technical Report P/N
300-006-714, EMC Corporation (Apr 2012)
[4] VERITAS Volume Replicator (tm) 3.5 Administrator’s Guide (Solaris). Technical Report 249505, Symantec
Corporation, Mountain View, CA, USA (Jun 2002)
[5] Secure Data Protection With Dot Hills Batch Remote Replication. White Paper, dot Hill Corporation (Jul
2012)
[6] Ji, M., Veitch, A.C., Wilkes, J.: Seneca: Remote Mirroring Done Write. In: Proceedings of the General Track:
2003 USENIX Annual Technical Conference, San Antonio, Texas, USA (Jun 2003) 253–268
[7] DFSMS/MVS Version 1 Remote Copy Administrator’s Guide and Reference 4th edition. Technical Report
SC35-0169-03, IBM Corporation (Dec 1997)
[8] HP OpenView continuous access storage appliance. White Paper, Hewlett-Packard Company (Nov 2002)
[9] Liu, X., Niv, G., Shenoy, P.J., Ramakrishnan, K.K., van der Merwe, J.E.: The Case for Semantic Aware
Remote Replication. In: Proceedings of the 2006 ACM Workshop On Storage Security And Survivability,
StorageSS 2006, Alexandria, VA, USA (Oct 2006) 79–84
[10] LVM.
[10] Breuer, P.T., Lopez, A.M., Ares, A.G.: The Network Block Device. Linux Journal 2000(73) (2000) 40
[12] Grama, A., Gupta, A., Karypis, G., Kumar, V.: Introduction to Parallel Computing, Second Edition.
Addison-Wesley, Essex, England (2003)
[13] Keeton, K., Santos, C.A., Beyer, D., Chase, J.S., Wilkes, J.: Designing for Disasters. In: Proceedings of the
3rd USENIX Conference on File and Storage Technologies, FAST 2004, San Francisco, California, USA (Mar
2004) 59–72
[14] Welch, T.A.: A Technique for High-Performance Data Compression. IEEE Computer 17(6) (1984) 8–19
[15] NIST Advanced Encryption Standard(AES). Federal Information Processing Standards Publication (2001)
[16] Iometer.
【探討自適應(yīng)協(xié)同流水線的遠(yuǎn)程復(fù)制系統(tǒng)】相關(guān)文章：
探討消防自動噴水滅火系統(tǒng)08-25
淺析貝葉斯網(wǎng)絡(luò)在自適應(yīng)超媒體系統(tǒng)中應(yīng)用研究05-29
可視化遠(yuǎn)程會商系統(tǒng)及其維護(hù)09-19
探討山東省區(qū)域創(chuàng)新系統(tǒng)建設(shè)05-11
探討基于多種通信方式并存的配網(wǎng)自動化通信系統(tǒng)06-01
基于電話網(wǎng)絡(luò)的熱網(wǎng)遠(yuǎn)程控制系統(tǒng)設(shè)計05-11
論Ｅ企業(yè)的協(xié)同電子商務(wù)模式06-03
探討西瓜嫁接育苗技術(shù)05-29