大家看到這張表這是今天OpenStack Nova的調(diào)度。第二，基于資源計(jì)算節(jié)點(diǎn)上有多少I/O和多少帶寬可以用，之后根據(jù)大家的需求對設(shè)備的支持，Nova自己能夠測一下CPU利用率。第三，針對Fit。最后是自己寫條件要不要在這臺(tái)后端運(yùn)行，這張表是計(jì)算全值的動(dòng)作，從前面的表上大家可以有一個(gè)感覺，特別零散，把這些做成表以后看起來還非常亂，這就是開源社區(qū)的特點(diǎn)，我有一個(gè)需求，我加一個(gè)future，我有一個(gè)不滿意的地方就拿去修一下，沒有總體規(guī)劃。再往下面做的時(shí)候，可能這個(gè)事情做起來比較麻煩，也沒有辦法維護(hù)，從這張圖實(shí)際上是代碼實(shí)現(xiàn)上的大致類圖，大家可以看一下整個(gè)流程做的蠻詭異的。他先把一些不滿足條件的過濾掉，對剩下的做了優(yōu)先序的排序，之后再往下類層次結(jié)構(gòu)，如果你自己寫一個(gè)調(diào)度器滿足自己要求的話，就在后面接一個(gè)就可以了。所以聽起來也不是那么特別的難，如果你有上游代碼不滿足你需要的話。
另外中間還有一個(gè)項(xiàng)目叫做GANNTP，是嘗試在OpenStack里做一個(gè)比較通用的路由器，這個(gè)項(xiàng)目做了一兩年就死掉了，因?yàn)樗抢鋈胃闪?，沒有跟Nova密切配合，Nova有自己的調(diào)度器還在往前做，GANNTP還在自己往前做，所以社區(qū)的決定是調(diào)度器不能自己拉出去另起爐灶，要從Nova里面找。所以一年前社區(qū)開始做調(diào)度器，對整個(gè)上的調(diào)度做了非常高度的抽象，我有什么資源，用一個(gè)表來表示，我已經(jīng)分配了哪些，然后提供一些資源，每個(gè)資源有一個(gè)名字，最小值多少，最大值多少，每次往上可以漲多少，這些都可以搞。對于不能計(jì)量的資源，比如就是X86機(jī)器的區(qū)別，還不好用數(shù)字表達(dá)的話，這種可以用另外一種PY6表達(dá)方式，用這樣新的概念就可以表達(dá)你所有能夠想象的需求。這是非常有野心的項(xiàng)目，也很值得關(guān)注。至于說這個(gè)是不是將來能一統(tǒng)天下也不知道，不過有Nova這個(gè)團(tuán)隊(duì)的強(qiáng)力支持，這個(gè)事做成的概率還是要高很多。
接下來我們看一下另外一個(gè)K8S，它里面做調(diào)度的時(shí)候做法，它做了很多類似labor的東西，也就是打標(biāo)簽，仍然是分幾大類，一種是純labor，另外是有統(tǒng)計(jì)數(shù)，有幾個(gè)CPU，有多少內(nèi)存。像GPU最近也加進(jìn)去了，但是GPU只能支持0、1，到2就搞不動(dòng)了，所有的需求都是加到哪兒算哪兒，這個(gè)是蠻令人失望的。還有這上面做的比較有趣的是，在它的調(diào)度里把存儲(chǔ)做進(jìn)去了，這個(gè)是OpenStack里面的弱點(diǎn)。OpenStack做調(diào)度的時(shí)候是不考慮網(wǎng)絡(luò)，不考慮存儲(chǔ)的。K8S調(diào)度器也跟Nova長得很像，第一步是做過濾，第二步是根據(jù)不同象限和維度做優(yōu)先級(jí)排序，如果排出來是好幾個(gè)，我就隨便選一個(gè)，基本上這個(gè)思路沒有太新鮮的東西。K8S因?yàn)閷?shí)現(xiàn)是編譯完了以后發(fā)布的，所以對它進(jìn)行擴(kuò)展和OpenStack的還不一樣，OpenStack隨便在里面改兩行代碼，重新啟一下，誰都不知道就把這個(gè)事干了，但是K8S不一樣，是編譯完才能運(yùn)行，所以在上面擴(kuò)展有所不同。所以在K8S做調(diào)度擴(kuò)展是給了這么一種做法，你可以寫自己的調(diào)度器，但是作為K8S自己調(diào)度器的擴(kuò)展是外面隨便搞。
oVirt可能在國內(nèi)外得不多，但是我一個(gè)朋友在國外參加活動(dòng)的時(shí)候，發(fā)現(xiàn)oVirt用得比較多，是比較成熟的東西，至于是不是語言，這種定性的評(píng)價(jià)我們不去講，我們先關(guān)注一下它的調(diào)度做法。沒有什么驚喜的，仍然是我有一堆機(jī)器之后，你給我什么樣的條件，然后滿足這些條件，它做得比較好的一點(diǎn)是在擴(kuò)展性上支持多種語言，你去oVirt網(wǎng)站上也可以看到有一些評(píng)價(jià)，可能用Java是比較好一些。oVirt Filters對于云來說就有點(diǎn)太細(xì)了。下面這張表是過濾出來這些機(jī)器以后，基于不同維度再去做全值的計(jì)算。
最后一組我們看一下Mesos，我對這個(gè)不是特別感冒，我并不認(rèn)為Mesos是適合cloud的，這也是個(gè)人看法。Mesos可能在座有專家對這個(gè)比較熟悉，Mesos是自己不做調(diào)度，他只負(fù)責(zé)資源管理，把資源包放上去，自己不做調(diào)度。它在做資源描述的時(shí)候，比如說在每個(gè)Mesos可以配，有多少CPU、GPU，有多少資源可以供應(yīng)這件事都可以做了。接下來做調(diào)度的話，我稍微看了一下Mesos，常見的評(píng)價(jià)是Mesos比較適合運(yùn)行時(shí)間比較長的應(yīng)用。所以大家用Mesos定制調(diào)度實(shí)現(xiàn)的時(shí)候，可能就會(huì)遇到一些困擾，你理解它本身就有點(diǎn)費(fèi)勁，它在底下那些資源表達(dá)能力也就那樣，反正你自己隨便寫。
最后我嘗試給一個(gè)討論，純粹的個(gè)人觀點(diǎn)陳述。我們看調(diào)度本身是一個(gè)什么樣的問題，我們經(jīng)常寫代碼，每天在那兒自己high得不得了，要修多少bug，往往可能就忘了自己為什么干這件事，我嘗試對調(diào)度這件事情做總結(jié)，我們?yōu)槭裁醋稣{(diào)度，首先從上往下看它都有自己的資源需求，下面不管用什么平臺(tái)，中間是資源分配或者調(diào)度的過程。那上面資源本身需求有哪些因素，你要做一個(gè)宇宙第一的調(diào)度器的話，你要討論哪些因素。這個(gè)需求本身可能是hard，就是不給我兩個(gè)CPU就起不了，其他的維度還有是這個(gè)需求是不變的，還是沒法預(yù)測的。那么負(fù)載什么時(shí)候到，它是長得胖還是瘦，不知道的，它是不是有對特殊設(shè)備的需求，比如說我去玩社區(qū)的時(shí)候，或者搞認(rèn)知計(jì)算還是人工智能，深度學(xué)習(xí)，我要玩GPU什么的，沒有GPU這事就干不了，而這種調(diào)度能力是不是調(diào)度器能夠支持，下面能不能調(diào)配上來也不知道。一堆服務(wù)給你的時(shí)候，你把它給到你的機(jī)制上，讓它們自動(dòng)連接好，并且能夠彼此發(fā)現(xiàn)對方還能夠工作，這個(gè)也不容易。從下面我們看資源貢獻(xiàn)的角度，我看論文上有一些分類，一種是隨時(shí)要隨時(shí)給，第二是你要的時(shí)候先說，第三種是有，但是我不保證，你現(xiàn)在用就用了，隨時(shí)都可能完全沒了。第一種你可以單獨(dú)的給你CPU，你還是干不了活。而且你還要考慮運(yùn)維造成的資源中斷等等因素。那么在中間要考慮哪些問題，要考慮資源利用率，要考慮既然是虛擬化平臺(tái)，那虛擬機(jī)是不是可以搬來搬去，你要考慮完成時(shí)間，這些都是為了討好你的用戶，都是為了提高性能。如果你做得更好一些，你在調(diào)度的時(shí)候還要考慮怎么提高服務(wù)質(zhì)量。只有在學(xué)術(shù)圈里才考慮你的調(diào)度器策略夠不夠公平，調(diào)度器本身是不是足夠快，是不是能夠skill做預(yù)測。我個(gè)人比較失望的是，到目前為止我沒有看到任何一個(gè)調(diào)度器cost，感覺我提供了資源所有人拿去都是不花錢的。其他的一些Factors技術(shù)，我調(diào)研發(fā)現(xiàn)過去一共有1600多篇論文，大家提出了90多種以上不同的解決方法，但是真正落地的不多。第二，因?yàn)槲覀冋嬲氖巧逃茫闶遣皇强梢钥紤]讓用戶做協(xié)商和拍賣，把資源充分利用起來，發(fā)揮它的價(jià)值。
我們現(xiàn)在看到的狀況下，這個(gè)領(lǐng)域研究非?；钴S，也不知道出了多少博士生，出了多少博導(dǎo)。如果你的云不管是自己用，還是別人用，如果真的有好的調(diào)度的話，真正的是很多東西都可以一刀切。另外，可能列了那么多表，從不同框架里看到不同的算法，可能真的沒有一個(gè)是符合你的需要的，然后更重要的一點(diǎn)是，你自己都不知道你自己想要什么的時(shí)候，這件事就沒法解決了。因?yàn)槲疫€是做以測序?yàn)橹?，希望在社區(qū)里大家集思廣益，不管你有什么想法，我們是不是可以拿出來共同探討，把這件事情做得更好。謝謝大家！
