RDS系列螺帶式混合機(jī)

作者：熊中哲（沃趣科技）

郵箱：orain.xiong@woqutech.com，歡迎交流~

導(dǎo) 語

前文數(shù)據(jù)庫容器化｜未來已來我們介紹了基于Kubernetes實(shí)現(xiàn)的下一代私有 RDS。其中，調(diào)度策略是具體實(shí)現(xiàn)時(shí)至關(guān)重要的一環(huán)，它關(guān)系到RDS集群的服務(wù)質(zhì)量和部署密度。那么，RDS需要怎樣的調(diào)度策略呢？本文通過數(shù)據(jù)庫的視角結(jié)合Kubernetes的源碼，分享一下我的理解。

It was the best of times, it was the worst of times。

—by Dickens.

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

我有個(gè)朋友是維護(hù)Mainframe的，他還在使用40年前的系統(tǒng)。

調(diào)度策略很重要

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

Google Borg

先看看Google是如何看待Borg(Kubernetes 的前身)的核心價(jià)值。在Google paper <Large-scale cluster management at Google with Borg>中，開篇就定義了 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

再看看公有云的領(lǐng)頭羊， AWS是這樣描述其RDS產(chǎn)品的:

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

提高部署密度，減少硬件的需求量，最終達(dá)到降低硬件投入的目標(biāo)。

同時(shí)，

必須滿足業(yè)務(wù)需求。

本文嘗試以數(shù)據(jù)庫的視角，從多個(gè)角度闡述RDS場景需要怎樣的調(diào)度策略。

說明:

為了實(shí)現(xiàn)更精細(xì)化的調(diào)度策略，Kubernetes(版本1.7) 調(diào)度器提供了17個(gè)調(diào)度算法。這些算法分為兩類Predicate和Priority，通俗的描述是過濾和打分。設(shè)計(jì)思路大致如下：

1.通過過濾算法，從集群中出滿足條件的節(jié)點(diǎn)；

2.通過打分算法，對過濾出來的節(jié)點(diǎn)打分并排名；

3.挑出分?jǐn)?shù)最高的節(jié)點(diǎn)，如果有分?jǐn)?shù)相同的，隨機(jī)挑一個(gè)。

本文將基于Kubernetes的實(shí)現(xiàn)，結(jié)合RDS場景展開，并不會把所有的算法流水賬似的寫一遍，相關(guān)資料很多，有興趣的同學(xué)可以去看文檔。具體實(shí)現(xiàn)見：

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

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

下面進(jìn)入主題。

調(diào)度策略

視角一 : 計(jì)算資源調(diào)度策略

這里討論的計(jì)算資源僅包含 CPU，Memory：

需要特別說明，畢竟Kubernetes已經(jīng)支持GPU。

看上去很簡單，挑選出一個(gè)滿足資源要求的節(jié)點(diǎn)即可，但是考慮到整合密度和數(shù)據(jù)庫的業(yè)務(wù)特點(diǎn)并不簡單，我們還需要考慮到以下幾點(diǎn)：

峰值和均值：

數(shù)據(jù)庫的負(fù)載隨著業(yè)務(wù)、時(shí)間、周期不斷變化，到底是基于峰值調(diào)度還是均值調(diào)度呢？這是一個(gè)有關(guān)部署密度的問題，最好的辦法就像Linux里面限定資源的方式，讓我們設(shè)置Soft Limit 和Hard Limit，以Soft Limit分配資源，同時(shí)Hard Limit又能限定使用的最大資源。Kubernetes也是這么做的，它會通過 Request 和 Limit 兩個(gè)閾值來進(jìn)行管理容器的資源使用。

Pod是Kubernetes的調(diào)度單位

Requst作為Pod初始分配值，Limit 限定了Pod能使用的最大值。分配時(shí)采用Requst值進(jìn)行調(diào)度，這里有個(gè)假設(shè)：

同一節(jié)點(diǎn)上運(yùn)行的容器不會同時(shí)達(dá)到 Limit 閾值

有效的實(shí)現(xiàn)了計(jì)算資源利用率的high utilization，非常適合數(shù)據(jù)庫開發(fā)或測試場景。

如果假設(shè)不成立，

當(dāng)某節(jié)點(diǎn)運(yùn)行的所有容器同時(shí)接近Limit，并有將節(jié)點(diǎn)資源用完的趨勢或者事實(shí)(在運(yùn)行的過程中，調(diào)度器會定期收集所有節(jié)點(diǎn)的資源使用情況，“搜集”用詞不太準(zhǔn)確，但便于理解)，創(chuàng)建 Pod的請求也不會再調(diào)度到該節(jié)點(diǎn)。

以內(nèi)存為例, 當(dāng)Pod的請求超出Node可以提供的內(nèi)存, 會以異常的方式告知調(diào)度器, 內(nèi)存資源不足

同時(shí)，基于優(yōu)先級，部分容器將會被驅(qū)逐到其他節(jié)點(diǎn)(例如通過重啟 Pod的方式)，所以并不適合生產(chǎn)環(huán)境。

資源的平衡：

對于長期運(yùn)行的集群，在滿足資源的同時(shí)還要考慮到集群中各節(jié)點(diǎn)資源分配的平衡性。

類似Linux Buddy System，僅僅分配進(jìn)程需要的內(nèi)存是不夠的，還要保障操作系統(tǒng)內(nèi)存的連續(xù)性。

舉個(gè)例子，RDS集群有兩個(gè)節(jié)點(diǎn)，用戶向RDS申請 2顆CPU和4GB內(nèi)存 以創(chuàng)建 MySQL實(shí)例，兩節(jié)點(diǎn)資源使用情況如下：

在資源同時(shí)滿足的情況下，調(diào)度會通過兩個(gè)公式對節(jié)點(diǎn)打分。

基于已使用資源比率(Balanced Resource)打分，實(shí)現(xiàn)如下：

將節(jié)點(diǎn)資源輸入公式，可簡化成：

NodeA 分?jǐn)?shù) = int(1-math.Abs(8/16 - 8/32)) * float64(10) = 30/4

NodeB 分?jǐn)?shù) = int(1-math.Abs(8/32 - 16/64)) * float64(10) = 10

基于該算法Node B的分?jǐn)?shù)更高。

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

該算法可簡化成：

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

有興趣的同學(xué)可以算一下，不再贅述。

數(shù)據(jù)庫會被調(diào)度到綜合打分最高的節(jié)點(diǎn)。

視角二 : 存儲資源調(diào)度策略

存儲資源是有狀態(tài)服務(wù)中至關(guān)重要的一環(huán)，也讓有狀態(tài)服務(wù)的實(shí)現(xiàn)難度遠(yuǎn)超無狀態(tài)服務(wù)。

除了滿足請求數(shù)據(jù)庫的存儲資源的容量要求，調(diào)度策略必須要能夠識別底層的存儲架構(gòu)和存儲負(fù)載，在提供存儲資源的同時(shí)，滿足數(shù)據(jù)庫的業(yè)務(wù)需求(比如數(shù)據(jù)零丟失和高可用)。

從2017年年初開始，基于分布式存儲技術(shù),我們的RDS已經(jīng)實(shí)現(xiàn)了計(jì)算和存儲分離的架構(gòu)。

計(jì)算存儲分離

在實(shí)現(xiàn)數(shù)據(jù)庫的數(shù)據(jù)零丟失，高可用的同時(shí)，架構(gòu)變得更通用，更簡單。但對企業(yè)級用戶，還遠(yuǎn)遠(yuǎn)不夠，cost-efficient 是考量產(chǎn)品成熟度的重要因素。

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

從功能角度 :

存儲資源分成兩大類

distribution，基于分布式存儲技術(shù)實(shí)現(xiàn)，對 Flash 設(shè)備做了專門的 優(yōu)化，提供數(shù)據(jù)冗余和彈性擴(kuò)容功能；

local，使用計(jì)算節(jié)點(diǎn)本地存儲。

對于生產(chǎn)環(huán)境，我們會申請distribution資源。而那些不太重要的或者臨時(shí)性的，譬如有的客戶需要經(jīng)常生成臨時(shí)性的克隆庫進(jìn)行測試，或者擴(kuò)展臨時(shí)備庫以應(yīng)對突發(fā)的業(yè)務(wù)高峰，我們會申請local資源。

從性能角度：

我們又將distribution分成了兩類high和medium，以應(yīng)業(yè)務(wù)不同的IOPS，Through put，Latency需求。

IO密集型業(yè)務(wù)，我們會分配high類型。對于計(jì)算密集型或者重要值很高的備庫，我們會分配medium類型。

從數(shù)據(jù)庫角度：

比如, 不同的數(shù)據(jù)庫物理卷的掛載參數(shù)也不同；

如果調(diào)度器能夠?qū)崿F(xiàn), 將極大的提高存儲資源的cost-efficient。

這些特性帶有明顯的數(shù)據(jù)庫業(yè)務(wù)特性，原生的Kubernetes調(diào)度器并不支持。但是，我們通過二次開發(fā)，Out of Cluster的方式實(shí)現(xiàn)了外置的Kubernetes storage provisoner，并通過自定義的參數(shù)和代碼實(shí)現(xiàn)和調(diào)度器的交互。

Kubernetes會使用我們提供的storage provisoner創(chuàng)建存儲資源.

這樣Kubernetes的調(diào)度器就可以基于RDS的業(yè)務(wù)需求，感知底層存儲架構(gòu)，提供滿足業(yè)務(wù)需求的調(diào)度服務(wù)。

除去需要的容量信息，需要傳遞給調(diào)度器如下信息(就像請CPU，Memory資源一樣)：

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"

通過這四個(gè)參數(shù)將會告知。

從功能角度：

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

從性能角度：

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

從數(shù)據(jù)庫角度：

volume.beta.kubernetes.io/mount-options: sync, 使用特定 mount 參數(shù)

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

視角三 : 關(guān)系型數(shù)據(jù)庫

關(guān)系型數(shù)據(jù)庫是有狀態(tài)服務(wù)，但要求更加復(fù)雜。比如我們提供了MySQL的Read Write Cluster(讀寫分離集群) 和Sharding Cluster (分庫分表集群)，每個(gè)數(shù)據(jù)庫實(shí)例都有自己的角色。調(diào)度器必須感知集群角色以實(shí)現(xiàn)業(yè)務(wù)特點(diǎn)：

比如, 基于數(shù)據(jù)庫角色, 我們有如下調(diào)度需求:

ReadWrite Cluster的Master和Slave不能調(diào)度到同一節(jié)點(diǎn) Master的多個(gè)Slave不能調(diào)度到同一節(jié)點(diǎn) Sharding Cluster的每個(gè)分片不能調(diào)度到同一節(jié)點(diǎn) 某些備份任務(wù)須調(diào)度到指定Slave所在的節(jié)點(diǎn) …..

帶有明顯的業(yè)務(wù)(RDS)特點(diǎn)，原生Kuberentes的調(diào)度策略并不能識別這些角色和關(guān)系。

與此同時(shí)，容器的運(yùn)行狀態(tài)和RDS集群還在動態(tài)變化：

因 Failover遷移到其他節(jié)點(diǎn)

RDS集群 Scale Out

以上具體的問題抽象成：

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

再通過我們的二次開發(fā)，將數(shù)據(jù)庫的角色和業(yè)務(wù)流程集成到調(diào)度器中，以滿足全部需求。

親和性(Affinity)

調(diào)度需求4可以歸納到這里

需求4 : 某些備份任務(wù)須調(diào)度到指定 Slave 所在的節(jié)點(diǎn)

在所有節(jié)點(diǎn)中找到指定 Slave 所在節(jié)點(diǎn), 以確定待調(diào)度備份任務(wù)調(diào)度到哪個(gè)節(jié)點(diǎn). 該需求必須滿足, 不然備份任務(wù)無法成功.

建立已運(yùn)行數(shù)據(jù)庫和節(jié)點(diǎn)的關(guān)系，在通過Affinity和Anti-Affinity公式對所有節(jié)點(diǎn)打分，以此決定待調(diào)度數(shù)據(jù)庫是否要調(diào)度到該節(jié)點(diǎn)。

查找該節(jié)點(diǎn)所有數(shù)據(jù)庫實(shí)例：

確定該節(jié)點(diǎn)是否有指定 Slave：

反親和性(Anti-Affinity)

需求1 : ReadWrite Cluster的 Master和 Slave不能調(diào)度到同一節(jié)點(diǎn)

以待調(diào)度數(shù)據(jù)庫的角色為輸入，建立已運(yùn)行數(shù)據(jù)庫和節(jié)點(diǎn)的關(guān)系，再通過 Anti-Affinity 公式對所有節(jié)點(diǎn)打分，以此決定待調(diào)度數(shù)據(jù)庫是否要調(diào)度到該節(jié)點(diǎn)。

以需求1為例，統(tǒng)計(jì)集群成員的分布情況，該節(jié)點(diǎn)上同一數(shù)據(jù)庫集群的成員越多，分?jǐn)?shù)越低。

反親和性(Anti-Affinity)公式

對所有節(jié)點(diǎn)打分

分布度(Spread Width)

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

需求2，3可以歸納到這里。

以需求2為例, 統(tǒng)計(jì)集群成員的分布情況, 該節(jié)點(diǎn)上同一數(shù)據(jù)庫集群的成員越多, 分?jǐn)?shù)越低。

然后對所有節(jié)點(diǎn)打分，公式如下：

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

需要特別說明的是, 在RDS進(jìn)行調(diào)度時(shí)：

需求1，4必須滿足； 需求2，3盡量滿足既可以。

必須和盡量也需要作為調(diào)度參數(shù)，讓調(diào)度器知曉。

結(jié) 語

本文僅以RDS的視角，從三個(gè)層級講述了對調(diào)度器的要求。

真實(shí)的世界會更加復(fù)雜，比如針對Read Write Cluster，Slave必須等待Master創(chuàng)建完畢，而Sharding Cluster，所有分片可以并發(fā)創(chuàng)建……

在設(shè)計(jì)產(chǎn)品和完成編碼的過程中，踩坑無數(shù)。不能否認(rèn)的是，站在巨人的肩膀上可以讓我們看的更遠(yuǎn)。不知道Ending怎么寫, 就這樣吧。

BTW，如果你對我們正在做的事情感興趣，投簡歷我吧：orain.xiong@gmail.com

知數(shù)堂