1. 程式人生 > >Hadoop框架基礎(五)

Hadoop框架基礎(五)

jar cluster 安裝 ado 站點 put 文檔 編號 集群管理

** Hadoop框架基礎(五)

已經部署了Hadoop的完全分布式集群,我們知道NameNode節點的正常運行對於整個HDFS系統來說非常重要,如果NameNode宕掉了,那麽整個HDFS就要整段垮掉了,所以人類思考,能不能讓世界多一點愛:),我們能不能弄個備用的NameNode,一旦正在使用的NameNode原地爆炸了,另一臺備用的NameNode能立刻代替原先NameNode的位置,繼續讓HDFS系統正常運行?(同理,ResourceManager也是可以的。)

世界果然充滿愛,動物管理員橫空出世——zookeeper框架

技術分享圖片

** ZooKeeper

這個框架的翻譯為動物園管理員,想想其實是有道理的,大數據領域,Hadoop框架是大象,Hive框架是蜜蜂(為啥是個大象頭哎餵?),Pig框架是豬,都是人類的好朋友,所以有個動物管理員也不差異。接下來簡單介紹一下zookeeper框架。

技術分享圖片

** zookeeper功能:

* 統一命名服務(Name Service)

* 配置管理(Configuration Management)

* 集群管理(Group Membership)

* 共享鎖(Locks)/同步鎖

** zookeeper簡述:

apache開源項目,提供分布式集群,屬於Hadoop底下的一個分支,為分布式應用提供協調服務,官方網站:zookeeper.apache.org,zookeeper服務器為奇數個,即2n+1個服務器,允許有n個機器宕機,不影響整個系統的運行。比如:3臺機器,其中有1臺機器宕機,且存活的Server的數目不得少於n+1.,不會影響整個系統運行。 zookeeper集群會選擇出一個leader服務器,其他服務器角色是follower,它使用的FastLeaderELection選舉算法是類fast paoxs的算法(有興趣的可以周邊查閱下),投票數量結果過半的服務器選為leader服務器。

** zookeeper原理簡述

技術分享圖片

當leader崩潰或者leader失去大多數的follower,這時候zookeeper進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的Server都恢復到一個正確的狀態,系統默認的選舉算法為fast paxos。

** zookeeper的Fast Leader選舉機制

首先介紹幾個概念

服務器ID

比如有三臺服務器,編號分別是1,2,3。

編號越大在選擇算法中的權重越大。

數據ID

服務器中存放的最大數據ID.

值越大說明數據越新,在選舉算法中數據越新權重越大。

邏輯時鐘

或者叫投票的輪數,同一輪投票過程中的邏輯時鐘值是相同的。每投完一輪票這個數據就會增加,然後與接收到的其它服務器返回的投票信息中的數值相比,根據不同的值做出不同的判斷。

選舉狀態

LOOKING,競選狀態。

FOLLOWING,隨從狀態,同步leader狀態,參與投票。

OBSERVING,觀察狀態,同步leader狀態,不參與投票。

LEADING,領導者狀態。

選舉消息內容

在投票完成後,需要將投票信息發送給集群中的所有服務器,它包含如下內容。

服務器ID

數據ID

邏輯時鐘(或者理解為選舉輪數,從0開始遞增)

選舉狀態

開始投票:

1、恢復數據

zookeeper服務器中的每份數據,都有一個對應的id值,這個值是依次遞增的,越新的數據,對應的ID值就越大,所以先把數據恢復到最新。

2、廣播投票到其他服務器

恢復數據到最新之後,每個zookeeper服務器發送自己選舉的leader(嶄新狀態首次投票推選自己),這個協議中包含了以下幾部分的數據:

* 當前的服務器的id,即sid

* 當前服務器的最大的數據id,這個值大的服務器,說明存放了更新的數據.

* 當前服務器本次的邏輯時鐘的值

* 當前機器的選舉狀態

3、接收其他服務器的廣播

每個服務器將自己的數據(以上4個)廣播給其他服務器,同時也接收其他服務器廣播過來的數據,之後:

如果所接收數據中服務器的狀態還是在選舉階段(LOOKING 狀態),那麽首先判斷邏輯時鐘值,又分為以下三種情況:

* 如果發送過來的邏輯時鐘大於目前的邏輯時鐘,那麽說明這次選舉更加的新,此時需要更新一下本機的邏輯時鐘值,同時將之前收集到的來自其他服務器的選舉清空,因為這些數據已經過期了。然後判斷是否需要更新當前自己的選舉情況。在這裏是根據選舉sid和保存的最大數據id來進行判斷的,這兩種數據之間對這個選舉結果的影響的權重關系是:首先看數據id,數據id大者勝出;其次再判斷sid,sid大者勝出。然後再將自身最新的選舉結果廣播給其他服務器。

* 如果發送過來數據的邏輯時鐘小於本機的邏輯時鐘,說明對方在一個相對較早的選舉進程中,此時只需要發送自己的選舉數據即可。

* 兩邊的邏輯時鐘相同,此時只需要判斷是否需要更新本機的數據,如果更新了再將自己最新的選舉結果廣播出去就是了。

然後再處理兩種情況:

* 服務器判斷是不是已經收集到了所有服務器的選舉狀態,如果是,那麽這臺服務器選舉的leader就定下來了,然後根據選舉結果設置自己的角色(FOLLOWING還是LEADER),選舉結束。

* 即使沒有收集到所有服務器的選舉狀態,也可以根據該節點上選擇的最新的leader是不是得到了超過半數以上服務器的支持,如果是,那麽當前線程將被阻塞等待一段時間(這個時間在finalizeWait定義)看看是不是還會收到當前leader的數據更優的leader,如果經過一段時間還沒有這個新的leader提出來,那麽這臺服務器最終的leader就確定了,否則進行下一次選舉。

如果所接收服務器不在選舉狀態,也就是在FOLLOWING或者LEADING狀態做以下兩個判斷:

* 如果邏輯時鐘相同,將該數據保存到recvset,如果所接收服務器宣稱自己是leader,那麽將判斷是不是有半數以上的服務器選舉它,如果是則設置選舉狀態,選舉結束。

* 否則這是一條與當前邏輯時鐘不符合的消息,那麽說明在另一個選舉過程中已經有了選舉結果,於是將該選舉結果加入到集合中,再根據集合來判斷是否可以結束選舉,如果可以也是保存邏輯時鐘,設置選舉狀態,選舉結束。

原理引用網絡上的一張圖,如圖所示:

技術分享圖片

在此舉個例子:假設有5臺機器

服務器1啟動,給自己投票,然後發投票信息,由於其它機器還沒有啟動所以它收不到反饋信息,服務器1的狀態一直屬於Looking。

服務器2啟動,給自己投票,同時與之前啟動的服務器1交換結果,由於服務器2的編號大所以服務器2勝出,但此時投票數沒有大於半數,所以兩個服務器的狀態依然是LOOKING。

服務器3啟動,給自己投票,同時與之前啟動的服務器1,2交換信息,由於服務器3的編號最大所以服務器3勝出,此時投票數正好大於半數,所以服務器3成為leader,服務器1,2成為follower。

服務器4啟動,給自己投票,同時與之前啟動的服務器1,2,3交換信息,盡管服務器4的編號大,但之前服務器3已經勝出,所以服務器4只能成為follower。

服務器5啟動,後面的邏輯同服務器4成為follower。

zookeeper安裝:

* 下載地址傳送門:

zookeeper下載:鏈接:http://pan.baidu.com/s/1o78IBsY 密碼:xh3k

* 解壓到modules目錄中

* 修改配置文件(cp -a命令意為保留原文件屬性的情況下,復制文件)

復制conf目錄下的zoo_sample.cfg文件並重命名為zoo.cfg文件

$ cp -a zoo_sample.cfg zoo.cfg,執行後,如圖:

技術分享圖片

對文件做如下修改:

$ vi zoo.cfg

dataDir=/opt/modules/zookeeper-3.4.5/zkData, 如圖:

技術分享圖片

創建這個目錄:

$ mkdir /opt/modules/zookeeper-3.4.5/zkData

* 啟動zookeeper

單節點啟動,切換到zookeeper的安裝根目錄:

$ bin/zkServer.sh start

查看啟動狀態:

$ bin/zkServer.sh status,如圖:

技術分享圖片

** zookeeper集群的部署

集群規劃如下:

技術分享圖片

* 修改zoo.cfg

dataDir=/opt/modules/zookeeper-3.4.5/zkData

server.1=192.168.122.200:2888:3888

server.2=192.168.122.201:2888:3888

server.3=192.168.122.202:2888:3888

註意:這裏我使用的是三臺服務器的ip地址,如圖:

技術分享圖片

* 添加myid文件,註意一定要在linux裏面創建

$ vi zkData/myid

添加內容:1

* 把zookeeper目錄拷貝給其他集群服務器

$ scp -r zookeeper-3.4.5/ z02:/opt/modules/

$ scp -r zookeeper-3.4.5/ z03:/opt/modules/

修改myid文件

z02 為 2

z03 為 3

* 依次啟動所有集群服務

$ bin/zkServer.sh start

* 檢查每個服務器的狀態

$ bin/zkServer.sh status

一頓操作之後,如圖:通過查看狀態,可以發現,現在的leader服務器是z02,其他的服務器為follower。

技術分享圖片

** NameNode的HA部署

目標: 防止單個namenode宕機以後,整個HDFS集群失效

集群規劃:

技術分享圖片

註意:建議配置之前把之前服務器配置備份一次,方便以後使用

$ cp -ra hadoop-2.5.0/ back-up-hadoop-2.5.0/,如圖:

技術分享圖片

* 配置core-site.xml,如圖:

技術分享圖片

* 配置:hdfs-site.xml,如圖:

技術分享圖片

* 拷貝文件給其他服務器

刪除三臺服務器的數據目錄,去每個機器上執行該命令:

$ rm -rf data/

拷貝給其他兩臺服務器:

$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml z02:/opt/modules/hadoop-2.5.0/etc/hadoop/

$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml z03:/opt/modules/hadoop-2.5.0/etc/hadoop/

* 啟動服務

* 在各個JournalNode節點上,輸入以下命令啟動journalnode服務:

$ sbin/hadoop-daemon.sh start journalnode

* 在[nn1]上,對其進行格式化,並啟動

$ bin/hdfs namenode -format

$ sbin/hadoop-daemon.sh start namenode

* 在[nn2]上,同步nn1的元數據信息,並啟動

$ bin/hdfs namenode -bootstrapStandby

$ sbin/hadoop-daemon.sh start namenode

* 在nn1中與nn2中查看jps進程如下圖:

技術分享圖片

* 瀏覽器瀏覽,以下兩個地址均可以訪問HDFS:

http://z01:50070/

http://z02:50070/

* 手動把nn1設置為active

$ bin/hdfs haadmin -transitionToActive nn1

以上為手動故障轉移,如果我們想自動切換故障,需要進行如下配置,即開啟故障自動轉移功能

*關閉所有HDFS服務

在[nn1]執行:

$ sbin/stop-dfs.sh,如圖:

技術分享圖片

配置core-site.xml

添加屬性:

ha.zookeeper.quorum:z01:2181,z02:2181,z03:2181

配置hdfs-site.xml

添加屬性:

dfs.ha.automatic-failover.enabled.mycluster:true

* 拷貝文件給後面兩臺服務器

$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml z02:/opt/modules/hadoop-2.5.0/etc/hadoop/

$ scp etc/hadoop/core-site.xml etc/hadoop/hdfs-site.xml z03:/opt/modules/hadoop-2.5.0/etc/hadoop/

* 啟動Zookeeper服務

$ bin/zkServer.sh start

啟動zookeeper,初始化HA在Zookeeper中狀態

$ bin/hdfs zkfc -formatZK

*啟動HDFS服務

在[nn1]執行:

$ sbin/start-dfs.sh

nn1與nn2的jps如圖所示:

技術分享圖片

* 查看活躍狀態

$ bin/hdfs haadmin -getServiceState nn1

$ bin/hdfs haadmin -getServiceState nn2

如圖:

技術分享圖片

* 測試,訪問如下站點也可以查看NameNode的活躍狀態:

http://z01:50070/

http://z02:50070/

此時kill掉active的NameNode進程,查看standby狀態會自動切換到active

** Yarn的HA部署

目標: 防止單個resourcemanager宕機以後,整個YARN集群失效

集群規劃:

技術分享圖片

* 配置:yarn-site.xml,如圖:

技術分享圖片

* 拷貝給其他服務器並修改

$ scp etc/hadoop/yarn-site.xml z02:/opt/modules/hadoop-2.5.0/etc/hadoop/

$ scp etc/hadoop/yarn-site.xml z03:/opt/modules/hadoop-2.5.0/etc/hadoop/

* 啟動每個服務器的服務

通過jps查看每個服務器的zookeeper服務QuorumPeerMain已經運行,沒有運行則開啟,方式前文已經說過,不再贅述。

在 z02中:

$ sbin/start-yarn.sh

在z03中:

$ sbin/yarn-daemon.sh start resourcemanager

查看服務狀態:

$ bin/yarn rmadmin -getServiceState rm1

$ bin/yarn rmadmin -getServiceState rm2

如圖:

技術分享圖片

測試:

運行我們之前打好的jar包,進行wordcount實例運算,在運算過程中kill掉active的rm,觀察任務運行。

先開啟HDFS服務(忘記的請看上邊的內容),再上傳一個words.txt文檔到HDFS,再開始單詞統計,涉及命令:

$ bin/hdfs dfs -mkdir /input/

$ bin/hdfs dfs -mkdir /input/words/

$ bin/hdfs dfs -put words.txt /input/words/

如圖:

技術分享圖片

$ bin/yarn jar MyWordCount.jar /input/words/words.txt /output/

** 總結

這一節簡單介紹了zookeeper並闡述其工作原理,成功使用zookeeper部署了NameNode HA和Resourcemanager HA。


個人微博:http://weibo.com/seal13

QQ大數據技術交流群(廣告勿入):476966007



作者:Z盡際
鏈接:https://www.jianshu.com/p/b39f71b1522b
來源:簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請註明出處。

Hadoop框架基礎(五)