美團雲混合存儲系統：成本及性能優化路徑

前言

在過去60年間，機械硬盤的容量呈指數級增加的同時體積也愈來愈小。1956年IBM一塊 5兆的巨型硬盤須要數人推上車去運輸，到2016年一塊3.5寸的機械硬盤就有10TB的大小，60年增加了9個數量級。但與容量和體積的變化相比，機械硬盤的性能增加很是緩慢，吞吐率基本保持在200兆每秒上下。IOPS增加更慢，一塊7200轉的硬盤在不一樣的iodepth下的IOPS次數大概在100-200範圍內。這是容量與性能上的失衡。

而另外一方面，目前市場上固態硬盤和機械硬盤報價，單GB的成本能夠相差10倍，巨大的差價就是巨大的優化空間。

容量與性能、成本的失衡促使美團雲存儲研發團隊開始推動混合存儲系統的研究。

設計混合存儲系統的意義

一般，根據成本和性能這兩個維度，咱們能夠將雲硬盤分紅3檔：

一、 容量型雲硬盤：成本比較低，性能也比較低的產品

二、 效率型雲硬盤：成本及性能適中的產品

三、 性能型雲硬盤：性能比較高，價格也比較高

由於性價比適中，因此咱們在雲平臺上給用戶建立最多就是效率型的雲硬盤。

咱們不妨計算一下，若是要求雲平臺爲100個雲硬盤同時提供4000併發IOPS能力的話，我須要準備一個什麼樣的系統。有兩種實施方案：

第一種，若是用傳統的機械硬盤去搭建這個系統，大體須要6千塊硬盤，產生48千瓦的功耗，3年TCO就會達到千萬元。

第二種，用單盤性能3萬（保守估計）IOPS的固態硬盤，則只需40塊，功耗是0.1千瓦，3年TCO只有20萬。

兩種方案一樣達到目標的狀況下呈現出50倍的成本差距，固態硬盤性價比優點更明顯。

所以，當咱們設計存儲系統的時候，性能和容量主要爲知足需求，當這需求肯定了以後，就會有一個最優成本方案。這也是咱們設計混合存儲系統的一個主要思路。下面具體講一下如何經過對混合存儲系統進行成本優化和性能優化來實現這一想法。

混合存儲-成本優化路徑

緩存優化

在如何平衡需求與成本得到最優解的思考中，咱們很天然地想到將機械硬盤的不少flash組合起來造成混合存儲，並讓每一塊flash都發揮出比較顯著的優點。那麼如何優化呢？

優化的方式有如下兩種：

一種是RAID卡緩存，把閃存看成機械硬盤的混存。若是要是這樣混存的話，其實最簡單的就是在RAID卡上面有加一個小的閃存給作緩存；

另外一種是內核緩存，爲內核增長了一些模塊，如用flash給機械硬盤作緩存。

緩存的優化方案有很高的性價比，加上去以後效果是立竿見影。可是有一些缺陷，優化效果受限於緩存的命中率，對隨機讀測試無效，沒法實現產品承諾。因此咱們沒有放棄了這一方案。

糾刪碼

下降成本還有一種方式就是糾刪碼，傳統的分佈式存儲通常是3塊數據，每一塊數據分3個副本，一共要存12塊。換了糾刪碼的話，3塊數據經過數據運算產生兩個校驗塊，則是存6塊，達到空間降低一半的效果。

可是糾刪碼分佈式存儲條件下，尤爲是熱的分佈式可讀可寫的狀況下，實現糾刪碼是一個很是複雜的過程。並且它在寫做的時候對性能是有影響，由於寫的時候有編碼，而編碼會對IO流程產生一些影響，會對性能產生負面效果。

因此咱們嘗試了一些其餘的方案。首先咱們進行了一個性能測試，用不一樣的測試方式對SSD隨機寫的性能IOPS和機械硬盤順序寫的IOPS分別進行了測試。

測試結果顯示，機械硬盤隨機IO很是差，可是順序IO結果不錯，大體能夠達到跟一塊SSD的水平。這一結果啓發了咱們，能夠在機械硬盤上用順序寫的方式從新寫。

當客戶端要讀數據的時候，數據就直接從閃存裏面去讀；當寫的時候，寫到閃存裏，同時順序的寫到兩塊機械硬盤上面。這樣的話，讀是從固態硬盤讀，能夠保證良好性能；寫的時候固態硬盤隨機寫性能也好，換了這方式之後整個系統的性能就實現了均衡。

前文提到在機械硬盤上是順序寫，順序寫有一個問題，由於順序寫至關於排列隊列，讀的時候就須要知道到隊列的位置去讀。因此這種方式對讀很不利，咱們仍是要把專用的順序寫到專用數據，回寫到所謂數據塊裏面。因此，這須要系統容許在比較閒置的時機，將數據回寫到Journal，保證這順序有高有低的。實測，線上workload存在明顯的波峯波谷現象，因此也證實了經過糾刪碼實現混合存儲這一方案實現成本優化的可行性。

上述混合存儲的思路是基於美團雲的塊存儲系統得以實現的，整個系統是美團雲存儲團隊徹底自主研發。關於該存儲系統的詳解，可點擊《分佈式塊存儲系統Ursa的設計與實現》瞭解詳情。後續咱們還將分享糾刪碼的相關內容，請持續關注更新。

混合存儲-性能優化路徑

固態硬盤的性能很是好，若是想要把固態硬盤性能發揮出來的話，須要在軟件上作不少的優化。第一個方面是優化代碼效率，第二是發覺利用並行性。

代碼效率

在代碼效率方面的優化，有幾個方面：

• 避免使用Iostream
  
• Stack vs new/delete
  
• Resource poling&caching
  
• Logging
  
• SSE/AVX（CRC、EC）
  
• 避免使用Sendfile()
  
• 保持可維護性
  

上述幾種方式中，Sendfile有一個很是大的問題，它不支持異步文件讀取，這樣的話會影響服務端的併發處理，反而會下降性能，因此咱們不建議用sendfile。還有iostream，咱們注意到有些開源存儲系統在使用，雖然在IO提高方面多是比較方便的方式，可是效率比較低，所以咱們也不建議使用。

並行

在並行的方面，有四個優化方向：

一、 無關任務獨立並行執行

在服務端把無關的每個Disk都有一個或多個進程進行服務，客戶端每virtual disk 一個進程；

二、 盤內並行

使用異步API；

三、 任務流出：流水化處理

磁盤和網絡並行運行。

從這圖上能夠看出來網絡的流水化對IOPS提高很是明顯。

四、 任務完成：亂序完成

慢請求不阻塞其餘請求。

SubChunk

IOPS方面，機械硬盤吞吐率表現較差一些。因此咱們會把機械硬盤上面作SubChunk來提升吞吐率。

肯定優化方案後，咱們對該方案進行了一些性能評估。測試環境中咱們用了三臺服務器，其中一臺服務器配了12塊SSD，另外配了12塊HDD。

在吞吐率方面咱們的混合存儲方案性能能夠跟SSD性能相差不大；

在IOPS方面能夠說兩種方式基本上是沒有什麼顯著區別的；

在延遲上，咱們首先用了ping-4KB作測試，大概是一百多us的延遲，而後按照SSD+ping-4KB、SSD-Hybrid、SSD3R分別去讀寫數據測延遲，SSD-Hybrid與SSD3R的延遲基本持平。這個延遲對於TCP網絡加以太網仍是不錯的。

所以這一混合存儲方案從性能和成本是上可以知足產品需求的。性能上面還有一些潛力可挖，好比說用RDMA等，對此，咱們從此還將持續優化。

----------------------------------------- 

加入美團雲開發者交流QQ羣，與更多的開發大牛共同窗習。 QQ羣號：469243579