HDFS Router-based Federation

本文講述了 HDFS Router-based Federation 的架構和特性。
上期回顧： 漫談Hbase Fil ter

Abstract

Hadoop 社區爲了解決 HDFS 橫向擴展的問題，早前的版本中實現了基於 ViewFs 的 Federation 架構，而在最新的 Hadoop 版本中，社區又實現了基於 Router 的 Federatio n架構，而且在這個架構之上還實現了許多加強集羣管理能力的特性。Router 將掛載表從 Client 中抽離了出來，解決了掛載表不一致的問題，本篇文章就會介紹 HDFS Router-based Federation 的架構和特性。

Background

在 HDFS 單集羣的架構中，隨着集羣規模的擴大，Block Manager 和Namespace 會消耗掉 NameNode 愈來愈多的資源，最終致使NameNode 難以提供可靠的服務。因而就提出了 Federation 架構。

Federation 架構是指由多個子集羣聯合構成一個 Federation 集羣，一般的作法是這些子集羣會共享 Datanode.而後由掛載表來維護Federation Namespace 到子集羣 Namespace 間的映射關係，這個掛載表存在客戶端本地的配置文件裏，由客戶端來解析從而訪問到正確的子集羣。在社區的實現中，用了一個新的協議 viewfs:// 來訪問Federation Namespace.

小米內部對 Federation 實現作了不少優化。爲了提升用戶易用性，讓用戶配合集羣遷移，咱們儘量的對用戶屏蔽細節，實現訪問Federation 集羣和普通集羣不須要用戶修改代碼甚至配置，

• 對社區的 ViewFs 增長了一層封裝，改用本來的 hdfs:// 協議

• 掛載表存儲在 Zookeeper 集羣中，客戶端週期性的檢查掛載表是否有更新

• 實現了 Federation 集羣中不一樣子集羣間的 rename 操做

可是 Federation 架構也帶來了一些問題，

• 掛載表是由客戶端實現，修改代碼邏輯須要考慮新老客戶端的兼容性並分發新的客戶端

• 在實現子集羣 Namespace 的 Rebalance 時，難以保證全部客戶端同步更新到新的掛載表

因而，社區提出了新的 Federation 架構：Router-based Federation

Router

爲了對用戶屏蔽 Federation 的實現細節，將掛載表的配置和實現從客戶端中剝離出來，一個天然的想法引入新的代理服務，客戶端直接請求代理服務，再由其解析掛載表後將請求轉發給正確的子集羣。咱們將這個代理服務叫作 Router.

Router Rpc Forwarding

咱們首先來看 Router 是如何代理轉發RPC的。

圖中標識的是調用關係。Router 會啓動 RouterRpcServer 服務，這個類和 NameNodeRpcServer 同樣實現了 ClientProtocol,也就是說 Client 不須要改實現，就能夠把 Router 看成 Namenode 來訪問。固然，Router 也實現了其餘的協議用以管理員來管理 Router 或集羣狀態。
Router 在經過 RouterRpcServe 收到 RPC 後，顯示經過解析掛載表獲得對應的子集羣和其路徑，再經過 ConnectionManager 構造出對應NameNode 的 RPC Client,利用 Client 轉發這個 RPC.
ConnectionManager 維護了一組鏈接池，每一個 RPC 的UserGroupInformation,NameNode Address 和 Protocol 共同構成了鏈接池的 Key.鏈接池在構造時會建立必定數量的 RPC Client,隨後對於每個過來的 RPC,在鏈接池裏找一個空閒的 RPC Client 用以發送RPC.當空閒的 RPC Client 不夠時，由後臺的 Creator 線程異步的構造新的鏈接，同時有後臺的 Cleaner 線程負責清理鏈接池。

Router 如何代理用戶的信息將在後面的 Router Security 章節說明。

MountTableResolver

在 Router 中，每一條 Federation Namespace 到子集羣 Namespace的映射對應一個 MountTable,全部的 MountTable 就是集羣的掛載表。在 MountTableResolver 中，由類型爲 TreeMap<String, MountTable>的成員來管理，Key 爲 Federation Namespace 下的路徑，Value 爲對應的MountTable.在解析的時候，會從這個路徑向它的父目錄找最近的掛載點，也就是最長匹配，這一點和社區本來的 ViewFs 的實現不一樣，Router 支持了嵌套掛載表。

社區還實現了一個支持把一個路徑掛在多個集羣下的 Resolver,它能夠根據指定的規則例如一致性哈希來決定把子目錄映射到哪一個子集羣上。
掛載表由管理員經過命令來設定，可是爲了讓全部的 Router 都能讀到最新的掛載表，以及 Router 重啓後不須要從新設定掛載表，這個掛載表應該持久化存在哪裏呢？

State Store

爲了更方便的管理 Router 的配置和狀態，咱們引入了 State Store,這是對於咱們存儲 Router 狀態的存儲服務的一個抽象，目前社區有基於文件系統和基於 Zookeeper 的兩種實現。

負責與 State Store 通訊的是 StateStoreDriver,定義了一些基本的GET/PUT 接口，由 StateStoreConnectionMonitorService 維護。StateStoreService 是 Router 管理 State Store 的服務，負責從 State Store 拉取數據，更新註冊進來的 RecordStore 的緩存。在 State Store 上存儲的叫作Record,目前只有基於 protobuf 的序列化實現。
舉例來講，上面咱們提到的掛載表就是一個 RecordStore 的實現，每條 Mount Table 就是一個 Record,他們被 protobuf 序列化後存儲在State Store 上。

Router Security

有了上面的架構，Router 就能夠做爲一個無狀態的代理層來工做了。但是 Client 再也不直接與NameNode通訊，非 RBF 集羣的安全認證方案就失效了，因此就有了 Router 層的安全認證方案。

HDFS實踐中用到的認證方案有兩個，Kerberos 和 Delegation Token，這兩種是針對不一樣應用同時在使用的。
咱們先來看 Kerberos 如何在 Router 層實現。

顯然，咱們能夠將 Router 做爲 Service 註冊到 Kerberos，由 Router來認證 Client.同時，Router 由做爲 HDFS 的超級用戶來代理 Client 的用戶信息，在代碼中能夠這樣簡單的實現

UserGroupInformation routerUser = UserGroupInformation.getLoginUser();
connUGI = UserGroupInformation.createProxyUser(    
    ugi.getUserName(), routerUser);複製代碼

Delegation Token 相對就沒這麼容易實現了。

按照社區如今的實現，是由 Router 來構造 Delegation Token,認證Client.爲了讓全部的 Router 能同步已構造的 Delegation Token,須要將其存到 State Store 來讓 Router 間進行同步。這樣作的好處實現簡單，不須要和全部的 NameNode 進行通訊就能夠在 Route r層完成認證。壞處是須要 Router 間進行同步，這可能會致使性能問題，以及因爲 Zookeeper 並不是保證強一致性，Router 可能會讀不到另外一個 Router構造的 Delegation Token,結果 Client 認證失敗。

Other Features

在這樣的架構下，社區還實現了不少有趣的特性

• 掛載表上能夠設置權限

• 聚合 Quota.因爲一個掛載表下的子目錄能夠掛在不一樣的子集羣上，因此就須要聚合 Quota 來管理全部子集羣上的 Quota.

• Disabled Namespace.

Community Practice

社區的 RBF 架構圖以下

在社區文檔中提到的推薦實踐是，在每個 NameNode 的機器上啓動一個 Router 服務，State Store 是 Zookeeper 實現，掛載表的映射關係中 Federation Namespace 和子集羣 Namespace 上的路徑相同。

Future Works

• 基於 Zookeeper 可能會致使 Delegation Token 認證失敗，因此咱們須要調用同步接口，或者換用強一致性的存儲，例如etcd.

• Router 對 NameNode 隱藏了 Clien t的 ip.Router 應該將 RPC上下文也發給 NameNode,使其能在 Audit Log 裏記錄 Client 正確的信息。

• Rebalance.社區沒有實現跨子集羣的遷移，可是小米內部實現了跨子集羣的 Federation Rename,咱們能夠在將來將這一特性合併到社區的 Rebalance 方案中。

本文首發於公衆號「小米雲技術」，轉載請註明出處爲公衆號：小米雲技術，ID：mi-cloud-tech。原文連接：HDFS Router-based Federation