今天閱讀了一個(gè)berkeley學(xué)生Andrew Konwinski的有關(guān)集群資源調(diào)度的技術(shù)報(bào)告，其中對(duì)于目前現(xiàn)有集群調(diào)度技術(shù)的分類，我覺(jué)得說(shuō)的很好，另外，它還介紹了一種模擬實(shí)驗(yàn)的蒙特卡洛方法，現(xiàn)在做一個(gè)摘要與總結(jié)，報(bào)告鏈接：http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-273.html?

里面還說(shuō)了一個(gè)比較重要的特點(diǎn)是，悲觀鎖和樂(lè)觀鎖：

The pessimistic concurrency control approach is to have the database server lock the row on User A's behalf, so User B has to wait until User A has finished its work before proceeded. We effectively solve the problem by not allowing two users to work on the same piece of data at the same time. It just prevents the conflict.

The optimistic concurrency control approach doesn't actually lock anything - instead, it asks User A to remember what the row looked like when he first saw it, and when it's time to update it, the user asks the database to go ahead only if the row still looks like he remembers it. It doesn't prevent a possible conflict, but it can detect it before any damage is done and fail safely.

?

動(dòng)機(jī)

目前，大型web服務(wù)主要運(yùn)行在普通服務(wù)器集群上面。這個(gè)主要是由于（1）更加廉價(jià)的計(jì)算資源和（2）通過(guò)公有云和私有云接口訪問(wèn)這些資源的方便性。這個(gè)現(xiàn)象導(dǎo)致了多種編程模型的出現(xiàn)，比如為處理留作業(yè)的MapReduce，Dryad，MapReduce Online以及為圖計(jì)算開發(fā)的Pregel和很多其他的系統(tǒng)。

新的計(jì)算框架會(huì)持續(xù)的出現(xiàn)，沒(méi)有一個(gè)單獨(dú)的框架能滿足所有的需求。這個(gè)就導(dǎo)致了我們希望在同一個(gè)集群中同時(shí)運(yùn)行不同的計(jì)算模型，為某個(gè)應(yīng)用選擇最好的框架。這個(gè)需求就需要一個(gè)支持多編程模型的集群資源管理系統(tǒng)，這個(gè)系統(tǒng)需要滿足一下要求：

可伸縮性：對(duì)于節(jié)點(diǎn)的數(shù)目和能處理的作業(yè)到達(dá)速率的增長(zhǎng)，系統(tǒng)有很好的伸縮性。

靈活性：支持高度異構(gòu)的混合作業(yè)同時(shí)運(yùn)行在普通的集群中。

可用性和可維護(hù)性：在集群中方便地兼容新的作業(yè)。部署/升級(jí)編程框架簡(jiǎn)答。

錯(cuò)誤隔離：隔離不同種作業(yè)的錯(cuò)誤，防止錯(cuò)誤的級(jí)聯(lián)。

資源利用率：提高整個(gè)集群資源的利用率。

?

集群負(fù)載的分類

為了達(dá)到以上的目的和設(shè)計(jì)出滿足要求的系統(tǒng)，我們需要對(duì)目前集群中的作業(yè)進(jìn)行一個(gè)分類：

服務(wù)任務(wù)和終止任務(wù)(Service Jobs vs Terminating Jobs)

? ? ? 服務(wù)任務(wù)是一直運(yùn)行的程序，比如web服務(wù)器和關(guān)系數(shù)據(jù)庫(kù)。

? ? ? 終止任務(wù)類似于批處理程序，它們根據(jù)一定的輸入進(jìn)行一定的處理，然后退出。

目前的資源管理系統(tǒng)一般只會(huì)處理其中的一種任務(wù)。

任務(wù)選擇率(Task pickiness)

? ? ? 任務(wù)可以選擇為其提供服務(wù)的資源的要求和偏好。

作業(yè)彈性(Job elasticity)

? ? ? 可能根據(jù)作業(yè)不同時(shí)間的負(fù)載動(dòng)態(tài)的伸縮資源。

任務(wù)和作業(yè)的持續(xù)時(shí)間(Job and task duraton)

? ? ? 終止作業(yè)可能有不同的持續(xù)時(shí)間。

任務(wù)調(diào)度時(shí)間敏感性

? ? ? 有的任務(wù)會(huì)有響應(yīng)時(shí)間的要求，這回影響到用戶體驗(yàn)。

?

集群調(diào)度的分類

目前所有的集群調(diào)度技術(shù)可以以下面的方式分類：

?

?

?單代理（Monolithic）：

集群中僅僅只有一個(gè)調(diào)度器，它串行的做出所有的調(diào)度決策。

這個(gè)是目前大多數(shù)集群管理系統(tǒng)，比如Hadoop和Torque系統(tǒng)使用的架構(gòu)，優(yōu)勢(shì)在于簡(jiǎn)單。但是有很多先天的劣勢(shì)：

1單調(diào)度策略，在伸縮性，靈活性和拓展性方面均不好。

? ? ? ? 對(duì)于混合的作業(yè)流，這個(gè)方式并不能很好適應(yīng)。批處理式的作業(yè)比較適合用非搶占的公平調(diào)度而延遲敏感的作業(yè)需要使 ? 用優(yōu)先級(jí)搶占策略，這樣的架構(gòu)不能滿足這些要求。

2單點(diǎn)故障。

3負(fù)載瓶頸。

4Head of line(HOL) blocking餓死現(xiàn)象。

?

多代理架構(gòu)

狀態(tài)分區(qū)的調(diào)度（Partitioned State Scheduling)

靜態(tài)分區(qū)

優(yōu)勢(shì)：沒(méi)有單點(diǎn)故障，等待調(diào)度延遲小，更好的錯(cuò)誤隔離。

劣勢(shì)：劣勢(shì)主要集中在靜態(tài)的分區(qū)上，比如1）一個(gè)超過(guò)一個(gè)分區(qū)的作業(yè)就不能運(yùn)行。2）一個(gè)分區(qū)可能對(duì)于一個(gè)小作業(yè)來(lái)說(shuō)太大了。3）碎片問(wèn)題

?

動(dòng)態(tài)分區(qū)

優(yōu)勢(shì)：如靜態(tài)分區(qū)，并加上其的劣勢(shì)。

劣勢(shì)：需要維護(hù)一個(gè)元數(shù)據(jù)服務(wù)器，這個(gè)元數(shù)據(jù)服務(wù)器需要上鎖，可能會(huì)有性能開銷。

以上的兩個(gè)部分分區(qū)方案就類似于數(shù)據(jù)庫(kù)中控制同步的方式中的悲觀并發(fā)控制。這種方式要求提前就把調(diào)度管理域給劃分開來(lái)。

?

復(fù)制狀態(tài)的調(diào)度（Replicated State Scheduling）

這個(gè)調(diào)度策略允許調(diào)度管理域重疊，比較像數(shù)據(jù)庫(kù)中同步控制中的樂(lè)觀并發(fā)控制。

這個(gè)架構(gòu)目前是最靈活的，但是需要更復(fù)雜的處理邏輯以及同步的控制。

總結(jié)

以上是生活随笔為你收集整理的多代理集群调度：可伸缩性和灵活性的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。