hadoop-2.2.0多個隊列資源分配

文章內容來源：http://blog.163.com/yangshaohui_2004/blog/static/618545020144711438505/

在yarn-site.xml屬性：

• yarn.scheduler.fair.allow-undeclared-pools

• 如果這是true，新的隊列可以在提交申請時被創建，無論是因為它們是由提交者指定為應用程序的隊列中，或者因為它們是由用戶的默認隊列屬性放在那里。如果此為假，任何時間的應用程序將被放置在一個未在該分配文件中指定一個隊列，它被放置在“默認”的隊列來代替。默認為true。如果隊列放置策略中給出了配置文件，則忽略此屬性。

• 配置文件格式

  配置文件必須是XML格式。該格式包含了五種類型的元素：

• 隊列中的元素，它們代表的隊列。每一個都可以包含下面的屬性：
  • minResources：最少的資源隊列有權在形式的“X MB，Y vcores”。對於單資源公平性的政策，在vcores值將被忽略。如果一個隊列的最低份額不滿意，將根據之前同一母公司提供可用資源的任何其他隊列。當下資源的公平策略隊列被認為是不滿意的，如果它的內存使用量低於其最低內存份額。就失去優勢資源公平性，一個隊列被認為是不滿意的，如果它的使用，它的相對於所述簇的容量優勢資源低於它的最低份額該資源。如果多個隊列不滿意在這種情況下，資源進入隊列有關的資源使用情況和最小值之間的最小比率。注意，有可能是一個隊列，即低於其最小可能不會立即起床到最小，當它提交的申請，因為已經運行的作業可以利用這些資源。
  • maxResources：最大的資源隊列是允許的，在形式的“X MB，Y vcores”。對於單資源公平性的政策，在vcores值將被忽略。隊列永遠不會被分配一個容器，將其放在總使用量超過此限制。
  • maxRunningApps：從隊列限制的應用程序的數量，同時運行
  • 重量：與其他隊列非按比例分擔集群。權值默認為1，而與體重2隊列應收取約兩倍的資源作為一個與默認權重隊列。
  • schedulingPolicy：設置任何隊列的調度策略。允許的值是“先進先出”/“公平”/“DRF”或 ??擴展任何類org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy。默認為“公平”。如果“先進先出”，應用程序與先前提交時間以偏愛的容器，但后來提交的應用程序可以同時運行，如果有剩余的空間集群在滿足前面的應用程序的請求后。
  • aclSubmitApps：用戶和/或可以提交應用程序的隊列組的列表。請參考下面的ACL部分在此列表的格式和隊列是如何工作的ACL的詳細信息。
  • aclAdministerApps：用戶和/或組可管理一個隊列的列表。目前唯一的行政行為是殺一個應用程序。請參考下面的ACL部分在此列表的格式和隊列是如何工作的ACL的詳細信息。
  • minSharePreemptionTimeout：秒數隊列是根據它的最小份額的時候，才試圖搶占容器，以使資源從其他隊列。
• 用戶元件，它代表設置管用戶個性化的行為。它們可以包含一個屬性：maxRunningApps上運行的應用程序對特定用戶數量的限制。
• 一個userMaxAppsDefault元素，它設置默認運行的應用程序的限制是不是另有規定的限制的任何用戶。
• 一個fairSharePreemptionTimeout元素，幾秒鍾的隊列號是其公平份額下的時候，才嘗試搶占容器，以使資源從其他隊列。
• 一個defaultQueueSchedulingPolicy元素，它設置為隊列默認的調度策略; 如果所指定的每個隊列的schedulingPolicy元素覆蓋。默認為“公平”。
• 一個queuePlacementPolicy元素，其中包含告訴調度程序如何進入的應用程序放置到隊列規則元素的列表。規則的應用，因為它們列出的順序。規則可能需要的參數。所有規則接受“創造”的說法，這表示規則是否可以創建一個新的隊列。“創建”默認為true; 如果設置為false，該規則將放在未在配置文件中配置一個隊列的應用程序，我們繼續到下一個規則。最后一條規則必須是一個永遠無法發出繼續。有效的規則是：
  • 規定：應用程序被放置到它要求隊列中。如果應用程序要求沒有隊列，也就是說，它指定了“default”，我們繼續。
  • 用戶：應用程序被放置到一個與誰提交它的用戶的名稱隊列。
  • primaryGroup：應用程序被放置到一個隊列，誰提交它的用戶的主組的名稱。
  • secondaryGroupExistingQueue：應用程序被放置到一個有一個與誰提交了用戶的次要組名的隊列。符合配置的隊列中的第一次要組將被選中。
  • 默認：應用程序被放置到一個名為“默認”的隊列。
  • 拒絕：應用程序被拒絕。

  這里有一個例子配置文件中給出：

• <?xml version="1.0"?>
  <allocations>
    <queue name="sample_queue">
      <minResources>10000 mb,0vcores</minResources>
      <maxResources>90000 mb,0vcores</maxResources>
      <maxRunningApps>50</maxRunningApps>
      <weight>2.0</weight>
      <schedulingPolicy>fair</schedulingPolicy>
      <queue name="sample_sub_queue">
        <aclSubmitApps>charlie</aclSubmitApps>
        <minResources>5000 mb,0vcores</minResources>
      </queue>
    </queue>
    
    <user name="sample_user">
      <maxRunningApps>30</maxRunningApps>
    </user>
    <userMaxAppsDefault>5</userMaxAppsDefault>
    
    <queuePlacementPolicy>
      <rule name="specified" />
      <rule name="primaryGroup" create="false" />
      <rule name="default" />
    </queuePlacementPolicy>
  </allocations>

請注意，為了與原來的FairScheduler兼容性，“ queue”元素可以代替其命名為“pool”的元素。

隊列的訪問控制列表（ACL）

隊列的訪問控制列表（ACL）允許管理員控制誰可以采取行動，特別是隊列。它們被配置成與aclSubmitApps和aclAdministerApps特性，這可以為每個隊列被設置。目前只支持行政行為被殺死的應用程序。誰可以管理一個隊列中任何人也可以提交申請了。這些屬性需要像“用戶1，用戶2組1，組2”或“組1，組2”的格式值。如果它的用戶或組是在該隊列的訪問控制列表或任何該隊列的祖先ACL在一個隊列動作將被允許。所以，如果隊列2是內部隊列1，而user1的隊列1的ACL，和user2是在隊列2的ACL，那么這兩個用戶可以向隊列2。

根隊列的ACL是“*”，其中，因為ACL是傳下來的默認值，也就是說，每個人都可以提出來，並從每個隊列殺應用程序。要開始限制訪問，修改root隊列的ACL來的東西比“*”等。