ZooKeeper管理員指南——部署與管理

轉載請註明：@ni掌櫃 nileader@gmail.com

本文以ZooKeeper3.4.3版本的官方指南為基礎：http://zookeeper.apache.org/doc/r3.4.3/zookeeperAdmin.html，補充一些作者運維實踐中的要點，圍繞ZK的部署和運維兩個方面講一些管理員需要知道的東西。本文並非一個ZK搭建的快速入門，關於這方面，可以檢視《ZooKeeper快速搭建》。

1.部署

本章節主要講述如何部署ZooKeeper，包括以下三部分的內容：

1. 系統環境

2. 叢集模式的配置

3. 單機模式的配置

系統環境和叢集模式配置這兩節內容大體講述瞭如何部署一個能夠用於生產環境的ZK叢集。如果僅僅是想在單機上將ZK執行起來，進行一些開發與測試，那麼第三部分或許是你的菜。

1.1系統環境

1.1.1平臺支援

注：執行client是指作為客戶端，與server進行資料通訊，而執行server是指將ZK作為伺服器部署執行。

1.1.2軟體環境

ZooKeeper Server是一個Java語言實現的分散式協調服務框架，因此需要6或更高版本的JDK支援。叢集的機器數量方面，寬泛的講，其實是任意臺機器都可以部署執行的，注意，這裡並沒有說一定要奇數臺機器哦！通常情況下，建議使用3臺獨立的Linux伺服器構成的一個ZK叢集。

1.2叢集模式的配置

為了確保ZooKeeper服務的穩定與可靠性，通常是搭建成一個ZK叢集來對外提供服務。關於ZooKeeper，需要明確一個很重要的特性：叢集中只要有過半的機器是正常工作的，那麼整個叢集對外就是可用的（本文下面就用“過半存活即可用”來代替這個特性吧^-^）。正是基於這個特性，建議是將ZK叢集的機器數量控制為奇數較為合適。為什麼選擇奇數臺機器，我們可以來看一下，假如是4臺機器構成的ZK叢集，那麼只能夠允許叢集中有一個機器down掉，因為如果down掉2臺，那麼只剩下2臺機器，顯然沒有過半。而如果是5臺機器的叢集，那麼就能夠對2臺機器down掉的情況進行容災了。

你可以按照以下步驟來配置一個ZK機器，更多詳細步驟請檢視《ZooKeeper快速搭建》：

1. 安裝JDK。相關連結：http://java.sun.com/javase/downloads/index.jsp

2. 設定Java heap 大小。避免記憶體與磁碟空間的交換，能夠大大提升ZK的效能，設定合理的heap大小則能有效避免此類空間交換的觸發。在正式釋出上線之前，建議是針對使用場景進行一些壓力測試，確保正常執行後記憶體的使用不會觸發此類交換。通常在一個實體記憶體為4G的機器上，最多設定-Xmx為3G。

3. 下載安裝ZooKeeper，相關連結：http://zookeeper.apache.org/releases.html

4. 配置檔案zoo.cfg。初次使用zookeeper，按照如下這個簡單配置即可：

tickTime=2000 
dataDir=/var/lib/zookeeper/ 
clientPort=2181 
initLimit=5 
syncLimit=2 server.1=zoo1:2888:3888 
server.2=zoo2:2888:3888 
server.3=zoo3:2888:3888 

本文後續章節會對這些引數進行詳細的介紹，這裡只是簡單說幾點：

   A. 叢集中的每臺機器都需要感知整個叢集是由哪幾臺機器組成的，在配置檔案中，可以按照這樣的格式，每行寫一個機器配置：server.id=host:port:port. 關於這個id，我們稱之為Server ID，標識host機器在叢集中的機器序號，在每個ZK機器上，我們需要在資料目錄（資料目錄就是dataDir引數指定的那個目錄）下建立一個myid檔案，myid中就是這個Server ID數字。

   B. 在ZooKeeper的設計中，叢集中任意一臺機器上的zoo.cfg檔案的內容都是一致的。因此最好是用SVN把這個檔案管理起來，保證每個機器都能共享到一份相同的配置。

5. 關於myid檔案。myid檔案中只有一個數字，即一個Server ID。例如，server.1 的myid檔案內容就是“1”。注意，請確保每個server的myid檔案中id數字不同，並且和server.id=host:port:port中的id一致。另外，id的範圍是1~255。

6. 至此，配置檔案基本ok，可以嘗試使用如下命令來啟動zookeeper了：

$ java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf \ org.apache.zookeeper.server.quorum.QuorumPeerMainzoo.cfg 

注意，不同的ZK版本，依賴的log4j和slf4j版本也是不一樣的，請看清楚自己的版本後，再執行上面這個命令。QuorumPeerMain類會啟動ZooKeeper Server，同時，JMX MB也會被啟動，方便管理員在JMX管理控制檯上進行ZK的控制。這裡有對ZK JMX的詳細介紹：http://zookeeper.apache.org/doc/r3.4.3/zookeeperJMX.html.  另外，完全可以有更簡便的方式，直接使用%ZK_HOME%/bin 中的指令碼啟動即可。

./zkServer.sh start 

7. 連線ZK host來檢驗部署是否成功。

   A. Java語言的話，可以通過執行這個命令來檢測：

$ java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf:src/java/lib/jline-0.9.94.jar \ org.apache.zookeeper.ZooKeeperMain -server 127.0.0.1:2181 

   B. 如果是C語言的話，方法如下：

$ make cli_st 
$ make cli_mt 

然後按照的這樣的方式連線ZK：$ cli_mt 127.0.0.1:2181。無論執行哪種客戶端，最終都是一個類似於檔案系統的命令列操作。

注意：除了上面這種檢測方法，其實%ZK_HOME%/bin也有其它指令碼，下面這個命令執行後，就進入了zookeeper樹狀結構的檔案系統中。

./zkCli.sh 

另外，還有一種方式，能夠檢視ZK伺服器當前狀態，如下，這個能夠很好的看出目前這個機器的執行情況了：

$ echo stat|nc localhost 2181 
Zookeeper version: 3.4.3-1240972, built on 02/06/2012 10:48 GMT 
Clients: 
/127.0.0.1:40293[0](queued=0,recved=1,sent=0) 
 
Latency min/avg/max: 1/2/3 
Received: 4 
Sent: 3 
Outstanding: 0 
Zxid: 0×200000006 
Mode: leader 
Node count: 4 

1.3單機模式的配置

如果你想安裝一個ZooKeeper來進行開發測試，通常可以使用單機模式來啟動ZK。大體的步驟和上面說的是一樣了，除了配置檔案會更加簡單一些。詳細的配置方法可以檢視這裡：http://zookeeper.apache.org/doc/r3.4.3/zookeeperStarted.html#sc_InstallingSingleMode

2.運 維

本章節主要要講述如何更好地運維ZooKeepr，大致包含以下幾部分內容：

   2.1. 部署方案的設計

   2.2. 日常運維

   2.3. Server的自檢恢復

   2.4. 監控

   2.5. 日誌管理

   2.6. 資料載入出錯

   2.7. 配置引數詳解

   2.8. 常用的四字命令

   2.9. 資料檔案管理

   2.10. 注意事項

2.1 部署方案的設計

我們常說的ZooKeeper能夠提供高可用分散式協調服務，是要基於以下兩個條件：

    1. 叢集中只有少部分的機器不可用。這裡說的不可用是指這些機器或者是本身down掉了，或者是因為網路原因，有一部分機器無法和叢集中其它絕大部分的機器通訊。例如，如果ZK叢集是跨機房部署的，那麼有可能一些機器所在的機房被隔離了。

   2. 正確部署ZK server，有足夠的磁碟儲存空間以及良好的網路通訊環境。

下面將會從叢集和單機兩個維度來說明，幫助zookeeper管理員儘可能地提高ZK叢集的可用性。

2.1.1叢集維度

在上面提到的“過半存活即可用”特性中已經講到過，整個叢集如果對外要可用的話，那麼叢集中必須要有過半的機器是正常工作並且彼此之間能夠正常通訊。基於這個特性，那麼如果想搭建一個能夠允許F臺機器down掉的叢集，那麼就要部署一個由2xF+1 臺機器構成的ZK叢集。因此，一個由3臺機器構成的ZK叢集，能夠在down掉一臺機器後依然正常工作，而5臺機器的叢集，能夠對兩臺機器down掉的情況容災。注意，如果是一個6臺機器構成的ZK叢集，同樣只能夠down掉兩臺機器，因為如果down掉3臺，剩下的機器就沒有過半了。基於這個原因，ZK叢集通常設計部署成奇數臺機器。

所以，為了儘可能地提高ZK叢集的可用性，應該儘量避免一大批機器同時down掉的風險，換句話說，最好能夠為每臺機器配置互相獨立的硬體環境。舉個例子，如果大部分的機器都掛在同一個交換機上，那麼這個交換機一旦出現問題，將會對整個叢集的服務造成嚴重的影響。其它類似的還有諸如：供電線路，散熱系統等。其實在真正的實踐過程中，如果條件允許，通常都建議嘗試跨機房部署。畢竟多個機房同時發生故障的機率還是挺小的。

2.1.2 單機維度

對於ZK來說，如果在執行過程中，需要和其它應用程式來競爭磁碟，CPU，網路或是記憶體資源的話，那麼整體效能將會大打折扣。

首先來看看磁碟對於ZK效能的影響。客戶端對ZK的更新操作都是永久的，不可回退的，也就是說，一旦客戶端收到一個來自server操作成功的響應，那麼這個變更就永久生效了。為做到這點，ZK會將每次更新操作以事務日誌的形式寫入磁碟，寫入成功後才會給予客戶端響應。明白這點之後，你就會明白磁碟的吞吐效能對於ZK的影響了，磁碟寫入速度制約著ZK每個更新操作的響應。為了儘量減少ZK在讀寫磁碟上的效能損失，不仿試試下面說的幾點：

   A、使用單獨的磁碟作為事務日誌的輸出（比如我們這裡的ZK叢集，使用單獨的掛載點用於事務日誌的輸出）。事務日誌的寫效能確實對ZK效能，尤其是更新操作的效能影響很大，所以想辦法搞到一個單獨的磁碟吧！ZK的事務日誌輸出是一個順序寫檔案的過程，本身效能是很高的，所以儘量保證不要和其它隨機寫的應用程式共享一塊磁碟，儘量避免對磁碟的競爭。

   B、儘量避免記憶體與磁碟空間的交換。如果希望ZK能夠提供完全實時的服務的話，那麼基本是不允許作業系統觸發此類swap的。因此在分配JVM堆大小的時候一定要非常小心，具體在本文最後的“注意事項”章節中有講到。

2.2 日常運維

對zookeeper運維是一個長期積累經驗的過程，希望以下幾點對廣大ZK運維人員有一定的幫助：

2.2.1 清理資料目錄

上文中提到dataDir目錄指定了ZK的資料目錄，用於儲存ZK的快照檔案（snapshot）。另外，預設情況下，ZK的事務日誌也會儲存在這個目錄中。在完成若干次事務日誌之後（在ZK中，凡是對資料有更新的操作，比如建立節點，刪除節點或是對節點資料內容進行更新等，都會記錄事務日誌），ZK會觸發一次快照（snapshot），將當前server上所有節點的狀態以快照檔案的形式dump到磁碟上去，即snapshot檔案。這裡的若干次事務日誌是可以配置的，預設是100000，具體參看下文中關於配置引數“snapCount”的介紹。

考慮到ZK執行環境的差異性，以及對於這些歷史檔案，不同的管理員可能有自己的用途（例如作為資料備份），因此預設ZK是不會自動清理快照和事務日誌，需要交給管理員自己來處理。這裡是我們用的清理方法，保留最新的66個檔案，將它寫到crontab中，每天凌晨2點觸發一次：

#!/bin/bash 
 
#snapshot file dir 
dataDir=/home/yinshi.nc/test/zk_data/version-2 
#tran log dir 
dataLogDir=/home/yinshi.nc/test/zk_log/version-2 
#zk log dir 
logDir=/home/yinshi.nc/test/logs 
#Leave 66 files 
count=66 
count=$[$count+1] 
ls -t $dataLogDir/log.* | tail -n +$count | xargs rm -f 
ls -t $dataDir/snapshot.* | tail -n +$count | xargs rm -f 
ls -t $logDir/zookeeper.log.* | tail -n +$count | xargs rm -f 
 
#find /home/yinshi.nc/taokeeper/zk_data/version-2 -name “snap*” -mtime +1 | xargs rm -f 
#find /home/yinshi.nc/taokeeper/zk_logs/version-2 -name “log*” -mtime +1 | xargs rm -f 
#find /home/yinshi.nc/taokeeper/logs/ -name “zookeeper.log.*” -mtime +1 | xargs rm –f 

其實，僅管ZK沒有自動幫我們清理歷史檔案，但是它的還是提供了一個叫PurgeTxnLog的 工具類，實現了一種簡單的歷史檔案清理策略，可以在這裡看一下他的使用方法：http://zookeeper.apache.org/doc/r3.4.3/api/index.html簡單使用如下：

java -cp zookeeper.jar:lib/slf4j-api-1.6.1.jar:lib/slf4j-log4j12-1.6.1.jar:lib/log4j-1.2.15.jar:conf org.apache.zookeeper.server.PurgeTxnLog<dataDir><snapDir> -n <count> 

最後一個參數列示希望保留的歷史檔案個數，注意，count必須是大於3的整數。可以把這句命令寫成一個定時任務，以便每天定時執行清理。

注意： 從3.4.0版本開始， zookeeper提供了自己清理歷史檔案的功能了，相關的配置引數是autopurge.snapRetainCount和autopurge.purgeInterval，在本文後面會具體說明。更多關於zookeeper的日誌清理，可以閱讀這個文章《ZooKeeper日誌清理》。

2.2.2 ZK程式日誌

這裡說兩點，ZK預設是沒有向ROLLINGFILE檔案輸出程式執行時日誌的，需要我們自己在conf/log4j.properties中配置日誌路徑。另外，沒有特殊要求的話，日誌級別設定為INFO或以上，我曾經測試過，日誌級別設定為DEBUG的話，效能影響很大！

2.3 Server的自檢恢復

ZK執行過程中，如果出現一些無法處理的異常，會直接退出程式，也就是所謂的快速失敗（fail fast）模式。在上文中有提到，“過半存活即可用”的特性使得叢集中少數機器down掉後，整個叢集還是可以對外正常提供服務的。另外，這些down掉的機器重啟之後，能夠自動加入到叢集中，並且自動和叢集中其它機器進行狀態同步（主要就是從Leader那裡同步最新的資料），從而達到自我恢復的目的。

因此，我們很容易就可以想到，是否可以藉助一些工具來自動完成機器的狀態檢測與重啟工作。回答是肯定的，這裡推薦兩個工具： Daemontools(http://cr.yp.to/daemontools.html) 和 SMF（http://en.wikipedia.org/wiki/Service_Management_Facility），能夠幫助你監控ZK程式，一旦程式退出後，能夠自動重啟程式，從而使down掉的機器能夠重新加入到叢集中去~

2.4 監控

有幾種方法：

    1、 ZK提供一些簡單但是功能強大的4字命令，通過對這些4字命令的返回內容進行解析，可以獲取不少關於ZK執行時的資訊。

    2、用jmx也能夠獲取一些執行時資訊，詳細可以檢視這裡：http://zookeeper.apache.org/doc/r3.4.3/zookeeperJMX.html

    3、淘寶網已經實現的一個ZooKeeper監控——TaoKeeper，已開源，在這裡：http://rdc.taobao.com/team/jm/archives/1450，主要功能如下:

       A、機器CPU/MEM/LOAD的監控

       B、ZK日誌目錄所在磁碟空間監控

       C、單機連線數的峰值報警

       D、單機Watcher數的峰值報警

       E、節點自檢

       F、ZK執行時資訊展示

2.5 日誌管理

ZK使用log4j作為日誌系統，conf目錄中有一份預設的log4j配置檔案，注意，這個配置檔案中還沒有開啟ROLLINGFILE檔案輸出，配置下即可。其它關於log4j的詳細介紹，可以移步到log4j的官網：http://logging.apache.org/log4j/1.2/manual.html#defaultInit

2.6載入資料出錯

ZK在啟動的過程中，首先會根據事務日誌中的事務日誌記錄，從本地磁碟載入最後一次提交時候的快照資料，如果讀取事務日誌出錯或是其它問題（通常在日誌中可以看到一些IO異常），將導致server將無法啟動。碰到類似於這種資料檔案出錯導致無法啟動伺服器的情況，一般按照如下順序來恢復：

    1、確認叢集中其它機器是否正常工作，方法是使用“stat”這個命令來檢查：echo stat|nc ip 2181

    2、如果確認其它機器是正常工作的（這裡要說明下，所謂正常工作還是指叢集中有過半機器可用），那麼可以開始刪除本機的一些資料了，刪除$dataDir/version-2和$dataLogDir/version-2 兩個目錄下的所有檔案。

重啟server。重啟之後，這個機器就會從Leader那裡同步到最新資料，然後重新加入到叢集中提供服務。

2.7 配置引數詳解(主要是%ZOOKEEPER_HOME%/conf/zoo.cfg檔案)

2.8 常用的四字命令

$>echo conf|nc localhost 2181 
clientPort=2181 
dataDir=/home/test/taokeeper/zk_data/version-2 
dataLogDir=/test/admin/taokeeper/zk_log/version-2 
tickTime=2000 
maxClientCnxns=1000 
minSessionTimeout=4000 
maxSessionTimeout=40000 
serverId=2 
initLimit=10 
syncLimit=5 
electionAlg=3 
electionPort=3888 
quorumPort=2888 
peerType=0 

$>echo cons|nc localhost 2181 
/1.2.3.4:43527[1](queued=0,recved=152802,sent=152806,sid=0x2389e662b98c424,lop=PING,est=1350385542196,to=6000,lcxid=0×114,lzxid=0xffffffffffffffff,lresp=1350690663308,llat=0,minlat=0,avglat=0,maxlat=483) 
…… 

$>echo stat|nc localhost 2181 
Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT 
Clients: 
/10.2.3.4:59179[1](queued=0,recved=44845,sent=44845) 
 
Latency min/avg/max: 0/0/1036 
Received: 2274602238 
Sent: 2277795620 
Outstanding: 0 
Zxid: 0xa1b3503dd 
Mode: leader 
Node count: 37473 

$>echo srvr|nc localhost 2181 
Zookeeper version: 3.3.5-1301095, built on 03/15/2012 19:48 GMT 
Latency min/avg/max: 0/0/980 
Received: 2592698547 
Sent: 2597713974 
Outstanding: 0 
Zxid: 0xa1b356b5b 
Mode: follower 
Node count: 37473 

$>echo wchs|nc localhost 2181 
3890 connections watching 537 paths 
Total watches:6909 

$>echo wchc|nc localhost 2181 
0x2389e662b97917f 
/mytest/test/path1/node1 
0x3389e65c83cd790 
/mytest/test/path1/node2 
0x1389e65c7ef6313 
/mytest/test/path1/node3 
/mytest/test/path1/node1 

$>echo wchp|nc localhost 2181 
/mytest/test/path1/node 
0x1389e65c7eea4f5 
0x1389e65c7ee2f68 
/mytest/test/path1/node2 
0x2389e662b967c29 
/mytest/test/path1/node3 
0x3389e65c83dd2e0 
0x1389e65c7f0c37c 
0x1389e65c7f0c364 

$ echo mntr | nc localhost 2185 
zk_version 3.4.0 
zk_avg_latency 0 
zk_max_latency 0 
zk_min_latency 0 
zk_packets_received 70 
zk_packets_sent 69 
zk_outstanding_requests 0 
zk_server_state leader 
zk_znode_count 4 
zk_watch_count 0 
zk_ephemerals_count 0 
zk_approximate_data_size 27 
zk_followers 4 – only exposed by the Leader 
zk_synced_followers 4 – only exposed by the Leader 
zk_pending_syncs 0 – only exposed by the Leader 
zk_open_file_descriptor_count 23 – only available on Unix platforms 
zk_max_file_descriptor_count 1024 – only available on Unix platforms 

2.9 資料檔案管理

預設情況下，ZK的資料檔案和事務日誌是儲存在同一個目錄中，建議是將事務日誌儲存到單獨的磁碟上。

2.9.1資料目錄

ZK的資料目錄包含兩類檔案：

    A、myid – 這個檔案只包含一個數字，和server id對應。

    B、snapshot. - 按zxid先後順序的生成的資料快照。

叢集中的每臺ZK server都會有一個用於惟一標識自己的id，有兩個地方會使用到這個id：myid檔案和zoo.cfg檔案中。myid檔案儲存在dataDir目錄中，指定了當前server的server id。在zoo.cfg檔案中，根據server id，配置了每個server的ip和相應埠。Zookeeper啟動的時候，讀取myid檔案中的server id，然後去zoo.cfg 中查詢對應的配置。

zookeeper在進行資料快照過程中，會生成 snapshot檔案，儲存在dataDir目錄中。檔案字尾是zxid，也就是事務id。（這個zxid代表了zk觸發快照那個瞬間，提交的最後一個事務id）。注意，一個快照檔案中的資料內容和提交第zxid個事務時記憶體中資料近似相同。僅管如此，由於更新操作的冪等性，ZK還是能夠從快照檔案中恢復資料。資料恢復過程中，將事務日誌和快照檔案中的資料對應起來，就能夠恢復最後一次更新後的資料了。

2.9.2事務日誌目錄

dataLogDir目錄是ZK的事務日誌目錄，包含了所有ZK的事務日誌。正常執行過程中，針對所有更新操作，在返回客戶端“更新成功”的響應前，ZK會確保已經將本次更新操作的事務日誌寫到磁碟上，只有這樣，整個更新操作才會生效。每觸發一次資料快照，就會生成一個新的事務日誌。事務日誌的檔名是log.，zxid是寫入這個檔案的第一個事務id。

2.9.3檔案管理

不同的zookeeper server生成的snapshot檔案和事務日誌檔案的格式都是一致的（無論是什麼環境，或是什麼樣的zoo.cfg 配置）。因此，如果某一天生產環境中出現一些古怪的問題，你就可以把這些檔案下載到開發環境的zookeeper中載入起來，便於除錯發現問題，而不會影響生產執行。另外，使用這些較舊的snapshot和事務日誌，我們還能夠方便的讓ZK回滾到一個歷史狀態。

另外，ZK提供的工具類LogFormatter能夠幫助視覺化ZK的事務日誌，幫助我們排查問題，關於事務日誌的可以化，請檢視這個文章《視覺化zookeeper的事務日誌》.

需要注意的一點是，zookeeper在執行過程中，不斷地生成snapshot檔案和事務日誌，但是不會自動清理它們，需要管理員來處理。（ZK本身只需要使用最新的snapshot和事務日誌即可）關於如何清理檔案，上面章節“日常運維”有提到。

2.10 注意事項

2.10.1 保持Server地址列表一致

    A、客戶端使用的server地址列表必須和叢集所有server的地址列表一致。（如果客戶端配置了叢集機器列表的子集的話，也是沒有問題的，只是少了客戶端的容災。）

    B、叢集中每個server的zoo.cfg中配置機器列表必須一致。

2.10.2 獨立的事務日誌輸出

對於每個更新操作，ZK都會在確保事務日誌已經落盤後，才會返回客戶端響應。因此事務日誌的輸出效能在很大程度上影響ZK的整體吞吐效能。強烈建議是給事務日誌的輸出分配一個單獨的磁碟。

2.10.3 配置合理的JVM堆大小

確保設定一個合理的JVM堆大小，如果設定太大，會讓記憶體與磁碟進行交換，這將使ZK的效能大打折扣。例如一個4G記憶體的機器的，如果你把JVM的堆大小設定為4G或更大，那麼會使頻繁發生記憶體與磁碟空間的交換，通常設定成3G就可以了。當然，為了獲得一個最好的堆大小值，在特定的使用場景下進行一些壓力測試。

本文出自 “ni掌櫃部落格” 部落格，請務必保留此出處http://nileader.blog.51cto.com/1381108/1032157