Curve 替換 Ceph 在網易雲音樂的實踐

語言: CN / TW / HK

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

1. 業務側

i. 根據我們雲音樂應用場景,Ceph 雲盤主要存在二大痛點

  • 效能差:由於單卷效能差(主要是 IO 時延高,IOPS 上不去,並且容易受到叢集內其他高負載卷的影響),因此只能用於系統盤,或者作為雲盤供應用列印日誌,無法支撐中介軟體業務使用。

  • IO 抖動:經過我們觀察發現 IO 時延超出 2s 就可能會導致磁碟 util 100%,業務就會大面積告警,請求堆積,嚴重情況下會引發雪崩效應;根據前 2 年的觀察,Ceph 雲盤 IO 抖動的非常頻繁(基本每月都有),抖動時長也達分鐘級,因此有很多核心應用都切換到了本地儲存來規避類似問題。

ii. Curve 雲盤優勢

  • 抖動:自從使用 Curve 雲盤後,磁碟 IO util 監控再也沒有出現過因分散式儲存系統導致的100%告警,業務執行的穩定性得到極大提升,核心業務也逐步遷回了 Curve 雲盤(畢竟雲盤的高空間利用率、可靠性、可遷移性、快速恢復能力也是業務非常看重的)。

  • 效能:同等硬體下,Curve 單卷效能是 Ceph 卷的 2倍+,時延也大大低於 Ceph,具體效能對比可以參考下圖:

2. 運維側

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/curve/blob/master/docs/cn/nebd.md