容器化RDS｜調度策略

導語

前文《數據庫容器化未來已來》我們介紹了基于Kubernetes實現的下一代私有 RDS。其中調度策略是具體實現時至關重要的一環它關系到RDS 集群的服務質量和部署密度。那么RDS 需要怎樣的調度策略呢本文通過數據庫的視角結合Kubernetes的源碼分享一下我的理解。

It was the best of times, it was the worst of times。—— by Dickens.

人類從爬行到直立用了幾百萬年但是我們這些碼農從Bare Metal到 Container只花了幾萬分之一的時間。

我有個朋友是維護Mainframe的他還在使用40年前的系統。

調度策略很重要

看看巨人們在干什么有助于我們更好的理解這個世界。

Google Borg

先看看Google是如何看待Borg (Kubernetes 的前身)的核心價值。在Google paper 中開篇就定義了 Borg

It achieves high utilization by combining admission control, efficient task-packing,over-commitment, and machine sharing with process-level performance isolation.

里面還專門介紹了基于 CPI (Cycles Per Instruction)測量資源利用率的方式。

AWS RDS

再看看公有云的領頭羊 AWS是這樣描述其RDS產品的

不管是Google Borg還是AWS除了提供更靈活更開放更兼容更安全可用性更高的系統都將cost-efficienthigh utilization放到了更重要的位置。

提高部署密度減少硬件的需求量最終達到降低硬件投入的目標。同時必須滿足業務需求。

本文嘗試以數據庫的視角從多個角度闡述RDS場景需要怎樣的調度策略。

說明:

為了實現更精細化的調度策略Kubernetes(版本1.7) 調度器提供了17個調度算法。這些算法分為兩類Predicate和Priority通俗的描述是過濾和打分。設計思路大致如下

1.通過過濾算法從集群中出滿足條件的節點

2.通過打分算法對過濾出來的節點打分并排名

3.挑出分數最高的節點如果有分數相同的隨機挑一個。

本文將基于Kubernetes的實現結合RDS場景展開并不會把所有的算法流水賬似的寫一遍相關資料很多有興趣的同學可以去看文檔。具體實現見

① kubernetes/plugin/pkg/scheduler/algorithm/priorities

② kubernetes/plugin/pkg/scheduler/algorithm/predicates

下面進入主題。

調度策略

視角一計算資源調度策略

這里討論的計算資源僅包含 CPUMemory

需要特別說明畢竟Kubernetes已經支持GPU。

看上去很簡單挑選出一個滿足資源要求的節點即可但是考慮到整合密度和數據庫的業務特點并不簡單我們還需要考慮到以下幾點

峰值和均值

數據庫的負載隨著業務、時間、周期不斷變化到底是基于峰值調度還是均值調度呢這是一個有關部署密度的問題最好的辦法就像Linux里面限定資源的方式讓我們設置Soft Limit 和Hard Limit以Soft Limit分配資源同時Hard Limit又能限定使用的最大資源。

Kubernetes也是這么做的它會通過 Request 和 Limit 兩個閾值來進行管理容器的資源使用。

Pod是Kubernetes的調度單位

Requst作為Pod初始分配值Limit 限定了Pod能使用的最大值。分配時采用Requst值進行調度這里有個假設

同一節點上運行的容器不會同時達到 Limit 閾值

有效的實現了計算資源利用率的high utilization非常適合數據庫開發或測試場景。

如果假設不成立當某節點運行的所有容器同時接近Limit并有將節點資源用完的趨勢或者事實(在運行的過程中調度器會定期收集所有節點的資源使用情況“搜集”用詞不太準確但便于理解)創建 Pod的請求也不會再調度到該節點。

以內存為例, 當Pod的請求超出Node可以提供的內存, 會以異常的方式告知調度器, 內存資源不足

同時基于優先級部分容器將會被驅逐到其他節點(例如通過重啟 Pod 的方式)所以并不適合生產環境。

資源的平衡

對于長期運行的集群在滿足資源的同時還要考慮到集群中各節點資源分配的平衡性。

類似Linux Buddy System僅僅分配進程需要的內存是不夠的還要保障操作系統內存的連續性。

舉個例子RDS集群有兩個節點用戶向RDS申請 2顆CPU和4GB內存 以創建 MySQL實例兩節點資源使用情況如下

在資源同時滿足的情況下調度會通過兩個公式對節點打分。

基于已使用資源比率(Balanced Resource)打分實現如下

將節點資源輸入公式可簡化成

NodeA 分數 = int(1-math.Abs(8/16 - 8/32)) * float64(10) = 30/4

NodeB 分數 = int(1-math.Abs(8/32 - 16/64)) * float64(10) = 10

基于該算法Node B的分數更高。

再通過未使用資源(calculateUnused)持續打分。

該算法可簡化成

cpu((capacity - sum(requested)) * 10 / capacity) + memory((capacity - sum(requested)) * 10 / capacity) / 2

有興趣的同學可以算一下不再贅述。

數據庫會被調度到綜合打分最高的節點。

視角二 : 存儲資源調度策略

存儲資源是有狀態服務中至關重要的一環也讓有狀態服務的實現難度遠超無狀態服務。

除了滿足請求數據庫的存儲資源的容量要求調度策略必須要能夠識別底層的存儲架構和存儲負載在提供存儲資源的同時滿足數據庫的業務需求(比如數據零丟失和高可用)。

從2017年年初開始基于分布式存儲技術,我們的RDS已經實現了計算和存儲分離的架構。

在實現數據庫的數據零丟失高可用的同時架構變得更通用更簡單。但對企業級用戶還遠遠不夠cost-efficient 是考量產品成熟度的重要因素。

所以從一開始我們就以3種維度的存儲QoS來思考這個問題

從功能角度 :

【存儲資源分成兩大類】

1) distribution基于分布式存儲技術實現對 Flash 設備做了專門的 優化提供數據冗余和彈性擴容功能

2) local使用計算節點本地存儲。

對于生產環境我們會申請distribution資源。而那些不太重要的或者臨時性的譬如有的客戶需要經常生成臨時性的克隆庫進行測試或者擴展臨時備庫以應對突發的業務高峰我們會申請 local資源。

從性能角度

我們又將distribution分成了兩類high和medium以應業務不同的IOPSThrough putLatency需求。

IO密集型業務我們會分配high類型。對于計算密集型或者重要值很高的備庫我們會分配medium類型。

從數據庫角度

比如, 不同的數據庫物理卷的掛載參數也不同

如果調度器能夠實現, 將極大的提高存儲資源的 cost-efficient。

這些特性帶有明顯的數據庫業務特性原生的Kubernetes 調度器并不支持。但是我們通過二次開發Out of Cluster的方式實現了外置的Kubernetes storage provisoner并通過自定義的參數和代碼實現和調度器的交互。

Kubernetes 會使用我們提供的storage provisoner創建存儲資源.

這樣Kubernetes的調度器就可以基于RDS的業務需求感知底層存儲架構提供滿足業務需求的調度服務。

除去需要的容量信息需要傳遞給調度器如下信息(就像請CPUMemory資源一樣)

volume.beta.kubernetes.io/mount-options: sync

volume.orain.com/storage-type: "distribution"

volume.orain.com/storage-qos: "high"

volume.orain.com/dc-id: "278"

通過這四個參數將會告知。

從功能角度

volume.orain.com/storage-type”distribution”, 使用 distribution 類型存儲資源。

從性能角度

volume.orain.com/storage-qos”high”, 從高性能存儲池獲取 Volume

從數據庫角度

volume.beta.kubernetes.io/mount-optionssync, 使用特定 mount 參數

volume.orain.com/dc-id”278”, 使用編號為278的 Volume

視角三 : 關系型數據庫

關系型數據庫是有狀態服務但要求更加復雜。比如我們提供了MySQL的Read Write Cluster (讀寫分離集群) 和Sharding Cluster (分庫分表集群)每個數據庫實例都有自己的角色。調度器必須感知集群角色以實現業務特點

比如, 基于數據庫角色, 我們有如下調度需求:

ReadWrite Cluster的Master和Slave不能調度到同一節點

Master的多個Slave不能調度到同一節點

Sharding Cluster的每個分片不能調度到同一節點

某些備份任務須調度到指定Slave所在的節點

……

帶有明顯的業務(RDS)特點原生Kuberentes的調度策略并不能識別這些角色和關系。

與此同時容器的運行狀態和RDS集群還在動態變化

因Failover遷移到其他節點

RDS集群Scale Out

以上具體的問題抽象成

親和性(Affinity), 反親和性(Anti-Affinity)和分布度(Spread Width)

再通過我們的二次開發將數據庫的角色和業務流程集成到調度器中以滿足全部需求。

親和性(Affinity)

調度需求4可以歸納到這里

需求4 : 某些備份任務須調度到指定 Slave 所在的節點

在所有節點中找到指定 Slave 所在節點, 以確定待調度備份任務調度到哪個節點. 該需求必須滿足, 不然備份任務無法成功。

建立已運行數據庫和節點的關系在通過Affinity和Anti-Affinity公式對所有節點打分以此決定待調度數據庫是否要調度到該節點。

查找該節點所有數據庫實例

確定該節點是否有指定 Slave

反親和性(Anti-Affinity)

需求1ReadWrite Cluster 的 Master 和 Slave 不能調度到同一節點

以待調度數據庫的角色為輸入建立已運行數據庫和節點的關系再通過 Anti-Affinity 公式對所有節點打分以此決定待調度數據庫是否要調度到該節點。

以需求1為例統計集群成員的分布情況該節點上同一數據庫集群的成員越多分數越低。

反親和性(Anti-Affinity)公式

對所有節點打分

分布度(Spread Width)

有種更時髦的叫法散射度(scatter width)

需求23可以歸納到這里。

以需求2為例, 統計集群成員的分布情況, 該節點上同一數據庫集群的成員越多分數越低。

然后對所有節點打分公式如下

float64(schedulerapi.MaxPriority) * ((maxCountByNodeName -countsByNodeName[node.Name]) / maxCountByNodeName)

需要特別說明的是, 在RDS進行調度時

需求14必須滿足

需求23盡量滿足既可以。

必須和盡量也需要作為調度參數讓調度器知曉。

結語

本文僅以RDS的視角從三個層級講述了對調度器的要求。

真實的世界會更加復雜比如針對Read Write ClusterSlave 必須等待Master創建完畢而Sharding Cluster所有分片可以并發創建……

在設計產品和完成編碼的過程中踩坑無數。不能否認的是站在巨人的肩膀上可以讓我們看的更遠。不知道Ending怎么寫就這樣吧。

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

容器

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。