Apache > Hadoop > ZooKeeper
 

ZooKeeper 管理者ガイド

デプロイメントと管理のためのガイド

デプロイメント

ここでは、ZooKeeper のデプロイメントについて説明します。取り上げるトピックは次のとおりです。

最初の 2 つのトピックは、データセンターなどの実働環境への ZooKeeper のインストールに関心があるユーザーを対象としています。最後のトピックは、評価やテスト、開発など、実働環境ではない、限定された目的で ZooKeeper をセットアップするユーザーを対象としています。

必要システム

サポートされるプラットフォーム

  • GNU/Linux は、サーバーとクライアントのどちらについても、開発プラットフォームおよび実用プラットフォームとしてサポートされています。

  • Sun Solaris は、サーバーとクライアントのどちらについても、開発プラットフォームおよび実用プラットフォームとしてサポートされています。

  • FreeBSD は、クライアントについてのみ、開発プラットフォームおよび実用プラットフォームとしてサポートされています。FreeBSD JVM の Java NIO セレクタサポートには問題があります。

  • Win32 は、サーバーとクライアントのどちらについても、開発プラットフォームとしてのみサポートされています。

  • MacOSX は、サーバーとクライアントのどちらについても、開発プラットフォームとしてのみサポートされています。

必要なソフトウェア

ZooKeeper は、リリース 1.6 またはそれ以降の Java (JDK 6 以上) で動作します。ZooKeeper は、複数の ZooKeeper サーバーのアンサンブルとして実行されます。アンサンブルの最低推奨サイズは ZooKeeper サーバー 3 つで、さらにこれらのサーバーをそれぞれ独立したマシンで実行することが推奨されます。Yahoo! では、ZooKeeper は通常、デュアルコアプロセッサ、2GB の RAM、80GB の IDE ハードドライブを搭載した複数の専用 RHEL マシンにデプロイされています。

クラスタ (マルチサーバー) セットアップ

信頼性の高い ZooKeeper サービスを提供するには、アンサンブルと呼ばれるクラスタに ZooKeeper をデプロイする必要があります。アンサンブルの過半数が動作している限り、ZooKeeper サービスは利用可能です。ZooKeeper では過半数が必要になるので、奇数台のマシンを使うのがベストです。たとえば 4 台のマシンを使う場合、ZooKeeper が対応できるのはマシン 1 台の障害までです。なぜなら、2 台のマシンに障害が発生すると、残りの 2 台では過半数にならないためです。一方、5 台のマシンを使えば、ZooKeeper はマシン 2 台までの障害に対応できます。

アンサンブルを構成するサーバーの設定手順は、次のとおりです。この手順は、アンサンブル内のすべてのホストで実行する必要があります。

  1. Java JDK をインストールします。使用しているシステム用のネイティブパッケージを使用できます。また、次のところから JDK をダウンロードすることもできます。

    http://java.sun.com/javase/downloads/index.jsp

  2. Java のヒープサイズを設定します。これはスワップを発生させないようにするために非常に重要なポイントです。スワップが発生すると、ZooKeeper のパフォーマンスは著しく低下します。適切な値を決定するには、負荷テストを実施し、スワップが発生する限界の値より大幅に低い値を設定します。値は控え目に設定します。たとえば、4GB のメモリを搭載したマシンでは、3GB を最大ヒープサイズとして使います。

  3. ZooKeeper サーバーパッケージをインストールします。ZooKeeper サーバーパッケージは次のところからダウンロードできます。

    http://hadoop.apache.org/zookeeper/releases.html

  4. 設定ファイルを作成します。ファイル名は何でもかまいません。次に示す設定を出発点として使ってください。

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

    各設定およびその他の設定の意味については、あとの「設定パラメータ」で詳しく説明しています。ここでは、いくつかの点について補足しておきます。

    ZooKeeper アンサンブルを構成する各マシンは、アンサンブル内のほかのすべてのマシンについても知っている必要があります。これを行うのが、server.id=host:port:port という形式で記述された一連の行です。パラメータ hostport については、説明の必要はないでしょう。各マシンにサーバー id を割り当てるには、サーバーごとに 1 つ、myid という名前のファイルを、そのサーバーのデータディレクトリに作成します。データディレクトリは、設定ファイルのパラメータ dataDir で指定します。

  5. myid ファイルは、そのマシンの id のテキストだけを含む 1 行のファイルです。したがって、サーバー 1 の myid には、"1" というテキストが含まれ、それ以外には何も含まれないことになります。id はアンサンブル内で一意でなければならず、値は 1 から 255 までである必要があります。

  6. 設定ファイルをセットアップしたら、次の要領で ZooKeeper サーバーを起動できます。

    $ java -cp zookeeper.jar:lib/log4j-1.2.15.jar:conf \ org.apache.zookeeper.server.quorum.QuorumPeerMain zoo.cfg

    QuorumPeerMain が ZooKeeper サーバーを起動し、JMX 管理ビーンが登録されて、JMX 管理コンソールを介した管理が可能になります。JMX で ZooKeeper を管理する方法の詳細については、ZooKeeper JMX のドキュメントを参照してください。

    サーバーインスタンスの起動例については、リリースに含まれているスクリプト bin/zkServer.sh を参照してください。

  7. ホストに接続してデプロイメントをテストします。

    • Java では、次のコマンドを実行すると、簡単な操作を行うことができるようになります。

      $ java -cp zookeeper.jar:src/java/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

    • C では、シングルスレッドクライアントまたはマルチスレッドクライアントをコンパイルできます。これらのソースは、ZooKeeper ソースの c サブディレクトリにあります。次のコマンドを実行すると、シングルスレッドクライアントが作成されます。

      $ make cli_st

      また、次のコマンドを実行すると、マルチスレッドクライアントが作成されます。

      $ make cli_mt

    どちらのプログラムを実行してもシェルが立ち上がり、ファイルシステムでの操作に似た処理を行うことができるようになります。たとえば、マルチスレッドクライアントで ZooKeeper に接続するには、次のコマンドを実行します。

    $ cli_mt 127.0.0.1:2181

シングルサーバーでの開発者向けセットアップ

開発のために ZooKeeper をインストールするときは、開発用のマシンに ZooKeeper のシングルサーバーインスタンスをセットアップし、Java または C のクライアントサイドライブラリとバインディングをインストールすると便利です。

シングルサーバーインスタンスのセットアップ手順はすでに述べた手順と同じで、設定ファイルだけがよりシンプルなものになります。詳しい手順については、「ZooKeeper スタートガイド」の「スタンドアロンモードでの実行」を参照してください。

クライアントサイドライブラリのインストール方法については、「ZooKeeper プログラマーズガイド」の「バインディング」を参照してください。

管理

ここでは、ZooKeeper の実行と保守ついて説明します。取り上げるトピックは次のとおりです。

ZooKeeper デプロイメントの設計

ZooKeeper での信頼性は、次の 2 つことを前提としています。

  1. デプロイメントのうち少数のマシンだけが障害を起こす。ここでいう障害とは、マシンのクラッシュや、マシンがほかの大多数のサーバーから切り離される一部のネットワークエラーを意味している。

  2. デプロイされたマシンは正常に動作する。正常に動作するとは、コードを正常に実行すること、適切に動作するクロックを持っていること、一貫した動作をするストレージおよびネットワークコンポーネントを持っていることを意味している。

以下では、上の前提の実現可能性を最大限に高めるために、ZooKeeper 管理者が考慮すべき事項について説明します。これらの事項の中には、複数のマシンにまたがるものと、デプロイする各マシンに関係するものがあります。

複数のマシンにまたがる要件

ZooKeeper サービスがアクティブであるためには、障害の発生していない、互いに通信可能なマシンが過半数存在していなければなりません。したがって、F 台のマシンの障害に対応できるデプロイメントを作成するには、2xF+1 台のマシンをデプロイする必要があります。たとえば、3 台のマシンで構成されるデプロイメントは 1 台の障害に対応でき、5 台のマシンで構成されるデプロイメントは 2 台の障害に対応できます。6 台のマシンで構成されるデプロイメントの場合、3 台のマシンでは過半数にならないので、対応できるのは 2 台の障害までであることに注意してください。このような理由から、ZooKeeper デプロイメントは通常、奇数台のマシンで構成します。

耐障害性を最大限に高めるには、マシンの障害をそのマシンだけにとどめるための工夫が必要です。たとえば、マシンの大半が同じスイッチを使っている場合、そのスイッチが故障すると、障害がほかに飛び火して、ZooKeeper サービスがダウンするおそれがあります。複数のマシンが電源供給回路や冷却システムなどを共有している場合も同じです。

単一マシンの要件

ストレージメディアや CPU、ネットワーク、メモリといった資源へのアクセスを、ZooKeeper とほかのアプリケーションが取り合うような状況下では、ZooKeeper のパフォーマンスは大幅に低下します。ZooKeeper は高い持続性を保証していますが、それを可能にしているのは、ストレージメディアを使って変更内容を記録してから、実際に変更を行う操作を完了するようにしているからです。このような依存関係をふまえた上で、ZooKeeper の操作がマシンのメディアによって阻害されることがないように注意する必要があります。パフォーマンスの低下を避けるために、次のような措置を講じることができます。

  • ZooKeeper のトランザクションログは専用のデバイスに置かなければなりません (専用のパーティションでは不十分です)。ZooKeeper はトランザクションログをシーケンシャルに書き込み、シークを行いません。ログデバイスをほかのプロセスと共有すると、シークや競合が発生し、数秒の遅延が生じるおそれがあります。

  • スワップが発生するような状況で ZooKeeper を実行しないでください。あらゆる種類の適時性を保ったまま ZooKeeper を動作させるには、ZooKeeper をスワップさせないことが絶対条件です。したがって、ZooKeeper に割り当てる最大ヒープサイズは、ZooKeeper が利用できる実メモリを決して超えないようにしてください。詳細については、あとの「避けるべきこと」を参照してください。

プロビジョニング

考慮すべきこと: ZooKeeper の長所と限界

運用

保守

ZooKeeper クラスタでは、長期保守はほとんど必要ありませんが、以下の点に注意する必要があります。

現在使用中のデータディレクトリのクリーンアップ

ZooKeeper のデータディレクトリには、特定のサービス提供アンサンブルが格納しているすべての znode の永続コピーであるファイルが置かれます。これらのファイルは、スナップショットファイルとトランザクションログファイルです。znode に変更が加えられると、これらの変更はトランザクションログに追記され、時折、ログのサイズが大きくなった時点で、すべての znode の現在の状態のスナップショットがファイルシステムに書き込まれます。このスナップショットは、それ以前のすべてのログに置き換わるものです。

ZooKeeper サーバーは、古いスナップショットとログファイルを削除しません。ファイルを削除するのは運用担当者の役割です。サービスの提供環境はそれぞれに異なるので、これらのファイルを管理するための要件も、インストールの形態によって異なるのがふつうです (バックアップなど)。

PurgeTxnLog ユーティリティは、管理者が使用できる簡単な保持ポリシーを実装しています。呼び出し方 (引数その他) の詳細については、API ドキュメントを参照してください。

次に示す例では、最新の <count> 個のスナップショットとこれらに対応するログを保持し、その他のファイルは削除します。通常、<count> の値は 3 より大きくする必要があります (これは必須ではありませんが、最新のログが破損するなど、ごくまれに起こる事態でも、3 つのバックアップが確保できることになります)。このコマンドを ZooKeeper サーバーマシン上で cron ジョブとして実行すれば、ログを毎日クリーンアップすることができます。

 java -cp zookeeper.jar:log4j.jar:conf org.apache.zookeeper.server.PurgeTxnLog <dataDir> <snapDir> -n <count>

デバッグログのクリーンアップ (log4j)

あとの「ログ記録」を参照してください。デバッグログについては、log4j の組み込み機能を使ってローリングファイルアペンダをセットアップすることを想定しています。セットアップ例については、リリース tarball に含まれている設定ファイルのサンプル conf/log4j.properties を参照してください。

スーパーバイザ

各 ZooKeeper サーバープロセス (JVM) を管理するスーパーバイザプロセスを用意すると便利です。ZooKeeper サーバーは、「フェイルファスト (fail fast)」を実現するように設計されています。これは、回復不可能なエラーが発生した場合に、ZooKeeper サーバーがシャットダウン (プロセス終了) することを意味しています。ZooKeeper サービス提供クラスタは信頼性が高いので、サーバーがダウンしても、クラスタ全体は依然アクティブな状態にとどまり、リクエストを処理します。また、クラスタは「自己回復 (self healing)」するので、障害でダウンしたサーバーも、再起動後は人手による介入なしに自動的にアンサンブルに再参加します。

daemontoolsSMF など、ZooKeeper サーバーを管理するスーパーバイザプロセスを用意すると、サーバープロセスが異常終了した場合に、自動的に再起動させ、速やかにクラスタに再参加させることができます (例として挙げた daemontools と SMF 以外にも、さまざまなものをスーパーバイザプロセスとして使用できます。どれを使うかは管理者次第です)。

監視

ZooKeeper サービスは、1) 4 文字語を使用するコマンドポート、2) JMX、のいずれかの方法で監視できます。使用する環境や要件に応じて、該当するセクションやドキュメントを参照してください。

ログ記録

ZooKeeper は、ログ記録用のインフラとして、log4j バージョン 1.2 を使用しています。ZooKeeper のデフォルトの log4j.properties ファイルは、conf ディレクトリにあります。log4j では、log4j.properties が現在の作業ディレクトリ (ZooKeeper を起動したディレクトリ) に存在するか、またはクラスパスからアクセス可能な場所に存在している必要があります。

詳細については、log4j マニュアルの「Log4j Default Initialization Procedure」を参照してください。

トラブルシューティング

ファイルが破損しているためにサーバーが起動しない

ZooKeeper サーバーのトランザクションログに何らかのファイル破損があると、サーバーがデータベースを読み取ることができず、サーバーが起動しないことがあります。この場合、ZooKeeper データベースをロードするときに IOException が発生します。サーバーが起動しないときは、アンサンブル内のほかのすべてのサーバーが起動して動作していることを確認します。コマンドポートで "stat" コマンドを実行し、ほかのすべてのサーバーが正常に動作していることを確認します。アンサンブル内のほかのすべてのサーバーが正常に動作していることを確認したら、ファイルが破損しているサーバーのデータベースを削除できます。datadir/version-2 と datalogdir/version-2/ 内のすべてのファイルを削除します。サーバーを再起動します。

設定パラメータ

ZooKeeper の動作は、ZooKeeper 設定ファイルで制御します。ZooKeeper 設定ファイルは、ZooKeeper サービスを構成するすべてのサーバーでディスクレイアウトが同じである場合、これらすべてのサーバーで同一の設定ファイルを使用できるように設計されています。サーバーによって異なる設定ファイルを使う場合は、これら異なる設定ファイルのすべてにおいて、サーバーのリストが一致するよう注意しなければなりません。

最小設定

ここでは、設定ファイルで最低限定義しなければならないキーワードについて説明します。

clientPort

クライアントからの接続をリスンするポート、すなわち、クライアントが接続を試みるポートです。

dataDir

ZooKeeper がインメモリデータベースのスナップショットを格納する場所です。ほかに特別の指定がなければ、データベースに対する更新のトランザクションログも、ここで指定された場所に格納されます。

トランザクションログの置き場所には注意してください。一貫して良好なパフォーマンスを確保するためには、トランザクションログ専用のデバイスを用意することが重要です。ビジーなデバイスにトランザクションログを置くと、パフォーマンスが低下します。

tickTime

1 つの tick の長さで、ZooKeeper で使われる基本的な時間の単位 (ミリ秒) です。ハートビートやタイムアウトには、ここで指定する値が利用されます。たとえば、最小セッションタイムアウトは tickTime の 2 倍になります。

高度な設定

The configuration settings in the section are optional. You can use them to further fine tune the behaviour of your ZooKeeper servers. Some can also be set using Java system properties, generally of the form zookeeper.keyword. The exact system property, when available, is noted below.

dataLogDir

(No Java system property)

This option will direct the machine to write the transaction log to the dataLogDir rather than the dataDir. This allows a dedicated log device to be used, and helps avoid competition between logging and snaphots.

Having a dedicated log device has a large impact on throughput and stable latencies. It is highly recommened to dedicate a log device and set dataLogDir to point to a directory on that device, and then make sure to point dataDir to a directory not residing on that device.

globalOutstandingLimit

(Java system property: zookeeper.globalOutstandingLimit.)

Clients can submit requests faster than ZooKeeper can process them, especially if there are a lot of clients. To prevent ZooKeeper from running out of memory due to queued requests, ZooKeeper will throttle clients so that there is no more than globalOutstandingLimit outstanding requests in the system. The default limit is 1,000.

preAllocSize

(Java system property: zookeeper.preAllocSize)

To avoid seeks ZooKeeper allocates space in the transaction log file in blocks of preAllocSize kilobytes. The default block size is 64M. One reason for changing the size of the blocks is to reduce the block size if snapshots are taken more often. (Also, see snapCount).

snapCount

(Java system property: zookeeper.snapCount)

ZooKeeper logs transactions to a transaction log. After snapCount transactions are written to a log file a snapshot is started and a new transaction log file is created. The default snapCount is 100,000.

traceFile

(Java system property: requestTraceFile)

If this option is defined, requests will be will logged to a trace file named traceFile.year.month.day. Use of this option provides useful debugging information, but will impact performance. (Note: The system property has no zookeeper prefix, and the configuration variable name is different from the system property. Yes - it's not consistent, and it's annoying.)

maxClientCnxns

(No Java system property)

Limits the number of concurrent connections (at the socket level) that a single client, identified by IP address, may make to a single member of the ZooKeeper ensemble. This is used to prevent certain classes of DoS attacks, including file descriptor exhaustion. The default is 10. Setting this to 0 entirely removes the limit on concurrent connections.

clientPortBindAddress

New in 3.3.0: the address (ipv4, ipv6 or hostname) to listen for client connections; that is, the address that clients attempt to connect to. This is optional, by default we bind in such a way that any connection to the clientPort for any address/interface/nic on the server will be accepted.

minSessionTimeout

(No Java system property)

New in 3.3.0: the minimum session timeout in milliseconds that the server will allow the client to negotiate. Defaults to 2 times the tickTime.

maxSessionTimeout

(No Java system property)

New in 3.3.0: the maximum session timeout in milliseconds that the server will allow the client to negotiate. Defaults to 20 times the tickTime.

クラスタオプション

The options in this section are designed for use with an ensemble of servers -- that is, when deploying clusters of servers.

electionAlg

(No Java system property)

Election implementation to use. A value of "0" corresponds to the original UDP-based version, "1" corresponds to the non-authenticated UDP-based version of fast leader election, "2" corresponds to the authenticated UDP-based version of fast leader election, and "3" corresponds to TCP-based version of fast leader election. Currently, algorithm 3 is the default

The implementations of leader election 1 and 2 are currently not supported, and we have the intention of deprecating them in the near future. Implementations 0 and 3 are currently supported, and we plan to keep supporting them in the near future. To avoid having to support multiple versions of leader election unecessarily, we may eventually consider deprecating algorithm 0 as well, but we will plan according to the needs of the community.

initLimit

(No Java system property)

Amount of time, in ticks (see tickTime), to allow followers to connect and sync to a leader. Increased this value as needed, if the amount of data managed by ZooKeeper is large.

leaderServes

(Java system property: zookeeper.leaderServes)

Leader accepts client connections. Default value is "yes". The leader machine coordinates updates. For higher update throughput at thes slight expense of read throughput the leader can be configured to not accept clients and focus on coordination. The default to this option is yes, which means that a leader will accept client connections.

Turning on leader selection is highly recommended when you have more than three ZooKeeper servers in an ensemble.

server.x=[hostname]:nnnnn[:nnnnn], etc

(No Java system property)

servers making up the ZooKeeper ensemble. When the server starts up, it determines which server it is by looking for the file myid in the data directory. That file contains the server number, in ASCII, and it should match x in server.x in the left hand side of this setting.

The list of servers that make up ZooKeeper servers that is used by the clients must match the list of ZooKeeper servers that each ZooKeeper server has.

There are two port numbers nnnnn. The first followers use to connect to the leader, and the second is for leader election. The leader election port is only necessary if electionAlg is 1, 2, or 3 (default). If electionAlg is 0, then the second port is not necessary. If you want to test multiple servers on a single machine, then different ports can be used for each server.

syncLimit

(No Java system property)

Amount of time, in ticks (see tickTime), to allow followers to sync with ZooKeeper. If followers fall too far behind a leader, they will be dropped.

group.x=nnnnn[:nnnnn]

(No Java system property)

Enables a hierarchical quorum construction."x" is a group identifier and the numbers following the "=" sign correspond to server identifiers. The left-hand side of the assignment is a colon-separated list of server identifiers. Note that groups must be disjoint and the union of all groups must be the ZooKeeper ensemble.

You will find an example here

weight.x=nnnnn

(No Java system property)

Used along with "group", it assigns a weight to a server when forming quorums. Such a value corresponds to the weight of a server when voting. There are a few parts of ZooKeeper that require voting such as leader election and the atomic broadcast protocol. By default the weight of server is 1. If the configuration defines groups, but not weights, then a value of 1 will be assigned to all servers.

You will find an example here

認証・許可オプション

The options in this section allow control over authentication/authorization performed by the service.

zookeeper.DigestAuthenticationProvider.superDigest

(Java system property only: zookeeper.DigestAuthenticationProvider.superDigest)

By default this feature is disabled

New in 3.2: Enables a ZooKeeper ensemble administrator to access the znode hierarchy as a "super" user. In particular no ACL checking occurs for a user authenticated as super.

org.apache.zookeeper.server.auth.DigestAuthenticationProvider can be used to generate the superDigest, call it with one parameter of "super:<password>". Provide the generated "super:<data>" as the system property value when starting each server of the ensemble.

When authenticating to a ZooKeeper server (from a ZooKeeper client) pass a scheme of "digest" and authdata of "super:<password>". Note that digest auth passes the authdata in plaintext to the server, it would be prudent to use this authentication method only on localhost (not over the network) or over an encrypted connection.

安全ではないオプション

The following options can be useful, but be careful when you use them. The risk of each is explained along with the explanation of what the variable does.

forceSync

(Java system property: zookeeper.forceSync)

Requires updates to be synced to media of the transaction log before finishing processing the update. If this option is set to no, ZooKeeper will not require updates to be synced to the media.

jute.maxbuffer:

(Java system property: jute.maxbuffer)

This option can only be set as a Java system property. There is no zookeeper prefix on it. It specifies the maximum size of the data that can be stored in a znode. The default is 0xfffff, or just under 1M. If this option is changed, the system property must be set on all servers and clients otherwise problems will arise. This is really a sanity check. ZooKeeper is designed to store data on the order of kilobytes in size.

skipACL

(Java system property: zookeeper.skipACL)

Skips ACL checks. This results in a boost in throughput, but opens up full access to the data tree to everyone.

ZooKeeper のコマンド: 4 文字語

ZooKeeper responds to a small set of commands. Each command is composed of four letters. You issue the commands to ZooKeeper via telnet or nc, at the client port.

Three of the more interesting commands: "stat" gives some general information about the server and connected clients, while "srvr" and "cons" give extended details on server and connections respectively.

conf

New in 3.3.0: Print details about serving configuration.

cons

New in 3.3.0: List full connection/session details for all clients connected to this server. Includes information on numbers of packets received/sent, session id, operation latencies, last operation performed, etc...

crst

New in 3.3.0: Reset connection/session statistics for all connections.

dump

Lists the outstanding sessions and ephemeral nodes. This only works on the leader.

envi

Print details about serving environment

ruok

Tests if server is running in a non-error state. The server will respond with imok if it is running. Otherwise it will not respond at all.

A response of "imok" does not necessarily indicate that the server has joined the quorum, just that the server process is active and bound to the specified client port. Use "stat" for details on state wrt quorum and client connection information.

srst

Reset server statistics.

srvr

New in 3.3.0: Lists full details for the server.

stat

Lists brief details for the server and connected clients.

wchs

New in 3.3.0: Lists brief information on watches for the server.

wchc

New in 3.3.0: Lists detailed information on watches for the server, by session. This outputs a list of sessions(connections) with associated watches (paths). Note, depending on the number of watches this operation may be expensive (ie impact server performance), use it carefully.

wchp

New in 3.3.0: Lists detailed information on watches for the server, by path. This outputs a list of paths (znodes) with associated sessions. Note, depending on the number of watches this operation may be expensive (ie impact server performance), use it carefully.

Here's an example of the ruok command:

$ echo ruok | nc 127.0.0.1 5111
imok

データファイル管理

ZooKeeper stores its data in a data directory and its transaction log in a transaction log directory. By default these two directories are the same. The server can (and should) be configured to store the transaction log files in a separate directory than the data files. Throughput increases and latency decreases when transaction logs reside on a dedicated log devices.

データディレクトリ

This directory has two files in it:

  • myid - contains a single integer in human readable ASCII text that represents the server id.

  • snapshot.<zxid> - holds the fuzzy snapshot of a data tree.

Each ZooKeeper server has a unique id. This id is used in two places: the myid file and the configuration file. The myid file identifies the server that corresponds to the given data directory. The configuration file lists the contact information for each server identified by its server id. When a ZooKeeper server instance starts, it reads its id from the myid file and then, using that id, reads from the configuration file, looking up the port on which it should listen.

The snapshot files stored in the data directory are fuzzy snapshots in the sense that during the time the ZooKeeper server is taking the snapshot, updates are occurring to the data tree. The suffix of the snapshot file names is the zxid, the ZooKeeper transaction id, of the last committed transaction at the start of the snapshot. Thus, the snapshot includes a subset of the updates to the data tree that occurred while the snapshot was in process. The snapshot, then, may not correspond to any data tree that actually existed, and for this reason we refer to it as a fuzzy snapshot. Still, ZooKeeper can recover using this snapshot because it takes advantage of the idempotent nature of its updates. By replaying the transaction log against fuzzy snapshots ZooKeeper gets the state of the system at the end of the log.

ログディレクトリ

The Log Directory contains the ZooKeeper transaction logs. Before any update takes place, ZooKeeper ensures that the transaction that represents the update is written to non-volatile storage. A new log file is started each time a snapshot is begun. The log file's suffix is the first zxid written to that log.

ファイル管理

The format of snapshot and log files does not change between standalone ZooKeeper servers and different configurations of replicated ZooKeeper servers. Therefore, you can pull these files from a running replicated ZooKeeper server to a development machine with a stand-alone ZooKeeper server for trouble shooting.

Using older log and snapshot files, you can look at the previous state of ZooKeeper servers and even restore that state. The LogFormatter class allows an administrator to look at the transactions in a log.

The ZooKeeper server creates snapshot and log files, but never deletes them. The retention policy of the data and log files is implemented outside of the ZooKeeper server. The server itself only needs the latest complete fuzzy snapshot and the log files from the start of that snapshot. See the maintenance section in this document for more details on setting a retention policy and maintenance of ZooKeeper storage.

避けるべきこと

Here are some common problems you can avoid by configuring ZooKeeper correctly:

inconsistent lists of servers

The list of ZooKeeper servers used by the clients must match the list of ZooKeeper servers that each ZooKeeper server has. Things work okay if the client list is a subset of the real list, but things will really act strange if clients have a list of ZooKeeper servers that are in different ZooKeeper clusters. Also, the server lists in each Zookeeper server configuration file should be consistent with one another.

incorrect placement of transasction log

The most performance critical part of ZooKeeper is the transaction log. ZooKeeper syncs transactions to media before it returns a response. A dedicated transaction log device is key to consistent good performance. Putting the log on a busy device will adversely effect performance. If you only have one storage device, put trace files on NFS and increase the snapshotCount; it doesn't eliminate the problem, but it should mitigate it.

incorrect Java heap size

You should take special care to set your Java max heap size correctly. In particular, you should not create a situation in which ZooKeeper swaps to disk. The disk is death to ZooKeeper. Everything is ordered, so if processing one request swaps the disk, all other queued requests will probably do the same. the disk. DON'T SWAP.

Be conservative in your estimates: if you have 4G of RAM, do not set the Java max heap size to 6G or even 4G. For example, it is more likely you would use a 3G heap for a 4G machine, as the operating system and the cache also need memory. The best and only recommend practice for estimating the heap size your system needs is to run load tests, and then make sure you are well below the usage limit that would cause the system to swap.

ベストプラクティス

For best results, take note of the following list of good Zookeeper practices:

For multi-tennant installations see the section detailing ZooKeeper "chroot" support, this can be very useful when deploying many applications/services interfacing to a single ZooKeeper cluster.