Curve 塊儲存已在生產環境上線使用近三年，經受住了各種異常和極端場景的考驗，效能和穩定性均超出核心業務需求預期
網易雲音樂背景
網易雲音樂是中國領先的線上音樂平臺之一，為音樂愛好者提供互動的內容社群。網易雲音樂打造了一個大型、富有活力且堅固、快速成長的業態，為使用者提供以社群為中心的線上音樂服務及社交娛樂服務。其標誌性重點產品包括 “網易雲音樂” 及附屬的社交娛樂產品，如 “LOOK 直播”、“聲波” 及 “音街”，通過科技驅動的工具讓音樂愛好者自主發掘、享受、分享並創作不同的音樂和音樂衍生內容，並與他人互動。
雲音樂雲盤業務背景
雲音樂使用雲盤的業務主要包括主站、UGC、曲庫等 Java 應用，其中主站是雲音樂核心業務，需要提供最高等級的 SLA 保障（年可用率 >=99.99%），面對提供上億級使用者量穩定的雲音樂體驗，這一直以來也是我們的重難點。2019 年之前雲音樂主要使用 Ceph 雲盤，眾所周知，Ceph 在大規模場景下存在效能缺陷，且很難保證我們在各種異常 (壞盤慢盤、儲存機當機、儲存網路擁塞等) 場景下雲盤 IO 響應時延不受影響；Ceph 雲盤的 IO 抖動問題，我們曾嘗試花很多人力精力做優化改造，但都只是稍微有所緩解，無法徹底解決；效能問題也投入大量人力進行分析優化，但仍然不能達到預期，因此我們才立項瞭解 Curve 塊儲存分散式儲存系統。
Curve 塊儲存介紹
Curve 塊儲存可以良好適配主流雲端計算平臺，並且具備高效能、易運維、穩定不抖動等優勢。我們在實際應用中，使用 Curve 塊儲存對接 Cinder 作為雲主機雲盤儲存後端，對接 Nova 作為雲主機系統盤，對接 Glance 作為映象儲存後端。在建立雲主機過程中，Nova 會通過 Curve 塊儲存提供的 Python SDK 克隆出新卷作為雲主機系統盤使用。在建立雲盤過程中，Cinder 會通過 Python SDK 建立空卷或者通過已有的卷快照克隆出新卷，之後可以掛載到雲主機上作為雲盤使用。雲主機使用 Libvirt 作為虛擬化管控服務，使用 QEMU/KVM 作為虛擬化引擎。Curve 塊儲存為 Libvirt/QEMU 提供了驅動庫，編譯後就可以直接使用 Curve 卷作為遠端儲存，不需要把 Curve 塊儲存卷掛載到本地。
為什麼選擇 Curve
- 業務側
i. 根據我們雲音樂應用場景，Ceph 雲盤主要存在二大痛點：
效能差：由於單卷效能差（主要是 IO 時延高，IOPS 上不去，並且容易受到叢集內其他高負載卷的影響），因此只能用於系統盤，或者作為雲盤供應用列印日誌，無法支撐中介軟體業務使用。
IO 抖動：經過我們觀察發現 IO 時延超出 2s 就可能會導致磁碟 util 100%，業務就會大面積告警，請求堆積，嚴重情況下會引發雪崩效應；根據前 2 年的觀察，Ceph 雲盤 IO 抖動的非常頻繁（基本每月都有），抖動時長也達分鐘級，因此有很多核心應用都切換到了本地儲存來規避類似問題。
ii. Curve 雲盤優勢：
抖動：自從使用 Curve 雲盤後，磁碟 IO util 監控再也沒有出現過因分散式儲存系統導致的 100% 告警，業務執行的穩定性得到極大提升，核心業務也逐步遷回了 Curve 雲盤（畢竟雲盤的高空間利用率、可靠性、可遷移性、快速恢復能力也是業務非常看重的）。
效能：同等硬體下，Curve 單卷效能是 Ceph 卷的 2 倍 +，時延也大大低於 Ceph，具體效能對比可以參考下圖：
- 運維側
i. 根據我們雲音樂運維場景，Ceph 的痛點主要有如下：
服務升級：常見的需要升級客戶端的場景包括 bug 修復、新功能增強以及版本升級這幾個方面，我們遇到過一個 Ceph 社群訊息模組 32 位序號溢位的 bug，該 bug 會在長期執行的客戶端出現，造成 IO hang，客戶端和服務端都需要更新版本才能解決。更新客戶端的時候有兩種選擇，一是重啟雲主機的 QEMU 程式，二是對雲主機執行熱遷移操作 live migration，這兩個操作在少量雲主機場景下可行性比較高，但如果對成百上千臺雲主機進行類似操作，顯然可操作性非常低，業務顯然無法接受。另外服務端升級在重啟 OSD 程式時也會造成一定的 IO 抖動，需要在業務低峰期操作，並且需要業務臨時關閉磁碟 util 告警。
效能：運維人員主要關注儲存叢集整體效能，若叢集總容量和總效能不匹配，容易導致容量充足的情況下效能卻不足的問題，要麼少建立卷導致容量浪費，要麼繼續建立卷但是會影響單卷的 IO 時延和吞吐，另外 Ceph 叢集卷數量到達一定規模後，隨著卷數量的增加，其叢集整體效能也是逐漸下降的，這就導致單卷的效能受到更大的影響。
演算法：受限於 CRUSH 演算法限制，Ceph 的 OSD 之間資料分佈非常不均衡，空間浪費嚴重，據我們觀察，最高和最低的 OSD 空間使用率差值可以達到 50%，經常需要進行資料均衡操作，但在資料均衡過程中會產生大量的資料遷移操作，導致 IO 抖動，另外資料均衡也不能完美的解決 OSD 容量使用不均衡問題。
IO 抖動：壞盤換盤，節點當機，高 IO 負載，擴容（不新增 pool，新增太多 pool 會導致 OpenStack 維護變複雜）資料均衡，網路卡丟包，慢盤等等。
ii. 相對來說 Curve 在上述幾個方面具備顯著優勢：
服務升級：客戶端支援熱升級，操作過程中 QEMU 程式不需要重啟，也不需要遷移，毫秒級影響對雲主機內業務幾乎無感，熱升級相關架構設計可以參考①。Curve 服務端升級時，得益於 quorum 機制的一致性協議 raft，只要做到按副本域升級，就可以保證對業務 IO 的影響在秒級，IO 時延不超過 2s 就不會導致 util 100%。
效能：Curve 叢集可以在同等容量規模下，建立更多的卷，並且保持穩定的效能輸出。
演算法：Curve 資料分配由中心化的 MDS 服務進行，可以保證非常高的均衡性，最高和最低的 chunkserver 空間利用率偏差不超過 10%，也就不需要做資料均衡操作。
IO 抖動：Ceph 雲盤容易發生 IO 抖動的場景下，Curve 雲盤表現更穩定，Curve VS Ceph 具體如下圖：
使用 Curve 落地成果
Curve 塊儲存已在生產環境上線使用近三年，經受住了各種異常和極端場景的考驗，效能和穩定性均超出核心業務需求預期，常見故障場景下未產生明顯 IO 抖動，服務端及客戶端版本升級也未影響業務正常執行，這充分證明我們當時的選擇是正確的，另外還要感謝 Curve 團隊的同學在我們使用的過程中給予的幫助。目前：雲音樂使用 Curve 塊儲存作為雲主機的雲盤和系統盤，其中系統盤通常為固定容量 40GB 或 60GB 兩種規格，雲盤容量最小 50GB，最大支援 4TB（此為軟性限制，Curve 雲盤實際支援建立 PB 級卷）。
後續規劃
結合 Curve 塊儲存方面：
探索基於 Curve 塊儲存的雲原生中介軟體場景，例如將改造後的 Redis、Kafka、訊息佇列等服務執行在 Curve 塊儲存捲上，減少故障切換時間。
上線基於 CurveBS+PolarFS+MySQL 的雲原生資料庫。
其他存量使用 Ceph 雲盤、本地儲存的雲主機切換到 Curve 塊儲存卷。
目前 Curve 團隊也在全力開發共享檔案儲存服務，網易內部基於 OpenStack 的私有云 2.0 平臺已經逐漸演進到基於 Kubernetes 的 3.0 平臺，業務對於 ReadWriteMany 的型別的 PVC 卷的需求已經越來越迫切，Curve 團隊開發了 Curve 分散式共享檔案系統，該系統支援將資料儲存到 Curve 塊儲存後端或者相容 S3 協議的物件儲存服務，後續也將盡快上線使用。
參考：
① https://github.com/opencurve/...
GitHub：https://github.com/opencurve/...
微信群：請搜尋新增或搜尋群助手微訊號 OpenCurve_bot