第25章 Rack スキーマ参照
使用先: KafkaBridgeSpec
、KafkaClusterSpec
、KafkaConnectSpec
、KafkaMirrorMaker2Spec
rack
オプションは、ラックの認識を設定します。ラックは、アベイラビリティーゾーン、データセンター、またはデータセンターの実際のラックを表すことができます。rackの設定は、topologyKey
で行います。topologyKey
は、OpenShift ノード上のラベルを識別するもので、その値にはトポロジーの名前が含まれています。このようなラベルの例としては、topology.kubernetes.io/zone
(古い OpenShift バージョンでは failure-domain.beta.kubernetes.io/zone
) があり、これには OpenShift ノードが実行されているアベイラビリティゾーンの名前が含まれています。Kafka クラスターが実行するラックを認識するように設定し、パーティションレプリカを異なるラックに分散したり、最も近いレプリカからのメッセージの消費したりするなどの追加機能を有効にできます。
OpenShift ノードラベルの詳細は、Well-Known Labels, Annotations and Taints を参照してください。ノードがデプロイされたゾーンやラックを表すノードラベルについては、OpenShift 管理者に相談します。
25.1. ラック間でのパーティションレプリカの分散 リンクのコピーリンクがクリップボードにコピーされました!
ラックアウェアネスを設定すると、AMQ Streams は各 Kafka ブローカーの broker.rack
設定を行います。broker.rack の
設定では、各ブローカにラック ID を割り当てます。broker.rack
を設定すると、Kafka ブローカーはパーティションレプリカをできるだけ多くの異なるラックに分散して配置します。レプリカが複数のラックに分散されている場合、複数のレプリカが同時に失敗する可能性は、同じラックにある場合よりも低くなります。レプリカを分散すると回復性が向上し、可用性と信頼性にとっても重要です。Kafka でラックアウェアネスを有効にするには、以下の例のように、Kafka
のカスタムリソースの .spec.kafka
セクションに rack
オプションを追加します。
Kafka の rack
設定例
Pod が削除または再起動すると、ブローカーが実行されているラックは、変更されることがあります。その結果、異なるラックで実行しているレプリカが、同じラックを共有する可能性があります。RackAwareGoal
で Cruise Control と KafkaRebalance
リソースを使用して、レプリカが異なるラックに分散していることを確認します。
Kafka
カスタムリソースでラックアウェアネスが有効になっている場合、AMQ Streams は自動的に OpenShift の preferredDuringSchedulingIgnoredDuringExecution
アフィニティールールを追加して、Kafka ブローカーを異なるラックに分散させます。ただし、優先 ルールは、ブローカーが分散されることを保証しません。OpenShift と Kafka の設定に応じて、affinity
ルールを追加したり、ZooKeeper と Kafka の両方に topologySpreadConstraints
を設定したりして、できるだけ多くのラックにノードが適切に分散されるようにしてください。詳細は、Pod スケジュールの設定 を参照してください。