翻譯： https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_hag_hdfs_ha_enabling.html
HDFS高可用性（HA）群集使用兩個NameNode（活動NameNode和備用NameNode）。在任意時刻只有一個NameNode處于活動狀態(tài)。HDFS HA維護一份名稱空間修改日志，兩個NameNode 都可以訪問得到，在發(fā)生故障時，備用NameNode可以獲取最新的名稱空間修改日志和集群中塊的位置信息。
重要提示：啟用和禁用HA會導致HDFS服務和依賴于HDFS的所有服務中斷服務。在啟用或禁用HA之前，請確保群集上沒有運行作業(yè)。
閱讀：
使用Cloudera Manager啟用HDFS HA
最低要求的角色： 群集管理員（也由完全管理員提供）
您可以使用Cloudera Manager為CDH 5群集配置HDFS HA的自動進行故障轉移。在Cloudera Manager 5中，HA使用Quorum-based的存儲實施。Quorum-based的存儲依賴于一組JournalNodes，每個JournalNode都維護一個本地目錄，用來記錄對名稱空間元數據的修改。啟用高可用性啟用自動故障轉移作為同一命令的一部分。
重要：
- 啟用或禁用HA會導致先前的監(jiān)控歷史記錄變得不可用。
- 一旦啟用JobTracker HA，一些參數將被自動設置。如果您想要更改這些參數的默認值，請使用高級配置。
- mapred.jobtracker.restart.recover：true
- mapred.job.tracker.persist.jobstatus.active：true
- mapred.ha.automatic-failover.enabled：true
- mapred.ha.fencing.methods：shell（true）
啟用高可用性和自動故障轉移
啟用高可用性的工作流程將引導您完成添加第二個（備用）NameNode和配置JournalNodes。
- 執(zhí)行HDFS HA硬件配置下描述的所有配置和設置任務。
- 確保你有一個ZooKeeper服務。
- 轉到HDFS服務。
- 選擇Actions > Enable High Availability。顯示有資格運行備用NameNode和JournalNodes的主機的頁面。
a. 為名稱服務指定一個名稱，然后單擊繼續(xù)。注意：為名稱服務使用唯一名稱。
b. 在NameNode主機字段中，單擊選擇主機。顯示主機選擇對話框。
c. 選中要設置備用NameNode的主機旁邊的復選框，然后單擊OK。備用NameNode不能與活動NameNode位于同一主機上，并且所選主機應具有與活動NameNode相同的硬件配置（RAM，磁盤空間，內核數量等）。
d. 在JournalNode主機字段中，單擊選擇主機。顯示主機選擇對話框。
e. 選中奇數個主機旁邊的復選框（至少三個）作為JournalNodes，然后單擊確定。JournalNodes應托管在與NameNodes具有相似硬件規(guī)格的主機上。Cloudera建議您將JournalNode分別放置在與活動和備用NameNode相同的主機上，以及類似硬件上的第三個JournalNode，例如JobTracker。
f. 點擊繼續(xù)。
g. 在JournalNode的編輯目錄屬性中，將JournalNode編輯目錄的目錄位置輸入到每個JournalNode主機的字段中。
* 每個JournalNode只能輸入一個目錄。每個JournalNode上的路徑不需要相同。
* 您指定的目錄應該是空的。
* 目錄所有者應該是hdfs:hadoop，并且必須具有讀取，寫入和執(zhí)行權限（drwx ------）。
h. 額外選項：決定Cloudera Manager是否應清除ZooKeeper，備用NameNode和JournalNodes中的現有數據。如果目錄不為空（例如，您重新啟用先前的HA配置），則Cloudera Manager不會自動刪除內容 - 您可以通過保持默認復選框選擇來選擇刪除內容。建議的默認值是清除目錄。如果您選擇不這樣做，數據應該在JournalNodes的編輯目錄中同步，并且應該具有與NameNodes相同的版本數據。
i. 點擊繼續(xù)。
Cloudera Manager執(zhí)行一組命令來停止相關服務，根據需要刪除，創(chuàng)建和配置角色和目錄，創(chuàng)建名稱服務和故障轉移控制器，重新啟動相關服務以及部署新的客戶端配置。
重要 ：如果操作已完成，某些步驟（如格式化NameNode）可能會報告失敗。但是，配置步驟可以繼續(xù)執(zhí)行。
- 如果要配置群集中的其他服務使用HA，請按照配置其他CDH組件使用HDFS HA。
重要提示：如果更改NameNode服務RPC端口（dfs.namenode.servicerpc-address），同時啟用自動故障轉移，這會導致保存在ZooKeeper中的NameNode地址不匹配/hadoop-ha znode和故障切換控制器配置的NameNode地址。這將阻止故障切換控制器重新啟動。如果您需要在啟用自動故障切換后更改NameNode Service RPC端口，則必須執(zhí)行以下操作重新初始化znode：
停止HDFS服務。
配置服務RPC端口：
a. 轉到HDFS服務。
b. 單擊Configuration 選項卡。
c. 選擇Scope > NameNode。
d. 選擇 Category > Ports and Addresses.。
e. 找到NameNode Service RPC端口屬性或通過在搜索框中輸入名稱來搜索它。
f. 根據需要更改端口值。
要根據需要將此配置屬性應用于其他角色組，請編輯相應角色組的值。請參閱使用Cloudera Manager修改配置屬性。在ZooKeeper服務器主機上運行zookeeper-client.。
a. 執(zhí)行以下操作刪除配置的名稱服務。這個例子假設nameservice的名字是nameservice1。您可以在HDFS Instances 選項卡上的 Federation and High Availability 標識名稱服務：rmr /hadoop-ha/nameservice1單擊Instances 選項卡。
選擇 Actions > Initialize High Availability State in ZooKeeper.
啟動HDFS服務。
隔離方法Fencing Methods
為確保一次只有一個NameNode處于活動狀態(tài)，共享編輯目錄需要使用fencing methods 。在故障轉移期間，fencing methods負責確保先前活動的NameNode不再有權訪問共享編輯目錄，以便新的活動NameNode可以安全地繼續(xù)寫入。
默認情況下，Cloudera Manager將HDFS配置為使用 fencing method (shell(true))）。
fencing 參數位于 HDFS服務配置屬性下的 Service-Wide > High Availability 類別中。
有關CDH 5提供的fencing方法以及如何配置fencing的詳細信息，請參閱fencing配置。
使用命令行啟用HDFS HA
重要：
- 在不使用Cloudera Manager配置時，遵循這些命令行指示信息。
- 此信息特別適用于CDH 5.14.x。有關其他版本的信息，請參閱Cloudera文檔。
本節(jié)介紹CDH 5中HDFS HA所需的軟件配置，并介紹如何設置配置屬性并使用命令行來部署HDFS HA。
為HDFS HA配置文件
配置概述
HA配置向后兼容，并允許現有的單一NameNode配置在無需更改情況下即可工作。新配置的設計使群集中的所有節(jié)點都可以具有相同的配置，而無需根據節(jié)點的類型將不同的配置文件部署到不同的機器。
HA群集重用Nameservice ID來標識由多個HA NameNode組成的單個HDFS實例。另外，還有一個名為NameNode ID的新抽象。群集中每個不同的NameNode都有一個不同的NameNode ID。配置文件的參數需要包括Nameservice ID和NameNode ID以支持所有NameNode使用同一個配置文件。
對現有配置參數的更改
對于YARN實現，以下配置參數已更改：
fs.defaultFS - 以前為 fs.default.name ，這是Hadoop FS客戶端在未給出任何前綴時使用的默認路徑前綴。（fs.default.name 參數已經被YARN棄用，但仍然有效。）
或者，您可以將Hadoop客戶端的默認路徑配置為使用啟用HA的邏輯URI。例如，如果你使用myCluster 作為Nameservice ID，如下所示，這將是所有HDFS路徑的權威部分的值。你可以在你的core-site.xml配置文件中設置默認路徑：
- 對于YARN：
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
- 對于MRv1：
<property>
<name>fs.default.name</name>
<value>hdfs://mycluster</value>
</property>
新的配置參數
要配置HA NameNodes，您必須在hdfs-site.xml中添加多個配置選項。
您設置這些配置的順序不重要，但是dfs.nameservices and dfs.ha.namenodes.[Nameservice ID]的值非常關鍵。這意味著您應該在設置其余配置選項之前決定這些值。
配置dfs.nameservices
dfs.nameservices - 這個名字服務的邏輯名稱
例如，為此名稱服務選擇一個邏輯名稱 myCluster，并使用此邏輯名稱作為此配置選項的值。你選擇的名字是任意的。它將用于配置，也將作為群集中HDFS的絕對路徑。
配置dfs.ha.namenodes.[nameservice ID]
dfs.ha.namenodes.[nameservice ID] - 名稱服務中每個NameNode的唯一標識符
配置逗號分隔的NameNode ID列表。這將由DataNode用于確定群集中的所有NameNode。例如，如果你使用myCluster 作為NameService ID，并且您想使用NN1 和 NN2 作為NameNodes的個體ID，您可以按如下方式進行配置：
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
注意：在此版本中，您可以為每個名稱服務配置最多兩個NameNode。
配置dfs.namenode.rpc-address.[nameservice ID]
dfs.namenode.rpc-address.[nameservice ID].[name node ID]- 每個NameNode偵聽的完全限定的RPC地址
對于前面配置的兩個NameNode ID，請設置NameNode進程的完整地址和RPC端口。請注意，這會導致兩個單獨的配置選項。例如：
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>machine1.example.com:8020</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>machine2.example.com:8020</value>
</property>
注意：如有必要，您可以類似地配置 servicerpc-address。
配置dfs.namenode.http-address.[nameservice ID]
dfs.namenode.http-address.[nameservice ID].[name node ID] - 每個NameNode監(jiān)聽的全限定HTTP地址
與上面的rpc-address類似，為兩個NameNode的HTTP服務器設置偵聽地址。例如：
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>machine1.example.com:50070</value>
</property>
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>machine2.example.com:50070</value>
</property>
注意：如果您啟用了Hadoop Kerberos安全功能，并且您打算使用HSFTP，則還應該設置 https-address 。
配置dfs.namenode.shared.edits.dir
dfs.namenode.shared.edits.dir - 共享存儲目錄的位置
配置供JournalNodes使用的共享編輯存儲地址，由Active NameNode寫入并由Standby NameNode讀取，以保持兩個 NameNode所做的所有文件系統更改一致。盡管您必須指定多個JournalNode地址，但您應該只配置其中一個URI。該URI應該采用以下格式：
qjournal://<host1:port1>;<host2:port2>;<host3:port3>/<journalId>
日志ID是此名稱服務的唯一標識符，它允許一組JournalNodes為多個聯邦名稱系統提供存儲。盡管這不是要求，但重用名稱服務標識是個好主意。
例如，如果該群集的JournalNodes在機器 node1.example.com, node2.example.com, 和 node3.example.com 上運行，并且nameservice ID是 myCluster，您可以使用以下值作為此設置的值（JournalNode的默認端口為8485）：
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>
配置dfs.journalnode.edits.dir
dfs.journalnode.edits.dir - JournalNode守護進程將存儲其本地狀態(tài)的路徑
在每個JournalNode機器上，配置JournalNodes使用的用于編輯和存儲其他本地狀態(tài)信息的絕對路徑; 每個JournalNode只使用一個路徑。（其他JournalNodes提供冗余;您也可以在本地連接的RAID-1或RAID-10陣列上配置此目錄。）
例如：
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/data/1/dfs/jn</value>
</property>
創(chuàng)建目錄（如果它不存在）并確保它的所有者是hdfs
$ sudo mkdir -p /data/1/dfs/jn
$ sudo chown -R hdfs:hdfs /data/1/dfs/jn
客戶端故障轉移配置
dfs.client.failover.proxy.provider.[nameservice ID] - HDFS客戶端用于聯系Active NameNode的Java類
配置DFS客戶端將用于確定哪個NameNode是當前活動的Java類的名稱，以及哪個NameNode當前正在為客戶端請求提供服務。目前Hadoop附帶的唯一實現是 ConfiguredFailoverProxyProvider，所以使用這個，除非你使用自定義的。例如：
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
fencing 配置
dfs.ha.fencing.methods - 一個腳本或Java類的列表，它們將用于在故障轉移期間對活動NameNode進行籬笆劃分
系統理想是，在任何給定的時間只有一個NameNode處于活動狀態(tài)。
當您使用Quorum-based的存儲時，只有一個NameNode將被允許寫入JournalNodes，因此在“裂腦”場景中不會破壞文件系統元數據。為dfs.ha.fencing.methods 屬性配置的默認值 shell(true) ，它并沒有明確地嘗試隔離備用NameNode。
在沒有明確屏蔽的情況下，有一個狹窄的時間窗口，以前活動的NameNode可能會提供對來自客戶端的讀取的過時響應。當以前活動的NameNode試圖寫入JournalNodes時，此窗口結束，此時NameNode關閉。
由于沒有裂腦的危險，這種時間窗口很少成為應用程序的問題。在需要強讀取一致性的罕見或特殊情況下，請使用明確的屏蔽方法，如agent-based fencer。
注意：如果您選擇使用agent-based fencer ，則仍應配置shell(true) ，因為如果agent-based fencer失敗時其他NameNode沒有響應。
故障切換期間使用的防護方法將配置為以回車分隔的列表，并且會按順序嘗試這些方法，直到其中一個表明防護已成功為止。
有關實現自己的自定義fencing 的信息，請參閱 org.apache.hadoop.ha.NodeFencer class.。
配置外殼防護方法
shell - 運行任意的shell命令來隔離活動的NameNode
shell fencing方法運行一個任意的shell命令，你可以像下面這樣配置它：
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
</property>
'（'和'）'之間的字符串直接傳遞給bash shell ，不能包括任何結束括號。
執(zhí)行時，配置腳本的第一個參數將是要被隔離的NameNode的地址，后面是在配置中指定的所有參數。
shell命令將在啟動時包含hadoop環(huán)境中所有的配置遍歷，將配置項中的_替換為. 。例如， dfs_namenode_rpc-address 將包含目標節(jié)點的RPC地址，即使配置可能將該變量指定為 dfs.namenode.rpc-address.ns1.nn1。
| 變量 | 描述 |
|---|---|
| $ target_host | 要隔離的節(jié)點的主機名 |
| $ target_port | 圍繞節(jié)點的IPC端口 |
| $ TARGET_ADDRESS | 以上兩個變量組合為port |
| $ target_nameserviceid | 要被隔離的NameNode的名稱服務ID |
| $ target_namenodeid | 要被隔離的NameNode的NameNode ID |
要fencing的目標節(jié)點的以下變量也可用：
| 變量 | 描述 |
|---|---|
| $ target_host | 要隔離的節(jié)點的主機名 |
| $ target_port | 圍繞節(jié)點的IPC端口 |
| $ TARGET_ADDRESS | 以上兩個變量組合為port |
| $ target_nameserviceid | 要被隔離的NameNode的名稱服務ID |
| $ target_namenodeid | 要被隔離的NameNode的NameNode ID |
您也可以使用這些環(huán)境變量作為shell命令本身的替代。例如：
<property>
<name>dfs.ha.fencing.methods</name>
<value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
</property>
如果shell命令返回0的退出碼，則確定防護成功。如果它返回任何其他退出代碼，則防護未成功，并嘗試列表中的下一個防護方法。
注意：此防護方法不會實現任何超時。如果超時是必要的，它們應該在shell腳本中實現（例如，通過分支子shell在幾秒鐘內殺死它的父代）。
自動故障轉移配置
以上各節(jié)介紹如何配置手動故障轉移。在該模式下，即使主動節(jié)點發(fā)生故障，系統也不會自動觸發(fā)從活動節(jié)點到備用節(jié)點的故障轉移。本節(jié)介紹如何配置和部署自動故障轉移。有關如何實現自動故障轉移的概述，請參閱自動故障轉移。
部署ZooKeeper
在典型的部署中，ZooKeeper守護進程被配置為在三個或五個節(jié)點上運行。由于ZooKeeper本身具有輕量資源需求，因此可以在與HDFS NameNode和Standby節(jié)點上配置ZooKeeper節(jié)點。使用MapReduce v2（MRv2）的操作員經常選擇在與YARN ResourceManager相同的節(jié)點上部署第三個ZooKeeper進程。建議將ZooKeeper節(jié)點的數據存儲與HDFS元數據的存儲分開，以獲得最佳性能和隔離。
有關如何設置ZooKeeper集成的說明，請參閱ZooKeeper文檔。在下面的章節(jié)中，我們假設您已經建立了一個在三個或更多節(jié)點上運行的ZooKeeper集群，并通過使用ZooKeeper命令行界面（CLI）進行連接來驗證其正確的操作。
配置自動故障轉移
注意：在開始配置自動故障轉移之前，您必須關閉群集。當集群正在運行時，不支持從手動故障轉移設置轉換為自動故障轉移設置。
配置自動故障轉移需要兩個額外的配置參數。在hdfs-site.xml 文件，添加：
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
這指定應將群集設置為自動故障轉移。
在core-site.xml文件，添加：
<property>
<name>ha.zookeeper.quorum</name>
<value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
</property>
這列出了運行ZooKeeper服務的主機端口對。
與本文檔前面介紹的參數一樣，這些設置可以通過在名稱服務的基礎上配置 nameservice ID后綴來配置。例如，在啟用了聯合的群集中，您可以通過設置僅顯式啟用其中一個名稱服務的自動故障轉移dfs.ha.automatic-failover.enabled.my-nameservice-id 。
還有其他幾個配置參數可以用來控制自動故障轉移的行為，但它們在大多數安裝中不是必需的。有關詳細信息，請參閱Hadoop文檔的配置部分。
初始化ZooKeeper中的HA狀態(tài)
添加配置密鑰后，下一步是在ZooKeeper中初始化所需的狀態(tài)。您可以通過從其中一個NameNode主機運行以下命令來完成此操作。
注意：使用此命令時，ZooKeeper集合必須正在運行; 否則將無法正常工作。
$ hdfs zkfc -formatZK
這將創(chuàng)建一個znode, 其上存儲有自動故障轉移系統所需數據。
安全訪問ZooKeeper
如果您運行的是安全群集，則可能需要確保存儲在ZooKeeper中的信息也是安全的。這可以防止惡意客戶修改ZooKeeper中的元數據或者觸發(fā)錯誤的故障轉移。
為了保護ZooKeeper中的信息，請首先將以下內容添加到core-site.xml文件：
<property>
<name>ha.zookeeper.auth</name>
<value>@/path/to/zk-auth.txt</value>
</property>
<property>
<name>ha.zookeeper.acl</name>
<value>@/path/to/zk-acl.txt</value>
</property>
請注意這些值中的'@'字符 - 它指定配置不是內聯的，而是指向磁盤上的文件。
第一個配置的文件指定ZooKeeper認證列表，ZooKeeper CLI使用相同的配置格式。例如，你可以指定類似 digest:hdfs-zkfcs:mypassword 的形式 ， 其中hdfs-zkcs是ZooKeeper的唯一用戶名， mypassword是密碼 。
接下來，使用如下命令生成與此驗證對應的ZooKeeper訪問控制列表（ACL）：
$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=
將' - >'字符串后面的輸出部分復制并粘貼到文件 zk-acls.txt 中，以字符串“digest：”為前綴。例如：
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda
要使這些ACL生效，請重新運行 zkfc -formatZK 命令，如上所述。
這樣做后，您可以按如下方式驗證ZooKeeper CLI的ACL：
[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa
自動故障轉移FAQ
- 是否需要以特定順序啟動ZKFC和NameNode守護進程？
不需要。在任何給定的節(jié)點上，您可以在其相應的NameNode之前或之后啟動ZKFC。
- 我應該進行哪些額外的監(jiān)測？
您應該在運行NameNode的每臺主機上添加監(jiān)控，以確保ZKFC保持運行。例如，在某些ZooKeeper故障中，ZKFC可能會意外退出，應該重新啟動以確保系統已準備好進行自動故障轉移。此外，您應該在ZooKeeper quorum 中監(jiān)視每個服務器。如果ZooKeeper崩潰，自動故障轉移將不起作用。
- 如果ZooKeeper出現故障會發(fā)生什么？
如果ZooKeeper群集崩潰，則不會觸發(fā)自動故障轉移。但是，HDFS將繼續(xù)運行，沒有任何影響。當ZooKeeper重新啟動時，HDFS將會重新連接。 - 我可以將我的NameNode中的一個指定為主/首選嗎？
目前，這不支持。首先啟動的NameNode將變?yōu)榛顒訝顟B(tài)。您可以選擇以特定順序啟動群集，以便首選節(jié)點首先啟動。 - 如何在配置自動故障轉移時啟動手動故障轉移？
即使配置了自動故障轉移，您也可以啟動手動故障轉移。它將執(zhí)行相應的故障轉移。
部署HDFS高可用性
在設置完所有必要的配置選項后，即可啟動JournalNodes和兩個HA NameNode。
重要提示： 在開始之前：請確保您已執(zhí)行中所述的所有配置和設置任務 配置硬件的HDFS HA和配置軟件HDFS HA，包括初始化的ZooKeeper HA狀態(tài)，如果部署了自動故障轉移。
安裝并啟動JournalNodes
-
將JournalNode守護程序安裝在它們將運行的每臺機器上。
要在Red Hat兼容系統上安裝JournalNode：
$ sudo yum install hadoop-hdfs-journalnode
在Ubuntu和Debian系統上安裝JournalNode：
$ sudo apt-get install hadoop-hdfs-journalnode
在SLES系統上安裝JournalNode：
$ sudo zypper install hadoop-hdfs-journalnode
- 在他們將要運行的每臺機器上啟動JournalNode守護進程：
sudo service hadoop-hdfs-journalnode start
在格式化主NameNode（在新集群中）之前和啟動NameNodes（在所有情況下）之前，請確保守護進程啟動。
格式化NameNode（如果是新集群）
如果您正在設置新的HDFS群集，請格式化您將用作主NameNode的NameNode; 請參閱格式化NameNode。
重要提示：確保JournalNodes已啟動。如果您已將NameNode配置為與JournalNodes進行通信，但尚未啟動JournalNodes，則格式化將失敗。
初始化共享編輯目錄（如果轉換現有的非HA集群）
如果要將非HA NameNode轉換為HA，需要使用本地NameNode中的edits目錄的數據初始化共享編輯目錄：
hdfs namenode -initializeSharedEdits
啟動NameNodes
- 啟動主（已格式化）的NameNode：
$ sudo service hadoop-hdfs-namenode start
- 啟動備用NameNode：
$ sudo -u hdfs hdfs namenode -bootstrapStandby
$ sudo service hadoop-hdfs-namenode start
注意：如果啟用了Kerberos，請不要使用命令sudo -u <user> <command>; 他們會因安全錯誤而失敗。使用以下命令：$ kinit <user>（如果您使用密碼）或 $ kinit -kt <keytab> <principal>（如果你使用的是 keytab
），然后，對于該用戶執(zhí)行的每個命令 $ <command>.
啟動備用NameNode 帶-bootstrapStandby選項會將主NameNode的元數據目錄（包括名稱空間信息和最新的檢查點）的內容復制到備用NameNode。（保存NameNode元數據的目錄位置使用配置選項 dfs.namenode.name.dir 和 dfs.namenode.edits.dir）進行配置。
您可以通過每個NameNode配置的HTTP地址來訪問其網頁。請注意，在配置的地址旁邊是NameNode的HA狀態(tài)（“Standby”或“Active”）。每當HA NameNode啟動并且未啟用自動故障轉移時，它最初處于Standby狀態(tài)。如果啟用自動故障轉移，則啟動的第一個NameNode將變?yōu)榛顒訝顟B(tài)。
重新啟動服務（如果轉換現有的非HA集群）
如果要從非HA轉換為HA配置，則需要重新啟動JobTracker和TaskTracker（對于MRv1，如果使用的話）或者ResourceManager，NodeManager和JobHistory Server（對于YARN）以及DataNode：
在每個DataNode上：
$ sudo service hadoop-hdfs-datanode start
在每個TaskTracker系統（MRv1）上：
$ sudo service hadoop-0.20-mapreduce-tasktracker start
在JobTracker系統（MRv1）上：
$ sudo service hadoop-0.20-mapreduce-jobtracker start
驗證JobTracker和TaskTracker是否正確啟動：
sudo jps | grep Tracker
在ResourceManager系統（YARN）上：
$ sudo service hadoop-yarn-resourcemanager start
在每個NodeManager系統上（YARN;通常與運行DataNode服務的系統相同）：
$ sudo service hadoop-yarn-nodemanager start
在MapReduce JobHistory服務器系統（YARN）上：
$ sudo service hadoop-mapreduce-historyserver start
部署自動故障轉移（如果已配置）
如果您使用ZooKeeper FailoverController（ZKFC）配置自動故障切換，則必須在每臺NameNode上安裝并啟動 zkfc 守護進程。命令如下。
在紅帽兼容系統上安裝ZKFC：
$ sudo yum install hadoop-hdfs-zkfc
在Ubuntu和Debian系統上安裝ZKFC：
$ sudo apt-get install hadoop-hdfs-zkfc
在SLES系統上安裝ZKFC：
$ sudo zypper install hadoop-hdfs-zkfc
啟動 zkfc ：
$ sudo service hadoop-hdfs-zkfc start
以特定順序啟動ZKFC和NameNode后臺進程并不重要。在任何給定的節(jié)點上，您可以在相應的NameNode之前或之后啟動ZKFC。
您應該在運行NameNode的每臺主機上添加監(jiān)控，以確保ZKFC保持運行。例如，在某些類型的ZooKeeper故障中，ZKFC可能會意外退出，應該重新啟動以確保系統準備好進行自動故障轉移。
此外，您應該在每個服務器監(jiān)控ZooKeeper quorum 。如果ZooKeeper崩潰，則自動故障轉移將不起作用。如果ZooKeeper群集崩潰，則不會觸發(fā)自動故障轉移。但是，HDFS將繼續(xù)運行，沒有任何影響。當ZooKeeper重新啟動時，HDFS將會重新連接。
驗證自動故障轉移
在啟用了自動故障轉移的群集的初始部署之后，您應該測試其操作。為此，首先找到活動的NameNode。如上所述，您可以通過訪問NameNode Web界面來確定哪個節(jié)點處于活動狀態(tài)。
一旦找到活動的NameNode，就可以在該節(jié)點上引發(fā)故障。例如，你可以使用 kill -9 <pid of NN> 模擬JVM崩潰。或者，您可以重新啟動機器或其網絡接口以模擬不同類型的停機。觸發(fā)中斷后，另一個NameNode應在幾秒鐘內自動激活。檢測故障并觸發(fā)故障轉移所需的時間取決于配置ha.zookeeper.session-timeout.ms，默認為5秒。
如果測試不成功，則可能是配置錯誤。檢查zkfc 日志 以及NameNode守護進程來進一步診斷問題。
