《Hadoop權威指南：大數據的存儲與分析》—3.2.5 HDFS的高可用性

3.2.5? HDFS的高可用性

通過聯合使用在多個文件系統中備份namenode的元數據和通過備用namenode創建監測點能防止數據丟失，但是依舊無法實現文件系統的高可用性。namenode 依舊存在單點失效(SPOF, single point of failure)的問題。如果namenode失效了，那么所有的客戶端，包括MapReduce作業，均無法讀、寫或列舉(list)文件，因為namenode是唯一存儲元數據與文件到數據塊映射的地方。在這一情況下，Hadoop系統無法提供服務直到有新的namenode上線。

在這樣的情況下，要想從一個失效的namenode恢復，系統管理員得啟動一個擁有文件系統元數據副本的新的namenode，并配置datanode和客戶端以便使用這個新的namenode。新的namenode直到滿足以下情形才能響應服務：(1)將命名空間的映像導入內存中；(2)重演編輯日志；(3)接收到足夠多的來自datanode的數據塊報告并退出安全模式。對于一個大型并擁有大量文件和數據塊的集群，namenode的冷啟動需要30分鐘，甚至更長時間。

系統恢復時間太長，也會影響到日常維護。事實上，預期外的namenode失效出現概率很低，所以在現實中，計劃內的系統失效時間實際更為重要。

Hadoop2針對上述問題增加了對HDFS高可用性(HA)的支持。在這一實現中，配置了一對活動-備用(active-standby) namenode。當活動namenode失效，備用namenode就會接管它的任務并開始服務于來自客戶端的請求，不會有任何明顯中斷。實現這一目標需要在架構上做如下修改。

namenode之間需要通過高可用共享存儲實現編輯日志的共享。當備用namenode接管工作之后，它將通讀共享編輯日志直至末尾，以實現與活動namenode的狀態同步，并繼續讀取由活動namenode寫入的新條目。

datanode需要同時向兩個namenode發送數據塊處理報告，因為數據塊的映射信息存儲在namenode的內存中，而非磁盤。

客戶端需要使用特定的機制來處理namenode的失效問題，這一機制對用戶是透明的。

輔助namenode的角色被備用namenode所包含，備用namenode為活動的namenode命名空間設置周期性檢查點。

可以從兩種高可用性共享存儲做出選擇：NFS過濾器或群體日志管理器(QJM，quorum journal manager)。QJM是一個專用的HDFS實現，為提供一個高可用的編輯日志而設計，被推薦用于大多數HDFS部署中。QJM以一組日志節點(journal node)的形式運行，每一次編輯必須寫入多數日志節點。典型的，有三個journal節點，所以系統能夠忍受其中任何一個的丟失。這種安排與ZooKeeper的工作方式類似，當然必須認識到，QJM的實現并沒使用ZooKeeper。(然而，值得注意的是，HDFS HA在選取活動的namenode時確實使用了ZooKeeper技術，詳情參見下一章。)

在活動namenode失效之后，備用namenode能夠快速(幾十秒的時間)實現任務接管，因為最新的狀態存儲在內存中：包括最新的編輯日志條目和最新的數據塊映射信息。實際觀察到的失效時間略長一點(需要1分鐘左右)，這是因為系統需要保守確定活動namenode是否真的失效了。

在活動namenode失效且備用namenode也失效的情況下，當然這類情況發生的概率非常低，管理員依舊可以聲明一個備用namenode并實現冷啟動。這類情況并不會比非高可用(non-HA)的情況更差，并且從操作的角度講這是一個進步，因為上述處理已是一個標準的處理過程并植入Hadoop中。

系統中有一個稱為故障轉移控制器(failover controller)的新實體，管理著將活動namenode轉移為備用namenode的轉換過程。有多種故障轉移控制器，但默認的一種是使用了ZooKeeper來確保有且僅有一個活動namenode。每一個namenode運行著一個輕量級的故障轉移控制器，其工作就是監視宿主namenode是否失效(通過一個簡單的心跳機制實現)并在namenode失效時進行故障切換。

管理員也可以手動發起故障轉移，例如在進行日常維護時。這稱為“平穩的故障轉移”(graceful failover)，因為故障轉移控制器可以組織兩個namenode有序地切換角色。

但在非平穩故障轉移的情況下，無法確切知道失效namenode是否已經停止運行。例如，在網速非常慢或者網絡被分割的情況下，同樣也可能激發故障轉移，但是先前的活動namenode依然運行著并且依舊是活動namenode。高可用實現做了更進一步的優化，以確保先前活動的namenode不會執行危害系統并導致系統崩潰的操作，該方法稱為“規避”(fencing)。

同一時間QJM僅允許一個namenode向編輯日志中寫入數據。然而，對于先前的活動namenode而言，仍有可能響應并處理客戶過時的讀請求，因此，設置一個SSH規避命令用于殺死namenode的進程是一個好主意。當使用NFS過濾器實現共享編輯日志時，由于不可能同一時間只允許一個namenode寫入數據(這也是為什么推薦QJM的原因)，因此需要更有力的規避方法。規避機制包括：撤銷namenode訪問共享存儲目錄的權限（通常使用供應商指定的NFS命令）、通過遠程管理命令屏蔽相應的網絡端口。訴諸的最后手段是，先前活動namenode可以通過一個相當形象的稱為“一槍爆頭”STONITH，shoot the other node in the head)的技術進行規避，該方法主要通過一個特定的供電單元對相應主機進行斷電操作。

客戶端的故障轉移通過客戶端類庫實現透明處理。最簡單的實現是通過客戶端的配置文件實現故障轉移的控制。HDFS URI使用一個邏輯主機名，該主機名映射到一對namenode地址(在配置文件中設置)，客戶端類庫會訪問每一個namenode地址直至處理完成。

Hadoop 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。