YARN中的失敗分析
對於在YARN中運行的MapReduce程序，需要考慮以下幾種實體的失敗
任務、application master、節點管理器、資源管理器
1. 任務運行失敗
任務運行失敗類似於MapReduce1的情況。JVM的運行時異常和突然退出被反饋給application master，該任務嘗試被標記為失敗。類似的，通過在umbilical channel上的ping缺失(由mapreduce.task.time設定超時值)，application master會注意到掛起的任務，任務嘗試再次被標記為失敗。
4次嘗試后任務標記為失敗(map任務由mapreduce.map.maxattemps設置，reduce任務由mapreduce.reduce.maxattempts設置)。如果一個作業中超過mapreduce.map.failures.maxpercent的map任務或超過mapreduce.reduce.failures.maxpercent的reduce任務運行失敗，name整個作業就失敗了。
2. application master運行失敗
YARN中的應用程序在運行失敗的時候有幾次嘗試機會，就像MapReduce任務在遇到硬件或網絡故障時要進行幾次嘗試一樣。在默認情況下，只要應用程序運行失敗一次就會被標記為失敗，但我們可以設置yarn.resourcemanager.am.max-retries屬性增加允許失敗的次數。
Application master向資源管理器發送周期性的心跳，當application master發生故障時，資源管理器將檢測到該故障並在一個新的容器(由節點管理器管理)中開始一個新的master實例。MapReduce application master可以恢復故障應用程序所運行任務的狀態，使其不必重新運行。默認情況下是不能恢復的，因此故障application master將重新運行它們的所有任務，但我們可以設置yarn.app.mapreduce.am.job.recovery.enable為true，啟用這個功能。
客戶端向application master輪詢進度報告，如果它的application master運行失敗，客戶端就需要定位新的實例。在作業初始化期間，客戶端向資源管理器詢問並緩存application master的地址，使其每次需要向application master查詢是不必重載資源管理器。但是，如果application master運行失敗，客戶端就會在發出狀態更新請求時超時，這時客戶端會返回資源管理器請求新的application master的地址。
3. 節點管理器運行失敗
如果節點管理器失敗，就會停止向資源管理器發送心跳信息並被移出可用節點資源管理器池。默認值為600000（10分鍾）的屬性yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms決定着資源管理器認為節點管理器失敗之前的等待時間。
如果應用程序的運行失敗次數過高，那么節點管理器可能會被拉黑。由application master管理黑名單，對於MapReduce，如果一個節點管理器上有超過三個任務失敗，application master就會盡量將任務調度到不同的節點上。可以通過mapreduce.job.maxtaskfailures.per.tracker設置該閾值。
4. 資源管理器運行失敗
資源管理器失敗是非常嚴重的問題，沒有資源管理器，作業和任務容器將無法啟動。資源管理器的設計從一開始就通過使用檢查點機制將其狀態保存到持久性存儲，從而實現從失敗中恢復。
在資源管理器失敗后，由管理員啟動一個新的資源管理器實例並恢復到保存的狀態。狀態由系統中的節點管理器和運行的應用程序組成。(注意，任務並非資源管理器狀態的組成部分，因為它們由application master管理。因此，存儲的狀態數量比jobtracker中的狀態更好管理)
資源管理器使用的存儲容量通過yarn.resourcemanager.store.class的屬性進行配置。默認值為org.apache.hadoop.yarn.server.resourcemanager.recovery.MemStore，這保存在內存中，因此可操作性不是很高