云盤為云服務器提供高可用、高可靠、持久化的數據塊級隨機存儲，其性能和數據可靠性尤為重要。UCloud根據以往的運營經驗，在過去一年里重新設計了云盤的底層架構，在提升普通云盤性能的同時，完成了對NVME高性能存儲的支持。下文從IO路徑優化、元數據分片、支持NVME等技術維度著手，詳細講解了UCloud云硬盤的架構升級和性能提升策略。

IO路徑優化

過去，IO讀寫需要經過三層架構，請求首先通過網絡，訪問proxy代理服務器(proxy主要負責IO的路由獲取、緩存、讀寫轉發以及IO寫操作的三份復制)，***到達后端存儲節點。老的架構里，每一次讀/寫IO都需要經過2次網絡轉發操作。

為了降低延時，優化后的方案將proxy負責的功能拆分，定義由client負責IO的路由獲取、緩存，以及將IO的讀寫發送到主chunk當中，由主chunk負責IO寫的三份復制。架構升級之后，IO的讀寫只需經過兩層架構，尤其對于讀IO而言，一次網絡請求可直達后端存儲節點，其時延平均可降低0.2-1ms。

元數據分片

分布式存儲會將數據進行分片，從而將每個分片按多副本打散存儲于集群中。老架構中，UCloud支持的分片大小是1G。但是，在特殊場景下(如業務IO熱點局限在較小范圍內)，1G分片會使普通SATA磁盤的性能非常差，并且在SSD云盤中，也不能均勻的將IO流量打撒到各個存儲節點上。所以新架構中，UCloud將元數據分片調小，支持1M大小的數據分片。

分片過小時，需要同時分配或掛載的元數據量會非常大，容易超時并導致部分請求失敗。這是由于元數據采用的是預分配和掛載，申請云盤時系統直接分配所有元數據并全部load到內存。

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

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

對NVME高性能存儲的支持

NVME充分利用 PCI-E 通道的低延時以及并行性極大的提升NAND固態硬盤的讀寫性能和降低時延，其性能百倍于HDD。目前常用的基于NAND的固態硬盤可支持超10W的寫IOPS、40-60W的讀IOPS以及1GB-3GB讀寫帶寬，為支持NVME，軟件上需要配套的優化設計。

首先，傳統架構采用單線程傳輸，單個線程寫 IOPS達6W，讀IOPS達8W，難以支持后端NVME硬盤幾十萬的IOPS以及1-2GB的帶寬。為了利用NVME磁盤的性能，需要將單線程傳輸改為多線程傳輸，系統定期上報線程CPU以及磁盤負載狀態，當滿足某線程持續繁忙、而有線程持續空閑情況時，可將選取部分磁盤分片的IO切換至空閑線程，目前5個線程可以完全發揮NVME的能力。

此外，在架構優化上，除了減少IO路徑層級以及更小分片外，UCloud在IO路徑上使用內存池、對象池，減少不停的new delete，同時盡量用數組索引，減少查詢消耗，并避免字符串比較以及無謂的拷貝，最終充分地發揮NVME磁盤性能。

以上內容最早發表于UCloud 10月12日在上海主辦的Tech Talk***期活動。Tech Talk是UCloud面向用戶做深度技術交流的線下活動，后面也會繼續舉辦，歡迎參加。