HDFS NameNode HA框架設計文檔（HDFS-1623：High Availability Framework for HDFS NN）

openkk 12年前發布 | 38K 次閱讀 Hadoop 分布式/云計算/大數據

原文請參

譯文如下：
</div>

1     Problem Statement

有很多方式可以使得NN更加的Available，例如：減少啟動時間，配置熱刷選，減少升級時間，NN的手動或自動的Failover。本文檔通過Failover來解決NN的SPOF問題

有很多種方式可以提供NN的Failover，例如Shared-Storage，IP-Failover，smart-client，Zookeeper，linxu-ha。這些不同的方式作為HA框架的構建積木，本文定義了各個積木塊及其實現。
</blockquote> 2     Terminology

ActiveNN     提供讀寫服務的NN

StandbyNN     等待成為ActiveNN的NN，0.21中的BackupNode可以用來實現為Standby

為了避免混淆，PrimaryNN和SecondaryNN將不會在這里使用。

Hot, Warm, Cold failover這三個Failover，依賴于StandbyNN中存儲的ActiveNN運行時狀態決定：
</blockquote>

Cold Standby:      StandbyNN不存儲任何狀態，在ActiveNN失效后它才開始啟動

Warm Standby:   StandbyNN具有部分狀態，包括Fsimage，Editlogs，但沒有Blockreport信息。或者含有Fsimage和rolled logs以及Blockreports

Hot Standby:        StandbyNN具有幾乎所有的ActiveNN的狀態，能夠立即啟動
</div> </div> </blockquote> </blockquote> 3     High Level Use Cases

Planned Downtime：Hadoop經常需要升級軟件和更新配置而重啟集群。在一個4000個節點的集群大概需要2個小時來重啟，在release23內，大概需要半個小時

UnplannedDowntime：NN的Failover可能由于硬件，OS，NN自身等各種原因。由于不確定性，導致NN在某些領域很難達到SLA的要求

這兩者都可以通過warm/hot的Failover來減少宕機時間。實踐表明，有計劃的升級是hdfs的宕機最大的原因。
</blockquote> 4     Out of scope

Active-ActiveNN     這種模式太難搞了，這個設計真值討論Acitve-StandbyNN的模式

More-than-2 NN     現在只討論一個namespace，最多兩個NN的情況

Cross-cole Failover或者稱為BCP
</blockquote>

5     Failures Supported

支持一個HW失效如disk，nic，links等等，多重失效不會處理，僅僅保證數據不會丟失

軟件失效如NN及NN的lockup都會支持，但是同樣的錯誤在StandbyNN變成ActiveNN時再次發生，可能不會處理好

NN的GC是一個比較郁悶的問題，GC的時候可能會是的ActiveNN被認為是dead的
</blockquote>

6     Requirements

1、只有一個NN是Active的并且 只有這個ActiveNN能提供服務，改變namespace。以后可以考慮讓StandbyNN提供讀服務

2、提供手動Failover，在升級過程中，Failover在NN-DN之間寫一部不變的情況下才能生效

3、在之前的NN重新恢復之后，不能提供failback

4、數據一致性比Failover更重要

5、盡量少用特殊的硬件

6、HA的設置和Failover都應該保證在兩者操作錯誤或者配置錯誤的時候，不得導致數據損壞

7、NN的短期GC不應該觸發Failover
</blockquote>

7     Detailed Use Cases

1、單一NN的配置，沒有Failover

2、Active-Standby配置手動Failover，Standby可以是cold/warm/hot

3、Active-Standby配置自動Failover：
</blockquote>

1、兩個NN啟動，一個自動成為ActiveNN，一個為Standby

2、Active失效或者狀態未知，Standby接管并成為ActiveNN

3、Active和Standby度運行的情況，Standby失效，Active不受影響

4、 Standby沒啟動且 Active失效不能啟動時候，Standby應該可以啟動成為ActiveNN。
</blockquote> </blockquote>

8     Design Considerations

以下是幾個設計方案，有幾個模塊都有幾 種方案供選擇，如：是否啟動Storage來存儲NN的狀態？如何進行leader election(Zookeeper/LinuxHA/其他)？如何實現fencing？其他部分基本一致。以下兩個圖分別描述Zookeeper和 LinuxHA來做shared-storage的情況，這個設計也可擴展到BackupNode

HDFS NameNode HA框架設計文檔（HDFS-1623：High Availability Framework for HDFS NN）

HDFS NameNode HA框架設計文檔（HDFS-1623：High Availability Framework for HDFS NN）


8、1     shared storage vs shared nothing storage for NN metadata

在Active和Standby之間，可以選擇采用share-storage(NFS)或選擇ActvieStream將edits導向StandbyNode(release21之后的BackupNode就是這樣)，以下是一些考慮點：
</blockquote>

1、shared-storage的 server就是一個spof，也需要能夠做到HA。bookkeeper是一個好的解決方案，但是目前仍不成熟。使用bookkeeper，NN不需要 將狀態保存到本地disk就可讓NN完全"stateless"。有些實現已經將NFS作為方案實現了

2、BackupNode可以不要使用shared-storage，但是不支持usecase3.4

3、只要shared-storage不用在BackupNode的方式去解決usecase3.4，那么BackupNode不需要去做fencing，shared-store必須要考慮fencing，如果用STONITH，那么所有的fencing問題都解決了

4、BackupNode只有在full-sync的情況下才能接管變成ActiveNN

5、但是當BackupNode宕機了，還需要使用外部的存儲設備來獲取ActiveNN的狀態，這又會到了shared-storage的情況

HDFS NameNode HA框架設計文檔（HDFS-1623：High Availability Framework for HDFS NN）

HDFS NameNode HA框架設計文檔（HDFS-1623：High Availability Framework for HDFS NN）
</blockquote> 8、2      Parallel Block reports to Active & Standby
本設計中，DN要么同時向Active&Standby都發送Blockreport，通過一個中間層來完成將Blockreport變成兩個分支發現Active&Standby
8、3      Client redirection after failover

當ActiveNN失效時，client需要重連到新的ActiveNN，這也稱為client-Failover，一般通過以下方式來完成：
</blockquote>

1、修改DNS綁定：但是很多os，lib庫，都會緩存DNS。

2、Smart-Client：和server-based重定向一起，通過重試或者re-lookup到ActiveNN，但需要考慮：
</blockquote> </blockquote>

1、注意：使用server-based重定向時，如果發生split-brain，兩個server都不會做重定向。所以在任何shared-storage情況下必須要有一個很好的fencing機制確保只有一個server在寫editlog
2、能夠和http以及JMX很好的協作否？

3、Failover時間拉長，因為Client必須要和第一個NN（可能死了）聯系，才能去重新獲取新的NN
</blockquote> 3、使用in-band負載均衡去通知client定位到正確的NN，但是client太多了就很難擴展了
4、IP-Failover，這是業界最常用的方式之一，通過vip的方式提供服務，vip的地址由ActiveNN來提供，在跨機架的情況需要使用VLAN來支持 </blockquote> 8、4      Client time‐out during NN startup </blockquote>

NN在需要一個相當長 的時間來進行start，load-fsimage，apply-eidts，接受Blockreport之后才提供服務。這也使得client以為NN 已經死了。因此，在ActiveNN啟動時，應該向client響應一個"Startingup"的信息叫client進行wait。

8、5      Failover control outside NN using FailoverController(Watchdog)

FailoverController 被設計在獨立于NN之外，類似與LinuxHA中的ResourceManager。所以如果使用LinuxHA的話，那么 ResourceManager直接作為FailoverController，如果使用Zookeeper的話，可以自己寫一個 FailoverController，或者配置LinuxHA的ResourceManager來連接到Zookeeper作為 FailoverController

FailoverController主要完成以下功能：

監控NN的狀態，OS，HW，以及網絡

監控heartbeat，以便參與leader選決

在leader選舉中，一旦一個NN被選擇了，那么其FailoverController會通知NN從Standby轉向Active，NN啟動的時候都是Standby的，除非FailoverController通知了NN做狀態轉換到Active
讓FailoverController獨立出來，有以下幾個優點： </blockquote>

1、對FailoverController進行heartbeat的監控更好，使得不會像NN那樣做GC導致heartbeat過期。

2、FailoverController的代碼少，從應用中隔離，更健壯

3、使得leader election可插拔
</blockquote>

8、6     Fencing

在Failover的 過程中，必須確保只有一個Active的NN能夠寫入到shared狀態中去。盡管有leader election，但是老的Active實例可能被隔離但不一定能迅速的切換為Standby狀態，所以會繼續寫入到shared狀態中。Fencing 通過要求ActiveNN在發生IO錯誤時，不要再次試圖重新獲取Share-State的寫權限。因為Fencing設備可以在老的ActiveNN上 發起一個IO錯誤。因此最好是讓老的ActiveNN退出，變成standby都不行。

以下幾個shared-resource需要考慮fencing

1、當使用share-storage來存儲NN的metadata的時候，必須確保只有一個ActiveNN來寫入editlog

2、Datanodes：必須確保只有一個NN能夠發布delete操作來管理replica

3、 Clients：clients雖然不會受限制于一個被NN寫入的share-storage的設備，但是當client發送數據更新到兩個NN的時候， 必須要確保只有一個NN來響應這個請求。當NN端已經通過share-storage來fencing時，那么就只有一個NN能夠正確的響應到 client
</blockquote>

8、7     Other failover issues

Failover過程中的lease Recovery-TBD

Failover過程中的pipeline Recovery
</blockquote>

9     Detailed Design

9、1     Fencing

上面已經描述在share-storage中，fencing是必須的，fencing之后，NN應該退出
</blockquote>

9、1、1      Fencing Shared Storage Containing NN Metadata
</blockquote>

在hdfs-1073之后，fsimage和editlog已經解耦，所以只有editlog需要fencing。NN啟動時候，永遠都會打開一個新的editlog，所以需要確保老的Active不會再次寫入老的edit然后和client進行交互
</blockquote>

1、WITH-NFS：fencing解決方案需要被調查

2、WITH-BOOKKEEPER：當前正和bookkeeper的開發者商量開發fencing的事情

3、WITH-Share-Disk(scsi/san)：這些設備都有內置的fencing，但不一定在Hadoop的環境下合適
</blockquote> </blockquote> </blockquote>

9、1、2      Fencing DataNodes

兩個解決方案：

Solution 1：
</blockquote> </blockquote>

在heartbeat的響應中，NN表名自己的狀態是Active/Standby。
</blockquote> </blockquote>

如果DN發現了狀態更改，再次檢查zk中去發現ActiveNN

如果Active從A->B->A，那么DN將無法檢查到，可以通過FailoverController來通知DN，但是DN太多了，所以必須要將這個機制內建在協議中。
</blockquote> Solution 2： </blockquote> </blockquote>

每個NN都一個數字，當狀態發送改變時候，增加這個數字，這個數字在register和heartbeat中都攜帶

DN為每個NN都保存這個數字，并且監聽最近的從Standby->Active的NN

如果之前Active回來并且自稱是ActiveNN的時候(例如由于長GC)，DN應該拒絕它，因為之前那個數字已經stale，另外一個新的數字已經接管為Active了。
</blockquote> </blockquote>

9、1、3     Fencing Clients

當client向NN發送update的命令的時候，只有一個ActiveNN會響應。如果NN采用shared-storage的fencing，那么non-ActiveNN也沒法寫入editlog，所以也無法向client發回響應

9、1、4     Stonith as a Brute-Force Fencing Solution

Stonith經常是一個比較粗魯的fencing的一個解決方案，當沒有其他fencing解決方案的時候，Stonith一般通過控制電源來關閉節點。

9、2     Leader Election and FailoverController Deamon

上面已經說了獨立的 FailoverController的優點了，另外，LinuxHA中的ResourceManager已經可以作為 FailoverController來使用了。所以，如果采用LinuxHA方案時，直接用ResourceManager來作為 FailoverController，采用zk時候，可以自己寫一個類似的FailoverController，或者利用LinuxHA的 ResourceManager作為妨礙了，zk作為Leader Elector
</blockquote>

9、2、1     FailoverController Daemon‘s  Operatuions：

Heartbeat：確保ActiveNN的監控狀況，一旦丟失，立即初始化一個LeaderElection
</blockquote> </blockquote>

For ZK：FailoverController定期向ZK發送Heartbeat

For LinuxHA：ResourceManager向Standby發送Heartbeats
</blockquote> HealthMonitor： </blockquote> </blockquote>

查看NNprocess的狀態

簡單查詢NN的響應(考慮到NN的GC問題)

OS健康檢查

NIC健康檢查

網關健康檢查（有坑）
FailoverController需要容許NN在進行Active->Standby或者Standby->Active轉換時，可以進行一系列的操作，而這些操作是可配置的。如LinuxHA容許個人配置一系列的操作在它管理的資源上執行 </blockquote>

在 Standby->Active的轉換過程中，以下步驟是必須的
</blockquote>

Fencing shared-storage和DNs（Stonith是最后的選擇）

更新client的地址并且接管vip

通知StandbyNN變成AcitveNN
</blockquote> </blockquote>

在Active->Standby的轉換過程中，以下步驟是必須的
</blockquote>

更新client的地址或者放棄VIP

通知ActiveNN要么轉換為Standby，要么退出，如果不響應，則kill掉
</blockquote> </blockquote> </blockquote>

9、3     NN Startup and Active-Standby State Changes

在NN啟動時，首先進入到Standby，只有FailoverController通知變成Active的情況下，才回變成Active
</blockquote>

9、3、1     NN in Standby

不響應任何請求
</blockquote>

讀取image，處理edits（通過disk或者socket如果是Bnn）
</blockquote>

接收BRs并處理，但是不會發送Delete&Copy命令到DN
</blockquote>

9、3、2     NN become Active

當NN變成Active的時候，過程如下：

完成最后的edit處理
</blockquote>

通知client，目前自己處理Startup模式（safemode的一個變種）
</blockquote> </blockquote>

9、4     Client Redirection

上面已經描述了兩種可行的方案，設計方案需討論

9、4、1     Smart-Client Approach

需要討論在NN進行Failover的時，Client通過另外的service(如：zk)進行lookup ActiveNN的地址。這種方式的優缺點在哪兒？和SecurityToken會不會沖突？

9、4、2     IP Failover Approach

業界標準做法-如何工作？TBD

優點在于： 對所有協議(HDFS,HTTP,JMX,ETC)透明。

問題在于：跨機架的vip
</blockquote>

9、5     Shared Storage Approach

Standby reads rolled edits from shared storage. i.e. is out of date only wrt to the current unrolled edits  (assuming hdfs‐1073). Add details. TBD

9、6     Non-share Approach: using the backup NN

考慮usecase3.4，并且介紹BN如何工作，另外如果ActiveNN由于nic問題和BN失去聯系，而將BN剔除，如果此時Failover了，那么顯然BN和ActiveNN不同步
10      Appendix A: Situations that resulting in problematic behavior

10.1 Automatic Failback

Explain the problem and how it can occur

10.2 Amnesia

Loss of state that was already communicated to clients – can occur if fencing is poor or if and older state is read by Standby.Explain details
</div>

10.3 GC
</div>

How do we differential from NN that does not response when it hung versus one that is in short GC phase？Investigate
</div> </div> </blockquote> 轉自：http://blog.csdn.net/chenpingbupt

 本文由用戶 openkk 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

相關經驗

相關資訊

相關文檔