您好,登錄后才能下訂單哦!
? 在hadoop1.0的時候,hdfs集群中namenode存在單點故障的問題,當namenode不可用的時候,就會導致整個hdfs集群服務不可用。另外如果需要臨時對namenode進行設計或者其他操作時,停掉namenode之后,hdfs集群也無法使用了。
? 通過HA的方式,可以一定程度上解決單點故障問題。
1)元數據管理方式需要改變:
內存中各自保存一份元數據;
Edits日志只有Active狀態的namenode節點可以做寫操作;
兩個namenode都可以讀取edits;
共享的edits放在一個共享存儲中管理(qjournal和NFS兩個主流實現);
2)需要一個狀態管理功能模塊
hadoop實現了一個zkfailover,常駐在每一個namenode所在的節點,每一個zkfailover負責監控自己所在namenode節點,利用zk進行狀態標識,當需要進行狀態切換時,由zkfailover來負責切換,切換時需要防止brain split現象的發生。
3)必須保證兩個NameNode之間能夠ssh無密碼登錄。用于后面的隔離。通過ssh方式到另外的namenode節點上,將namenode進程徹底殺死。防止腦裂。
4)隔離(Fence),即同一時刻僅僅有一個NameNode對外提供服務
namenode HA自動故障轉移除了要兩個namenode之外,還需要增加兩個組件:zookeeper集群服務,ZKFailoverController(ZKFC)。
它是zookeeper的一個客戶端,同時負責監控namenode的狀態。每個namenode上都運行一個ZKFC進程。
1)健康監測:
ZKFC使用一個健康檢查命令定期地ping與之在相同主機的NameNode,只要該NameNode及時地回復健康狀態,ZKFC認為該節點是健康的。如果該節點崩潰,凍結或進入不健康狀態,健康監測器標識該節點為非健康的。
2)ZooKeeper會話管理:
當本地NameNode是健康的,ZKFC保持一個在ZooKeeper中打開的會話。如果本地NameNode處于active狀態,ZKFC也保持一個特殊的znode鎖,該鎖使用了ZooKeeper對短暫節點(也就是臨時節點)的支持,如果會話終止,鎖節點將自動刪除。
ZKFC會在zookeeper上創建一個 /hadoop-ha/namenodeHA集群名稱/ 這樣一個節點,
該節點上有兩個子節點:
ActiveBreadCrumb:
持久節點,節點的值中記錄了 HA集群名稱 active節點別名 active節點地址
主要用于其他想訪問namenode服務的client用于獲取active狀態的namenode地址,所以必須得是持久節點。
ActiveStandbyElectorLock:
臨時節點,節點的值中記錄了 HA集群名稱 active節點別名 active節點地址。
起到互斥鎖的作用,只有獲取到該節點的使用權,才能修改上面ActiveBreadCrumb節點的值。
因為是臨時節點,所以當active namenode和zk保持連接,該節點就會一直存在,而standby的namenode也是和zk保持連接,但是發現該臨時節點已存在,就明白已經有人占用了,所以它不會做任何事。當上面的active namenode發生問題,不正常了,ZKFC就會斷開和zk的連接,那么臨時節點就會消失。此時standby namenode就會重新創建該臨時節點,相當于獲得了鎖,可以修改ActiveBreadCrumb的值。此時它自己也就順理成章變成新的active namenode。
3)基于ZooKeeper的選擇:
如果本地NameNode是健康的,且ZKFC發現沒有其它的節點當前持有znode鎖,它將為自己獲取該鎖。如果成功,則它已經贏得了選擇,并負責運行故障轉移進程以使它的本地NameNode為active。
主機 | 角色 |
---|---|
bigdata121/192.168.50.121 | namenode,journalnode,datanode,zk |
bigdata122/192.168.50.122 | namenode,journalnode,zk |
bigdata123/192.168.50.123 | zk |
軟件版本 | hadoop2.8.4,zookeeper3.4.10,centos7.2 |
jdk,zookeeper部署不重復講了,看之前的文章吧
基礎環境配置:
每個機器添加主機名解析/etc/hosts
每臺主機對自己,以及對另外兩臺主機都要配置ssh免秘鑰登錄
關閉防火墻以及selinux
hadoop的完整部署可以看之前的文章,這里著重講namenode HA的配置。
修改配置文件:
core-site.xml
<configuration>
<!--指定namenode的HA集群的名字 -->
<property>
<name>fs.defaultFS</name>
<value>hdfs://mycluster</value>
</property>
<!--指定hadoop中hdfs保存數據塊和元數據塊的目錄-->
<property>
<name>hadoop.tmp.dir</name>
<value>/opt/modules/HA/hadoop-2.8.4/data/ha_data</value>
</property>
<!--指定使用的zk集群的所有節點ip:port-->
<property>
<name>ha.zookeeper.quorum</name>
<value>bigdata121:2181,bigdata122:2181,bigdata123:2181</value>
</property>
</configuration>
hdfs-site.xml
<configuration>
<!-- namenode完全分布式集群名稱,名字需和core-site中定義的集群名字一樣 -->
<property>
<name>dfs.nameservices</name>
<value>mycluster</value>
</property>
<!-- 集群中NameNode節點都有哪些,這里是節點的別名 -->
<property>
<name>dfs.ha.namenodes.mycluster</name>
<value>nn1,nn2</value>
</property>
<!-- nn1的RPC通信地址 -->
<property>
<name>dfs.namenode.rpc-address.mycluster.nn1</name>
<value>bigdata121:9000</value>
</property>
<!-- nn2的RPC通信地址 -->
<property>
<name>dfs.namenode.rpc-address.mycluster.nn2</name>
<value>bigdata122:9000</value>
</property>
<!-- nn1的http通信地址 -->
<property>
<name>dfs.namenode.http-address.mycluster.nn1</name>
<value>bigdata121:50070</value>
</property>
<!-- nn2的http通信地址 -->
<property>
<name>dfs.namenode.http-address.mycluster.nn2</name>
<value>bigdata122:50070</value>
</property>
<!-- 指定NameNode元數據在JournalNode上的存放位置,用于存放edits日志 ,多個節點用逗號隔開-->
<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://bigdata121:8485;bigdata122:8485/mycluster</value>
</property>
<!-- 配置隔離機制,即同一時刻只能有一臺服務器對外響應,有shell和sshfence兩種方式,主要用于到down掉的namenode所在主機將進程kill掉
防止腦裂的情況 -->
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>
<!-- 使用隔離機制時需要ssh無秘鑰登錄到另外的主機上將namenode進程kill掉,這里指定私鑰的路徑-->
<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_rsa</value>
</property>
<!-- 聲明journalnode服務器存儲目錄-->
<property>
<name>dfs.journalnode.edits.dir</name>
<value>/opt/modules/HA/hadoop-2.8.4/data/jn</value>
</property>
<!-- 關閉權限檢查-->
<property>
<name>dfs.permissions.enable</name>
<value>false</value>
</property>
<!-- 訪問代理類:client,mycluster,active配置失敗自動切換實現方式。用于訪問已配置HA的namenode-->
<property>
<name>dfs.client.failover.proxy.provider.mycluster</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>
<!-- 啟動ha的自動故障轉移,無需手動切換故障的namenode-->
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
</configuration>
配置文件同步到各個節點中。使用scp或者rsync隨意吧。
第一次啟動時:
cd /opt/modules/HA/hadoop-2.8.4
1)各個journalnode節點上啟動journalnode服務
sbin/hadoop-daemon.sh start journalnode
2)nn1上格式化namenode,并啟動
bin/hdfs namenode -format
sbin/hadoop-daemon.sh start namenode
3)nn2上通過啟動的journalnode從nn1上同步namenode的數據到本地namenode
bin/hdfs namenode -bootstrapStandby
4)啟動nn2
sbin/hadoop-daemon.sh start namenode
5)nn1上啟動所有datanode
sbin/hadoop-daemons.sh start datanode
6)兩臺namenode上查看namenode狀態
bin/hdfs haadmin -getServiceState nn1
bin/hdfs haadmin -getServiceState nn2
正常情況一個是active,一個是standby
7)手動轉換成active和standby
bin/hdfs haadmin -transitionToActive namenode名稱
bin/hdfs haadmin -transitionToStandby namenode名稱
注意,如果需要手動切換,那么需要將hdfs-site.xml中的自動切換關掉。否則報錯。
或者使用 --forceactive 進行強制轉換。
啟動完成后,可以手動將active的namenode關掉,可以看到剛剛standby的namenode會自動轉為 active。而剛才關掉的namenode重新上線的話,就會變為standby。
第二次啟動:
直接start-dfs.sh即可
當我們啟動完整個namenode的HA集群之后,我們發現并沒有SNN的身影,天真的我以為以為還需要手動啟動,就手動啟動一發了,結果報錯了。
查看SNN的啟動日志,可以發現有這么一個報異常信息
org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Failed to start secondary namenode
java.io.IOException: Cannot use SecondaryNameNode in an HA cluster. The Standby Namenode will perform checkpointing.
at org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode.<init>(SecondaryNameNode.java:189)
at org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode.main(SecondaryNameNode.java:690)
意思很明顯了,就是說SNN的職責由standby的namenode來完成了,HA狀態下不需要SNN的存在了。這樣其實也很合理,可以說是充分利用了standby的namenode,免得它閑在那里。
其實和上面的namenode的ha類似,也是借助ZKFC進行監控RM。
會在 zk上創建一個 /yarn-leader-election/yarn集群名稱 的節點,
下面有兩個子節點:ActiveBreadCrumb, ActiveStandbyElectorLock
作用類似,不重復講。工作機制基本類似的
主機 | 角色 |
---|---|
bigdata121 | zk, rm |
bigdata122 | zk, rm |
bigdata123 | zk |
yarn-site.xml
<configuration>
<!-- Site specific YARN configuration properties -->
<!--指定reducer獲取數據方式為shuffle機制-->
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<!--啟動日志聚集功能-->
<property>
<name>yarn.log-aggregation-enable</name>
<value>true</value>
</property>
<!--指定日志保留時間為7天,單位是秒-->
<property>
<name>yarn.log-aggregation.retain-seconds</name>
<value>604800</value>
</property>
<!--啟用resourcemanager ha-->
<property>
<name>yarn.resourcemanager.ha.enabled</name>
<value>true</value>
</property>
<!--聲明兩臺resourcemanager的集群名稱-->
<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>cluster-yarn1</value>
</property>
<!--聲明兩臺resourcemanager的節點的別名-->
<property>
<name>yarn.resourcemanager.ha.rm-ids</name>
<value>rm1,rm2</value>
</property>
<!--聲明兩臺rm的地址-->
<property>
<name>yarn.resourcemanager.hostname.rm1</name>
<value>bigdata121</value>
</property>
<property>
<name>yarn.resourcemanager.hostname.rm2</name>
<value>bigdata122</value>
</property>
<!--指定zookeeper集群的地址-->
<property>
<name>yarn.resourcemanager.zk-address</name>
<value>bigdata121:2181,bigdata122:2181,bigdata123:2181</value>
</property>
<!--啟用自動恢復,故障自動切換-->
<property>
<name>yarn.resourcemanager.recovery.enabled</name>
<value>true</value>
</property>
<!--指定resourcemanager的狀態信息存儲在zookeeper集群-->
<property>
<name>yarn.resourcemanager.store.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
</property>
</configuration>
配置文件同步到其他節點。
bigdata121:啟動yarn
sbin/start-yarn.sh
bigdata122:啟動rm
sbin/yarn-daemon.sh start resourcemanager
查看服務狀態:
bin/yarn rmadmin -getServiceState rm1
bin/yarn rmadmin -getServiceState rm2
測試方式和namenode類似,這里不重復
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。