Hdfs高可用，yarn高可用

時間 2020-12-20

1.爲什麼高可用？

之前的hdfs的nn+dn+snn架構，snn是一個小時備份一次，如果突然nn節點掛了，就算回到之前的備份，新數據已經丟失。
爲了彌補這個缺點，有高可用架構nn+dn+nn，兩個nn一主一備，其中一個掛了，另一個馬上頂上。解決了單點問題。

如圖所示，兩個nn通過jn（JounalNode 日誌）來共享狀態，而dn會同時向兩個nn彙報心跳和blockreport。zk集羣裏的許多個zk通過選舉ZKFC進程來控制nn狀態。

各個點的細節

ActiveNN：操作記錄寫到自己的editlog,
同時JN集羣也會寫一份；
接收 DN的心跳和blockreport
StandbyNN: 接收JN集羣的日誌，
先是讀取執行log操作（重演），使得自己的元數據和activenn節點保持一致；
接收 DN的心跳和blockreport；
JounalNode: 用於 active standby nn節點的同步數據，部署是2n+1個(3個/5個–>7個)，奇數個的原因是爲避免兩個nn得到的選票是一樣的。
ZKFC: 單獨的進程
監控NN的健康狀態
向ZK定期發送心跳，使自己可以被選舉；當自己被ZK選舉爲主的時候，
zkfc進程通過RPC調用使NN的狀態變爲active，對外提供實時服務，無感知。
hdfs地址問題：假如
```
NN1 active  hdfs://192.168.1.100:9000/
NN2 standby hdfs://192.168.1.101:9000/
```
NN1地址是配置在core-site.xml，如果他崩了，那麼如何能切換到NN2呢？命名空間: nameservice: ruozeclusterg5，在這裏面設置nn的ip
```
hdfs dfs -ls hdfs://ruozeclusterg5/
```
zk部署：生產上50臺規模以下 7臺
50~100 9/11臺
>100 11臺要是2n+1 奇數個，做選舉

ZKFC: 線程
只作爲RM進程的一個線程而非獨立的守護進程來獨立存在
RMStateStore:
a.RM把job信息存在在ZK的/rmstore（就是RMStateStore）下，activeRM會向這個目錄寫app信息
b.當active RM掛了，另外一個standby RM通過zkfc選舉成功爲active，會從/rmstore讀取相應的作業信息。
重新構建作業的內存信息，啓動內部服務，開始接收NM的心跳，構建集羣的資源信息，並且接收客戶端的作業提交請求。
RM:
a.啓動時候的會向ZK的目錄/hadoop-ha寫個lock文件，寫成功的話，就爲active，否則爲standby。
然後standby rm節點會一直監控這個lock文件是否存在，假如不存在，就試圖創建，假如成功就爲active。
b.接收client的請求。接收和監控NM的資源狀況彙報，負載資源的分配和調度。
c.啓動和監控ApplicationMaster(AM) on NM的container

ApplicationMaster 就是JOB的老大相當於spark driver
NM: 節點的資源管理
啓動container運行task計算
上報資源
彙報task進度給AM ApplicationMaster

zkfc：hdfs是進程，yarn是線程 dn/nm：hdfs的dn同時向兩個nn彙報，yarn的nm只向active的rm彙報。