百微秒時延，騰訊云云硬盤CBS架構深度解密

1、CBS架構演進

1. CBS雲硬盤

什麼是雲硬盤呢？騰訊雲的雲硬盤叫 CBS，CBS 就是 Cloud Block Storage，基於雲的分佈式塊存儲服務。
雲的概念聽起來很玄乎，其實我理解的雲的核心技術就是分佈式，雲是分佈式的一個商業包裝，經過雲這個接口把它推出去，給你們提供就像水、電同樣的基礎服務，這是我給雲的定義。 雲裏邊最核心的是分佈式技術，雲硬盤也是基於分佈式去實現的一個硬盤，跟電腦裏面的硬盤功能相同，可是又比我的電腦裏的硬盤有更豐富的能力。
好比基於分佈式實現，性能上就使得橫向拓展的能力很是好。我的電腦硬盤只能提供幾百兆的吞吐能力，CBS 基於雲的硬盤能夠提供更大的存儲性能，咱們如今能夠作到5GB，這是本地傳統物理硬盤很難作到的。 在可靠性方面，CBS 是基於多副本的存儲策略，也就是說原則上會將用戶數據存多份，通常是三份，這樣的策略讓數據的可靠性更強。 另外是可用性方面。傳統的物理硬盤壞了，上面的數據就丟了，也就影響到了用戶的服務。可是雲硬盤不同，它是基於分佈式實現的，當這一塊硬盤故障的時候能夠快速進行隔離，由於是多副本存儲數據的，另外的副本就能夠及時的提供服務，不影響用戶的可用性。 當前雲硬盤服務主要的對象是你們在騰訊雲上買的雲主機，是給雲主機提供持久化的塊存儲服務的。 以上這些就是我給 CBS 雲硬盤下的定義，首先它是基於分佈式技術實現的，就像我的電腦硬盤同樣，硬盤能夠提供的全部能力它均可以提供，而且在高性能、可靠性和可用性進行了加強，提供持久化的塊存儲服務。 

2. CBS架構演進

CBS 的演進通過了三代架構 —— CBS apllo、CBS atlas 和 HiSTOR。塊存儲最先是從 2011 年開始作的，當時不叫 CBS，而是叫 TBS。最先的一代架構是基於之前騰訊雲架構平臺部已有的存儲平臺打造了塊存儲的服務。但這個已有的存儲平臺一開始並非爲塊這個場景專門設計的，因此存在不少問題。 2013 年、2014 年是雲發展比較快的階段，當 2014 年規模到了幾個 PB 的時候，發現當時的架構不能承載用戶的需求，因此在 2014 年時用 CBS apllo 及時替代了更老的一代架構，適應了雲快速發展的需求，快速的把塊存儲的規模從幾 PB 增長到了上百 PB，我的認爲這是很是優秀的一代架構。 可是到 2016 年，雖然之前的架構很優秀，可是成本方面會略高一些、性能上也不盡如意，因此在2016年但願可以在成本和性能方面有所改進，性能這也是本期我要講的主題。
在 2016 年咱們設計了新一代 CBS 架構 Atlas，2017 年 Atlas 正式上線接用戶業務。 目前在騰訊雲上跑的主流的架構是 CBS atlas，承載着數 EB 的數據規模。如今不少用戶把數據放在雲上，騰訊雲上也已經衍生了幾十億、上百億、甚至上千億美金的獨角獸公司出來，他們就是依賴於雲去支撐他們的服務。 在如今這個階段，就要全場景的看用戶的需求，最主要的一塊就是對性能的要求慢慢成爲了矛盾的焦點。原先預計雲盤很快便會取代本地盤，但在去年的時候發現取代的節奏在變緩，分析以後發現用戶仍用本地盤是由於雲盤某些場景沒有服務好，典型的是關於 DB 的需求。 雲盤是基於分佈式的，中間經過網絡互聯，天生比本地盤的延時略高，可是到底高多少呢？若是高的程度可以在提供的優點能夠覆蓋住的狀況下，用戶就會願意用 CBS 盤，但若是影響大於優點，那麼用戶就不接受了。
這時候這個矛盾就凸顯出來了，要解決用戶在性能上的需求，這時候「極速存儲」就應運而生，它在性能上有了很大的提高。到今年上半年的時候平臺側就達到了咱們認爲可以知足用戶需求的能力，今年 8 月產品層面推出相關產品。
以上就是我參與的三代架構以及前面沒有參與那代架構演進的歷程。我列了三個時間點，其中2014年是很是重要的時間點，雲快速發展推出 applo 架構，2017 年推出 atlas 架構，到去年爲了解決用戶全面上雲對性能的要求，咱們投入精力搞了 HiSTOR 的架構。 

3. CBS存儲系統

CBS 存儲系統架構究竟是怎麼樣的呢？最新的架構能夠分紅三塊： 

• 客戶端

• 存儲集羣

• 控制集羣

 先介紹一下存儲集羣，存儲系統很重要的一塊就是存儲集羣，這是後端的存儲給用戶提供存儲服務；另外給用戶提供服務確定要有個接入點，也就是前面的客戶端；分佈式系統要有對集羣作控制的模塊，也就是控制集羣，固然控制模塊自己也是多機的分佈式系統；CBS存儲系統能夠分爲這三塊。 今天要講的是塊存儲，其實如今 CBS 存儲系統已經被打形成了統一的存儲平臺，如今騰訊雲上購買的雲文件也是這一套存儲系統提供的服務，另外雲原生的數據庫，後端的存儲系統也是它。 CBS 的存儲系統 HiSTOR 的特色首先是極簡的架構。多年前我也對外分享過一個「大道至簡」的設計理念，用極簡的架構知足用戶的需求是最好的。
整個集羣分爲三部分，客戶端直接訪問存儲，中間沒有傳統的存儲系統的接入模塊，因此是一種極簡的架構。 另外一個特色是統一存儲。咱們提供的不只是塊存儲服務，而是多種存儲類型服務共享的一個平臺。CBS 存儲系統爲何一直向前演進呢？由於要解決問題。
Atlas 取代 Applo 核心的目的是什麼？首先是成本，由於架構層面足夠的簡單，只有兩層，沒有中間的接入集羣、接入設備和其餘的管理設備是沒有的，因此在成本上是大大的下降了。 這套架構比以前的架構在成本上有優點，物理成本上節約了 50% 左右，但產品怎麼可以讓用戶去買單呢？要讓用戶有買單的意願就要作到成本足夠低，成本問題是幾年前解決用戶上雲的需求的主要矛盾。
慢慢的在用戶上雲了之後，包括核心的業務開始往雲上切，騰訊雲上已經孕育出了不少十億、上百億、上千億美金的獨角獸公司，這個時候如何讓用戶放心把業務放到雲上呢？必定要讓其用得放心，質量必定要過關，解決成本問題後咱們投入大量的精力在質量上。 質量要過關，可靠性、可用性和數據安全方面必定要過關。 

2、CBS新的挑戰

如今不少公司已經把它的所有業務都放到雲上，這時候就須要把他服務好，讓他用得爽。雲盤相對本地盤主要的劣勢就是延時相對本地盤比較高，因此今天要講的主題是怎麼在這一點上有所突破。               性能方面有三個維度，除了一再強調的延時維度，還有吞吐維度和 IOPS 的維度。  

1. 吞吐維度

 吞吐維度指的是帶寬。如今不少大數據場景、AI 訓練的場景對帶寬的需求很是大，SSD 雲盤提供的 260 兆的帶寬，跟用戶需求是有落差的，因此除了在延時上須要作到極致之外，帶寬方面也要知足用戶的需求。 

2. IOPS

之前都是本地盤間的比較，你們以爲 IOPS 不是個矛盾點，本地物理硬盤隨機訪問的IOPS 也就是在 200、300 的級別。而云盤產生以後，最老的一代產品可以提供的是幾千的IOPS。
當時是能夠知足需求，但慢慢的上雲的場景愈來愈多後，雲主機的母機上單個服務對 IOPS 的需求不高，可是加在一塊兒需求就變得很大。 

3. 延時維度

延時維度最典型的是 DB 的業務。可能多年前放在雲硬盤上的數據價值並不高，可是 DB 數據價值密度很是高，如何把 DB 應用場景服務好也是須要花很大的精力思考的問題。  

3、CBS低延時結構優化

1. CBS延時優化

那麼 CBS 延時如何優化呢？不少人提出過不少具體手段，可是總結起來就是兩個方面，一是怎麼把併發作上去，二是怎麼把延時作下來。 把併發作上去，這是分佈式存儲自然有的優點，只是技術實現上的難度大小而已，但跟延時比起來並非這麼困難。
低延時無非是兩種手段，首先用更快的硬件去解決，另外是怎麼把軟件 IO 棧作到儘可能的扁平化，本期的主要是基於軟件的維度考慮延時優化，具體是從 CBS 的四個維度入手：分佈式層面優化、接入端、存儲側和中間交互的網絡的優化方面。 

2. 分佈式架構

CBS 存儲系統是極簡的架構，客戶端訪問存儲中間就是網絡，涉及優化的也就是三個層面加一個架構，咱們按這幾點來進行分解。 首先從架構層面，CBS altas 直接從客戶端訪問存儲，是兩層分佈式架構，沒有傳統的接入點也就沒有了接入瓶頸。另外是客戶端直接訪問存儲中間訪問路徑能夠作到最短，這就是當前架構的優點。 提及來很簡單，但作成兩層架構實現起來技術難度很大。首先是路由管理上如何作？CBS 的存儲系統用的路由方式是一致性哈希，這就涉及到哈希路由如何推送到客戶端。
自己路由的變動是由控制集羣維護的，路由更新後若是直接推送客戶端的話看起來很簡單，但面對雲上的集羣規模就會發現問題。騰訊目前是上百萬臺的規模，若是把一個信息推送到上百萬個節點根本是不可行的事情。
因此在實現上咱們想個了方式叫「惰性路由同步」，集羣管理節點變動後不是直接推送客戶端而是推送到存儲節點，再由節點中轉到客戶端。 爲何這樣可行呢？接入節點上百萬臺，可是存儲節點比客戶端節點是數量少得多，推送到存儲節點對中心控制節點的負載是能夠容忍的，因此先推送到存儲節點，以後對中控系統來講工做就完成了，推送也就完成了。 惰性路由同步的惰性體如今哪裏？起名字的時候咱們借鑑了內核內存分配的方式，內核去申請內存的時候只是一個虛擬的，並無把真實物理內存分配給你。 分佈式架構里路由同步的策略也是相似的，先推送以後並不急於推送到客戶端節點，若是有需求訪問存儲的時候，再同步把路由推送到客戶端節點。這時候拿到最新的路由就能夠訪問到須要的數據了，使用的時候再去推送的策略即是「惰性路由同步」。 架構層面，原先的架構雖說是兩層，但由於是多副本存儲，數據到了存儲節點後還有一次複製的過程，須要再複製成多份數據存到節點上去，這時候雖然架構上是極簡的，但寫的時候有兩次的路由，就至關於數據走了兩跳。 爲了作到延時上的極簡，咱們是根據 IO 大小作了不一樣的策略，若是是小 IO 的話，走的是之前的模式，直接客戶端出三份，這樣對小 IO 便只須要一跳。
但爲何大 IO 不這麼作呢？客戶端出流量的話，出三份實際上是佔用計算的網絡流量的，因此這樣是須要跟前端計算的同事協商的。但小的 IO 這麼作，不須要增長前端的計算帶寬，這就是爲何大小 IO 須要作不一樣策略的緣由。  

3. CBS接入端

上圖所示的客戶端架構是一個主流的架構，接入方式是基於 iSCSI 的通用塊設備接入，虛擬機經過訪問存儲的時候是 QEMU 訪問一個主機上的塊設備，往下走 SCSI 設備。
SCSI 的底層就是 iSCSI initiator，經過網絡訪問 CBS 的客戶端，而後再訪問後端存儲。路徑很是的長，首先要複製數據、切換訪問內核，以後經過 iSCSI ，再經過網絡訪問 CBS 的客戶端，客戶端再經過網絡把數據發出來，中間通過了多少次的上下文切換和數據拷貝，因此延時上很是不友好。 有沒有其餘的接入方式呢？第一次想這個問題的時候是在 2016 年，咱們在設計架構時，當時想直接用共享內存的方式把數據旁路出來，就不用通過這麼屢次的來來回回的切換了。
後來老闆們說你爲何這麼作呢，英特爾搞了一個更好的東西，就是能夠直接在虛擬機上把數據旁路出來，也就是 SPDK。IO 設備是虛擬機的話，SPDK 能夠作 IO 的後端，直接把數據同步出來，再把客戶端作到 SPDK 裏面，這個數據路徑是要短很是多。 虛擬機裏面直接用數據共享的方式跟 SPDK 交互數據，SPDK 在後端訪問存儲，再通過網絡處理，比起剛纔說的來來回回好幾回要簡單得多了。 可是不是這樣就作到極致了呢？最初作的方式是 SPDK 跟客戶端的訪問沒有在一個線程裏面，而是兩個線程，之間經過共享內存。
但這樣對延時並不友好，由於通過了線程的一次切換，哪怕只是幾個微秒的區別，但在一個超高性能場景中幾微秒也是比較多的。因此咱們又作了優化，把客戶端跟 SPDK 放在同一個線程裏作，這樣就沒有線程上下文的切換了。 總結下來，是用 SPDK 的接入方式取代了 iSCSI 的接入方式，用零拷貝的輪詢方式取代了原來兩線程數據共享的方式。最後是有一個水平擴展的能力，這跟延時無關。 剛纔提到老闆們站的高度更高，在 2016 年便提出了用 SPDK，那 SPDK 究竟是什麼呢？
這是一個英特爾用來作高性能存儲的開發套件，提供一些 lib 庫之類的工具，經過它作高性能存儲的應用開發。具體技術實現首先是在用戶態實現的，能夠減小對內核的切換，用戶態、內核間的上下文切換對 CPU 消耗也比較高，另外就是輪詢，說白了就是 CPU 的死轉。SPDK 主要就是這些方面的技術。 

4. CBS存儲引擎 

2016 年在作架構的時候，首先開發了一個高性能的開發框架叫 CEDA。這是基於封裝的事件驅動的框架，核心理念是基於微服務模型，是事件驅動的、事件觸發的高性能的開發框架，存儲引擎是基於 CEDA 框架實現的。 膠片裏面有個 DATA POOl，也就是數據池，IO 過來以後從數據池中分配數據存儲的內存，整個生命週期數據不作拷貝，因此能夠作到數據零拷貝。
核心路徑上跟其餘的 SPDK 理念同樣，不是用事件驅動的方式，而是用輪訓方式，雖然對 CPU 消耗高了，但沒有線程的喚醒和休眠，能夠作到相對比較好的水平。
存儲引擎訪問硬盤，如今用的也是 SPDK 方式，能夠儘可能的減小訪問硬盤時在用戶端內核進行切換的時間消耗。 但這個過程仍然有一次切換，說白了仍是沒有達到極致，用戶態的任務調度可讓一個 IO 的處理從進存儲引擎到最後落地訪問存儲硬件整個在一個上下文裏面作，沒有切換的開銷，這樣就能夠把延時作到極致。 

5. CBS (極速型雲盤) 網絡

架構、客戶端、存儲引擎、中間是網絡，咱們之因此把網絡放到最後，並非說它不重要。軟件作到這樣是至關不錯的，但它的延時和網絡比起來仍是小巫見大巫，一次跳轉的話大幾十個 us。 那麼如何在網絡上作優化呢？騰訊有兩款產品，CBS 極速型雲盤和加強型雲盤，極速雲盤是網絡層面用的 RDMA，遠程直接內存訪問，說得簡單一些就是一個硬件卸載的理念，把網絡的協議的處理儘可能放在硬件裏面作，這樣能夠旁路掉操做系統內核的工做。
在硬件和用戶態的應用之間直接共享數據，也就是全棧都沒有了內存的拷貝，也不須要內核和用戶態作協議的解析處理，這些硬件就幫你作了。經過這種操做這樣能夠把延時降到極至，用的是旁路內核減小切換的理念。 那咱們作得跟別人作的有什麼不一樣呢？總結起來，咱們作的比較好的幾點，雖然是  RDMA 網絡，但咱們並不單純是 RDMA，而是 RDMA 和 TCP 並存，在故障的時候能夠快速自動切換。
另外一方面擁塞控制，騰訊雲的量級是百萬級別的服務器規模，放眼全球 RDMA 的使用超過一萬臺機器規模的都不多，RDMA 集羣應用規模通常並不大，RDMA 的擁塞控制是比較大的隱患，或者說是如今存在的主要問題之一。
CBS 的 RDMA 擁塞控制層面如何作的呢？除了硬件提供的擁塞控制能力，應用層也作了控制，好比存儲和客戶端的交互用的 RDMA_read 方式。 RDMA 有幾種交互方式，一種是 send/recv 方式，一種是 read/write 的交互方式，簡單而言，前一種模式交互流程是短的、少的，可是切入應用以後會有一次數據的拷貝，由於要有交互協議處理的 buff 和應用之間的 buff 拷貝，對大 IO 來講並不友好。 另外一種方式 RDMA_read，最主要的好處是沒有了剛纔說的拷貝過程，因此對大 IO 比較友好，可是交互流程比前面說的方式要多幾跳，這樣對小 IO 並不友好。 因此從交互協議層面來講，用了這兩種相結合的方式。當須要帶寬的時候用的是 read 方式，當須要短的延時時候用的是 send/recv 方式。 用 read 方式作擁塞控制，存儲側來看，好比須要去寫個數據到存儲的時候，先跟存儲握手一次，告訴他我要寫了，這時候存儲向客戶端發一個 read 指令，控制權徹底在存儲。
由於整個集羣模型是很是多的客戶端訪問少許的存儲，存儲自己是容易發生擁塞的點，存儲端主動的發起數據的讀寫請求的話，能夠根據本身的負載去作擁塞控制，這是基於應用的擁塞控制的可行性，以上是 CBS 在 RDMA 網絡方面作得相對比較有特點的幾個方面。 

6. CBS（加強型雲盤）網絡

 

極速雲盤用的是 RDMA 網絡，加強型雲盤用的是 TCP 網絡，TCP 網絡是延時消耗的大頭，內核協議處理佔了整個網絡延時的百分之八九十，若是仍是用 TCP 網絡的話就看如何解決掉內核佔消耗比較高的問題就能夠了。
內核 TCP 方式是內核消耗高，由於上下文切換很頻繁，解決這個矛盾放到用戶態來看，就是協議處理放到用戶態，沒有上下文切換。騰訊作的 ZTCP 用戶態協議棧同時也能夠零拷貝，用戶協議也作了用戶態零拷貝以求性能的極至，這是加強型雲盤的網絡協議的優化。 

7. CBS網絡模型對比

CBS 網絡模型的交互方式有三種： 

• 傳統的內核 TCP 協議棧交互；

• 極速雲盤用的 RDMA 網絡交互；

• 加強型雲盤用的用戶態 TCP 協議棧交互。

 咱們對三者進行一個對比。內核態 TCP 把 TCP 解析放到內核，主要問題是頻繁的上下文的切換、太多的數據拷貝，這是它的問題。
用戶態協議棧是減小數據拷貝和上下文的切換，騰訊作 ZTCP 的特色是同時支持零拷貝，RDMA 是不須要軟件作而是硬件來幫助作，協議棧卸載到硬件裏面以求作到旁路掉內核、數據零拷貝，達到這個技術的要求，同而將延時降到最低，這是三種網絡交互形式的對比。 

4、CBS延時優化成果

1. CBS延時能力

咱們的 CBS 延時優化到底作到了什麼水平呢？上圖是產品化的時候開發同窗測的數據，可以作到的是 140 us 左右，百微秒級別，這還不是最新的數據，如今能夠作到100 us 到 120 us 之間。 當前給到產品化的能力就是 100 us 到 150 us，研發側能夠作 100 us 到 120 us 之間。接下來要作到什麼程度呢？給產品的目標是但願年末可以作到 50 us 到 100 us 這樣的水平。 

2. 產品化

 產品化層面，8 月 13 日的時候產品側推出了一個叫加強型 SSD 雲硬盤的產品，這已是正式的產品化了，能夠在騰訊雲官網買到，如今極速型 SSD 雲硬盤也已經開始公測了。              
以上就是我和你們分享的CBS在架構演進及基於當前最新的架構打造的百微秒級別的極速雲盤產品的狀況，謝謝觀看。

5、Q&A

Q：支持幾PB到上百PB的瓶頸是什麼呢？ A： 從成本層面來看，就是在合理成本的狀況提供讓客戶接受的產品。從質量層面看，就是怎麼可以提供用戶能夠接受的可靠性和可用性的一個產品。我認爲主要的瓶頸就是成本和質量，這個作大規模主要的兩個瓶頸點。
Q：一致性哈希未來遷移時怎麼避免數據遷移？   A： 數據遷移不能避免，但能夠考慮如何減小。在實現上有一些儘可能減小數據遷移的方式，好比去作路由分裂的時候，最粗暴的方式是把一個哈希分區的數據遷到兩個裏面去，避免的方式我只遷移分裂的一個新分區的數據，另外一個分區還繼承老的分區屬性，這樣剩餘通常數據就不用遷移。
Q：高併發小 IO 高的話，client 會不會佔計算節點的 CPU 和內存很高？ A： 在 RDMA 協議層面咱們是用了兩種相結合的方式，對於小 IO 用的 send/recv 的方式，對大 IO 用的是 read/write 的方式。這麼作的緣由，是在大 IO 的狀況下儘可能減小對 CPU 的消耗，提高它的吞吐性能。對於小 IO 來講只能針對一部分特徵來減小 CPU 的消耗，不能避免 CPU 的消 耗。client 佔用的資源已和客戶購買雲主機的 CPU/內存作了隔離，不會影響到客戶的雲主機使用。   Q：雲硬盤將來會逐步替代物理硬盤嗎？ A： 只要用戶把它的業務逐步的放在雲上，我認爲雲硬盤取代物理硬盤是一個大趨勢。雲硬盤相對於物理硬盤它的劣勢主要就在於延時層面，其餘層面雲硬盤相對於物理硬盤都是有優點的。只要能解決延時的問題，雲硬盤取代物理硬盤是必然趨勢。   Q：不一樣大小 IO 經過不一樣方式複製，大 IO 經過 raft 之類的算法麼？小 IO 直接複製到三個 store，是本身實現的複製算法麼？ A： CBS 沒有使用raft 算法，數據複製部分是使用自研的算法。   Q：新的架構在容災層面怎麼考慮的？ A： 分爲兩個層面，一個是元數據層面，一個是數據層面。元數據層面分爲集羣元數據和存儲原數據。集羣元數據也是三副本，咱們會把原數據的變動，操做的流水，包括元數據自己記錄下來，因此原則上你的集羣元數據是能夠恢復到任何一個時間點的。   存儲的元數據怎麼去解決？存儲的元數據跟集羣原數據同樣，咱們會把全部變動記錄到硬盤上，包括變動流程也會記錄下來。另一層面，會像集羣元數據同樣會把它弄到異構系統裏面。
還有一個層面，可能有些元數據只是記載了硬盤的一個位置，準確的說它是記在兩副本，可是記在一塊兒的，物理位置是連續的。   在最新的架構裏面，兩個元數據的備份是放在硬盤的不一樣的位置，但無論你放幾份，放到哪裏，若是有人惡意破壞，那你仍是會把數據搞丟。   怎麼去避免這種狀況？咱們如今最新的架構裏面作了一個離散元數據，就把全部的元數據的數據記在一塊兒，去落地到硬盤上，每個數據它都帶了自身的元數據，即便你把元數據集中區給抹掉了，我同樣能夠從經過存在的數據把元數據恢復出來。從而保證元數據的安全。由於元數據是描述數據的數據，是最重要的數據。若是它丟了即便數據存在那也等同於丟失，因此元數據就顯得異常重要，這幾個能力都是在元數據層面的安全加固。   容災還涉及到數據的容災，這方面咱們是有快照能力的，將來幾天的直播中也會有其餘小夥伴介紹這點，在這我就不深刻講解了。   Q：雲盤的帶寬是否會佔用母機帶寬，擁塞時如何抉擇？ A： 如今數據多副本複製，我是有兩種策略，一種是先把那個數據路由到一個主節點處，主節點再把它複製成多份，這是一種策略。還有一種策略就是直接從客戶端分三份出來去作存儲，後面這種方式會佔用計算帶寬，因此我會根據 IO 的大小作不一樣的策略。無論怎樣，CBS使用帶寬是不佔用客戶購買雲主機的帶寬，也不會影響到客戶的雲主機使用。
Q：雲硬盤和對象存儲的差異是什麼？若是是把硬盤雲化，請問是支持多少種文件系統格式？   A： 雲硬盤相對比較「熱」，也就是延時比較敏感。 雲硬盤和本地的物理硬盤實際上是同樣的，你就跟普通物理硬盤同樣用它就好了，能夠根據須要格式化爲本身須要的文件系統   Q：不少時候，網絡 rtt 有十幾 ms，雲硬盤延遲會很高？ A： 騰訊雲的網絡沒有這麼差，應該是在百微秒級別。   Q：老師，請問大IO/小IO的分界點是多少？ A：這個大小斷定方式是不同，客戶端是 4K，存儲集羣內部 IO 是 32K。   Q：存量的雲主機支持極速型雲盤嗎？ A： 極速型雲盤目前公測中，若是有須要，能夠官網頁面提交申請，會有專人聯繫，感謝！   Q：雲硬盤能實現一盤多機掛載嗎？多機同時操做，怎麼保障一致性？ A： 支持。雲硬盤是塊存儲，塊存儲級別不能保障讀寫衝突的一致性問題。須要文件系統或應用層面保證，因此適用於oracle rac這些已經實現分佈式鎖的場景。