關於容量調度器(CS）和預訂系統的cs實現。基本需要通過API而不是CLI來操作，有點麻煩。 ...
本文翻譯自 http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html
和http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/ReservationSystem.html
1、目的
本文主要描述容量調度器，它是一個可拔插的插件，負責為所有的應用按照特定的限制分配資源。
2、概覽
cs（譯註：為了便於寫，把CapacitiesScheduler編寫為cs)的目的就是能夠讓hadoop應用以操作員友好的方式運行，並能夠最大化集群的吞吐和利用。
以往，每個組織都有自己私有的計算資源，並且這些資源具有足夠的容量來滿足不同時段組織的SLA。這通常會導致交叉的平均利用，並會讓管理有點不堪重負，因為如果組織多的話，那麼集群也會很多。在不同組織之間共用hadoop集群是比較划算的行為，因為不需要創建私有的集群。然後，每個組織都會關心共用的事情，因為大家都擔憂其他組織過分使用集群資源。
cs能夠讓應用共用集群，並保證應用的資源需求（譯註：保證各個應用預先分配的資源，例如不會用著用著，然後發生cpu都被其它應用霸占了之類的事情.並不是說能夠讓每個應用都可以暢快地使用所有的資源)。中心思想就是共用。此外還有一個不一樣的好處，某個時刻某個組織可以使用其它其它組織的資源--換言之，組織可以彈性利用資源。
cs提供一系列嚴格的限制來確保單個的應用/用戶/隊列無法消費過量的資源。此外，cs對用戶或者隊列的初始/掛起應用做某種限制，這樣可以確保集群的公平和穩定。
cs的首要概念是隊列(queues).這些隊列由管理員設置，隊列可以實現共用集群的共用經濟。
為了提供對資源的進一步的控制，和共用的可預見性，cs支持分層隊列（譯註：原文hierarchical ），確保在其它隊列可以利用空閑資源之前，特定組織的隊列（包括子隊列）可以共用資源，由此特定組織的的應用可以更好地共用空閑資源。
譯註：
- sla,這裡並非指hadoop的服務級別授權，而是指“服務級別協議”，具體可以參考http://www.sohu.com/a/111043704_120672 ，但可以簡單理解為“需求”
- 這個小節的中心思想就是:cs,共用，隊列，分層隊列，確保
3、特性
-
Hierarchical Queues - 分層隊列。確保在其它隊列可以利用空閑資源之前，特定組織的隊列（包括子隊列）可以共用資源，由此特定組織的的應用可以更好地共用空閑資源
-
Capacity Guarantees -容量保證。系統分配給隊列分配容量的一部分，這部分就歸特定隊列處置。隊列中的應用都可以訪問分配給隊列的容量。管理員可以為隊列配置軟限制和可選的硬限制
-
Security -安全。每個隊列都有嚴格的ACLs，acls控制誰可以提交應用到隊列中。此外，一個用戶不能看/修改其它用戶隊列的應用。
-
Elasticity - 彈性。任何隊列可以利用空閑資源，即使已經超過了自身的限額。
-
Multi-tenancy - 多租戶。有各種設置來保證資源不會被獨占，大家可以共用。
-
Operability --可操作
- 運行時配置 - 隊列定義和屬性（如容量），ACLS可以在運行時由管理員以安全的方式修改。此外為管理員和用戶提供了一個控制台，通過控制台可以查看當前資源的分配。管理員可以在運行時添加隊列，但不能刪除正在運行的隊列。（譯註：如果這樣，只能先停止應用了或者先停止隊列）
- 釋放應用- 管理員可以在運行時stop隊列，但正在運行得應用可以一致運行到完成，而新的應用不能加入隊列。如果隊列處於STOPPED狀態，那麼就無法添加新應用到隊列或者子隊列上。這樣管理員可以優雅地停止隊列. 此外，管理員可以啟動正在停止中(STOPPED)的隊列.
-
Resource-based Scheduling（基於資源的調度） - 支持資源密集應用（譯註：簡而言之就是可以不同需求給予不同資源）. 目前支持的資源只有記憶體。
-
Queue Mapping based on User or Group - 基於用戶/組的隊列映射 。換言之，不同的用戶或者組所提到的作業會對應到不同隊列，適當程度簡化了操作。
-
Priority Scheduling 優先權調度- 不同應用可以按照不同的優先權調度。應用的優先權值越大，優先順序越高。目前，應用優先權只支持FIFO策略。譯註：應該指的是在先按照優先權排序的情況下，最大優先權的的可以進入FIFO堆棧，但絕對不能插隊。
4、配置
4.0 使用容量調度器
修改yarn-site.xml
yarn.resourcemanager.scheduler.class 取值 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
4.1 配置隊列
etc/hadoop/capacity-scheduler.xml
cs有個預定義的隊列root。所有的隊列都是這個隊列的子隊列。
其它隊列可以通過yarn.scheduler.capacity.root.queues配置，多個隊列以逗號分隔。
使用隊列路徑來設定隊列的層級。隊列路徑必須是全路徑，以root開始，使用點號作為分隔符。
特定的子隊列可以使用以下形式定義yarn.scheduler.capacity.<queue-path>.queues。子隊列並不繼承上級隊列的屬性，除非有特別說明。
以下是一個例子，有3個頂級子隊列a,b,c。a，b有一些子隊列：
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b,c</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.queues</name>
<value>a1,a2</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.queues</name>
<value>b1,b2,b3</value>
<description>The queues at the this level (root is the root queue).
</description>
</property>
4.2 隊列屬性
- 資源分配
| 屬性 | 描述 |
|---|---|
| yarn.scheduler.capacity.<queue-path>.capacity |
容量百分比，可以有小數位。但所有隊列的和必須是100。但如果系統有空閑資源，隊列中的應用實際是可能耗費比限定的份兒跟多的資源，這就是彈性。 |
| yarn.scheduler.capacity.<queue-path>.maximum-capacity |
隊列允許使用的最大份額百分比。預設-1，就是不允許。 |
| yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent |
隊列中用戶的資源下限（百分比-但必須是整數）。用戶實際使用的資源可能介於兩個限制點之間。一個隊列可能包含了多個用戶的應用，那麼如果一個隊列有2個提交了應用的用戶， 那麼可以限制50,3個就是33,3個就是25，諸如此類。如果設置為100（預設），那麼就是不做限制，這樣占先用。 |
| yarn.scheduler.capacity.<queue-path>.user-limit-factor |
定義某個用戶可以使用的容量倍數。預設是1，就是隊列容量的全部。這個值可以帶小數。 譯註：這應該是一個<=1的值。 |
| yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb |
資源可以管理器分配給容器的最大記憶體（分配對隊列的最大記憶體）。這個設置會覆蓋 yarn.scheduler.maximum-allocation-mb。但必須小於等於集群的最大限額。 |
| yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores |
最大的虛擬核(virtual core).覆蓋 yarn.scheduler.maximum-allocation-vcores，但必須小於等於後者。 |
- 運行和掛起應用
| Property | Description |
|---|---|
|
yarn.scheduler.capacity.maximum-applications yarn.scheduler.capacity.<queue-path>.maximum-applications |
系統併發的正在運行和掛起的應用總數，預設是10000. yarn.scheduler.capacity.<queue-path>.maximum-applications可以覆蓋 yarn.scheduler.capacity.maximum-applications的值，但值只能小於等於後者。 取值為整數。 |
|
yarn.scheduler.capacity.maximum-am-resource-percent yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent |
am可以使用的最大資源百分比（用於併發的活動應用）。取值為浮點數，例如0.5，表示50%。 yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent可以覆蓋 yarn.scheduler.capacity.maximum-am-resource-percent，但取值必須小於等於後者。 |
譯註：每一行，有兩個屬性
- 隊列管理和許可權
| Property | Description |
|---|---|
| yarn.scheduler.capacity.<queue-path>.state |
設置隊列的狀態，可以是RUNNING/STOPPED.如果是後者，則隊列不能增加新應用，但現有運行得應用可以一致運行到結束。 |
| yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications |
隊列提交應用許可權列表acl--控制誰可以提交應用。如果用戶/組有隊列（或者升級隊里的）acl許可權，那麼就可以提交應用。 如果沒有設定，那麼從其上級繼承。 |
| yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue |
控制誰可以管理隊列的應用。 其它方式同上一行屬性。 譯註：原文沒有說如何管理。停止，刪除？ |
註：這個acl的格式不同於hdfs文件的acl格式。*表示任何人，space表示沒有人。對於root隊列來說，如果沒有設定，預設是*
- 基於用戶/組的隊列隱射
| Property | Description |
|---|---|
| yarn.scheduler.capacity.queue-mappings |
語法 [u or g]:[name]:[queue_name][,next_mapping]* 列表可以多個，之間以逗號分隔。 %user放在[name]部分，表示已經提交應用的用戶。 如果隊列名稱和用戶一樣，那可以使用%user表示隊列。 如果隊列名稱和用戶主組一樣，可以使用%primary_group表示隊列。 譯註：這個語法有點怪異 |
| yarn.scheduler.capacity.queue-mappings-override.enable |
定義針對特定用戶的隊列是否可以被覆蓋。預設是false. 譯註：沒有說明如何覆蓋 |
例子：
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user1:queue1,g:group1:queue2,u:%user:%user,u:user2:%primary_group</value>
<description>
Here, <user1> is mapped to <queue1>, <group1> is mapped to <queue2>,
maps users to queues with the same name as user, <user2> is mapped
to queue name same as <primary group> respectively. The mappings will be
evaluated from left to right, and the first valid mapping will be used.
u:%user:%user ---已經提交應用的用戶，映射到和用戶名稱一樣的隊列上。
u:user2:%primary_group --user2提交的應用映射到user2主組名稱一樣的隊列上。
</description>
</property>
譯註：如果用戶組並不多，隊列也不多，建議還是使用簡單的語法，而不要使用帶%的，後者有點混，而且還不知道是否會導致異常。
4.3 配置應用優先權
應用優先和FIFO排序策略一起工作。
Default priority for an application can be at cluster level and queue level.
應用的預設優先權可以設定集群或者隊列級別。
- 集群級別 : 定義了整個集群的最大優先權（整數值），具體原因的優先全如果大於它，那麼就以集群最大優先權為準。. $HADOOP_HOME/etc/hadoop/yarn-site.xml 配置了這個值.
| Property | Description |
|---|---|
| yarn.cluster.max-application-priority | Defines maximum application priority in a cluster. |
- 葉子隊列級別 : $HADOOP_HOME/etc/hadoop/capacity-scheduler.xml 可以配置這個葉子級別的。
| Property | Description |
|---|---|
| yarn.scheduler.capacity.root.<leaf-queue-path>.default-application-priority | Defines default application priority in a leaf queue. |
註意: 如果應用移動到不同的隊列，其優先權不會改變
4.4 容量調度容器搶占
cs支持容器搶占，就是如果有一些隊列使用了超限的資源，那麼這些超限的資源是可以被搶走的。
- yarn-site.xml 的配置
| Property | Description |
|---|---|
| yarn.resourcemanager.scheduler.monitor.enable |
啟用監視程式。預設不啟用 譯註：應該設置為true |
| yarn.resourcemanager.scheduler.monitor.policies |
監視策略 預設值是 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy |
如果yarn.resourcemanager.scheduler.monitor.policies的取值是org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy
- 那麼可以配置一下屬性（同樣是在yarn-site.xml中）
| Property | Description |
|---|---|
| yarn.resourcemanager.monitor.capacity.preemption.observe_only |
眼觀手不動-不搶也不殺事件。預設是false. 譯註：應該設置為true |
| yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval |
監視間隔（輪詢/掃描間隔），預設是3000毫秒。 |
| yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill |
從發出搶占請求到殺掉容器的時間，預設是15000毫秒 |
| yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round |
一個回合中，搶占的最大的資源百分比。通過控制這個值，就可以限制從集群申請容器的步伐。 在計算總的期望搶占（需求）後，策略會要求總和必須小於=這個值。預設是0.1 譯註：這個比率必須乘以100，才是百分比。 |
| yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity |
如果無法搶占那麼多，那麼可以少搶多少？ 這個值積極的一面是可以防止可能無法搶到。 如果這個值比較高，那麼可能無法那麼快搶到需要的容量。預設是0.1 |
| yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor |
自然終止搶占百分比(差額）. 對於一個計算過的搶占， 由於容器自然過期，那麼就只會搶占這個比率的差額。 這個確定了幾何比率（這個比率和MAX_IGNORED_OVER_CAPACITY有關）。 李I如，如果因數是0.5(就是5%），那麼差額就是95%. 那麼在 5 * #WAIT_TIME_BEFORE_KILL間隔內，就會申請幾乎95%的資源，即使沒有自然終止（其它的應用或者容器）。 預設值是0.2（2%）。 譯註：這個定義挺奇怪的。 |
- capacity-scheduler.xml 中關於已經屬於隊列的應用容器搶占配置 。
| Property | Description |
|---|---|
| yarn.scheduler.capacity.<queue-path>.disable_preemption |
是否禁止搶占已經屬於隊列的應用容器。 僅當以下兩個屬性設置如下的時候，本屬性才啟用： yarn.resourcemanager.scheduler.monitor.enable = true yarn.resourcemanager.scheduler.monitor.policies = org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy 如果特定隊列沒有設定，就從上級隊列繼承。 預設是false(譯註：就是可以搶) |
- 保留管理
cs可以通過參數來控制創建，刪除，更新和列出預留信息。註意，任何人都可以這麼做，只要有許可權（自己的可以操縱自己的）。如果有啟用預留acl,但又沒有定義，那麼任何人都可以操作。
在下麵這個例子中，<queue>是隊列名稱。
| Property | Description |
|---|---|
| yarn.scheduler.capacity.root.default.acl_administer_reservations | 設置預設隊列的管理acl |
| yarn.scheduler.capacity.root.<queue>.acl_administer_reservations |
這個ACL具有全部許可權：創建，刪除，修改和列出。 這個許可權不繼承上級的，除非有特定說明（譯註：如何特別說明） 譯註：文檔並沒有給出acl的示例。但根據本文多次出現過的經驗來看，也許是“u:user1:queue1,g:group1:queue2”這樣形式的。 |
| yarn.scheduler.capacity.root.<queue>.acl_list_reservations |
查看許可權。 這個許可權不繼承上級的，除非有特定說明（譯註：如何特別說明） |
| yarn.scheduler.capacity.root.<queue>.acl_submit_reservations |
提交（創建） 這個許可權不繼承上級的，除非有特定說明（譯註：如何特別說明） |
譯註：上表的屬性中包含了<queue>而不是<queue-path>,當時原文作者的疏忽所致。本人認為，這應該修改為<queue-path>更好，更容易理解，也可以保持全文一致。
4.5 使用容量調度器配置預訂系統
cs支持預訂系統-允許用戶預留資源。
應用可以在運行時（提交）設定 reservationId，以請求保留的資源。
- yarn-site.xml 中的配置
| Property | Description |
|---|---|
| yarn.resourcemanager.reservation-system.enable |
是否啟用預訂(非空） 預設為否(false) 取值true/false |
| yarn.resourcemanager.reservation-system.class |
預訂類（可選） 如果沒有設置，就直接取 yarn-site.xml中yarn.resourcemanager.scheduler.class屬性值。 譯註：cs的話，就取 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler |
| yarn.resourcemanager.reservation-system.plan.follower |
PlanFollower類名，用於定時同步cs（可選參數） 取值和yarn.resourcemanager.scheduler.class屬性值有關。 如果cs，那麼取值org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacitySchedulerPlanFollower |
| yarn.resourcemanager.reservation-system.planfollower.time-step |
PlanFollower定時器的間隔(毫秒-整數，可選參數）。 預設是1000毫秒 |
- capacity-scheduler.xml中的配置
cs支持預訂，而且可以在任意葉子隊列上配置。
| Property | Description |
|---|---|
| yarn.scheduler.capacity.<queue-path>.reservable |
是否可以預訂（非空） 預設false(不可以） 譯註：因為設置就是為了預訂，所以一般設定為true |
| yarn.scheduler.capacity.<queue-path>.reservation-agent |
預訂代理（類名），用於確定預訂代理是否已經實現。 預設值：org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy. |
| yarn.scheduler.capacity.<queue-path>.reservation-move-on-expiry |
可選參數 當有關的預訂過期後，應用是否要移動到上級可預訂的隊列（或者是被殺掉） 預設是true. |
| yarn.scheduler.capacity.<queue-path>.show-reservations-as-queues |
可選參數 是否在調度器UI中顯示預訂隊列。 預設false（不顯示） |
| yarn.scheduler.capacity.<queue-path>.reservation-policy |
預訂策略類（可選參數） 用於確定共用策略是否實現了，這個共用策略負責驗證新的預訂沒有破壞標準。 預設值是org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy. |
| yarn.scheduler.capacity.<queue-path>.reservation-window |
預留視窗(可選參數） 單位毫秒（必須是整數） 共用策略類在這個視窗內會驗證計劃中約束是否通過。 預設是1天（86400000) |
| yarn.scheduler.capacity.<queue-path>.instantaneous-max-capacity |
瞬間最大容量（可選參數） 實際是任意時間，單位是比率（但不是百分比） 共用策略允許單個用戶保留的最大容量 預設是1，也就是100%. |
| yarn.scheduler.capacity.<queue-path>.average-capacity |
平均容量（可選參數） 在預訂視窗內，共用策略允許單個用戶保留的平均容量。 預設是1（100%） |
| yarn.scheduler.capacity.<queue-path>.reservation-planner |
預訂計劃執行程式（類，可選） 用於確認計劃程式的實現情況，如果計劃容量低於用於預訂的，那麼這個類會被激活。 預設值 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner 這個類被激活後，會掃描計劃，並按照LIFO的順序儘可能地移除預留的容量，直到預留的資源達到了計劃要求。 譯註：LIFO--即後進先出。 |
| yarn.scheduler.capacity.<queue-path>.reservation-enforcement-window |
預留強制視窗（可選） 計劃程式在這個時間視窗內，會驗證計劃限定是否被滿足了。 整數類型，單位毫秒 預設是1小時即3600000 |
譯註：具體如何預訂，並不是僅僅這幾個參數。實際實現的時候，還需要結合一些其它操作,例如yarn關於rm的REST API
也許以後，yarn自己會提供cli工具直接申請預訂並提交作業，目前來看，需要通過編程來實現。
但很多時候，如果不直接使用yarn的話，也不需要考慮這個，例如使用spark,presto的時候，它們可以和yarn一起部署。
預訂系統更多的內容可以參閱 http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/ReservationSystem.html
4.6 其它屬性
- 資源計算器
| Property | Description |
|---|---|
| yarn.scheduler.capacity.resource-calculator |
資源計算器類-比較調度器中的資源。 例如org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator僅僅計算記憶體，而DominantResourceCalculator會使用記憶體，cpu等等。 譯註：目前還是使用 org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator 吧。 因為有關的實現主要基於記憶體的。 yarn的資源管理還是比較初級的。 |
- 數據本地性
| Property | Description |
|---|---|
| yarn.scheduler.capacity.node-locality-delay |
節點局部性延遲 在cs企圖調度本地機棧容器後(失敗），還可以錯過錯過多少次的調度次數。 通常設置為集群節點數。 預設情況下，應該設置為基站中節點數，例如40（一個機棧可能有40台）。 譯註：調度器在本地機棧找資源，可以在機棧內的節點一個個找過去。所以可以嘗試那麼多次。 由於沒有看有關的代碼，並不清楚具體如何一個個找的。 |
4.7 回顧容量調度器配置
一旦按照配置完畢，這些配置可以通過yarn的WEB-UI來查看：
-
以常規模式啟動yarn
-
打開rm的web-ui
-
找到 /scheduler 頁面，就可以看到隊列和有關資源.
5、修改隊列配置
修改隊列屬性，添加隊列是非常簡單。只需要編輯conf/capacity-scheduler.xml,並執行 yarn rmadmin -refreshQueues
$ vi $HADOOP_CONF_DIR/capacity-scheduler.xml
$ $HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues
註意: 隊列不能刪除，但可以添加新的，更新也是可以的。
譯註：不需要修改所有節點上的，因為rmadmin會自動做那個事情。此外如何刪除隊列？難道要靠重配，重啟yarn集群嗎？
以下內容翻譯自 http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/ReservationSystem.html
6、預訂系統
譯註：本文已經省略掉一些原文的內容
流程圖
典型預訂流程：
- Step 0 用戶提交一個預訂創建請求，並接收到一個響應，響應包含一個ReservationId（預訂ID)
-
Step 1 用戶提交一個預訂請求（使用 Reservation Definition Language (RDL) --預定定義語言）和預訂ID，請求包括諸如資源和暫時約束（例如截止時間）。這個提交可以使用編程方式完成，編程方式包括使用客戶端到RM的協議或者RM REST api 。如果相同的RDL內容和預訂ID提交做了多次，但是是無用的，系統不會創建新的預留，雖然系統的提示是成功的。如果僅僅RDL不同，那麼會被拒絕。
-
Step 2 預訂系統啟動一個預訂代理（ReservationAgent,上圖綠色的。譯註：原文說綠色，但本文看到的是藍色的），從PLAN（計劃中）找一可用的分配，所謂PLAN(計劃）就是一個數據結構，記錄了所有已經接收的預訂和系統中的可用資源。
-
Step 3 共用策略提供一個途徑來強制收到的預留是恆定的（至少是符合要求的），而這個收到的可能是潛在會被拒絕的。 例如，CapacityOvertimePolicy會允許用戶的瞬時最大容量，但一段時間內又會做一定的限制 。例如用戶的瞬時請求可以是50%的集群容量，但在24小時內，均值不能超過10% 。
-
Step 4 成功驗證後，預訂系統會返回給用戶一個預訂ID（可以比作一張車票）
-
Step 5 當預訂時間到達，部件PlanFollower（後續計劃程式）把計劃的狀態推送給調度器 ，推送方式是動態創建/ 調整/銷毀隊列。
-
Step 6 然後用戶可以提交一個或者多個作業給預留隊列，提交的時候只需要簡單地包含預訂ID即可。
-
Step 7 調度器會提供一些容器（這些容器已經預先創建，用於滿足預訂需求）。在預訂限制內，用戶可以隨意使用資源。
-
Step 8 系統包含適應/脫離集群容量的機制。包括如果可能就移動預留，或者拒絕一些最小量的請求
譯註：總體上預訂的實現分為幾個步驟：
1.預訂
2.執行，包含提交計劃和調整共用。
3.脫離（完結）
