一、HDFS副本機制

HDFS對于讀寫的容錯機制是基于HDFS的副本機制

對于檔案上傳

HDFS副本放置策略是默認三個備份，當前節點一份，同一機架不同節點一份，不同機架任任意節點一份，如果上傳程序中某一副本上傳失敗，那么整個塊的上傳失敗，需要重新啟動這個副本的上傳，

對于檔案下載

下載失敗可能因為備份丟失或節點壞掉，此時會優先調取同一機架另外一個節點的資料備份，以減少資料開銷，如果該機架的機器集體宕機，則從另一個機架上獲取資料備份，

二、YARN容錯機制

YARN是如何配合副本機制的

ResourceManager通常運行在NameNode上，NodeManager運行在DataNode上，
ResourceManager管理所有DataNode上的NodeManager，NodeManager負責監控每一臺設備上的系統資源狀況，包括CPU、記憶體、當前節點上運行的任務、存盤的檔案塊資訊，通過心跳機制由NodeManager定時向ResourceManager匯報，以便于實時掌握整個HDFS上的資源狀況，
心跳既是NodeManager向ResourceManager匯報的機制，也是ResourceManager向DataNode發布任務的機制，

YARN執行流程

• 客戶端提交作業后，會向ResourceManager申請運行MRAppMaster（運行MapReduce應用程式的AppMaster），
• ResourceManager為該應用程式分配第一個Container，并與對應的NodeManager建立通信，
• NodeManager創建Container容器，并啟動MRAppMaster，
• AppMaster啟動時，首先會注冊到ResourceManager，啟動成功后與ResourceManager保持心跳，
• AppMaster從HDFS上下載Job資源到本地，并根據切片資訊創建MapTask和ReduceTask，
• AppMaster采用輪詢的方式通過RPC協議向ResourceManager申請和領取Container資源，
• ResourceManager回傳AppMaster申請的Containers資訊，申請成功的Container，由AppMaster進行初始化，
• Container的啟動資訊初始化后，AppMaster與對應的NodeManager通信，要求NodeManager啟動Container，
• AppMaster與NodeManager保持心跳，從而對NodeManager上運行的任務進行監控和管理，
• Container通過RPC協議向AppMaster匯報自己的狀態和進度等資訊，以便AppMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啟動任務，
• 應用程式運行程序中，客戶端可以隨時通過RPC與AppMaster通信獲取應用程式的運行狀態、進度更新等資訊，
• 應用程式運行結束后，AppMaster向ResourceManager注銷自己，并允許屬于它的Container被識訓，

Map/ReduceTask

AppMaster負責任務的容錯

• MapReduce的計算程序中，有可能會啟動多個MapTask和ReduceTask，如果某個MapTask失敗，AppMaster通過心跳機制向ApplicationManager傳遞任務失敗資訊，然后ApplicationManager會重啟這個MapTask任務，通過ResourceSchedule去找到另一個副本block所在的節點，并把節點資訊反饋給AppMaster，AppMaster通過當前節點的NodeManager把任務傳給目標DataNode，在目標DataNode上重建一個Container，并且調取當前節點上的副本block來啟動MapTask，

PS：

• 當AppMaster被告知一個任務嘗試失敗后，將重新調度該任務的執行，AppMaster會試圖避免在以前失敗過的DataNode上重新調度該任務，默認情況下，如果一個任務失敗超過4次，將不會再重試運行任務，即整個作業失敗，最多嘗試次數可通過mapreduce.map.maxattempts設定，
• 對于一些應用程式，不希望因為少數幾個任務失敗就終止運行整個作業，因為即使有任務失敗，作業的一些結果可能還是可用的，在這種情況下，可以為作業設定在不觸發作業失敗的情況下允許任務失敗的最大百分比，針對MapTask和ReduceTask可以通過mapreduce.map.failures.maxpercent設定，

ApplicationMaster

ResourceManager負責AppMaster的容錯

• AppMaster與ResourceManager通過心跳機制保持定期通信，當檢測到AppMaster運行失敗時，ResourceManager會重新分配Container資源并啟動AppMaster，MRAppMaster在作業運行程序中將狀態資訊動態記錄到HDFS上，一旦出現故障重啟后，它能夠從HDFS讀取并恢復之前的運行狀態，以減少重新計算帶來的開銷，

PS：

• 在作業初始化期間，客戶端向ResourceManager詢問并快取AppMaster的地址，使其每次需要向AppMaster查詢時不必多載ResourceManager，但是如果AppMaster運行失敗，客戶端就會在發出狀態更新時請求時經歷超時，這時客戶端會折回向ResourceManager請求新的AppMaster的地址，這個程序對于用戶是透明的，

NodeManager

• 如果NodeManager由于崩潰或運行非常緩慢而失敗，就會停止向ResourceManager發送心跳資訊（或發送頻率很低），如果10分鐘內沒有收到一條心跳資訊，ResourceManager將會通知該NodeManager并將其從節點池中移除以調度啟用容器，
• 在失敗的NodeManager上運行的所有任務或AppMaster都用前兩節描述的機制進行恢復，對于那些曾經在失敗的NodeManager上運行且成功完成的MapTask，如果屬于未完成的作業，那么AppMaster會安排他們重新運行，因為這些MapTask的中間輸出保存在失敗的NodeManager的本地檔案系統中，可能無法被ReduceTask訪問，

PS：

• 如果應用程式的運行失敗次數過高，那么NodeManager可能會被拉黑，對于MapReduce，如果一個NodeManager上有超過三個任務失敗，AppMaster就會盡量將任務調度在不同的節點上，

三、高可用集群HA Cluster

NameNode

ZooKeeper負責NameNode的容錯

• 以上的所有容錯都是基于DataNode的故障問題進行考慮的，但是NameNode本身就存在單點故障，如果NameNode出現故障，則整個集群會直接宕機，因此HDFS提供了HA的架構，借助于ZooKeeper的機制來完成NameNode的管理，
• 在高可用集群狀態下，NameNode會被配置在多臺獨立的機器上，但只有一個NameNode處于Active狀態，其他都是Standby狀態，Active狀態的NameNode會回應集群中所有的客戶端的請求，Standby狀態的NameNode只是作為一個副本，保證在必要的時候提供一個快速的轉移，使得上層對NameNode的切換無感知，
• 在任務執行期間，ZooKeeper一直在同步Standby NameNode與Active NameNode鏡像資料，Active NameNode不斷將資訊寫入共享存盤系統，Standby NameNode則不斷讀取這些資訊，使得Active NameNode和Standby NameNode記憶體中的HDFS元資料保持同步，
• 當ZooKeeper通過和NameNode之間的心跳機制檢測到Active NameNode掛掉時，需先保證選中的Standby NameNode資訊完全同步后，才會啟動它并將狀態切換至Active，同時對外啟動Job，比如之前掛掉的NameNode上有個Job未執行完，當前Active NameNode剛接過來發現有個未完成的串列，則通過ApplicationManager把這個Job重啟一遍，