<input id="ohw05"></input>
  • <table id="ohw05"><menu id="ohw05"></menu></table>
  • <var id="ohw05"></var>
  • <code id="ohw05"><cite id="ohw05"></cite></code>
    <label id="ohw05"></label>
    <var id="ohw05"></var>
  • Curve 替換 Ceph 在網易云音樂的實踐

    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

     

    posted @ 2022-06-28 16:25  網易數帆  閱讀(2)  評論(0編輯  收藏  舉報

    国产美女a做受大片观看