HDFS Federation
　　　　NameNode在內存中保存文件系統中每個文件和每個數據塊的引用關系，這意味著對于一個擁有大量文件的超大集群來說，內存將成為限制系統橫向擴展的瓶頸。在2.0發行版本系列中引入的Federation HDFS允許
　　系統通過添加NameNode實現擴展，其中每個NameNode管理文件系統命名空間的一部分。在Federation環境下，每個NameNode維護一個命名空間卷（NameSpace Volume），包括命名空間的元數據和在該命名空
　　間下的文件的所有的數據塊的數據塊池。命名空間卷是相互獨立的，且互不通信，甚至其中一個NameNode失效也不會影響由其他NameNode維護的命名空間的可用性。數據塊池不在進行切分，因此集群中的DataNode
　　需要注冊到每個NameNode，并且存儲來自多個數據塊池中的數據塊。
　　　　采用Federation的最主要原因是簡單，Federation能夠快速的解決了大部分單NameNode的問題。Federation 整個核心設計實現大概用了4個月。大部分改變是在Datanode、Config和Tools，而NameNode本身的
　　改動非常少，這樣 Namenode原先的魯棒性不會受到影響。這使得該方案與之前的HDFS版本兼容。為了水平擴展NameNode，Federation使用了多個獨立的NameNode/namespace。這些NameNode之間是聯合的，
　　也就是說，他們之間相互獨立且不需要互相協調，各自分工，管理自己的區域。分布式的DataNode被用作通用的數據塊存儲存儲設備。每個DataNode要向集群中所有的NameNode注冊，且周期性地向所有NameNode
　　發送心跳和塊報告，并執行來自所有NameNode的命令。一個block pool由屬于同一個namespace的數據塊組成，每個DataNode可能會存儲集群中所有block pool的數據塊。每個block pool內部自治，也就是說各自管
　　理各自的block，不會與其他block pool交流。一個NameNode掛掉了，不會影響其他NameNode。某個NameNode上的namespace和它對應的block pool一起被稱為namespace volume。它是管理的基本單位。當一
　　個NameNode/nodespace被刪除后，其所有DataNode上對應的block pool也會被刪除。當集群升級時，每個namespace volume作為一個基本單元進行升級。??? 

HDFS High Availability
　　　　通過聯合使用在多個文件系統中備份NameNode的元數據和通過備用NameNode創建監測點能防止數據丟失，但是依舊無法實現文件系統的高可用性。NameNode依舊存在單點故障（SPOF）問題。如果NameNode
　　失效了，那么所有的客戶端包括MapReduce作業均無法讀、寫或列（list）文件，因為NameNode是唯一存儲元數據與文件到數據塊映射的地方，在這一情況下，Hadoop系統無法提供服務直到有新的NameNode上線。
　　　　在這樣的情況下，要想從一個失效的NameNode恢復，系統管理員得啟動一個擁有文件系統元數據的副本的新的NameNode，并配置DataNode和客戶端以便使用這個新的NameNode。新的NameNode直到滿足以
　　下情形才能響應服務：1）將命名空間的鏡像導入到內存中；2）重做編輯日志；3）接收到足夠多的來自DataNode的數據庫報告并推出安全模式。對于一個大型并擁有大量文件和數據塊的集群，NameNode的冷啟動需要
　　至少30分鐘甚至更長時間。如果系統恢復時間太長，也會影響到日常維護。事實上，NameNode失效的可能性非常低，所以在實際應用中計劃系統失效時間就顯得尤為重要。
　　　　在Hadoop-2.x系列發行版本中對上述問題提供了高可用性（High Availability）的支持。在這一實現中，配置了一對活動-備用（Active-Standby）的NameNode。當活動的NameNode失效，備用NameNode則會
　　接管已失效NameNode的任務并開始服務于來自客戶端的請求，不會有任何明顯的中斷。1：NameNode之間需要通過高可用的共享存儲實現編輯日志的共享。在早期的高可用實現版本中需要一個NFS
　　（Network File System）過濾器來輔助實現，但是在后續版本中提供了更多的選擇，如構建于ZooKeeper之上的BookKeeper這樣的系統。當備用的NameNode接管工作后，它將通過讀取共享編輯日志直至末尾，以實現
　　與活動的NameNode的狀態同步，并繼續讀取由活動的NameNode寫入的新條目；2：DataNode需要同時向兩個NameNode發送數據塊處理報告，因為數據塊的映射信息存儲在NameNode的內存中，而非磁盤。3：客
　　戶端需要使用特定的機制來處理NameNode的失效問題，這一機制對用戶是透明的。
　　　　在活動的NameNode失效之后，備用NameNode能快速（幾十秒的時間）實現任務接管，因為最新的狀態存儲在內存中：包括最新的編輯日志條目和最新的數據塊映射信息。實際觀察到的失效時間會長一點（需要1分
　　鐘左右），這是因為系統需要保守確定活動NameNode是否真的失效了。
　　　　在活動的NameNode失效且備用NameNode也失效的情況下，管理員依舊可以申明一個備用NameNode實現冷啟動。這類情況并不會比非高可用（no-HA）的情況更差，并且從操作的角度講這是一個進步，因為上述
　　處理已經是一個標準的處理過程并植入Hadoop中。
　　　　故障轉移與規避：一個稱為故障轉移控制器（failover_controller）的系統中有一個新實體管理著將將活動NameNode轉移為備用NameNode的轉換過程。故障轉移控制器是可插拔的，但其最初的實現是基于
　　ZooKeeper的并由此確保且僅有一個活動的NameNode。每一個NameNode運行著一個輕量級的的故障轉移控制器（DFSZKFailoverController），其工作就是監視宿主NameNode是否失效（通過一個簡單的心跳機制實
　　現）并在NameNode失效時進行故障切換。管理員也可以手動發起故障轉移，例如在進行日常維護時。這稱為“平穩的故障轉移”（故障轉移控制器會組織兩個NameNode有序切換）。在非平穩的故障轉移時，無法確切知
　　道失效NameNode是否已經停止運行。例如在網絡非常慢或網絡被分割的情況下，同樣也可能激發故障轉移，但是先前活動的NameNode依然運行著并依舊是活動的NameNode。高可用實現做了更進一步的優化以用來確
　　保先前活動NameNode不會執行危害系統并導致系統崩潰的操作，該方法稱為“規避”（fencing）。系統引入了一系列的規避機制，包括殺死NameNode進程，收回訪問共享存儲目錄的權限（通常使用供應商指定的NFS
　　命令），通過遠程管理命令以屏蔽相應網絡端口。訴諸最后的手段是先前活動NameNode可以通過一個相當形象的成為STONITH（shoot the node in the head）的技術進行規避，該方法主要通過一個特定的供電單元對相
　　應的主機進行斷電操作。客戶端的故障切換通過客戶端類庫實現透明處理。最簡單的實現是通過客戶端的配置文件實現故障切換的控制。HDFS URI使用一個邏輯主機名，該主機名映射到一對NameNode地址（在配置文件中
　　設置），客戶端類庫會訪問每一個NameNode地址，直至處理完成。
　　　　

轉載于:https://www.cnblogs.com/mengyao/p/4696348.html

總結

以上是生活随笔為你收集整理的HDFS Federation与HDFS High Availability详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。