29.3. 永続ボリュームからのクラスターの復元


Kafka クラスターは、永続ボリューム (PV) が存在していれば、そこから復元できます。

たとえば、以下の場合に行います。

  • namespace が意図せずに削除された後。
  • OpenShift クラスター全体が失われた後でも PV がインフラストラクチャーに残っている場合。

29.3.1. namespace が削除された場合の復元

永続ボリュームと namespace の関係により、namespace の削除から復元することが可能です。PersistentVolume (PV) は、namespace の外部に存在するストレージリソースです。PV は、namespace 内部に存在する PersistentVolumeClaim (PVC) を使用して Kafka Pod にマウントされます。

PV の回収 (reclaim) ポリシーは、namespace が削除されるときにクラスターに動作方法を指示します。以下に、回収 (reclaim) ポリシーの設定とその結果を示します。

  • Delete (デフォルト) に設定すると、PVC が namespace 内で削除されるときに PV が削除されます。
  • Retain に設定すると、namespace の削除時に PV は削除されません。

namespace が意図せず削除された場合に PV から復旧できるようにするには、PV 仕様で persistentVolumeReclaimPolicy プロパティーを使用してポリシーを Delete から Retain にリセットする必要があります。

apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  persistentVolumeReclaimPolicy: Retain

または、PV は、関連付けられたストレージクラスの回収 (reclaim) ポリシーを継承できます。ストレージクラスは、動的ボリュームの割り当てに使用されます。

ストレージクラスの reclaimPolicy プロパティーを設定することで、ストレージクラスを使用する PV が適切な回収 (reclaim) ポリシー で作成されます。ストレージクラスは、storageClassName プロパティーを使用して PV に対して設定されます。

apiVersion: v1
kind: StorageClass
metadata:
  name: gp2-retain
parameters:
  # ...
# ...
reclaimPolicy: Retain
apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  storageClassName: gp2-retain
注記

Retain を回収 (reclaim) ポリシーとして使用しながら、クラスター全体を削除する場合は、PV を手動で削除する必要があります。そうしないと、PV は削除されず、リソースに不要な経費がかかる原因になります。

29.3.2. OpenShift クラスター喪失からの復旧

クラスターが失われた場合、ディスク/ボリュームのデータがインフラストラクチャー内に保持されていれば、それらのデータを使用してクラスターを復旧できます。PV が復旧可能でそれらが手動で作成されていれば、復旧の手順は namespace の削除と同じです。

29.3.3. 削除したクラスターの永続ボリュームからの復元

この手順では、削除されたクラスターを永続ボリューム (PV) から復元する方法を説明します。

この状況では、Topic Operator はトピックが Kafka に存在することを認識しますが、KafkaTopic リソースは存在しません。

クラスター再作成の手順を行うには、2 つの方法があります。

  1. すべての KafkaTopic リソースを復旧できる場合は、オプション 1 を使用します。

    これにより、クラスターが起動する前に KafkaTopic リソースを復旧することで、該当するトピックが Topic Operator によって削除されないようにする必要があります。

  2. すべての KafkaTopic リソースを復旧できない場合は、オプション 2 を使用します。

    この場合、Topic Operator なしでクラスターをデプロイし、Topic Operator のトピックストアメタデータを削除してから、Topic Operator で Kafka クラスターを再デプロイすることで、該当するトピックから KafkaTopic リソースを再作成できるようにします。

注記

Topic Operator がデプロイされていない場合は、PersistentVolumeClaim (PVC) リソースのみを復旧する必要があります。

作業を開始する前に

この手順では、データの破損を防ぐために PV を正しい PVC にマウントする必要があります。volumeName が PVC に指定されており、それが PV の名前に一致する必要があります。

詳細は、永続ストレージ を参照してください。

注記

この手順には、手動での再作成が必要な KafkaUser リソースの復旧は含まれません。パスワードと証明書を保持する必要がある場合は、KafkaUser リソースの作成前にシークレットを再作成する必要があります。

手順

  1. クラスターの PV についての情報を確認します。

    oc get pv

    PV の情報がデータとともに表示されます。

    この手順で重要な列を示す出力例:

    NAME                                         RECLAIMPOLICY CLAIM
    pvc-5e9c5c7f-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-my-cluster-zookeeper-1
    pvc-5e9cc72d-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-0
    pvc-5ead43d1-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-2
    pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-0-my-cluster-kafka-0
    pvc-7e21042e-3317-11ea-9786-02deaf9aa87e ... Retain ...    myproject/data-0-my-cluster-kafka-1
    pvc-7e226978-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-0-my-cluster-kafka-2
    • NAME は各 PV の名前を示します。
    • RECLAIM POLICY は PV が 保持される ことを示します。
    • CLAIM は元の PVC へのリンクを示します。
  2. 元の namespace を再作成します。

    oc create namespace myproject
  3. 元の PVC リソース仕様を再作成し、PVC を該当する PV にリンクします。

    以下に例を示します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: data-0-my-cluster-kafka-0
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: gp2-retain
      volumeMode: Filesystem
      volumeName: pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c
  4. PV 仕様を編集して、元の PVC にバインドされた claimRef プロパティーを削除します。

    以下に例を示します。

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      annotations:
        kubernetes.io/createdby: aws-ebs-dynamic-provisioner
        pv.kubernetes.io/bound-by-controller: "yes"
        pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs
      creationTimestamp: "<date>"
      finalizers:
      - kubernetes.io/pv-protection
      labels:
        failure-domain.beta.kubernetes.io/region: eu-west-1
        failure-domain.beta.kubernetes.io/zone: eu-west-1c
      name: pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
      resourceVersion: "39431"
      selfLink: /api/v1/persistentvolumes/pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
      uid: 7efe6b0d-3317-11ea-a650-06e1eadd9a4c
    spec:
      accessModes:
      - ReadWriteOnce
      awsElasticBlockStore:
        fsType: xfs
        volumeID: aws://eu-west-1c/vol-09db3141656d1c258
      capacity:
        storage: 100Gi
      claimRef:
        apiVersion: v1
        kind: PersistentVolumeClaim
        name: data-0-my-cluster-kafka-2
        namespace: myproject
        resourceVersion: "39113"
        uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: failure-domain.beta.kubernetes.io/zone
              operator: In
              values:
              - eu-west-1c
            - key: failure-domain.beta.kubernetes.io/region
              operator: In
              values:
              - eu-west-1
      persistentVolumeReclaimPolicy: Retain
      storageClassName: gp2-retain
      volumeMode: Filesystem

    この例では、以下のプロパティーが削除されます。

    claimRef:
      apiVersion: v1
      kind: PersistentVolumeClaim
      name: data-0-my-cluster-kafka-2
      namespace: myproject
      resourceVersion: "39113"
      uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
  5. Cluster Operator をデプロイします。

    oc create -f install/cluster-operator -n my-project
  6. クラスターを再作成します。

    クラスターの再作成に必要なすべての KafkaTopic リソースがあるかどうかに応じて、以下の手順を実行します。

    オプション 1: クラスターを失う前に存在した KafkaTopic リソースが すべて ある場合 (__consumer_offsets からコミットされたオフセットなどの内部トピックを含む)。

    1. すべての KafkaTopic リソースを再作成します。

      クラスターをデプロイする前にリソースを再作成する必要があります。そうでないと、Topic Operator によってトピックが削除されます。

    2. Kafka クラスターをデプロイします。

      以下に例を示します。

      oc apply -f kafka.yaml

    オプション 2: クラスターを失う前に存在したすべての KafkaTopic リソースがない場合。

    1. オプション 1 と同様に Kafka クラスターをデプロイしますが、デプロイ前に Kafka リソースから topicOperator プロパティーを削除して、Topic Operator がない状態でデプロイします。

      デプロイメントに Topic Operator が含まれると、Topic Operator によってすべてのトピックが削除されます。

    2. Kafka クラスターから内部トピックストアのトピックを削除します。

      oc run kafka-admin -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete

      このコマンドは、Kafka クラスターへのアクセスに使用されるリスナーおよび認証のタイプに対応している必要があります。

    3. Kafka クラスターを topicOperator プロパティーで再デプロイして TopicOperator を有効にし、KafkaTopic リソースを再作成します。

      以下に例を示します。

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      metadata:
        name: my-cluster
      spec:
        #...
        entityOperator:
          topicOperator: {} 1
          #...
    1
    ここで示すデフォルト設定には、追加のプロパティーはありません。EntityTopicOperatorSpec スキーマリファレンス で説明されているプロパティーを使用して、必要な設定を指定します。
  7. KafkaTopic リソースのリストを表示して、復旧を確認します。

    oc get KafkaTopic
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.