第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 は namespace namespace で実行され、Kafka クラスターの名前は my-cluster です。
  • 3 つのノードで構成される ZooKeeper クラスターが稼働しています。

各 ZooKeeper サーバーに対して、1 つずつ以下の手順を実行します。

  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
      # ...
  2. 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 コマンドにあるクライアントポートの最後の番号と一致します。

  3. 元のクラスターを構成するノードの 1 つ (ノード 0、1、または 2) で zookeeper-shell セッションを開きます。

    kubectl exec -n <namespace> -it <my-cluster>-zookeeper-0 -c zookeeper -- ./bin/zookeeper-shell.sh localhost:21810
  4. シェルセッションで以下の行を入力し、新しいサーバーを投票メンバーとしてクォーラムに追加します。

    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 クラスターの他のサーバーに伝播されます。新しいサーバーはクォーラムの完全メンバーになります。

  5. Kafka カスタムリソースの spec.zookeeper.replicas で、レプリカ数を 1 つ増やします (n=5)。
  6. 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 と似たものになるはずです。

  7. 元のクラスターを構成するノードの 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>
  8. シェルセッションで以下の行を入力し、新しい ZooKeeper サーバーを投票メンバーとしてクォーラムに追加します。

    reconfig -add server.<n>=127.0.0.1:2888<n-1>:3888<n-1>:participant;127.0.0.1:2181<n-1>
  9. 追加するサーバーごとに、ステップ 5 から 8 を繰り返します。
  10. 希望するサイズのクラスターがある場合、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-0zookeeper-1、および zookeeper-2 が維持されます。

注記

次に進む前に、ZooKeeper ドキュメント の「Removing servers」にある注記をお読みください。

各 ZooKeeper サーバーに対して、1 つずつ以下の手順を実行します。

  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 コマンドにあるクライアントポートの最後の番号と一致します。

  2. config コマンドを使用して既存のクラスター設定を出力します。

    config

    5 つの 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
  3. 次に、番号が一番大きいサーバーを最初に削除します。この場合は 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
  4. 伝播が完了したら、Kafka リソースの zookeeper セクションのレプリカ数を 1 つ減らすことができます。これにより、zookeeper-4 (server.5) がシャットダウンされます。
  5. ステップ 1 から 4 を繰り返し、クラスターのサイズを段階的に縮小します。必ずサーバーを降順に削除してください
  6. 希望するサイズのクラスターがある場合、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 にスケールダウンすることも可能です。ただし、これは不安定になる可能性があるため、推奨されません

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る