構建高可靠hadoop集群之3- Quorum Journal Manager

来源:http://www.cnblogs.com/lzfhope/archive/2017/06/16/6973056.html
-Advertisement-
Play Games

hadoop的ha部署-利用zookeeper和jns來實現 ...


在正式環境中，搭建高可靠(ha)的系統是必須的。

例如oralce的rac,apache集群，windows伺服器集群

本文不再贅言ha的重要性。

本文主要是對 http://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html#Administrative_commands

的翻譯，外加一些其它參考和個人的感悟。

---原文相當長

譯註：ha-high availability 。原文說了半天，就是要求我們使用zookeeper來實現自動故障轉移（切換），當然這也是絕大部分管理員所期望的。

 

1.目的

本指引提供關於HDFS高可靠特性的概覽和如何配置管理高可靠hdfs集群（利用日誌管理器特性qjm).

本文檔假定讀者已經理解主要的部件和節點類型。

 

2.註意：使用日誌管理器還是傳統的共用存儲

本指引討論如何使用qjm配置高可靠的HDFS集群，qjm的作用在於活動名稱幾點和備份名稱節點之間共用編輯日誌。

 

3.背景

在hadoop 2.0.0之前，HDFS集群中名稱節點是單一故障點。每個集群只有單一的名稱節點，如果機器或者進程發生故障，那麼集群就不可用了，除非名稱節點重啟或者在新的機器上搭建。

這影響了HDFS集群的總體可用性，主要體現在兩個途徑：

  • 機器突然故障，直到一個操作員重啟了名稱節點
  • 計劃中的維護，例如軟體或者硬體升級（升級名稱節點）會導致整個集群不可用

通過運行兩個冗餘的名稱節點（一個活動，一個待命），可以避免以上提到的問題。這樣如果其中一個有問題或者需要，就可以快速切換到備用節點（譯註：standby ,待命，等待,備用）。

4.框架

在一個典型的ha集群中，有兩個分開的機器被配置為名稱節點。在任何時候，只有一個名稱節點是活動狀態(active),另外一個是等待狀態(standby).活動的名稱節點負責所有客端操作，而等待節點僅僅簡單維護名稱空間狀態，以便需要的時候切換。

為了讓等待狀態的節點保持和活動節點的狀態同步，兩個節點都需要通過一組的守護程式來通訊，這個守護程式稱為journalNodes(JNs-日誌節點)。當活動節點發生任何的名稱空間修改的時候，活動節點記錄這些修改，並告知JNS。等地節點從JNS讀取編輯日誌，並立刻尋找編輯日誌的變更信息。當等待節點看到編輯信息，它會應用到自身的名稱空間。如果主節點發生故障，等待節點會確保自己已經從jns讀取了所有的編輯信息，之後才會把自己設置為活動。這樣確保名稱空間完全同步故障前的內容。

為了提供給一個快速的故障切換，也需要等待節點具有及時的塊位置信息。為了獲得這個，數據節點必須配置兩個名稱節點的信息，並且心跳信息和快報告需要發送給兩個節點。

一個時刻只能有一個名稱節點是活動的，這是ha的必須條件。否則，名稱節點的狀態會分散在兩個節點上，就可能導致數據丟失或者其它錯誤的結果。為了確保這點，並防止稱為腦裂的場景，jns在一個時間點，只會允許一個寫入程式。活動的節點負責寫信息給jns,同時這樣也會主持其它名稱節點變成活動狀態。

5.硬體資源

為了部署一個ha集群，我們應該準備以下內容:

  1. 名稱節點機器-用於運行活動名稱節點和等待名稱節點，它們應該具有同樣的硬體。
  2. jns機器-用於運行日誌管理程式（jns）。jns守護程式相對看起來比較輕量，所以可以和其它的hadoop守護程式部署在同一機器上，那些守護程式可以是名稱節點，jobtracker(作業追蹤器),或者yarn資源管理器。註：至少必須有3個jns守護程式，因為編輯日誌必須寫入到大部分jns中。這樣如果其中一些設備出現問題，那麼還有一些jns可以繼續工作。我們也可以運行多於3個jns，但為了提升系統的容錯性，我們應該運行奇數個jns(3,5,7等等）。因為這樣系統至少可以提供(n-1)/2的容錯次數。

需要註意的是，在一個ha集群中，等待名稱節點也執行名稱空間的檢查點，所以就無需運行第二名稱節點，檢查點節點，或者備份名稱節點。

譯註：關於為什麼jns的守護守護程式是奇數個，這個應該和名稱節點寫編輯日誌到jns的方式有關，由於本人並沒有研究代碼，所以不能解釋具體是什麼。

 

6.部署

6.1配置一覽

類似於聯合配置，ha配置向後相容，並允許現有的單名稱節點配置可以不用修改（配置）而繼續運行。

新的配置允許集群中所有的節點具有相同的配置，這樣不需要根據不同的節點類型部署同的配置文件。

譯註：這的確是一個很好的想法，否則部署成千上萬的集群的確是非常麻煩的，現在不用擔心配置搞混這種事情。

類似於HDFS Federation，ha集群會重用nameservice ID來識別單個的HDFS實例，這個實例可能包含了多個ha名稱節點。此外，一個新的抽象稱為NAMENODE id 加入到ha 中。每個獨立的名稱節點有一個不同的NAMENODE id.

為了支持單一配置文件，相關的配置參數必須把nameservice id作為尾碼，同時也帶上namenode id.

6.2配置明細

為了配置ha名稱節點，我們必須在hdfs-site.xml中添加幾個配置。

配置的順序無關緊要，但dfs.nameservices 和 dfs.ha.namenodes.[nameservice ID]的值會決定接下來配置的關鍵信息。因此，我們必須優先考慮這個兩個。

dfs.nameservices - 名稱服務的邏輯名稱

<property>
  <name>dfs.nameservices</name>
  <value>mycluster</value>
</property>

譯註：如果啟用federation,那麼就可以同時啟用多個集群。啟用多個集群的唯一原因，就是為了便於大家共用，其次就是增加namenode的輸出能力，屬於典型的併排模式。

dfs.ha.namenodes.[nameservice ID] - 名稱服務中唯一的名稱節點標識

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

譯註：上面藍色的mycluster是通過dfs.nameservices來決定，並非固定的。其次，目前只能允許一個ha集群終有兩個名稱節點，將來會支持更多一些。

         最後，nn1,nn2也是一個邏輯名稱罷了，不是設置為機器的實際名稱。

 

dfs.namenode.rpc-address.[nameservice ID].[name node ID] -  名稱節點的全稱PRC地址，名稱節點通過這個偵聽rpc信息

<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>

譯註：必須指定埠

 

dfs.namenode.http-address.[nameservice ID].[name node ID] -名稱節點的http地址全稱，用於偵聽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的安全選項，則必須配置https-address，配置類似上面的http-address.

 

dfs.namenode.shared.edits.dir-jns地址，名稱節點寫編輯日誌的目標，多個以分號分隔

uri的格式必須形如：qjournal://*host1:port1*;*host2:port2*;*host3:port3*/*journalId*.

其中journalid實際就是名稱服務的唯一標識符。雖然不是強制的，但把journalid設置為何nameservice id一致，是不錯的主意。（譯註：也許將來hdfs就不存在journalid,直接是nameservice id了)

<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>

這個地址用於活動節點寫入編輯信息，等待節點讀取編輯信息。雖然我們必須設定多個jns地址，但我們只能配置一個uri.

 

dfs.client.failover.proxy.provider.[nameservice ID] - hdfs客戶端聯繫活動名稱節點的類

這個類的作用是識別活動節點。當前hadoop提供了兩個實現，分別是ConfiguredFailoverProxyProvider 和 RequestHedgingProxyProvider (第一次調用，會同時聯繫多個節點來判斷哪個是活動的，隨後的請求會激活活動的節點，除非發生了故障切換），

請使用兩者之一，除非自行定製。例如：

<property>
  <name>dfs.client.failover.proxy.provider.mycluster</name>
  <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

譯註：RequestHedgingProxyProvider 和 ConfiguredFailoverProxyProvider 有什麼區別

 

dfs.ha.fencing.methods - 腳本或者java類的列表，用於在故障切換中隔離活動名稱節點

重點，當使用仲裁日誌管理器的時候，一個時間點，只能有一個活動的名稱節點，只能是活動名稱節點寫jns，所以即使腦裂，也不會破壞系統元數據。然而，當故障切換髮生的時候，仍然有可能，前面一個活動名稱節點為客戶端提供讀請求，這樣客戶端獲得信息就可能是過時的。因此，即使有使用仲裁日誌管理器，也有必要配置一些隔離方法。為了在隔離機制失敗的時候，提升系統的可靠性，仍然有必要配置那麼一個隔離方法，這個方法用於保證返回成功，好像最近的隔離方法還在清單中。

註意，如果我們選擇一些沒有實際作用的隔離方法，我們依然需要配置這些，例如"shell(/bin/true)".

隔離方法用回車符分隔，它們會逐個被嘗試，直到返回成功。hadoop提供了兩個方法：shell和sshfence.

如果想實現定製的隔離方法，請看 org.apache.hadoop.ha.NodeFencer 類。

譯註：這個地址可以看 http://www.programcreek.com/java-api-examples/index.php?source_dir=hadoop-master/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ha/NodeFencer.java

sshfence - ssh到活動名稱節點，並kill進程

sshfence選項通過ssh連接到目標節點，並使用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>

此外，還可以配置連接的用戶和埠，連接時限（單位毫秒， 如果超過這個連接時限沒有連接到活動節點，那麼表示隔離失敗).

<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>

譯註：這就必要要求名稱節點上要有fuser這個程式。此外，hadoop目前這種做法，也許將來不會再採取了，個人認為有點low!

shell - 運行一個強制shell命令來隔離活動名稱節點

配置看起來如下：

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

 

位於小括弧內的字元串傳遞了bash shell的路徑，並且可能不包含任何的反小括弧。（譯註：對於 may not include any closing parentheses 不是很理解）

shell命令必須在具有當前hadoop配置的環境變數中運行，使用下劃線(_)替換配置關鍵信息中任意的點號(.)。使用的配置早有名稱節點有關的配置-例如dfs_namenode_rpc-address包含了目標名稱節點的rpc地址，當然也可能是形如dfs.namenode.rpc-address.ns1.nn1.

此外，以下變數也是可以使用的：

$target_host               hostname of the node to be fenced  --被隔離名稱節點的主機名稱
$target_port               IPC port of the node to be fenced     --被隔離節點的ipc埠
$target_address          the above two, combined as host:port    --以上兩個變數的合併
$target_nameserviceid  the nameservice ID of the NN to be fenced    --被隔離節點的名稱服務ID
$target_namenodeid    the namenode ID of the NN to be fenced       --被隔離節點的名稱節點ID

這些變數，可以直接在參數中使用，例如：

<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腳本中實現。

 

fs.defaultFS -  如果客戶沒有提供路徑首碼，那麼使用這個預設的

我們可以為hadoop客戶端配置預設的路徑，以便可以使用啟用了ha的邏輯uri.

如果早先使用"mycluster"作為名稱服務ID，那麼這個id就是所有HDFS路徑的重要部分。

我們可以在core-site.xml文件中，如下配置：

<property>
  <name>fs.defaultFS</name>
  <value>hdfs://mycluster</value>
</property>

譯註： 以後訪問ha的hdfs就需要帶上 hdfs://mycluster之類的首碼（不需要使用hdfs://host:port之類的）

如果啟用viewfs，則這個可能又不同了。

dfs.journalnode.edits.dir - jns守護程式本地用於存儲編輯日誌等的路徑

這是一個絕對路徑，位於jns機器上，用於存儲編輯日誌和其它本地狀態。我們可能只使用一個路徑。如果要路徑冗餘，那就需要運行多個jns,或者是路徑位於raid磁碟上。例如：

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

6.3部署明細

在所有配置完成後，就必須啟動有關機器上的jns守護程式。這可以通過運行 hadoop-daemon.sh start journalnode 來完成，然後就是等待守護程式在有關的機器上啟動。

一旦守護程式完成啟動，就必須初始同步兩個ha名稱節點磁碟上的元數據。

  • 如果配置的是一個新的hdfs集群，那麼必須其中一個名稱節點上先運行hdfs namenode -format
  • 如果早已經格式化過，或者僅僅是把一個非ha集群轉換為ha集群，那麼必須把元數據目錄下的數據拷貝到另外一臺，沒有格式化的那一臺節點必須運行hdfs namenode -bootstrapStandby.
  • 如果是把一個非ha名稱節點轉為ha節點，那麼必須運行 hdfs namenode -initializeSharedEdits，這樣會使用名稱節點本地編輯日誌目錄中的數據初始化jns。

譯註：關於上面的第二點和第三點的區別，第三點中提到的名稱節點可能是第二名稱節點，檢查點節點，或者是備份節點；而第二點的應該是屬於新增一個名稱節點了。

然後，就可以啟動兩台名稱節點了。

然後可以通過web瀏覽器來訪問兩個名稱節點。需要註意的是，配置地址(configured address)後跟著的是"active"或者"standby".無論什麼時候，一個名稱幾點啟動的時候，其初始狀態是"standby".

6.4 管理命令

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

  • transitionToActive and transitionToStandby - 傳輸狀態到另外一個節點（active或者standay)

    註意，這個命令不提供隔離，所以要少用。應該使用hdfs haadin -failover

  • failover -開始在兩個節點之間進行故障切換

    命令用戶切換第一節點到第二個節點。如果 第一個節點是standby，那麼可以沒有錯誤地切換到第二個（第二個變為active).如果第一個是active的，那麼會先嘗試把它變為standby.如果嘗試失敗，那麼隔離方法會被啟用，直到其中一個格式嘗試成功。如果有成功，那麼第二個會被置為active.如果隔離都失敗，那麼切換失敗，並返回錯誤信息。（譯註：如果第一個是standy，還有需要切換嗎？難道兩個都可能是standby嗎)

  • getServiceState -監測名稱節點的狀態，是active還是standby

  • checkHealth -檢查指定節點的健康狀態

    成功（健康）返回0，其它就是不健康.註：在2.8.0版本中，尚未實現，總是返回0，除非指定名稱節點關閉了。

7.自動故障轉移

7.1簡介

以上章節描述如何手動配置故障轉移。那種模式下，系統不會子弟on個觸發一個故障轉移，即使活動節點失敗了。以下內容描述如何配置和部署一個自動故障轉移。

7.2組件

自動故障轉移會添加兩個組件：一個zookeeper仲裁者，一個ZKFC(ZK故障轉移控制器進程）。譯註:為了便於書寫，後文把zookeeper簡寫為zk

阿帕奇的zookeeper是一個高可靠服務，可用於維護少量的協調數據，通知客戶數據的變更，並監控客戶端的故障。HDFS的自動故障轉移依賴於zookeeper的以下幾個方面：

  • 故障偵測 - 集群中每個名稱節點上都會運行一個zookeeper的持久會話.如果機器崩潰，那麼zk會話就會過期，然後就通知其它節點應該觸發故障轉移了。

  • 活動節點選舉 - zk提供了一個簡單的機制來選擇唯一一個節點作為活動節點。如果當前的活動節點完蛋，另外一個節點可能會在zk中設立一個排他鎖，宣告它要成為下一個活動節點。

ZKFC是zk的新組件，屬於zk的客戶端，也會監控和管理名稱節點的狀態。每個運行名稱節點的機器同時也會運行一個zkfc，zkfc負責：

  • 監控監控 - zkfc使用健康檢查命令定期檢查本地的名稱節點（譯註：原文使用的是ping,大意是提醒讀者這個行為很像ping）. 只要名稱節點及時回應健康的狀態，那麼zkfc就會認為節點是健康的。如果節點崩潰，或者凍結（譯註：原文是frozen),或者進入一個不健康的狀態，那麼zkfc就會把它標記為不健康.

  • zk會話管理- 當本地的名稱節點健康的時候，zkfc會和zk保持一個打開的會話。如果本地節點是活動的，那麼會話就持有一個特定的“lock” znode（譯註：這個可能zk系統的一個說法，運行zkfc的節點稱為znode）. 這個鎖會把當前節點當作一個“ephemeral”節點；如果會話過期，那麼鎖定的節點會被刪除掉。(譯註：ephemeral-本意是“短暫的瞬息的”，按照zk的設計思路，大意是總認為每個節點的狀態都是可疑的，zk總是在等待著選擇下一個節點。每一個名稱活動且被鎖定的名稱節點其狀態都是暫時的，隨時可以被其它的節點替代，如果有必要的話）。

  • zk-基本選舉 - 如果本地節點是健康的，zkfc認為沒有其它節點持有一個鎖定的znode，它自己會試圖獲取鎖。如果成功，那麼它就“贏得選舉”，並負責啟動一個故障轉移，把本地節點設定為活動的名稱節點。故障轉移的過程類似於前文的手動方式：  首先，隔離先前的節點（如果有必要），然後本地節點轉為為活動的狀態.

要瞭解更多自動故障轉移的設計細節，請參考apache hdfs jira--https://issues.apache.org/jira/browse/HDFS-2185

譯註：現有版本的ha-hdfs相對比較簡單，總共部署了兩個名稱節點，將來可能會支持更多的節點。zk可以支持許多znode

zk的監控和選舉看起來還是相對簡單的：每個znode不斷試圖證明自己ok，如果不ok，就被zk刪除掉。剩下的健康znode就會爭寵，成功了就切換到特定的節點。

當然，還有更多的細節。不過這不是ha的重點。

 

7.3部署zookeeper

在一個典型的部署中，zk守護程式運行在3到5個節點中。由於zk自己對資源要求很低，把它們和hdfs的名稱節點（活動的或者等待的）部署在同樣的硬體上也是可以接受的。許多人會選擇把第三個zk進程和yarn資源管理器部署在一起。

強烈建議：不要和名稱節點部署在一起，考慮到性能和隔離性。

zk的配置已經超過了本文的範圍。我們假定你已經在3到5個節點上成功部署並運行了一個zk集群，並通過zk cli驗證過了。

譯註：把zk和nn部署在一起，簡直就是犯罪，不如不做，但原文作者也不會強制阻止那種“勇敢”的行為。

 

7.4開始前準備

在開始配置自動故障轉移前，我們必須關閉現有的hadoop集群。集群正在運行得時候，是無法從手動模式切換到自動模式的。

 

7.5配置自動故障轉移

需要在hdfs-site.xml中添加以下部分：

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

   <description>啟動自動故障轉移</description>
 </property>   

 

在core-site.xml中添加如下：

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

   <description>列出運行zk的機器和埠，以逗號分隔</description>
 </property>

譯註：原文說到，還有幾種配置的方式。 由於不常用，所以本人也可以少打幾個字了。

 

7.6初始化zookeeper的ha狀態

在添加了關鍵配置之後，下一步就是初始化zk的數據。我們可以在其中一臺名稱節點上運行名稱來完成這個步驟：

$HADOOP_PREFIX/bin/hdfs zkfc -formatZK

這個命令的作用就是在ZK中創建一個ZNODE數據。

譯註：一般人安裝的時候，不一定設定了HADOOP_PREFIX的變數，多是設定HADOOP_HOME，而且一般有設定PATH，所以以上的命令可以簡化為 hdfs zkfc -formatZK  ,或者簡單把HADOOP_PREFIX替換為HADOOP_HOME,實在不行多設置一環境變數也可以 export HADOOP_PREFIX=$HAOOP_HOME

 

7.7使用start-dfs.sh啟動集群

由於自動故障轉移已經啟用，所以start-dfs.sh腳本會自動啟動ZKFC守護程式（在所有每次節點上）。當zkfc啟動的時候，它們會自動選舉一個活動節點。

譯註：自從有了start-dfs.sh之後，啟動集群變得方便了許多，不用關心在哪個節點上啟動哪些命令。

 

7.8手動啟動集群

如果是手動管理集群，請使用以下命令（在每一個名稱節點上執行)

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

 

7.9安全訪問zookeeper

如果我們運行的是一個安全集群，我們可能會想確保存儲在zk中的數據也是安全的。這樣可以阻止一些惡意客戶端修改zk的元數據，或者觸發一些錯誤的故障轉移。

為了保全zk的信息，第一步是在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>

符號@是一個指示，意思是後面跟上的才是一個整個要用到的文件。

第一步，設置zk-auth.txt的內容，內容格式如下：

digest:hdfs-zkfcs:mypassword

hdfs-zkfcs是zk的用戶名稱，mypassword是zk用戶的密碼

第二步，生成zk-acl.txt(需要和zk-auth.txt中的用戶對應)

請使用以下命令生成：

[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=

把上面輸出中"->"後的紅色字元串整合如下: digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

最後，為了保證這些acl起作用，必須重新運行  hdfs zkfc -formatZK  (譯註：如果一開始就配置了安全存取，那麼格式化一次就可以了）

之後，就是通過zk-cli來驗證：

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha

'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM= : cdrwa

 

7.10驗證自動故障轉移

一旦自動故障轉移已經設置好，我們必須測試下。首先找到活動的節點-這個可以通過名稱節點的http來訪問獲取，例如http://nn1:50070

之後，在活動的節點上搞個破壞。例如斷線，kill進程，關機等等。然後看下另外一個節點的狀態是否變成active了(不是馬上，可能要幾秒鐘）。這個等待間隔取決於配置 ha.zookeeper.session-timeout.ms,預設是5秒。

如果沒有成功，那麼一定那麼配錯了。檢查下zfkc的日誌和名稱節點的日誌，或者再看看配置那裡出現錯誤了沒有。

8.自動故障轉移FAQ

  • zkfc和名名稱節點的啟動順序是否重要？ 

    不。任何名稱節點上zkfc都可以在名稱節點前或者後啟動  。  譯註：這個是比較令人奇怪的事情，不過當ha中使用zk和多個名稱節點配置之後，除非zk啟動了，否則無法使用的。所以不需要關註這個問題。

  • 是否需要額外監測一些東西？

    應該更多關註每個名稱節點，確保其上的zkfc是正在運行中。有些情況的zk故障，例如zkfc可能會意外退出，那麼就需要確保重啟zkfc。此外，必須監控zk伺服器。如果zk伺服器完蛋了，也無法自動故障轉移。

  • zk關閉的時候發生了什麼？

    如果狀況集群甭快，那麼就無法自動觸發故障轉移。然而這對hdfs沒有任何影響，還是可用的. 當zk重啟，hdfs會靜悄悄重連zk。

        譯註：就這個方面而言，個人覺得oracle rac做得還是挺不錯的，當然hdfs做得也還可以。

  • 是否可以指定某個名稱節點為主要的？

    不。當前不允許。那個先啟動，那個就是活動的。你可以選擇先啟動其中一個，或者關閉另外一個然後再重啟來切換到其中一個為主要的點。但不能總是指定為主要的。

  • 如果已經配置了自動化的，那麼如何手動故障切換？

    即使配置了自動故障轉移，我們也可以使用hdfs haadmin來做手動的故障轉移，效果是一樣的。

 

9.ha HDFS 的升級/就緒/回滾

當升級HDFS某些版本的時候，有些時候新版本軟體可以簡單安裝並重啟集群。有些時候，升級hdfs，可能要求修改磁碟數據。在這種情況下，必須使用HDFS  Upgrade/Finalize/Rollback工具。在ha環境下，這個更加複雜，因為名稱節點磁碟上的元數據是分佈的，除了名稱節點是這樣，jns也是如此。這個章節描述在ha hdfs中如何使用 Upgrade/Finalize/Rollback。

為了執行一個ha升級,操作人員必須做以下事情:

  1. 正常關閉所有的名稱節點，然後安裝新的軟體。

  2. 啟動所有jns。至關重要-Upgrade/Finalize/Rollback的時候jns必須都在運行。如果期間，有任意的jns停止運行，那麼操作會失敗。

  3. 使用-upgrade選項啟動其中一個名稱節點

  4. 啟動的時候，這台名稱節點立即進入ACTIVE狀態,然後執行對本地存儲目錄和共用編輯日誌的升級。

  5. 然後使用-bootstrapStandby選項啟動另外一個名稱節點。

註意，如果想就緒或者回滾，那麼只需要正常啟動名稱節點。

 

就緒一個升級, 操作人員使用‘hdfs dfsadmin -finalizeUpgrade’命令即可，其中一臺名稱節點執行即可。活動的那個會做共用日誌的就緒工作，另外一臺則會把以前的FS的磁碟信息刪除掉（譯註：登臺下一次jns的同步).

執行回滾, 兩個名稱節點都需要關閉，操作人員在執行upgrade的那臺上名稱節點上執行roll back命令，然後那個節點會執行數據回滾。然後這個節點，再次執行正常啟動，另外一臺則執行  `-bootstrapStandby' .

 

譯註：

1）升級/就緒/回滾之類的都是hdfs namenode中的幾個命令。關於“Finalization”原文的意思就是為升級掃尾並打上正常標記的意思。Finalization本意是終結，但可能會讓讀者誤會。

因為終結一個升級狀態後，就是集群的就緒，所以譯文使用“就緒"而不是”終結".

2) 當故障轉移發生的時候，如何保證hadoop應用可以正常使用了？ 由於一些應用可能直接通過直接指向其中一臺名稱節點，這樣可能存在問題。 所以解決這個問題，要麼hadoop已經提供了類似oracle的透明故障轉移，要麼使用api的開發人員必須考慮自己編碼實現

應用的透明故障轉移。由於本人並沒有使用hadoop的api編程，尚不清楚這個。 也不清楚更新的版本中的是什麼情況。

3)hadoop的 federation和ha是可以同時部署的，這個方面可以參考 http://www.linuxidc.com/Linux/2014-05/101181.htm

不好比較hadoop的這種ha和提高吞吐的架構，如果和oracle rac比較，個人覺得後者更加高級一些，既能提高吞吐，也可以提高可靠性，  至少對於開發人員和用戶而言是這樣的。

如果你的應用並不需要同時運行那麼多的task,建議暫時部署ha即可。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 更新下載庫update使用
    下載更新apk，基本上每個app都需要的功能，以前都是自己寫，近期想藉助第三方的一個庫來做，功能齊全，感覺不錯，記錄使用過程，雖然官方也有使用教程，不過畢竟粗略，網上也能搜到，不過基本都是複製的 首先下載庫，地址改成我們自己的，檢查地址就讓它了，這個根據自己的業務調整，也能自定義 接下來是參數介紹 ...
  • Android基礎
    Android基礎 Android系統架構 JVM和DVM的不同 區別 1. 基於的架構不同。jvm 基於棧架構，棧是位於記憶體上的一個空間，執行指令操作，需要向cpu定址； dvm 基於寄存器架構，寄存器是cpu的一個組成部分，執行指令操作無需定址直接執行。 2. 執行文件的格式不同，jvm執行的是 ...
  • XMPPFramework核心類介紹
    XMPPFramework結構 在進入下一步之前，先給大家講講XMPPFramework的目錄結構，以便新手們更容易讀懂文章。我們來看看下圖： 雖然這裡有很多個目錄，但是我們在開發中基本只關心Core和Extensions這兩個目錄下的類。各個目錄主要用來幹嘛的？ Authentication：這一 ...
  • oracle根據成績排名查詢某個名次段的人員
    先說一下表結構 名字name 分數fenshu 表名test1，以下查詢的是成績排名為第三名和第四名，這個模板讓你查隨意排名段的人 select name,fenshu,mc from (select name, fenshu,dense_rank() over (order by fenshu d ...
  • 構建高可靠hadoop集群之4-許可權指引
    此文翻譯自 http://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html 譯註：實際部署中，沒有安全控制的hadoop的，最好不要使用，因為可能很多心血會毀於一旦。 概覽 ...
  • 關於資料庫冗餘欄位及適當性
    依個人理解，冗餘欄位就是本存在一張表的欄位，也出現在另一張表中。 例如：有三張表，用戶表、商品表、訂單表，用戶表中有欄位name，而訂單表中也存在欄位name。 對於這個欄位冗餘有好有壞 好： 從用戶表、商品表、訂單表說起，當我需要查詢“訂單表”所有數據並且只需要“用戶表”的name，一般都可以通過 ...
  • MySQL性能優化
    查詢緩存 查詢緩存（Query Caching）緩存了SELECT查詢及其結果數據集，當執行一個同樣的SELECT查詢時，MySQL會從記憶體中直接取出結果，加快了查詢執行速度、減小了資料庫的壓力。執行 可以查看MySQL查詢緩存是否打開，開啟查詢緩存只需配置my.cnf文件即可，具體如下： quer ...
  • Oracle Buffer Pool內部閂鎖機制
    本文中根塊，枝塊，葉塊，表塊分別是索引根塊，索引枝塊，索引葉塊，數據表塊的簡稱。 此外本文大多數觀點來自於大師呂海波《Oracle內核技術揭秘》一書，本博文為個人感想。 首先需要明確4點關於CBC LATCH和BUFFER PIN的知識點： 1. 對於根塊和枝塊，CBC LATCH都是以S模式獲取的 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類