Hdfs的HA模式搭建驗證

搭建準備（全分佈式到HA模式）
節點規劃

拓展：
journalNode與NFS（A機子與B機子相同目錄掛載到C機子目錄）

HA模式下：有一個問題，你的NN是2臺？在某一時刻，誰是Active呢？
client是隻能連接Active的，那麼怎麼配置呢？

core-site.xml
fs.defaultFs -> hdfs://node01:9000
改爲下面的配置
hdfs://mycluster
用zk中的前綴（nameservice代替）

配置：
《core-site.xml》

	    <property>
		  <name>fs.defaultFS</name>
		  <value>hdfs://mycluster</value>
		</property>

		 <property>
		   <name>ha.zookeeper.quorum</name>
		   <value>node02:2181,node03:2181,node04:2181</value>
		 </property>

《hdfs-site.xml

		#以下是  一對多，邏輯到物理節點的映射
		<property>
		  <name>dfs.nameservices</name>
		  <value>mycluster</value>
		</property>
		<property>
		  <name>dfs.ha.namenodes.mycluster</name>
		  <value>nn1,nn2</value>
		</property>
		<property>
		  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
		  <value>node01:8020</value>
		</property>
		<property>
		  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
		  <value>node02:8020</value>
		</property>
		<property>
		  <name>dfs.namenode.http-address.mycluster.nn1</name>
		  <value>node01:50070</value>
		</property>
		<property>
		  <name>dfs.namenode.http-address.mycluster.nn2</name>
		  <value>node02:50070</value>
		</property>

		#以下是JN在哪裏啓動，數據存那個磁盤，同時也把JN的作用在參數名稱上體現了
		#（dfs.namenode.shared.edits.dir=>分享nn的edits的dir）
		<property>
		  <name>dfs.namenode.shared.edits.dir</name>
		  <value>qjournal://node01:8485;node02:8485;node03:8485/mycluster</value>
		</property>
		<property>
		  <name>dfs.journalnode.edits.dir</name>
		  <value>/var/bigdata/hadoop/ha/dfs/jn</value>
		</property>
		
		#HA角色切換的代理類和實現方法，我們用的ssh免密
		#因爲ZKFC有三隻手，要連zk、自己的nn、對面的nn
		#所以必須自己對自己免密，自己跟對面nn的機子免密
		<property>
		  <name>dfs.client.failover.proxy.provider.mycluster</name>
		  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
		</property>
		<property>
		  <name>dfs.ha.fencing.methods</name>
		  <value>sshfence</value>
		</property>
		<property>
		  <name>dfs.ha.fencing.ssh.private-key-files</name>
		  <value>/root/.ssh/id_dsa</value>
		</property>

##Hadoop中ssh免密的作用有如下兩點：
1：管理集羣間腳本調用
2：HA中zkfc調用本機，調用對面的nn

		#開啓自動化： 啓動zkfc
		 <property>
		   <name>dfs.ha.automatic-failover.enabled</name>
		   <value>true</value>
		 </property>

流程：

• 基礎設施

  • ssh免密：
    • 1）啓動start-dfs.sh腳本的機器需要將公鑰分發給別的節點
    • 2）在HA模式下，每一個NN身邊會啓動ZKFC，
      ZKFC會用免密的方式控制自己和其他NN節點的NN狀態

• 應用搭建

  • HA 依賴 ZK 搭建ZK集羣
  • 修改hadoop的配置文件，並集羣同步

• 初始化啓動（由HA 架構從裏到外）

  • 1）先啓動JN hadoop-daemon.sh start journalnode

  • 2）選擇一個NN 做格式化：hdfs namenode -format <只有第一次搭建做，以後不用做>

  • 3)啓動這個格式化的NN ，以備另外一臺同步 hadoop-daemon.sh start namenode

  • 4)在另外一臺機器中： hdfs namenode -bootstrapStandby

  • 5)格式化zk： hdfs zkfc -formatZK <只有第一次搭建做，以後不用做>

  • 6)start-dfs.sh

• 使用

---

• 使用驗證：
  • 1）去看jn的日誌和目錄變化：
  • 2）node04
    • zkCli.sh
      • ls /
      • 啓動之後可以看到鎖：
      • get /hadoop-ha/mycluster/ActiveStandbyElectorLock
  • 3）殺死namenode 殺死zkfc

    • kill -9 xxx

    • a)殺死第一臺active NN

      • 查看zk的hadoop-ha節點下的lock信息
        • 鎖持有者變成了第二臺
      • 查看webUI，發現主備變了
        • 第一臺掛，第二臺是主
      • 最後再啓動第一臺hadoop-daemon.sh start namenode
        • 發現第一臺是備，第二臺是主

    • b)殺死第二臺active NN身邊的zkfc

      • 查看zk的hadoop-ha節點下的lock信息
        • 鎖持有者變成了第一臺
      • 恢復第二臺的zkfc hadoop.daemon.sh start zkfc
        • 第一臺是主，第二臺是備

    • c)shutdown activeNN 主機的網卡 ： ifconfig eth0 down

      • 2節點一直阻塞降級（zk中的鎖持有者的節點不一定是active，因爲另外那個正常nn主機上的ZKFC要去被殺掉網卡的nn主機探查nn狀態的，但是網卡被殺連接拒絕，所以另外那個正常nn主機上的ZKFC也就蒙了，一直在報錯）

      • 如果恢復1上的網卡 ifconfig eth0 up

      • 最終 2變成active