第6章 既知の問題
このセクションでは、AMQ Streams 1.4 on OpenShift の既知の問題について説明します。
6.1. ZooKeeper 3.5.7 のスケールアップまたはダウン リンクのコピーリンクがクリップボードにコピーされました!
ZooKeeper のスケールアップまたはダウンに関連する既知の問題があります。ZooKeeper のスケールアップとは、サーバーを ZooKeeper クラスターに追加することを言います。ZooKeeper のスケールダウンとは、ZooKeeper クラスターからサーバーを削除することを言います。
Kafka 2.4.0 には ZooKeeper 3.5.7 が必要です。
ZooKeeper 3.5.7 サーバーの設定手順は、ZooKeeper 3.4.x サーバーとは大きく異なります。新しい設定手順は 動的再設定 と呼ばれ、ZooKeeper CLI または Admin API を使用してサーバーを追加または削除する必要があります。これにより、スケールアップまたはダウンの処理中に ZooKeeper クラスターの安定性が維持されます。
ZooKeeper 3.5.7 クラスターをスケールアップまたはダウンするには、この既知の問題に記載されている手順を実行する必要があります。
今後の AMQ Streams のリリースでは、ZooKeeper のスケールアップおよびスケールダウンは Cluster Operator によって処理されます。
AMQ Streams 1.4 クラスターでの ZooKeeper 3.5.7 サーバーのスケールアップ
この手順では、以下を前提とします。
-
AMQ Streams は
namespacenamespace で実行され、Kafka クラスターの名前はmy-clusterです。 - 3 つのノードで構成される ZooKeeper クラスターが稼働しています。
各 ZooKeeper サーバーに対して、1 つずつ以下の手順を実行します。
Kafkaカスタムリソースのspec.zookeeper.replicasプロパティーを編集します。レプリカ数を4(n=4) に設定します。apiVersion: kafka.strimzi.io/v1beta1 kind: Kafka metadata: name: my-cluster spec: kafka: # ... zookeeper: replicas: 4 storage: type: persistent-claim size: 100Gi deleteClaim: false # ...ZooKeeper サーバー (
zookeeper-3) を通常通り起動し、既存のクォーラムへのリンクを確立します。これを確認するには、以下を実行します。
kubectl exec -n <namespace> -it <my-cluster>-zookeeper-3 -c zookeeper -- bash -c "echo 'srvr' | nc 127.0.0.1 21813 | grep 'Mode:'"コマンドの出力は
Mode: followerと似たものになるはずです。注記新しい ZooKeeper ノード
zookeeper-xの名前にあるインデックス番号は、nc 127.0.0.1 2181xコマンドにあるクライアントポートの最後の番号と一致します。元のクラスターを構成するノードの 1 つ (ノード 0、1、または 2) で
zookeeper-shellセッションを開きます。kubectl exec -n <namespace> -it <my-cluster>-zookeeper-0 -c zookeeper -- ./bin/zookeeper-shell.sh localhost:21810シェルセッションで以下の行を入力し、新しいサーバーを投票メンバーとしてクォーラムに追加します。
reconfig -add server.4=127.0.0.1:28883:38883:participant;127.0.0.1:21813注記ZooKeeper クラスター内では、ノードはノード名のようにゼロからではなく、1 からインデックス化されます。そのため、新しい
zookeeper-3ノードは ZooKeeper 設定内でserver.4と呼ばれます。これにより、新規クラスター設定が出力されます。
server.1=127.0.0.1:28880:38880:participant;127.0.0.1:21810 server.2=127.0.0.1:28881:38881:participant;127.0.0.1:21811 server.3=127.0.0.1:28882:38882:participant;127.0.0.1:21812 server.4=127.0.0.1:28883:38883:participant;127.0.0.1:21813 version=100000054新しい設定は ZooKeeper クラスターの他のサーバーに伝播されます。新しいサーバーはクォーラムの完全メンバーになります。
-
Kafkaカスタムリソースのspec.zookeeper.replicasで、レプリカ数を 1 つ増やします (n=5)。 ZooKeeper サーバー (
zookeeper-<n-1>) を通常通り起動し、既存のクォーラムへのリンクを確立します。これを確認するには、以下を実行します。kubectl exec -n <namespace> -it <my-cluster>-zookeeper-<n-1> -c zookeeper -- bash -c "echo 'srvr' | nc 127.0.0.1 2181<n-1> | grep 'Mode:'"コマンドの出力は
Mode: followerと似たものになるはずです。元のクラスターを構成するノードの 1 つ (この例ではノード 0 >= i <= n-2) で
zookeeper-shellセッションを開きます。kubectl exec -n <namespace> -it <my-cluster>-zookeeper-<i> -c zookeeper -- ./bin/zookeeper-shell.sh localhost:2181<i>シェルセッションで以下の行を入力し、新しい ZooKeeper サーバーを投票メンバーとしてクォーラムに追加します。
reconfig -add server.<n>=127.0.0.1:2888<n-1>:3888<n-1>:participant;127.0.0.1:2181<n-1>- 追加するサーバーごとに、ステップ 5 から 8 を繰り返します。
希望するサイズのクラスターがある場合、ZooKeeper クラスターを再度ロールできることを Cluster Operator に通信する必要があります。これには、
Kafkaカスタムリソースでmanual-zk-scalingアノテーションをfalseに設定します。ZooKeeper レプリカの数を変更すると、Cluster Operator によって自動的にtrueに設定されます。kubectl -n <namespace> annotate statefulset <my-cluster>-zookeeper strimzi.io/manual-zk-scaling=false --overwrite
AMQ Streams 1.4 クラスターの ZooKeeper 3.5.7 サーバーのスケールダウン
この手順では、AMQ Streams が namespace namespaceで実行され、Kafka クラスターの名前が my-cluster であることを仮定します。
ZooKeeper ノードを削除する際、番号が最も大きいサーバーから降順で削除されます。したがって、5 つのノードで構成されるクラスターを 3 つのノードにスケールダウンする場合、zookeeper-4 および zookeeper-3 が削除され、zookeeper-0、zookeeper-1、および zookeeper-2 が維持されます。
次に進む前に、ZooKeeper ドキュメント の「Removing servers」にある注記をお読みください。
各 ZooKeeper サーバーに対して、1 つずつ以下の手順を実行します。
スケールダウンの後も維持されたノードのいずれかで、
zookeeper-shellにログインします 。kubectl exec -n <namespace> -it <my-cluster>-zookeeper-0 -c zookeeper -- ./bin/zookeeper-shell.sh localhost:21810注記ZooKeeper ノード
zookeeper-xの名前にあるインデックス番号は、zookeeper-shell.sh localhost:2181xコマンドにあるクライアントポートの最後の番号と一致します。configコマンドを使用して既存のクラスター設定を出力します。config5 つの ZooKeeper ノードがあるクラスターからスケールダウンする場合、コマンドの出力は以下のようになります。
server.1=127.0.0.1:28880:38880:participant;127.0.0.1:21810 server.2=127.0.0.1:28881:38881:participant;127.0.0.1:21811 server.3=127.0.0.1:28882:38882:participant;127.0.0.1:21812 server.4=127.0.0.1:28883:38883:participant;127.0.0.1:21813 server.5=127.0.0.1:28884:38884:participant;127.0.0.1:21814 version=100000057次に、番号が一番大きいサーバーを最初に削除します。この場合は
server.5になります。reconfig -remove 5これにより、クォーラムの他のメンバーすべてに伝播される新しい設定が出力されます。
server.1=127.0.0.1:28880:38880:participant;127.0.0.1:21810 server.2=127.0.0.1:28881:38881:participant;127.0.0.1:21811 server.3=127.0.0.1:28882:38882:participant;127.0.0.1:21812 server.4=127.0.0.1:28883:38883:participant;127.0.0.1:21813 version=200000012-
伝播が完了したら、
Kafkaリソースのzookeeperセクションのレプリカ数を 1 つ減らすことができます。これにより、zookeeper-4(server.5) がシャットダウンされます。 - ステップ 1 から 4 を繰り返し、クラスターのサイズを段階的に縮小します。必ずサーバーを降順に削除してください。
希望するサイズのクラスターがある場合、ZooKeeper クラスターを再度ロールできることを Cluster Operator に通信する必要があります。これには、
Kafkaカスタムリソースでmanual-zk-scalingアノテーションをfalseに設定します。ZooKeeper レプリカの数を変更すると、Cluster Operator によって自動的にtrueに設定されます。kubectl -n <namespace> annotate statefulset <my-cluster>-zookeeper strimzi.io/manual-zk-scaling=false --overwrite注記複数のサーバーを指定して一度に削除することもできます。たとえば、
reconfig -remove 4,5を入力して一度に最も大きな番号のサーバーを 2 つ削除し、一度に 5 から 3 にスケールダウンすることも可能です。ただし、これは不安定になる可能性があるため、推奨されません。