3.2. ZooKeeper クラスターの設定

多くの実稼働環境では、複製された ZooKeeper インスタンスのクラスターをデプロイすることが推奨されます。信頼性の高い ZooKeeper サービスでは、ZooKeeper クラスターの安定性および高可用性が重要になります。ZooKeeper クラスターは ensembles とも呼ばれ ます。

ZooKeeper クラスターは、通常最適なノード数で構成されます。ZooKeeper では、クラスター内のノードの大半が稼働している必要があります。以下に例を示します。

ZooKeeper クラスターでより多くのノードがあると、クラスター全体の回復性および信頼性が向上します。

ZooKeeper は、偶数のノードを使用してクラスターで実行することができます。ただし、追加のノードはクラスターの回復性を増やしません。4 つのノードで構成されるクラスターでは、少なくとも 3 つのノードが利用可能必要があり、1 つのノードのみを許容できます。そのため、3 つのノードのみを持つクラスターと同じ回復性があります。

理想的には、異なる ZooKeeper ノードは、異なるデータセンターまたはネットワークセグメントに配置する必要があります。ZooKeeper ノードの数を増やすと、クラスター同期で費やされたワークロードが増加します。ほとんどの Kafka ユースケースでは、3、5、または 7 のノードで構成される ZooKeeper クラスターで十分です。

複製された ZooKeeper 設定は、スタンドアロン設定でサポートされるすべての設定オプションをサポートします。クラスタリング設定の追加オプションが追加されます。

上記のオプションに加え、すべての設定ファイルに ZooKeeper クラスターのメンバーである必要があるサーバーのリストが含まれている必要があります。サーバーレコードは server.id=hostname:port1:port2 の形式で指定する必要があります。

以下は、3 つのノードで構成される ZooKeeper クラスターの設定ファイルの例になります。

timeTick=2000
dataDir=/var/lib/zookeeper/
initLimit=5
syncLimit=2
reconfigEnabled=true
standaloneEnabled=false

server.1=172.17.0.1:2888:3888:participant;172.17.0.1:2181
server.2=172.17.0.2:2888:3888:participant;172.17.0.2:2181
server.3=172.17.0.3:2888:3888:participant;172.17.0.3:2181

timeTick=2000
dataDir=/var/lib/zookeeper/
initLimit=5
syncLimit=2
reconfigEnabled=true
standaloneEnabled=false

server.1=172.17.0.1:2888:3888:participant;172.17.0.1:2181
server.2=172.17.0.2:2888:3888:participant;172.17.0.2:2181
server.3=172.17.0.3:2888:3888:participant;172.17.0.3:2181

上記の例では、3 つのノードがあるため、それぞれに 1、2、および 3 の値がそれぞれ異なる myid があります。