MicroStrategy ONE

ZooKeeper から KRaft モードへの移行

Strategy One (2025年12月) 以降、Kafka は Platform Analytics で KRaft モードのみで動作するようになります。このアップデートにより、ZooKeeper サービスの要件と可用性が削除され、バージョン 4.10 の時点で最新の Kafka アーキテクチャと一致して、パフォーマンスが向上し、レジリエンスが改善されます。

既存のデータの移行はサポートされていないことに注意してください。既存のすべてのテレメトリ データは、Strategy One (2025年12月) 以降にアップグレードする前に完全に処理する必要があります。

主なアップグレードの影響

  1. データ移行の制限: 履歴データの移行なし

    Kafka v4.1.0 以降では、ZooKeeper から KRaft モードへの履歴データまたはコンシューマー グループ オフセットの移行がサポートされていません。

    • 現在の Kafka クラスター (ZooKeeper を使用) 内の既存のデータは、アップグレード後に使用できなくなります。

    • お客様は、アップグレードを開始する前に、既存のすべてのテレメトリ データを処理する必要があります。未処理のレコードとオフセットは転送または保存できないため、データ損失を回避するために必要です。

    アップグレードする前に、以下を完了する必要があります:

    • すべての処理中のデータを処理: すべての Platform Analytics コンシューマーがすべてのトピック パーティションの使用を完了し、バックログをクリアしていることを確認します。

    • コンシューマーの完了を検証: lu_topic_partition_offset テーブルを確認して、オフセットが増加しなくなったことを確認します。これは、コンシューマーがすべてのトピックからのデータの処理を完了したことを示します。

    • オンプレミスおよびインスタンスベースのユーザーの場合、すべてのデータを処理せずに誤ってアップグレードした場合は、古い ZooKeeper モードでクラスターを一時的に再起動して、残りのレコードを処理してから、最終的に KRaft に移行できます。

      すべてのデータを処理せずにアップグレードすると、未処理のテレメトリは永久に失われます。

  2. アーキテクチャの変更: ZooKeeper の削除

    v4.1.0 以降、ZooKeeper は Kafka デプロイメントに含まれなくなりました。

    • ZooKeeper サービスまたはコンテナー/ポッドは不要になりました。

    • すべてのクラスター メタデータと調整は、Raft コンセンサス プロトコル (KRaft) を介して Kafka 内で行われます。

  3. アップグレード要件

    • すべてのブローカーを一度にアップグレードする必要があります: 混合モード クラスターはサポートされていません。一部のブローカーを ZooKeeper で、他のブローカーを KRaft で同時に実行することはできません。

    • ネットワーク構成: コントローラー クォーラム トラフィックに必要なポートを開き、必要に応じてファイアウォール/ネットワーク ポリシーを更新します。

Platform Analytics 用の KRaft モードで 3 ノード Kafka クラスターを構成する

単一ノード Kafka デプロイメントは、Windows および Linux インストーラーによって標準で利用できます。以下の手順を使用して、3 ノード クラスターをデプロイします。

前提条件

ノード: 3 つの Linux サーバーが必要です:

  • ノード 1: <IP Node1>

  • ノード 2: <IP Node2>

  • ノード 3: <IP Node3>

クラスター ID: 汎用一意識別子 (UUID) を使用します。例: 11111111-1111-1111-1111-111111111111。

3 ノード Kafka クラスターを構成する

  1. 各ノードで config/server.properties ファイルを次のように作成または編集します:

    • ノード 1 (<IP Node1>):

      コピー 
      node.id=1
      listeners=PLAINTEXT://<IP Node1>:9092,CONTROLLER://<IP Node1>:9093
      advertised.listeners=PLAINTEXT://<IP Node1>:9092
      controller.quorum.bootstrap.servers=<IP Node1>:9093,<IP Node2>:9093,<IP Node3>:9093
      controller.quorum.voters=1@<IP Node1>:9093,2@<IP Node2>:9093,3@<IP Node3>:9093
      offsets.topic.replication.factor=3
      share.coordinator.state.topic.replication.factor=3
      transaction.state.log.replication.factor=3

    • ノード 2 (<IP Node2>):

      コピー 
      node.id=2
      listeners=PLAINTEXT://<IP Node2>:9092,CONTROLLER://<IP Node2>:9093
      advertised.listeners=PLAINTEXT://<IP Node2>:9092
      controller.quorum.bootstrap.servers=<IP Node1>:9093,<IP Node2>:9093,<IP Node3>:9093
      controller.quorum.voters=1@<IP Node1>:9093,2@<IP Node2>:9093,3@<IP Node3>:9093
      offsets.topic.replication.factor=3
      share.coordinator.state.topic.replication.factor=3
      transaction.state.log.replication.factor=3

    • ノード 3 (<IP Node3>):

      コピー 
      node.id=3
      listeners=PLAINTEXT://<IP Node3>:9092,CONTROLLER://<IP Node3>:9093
      advertised.listeners=PLAINTEXT://<IP Node3>:9092
      controller.quorum.bootstrap.servers=<IP Node1>:9093,<IP Node2>:9093,<IP Node3>:9093
      controller.quorum.voters=1@<IP Node1>:9093,2@<IP Node2>:9093,3@<IP Node3>:9093
      offsets.topic.replication.factor=3
      share.coordinator.state.topic.replication.factor=3
      transaction.state.log.replication.factor=3

  2. すべてのノードで同じクラスター ID を使用して、各ノードで次を実行します:

    コピー 
    bin/kafka-storage.sh format -t 11111111-1111-1111-1111-111111111111 -c config/server.properties

  3. 各ノードで、次を使用して Kafka をデーモンとして起動します:

    コピー 
    bin/kafka-server-start.sh -daemon config/server.properties

  4. 任意のノードで、KRaft クォーラム ステータスを確認します:

    コピー 
    bin/kafka-metadata-quorum.sh --bootstrap-server <IP Node3>:9092 describe --status

    次のような詳細が表示されます:

    コピー 
    ClusterId:              11111111-1111-1111-1111-111111111111
    LeaderId:               3
    CurrentVoters: [{"id": 1, "endpoints": [...]}, {"id": 2, ...}, {"id": 3, ...}]
    ...

  5. 次を使用して、Platform Analytics と Intelligence Server を構成します:

    • Platform Analytics Consumer (PAConsumerConfig.yaml):

      コピー 
      kafkaTopicNumberOfReplicas: 3
      kafkaConsumerProperties:
          bootstrap.servers: "<IP Node1>:9092,<IP Node2>:9092,<IP Node3>:9092"

    • Intelligence Server (Command Manager 経由):

      コピー 
      ALTER SERVER CONFIGURATION ENABLEMESSAGINGSERVICES TRUE CONFIGUREMESSAGINGSERVICES "bootstrap.servers:<IP Node1>:9092,<IP Node2>:9092,<IP Node3>:9092/batch.num.messages:5000/queue.buffering.max.ms:2000";

    • Library Config:

      コピー 
      producer.kafkaProperties.bootstrap.servers = <IP Node1>:9092,<IP Node2>:9092,<IP Node3>:9092

  6. Kafka の起動後、Kafka トピック データ フォルダー kafka_data が各ノードで利用可能であることを確認します。

  7. 次のテスト メッセージを送信します:

    コピー 
    bin/kafka-console-producer.sh --bootstrap-server <IP Node3>:9092 --topic Mstr.PlatformAnalytics.IsReportSecurityFilterStats

    次のメッセージを使用してテストします:

    コピー 
    bin/kafka-console-consumer.sh --bootstrap-server <IP Node3>:9092 --topic Mstr.PlatformAnalytics.IsReportSecurityFilterStats --from-beginning

    メッセージが表示され、ノード間レプリケーションとクラスターの健全性が確認されます。

追加情報

  • ZooKeeper サービスは不要です - ZooKeeper プロパティを構成しないでください。

  • 3 つのノードすべてが同じクラスター ID を使用する必要があります。

  • フォールト トレランスのために、レプリケーション係数はブローカーの数と同じでなければなりません。

よくある質問

1. 既存の Kafka データとオフセットを新しいクラスターに移行できますか?

いいえ。ZooKeeper から KRaft クラスターへの履歴データ移行はサポートされていません。既存のすべてのデータは、アップグレード前に処理する必要があります。

2. アップグレード後に ZooKeeper サービスは存在しますか?

いいえ。ZooKeeper はアーキテクチャから完全に削除されます。すべての調整は、Raft を介して Kafka 内で管理されます。

Kafka サービス スクリプトの更新

/etc/init.d の下の Linux サービス スクリプトは、mstr-user@install_time-kafka-zookeeper から mstr-user@install_time-kafka に名前が変更されます。

新しい Kafka サービス コマンド

制御コマンドが kafka-zookeeper から kafka に変更されました:

コピー 
service microstrategy kafkastart | kafkastop | kafkastatus

3. 未処理のデータがある状態で誤ってアップグレードした場合はどうなりますか?

データは失われます。オンプレミス デプロイメントの場合、古い Kafka (ZooKeeper モード) を一時的に起動し、処理を完了してから、再アップグレードできます。