如何理解Namenode的HA機制

這篇文章主要講解了“如何理解Namenode的HA機制”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解Namenode的HA機制”吧！

【整體設計】

NN（Namenode）的HA機制主要依靠zkfc完成，zkfc在NN所在節點以獨立進程的方式運行。其內部主要由主控模塊（ZKFailoverController）、健康檢測模塊（HealthMonitor）、主從選舉模塊（ActiveStandbyElector）三個模塊協同實現。

zkfc進程啟動時，首先會創建ZKFailoverController，負責其余兩個模塊回調事件的處理。

健康檢測模塊通過定時向NN發送rpc請求進行健康狀態的監測。

主從選舉模塊封裝了對zookeeper的處理邏輯，包括tcp連接的建立、創建節點、watch節點的變化等。

當NN的健康狀態發生變化時，健康檢測模塊會回調通知主控模塊，進而觸發選舉模塊進行選舉或者退出選舉。

同樣，當選舉模塊檢測到zookeeper上節點的狀態變化時，會自主觸發進行選舉，然后回調通知主控模塊，最后通過rpc通知NN成為active或standby。

zkfc的啟動選舉流程如下圖所示：

• zkfc啟動后，首先構造選舉模塊，并向zookeeper建立連接

• 然后啟動對NN的健康檢測，向NN發送rpc請求，獲取NN的狀態和健康情況

• 假如NN是健康的，觸發進行選舉，即在zookeeper上創建臨時的鎖節點

• zk本身的機制保證只有一個zkfc能成功創建節點。

  對于成功創建節點的zkfc，會向其他的NN發送rpc請求進行fencing（本質上是告知對端成為standby），然后在zookeeper上創建持久的記錄NN主從相關信息的節點（ActiveBreadCrumb），最后向本地的 NN發送rpc請求告知其成為ANN（ActiveNameNode）。

  
  

  而創建節點失敗的zkfc，則通過回調向本地的NN發送rpc請求，告知其成為standby，然后對ANN在zookeeper中創建的鎖節點進行watch。

【HA切換場景】

• ANN異常

  當ANN出現異常（包括進程退出，狀態和健康情況的rpc請求無響應等）時，zkfc會主動退出選舉，即結束與zookeeper的tcp連接，該連接對應的會話在zookeeper上創建的鎖節點也會自動被刪除。

  
  

  在該節點上進行watch的（運行在SNN上的）zkfc感知到節點的變化，觸發進行選舉（重新在zookeeper上創建鎖節點），然后獲取ActiveBreadCrumb節點的值，從中得到老的ANN節點的信息，當發現老的ANN并非本節點時，zkfc就觸發對其進行fencing，然后在ActiveBreadCrumb節點上寫入新的信息，最后通知SNN成為新的ANN。

  
  

• zkfc異常&ANN所在節點網絡異常

  這兩種場景和上面的流程差別不大，區別在于，zookeeper檢測zkfc建立的連接超時，從而自動將該連接上會話創建的臨時節點刪除。后面的流程就和上面的一樣了。

  
  

【注意事項】

• fencing的處理

  前面選舉流程和HA切換流程中都提到了fencing（隔離），那么為什么好進行fencing，fencing的意義是什么？

  
  

  就上面zkfc異常的場景，來深入分析下：

  當ANN所在節點的zkfc出現異常，或者僅僅是zkfc與zookeeper之間的網絡不穩定，導致zkfc與zookeeper之間的會話超時，從而觸發snn節點上的zkfc選舉并成為新的ANN。

  
  

  如果不進行fencing，那么此時存在兩個ANN，并同時對外提供服務，這可能會導致hdfs的數據不能保證一致性，甚至出現錯亂無法恢復。

  
  

  因此SNN在成為新的ANN之前，需要對老的ANN進行fencing處理。

  具體為zkfc直接向老的ANN發送rpc請求，通知其成為SNN，這個過程為優雅的fencing。

  
  

  如果老的ANN成功響應，那么zkfc會進而通知SNN成為新的ANN。

  如果老的ANN沒有進行響應，那么就會根據配置的方式再次進行fencing。

  
  

  可配置的方式包括ssh和執行指定的腳本。

  
  

  ssh的方式為zkfc通過ssh到老的ANN節點上，然后執行kill動作，將老的ANN殺掉，最后通知SNN成為新的ANN。如果ANN所在節點的網絡異常，無法成功ssh，因此也就無法將老的ANN殺掉。

  
  

  因此，通常的方式是執行自己編寫的腳本，在腳本中進行相關的處理動作。zkfc通過腳本的返回結果決定通知SNN成為新的ANN，或者再次觸發選舉流程。

  
  

• 健康狀態的定義

  前面提到了健康檢測模塊會定時向NN發送rpc請求，獲取nn的狀態（Active/Standby/Initializing）和健康狀態，那么NN怎樣判斷自身是健康的呢？

  
  

  跟蹤其源碼發現：NN對配置的本地目錄（用于存儲fsimage和editlog的目錄和其他指定配置的目錄）進行磁盤容量檢查，如果目錄對應的磁盤容量達到配置的最小值，則NN認為自身是健康的，否則認為是非健康的。

  
  

• 確保父節點存在

  zkfc啟動并成功連接zookeeper后，首先會存儲鎖節點的父親節點是否存在，如果不存在，zkfc進程會直接退出。

  
  

  zkfc啟動時，可以指定format參數，這時zkfc會刪除在zookeeper上存儲的信息，并創建出必備的父親節點，然后進程退出。再次啟動時（不帶參數）就能正確進行選舉了。

  
  

  另外，如果在zkfc運行過程中，將對應的父親節點刪除了，zkfc不會再自動創建出來，此時選舉用的鎖節點會持續創建失敗導致無法正常選舉，從而導致NN無法正常提供服務。

  
  

• 確保NN的ID與IP保持一致

  NN正常選舉成功后，ANN會在zookeeper上創建ActiveBreadCrumb節點，記錄ANN/SNN的ID與對應的IP信息。

  
  

  由于該節點是持久化的，因此當NN重啟或者重新選舉后，會讀取該節點的值，從中獲取老的ANN的IP信息，用于fencing處理。在此之前，會將節點記錄的NN的ID與對應的IP和本地配置的情況進行比較，如果與配置中的不一致，會拋出異常不會再進行后續的處理。

  
  

  通常出現該情況的場景是NN以容器的方式部署運行，當NN所在的容器下線重啟后，NN分配的IP發生了變化，導致與記錄在zookeeper中ActiveBreadCrumb節點的信息不一致。

感謝各位的閱讀，以上就是“如何理解Namenode的HA機制”的內容了，經過本文的學習后，相信大家對如何理解Namenode的HA機制這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！