這是CDP中Yarn使用系列中的一篇，之前的文章請參考使用YARN Web UI和CLI>和CDP 中配置Yarn的安全性>。
您可以透過排程分配資源、透過配置 cgroup 限制 CPU 使用、使用分割槽將叢集劃分為子叢集以及在 Docker 容器上啟動應用程式來管理叢集上執行的應用程式的資源。
該CapacityScheduler負責排程。所述 CapacityScheduler用於在操作員友好的方式執行的應用程式的Hadoop作為共享，多租戶簇同時最大化吞吐量和叢集的利用率。
該ResourceCalculator是yarn的部分CapacityScheduler。如果您只有一種型別的資源，通常是 CPU 虛擬核心 （vcore），請使用 DefaultResourceCalculator。 如果您有多種資源型別，請使用 DominantResourceCalculator。
多種資源型別的YARN資源分配
您可以使用 YARN 中的容量排程程式來管理叢集容量。您可以使用容量排程程式的DefaultResourceCalculator或 DominantResourceCalculator來分配可用資源。
YARN 中排程的基本單位是佇列。每個佇列的容量指定了可用於提交到佇列的應用程式的叢集資源的百分比。您可以在反映使用叢集資源的組織、組和個人所需的資料庫結構、資源要求和訪問限制的層次結構中設定佇列。
當您希望資源計算器僅考慮用於資源計算的可用記憶體時，您可以使用預設資源計算器。使用預設資源計算器 （ DefaultResourceCalculator） 時，將根據可用記憶體分配資源。
如果您有多種資源型別，請使用主導資源計算器 （ DominantResourceCalculator） 來啟用 CPU、GPU 和記憶體排程。主導資源計算器基於資源分配的主導資源公平 （DRF） 模型。DRF 旨在在混合工作負載叢集中在不同型別的程序之間公平地分配 CPU 和記憶體資源。
例如，如果使用者 A 執行 CPU 密集型任務，使用者 B 執行記憶體密集型任務，則 DRF 為使用者 A 執行的任務分配更多 CPU 和更少記憶體，為使用者 B 執行的任務分配更少 CPU 和更多記憶體。 在單個資源情況下，所有作業都請求相同的資源，DRF 會降低該資源的最大-最小公平性。
分層佇列特徵
在設定容量排程程式分層佇列之前，您必須考慮它們的各種特徵。
有兩種型別的佇列：父佇列和葉佇列。
父佇列支援跨組織和子組織的資源管理。它們可以包含更多的父佇列或葉佇列。他們自己不直接接受任何申請提交。
葉佇列是位於父佇列下並接受應用程式的佇列。葉佇列沒有任何子佇列，因此沒有任何以“。queues”結尾的配置屬性。
有一個不屬於任何組織的頂級父根佇列，而是代表叢集本身。
使用父佇列和葉佇列，管理員可以為各種組織和子組織指定容量分配。
佇列之間的排程
分層佇列確保在任何剩餘的空閒資源與屬於其他組織的佇列共享之前，首先在組織的子佇列之間共享有保證的資源。這使每個組織都能夠控制其保證資源的使用。
在層次結構中的每個級別，每個父佇列都根據需要以排序的方式儲存其子佇列的列表。佇列的排序由當前使用的每個佇列容量的部分決定（如果任意兩個佇列的保留容量相等，則由全路徑佇列名稱決定）。
根隊列了解叢集容量需要如何在第一級父佇列之間分配，並對其每個子佇列呼叫排程。
每個父佇列將其容量限制應用於其所有子佇列。
葉佇列儲存活動應用程式列表（可能來自多個使用者）並以 FIFO（先進先出）方式排程資源，同時遵守為單個使用者指定的容量限制。
申請預留
對於資源密集型應用程式，如果節點的可用容量可以滿足特定應用程式的要求，則容量排程程式會在叢集節點上建立預留。這確保資源僅由該特定應用程式使用，直到滿足應用程式預留。
容量排程器負責將叢集中的空閒資源與應用程式的資源需求進行匹配。很多時候，一個排程週期會發生，即使節點上有空閒資源，它們的大小也不足以滿足應用程式在佇列頭部等待資源的需求。這通常發生在高記憶體應用程式中，這些應用程式對容器的資源需求遠大於叢集中執行的典型應用程式。這種不匹配會導致這些資源密集型應用程式匱乏。
容量排程程式預留功能解決了這個問題，如下所示：
當一個節點報告一個完成的容器時，容量排程器會根據容量和最大容量設定選擇一個合適的佇列來利用新的可用資源。
在選定的佇列中，容量排程程式按照 FIFO 順序檢視應用程式以及使用者限制。一旦發現有需要的應用程式，容量排程器就會嘗試檢視該節點的可用容量是否可以滿足該應用程式的要求。
如果大小不匹配，Capacity Scheduler 會立即在節點上為應用程式所需的 Container 建立預留。
一旦為節點上的應用程式預留了資源，容量排程器就不會將這些資源用於任何其他佇列、應用程式或容器，直到應用程式預留完成。
進行預留的節點在足夠多的 Container 完成執行時進行報告，以便節點上的總可用容量現在與預留大小匹配。發生這種情況時，容量排程程式將預留標記為已完成，將其刪除，並在節點上分配一個容器。
在某些情況下，另一個節點會滿足應用程式所需的資源，因此應用程式不再需要第一個節點上的預留容量。在這種情況下，預留將被簡單地取消。
為了防止預留數量以無限方式增長，並避免任何潛在的排程死鎖，容量排程器在每個節點上一次僅維護一個活動預留。
資源分發工作流
在排程期間，層次結構中任何級別的佇列都按照其當前使用容量的順序進行排序，可用資源從當前服務不足的佇列開始分配。
僅就效能而言，資源排程具有以下工作流程：
佇列服務不足的情況越多，它在資源分配期間獲得的優先順序就越高。服務不足的佇列是已用容量與叢集總容量之比最小的佇列。
任何父佇列的已用容量被定義為其所有後代佇列的已用容量的總和，遞迴地。
葉佇列的已用容量是該佇列中執行的所有應用程式的分配容器所使用的資源量。
一旦決定為父佇列提供當前可用的空閒資源，就會遞迴地進行進一步的排程，以確定哪個子佇列可以使用這些資源——基於先前描述的已用容量概念。
進一步的排程發生在每個葉佇列內，以按 FIFO 順序將資源分配給應用程式。
這還取決於位置、使用者級別限制和應用程式限制。
一旦選擇了葉佇列中的應用程式，排程也發生在應用程式中。應用程式可能具有不同的資源請求優先順序。
為確保彈性，已配置但由於缺乏需求而未被任何佇列使用的容量會自動分配給需要資源的佇列。
相對模式下的資源分配過程 - 示例
要了解資源分配工作流，請考慮一個 100 節點叢集的示例，每個叢集為 YARN 容器分配 10 GB 記憶體，叢集總容量為 1000 GB （1 TB）。
例如，在相對分配模式下，“工程”組織分配了叢集容量的 60%，即絕對容量 600 GB。同樣，“支援”組織分配 100 GB，“營銷”組織分配 300 GB。
在“工程”組織下，容量在“開發”團隊和“qa”團隊之間以1：4的比例分配。所以“開發”得到120GB，480GB分配給“qa”。
現在考慮以下事件的時間線：
最初，整個“工程”佇列是空閒的，沒有執行任何應用程式，而“支援”和“營銷”佇列則充分利用了它們的容量。
使用者 Sid 和 Hitesh 首先向“開發”葉佇列提交應用程式。它們的應用程式具有彈性，可以使用叢集中的所有可用資源或叢集資源的子集（取決於資源使用狀態）執行。
即使“開發”佇列分配了 120 GB，Sid 和 Hitesh 也被允許各自佔用 120 GB，總共 240 GB。
儘管“開發”佇列配置為以 120 GB 的容量執行，但仍可能發生這種情況。容量排程器允許叢集資源的彈性共享，以更好地利用可用的叢集資源。由於“工程”佇列中沒有其他使用者，因此允許 Sid 和 Hitesh 使用可用的空閒資源。
接下來，使用者Jian、Zhijie 和Xuan 向“開發”葉子佇列提交了更多應用程式。即使每個限制為 120 GB，佇列中的總使用容量也變為 600 GB —— 實質上接管了分配給“qa”葉佇列的所有資源。
使用者 Gupta 現在向“qa”佇列提交申請。由於叢集中沒有可用資源，使用者的應用程式必須等待。
鑑於“開發”佇列正在使用所有可用的叢集資源，Gupta 可能會也可能不會立即取回他的“qa”佇列的保證容量——這取決於是否啟用了搶佔。
隨著Sid、Hitesh、Jian、Zhijie、Xuan 的應用程式執行完畢，資源可用，新的可用Container 將分配給Gupta 的應用程式。
這將一直持續到叢集穩定在“開發”和“qa”佇列的預期 1：4 資源使用率。
從這個例子可以看出，濫用使用者有可能不斷提交應用程式，從而鎖定其他佇列的資源分配，直到容器完成執行或被搶佔。為了避免這種情況，Capacity Scheduler 支援限制任何佇列的彈性增長。例如，您可以透過設定最大容量屬性來限制“開發”佇列獨佔“工程”佇列容量。
根據本示例設定最大容量屬性，請執行以下操作：
在 Cloudera Manager 中，選擇叢集 > YARN 佇列管理器 UI 服務。圖形佇列層次結構顯示在
概覽
選項卡中。
單擊開發佇列上的三個垂直點，然後選擇Edit Child Queues選項。
在配置值欄位中輸入40。
點選儲存。
設定後，“開發”佇列的使用者仍然可以超出其 120 GB 的容量，但不會為他們分配超過“工程”父佇列容量的 40%（即 600 GB 的 40%） = 240 GB）。
容量和最大容量屬性可用於控制使用 YARN 叢集的組織和子組織之間的共享和彈性。管理員應該平衡這些屬性以避免導致利用率損失的嚴格限制，並避免過度的跨組織共享。
資源分配概覽
您可以使用 Absolute 模式（其中分配 vCore 和記憶體資源的實際單位）、Relative 模式（其中資源按總資源的百分比分配）或權重模式（其中分配資源）為佇列分配資源。資源作為總資源的一部分進行分配。
相對模式：在 YARN 佇列管理器 UI 中，容量值顯示為百分比。編輯佇列資源時，容量以百分比指定。分配給一組兄弟佇列的容量必須等於父佇列的 100%。
絕對模式：在 YARN 佇列管理器 UI 中，容量值以單位顯示。編輯佇列資源時，會為每種資源型別顯示一個單獨的選項卡。分配的總容量必須小於或等於父級的容量。
權重模式：在 YARN 佇列管理器 UI 中，容量值顯示為數值並以“w”為字尾。例如，5w。編輯佇列資源時，容量以總資源的權重或分數指定。根據佇列的權重與父項下配置的權重總和的關係來劃分資源。
注意
如果您有處於相對模式的現有受管佇列，則不允許轉換為權重模式。您必須刪除受管父佇列，然後從相對模式轉換為權重模式。
注意
YARN 佇列管理器不支援資源的混合分配。也就是說，一些佇列使用百分比分配，一些佇列使用權重。
使用 CPU 排程
具有 CPU 排程功能的 Cgroup 可幫助您有效管理混合工作負載。
注意
您應該只在 Linux 環境中使用 CPU 排程，因為 Windows 沒有隔離機制（cgroups 等效）。
僅限 MapReduce 作業
如果您主要在叢集上執行 MapReduce 作業，則啟用 CPU 排程不會對效能產生太大影響。MapReduce 的主要資源是記憶體，因此 DRF 排程程式繼續以類似於預設資源計算器的方式平衡 MapReduce 作業。在單個資源的情況下，DRF 減少到該資源的最大-最小公平性。
混合工作負載
混合工作負載的一個例子是在 YARN 上執行 MapReduce 和 Storm 的叢集。MapReduce 不受 CPU 限制，但 Storm on YARN 的容器需要比記憶體更多的 CPU。當您將 Storm 作業與 MapReduce 作業一起新增時，DRF 排程程式會嘗試平衡記憶體和 CPU 資源，但您可能會看到一些效能下降的結果。隨著您新增更多 CPU 密集型的 Storm 作業，隨著叢集 CPU 資源的消耗，單個作業的執行時間開始延長。
為了解決這個問題，您可以將 cgroups 與 CPU 排程一起使用。使用 cgroups 可為 CPU 密集型程序（例如 YARN 上的 Storm）提供隔離，從而使您能夠以可預測的方式規劃和約束 CPU 密集型 Storm 容器。
您還可以將分割槽與 CPU 排程和 cgroup 結合使用，以將 Storm on YARN 作業限制為叢集節點的子集。
配置 CPU 排程和隔離
您可以在叢集上配置 CPU 排程，為應用程式容器分配具有所需 CPU 資源的最佳節點。
使用分散式 shell 進行 CPU 排程
您可以透過指定記憶體和 vCore 以外的資源來執行分散式 shell。以下是分散式 shell 的示例，但您也可以將 CPU 排程與其他框架一起使用。
使用以下命令為兩個容器分配兩個核心：
使用 GPU 排程
在您的叢集上，您可以配置 GPU 排程和隔離。目前，YARN 僅支援 Nvidia GPU。您可以使用 Cloudera Manager 在叢集上配置 GPU 排程。
配置 GPU 排程和隔離
您可以在叢集上配置 GPU 排程和隔離。目前，YARN 僅支援 Nvidia GPU。
YARN NodeManager 必須與 Nvidia 驅動程式一起安裝。
在 Cloudera Manager 中，導航到Hosts > Hosts Configuration。
搜尋cgroup。
選中啟用基於 Cgroup 的資源管理 複選框。
單擊儲存更改。
導航到YARN >配置
搜尋cgroup。
找到Use CGroups for Resource Management屬性併為適用的叢集啟用它。
找到始終使用 Linux Container Executor屬性併為適用的叢集啟用它。
搜尋gpu。
找到Enable GPU Usage屬性並選中 NodeManager Default Group複選框。
找到NodeManager GPU Devices Allowed屬性並使用以下方式之一定義由 YARN 管理的 GPU 裝置。
使用預設值auto將自動檢測所有 GPU 裝置。在這種情況下，所有 GPU 裝置都由 YARN 管理。
手動定義由 YARN 管理的 GPU 裝置。
找到NodeManager GPU Detection Executable屬性並定義 nvidia-smi 的位置。預設情況下，此屬性沒有值，這意味著 YARN 檢查以下路徑以查詢 nvidia-smi：
/usr/bin
/bin
/usr/local/nvidia/bin
單擊儲存更改。
單擊頁面頂部的陳舊配置：需要重新啟動按鈕。
單擊重新啟動陳舊服務。
請注意，此步驟將重新啟動所有具有陳舊配置的服務。
選擇重新部署客戶端配置，然後單擊 立即重新啟動。
如果NodeManager啟動失敗，會顯示如下錯誤：
透過LD_LIBRARY_PATH使用以下命令在 yarn -env。sh 中匯出來修復錯誤：
將 GPU 排程與分散式 shell 結合使用
您可以透過指定記憶體和 vCore 以外的資源來執行分散式 shell。以下是分散式 shell 的示例，但您也可以將 GPU 排程與其他框架一起使用。
使用以下命令在
沒有
Docker 容器的
情況下
執行分散式 shell 和 GPU ：
您會收到類似於以下內容的輸出：
使用FPGA排程
您可以使用 FPGA 作為資源型別。
現場可程式設計門陣列 （FPGA） 是一種包含可配置邏輯塊矩陣（主要是邏輯閘）的卡。FPGA 可以重新程式設計，這意味著可以重新佈線門和整合裝置之間的互連。這與普通 CPU 形成對比，因為 CPU 內部的佈線和連線無法更改：只能更改其上執行的軟體，但硬體始終相同。另一方面，FPGA 允許在電路級別上進行更改。
FPGA 裝置不僅包含可重新佈線的邏輯閘（如 AND 或 OR 門），還包含儲存器、DSP、晶片、外部聯結器等。
FPGA 程式設計
FPGA 可以透過多種方式進行程式設計。最流行的方法是 VHDL 和 Verilog。
英特爾 FPGA 卡允許使用者上傳所謂的 OpenCL 核心以同時快速執行某些計算。OpenCL 是一個框架和一組標準，目前由 Khronos Group 開發和維護。有關更多資訊，請參閱Khronos 的 OpenCL 文件。
配置FPGA排程和隔離
您可以使用 Cloudera Manager 將 FPGA 啟用和配置為資源型別。
確保 FPGA 執行時或 SDK 的安裝方式使得節點管理器可以執行 aocl 命令。有關如何安裝 FPGA 的更多資訊，請參閱Intel Acceleration Stack Quick Start Guide for Intel Programmable Acceleration Card with Intel Arria 10 GX FPGA。
在 Cloudera Manager 中，選擇YARN服務。
單擊配置選項卡。
在過濾器下選擇FPGA 管理類別。
找到Enable FPGA Usage屬性並選擇可以向請求它們的 YARN 應用程式提供 FPGA 裝置的 NodeManager。
使用FPGA （aocl） 工具屬性的路徑指定安裝在適用節點上的英特爾 aocl 工具的完整本地路徑。
使用Allowed FPGA devices指定可以由 YARN NodeManager 管理的 FPGA 裝置。
有效值如下：
Auto：預設值。允許使用所有可用的 FPGA 裝置。
逗號分隔列表：列出允許的 FPGA 的次要編號。例如：0，1
使用可用 FPGA 裝置列表屬性手動指定可用的 FPGA 裝置。
按以下格式提供值：deviceA/major_number：minor_number，deviceB/major_number：minor_number
例如：acl0/238：0，acl1/238：1
使用該aocl diagnose 命令顯示 acl 編號。
主要和次要裝置號通常可以透過列出/dev。 每張卡都有一個對應的裝置檔案。該ls -l命令顯示兩個數字。
使用FPGA 裝置主裝置號屬性提供 FPGA 卡的主裝置號。
此屬性在container-executor。cfg 檔案中使用。
重要
每個節點只能指定一個主編號，即一個節點只能有一種FPGA卡。
使用FPGA 初始化指令碼屬性來提供設定 FPGA 裝置環境的 shell 指令碼的路徑。
初始化指令碼設定各種環境變數，並提供其他指令碼以允許aocl工具正常執行。此指令碼的內容在很大程度上取決於安裝。例如，在英特爾處理加速卡 （PAC） 的情況下，有必要提供 init_env。sh和init_opencl。sh。
可能需要匯出以下環境變數：
AOCL_BOARD_PACKAGE_ROOT
CL_CONTEXT_COMPILER_MODE_INTELFPGA
有關更多詳細資訊，請查閱供應商的文件。
單擊儲存更改。
重新啟動受影響的 NodeManager。
啟用並配置了 FPGA 支援。透過指定yarn。io/fpga為資源來請求 FPGA資源。
將 FPGA 與分散式 shell 結合使用
啟用 FPGA 支援後，可以透過指定yarn。io/fpga為資源來請求 FPGA 資源。
以下是分散式 shell 示例：
此命令在安裝了 FPGA 卡的節點上執行該命令date。
使用 Cgroups 限制 CPU 使用率
您可以使用 cgroups 來限制 Hadoop 叢集中的 CPU 使用率。
您可以使用 cgroups 來隔離 Hadoop 叢集中佔用大量 CPU 的程序。如果您正在使用 CPU 排程，您還應該使用 cgroups 來約束和管理 CPU 程序。如果您不使用 CPU 排程，請不要啟用 cgroup。
當您啟用 CPU 排程時，佇列仍用於分配叢集資源，但使用利用顯性資源公平性 （DRF） 的排程程式同時考慮 CPU 和記憶體。在 DRF 模型中，資源分配考慮了程序所需的主導資源。CPU 密集型程序（例如 Storm-on-YARN）獲得更多的 CPU 和更少的記憶體。記憶體密集型程序（例如 MapReduce）獲得更多記憶體和更少 CPU。DRF 排程程式旨在在混合工作負載叢集中的不同型別的程序之間公平地分配記憶體和 CPU 資源。
Cgroups 透過提供 CPU 資源隔離來補充 CPU 排程。它使您能夠對授予單個 YARN 容器的 CPU 資源量設定限制，還允許您對 YARN 程序使用的 CPU 資源總量設定限制。
Cgroups 代表了 YARN 資源管理功能的一個方面，包括 CPU 排程、分割槽、存檔儲存和作為儲存的記憶體。如果使用 CPU 排程，則應使用 cgroups 來約束和管理 CPU 程序。
使用 Cgroup
您可以使用嚴格的 cgroups CPU 限制來限制混合工作負載叢集中的 CPU 程序。
混合工作負載的一個示例是執行 MapReduce 和 Storm-on-YARN 的叢集。MapReduce 不受 CPU 限制（MapReduce 容器不需要太多 CPU）。Storm-on-YARN 受 CPU 限制：其容器要求的 CPU 多於記憶體。當您開始將 Storm 作業與 MapReduce 作業一起新增時，DRF 排程程式會嘗試平衡記憶體和 CPU 資源，但是隨著更多 CPU 密集型 Storm 作業的新增，它們可能會開始佔用大部分叢集 CPU 資源。
您可以將 cgroup 與 CPU 排程一起使用來幫助管理混合工作負載。cgroups 為諸如 Storm-on-YARN 之類的 CPU 密集型程序提供隔離，從而使您能夠以可預測的方式規劃和約束 CPU 密集型 Storm 容器。
當您啟用嚴格的 cgroup CPU 限制時，即使有額外的 CPU 可用，每個資源也只會獲得它所要求的資源。這對於涉及退款或嚴格 SLA 實施的場景很有用，在這些場景中，您始終需要準確瞭解正在使用的百分比或 CPU。
此外，啟用嚴格的 CPU 限制將使作業效能可預測，而如果不設定嚴格的限制，CPU 密集型作業在叢集使用率不高時會執行得更快，但在叢集中執行更多作業時會變慢。因此，嚴格的 CPU 限制對於基準測試也很有用。
您還可以將分割槽與 cgroups 和 CPU 排程結合使用，以將 Storm-on-YARN 作業限制為叢集節點的子集。
