13倍效能，3倍穩定性提升！UCloud雲硬碟做了這些事

SSD 軟體架構 IOPS · 發表 2018-11-09 19:18:46

摘要：近期，我們推出高效能SSD雲盤，滿足使用者對高效能的場景需求。SSD雲盤相比普通雲盤，IOPS提升了13倍，穩定性提升了3倍，平均時延提升了10倍。為了做到這些，我們從去年10月份開始對雲盤的架構進行了重新設計，充分減少時延和提升IO能力；並通過複用部分架構和軟體，提供效能更好、更穩...

近期，我們推出高效能SSD雲盤，滿足使用者對高效能的場景需求。SSD雲盤相比普通雲盤，IOPS提升了13倍，穩定性提升了3倍，平均時延提升了10倍。為了做到這些，我們從去年10月份開始對雲盤的架構進行了重新設計，充分減少時延和提升IO能力；並通過複用部分架構和軟體，提供效能更好、更穩定的普通雲盤；同時逐步引入Stack/Kernel Bypass技術，打造下一代超高效能儲存。新架構推出後，已服務了現網使用者的3400多個雲盤例項，總儲存容量達800 TB，叢集每秒IOPS均值31萬。

架構升級要點

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

1 、解決原有軟體架構不能充分發揮硬體能力的侷限

2 、支援SSD雲盤，提供QOS保證，充分發揮後端NVME物理盤的IOPS和頻寬效能，單個雲盤IOPS可達2.4W

3 、支援更大容量雲盤，32T甚至更大

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

5 、支援併發建立幾千塊雲盤，支援併發掛載幾千塊雲盤

6 、支援老架構雲盤線上向新架構遷移，支援普通雲盤線上遷移至SSD雲盤

新架構改造實踐

改造一：IO路徑優化

老架構中，整個IO路徑有三大層，第一層宿主Client側，第二層Proxy側，第三層儲存Chunk層。Proxy負責IO的路由獲取以及快取；IO的讀寫轉發到下一層儲存層，負責IO寫三份複製。

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

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

改造二：元資料分片

分散式儲存中，會將資料進行分片，從而將每個分片按多副本打散儲存於叢集中。如下圖，一個200G的雲盤，如果分片大小是1G，則有200個分片。老架構中，分片大小是1G，在實際業務過程中我們發現，部分業務的IO熱點集中在較小範圍內，如果採用1G分片，普通SATA磁碟效能會很差。並且在SSD雲盤中，也不能均勻的將IO流量打散到各個儲存節點上。

新架構中，我們支援了1M大小的分片。1M分片，可以充分使用整個叢集的能力。高效能儲存中，因為固態硬碟效能較好，業務IO熱點集中在較小範圍內，也能獲得較好的效能。

但UCloud元資料採用的是預分配和掛載方案，申請雲盤時系統直接分配所有元資料並全部載入到記憶體。分片過小時，需要同時分配或掛載的元資料量會非常大，容易超時並導致部分請求失敗。

例如，同時申請100塊300G的雲盤，如果按1G分片，需要同時分配3W條元資料；如果按照1M分片，則需要同時分配3000W條元資料。

為了解決分片變小導致的元資料分配/掛載失敗問題，我們嘗試改變IO時的分配策略，即雲盤掛載時，將已分配的元資料載入到記憶體中。IO時，如果IO範圍命中已經分配路由，則按記憶體中的路由進行IO；如果IO範圍命中未分配路由，則實時向元資料模組請求分配路由，並將路由儲存在記憶體中。

按IO時分配，如果同時申請100塊300G的雲盤, 同時掛載、同時觸發IO，大約會產生1000 IOPS，偏隨機。最壞情況會觸發1000 * 100 = 10W 元資料分配。在IO路徑上，還是存在較大消耗。

最終，新架構中我們放棄了中心節點儲存分片元資料的方案，採用了以一套統一規則去計算獲取路由的方案。

該方案中，Client 端和集群后端採用同樣的計算規則R（分片大小、pg個數、對映方法、衝突規則）；雲盤申請時，元資料節點利用計算規則四元組判斷容量是否滿足；雲盤掛載時，從元資料節點獲取計算規則四元組； IO時，按計算規則R（分片大小、pg個數、對映方法、衝突規則）計算出路路由元資料然後直接進行IO。通過這種改造方案，可以確保在1M資料分片的情況下，元資料的分配和掛載暢通無阻，並節省IO路徑上的消耗。

改造三：支援SSD高效能雲盤

通過上述對比可以看到，NVME固態硬碟效能百倍於機械盤，但需要軟體的配套設計，才能利用NVME固態硬碟的能力。

SSD雲盤提供QoS保證，單盤IOPS：min{1200+30*容量，24000} 對於SSD雲盤，傳統的單執行緒模式會是瓶頸，難以支援後端NVME硬碟幾十萬的IOPS以及1-2GB的頻寬，所以我們採用了多執行緒模型。

為了較快推出SSD雲盤，我們還是採用了傳統TCP網路程式設計模型，未使用Kernel Bypass。同時，通過一些軟體細節的優化，來減少CPU消耗。

目前，單個執行緒寫可達6W IOPS，讀可達8W IOPS，5個執行緒可以基本利用NVME固態硬碟的能力。目前我們能提供雲盤IO能力如下：

改造四：防過載能力

對於普通雲盤，新架構的軟體不再是瓶頸，但一般的機械硬碟而言，佇列併發大小隻能支援到32-128左右。100塊雲盤，持續同時各有幾個IO命中一塊物理HDD磁碟時，因為HDD硬碟佇列併發布較小，會出現較多的io_submit耗時久或者失敗等問題。Client側判斷IO超時後，會重試IO傳送，造成Chunk端TCP緩衝區積壓越來越多的IO包，越來越多的超時積壓在一起，最終導致系統過載。

對於普通雲盤，需控制併發提交佇列大小，按佇列大小，依次遍歷所有云盤，下發各雲盤的IO，如上圖的1、2、3。實際程式碼邏輯裡，還需要考慮雲盤大小的權重。

對於SSD雲盤來說，傳統的單個執行緒會是瓶頸，難以支援幾十萬的IOPS以及1-2GB的頻寬。

壓測中，我們模擬了熱點集中在某個執行緒上的場景，發現該執行緒CPU基本處於99%-100%滿載狀態，而其它執行緒則處於空閒狀態。後來，我們採用定期上報執行緒CPU以及磁碟負載狀態的方式，當滿足某執行緒持續繁忙而有執行緒持續空閒時，選取部分磁碟分片的IO切換至空閒執行緒，來規避部分執行緒過載。

改造五：線上遷移

老架構普通雲盤效能較差，部分普通雲盤使用者業務發展較快，希望從普通雲盤遷移至SSD雲盤，滿足更高的業務發展需要。目前線上存在2套老架構，為了快速達到線上遷移的目的，我們第一期決定從系統外圍支援線上遷移。

遷移流程如下：

1 後端設定遷移標記；

2 Qemu連線重置到Trans Client；

3 寫IO流經過Trans Client 到Trans模組，Trans模組進行雙寫：一份寫老架構，一份寫新架構；

4 Trigger 遍歷磁碟, 按1M大小觸發資料命令給Trans觸發資料後臺搬遷。未完成搬遷前，IO讀經Trans向舊架構Proxy讀取；

5 當全部搬遷完成後，Qemu連線重置到新架構Client，完成線上遷移。

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

經過上述系列改造，新的雲硬碟架構基本完成了最初的升級目標。目前，新架構已經正式上線併成功運用於日常業務當中。在這裡，也談談我們正在研發的幾項工作。

1、容量具備無限擴充套件能力

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

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

2、超高效能儲存

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

傳統應用伺服器軟體模式下，基於TCP的Epoll Loop, 網絡卡的收發包，IO的讀寫要經過使用者態、核心態多層拷貝和切換，並且需要靠核心的中斷來喚醒，軟體很難壓榨出硬體的全部能力。例如在IOPS和時延上，只能靠疊加執行緒去增加IOPS，然而，IOPS很難隨著執行緒的增加而線性增長，此外時延抖動也較高。