ResourceManager 是管理資源和排程在 YARN 上執行的應用程式的中央權限。因此,它可能是 Apache YARN 集群中的單點故障。本文件概述了 ResourceManager 重新啟動,這項功能增強了 ResourceManager,使其在重新啟動時仍能持續運作,並讓使用者不會察覺到 ResourceManager 的停機時間。
ResourceManager 有兩種重新啟動類型
非工作保留 RM 重新啟動:此重新啟動增強了 RM,使其能將應用程式/嘗試狀態和其他憑證資訊持續儲存在可插入的狀態儲存體中。RM 會在重新啟動時從狀態儲存體重新載入此資訊,並重新啟動先前執行的應用程式。使用者不需要重新提交應用程式。
保留工作的 RM 重新啟動:此功能著重於透過在重新啟動時結合來自節點管理員的容器狀態和來自應用程式主控的容器要求,來重建 RM 的執行狀態。與不保留工作的 RM 重新啟動的主要差異在於,先前執行的應用程式在 RM 重新啟動後不會被終止,因此應用程式不會因為 RM 中斷而遺失其工作。
不保留工作的 RM 重新啟動
在不保留工作的 RM 重新啟動中,當用戶端提交應用程式時,RM 會將應用程式元資料(即 ApplicationSubmissionContext)儲存在可插入的狀態儲存體中,並在應用程式完成時儲存應用程式的最終狀態,例如完成狀態(失敗、終止或已完成)和診斷。此外,RM 也儲存安全金鑰、權杖等憑證,以便在安全環境中工作。當 RM 關閉時,只要狀態儲存體中提供所需資訊(即應用程式元資料和在安全環境中執行時的憑證),則當 RM 重新啟動時,它可以從狀態儲存體中擷取應用程式元資料並重新提交應用程式。如果應用程式在 RM 停用之前已完成(即失敗、終止或已完成),則 RM 不會重新提交這些應用程式。
在 RM 停機期間,節點管理員和用戶端會持續輪詢 RM,直到 RM 啟動。當 RM 啟動時,它會傳送重新同步命令給所有透過心跳通訊的節點管理員和應用程式主控。節點管理員會終止其管理的所有容器,並重新向 RM 註冊。這些重新註冊的節點管理員類似於新加入的節點管理員。預計應用程式主控(例如 MapReduce 應用程式主控)在收到重新同步命令時會關閉。在 RM 重新啟動並從狀態儲存體載入所有應用程式元資料和憑證,並將其填入記憶體後,它會為每個尚未完成的應用程式建立新的嘗試(即應用程式主控),並照常重新啟動該應用程式。如前所述,先前執行的應用程式的作業會以這種方式遺失,因為它們基本上會在重新啟動時透過 RM 的重新同步命令終止。
保留工作的 RM 重新啟動
在保留工作的 RM 重新啟動中,RM 確保應用程式狀態的持久性,並在復原時重新載入該狀態,此重新啟動主要著重於重建 YARN 集群的整個執行狀態,其中大部分是 RM 內部中央排程器的狀態,該狀態會追蹤所有容器的生命週期、應用程式的餘裕和資源要求、佇列的資源使用情況等。透過這種方式,RM 不需要終止應用程式主控並從頭重新執行應用程式,因為這是在不保留工作的 RM 重新啟動中執行的。應用程式可以簡單地重新與 RM 同步,並從中斷處繼續執行。
RM 透過利用從所有 NM 傳送的容器狀態,來恢復其執行狀態。NM 在與重新啟動的 RM 重新同步時,不會終止容器。它會繼續管理容器,並在重新註冊時將容器狀態傳送給 RM。RM 透過吸收這些容器資訊,來重建容器執行個體和相關應用程式的排程狀態。同時,AM 需要重新傳送未完成的資源要求給 RM,因為 RM 在關閉時可能會遺失未完成的要求。使用 AMRMClient 函式庫與 RM 通訊的應用程式撰寫人員,不需要擔心 AM 在重新同步時重新傳送資源要求給 RM 的部分,因為函式庫本身會自動處理。
此部分說明啟用 RM 重新啟動功能所涉及的組態。
屬性 | 說明 |
---|---|
yarn.resourcemanager.recovery.enabled |
true |
屬性 | 說明 |
---|---|
yarn.resourcemanager.store.class |
要使用的狀態儲存類別名稱,用於儲存應用程式/嘗試狀態和憑證。可用的狀態儲存實作包括:org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore (一個基於 ZooKeeper 的狀態儲存實作)、org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore (一個基於 Hadoop 檔案系統的狀態儲存實作,例如 HDFS 和本機檔案系統),以及 org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore (一個基於 LevelDB 的狀態儲存實作)。預設值設定為 org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore 。 |
基於 ZooKeeper 的狀態儲存:使用者可以自由選擇任何儲存空間來設定 RM 重新啟動,但必須使用基於 ZooKeeper 的狀態儲存來支援 RM HA。原因是只有基於 ZooKeeper 的狀態儲存支援圍欄機制,以避免發生多個 RM 假設它們處於活動狀態,並同時可以編輯狀態儲存的腦裂情況。
基於檔案系統的狀態儲存:支援 HDFS 和本機檔案系統的狀態儲存。不支援圍欄機制。
基於 LevelDB 的狀態儲存:基於 LevelDB 的狀態儲存被認為比基於 HDFS 和 ZooKeeper 的狀態儲存更輕量。LevelDB 支援更好的原子操作、每個狀態更新更少的 I/O 作業,以及檔案系統上的總檔案數目更少。不支援圍欄機制。
同時支援基於 HDFS 和本機檔案系統的狀態儲存實作。要使用的檔案系統類型由 URI 的架構決定。例如,hdfs://127.0.0.1:9000/rmstore
使用 HDFS 作為儲存空間,而 file:///tmp/yarn/rmstore
使用本機檔案系統作為儲存空間。如果在 URI 中未指定架構(hdfs://
或 file://
),則要使用的儲存類型由 core-site.xml
中定義的 fs.defaultFS
決定。
屬性 | 說明 |
---|---|
yarn.resourcemanager.fs.state-store.uri |
指向儲存 RM 狀態的 FileSystem 路徑位置的 URI(例如 hdfs://127.0.0.1:9000/rmstore)。預設值為 ${hadoop.tmp.dir}/yarn/system/rmstore 。如果未提供 FileSystem 名稱,則會使用在 *conf/core-site.xml 中指定的 fs.default.name 。 |
屬性 | 說明 |
---|---|
yarn.resourcemanager.fs.state-store.retry-policy-spec |
Hadoop FileSystem 儲存體重試政策規範。Hadoop FileSystem 儲存體重試始終處於啟用狀態。以睡眠時間和重試次數成對指定,即 (t0, n0)、(t1, n1)、…,前 n0 次重試平均睡眠 t0 毫秒,後續 n1 次重試平均睡眠 t1 毫秒,依此類推。預設值為 (2000, 500) |
屬性 | 說明 |
---|---|
hadoop.zk.address |
主機:埠對的逗號分隔清單。每個對應一個 ZooKeeper 伺服器(例如「127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002」),供 RM 用來儲存 RM 狀態。 |
yarn.resourcemanager.zk-state-store.parent-path |
將儲存 RM 狀態的根 znode 的完整路徑。預設值為 /rmstore。 |
屬性 | 說明 |
---|---|
hadoop.zk.num-retries |
如果連線中斷,RM 嘗試連線 ZooKeeper 伺服器的次數。預設值為 500。 |
hadoop.zk.retry-interval-ms |
連線 ZooKeeper 伺服器時,兩次重試之間的間隔(毫秒)。預設值為 2 秒。 |
hadoop.zk.timeout-ms |
ZooKeeper 會話逾時(毫秒)。ZooKeeper 伺服器使用此設定來判斷會話何時逾時。當伺服器在由這個設定指定的會話逾時期間內未收到來自儲存體的訊息(即沒有心跳),就會發生會話逾時。預設值為 10 秒 |
屬性 | 說明 |
---|---|
hadoop.zk.acl |
用於設定 ZooKeeper znode 權限的 ACL。預設值為 world:anyone:rwcda |
屬性 | 說明 |
---|---|
yarn.resourcemanager.leveldb-state-store.path |
儲存 RM 狀態的本機路徑。預設值為 ${hadoop.tmp.dir}/yarn/system/rmstore |
屬性 | 說明 |
---|---|
yarn.resourcemanager.work-preserving-recovery.scheduling-wait-ms |
設定 RM 在工作保留復原中配置新容器之前等待的時間。此等待期間讓 RM 有機會在復原時與叢集中的 NM 重新同步,然後再將新容器指派給應用程式。 |
如果 RM 在啟用工作保留復原的狀態下重新啟動,則 ContainerId 字串格式會有所變更。它使用下列格式:Container_{clusterTimestamp}_{appId}_{attemptId}_{containerId}
,例如 Container_1410901177871_0001_01_000005
。
它現在已變更為:Container_
e{epoch}_{clusterTimestamp}_{appId}_{attemptId}_{containerId}
,例如 Container_
e17_1410901177871_0001_01_000005
。
在此,額外的 epoch 數字是一個從 0 開始的單調遞增整數,並且每次 RM 重新啟動時都會增加 1。如果 epoch 數字為 0,則會將其省略,而 containerId 字串格式與之前保持相同。
以下是使用基於 ZooKeeper 的狀態儲存來啟用 RM 工作保留重新啟動的最小設定集。
<property> <description>Enable RM to recover state after starting. If true, then yarn.resourcemanager.store.class must be specified</description> <name>yarn.resourcemanager.recovery.enabled</name> <value>true</value> </property> <property> <description>The class to use as the persistent store.</description> <name>yarn.resourcemanager.store.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value> </property> <property> <description>Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server (e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") to be used by the RM for storing RM state. This must be supplied when using org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore as the value for yarn.resourcemanager.store.class</description> <name>hadoop.zk.address</name> <value>127.0.0.1:2181</value> </property>