1. 程式人生 > >hadoop-2.7.4-翻譯文件-QJM高可用

hadoop-2.7.4-翻譯文件-QJM高可用

HDFS高可用(QJM)

        本指南概述了HDFS高可用性(HA)功能以及如何使用Quorum Journal Manager(QJM)功能配置和管理HA HDFS叢集。

本文件假設讀者對HDFS叢集中的一般元件和節點型別有一般的瞭解。有關詳細資訊,請參閱分散式叢集部署

        本指南討論如何使用Quorum Journal Manager(QJM)配置和使用HDFS HA,以共享Active和Standby NameNodes之間的編輯日誌。有關如何使用NFS為共享儲存而不是QJM配置HDFS HA的資訊,(暫無)

        在Hadoop 2.0.0之前,NameNode在HDFS叢集中存在單點故障(SPOF)。每個叢集只有一個NameNode,如果該機器或程序變得不可用,則整個叢集將不可用,直到NameNode重新啟動或在單獨的計算機上啟動。

這兩個方面影響了HDFS叢集的總體可用性:

  • 在計算機事件(如機器崩潰)的情況下,叢集將不可用,直到操作員重新啟動NameNode。

  • 對NameNode機器上的計劃維護事件(如軟體或硬體升級),將導致叢集的宕機。

        HDFS高可用性功能,通過在一個叢集中提供兩個具有熱備份功能的,主動/被動配置可選的NameNode,來解決上述問題。

這允許在機器崩潰的情況下,快速將故障切換到新的NameNode,或者需要對叢集進行維護時,允許管理員手動啟動快速轉換。

        在典型的HA群集中,兩個單獨的機器配置為NameNodes。在任何時間點,其中一個NameNodes處於Active狀態,另一個處於Standby狀態。Active NameNode負責群集中的所有客戶端操作,而Standby只是作為從屬節點,維護足夠的狀態以便必要時提供快速故障轉移。

        為了使Standby節點保持其狀態與Active節點同步,兩個節點都與一組名為“JournalNodes”(JN)的單獨守護程式進行通訊。

當Active節點執行任何名稱空間的修改時,它可以將編輯日誌持久化記錄到這些JN叢集當中。Standby節點能夠讀取JN中的編輯日誌,並且不斷監視編輯日誌的更改。當Standby節點發現有新的編輯日誌時,它將這些編輯日誌應用於自己的namespace。當Active NameNode出現故障而需要進行狀態切換時,Standby節點必須確保它已經從JounalNodes讀取所有編輯日誌,然後再將其自身切換到Active狀態。這步操作保證namespace在進行故障轉移前完全同步。

        為了提供快速故障切換,還需要Standby節點儲存叢集中檔案塊的位置的最新資訊。為了實現這一點,每個DataNodes配置了兩個NameNodes的位置,並同時向兩者傳送檔案塊資訊和心跳資訊。

        對於HA群集的正確操作至關重要,因為一次只能有一個NameNodes處於Active狀態。否則,namespace的狀態將在兩者之間快速產生偏差,產生了資料丟失或其他非正常結果的風險。為了確保此屬性並防止所謂的“腦裂”,JournalNodes將只允許一個NameNode對其進行寫入操作。在故障切換期間,將要轉換為Active的NameNode將直接接管寫入JournalNodes的角色,這將有效地防止其他NameNode繼續處於Active狀態,從而允許新的Active節點可以安全地進行故障切換。

        為了部署HA群集,您應該準備以下內容:

  • NameNode主機 - 執行Active和Standby狀態NameNodes的計算機應採用效能相當的硬體,以及與非HA叢集中使用的硬體相當的硬體。
  • JournalNode主機 -JournalNode守護程序是相對輕量級的,所以這些守護程序可以合理地與其他Hadoop守護程序(例如NameNodes,JobTracker或YARN ResourceManager)並置在同一機器上。注意:必須至少有3個JournalNode守護程序,因為編輯日誌修改必須寫入大多數JN(大於1/2)。這將允許系統容忍單個JN的故障。您還可以執行超過3個JournalNodes,在實際中為了增加系統可以容忍的故障節點數,您應該執行奇數JN(即3,5,7等)。請注意,當使用N JournalNodes執行時,系統最多可以忍受(N-1)/ 2數量的JN故障,並繼續正常工作。

        請注意,在HA群集中,Standby NameNode還執行名稱空間狀態的檢查點任務,因此不需要在HA群集中執行Secondary NameNode,CheckpointNode或BackupNode。而且如果執行SNN,CN,BN還會產生錯誤。這一功能還支援在非HA的HDFS叢集轉化為HA叢集時重用先前專用於Secondary NameNode的硬體。


叢集部署

配置概覽

        與聯邦HDFS配置類似,HA叢集配置向後相容,允許現有的單節點NameNode配置而無需對叢集做更改。新的配置設計使叢集中所有的節點可以使用相同的配置檔案,而不需要根據節點、機器的不同而採用不同配置。

       與聯邦HDFS一樣,HA叢集使用新的名稱服務來標識可能實際上由多個HA NameNode組成的單個HDFS例項。另外,一個稱為NameNode ID的新抽象概念與HA同步引入。叢集中的每個不同的NameNode具有不同的NameNode ID來區分。為了支援所有NameNodes配置寫入同一個配置檔案,相關配置引數加入NameNode ID的字尾


配置細節

        要配置HA NameNodes,必須在[hdfs-site.xml]配置檔案中新增多個配置選項

設定這些配置的順序是不重要的,但是為dfs.nameservicesdfs.ha.namenodes選擇的值[nameservice ID]將決定隨後的關鍵字。因此,在設定其餘配置選項之前,您應該確定這些值。

  • dfs.nameservices - 這個新的名稱服務的邏輯名稱

    為此名稱伺服器選擇邏輯名稱,例如“mycluster”,並使用此邏輯名稱作為此配置選項的值。你選擇的名字是任意的。它將用於叢集中的配置和絕對HDFS路徑的許可權元件。

    注意:如果您還使用聯邦HDFS,則此配置設定還應包含其他名稱服務(HA或其他)的列表,以逗號分隔。

    <property>
      <name>dfs.nameservices</name>
      <value>mycluster</value>
    </property>
  • dfs.ha.namenodes。[nameservice ID] - nameservice中每個NameNode的唯一識別符號

    使用以逗號分隔的NameNode ID列表進行配置。DataNodes將使用它來確定叢集中的所有NameNodes。例如,如果以前使用“mycluster”作為nameervice ID,並且想要使用“nn1”和“nn2”作為NameNodes的各個ID,則可以將其配置為:

    <property>
      <name>dfs.ha.namenodes.mycluster</name>
      <value>nn1,nn2</value>
    </property>

    注意:目前,每個名稱服務最多隻能配置兩個NameNodes。

  • dfs.namenode.rpc-address。[nameservice ID]。[name node ID] - 每個要監聽的NameNode的完全限定的RPC地址

    對於以前配置的兩個NameNode ID,請設定NameNode程序的完整地址和IPC埠。請注意,這將導致兩個單獨的配置選項。例如:

    <property>
      <name>dfs.namenode.rpc-address.mycluster.nn1</name>
      <value>machine1.example.com:8020</value>
    </property>
    <property>
      <name>dfs.namenode.rpc-address.mycluster.nn2</name>
      <value>machine2.example.com:8020</value>
    </property>

    注意:如果您願意,也可以配置“ servicerpc-address ”設定。

  • dfs.namenode.http-address。[nameservice ID]。[name node ID] - 每個要監聽的NameNode的完全限定的HTTP地址

    類似於上面的rpc-address,設定兩個NameNodes的HTTP伺服器進行監聽的地址。例如:

    <property>
      <name>dfs.namenode.http-address.mycluster.nn1</name>
      <value>machine1.example.com:50070</value>
    </property>
    <property>
      <name>dfs.namenode.http-address.mycluster.nn2</name>
      <value>machine2.example.com:50070</value>
    </property>

    注意:如果您啟用了Hadoop的安全功能,您還應該為每個NameNode 設定類似https地址

  • dfs.namenode.shared.edits.dir - 定義一個包括JN節點的URI物件,用來標識NameNodes將寫/讀編輯日誌的位置。

    這是個配置提供了共享編輯儲存的JournalNodes地址,由Active NameNode寫入並由Standby NameNode讀取,以儲存Active NameNode所做的所有檔案系統更改的最新資訊。雖然您必須指定多個JournalNode地址,但只能配置一個URIURI應具有以下格式:qjournal:// * host1:port1 *; * host2:port2 *; * host3:port3 * / * journalId *。Journal ID應該為此名稱服務的唯一識別符號,允許單個JournalNodes集合為多個聯合名稱系統提供儲存。雖然這麼做不是必須的,但是對於日誌識別符號來說,重用名稱服務的ID是個好主意。

    例如,如果此群集的JournalNodes在機器“node1.example.com”,“node2.example.com”和“node3.example.com”上執行,並且名稱服務ID為“mycluster”,則將使用以下作為此設定的值(JournalNode的預設埠為8485):

    <property>
      <name>dfs.namenode.shared.edits.dir</name>
      <value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
    </property>
  • dfs.client.failover.proxy.provider。[nameservice ID] - HDFS客戶端用於連線Active NameNode的Java類

    配置將由DFS客戶端使用的Java類的名稱來確定哪個NameNode是當前的Active,因此來確定哪個NameNode當前正在為客戶端請求提供服務。Hadoop當前唯一的實現是ConfiguredFailoverProxyProvider,除非您使用自行定義的java類,否則應採用如下配置:

    <property>
      <name>dfs.client.failover.proxy.provider.mycluster</name>
      <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
    </property>
  • dfs.ha.fencing.methods - 在故障轉移期間將用於隔離Active NameNode的指令碼或Java類的列表。

    它將被用於保證系統的正確性,及在任何時間僅存在一個Active Namenode。重要的是,當使用Quorum Journal Manager時,只有一個NameNode將被允許寫入JournalNodes,所以不會導致檔案系統元資料的破壞,及裂腦現象。但是,發生故障轉移時,以前的Active NameNode可能會向客戶端提供讀取請求,這可能是過期的,直到該NameNode在嘗試寫入JournalNodes時關閉。因此,即使使用Quorum Journal Manager,仍然需要配置一些防護方法。但是,為了提高系統在防護機制發生故障時的可用性,建議配置防護方法,保證將其作為列表中最後的防護方法返回true。注意,如果您選擇不使用實際的防護方法,您仍然必須為此設定配置一些內容,例如“ shell(/ bin / true) ”。

    在故障切換期間使用的防護方法被配置為使用回車符分隔的列表,它將按順序嘗試,直到一個指示隔離成功。Hadoop有兩種方法:shellsshfence有關實現自己的定製隔離方法的資訊,請參閱org.apache.hadoop.ha.NodeFencer類。


    sshfence - SSH到Active NameNode並終止程序

    sshfence選項SSHes到目標節點,並使用fuser命令殺死程序監聽服務的TCP埠上。為了使這個隔離選項工作,它必須能夠SSH到目標節點而不提供密碼。因此,還必須配置dfs.ha.fencing.ssh.private-key-files選項,該選項是以逗號分隔的SSH私鑰檔案列表。例如:

    <property>
      <name>dfs.ha.fencing.methods</name>
      <value>sshfence</value>
    </property>
    
    <property>
      <name>dfs.ha.fencing.ssh.private-key-files</name>
      <value>/home/exampleuser/.ssh/id_rsa</value>
    </property>

    或者,可以配置非標準使用者名稱或埠來執行SSH。也可以為SSH配置超時時間(以毫秒為單位),之後該防護方法將被認為失敗。它可以像這樣配置:

    <property>
      <name>dfs.ha.fencing.methods</name>
      <value>sshfence([[username][:port]])</value>
    </property>
    <property>
      <name>dfs.ha.fencing.ssh.connect-timeout</name>
      <value>30000</value>
    </property>

    shell - 執行一個任意的shell命令來隔離Active NameNode

    所述shell隔離方法可以執行任意的shell指令碼。它可以像這樣配置:

    
           
    <property>
      <name>dfs.ha.fencing.methods</name>
      <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
    </property>

    '('和')'之間的字串會直接傳遞給bash shell,並且不能包含任何括號。

    該shell命令所執行的環境將包含所有當前的Hadoop配置變數,將會使用 '_' 替換hadoop配置變數中所有的 '.' 字元所使用的配置檔案已經從指定的NameNode通用配置中提取出了所有配置資訊 - 例如,dfs_namenode_rpc-address將包含目標節點的RPC地址,即使該配置可以將該變數指定為dfs.namenode.rpc-address.ns1 .nn1

    另外,還可以使用下列參考要隔離的目標節點的變數:

       
    $ target_host 要隔離的節點的主機名
    $ target_port 要隔離的節點的IPC埠
    $ TARGET_ADDRESS 要隔離的主機:埠
    $ target_nameserviceid 要隔離的NN的名稱服務ID
    $ target_namenodeid 要隔離的NN的namenode ID

    這些環境變數也可以用作shell命令本身的替代。例如:

    <property>
      <name>dfs.ha.fencing.methods</name>
      <value>shell(/path/to/my/script.sh --nameservice=$target_nameserviceid $target_host:$target_port)</value>
    </property>

    如果shell命令返的退出程式碼為0,則確定隔離是成功的。如果它返回任何其他退出程式碼,則隔離不成功,並且將嘗試列表中的下一個隔離方法。

    注意:此隔離方法不會執行任何超時。如果超時是必要的,它們應該在shell指令碼本身中實現(例如,通過在幾秒鐘內分割子shell來殺死其父程序)。


  • fs.defaultFS - 當沒有給出Hadoop FS客戶端時使用的預設路徑字首。

    或者,您現在可以配置Hadoop客戶端使用新的啟用HA的邏輯URI。如果您以前使用“mycluster”作為名稱服務ID,則它將是所有HDFS路徑中的一部分。core-site.xml檔案中可以這樣配置

    <property>
      <name>fs.defaultFS</name>
      <value>hdfs://mycluster</value>
    </property>
  • dfs.journalnode.edits.dir - JournalNode守護程序儲存其本地狀態的路徑

    這是JournalNode機器上的絕對路徑,來儲存JN的編輯日誌和其他本地狀態。您只能使用單一路徑進行此配置。通過執行多個單獨的JournalNodes或通過在本地連線的RAID陣列上配置此目錄來提供此資料的冗餘。例如:

    <property>
      <name>dfs.journalnode.edits.dir</name>
      <value>/path/to/journal/node/local/data</value>
    </property>


部署細節

完成所有必要的配置選項後,必須在對應的的機器上啟動JournalNode守護程式。這可以通過執行命令“ hadoop-daemons.sh start journalnode ”並等待守護程序在每個相關的機器上啟動,或者ssh登入到指定機器啟動單一的journalnode程序“ssh exp hadooop-daemon.sh start journalnode”。

一旦JournalNodes啟動,必須​​首先同步兩個HA NameNodes的磁碟元資料。

  • 如果要啟用新的HDFS群集,則應首先在其中一個NameNode上執行format命令(hdfs namenode -format)(之後啟動該NameNode)。

  • 如果您已經格式化了NameNode,或者將非HA叢集轉換為HA叢集,則現在應該在未格式化的NameNode節點通過執行命令“ hdfs namenode -bootstrapStandby ”命令將已啟動NameNode元資料目錄的內容複製到該未格式化的NameNode當中執行此命令還將確保JournalNodes(由dfs.namenode.shared.edits.dir配置)包含足夠的編輯事務以能夠啟動兩個NameNodes。

  • 如果將非HA NameNode轉換為HA NameNode,則應執行命令“ hdfs namenode -initializeSharedEdits ”,該命令將使用本地NameNode編輯目錄中的編輯日誌初始化JournalNodes。

此時,您可以像正常啟動NameNode一樣啟動兩個HA NameNodes。

您可以通過瀏覽其配置的HTTP地址分別訪問每個NameNodes的web-ui。您應該注意,配置的地址旁邊將是NameNode的HA狀態(“standby”或“active”)。每當HA NameNode啟動時,它的初始狀態都是standby。


管理命令

現在,您的HA名稱節點已配置並啟動,您將可以訪問一些其他命令來管理HA HDFS叢集。具體來說,您應該熟悉“ hdfs haadmin ”命令的所有子命令。執行此命令而沒有任何其他引數將顯示以下使用資訊:

用法:haadmin
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-checkHealth <serviceId>]
    [-help <command>]

本指南介紹了每個子命令的高階使用。對於每個子命令的具體使用資訊,應執行“ hdfs haadmin -help <command >”。

  • transitionToActive transitionToStandby - 將給定NameNode的狀態轉換為Active或Standby

    這些子命令會使給定的NameNode轉換到Active或Standby狀態。這些命令不會嘗試執行任何隔離方法,因此很少使用我們通常偏向於使用“ hdfs haadmin -failover ”子命令來控制NameNode的狀態轉換而非前者。

  • failover - 在兩個NameNodes之間啟動故障轉移

    此子命令啟動故障轉移,從第一個NameNode切換到第二個NameNode。如果第一個NameNode處於standby狀態,則該命令只會將第二個狀態轉換為active狀態,而不會出現錯誤。如果第一個NameNode處於活動狀態,則會嘗試將其正常地轉換到standby狀態。如果轉換失敗,將按順序嘗試隔離方法(由dfs.ha.fencing.methods配置),直到轉換成功。只有在此過程之後,第二個NameNode才會轉換到活動狀態。如果沒有隔離方法成功,則第二個NameNode將不會轉換到活動狀態,並返回錯誤。

  • getServiceState - 確定給定的NameNode的執行狀態,active或者standby

    連線到提供的NameNode以確定其當前狀態,將“standby”或“active”適當地列印到標準輸出。計劃任務或監視指令碼可能會使用此子命令,這些指令碼需要基於NameNode當前處於活動狀態或待機狀態而執行不同的操作。

  • checkHealth - 檢查給定NameNode的健康狀況

    連線到指定的NameNode以檢查其執行狀況。NameNode能夠對其自身執行一些診斷,包括檢查內部服務是否按預期執行。如果NameNode是健康的,則此命令將返回0,否則返回非零值。可以使用此命令達到監控目的。

    注意:checkhealth命令還沒有實現,目前總是會返回成功,除非給定的NameNode完全關閉。


自動故障轉移

介紹

以上部分介紹如何配置手動故障切換。在該模式下,即使主動節點出現故障,系統也不會自動觸發從active NameNode到standby NameNode的故障轉移。本節介紹如何配置和部署自動故障切換。

元件

自動故障切換為HDFS部署添加了兩個新元件:ZooKeeper仲裁和ZKFailoverController程序(簡寫為ZKFC)。

Apache ZooKeeper是一種高度可用的服務,用於維護少量協調資料,通知客戶該資料的更改,以及監控客戶端的故障。自動HDFS故障切換的實現依賴於ZooKeeper,具體如下:

  • 故障檢測 - 群集中的每個NameNode機器在ZooKeeper中維護一個持久會話。如果機器崩潰,ZooKeeper會話將過期,通知另一個NameNode應該觸發故障切換。

  • 活動NameNode推選 - ZooKeeper提供了一個簡單的機制,專門用於active NameNode的推選。如果當前活動的NameNode崩潰,則另一個節點可能會在ZooKeeper中採取特殊排他鎖,來表示該節點應該成為下一個active節點。

ZKFailoverController(ZKFC)是一個新的元件,它是一個ZooKeeper客戶端,還監視和管理NameNode的狀態。執行NameNode的每臺機器也執行一個ZKFC,ZKFC負責:

  • 健康監控 - ZKFC定期使用健康檢查命令對其本地NameNode進行ping操作。只要NameNode以健康狀態作出響應,ZKFC認為節點健康。如果節點崩潰,宕機或以其他方式進入不健康狀態,健康狀況監視器會將其標記為不健康。

  • ZooKeeper會話管理 - 當本地NameNode健康時,ZKFC在ZooKeeper中持有一個會話。如果本地NameNode處於活動狀態,它也會儲存一個特殊的znode“鎖”。這個鎖由ZooKeeper“短暫”的節點提供支援; 如果會話過期,znode鎖將被自動刪除。

  • 基於ZooKeeper的選舉 - 如果本地NameNode是健康的,並且ZKFC看到沒有其他節點當前持有znode鎖,則它本身將嘗試獲取該鎖。如果成功,則該zkfc“贏得選舉”,並負責執行故障切換,使其本地NameNode處於活動狀態。故障轉移過程類似於上述手動故障轉移:首先,如果需要的話會先前的active NameNode隔離,然後將本地NameNode轉換到活動狀態。

有關自動故障切換設計的更多詳細資訊,請參閱Apache HDFS JIRA上附帶的HDFS-2185設計文件。

部署ZooKeeper

在典型的部署中,ZooKeeper守護程序配置為在三個或五個節點上執行。由於ZooKeeper本身具有輕量資源要求,因此可以將ZooKeeper節點與HDFS NameNode和Standby Node在同一硬體上並置。許多程式(員)猿選擇在與YARN ResourceManager相同的節點上部署第三個ZooKeeper程序。建議將ZooKeeper節點配置為將其資料儲存在與HDFS元資料不同的磁碟驅動器上,以獲得最佳效能和隔離。

ZooKeeper的設定超出了本文件的範圍。我們假設您已經設定了執行在三個或更多節點上的ZooKeeper叢集,並通過使用ZK CLI進行連線來驗證其正確的操作。

在開始之前

在開始配置自動故障切換之前,應該關閉叢集。當叢集執行時,目前無法從手動故障轉移配置轉換到自動故障轉移配置。

配置自動故障轉移

自動故障轉移的配置需要為您的配置新增兩個新引數。在您的[hdfs-site.xml]檔案中,新增:

 <property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
 </property>

這指定應該為叢集設定自動故障切換。在您的[core-site.xml]檔案中,新增:

 <property>
   <name>ha.zookeeper.quorum</name>
   <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
 </property>

這將列出執行ZooKeeper服務的主機埠對。

與文件中先前描述的引數一樣,這些設定可以通過使用名稱服務ID作為字尾關鍵字來對每個nameservice進行配置。例如,在啟用聯邦的叢集中,您可以通過設定dfs.ha.automatic-failover.enabled.my-nameservice-id來顯式啟用僅一個名稱伺服器的自動故障轉移

還有其他幾個配置引數可以設定為控制自動故障切換的行為; 然而,它們對大多數安裝沒有必要。有關詳細資訊,請參閱配置關鍵字具體文件。

在ZooKeeper中初始化HA狀態

新增配置鍵後,下一步是在ZooKeeper中初始化所需的狀態。您可以通過從其中一個NameNode主機執行以下命令來執行此操作。

[hdfs] $ $ HADOOP_PREFIX / bin / hdfs zkfc -formatZK

這將在ZooKeeper中建立一個znode來為自動故障切換系統儲存其資料。

使用start-dfs.sh啟動群集

由於配置中啟用了自動故障轉移功能,所以start-dfs.sh指令碼現在將自動在執行NameNode的任何計算機上啟動ZKFC守護程式。當ZKFC啟動時,它們將自動選舉一個NameNodes以使其成為活動狀態。

手動啟動叢集

如果手動管理叢集中的服務,則需要在執行NameNode的每臺計算機上手動啟動zkfc守護程式。您可以通過執行以下命令啟動守護程式:

[hdfs] $ $ HADOOP_PREFIX / sbin / hadoop-daemon.sh --script $ HADOOP_PREFIX / bin / hdfs start zkfc

訪問ZooKeeper的許可權保護

如果您正在執行安全叢集,則可能需要確保儲存在ZooKeeper中的資訊也得到保護。這樣可以防止惡意客戶端修改ZooKeeper中的元資料或潛在地觸發虛假的故障轉移。

為了保護ZooKeeper中的資訊,首先將以下內容新增到您的core-site.xml檔案中:

 <property>
   <name>ha.zookeeper.auth</name>
   <value>@/path/to/zk-auth.txt</value>
 </property>
 <property>
   <name>ha.zookeeper.acl</name>
   <value>@/path/to/zk-acl.txt</value>
 </property>

請注意這些值中的“@”字元 - 這表示配置不是內聯的,而是指向磁碟上的檔案。

第一個配置的檔案指定了一個ZooKeeper認證列表,與ZK CLI使用的格式相同。例如,您可以指定以下內容:

digest:hdfs-zkfcs:mypassword

...其中hdfs-zkfcs是ZooKeeper的唯一使用者名稱,mypassword是用作密碼的唯一字串。

接下來,使用以下命令生成與此身份驗證相對應的ZooKeeper ACL:

[hdfs]$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs=

將' - >'字串後的輸出部分複製貼上到檔案zk-acls.txt中,字首為“ digest:” 例如:

digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

為了使這些ACL生效,您應該如上所述重新執行zkfc -formatZK命令。

這樣做後,您可以從ZK CLI驗證ACL,如下所示:

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa

驗證自動故障轉移

一旦設定了自動故障切換,您應該測試其操作。為此,首先找到活動的NameNode。您可以通過訪問NameNode Web-UI面來檢視哪個節點處於活動狀態 - 每個節點在頁面頂部顯示了其HA狀態。

找到活動的NameNode後,可以在該節點製造一些故障。例如,可以使用kill -9 <NN/ZKFC pid>來模擬JVM崩潰。或者,您可以重新啟動機器或拔掉其網路介面(可以使用 ifdown eth0 命令)以模擬不同型別的中斷。觸發您想要測試的中斷後,其他NameNode將在幾秒鐘內自動變為活動狀態。檢測故障並觸發故障切換所需的時間取決於ha.zookeeper.session-timeout.ms的配置,但預設為5秒。

如果測試不成功,您可能存在配置錯誤。檢查zkfc守護程式以及NameNode守護程式的日誌,以進一步診斷問題。

自動故障轉移常見問題

  • 我以任何特定的順序啟動ZKFC和NameNode守護程序很重要嗎?

    否。在任何給定的節點上,您可以在其對應的NameNode之前或之後啟動ZKFC。

  • 我應該進行什麼額外的監測嗎?

    您應該在執行NameNode的每個主機上新增監控,以確保ZKFC保持執行。在某些型別的ZooKeeper故障中,例如,ZKFC可能會意外退出,並應重新啟動zkfc以確保系統已準備好進行自動故障轉移。

    此外,您應該監視ZooKeeper仲裁中的每個伺服器。如果ZooKeeper崩潰,則自動故障切換將不起作用。

  • 如果ZooKeeper停機,會發生什麼?

    如果ZooKeeper群集崩潰,則不會觸發自動故障轉移。然而,HDFS將繼續執行而沒有任何影響。當ZooKeeper重新啟動時,HDFS將重新連線沒有任何問題。

  • 我可以將我的一個NameNodes指定為主要/首選項嗎?

    不,目前不支援。首先啟動NameNode將變為活動狀態。您可以選擇以特定順序啟動叢集,以便首選節點首先啟動。

  • 配置自動故障切換時,如何啟動手動故障切換?

    即使配置了自動故障切換,也可以使用相同的hdfs haadmin命令啟動手動故障切換它將進行協調故障切換。

HDFS升級/完成/回滾與HA啟用

在HDFS版本之間進行更改時,有時可以簡單地安裝較新的版本,並重新啟動叢集。然而,有時升級您正在執行的HDFS版本可能需要更改磁碟上的資料。在這種情況下,在安裝新軟體之後,必須使用HDFS升級/完成/回滾工具。這個過程在HA環境中變得更加複雜,因為NN所依賴的磁碟元資料是被定義為分部核實儲存的:在成對的HA NN上,在JournalNodes上,以及在QJM被用於共享的編輯日誌。本部分介紹在HA設定中使用HDFS升級/完成/回滾工具的步驟。

要執行HA升級,操作員必須執行以下操作:

  1. 正常關閉所有NN,並安裝較新的版本。

  2. 啟動所有JN。請注意,執行升級、回滾或完成操作時,所有JN都正在執行至關重要如果任何JN在執行任何這些操作時關閉,操作都將失敗。

  3. 使用'-upgrade'引數啟動其中一個NN

  4. 一開始,這個NN將不像往常一樣在HA設定中進入待機狀態。相反,此NN將立即進入活動狀態,執行其本地儲存目錄的升級,並執行共享編輯日誌的升級。

  5. 此時,HA對中的其他NN將與升級的NN不同步。為了使其恢復同步,並且再次具有高度可用的設定,您應該通過使用'-bootstrapStandby'引數執行NN來重新引導該NameNode 使用'-upgrade'標誌啟動這個第二個NN是一個錯誤操作

請注意,如果您在完成、升級或回滾操作之前的任何時候之前重新啟動NameNodes,那麼您應該正常啟動NN,即沒有任何特殊的啟動引數。

要完成HA升級,操作員可以在兩個NN同時執行並且有且只有其中一個處於active態時使用“hdfs dfsadmin -finalizeUpgrade”命令。此時發生的活動NN將執行共享日誌的最終化,並且本地目錄中包含其先前FS狀態的NN將對其狀態進行刪除。

要執行升級的回滾,應首先關閉兩個NN。運營商應該在啟動升級過程的NN上執行回滾命令,該命令將對本地目錄進行回滾,以及NFS或JN上的共享日誌。之後,應該啟動這個NN,並且操作員應該在另一個NN上執行`-bootstrapStandby',使兩個NN以回滾後的檔案系統狀態保持同步。