HDFS High Availability Using the Quorum Journal Manager HDFS High Availability Using the Quorum Journal Manager. 1 4.1 目的... 1 4.2 Note: Using the Quo ...
HDFS High Availability Using the Quorum Journal Manager
HDFS High Availability Using the Quorum Journal Manager
4.2 Note: Using the Quorum Journal Manager or Conventional Shared Storage
4.9 啟動HA的HDFS Upgrade/Finalization/Rollback
4.1 目的
這個手冊的目的是對HDFS HA的概述，和如何配置和管理HA HDFS集群，使用Quorum Journal Manager(QJM)特性。
4.2 Note: Using the Quorum Journal Manager or Conventional Shared Storage
這裡討論如何配置和使用 QJM配置HDFS HA。使用QJM在standby和activenamenode共用edit log。HDFS HA可以使用NFS。可以查看this alternative guide.
4.3 background
之前的hadoop 2.0.0,namende在HDFS集群是單點錯誤(SPOF)，如果機器或者進程不可用，整個cluster就變的不可用。
· 機器crash，整個namenode都不可用，整個集群就不可用。
· 計劃的維護，在namenode設備上，軟體和硬體的更新。
HDFS高可用功能可以解決以上問題。這個功能允許namenode 的機器crash的時候快速的進行切換，或者由管理員發起的切換。
4.4結構體系
在典型的HA集群，2個或者多個機器被配置為了namenode。時間點內，只有一個active狀態的namenode，其他都是standby的。Active namenode為所有client服務。Standby在需要的時候只用來做failover。
為了讓standby node保持與active node同步狀態，node使用獨立的守護進程JournalNodes來交流。當任何namespace修改都是在active node上。然後會修改到多數的JNs。Standby node可以從JNs中讀取editlog，並且不斷查看editlog的修改。Standby node會查看edit，然後應用到自己的namespace。如果failoverstandby會保證已經讀取了所有的editlog。保證namespace在failover之前被完全同步。
為了提供最快的failover，standby node必須有集群block中最新的信息。為了達到，namenode被配置為location在所有的namenode，並且block location信息和心跳會發送到所有的namenode。
Namenode一個時間內只能有一個active，為了避免出現腦裂JouralNodes只允許一個namenode寫入。在failover時，namenode會變成active也會替換寫入JournalNodes的角色，這樣可以防止其他namenode變成active，讓新的active進行安全的切換。
4.5 硬體資源
為了部署HA集群，你需要準備一下：
· Namenode設備，active和standby namenode需要有一樣的設備
· JournalNode設備，JournalNode是比較輕量的，可以和其他hadoop進程一起存在。Node:至少要有3個JournalNode進程，因為edit log修改會要求寫入多數JNs。允許系統去相容單點故障。一般都適用3個進程，也可以增加，從而增加容錯。
在HA集群中，standby的namenode也會執行checkpoint，因此不需要secondary node，backup node，checkpoint node。
4.6 部署
4.6.1 配置概述
配置類似於namenode聯合，HA的允許配置已經存在的單個namenode繼續工作不需要修改。新的配置被設計成，所有cluster的node都有一樣的配置，不需要為不通的設備配置不通的配置文件。
和HDFS聯合一樣，HA集群使用nameserivce ID來識別一個HDFS實例，也可能是一個多個Namenode 的HA。另外一個新的抽象Namenode ID在HA中被使用。每個不通的Namenode有一個不通的namenode id來分別。為了支持一個配置文件到處使用，有些配置使用nameservice id或者namenode id尾碼。
4.6.2 詳細配置
為了配置namenode HA，你必須增加一些選項在hdfs-site.xml裡面
這些配置的順序是不重要的，但是dfs.nameservices和dfs.ha.namenodes.[nameservice ID]的值是比較重要的。因此你需要知道這些值，才能配置後面的參數：
· Dfs.nameservices 新的nameservice的邏輯名
為nameservice選擇一個邏輯名，比如mycluster，並且使用這個邏輯名，完成後面的配置。這個名字是任意的。會用來配置和HDFS絕對路徑的組件。
註意，如果你也使用HDFS聯合，那這個配置要包含其他的namespace，HA等，使用逗號分隔。
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
·
dfs.ha.namenodes.[nameservice ID] 用來唯一標識nameservice中的namenode
使用逗號來分割，可以讓datanode確定所有的集群中的namenode，比如你使用mycluster作為nameservice ID，使用nn1,nn2,nn3標識namenode。
<property>
<name>dfs.ha.namenodes.mycluster</name> <value>nn1,nn2,
nn3</value></property>
註意：namenode的最小數量是2，但是可以配置的更多，但是不建議超過5個，推薦3個，因為有交互的壓力。
·
dfs.namenode.rpc-address.[nameservice ID].[name node ID] 設置每個namenode監聽的埠。
通過之前配置的namenode id來配置namenode監聽的埠。
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>machine1.example.com:9820</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>machine2.example.com:9820</value>
</property>
<property>
<name>dfs.namenode.rpc-address.mycluster.nn3</name>
<value>machine3.example.com:9820</value>
</property>
Servicerpc-address也可以差不多一樣來配置。
·
dfs.namenode.http-address.[nameservice ID].[name node ID] 配置namenode 的http監聽
如果啟動了hadoop的安全選項，還需要為每個namenode配置https-address
·
dfs.namenode.shared.edits.dir 設置namenode可以讀寫編輯的JNs
配置了提供shared edit storage的journalnode，由active namenode寫入，standby namenode讀取更新standby node。儘管你必須制定多個JournalNode地址，但是只需要配置一個。URI的格式如下：qjournal://*host1:port1*;*host2:port2*;*host3:port3*/*journalId*。Journal ID是nameserivce的唯一標識，允許一個journalnode來自於多個聯合的namesystem。儘管不是需要的，但是使用nameservice id作為journal標識是很好的選擇。
比如journalnodes運行在“node1.example.com”, “node2.example.com”, 和“node3.example.com”，nameservice id是mycluster，可以用這些來配置了（預設埠是8485）
·
dfs.ha.fencing.methods 在failover時，用這個腳本或者java
classes來隔離活動的namenode。
這在一個時間內只有一個active namenode是可取的。當使用Quorum Journal Manager，只有一個namenode允許被寫入到journalnode，那麼就有可能因為腦裂出現元數據損壞。然而當failover發生，之前的active namenode還是會服務客戶端的讀請求，當嘗試寫入journalnode的時候namenode被關閉，從而過期。對於這個原因，還是可以在使用Quorum Journal Manager的時候使用一些隔離的方法。
sshfence SSH來kill活動的進程
sshfence選項SSH到目標伺服器使用fuser kill監聽埠的服務。為了讓這個隔離工作需要設置無驗證ssh到目標伺服器上。因此還需要配置dfs.ha.fencing.ssh.private-key-files，使用逗號分隔：
其他選項，因為連接可能會超時，或者指定其他用戶和埠來連接。超時單位是毫秒
shell 運行任意的shell命令來隔離活動的namenode
shell隔離方法是指定一個shell命令：
括弧裡面的值會直接被傳到bash中。
·
fs.defaultFS當沒有指定的時候，客戶端連接的預設的hadoop
fs
配置啟動ha之後的uri。如果使用mycluster作為nameservice id，那麼可以作為HDFS路徑的一部分比如：
·
dfs.journalnode.edits.dir journalnode進程用來保存本地狀態的路徑
journalnode設備的絕對路徑用來保存edit和其他JNs使用的local狀態。這個配置可能只使用一個路徑。通過配置多個journalnode來冗餘
4.6.3 部署細節
一些必要的配置都配置了之後，啟動journalnode進程。使用命令hdfs --daemon start journalnode啟動journalnode。
一旦journalnode被啟動之後需要做個初始化操作，磁碟上同步元數據。
· 如果你設置了HDFS集群，就需要在其中一個namenode上啟動命令
· 如果已經有了初始化有的namenode，或者已經有一個沒有啟動HA的集群要設置為啟動HA，那麼就要複製namenode的元數據目錄到其他的node中。運行hdfs namenode –bootstrapStandby在非格式化的namenode中。使用這個命令也保證了joournalnode有足夠的日誌來啟動2個namenode。
· 如果你轉化非HA的namenode到HA的。需要運行hdfs namenode –initializeSharedEdits，從namenode edit目錄初始化journalnode。
這個時候所有的namenode就和一個namenode一樣。
你可以訪問每個namenode 的網站。然後註意HA狀態是standby還是active，當每個namenode啟動時，一開始的狀態都是standby狀態。
4.6.4 管理命令
現在HA namenode已經配置好了並且已經啟動了，那麼就會有一些額外的管理命令，
Usage: haadmin
[-transitionToActive <serviceId>]
[-transitionToStandby <serviceId>]
[-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
[-getServiceState <serviceId>]
[-getAllServiceState]
[-checkHealth <serviceId>]
[-help <command>]
子命令的幫助可以查看hdfs haadmin -help <command>
·
transitionToActive和transitionToStandby
轉化standby和active的狀態。
這2個子命令會導致namenode的狀態轉化。這個命令不會有隔離，因此儘量不要用。應該使用hdfs haadmin –failover命令
·
failover 在2個namenode之間做切換
這個子命令會導致namenode之間的failover。如果第一個namenode是standby狀態，這個命令只是把第二個node設置為active。如果第一個namenode是active的，就會被轉化為standby。如果出現錯誤那麼隔離方法（dfs.ha.fencing.methods）就會嘗試直到成功。這個過程完了之後第二個node會變成active狀態。如果隔離方法沒有成功，第二個namenode不會被轉化為active狀態，會錯誤退出。
·
getServiceState 確定namenode是active還是standby
連接到namenode並確定當前的狀態，standby或者active會輸出。
·
getAllServiceState 返回所有namenode的狀態
連接到配置好的namenode來決定當前的狀態，輸出standy或者active
·
checkHealth 檢查指定namenode的健康
連接到namenode來檢查健康。Namenode有能力自己診斷，包括檢查服務是否預期運行。如果返回0表示健康，否則非0。這個功能還沒實現。
4.7 自動切換
4.7.1 說明
上面描述配置手動故障轉移。如果namenode報錯也不會自動轉移。
4.7.2 組件
自動故障轉移增加了2個新的組件，zookeeper quorum和ZKFailoverController進程(ZKFC)。
Apache Zookeeper是高可用的服務維護了少量的協作數據，通知客戶端數據的修改，並且監控客戶端的錯誤。HDFS的自動故障轉移依賴於Zookeeper:
· 錯誤診斷每個nanenode在ZooKeeper中維護了一個長連接。如果機器crash，ZooKeeper會話會過期，通知其他namenode做failover
· Active Namenode選舉，Zookeeper提供簡單的機制選舉一個node作為active。如果當前的active namenode crash。另外一個node會獲取一個在ZooKeeper的排他鎖，表示它會變成下一個active
ZKFailoverController(ZKFC)是一個新的組件，是一個ZooKeeper客戶端可以用來監控和管理namenode 的狀態。每個namenode都運行了ZKFC,ZKFC主要工作：
· Health監控 ZKFC 定期的ping 本地的namenode作為健康檢查。如果namenode定期回覆那麼就認為是健康的，如果node crash，frozen或者其他原因不健康，那麼健康監控會標記為不健康。
· ZooKeeper會話管理當本地namenode 是健康的，ZKFC會在ZooKeeper打開一個會話。如果本地namenode是活動的，會獲取一個指定的lock。這個lock會使用ZooKeeper支持的ephemeral node如果會話過期，lock node會被自動刪除。
· ZooKeeper基於選舉如果namenode是健康的，ZKFC發現沒有lock znode,那麼就會去獲取這個鎖，如果成功，那麼就贏得了選舉，返回failover結果local namenode acitive。Failover過程和手動failover相似：第一，之前的active隔離是必要的，然後local namenode 轉化為 active 。
自動failover，查看HDFS-2185，HDFS JIRA。
4.7.3 部署Zookeeper
在通常部署，Zookeeper配置運行3個或者5個node，Zookeeper自身是輕量的可以放在namenode或者standby node上。很多會部署在和Zookeeper進程會和yarn resourcemanager同一個node上。推薦把Zookeeper node保存在獨立的磁碟上，用於隔離性能問題。
4.7.4 開始配置前
在開始配置自動故障轉移前，需要先關閉集群。當在集群運行的情況下，把手動轉移轉化為自動轉移是不可能的。
4.7.5 配置自動故障轉移
為了自動故障轉移，配置2個參數，hdfs-site.xml中：
指定那些需要自動故障轉移的node,core-site.xml中：
運行了Zookeeper服務的host和埠。
這些設置可以配置在每個nameservice上，使用nameservice的首碼。比如cluster啟動了聯合，那麼就可以為某個nameservice配置自動故障轉移，配置dfs.ha.automatic-failover.enabled.my-nameservice-id。
這裡還有一些其他配置自動故障，但是對大多數來說是沒必要的。
4.7.6 初始化Zookeeper中的HA狀態
配置好之後，下一步就是初始化Zookeeper的狀態。可以用一下命令在一個namenode上運行：
然後在Zookeeper中創建znode，裡面保存了自動故障轉移的數據。
4.7.7 啟動start-dfs.sh
因為自動故障轉移已經在配置文件中設置，start-dfs.sh腳本會自動啟動ZKFC進程，啟動之後會自動選擇一個namenode稱為active。
4.7.8 手動啟動cluster
如果是手動管理cluster的，需要手動啟動zkfc進程。
4.7.9 Zookeeper安全訪問
如果運行了安全的cluster，也需要保證保存在Zookeeper也是安全的。這樣可以防止用戶惡意修改元數據，活導致錯誤的faliover。
為了安全的Zookeeper，在core-site.xml添加一下信息：
這裡的@，配置的值不是這個值，而是指向的文件。
第一個文件列出了Zookeeper的驗證，和ZK CLI的格式一樣：
Hdfs-zkfcs是Zookeeper的唯一用戶名，mypassword是密碼。
下一步生成關聯到驗證的Zookeeper ACL，使用命令行如下：
然後把輸出的->之後的字元串複製到zk-acls.txt,並且帶著digest首碼：
為了讓ACL生效，需要運行zkfc –formatZK命令。
然後就可以在ZK CLI驗證ACLS：
4.7.10 驗證自動failover
一旦自動故障轉移已經啟動，那麼就需要測試操作。首先定位在active namenode。可以從namenode 的網站查看namenode 的狀態。
一旦定位到活動的namenode，使用 kill -9 pid來模擬jvm崩潰，或者可以關機，或者拔網線來模擬。一旦觸發，在幾秒內其他的namenode會自動變active。發現錯誤，觸發failover的時間取決於配置，ha.zookeeper.session-timeout.ms，預設是5秒。
如果測試沒有成功，可能有配置錯誤。檢查zkfc進程和namenode進程日誌來發現問題。
4.8 自動故障轉移FAQ
· Is it important that I start the ZKFC and NameNode daemons in any particular order?
No. On any given node you may start the ZKFC before or after its corresponding NameNode.
· What additional monitoring should I put in place?
