介紹
衆所周知，YARN可擴展到數千個節點。 YARN的可伸縮性由Resource Manager確定，並且與節點數，活躍的應用程序，活躍的容器和心跳頻率成比例。降低心跳可以提高可擴展性，但對利用率有害。本文檔描述了一種基於聯邦（federation）的方法，通過聯合多個YARN子集，將單個YARN集羣擴展到數萬個節點。所提出的方法是將大的（10-100k節點）集羣劃分爲稱爲子集羣的較小單元，每個集羣具有其自己的YARN RM和計算節點。聯合系統（federation system）將這些子集羣拼接在一起，使它們成爲應用程序的一個大型YARN集羣。在此聯合環境中運行的應用程序將看到單個大型YARN羣集，並且能夠在聯合羣集的任何節點上計劃任務。聯合系統將與子集羣的Resource Manager協商併爲應用程序提供資源。目標是允許單個作業無縫地“跨越”子集羣。
這種設計在結構上是可擴展的，因爲我們限制每個RM負責的節點數量，並且適當的策略將會保證大多數應用程序駐留在單個子集羣中，因此每個RM看到的應用程序數量 也是有限的。 這意味着我們幾乎可以通過簡單地添加子集來線性擴展（因爲它們之間需要很少的協調）。 此體系結構可以在每個子集羣中提供非常嚴格的調度不變量來實施，而跨集羣的連續重新平衡將強制這些屬性在全局級別也得到尊重。
架構
YARN Federation的主要設計思想是希望通過聯合的方式讓集羣可以有多個SubCluster 。 每個SubCluster都是一個獨立的小集羣，由子集羣的ResourceManager分別管理一部分節點。這些小集羣共同組成一個大的YARN Federation集羣，實現資源的統一管理與作業調度。
- sub-cluster：子集羣是一個YARN集羣，具有多達數千個節點。
子集羣的YARN RM將在保持高可用性的情況下運行，即，我們應該能夠容忍YARN RM，NM故障。如果整個子集羣遭到破壞，外部機制將確保在單獨的子集羣中重新提交作業。
子集羣也是聯合環境中的可伸縮性單元。我們可以通過添加一個或多個子集羣來擴展聯合環境。 - Router：路由組件，一個Federation 集羣可以配置一組，但最少配置一個。用戶提交應用時首先會訪問其中一個Router，然後Router會先從State Store中獲得所有“Sub Cluster”信息（active rm 和 其他一些使用率信息），之後根據配置的路由策略（從策略存儲中獲取）將應用程序提交請求轉發到對應的RM上。
- AMRMProxy：AMRMProxy是應用程序和多個RM通訊的橋樑。他允許一個App可以跨子集羣運行。例如，一個App有2000個task, 這些task會分散到所有子集羣上運行，每個子集羣運行一部分。AMRMProxy運行在所有的NM機器上，它實現了ApplicationMasterProtocol接口作爲AM的YARN RM的代理。 應用程序不能直接與子集羣的RM通信。 YARN框架強制應用程序只能連接到AMRMProxy，從而提供對多個YARN RM（通過動態路由/拆分/合併通信）的透明訪問。 在任何時候，作業都可以跨主子集羣和多個輔助子集羣運行，其中AMRMProxy的運行策略會試圖限制每個作業的佔用空間以降低調度上的開銷。
- Global Policy Generator(簡寫：GPG)：全局策略生成器忽略整個聯合，並確保系統始終被正確的配置和調整。 關鍵設計點是羣集的可用性不依賴於永遠在線的GPG。
- Federation State-Store：聯合狀態定義了需要維護的附加狀態，以便將多個單獨的子集羣鬆散地耦合到單個大型聯合集羣中。
- Federation Policy Store：聯合策略存儲是一個邏輯上獨立的存儲，其中包含有關如何將應用程序和資源請求路由到不同子集羣的信息。 當前的實現提供了幾種策略，從隨機/散列/循環/優先級（random/hashing/roundrobin/priority）到更復雜的策略，這些策略考慮了子集羣的負載。
應用程序跨Sub-Clusters運行的流程
提交應用程序時，Router會找一個最合適的子集羣運行應用程序，稱之爲應用程序的主子集羣。AM與RM的所有通信都通過AM機器本地的AMRMProxy進行。理想情況下，應用程序默認會運行在資源和數據都可用的子集羣上，但如果需要其他子集羣節點上的資源，則AMRMProxy將與這個子集羣的RM通訊請求資源。讓應用程序像在一個大集羣上運行。這個功能需要AMRMProxy，全局策略生成器（Global Policy Generator，GPG）和Router組合在一起使用。
配置
具體配置在官網上可以看到，在此不介紹。