一、背景
天雲趨勢在2012年下半年開始為某大型國有銀行的曆史交易資料備份及查詢提供基于Hadoop的技術解決方案，由于行業的特殊性，客戶對服務的可用性有着非常高的要求，而HDFS長久以來都被單點故障的問題所困擾，直到Apache Hadoop在2012年5月釋出了2.0的alpha版本，其中MRv2還很不成熟，可HDFS的新功能已經基本可用，尤其是其中的的High Availability(以下簡稱HA)和Federation。Cloudera也于7月制作了CDH4.0.1，包含了Hadoop 2.0的諸多新功能群組件，于是我們就基于CDH4.0.1進行了HA和Federation的測試。
此工作由我和同僚張軍、錢興會共同完成。
二、為什麼需要HA和Federation
單點故障
在Hadoop 2.0之前，也有若幹技術試圖解決單點故障的問題，我們在這裡做個簡短的總結
Secondary NameNode。它不是HA，它隻是階段性的合并edits和fsimage，以縮短叢集啟動的時間。當NameNode(以下簡稱NN)失效的時候，Secondary NN并無法立刻提供服務，Secondary NN甚至無法保證資料完整性：如果NN資料丢失的話，在上一次合并後的檔案系統的改動會丢失。
手動把name.dir指向NFS。這是安全的Cold Standby，可以保證中繼資料不丢失，但叢集的恢複則完全靠手動。
叢集容量和叢集性能
單NN的架構使得HDFS在叢集擴充性和性能上都有潛在的問題，當叢集大到一定程度後，NN程序使用的記憶體可能會達到上百G，常用的估算公式為1G對應1百萬個塊，按預設塊大小計算的話，大概是64T (這個估算比例是有比較大的富裕的，其實，即使是每個檔案隻有一個塊，所有中繼資料資訊也不會有1KB/block)。同時，所有的中繼資料資訊的讀取和操作都需要與NN進行通信，譬如用戶端的addBlock、getBlockLocations，還有DataNode的blockRecieved、sendHeartbeat、blockReport，在叢集規模變大後，NN成為了性能的瓶頸。Hadoop 2.0裡的HDFS Federation就是為了解決這兩個問題而開發的。
三、Hadoop 2.0裡HA的實作方式
圖檔作者： Sanjay Radia, Suresh Srinivas
在這個圖裡，我們可以看出HA的大緻架構，其設計上的考慮包括：
利用共享存儲來在兩個NN間同步edits資訊。
DataNode(以下簡稱DN)同時向兩個NN彙報塊資訊。
這是讓Standby NN保持叢集最新狀态的必需步驟，不贅述。
用于監視和控制NN程序的FailoverController程序
顯然，我們不能在NN程序内進行心跳等資訊同步，最簡單的原因，一次FullGC就可以讓NN挂起十幾分鐘，是以，必須要有一個獨立的短小精悍的watchdog來專門負責監控。這也是一個松耦合的設計，便于擴充或更改，目前版本裡是用ZooKeeper(以下簡稱ZK)來做同步鎖，但使用者可以友善的把這個ZooKeeper FailoverController(以下簡稱ZKFC)替換為其他的HA方案或leader選舉方案。
共享存儲fencing，確定隻有一個NN可以寫入edits。
用戶端fencing，確定隻有一個NN可以響應用戶端的請求。
DataNode fencing，確定隻有一個NN可以向DN下發指令，譬如删除塊，複制塊，等等。
四、Hadoop 2.0裡Federation的實作方式
這個圖過于簡明，許多設計上的考慮并不那麼直覺，我們稍微總結一下
多個NN共用一個叢集裡DN上的存儲資源，每個NN都可以單獨對外提供服務
每個NN都會定義一個存儲池，有單獨的id，每個DN都為所有存儲池提供存儲
DN會按照存儲池id向其對應的NN彙報塊資訊，同時，DN會向所有NN彙報本地存儲可用資源情況
如果需要在用戶端友善的通路若幹個NN上的資源，可以使用用戶端挂載表，把不同的目錄映射到不同的NN，但NN上必須存在相應的目錄
這樣設計的好處大緻有：
改動最小，向前相容
現有的NN無需任何配置改動.
如果現有的用戶端隻連某台NN的話，代碼和配置也無需改動。
分離命名空間管理和塊存儲管理
提供良好擴充性的同時允許其他檔案系統或應用直接使用塊存儲池
統一的塊存儲管理保證了資源使用率
可以隻通過防火牆配置達到一定的檔案通路隔離，而無需使用複雜的Kerberos認證
用戶端挂載表
通過路徑自動對應NN
使Federation的配置改動對應用透明
五、測試環境
以上是HA和Federation的簡介，對于已經比較熟悉HDFS的朋友，這些資訊應該已經可以幫助你快速了解其架構和實作，如果還需要深入了解細節的話，可以去詳細閱讀設計文檔或是代碼。這篇文章的主要目的是總結我們的測試結果，是以現在才算是正文開始。
為了徹底搞清HA和Federation的配置，我們直接一步到位，選擇了如下的測試場景，結合了HA和Federation：
這張圖裡有個概念是前面沒有說明的，就是NameService。Hadoop 2.0裡對NN進行了一層抽象，提供服務的不再是NN本身，而是NameService(以下簡稱NS)。Federation是由多個NS組成的，每個NS又是由一個或兩個(HA)NN組成的。在接下裡的測試配置裡會有更直覺的例子。
圖中DN-1到DN-6是六個DataNode，NN-1到NN-4是四個NameNode，分别組成兩個HA的NS，再通過Federation組合對外提供服務。Storage Pool 1和Storage Pool 2分别對應這兩個NS。我們在用戶端進行了挂載表的映射，把/share映射到NS1，把/user映射到NS2，這個映射其實不光是要指定NS，還需要指定到其上的某個目錄，稍後的配置中大家可以看到。
下面我們來看看配置檔案裡需要做哪些改動，為了便于了解，我們先把HA和Federation分别介紹，然後再介紹同時使用HA和Federation時的配置方式，首先我們來看HA的配置：
對于HA中的所有節點，包括NN和DN和用戶端，需要做如下更改：
HA，所有節點，hdfs-site.xml
以上的示例裡，我們用了${}來表示變量值，其展開後的内容大緻如下：
與此同時，在HA叢集的NameNode或用戶端還需要做如下配置的改動：
HA，NameNode，hdfs-site.xml
HA，用戶端，hdfs-site.xml
最後，為了友善使用相對路徑，而不是每次都使用hdfs://ns1作為檔案路徑的字首，我們還需要在各角色節點上修改core-site.xml：
HA，所有節點，core-site.xml
接下來我們看一下如果單獨使用Federation，應該如何配置，這裡我們假設沒有使用HA，而是直接使用nn1和nn2組成了Federation叢集，他們對應的NS的邏輯名稱分别是ns1和ns2。為了便于了解，我們從用戶端使用的core-site.xml和挂載表入手：
Federation，所有節點，core-site.xml
我們在上面的core-site中包含了一個cmt.xml檔案，也就是Client Mount Table，用戶端挂載表，其内容就是虛拟路徑到具體某個NS及其實體子目錄的映射關系，譬如/share映射到ns1的/real_share，/user映射到ns2的/real_user，示例如下：
Federation，所有節點，cmt.xml
注意，這裡面的nsX與core-site.xml中的nsX對應。而且對每個NS，你都可以建立多個虛拟路徑，映射到不同的實體路徑。與此同時，hdfs-site.xml中需要給出每個NS的具體資訊：
Federation，所有節點，hdfs-site.xml
可以看到，在隻有Federation且沒有HA的情況下，配置的name裡隻需要直接給出${NS_ID}，然後value就是實際的機器名和端口号，不需要再.${NN_ID}。
這裡有一個情況，就是NN本身的配置。從上面的内容裡大家可以知道，NN上是需要事先建立好用戶端挂載表映射的目标實體路徑，譬如/real_share，之後才能通過以上的映射進行通路，可是，如果不指定全路徑，而是通過映射+相對路徑的話，用戶端隻能在挂載點的虛拟目錄之下進行操作，進而無法建立映射目錄本身的實體目錄。是以，為了在NN上建立挂載點映射目錄，我們就必須在指令行裡使用hdfs協定和絕對路徑：
上面這個問題，我在EasyHadoop的聚會上沒有講清楚，隻是簡單的說在NN上不要使用viewfs://來配置，而是使用hdfs://，那樣是可以解決問題，但是是并不是最好的方案，也沒有把問題的根本說清楚。
最後，我們來組合HA和Federation，真正搭建出和本節開始處的測試環境示意圖一樣的執行個體。通過前面的描述，有經驗的朋友應該已經猜到了，其實HA+Federation配置的關鍵，就是組合hdfs-site.xml裡的dfs.nameservices以及dfs.ha.namenodes.${NS_ID}，然後按照${NS_ID}和${NN_ID}來組合name，列出所有NN的資訊即可。其餘配置一樣。
HA + Federation，所有節點，hdfs-site.xml
對于沒有.${NS_ID}，也就是未區分NS的項目，需要在每台NN上分别使用不同的值單獨配置，尤其是NFS位置(dfs.namenode.shared.edits.dir)，因為不同NS必定要使用不同的NFS目錄來做各自内部的HA (除非mount到本地是相同的，隻是在NFS伺服器端是不同的，但這樣是非常不好的實踐)；而像ZK位置和隔離方式等其實大可使用一樣的配置。
除了配置以外，叢集的初始化也有一些額外的步驟，譬如，建立HA環境的時候，需要先格式化一台NN，然後同步其name.dir下面的資料到第二台，然後再啟動叢集 (我們沒有測試從單台更新為HA的情況，但道理應該一樣)。在建立Federation環境的時候，需要注意保持${CLUSTER_ID}的值，以確定所有NN能共享同一個叢集的存儲資源，具體做法是在格式化第一台NN之後，取得其${CLUSTER_ID}的值，然後用如下指令格式化其他NN：
當然，你也可以從第一台開始就使用自己定義的${CLUSTER_ID}值。
如果是HA + Federation的場景，則需要用Federation的格式化方式初始化兩台，每個HA環境一台，保證${CLUSTER_ID}一緻，然後分别同步name.dir下的中繼資料到HA環境裡的另一台上，再啟動叢集。
Hadoop 2.0中的HDFS用戶端和API也有些許更改，指令行引入了新的hdfs指令，hdfs dfs就等同于以前的hadoop fs指令。API裡引入了新的ViewFileSystem類，可以通過它來擷取挂載表的内容，如果你不需要讀取挂載表内容，而隻是使用檔案系統的話，可以無視挂載表，直接通過路徑來打開或建立檔案。代碼示例如下：
六、HA測試方案和結果
Federation的測試主要是功能性上的，能用就OK了，這裡的測試方案隻是針對HA而言。我們設計了兩個次元的測試矩陣：系統失效方式，用戶端連接配接模型
系統失效有兩種：
終止NameNode程序：ZKFC主動釋放鎖
模拟機器OOM、死鎖、硬體性能驟降等故障
NN機器掉電：ZK鎖逾時
模拟網絡和交換機故障、以及掉電本身
用戶端連接配接也是兩種：
已連接配接的用戶端(持續拷貝96M的檔案，1M每塊)
通過增加塊的數目，我們希望用戶端會不斷的向NN去申請新的塊；一般是在第一個檔案快結束或第二個檔案剛開始拷貝的時候使系統失效。
新發起連接配接的用戶端(持續拷貝96M的檔案，100M每塊)
因為隻有一個塊，是以在實際拷貝過程中失效并不會立刻導緻用戶端或DN報錯，但下一次新發起連接配接的用戶端會一開始就沒有NN可連；一般是在第一個檔案快結束拷貝時使系統失效。
針對每一種組合，我們反複測試10－30次，每次拷貝5個檔案進入HDFS，因為時間不一定掐的很準，是以有時候也會是在第三或第四個檔案的時候才使系統失效，不管如何，我們會在結束後從HDFS裡取出所有檔案，并挨個檢查檔案MD5，以確定資料的完整性。
測試結果如下：
ZKFC主動釋放鎖
5-8秒切換(需同步edits)
用戶端偶爾會有重試(~10%)
但從未失敗
ZK鎖逾時
15-20s切換(逾時設定為10s)
用戶端重試幾率變大(~75%)
且偶有失敗(~15%)，但僅見于已連接配接用戶端
可確定資料完整性
MD5校驗從未出錯
失敗時用戶端有Exception
我們的結論是：Hadoop 2.0裡的HDFS HA基本可滿足高可用性
擴充測試
我們另外還(試圖)測試Append時候NN失效的情形，因為Append的代碼邏輯非常複雜，是以期望可以有新的發現，但是由于複雜的那一段隻是在補足最尾部塊的時候，是以必須在測試程式一運作起來就關掉NN，測了幾次，沒發現異常情況。另外我們還使用HBase進行了測試，由于WAL隻是append，而且HFile的compaction操作又并不頻繁，是以也沒有遇到問題。
七、HA推薦配置及其他
HA推薦配置
ha.zookeeper.session-timeout.ms ＝ 10000
ZK心跳是2000
預設的5000很容易因為網絡擁塞或NN GC等導緻誤判
為避免電源閃斷，不要把start-dfs.sh放在init.d裡
dfs.ha.fencing.methods ＝ shell(/path/to/the/script)
STONITH (Shoot The Other Node In The Head)不一定可行，當沒有網絡或掉電的時候，是沒法shoot的
預設的隔離手段是sshfence，在掉電情況下就無法成功完成，進而切換失敗
唯一能保證不發生腦裂的方案就是確定原Active無法通路NFS
通過script修改NFS上的iptables，禁止另一台NN通路
管理者及時介入，恢複原Active，使其成為Standby。恢複iptables
用戶端重試機制
代碼可在org.apache.hadoop.io.retry.RetryPolicies.FailoverOnNetworkExceptionRetry裡找到。目前的用戶端在遇到以下Exception時啟動重試：
其重試時間間隔的計算公式為：
RAND(0.5~1.5) * min (2^retryies * baseMillis, maxMillis)
baseMillis = dfs.client.failover.sleep.base.millis，預設500
maxMillis = dfs.client.failover.sleep.max.millis，預設15000
最大重試次數：dfs.client.failover.max.attempts，預設15
未盡事宜
關于那15%失敗的情況，我們從日志和代碼分析，基本确認是HA裡的問題，就是Standby NN在變為Active NN的過程中，會試圖重置檔案的lease的owner，進而導緻LeaseExpiredException: Lease mismatch，用戶端遇到這個異常不會重試，導緻操作失敗。這是一個非常容易重制的問題，相信作者也知道，可能是為了lease安全性也就是資料完整性做的一個取舍吧：甯可用戶端失敗千次，不可lease配置設定錯一次，畢竟，用戶端失敗再重新建立檔案是一個很廉價且安全的過程。另外，與MapReduce 2.0 (YARN)的整合測試我們也沒來得及做，原因是我們覺得YARN本身各個元件的HA還不完善，用它來測HDFS的HA有點本末倒置。