深度解析大快DKadoop大資料運維管理平台功能

之前幾周的時間一直是在圍繞DKhadoop的運作環境搭建寫分享，有一些朋友留言索要了dkhadoop安裝包，不知道有沒有去下載下傳安裝一探究竟。關于DKHadoop下載下傳安裝基本已經講清楚了，這幾天有點空閑把大快DKM大資料運維管理平台的内容整理了一些，作為DKHadoop相配套的管理平台，是有必要對DKM有所了解的。

DKM 是DKHadoop管理平台。作為大資料平台端到端Apache Hadoop 的管理應用，DKM 對 DKH 的每個部件都提供了細粒度的可視化和控制。通過DKM ，運維人員是可以提高叢集的性能，提升服務品質，提高合規性并降低管理成本。

DKM 設計的目的是為了使得對于企業資料中心的管理變得簡單和直覺。通過DKM ，可以友善地部署，并且集中式的操作完整的大資料軟體棧。該應用軟體會自動化安裝過程，進而減少了部署叢集的時間。通過DKM 可以提供一個叢集範圍内的節點實時運作狀态視圖。同時，還提供了一個中央控制台，可以用于配置叢集。總結DKM 能夠提供的功能主要有以下幾點：

1.自動化Hadoop 安裝過程，大幅縮短部署時間；

2.提供實時的叢集概況，例如節點，服務的運作狀況；

3.提供了集中的中央控制台對叢集的配置進行更改；

4.包含全面的報告和診斷工具，幫助優化性能和使用率；

 基本功能 ： DKM的基本功能主要可以分為四大子產品：管理功能，監控功能，診斷功能和內建功能。本篇我們就先來看以下管理功能： 1、 批量部署

我們都知道Hadoop 本身是一個分布式的系統，是以在安裝時，需要對每一個節點進行元件的安裝，并且由于是開源軟體，其安裝過程相對比較複雜，Hadoop 每個元件都需要做很多的配置工作，這一點相信各位深有體會。DKH 提供了DKM 來自動化安裝部署Hadoop 。 大大縮短了Hadoop 的安裝時間，同時也簡化了安裝Hadoop 的過程。（DKHADOOP安裝步驟請參考此前分享的文章）

自動化安裝的過程如下：

1.安裝環境準備，下載下傳DKM 以及DKH 的安裝檔案，安裝JDK，yum 等基本軟體。

2.挑選一台節點，安裝DKM ，使用者隻需要啟動安裝腳本即可，通常情況下幾分鐘就能夠完成。

3.DKM 是一個web 應用，提供了基于浏覽器的界面，使用者可以通過浏覽器可視化的進行DKH的安裝部署。

4.通過DKM 界面，添加其他需要的安裝的節點，選擇要安裝的Hadoop 元件，以及每個節點承擔的角色，選擇安裝，DKM 會自動地将需要安裝的軟體分發到對應的節點，并完成安裝。

5.當所有節點的軟體都安裝完成之後，DKM 會啟動所有的服務。從上述的安裝過程可以看出DKH 的安裝主要展現兩個特點，批量化以及自動化。隻需要在其中一個節點完成，其他節點都可以進行批量化的自動安裝。

2、 叢集配置

（ 1 ） 可視化參數配置界面

Hadoop 包含許多的元件，不同的元件都包含各種各樣的配置， 并且分布于不同的主機之上。 DKM 針對這種情況提供了界面化的參數配置功能，并且能夠自動的部署到每個節點。

2 高可靠配置

DKM 對關鍵的元件使用HA部署方案，避免單點失效的發生，同時DKH 對于元件的異常錯誤提供了自動恢複處理，最大限度的保證服務的可靠性。

3 HDFS 高可靠

在标準配置中，NameNode 是HDFS群集中的單點故障（SPOF）。每個群集都具有一個NameNode ，如果機器或程序變為不可用，群集整體将變為不可用，直到NameNode 在新主機上重新啟動或上線。Secondary NameNode 不提供故障轉移功能。 為了讓“備用” NameNode 的狀态與“活動”NameNode 在此實施中保持同步，兩個節點均與一組名為JournalNode 的獨立背景程式進行通信。由“活動”NameNode 執行任何Namespace 修改時，它會持續記錄其中大部分JournalNode 的修改記錄。 “備用”NameNode 能夠從JournalNode 讀取編輯操作，并不斷監視它們以了解編輯日志發生的更改。當備用節點發現編輯操作時，它會将這些編輯應用于自己的Namespace 。在發生故障轉移時，備用節點将確定首先從JournalNode 讀取所有的編輯操作，然後才會将自己更新為“活動狀态”。這確定了再發生故障轉移之前完全同步Namespace 狀态。

為了提供快速故障轉移，備用NameNode 還需要擁有有關群集中的塊位置的最新資訊。為實作這一目的，DataNode 配置了這兩個NameNode的位置，它們會将這塊位置資訊和檢測信号發送給這兩個NameNode。

一次隻能有其中一個NameNode 處于活動狀态，這一點對于HA群集的正常運作來說至關重要。否則，Namespace 狀态會在兩者之間快速出現分歧，進而導緻資料丢失風險或其他不正确的結果。為了確定此屬性并防止所謂的“大腦分裂狀況”，JournalNode 一次隻允許一個NameNode 成為寫入程式。在故障轉移過程中，要進入“活動”狀态的NameNode 将接管JournalNode的寫入角色，這會有效地阻止其它NameNode繼續保持“活動”狀态，使得新的“活動”NameNode可以安全地繼續執行故障轉移。

DKH 預設開啟了HA . 使用者不用擔心此問題。

4 YARN 高可靠

YARN ResourceManager(RM) 負責跟蹤群集中的資源并安排應用程式（例如，MapReduce作業）。RM 高可用性（HA）功能以活動/待機 RM 對形式添加備援，以删除此單點故障。此外，在從待機RM 到活動RM 進行故障轉移時，應用程式可以從其上次檢查點狀态恢複； 例如，在MapReduce 作業中完成的map 任務不在後續的嘗試中重新運作。這樣可以在不對運作中的應用程式産生任何重要性能影響的情況下，處理以下事件：

計劃外事件，如計算機崩潰。

計劃内維護事件，如在運作ResourceManager的計算機上進行的軟體或硬體更新。

RM HA 要求Zookeeper 和HDFS 服務處于運作狀态。RM HA 通過活動-待機RM 對的方式實施。啟動時，每個RM 處于待機狀态；啟動過程，但未加載狀态。轉換到活動狀态時，RM會從指定的狀态存儲加載内部狀态，并啟動所有内部服務。 管理者（通過CLI）或通過內建的故障轉移控制器（啟用自動故障轉移時）可促進轉換為活動狀态。

DKH 預設開啟了Resource Manager HA 。使用者不需要擔心。

3、 權限管理

對系統管理者，資料庫管理者及其他管理者必須授予不同級别的管理權限。