Hadoop 2.0 NameNode HA和Federation實踐

一、背景

天雲趨勢在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之前，也有若干技術試圖解決單點故障的問題，我們在這裏做個簡短的總結
1. Secondary NameNode。它不是HA，它只是階段性的合併edits和fsimage，以縮短集羣啓動的時間。當NameNode(以下簡稱NN)失效的時候，Secondary NN並無法立刻提供服務，Secondary NN甚至無法保證數據完整性：如果NN數據丟失的話，在上一次合併後的文件系統的改動會丟失。
2. Backup NameNode (HADOOP-4539)。它在內存中複製了NN的當前狀態，算是Warm Standby，可也就僅限於此，並沒有failover等。它同樣是階段性的做checkpoint，也無法保證數據完整性。
3. 手動把name.dir指向NFS。這是安全的Cold Standby，可以保證元數據不丟失，但集羣的恢復則完全靠手動。
4. Facebook AvatarNode。Facebook有強大的運維做後盾，所以Avatarnode只是Hot Standby，並沒有自動切換，當主NN失效的時候，需要管理員確認，然後手動把對外提供服務的虛擬IP映射到Standby NN，這樣做的好處是確保不會發生腦裂的場景。其某些設計思想和Hadoop 2.0裏的HA非常相似，從時間上來看，Hadoop 2.0應該是借鑑了Facebook的做法。
5. 還有若干解決方案，基本都是依賴外部的HA機制，譬如DRBD，Linux HA，VMware的FT等等。
集羣容量和集羣性能
單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的實現方式

圖片來源： HDFS-1623 設計文檔
圖片作者： Sanjay Radia, Suresh Srinivas

在這個圖裏，我們可以看出HA的大致架構，其設計上的考慮包括：

利用共享存儲來在兩個NN間同步edits信息。
以前的HDFS是share nothing but NN，現在NN又share storage，這樣其實是轉移了單點故障的位置，但中高端的存儲設備內部都有各種RAID以及冗餘硬件包括電源以及網卡等，比服務器的可靠性還是略有提高。通過NN內部每次元數據變動後的flush操作，加上NFS的close-to-open，數據的一致性得到了保證。社區現在也試圖把元數據存儲放到BookKeeper上，以去除對共享存儲的依賴，Cloudera也提供了Quorum Journal Manager的實現和代碼，這篇中文的blog有詳盡分析：基於QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代碼分析
DataNode(以下簡稱DN)同時向兩個NN彙報塊信息。
這是讓Standby NN保持集羣最新狀態的必需步驟，不贅述。
用於監視和控制NN進程的FailoverController進程
顯然，我們不能在NN進程內進行心跳等信息同步，最簡單的原因，一次FullGC就可以讓NN掛起十幾分鍾，所以，必須要有一個獨立的短小精悍的watchdog來專門負責監控。這也是一個鬆耦合的設計，便於擴展或更改，目前版本里是用ZooKeeper(以下簡稱ZK)來做同步鎖，但用戶可以方便的把這個ZooKeeper FailoverController(以下簡稱ZKFC)替換爲其他的HA方案或leader選舉方案。
隔離(Fencing)，防止腦裂，就是保證在任何時候只有一個主NN，包括三個方面：
- 共享存儲fencing，確保只有一個NN可以寫入edits。
- 客戶端fencing，確保只有一個NN可以響應客戶端的請求。
- DataNode fencing，確保只有一個NN可以向DN下發命令，譬如刪除塊，複製塊，等等。

四、Hadoop 2.0裏Federation的實現方式

圖片來源： HDFS-1052 設計文檔
圖片作者： Sanjay Radia, Suresh Srinivas

這個圖過於簡明，許多設計上的考慮並不那麼直觀，我們稍微總結一下

多個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

<property>
    <name>dfs.nameservices</name>
    <value>ns1</value>
    <description>提供服務的NS邏輯名稱，與core-site.xml裏的對應</description>      
</property>

<property>
    <name>dfs.ha.namenodes.${NS_ID}</name>
    <value>nn1,nn3</value>
    <description>列出該邏輯名稱下的NameNode邏輯名稱</description>      
</property>

<property>
    <name>dfs.namenode.rpc-address.${NS_ID}.${NN_ID}</name>
    <value>host-nn1:9000</value>
    <description>指定NameNode的RPC位置</description>      
</property>

<property>
    <name>dfs.namenode.http-address.${NS_ID}.${NN_ID}</name>
    <value>host-nn1:50070</value>
    <description>指定NameNode的Web Server位置</description>      
</property>

以上的示例裏，我們用了${}來表示變量值，其展開後的內容大致如下：

<property>
    <name>dfs.ha.namenodes.ns1</name>
    <value>nn1,nn3</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns1.nn1</name>
    <value>host-nn1:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns1.nn1</name>
    <value>host-nn1:50070</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns1.nn3</name>
    <value>host-nn3:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns1.nn3</name>
    <value>host-nn3:50070</value>
</property>

與此同時，在HA集羣的NameNode或客戶端還需要做如下配置的改動：

HA，NameNode，hdfs-site.xml

<property>
    <name>dfs.namenode.shared.edits.dir</name>
    <value>file:///nfs/ha-edits</value>
    <description>指定用於HA存放edits的共享存儲，通常是NFS掛載點</description>
</property>

<property>
    <name>ha.zookeeper.quorum</name>
    <value>host-zk1:2181,host-zk2:2181,host-zk3:2181,</value>
    <description>指定用於HA的ZooKeeper集羣機器列表</description>
</property>

<property>
    <name>ha.zookeeper.session-timeout.ms</name>
    <value>5000</value>
    <description>指定ZooKeeper超時間隔，單位毫秒</description>
</property>

<property>
    <name>dfs.ha.fencing.methods</name>
    <value>sshfence</value>
    <description>指定HA做隔離的方法，缺省是ssh，可設爲shell，稍後詳述</description>
</property>

HA，客戶端，hdfs-site.xml

<property>
    <name>dfs.ha.automatic-failover.enabled</name>
    <value>true</value>
    <description>或者false</description>
</property>

<property>
    <name>dfs.client.failover.proxy.provider.${NS_ID}</name>
    <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    <description>指定客戶端用於HA切換的代理類，不同的NS可以用不同的代理類
        以上示例爲Hadoop 2.0自帶的缺省代理類</description>
</property>

最後，爲了方便使用相對路徑，而不是每次都使用hdfs://ns1作爲文件路徑的前綴，我們還需要在各角色節點上修改core-site.xml：

HA，所有節點，core-site.xml

<property>
    <name>fs.defaultFS</name>
    <value>hdfs://ns1</value>
    <description>缺省文件服務的協議和NS邏輯名稱，和hdfs-site裏的對應
        此配置替代了1.0裏的fs.default.name</description>      
</property>

接下來我們看一下如果單獨使用Federation，應該如何配置，這裏我們假設沒有使用HA，而是直接使用nn1和nn2組成了Federation集羣，他們對應的NS的邏輯名稱分別是ns1和ns2。爲了便於理解，我們從客戶端使用的core-site.xml和掛載表入手：

Federation，所有節點，core-site.xml

<xi:include href=“cmt.xml"/>
<property>
    <name>fs.defaultFS</name>
    <value>viewfs://nsX</value>
    <description>整個Federation集羣對外提供服務的NS邏輯名稱，
        注意，這裏的協議不再是hdfs，而是新引入的viewfs
        這個邏輯名稱會在下面的掛載表中用到</description>
</property>

我們在上面的core-site中包含了一個cmt.xml文件，也就是Client Mount Table，客戶端掛載表，其內容就是虛擬路徑到具體某個NS及其物理子目錄的映射關係，譬如/share映射到ns1的/real_share，/user映射到ns2的/real_user，示例如下：

Federation，所有節點，cmt.xml

<configuration>
    <property>
        <name>fs.viewfs.mounttable.nsX.link./share</name>
        <value>hdfs://ns1/real_share</value>
    </property>
    <property>
        <name>fs.viewfs.mounttable.nsX.link./user</name>
        <value>hdfs://ns2/real_user</value>
    </property>
</configuration>

注意，這裏面的nsX與core-site.xml中的nsX對應。而且對每個NS，你都可以建立多個虛擬路徑，映射到不同的物理路徑。與此同時，hdfs-site.xml中需要給出每個NS的具體信息：

Federation，所有節點，hdfs-site.xml

<property>
    <name>dfs.nameservices</name>
    <value>ns1,ns2</value>
    <description>提供服務的NS邏輯名稱，與core-site.xml或cmt.xml裏的對應</description>      
</property>

<property>
    <name>dfs.namenode.rpc-address.ns1</name>
    <value>host-nn1:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns1</name>
    <value>host-nn1:50070</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns2</name>
    <value>host-nn2:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns2</name>
    <value>host-nn2:50070</value>
</property>

可以看到，在只有Federation且沒有HA的情況下，配置的name裏只需要直接給出${NS_ID}，然後value就是實際的機器名和端口號，不需要再.${NN_ID}。

這裏有一個情況，就是NN本身的配置。從上面的內容裏大家可以知道，NN上是需要事先建立好客戶端掛載表映射的目標物理路徑，譬如/real_share，之後才能通過以上的映射進行訪問，可是，如果不指定全路徑，而是通過映射+相對路徑的話，客戶端只能在掛載點的虛擬目錄之下進行操作，從而無法創建映射目錄本身的物理目錄。所以，爲了在NN上建立掛載點映射目錄，我們就必須在命令行裏使用hdfs協議和絕對路徑：

hdfs dfs -mkdir hdfs://ns1/real_share

上面這個問題，我在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

<property>
    <name>dfs.nameservices</name>
    <value>ns1, ns2</value>
</property>

<property>
    <name>dfs.ha.namenodes.ns1</name>
    <value>nn1,nn3</value>
</property>

<property>
    <name>dfs.ha.namenodes.ns2</name>
    <value>nn2,nn4</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns1.nn1</name>
    <value>host-nn1:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns1.nn1</name>
    <value>host-nn1:50070</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns1.nn3</name>
    <value>host-nn3:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns1.nn3</name>
    <value>host-nn3:50070</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns2.nn2</name>
    <value>host-nn2:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns2.nn2</name>
    <value>host-nn2:50070</value>
</property>

<property>
    <name>dfs.namenode.rpc-address.ns2.nn4</name>
    <value>host-nn4:9000</value>
</property>

<property>
    <name>dfs.namenode.http-address.ns2.nn4</name>
    <value>host-nn4:50070</value>
</property>

對於沒有.${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：

hadoop namenode -format -clusterid ${CLUSTER_ID}

當然，你也可以從第一臺開始就使用自己定義的${CLUSTER_ID}值。

如果是HA + Federation的場景，則需要用Federation的格式化方式初始化兩臺，每個HA環境一臺，保證${CLUSTER_ID}一致，然後分別同步name.dir下的元數據到HA環境裏的另一臺上，再啓動集羣。

Hadoop 2.0中的HDFS客戶端和API也有些許更改，命令行引入了新的hdfs命令，hdfs dfs就等同於以前的hadoop fs命令。API裏引入了新的ViewFileSystem類，可以通過它來獲取掛載表的內容，如果你不需要讀取掛載表內容，而只是使用文件系統的話，可以無視掛載表，直接通過路徑來打開或創建文件。代碼示例如下：

ViewFileSystem fsView = (ViewFileSystem) ViewFileSystem.get(conf);
MountPoint[] m = fsView.getMountPoints();
for (MountPoint m1 : m)
    System.out.println( m1.getSrc() );

// 直接使用/share/test.txt創建文件
// 如果按照之前的配置，客戶端會自動根據掛載表找到是ns1
// 然後再通過failover proxy類知道nn1是Active NN並與其通信
Path p = new Path("/share/test.txt");
FSDataOutputStream fos = fsView.create(p);

六、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時啓動重試：

// 連接失敗
ConnectException
NoRouteToHostException
UnKnownHostException
// 連到了Standby而不是Active
StandbyException

其重試時間間隔的計算公式爲：
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有點本末倒置。

Hadoop 2.0 NameNode HA和Federation實踐

python gdal 安裝使用（Windows， python 3.6.8）

js獲取瀏覽器類型（包含IE11）

win7下安裝 python2 和python3

安裝xampp之後報錯XAMPP: Starting Apache...fail.修改端口

centos7.5安裝mysql-5.7.28 經典版

centos 7.6 安裝python2和python3

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結