Hadoop2.X大資料叢集規劃與架構設計
第一階段：先說說偽分散式
不管是HDFS和YARN，在我們之前的文章中已經說過關於偽分散式的部署和安裝。也就是我們把HDFS的兩個節點NameNode和DataNode，YARN的ResourceManger和NodeManager都放在同一個機器上。
機器1：bigdata-senior01.kfk.com
程序包括：
NameNode
DataNode
ResourceManager
NodeManager
網際網路科技發展蓬勃興起，人工智慧時代來臨，抓住下一個風口。為幫助那些往想網際網路方向轉行想學習，卻因為時間不夠，資源不足而放棄的人。我自己整理的一份最新的大資料進階資料和高階開發教程，大資料學習群：199加上【427】最後加上210就可以找到組織學習 歡迎進階中和進想深入大資料的小夥伴加入。
第二階段：Hadoop分散式初級設計
既然是分散式，我們說分散式是主從架構，也就是說至少要一個主節點，多個從節點吧。所以不管是HDFS或者YARN，對於DataNode節點和NodeManager節點必須是多臺，最少也要是3臺。我們自己玩，機器資源不富裕的情況下，搞個3臺機器沒有問題，效果一樣能達到。所以，接下來我們做一個分散式叢集機器的規劃設計。
機器規劃
機器1：bigdata-senior01.kfk.com
程序包括：
NameNode
DataNode
NodeManager
機器2：bigdata-senior02.kfk.com
程序包括：
ResouceManager
NodeManger
DataNode
機器3：bigdata-senior03.kfk.com
程序包括：
DataNode
NodeManager
SecondaryNameNode
首先我們保證每天機器上分別有一個DataNode節點和NodeManager節點。因為都是從節點，真正幹活的。在數量上我們要保證。那麼NameNode和ResourceManager是兩個非常重要的管理者，在我們架構設計的時候，儘可能的把它們分開，不要放在一臺機器上。我們客戶端的請求，第一時間與NameNode和ResourceManager打交道。NameNode負責管理HDFS檔案系統的元資料，客戶端不管是讀檔案還是寫檔案，都要首先找到NameNode獲取檔案的元資料，再進行檔案的操作。ResourceManager也是如此，它負責管理叢集中的資源和任務排程，你也可以把它視為“大資料作業系統”。客戶端能否提交應用並執行，就看你的ResourceManager是否正常。
SecondaryNameNode的作用
還有一個程序，就是下圖中的SecondaryNameNode,它是幹什麼的呢。我們可以這麼來理解，比如NameNode就好比是我們一本書的目錄，它就像一本書內容的管理員，當用戶需要看書的時候，他可以告訴使用者這個書的標題是什麼，內容 在哪一頁，使用者通過書的目錄直奔某一頁的內容。假如有一天，這個書的內容發生了變化，增加了好多內容，前天張三加了內容，昨天王四加了內容，今天李二加了內容，如果這個書的內容在不斷的變化，那我的目錄是不是要變化？這是一定的。如果你的書目錄與書的內容同步，那這個書就沒有意義了，對於使用者來說，不會看你這本書。我們只是舉個例子，當然現實中不可能存在，除非是電子WORD文件，還是有這個場景的。
其實中這個例子中我們可以看出，如果書的內容要與目錄同步，我們必須要不停的跟進修改內容的日誌資訊來重新改編我們的書目錄，也就是隻要書的內容變化了，我們就要對書的目錄做一個合併，永遠保證與內容同步一致。那麼SecondaryNameNode這個程序做的工作就如同根據書的內容不停的重新合併書目錄一樣，在HDFS檔案系統中，它會根據使用者對檔案的操作日誌，來合併NameNode中檔案元資料，永遠保證元資料與DataNode節點上儲存的檔案資訊一致。
為什麼要HA
從我們上一步的叢集設計規劃中可以看出，我們只有一個NameNode節點。我們說NameNode的節點是非常重要的，如果只有一個NameNode並且出現故障，那整個HDFS叢集將無法使用，直到NameNode重新啟動。那我們是否可以考慮部署兩個NameNode節點呢？從現實意義上來說，這是必須的。這也就是我們要說的HDFS的HA設計。
NameNode主要在以下兩個方面影響HDFS叢集：
NameNode叢集發生意外，如宕機，叢集將無法使用，直到管理員重啟
NameNode機器需要升級，包括軟體、硬體升級，此時叢集將無法使用
其實在Hadoop2.0之前，在HDFS叢集中NameNode是存在單點故障的。
HA的重要性
那麼什麼是HDFS的HA呢，也就是說HA的功能通過配置Active/Standby兩個NameNodes來解決在叢集中NameNode單點故障的問題。如果對外提供服務的Active節點出現故障或者需要升級，這時我們可以通過HA將NameNode很快的切換到另一臺機器上，繼續對外服務。從而達到HDFS的高可用性。
HA的架構設計中，我們設計了兩臺NameNode節點。當然對於客戶端訪問來說，我們也是需要做一個代理的。為什麼要代理？對於客戶端訪問來說，HDFS是透明的，你有多少臺NameNode節點，客戶端並不關心，你HDFS只要保證一點，能讓我正常訪問HDFS系統就OK。但對於HDFS系統來說，兩個NameNode，你得選擇哪個提供給客戶端訪問，所以必須要有代理機制。也就是在NameNode的上層必須要有一個代理層。那這個代理層就需要我們之前說的協同服務框架Zookeeper來做。
基於上面的架構圖，我們來思考一個問題：
如何保證edit日誌檔案的安全和完整
我們兩個NameNode節點，如果Active節點宕機，我Standby節點要接著繼續對服務，那麼這個正常對外服務源自與檔案元資料的完整性，也就是說Active節點要實時非常安全、完整的記錄檔案的操作日誌資訊，這樣Standby在讀取的時候，讀取的日誌資訊是完整的，當Active節點宕機，Standby才能接手繼續工作。
方案一：一個好的檔案系統
找一臺比較好的 伺服器 ，作為外部的檔案儲存裝置，Active節點的NameNode將edit日誌檔案寫入，Standby節點的NameNode將讀取寫入的日誌檔案。那麼這種方案需要好的 企業級 服務。成本上來說代價昂貴，與我們小成本、大叢集的分散式理念相違背。
方案二：分散式儲存日誌資訊QJM
NameNode 管理檔案 的元資料，包括fsimage和edits，在開始啟動的時候NameNode的Active節點和Standby節點元資料是一樣的。但是啟動之後，Active節點提供對外服務，那麼它的edits日誌檔案在不停的變化，這個時候兩個NameNode節點上的日誌檔案肯定是不一樣的。那麼就需要一種機制，保證Active節點的日誌安全的寫入某個地方，並且讓Standby節點能完整的讀取。
我們說HDFS檔案的安全性和完整性是通過DataNode節點副本的方式來保證的，每一個檔案的儲存預設至少是3份。那麼我們的edit日誌檔案為了保證安全性，也類似於DataNode檔案的儲存方式，以2n+1副本的方式進行儲存。n表示允許損壞的機器節點數量。也就是說Active的NameNode節點將edit日誌存三份，允許其中一個節點寫入edit日誌失敗。那麼負責儲存edit日誌檔案節點程序是誰呢？就是 JournalNode。它的節點數必須是奇數。JournalNode負責管理edit日誌檔案的安全性和完整性，從而達到NameNode的Active節點與Standby節點之間元資料的同步。
“use HDFS HA using the Quorum Journal Manager (QJM) to share edit logs between the Active and Standby NameNodes“這是官網的一句話。QJM，分散式的日誌管理，節點名稱就是 JournalNode。
方案三：使用ZooKeeper進行資料儲存
edits檔案資料量不是很大，所以我們也可以採用ZooKeeper進行儲存。
那麼一般架構設計中，還是採用QJM分散式日誌儲存來達到兩個NameNode節點之間元資料的同步。
不管是Active節點還是Standby節點，每個DataNode服務必須報告自己的塊資訊。
一下說明來自官方：
Note that, in an HA cluster, the Standby NameNode also performs checkpoints of the namespace state, and thus it is not necessary to run a Secondary NameNode, CheckpointNode, or BackupNode in an HA cluster. In fact, to do so would be an error. This also allows one who is reconfiguring a non-HA-enabled HDFS cluster to be HA-enabled to reuse the hardware which they had previously dedicated to the Secondary NameNode。
第四階段：HDFS故障自動轉移
兩個NameNode，我們需要自動切換故障轉移，那麼我們需要藉助HDFS的ZKFC程序，這個程序是給予ZooKeeper的。首先我們需要配置好ZooKeeper。
這個配置很簡單
第五階段：YARN的HA
其實YARN的HA配置比HDFS要簡單的多，YARN的HA只是基於ZooKeeper來配置它的高可用性。在Hadoop2.4版本之前是單節點故障。
我們說故障轉移，是不是跟HDFS一樣需要有個ZKFC的程序呢，其實它是有的。只不過RM中的ZKFC是以執行緒的方式存在於RM的程序中。所以，在配置故障轉移的時候，我們不需要像HDFS一樣單獨去啟動一個ZKFC程序。
