spark 基於ZooKeeper實現HA高可用性以及自動主備切換

北風網spark學習筆記

默認情況下，standalone cluster manager對於worker節點的失敗是具有容錯性的（迄今爲止，Spark自身而言對於丟失部分計算工作是有容錯性的，它會將丟失的計算工作遷移到其他worker節點上執行）。然而，調度器是依託於master進程來做出調度決策的，這就會造成單點故障：如果master掛掉了，就沒法提交新的應用程序了。爲了解決這個問題，spark提供了兩種高可用性方案，分別是基於zookeeper的HA方案以及基於文件系統的HA方案。

基於zookeeper的HA方案

概述

使用zookeeper來提供leader選舉以及一些狀態存儲，你可以在集羣中啓動多個master進程，讓它們連接到zookeeper實例。其中一個master進程會被選舉爲leader，其他的master會被指定爲standby模式。如果當前的leader master進程掛掉了，其他的standby master``會被選舉，從而恢復舊master的狀態。並且恢復作業調度。整個恢復過程（從leader master掛掉開始計算）大概會花費1~2分鐘。要注意的是，這隻會推遲調度新的應用程序，master掛掉之前就運行的應用程序是不被影響的。

配置

如果要啓用這個恢復模式，需要在spark-env.sh文件中，設置SPARK_DAEMON_JAVA_OPTS選項：

spark.deploy.recoveryMode		# 設置爲ZOOKEEPER來啓用standby master恢復模式（默認爲NONE）
spark.deploy.zookeeper.url		# zookeeper集羣url（舉例來說，192.168.75.101:2181,192.168.75.102:2181）
spark.deploy.zookeeper.dir		# zookeeper中用來存儲恢復狀態的目錄（默認是/spark）

備註：如果在集羣中啓動了多個master節點，但是沒有正確配置master去使用zookeeper，master在掛掉進行恢復時是會失敗的，因爲沒法發現其他master，並且都會認爲自己是leader。這會導致集羣的狀態不是健康的，因爲所有master都會自顧自地去調度。

細節

• 在啓動一個zookeeper集羣之後，啓用高可用性是很直接的。簡單地在多個節點上啓動多個master進程，並且給它們相同的zookeeper配置（zookeeper url和目錄）。master就可以被動態加入master集羣，並可以在任何時間被移除掉。
• 爲了調度新的應用程序或者向集羣中添加worker節點，它們需要知道當前leader master的ip地址。這可以通過傳遞一個master列表來完成。舉例來說，我們可以將我們的SparkContext連接的地址指向spark://host1:port1,host2:port2。這就會導致你的SparkContext嘗試去註冊所有的master，如果host1掛掉了，那麼配置還是正確的，因爲會找到新的leader master，也就是host2。
• 對於註冊一個master和普通的操作，這是一個重要的區別。當一個應用程序啓動的時候，或者worker需要被找到並且註冊到當前的leader master的時候。一旦它成功註冊了，就被保存在zookeeper中了。如果故障發生了，new leader master會去聯繫所有的之前註冊過的應用程序和worker，並且通知它們master的改變。這樣的話，它們甚至在啓動的時候都不需要知道new master的存在。
• 正是由於這個屬性，new master可以在任何時間被創建，並且我們唯一需要擔心的一件事情就是新的應用程序和worker可以找到並且註冊到master。一旦註冊上去之後，我們就不用擔心它了。

實驗

• 將192.168.75.101機器上的spark集羣先停止

  ./sbin/stop-all.sh
  

• 修改機器上的spark-env.sh文件，在其中加入上述三個屬性

  export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=192.168.75.101:2181,192.168.75.102:2181 -Dspark.deploy.zookeeper.dir=/spark"
  

• 啓動集羣
  在192.168.75.101上直接用啓動集羣：./sbin/start-all.sh

• 在192.168.75.102上部署spark安裝包，並啓動一個master進程

安裝scala 2.11.4

1. 將課程提供的scala-2.11.4.tgz使用WinSCP拷貝到/usr/local/src目錄下。

2. 對scala-2.11.4.tgz進行解壓縮：tar -zxvf scala-2.11.4.tgz

3. 對scala目錄進行重命名：mv scala-2.11.4 scala

4. 配置scala相關的環境變量

   vi ~/.bashrc
   export SCALA_HOME=/usr/local/scala
   export PATH=$SCALA_HOME/bin
   source ~/.bashrc
   

5. 查看scala是否安裝成功：scala -version

安裝spark客戶端

1. 將spark-1.5.1-bin-hadoop2.4.tgz使用WinSCP上傳到/usr/local/src目錄下。

2. 解壓縮spark包：tar -zxvf spark-1.5.1-bin-hadoop2.4.tgz。

3. 重命名spark目錄：mv spark-1.5.1-bin-hadoop2.4 spark

4. 修改spark環境變量

   vi ~/.bashrc
   export SPARK_HOME=/usr/local/spark
   export PATH=$SPARK_HOME/bin
   export CLASSPATH=.:$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
   source ~/.bashrc
   

修改spark-env.sh文件

cd /usr/local/spark/conf
cp spark-env.sh.template spark-env.sh
vi spark-env.sh
export JAVA_HOME=/usr/java/latest
export SCALA_HOME=/usr/local/scala
export HADOOP_HOME=/usr/local/hadoop
export HADOOP_CONF_DIR=/usr/local/hadoop/etc/hadoop
export SPARK_MASTER_IP=192.168.75.102
export SPARK_DAEMON_MEMORY=100m
export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER -Dspark.deploy.zookeeper.url=192.168.75.101:2181,192.168.75.102:2181 -Dspark.deploy.zookeeper.dir=/spark"

在192.168.1.102上單獨啓動一個standby master進程：./sbin/start-master.sh

• 提交應用程序

  將master地址修改爲192.168.75.101:7077,192.168.75.102:7078

• 殺掉原先的leader master，等到standby master接管集羣，再次提交應用程序

• 再次手動啓動原來的leader master（死掉）

基於文件系統的HA方案

zookeeper是實現生產級別的高可用性的最佳方式，但是如果你就是想要在master進程掛掉的時候，手動去重啓它，而不是依靠zookeeper實現自動主備切換，那麼可以使用FILESYSTEM模式。當應用程序和worker都註冊到master之後，master就會將它們的信息寫入指定的文件系統目錄中，以便於當master重啓的時候可以從文件系統中恢復註冊的應用程序和worker狀態。

配置

要啓用這種恢復模式，需要在spark-env.sh中設置SPARK_DAEMON_JAVA_OPTS

spark.deploy.recoveryMode		# 設置爲FILESYSTEM來啓用單點恢復（默認值爲NONE）
spark.deploy.recoveryDirectory	# spark在哪個文件系統目錄內存儲狀態信息，必須是master可以訪問的目錄

細節

1. 這個解決方案可以與進程監控或管理器（比如monit）結合使用，或者就僅僅是啓用手動重啓恢復機制即可。
2. 文件系統恢復比不做任何恢復機制肯定是要好的，這個模式更加適合於開發和測試環境，而不是生產環境。此外，通過stop-master.sh腳本殺掉一個master進程是不會清理它的恢復狀態的，所以當你重啓一個新的master進程時，它會進入恢復模式。這會增加你的恢復時間至少1分鐘，因爲它需要等待之前所有已經註冊的worker等節點先timeout。
3. 這種方式沒有得到官方的支持，也可以使用一個NFS目錄作爲恢復目錄。如果原先的master節點完全死掉了，你可以在其他節點上啓動一個master進程，它會正確地恢復之前所有註冊的worker和應用程序。之後的應用程序可以找到新的master，然後註冊。

實驗

1. 關閉兩臺機器上的master和worker

2. 修改192.168.75.101機器上的spark-env.sh

   export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=FILESYSTEM -Dspark.deploy.recoveryDirectory=/usr/local/spark_recovery"
   

3. 在`192.168.75.101上啓動spark集羣

4. 在spark-shell中進行wordcount計數，到一半，有一個running application

5. 殺掉master進程

6. 重啓master進程

7. 觀察web ui上，是否恢復了worker以及原先正在運行的application