第9章 Cruise Control によるクラスターのリバランス

重要

Cruise Control によるクラスターのリバランスはテクノロジープレビューの機能です。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあります。Red Hat は、本番環境でのテクノロジープレビュー機能の実装は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

Cruise Control を AMQ Streams クラスターにデプロイし、Kafka クラスターのリバランスに使用できます。

Cruise Control は、クラスターワークロードの監視、事前定義の制約を基にしたクラスターのリバランス、異常の検出および修正などの Kafka の操作を自動化するオープンソースのシステムです。Cruise Control は Load Monitor、Analyzer、Anomaly Detector、および Executor の主な 4 つのコンポーネントと、クライアントの対話に使用される REST API で構成されます。AMQ Streams は REST API を使用して、以下の Cruise Control 機能をサポートします。

  • 複数の最適化ゴールから、最適化プロポーザルを生成します。
  • 最適化プロポーザルを基にして Kafka クラスターのリバランスを行います。

異常検出、通知、独自ゴールの作成、トピックレプリケーション係数の変更などの、その他の Cruise Control の機能は現在サポートされていません。

Cruise Control の サンプル YAML ファイルは、examples/cruise-control/ にあります。

9.1. Cruise Control とは

Cruise Control は、分散された Kafka クラスターを効率的に実行するための時間および労力を削減します。

通常、クラスターの負荷は時間とともに不均等になります。大量のメッセージトラフィックを処理するパーティションは、使用可能なブローカー全体で不均等に分布される可能性があります。クラスターを再分散するには、管理者はブローカーの負荷を監視し、トラフィックの多いパーティションを容量に余裕のあるブローカーに手作業で再割り当てします。

Cruise Control はクラスターのリバランス処理を自動化します。CPU、ディスク、およびネットワーク負荷を基にして、クラスターにおけるリソース使用のワークロードモデルを構築し、パーティションの割り当てをより均等にする、最適化プロポーザル (承認または拒否可能) を生成します。これらのプロポーザルの算出には、設定可能な最適化ゴールが複数使用されます。

最適化プロポーザルを承認すると、Cruise Control はそのプロポーザルを Kafka クラスターに適用します。クラスターのリバランス操作が完了すると、ブローカー Pod はより効率的に使用され、Kafka クラスターはより均等に分散されます。

その他のリソース

9.2. 最適化ゴールの概要

Cruise Control は Kafka クラスターをリバランスするために、最適化ゴールを使用して、承認または拒否可能な最適化プロポーザルを生成します。

最適化ゴールは、Kafka クラスター全体のワークロード再分布およびリソース使用の制約です。一部の例外を除き、AMQ Streams では Cruise Control プロジェクトで開発されたすべての最適化ゴールがサポートされます。以下に、サポートされるゴールをデフォルトの優先度順に示します。

  1. ラックアウェアネス
  2. レプリカの容量
  3. 容量: ディスク容量、ネットワークインバウンド容量、ネットワークアウトバウンド容量
  4. レプリカの分布
  5. 潜在的なネットワーク出力
  6. リソース分布: ディスク使用率の分布、ネットワークインバウンド使用率の分布、ネットワークアウトバウンド使用率の分布。
  7. リーダーへの単位時間あたりバイト流入量の分布
  8. トピックレプリカの分布
  9. リーダーレプリカの分布
  10. 優先リーダーの選択

各最適化ゴールの詳細は、Cruise Control Wiki の「Goals」を参照してください。

注記

CPU ゴール、ブローカー内ディスクゴール、独自のゴール、および Kafka アサイナーゴールはサポートされていません。

AMQ Streams カスタムリソースでのゴールの設定

Kafka および KafkaRebalance カスタムリソースで最適化ゴールを設定します。Cruise Control には、必ず満たさなければならない ハード 最適化ゴールの設定と、マスターデフォルト、およびユーザー提供最適化ゴールの設定があります。最適化ゴールは、ブローカーリソースのあらゆる容量制限 の対象となります。

以下のセクションでは、各ゴール設定の詳細を説明します。

ハードゴールおよびソフトゴール

ハードゴールは最適化プロポーザルで必ず満たさなければならないゴールです。ハードゴールとして設定されていないゴールはソフトゴールと呼ばれます。ソフトゴールは ベストエフォート 型のゴールと解釈できます。最適化プロポーザルで満たす必要はありませんが、最適化の計算に含まれます。すべてのハードゴールを満たし、1 つ以上のソフトゴールに違反する最適化プロポーザルは有効です。

Cruise Control は、すべてのハードゴールを満たし、優先度順にできるだけ多くのソフトゴールを満たす最適化プロポーザルを算出します。すべてのハードゴールを満たさない最適化プロポーザルは Cruise Control によって拒否され、ユーザーには送信されません。

注記

たとえば、クラスター全体でトピックのレプリカを均等に分布するソフトゴールがあるとします (トピックレプリカ分布のゴール)。このソフトゴールを無視すると、設定されたハードゴールがすべて有効になる場合、Cruise Control はこのソフトゴールを無視します。

Cruise Control では、以下のマスター最適化ゴールがハードゴールとして事前設定されています。

RackAwareGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal

Kafka.spec.cruiseControl.confighard.goals プロパティーを編集し、Cruise Control のデプロイメント設定でハードゴールを設定します。

  • Cruise Control から事前設定されたハードゴールを継承する場合は、Kafka.spec.cruiseControl.confighard.goals プロパティーを指定しないでください。
  • 事前設定されたハードゴールを変更するには、完全修飾ドメイン名を使用して、希望のゴールを hard.goals プロパティーに指定します。

ハード最適化ゴールの Kafka 設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}
  cruiseControl:
    brokerCapacity:
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    config:
      hard.goals: >
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkInboundCapacityGoal,
        com.linkedin.kafka.cruisecontrol.analyzer.goals.NetworkOutboundCapacityGoal
      # ...

ハードゴールの数を増やすと、Cruise Control が有効な最適化プロポーザルを生成する可能性が低くなります。

skipHardGoalCheck: trueKafkaRebalance カスタムリソースに指定された場合、Cruise Control はユーザー提供の最適化ゴールのリスト (KafkaRebalance.spec.goals 内) に設定済みのハードゴール (hard.goals) がすべて含まれていることをチェックしません。そのため、すべてではなく一部のユーザー提供の最適化ゴールが hard.goals リストにある場合、skipHardGoalCheck: true が指定されていてもハードゴールとして処理されます。

マスター最適化ゴール

マスター最適化ゴールはすべてのユーザーが使用できます。マスター最適化ゴールにリストされていないゴールは、Cruise Control 操作で使用できません。

Cruise Control の デプロイメント設定を変更しない限り、AMQ Streams は以下のマスター最適化ゴールを優先度順 (降順) に Cruise Control から継承します。

RackAwareGoal; ReplicaCapacityGoal; DiskCapacityGoal; NetworkInboundCapacityGoal; NetworkOutboundCapacityGoal; ReplicaDistributionGoal; PotentialNwOutGoal; DiskUsageDistributionGoal; NetworkInboundUsageDistributionGoal; NetworkOutboundUsageDistributionGoal; TopicReplicaDistributionGoal; LeaderReplicaDistributionGoal; LeaderBytesInDistributionGoal; PreferredLeaderElectionGoal

これらのゴールの 5 つが ハードゴール として事前設定されています。

複雑さを軽減するため、1 つ以上のゴールを KafkaRebalance リソースでの使用から完全に除外する必要がある場合を除き、継承されるマスター最適化ゴールを使用することが推奨されます。必要な場合、マスター最適化ゴールの優先順位は デフォルトの最適化ゴール の設定で変更できます。

マスター最適化ゴールは、必要であれば Cruise Control のデプロイメント設定である Kafka.spec.cruiseControl.config.goals で設定できます。

  • 継承されたマスター最適化ゴールを許可する場合は、goals プロパティーを Kafka.spec.cruiseControl.config に指定しないでください。
  • 継承されたマスター最適化ゴールを変更する必要がある場合は、goals 設定オプションにゴールのリストを優先度が高いものから順に指定します。
注記

継承されたマスター最適化ゴールを変更する場合、Kafka.spec.cruiseControl.confighard.goals プロパティーに設定されたハードゴールがあれば、必ず設定したマスター継承ゴールのサブセットになるように確認してください。そうでないと、最適化プロポーザルの生成時にエラーが発生します。

デフォルトの最適化ゴール

Cruise Conrol はデフォルトの最適化ゴール を使用して キャッシュされた最適化プロポーザル を生成します。キャッシュされた最適化プロポーザルの詳細は、「最適化プロポーザルの概要」 を参照してください。

ユーザー提供の最適化ゴールKafkaRebalance カスタムリソースに設定すると、デフォルトの最適化ゴールを上書きできます。

Cruise Control のデプロイメント設定default.goals を指定しない限り、マスター最適化ゴールがデフォルトの最適化ゴールとして使用されます。この場合、マスター最適化ゴールを使用して、キャッシュされた最適化プロポーザルが生成されます。

  • マスター最適化ゴールをデフォルトのゴールとして使用する場合は、default.goals プロパティーを Kafka.spec.cruiseControl.config に指定しないでください。
  • デフォルトの最適化ゴールを編集するには、Kafka.spec.cruiseControl.configdefault.goals プロパティーを編集します。マスター最適化ゴールのサブセットを使用する必要があります。

デフォルト最適化ゴールの Kafka 設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
  zookeeper:
    # ...
  entityOperator:
    topicOperator: {}
    userOperator: {}
  cruiseControl:
    brokerCapacity:
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    config:
      default.goals: >
         com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
         com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal,
         com.linkedin.kafka.cruisecontrol.analyzer.goals.DiskCapacityGoal
      # ...

デフォルトの最適化ゴールの指定がない場合、マスター最適化ゴールを使用して、キャッシュされたプロポーザルが生成されます。

ユーザー提供の最適化ゴール

ユーザー提供の最適化ゴールは、特定の最適化プロポーザルに設定済みのデフォルトゴールを絞り込みます。必要に応じて、KafkaRebalance カスタムリソースの spec.goals で設定できます。

KafkaRebalance.spec.goals

ユーザー提供の最適化ゴールは、さまざまな状況の最適化プロポーザルを生成できます。たとえば、ディスクの容量やディスクの使用率を考慮せずに、Kafka クラスター全体でリーダーレプリカの分布を最適化したい場合があります。この場合、リーダーレプリカ分布の単一のユーザー提供ゴールが含まれる KafkaRebalance カスタムリソースを作成します。

ユーザー提供の最適化ゴールには以下が必要になります。

  • 設定済みのハードゴールがすべて含まれるようにする必要があります。そうでないと、エラーが発生します。
  • マスター最適化ゴールのサブセットである必要があります。

最適化プロポーザルの設定済みのハードゴールを無視するには、skipHardGoalCheck: true オプションを KafkaRebalance カスタムリソースに追加します。

その他のリソース

9.3. 最適化プロポーザルの概要

最適化プロポーザルは、パーティションのワークロードをブローカー間でより均等に分布することで、Kafka クラスターの負荷をより均等にするために提案された変更の概要です各最適化プロポーザルは、そのプロポーザルの生成に使用された 最適化ゴール のセットが基になっており、ブローカーリソースの設定済みの容量制限 の対象になります。

最適化プロポーザルは KafkaRebalance カスタムリソースの Status.Optimization Result プロパティーに含まれます。提供される情報は完全な最適化プロポーザルの概要になります。概要を使用して以下を決定します。

  • 最適化プロポーザルの承認。プロポーザルを Kafka クラスターに適用し、クラスターリバランス操作を開始するよう Cruise Control が指示されます。
  • 最適化プロポーザルの拒否。最適化ゴールを変更し、別のプロポーザルを生成できます。

最適化プロポーザルはすべてドライランです。最適化プロポーザルを最初に生成しないと、クラスターのリバランスを承認できません。生成できる最適化プロポーザルの数に制限はありません。

キャッシュされた最適化プロポーザル

Cruise Control は、設定済みのデフォルト最適化ゴールを基にして キャッシュされた最適化プロポーザル を維持します。キャッシュされた最適化プロポーザルはワークロードモデルから生成され、Kafka クラスターの現在の状況を反映するために 15 分ごとに更新されます。デフォルトの最適化ゴールを使用して最適化プロポーザルを生成する場合、Cruise Control は最新のキャッシュされたプロポーザルを返します。

キャッシュされた最適化プロポーザルの更新間隔を変更するには、Cruise Control デプロイメント設定の proposal.expiration.ms 設定を編集します。更新間隔を短くすると、Cruise Control サーバーの負荷が増えますが、変更が頻繁に行われるクラスターでは、更新間隔を短くするよう考慮してください。

最適化プロポーザルの内容

以下の表は、最適化プロポーザルに含まれるプロパティーについて説明しています。

JSON プロパティー説明

numIntraBrokerReplicaMovements

ディスクとクラスターのブローカーとの間で転送されるパーティションレプリカの合計数。

リバランス操作中のパフォーマンスへの影響度: 比較的高いが、numReplicaMovements よりも低い。

excludedBrokersForLeadership

サポートされていません。空のリストが返されます。

numReplicaMovements

個別のブローカー間で移動されるパーティションレプリカの数。

リバランス操作中のパフォーマンスへの影響度: 比較的高い。

onDemandBalancednessScoreBefore, onDemandBalancednessScoreAfter

最適化プロポーザルの生成前および生成後における、Kafka クラスターの全体的な 分散度 (balancedness) の値。

スコアは、違反した各ソフトゴールの BalancednessScore の合計を 100 から引いて算出されます。Cruise Control は、複数の要因を基にして BalancednessScore を各最適化ゴールに割り当てます。要因には、default.goals またはユーザー提供ゴールのリストでゴールの位置を示す優先順位が含まれます。

Before スコアは、Kafka クラスターの現在の設定を基にします。After スコアは、生成された最適化プロポーザルを基にします。

intraBrokerDataToMoveMB

同じブローカーのディスク間で移動される各パーティションレプリカのサイズの合計 (numIntraBrokerReplicaMovements も参照してください。

リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。大量のデータを移動する場合、同じブローカーのディスク間で移動する方が個別のブローカー間で移動するよりも影響度が低くなります (dataToMoveMB 参照)。

recentWindows

最適化プロポーザルの基になるメトリクスウインドウの数。

dataToMoveMB

個別のブローカーに移動される各パーティションレプリカのサイズの合計 (numReplicaMovements も参照してください。

リバランス操作中のパフォーマンスへの影響度: 場合による。値が大きいほど、クラスターのリバランスの完了にかかる時間が長くなります。

monitoredPartitionsPercentage

最適化プロポーザルの対象となる Kafka クラスターのパーティションの割合 (パーセント)。excludedTopics の数が影響します。

excludedTopics

サポートされていません。空のリストが返されます。

numLeaderMovements

リーダーが別のレプリカに切り替えられるパーティションの数。ZooKeeper 設定の変更を伴います。

リバランス操作中のパフォーマンスへの影響度: 比較的低い。

excludedBrokersForReplicaMove

サポートされていません。空のリストが返されます。

9.4. Cruise Control のデプロイ

Cruise Control を AMQ Streams クラスターにデプロイするいは、Kafka リソースの cruiseControl プロパティーを使用して設定を定義した後、リソースを作成または更新します。

Kafka クラスターごとに Cruise Control のインスタンスを 1 つデプロイします。

前提条件

  • OpenShift クラスターが必要です。
  • 稼働中の Cluster Operator が必要です。

手順

  1. Kafka リソースを編集し、cruiseControl プロパティーを追加します。

    設定可能なプロパティーは以下の例のとおりです。

    apiVersion: kafka.strimzi.io/v1beta1
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      # ...
      cruiseControl:
        brokerCapacity: 1
          inboundNetwork: 10000KB/s
          outboundNetwork: 10000KB/s
          # ...
        config: 2
          default.goals: >
             com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
             com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal
             # ...
          cpu.balance.threshold: 1.1
          metadata.max.age.ms: 300000
          send.buffer.bytes: 131072
          # ...
        resources: 3
          requests:
            cpu: 200m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 128Mi
        logging: 4
            type: inline
            loggers:
              cruisecontrol.root.logger: "INFO"
        template: 5
          pod:
            metadata:
              labels:
                label1: value1
            securityContext:
              runAsUser: 1000001
              fsGroup: 0
            terminationGracePeriodSeconds: 120
        readinessProbe: 6
          initialDelaySeconds: 15
          timeoutSeconds: 5
        livenessProbe: 7
          initialDelaySeconds: 15
          timeoutSeconds: 5
    # ...
    1
    ブローカーリソースの容量制限を指定します。詳細は、容量の設定 を参照してください。
    2
    Cruise Control 設定を定義します。これには、デフォルトの最適化ゴール (default.goals で設定) が含まれ、マスター最適化ゴール (goals で設定) またはハードゴール (hard.goals で設定) へのカスタマイズも含まれまもす。AMQ Streams によって直接管理されるものを除き、標準の Cruise Cntrol 設定オプション をすべて提供できます。最適化ゴールの設定に関する詳細は、「最適化ゴールの概要」 を参照してください。
    3
    Cruise Control によって予約された CPU およびメモリーリソース。詳細は、「CPU およびメモリーリソース」を参照してください。
    4
    ConfigMap より直接的 (inline) または間接的 (external) に追加されたロガーおよびログレベルを定義します。カスタム ConfigMap は、log4j.properties キー下に配置する必要があります。Cruise Control には cruisecontrol.root.logger という名前の単一のロガーがあります。ログレベルは INFO、ERROR、WARN、TRACE、DEBUG、FATAL、または OFF に設定できます。詳細は、「ロギングの設定」を参照してください。
    5
    6
    7
  2. リソースを作成または更新します。

    oc apply -f kafka.yaml
  3. Cruise Control が正常にデプロイされたことを確認します。

    oc get deployments -l app.kubernetes.io/name=strimzi

自動作成されたトピック

以下の表は、Cruise Control のデプロイ時に自動作成される 3 つのトピックを表しています。これらのトピックは、Cruise Control が適切に動作するために必要であるため、削除または変更しないでください。

自動作成されたトピック作成元機能

strimzi.cruisecontrol.metrics

AMQ Streams の Metrics Reporter

Metrics Reporter からの raw メトリクスを各 Kafka ブローカーに格納します。

strimzi.cruisecontrol.partitionmetricsamples

Cruise Control

各パーティションの派生されたメトリクスを格納します。これらは Metric Sample Aggregator によって作成されます。

strimzi.cruisecontrol.modeltrainingsamples

Cruise Control

クラスターワークロードモデル の作成に使用されるメトリクスサンプルを格納します。

Cruise Control に必要なレコードを削除しないようにするため、自動作成されたトピックではログの圧縮は無効になっています。

次のステップ

Cruise Control を設定およびデプロイした後、最適化プロポーザルを生成できます。

9.5. Cruise Control の設定

Kafka.spec.cruiseControlconfig プロパティーには設定オプションがキーとして含まれ、それらの値は以下の JSON タイプの 1 つになります。

  • 文字列
  • 数値
  • ブール値
注記

JSON または YAML に似た文字列は、明示的に引用符で囲む必要があります。

AMQ Streams によって直接管理されるオプション以外は、Cruise Control ドキュメント の「Configurations」セクションにリストされているすべてのオプションを指定および設定できます。以下の文字列の 1 つと同じキーまたは以下の文字列の 1 つで始まるキーを持つ設定オプションは編集できません

  • bootstrap.servers
  • zookeeper.
  • ssl.
  • security.
  • failed.brokers.zk.path
  • webserver.http.port
  • webserver.http.address
  • webserver.api.urlprefix
  • metric.reporter.sampler.bootstrap.servers
  • metric.reporter.topic
  • metric.reporter.topic.pattern
  • partition.metric.sample.store.topic
  • broker.metric.sample.store.topic
  • capacity.config.file
  • skip.sample.store.topic.rack.awareness.check
  • cruise.control.metrics.topic
  • sasl.

制限されたオプションが指定された場合、そのオプションは無視され、警告メッセージが Cluster Operator のログファイルに出力されます。すべてのサポートされるオプションは Cruise Control に渡されます。

Cruise Control の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    config:
      default.goals: >
         com.linkedin.kafka.cruisecontrol.analyzer.goals.RackAwareGoal,
         com.linkedin.kafka.cruisecontrol.analyzer.goals.ReplicaCapacityGoal
      cpu.balance.threshold: 1.1
      metadata.max.age.ms: 300000
      send.buffer.bytes: 131072
    # ...

容量の設定

Cruise Control は 容量制限 を使用して、特定のリソースベースの最適化ゴールが破損しているか判断します。

Kafka ブローカーリソースの容量制限は、Kafka.spec.cruiseControlbrokerCapacity プロパティーに指定します。容量制限は、記述された単位で以下のブローカーリソースに設定できます。

  • disk - バイト単位のディスクストレージ
  • cpuUtilization - パーセント (0-100) で表した CPU 使用率
  • inboundNetwork - バイト毎秒単位のインバウンドネットワークスループット
  • outboundNetwork - バイト毎秒単位のアウトバウンドネットワークスループット

AMQ Streams の Kafka ブローカーは同種であるため、Cruise Control は監視している各ブローカーに同じ容量制限を適用します。

Cruise Control の brokerCapacity の設定例

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
metadata:
  name: my-cluster
spec:
  # ...
  cruiseControl:
    # ...
    brokerCapacity:
      disk: 100G
      cpuUtilization: 100
      inboundNetwork: 10000KB/s
      outboundNetwork: 10000KB/s
    # ...

その他のリソース

詳細は BrokerCapacity スキーマ参照」 を参照してください。

ロギングの設定

Cruise Control には独自の設定可能なロガーがあります。

  • cruisecontrol.root.logger

Cruise Control では Apache log4j ロガー実装が使用されます。

logging プロパティーを使用してロガーおよびロガーレベルを設定します。

ログレベルを設定するには、ロガーとレベルを直接指定 (インライン) するか、またはカスタム (外部) ConfigMap を使用します。ConfigMap を使用する場合、logging.name プロパティーを外部ロギング設定が含まれる ConfigMap の名前に設定します。ConfigMap 内では、ロギング設定は log4j.properties を使用して記述されます。

inline および external ロギングの例は次のとおりです。

inline ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: inline
      loggers:
        cruisecontrol.root.logger: "INFO"
    # ...

外部ロギング

apiVersion: kafka.strimzi.io/v1beta1
kind: Kafka
# ...
spec:
  cruiseControl:
    # ...
    logging:
      type: external
      name: customConfigMap
    # ...

9.6. 最適化プロポーザルの生成

KafkaRebalance リソースを作成または更新すると、Cruise Control は 設定済みの最適化ゴールを基にして、Kafka クラスターの 最適化プロポーザル を生成します。

最適化プロポーザルの概要情報を分析して、プロポーザルを承認するかどうかを決定します。

前提条件

手順

  1. KafkaRebalance リソースを作成します。

    1. Kafka リソースに定義された デフォルトの最適化ゴール を使用するには、spec プロパティーを空のままにします。

      apiVersion: kafka.strimzi.io/v1alpha1
      kind: KafkaRebalance
      metadata:
        name: my-rebalance
        labels:
          strimzi.io/cluster: my-cluster
      spec: {}
    2. デフォルトのゴールを使用する代わりに ユーザー定義の最適化ゴール を設定するには、goals プロパティーを追加し、1 つ以上のゴールを入力します。

      以下の例では、ラックアウェアネスおよびレプリカの容量はユーザー定義の最適化ゴールとして設定されています。

      apiVersion: kafka.strimzi.io/v1alpha1
      kind: KafkaRebalance
      metadata:
        name: my-rebalance
        labels:
          strimzi.io/cluster: my-cluster
      spec:
        goals:
          - RackAwareGoal
          - ReplicaCapacityGoal
  2. リソースを作成または更新します。

    oc apply -f your-file

    Cluster Operator は Cruise Control から最適化プロポーザルを要求します。Kafka クラスターのサイズによっては処理に数分かかることがあります。

  3. KafkaRebalance リソースのステータスを確認します。

    oc describe kafkarebalance rebalance-cr-name

    Cruise Control は以下の 2 つの状態の 1 つを返します。

    • PendingProposal: 最適化プロポーザルが準備できているかどうかを確認するために、リバランス operator が Cruise Control API をポーリングしています。
    • ProposalReady: 最適化プロポーザルを確認し、希望する場合は承認することができます。最適化プロポーザルは KafkaRebalance リソースの Status.Optimization Result プロパティーに含まれます。
  4. 最適化プロポーザルを確認します。

    oc describe kafkarebalance rebalance-cr-name

    以下はプロポーザルの例になります。

    Status:
      Conditions:
        Last Transition Time:  2020-05-19T13:50:12.533Z
        Status:                ProposalReady
        Type:                  State
      Observed Generation:     1
      Optimization Result:
        Data To Move MB:  0
        Excluded Brokers For Leadership:
        Excluded Brokers For Replica Move:
        Excluded Topics:
        Intra Broker Data To Move MB:         0
        Monitored Partitions Percentage:      100
        Num Intra Broker Replica Movements:   0
        Num Leader Movements:                 0
        Num Replica Movements:                26
        On Demand Balancedness Score After:   81.8666802863978
        On Demand Balancedness Score Before:  78.01176356230222
        Recent Windows:                       1
      Session Id:                             05539377-ca7b-45ef-b359-e13564f1458c

    Optimization Result セクションのプロパティーには、保留クラスターリバランス操作の詳細が表示されます。各プロパティーの説明は、「最適化プロポーザルの内容」を参照してください。

9.7. 最適化プロポーザルの承認

状態が ProposalReady の場合、Cruise Control によって生成された最適化プロポーザルを承認できます。その後、Cruise Control は最適化プロポーザルを Kafka クラスターに適用して、パーティションをブローカーに再割り当てし、パーティションのリーダーを変更します。

注意

これはドライランではありません。最適化プロポーザルを承認する前に、以下を行う必要があります。

  • 最新でない可能性があるため、プロポーザルを更新します。
  • プロポーザルの内容を注意して確認します。

前提条件

手順

承認する最適化プロポーザルに対して、以下の手順を実行します。

  1. 最適化プロポーザルが新規生成された場合を除き、プロポーザルが Kafka クラスターの状態に関する現在の情報を基にしていることを確認します。これには、最適化プロポーザルを更新し、必ず最新のクラスターメトリクスを使用するようにします。

    1. OpenShift で KafkaRebalance リソースに refresh アノテーションを付けます。

      oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=refresh
    2. KafkaRebalance リソースのステータスを確認します。

      oc describe kafkarebalance rebalance-cr-name
    3. 状態が ProposalReady に変わるまで待ちます。
  2. Cruise Control が適用する最適化プロポーザルを承認します。

    OpenShift で KafkaRebalance リソースにアノテーションを付けます。

    oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=approve
  3. Cluster Operator は アノテーションが付けられたリソースを検出し、Cruise Control に Kafka クラスターのリバランスを指示します。
  4. KafkaRebalance リソースのステータスを確認します。

    oc describe kafkarebalance rebalance-cr-name
  5. Cruise Control は以下の 3 つの状態の 1 つを返します。

    • Rebalaning: クラスターリバランス操作の実行中です。
    • Ready: クラスターリバランス操作が正常に完了しました。
    • NotReady: エラーが発生しました。KafkaRebalance リソースの問題の修正」 を参照してください。

9.8. クラスターリバランスの停止

クラスターリバランス操作を開始すると、完了まで時間がかかることがあり、Kafka クラスターの全体的なパフォーマンスに影響します。

実行中のクラスターリバランス操作を停止するには、stop アノテーションを KafkaRebalance カスタムリソースに適用します。これにより、現在のパーティション再割り当てのバッチ処理を完了し、リバランスを停止するよう Cruise Control が指示されます。リバランスの停止時、完了したパーティションの再割り当てはすで適用されています。そのため、Kafka クラスターの状態は、リバランス操作の開始前とは異なります。さらなるリバランスが必要な場合は、新しい最適化プロポーザルを生成してください。

注記

中間 (停止) 状態の Kafka クラスターのパフォーマンスは、初期状態の場合よりも悪くなる可能性があります。

前提条件

  • KafkaRebalance カスタムリソースに approve アノテーションを付けて 最適化プロポーザルが承認済みである必要があります。
  • KafkaRebalance カスタムリソースの状態が Rebalancing である必要があります。

手順

  1. OpenShift で KafkaRebalance リソースにアノテーションを付けます。

    oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=stop
  2. KafkaRebalance リソースのステータスを確認します。

    oc describe kafkarebalance rebalance-cr-name
  3. 状態が Stopped に変わるまで待ちます。

9.9. KafkaRebalance リソースの問題の修正

KafkaRebalance リソースの作成時や、Cruise Control との対話中に問題が発生した場合、エラーとその修正方法の詳細がリソースの状態で報告されます。また、リソースも NotReady の状態に変わります。

クラスター再分散操作を続行するには、KafkaRebalance リソース自体で問題を修正する必要があります。問題には以下が含まれる可能性があります。

  • 正しく設定されていないパラメーター。
  • Cruise Control サーバーに接続できない。

問題の修正後、refresh アノテーションを KafkaRebalance リソースに付ける必要があります。「refresh」(更新) 中、Cruise Control サーバーから新しい最適化プロポーザルが要求されます。

前提条件

手順

  1. KafkaRebalance の状態からエラーに関する情報を取得します。

    oc describe kafkarebalance rebalance-cr-name
  2. KafkaRebalance リソースで問題の解決を試みます。
  3. OpenShift で KafkaRebalance リソースにアノテーションを付けます。

    oc annotate kafkarebalance rebalance-cr-name strimzi.io/rebalance=refresh
  4. KafkaRebalance リソースのステータスを確認します。

    oc describe kafkarebalance rebalance-cr-name
  5. 状態が PendingProposal から ProposalReady に変わるまで待ちます。