cloudera產品高可用性配置說明

簡 了解高可用性架 高可用性設計概 處理HDFS命名空間的更 SharedEdits 的機 為共享使用 為共享使用QuorumJournal QuorumJournalManager的功 QuorumJournalManager設計概 發(fā)送塊位置信息到 和NameNode的客戶端通 NameNode故障恢 人工故障恢 自動故障恢 通過防止腦裂現(xiàn) FencingoftheSharedEditDirectoryona FencingoftheSharedEditDirectoryin 設置高可用性的要 設置高可用 使用QuorumJournalManager進行共享.....................................................................................配置CDH其他組件使用HDFS高可用 配置HiveMetastore使用HDFS高可用 配置Hue使用HDFS高可用 配置Impala使用HDFS高可用 參 簡介ApacheHadoop*集群中通常有多個用戶長時間地運行多個作業(yè)。這些作業(yè)生成的數(shù)據(jù)分析PrimaryNameNode的單點故障。如果其中一個服務失敗，本文將介紹如何為Cloudera產品設置高可用性。了解高可用性架構高可用性功能支持PrimaryNameNodeactive-standby配置。這表示Primary會被激活。PrimaryNameNode的冗余對象被稱為StandbyNameNode。PrimaryNameNode負責集群中的HDFS操作，比如從HDFS文件并寫入文件到HDFS。StandbyNamenode的作用是HDFS集群的狀態(tài)，以便提供熱備份。熱備份是指高可用性設計概述PrimaryNameNode編輯日志到一個名為SharedEdits的特定 NameNode對此 構。這意味著對PrimaryNameNode命名空間做出的任何更改都將被到StandbyNameNode名空間。HDFS命名空間的更改旦編輯日志更改成功，PrimaryNameNode的文件系統(tǒng)結構的內存中信息將被更新。StandbyNameNode文件系統(tǒng)結構必須和PrimaryNameNode的文件系統(tǒng)結構完全相同。這意味著StandbyNamenode必須對PrimaryNameNode的編輯日志有讀的權限。高可用性設計使用sharededits 是PrimaryNameNode ，也是StandbyNameNode編輯日志的 NameNode使用編輯日志中的信息來更新HDFS命名空間的內存中信息。此外，StandbyNameNode不可改動編輯日志，只能。通過這些操作，StandbyNameNode確保了HDFS文件結構會一直和Primary NameNode保持一致。如果發(fā)生故障切換，StandbyNameNode將確認在激活前它已所有編輯日志中的信息并更新了命名空間。因此，StandbyNameNode在成為PrimaryNameNode之前，它名空間將保持和PrimaryNameNode同步。Edits 的機制SharedEdits 必須可被二個NameNode，且都對此 外，NameNode必須能不間斷地讀／寫此 ，且二個NameNode都能一直同樣的數(shù)據(jù)。高可用性HDFS支持以下二種NameNodeSharedEdits 網絡文件共享QuorumJournal為共享使用SharedEdits ，即NFS掛載NameNode的服務器。你可能只有一個SharedEdits 則HDFS客戶端將不能寫入數(shù)據(jù)到HDFS。因此，SharedEdits 高可用、高質量的NAS設備。為共享使用QuorumJournalSharedEditsNFS上是可被接受的方式，這通常也符合公司現(xiàn)存的整體架構。但是，對有些組織來說，NFS掛載選項可能造成以下問題。SharedEditsNAS設備上。NAS設備通常很昂貴，而且要求特別的設備用于和操作。操作、實施和管理—除了部署HDFS外，NFS掛載還要求額外的配置、和。這致HDFS不能工作。最后，存放SharedEdits 的服務器或NAS設備將增加機構對外部設備的依賴性，這一點對管理和NameNode影響重大。NFS客戶端有很多缺陷—在Linux操作系統(tǒng)中，NFS客戶端尚有很多缺陷，且難以配置。而且，每個客戶端的具體實施可能不盡相同，也就是說，預測客戶端的行為將很，而且每個客戶端的行為都不相同。因此，將NFS客戶端掛載在SharedEdits 致錯誤，這將使得NameNode不能讀或寫該 要解決這一問題，ApacheHadoop*QuorumJournalManager（QJM）NFS選日志在集群的多個節(jié)點上。編輯日志的備份將在集群中的另一個節(jié)點上變?yōu)榭捎?。QJM集群中允許失敗且失敗后可繼續(xù)提供服務的節(jié)點數(shù)量根據(jù)以下算法計算：(N-1)/2無需特殊硬件或外部依賴—NFS通常要求有NAS設備，這一選項對硬件或服務無特殊要求。QuorumJournalManager可部署在部署了饢的同一標準硬件上。實際操作中，推薦將QuorumJournalManager安裝在已安裝饢軟件的同一節(jié)點上。QuorumJournalManager可定義集群中的故障恢復節(jié)點數(shù)。網絡延遲將影響所有節(jié)點—QuorumJournalManager集群點的編輯日志數(shù)據(jù)的不會影響對編輯日志數(shù)據(jù)的讀／寫速度。而且，增加要編輯日志數(shù)據(jù)的節(jié)點數(shù)會在NameNode數(shù)據(jù)時造成網絡延遲。QuorumJournalManager應用程序包含由數(shù)個節(jié)點組成的集群，HDFS編輯日志在每個節(jié)點上。在QuorumJournalManagerJournalNode。QuorumJournalManager使用分編輯HDFS編輯日志。NameNode是消耗QuorumJournalManager資源的客戶端。每個NameNode上都運行進行寫入編輯操作。QJM在多數(shù)節(jié)點返回成功消息后，將認為寫入編輯已成功。一旦集群確認編輯完成，編輯日志的某一部分可能只能從QuorumJournalManager集群。因此，StandbyNameNode可使用QJM來集群中任何節(jié)點上的編輯日志數(shù)據(jù)，并確保該數(shù)據(jù)和集群中其他的數(shù)據(jù)完全一致。發(fā)送塊位置信息到塊位置信息。在HDFS中，DataNode負責向NameNode周期性報告在其中的快信息。NameNode不負責也不編輯日志的塊位置信息。因此，高可用性設計中將通過改變DataNode報告塊信息的方式來完成這一點。在高可用性配置中，PrimaryNameNodeStandbyNameNode的網絡地址在每個節(jié)點的NameNode。但是，DataNodePrimaryNameNode發(fā)出NameNode的客戶端通信HDFSNameNodeactive-active配置模式。這表示在任何時候，只能有和active狀態(tài)的NameNode通訊，客戶端將會：NameNode，客戶端需要嘗試和另一個NameNode通信。一個NameNode建立通信。NameNode人工故障恢復HDFS集群中，管理員可使用以下新命令：hdfshaadmin-failover的子命令。failover子命令有二個額外的參數(shù)。第一個參數(shù)是當前active狀態(tài)的復嘗試從PrimaryNameNode切換到StandbyNameNode。自動故障恢復HDFSactive狀態(tài)ZooKeeperApacheZooKeeper(ZK)*是一個高可用性協(xié)調服務，用于分布式應用程序的狀態(tài)、進程和配置數(shù)據(jù)。ZooKeeperquorum是ZooKeeper集群中的一組節(jié)點，用來單個應用程序的數(shù)據(jù)。在高可用性自動故障恢復中，ZooKeeperquorum提供以下功能：探測NameNode—每個NameNode的狀態(tài)在ZKquorum都作為持續(xù)進程進行。如果有NameNode進入無法提供服務的狀態(tài)，則ZK進程將失效，并通知另一NameNode此狀態(tài)。如果無法提供服務的NameNode之前為active狀態(tài)，則其他NameNode將觸發(fā)故障恢復，使自己成為active狀態(tài)的節(jié)點。NameNode—NameNodeactive狀態(tài)的，當前activeNameNodeZKquorumNameNode中哪非active或active。activeNameNode進入非服務狀態(tài)（OOS），NameNode觸發(fā)故activeNameNodeStandbyNameNodeZK鎖然后成為狀態(tài)—定期發(fā)送心跳到NameNode，以檢查NameNode是否運行狀態(tài)良好。如果NameNode沒有在一定的時間內返回信息或返回的狀態(tài)為非良好狀態(tài)，則ZKFC將認為NameNode狀態(tài)錯誤。ZooKeeper—ZKFCNameNodeZKFC將在ZKquorum中對此一個持續(xù)進程。此進程表示NameNode狀態(tài)良好且可用。如果NameNodeactiveactiveZK鎖將被釋放。ActiveNameNode—ZKFCNameNode運行狀態(tài)良好，且其他ZKFC必須觸發(fā)一個故障恢復以使得NameNodeactiveNameNode。通過防止腦裂現(xiàn)高可用性HDFS不支持雙機熱配置，也就是說，同一時間內只有一個NameNode可成為對方快速分離。如果HDFS結構分離，則很有可能HDFS上的數(shù)據(jù)會丟失或損壞。而且，HDFSNameNodeNameNode返回的結果可能和另一個NameNode返回的結果明顯不同。HDFS為例，這意味這二個NameNode都認為自己是active狀態(tài)的節(jié)點，其他節(jié)點是StandbyNameNodeHDFS中沒有數(shù)據(jù)丟失、損壞或不一致，防止腦裂現(xiàn)象在集群中，進程用于將工作不正常的服務孤立起來，以防止該服務共享資源。在高HDFS中，進程發(fā)生在NameNodeactiveNameNode會驗證之前為activeNameNode將不能編輯HDFS命名空間。FencingoftheSharedEditDirectoryonaactiveNameNodeactiveNameNodeactive操作將嘗試找到并終止之前為active狀態(tài)的NameNode服務，從而防止之前為active狀態(tài)的NameNodeSharedEdits FencingoftheSharedEditDirectoryinQJM上的，它不需要額外的或特別的硬件和軟件。在QJM中，NameNode更改編輯日志，當NameNode成為active時，QJM將會被分配一個號（epochnumber）。號同時在QJM和所有的JournalNode上要生成號，NameNode的QJM從所有的JournalNode上獲取號。QJM將找出最高的號，加上1，結果即為新的號。QJMJN可決定寫入者比之前的寫入者新還是舊。如對于另一個NameNode，被認為是新的寫入者。QJM通過以下方式使用號在NameNode被允許更改編輯日志前，QJM必須已被成功分配號間第一次被格式化后，第一個active狀態(tài)的NameNode將被分配號1。任何故障恢復都將導致號的增加。在號被成功分配給QJM前，QJM必須發(fā)送號到集群中的所有JournalNode上。多數(shù)JournalNode必須返回一個消息，標明號已成功收到，否則QJM將不能使用該如果QJM回應號的消息請求，它將這一號以便日后參考。無論何時行對比。如果請求中的號低于JN的號，JN將寫請求。如果請求中