導語 | CBS云硬盤為騰訊云客戶提供了?可靠、?可?和低成本的統?塊存儲服務。CBS針對數據安全、云服務器?產、資源均衡、云盤介質升級等場景下的數據調度能?需求，抽象出統?數據調度平臺。本文是對騰訊云存儲專家工程師——楊光超在云+社區online的分享整理，希望與大家一同交流。

點擊查看完整直播回放

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

? ? ? ? ? ?

CBS存儲系統，主要為騰訊云的CVM提供高性能、高可靠、低成本的塊存儲服務。

CBS數據調度系統，是基于存儲系統構建的統一的數據調度服務。為什么要構建統一的數據調度呢？

在2015年時它僅僅作為快照系統存在，僅是保存在云上的數據，目的是為了提高整個數據的安全性。用戶會對數據進行備份，如果這個時候數據丟失，可以利用快照對其恢復。

上云業務尚未規模化，快照系統的業務量不大，而且快照備份本身是離線業務，所以針對IO時延時延方面并不敏感。

但隨著業務上云越來越多，云盤的規模也越來越大。利用回滾的能力，來做鏡像生產云服務器，數據調度系統拓展了新的應用場景，同時，系統回滾能力也要求越來越高，時延方面也逐漸敏感。

隨著CBS業務不斷快速增長和架構不斷演進，催生出另一個全新數據調度場景——云盤的在線遷移。

云盤在線遷移是什么意思？某些場景下需要將云盤從一個存儲倉庫遷移到另外一個存儲倉庫，而且是在線遷移，對用戶的業務是無損的。

它有一個特點是對時延的抖動敏感，用戶的業務已經運行了，對整個時延抖動的要求是極低的。

我們把前文所述的數據能力抽象出一個統一數據調度平臺，負責我們離線的數據和在線的數據打通。它當前涵蓋主要三個場景：數據保護、云服務器批量生產和云盤在線遷移。下文將圍繞這三個場景一一展開。

首先介紹整個數據調度系統的三層架構，第一層是業務中控層，中控是高可用服務，負責接受前端的業務請求，不管是打快照還是做回滾，以及云盤遷移，都會到我們的中控層，再轉發任務給數據調度層。

數據調度層是集群模式，會把調度任務按照邏輯地址劃為大小相同的數據塊，并把塊信息給到傳輸層，那么傳輸層看到的就是一個個的數據塊，數據調度層會告訴傳輸層節點這個數據塊源端在哪里，目的在哪里，再由傳輸層節點完成了數據的搬遷功能。

數據調度系統，為CBS構筑離線存儲系統和在線存儲系統、在線存儲系統之間數據流動能力。

===

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

?? ? ? ? ? ?

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

1. 數據保護

（1）數據保護

用在我們的日常備份，也就是重要的業務數據要做備份，萬一哪天有損壞，我們恢復到前一天或者前一段時間點的數據。這是我們常用的日常備份。目前產品能力有手動快照和定期自動快照兩種。

（2）業務恢復

業務恢復指的是，假如你業務受損了，也可以快速的恢復。還有一種場景就是系統重裝來恢復環境，假如說你的系統做了測試，想恢復到原來的現場，我們可以通過系統重裝來完成。

2. 鏡像生產云服務器

（1）鏡像制作

通過云盤制作鏡像，就是一次快照的創建。

（2）鏡像生產云服務器

鏡像制作完成之后，我們用鏡像去批量部署應用，這樣就能夠達到快速的部署業務的目的。

（3）鏡像異地復制

假如我們的業務需要容災，或者說同一鏡像需要多地域的部署業務，就可以通過把鏡像從一個地域復制到另外一個地域完成，就是鏡像的跨地域復制能力。

3. 云盤遷移

（1）資源均衡

為了提升用戶的體驗，需要倉庫間資源均衡調度。

（2）架構升級

CBS新架構，無論是產品性能還是用戶體驗方面，都有很大的提升，需要對云盤做架構升級，需要把云盤從老系統遷到新的系統里。

（3）硬件批次故障

如果出現了批次的硬件故障，需要把倉庫里的所有的云盤遷出到正常的倉庫里面，這依賴云盤遷移能力。

---

4. 面臨的挑戰

（1）數據保護

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

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

（2）鏡像生產云服務器

• 秒級開機：在鏡像生產云服務器的場景下，為了提升用戶體驗，需要鏡像生產開機之后能夠立馬啟動，而不是要等鏡像數據全部下載完成。

• 高并發能力：我們通過鏡像批量發放云服務器的時候，支持用戶上萬的并發能力。

（3）云盤遷移

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

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

三、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；最終將A2、B3、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的殘留問題。那么調度系統如何解決這個問題呢？

關鍵是引入版本號機制，低版本數據不能覆蓋高版本數據。每一條鏈路上版本號不一樣，我們在底層存儲上做了一些保證，設定了高版本數據可以覆蓋低版本數據，但低版本數據不能覆蓋高版本數據。

調度系統為每一條鏈路指定一個新版本，版本號隨切換順序遞增，這樣低版本數據即使有殘留，也不會覆蓋新鏈路上的數據，因為新鏈路上的數據版本號高。

===

四、未來演進方向

當前主要是服務于塊存儲的場景，接下來會在支持塊、文件、DB三個場景下數據調度的一些需求上發力，讓調度系統能適配更多業務場景。

第二是性能上面，需要支持超低時延云盤的在線遷移。

第三是數據安全，數據安全是我們的核心能力，我們的快照能力現在支持的RPO窗口是比較大的，后續我們還要支持秒級RPO能力，滿足客戶更細粒度的數據保護需求。

最后就是運營方面的一些建設，也就是前文提到的智能調度，整個云盤的遷移需要智能化，通過AI訓練動態實時發現潛在資源風險，這樣就能夠做到整個存儲層池化資源的均衡。

六、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：我們在中控節點是有主備的概念。然后我們的調度集群和傳輸集群都是無狀態的，也就是沒有主備的概念。

講師簡介

楊光超

騰訊云存儲專家工程師

騰訊云硬盤CBS數據調度技術負責人，2015年加入騰訊，持續專注于塊存儲領域相關技術，在騰訊云硬盤團隊先后參與了CBS三代存儲系統的研發工作，致力于打造一個為用戶提供穩定可靠、低延遲、可擴展的海量存儲服務系統。

沙龍預告

今晚20:00，騰訊看點獨立端推薦研發中心總監——彭默將出席云加社區沙龍直播間，分享騰訊看點信息流推薦系統的架構演進，掃描海報二維碼或者點擊文末「閱讀原文」，即可預約觀看今晚直播~

總結

以上是生活随笔為你收集整理的秒启万台主机，腾讯云云硬盘数据调度架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。