? ? ? ?在學(xué)術(shù)界和工業(yè)界胸完，云計(jì)算資源調(diào)度問題都被認(rèn)為與非確定性多項(xiàng)式(Non-deterministic polynomial)優(yōu)化問題一樣困難，即一個(gè)NP問題儡循。因此舶吗，解決相對常規(guī)的調(diào)度問題的算法在問題的規(guī)模增大時(shí)可能會遭受維度的破壞。隨著云計(jì)算的不斷發(fā)展和復(fù)雜性的增加择膝，這個(gè)問題變得更具挑戰(zhàn)性誓琼。

什么是資源調(diào)度？

? ? ? ?資源調(diào)度是指在特定的資源環(huán)境下肴捉，根據(jù)一定的資源使用規(guī)則腹侣，在不同的資源使用者之間進(jìn)行資源調(diào)整的過程。這些資源使用者對應(yīng)著不同的計(jì)算任務(wù)(例如一個(gè)虛擬解決方案)齿穗，每個(gè)計(jì)算任務(wù)存操作系統(tǒng)中對應(yīng)于一個(gè)或者多個(gè)進(jìn)程傲隶。通常有兩種途徑可以實(shí)現(xiàn)計(jì)算任務(wù)的資源調(diào)度:在計(jì)算任務(wù)所在的機(jī)器上調(diào)整分配給它的資源使用量，或者將計(jì)算任務(wù)轉(zhuǎn)移到其他機(jī)器上窃页。

? ? ? 下圖是將計(jì)算任務(wù)遷移到其他機(jī)器上的一個(gè)例子跺株。在這個(gè)例子中，物理資源A(如一臺物理服務(wù)器)的使用率遠(yuǎn)高于物理資源B脖卖，通過將計(jì)算任務(wù)1從物理資源A遷移到物理資源B乒省，使得資源的使用更加均衡和合理，從而達(dá)到負(fù)載均衡的目的畦木。

? ? ? ?對于云平臺的調(diào)度研究不僅僅讓每一個(gè)云計(jì)算廠家造了N多個(gè)輪子袖扛，也因此畢業(yè)了不少這個(gè)研究方向的博士碩士研究生，對于Kubernetes的調(diào)度分析網(wǎng)上也已經(jīng)爛大街了十籍，例如XXX基于Kubernetes的調(diào)度實(shí)踐等等這樣的分享演講也到處都是蛆封，大家都在討論用什么算法，提升了多少的性能勾栗，可并沒發(fā)現(xiàn)有人討論云平臺的調(diào)度究竟是一個(gè)什么樣的問題惨篱？

云資源調(diào)度問題

? ? ? ?云資源調(diào)度問題主要分為三層：為應(yīng)用程序調(diào)度資源，調(diào)度虛擬資源（如虛擬機(jī)）到物理資源围俘，物理資源調(diào)度和落地砸讳。而且机断，在每一層可以有多個(gè)不同的目標(biāo)進(jìn)行優(yōu)化。在應(yīng)用層绣夺，可能要滿足用戶指定的服務(wù)水平目標(biāo)（SLO） - 即調(diào)度QoS吏奸，優(yōu)化提供商的效率，或者在兩者之間協(xié)商一些妥協(xié)陶耍。在虛擬資源層奋蔚，可以優(yōu)化負(fù)載均衡，提高資源利用率例如CPU和內(nèi)存的占比烈钞，此外還有成本效益或節(jié)能泊碑。

? ? ? 對于較小規(guī)模的云資源調(diào)度問題，即使使用窮舉調(diào)度算法將問題轉(zhuǎn)換為組合優(yōu)化的問題也可以滿足需求毯欣。然而馒过，作為一個(gè)NP難題，我們需要隨著維度的增加或要優(yōu)化的變量的數(shù)量而打破窮舉或枚舉的方法酗钞。因此腹忽，我們需要轉(zhuǎn)向啟發(fā)式的方法⊙庾鳎“在所有的啟發(fā)式方法中窘奏，最強(qiáng)大的是基于總體的EC算法，它有效地在團(tuán)隊(duì)成員之間交換搜索信息葫录。由于云資源調(diào)度的問題被認(rèn)為是NP難題着裹，所以它的難處理性最好通過EC算法來解決∶淄“這些”EC“算法是什么骇扇？不是最終的一致性，在這種情況下面粮，它指的是“進(jìn)化計(jì)算” - 例如最常提到的是遺傳算法少孝，粒子群算法和蟻群優(yōu)以及花授粉算法。

? ? ? ?就我自己粗淺認(rèn)識而言但金，雖然我們說有很多的解決方案韭山，例如OpenStack Nova郁季、kube-scheduler冷溃、oVirt等等，但我們不會見到一個(gè)通用的萬能的方案或者可以完全解決調(diào)度中可能增加的影響因子和支持硬件以及不同的需求的問題梦裂。調(diào)度這個(gè)問題本身不是我們拿來別人的方案來解決我們自己的問題似枕，而是我們的問題應(yīng)該使用什么樣的方案來解決，我覺得這兩種說法是有很大區(qū)別的年柠。

為什么說這是個(gè)不確定性問題凿歼？

首先我們面臨三個(gè)挑戰(zhàn)：

第一個(gè)挑戰(zhàn)是平臺狀態(tài)一致性問題，相信做過云資源調(diào)度的同學(xué)一定遇到過超售的問題，這就是因?yàn)樾屡f數(shù)據(jù)的交叉導(dǎo)致在調(diào)度的過程出現(xiàn)了臨界的數(shù)據(jù)不一致答憔。

第二個(gè)挑戰(zhàn)是調(diào)度需求本身可能隨時(shí)間而改變味赃，這也是最不確定性的問題，這種不確定性可能來自于用戶虐拓，也可能來自對手心俗，需要考慮特殊的調(diào)度請求又要滿足軟件硬件的兼容。

第三個(gè)挑戰(zhàn)是規(guī)模蓉驹，隨著云計(jì)算的迅速發(fā)展城榛，資源，用戶态兴，任務(wù)和工作流程的規(guī)模不斷擴(kuò)大狠持。未來越來越多的任務(wù)將在云環(huán)境中處理，越來越多的云資源需要在互聯(lián)網(wǎng)普及的環(huán)境中進(jìn)行管理和調(diào)度瞻润。

所以喘垂，想要設(shè)計(jì)或者實(shí)現(xiàn)符合自己的云平臺調(diào)度方案，第一點(diǎn)就是定義需求邊界和成本绍撞。

最難的我覺得不是能不能實(shí)現(xiàn)這樣的一個(gè)調(diào)度器或者設(shè)計(jì)一個(gè)牛逼的調(diào)度算法王污，而是我們應(yīng)該怎么定義我們的調(diào)度需求邊界，我們比較看重什么因素楚午，哪些是我們完全不需要考慮兼容的昭齐，哪些在未來可能要解決的問題，舍棄與妥協(xié)矾柜。比如在平臺一致性問題的解決中可能我們需要避免在負(fù)載高的宿主機(jī)上調(diào)度阱驾，但這樣可能會降低資源的使用率。正如我們在考慮架構(gòu)時(shí)需要首先考慮的架構(gòu)的邊界怪蔑，沒有邊界的方案純屬扯淡里覆。

比如，我需要四個(gè)CPU缆瓣，你是不夠的話是就不給還是先給你兩個(gè)用著喧枷，能不能湊合下，這些都是彈性的弓坞，動(dòng)態(tài)的隧甚，可商量的。還有就是你的響應(yīng)性能是多少的要求呢渡冻？比如在我完成新版的調(diào)度之前的那一個(gè)版本的調(diào)度也是可用的戚扳，照樣支撐了數(shù)萬臺機(jī)器的調(diào)度并為億萬用戶正常服務(wù)，當(dāng)上線新版的調(diào)度后族吻，調(diào)度性能上升了將近兩個(gè)數(shù)量級帽借，但對于外界使用是無感知的珠增，創(chuàng)建一臺機(jī)器需要分鐘級別的時(shí)間，而調(diào)度性能只是從秒級到毫秒級砍艾。還有就是是不是有對特殊設(shè)備的支持蒂教，例如GPU，特定的CPU等等脆荷，是不是要支持網(wǎng)絡(luò)和磁盤的調(diào)度悴品，支持不支持本地磁盤等等。有時(shí)候可能還需要判斷是IO類型的主機(jī)還是計(jì)算類型的主機(jī)简烘。另外還有些問題可能是我們自己臆造的苔严，例如我們會不由自主的想，要不要體現(xiàn)調(diào)度的公平性孤澎，可不可以預(yù)測等等届氢。但從我看到的而言，真正落地的有多少會去體現(xiàn)公平性覆旭，一般來說我們并不非要某一次調(diào)度一定是最優(yōu)的退子，我們僅僅需要的是能命中合適機(jī)器；還有對于預(yù)測的一些理論大概在學(xué)術(shù)界比較盛行吧型将！

真正的生產(chǎn)環(huán)境的云平臺調(diào)度主要在做兩件事寂祥，可用性和低成本，即如何在低成本的情況下滿足可用性七兜。這一點(diǎn)學(xué)術(shù)界大概對花費(fèi)考慮的不多丸凭，就我看來是這樣，總覺得資源是足夠的腕铸，這也是每年上百篇論文幾乎沒有落地的主要原因惜犀。另一個(gè)是算法真正的可行性，目前業(yè)界幾乎所有的調(diào)度狠裹，最有效的算法還是基于規(guī)則和資源狀態(tài)的調(diào)度虽界。工業(yè)界最終的方向是盈利，所有的事情都會基于這一點(diǎn)涛菠，所以提高調(diào)度的性能莉御，提高資源的使用率或者說降低成本將是主要的功能。

調(diào)度俗冻，一直在路上礁叔！

主要來源：知乎專欄 “進(jìn)擊的云計(jì)算”