13倍性能，3倍穩(wěn)定性提升！UCloud云硬盤做了這些事

作者：彭晶鑫 2018-11-08 15:44:10
云計算 近期，我們推出高性能SSD云盤，滿足用戶對高性能的場景需求。SSD云盤相比普通云盤，IOPS提升了13倍，穩(wěn)定性提升了3倍，平均時延降低了10倍。

近期，我們推出高性能SSD云盤，滿足用戶對高性能的場景需求。SSD云盤相比普通云盤，IOPS提升了13倍，穩(wěn)定性提升了3倍，平均時延降低了10倍。為了做到這些，我們從去年10月份開始對云盤的架構進行了重新設計，充分減少時延和提升IO能力;并通過復用部分架構和軟件，提供性能更好、更穩(wěn)定的普通云盤;同時逐步引入Stack/Kernel Bypass技術，打造下一代超高性能存儲。新架構推出后，已服務了現(xiàn)網(wǎng)用戶的3400多個云盤實例，總存儲容量達800TB，集群每秒IOPS均值31萬。

架構升級要點

通過對現(xiàn)階段問題和需求的分析，我們整理了這次架構升級的具體要點：

1、解決原有軟件架構不能充分發(fā)揮硬件能力的局限;

2、支持SSD云盤，提供QOS保證，充分發(fā)揮后端NVME物理盤的IOPS和帶寬性能，單個云盤IOPS可達2.4W;

3、支持更大容量云盤，32T甚至更大;

4、充分降低IO流量的熱點問題;

5、支持并發(fā)創(chuàng)建幾千塊云盤，支持并發(fā)掛載幾千塊云盤;

6、支持老架構云盤在線向新架構遷移，支持普通云盤在線遷移至SSD云盤。

新架構改造實踐

改造一：IO路徑優(yōu)化

老架構中，整個IO路徑有三大層，第一層宿主Client側，第二層Proxy側，第三層存儲Chunk層。Proxy負責IO的路由獲取以及緩存;IO的讀寫轉發(fā)到下一層存儲層，負責IO寫三份復制。

而新架構中，路由獲取交給了Client，IO讀寫Client可直接訪問存儲Chunk層，寫三份復制也交給了Chunk。整個IO路徑變成了2層，一層是宿主Client側, 另一層存儲Chunk層。

架構升級之后，對讀IO，一次網(wǎng)絡請求直達到后端存儲節(jié)點，老架構都是2次。對寫IO，主副本IO一次網(wǎng)絡請求直達后端存儲節(jié)點，另外2副本經(jīng)過主副本，經(jīng)歷兩次網(wǎng)絡轉發(fā)，而老架構三個副本均為兩次。讀IO時延平均降低0.2-1ms，寫尾部時延減低，也有效的降低總體時延。

改造二：元數(shù)據(jù)分片

分布式存儲中，會將數(shù)據(jù)進行分片，從而將每個分片按多副本打散存儲于集群中。如下圖，一個200G的云盤，如果分片大小是1G，則有200個分片。老架構中，分片大小是1G，在實際業(yè)務過程中我們發(fā)現(xiàn)，部分業(yè)務的IO熱點集中在較小范圍內，如果采用1G分片，普通SATA磁盤性能會很差。并且在SSD云盤中，也不能均勻的將IO流量打散到各個存儲節(jié)點上。

新架構中，我們支持了1M大小的分片。1M分片，可以充分使用整個集群的能力。高性能存儲中，因為固態(tài)硬盤性能較好，業(yè)務IO熱點集中在較小范圍內，也能獲得較好的性能。

但UCloud元數(shù)據(jù)采用的是預分配和掛載方案，申請云盤時系統(tǒng)直接分配所有元數(shù)據(jù)并全部加載到內存。分片過小時，需要同時分配或掛載的元數(shù)據(jù)量會非常大，容易超時并導致部分請求失敗。

例如，同時申請100塊300G的云盤，如果按1G分片，需要同時分配3W條元數(shù)據(jù);如果按照1M分片，則需要同時分配3000W條元數(shù)據(jù)。

為了解決分片變小導致的元數(shù)據(jù)分配/掛載失敗問題，我們嘗試改變IO時的分配策略，即云盤掛載時，將已分配的元數(shù)據(jù)加載到內存中。IO時，如果IO范圍命中已經(jīng)分配路由，則按內存中的路由進行IO;如果IO范圍命中未分配路由，則實時向元數(shù)據(jù)模塊請求分配路由，并將路由存儲在內存中。

按IO時分配，如果同時申請100塊300G的云盤, 同時掛載、同時觸發(fā)IO，大約會產(chǎn)生1000 IOPS，偏隨機。最壞情況會觸發(fā)1000* 100 = 10W 元數(shù)據(jù)分配。在IO路徑上，還是存在較大消耗。

最終，新架構中我們放棄了中心節(jié)點存儲分片元數(shù)據(jù)的方案，采用了以一套統(tǒng)一規(guī)則去計算獲取路由的方案。

該方案中，Client 端和集群后端采用同樣的計算規(guī)則R(分片大小、pg個數(shù)、映射方法、沖突規(guī)則);云盤申請時，元數(shù)據(jù)節(jié)點利用計算規(guī)則四元組判斷容量是否滿足;云盤掛載時，從元數(shù)據(jù)節(jié)點獲取計算規(guī)則四元組; IO時，按計算規(guī)則R(分片大小、pg個數(shù)、映射方法、沖突規(guī)則)計算出路路由元數(shù)據(jù)然后直接進行IO。通過這種改造方案，可以確保在1M數(shù)據(jù)分片的情況下，元數(shù)據(jù)的分配和掛載暢通無阻，并節(jié)省IO路徑上的消耗。

改造三：支持SSD高性能云盤

通過上述對比可以看到，NVME固態(tài)硬盤性能百倍于機械盤，但需要軟件的配套設計，才能利用NVME固態(tài)硬盤的能力。

SSD云盤提供QoS保證，單盤IOPS：min{1200+30*容量，24000} 對于SSD云盤，傳統(tǒng)的單線程模式會是瓶頸，難以支持后端NVME硬盤幾十萬的IOPS以及1-2GB的帶寬，所以我們采用了多線程模型。

為了較快推出SSD云盤，我們還是采用了傳統(tǒng)TCP網(wǎng)絡編程模型，未使用KernelBypass。同時，通過一些軟件細節(jié)的優(yōu)化，來減少CPU消耗。

目前，單個線程寫可達6WIOPS，讀可達8W IOPS，5個線程可以基本利用NVME固態(tài)硬盤的能力。目前我們能提供云盤IO能力如下：

改造四：防過載能力

對于普通云盤，新架構的軟件不再是瓶頸，但一般的機械硬盤而言，隊列并發(fā)大小只能支持到32-128左右。100塊云盤，持續(xù)同時各有幾個IO命中一塊物理HDD磁盤時，因為HDD硬盤隊列并發(fā)布較小，會出現(xiàn)較多的io_submit耗時久或者失敗等問題。Client側判斷IO超時后，會重試IO發(fā)送，造成Chunk端TCP緩沖區(qū)積壓越來越多的IO包，越來越多的超時積壓在一起，最終導致系統(tǒng)過載。

對于普通云盤，需控制并發(fā)提交隊列大小，按隊列大小，依次遍歷所有云盤，下發(fā)各云盤的IO，如上圖的1、2、3。實際代碼邏輯里，還需要考慮云盤大小的權重。

對于SSD云盤來說，傳統(tǒng)的單個線程會是瓶頸，難以支持幾十萬的IOPS以及1-2GB的帶寬。

壓測中，我們模擬了熱點集中在某個線程上的場景，發(fā)現(xiàn)該線程CPU基本處于99%-100%滿載狀態(tài)，而其它線程則處于空閑狀態(tài)。后來，我們采用定期上報線程CPU以及磁盤負載狀態(tài)的方式，當滿足某線程持續(xù)繁忙而有線程持續(xù)空閑時，選取部分磁盤分片的IO切換至空閑線程，來規(guī)避部分線程過載。

改造五：在線遷移

老架構普通云盤性能較差，部分普通云盤用戶業(yè)務發(fā)展較快，希望從普通云盤遷移至SSD云盤，滿足更高的業(yè)務發(fā)展需要。目前線上存在2套老架構，為了快速達到在線遷移的目的，我們第一期決定從系統(tǒng)外圍支持在線遷移。

遷移流程如下：

1、后端設置遷移標記;

2、Qemu連接重置到Trans Client;

3、寫IO流經(jīng)過Trans Client到Trans模塊，Trans模塊進行雙寫：一份寫老架構，一份寫新架構;

4、Trigger遍歷磁盤, 按1M大小觸發(fā)數(shù)據(jù)命令給Trans觸發(fā)數(shù)據(jù)后臺搬遷。未完成搬遷前，IO讀經(jīng)Trans向舊架構Proxy讀取;

5、當全部搬遷完成后，Qemu連接重置到新架構Client，完成在線遷移。

加一層Trans及雙寫，使遷移期間存在一些性能損耗。但對于普通云盤，遷移期間可以接受。我們目前對于新架構也正在建設基于Journal的在線遷移能力，目標在遷移期間，性能影響控制在5%以下。

經(jīng)過上述系列改造，新的云硬盤架構基本完成了最初的升級目標。目前，新架構已經(jīng)正式上線并成功運用于日常業(yè)務當中。在這里，也談談我們正在研發(fā)的幾項工作。

1、容量具備無限擴展能力

每個可用區(qū)，會存在多個存儲集群Set. 每個Set可提供1PB左右的存儲(我們并沒有讓集群無限擴容)。當Set1的云盤需要從1T擴容至32T 、100T時，可能會碰到Set1的容量不足的問題。

因此，我們計劃將用戶申請的邏輯盤，進行分Part, 每個Part可以申請再不用的Set中，從而具備容量可以無限擴展的能力。

2、超高性能存儲

近10年，硬盤經(jīng)過 HDD -> SATA SSD -> NVME SSD的發(fā)展。同時，網(wǎng)絡接口也經(jīng)歷了10G -> 25G -> 100G的跨越式發(fā)展。然而CPU主頻幾乎沒有較大發(fā)展，平均在2-3GHZ，我們使用的一臺物理機可以掛6-8塊NVME盤，意味著一臺物理機可以提供300-500萬的IOPS。

傳統(tǒng)應用服務器軟件模式下，基于TCP的Epoll Loop, 網(wǎng)卡的收發(fā)包，IO的讀寫要經(jīng)過用戶態(tài)、內核態(tài)多層拷貝和切換，并且需要靠內核的中斷來喚醒，軟件很難壓榨出硬件的全部能力。例如在IOPS和時延上，只能靠疊加線程去增加IOPS，然而，IOPS很難隨著線程的增加而線性增長，此外時延抖動也較高。

我們希望通過引入零拷貝、用戶態(tài)、輪詢的技術方案來優(yōu)化上圖中的三種IO路徑，從而減少用戶態(tài)、內核態(tài)、協(xié)議棧的多層拷貝和切換，并結合輪詢一起壓榨出硬件的全部能力。

最終，我們選擇了RDMA，VHOST，SPDK三個技術方案。

• 方案一：超高性能存儲-VHOST

傳統(tǒng)模式如下，IO經(jīng)過虛機和Qemu驅動，再經(jīng)過UnixDomain Socket到Client。經(jīng)過多次用戶態(tài)內核態(tài)，以及IO路徑上的拷貝。

而利用VHOST User模式，可以利用共享內存進行用戶態(tài)的VM到Client側的數(shù)據(jù)傳輸。在實際中，我們利用了SPDK VHOST。

研發(fā)環(huán)境中，我們將Client收到IO請求后立即模擬返回給VM，也就是不向存儲后端發(fā)送數(shù)據(jù)，得到的數(shù)據(jù)如上圖。單隊列時延可以降低90us，IOPS有幾十倍的提升。

• 方案二：超高性能存儲-RDMA+SPDK

RDMA提供了一種消息服務，應用程序利用RDMA可以直接訪問遠程計算機上的虛擬內存，RDMA減少了CPU占用以及內存帶寬瓶頸，提供了很高的帶寬，并利用Stack Bypass和零拷貝技術，提供了低延遲的特性。

SPDK可以在用戶態(tài)高并發(fā)零拷貝地以用戶態(tài)驅動直接訪問NVME 固態(tài)硬盤。并利用輪詢模式避免了內核上下文切換和中斷處理帶來的開銷。

目前團隊正在研發(fā)利用RDMA和SPDK的存儲引擎框架，研發(fā)測試環(huán)境中，后端用一塊NVME固態(tài)盤，我們在單隊列和IOPS上可以提升如下：

包括SPDK VHOST USER的Client側，以及RDMA+SPDK的存儲側方案，預計12月會推出公測版。

總結

過去的一年時間里，我們重新設計和優(yōu)化了云盤的存儲架構，解決了過去老架構的諸多問題，并大幅提升了性能。經(jīng)過4個月公測，SSD云盤和新架構普通云盤都于8月份全量上線，并保持了極高的穩(wěn)定性，目前單盤可提供2.4W IOPS。

新聞標題：13倍性能，3倍穩(wěn)定性提升！UCloud云硬盤做了這些事
本文URL：http://m.fisionsoft.com.cn/article/coedhhh.html