hadoop(二):hdfs HA原理及安裝

  轉自：http://www.cnblogs.com/tgzhu/p/5790565.html

   早期的hadoop版本，NN是HDFS集群的單點故障點，每一個集群只有一個NN,如果這個機器或進程不可用，整個集群就無法使用。為了解決這個問題，出現了一堆針對HDFS HA的解決方案（如：Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等）; 在HA具體實現方法不同的情況下，HA框架的流程是一致的, 不一致的就是如何存儲和管理日志。在Active NN和Standby NN之間要有個共享的存儲日志的地方，Active NN把EditLog寫到這個共享的存儲日志的地方，Standby NN去讀取日志然后執行，這樣Active和Standby NN內存中的HDFS元數據保持着同步。一旦發生主從切換Standby NN可以盡快接管Active NN的工作; 在 HDP2.4安裝(五)：集群及組件安裝 章節使用ambari創建cluster時，默認並未啟用 hdfs ha, 可以通過 ambari 管理界面進行安裝

目錄：

• SPOF（single point of failure）方案回顧
• hadoop2.x ha 原理
• hadoop2.x ha 詳述
• hadoop2.x Federation
• ha 安裝配置

SPOF方案回顧：

---

1. Secondary NameNode：它不是HA，它只是階段性的合並edits和fsimage，以縮短集群啟動的時間。當NN失效的時候，Secondary NN並無法立刻提供服務，Secondary NN甚至無法保證數據完整性：如果NN數據丟失的話，在上一次合並后的文件系統的改動會丟失
2. Backup NameNode (HADOOP-4539)：它在內存中復制了NN的當前狀態，算是Warm Standby，可也就僅限於此，並沒有failover等。它同樣是階段性的做checkpoint，也無法保證數據完整性
3. 手動把name.dir指向NFS（Network File System），這是安全的Cold Standby，可以保證元數據不丟失，但集群的恢復則完全靠手動
4. Facebook AvatarNode：Facebook有強大的運維做后盾，所以Avatarnode只是Hot Standby，並沒有自動切換，當主NN失效的時候，需要管理員確認，然后手動把對外提供服務的虛擬IP映射到Standby NN，這樣做的好處是確保不會發生腦裂的場景。其某些設計思想和Hadoop 2.0里的HA非常相似，從時間上來看，Hadoop 2.0應該是借鑒了Facebook的做法
   • Facebook AvatarNode 原理示例圖
   • 

• • PrimaryNN 與StandbyNN之間通過NFS來共享FsEdits、FsImage文件，這樣主備NN之間就擁有了一致的目錄樹和block信息；而block的 位置信息，可以根據DN向兩個NN上報的信息過程中構建起來。這樣再輔以虛IP，可以較好達到主備NN快速熱切的目的。但是顯然，這里的NFS又引入了新的SPOF
  • 在主備NN共享元數據的過程中，也有方案通過主NN將FsEdits的內容通過與備NN建立的網絡IO流，實時寫入備NN，並且保證整個過程的原子性。這種方案，解決了NFS共享元數據引入的SPOF，但是主備NN之間的網絡連接又會成為新的問題

hadoop2.X ha 原理:

---

• hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager，這是一個基於Paxos算法實現的HDFS HA方案，它給出了一種較好的解決思路和方案,示意圖如下：
• 
• 基本原理就是用2N+1台 JN 存儲EditLog，每次寫數據操作有大多數（>=N+1）返回成功時即認為該次寫成功，數據不會丟失了。當然這個算法所能容忍的是最多有N台機器掛掉，如果多於N台掛掉，這個算法就失效了。這個原理是基於Paxos算法
• 在HA架構里面SecondaryNameNode這個冷備角色已經不存在了，為了保持standby NN時時的與主Active NN的元數據保持一致，他們之間交互通過一系列守護的輕量級進程JournalNode
• 任何修改操作在 Active NN上執行時，JN進程同時也會記錄修改log到至少半數以上的JN中，這時 Standby NN 監測到JN 里面的同步log發生變化了會讀取 JN 里面的修改log，然后同步到自己的的目錄鏡像樹里面，如下圖：
• 
• 當發生故障時，Active的 NN 掛掉后，Standby NN 會在它成為Active NN 前，讀取所有的JN里面的修改日志，這樣就能高可靠的保證與掛掉的NN的目錄鏡像樹一致，然后無縫的接替它的職責，維護來自客戶端請求，從而達到一個高可用的目的
• QJM方式來實現HA的主要優勢：

1. 1. 不需要配置額外的高共享存儲，降低了復雜度和維護成本
   2. 消除spof
   3. 系統魯棒性(Robust:健壯)的程度是可配置
   4. JN不會因為其中一台的延遲而影響整體的延遲，而且也不會因為JN的數量增多而影響性能（因為NN向JN發送日志是並行的）

hadoop2.x ha 詳述：

---

• datanode的fencing: 確保只有一個NN能命令DN。HDFS-1972中詳細描述了DN如何實現fencing

1. 1. 每個NN改變狀態的時候，向DN發送自己的狀態和一個序列號
   2. DN在運行過程中維護此序列號，當failover時，新的NN在返回DN心跳時會返回自己的active狀態和一個更大的序列號。DN接收到這個返回則認為該NN為新的active
   3. 如果這時原來的active NN恢復，返回給DN的心跳信息包含active狀態和原來的序列號，這時DN就會拒絕這個NN的命令

• 客戶端fencing：確保只有一個NN能響應客戶端請求，讓訪問standby nn的客戶端直接失敗。在RPC層封裝了一層，通過FailoverProxyProvider以重試的方式連接NN。通過若干次連接一個NN失敗后嘗試連接新的NN，對客戶端的影響是重試的時候增加一定的延遲。客戶端可以設置重試此時和時間
• Hadoop提供了ZKFailoverController角色，部署在每個NameNode的節點上，作為一個deamon進程, 簡稱zkfc，示例圖如下：
• 
• FailoverController主要包括三個組件:

1. 1. HealthMonitor: 監控NameNode是否處於unavailable或unhealthy狀態。當前通過RPC調用NN相應的方法完成
   2. ActiveStandbyElector: 管理和監控自己在ZK中的狀態
   3. ZKFailoverController 它訂閱HealthMonitor 和ActiveStandbyElector 的事件，並管理NameNode的狀態

• ZKFailoverController主要職責：

1. 1. 健康監測：周期性的向它監控的NN發送健康探測命令，從而來確定某個NameNode是否處於健康狀態，如果機器宕機，心跳失敗，那么zkfc就會標記它處於一個不健康的狀態
   2. 會話管理：如 果NN是健康的，zkfc就會在zookeeper中保持一個打開的會話，如果NameNode同時還是Active狀態的，那么zkfc還會在 Zookeeper中占有一個類型為短暫類型的znode，當這個NN掛掉時，這個znode將會被刪除，然后備用的NN，將會得到這把鎖，升級為主 NN，同時標記狀態為Active
   3. 當宕機的NN新啟動時，它會再次注冊zookeper，發現已經有znode鎖了，便會自動變為Standby狀態，如此往復循環，保證高可靠，需要注意，目前僅僅支持最多配置2個NN
   4. master選舉：如上所述，通過在zookeeper中維持一個短暫類型的znode，來實現搶占式的鎖機制，從而判斷那個NameNode為Active狀態

 

hadoop2.x Federation：

---

• 單Active NN的架構使得HDFS在集群擴展性和性能上都有潛在的問題，當集群大到一定程度后，NN進程使用的內存可能會達到上百G，NN成為了性能的瓶頸
• 常用的估算公式為1G對應1百萬個塊，按缺省塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個文件只有一個塊，所有元數據信息也不會有1KB/block)
• 為了解決這個問題,Hadoop 2.x提供了HDFS Federation, 示意圖如下：
• 
• 多個NN共用一個集群里的存儲資源，每個NN都可以單獨對外提供服務
• 每個NN都會定義一個存儲池，有單獨的id，每個DN都為所有存儲池提供存儲
• DN會按照存儲池id向其對應的NN匯報塊信息，同時，DN會向所有NN匯報本地存儲可用資源情況
• 如果需要在客戶端方便的訪問若干個NN上的資源，可以使用客戶端掛載表，把不同的目錄映射到不同的NN，但NN上必須存在相應的目錄
• 設計優勢：

1. 1. 改動最小，向前兼容；現有的NN無需任何配置改動；如果現有的客戶端只連某台NN的話，代碼和配置也無需改動
   2. 分離命名空間管理和塊存儲管理
   3. 客戶端掛載表：通過路徑自動對應NN、使Federation的配置改動對應用透明

• 思考：與上面ha方案中介紹的最多2個NN沖突？

ha 安裝配置：

---

• 關於NameNode高可靠需要配置的文件有core-site.xml和hdfs-site.xml
• 關於ResourceManager高可靠需要配置的文件有yarn-site.xml    (參數配置及說明見第四章)
• 操作的過程可通過 ambarir 的管理界面提供的 "enable NameNode HA" 完成,如下圖：
• 
• 系統要求：至少3台以上zookeeper服務器，在原來基礎上，將 hdp2\hdp3\R作為zookeeper
• 停止HBase所有服務，設置JN安裝在host，及standby NN 節點主機，如下圖：
• 
• 按默認配置安裝的 secondary NN將去被刪除，同時安裝 standby NN, 在 R、hdp1、hdp2上配置 JN服務，如下：
• 
• 登陸至 active NN (hdp4), 執行下面的命令
• 命令： sudo su hdfs -l -c 'hdfs dfsadmin -safemode enter'    （進入安全模式）
• 命令： sudo su hdfs -l -c 'hdfs dfsadmin -saveNamespace'    （create checkpoint)
• 
• ambari 檢測到 NN進入安全模式並且checkpoint 后進入組件配置，如圖：
• 
• 初始化JN節點，進入 hdp4,執行命令：sudo su hdfs -l -c 'hdfs namenode -initializeSharedEdits'
• ambari檢測到初始化成功后，進入下一步，如圖 start component
• 
• 手工初始化 NN HA Metadata, 登陸hdp4主機，命令如下：
• 命令： sudo su hdfs -l -c 'hdfs zkfc -formatZK'
• 登陸到standy NN (R), 執行命令：
• 命令： sudo su hdfs -l -c 'hdfs namenode -bootstrapStandby'
• 成功執行上面命令后，點擊“下一步”，開始HA安裝，成功后如圖:
• 
• 回到 ambari 面板
•