秒啓萬臺主機，騰訊云云硬盤數據調度架構演進

1、CBS數據調度系統的演進歷程 

           
CBS存儲系統，主要爲騰訊雲的CVM提供高性能、高可靠、低成本的塊存儲服務。 CBS數據調度系統，是基於存儲系統構建的統一的數據調度服務。爲何要構建統一的數據調度呢？
在2015年時它僅僅做爲快照系統存在，僅是保存在雲上的數據，目的是爲了提升整個數據的安全性。用戶會對數據進行備份，若是這個時候數據丟失，能夠利用快照對其恢復。
上雲業務還沒有規模化，快照系統的業務量不大，並且快照備份自己是離線業務，因此針對IO時延時延方面並不敏感。 但隨着業務上雲愈來愈多，雲盤的規模也愈來愈大。利用回滾的能力，來作鏡像生產雲服務器，數據調度系統拓展了新的應用場景，同時，系統回滾能力也要求愈來愈高，時延方面也逐漸敏感。 隨着CBS業務不斷快速增加和架構不斷演進，催生出另外一個全新數據調度場景——雲盤的在線遷移。
雲盤在線遷移是什麼意思？某些場景下須要將雲盤從一個存儲倉庫遷移到另一個存儲倉庫，並且是在線遷移，對用戶的業務是無損的。
它有一個特色是對時延的抖動敏感，用戶的業務已經運行了，對整個時延抖動的要求是極低的。 咱們把前文所述的數據能力抽象出一個統一數據調度平臺，負責咱們離線的數據和在線的數據打通。它當前涵蓋主要三個場景：數據保護、雲服務器批量生產和雲盤在線遷移。下文將圍繞這三個場景一一展開。

首先介紹整個數據調度系統的三層架構，第一層是業務中控層，中控是高可用服務，負責接受前端的業務請求，無論是打快照仍是作回滾，以及雲盤遷移，都會到咱們的中控層，再轉發任務給數據調度層。
數據調度層是集羣模式，會把調度任務按照邏輯地址劃爲大小相同的數據塊，並把塊信息給到傳輸層，那麼傳輸層看到的就是一個個的數據塊，數據調度層會告訴傳輸層節點這個數據塊源端在哪裏，目的在哪裏，再由傳輸層節點完成了數據的搬遷功能。
數據調度系統，爲CBS構築離線存儲系統和在線存儲系統、在線存儲系統之間數據流動能力。

2、典型業務場景以及面臨的挑戰

                下文將爲你們介紹CBS的三個典型業務場景，以及面臨的挑戰有哪些？  

1. 數據保護

 （1）數據保護
用在咱們的平常備份，也就是重要的業務數據要作備份，萬一哪天有損壞，咱們恢復到前一天或者前一段時間點的數據。這是咱們經常使用的平常備份。目前產品能力有手動快照和按期自動快照兩種。
（2）業務恢復
業務恢復指的是，假如你業務受損了，也能夠快速的恢復。還有一種場景就是系統重裝來恢復環境，假如說你的系統作了測試，想恢復到原來的現場，咱們能夠經過系統重裝來完成。 2. 鏡像生產雲服務器 （1）鏡像製做
經過雲盤製做鏡像，就是一次快照的建立。
（2）鏡像生產雲服務器
鏡像製做完成以後，咱們用鏡像去批量部署應用，這樣就可以達到快速的部署業務的目的。
（3）鏡像異地複製
假如咱們的業務須要容災，或者說同一鏡像須要多地域的部署業務，就能夠經過把鏡像從一個地域複製到另一個地域完成，就是鏡像的跨地域複製能力。 

3. 雲盤遷移

 （1）資源均衡
爲了提高用戶的體驗，須要倉庫間資源均衡調度。
（2）架構升級
CBS新架構，不管是產品性能仍是用戶體驗方面，都有很大的提高，須要對雲盤作架構升級，須要把雲盤從老系統遷到新的系統裏。
（3）硬件批次故障
若是出現了批次的硬件故障，須要把倉庫裏的全部的雲盤遷出到正常的倉庫裏面，這依賴雲盤遷移能力。 

4. 面臨的挑戰 

 

（1）數據保護

 

• 無感備份：數據備份要作到無感備份。

• 數據可靠：備份的數據要可靠存儲，不能說備份出去了，當須要恢復的時候發現數據錯誤。

 

（2）鏡像生產雲服務器

 

• 秒級開機：在鏡像生產雲服務器的場景下，爲了提高用戶體驗，須要鏡像生產開機以後可以立馬啓動，而不是要等鏡像數據所有下載完成。

• 高併發能力：咱們經過鏡像批量發放雲服務器的時候，支持用戶上萬的併發能力。

 

（3）雲盤遷移

 

• 業務無感知：不能給用戶業務形成可感知的時延抖動。

• 故障自愈能力:假如遷移的過程當中系統出現故障，或者說軟件層出現Bug，或者雲盤遷移受阻的時候，須要很強的自愈能力，故障對業務無感知。

 

3、CBS數據調度系統關鍵技術

1. COW與ROW

對於數據保護技術，傳統行業經常使用的就是快照。提到快照，不得不說經常使用的兩種快照技術： 

（1）COW技術

寫時複製，就是當建立完快照，再去寫這個同一個地址塊的時候，須要把原來的地址塊中數據先拷貝到新分配的地址塊空間中，再更新源地址塊中數據。

（2）ROW技術
寫訪問時，須要從新定向到另一個地址塊空間上去。

對於COW和ROW的實現機制，首先是寫時複製。如上圖所示，在T1時刻對源卷打下快照，上面藍色部分是源卷的地址塊指針，中間的橙色是磁盤上真正的物理空間——數據塊，這個時候源卷和快照的卷，地址塊指針都指向相同實際的物理空間。 以訪問block4爲例，當打完快照想更新block4的數據的時候，寫時複製的作法就是先重分配一個新block5，把block4的數據先拷貝到block5裏面去，而後再把快照的數據塊邏輯地址指針指向第5個數據塊，用戶io再更新block4數據塊。 通過此次寫過程以後，咱們能夠看到源卷的仍是指原來的這四個物理block地址，快照這邊其實有一個指針映射的過程，從原來的block4轉變到block5。
寫時複製有一個性能問題，就是把block4的數據讀出來，寫到block5裏面去，而後再同時有一次元數據更改，最後是用戶寫入到block4上面去，就是一個用戶寫會放大到「一次讀、三次寫」的過程。 COW技術存在嚴重的寫放大問題，影響寫的性能，它適用的場景是讀密集型。ROW跟COW不同的地方，在於若是用戶打完快照再寫block4空間，會新分配一個block5，用戶數據再寫入block5，修改源卷邏輯地址指針映射。ROW除用戶寫外，只增長一次元數據寫操做。這主要是影響讀性能，適用於寫密集型場景。 ROW和COW它們各有各的應用場景。在分佈式存儲領域，卷的數據是打散在一個存儲集羣的不少塊硬盤或者ssd上；因爲數據打散，讀的性能比單物理盤好不少。另外，存儲系統多會採用cache技術優化讀性能，因此如今分佈式存儲系統快照多采用ROW模式來實現。 

2. 多版本ROW機制

                          數據調度系統，採用多版本ROW機制實現快照技術。什麼是多版本呢？其實就是用版本號去區分快照點數據，建立一次快照，整個卷的版本號會加一。
舉個簡單例子，一個卷假若有四個數據塊，剛開始創卷並寫入數據的時候，T0時刻打一次快照，這個時候咱們要把備份的數據備份到離線存儲器裏，很明顯咱們要把A、B、D三個塊搬遷到離線存儲系統裏去。 假如說這個時候用戶再來寫A塊，由於卷的版本是2，會爲A塊再從新分配新的數據塊A'，A'塊的版本號記錄爲2。寫C塊，由於是第一次寫，以前沒有分配物理塊，那麼此次就分配一個物理塊C版本號記錄爲2。到T2時候再打快照能很明確知道，T0時刻到T2時刻新修改的數據塊，也就是要把A'和C塊搬到離線存儲系統裏。 

3. 快照概述

           
 CBS快照，是快照建立時候的數據的完整備份，採用全量加增量結合的方式備份數據。
全量是T0時刻以前沒有打快照的，這個時候的數據所有備份到離線系統。那麼在T2時刻建立快照只備份從T0時刻到T2時刻的中間修改的那一部分增量數據，這是全量加增量的備份機制。 建立快照，對用戶而言要達到秒級完成。當調度系統收到快照請求，首先到中控層，通知CBS存儲系統卷版本號加一，存儲系統收到請求後，將更新後的卷版本號同步給CBS客戶端。
從CBS客戶端新寫入的數據攜帶新版本號寫入到存儲側，存儲側就爲寫請求分配新版本物理block，達到經過block版本區分快照數據仍是卷數據。 存儲系統響應了以後，就告訴用戶建立快照成功了。這個時候快照數據還在咱們的CBS存儲系統裏，快照數據異步搬遷到離線存儲系統中。
數據調度層按照卷邏輯地址大小，切分紅數據塊大小，再告訴數據傳輸層，一個一個塊從存儲系統讀出來，上傳到咱們的離線存儲系統，這樣就完成了數據的備份。之因此要異構存儲快照數據，主要是基於快照數據可靠性來考量的 

4. 回滾流程

            
假如建立快照後，用戶的雲盤數據出現了損壞，用戶想回退到某個指定快照點。由於是全量加增量，那怎麼知道指定快照點有哪些數據是當前有效的？換句話說，備份完了後怎麼知道這個快照點有哪些是新增數據？哪些是須要依賴於舊快照點的數據？
全量加增量的備份方式，經過快照鏈來標識，快照鏈會做爲元數據持久化；每一個快照點具體備份了卷線性地址空間中的哪些數據塊經過bitmap來標識，bitmap中爲1的bit位表示該邏輯block有數據備份到離線系統中；數據備份完成後，調度系統會把bitmap元數據一塊兒寫入離線存儲系統中。
當咱們選定一個快照點（好比快照點3）進行回滾的時候，看到當前第一個塊A3，對應的bitmap的bit位爲0，表示沒有數據，那就依次向前看依賴的快照點，發現A2是最新的數據，就能夠不往前找了，以A2數據爲準。
看第二個數據塊，自己就有最新數據，那我就以數據塊B3爲準。第三個數據塊沒有，再往前，發現到它的依賴節點也沒有的話，再依次往前發現也沒有，那就是這個數據塊就是沒有數據的。
第四個數據塊，一樣的方式查找依賴的快照點，直到找到D1；最終將A二、B三、D1數據塊搬遷到雲盤裏面去，恢復到了你當時打快照點3時場景。
調度系統經過對指定快照點以及依賴的快照點進行數據合併，而後進行數據回放來回到指定快照點建立時刻的場景，這是一個回滾的流程。 

5. 鏡像生產雲服務器

             對於鏡像，好比在一臺雲服務器上，預裝一些軟件，對雲盤進行快照並製做成鏡像，這個鏡像是預裝環境一個模板，經過這個模板可以批量複製相同軟件環境的雲服務器。
在數據調動系統以前，鏡像是宿主機從鏡像系統下載後寫入CBS雲盤，整個鏡像下載完成後，雲服務器才啓動起來。
這種方式有諸多不足之處。首先，若是鏡像文件很大的話，下載時間很長，影響開機時間；其次，由於宿主機上面還有其餘雲服務器，下載鏡像佔用宿主機帶寬，其它雲服務器會受影響；再次，咱們要維護這樣一個鏡像系統，須要很大的資源開銷。 通過場景分析，能夠用數據調度系統的回滾能力支撐鏡像批量生產雲服務器功能。
首先鏡像製做用快照建立能力就可以完成，而後把鏡像放到咱們的離線系統裏面。若是須要批量發放雲服務器，再經過調度系統從離線的存儲系統，將鏡像文件導入到雲盤上面就能夠訪問。 對這兩種方式作一個對比，從建立時間和資源的佔用，速度的資源佔用和成本方面，經過回滾建立雲服務器具有以下幾大優點： 第一，就是秒級建立，不須要所有下載完成，雲服務器就能夠開機，下文也會介紹其技術細節。 第二，鏡像下載是沒有通過宿主機的，這樣的話對母機的資源沒有額外開銷，不會影響宿主機上其餘雲服務器。
第三，數據調度系統是個現成的系統，沒有增長額外資源、成本的問題。
綜上所述，經過回滾能力生產雲服務器，自然就解決了以前鏡像生產子機存在的痛點。 6. 秒級回滾      怎樣作到開機後立馬可以啓動呢？其實開機後能不能啓動，取決於雲服務器是否正常進行io訪問。
調度系統提供了一個秒級回滾的能力，經過回滾能讓咱們的雲服務器很短期開機啓動。
雲服務器啓動要訪問CBS雲盤上的鏡像數據，但鏡像從離線存儲系統搬遷到雲盤上是逐步完成的，要訪問的數據不必定已經搬遷到雲盤上。
建立雲服務器的時候數據調度系統會啓動從離線系統到雲盤按卷邏輯地址的線性順序搬遷，將卷的邏輯分紅數據塊，一塊一塊地往CBS雲盤上數據搬遷。
好比有一塊雲盤共有7個block，當已經完成了前兩個block的搬遷，但用戶想訪問的是第5個block，此時CBS客戶端會判斷當前尚未完成第5個block的搬遷，就主動通知數據調度系統，把第5個搬遷到CBS盤上去；調度系統收到這樣的請求，會把第5個block優先搬遷到CBS盤上。 搬遷完了以後，通知客戶端，block5已經搬遷完成，客戶端就能夠把訪問block5的io下發給存儲側。 也便是，在正常的用戶io路徑上，增長了一次數據塊從離線存儲系統到在線存儲系統的搬遷過程，只是會增長極短延時，但不會致使啓動慢。 

7. 熱點數據訪問策略

     
經過前文的介紹咱們知道，優先搬遷實際上是當用戶io訪問的數據塊還沒搬遷到CBS雲盤場景下，先將io在客戶端掛住，同時優先將該數據庫從離線系統到在線系統搬遷，而後將用戶io下發的過程。
這裏有一個io在客戶端掛住的動做，而掛住時間長短取決於優先搬遷的整個時延，咱們經過優化優先搬遷時延來減小io抖動。
經過鏡像生產子機這個典型的應用場景來講，鏡像通常會批量發放雲服務器，鏡像數據自己就是一個典型的熱數據訪問問題。
爲了起到提升用戶體驗的做用，也便是爲了優化用戶io在優先中的時延問題，調度系統將鏡像數據做爲熱點數據緩存在傳輸層，作了一層鏡像數據cache，來縮短訪問時延。
第一次去傳輸層加載數據的時候，cache未命中，就從離線存儲系統中加載上來，寫到咱們的CBS系統，同時數據塊緩存到咱們的cache裏面。
第二次加載就能命中，減小訪問離線存儲系統的時延。不管優先搬遷仍是數據搬遷，這層cache對優化用戶時延和減輕底層離線系統的負載是有很大做用的。 

8. 系統水平擴展能力

             爲了支持整個雲服務器的併發生產能力，調度系統針對系統水平擴展能力作了一些優化。如上圖所示，左邊是優化前地域部署的一箇中心繫統，一個數據調度層，另外一個數據傳輸層。
這裏會有兩個問題：第一，中控層覆蓋整個地域，一旦故障，就會影響整個地域的雲服務器的生產。
第二，單個大地域裏分不少的可用區，其實跨可用區的訪問存在時延，並且還挺大的。基於這種考慮，把大的部署模型拆分紅小的部署系統，同時加強系統內部可彈性擴展，系統間提高平行復制的能力。 把大地域部署拆分紅小可用區部署數據調度系統，一方面縮小故障率，另外一方面縮小了跨可用區訪問的一個時延的問題，這對調度系統的彈性能力有很大提高，有利於應對CBS業務的快速增加。 系統支持水平擴展能力以後，怎麼保證在一個小系統內負載均衡？
這裏總結了幾個方面分享給你們。咱們是經過靜態和動態相結合的方式保證整個系統負載均衡。靜態經過心跳上報負載信息，咱們在建立的時候經過卷式作快照，都是基於雲盤而言的，這樣咱們根據雲盤的ID作一次哈希，保證調度層各個節點上卷規模基本一致。
同時，由於每個雲盤的訪問的量包括數據量，負載狀況都不同，調度系統根據負載狀況再進行動態均衡，若是調度層單節點之間負載差超過了設定的預值，調度系統就會啓動動態的再均衡，將高負載節點上的任務調度到低負載節點上，達到各個調度節點之間的負載儘可能保持均衡。 再就是傳輸層，用了哈希的策略，保證各個傳輸節點均衡。由於傳輸節點就是看到數據塊的搬遷，它只要保證數據塊的搬遷是均勻的，那就能夠了。 但其實哈希也有少許的不均衡狀況，同一個鏡像數據塊訪問會落到同一個傳輸結點上，批量發放雲服務器時，會出現同一時刻訪問同一個數據塊形成傳輸層局部熱點問題，調度系統經過冗餘幾個副原本解決局部熱點訪問問題。

9. 任務平滑切換

            
假如說調度節點出現了故障，任務在調度層節點間怎麼作平滑切換呢？
首先對於節點故障的探測，這裏採用的是心跳探測、業務失敗率統計以及外圍監控探測相結合完成調度層節點的故障探測。
一旦發現調度層節點故障，上報給中控層，中控節點就啓動任務從故障節點切換到另外一個正常節點。
若是是備份任務，用戶對時延不感知，切換速度要求不高；但回滾時，數據訪問的優先搬遷須要調度層節點介入，若是不能及時將任務切換到正常的調度節點上，將會致使io卡住，體驗不好。
爲了解決這個問題，CBS客戶端訪問故障節點失敗後，輪詢下一個調度節點，從下一個調度節點獲取當前任務服務的調度節點地址信息，並快速切換，達到快速恢復io的目的。
任務的元數據是共享的，調度節點均可以訪問到；目的調度節點會根據惟一的任務key再把原數據加載出來。以上是任務平滑切換的基本機制。 

10. 鏡像跨地域複製技術

 
除了鏡像生產，還有鏡像的跨地域複製。首先，須要兩套數據調度系統支持，經過兩個地域的調度系統中控層，完成鏡像元數據的傳輸。
A地域調度層和傳輸層負責從A地域把數據塊讀出來寫到B地域來，完成搬遷後，A地域的中控層通知B地域中控層已經完成了數據的搬遷，B地域中控層通知調度層去完成源和目的數據一致性校驗，保證數據可靠傳出。 那爲何A地域的系統不能既負責傳輸又負責校驗呢？這至關於一我的既是裁判又是運動員，容易出問題發現不了。基於數據安全考慮，傳輸和校驗分開進行。 

11. 雲盤無感遷移

                雲盤遷移，是將雲盤從一個存儲倉庫遷移到另外一個存儲倉庫，業務無感知。遷移最核心的兩個點：數據可靠性和業務無感知。
數據可靠性將在下文展開論述，這裏重點介紹如何作到業務無感知遷移。
要作到業務無感知，關鍵在於遷移過程當中用戶io時延不會有明顯增長，爲了達到這個目的，數據調度系統引入一個IO接入層，把用戶的IO和調度系統底層的順序搬遷IO隔離開，作到用戶IO與順序搬遷IO隔離，減小IO抖動。 雲盤遷移過程當中，用戶IO如何訪問雲盤數據呢？
接入層作按搬遷數據塊大小將卷劃分紅block列表，同時維護每個block狀態。block有三個核心狀態，狀態之間會流轉。若是是讀請求，就統一讀源倉庫；若是是寫請求，則根據訪問block當前狀態，按下面規則來處理。

• 第一個是未搬遷狀態，用戶IO訪問的話，IO寫到源倉庫。

• 第二個狀態是正在搬遷中，接入層會暫時把IO掛住，等調度層把數據搬遷完，掛住的IO再放下去，寫到原倉庫和目的倉庫。IO掛住的機率極低，運營統計不到十萬分之一。

• 第三個狀態是已搬遷，同時寫源端和目的端。

爲何訪問已搬遷狀態的block，IO要同時寫源端和目的端呢？這裏是爲了提高系統可用性，假如說底層出現了任何故障，CBS客戶端只須要將IO鏈路上斷開，基於iscsi斷鏈重連會自動切回原倉庫中去，由於源倉庫數據是完整的，IO的自愈能力就比較高了。 遷移完了以後，把客戶端的IO路徑切到目的倉庫。這個時候的IO路徑，也是基於iscsi的I端到T端的斷鏈重連的過程。經過引入接入層，整個IO路徑，時延上只是增長了一段網絡開銷，時延抖動很是低，目前雲盤在線遷移，業務感知不到。 雲盤遷移裏的功能點很是豐富，還有一套輔助的系統——雲盤遷移決策系統，它能根據當前倉庫的負載狀況，各個盤的歷史訪問狀況，作一系列的預測，而後來發掘倉庫是否有容量、流量風險，提早決策，選擇一批合適的雲盤，選擇最優的目的倉庫，發起遷移，提早解除資源風險，這也是爲CBS業務增加在運營上作的一些建設。 

12. 數據可靠性

           
以上三個場景，面臨一個共同的挑戰就是數據可靠性。
在快照製做鏡像場景，從在線存儲裏面把數據讀出來，寫入到咱們離線存儲裏面，調度系統的數據塊會增長MD5校驗頭部一塊兒寫入離線存儲系統中；回滾的時候，調度系統從離線系統讀出來再計算一次MD5，檢查數據是否有損壞。
元數據除了MD5校驗外，還會跨地域備份，加強數據可靠性，同時增強跨地域巡檢。 
咱們在IO路徑上常遇到懸空IO的一些問題，好比說鏈路切換的時候有一些IO還沒落盤，卡到路上，殘留的IO會把新寫的數據覆蓋的問題。
這種問題在雲盤遷移過程當中表現尤其明顯，由於雲盤遷移涉及兩次io鏈路切換：從原倉庫切到接入層、從接入層切到目的倉庫，其實這些鏈路切換過程都會有IO的殘留問題。那麼調度系統如何解決這個問題呢？
關鍵是引入版本號機制，低版本數據不能覆蓋高版本數據。每一條鏈路上版本號不同，咱們在底層存儲上作了一些保證，設定了高版本數據能夠覆蓋低版本數據，但低版本數據不能覆蓋高版本數據。
調度系統爲每一條鏈路指定一個新版本，版本號隨切換順序遞增，這樣低版本數據即便有殘留，也不會覆蓋新鏈路上的數據，由於新鏈路上的數據版本號高。

4、將來演進方向

當前主要是服務於塊存儲的場景，接下來會在支持塊、文件、DB三個場景下數據調度的一些需求上發力，讓調度系統能適配更多業務場景。
第二是性能上面，須要支持超低時延雲盤的在線遷移。
第三是數據安全，數據安全是咱們的核心能力，咱們的快照能力如今支持的RPO窗口是比較大的，後續咱們還要支持秒級RPO能力，知足客戶更細粒度的數據保護需求。
最後就是運營方面的一些建設，也就是前文提到的智能調度，整個雲盤的遷移須要智能化，經過AI訓練動態實時發現潛在資源風險，這樣就可以作到整個存儲層池化資源的均衡。

6、Q&A

Q：首次全量打快照時，空塊也要搬遷麼？ A： 空塊在打快照的時候是不須要搬遷的。   Q：如今仍是按地域部署？ A： 咱們的部署模型，這塊是不斷優化演進的過程，以前是按大地域來部署，運營出現過一些問題，如今按小地域部署。後續會更增強化小地域和一個邏輯管理單元，一個邏輯調度的能力的複製。當超過最大能力時候，咱們再去擴展調度能力。   Q：遷移的速度是如何保證的？ A： 速度這塊是個動態控制的過程，最先是靜態，如今慢慢演變成動態，由於存儲倉庫負載是一個動態的過程，動態探測當前的空餘帶寬，去充分利用倉庫空餘帶寬，提高數據搬遷的速度。   Q：大數據寫入的時候雲盤的在線遷移有限制嗎？ A： 這塊是有限制的。當前有帶寬瓶頸，由於接入層雙寫源和目的；但咱們如今正在開發一個新能力，就把雲盤上的帶寬打散到接入集羣上去，突破單點的瓶頸，支持更高帶寬雲盤遷移。      Q：雲硬盤如何選型？ A： 咱們提供了多種的雲硬盤的選型，這塊能夠參照咱們的在線產品介紹，根據不一樣的產品能力規格，來選擇你的雲盤。   Q：系統可不能夠跟ZK交互？ A： ZK系統就是提供中控層選主服務，並不參與到調動的過程。   Q：若是寫入太快，打快照速度可能追不上寫入速度嗎？ A： 這塊是兩個概念，一旦建立完快照，快照數據是靜態的數據，用戶先寫的數據，是新的數據塊，兩者沒什麼關係，調度系統完成快照數據順序搬遷，不影響用戶寫入。   Q：快照刪除後，老的版本數據如何回收？ A： 備份完數據後，有一個數據的回收過程。由於已經完成備份的數據保留在在線系統裏面，在線存儲系統的block使用率，隨着打快照會慢慢的增加，存在資源風險。這些舊版本的也就是快照版本的數據會回收掉。若是高版本的數據對低版本數據有依賴，好比說新版本的數據塊只寫了前4KB，低版本的數據寫了尾巴4KB，這個時候舊版本的數據回收的時候，是要把舊版本尾巴上的這4K合併到新版本里去，才能把舊的版本數據塊回收掉，這是回收的基本原理。
Q：數據塊 劃分大小 是多大? A： 此處講到數據塊的大小，只是說了設計的原理，沒有具體說數據塊大小，這個數據塊大小可能根據咱們是按1MB來切分的，關於數據塊大小劃分各個廠商可能不同。   Q：若是快照取消了會有殘留數據麼在COS裏? A： 若是你正在打快照過程當中，而後你取消了，咱們會把前面的在離線系統裏刪除掉，因此它不會殘留的。   Q：跨區域的鏡像搬遷，對網絡有額外要求麼？ A： 網絡其實咱們目前是沒有什麼要求，在訪問網絡帶寬的時候會作留空，會作資源限制，由於咱們的數據啓動系統和離線，都是在公司內網。   Q：咱們如今整個數據調度系統是否是沒有主備的概念？ A： 咱們在中控節點是有主備的概念。而後咱們的調度集羣和傳輸集羣都是無狀態的，也就是沒有主備的概念。