8.10. Kafka および ZooKeeper ストレージの設定


AMQ Streams は、Kafka と ZooKeeper のデータストレージオプションを柔軟に設定できます。

サポート対象のストレージタイプは次のとおりです。

  • 一時データストレージ (開発用のみで推奨されます)
  • 永続ストレージ
  • JBOD (Kafka のみ。ZooKeeper では使用できません)

ストレージを設定するには、コンポーネントのカスタムリソースで storage プロパティーを指定します。ストレージタイプは、storage.type プロパティーを使用して設定されます。

また、ノードプール機能のプレビューを使用して、Kafka クラスターの高度なストレージ管理を行うこともできます。クラスター内で使用される各ノードプールに固有のストレージ設定を指定できます。Kafka リソースで使用できる同じストレージプロパティーは、KafkaNodePool プールリソースでも使用できます。

ストレージ関連のスキーマ参照では、ストレージ設定プロパティーに関する詳細情報が提供されます。

警告

Kafka クラスターをデプロイした後に、ストレージタイプを変更することはできません。

8.10.1. データストレージに関する留意事項

AMQ Streams がうまく機能するには、効率的なデータストレージインフラストラクチャーが不可欠です。ブロックストレージを使用することを強く推奨します。AMQ Streams は、ブロックストレージでの使用についてのみテストされています。NFS などのファイルストレージはテストされておらず、動作するという保証はありません。

ブロックストレージには、以下のいずれかのオプションを選択します。

  • Amazon Elastic Block Store (EBS) などのクラウドベースのブロックストレージソリューション。
  • ローカル永続ボリューム を使用した永続ストレージ
  • ファイバーチャネルiSCSI などのプロトコルがアクセスする SAN (ストレージエリアネットワーク) ボリューム
注記

AMQ Streams には OpenShift の raw ブロックボリュームは必要ありません。

8.10.1.1. ファイルシステム

Kafka は、メッセージの保存にファイルシステムを使用します。AMQ Streams は、Kafka で一般的に使用される XFS および ext4 ファイルシステムと互換性があります。ファイルシステムを選択して設定するときは、デプロイメントの基盤となるアーキテクチャーと要件を考慮してください。

詳細については、Kafka ドキュメントの Filesystem Selection を参照してください。

8.10.1.2. ディスク使用量

Apache Kafka と ZooKeeper には別々のディスクを使用します。

ソリッドステートドライブ (SSD) は必須ではありませんが、複数のトピックに対してデータが非同期的に送受信される大規模なクラスターで Kafka のパフォーマンスを向上させることができます。SSD は、高速で低レイテンシーのデータアクセスが必要な ZooKeeper で特に有効です。

注記

Kafka と ZooKeeper の両方にデータレプリケーションが組み込まれているため、レプリケーションされたストレージのプロビジョニングは必要ありません。

8.10.2. 一時ストレージ

一時データストレージは一時的なものです。ノード上のすべての Pod は、ローカルの一時ストレージスペースを共有します。データは、それを使用する Pod が実行されている限り保持されます。Pod が削除されると、データは失われます。ただし、Pod は高可用性環境でデータを回復できます。

その一時的な性質のため、一時ストレージは開発とテストにのみ推奨されます。

一時ストレージは emptyDir ボリュームを使用してデータを保存します。Pod がノードに割り当てられると、emptyDir ボリュームが作成されます。sizeLimit プロパティーを使用して、emptyDir のストレージの合計量を設定できます。

重要

一時ストレージは、単一ノードの ZooKeeper クラスターやレプリケーション係数が 1 の Kafka トピックでの使用には適していません。

一時ストレージを使用するには、Kafka または ZooKeeper リソースのストレージタイプ設定を ephemeral に設定します。ノードプール機能のプレビューを使用している場合は、個々のノードプールのストレージ設定に ephemeral を指定することもできます。

一時ストレージ設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: ephemeral
    # ...
  zookeeper:
    storage:
      type: ephemeral
    # ...
Copy to Clipboard Toggle word wrap

8.10.2.1. Kafka ログディレクトリーのマウントパス

一時ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。

/var/lib/kafka/data/kafka-logIDX
Copy to Clipboard Toggle word wrap

IDX は、Kafka ブローカー Pod インデックスです。たとえば、/var/lib/kafka/data/kafka-log0 のようになります。

8.10.3. 永続ストレージ

永続的なデータストレージは、システムが中断した場合でもデータを保持します。永続的なデータストレージを使用する Pod の場合、データは Pod の障害や再起動後も保持されます。永続的な性質のため、実稼働環境には永続ストレージを推奨します。

AMQ Streams で永続ストレージを使用するには、Kafka または ZooKeeper リソースのストレージ設定に persistent-claim を指定します。ノードプール機能のプレビューを使用している場合は、個々のノードプールのストレージ設定で Persistent-claim を指定することもできます。

Pod が Persistent Volume Claim (PVC) を使用して Persistent Volume (PV) 上でストレージ要求を行うようにリソースを設定します。PV は、オンデマンドで作成され、それを使用する Pod から独立したストレージボリュームを表します。PVC は、Pod の作成時に必要なストレージの量を要求します。PV の基盤となるストレージインフラストラクチャーを理解する必要はありません。PV がストレージ基準に一致する場合、PVC は PV にバインドされます。

ストレージタイプを指定するには、次の 2 つのオプションがあります。

storage.type: persistent-claim
ストレージタイプとして persistent-claim を選択した場合、単一の永続ストレージボリュームが定義されます。
storage.type: jbod
ストレージタイプとして jbod を選択すると、一意の ID を使用して永続ストレージボリュームの配列を柔軟に定義できます。

実稼働環境では、次のように設定することを推奨します。

  • Kafka またはノードプールの場合は、1 つ以上の永続ボリュームを使用して storage.typejbod に設定します。
  • ZooKeeper の場合、単一の永続ボリュームに対して storage.type をpersistent-claim として設定します。

永続ストレージには、次の設定オプションもあります。

id (任意)
ストレージ ID 番号。このオプションは、JBOD ストレージ宣言で定義されるストレージボリュームには必須です。デフォルトは 0 です。
size (必須)
永続ボリューム要求のサイズ (例: 1000Gi)。
class (任意)
PVC は、StorageClass を指定することにより、さまざまなタイプの永続ストレージを要求できます。ストレージクラスはストレージプロファイルを定義し、そのプロファイルに基づいて PV を動的にプロビジョニングします。ストレージクラスが指定されていない場合、OpenShift クラスターで default としてマークされたストレージクラスが使用されます。永続ストレージオプションには、SAN ストレージタイプまたは ローカル永続ボリューム が含まれる場合があります。
selector (任意)
特定の PV を指定する設定。選択したボリュームのラベルを表す key:value ペアを提供します。
deleteClaim (任意)
クラスターのアンインストール時に PVC を削除するかどうかを指定するブール値。デフォルトは false です。
警告

既存の AMQ Streams クラスターで永続ボリュームのサイズを増やすことは、永続ボリュームのサイズ変更をサポートする OpenShift バージョンでのみサポートされます。サイズを変更する永続ボリュームには、ボリューム拡張をサポートするストレージクラスを使用する必要があります。ボリューム拡張をサポートしないその他のバージョンの OpenShift およびストレージクラスでは、クラスターをデプロイする前に必要なストレージサイズを決定する必要があります。既存の永続ボリュームのサイズを縮小することはできません。

Kafka と ZooKeeper の永続ストレージ設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 2
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
    # ...
  zookeeper:
    storage:
      type: persistent-claim
      size: 1000Gi
    # ...
Copy to Clipboard Toggle word wrap

特定のストレージクラスを使用した永続ストレージ設定の例

# ...
storage:
  type: persistent-claim
  size: 500Gi
  class: my-storage-class
# ...
Copy to Clipboard Toggle word wrap

selector を使用して、SSD などの特定の機能を提供するラベル付き永続ボリュームを指定します。

セレクターを使用した永続ストレージ設定の例

# ...
storage:
  type: persistent-claim
  size: 1Gi
  selector:
    hdd-type: ssd
  deleteClaim: true
# ...
Copy to Clipboard Toggle word wrap

8.10.3.1. ストレージクラスのオーバーライド

デフォルトのストレージクラスを使用する代わりに、1 つ以上の Kafka または ZooKeeper ノードに異なるストレージクラスを指定できます。これは、ストレージクラスが、異なるアベイラビリティーゾーンやデータセンターに制限されている場合などに便利です。この場合、overrides フィールドを使用できます。

以下の例では、デフォルトのストレージクラスの名前は my-storage-class になります。

クラスオーバーライドを使用したストレージ設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  labels:
    app: my-cluster
  name: my-cluster
  namespace: myproject
spec:
  # ...
  kafka:
    replicas: 3
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
        class: my-storage-class
        overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
      # ...
  # ...
  zookeeper:
    replicas: 3
    storage:
      deleteClaim: true
      size: 100Gi
      type: persistent-claim
      class: my-storage-class
      overrides:
        - broker: 0
          class: my-storage-class-zone-1a
        - broker: 1
          class: my-storage-class-zone-1b
        - broker: 2
          class: my-storage-class-zone-1c
  # ...
Copy to Clipboard Toggle word wrap

overrides プロパティーが設定され、ボリュームによって以下のストレージクラスが使用されます。

  • ZooKeeper ノード 0 の永続ボリュームでは my-storage-class-zone-1a が使用されます。
  • ZooKeeper ノード 1 の永続ボリュームでは my-storage-class-zone-1b が使用されます。
  • ZooKeeper ノード 2 の永続ボリュームでは my-storage-class-zone-1c が使用されます。
  • Kafka ブローカー 0 の永続ボリュームでは my-storage-class-zone-1a が使用されます。
  • Kafka ブローカー 1 の永続ボリュームでは my-storage-class-zone-1b が使用されます。
  • Kafka ブローカー 2 の永続ボリュームでは my-storage-class-zone-1c が使用されます。

overrides プロパティーは現在、ストレージ class をオーバーライドするためにのみ使用されます。他のストレージ設定プロパティーのオーバーライドは現在サポートされていません。

8.10.3.2. 永続ストレージ用の PVC リソース

永続ストレージを使用すると、次の名前で PVC が作成されます。

data-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを格納するために使用されるボリュームの PVC。
data-cluster-name-zookeeper-idx
ZooKeeper ノード Pod idx のデータを格納するために使用されるボリュームの PVC。

8.10.3.3. Kafka ログディレクトリーのマウントパス

永続ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。

/var/lib/kafka/data/kafka-logIDX
Copy to Clipboard Toggle word wrap

IDX は、Kafka ブローカー Pod インデックスです。たとえば、/var/lib/kafka/data/kafka-log0 のようになります。

8.10.4. 永続ボリュームのサイズ変更

クラスターで使用される永続ボリュームは、ストレージインフラストラクチャーがサポートしている限り、データ損失のリスクなしにサイズ変更できます。ストレージのサイズを変更するための設定更新に続いて、AMQ Streams はストレージインフラストラクチャーに変更を行うように指示します。ストレージ拡張は、persistent-claim ボリュームを使用する AMQ Streams クラスターでサポートされています。

ストレージの削減は、ブローカーごとに複数のディスクを使用する場合にのみ可能です。ディスク上のすべてのパーティションを同じブローカー内の他のボリューム (ブローカー内) または同じクラスター内の他のブローカー (クラスター内) に移動した後、ディスクを削除できます。

重要

永続ボリュームのサイズは OpenShift で現在サポートされていないため、減らすことはできません。

前提条件

  • ボリュームのサイズ変更をサポートする OpenShift クラスター。
  • Cluster Operator が稼働中である。
  • ボリューム拡張をサポートするストレージクラスを使用して作成された永続ボリュームを使用する Kafka クラスター。

手順

  1. クラスターの Kafka リソースを編集します。

    size プロパティーを変更して、Kafka クラスター、ZooKeeper クラスター、またはその両方に割り当てられた永続ボリュームのサイズを増やします。

    • Kafka クラスターの場合は、spec.kafka.storage の下にある size プロパティーを更新します。
    • ZooKeeper クラスターの場合は、spec.zookeeper.storage の下にある size プロパティーを更新します。

    ボリュームサイズを 2000Giに増やす Kafka 設定

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: persistent-claim
          size: 2000Gi
          class: my-storage-class
        # ...
      zookeeper:
        # ...
    Copy to Clipboard Toggle word wrap

  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>
    Copy to Clipboard Toggle word wrap

    OpenShift では、Cluster Operator からの要求に応じて、選択された永続ボリュームの容量が増やされます。サイズ変更が完了すると、サイズ変更された永続ボリュームを使用するすべての Pod が Cluster Operator によって再起動されます。これは自動的に行われます。

  3. クラスター上の関連する Pod のストレージ容量が増加したことを確認します。

    oc get pv
    Copy to Clipboard Toggle word wrap

    ストレージが増加した Kafka ブローカー Pod

    NAME               CAPACITY   CLAIM
    pvc-0ca459ce-...   2000Gi     my-project/data-my-cluster-kafka-2
    pvc-6e1810be-...   2000Gi     my-project/data-my-cluster-kafka-0
    pvc-82dc78c9-...   2000Gi     my-project/data-my-cluster-kafka-1
    Copy to Clipboard Toggle word wrap

    出力には、ブローカー Pod に関連付けられた各 PVC の名前が表示されます。

8.10.5. JBOD ストレージ

JBOD ストレージを使用すると、複数のディスクまたはボリュームを使用するように Kafka クラスターを設定できます。このアプローチにより、Kafka ブローカーのデータストレージ容量が増え、パフォーマンスが向上する可能性があります。JBOD 設定は 1 つ以上のボリュームによって定義され、各ボリュームは 一時 または 永続 ボリュームのいずれかになります。JBOD ボリューム宣言のルールおよび制約は、一時および永続ストレージのルールおよび制約と同じです。たとえば、プロビジョニング後に永続ストレージのボリュームのサイズを縮小できません。また、タイプが ephemeral の場合は、sizeLimit の値を変更することはできません。

注記

JBOD ストレージは Kafka でのみ サポートされ、ZooKeeper ではサポートされません。

JBOD ストレージを使用するには、Kafka リソースのストレージタイプ設定を jbod に設定します。ノードプール機能のプレビューを使用している場合は、個々のノードプールのストレージ設定に jbod を指定することもできます。

volumes プロパティーを使用すると、JBOD ストレージアレイまたは設定を設定するディスクを記述できます。

JBOD ストレージ設定の例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    storage:
      type: jbod
      volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
      - id: 1
        type: persistent-claim
        size: 100Gi
        deleteClaim: false
  # ...
Copy to Clipboard Toggle word wrap

JBOD ボリュームが作成されると、ID を変更することはできません。JBOD 設定からボリュームを追加または削除できます。

8.10.5.1. JBOD ストレージの PVC リソース

永続ストレージを使用して JBOD ボリュームを宣言すると、次の名前の PVC が作成されます。

data-id-cluster-name-kafka-idx
Kafka ブローカー Pod idx のデータを格納するために使用されるボリュームの PVC。id は、Kafka ブローカー Pod のデータを格納するために使用されるボリュームの ID になります。

8.10.5.2. Kafka ログディレクトリーのマウントパス

JBOD ボリュームは、以下のパスにマウントされるログディレクトリーとして Kafka ブローカーによって使用されます。

/var/lib/kafka/data-id/kafka-logidx
Copy to Clipboard Toggle word wrap

id は、Kafka ブローカー Pod idx のデータを保存するために使用されるボリュームの ID に置き換えます。たとえば、/var/lib/kafka/data-0/kafka-log0 のようになります。

8.10.6. JBOD ストレージへのボリュームの追加

この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターにボリュームを追加する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。

注記

以前使用され、削除された id の下に新規ボリュームを追加する場合、以前使用された PersistentVolumeClaims が必ず削除されているよう確認する必要があります。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator
  • JBOD ストレージのある Kafka クラスター。

手順

  1. Kafka リソースの spec.kafka.storage.volumes プロパティーを編集します。新しいボリュームを volumes アレイに追加します。たとえば、id が 2 の新しいボリュームを追加します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
          - id: 1
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
          - id: 2
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
        # ...
      zookeeper:
        # ...
    Copy to Clipboard Toggle word wrap
  2. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>
    Copy to Clipboard Toggle word wrap
  3. 新しいトピックを作成するか、既存のパーティションを新しいディスクに再度割り当てます。

    ヒント

    Cruise Control は、パーティションを再割り当てするための効果的なツールです。ブローカー内のディスク分散を実行するには、KafkaRebalance.specrebalanceDisktrue に設定します。

8.10.7. JBOD ストレージからのボリュームの削除

この手順では、JBOD ストレージを使用するように設定されている Kafka クラスターからボリュームを削除する方法を説明します。この手順は、他のストレージタイプを使用するように設定されている Kafka クラスターには適用できません。JBOD ストレージには、常に 1 つのボリュームが含まれている必要があります。

重要

データの損失を避けるには、ボリュームを削除する前にすべてのパーティションを移動する必要があります。

前提条件

  • OpenShift クラスター
  • 稼働中の Cluster Operator
  • 複数のボリュームがある JBOD ストレージのある Kafka クラスター

手順

  1. 削除するディスクからすべてのパーティションを再度割り当てます。削除するディスクに割り当てられたままになっているパーティションのデータは削除される可能性があります。

    ヒント

    kafka-reassign-partitions.sh ツールを使用してパーティションを再割り当てできます。

  2. Kafka リソースの spec.kafka.storage.volumes プロパティーを編集します。volumes アレイから 1 つまたは複数のボリュームを削除します。たとえば、ID が 12 のボリュームを削除します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      kafka:
        # ...
        storage:
          type: jbod
          volumes:
          - id: 0
            type: persistent-claim
            size: 100Gi
            deleteClaim: false
        # ...
      zookeeper:
        # ...
    Copy to Clipboard Toggle word wrap
  3. リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat