《Hadoop權威指南：大數據的存儲與分析》—4.3.2 容量調度器配置

4.3.2? 容量調度器配置

容量調度器允許多個組織共享一個Hadoop集群，每個組織可以分配到全部集群資源的一部分。每個組織被配置一個專門的隊列，每個隊列被配置為可以使用一定的集群資源。隊列可以進一步按層次劃分，這樣每個組織內的不同用戶能夠共享該組織隊列所分配的資源。在一個隊列內，使用FIFO調度策略對應用進行調度。

正如圖4-3所示，單個作業使用的資源不會超過其隊列容量。然而，如果隊列中有多個作業，并且隊列資源不夠用了呢？這時如果仍有可用的空閑資源，那么容量調度器可能會將空余的資源分配給隊列中的作業，哪怕這會超出隊列容量。[1]這稱為“彈性隊列”(queue elasticity)。

正常操作時，容量調度器不會通過強行中止來搶占容器(container)[2]。因此，如果一個隊列一開始資源夠用，然后隨著需求增長，資源開始不夠用時，那么這個隊列就只能等著其他隊列釋放容器資源。緩解這種情況的方法是，為隊列設置一個最大容量限制，這樣這個隊列就不會過多侵占其他隊列的容量了。當然，這樣做是以犧牲隊列彈性為代價的，因此需要在不斷嘗試和失敗中找到一個合理的折中。

假設一個隊列的層次結構如下：

root

├─prod

└─dev

├─ eng

└─ science

范例4-1是一個基于上述隊列層次的容量調度器配置文件，文件名為capacity-scheduler.xml。在root隊列下定義兩個隊列：prod和dev，分別占40%和60%的容量。需要注意的是，對特定隊列進行配置時，是通過以下形式的配置屬性yarn.scheduler.capacity..進行設置的，其中, 表示隊列的層次路徑(用圓點隔開)，例如root.prod。

范例4-1. 容量調度器的基本配置文件

yarn.scheduler.capacity.root.queues

prod,dev

yarn.scheduler.capacity.root.dev.queues

eng,science

yarn.scheduler.capacity.root.prod.capacity

40

yarn.scheduler.capacity.root.dev.capacity

60

yarn.scheduler.capacity.root.dev.maximum-capacity

75

yarn.scheduler.capacity.root.dev.eng.capacity

50

yarn.scheduler.capacity.root.dev.science.capacity

50

可以看到，dev隊列進一步被劃分成eng和science兩個容量相等的隊列。由于dev隊列的最大容量被設置為75%，因此即使prod隊列空閑，dev隊列也不會占用全部集群資源。換而言之，prod隊列能即刻使用的可用資源比例總是能達到25%。由于沒有對其他隊列設置最大容量限制，eng或science中的作業可能會占用dev隊列的所有容量(將近75%的集群資源)，而prod隊列實際則可能會占用全部集群資源。

除了可以配置隊列層次和容量，還有些設置是用來控制單個用戶或應用能被分配到的最大資源數量、同時運行的應用數量及隊列的ACL認證等。關于容量調度器配置的更多內容，請參見http://bit_ly/capacity_schedular。

將應用放置在哪個隊列中，取決于應用本身。例如，在MapReduce中，可以通過設置屬性mapreduce.job.queuename來指定要用的隊列。如果隊列不存在，則在提交時會發送錯誤。如果不指定隊列，那么應用將被放在一個名為“default”的默認隊列中。

對于容量調度器，隊列名應該是隊列層次名的最后一部分，完整的隊列層次名是不會被識別的。例如，對于上述配置范例，prod和eng是合法的隊列名，但root.dev.eng 和 dev.eng作為隊列名是無效的。

大數據 容器 Hadoop

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

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