前言
該部署文檔是筆者在一台配置稍微較高的筆記本電腦上利用虛拟化技術(VMware)建立3台linux作業系統虛拟機作為分布式搭建基礎來操練大資料hadoop架構搭建，高度模拟出符合/類似生産環境的搭建方式進行部署，為在生産環境使用提供更真實的參考價值!
附錄A中簡單列出了真實生産環境部署的方式建議供參考
改文章屬于筆記性文章，這裡筆者隻是純屬記錄友善以後查閱。
HDFS原理
HDFS具有主/從架構。HDFS叢集由單個NameNode，一個管理檔案系統命名空間的主伺服器和管理用戶端對檔案的通路組成。此外，還有許多DataNode，通常是群集中每個節點一個，用于管理連接配接到它們運作的節點的存儲。HDFS公開檔案系統命名空間，并允許使用者資料存儲在檔案中。在内部，檔案被分成一個或多個塊，這些塊存儲在一組DataNode中。NameNode執行檔案系統命名空間操作，如打開，關閉和重命名檔案和目錄。它還确定了塊到DataNode的映射。DataNode負責提供來自檔案系統用戶端的讀寫請求。DataNodes還執行塊建立，删除。
NameNode和DataNode是設計用于在商用機器上運作的軟體。這些機器通常運作GNU / Linux作業系統（OS）。HDFS是使用Java語言建構的; 任何支援Java的機器都可以運作NameNode或DataNode軟體。使用高度可移植的Java語言意味着可以在各種計算機上部署HDFS。典型部署具有僅運作NameNode軟體的專用計算機。群集中的每台其他計算機都運作一個DataNode軟體執行個體。該體系結構不排除在同一台機器上運作多個DataNode，但在實際部署中很少出現這種情況。
群集中存在單個NameNode極大地簡化了系統的體系結構。NameNode是所有HDFS中繼資料的仲裁者和存儲庫。系統的設計使使用者資料永遠不會流經NameNode
HDFS旨在可靠地在大型群集中的計算機上存儲非常大的檔案。它将每個檔案存儲為一系列塊。複制檔案的塊以實作容錯。塊大小和複制因子可根據檔案進行配置。
除最後一個塊之外的檔案中的所有塊都具有相同的大小，而使用者可以在添加對可變長度塊的支援以追加和hsync之後啟動新塊而不将最後一個塊填充到配置的塊大小。
應用程式可以指定檔案的副本數。複制因子可以在檔案建立時指定，并可以在以後更改。HDFS中的檔案是一次寫入的（除了追加和截斷），并且在任何時候都有一個寫入器。
NameNode做出有關塊複制的所有決定。它定期從群集中的每個DataNode接收Heartbeat和Blockreport。收到心跳意味着DataNode正常運作。Blockreport包含DataNode上所有塊的清單。
複制品的放置對HDFS的可靠性和性能至關重要。優化副本放置可将HDFS與大多數其他分布式檔案系統區分開來。這是一項需要大量調整和體驗的功能。機架感覺副本放置政策的目的是提高資料可靠性，可用性和網絡帶寬使用率。副本放置政策的目前實作是朝這個方向的第一次努力。實施此政策的短期目标是在生産系統上驗證它，更多地了解其行為，并為測試和研究更複雜的政策奠定基礎。
大型HDFS執行個體在通常分布在多個機架上的計算機群集上運作。不同機架中兩個節點之間的通信必須通過交換機。在大多數情況下，同一機架中的計算機之間的網絡帶寬大于不同機架中的計算機之間的網絡帶寬。
NameNode通過Hadoop Rack Awareness中概述的過程确定每個DataNode所屬的機架ID 。一個簡單但非最優的政策是将複制品放在獨特的機架上。這可以防止在整個機架出現故障時丢失資料，并允許在讀取資料時使用來自多個機架的帶寬。此政策在群集中均勻分布副本，這樣可以輕松平衡元件故障的負載。但是，此政策會增加寫入成本，因為寫入需要将塊傳輸到多個機架。
對于常見情況，當複制因子為3時，HDFS的放置政策是在編寫器位于datanode上時将一個副本放在本地計算機上，否則放在随機datanode上，在另一個（遠端）機架上的節點上放置另一個副本，最後一個在同一個遠端機架中的另一個節點上。此政策可以減少機架間寫入流量，進而提高寫入性能。機架故障的可能性遠小于節點故障的可能性; 此政策不會影響資料可靠性和可用性保證。但是，它确實減少了讀取資料時使用的聚合網絡帶寬，因為塊隻放在兩個唯一的機架而不是三個。使用此政策時，檔案的副本不會均勻分布在機架上。三分之一的副本位于一個節點上，三分之二的副本位于一個機架上，另外三分之一均勻分布在剩餘的機架上。此政策可提高寫入性能，而不會影響資料可靠性或讀取性能。
如果複制因子大于3，則随機确定第4個及以下副本的放置，同時保持每個機架的副本數量低于上限（基本上是（副本 - 1）/機架+ 2）。
由于NameNode不允許DataNode具有同一塊的多個副本，是以建立的最大副本數是此時DataNode的總數。
在将存儲類型和存儲政策的支援添加到HDFS之後，除了上述機架感覺之外，NameNode還會考慮政策以進行副本放置。NameNode首先根據機架感覺選擇節點，然後檢查候選節點是否具有與檔案關聯的政策所需的存儲。如果候選節點沒有存儲類型，則NameNode将查找另一個節點。如果在第一個路徑中找不到足夠的節點來放置副本，則NameNode會在第二個路徑中查找具有回退存儲類型的節點。
此處描述的目前預設副本放置政策是正在進行的工作。
為了最大限度地減少全局帶寬消耗和讀取延遲，HDFS嘗試滿足最接近讀取器的副本的讀取請求。如果在與讀取器節點相同的機架上存在副本，則該副本首選滿足讀取請求。如果HDFS群集跨越多個資料中心，則駐留在本地資料中心的副本優先于任何遠端副本。
部署伺服器清單
這裡僅說明3台機子，ip是筆者部署後的ip位址，讀者請按你自己的為準（具體ip設定方式後面有講解）! 另外由于用于學習，是以機子配置很低，實際中的生産環境應該使用更多的機子和更高的配置；
筆者實體機（DELL 筆記本）配置資訊：
cpu（Intel(R) i5-7200U）
記憶體（RAM）
磁盤（SSD）
4Core
8G
256M
虛拟化3台虛拟機配置資訊：
節點名稱
ip
cpu
記憶體
磁盤
node1
192.168.137.101
1C
2G
10G
node2
192.168.137.102
node3
192.168.137.103
虛拟化3個節點
這裡參考筆者的另外一篇文章：建立虛拟機
叢集部署前期工作
這裡筆者使用XShell ssh用戶端通路3個伺服器節點，通路比較友善，可以将某條指令發送到目前的所有會話
安裝/更新 ntpdate指令，發送到3個節點
筆者使用阿裡雲網絡伺服器，讀者可以自行百度其它的
vi /etc/hosts
複制下面内容到hosts檔案
分發到其它兩台節點在node2 node3節點分别執行：
所有節點執行：
一路回車即可建立ssh公私鑰，建立ssh公私鑰匙後通過執行下面指令配置免密：
測試免密：
測試OK後進入下一步
jdk8下載下傳和安裝不示範，這裡主要給出規劃的目錄：
1、軟體壓縮包放置目錄: /opt/zip
2、軟體解壓放置目錄: /opt/soft
3、hdfs資料存儲目錄: /var/hadoop/hdfs
自行下載下傳，這裡注意版本号為：3.1.1，下載下傳到/opt/zip 解壓到/opt/soft， 配置環境變量
vi /etc/profile
筆者追加内容到/etc/profile如下：
執行source /etc/profile使配置生效。
檢查指令：
部署計劃
hdfs
node1(Master)
NameNode
Secondary Namenode
node2(Work)
DataNode
node3(Work)
配置HDFS相關檔案
由于叢集環境節點比較多，配置需要方法，這裡思路是先配置好一個節點，然後使用scp指令分發到其它節點，下面是分别對不同的配置檔案進行配置說明：
$HADOOP_HOME/etc/hadoop/hadoop-env.sh末尾追加如下内容：
注意：官方推薦hdfs，yarm，分别建立使用者,這裡簡單起見，直接統一使用root使用者，生産環境建議按官方推薦方式配置。
$HADOOP_HOME/etc/hadoop/core-site.xml配置内容如下：
$HADOOP_HOME/etc/hadoop/hdfs-site.xml配置内容如下：
$HADOOP_HOME/etc/hadoop/workersl配置内容如下：
在需要分發的節點上執行:
所有節點執行: source /etc/profile使配置生效。
啟動hadoop
用jps指令檢查目前節點是否有java程序，如果有請先停掉，然後在master（node1）節點執行啟動腳本：
node1:
node2:
node3:
浏覽器通路：
節點資訊界面：http://192.168.137.101:9870
所有應用管理界面：http://192.168.137.101:8088
job任務曆史記錄界面：http://192.168.137.101:19888
還有一點要說明的是啟動log在$HADOOP_HOME/logs目錄下，可以在hadoop-env.sh進行配置HADOOP_LOG_DIR；如HADOOP_LOG_DIR=/tmp/hadoop/logs
操作HDFS
檢視指令幫助：
檢視目錄清單：
建立目錄後檢視:
更多指令可以檢視官網：
https://hadoop.apache.org/docs/r3.1.1/hadoop-project-dist/hadoop-common/FileSystemShell.html#ls
NameNode高可用
在典型的HA群集中，兩個或多個單獨的計算機配置為NameNode。在任何時間點，其中一個NameNode處于活動狀态，而其他NameNode 處于待機狀态。Active NameNode負責叢集中的所有用戶端操作，而Standbys隻是充當工作者，維持足夠的狀态以在必要時提供快速故障轉移。
為了使備用節點保持其狀态與Active節點同步，兩個節點都與一組稱為“JournalNodes”（JN）的單獨守護程序通信。當Active節點執行任何名稱空間修改時，它會将修改記錄持久地記錄到大多數這些JN中。待機節點能夠從JN讀取編輯，并且不斷觀察它們對編輯日志的更改。當備用節點看到編輯時，它會将它們應用到自己的命名空間。如果發生故障轉移，Standby将確定在将自身更新為Active狀态之前已從JournalNodes讀取所有編輯内容。這可確定在發生故障轉移之前完全同步命名空間狀态。
為了提供快速故障轉移，備用節點還必須具有關于群集中塊的位置的最新資訊。為了實作這一點，DataNode配置了所有NameNode的位置，并向所有人發送塊位置資訊和心跳。
對于HA群集的正确操作而言，一次隻有一個NameNode處于活動狀态至關重要。否則，命名空間狀态将在兩者之間快速分歧，冒着資料丢失或其他不正确結果的風險。為了確定這個屬性并防止所謂的“裂腦情景”，JournalNodes隻允許一個NameNode一次成為一個作家。在故障轉移期間，要激活的NameNode将簡單地接管寫入JournalNodes的角色，這将有效地阻止其他NameNode繼續處于Active狀态，進而允許新的Active安全地進行故障轉移。
通過QJM實作NameNode的HA群集，您應準備以下内容：
NameNode - 運作Active和Standby NameNode的計算機應具有彼此相同的硬體，以及與非HA叢集中使用的硬體等效的硬體。
JournalNode - 運作JournalNodes的計算機。JournalNode守護程式相對輕量級，是以這些守護程式可以合理地與其他Hadoop守護程式并置在機器上，例如NameNodes，JobTracker或YARN ResourceManager。注意：必須至少有3個JournalNode守護程序，因為編輯日志修改必須寫入大多數JN。這将允許系統容忍單個機器的故障。您也可以運作3個以上的JournalNodes，但為了實際增加系統可以容忍的失敗次數，您應該運作奇數個JN（即3,5,7等）。請注意，當使用N JournalNodes運作時，系統最多可以容忍（N-1）/ 2個故障并繼續正常運作。
請注意，在HA群集中，備用NameNode還會執行命名空間狀态的檢查點，是以無需在HA群集中運作Secondary NameNode，CheckpointNode或BackupNode。事實上，這樣做會是一個錯誤。這還允許正在重新配置啟用HA的HDFS群集的人員啟用HA，以重用他們之前專用于Secondary NameNode的硬體。
通過QJM實作NameNode的高可用部署，具體部署如下：
現有部署如下：
在現有部署結構上增加Quorum Journal Manager相關角色進來之後的部署如下：
QJM
JournalNode
要配置HA NameNode，必須向hdfs-site.xml配置檔案添加多個配置選項。首先配置叢集名稱
以及叢集中每個namenode id
上面設定的這些配置的順序并不重要，但您為dfs.nameservices和dfs.ha.namenodes。[nameservice ID]選擇的值将确定後面的那些鍵。是以，在設定其餘配置選項之前，您應該決定這些值。
HA的NameNode最小數量為2，但您可以配置更多。由于通信開銷，建議不要超過5 - 推薦3個NameNodes。
下面對于兩個先前配置的NameNode ID，設定NameNode程序的完整位址和IPC端口
與上面的rpc-address類似，設定兩個NameNodes的HTTP伺服器的位址以進行偵聽
這是一個配置JournalNodes的位址的地方，它提供共享編輯存儲，由Active nameNode寫入并由Standby NameNode讀取，以保持Active NameNode所做的所有檔案系統更改的最新狀态。雖然您必須指定多個JournalNode位址，但您應該隻配置其中一個URI。URI應該是以下形式：qjournal：// * host1：port1 *; * host2：port2 *; * host3：port3 * / * journalId *。Journal ID是此nameservice的唯一辨別符，它允許一組JournalNodes為多個聯合名稱系統提供存儲。雖然不是必需的，但最好重用日志辨別符的名稱服務ID。
例如，如果此群集的JournalNodes在計算機“node1”，“node2”和“node3”上運作，并且名稱服務ID是“mycluster”，則您将使用以下為此設定的值（JournalNode的預設端口為8485）：
存儲JN使用的編輯和其他本地狀态
配置Java類的名稱，DFS用戶端将使用該名稱來确定哪個NameNode是目前的Active，以及哪個NameNode目前正在為用戶端請求提供服務。目前Hadoop附帶的兩個實作是ConfiguredFailoverProxyProvider和RequestHedgingProxyProvider（對于第一次調用，它同時調用所有名稱節點以确定活動的名稱，并在後續請求中調用活動的名稱節點直到發生故障轉移），是以除非您使用自定義代理提供程式，否則請使用其中一個。
對于系統的正确性，期望在任何給定時間隻有一個NameNode處于活動狀态。重要的是，在使用Quorum Journal Manager時，隻允許一個NameNode寫入JournalNodes，是以不存在從裂腦情況中破壞檔案系統中繼資料的可能性。但是，當發生故障轉移時，以前的Active NameNode仍可能向用戶端提供讀取請求，這可能已過期，直到NameNode在嘗試寫入JournalNode時關閉。是以，即使使用Quorum Journal Manager，仍然需要配置一些防護方法。但是，為了在防護機制失敗的情況下提高系統的可用性，建議配置防護方法，該方法可保證作為清單中的最後一個防護方法傳回成功
如果shell指令傳回退出代碼0，則确定防護成功。如果它傳回任何其他退出代碼，則防護不成功，将嘗試清單中的下一個防護方法。是以為了加強防護能力，可以适當多配置幾個選項， 如：
配置完成後的hdfs-site.xml檔案内容如下：
配置Hadoop用戶端的預設路徑以使用新的啟用HA的邏輯URI
配置完成後新的core-site.xml檔案内容如下：
末尾追加:
其它節點執行指令:
在設定了所有必需的配置選項後，必須在将運作它們的一組計算機上啟動JournalNode守護程式。這可以通過運作指令“ hdfs --daemon start journalnode ”并等待守護程序在每個相關機器上啟動來完成。
一旦啟動了JournalNodes，就必須首先同步兩個HA NameNodes的磁盤中繼資料。
如果要設定新的HDFS叢集，則應首先在其中一個NameNode上運作format指令（hdfs namenode -format）。
如果您已經格式化了NameNode，或者正在将啟用了HA的群集轉換為啟用HA，則現在應該通過運作指令将NameNode中繼資料目錄的内容複制到其他未格式化的NameNode上。hdfs namenode -bootstrapStandby “在未格式化的NameNode上。運作此指令還将確定JournalNodes（由dfs.namenode.shared.edits.dir配置）包含足夠的編輯事務，以便能夠啟動兩個NameNode。
如果要将非HA NameNode轉換為HA，則應運作指令“ hdfs namenode -initializeSharedEdits ”，該指令将使用本地NameNode編輯目錄中的編輯資料初始化JournalNodes。
我們适用的情況是将非HA NameNode轉換為HA，則應運作指令“ hdfs namenode -initializeSharedEdits ”，在運作該指令前需要先停止Secondary NameNode，CheckpointNode或BackupNode，以及namenode，具體執行指令步驟如下：
在所有節點執行：
在主節點node1執行：
在主節點node1繼續執行stop-dfs.sh：
在主節點node1繼續執行start-dfs.sh：
執行jps指令檢視啟動情況：
其它節點執行:
jps
回到node1節點執行:
此時，您可以像通常啟動NameNode一樣啟動所有HA NameNode。
您可以通過浏覽到配置的HTTP位址，分别通路每個NameNodes的網頁。您應該注意到，配置的位址旁邊将是NameNode的HA狀态（“待機”或“活動”）。每當HA NameNode啟動時，它最初處于待機狀态。
現在您的HA NameNode已配置并啟動，您将可以通路一些其他指令來管理HA HDFS叢集。具體來說，您應該熟悉“ hdfs haadmin ”指令的所有子指令。在沒有任何其他參數的情況下運作此指令将顯示以下用法資訊：
用法：haadmin
本指南介紹了每個子指令的進階用法。有關每個子指令的特定用法資訊，您應該運作“ hdfs haadmin -help <command >”。
transitionToActive和transitionToStandby - 将給定NameNode的狀态轉換為Active或Standby這些子指令使給定的NameNode分别轉換為Active或Standby狀态。這些指令不會嘗試執行任何防護，是以很少使用。相反，人們幾乎總是喜歡使用“ hdfs haadmin -failover ”子指令。
failover - 在兩個NameNode之間啟動故障轉移此子指令導緻從第一個提供的NameNode到第二個NameNode的故障轉移。如果第一個NameNode處于Standby狀态，則此指令隻是将第二個NameNode轉換為Active狀态而不會出現錯誤。如果第一個NameNode處于活動狀态，将嘗試将其正常轉換為待機狀态。如果失敗，将按順序嘗試防護方法（由dfs.ha.fencing.methods配置），直到成功為止。隻有在此過程之後，第二個NameNode才會轉換為Active狀态。如果沒有防護方法成功，則第二個NameNode将不會轉換為活動狀态，并且将傳回錯誤。
getServiceState - 确定給定的NameNode是Active還是Standby連接配接到提供的NameNode以确定其目前狀态，适當地将“待機”或“活動”列印到STDOUT。此子指令可能由cron作業或監視腳本使用，這些腳本需要根據NameNode目前是活動還是待機而表現不同。
getAllServiceState - 傳回所有NameNode的狀态連接配接到已配置的NameNodes以确定目前狀态，适當地将“待機”或“活動”列印到STDOUT。
checkHealth - 檢查給定NameNode的運作狀況連接配接到提供的NameNode以檢查其運作狀況。NameNode能夠對自身執行某些診斷，包括檢查内部服務是否按預期運作。如果NameNode是健康的，則此指令将傳回0，否則傳回非零。可以使用此指令進行監視。注意：這尚未實作，并且除非給定的NameNode完全關閉，否則目前将始終傳回成功。
以上部分介紹了如何配置手動故障轉移。在該模式下，即使活動節點發生故障，系統也不會自動觸發從活動狀态到備用NameNode的故障轉移。本節介紹如何配置和部署自動故障轉移。
自動故障轉移為HDFS部署添加了兩個新元件：ZooKeeper仲裁和ZKFailoverController程序（縮寫為ZKFC）。
Apache ZooKeeper是一種高可用性服務，用于維護少量協調資料，通知用戶端該資料的更改以及監視用戶端是否存在故障。自動HDFS故障轉移的實作依賴于ZooKeeper來實作以下功能：
故障檢測 - 叢集中的每個NameNode計算機都在ZooKeeper中維護一個持久會話。如果計算機崩潰，ZooKeeper會話将過期，通知其他NameNode應該觸發故障轉移。
Active NameNode選舉 - ZooKeeper提供了一種簡單的機制，可以将節點專門選為活動節點。如果目前活動的NameNode崩潰，則另一個節點可能在ZooKeeper中采用特殊的獨占鎖，訓示它應該成為下一個活動的。
ZKFailoverController（ZKFC）是一個新元件，它是一個ZooKeeper用戶端，它還監視和管理NameNode的狀态。運作NameNode的每台機器也運作ZKFC，ZKFC負責：
運作狀況監視 - ZKFC定期使用運作狀況檢查指令對其本地NameNode進行ping操作。隻要NameNode及時響應健康狀态，ZKFC就認為該節點是健康的。如果節點已崩潰，當機或以其他方式進入不健康狀态，則運作狀況螢幕會将其标記為運作狀況不佳。
ZooKeeper會話管理 - 當本地NameNode運作正常時，ZKFC在ZooKeeper中保持會話打開。如果本地NameNode處于活動狀态，它還擁有一個特殊的“鎖定”znode。此鎖使用ZooKeeper對“短暫”節點的支援; 如果會話過期，将自動删除鎖定節點。
基于ZooKeeper的選舉 - 如果本地NameNode是健康的，并且ZKFC發現沒有其他節點目前持有鎖znode，它将自己嘗試擷取鎖。如果成功，那麼它“赢得了選舉”，并負責運作故障轉移以使其本地NameNode處于活動狀态。故障轉移過程類似于上述手動故障轉移：首先，必要時對先前的活動進行隔離，然後本地NameNode轉換為活動狀态。
有關自動故障轉移設計的更多詳細資訊，請參閱Apache HDFS JIRA上附加到HDFS-2185的設計文檔。
在典型部署中，ZooKeeper守護程式配置為在三個或五個節點上運作。由于ZooKeeper本身具有輕量級資源要求，是以可以在與HDFS NameNode和備用節點相同的硬體上并置ZooKeeper節點。許多營運商選擇在與YARN ResourceManager相同的節點上部署第三個ZooKeeper程序。建議将ZooKeeper節點配置為将資料存儲在與HDFS中繼資料不同的磁盤驅動器上，以獲得最佳性能和隔離。
ZooKeeper的設定超出了本文檔的範圍。我們假設您已經設定了在三個或更多節點上運作的ZooKeeper叢集，并通過使用ZK CLI進行連接配接來驗證其正确的操作。
由于資源有限，我們依舊在現有的3台機子上進行部署Zookeeper，部署結構如下:
ZK
ZKFC
leader
follower
1、所有節點建立目錄
2、在其中node1節點上下載下傳解壓zookeeper
3、配置ZOO_HOME到/etc/profile
4、vi zoo.cfg内容如下：
5、分發到node2 node3
在開始配置自動故障轉移之前，應關閉群集。當群集運作時，目前無法從手動故障轉移設定轉換為自動故障轉移設定。
自動故障轉移的配置需要在配置中添加兩個新參數。在hdfs-site.xml檔案中，添加：
開啟群集以進行自動故障轉移
在您的core-site.xml檔案中，添加：
列出運作ZooKeeper服務的主機端口對
在您的hadoop-env.sh檔案中追加：
将hdfs-site.xml和core-site.xml在需要分發的其它節點(如果像筆者總是在node1進行配置，然後分發到node2,node3)上執行
下一步是在ZooKeeper中初始化所需的狀态。您可以通過從其中一個NameNode主機運作以下指令來執行此操作。我們選擇在node1節點執行:
這将在ZooKeeper中建立一個znode，為自動故障轉移系統存儲其資料。
由于配置中已啟用自動故障轉移，是以start-dfs.sh腳本現在将在運作NameNode的任何計算機上自動啟動ZKFC守護程式。當ZKFC啟動時，它們将自動選擇其中一個NameNode變為活動狀态。
手動啟動zkfs
手動停止zkfs
通過下面三個位址進行測試：
http://node1:9870
http://node2:9870
http://node3:9870
首先找到Active的NameNode所在節點，然後在那個節點上執行: hdfs --daemon stop namenode将其NameNode停止模拟故障，然後我們再看看其它兩個節點是否有其它一個狀态變為Active。筆者機子測試時node1狀态變為Active
我們在node1也執行:hdfs --daemon stop namenode，此時來看看node2狀态是否從standby變為active
再重新整理一下可以看到變為activie.
然後再啟動node1和node3,可以看到node1和node3都是standby,node2為active：
可以看到，NameNode目前确實做到了自動故障轉移的能力！
如果您正在運作安全群集，則可能需要確定ZooKeeper中存儲的資訊也是安全的。這可以防止惡意用戶端修改ZooKeeper中的中繼資料或可能觸發錯誤的故障轉移。
在配置之前，我們可以登入zookeeper，嘗試随意通路：
可以看到，沒有任何限制，全世界都具有對hadoop-ha節點的cdrwa所有權限；
為了保護ZooKeeper中的資訊，首先将以下内容添加到core-site.xml檔案中：
請注意這些值中的“@”字元 - 這指定配置不是内聯的，而是指向磁盤上的檔案。身份驗證資訊也可以通過CredentialProvider讀取（請參閱hadoop-common項目中的CredentialProviderAPI指南）。
第一個配置的檔案指定ZooKeeper身份驗證清單，格式與ZK CLI使用的格式相同。例如，您可以指定以下内容：
其中hdfs-zkfcs是ZooKeeper的唯一使用者名，mypassword是一些用作密碼的唯一字元串
接下來，使用如下指令生成與此身份驗證對應的ZooKeeper ACL：
注意：
zookeeper-3.3.6.jar是你所安裝zookeeper的具體名稱；
$ZOO_HOME是你具體配置的環境變量名稱；
hdfs-zkfcs:mypassword是你寫入zk-auth.txt去掉digest:字首後的内容
執行完成後輸出：
其中cdrwa代表具體權限
将此輸出的部分複制并粘貼到“ - >”字元串後面的zk-acl.txt檔案中，字首為字元串“ digest： ”。例如：
最後在所有節點執行如下指令：
在需要分發的節點執行如下指令：
為了使這些ACL生效，您應該重新運作hdfs zkfc -formatZK指令，執行此操作後，您可以從ZK CLI驗證ACL，如下所示：
所有節點執行指令如下：
其中一個節點，筆者這裡選擇node1執行:
中途有詢問時輸入Y進行确認
連接配接zookeeper:
可以看到限制目錄對指定的使用者和密碼才有cdrwa的權限
雖然HDFS HA解決了“單點故障”問題，但是在系統擴充性、整體性能和隔離性方面仍然存在問題。
（1） 系統擴充性方面，中繼資料存儲在NN記憶體中，受記憶體上限的制約。
（2） 整體性能方面，吞吐量受單個NN的影響。
（3） 隔離性方面，一個程式可能會影響其他運作的程式，如一個程式消耗過多資源導緻其他程式無法順利運作。HDFS HA本質上還是單名稱節點。HDFS聯邦可以解決以上三個方面問題。
在HDFS聯邦中，設計了多個互相獨立的NN，使得HDFS的命名服務能夠水準擴充，這些NN分别進行各自命名空間和塊的管理，不需要彼此協調。每個DN要向叢集中所有的NN注冊，并周期性的發送心跳資訊和塊資訊，報告自己的狀态。
HDFS聯邦擁有多個獨立的命名空間，其中，每一個命名空間管理屬于自己的一組塊，這些屬于同一個命名空間的塊組成一個“塊池”。每個DN會為多個塊池提供塊的存儲，塊池中的各個塊實際上是存儲在不同DN中的。
1、命名空間可伸縮性 - 聯合添加命名空間水準擴充。通過允許将更多Namenode添加到群集中，使用大量小檔案的大型部署或部署可從命名空間擴充中受益。
2、性能 - 檔案系統吞吐量不受單個Namenode的限制。向叢集添加更多名稱節點可擴充檔案系統讀/寫吞吐量。
3、隔離 - 單個Namenode在多使用者環境中不提供隔離。例如，實驗應用程式可能會使Namenode過載并減慢生産關鍵應用程式的速度。通過使用多個Namenode，可以将不同類别的應用程式和使用者隔離到不同的名稱空間。
聯邦一般在大公司内使用，中小企業使用場景相對較少，具體配置和搭建這裡不做介紹，有興趣可以自行查詢網絡資料進行搭建。
在HDFS中，DataNode 将資料塊存儲到本地檔案系統目錄中，具體的目錄可以通過配置 hdfs-site.xml 裡面的 dfs.datanode.data.dir 參數。在典型的安裝配置中，一般都會配置多個目錄，并且把這些目錄分别配置到不同的裝置上，比如分别配置到不同的HDD(HDD的全稱是Hard Disk Drive)和SSD(全稱Solid State Drives，就是我們熟悉的固态硬碟)上。
當我們往HDFS上寫入新的資料塊，DataNode 将會使用volume選擇政策來為這個塊選擇存儲的地方。目前Hadoop支援兩種volume選擇政策：round-robin 和 available space(詳情參見：HDFS-1804)，我們可以通過 dfs.datanode.fsdataset.volume.choosing.policy 參數來設定。
循環(round-robin)政策将新塊均勻分布在可用磁盤上;而可用空間( available-space )政策優先将資料寫入具有最大可用空間的磁盤(通過百分比計算的)。正如下圖所示：
預設情況下，DataNode 是使用基于round-robin政策來寫入新的資料塊。然而在一個長時間運作的叢集中，由于HDFS中的大規模檔案删除或者通過往DataNode 中添加新的磁盤仍然會導緻同一個DataNode中的不同磁盤存儲的資料很不均衡。即使你使用的是基于可用空間的政策，卷(volume)不平衡仍可導緻較低效率的磁盤I/O。比如所有新增的資料塊都會往新增的磁盤上寫，在此期間，其他的磁盤會處于空閑狀态，這樣新的磁盤将會是整個系統的瓶頸。
Diskbalancer是一個指令行工具，可以在datanode的所有磁盤上均勻配置設定資料。此工具與Balancer不同， 後者負責叢集範圍的資料平衡。由于多種原因，資料在節點上的磁盤之間可能存在不均勻的擴散。這可能是由于大量寫入和删除或由于磁盤更換造成的。此工具針對給定的datanode運作，并将塊從一個磁盤移動到另一個磁盤。
讓我們通過一個例子逐漸探讨這個有用的功能。首先，確定所有DataNode上的 dfs.disk.balancer.enabled 參數設定成true。本例子中，我們的DataNode已經挂載了一個磁盤(/mnt/disk1)，現在我們往這個DataNode上挂載新的磁盤(/mnt/disk2)，我們使用 df指令來顯示磁盤的使用率：
從上面的輸出可以看出，兩個磁盤的使用率很不均衡，是以我們來将這兩個磁盤的資料均衡一下。
在這之前，先停掉hdfs叢集:
請注意，群集上預設情況下不啟用磁盤平衡器。要啟用diskbalancer，必須在hdfs-site.xml 中将dfs.disk.balancer.enabled設定為true。
配置好之後分發到其它節點：
啟動hdfs叢集：
典型的磁盤平衡器任務涉及三個步驟(通過HDFS的diskbalancer 指令)：plan, execute 和 query。第一步，HDFS用戶端從NameNode上讀取指定DataNode的的必要資訊以生成執行計劃：
hdfs diskbalancer -plan node2(這裡必須是DataNode)
磁盤平衡執行計劃生成的檔案内容格式是Json的，并且存儲在HDFS之上。在預設情況下，這些檔案是存儲在 /system/diskbalancer 目錄下面：
hdfs dfs -ls /system/diskbalancer/xxxxxx (具體路徑從控制台輸出複制)
可以通過下面的指令在DataNode上執行這個生成的計劃：
hdfs diskbalancer -execute /system/diskbalancer/xxxxx (具體路徑從控制台輸出複制)
這個指令将JSON裡面的計劃送出給DataNode，而DataNode會啟動一個名為BlockMover的線程中執行這個計劃。我們可以使用 query 指令來查詢DataNode上diskbalancer任務的狀态：
hdfs diskbalancer -query node2
上面結果輸出的PLAN_DONE表示disk-balancing task已經執行完成。為了驗證磁盤平衡器的有效性，我們可以使用df -h 指令來檢視各個磁盤的空間使用率：
df -h
HDFS快照是檔案系統的隻讀時間點副本。可以在檔案系統的子樹或整個檔案系統上拍攝快照。快照的一些常見用例是資料備份，防止使用者錯誤和災難恢複。
HDFS快照的實施非常有效：
快照建立是即時的：成本是O（1），不包括inode查找時間。
僅當相對于快照進行修改時才使用附加記憶體：記憶體使用量為O（M），其中M是已修改檔案/目錄的數量。
不複制datanode中的塊：快照檔案記錄塊清單和檔案大小。沒有資料複制。
快照不會對正常HDFS操作産生負面影響：以反向時間順序記錄修改，以便可以直接通路目前資料。通過從目前資料中減去修改來計算快照資料。
一旦将目錄設定為snapshottable，就可以在任何目錄上拍攝快照。快照目錄可以容納65,536個同步快照。快照目錄的數量沒有限制。管理者可以将任何目錄設定為快照。如果快照目錄中有快照，則在删除所有快照之前，既不能删除也不能重命名目錄。
目前不允許嵌套的快照目錄。換句話說，如果其祖先/後代之一是快照目錄，則無法将目錄設定為snapshottable。
針對一個snapshottable目錄，“.snapshot”路徑用來指定存放的快照。例如：/foo是一個snapshottable目錄，/foo/bar是一個 /foo下的一個檔案/目錄，并且/foo有一個快照s0，那麼路徑/foo/.snapshort/s0/bar 指向/foo/bar的快照。
參考官方文檔
yarn原理
Yarn是一個資源排程平台，負責為運算程式提供伺服器運算資源，相當于一個分布式的作業系統平台，而MapReduce等運算程式則相當于運作于作業系統之上的應用程式。
YARN是一個資源管理、任務排程的架構，主要包含三大子產品：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）。其中，ResourceManager負責所有資源的監控、配置設定和管理；ApplicationMaster負責每一個具體應用程式的排程和協調；NodeManager負責每一個節點的維護。對于所有的applications，RM擁有絕對的控制權和對資源的配置設定權。而每個AM則會和RM協商資源，同時和NodeManager通信來執行和監控task。幾個子產品之間的關系如圖所示。
ResourceManager:負責整個叢集的資源管理和配置設定，是一個全局的資源管理系統。
NodeManager以心跳的方式向ResourceManager彙報資源使用情況（目前主要是CPU和記憶體的使用情況）。RM隻接受NM的資源回報資訊，對于具體的資源處理則交給NM自己處理。
YARN Scheduler根據application的請求為其配置設定資源，不負責application job的監控、追蹤、運作狀态回報、啟動等工作。
NodeManager是每個節點上的資源和任務管理器，它是管理這台機器的代理，負責該節點程式的運作，以及該節點資源的管理和監控。YARN叢集每個節點都運作一個NodeManager。
NodeManager定時向ResourceManager彙報本節點資源（CPU、記憶體）的使用情況和Container的運作狀态。當ResourceManager當機時NodeManager自動連接配接RM備用節點.
NodeManager接收并處理來自ApplicationMaster的Container啟動、停止等各種請求。
ApplicationMaster使用者送出的每個應用程式均包含一個ApplicationMaster，它可以運作在ResourceManager以外的機器上。負責與RM排程器協商以擷取資源（用Container表示）。将得到的任務進一步配置設定給内部的任務(資源的二次配置設定)。與NM通信以啟動/停止任務。監控所有任務運作狀态，并在任務運作失敗時重新為任務申請資源以重新開機任務。目前YARN自帶了兩個ApplicationMaster實作，一個是用于示範AM編寫方法的執行個體程式DistributedShell，它可以申請一定數目的Container以并行運作一個Shell指令或者Shell腳本；另一個是運作MapReduce應用程式的AM—MRAppMaster。
注：RM隻負責監控AM，并在AM運作失敗時候啟動它。RM不負責AM内部任務的容錯，任務的容錯由AM完成。
(1) client向RM送出應用程式，其中包括啟動該應用的ApplicationMaster的必須資訊，例如ApplicationMaster程式、啟動ApplicationMaster的指令、使用者程式等。
(2) ResourceManager啟動一個container用于運作ApplicationMaster。
(3) 啟動中的ApplicationMaster向ResourceManager注冊自己，啟動成功後與RM保持心跳。
(4) ApplicationMaster向ResourceManager發送請求，申請相應數目的container。
(5) ResourceManager傳回ApplicationMaster的申請的containers資訊。申請成功的container，由ApplicationMaster進行初始化。container的啟動資訊初始化後，AM與對應的NodeManager通信，要求NM啟動container。AM與NM保持心跳，進而對NM上運作的任務進行監控和管理。
(6) container運作期間，ApplicationMaster對container進行監控。container通過RPC協定向對應的AM彙報自己的進度和狀态等資訊。
(7) 應用運作期間，client直接與AM通信擷取應用的狀态、進度更新等資訊。
(8) 應用運作結束後，ApplicationMaster向ResourceManager登出自己，并允許屬于它的container被收回。
這裡再次羅列出現有虛拟化3台機子的配置清單
在原有的機子上繼續添加yarn叢集程序，添加後的部署架構如下：
yarn
ResourceManager
NodeManager
配置yarn相關檔案
在任意節點（筆者選擇node1）修改配置：
修改mapre-site.xml
分發到其它節點
啟動yarn
在主節點node1 執行 start-yarn.sh 啟動完成後在所有節點執行jps:
ResourceManager高可用性
類似HDFS中的NameNode一樣，yarn元件的ResouRceManager角色同樣存在單點故障問題，在生産環境中，一般我們需要為ResouRceManager配置高可用從節點。以下是HA架構圖：
ResourceManager HA通過主/備架構實作 - 在任何時間點，其中一個RM處于活動狀态，并且一個或多個RM處于待機模式，等待活動發生任何事情時接管。轉換為活動的觸發器來自管理者（通過CLI）或啟用自動故障轉移時的內建故障轉移控制器。
如果未啟用自動故障轉移，則管理者必須手動将其中一個RM轉換為活動。要從一個RM故障轉移到另一個RM，它們應首先将Active-RM轉換為待機狀态，并将Standby-RM轉換為Active。所有這些都可以使用“ yarn rmadmin ”CLI完成。
RM可以選擇嵌入基于Zookeeper的ActiveStandbyElector來決定哪個RM應該是Active。當Active關閉或無響應時，另一個RM自動被選為Active，然後接管。請注意，不需要像HDFS那樣運作單獨的ZKFC守護程式，因為嵌入在RM中的ActiveStandbyElector充當故障檢測器和上司者選擇器而不是單獨的ZKFC守護程式。
在原有的機子上繼續添加yarn resourceManager HA高可用節點，在node2部署一個備用ResourceManager，高可用zk叢集使用現有的部署叢集，添加後的部署架構如下：
現yarn-site.xml完整配置資訊如下：
分發到其它兩個節點,在需要分發的節點上執行指令：
重新開機yarn, 在node1節點上執行:
在所有節點執行： jps
http://node1:8088
如果繼續通路node2：http://node2:8088 ，注意url位址會自動跳轉到active節點上：http://node1:8088
yarn rmadmin有一些特定于HA的指令選項，用于檢查RM的運作狀況和狀态，并轉換為Active / Standby。HA的指令将yarn.resourcemanager.ha.rm-ids設定的RM的服務id 作為參數。
輸出結果：active
輸出結果：standby
如果啟用了自動故障轉移，則無法使用手動轉換指令。雖然您可以通過-forcemanual标志覆寫它，但您需要謹慎。
送出mapreduce作業
在任意節點上執行下面指令即可：
至此，整個hdfs分布式部署講解完畢！
附錄A
由于集器資源有限，筆者在該文檔中使用的虛拟機配置極低，不适合生産使用，如果需要在真實生産環境部署分布式hdfs 和mapreduce yarn資料總管，需要加大節點資源配置，比如每個節點資源為：
CPU（核數）
節點數量
類型
4
8
500G
6
小型/初期資料量
16
按資料量計算
中大型/後期資料量
除此之外，還需要添加節點數量，這裡建議開始部署的節點數量是6台，部署計劃如下：
server
node4
node5
node6
...
随着資料量增大，通常對DataNode經常節點擴充。對于DataNode叢集擴充技術可以參考hadoop官方文檔相關内容。