Self-Balancing Clusters の構成オプションとコマンド¶

このセクションでは、Self-Balancing の構成オプションとコマンド、さらにサンプルについて説明します。

「Self-Balancing チュートリアル」を参照し、Self-Balancing のセットアップと簡単なテスト方法として、ブローカーの削除とバランス調整のモニタリングを試してください。その例では、レプリケーション係数の適切な構成方法と Self-Balancing 専用コマンド kafka-remove-brokers のデモが示されています。

ブローカーでの Self-Balancing の構成¶

Self-Balancing Clusters に固有の次の構成オプションは、$CONFLUENT_HOME/etc/kafka/server.properties で利用できます。

Self-Balancing を Multi-Region Clusters と組み合わせて使用している場合は、それぞれの server.properties ファイルの broker.rack で各ブローカーのラックの場所を指定する必要もあります。詳細については、「レプリカ配置とマルチリージョンクラスター」を参照してください。

confluent.balancer.enable¶

Kafka クラスターの間の負荷を測定し、複数の目標と要素に応じてデータのバランスを調整します。

型: boolean
デフォルト: false
重要度: 高

ちなみに

Confluent Platform に付属しているサンプル server.properties ファイルでは、confluent.balancer.enable が true に設定されています。これは、Self-Balancing がオンになっていることを示しています Self-Balancing をオンにする場合、これを再構成する必要はありません（これが false に指定されている場合やプロパティファイルにこのオプションが明示的に設定されていない場合、この値は false、つまりオフと見なされます）。
1 つ目のポイントと同様に、Confluent Platform のインストールに使用できる Confluent Platform Docker イメージでは、confluent.balancer.enable を Self-Balancing がオンであることを意味する true に設定します。
これは動的オプションです。クラスターの実行中に、Self-Balancing のオンとオフを切り替えられます。
ブローカーの追加操作または削除操作が実行されている間は Self-Balancing を無効にしてはいけません。追加または削除が完了するまで待機してください。いずれかの操作の実行中に Self-Balancing を無効にすると、ブローカーにパーティションを分散配置できなくなります。

confluent.balancer.heal.uneven.load.trigger¶

バランス調整をトリガーする条件を設定します。

有効な値は次のとおりです。

EMPTY_BROKER: （パーティションがない）空のブローカーがクラスターに追加されたときのみ、データを移動してクラスターのバランスを調整します。
ANY_UNEVEN_LOAD: 不均衡が検出されるたびに、クラスターで全体で負荷のバランスを実行します。これには空のブローカーと、実行中のクラスターアクティビティで発生する、不均等な負荷状態も含まれます。たとえば、特定のパーティションで負荷のピークがあると、バランス調整がトリガーされることがあります。
型: string
デフォルト : EMPTY_BROKER
重要度: 高

ちなみに

これは動的オプションです。クラスターが実行中でも、Self-Balancing のトリガー状態を変更できます。

confluent.balancer.heal.broker.failure.threshold.ms¶

ブローカーが永続的にエラー状態であると見なすデフォルト時間を設定します。

ブローカーがクラスターから消えたとき、Self-Balancing はこの時間だけ待機してから、ブローカーのエラーが永続的であると宣言し、そのデータを他のブローカーにバランス調整します。これは confluent.balancer.heal.uneven.load.trigger に設定されている値に依存しません。

デフォルト値は 1 時間（3600000 ミリ秒）です。

ブローカーのエラー検出をオフにするには、$CONFLUENT_HOME/etc/kafka/server.properties を編集して、confluent.balancer.heal.broker.failure.threshold.ms を -1 に設定している行のコメントを解除します。
ブローカーが "エラー" と宣言されるまでの時間のしきい値を調整するには、confluent.balancer.heal.broker.failure.threshold.ms の行のコメントを解除し、値を希望する正の数に変更します。

型: int
デフォルト: 3600000
重要度: 中

confluent.balancer.throttle.bytes.per.second¶

データのバランス処理に使用できる、ネットワークの最大帯域幅を指定します。この値は、ブローカーごとにバイト/秒単位で指定します。

デフォルトは 10 MB/秒です。

型: int
デフォルト: 10485760（10 MB/秒）
重要度: 中

ちなみに

これは動的オプションです。クラスターが実行中でもスロットルを調整できます。

スロットル設定を選択する方法¶

Self-Balancing は Apache Kafka® レプリケーションスロットルを使用し、バランス調整の一環としてパーティションを再割り当てするときに移動するデータの割合を制限します。各クラスターのワークロードとハードウェアの能力は異なるため、スロットルの選択に一般に適用できるガイドを示すのは困難です。通常のレプリケーショントラフィックはこのスロットルの影響を受けます。したがって、バランス調整を進めるためには、クラスターの各ブローカーにおけるインバウンドおよびアウトバウンドのレプリケーションレートの最大値よりも、スロットルを大きくする必要があります。これらの値は kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesInPerSec および kafka.server:type=BrokerTopicMetrics,name=ReplicationBytesOutPerSec のブローカーのメトリクスとして公開されます。

スロットルを選択する安全な方法は、最大レプリケーショントラフィックの少ない倍数（3 ～ 5 倍）から始めて、クラスターの正常性をモニタリングしながら、スロットルを少しずつ動的に増やすことです。プロダクションリクエストレイテンシは、モニタリングするのに適切なメトリクスです。再割り当てトラフィックに大量のネットワークスループットが使用される場合や、パーティションが再割り当てされる際に大量のデータがディスクに書き込まれている場合に、これが増加するからです。この開始値はかなり抑えた値で、クラスターによっては、大きなスロットル値でも安全です。

パーティションが再割り当てされない場合、レプリケーションスロットルは Self-Balancing によって自動的に削除されます。クラスター管理者が手動で削除する必要はありません。

confluent.balancer.disk.max.load¶

バランス調整の前に使用するログディスクの割合を指定値（0 ～ 1.0）に制限します。

デフォルトはログディスクの 85% です。

型: int
デフォルト: 0.85
重要度: 中

confluent.balancer.disk.max.replicas¶

ブローカーごとに許可されるレプリカの最大数を指定します。

デフォルトのレプリカ数は 10,000 個です。

型: int
デフォルト: 10000
重要度: 中

confluent.balancer.exclude.topic.names¶

Self-Balancing で移動されないトピックを指定します。コンマ区切りのリストで複数のトピックを指定できます。

たとえば、次の構成では、トピック pizza と popcorn が除外されます。

confluent.balancer.exclude.topic.names=pizza,popcorn
Copy

型: string
デフォルト: ""
重要度: 中

ちなみに

削除処理ではこの設定に関係なく、常にトピックが移動されます。
ベストプラクティスとして、除外トピックは最小限に抑え、この構成は必要な場合にのみ使用します。大量のトピックを除外に設定すると、Self-Balancing の動作に影響を及ぼします。詳細については、トラブルシューティングの「除外トピックが多すぎるため、Self-Balancing で問題が発生する」を参照してください。

confluent.balancer.exclude.topic.prefixes¶

Self-Balancing で移動されないトピックを、トピックのプレフィックスを基に指定します。コンマ区切りのリストで、複数のトピックのプレフィックスを指定できます。

たとえば、次の構成では、pizza.sales.ny および pizza.sales.tx で始まるすべてのトピックが除外されます。

confluent.balancer.exclude.topic.prefixes=pizza.sales.ny,pizza.sales.tx
Copy

型: string
デフォルト: ""
重要度: 中

ちなみに

削除処理ではこの設定に関係なく、常にトピックが移動されます。
ベストプラクティスとして、除外トピックは最小限に抑え、この構成は必要な場合にのみ使用します。大量のトピックを除外に設定すると、Self-Balancing の動作に影響を及ぼします。詳細については、トラブルシューティングの「除外トピックが多すぎるため、Self-Balancing で問題が発生する」を参照してください。

confluent.balancer.topic.replication.factor¶

Self-Balancing が内部ステートを格納するために使用する、トピックのレプリケーション係数を指定します。

デフォルト値は 3 です。

型: int
デフォルト値: 3
重要度: 中

注釈

デプロイのテスト以外では、可用性を確保するため、confluent.balancer.topic.replication.factor を 1 より大きい値にすることを推奨します。
（Self-Balancing に関係なく）レプリケーション係数には、ブローカーの総数を超える値を指定できません。
Self-Balancing が有効であるとき、server.properties の confluent.balancer.topic.replication.factor の値と replication.factor の他のすべてのインスタンスに、1 より大きくクラスターのブローカー総数より "少ない" 値を設定する必要があります。レプリケーション係数の値がデプロイされたブローカーの総数に等しいとき、ブローカーが停止または削除されると、このレプリケーション係数によりバランス調整が妨げられます。

Self-Balancing の内部トピック¶

Self-Balancing は以下のシステム、つまり "内部" トピックを作成します。これはクラスターの自動バランス調整を管理するために使用されます。

_confluent_balancer_api_state: Self-Balancing API で使用するステート情報を格納します。
_confluent_balancer_partition_samples: パーティションメトリクスを格納します。
_confluent_balancer_broker_samples: ブローカーメトリクスを格納します。

さらに、Self-Balancing には、Confluent Telemetry Reporter からのクラスターパフォーマンスに関するメトリクスが必要です。これは、Self-Balancing が有効な場合にデフォルトで有効になります（confluent.reporters.telemetry.auto.enable = true）。処理負荷、メッセージキューサイズ、応答時間、レプリケーションデータなどに関する、Self-Balancing に特に必要なメトリクスは、内部トピック _confluent-telemetry-metrics に送信されます。Self-Balancing は、この内部トピックから読み取り、バランス調整アルゴリズムでメトリクスを使用します。Self-Balancing を実行すると、_confluent-telemetry-metrics は短時間で大量のデータを収集できます。内部トピックのデフォルトの保持期間は 3 日間ですが、これは kafka-topics --config を使用して変更できます。Self-Balancing に関するこのトピックでは通常、1 日の保持期間で十分です。

規定により、Confluent Platform システムトピックの名前の先頭にアンダースコアを付けます。Self-Balancing トピック名の先頭には _confluent_balancer_ を付けます。次のとおり、既存のトピックのリスト（ユーザー作成トピックとシステムトピック）を取得できます。

kafka-topics --list --bootstrap-server localhost:9092
Copy

すべてのトピックまたは指定トピックで --describe オプションを指定すると、詳細情報を取得できます。

kafka-topics --describe --bootstrap-server localhost:9092
Copy

kafka-topics --describe --topic <topic> --bootstrap-server localhost:9092
Copy

たとえば、kafka-topics --describe を _confluent_balancer_partition_samples トピックで実行すると、次のような出力が表示されます。

Topic: _confluent_balancer_partition_samples PartitionCount: 32      ReplicationFactor: 2    Configs: cleanup.policy=delete,segment.bytes=1073741824,retention.ms=3600000
Topic: _confluent_balancer_partition_samples Partition: 0    Leader: 0       Replicas: 0,2   Isr: 0,2        Offline:
Topic: _confluent_balancer_partition_samples Partition: 1    Leader: 4       Replicas: 4,3   Isr: 4,3        Offline:
Topic: _confluent_balancer_partition_samples Partition: 2    Leader: 1       Replicas: 1,0   Isr: 1,0        Offline:
Topic: _confluent_balancer_partition_samples Partition: 3    Leader: 2       Replicas: 2,4   Isr: 2,4        Offline:
Topic: _confluent_balancer_partition_samples Partition: 4    Leader: 3       Replicas: 3,1   Isr: 3,1        Offline:
Topic: _confluent_balancer_partition_samples Partition: 5    Leader: 0       Replicas: 0,3   Isr: 0,3        Offline:
Topic: _confluent_balancer_partition_samples Partition: 6    Leader: 4       Replicas: 4,0   Isr: 4,0        Offline:
Topic: _confluent_balancer_partition_samples Partition: 7    Leader: 1       Replicas: 1,4   Isr: 1,4        Offline:
...
Copy

Control Center の必須構成¶

Self-Balancing が Confluent Control Center のモニタリング機能と通信するには、組み込みの Confluent REST Proxy が必要になります。

Control Center のプロパティファイルでの REST エンドポイントの構成¶

Control Center を Self-Balancing の構成とモニタリングに使用する場合、Control Center クラスターに REST エンドポイントを構成し、ブローカーで HTTP サーバーを有効にする必要があります。すべてのブローカーでこれが適切に構成されていない場合、Self-Balancing に Confluent Control Center からアクセスできません。

該当する Control Center プロパティファイルで confluent.controlcenter.streams.cprest.url を使用して、controlcenter.cluster の REST エンドポイントを定義します。デフォルトは以下に示すように http://localhost:8090 です。

# Kafka REST endpoint URL
confluent.controlcenter.streams.cprest.url="http://localhost:8090"
Copy

各ブローカーの関連 URL を特定します。クラスターに複数のブローカーがある場合は、コンマ区切りのリストを使用します。

参考

Self-Balancing チュートリアルの「REST エンドポイントとアドバタイズされたリスナーを使用する Control Center の構成」の5 つのブローカーがあるクラスターでこれを構成する例
「Control Center の構成リファレンス」の confluent.controlcenter.streams.cprest.url
「トラブルシューティング」の「Self-Balancing オプションが Control Center に表示されない」

Kafka ブローカーでの REST エンドポイントの認証の構成（セキュアなセットアップ）¶

ちなみに

Self-Balancing では Metadata Service（MDS）やセキュリティを実行する必要はありませんが、セキュリティを構成する場合は、RBAC の MDS クライアント構成を示す以下の例から始めることができます。
confluent.http.server.listeners の代わりに（Metadata Service を有効にする） confluent.metadata.server.listeners を使用して API リクエストをリッスンできます。confluent.metadata.server.listeners または confluent.http.server.listeners を使用できますが、両方を使用することはできません。リスナーが HTTPS を使用する場合は、適切な SSL 構成パラメーターも設定する必要があります。詳細については、「Admin REST APIs の構成オプション」を参照してください。

セキュアなセットアップで Self-Balancing を実行するには、Kafka ブローカーの各 server.properties ファイルで REST エンドポイントの認証を構成する必要があります。Kafka ブローカーファイルにこれらの構成がない場合、Control Center はセキュアなセットアップの Self-Balancing にアクセスできません。

最小限でも、以下の構成が必要になります。

# EmbeddedKafkaRest: HTTP Auth Configuration
kafka.rest.kafka.rest.resource.extension.class=io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension
kafka.rest.rest.servlet.initializor.classes=io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler
Copy

以下は、ブローカーの server.properties ファイルでの Kafka RBAC 用 MDS クライアント構成の例です。

# EmbeddedKafkaRest: Kafka Client Configuration
kafka.rest.bootstrap.servers=<host:port>, <host:port>, <host:port>
kafka.rest.client.security.protocol=SASL_PLAINTEXT

# EmbeddedKafkaRest: HTTP Auth Configuration
kafka.rest.kafka.rest.resource.extension.class=io.confluent.kafkarest.security.KafkaRestSecurityResourceExtension
kafka.rest.rest.servlet.initializor.classes=io.confluent.common.security.jetty.initializer.InstallBearerOrBasicSecurityHandler
kafka.rest.public.key.path=<rbac_enabled_public_pem_path>

# EmbeddedKafkaRest: MDS Client configuration
kafka.rest.confluent.metadata.bootstrap.server.urls=<host:port>, <host:port>, <host:port>
kafka.rest.ssl.truststore.location=<truststore_location>
kafka.rest.ssl.truststore.password=<password>
kafka.rest.confluent.metadata.http.auth.credentials.provider=BASIC
kafka.rest.confluent.metadata.basic.auth.user.info=<user:password>
kafka.rest.confluent.metadata.server.urls.max.age.ms=60000
kafka.rest.cilent.confluent.metadata.server.urls.max.age.ms=60000
Copy

参考

セキュリティに関する考慮事項
Admin REST APIs のセキュリティ
REST Proxy のセキュリティ
「Confluent Platform のデモ（cp-demo）」のオンプレミスチュートリアルの「セキュリティ」セクションに提供されている、さまざまな種類の構成の例

サンプル: ブローカー構成のオンザフライでのアップデート¶

Self-Balancing の設定のほとんどでは、アップデートするにはブローカーを停止し、クラスターをシャットダウンする必要があります。ただし、次のクラスターのデフォルト設定は動的です。つまりクラスターが実行中でも実行できます。

これらの動的プロパティの値を Confluent Control Center を通じて、またはコマンドラインの kafka-configs コマンドおよび --entity-default フラグで変更できます（次の例を参照）。

ちなみに

サンプルを実行するには、ブートストラップの <host:port> を指定する必要があります。クラスターがローカルホストで動作している場合、--bootstrap-server のデフォルトは localhost:9092 です。

Self-Balancing の有効化または無効化¶

confluent.balancer.enable （Self-Balancing のオンオフの切り替え）を使用します。

Self-Balancing をオンにするには、以下のとおり実行します。

kafka-configs --bootstrap-server <host:port> --entity-type brokers --entity-default --alter --add-config confluent.balancer.enable=true
Copy

Self-Balancing をオフにするには、以下のとおり実行します。

kafka-configs --bootstrap-server <host:port> --entity-type brokers --entity-default --alter --add-config confluent.balancer.enable=false
Copy

ちなみに

ブローカーの追加操作または削除操作が実行されている間は Self-Balancing を無効にしてはいけません。追加または削除が完了するまで待機してください。いずれかの操作の実行中に Self-Balancing を無効にすると、ブローカーにパーティションを分散配置できなくなります。

バランス調整のトリガー条件の設定¶

confluent.balancer.heal.uneven.load.trigger を使用して、"ブローカーが追加" または削除されたときのみバランス調整をしたり、あるいは均等ではない負荷を "常に" バランス調整したりできます。

Self-Balancing を均等ではない負荷（利用可能なブローカーの変化を含む）をバランス調整するように設定します。

kafka-configs --bootstrap-server <host:port> --entity-type brokers --entity-default --alter --add-config confluent.balancer.heal.uneven.load.trigger=ANY_UNEVEN_LOAD
Copy

Self-Balancing をブローカーが追加または削除されたときのみバランス調整するように設定します。

kafka-configs --bootstrap-server <host:port> --entity-type brokers --entity-default --alter --add-config confluent.balancer.heal.uneven.load.trigger=EMPTY_BROKER
Copy

カスタムスロットルの設定または削除¶

confluent.balancer.throttle.bytes.per.second を使用すると、Self-Balancing で利用できる最大ネットワーク帯域幅にカスタムスロットルを設定したり、カスタムスロットルを削除したりできます。

再割り当て処理のデフォルトスロットル値（10485760 つまり 10 MB/秒）をカスタムの固定値でオーバーライドするには、以下のとおり実行します。

kafka-configs --bootstrap-server <host:port> --entity-type brokers --entity-default --alter --add-config confluent.balancer.throttle.bytes.per.second=70485760
Copy

カスタムスロットルを無効にするには、以下のとおり実行します。

kafka-configs --bootstrap-server <host:port> --entity-type brokers --entity-default --alter --delete-config confluent.balancer.throttle.bytes.per.second
Copy

ちなみに

動的構成は「Confluent REST Proxy API リファレンス」で示すように変更することもできます。

kafka-remove-brokers¶

Confluent Enterprise 6.0.0 には新しい Kafka コマンド kafka-remove-brokers が含まれています。

このコマンドが機能するには、Self-Balancing を有効にする必要があります。

ちなみに

削除するブローカーに格納されているレプリカがいずれかのトピックにとって唯一のレプリカである場合、このブローカーの削除は失敗します。詳細については、「制限」を参照してください。
メトリクスの収集が完了していない場合、バランス調整計画の生成に十分なメトリクスがないため、ブローカーの削除の試行はほぼ即座に失敗します。ブローカーの削除に失敗した場合は、30 分待機してから再試行します。Self-Balancing の初期化が完了し、メトリクスを収集する時間がある場合、この処理は成功します。詳細については、トラブルシューティングの「Self-Balancing の初期化中にブローカーの削除の試行に失敗する」を参照してください。
ブローカーを Control Center UI からも削除できます。
ブローカーの追加操作または削除操作が実行されている間は Self-Balancing を無効にしてはいけません。追加または削除が完了するまで待機してください。いずれかの操作の実行中に Self-Balancing を無効にすると、ブローカーにパーティションを分散配置できなくなります。

フラグ¶

kafka-remove-brokers コマンドには、次の必須フラグとオプションフラグがあります。

--bootstrap-server

クラスターのブローカー用の、host:port 形式の接続文字列です。複数の URL（コンマ区切り）を指定することで、ブローカーノードが停止した場合にフェイルオーバーできます。（必須）

型: string
デフォルト: 空の文字列
重要度: 高

--delete

1 つのブローカーをクラスターから削除します。

型: string
デフォルト: ""
重要度: 高

--describe

ブローカー削除のステータスを表示します。

型: string
デフォルト: ""
重要度: 中

--broker-id

削除するブローカーの ID。（必須）

型: string
デフォルト: 空の文字列
重要度: 低

--command-config

管理クライアントに渡す構成を含むプロパティファイルを指定します。このオプションを使用できるのは --bootstrap-server オプションを指定した場合だけです。

型: string
デフォルト: ""
重要度: 低

--version

Kafka のバージョンを表示します。

型: string
デフォルト: ""
重要度: 低

例¶

次のコマンドはブローカー 2 を削除し、データをブローカー 1 に移動します（この例では、合計 5 個のブローカーを使用しています）。
```
./bin/kafka-remove-brokers --bootstrap-server localhost:9092,localhost:9093,localhost:9094,localhost:9095,localhost:9096 --broker-id 1 --delete 1>&2 | grep -v SLF4J
```
Copy

次のコマンドでは、バランス調整処理のステータスを表示します（--describe フラグが --delete の代わりに使用されています）。

./bin/kafka-remove-brokers --bootstrap-server localhost:9092,localhost:9093,localhost:9094,localhost:9095,localhost:9096 --broker-id 1 --describe 1>&2 | grep -v SLF4J
Copy

ブローカーの削除のフェーズ¶

ブローカーの削除処理を理解すると、Self-Balancing のモニタリングとトラブルシューティングで役に立ちます。ブローカーの削除を完了するには、Self-Balancing で次のタスクを順に実行します。

Self-Balancing が動作するコントローラー（リードブローカー）で利用できるブローカーのメトリクスを検証します（一種のリハーサルです）。
対象ブローカーをシャットダウンします。
パーティションの再割り当て（バランス調整）計画を算出します。
計画を実行し、パーティションを再割り当てして、トピックデータを移動します。

ちなみに

ブローカーを削除している間、クラスターには、一時的にレプリケーション数が不足するパーティションが発生します。バランス調整（上記のフェーズ 4）によりこれが自動的に解決されます。
十分なメトリクスがないためにブローカーの削除が失敗した場合にも、クラスターにレプリケーション数不足のパーティションが残ることがあります。これは、Self-Balancing が初期化されると自動的に解決されます。

ブローカーの削除は、次のシナリオで説明するように、Self-Balancing の初期化中に試行すると、失敗することがあります。

シナリオ 1: 十分なメトリクスがない場合（フェーズ 1）、初期化中にブローカーの削除を試行すると失敗します。解決策としては、Self-Balancing の初期化が完了するまで（約 30 分）待機し、ブローカーの削除を再試行します。

シナリオ 2: 初期化中にコントローラーの削除を試行すると、フェーズ 3 で失敗します。このシナリオでは、Self-Balancing はリードブローカーについて計画を算出するためのメトリクスを十分に収集できる程度に長時間動作しています。つまり、フェーズ 2 と 2 を通過して、削除するブローカーをシャットダウンしています。ただし、Self-Balancing のメトリクスの収集は、他のすべてのブローカー（その内の 1 つはフェイルオーバーコントローラー）で Self-Balancing メトリクスを得るのに十分なほどには進んでいません。これにより削除処理がストールします。コントローラーがシャットダウンされた（フェーズ 2）ので、Control Center で利用できないからです。ここでの解決策はシナリオ 1 と同様です。待機して、ブローカーの削除をコマンドラインから再試行します。

詳細については、「Self-Balancing の初期化中にブローカーの削除の試行に失敗する」を参照してください。

Self-Balancing の初期化¶

実行中のクラスターに対して Self-Balancing を有効にするとき、または既に Self-Balancing を有効にした状態でクラスターを起動するときは、初期化に約 30 分かかります。初期化には、クラスターのすべてのブローカーを対象とした、リードブローカーによるメトリクスの収集が含まれます。バランス調整計画を策定するために、Self-Balancing にはクラスターの十分なメトリクスが必要です。

したがって、メトリクスの収集は、Self-Balancing の各タスクを実行するための前提条件となります。初期化処理中にブローカーの削除を試行すると、この処理は失敗します。解決策は、Self-Balancing が初期化した後に、ブローカーの削除を再試行することです。削除を試行するブローカーがコントローラーである場合、コマンドラインから実行する必要があります。Control Center で利用できなくなるからです。詳細については、「ブローカーの削除のフェーズ」および「Self-Balancing の初期化中にブローカーの削除の試行に失敗する」を参照してください。

ブローカー削除タスクの優先度¶

Self-Balancing は、ブローカーの追加や通常のバランス調整の実行などのタスクより、ブローカーの削除リクエストの相対優先度を高くします。

優先度 1: ブローカーの削除
優先度 2: ブローカーの追加
優先度 3: 通常のバランス調整

継続中のブローカーの削除リクエストは、後続のリクエストより高い優先度になります。Self-Balancing は、ブローカーの削除タスクが進行中である場合、新しい "ブローカーの削除" リクエストを拒否します。

新しい "ブローカーの追加" リクエストを、別の "ブローカーの追加" タスクが進行中に受け取ると、Self-Balancing は新しいリクエストを進行中のタスクにマージします。

Self-Balancing Clusters の構成オプションとコマンド¶

ブローカーでの Self-Balancing の構成¶

confluent.balancer.enable¶

confluent.balancer.heal.uneven.load.trigger¶

confluent.balancer.heal.broker.failure.threshold.ms¶

confluent.balancer.throttle.bytes.per.second¶

スロットル設定を選択する方法¶

confluent.balancer.disk.max.load¶

confluent.balancer.disk.max.replicas¶

confluent.balancer.exclude.topic.names¶

confluent.balancer.exclude.topic.prefixes¶

confluent.balancer.topic.replication.factor¶

Self-Balancing の内部トピック¶

Control Center の必須構成¶

Control Center のプロパティファイルでの REST エンドポイントの構成¶

Kafka ブローカーでの REST エンドポイントの認証の構成（セキュアなセットアップ）¶

サンプル: ブローカー構成のオンザフライでのアップデート¶

Self-Balancing の有効化または無効化¶

バランス調整のトリガー条件の設定¶

カスタムスロットルの設定または削除¶

kafka-remove-brokers¶

フラグ¶

例¶

ブローカーの削除のフェーズ¶

Self-Balancing の初期化¶

ブローカー削除タスクの優先度¶

おすすめの関連情報¶