linux-hadoop高可用集羣和Zookeeper

1.hadoop高可用集羣
  hadoop高可用集羣的配置環境和hadoop分佈式部署的配置環境一樣。不同的是hadoop的分佈式部署只有一個master,其餘節點都是leader;而hadoop的高可用集羣中通常有兩臺不同的主機充當 NN (NN是指namenode,也就是master),其中一個master正常工作,狀態爲 Active ,另一個master用作備用,狀態爲 Standby ,當 Active NN 發生故障不能工作時它負責接管工作,如果必要,可以提供快速的故障恢復。
  Standby NN想要接管工作就必須和 Active NN 的狀態保持同步(元數據保持一致),它們都將會和JournalNodes守護進程通信。當Active NN 執行任何有關命名空間的修改,它需要持久化到一半以上的 JournalNodes 上(通過edits log 持久化存儲),而 Standby NN 負責觀察 edits log的變化,它能夠讀取從JNs 中讀取 edits 信息,並更新其內部的命名空間。一旦 Active NN出現故障, Atandby NN 將會保證從 JNs 中讀出了全部的 Edits,然後切換成 Active 狀態。Standby NN 讀取全部的 edits 可確保發生故障轉移之前,是和 Active NN 擁有完全同步的命名空間狀態。爲了提供快速的故障恢復,StandbyNN 也需要保存集羣中各個文件塊的存儲位置。爲了實現這個,集羣中所有的 Database 將配置好 Active NN 和 Standby NN 的位置,並向它們發送塊文件所在的位置。
  任何時候,集羣中都只能有一個 NN 處於 Active 狀態。否則,在兩個 Active NN的狀態下 NameSpace 狀態將會出現分歧,這將會導致數據的丟失及其它不正確的結果。爲了保證這種情況不會發生,在任何時間,JNs 只允許一個 NN 充當writer。在故障恢復期間,將要變成 Active 狀態的 NN 將取得 writer 的角色,並阻止另外一個 NN 繼續處於 Active狀態。

2.部署Hadoop高可用集羣
  <1> NameNode machines:運行 Active NN 和 Standby NN 的機器需要相同的硬件配置;
  <2> JournalNode machines:也就是運行 JN 的機器。JN 守護進程相對來說比較輕量,所以這些守護進程可以可其他守護線程(比如 NN,YARN ResourceManager)運行在同一臺機器上。在一個集羣中,最少要運行 3 個 JN 守護進程,這將使得系統有一定的容錯能力。當運行 N 個 JN時,系統將最多容忍(N-1)/2 個 JN 崩潰。
  <3> 在Hadoop高可用集羣中,Standby NN 也執行namespace 狀態的 checkpoints,所以不必要運行Secondary NN、CheckpointNode和BackupNode,事實運行這些守護進程是錯誤的。

(1) Zookeeper集羣至少三臺,總節點數爲奇數個。
[hadoop@server2 ~]$ tar zxf zookeeper-3.4.9.tar.gz      ##解壓安裝zookeeper
[hadoop@server2 ~]$ cp zookeeper-3.4.9/conf/zoo_sample.cfg zoo.cfg
[hadoop@server2 ~]$ vim zookeeper-3.4.9/conf/zoo.cfg
vim:(在最後面寫)
server.1=172.25.0.2:2888:3888
server.2=172.25.0.3:2888:3888
server.3=172.25.0.4:2888:3888
:wq
各節點配置文件相同,並且需要在/tmp/zookeeper 目錄中創建 myid 文件,寫入一個唯一的數字,取值範圍在1-255。

接下來在各節點啓動服務:
[hadoop@server2 ~]$ hadoop/bin/zkServer.sh start
[hadoop@server2 ~]$ hadoop/bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /home/hadoop/zookeeper-3.4.9/bin/../conf/zoo.cfg
Mode: leader        ##本節點是一個leader
bin/zkCli.sh -server 127.0.0.1:2181 ##連接 zookeeper

配置參數詳解:
clientPort  ##客戶端連接server的端口,即對外服務端口,一般設置爲2181
dataDir     ##存儲快照文件snapshot的目錄。默認情況下,事務日誌也會存儲在這裏。建議同時配置參數 dataLogDir, 事務日誌的寫性能直接影響 zk 性能。
tickTime    ##ZK中的一個時間單元。ZK中所有時間都是以這個時間單元爲基礎,以毫秒計,用來調節心跳和超時。
dataLogDir  ##事務日誌輸出目錄。儘量給事務日誌的輸出配置單獨的磁盤或是掛載點,這將極大的提升ZK 性能。
globalOutstandingLimit      ##最大請求堆積數。默認是 1000 ZK運行的時候, 儘管server已經沒有空閒來處理更多的客戶端請求了,但是還是允許客戶端將請求提交到服務器上來,以提高吞吐性能。當然,爲了防止 Server 內存溢出,這個請求堆積數還是需要限制下的。
preAllocSize    ##預先開闢磁盤空間,用於後續寫入事務日誌。默認是 64M,每個事務日誌大小就是 64M。
snapCount   ##每進行snapCount 次事務日誌輸出後,觸發一次快照(snapshot),此時,ZK 會生成一個snapshot.*文件,同時創建一個新的事務日誌文件 log.*。默認是 100000.(真正的代碼實現中,會進行一定的隨機數處理,以避免所有服務器在同一時間進行快照而影響性能)
traceFile   ##用於記錄所有請求的 log,一般調試過程中可以使用,但是生產環境不建議使用,會嚴重影響性能。
maxClientCnxns  ##單個客戶端與單臺服務器之間的連接數的限制,是ip級別的,默認是60,如果設置爲0,那麼表明不作任何限制。請注意這個限制的使用範圍,僅僅是單臺客戶端機器與單臺 ZK服務器之間的連接數限制,不是針對指定客戶端 IP,也不是 ZK集羣的連接數限制,也不是單臺 ZK 對所有客戶端的連接數限制。
clientPortAddress   ##對於多網卡的機器,可以爲每個 IP 指定不同的監聽端口。默認情況是所有 IP 都監聽
clientPort ##指定的端口。 New in 3.3.0
minSessionTimeoutmaxSessionTimeout  ##Session超時時間限制,如果客戶端設置的超時時間不在這個範圍,那麼會被強制設置爲最大或最小時間。
fsync.warningthresholdms    ##事務日誌輸出時,如果調用 fsync 方法超過指定的超時時間,那麼會在日誌中輸出警告信息。默認是 1000ms
autopurge.purgeInterval     ##在上文中已經提到,3.4.0及之後版本,ZK 提供了自動清理事務日誌和快照文件的功能,這個參數指定了清理頻率,單位是小時,需要配置一個 1 或更大的整數,默認是 0,表示不開啓自動清理功能。
autopurge.snapRetainCount   ##這個參數和上面的參數搭配使用,這個參數指定了需要保留的文件數目。默認是保留 3個。
initLimitFollower   ##在啓動過程中,會從 Leader 同步所有最新數據,然後確定自己能夠對外服務的起始狀態。Leader 允許 F 在initLimit 時間內完成這個工作。通常情況下,我們不用太在意這個參數的設置。如果 ZK 集羣的數據量確實很大了,F 在啓動的時候,從 Leader 上同步數據的時間也會相應變長,因此在這種情況下,有必要適當調大這個參數了。
syncLimit   ##在運行過程中,Leader 負責與 ZK 集羣中所有機器進行通信,例如通過一些心跳檢測機制,來檢測機器的存活狀態。如果 L 發出心跳包在 syncLimit 之後,還沒有從 F 那裏收到響應,那麼就認爲這個 F 已經不在線了。注意:不要把這個參數設置得過大,否則可能會掩蓋一些問題。
leaderServes    ##默認情況下,Leader 是會接受客戶端連接,並提供正常的讀寫服務。但是,如果你想讓Leader 專注於集羣中機器的協調,那麼可以將這個參數設置爲 no,這樣一來,會大大提高
寫操作的性能。
server.x=[hostname]:nnnnn[:nnnnn]   ##這裏的 x 是一個數字,與 myid 文件中的 id 是一致的。右邊可以配置兩個端口,第一個端口用於 F 和 L 之間的數據同步和其它通信,第二個端口用於 Leader 選舉過程中投票通信。
group.x=nnnnn[:nnnnn]weight.x=nnnnn ##對機器分組和權重設置,可以 參見這裏(No Java system property)
cnxTimeout  ##Leader 選舉過程中,打開一次連接的超時時間,默認是5s
zookeeper.DigestAuthenticationProvider.superDigest  ##ZK權限設置相關,具體參見《使用super身份對有權限的節點進行操作》和《ZooKeeper 權限控制》
skipACL     ##對所有客戶端請求都不作 ACL 檢查。如果之前節點上設置有權限限制,一旦服務器上打開這個開頭,那麼也將失效。(Java system property:zookeeper.skipACL)
forceSync   ##這個參數確定了是否需要在事務日誌提交的時候調用 FileChannel.force 來保證數據完全同步到磁盤。
jute.maxbuffer  ##每個節點最大數據量,是默認是 1M。這個限制必須在server 和 client 端都進行設置纔會生效。

(2)Hadoop配置
[hadoop@server2 ~]$ vim hadoop/etc/hadoop/core-site.xml     ##編輯core-site.xml文件
vim:
<!-- 指定 hdfs 的 namenode 爲 masters (名稱可自定義)-->
<property>
<name>fs.defaultFS</name>
<value>hdfs://masters</value>
</property>
<!-- 指定 zookeeper 集羣主機地址-->
<property>
<name>ha.zookeeper.quorum</name>
<value>172.25.0.2:2181,172.25.0.3:2181,172.25.0.4:2181</value>
</property>
:wq
[hadoop@server2 ~]$ vim hadoop/etc/hadoop/hdfs-site.xml     ##編輯hdfs-site.xml文件

(3)啓動hdfs集羣(按順序啓動)
1> 在三個DN上依次啓動zookeeper集羣
[hadoop@server2 ~]$ bin/zkServer.sh
start
[hadoop@server2 ~]$ jps
1222 QuorumPeerMain
1594 Jps
2>在三個 DN 上依次啓動 journalnode(第一次啓動 hdfs 必須先啓動 journalnode)
[hadoop@server2 ~]$ sbin/hadoop-daemon.sh start journalnode
[hadoop@server2 ~]$ jps
1493 JournalNode
1222 QuorumPeerMain
1594 Jps
3>格式化 HDFS 集羣
[hadoop@server2 ~]$ bin/hdfs namenode -format
Namenode 數據默認存放在/tmp,需要把數據拷貝到h2
[hadoop@server2 ~]$ scp -r /tmp/hadoop-hadoop 172.25.0.5:/tmp
4>格式化 zookeeper (只需在 h1 上執行即可)
[hadoop@server2 ~]$ bin/hdfs zkfc -formatZK
[hadoop@server2 ~]$ sbin/start-dfs.sh
5>查看各節點狀態
[hadoop@server1 hadoop]$ jps    ##server1和server5是masster
1431 NameNode
1739 DFSZKFailoverController
2013 Jps
[hadoop@server2 ~]$ jps     ##server2,server3和server4是leader
1493 JournalNode
1222 QuorumPeerMain
1400 DataNode
1594 Jps
在瀏覽器上測試
172.25.0.1:50070
6>測試故障自動切換
[hadoop@server1 hadoop]$ jps
1431 NameNode
2056 Jps
1739 DFSZKFailoverController
[hadoop@server1 hadoop]$ kill -9 1431
[hadoop@server1 hadoop]$ jps
1739 DFSZKFailoverController
2089 Jps
[hadoop@server1 hadoop]$ bin/hdfs dfs -lsFound 1 items
drwxr-xr-x
- hadoop supergroup
0 2017-03-04 17:39 input
殺掉server1主機的 namenode進程後依然可以訪問,此時server5 轉爲active狀態接
管namenode。
[hadoop@server1 hadoop]$ sbin/hadoop-daemon.sh start namenode   ##啓動 h1 上的 namenode,此時爲standby狀態。
在瀏覽器上測試:
172.25.0.1:50070    ##server1爲standby狀態
172.25.0.5:50070    ##server5爲active狀態
hadoop的高可用集羣配置完畢

3.yarn的高可用
[hadoop@server1 ~]$ vim hadoop/etc/hadoop/mapred-site.xml   ##編輯mapred-site.xml文件
vim:
<!--
指定 yarn 爲 MapReduce 的框架 --><property>
<name>mapreduce.framework.name</name>
<value>yarn</value>
</property>
:wq
[hadoop@server1 ~]$ vim hadoop/etc/hadoop/yarn-site.xml     ##編輯yarn-site.xml文件
[hadoop@server1 ~]$ hadoop/sbin/start-yarn.sh
hadoop@server1 hadoop]$ jps
6559 Jps
2163 NameNode
1739 DFSZKFailoverController
5127 ResourceManager

server2需要手動啓動
[hadoop@server1 ~]$ hadoop/sbin/yarn-daemon.sh start resourcemanager
最好把 RM 與 NN 分離運行

yarn故障切換測試:
[hadoop@server1 hadoop]$ jps
5918 Jps
2163 NameNode
1739 DFSZKFailoverController
5127 ResourceManager
[hadoop@server1 hadoop]$ kill -9 5127






 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章