バックアップおよび復元


OpenShift Container Platform 4.20

OpenShift Container Platform クラスターのバックアップおよび復元

概要

このドキュメントでは、クラスターのデータのバックアップと、さまざまな障害関連のシナリオでの復旧方法を説明します。

第1章 バックアップおよび復元

1.1. コントロールプレーンのバックアップおよび復元の操作

クラスター管理者は、OpenShift Container Platform クラスターを一定期間停止し、後で再起動する必要がある場合があります。クラスターを再起動する理由として、クラスターでメンテナンスを実行する必要がある、またはリソースコストを削減する必要がある、などが挙げられます。OpenShift Container Platform では、クラスターの正常なシャットダウン を実行して、後でクラスターを簡単に再起動できます。

クラスターをシャットダウンする前に etcd データをバックアップする 必要があります。etcd は OpenShift Container Platform のキーと値のストアであり、すべてのリソースオブジェクトの状態を保存します。etcd バックアップは障害復旧において重要な役割を果たします。OpenShift Container Platform では、正常でない etcd メンバーを置き換える こともできます。

クラスターを再度実行する場合は、クラスターを正常に再起動します

注記

クラスターの証明書は、インストール日から 1 年後に有効期限が切れます。証明書が有効である間は、クラスターをシャットダウンし、正常に再起動することができます。クラスターは、期限切れのコントロールプレーン証明書を自動的に取得しますが、証明書署名要求 (CSR) を承認する 必要があります。

以下のように、OpenShift Container Platform が想定どおりに機能しないさまざまな状況に直面します。

  • ノードの障害やネットワーク接続の問題などの予期しない状態により、再起動後にクラスターが機能しない。
  • 誤ってクラスターで重要なものを削除した。
  • 大多数のコントロールプレーンホストが失われたため、etcd のクォーラム (定足数) を喪失した。

保存した etcd スナップショットを使用して、クラスターを以前の状態に復元して、障害状況から常に回復できます。

1.2. アプリケーションのバックアップおよび復元の操作

クラスター管理者は、OpenShift API for Data Protection (OADP) を使用して、OpenShift Container Platform で実行しているアプリケーションをバックアップおよび復元できます。

OADP は、管理者がインストールした OADP のバージョンに適したバージョンの Velero (Velero CLI ツールのダウンロード の表を参照) を使用して、namespace の粒度で Kubernetes リソースと内部イメージをバックアップおよび復元します。OADP は、スナップショットまたは Restic を使用して、永続ボリューム (PV) をバックアップおよび復元します。詳細は、OADP の機能 を参照してください。

1.2.1. OADP 要件

OADP には以下の要件があります。

  • cluster-admin ロールを持つユーザーとしてログインする必要があります。
  • 次のストレージタイプのいずれかなど、バックアップを保存するためのオブジェクトストレージが必要です。

    • OpenShift Data Foundation
    • Amazon Web Services
    • Microsoft Azure
    • Google Cloud
    • S3 と互換性のあるオブジェクトストレージ
    • IBM Cloud® Object Storage S3
注記

OCP 4.11 以降で CSI バックアップを使用する場合は、OADP 1.1.x をインストールします。

OADP 1.0.x は、OCP 4.11 以降での CSI バックアップをサポートしていません。OADP 1.0.x には Velero 1.7.x が含まれており、OCP 4.11 以降には存在しない API グループ snapshot.storage.k8s.io/v1beta1 が必要です。

  • スナップショットを使用して PV をバックアップするには、ネイティブスナップショット API を備えているか、次のプロバイダーなどの Container Storage Interface (CSI) スナップショットをサポートするクラウドストレージが必要です。

    • Amazon Web Services
    • Microsoft Azure
    • Google Cloud
    • Ceph RBD や Ceph FS などの CSI スナップショット対応のクラウドストレージ
注記

スナップショットを使用して PV をバックアップしたくない場合は、デフォルトで OADP Operator によってインストールされる Restic を使用できます。

1.2.2. アプリケーションのバックアップおよび復元

Backup カスタムリソース (CR) を作成して、アプリケーションをバックアップします。バックアップ CR の作成 を参照してください。次のバックアップオプションを設定できます。

第2章 クラスターの正常なシャットダウン

このドキュメントでは、クラスターを正常にシャットダウンするプロセスを説明します。メンテナンスの目的で、またはリソースコストの節約のためにクラスターを一時的にシャットダウンする必要がある場合があります。

2.1. 前提条件

  • クラスターをシャットダウンする前に etcd バックアップ を作成する。

    重要

    クラスターの再起動時に問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。

    たとえば、次の条件により、再起動したクラスターが誤動作する可能性があります。

    • シャットダウン時の etcd データの破損
    • ハードウェアが原因のノード障害
    • ネットワーク接続の問題

    クラスターの回復に失敗した場合は、クラスターを以前の状態に復元 する手順を実行してください。

2.2. クラスターのシャットダウン

クラスターを正常な状態でシャットダウンし、後で再起動できるようにします。

注記

インストール日から 1 年までクラスターをシャットダウンして、正常に再起動することを期待できます。インストール日から 1 年後に、クラスター証明書が期限切れになります。ただし、クラスターの再起動時に、kubelet 証明書を回復するために保留中の証明書署名要求 (CSR) を手動で承認する必要がある場合があります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd のバックアップを取得している。
  • シングルノードの OpenShift クラスターを実行している場合は、クラスターをシャットダウンする前に、すべてのワークロード Pod をクラスターから退避させる。

手順

  1. クラスターを長期間シャットダウンする場合は、証明書の有効期限が切れる日付を確認し、次のコマンドを実行します。

    $ oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}'

    出力例

    2022-08-05T14:37:50Zuser@user:~ $ 
    1

    1
    クラスターが正常に再起動できるようにするために、指定の日付または指定の日付の前に再起動するように計画します。クラスターの再起動時に、kubelet 証明書を回復するために保留中の証明書署名要求 (CSR) を手動で承認する必要がある場合があります。
  2. クラスター内のすべてのノードをスケジュール不可としてマークします。クラウドプロバイダーの Web コンソールから、または次のループを実行することでマークできます。

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm cordon ${node} ; done

    出力例

    ci-ln-mgdnf4b-72292-n547t-master-0
    node/ci-ln-mgdnf4b-72292-n547t-master-0 cordoned
    ci-ln-mgdnf4b-72292-n547t-master-1
    node/ci-ln-mgdnf4b-72292-n547t-master-1 cordoned
    ci-ln-mgdnf4b-72292-n547t-master-2
    node/ci-ln-mgdnf4b-72292-n547t-master-2 cordoned
    ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl
    node/ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl cordoned
    ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k
    node/ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k cordoned
    ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn
    node/ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn cordoned

  3. 次の方法を使用して Pod を退避させます。

    $ for node in $(oc get nodes -l node-role.kubernetes.io/worker -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm drain ${node} --delete-emptydir-data --ignore-daemonsets=true --timeout=15s --force ; done
  4. クラスターのすべてのノードをシャットダウンします。これを実行するには、クラウドプロバイダーの Web コンソールから行うか、次のループを実行します。どちらかの方法を使用してノードをシャットダウンすると、Pod が正常に終了するため、データが破損する可能性が低くなります。

    注記

    API の仮想 IP が割り当てられたコントロールプレーンノードが、ループ内で最後に処理されるノードであることを確認してください。そうでない場合、シャットダウンコマンドが失敗します。

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done 
    1
    1
    -h 1 は、コントロールプレーンノードがシャットダウンされるまで、このプロセスを継続する時間 (分単位) を示します。10 ノード以上の大規模なクラスターでは、すべてのコンピュートノードが先にシャットダウンする時間を確保するために、-h 10 以上に設定します。

    出力例

    Starting pod/ip-10-0-130-169us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    Shutdown scheduled for Mon 2021-09-13 09:36:17 UTC, use 'shutdown -c' to cancel.
    Removing debug pod ...
    Starting pod/ip-10-0-150-116us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    Shutdown scheduled for Mon 2021-09-13 09:36:29 UTC, use 'shutdown -c' to cancel.

    注記

    シャットダウン前に OpenShift Container Platform に同梱される標準 Pod のコントロールプレーンノードをドレイン (解放) する必要はありません。クラスター管理者は、クラスターの再起動後に独自のワークロードのクリーンな再起動を実行する必要があります。カスタムワークロードが原因でシャットダウン前にコントロールプレーンノードをドレイン (解放) した場合は、再起動後にクラスターが再び機能する前にコントロールプレーンノードをスケジュール可能としてマークする必要があります。

  5. 外部ストレージや LDAP サーバーなど、不要になったクラスター依存関係をすべて停止します。この作業を行う前に、ベンダーのドキュメントを確認してください。

    重要

    クラスターをクラウドプロバイダープラットフォームにデプロイした場合は、関連するクラウドリソースをシャットダウン、一時停止、または削除しないでください。一時停止された仮想マシンのクラウドリソースを削除すると、OpenShift Container Platform が正常に復元されない場合があります。

第3章 クラスターの正常な再起動

このドキュメントでは、正常なシャットダウン後にクラスターを再起動するプロセスを説明します。

クラスターは再起動後に機能することが予想されますが、クラスターは以下の例を含む予期しない状態によって回復しない可能性があります。

  • シャットダウン時の etcd データの破損
  • ハードウェアが原因のノード障害
  • ネットワーク接続の問題

クラスターの回復に失敗した場合は、クラスターを以前の状態に復元 する手順を実行してください。

3.1. 前提条件

3.2. クラスターの再起動

クラスターの正常なシャットダウン後にクラスターを再起動できます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • この手順では、クラスターを正常にシャットダウンしていることを前提としています。

手順

  1. コントロールプレーンノードをオンにします。

    • クラスターインストール時の admin.kubeconfig を使用しており、API 仮想 IP アドレス (VIP) が稼働している場合は、次の手順を実行します。

      1. KUBECONFIG 環境変数を admin.kubeconfig パスに設定します。
      2. クラスター内の各コントロールプレーンノードに対して次のコマンドを実行します。

        $ oc adm uncordon <node>
    • admin.kubeconfig の認証情報にアクセスできない場合は、次の手順を実行します。

      1. SSH を使用してコントロールプレーンノードに接続します。
      2. localhost-recovery.kubeconfig ファイルを /root ディレクトリーにコピーします。
      3. そのファイルを使用して、クラスター内の各コントロールプレーンノードに対して次のコマンドを実行します。

        $ oc adm uncordon <node>
  2. 外部ストレージや LDAP サーバーなどのクラスターの依存関係すべてをオンにします。
  3. すべてのクラスターマシンを起動します。

    クラウドプロバイダーの Web コンソールなどでマシンを起動するには、ご使用のクラウド環境に適した方法を使用します。

    約 10 分程度待機してから、コントロールプレーンノードのステータス確認に進みます。

  4. すべてのコントロールプレーンノードが準備状態にあることを確認します。

    $ oc get nodes -l node-role.kubernetes.io/master

    以下の出力に示されているように、コントロールプレーンノードはステータスが Ready の場合、準備状態にあります。

    NAME                           STATUS   ROLES                  AGE   VERSION
    ip-10-0-168-251.ec2.internal   Ready    control-plane,master   75m   v1.33.4
    ip-10-0-170-223.ec2.internal   Ready    control-plane,master   75m   v1.33.4
    ip-10-0-211-16.ec2.internal    Ready    control-plane,master   75m   v1.33.4
  5. コントロールプレーンノードが準備状態に ない 場合、承認する必要がある保留中の証明書署名要求 (CSR) があるかどうかを確認します。

    1. 現在の CSR の一覧を取得します。

      $ oc get csr
    2. CSR の詳細をレビューし、これが有効であることを確認します。

      $ oc describe csr <csr_name> 
      1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    3. それぞれの有効な CSR を承認します。

      $ oc adm certificate approve <csr_name>
  6. コントロールプレーンノードが準備状態になった後に、すべてのワーカーノードが準備状態にあることを確認します。

    $ oc get nodes -l node-role.kubernetes.io/worker

    以下の出力に示されているように、ワーカーノードのステータスが Ready の場合、ワーカーノードは準備状態にあります。

    NAME                           STATUS   ROLES    AGE   VERSION
    ip-10-0-179-95.ec2.internal    Ready    worker   64m   v1.33.4
    ip-10-0-182-134.ec2.internal   Ready    worker   64m   v1.33.4
    ip-10-0-250-100.ec2.internal   Ready    worker   64m   v1.33.4
  7. ワーカーノードが準備状態に ない 場合、承認する必要がある保留中の証明書署名要求 (CSR) があるかどうかを確認します。

    1. 現在の CSR の一覧を取得します。

      $ oc get csr
    2. CSR の詳細をレビューし、これが有効であることを確認します。

      $ oc describe csr <csr_name> 
      1
      1
      <csr_name> は、現行の CSR のリストからの CSR の名前です。
    3. それぞれの有効な CSR を承認します。

      $ oc adm certificate approve <csr_name>
  8. コントロールプレーンとコンピュートノードの準備ができたら、次のコマンドを実行して、クラスター内のすべてのノードをスケジュール可能としてマークします。

    $ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
  9. クラスターが適切に起動していることを確認します。

    1. パフォーマンスが低下したクラスター Operator がないことを確認します。

      $ oc get clusteroperators

      DEGRADED 条件が True に設定されているクラスター Operator がないことを確認します。

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
      authentication                             4.20.0    True        False         False      59m
      cloud-credential                           4.20.0    True        False         False      85m
      cluster-autoscaler                         4.20.0    True        False         False      73m
      config-operator                            4.20.0    True        False         False      73m
      console                                    4.20.0    True        False         False      62m
      csi-snapshot-controller                    4.20.0    True        False         False      66m
      dns                                        4.20.0    True        False         False      76m
      etcd                                       4.20.0    True        False         False      76m
      ...
    2. すべてのノードが Ready 状態にあることを確認します。

      $ oc get nodes

      すべてのノードのステータスが Ready であることを確認します。

      NAME                           STATUS   ROLES                  AGE   VERSION
      ip-10-0-168-251.ec2.internal   Ready    control-plane,master   82m   v1.33.4
      ip-10-0-170-223.ec2.internal   Ready    control-plane,master   82m   v1.33.4
      ip-10-0-179-95.ec2.internal    Ready    worker                 70m   v1.33.4
      ip-10-0-182-134.ec2.internal   Ready    worker                 70m   v1.33.4
      ip-10-0-211-16.ec2.internal    Ready    control-plane,master   82m   v1.33.4
      ip-10-0-250-100.ec2.internal   Ready    worker                 69m   v1.33.4

      クラスターが適切に起動しなかった場合、etcd バックアップを使用してクラスターを復元する必要がある場合があります。詳細は、以前のクラスター状態への復元を参照してください。

第4章 OpenShift Container Platform クラスターの休止状態

OpenShift Container Platform クラスターを最大 90 日間休止状態にできます。

4.1. クラスター休止状態について

OpenShift Container Platform クラスターは、クラウドホスティングコストを節約するために休止状態にすることができます。OpenShift Container Platform クラスターを最大 90 日間休止状態にして、正常に再開できます。

最初の証明書のローテーションを可能にするために、クラスターのインストール後、クラスターを休止状態にする前に少なくとも 24 時間待つ必要があります。

重要

24 時間の証明書ローテーションの前にクラスターを休止状態にする必要がある場合は、代わりに、Enabling OpenShift 4 Clusters to Stop and Resume Cluster VMs の手順を使用します。

クラスターを休止状態にする場合、すべてのクラスターノードを休止状態にする必要があります。特定のノードのみの一時停止はサポートされていません。

再開後、クラスターの準備が整うまでに最大 45 分かかる場合があります。

4.2. 前提条件

  • クラスターを休止する前に etcd バックアップ を作成します。

    重要

    クラスターの再開時に問題が発生した場合にクラスターを復元できるように、休止する前に etcd のバックアップを作成することが重要です。

    たとえば、次の条件により、再開したクラスターが誤動作する可能性があります。

    • 休止中の etcd データの破損
    • ハードウェアが原因のノード障害
    • ネットワーク接続の問題

    クラスターの回復に失敗した場合は、クラスターを以前の状態に復元 する手順を実行してください。

4.3. クラスターの休止状態

クラスターを最大 90 日間休止状態にできます。クラスターが休止状態の間に証明書の有効期限が切れた場合でも、クラスターは回復できます。

前提条件

  • 最初の証明書のローテーションが完了するまで、クラスターは少なくとも 24 時間実行されている。

    重要

    24 時間の証明書ローテーションの前にクラスターを休止状態にする必要がある場合は、代わりに、Enabling OpenShift 4 Clusters to Stop and Resume Cluster VMs の手順を使用します。

  • etcd のバックアップを取得している。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. クラスターが少なくとも 24 時間インストールされていることを確認します。
  2. 以下のコマンドを実行して、すべてのノードが正常な状態であることを確認します。

    $ oc get nodes

    出力例

    NAME                                      STATUS  ROLES                 AGE   VERSION
    ci-ln-812tb4k-72292-8bcj7-master-0        Ready	  control-plane,master  32m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-master-1        Ready	  control-plane,master  32m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-master-2        Ready	  control-plane,master  32m   v1.33.4
    Ci-ln-812tb4k-72292-8bcj7-worker-a-zhdvk  Ready	  worker                19m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-worker-b-9hrmv  Ready	  worker                19m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2  Ready	  worker                19m   v1.33.4

    すべてのノードの STATUS 列に Ready と表示されます。

  3. 次のコマンドを実行して、すべてのクラスター Operator が良好な状態であることを確認します。

    $ oc get clusteroperators

    出力例

    NAME                      VERSION   AVAILABLE  PROGRESSING  DEGRADED  SINCE   MESSAGE
    authentication            4.20.0-0  True       False        False     51m
    baremetal                 4.20.0-0  True       False        False     72m
    cloud-controller-manager  4.20.0-0  True       False        False     75m
    cloud-credential          4.20.0-0  True       False        False     77m
    cluster-api               4.20.0-0  True       False        False     42m
    cluster-autoscaler        4.20.0-0  True       False        False     72m
    config-operator           4.20.0-0  True       False        False     72m
    console                   4.20.0-0  True       False        False     55m
    ...

    すべてのクラスター Operator には、AVAILABLE=TruePROGRESSING=False、および DEGRADED=False が表示されるはずです。

  4. 次のコマンドを実行して、すべてのマシン設定プールが良好な状態であることを確認します。

    $ oc get mcp

    出力例

    NAME    CONFIG                                            UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
    master  rendered-master-87871f187930e67233c837e1d07f49c7  True     False     False     3             3                  3                    0                     96m
    worker  rendered-worker-3c4c459dc5d90017983d7e72928b8aed  True     False     False     3             3                  3                    0                     96m

    すべてのマシン設定プールに、UPDATING=False および DEGRADED=False と表示される必要があります。

  5. クラスターの仮想マシンを停止します。

    クラスターのクラウド環境にネイティブなツールを使用して、クラスターの仮想マシンをシャットダウンします。

    重要

    bastion 仮想マシンを使用する場合は、この仮想マシンをシャットダウンしないでください。

4.4. 休止状態のクラスターの再開

休止状態のクラスターを 90 日以内に再開する場合、ノードを準備するために証明書署名要求 (CSR) を承認する必要がある場合があります。

クラスターのサイズによっては、クラスターの再開に約 45 分かかる場合があります。

前提条件

  • クラスターを休止状態にしてから 90 日未満である。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. クラスターの休止状態から 90 日以内に、クラスターの仮想マシンを再開します。

    クラスターのクラウド環境にネイティブなツールを使用して、クラスターの仮想マシンを再開します。

  2. クラスター内のノードの数に応じて、約 5 分間待機します。
  3. ノードの CSR を承認します。

    1. NotReady 状態の各ノードに CSR があることを確認します。

      $ oc get csr

      出力例

      NAME       AGE  SIGNERNAME                                   REQUESTOR                                                                  REQUESTEDDURATION  CONDITION
      csr-4dwsd  37m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2                       24h                Pending
      csr-4vrbr  49m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             24h                Pending
      csr-4wk5x  51m  kubernetes.io/kubelet-serving                system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             <none>             Pending
      csr-84vb6  51m  kubernetes.io/kube-apiserver-client-kubelet  system:serviceaccount:openshift-machine-config-operator:node-bootstrapper  <none>             Pending

    2. 次のコマンドを実行して、有効な各 CSR を承認します。

      $ oc adm certificate approve <csr_name>
    3. 次のコマンドを実行して、必要なすべての CSR が承認されたことを確認します。

      $ oc get csr

      出力例

      NAME       AGE  SIGNERNAME                                   REQUESTOR                                                                  REQUESTEDDURATION  CONDITION
      csr-4dwsd  37m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2                       24h                Approved,Issued
      csr-4vrbr  49m  kubernetes.io/kube-apiserver-client          system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             24h                Approved,Issued
      csr-4wk5x  51m  kubernetes.io/kubelet-serving                system:node:ci-ln-812tb4k-72292-8bcj7-master-1                             <none>             Approved,Issued
      csr-84vb6  51m  kubernetes.io/kube-apiserver-client-kubelet  system:serviceaccount:openshift-machine-config-operator:node-bootstrapper  <none>             Approved,Issued

      CSR の CONDITION 列には、Approved,Issued と表示される必要があります。

  4. 次のコマンドを実行して、すべてのノードが準備完了として表示されていることを確認します。

    $ oc get nodes

    出力例

    NAME                                      STATUS  ROLES                 AGE   VERSION
    ci-ln-812tb4k-72292-8bcj7-master-0        Ready	  control-plane,master  32m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-master-1        Ready	  control-plane,master  32m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-master-2        Ready	  control-plane,master  32m   v1.33.4
    Ci-ln-812tb4k-72292-8bcj7-worker-a-zhdvk  Ready	  worker                19m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-worker-b-9hrmv  Ready	  worker                19m   v1.33.4
    ci-ln-812tb4k-72292-8bcj7-worker-c-q8mw2  Ready	  worker                19m   v1.33.4

    すべてのノードの STATUS 列に Ready と表示されます。CSR を承認した後に、すべてのノードが準備完了になるまでに数分かかる場合があります。

  5. クラスター Operator が再起動し、新しい証明書を読み込むまで待機します。

    これには 5 分から 10 分かかる場合があります。

  6. 次のコマンドを実行して、すべてのクラスター Operator が正常な状態であることを確認します。

    $ oc get clusteroperators

    出力例

    NAME                      VERSION   AVAILABLE  PROGRESSING  DEGRADED  SINCE   MESSAGE
    authentication            4.20.0-0  True       False        False     51m
    baremetal                 4.20.0-0  True       False        False     72m
    cloud-controller-manager  4.20.0-0  True       False        False     75m
    cloud-credential          4.20.0-0  True       False        False     77m
    cluster-api               4.20.0-0  True       False        False     42m
    cluster-autoscaler        4.20.0-0  True       False        False     72m
    config-operator           4.20.0-0  True       False        False     72m
    console                   4.20.0-0  True       False        False     55m
    ...

    すべてのクラスター Operator には、AVAILABLE=TruePROGRESSING=False、および DEGRADED=False が表示されるはずです。

第5章 OADP アプリケーションのバックアップと復元

5.1. OpenShift API for Data Protection の概要

OpenShift API for Data Protection (OADP) 製品は、OpenShift Container Platform 上のお客様のアプリケーションを保護します。この製品は、OpenShift Container Platform のアプリケーション、アプリケーション関連のクラスターリソース、永続ボリューム、内部イメージをカバーする包括的な障害復旧保護を提供します。OADP は、コンテナー化されたアプリケーションと仮想マシン (VM) の両方をバックアップすることもできます。

ただし、OADP は etcd や OpenShift Operator の障害復旧ソリューションとしては機能しません。

重要

OADP サポートは、お客様のワークロード namespace とクラスタースコープリソースに適用されます。

クラスター全体の バックアップ復元は サポートされていません。

5.1.1. OpenShift API for Data Protection API

OADP は、バックアップをカスタマイズし、不要または不適切なリソースの組み込みを防止するための複数のアプローチを可能にする API を提供します。

OADP は次の API を提供します。

5.1.1.1. データ保護のための OpenShift API のサポート

OADP のサポートマトリックスを確認してください。

Expand
表5.1 サポートされている OADP のバージョン

バージョン

OCP のバージョン

一般公開

フルサポートの終了日

メンテナンスの終了日

延長更新サポート (EUS)

Extended Update Support 期間 2 (EUS 期間 2)

1.5

  • 4.19
  • 4.20

2025 年 6 月 17 日

1.6 のリリース

1.7 のリリース

EUS は OCP 4.20 です。

EUS Term 2 は OCP 4.20 です。

1.4

  • 4.14
  • 4.15
  • 4.16
  • 4.17
  • 4.18

2024 年 7 月 10 日

1.5 のリリース

1.6 のリリース

2026 年 6 月 27 日

EUS は OCP 4.16 です

2027 年 6 月 27 日

EUS Term 2 は OCP 4.16 です

1.3

  • 4.12
  • 4.13
  • 4.14
  • 4.15

2023 年 11 月 29 日

2024 年 7 月 10 日

1.5 のリリース

2025 年 10 月 31 日

EUS は OCP 4.14 です

2026 年 10 月 31 日

EUS Term 2 は OCP 4.14 です

5.1.1.1.1. OADP Operator のサポートされていないバージョン
Expand
表5.2 サポートされなくなった OADP Operator の以前のバージョン

バージョン

一般公開

フルサポート終了

メンテナンス終了

1.2

2023 年 6 月 14 日

2023 年 11 月 29 日

2024 年 7 月 10 日

1.1

2022 年 9 月 1 日

2023 年 6 月 14 日

2023 年 11 月 29 日

1.0

2022 年 2 月 9 日

2022 年 9 月 1 日

2023 年 6 月 14 日

EUS の詳細は、Extended Update Support を参照してください。

EUS Term 2 の詳細は、Extended Update Support Term 2 を参照してください。

5.2. OADP リリースノート

5.2.1. OADP 1.5 リリースノート

OpenShift API for Data Protection (OADP) 1.5 のリリースノートには、新機能と機能強化、非推奨となった機能、製品に関する推奨事項、既知の問題、および解決済みの問題が記載されています。

注記

OADP に関する詳細は、OpenShift API for Data Protection (OADP) FAQ を 参照してください。

5.2.1.1. OADP 1.5.5 リリースノート

OpenShift API for Data Protection (OADP) 1.5.5 のリリースノートには、解決済みの問題が記載されています。

5.2.1.1.1. 解決された問題
OADP 1.5.5 では、以下の CVE が修正されています。
シングルノードの OpenShift クラスターは、API 初期化前の CRD 同期が原因でクラッシュしなくなりました。

今回のアップデート以前は、OpenShift Container Platform のカスタムリソース定義 (CRD) が完全に初期化される前に不足していたため、イメージベースのアップグレード (IBU) 中にコントローラーがクラッシュしていました。その結果、この障害により、IBU アップグレード中の データ保護アプリケーション (DPA) のリコンシリエーションが 8 分間遅延した。今回のリリースでは、シングルノードの OpenShift 上の IBU 環境において、コントローラーが起動する前に OpenShift Container Platform の CRD がロードされるまで待機するようにすることで、この問題を解決します。また、リーダー選出も無効にします。この変更により、DPA リコンシリエーションウィンドウが短縮され、シングルノードの OpenShift クラスターの全体的なアップグレード期間が改善されます。

OADP-7508

5.2.1.2. OADP 1.5.4 リリースノート

OpenShift API for Data Protection (OADP) 1.5.4 は、コンテナーの健全性評価を更新するためにリリースされた、Container Grade Only (CGO) のリリースです。OADP 1.5.3 と比較して、製品自体のコードに変更はありません。OADP 1.5.4 では、既知の問題が導入され、いくつかの Common Vulnerabilities and Exposures (CVE) が修正されています。

5.2.1.2.1. 既知の問題
同じ NonAdminBackupStorageLocationRequest オブジェクトへの同時更新は、リソースの競合を引き起こします。

OADP セルフサービスでのバックアップ作成中に、複数のコントローラーまたはプロセスが同じ NonAdminBackupStorageLocationRequest オブジェクトを同時に更新すると、リソースの競合が発生します。その結果、リコンシリエーションの試行は オブジェクトが変更されました というエラーで失敗します。既知の回避策はありません。

OADP-6700

5.2.1.2.2. 解決された問題
OADP 1.5.4 では、以下の CVE が修正されています。
5.2.1.3. OADP 1.5.3 リリースノート

OpenShift API for Data Protection (OADP) 1.5.3 は、コンテナーのヘルスグレードを更新するためにリリースされた Container Grade Only (CGO) リリースです。OADP 1.5.2 と比較して、製品自体のコードは変更されていません。

5.2.1.4. OADP 1.5.2 リリースノート

OpenShift API for Data Protection (OADP) 1.5.2 のリリースノートには、解決済みの問題が記載されています。

5.2.1.4.1. 解決された問題
内部イメージバックアップ用の自己署名証明書が、他の BSL の動作を妨げないようにすべきである

この更新前は、OADP がすべての Backup Storage Location (BSL) の中で最初に検出されたカスタム CA 証明書のみを処理し、それをグローバルに適用していました。この動作により、それぞれ異なる CA 証明書を持つ複数の BSL が正しく動作していませんでした。さらに、システムが信頼する証明書が含まれていなかったため、標準サービスへの接続時にエラーが発生しました。

この更新により、OADP が次のように動作するように変更されました。

  • AWS BSL の一意の CA 証明書すべてを 1 つのバンドルに連結します。
  • システムが信頼する証明書を自動的に取り込みます。
  • それぞれ異なるカスタム CA 証明書を持つ複数の BSL を同時に動作させることができます。
  • イメージバックアップが有効になっている場合にのみ CA 証明書を処理します (デフォルトの動作)。

この機能拡張により、特に自己署名証明書を使用して内部イメージを AWS S3 互換ストレージにバックアップする場合に、それぞれ異なる証明書が必要な複数のストレージプロバイダーを使用する環境の互換性が向上します。

OADP-6765

5.2.1.5. OADP 1.5.1 リリースノート

OpenShift API for Data Protection (OADP) 1.5.1 のリリースノートには、新機能、解決済みの問題、既知の問題、および非推奨となった機能が記載されています。

5.2.1.5.1. 新機能
CloudStorage API は完全にサポートされています

この更新の前にテクノロジープレビューとして利用可能だった CloudStorage API 機能は、OADP 1.5.1 から完全にサポートされるようになりました。CloudStorage API は、オブジェクトストレージ用のバケットの作成を自動化します。

OADP-3307

新しい DataProtectionTest カスタムリソースが利用可能になりました

DataProtectionTest (DPT) は、OADP 設定を検証するためのフレームワークを提供するカスタムリソース (CR) です。

DPT CR は次のパラメーターの情報をチェックし、報告します。

  • オブジェクトストレージへのバックアップのアップロードパフォーマンス。
  • 永続ボリューム要求に対する Container Storage Interface (CSI) スナップショットの準備状況。
  • 暗号化やバージョン管理などのストレージバケットの設定。

DPT CR のこの情報を使用することで、データ保護環境が適切に設定され、指定された設定に従って動作していることを確認できます。

Azure 上の OADP で DPT を使用する場合は、STORAGE_ACCOUNT_ID を設定する必要があることに注意してください。

OADP-6300

新しいノードエージェントのロードアフィニティー設定が利用可能になりました
  • ノードエージェントのロードアフィニティー: DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。
  • リポジトリーメンテナンスジョブのアフィニティー設定: バックアップリポジトリーとして Kopia を使用する場合にのみ、DataProtectionApplication (DPA) カスタムリソース (CR) でリポジトリーメンテナンスジョブのアフィニティー設定を使用できます。

    すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定するか、リポジトリーごとに設定するかを選択できます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

  • Velero ロードアフィニティー: podConfig.nodeSelector オブジェクトを使用して、Velero Pod を特定のノードに割り当てることができます。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OADP-5832

ノードエージェントの同時負荷が利用可能に
この更新により、ユーザーはクラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できるようになります。また、リソース管理を改善し、バックアップと復元のワークフローを最適化することで、パフォーマンスの向上と、よりスムーズで効率的な利用体験を実現します。
5.2.1.5.2. 解決された問題
DataProtectionApplicationSpec が アノテーションの制限を超過したため、デプロイメントで設定ミスが発生する可能性があります。

この更新前は、DataProtectionApplicationSpec は非推奨の PodAnnotations を使用していたため、アノテーション制限のオーバーフローが発生していました。これにより、デプロイメントが誤まって設定される可能性がありました。このリリースでは、Operator によってデプロイされた Pod 内のアノテーション用の PodConfig が追加され、アノテーションの一貫性が確保され、エンドユーザーの管理性が向上しました。その結果、デプロイメントの信頼性が向上し、管理が容易になります。

OADP-6454

OADP コントローラーマネージャーのルートファイルシステムが読み取り専用に
この更新前は、openshift-adp-controller-manager-* Pod の manager コンテナーは、書き込み可能なルートファイルシステムで実行されるように設定されていました。その結果、コンテナーのファイルシステムを改ざんしたり、外部の実行可能ファイルを書き込んだりできてしまう可能性がありました。このリリースでは、コンテナーのセキュリティーコンテキストが更新され、ルートファイルシステムが読み取り専用に設定されるとともに、Kopia キャッシュなどの書き込みアクセスを必要とする機能が引き続き正しく動作するようになりました。その結果、コンテナーは、潜在的な脅威に対して、セキュリティーが強化されました。
複数の DPA で nonAdmin.enable: false を設定 しても、調整の問題は発生しなくなりました。

この更新前は、ユーザーが、非管理者 DataProtectionApplication (DPA) がすでに存在するクラスターに 2 つ目を作成しようとすると、新しい DPA のリコンサイルに失敗しました。このリリースでは、非管理者コントローラーのインストールがクラスターごとに 1 つに限定されていた制限が削除されました。その結果、ユーザーはエラーなしにクラスター全体に複数の非管理者コントローラーをインストールできます。

OADP-6500

OADP は自己署名証明書をサポートする

この更新前は、Minio などのストレージプロバイダーでバックアップイメージに自己署名証明書を使用すると、バックアッププロセス中に x509: certificate signed by unknown authority エラーが発生しました。このリリースでは、証明書の検証が更新され、OADP で自己署名証明書がサポートされるようになり、バックアップが確実に成功するようになりました。

OADP-641

velero description に は、defaultVolumesToFsBackup が含まれています

この更新前は、velero describe output コマンドで defaultVolumesToFsBackup フラグが省略されていました。これにより、ユーザーに対するバックアップ設定の詳細の可視性に影響が出ました。このリリースでは、velero describe 出力に defaultVolumesToFsBackup フラグ情報が含まれるようになり、バックアップ設定の可視性が向上しました。

OADP-5762

s3Url が保護されている場合、DPT CR は失敗しなくなりました。

この更新前は、DPT CR に仕様フィールドで caCert をスキップまたは追加する機能がなかったため、証明書が検証されていないことが原因で s3Url が保護されているときに DataProtectionTest (DPT) の実行に失敗しました。その結果、証明書が検証されていないことが原因でデータのアップロードに失敗しました。このリリースでは、DPT CR が更新され、仕様フィールドで CA 証明書を受け入れてスキップするようになり、SSL 検証エラーが解決されました。その結果、セキュリティー保護された s3Url を使用するときに DPT が失敗しなくなりました。

OADP-6235

既存の backupLocation 名を使用した DPA への backupLocation の追加が拒否されない

この更新前は、DataProtectionApplication (DPA) に同じ名前の 2 番目の backupLocation を追加すると、OADP が無効な状態になり、Velero が Secret 認証情報を読み取ることができないためにバックアップと復元が失敗していました。その結果、バックアップと復元の操作は失敗しました。このリリースでは、DPA での重複した backupLocation 名が許可されなくなり、バックアップと復元の失敗を防ぐことができます。その結果、重複する backupLocation 名は拒否され、データをシームレスに保護できるようになります。

OADP-6459

5.2.1.5.3. 既知の問題
Cinder CSI ドライバーを使用して OpenStack 上で作成されたバックアップの復元が失敗する

Cinder Container Storage Interface (CSI) ドライバーを使用して OpenStack プラットフォーム上で作成されたバックアップの復元操作を開始すると、ソースアプリケーションを手動でスケールダウンしてからでないと、初期バックアップに成功しません。復元ジョブが失敗し、バックアップからアプリケーションのデータと状態を正常に復元できなくなります。既知の回避策はありません。

OADP-5552

nodeAgent.loadAffinity パラメーターに多くの要素が含まれている場合、バックアップ中に Datamover Pod が予期しないノードにスケジュールされる。

Velero 1.14 以降の問題が原因で、OADP ノードエージェントは loadAffinity 配列にある最初の nodeSelector 要素しか処理しません。結果として、複数の nodeSelector オブジェクトを定義すると、最初のオブジェクト以外のすべてのオブジェクトが無視され、バックアップ中に予期しないノードで datamover Pod がスケジュールされる可能性があります。

この問題を回避するには、複数の nodeSelector オブジェクトから必要な matchExpressions をすべて最初の nodeSelector オブジェクトに統合します。その結果、すべてのノードアフィニティールールが正しく適用され、datamover Pod が適切なノードにスケジュールされるようになります。

OADP-6469

エイリアスコマンドで CA 証明書を使用すると OADP バックアップが失敗する

CA 証明書は、実行中の Velero コンテナーにファイルとして保存されません。その結果、Velero コンテナーに caCert がないため、手動でのセットアップとダウンロードが必要となり、ユーザーエクスペリエンスが低下しました。この問題を回避するには、Velero デプロイメントに証明書を手動で追加します。手順は、velero デプロイメント経由でエイリアスされた velero コマンドで cacert を使用する を参照してください。

OADP-4668

nodeSelector 仕様は、データムーバーの復元アクションではサポートされていません。

nodeAgent パラメーターに nodeSelector フィールドを設定して Data Protection Application (DPA) を作成すると、復元操作が完了する代わりに、Data Mover の復元が部分的に失敗します。既知の回避策はありません。

OADP-4743

DPA が caCert で設定されている場合に、イメージストリームのバックアップが部分的に失敗する。

DataProtectionApplication (DPA) の caCert を使用してバックアップ中に S3 接続で検証されていない証明書があると、ocp-django アプリケーションのバックアップが部分的に失敗し、データが失われます。既知の回避策はありません。

OADP-4817

Kopia はワーカーノード上のキャッシュを削除しない

ephemeral-storage パラメーターが設定され、ファイルシステムの復元が実行されている場合、キャッシュはワーカーノードから自動的に削除されません。その結果、バックアップの復元中に /var パーティションがオーバーフローし、ストレージ使用量が増加し、リソースが枯渇する可能性があります。この問題を回避するには、ノードエージェント Pod を再起動してキャッシュをクリアします。その結果、キャッシュが削除されます。

OADP-4855

無効なプロジェクト設定のため、Workload Identity で Google Cloud VSL バックアップが失敗する

Google Cloud Workload Identity で volumeSnapshotLocation (VSL) バックアップを実行するときに、DataProtectionApplication (DPA) の snapshotLocations 設定でも Google Cloud プロジェクトが指定されていると、Velero Google Cloud プラグインによって無効な API リクエストが作成されます。その結果、Google Cloud API が RESOURCE_PROJECT_INVALID エラーを返し、バックアップジョブが PartiallyFailed ステータスで終了します。既知の回避策はありません。

OADP-6697

STS を使用した AWS 上の CloudStorage API の VSL バックアップが失敗する

AZURE_RESOURCE_GROUP が VSL の DataProtectionApplication (DPA) 設定にすでに記載されていても、認証情報ファイルに AZURE_RESOURCE_GROUP パラメーターがないため、volumeSnapshotLocation (VSL) バックアップは失敗します。既知の回避策はありません。

OADP-6676

ImageStreams を使用したアプリケーションのバックアップが Azure の STS で失敗する

STS を使用して Azure クラスター上のイメージストリームリソースを含むアプリケーションをバックアップする場合、OADP プラグインはコンテナーレジストリーのシークレットベースの認証情報を誤って検索しようとします。その結果、必要なシークレットが STS 環境で見つからず、ImageStream カスタムバックアップアクションが失敗します。この結果、全体的なバックアップステータスが PartiallyFailed としてマークされます。既知の回避策はありません。

OADP-6675

CloudStorageRef 設定の DPA リコンシリエーションが失敗しました

ユーザーがバケットを作成し、backupLocations.bucket.cloudStorageRef 設定を使用する場合、バケットの認証情報は DataProtectionApplication (DPA) カスタムリソース (CR) に存在しません。その結果、バケット認証情報が CloudStorage CR に存在していても、DPA リコンシリエーションは失敗します。この問題を回避するには、DPA CR の backupLocations セクションに同じ認証情報を追加します。

OADP-6669

5.2.1.5.4. 非推奨の機能
configuration.restic 仕様フィールドが非推奨になる

OADP 1.5.0 では、configuration.restic 仕様フィールドは非推奨になりました。kopia または resticuploaderType として選択するには、uploaderType フィールドとともに nodeAgent セクションを使用します。Restic は OADP 1.5.0 では非推奨になっていることに注意してください。

OADP-5158

5.2.1.6. OADP 1.5.0 リリースノート

OpenShift API for Data Protection (OADP) 1.5.0 のリリースノートには、新機能、解決済みの問題、既知の問題、非推奨となった機能、およびテクノロジープレビュー機能が記載されています。

5.2.1.6.1. 新機能
OADP 1.5.0 には、新しい Self-Service 機能が導入されました。

OADP 1.5.0 では OADP Self-Service という名前の新しい機能が導入され、OpenShift Container Platform 上で namespace admin ユーザーがアプリケーションのバックアップおよび復元を実行できるようになりました。OADP の以前のバージョンでは、アプリケーションのバックアップと復元、Backup Storage Location の作成などの OADP 操作を実行するための cluster-admin ロールが必要でした。

OADP 1.5.0 以降では、バックアップおよび復元操作を実行するために cluster-admin ロールは必要ありません。namespace admin ロールで OADP を使用できます。namespace admin ロールには、ユーザーが割り当てられている namespace への管理者アクセスのみがあります。Self-Service 機能は、クラスター管理者が OADP Operator をインストールし、必要なパーミッションを付与した後にのみ使用できます。

OADP-4001

must-gather ツールを使用したログの収集が Markdown 概要で改善されました。

must-gather ツールを使用して、ログ、および OpenShift API for Data Protection (OADP) カスタムリソースに関する情報を収集できます。must-gather データはすべてのカスタマーケースに添付する必要があります。このツールは、must-gather ログクラスターディレクトリーにある収集された情報を含む Markdown 出力ファイルを生成します。

OADP-5384

dataMoverPrepareTimeout および resourceTimeout パラメーターが DPA 内の nodeAgent に追加される

Data Protection Application (DPA) の nodeAgent フィールドに、以下のパラメーターが含まれるようになりました。

  • dataMoverPrepareTimeout: DataUpload または DataDownload プロセスが待機する期間を定義します。デフォルト値は 30 分です。
  • resourceTimeout: 他の特定のタイムアウトパラメーターで処理されないリソースプロセスのタイムアウトを設定します。デフォルト値は 10 分です。

OADP-3736

nodeAgent デーモンセットを設定するために DPA の spec.configuration.nodeAgent パラメーターを使用する

Velero は、nodeAgent デーモンセットの設定に node-agent-config config map を使用しなくなりました。この更新により、nodeAgent デーモンセットを設定するには、Data Protection Application (DPA) で新しい spec.configuration.nodeAgent パラメーターを使用する必要があります。

OADP-5042

バックアップリポジトリーの設定 config map を使用して DPA を設定できるようになる

Velero 1.15 以降では、リポジトリーごとのキャッシュの合計サイズを設定できるようになりました。これにより、一時ストレージ不足による Pod の削除が阻止されます。DPA の NodeAgentConfig フィールドに追加された次の新しいパラメーターを参照してください。

  • cacheLimitMB: ローカルデータキャッシュサイズの制限をメガバイトで設定します。
  • fullMaintenanceInterval: デフォルト値は 24 時間です。次のオーバーライドオプションを使用して、Kopia リポジトリーから削除された Velero バックアップの削除レートを制御します。

    • normalGC: 24 hours
    • fastGC: 12 hours
    • eagerGC: 6 hours

OADP-5900

node-agent セキュリティーの強化

この更新により、以下の変更が追加されました。

  • DPA の velero フィールドに新しい configuration オプションが追加されました。
  • disableFsBackup パラメーターのデフォルト値は false または non-existing です。この更新により、SecurityContext フィールドに以下のオプションが追加されました。

    • Privileged: true
    • AllowPrivilegeEscalation: true
  • disableFsBackup パラメーターを true に設定すると、node-agent から次のマウントが削除されます。

    • host-pods
    • host-plugins
  • node-agent が常に root 以外のユーザーとして実行されるように変更します。
  • root ファイルシステムを読み取り専用に変更します。
  • 以下のマウントポイントを書き込みアクセスで更新します。

    • /home/velero
    • tmp/credentials
  • SeccompProfile パラメーターに SeccompProfileTypeRuntimeDefault オプションを使用します。

OADP-5031

並列アイテムバックアップの DPA サポートを追加

デフォルトでは、1 つのスレッドのみがアイテムブロックを処理します。Velero 1.16 は並列アイテムのバックアップをサポートしており、バックアップ内の複数のアイテムを並行して処理できます。

オプションの Velero サーバーパラメーター --item-block-worker-count を使用して、追加のワーカースレッドを実行し、アイテムを並行して処理できます。OADP でこれを有効にするには、dpa.Spec.Configuration.Velero.ItemBlockWorkerCount パラメーターをゼロより大きい整数値に設定します。

注記

複数のフルバックアップを並行して実行することは、まだサポートされていません。

OADP-5635

OADP ログが JSON 形式で利用できるようになる

OADP 1.5.0 のリリースにより、ログを JSON 形式で利用できるようになりました。Elastic ログ管理システムに事前に解析されたデータがあると便利です。

OADP-3391

oc get dpa コマンドが RECONCILED ステータスを表示するようになる

このリリースにより、ユーザーエクスペリエンスを向上させるために、oc get dpa コマンドが、NAME および AGE のみを表示する代わりに、RECONCILED ステータスを表示するようになりました。以下に例を示します。

$ oc get dpa -n openshift-adp
NAME            RECONCILED   AGE
velero-sample   True         2m51s

OADP-1338

5.2.1.6.2. 解決された問題
コンテナーが terminationMessagePolicyFallbackToLogsOnError を使用するようになる

このリリースにより、terminationMessagePolicy フィールドは、operator-managerveleronode-agentnon-admin-controller などの OpenShift API for Data Protection (OADP) Operator コンテナーの FallbackToLogsOnError 値を設定できるようになりました。

この変更により、コンテナーがエラーで終了し、終了メッセージファイルが空の場合、OpenShift はコンテナーログの最後の部分を終了メッセージとして使用します。

OADP-5183

namespace admin が復元後にアプリケーションにアクセスできるようになる

以前は、名前空間管理者は復元操作後にアプリケーションを実行できませんでした。

実行は以下のエラーで失敗しました。

  • exec operation is not allowed because the pod’s security context exceeds your permissions
  • unable to validate against any security context constraint
  • not usable by user or serviceaccount, provider restricted-v2

この更新により、この問題は解決され、namespace admin は復元後にアプリケーションに正常にアクセスできるようになりました。

OADP-5611

アノテーションを使用して、個々のリソースインスタンスレベルでのステータス復元を指定できるようになりました

以前は、ステータスの復元は、Restore カスタムリソース (CR) の restoreStatus フィールドを使用してリソースタイプでのみ設定されていました。

このリリースにより、次のアノテーションを使用して、個々のリソースインスタンスレベルでステータスの復元を指定できるようになりました。

metadata:
  annotations:
    velero.io/restore-status: "true"

OADP-5968

excludedClusterScopedResources で復元が成功するようになる

以前は、excludedClusterScopedResources フィールドが storageclassesNamespace パラメーターに設定されたアプリケーションのバックアップを実行すると、バックアップは成功していましたが、復元は部分的に失敗していました。この更新により、復元も成功するようになりました。

OADP-5239

waitingForPluginOperations フェーズ中に再起動された場合でもバックアップが完了する

以前は、以下のエラーメッセージが表示され、バックアップは failed とマークされていました。

failureReason: found a backup with status "InProgress" during the server starting,
mark it as "Failed"

この更新により、waitingForPluginOperations フェーズ中に再起動された場合、バックアップは完了します。

OADP-2941

DPA で` disableFsbackup` パラメーターが true に設定されている場合のエラーメッセージが、以前よりわかりやすくなる

以前は、Data Protection Application (DPA) の spec.configuration.velero.disableFsBackup フィールドが true に設定されている場合、バックアップが部分的に失敗し、エラーメッセージもわかりにくいものでした。

この更新により、エラーメッセージがトラブルシューティングに役立つ内容になります。たとえば、disableFsBackup: true が DPA における問題であることを示すエラーメッセージや、非管理者ユーザーが DPA にアクセスできないことを示すエラーメッセージなどが表示されるようになります。

OADP-5952

parseAWSSecret で AWS STS 認証情報を処理する

以前は、STS 認証を使用する AWS 認証情報が適切に検証されませんでした。

この更新により、parseAWSSecret 関数は STS 固有のフィールドを検出し、STS プロファイルを正しく処理できるように ensureSecretDataExists 関数を更新します。

OADP-6105

repositoryMaintenance ジョブアフィニティー設定が可能となる

以前は、リポジトリーメンテナンスジョブ Pod アフィニティーの新しい設定が DPA 仕様にはありませんでした。

この更新により、BackupRepository 識別子を設定にマッピングするための repositoryMaintenance ジョブアフィニティー設定を使用できるようになりました。

OADP-6134

CR 仕様が正しくなると、ValidationErrors フィールドが消える

以前は、スケジュール CR が間違った spec.schedule 値で作成され、後で正しい値でパッチが適用された場合、ValidationErrors フィールドが引き続き存在していました。その結果、仕様が正しい場合でも、ValidationErrors フィールドに誤った情報が表示されました。

この更新により、CR 仕様が正しくなると、ValidationErrors フィールドは自動的に消えるようになります。

OADP-5419

volumeSnapshotContents カスタムリソースは、restoreSpecincludedNamesapces フィールドが使用されると復元されます

以前は、復元仕様の includedNamespace フィールドで復元操作がトリガーされると、復元操作が正常に完了しましたが、volumeSnapshotContents カスタムリソース (CR) が作成されず、PVC は Pending ステータスになっていました。

この更新により、restoreSpecincludedNamesapces フィールドが使用されている場合でも、volumeSnapshotContents CR が復元されるようになりました。その結果、復元後、アプリケーション Pod は Running 状態になります。

OADP-5939

OADPOperator が AWS 上にバケットを正常に作成しました

以前は、コンテナーはセキュリティー目的で readOnlyRootFilesystem: true 設定で設定されていましたが、コードは os.CreateTemp() 関数を使用して /tmp ディレクトリーに一時ファイルを作成しようとしていました。そのため、Cloud Credential Operator (CCO) フローで AWS STS 認証を使用すると、OADP は次のエラーを表示し、AWS 認証情報の処理に必要な一時ファイルを作成できませんでした。

ERROR unable to determine if bucket exists. {"error": "open /tmp/aws-shared-credentials1211864681: read-only file system"}

この更新により、この問題に対応するために、以下の変更が追加されました。

  • tmp-dir という名前の新しい emptyDir ボリュームがコントローラー Pod の仕様に追加されました。
  • このボリュームを /tmp ディレクトリーにマウントするためのボリュームマウントがコンテナーに追加されました。
  • セキュリティーのベストプラクティスには、readOnlyRootFilesystem: true が維持されます。
  • 非推奨の ioutil.TempFile() 関数を推奨される os.CreateTemp() 関数に置き換えました。
  • 不要な io/ioutil インポートを削除しました。

OADP-6019

このリリースで解決されたすべての問題のリストは、Jira の OADP 1.5.0 の解決済みの問題 を参照してください。

5.2.1.6.3. 既知の問題
バックアップの有効期限が切れた後、Kopia がすべてのアーティファクトを削除しない

バックアップを削除した後でも、バックアップの有効期限が切れると、Kopia は S3 ロケーションの ${bucket_name}/kopia/$openshift-adp からボリュームアーティファクトを削除しません。期限切れおよび削除されたデータファイルに関する情報は、メタデータ内に残ります。

OpenShift API for Data Protection (OADP) が正常に機能するように、データは削除されず、/kopia/ ディレクトリーにあります。以下に例を示します。

  • kopia.repository: 暗号化、バージョン、その他の詳細などのメインリポジトリー形式の情報。
  • kopia.blobcfg: データ Blob の命名方法の設定。
  • kopia.maintenance: メンテナンスの所有者、スケジュール、最後に正常に実行されたビルドを追跡します。
  • log: ログ Blob

OADP-5131

このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.5.0 の既知の問題 のリストを参照してください。

5.2.1.6.4. 非推奨の機能
configuration.restic 仕様フィールドが非推奨になる

OpenShift API for Data Protection (OADP) 1.5.0 では、configuration.restic 仕様フィールドは非推奨になりました。kopia または resticuploaderType として選択するには、uploaderType フィールドとともに nodeAgent セクションを使用します。OpenShift API for Data Protection (OADP) 1.5.0 では、Restic は非推奨となっていることに注意してください。

OADP-5158

5.2.1.6.5. テクノロジープレビュー機能
HyperShift がホストする OpenShift クラスターのサポートがテクノロジープレビューとして利用可能に

OADP は、テクノロジープレビューとして、HyperShift がホストする OpenShift クラスター内でのアプリケーションの移行をサポートおよび容易化できます。これにより、ホステッドクラスターのアプリケーションのシームレスなバックアップおよび復元操作が実現します。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

OADP-3930

5.2.2. OADP 1.4 から 1.5 へのアップグレード

既存の OADP 1.4 インストールを OADP 1.5 にアップグレードする方法を学びましょう。

注記

必ず次のマイナーバージョンにアップグレードしてください。バージョンはスキップしないでください。新しいバージョンに更新するには、一度に 1 つのチャネルのみアップグレードします。たとえば、OADP 1.1 から 1.3 にアップグレードするには、最初に 1.2 にアップグレードし、次に 1.3 にアップグレードします。

5.2.2.1. OADP 1.4 から 1.5 への変更

Velero サーバーが、バージョン 1.14 から 1.16 に更新されました。

これにより、以下の変更が発生します。

バージョンサポートの変更
OpenShift API for Data Protection は、合理化されたバージョンサポートポリシーを実装します。Red Hat は、1 つの OpenShift バージョンで 1 つの OpenShift API for Data Protection (OADP) バージョンのみをサポートし、安定性と保守性を確保します。OADP 1.5.0 は、OpenShift 4.19 バージョンでのみサポートされます。
OADP Self-Service

OADP 1.5.0 では OADP Self-Service という名前の新しい機能が導入され、OpenShift Container Platform 上で namespace admin ユーザーがアプリケーションのバックアップおよび復元を実行できるようになりました。OADP の以前のバージョンでは、アプリケーションのバックアップと復元、Backup Storage Location の作成などの OADP 操作を実行するための cluster-admin ロールが必要でした。

OADP 1.5.0 以降では、バックアップおよび復元操作を実行するために cluster-admin ロールは必要ありません。namespace admin ロールで OADP を使用できます。namespace admin ロールには、ユーザーが割り当てられている namespace への管理者アクセスのみがあります。Self-Service 機能は、クラスター管理者が OADP Operator をインストールし、必要なパーミッションを付与した後にのみ使用できます。

backupPVC および restorePVC 設定

backupPVC リソースは、データ移動型のバックアップ操作中にデータへアクセスするための中間永続ボリューム要求 (PVC) です。DataProtectionApplication (DPA) カスタムリソースの nodeAgent.backupPVC セクションを使用して、readonly バックアップ PVC を作成します。

restorePVC リソースは、Data Mover の復元操作中にデータの書き込みに使用される中間 PVC です。

ignoreDelayBinding フィールドを使用して、DPA で restorePVC を設定できます。

5.2.2.2. DPA 設定をバックアップする

現在の DataProtectionApplication (DPA) 設定をバックアップする必要があります。

手順

  • 次のコマンドを実行して、現在の DPA 設定を保存します。

    コマンドの例

    $ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup

5.2.2.3. OADP Operator をアップグレードする

次の手順を使用して、OpenShift API for Data Protection (OADP) Operator をアップグレードできます。

注記

OADP 1.5.0 は OpenShift 4.18 クラスターにインストールしないでください。

前提条件

  • 最新の OADP 1.4.6 がインストールされている。
  • データのバックアップを作成している。

手順

  1. OpenShift 4.18 を OpenShift 4.19 にアップグレードします。

    注記

    OpenShift API for Data Protection (OADP) 1.4 は OpenShift 4.19 ではサポートされていません。

  2. OADP Operator のサブスクリプションチャネルを stable-1.4 から stable に変更します。
  3. Operator とコンテナーが更新され、再起動するまで待ちます。
5.2.2.4. DPA を OADP 1.5.0 の新しいバージョンに変換する

OpenShift API for Data Protection (OADP) 1.4 は OpenShift 4.19 ではサポートされていません。新しい spec.configuration.nodeAgent フィールドとそのサブフィールドを使用して、Data Protection Application (DPA) を新しい OADP 1.5 バージョンに変換できます。

手順

  1. nodeAgent デーモンセットを設定するには、DPA の spec.configuration.nodeAgent パラメーターを使用します。以下の例を参照してください。

    DataProtectionApplication の設定例

    ...
     spec:
       configuration:
         nodeAgent:
           enable: true
           uploaderType: kopia
    ...

  2. node-agent-config という名前の ConfigMap リソースを使用して nodeAgent デーモンセットを設定するには、以下の設定例を参照してください。

    config map の例

    ...
     spec:
       configuration:
         nodeAgent:
           backupPVC:
             ...
           loadConcurrency:
             ...
           podResources:
             ...
           restorePVC:
            ...
    ...

5.2.2.5. アップグレードの検証

次の手順を使用して、OpenShift API for Data Protection (OADP) のアップグレードを確認できます。

手順

  1. DataProtectionApplication (DPA) が正常に調整されたことを確認します。

    $ oc get dpa dpa-sample -n openshift-adp

    出力例

    NAME            RECONCILED   AGE
    dpa-sample      True         2m51s

    注記

    RECONCILED 列は True である必要があります。

  2. 次のコマンドを実行して、OADP リソースを表示して、インストールが完了したことを確認します。

    $ oc get all -n openshift-adp

    出力例

    NAME                                                    READY   STATUS    RESTARTS   AGE
    pod/node-agent-9pjz9                                    1/1     Running   0          3d17h
    pod/node-agent-fmn84                                    1/1     Running   0          3d17h
    pod/node-agent-xw2dg                                    1/1     Running   0          3d17h
    pod/openshift-adp-controller-manager-76b8bc8d7b-kgkcw   1/1     Running   0          3d17h
    pod/velero-64475b8c5b-nh2qc                             1/1     Running   0          3d17h
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/openshift-adp-controller-manager-metrics-service   ClusterIP   172.30.194.192   <none>        8443/TCP   3d17h
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.190.174   <none>        8085/TCP   3d17h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent   3         3         3       3            3           <none>          3d17h
    
    NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/openshift-adp-controller-manager   1/1     1            1           3d17h
    deployment.apps/velero                             1/1     1            1           3d17h
    
    NAME                                                          DESIRED   CURRENT   READY   AGE
    replicaset.apps/openshift-adp-controller-manager-76b8bc8d7b   1         1         1       3d17h
    replicaset.apps/openshift-adp-controller-manager-85fff975b8   0         0         0       3d17h
    replicaset.apps/velero-64475b8c5b                             1         1         1       3d17h
    replicaset.apps/velero-8b5bc54fd                              0         0         0       3d17h
    replicaset.apps/velero-f5c9ffb66                              0         0         0       3d17h

    注記

    node-agent Pod は、DataProtectionApplication (DPA) で restic または kopia を使用しているときにのみ作成されます。OADP 1.4.0 および OADP 1.3.0 バージョンでは、node-agent Pod は restic とラベル付けされています。

  3. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    出力例

    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true

5.3. OADP パフォーマンス

5.4. OADP の機能とプラグイン

OpenShift Container Platform のリソースをバックアップおよび復元するために、Velero をクラウドプロバイダーと統合する OpenShift API for Data Protection (OADP) の機能とデフォルトプラグインを確認してください。これは、バックアップおよび復元環境に適したプラグインと機能を選択するのに役立ちます。

5.4.1. OADP の機能

OpenShift Container Platform 上のアプリケーションを保護するために、OpenShift API for Data Protection (OADP) のバックアップ、復元、およびスケジューリング機能を確認してください。これは、データ保護ストラテジーにおいて利用可能な機能を理解するのに役立ちます。

バックアップ

OADP を使用して OpenShift Platform 上のすべてのアプリケーションをバックアップしたり、タイプ、namespace、またはラベルでリソースをフィルターしたりできます。

OADP は、Kubernetes オブジェクトと内部イメージをアーカイブファイルとしてオブジェクトストレージに保存することにより、それらをバックアップします。OADP は、ネイティブクラウドスナップショット API または Container Storage Interface (CSI) を使用してスナップショットを作成することにより、永続ボリューム (PV) をバックアップします。スナップショットをサポートしないクラウドプロバイダーの場合、OADP は Restic を使用してリソースと PV データをバックアップします。

注記

バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。

復元

バックアップからリソースと PV を復元できます。バックアップ内のすべてのオブジェクトを復元することも、オブジェクトを namespace、PV、またはラベルでフィルタリングすることもできます。

注記

バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。

スケジュール
指定した間隔でバックアップをスケジュールできます。
フック
フックを使用して、Pod 上のコンテナーでコマンドを実行できます。たとえば、fsfreeze を使用してファイルシステムをフリーズできます。バックアップまたは復元の前または後に実行するようにフックを設定できます。復元フックは、init コンテナーまたはアプリケーションコンテナーで実行できます。

5.4.2. OADP プラグイン

OpenShift API for Data Protection (OADP) が提供する、ストレージプロバイダーと連携してバックアップおよびスナップショット操作をサポートするデフォルトの Velero プラグインを確認してください。これにより、クラウド環境に適したプラグインを選択して設定することができます。

OADP は、OpenShift Container Platform リソースバックアップ、OpenShift Virtualization リソースバックアップ、および Container Storage Interface (CSI) スナップショット用のプラグインも提供します。

Expand
表5.3 OADP プラグイン
OADP プラグイン機能ストレージの場所

aws

Kubernetes オブジェクトをバックアップし、復元します。

AWS S3

スナップショットを使用してボリュームをバックアップおよび復元します。

AWS EBS

azure

Kubernetes オブジェクトをバックアップし、復元します。

Microsoft Azure Blob ストレージ

スナップショットを使用してボリュームをバックアップおよび復元します。

Microsoft Azure マネージドディスク

gcp

Kubernetes オブジェクトをバックアップし、復元します。

Google Cloud Storage

スナップショットを使用してボリュームをバックアップおよび復元します。

Google Compute Engine ディスク

openshift

OpenShift Container Platform リソースをバックアップおよび復元します。[1]

オブジェクトストア

kubevirt

OpenShift Virtualization リソースをバックアップおよび復元します。[2]

オブジェクトストア

csi

CSI スナップショットを使用して、ボリュームをバックアップおよび復元します。[3]

CSI スナップショットをサポートするクラウドストレージ

hypershift

HyperShift ホステッドクラスターリソースをバックアップおよび復元します。[4]

オブジェクトストア

  1. 必須。
  2. 仮想マシンディスクは CSI スナップショットまたは Restic でバックアップされます。
  3. csi プラグインは、Kubernetes CSI スナップショット API を使用します。

    • OADP 1.1 以降は snapshot.storage.k8s.io/v1 を使用します。
    • OADP 1.0 は snapshot.storage.k8s.io/v1beta1 を使用します。
  4. クラスターが HyperShift ホステッドクラスターでない場合は、DataProtectionApplication カスタムリソースに hypershift プラグインを追加しないでください。

5.4.3. OADP Velero プラグインについて

OADP デプロイメント時に、デフォルトのクラウドプロバイダープラグインを設定する方法、またはカスタムプラグインをインストールして、特定のストレージソリューションに接続する方法を確認してください。これにより、複数の環境にわたるリソースのバックアップと復元を正常に行うことができます。

5.4.3.1. デフォルトの Velero クラウドプロバイダープラグイン

デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルを設定するときに、次のデフォルトの Velero クラウドプロバイダープラグインのいずれかをインストールできます。

  • aws (Amazon Web Services)
  • gcp (Google Cloud)
  • azure (Microsoft Azure)
  • openshift (OpenShift Velero プラグイン)
  • csi (Container Storage Interface)
  • kubevirt (KubeVirt)

デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルで目的のデフォルトプラグインを指定します。

次の .yaml ファイルは、openshiftawsazure、および gcp プラグインをインストールします。

 apiVersion: oadp.openshift.io/v1alpha1
 kind: DataProtectionApplication
 metadata:
   name: dpa-sample
 spec:
   configuration:
     velero:
       defaultPlugins:
       - openshift
       - aws
       - azure
       - gcp
5.4.3.2. カスタム Velero プラグイン

デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルを設定するときに、プラグインの imagename を指定することにより、カスタム Velero プラグインをインストールできます。

デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルで目的のカスタムプラグインを指定します。

次の .yaml ファイルは、デフォルトの openshiftazure、および gcp プラグインと、イメージ quay.io/example-repo/custom-velero-plugin を持つ custom-plugin-example という名前のカスタムプラグインをインストールします。

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
 name: dpa-sample
spec:
 configuration:
   velero:
     defaultPlugins:
     - openshift
     - azure
     - gcp
     customPlugins:
     - name: custom-plugin-example
       image: quay.io/example-repo/custom-velero-plugin

5.4.4. OADP でサポートされるアーキテクチャー

OpenShift API for Data Protection (OADP) でサポートされているアーキテクチャーを確認してください。これは、クラスターインフラストラクチャーとの互換性を確認するのに役立ちます。

  • AMD64
  • ARM64
  • PPC64le
  • s390x
注記

OADP 1.2.0 以降のバージョンは、ARM64 アーキテクチャーをサポートします。

5.4.5. IBM Power および IBM Z の OADP サポート

IBM Power®および IBM Z®における OpenShift API for Data Protection (OADP) のサポート状況と、テスト済みのバックアップ場所を確認してください。これにより、IBM Power® または IBM Z® 環境との互換性およびサポートされている設定を確認できます。

  • OADP 1.3.6 は、IBM Power® と IBM Z® の両方の OpenShift Container Platform 4.12、4.13、4.14、4.15 に対して正常にテストされました。以下のセクションでは、これらのシステムのバックアップ場所に関して、OADP 1.3.6 のテストおよびサポート情報を示します。
  • OADP 1.4.6 は、IBM Power® と IBM Z® の両方の OpenShift Container Platform 4.14、4.15、4.16、4.17 に対して正常にテストされました。以下のセクションでは、これらのシステムのバックアップ場所に関して、OADP 1.4.6 のテストおよびサポート情報を示します。
  • OADP 1.5.5 は、IBM Power®および IBM Z®の両方において、OpenShift Container Platform 4.19 に対して正常にテストされました。以下のセクションでは、OADP 1.5.5 におけるこれらのシステムのバックアップ場所に関するテストおよびサポート情報を提供します。
5.4.5.1. IBM Power を使用したターゲットバックアップロケーションの OADP サポート

さまざまな OpenShift Container Platform バージョンおよび S3 互換のバックアップ場所を使用して IBM Power® 上で OADP を実行するための、テスト済みでサポートされている設定を確認してください。これにより、バックアップを設定する前に、IBM Power®環境がサポートされていることを確認できます。

  • OpenShift Container Platform 4.12、4.13、4.14、4.15、および OADP 1.3.6 で実行されている IBM Power® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが使用されましたが、Red Hat は、AWS 以外のすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.13、4.14、4.15、および OADP 1.3.6 を使用した IBM Power® の実行をサポートしています。
  • OpenShift Container Platform 4.14、4.15、4.16、4.17、および OADP 1.4.6 で実行されている IBM Power® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが使用されましたが、Red Hat は、AWS 以外のすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.14、4.15、4.16、4.17、および OADP 1.4.6 を使用した IBM Power® の実行をサポートしています。
  • OpenShift Container Platform 4.19 および OADP 1.5.5 を搭載した IBM Power®が、AWS S3 バックアップ先ターゲットに対して正常に動作することがテストされました。今回のテストでは AWS S3 をターゲットとしていましたが、Red Hat は、AWS 以外のすべての S3 バックアップ場所をターゲットとする場合においても、IBM Power®と OpenShift Container Platform 4.19 および OADP 1.5.5 の実行をサポートしています。
5.4.5.2. IBM Z を使用したターゲットバックアップロケーションの OADP テストとサポート

IBM Z® と S3 バックアップ場所をターゲットとする場合の、テスト済みでサポートされている OADP および OpenShift Container Platform のバージョン組み合わせを確認してください。これにより、IBM Z®環境および OADP バージョンがバックアップ操作でサポートされているかどうかを確認できます。

  • OpenShift Container Platform 4.12、4.13、4.14、4.15、および 1.3.6 で実行されている IBM Z® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが使用されましたが、Red Hat は、AWS 以外のすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.13、4.14、4.15、1.3.6 を使用した IBM Z® の実行をサポートしています。
  • OpenShift Container Platform 4.14、4.15、4.16、4.17、および 1.4.6 で実行されている IBM Z® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが使用されましたが、Red Hat は、AWS 以外のすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.14、4.15、4.16、4.17、および 1.4.6 を使用した IBM Z® の実行をサポートしています。
  • OpenShift Container Platform 4.19 および OADP 1.5.5 を搭載した IBM Z®が、AWS S3 バックアップ先ターゲットに対して正常にテストされました。今回のテストでは AWS S3 をターゲットとしていましたが、Red Hat は、AWS 以外のすべての S3 バックアップ場所をターゲットとして、IBM Z®と OpenShift Container Platform 4.19 および OADP 1.5.5 を実行することもサポートしています。
5.4.5.2.1. IBM Power®および IBM Z®プラットフォームを使用した OADP の既知の問題

IBM Power®および IBM Z®プラットフォーム上のシングルノード OpenShift クラスターでは、Kopia や Restic などのファイルシステムバックアップ (FSB) 方式と NFS ストレージのみを使用してください。これにより、これらのプラットフォームでサポートされていないバックアップ設定を回避することができます。

現時点では、この制限を回避する方法はありません。

5.4.6. OADP と FIPS

Federal Information Processing Standards (FIPS) は、米国連邦政府が連邦情報セキュリティー管理法 (FISMA) に沿って策定した一連のコンピューターセキュリティー標準です。

OpenShift API for Data Protection (OADP) はテスト済みで、FIPS 対応の OpenShift Container Platform クラスターで動作します。

5.4.7. Velero プラグインのパニックエラーの回避

イメージストリームの バックアップ中に発生する Velero プラグインのパニックエラーを解決するために、カスタムバックアップストレージロケーション (BSL) にラベルを付けます。これは、DataProtectionApplication (DPA) CR の外部で BSL を管理する場合に、OADP コントローラーが必要なレジストリーシークレットを作成することを保証するのに役立ちます。

シークレットが欠落していると、イメージストリームのバックアップ中に Velero プラグインでパニックエラーが発生する可能性があります。バックアップと BSL が DPA の範囲外で管理されている場合、OADP コントローラーは関連する oadp-<bsl_name>-<bsl_provider>-registry-secret パラメーターを作成しません。

バックアップ操作中に、OpenShift Velero プラグインが imagestream バックアップでパニックになり、次のパニックエラーが発生します。

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…

手順

  1. 次のコマンドを使用して、カスタムの BSL に適切なラベルを付けます。

    $ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
  2. BSL にラベルを付けた後、DPA がリコンサイルされるまで待ちます。

    注記

    DPA 自体に軽微な変更を加えることで、強制的に調整を行うことができます。

検証

  • DPA がリコンサイルされたら、次のコマンドを入力して、パラメーターが作成され、正しいレジストリーデータがそこに入力されていることを確認します。

    $ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'

5.4.8. OpenShift ADP コントローラーのセグメンテーション違反の回避策

Data Protection Application (DPA) の設定で、velero または cloudstorage の いずれかを定義して、Pod の無期限クラッシュを防いでください。この設定により、両方のコンポーネントが有効になっている場合に発生する 、openshift-adp-controller-manager Pod 内のセグメンテーション違反が解消されます。

openshift-adp-controller-manager Pod は、以下の設定が原因でクラッシュループセグメンテーション違反により失敗します。

  • velerocloudstorage を両方とも定義すると、openshift-adp-controller-manager は失敗します。
  • velerocloudstorage を両方とも定義しないと、openshift-adp-controller-manager は失敗します。

詳細は、OADP-1054 を参照してください。

5.5. OADP のユースケース

5.5.1. OpenShift API for Data Protection と Red Hat OpenShift Data Foundation (ODF) を使用したバックアップ

以下は、OADP と ODF を使用してアプリケーションをバックアップするユースケースです。

5.5.1.1. OADP と ODF を使用したアプリケーションのバックアップ

このユースケースでは、OADP を使用してアプリケーションをバックアップし、Red Hat OpenShift Data Foundation (ODF) によって提供されるオブジェクトストレージにバックアップを保存します。

  • Backup Storage Location を設定するために、Object Bucket Claim (OBC) を作成します。ODF を使用して、Amazon S3 互換のオブジェクトストレージバケットを設定します。ODF は、MultiCloud Object Gateway (NooBaa MCG) と Ceph Object Gateway (RADOS Gateway (RGW) とも呼ばれる) オブジェクトストレージサービスを提供します。このユースケースでは、Backup Storage Location として NooBaa MCG を使用します。
  • aws プロバイダープラグインを使用して、OADP で NooBaa MCG サービスを使用します。
  • Backup Storage Location (BSL) を使用して Data Protection Application (DPA) を設定します。
  • バックアップカスタムリソース (CR) を作成し、バックアップするアプリケーションの namespace を指定します。
  • バックアップを作成して検証します。

前提条件

  • OADP Operator をインストールした。
  • ODF Operator をインストールした。
  • 別の namespace で実行されているデータベースを持つアプリケーションがある。

手順

  1. 次の例に示すように、NooBaa MCG バケットを要求する OBC マニフェストファイルを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: test-obc
      namespace: openshift-adp
    spec:
      storageClassName: openshift-storage.noobaa.io
      generateBucketName: test-backup-bucket

    ここでは、以下のようになります。

    test-obc
    Object Bucket Claim の名前を指定します。
    test-backup-bucket
    バケットの名前を指定します。
  2. 次のコマンドを実行して OBC を作成します。

    $ oc create -f <obc_file_name>

    ここでは、以下のようになります。

    <obc_file_name>
    Object Bucket Claim マニフェストのファイル名を指定します。
  3. OBC を作成すると、ODF が Object Bucket Claim と同じ名前の secretconfig map を作成します。secret にはバケットの認証情報が含まれており、config map にはバケットにアクセスするための情報が含まれています。生成された config map からバケット名とバケットホストを取得するには、次のコマンドを実行します。

    $ oc extract --to=- cm/test-obc

    test-obc は OBC の名前です。

    出力例

    # BUCKET_NAME
    backup-c20...41fd
    # BUCKET_PORT
    443
    # BUCKET_REGION
    
    # BUCKET_SUBREGION
    
    # BUCKET_HOST
    s3.openshift-storage.svc

  4. 生成された secret からバケットの認証情報を取得するには、次のコマンドを実行します。

    $ oc extract --to=- secret/test-obc

    出力例

    # AWS_ACCESS_KEY_ID
    ebYR....xLNMc
    # AWS_SECRET_ACCESS_KEY
    YXf...+NaCkdyC3QPym

  5. 次のコマンドを実行して、openshift-storage namespace の s3 ルートから S3 エンドポイントのパブリック URL を取得します。

    $ oc get route s3 -n openshift-storage
  6. 次のコマンドに示すように、オブジェクトバケットの認証情報を含む cloud-credentials ファイルを作成します。

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  7. 次のコマンドに示すように、cloud-credentials ファイルの内容を使用して cloud-credentials シークレットを作成します。

    $ oc create secret generic \
      cloud-credentials \
      -n openshift-adp \
      --from-file cloud=cloud-credentials
  8. 次の例に示すように、Data Protection Application (DPA) を設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - aws
            - openshift
            - csi
          defaultSnapshotMoveData: true
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: noobaa
              s3Url: https://s3.openshift-storage.svc
              s3ForcePathStyle: "true"
              insecureSkipTLSVerify: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  cloud-credentials
            objectStorage:
              bucket: <bucket_name>
              prefix: oadp

    ここでは、以下のようになります。

    defaultSnapshotMoveData
    true に設定し、OADP Data Mover を使用して Container Storage Interface (CSI) スナップショットをリモートオブジェクトストレージに移動できるようにします。
    s3Url
    ODF ストレージの S3 URL を指定します。
    <bucket_name>
    バケット名を指定します。
  9. 次のコマンドを実行して DPA を作成します。

    $ oc apply -f <dpa_filename>
  10. 次のコマンドを実行して、DPA が正常に作成されたことを確認します。出力例から、status オブジェクトの type フィールドが Reconciled に設定されていることがわかります。これは、DPA が正常に作成されたことを意味します。

    $ oc get dpa -o yaml

    出力例

    apiVersion: v1
    items:
    - apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        namespace: openshift-adp
        #...#
      spec:
        backupLocations:
        - velero:
            config:
              #...#
      status:
        conditions:
        - lastTransitionTime: "20....9:54:02Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled
    kind: List
    metadata:
      resourceVersion: ""

  11. 次のコマンドを実行して、Backup Storage Location (BSL) が使用可能であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    出力例

    NAME           PHASE       LAST VALIDATED   AGE   DEFAULT
    dpa-sample-1   Available   3s               15s   true

  12. 次の例に示すように、バックアップ CR を設定します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace>

    ここでは、以下のようになります。

    <application_namespace>
    バックアップするアプリケーションの namespace を指定します。
  13. 次のコマンドを実行してバックアップ CR を作成します。

    $ oc apply -f <backup_cr_filename>

検証

  • 次のコマンドを実行して、バックアップオブジェクトが Completed フェーズにあることを確認します。詳細は、出力例を参照してください。

    $ oc describe backup test-backup -n openshift-adp

    出力例

    Name:         test-backup
    Namespace:    openshift-adp
    # ....#
    Status:
      Backup Item Operations Attempted:  1
      Backup Item Operations Completed:  1
      Completion Timestamp:              2024-09-25T10:17:01Z
      Expiration:                        2024-10-25T10:16:31Z
      Format Version:                    1.1.0
      Hook Status:
      Phase:  Completed
      Progress:
        Items Backed Up:  34
        Total Items:      34
      Start Timestamp:    2024-09-25T10:16:31Z
      Version:            1
    Events:               <none>

5.5.2. OpenShift API for Data Protection (OADP) による復元のユースケース

以下は、OADP を使用してバックアップを別の namespace に復元するユースケースです。

5.5.2.1. OADP を使用してアプリケーションを別の namespace に復元する

OADP を使用して、アプリケーションのバックアップを、新しいターゲット namespace の test-restore-application に復元します。バックアップを復元するには、次の例に示すように、復元カスタムリソース (CR) を作成します。この復元 CR では、バックアップに含めたアプリケーションの namespace を、ソース namespace が参照します。その後、新しい復元先の namespace にプロジェクトを切り替えてリソースを確認することで、復元を検証します。

前提条件

  • OADP Operator をインストールした。
  • 復元するアプリケーションのバックアップがある。

手順

  1. 次の例に示すように、復元 CR を作成します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: test-restore
      namespace: openshift-adp
    spec:
      backupName: <backup_name>
      restorePVs: true
      namespaceMapping:
        <application_namespace>: test-restore-application

    ここでは、以下のようになります。

    test-restore
    復元 CR の名前を指定します。
    <backup_name>
    バックアップの名前を指定します。
    <application_namespace>
    復元先のターゲット namespace を指定します。namespaceMapping は、ソースアプリケーションの namespace をターゲットアプリケーションの namespace にマップします。test-restore-application は、バックアップ復元するターゲット namespace の名前です。
  2. 次のコマンドを実行して復元 CR を適用します。

    $ oc apply -f <restore_cr_filename>

検証

  1. 次のコマンドを実行して、復元が Completed フェーズにあることを確認します。

    $ oc describe restores.velero.io <restore_name> -n openshift-adp
  2. 次のコマンドを実行して、復元先の namespace test-restore-application に切り替えます。

    $ oc project test-restore-application
  3. 次のコマンドを実行して、永続ボリューム要求 (pvc)、サービス (svc)、デプロイメント、シークレット、config map などの復元されたリソースを確認します。

    $ oc get pvc,svc,deployment,secret,configmap

    出力例

    NAME                          STATUS   VOLUME
    persistentvolumeclaim/mysql   Bound    pvc-9b3583db-...-14b86
    
    NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
    service/mysql      ClusterIP   172....157     <none>        3306/TCP   2m56s
    service/todolist   ClusterIP   172.....15     <none>        8000/TCP   2m56s
    
    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/mysql   0/1     1            0           2m55s
    
    NAME                                         TYPE                      DATA   AGE
    secret/builder-dockercfg-6bfmd               kubernetes.io/dockercfg   1      2m57s
    secret/default-dockercfg-hz9kz               kubernetes.io/dockercfg   1      2m57s
    secret/deployer-dockercfg-86cvd              kubernetes.io/dockercfg   1      2m57s
    secret/mysql-persistent-sa-dockercfg-rgp9b   kubernetes.io/dockercfg   1      2m57s
    
    NAME                                 DATA   AGE
    configmap/kube-root-ca.crt           1      2m57s
    configmap/openshift-service-ca.crt   1      2m57s

5.5.3. バックアップ時の自己署名 CA 証明書の追加

自己署名認証局 (CA) 証明書を Data Protection Application (DPA) に含めてから、アプリケーションをバックアップできます。バックアップは、Red Hat OpenShift Data Foundation (ODF) が提供する NooBaa バケットに保存します。

5.5.3.1. アプリケーションとその自己署名 CA 証明書のバックアップ

ODF によって提供される s3.openshift-storage.svc サービスは、自己署名サービス CA で署名された Transport Layer Security (TLS) プロトコル証明書を使用します。

certificate signed by unknown authority エラーを防ぐには、DataProtectionApplication カスタムリソース (CR) の Backup Storage Location (BSL) セクションに自己署名 CA 証明書を含める必要があります。この場合、次のタスクを完了する必要があります。

  • Object Bucket Claim (OBC) を作成して、NooBaa バケットを要求します。
  • バケットの詳細を抽出します。
  • DataProtectionApplication CR に自己署名 CA 証明書を含めます。
  • アプリケーションをバックアップします。

前提条件

  • OADP Operator をインストールした。
  • ODF Operator をインストールした。
  • 別の namespace で実行されているデータベースを持つアプリケーションがある。

手順

  1. 次の例に示すように、NooBaa バケットを要求する OBC マニフェストを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: test-obc
      namespace: openshift-adp
    spec:
      storageClassName: openshift-storage.noobaa.io
      generateBucketName: test-backup-bucket

    ここでは、以下のようになります。

    test-obc
    Object Bucket Claim の名前を指定します。
    test-backup-bucket
    バケットの名前を指定します。
  2. 次のコマンドを実行して OBC を作成します。

    $ oc create -f <obc_file_name>
  3. OBC を作成すると、ODF が Object Bucket Claim と同じ名前の secretConfigMap を作成します。secret オブジェクトにはバケットの認証情報が含まれ、ConfigMap オブジェクトにはバケットにアクセスするための情報が含まれています。生成された config map からバケット名とバケットホストを取得するには、次のコマンドを実行します。

    $ oc extract --to=- cm/test-obc

    test-obc は OBC の名前です。

    出力例

    # BUCKET_NAME
    backup-c20...41fd
    # BUCKET_PORT
    443
    # BUCKET_REGION
    
    # BUCKET_SUBREGION
    
    # BUCKET_HOST
    s3.openshift-storage.svc

  4. secret オブジェクトからバケット認証情報を取得するには、次のコマンドを実行します。

    $ oc extract --to=- secret/test-obc

    出力例

    # AWS_ACCESS_KEY_ID
    ebYR....xLNMc
    # AWS_SECRET_ACCESS_KEY
    YXf...+NaCkdyC3QPym

  5. 次の設定例を使用して、オブジェクトバケットの認証情報を含む cloud-credentials ファイルを作成します。

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  6. 次のコマンドを実行して、cloud-credentials ファイルの内容を使用して cloud-credentials シークレットを作成します。

    $ oc create secret generic \
      cloud-credentials \
      -n openshift-adp \
      --from-file cloud=cloud-credentials
  7. 次のコマンドを実行して、openshift-service-ca.crt config map からサービス CA 証明書を抽出します。証明書を Base64 形式で必ずエンコードし、次のステップで使用する値をメモしてください。

    $ oc get cm/openshift-service-ca.crt \
      -o jsonpath='{.data.service-ca\.crt}' | base64 -w0; echo

    出力例

    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0...
    ....gpwOHMwaG9CRmk5a3....FLS0tLS0K

  8. 次の例に示すように、バケット名と CA 証明書を使用して DataProtectionApplication CR マニフェストファイルを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - aws
            - openshift
            - csi
          defaultSnapshotMoveData: true
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: noobaa
              s3Url: https://s3.openshift-storage.svc
              s3ForcePathStyle: "true"
              insecureSkipTLSVerify: "false"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  cloud-credentials
            objectStorage:
              bucket: <bucket_name>
              prefix: oadp
              caCert: <ca_cert>

    ここでは、以下のようになります。

    insecureSkipTLSVerify
    SSL/TLS セキュリティーが有効かどうかを指定します。true に設定すると、SSL/TLS セキュリティーが無効になります。false に設定すると、SSL/TLS セキュリティーが有効になります。
    <bucket_name>
    前のステップで抽出したバケットの名前を指定します。
    <ca_cert>
    前の手順で Base64 でエンコードした証明書を指定します。
  9. 次のコマンドを実行して、DataProtectionApplication CR を作成します。

    $ oc apply -f <dpa_filename>
  10. 次のコマンドを実行して、DataProtectionApplication CR が正常に作成されたことを確認します。

    $ oc get dpa -o yaml

    出力例

    apiVersion: v1
    items:
    - apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        namespace: openshift-adp
        #...#
      spec:
        backupLocations:
        - velero:
            config:
              #...#
      status:
        conditions:
        - lastTransitionTime: "20....9:54:02Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled
    kind: List
    metadata:
      resourceVersion: ""

  11. 次のコマンドを実行して、Backup Storage Location (BSL) が使用可能であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    出力例

    NAME           PHASE       LAST VALIDATED   AGE   DEFAULT
    dpa-sample-1   Available   3s               15s   true

  12. 次の例を使用して、Backup CR を設定します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace>

    ここでは、以下のようになります。

    <application_namespace>
    バックアップするアプリケーションの namespace を指定します。
  13. 次のコマンドを実行して Backup CR を作成します。

    $ oc apply -f <backup_cr_filename>

検証

  • 次のコマンドを実行して、Backup オブジェクトが Completed フェーズにあることを確認します。

    $ oc describe backup test-backup -n openshift-adp

    出力例

    Name:         test-backup
    Namespace:    openshift-adp
    # ....#
    Status:
      Backup Item Operations Attempted:  1
      Backup Item Operations Completed:  1
      Completion Timestamp:              2024-09-25T10:17:01Z
      Expiration:                        2024-10-25T10:16:31Z
      Format Version:                    1.1.0
      Hook Status:
      Phase:  Completed
      Progress:
        Items Backed Up:  34
        Total Items:      34
      Start Timestamp:    2024-09-25T10:16:31Z
      Version:            1
    Events:               <none>

5.5.4. legacy-aws Velero プラグインの使用

AWS S3 互換の Backup Storage Location を使用している場合、アプリケーションのバックアップ中に SignatureDoesNotMatch エラーが発生する可能性があります。このエラーは、一部の Backup Storage Location で、新しい AWS SDK for Go V2 と互換性のない古いバージョンの S3 API がまだ使用されているために発生します。この問題を解決するには、DataProtectionApplication カスタムリソース (CR) で legacy-aws Velero プラグインを使用できます。legacy-aws Velero プラグインは、従来の S3 API と互換性のある古い AWS SDK for Go V1 を使用します。これによりバックアップが正常に実行されます。

5.5.4.1. DataProtectionApplication CR で legacy-aws Velero プラグインを使用する

次のユースケースでは、legacy-aws Velero プラグインを使用して DataProtectionApplication CR を設定し、アプリケーションをバックアップします。

注記

選択した Backup Storage Location に応じて、DataProtectionApplication CR で legacy-aws または aws プラグインのいずれかを使用できます。DataProtectionApplication CR で両方のプラグインを使用すると、aws and legacy-aws can not be both specified in DPA spec.configuration.velero.defaultPlugins というエラーが発生します。

前提条件

  • OADP Operator がインストールされている。
  • バックアップの場所として AWS S3 互換のオブジェクトストレージが設定されている。
  • 別の namespace で実行されているデータベースを持つアプリケーションがある。

手順

  1. 次の例に示すように、legacy-aws Velero プラグインを使用するように DataProtectionApplication CR を設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - legacy-aws
            - openshift
            - csi
          defaultSnapshotMoveData: true
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: noobaa
              s3Url: https://s3.openshift-storage.svc
              s3ForcePathStyle: "true"
              insecureSkipTLSVerify: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  cloud-credentials
            objectStorage:
              bucket: <bucket_name>
              prefix: oadp

    ここでは、以下のようになります。

    legacy-aws
    legacy-aws プラグインを使用するように指定します。
    <bucket_name>
    バケット名を指定します。
  2. 次のコマンドを実行して、DataProtectionApplication CR を作成します。

    $ oc apply -f <dpa_filename>
  3. 次のコマンドを実行して、DataProtectionApplication CR が正常に作成されたことを確認します。出力例から、status オブジェクトの type フィールドが Reconciled に設定され、status フィールドが "True" に設定されていることがわかります。このステータスは、DataProtectionApplication CR が正常に作成されたことを示します。

    $ oc get dpa -o yaml

    出力例

    apiVersion: v1
    items:
    - apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        namespace: openshift-adp
        #...#
      spec:
        backupLocations:
        - velero:
            config:
              #...#
      status:
        conditions:
        - lastTransitionTime: "20....9:54:02Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled
    kind: List
    metadata:
      resourceVersion: ""

  4. 次のコマンドを実行して、Backup Storage Location (BSL) が使用可能であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    次の例のような出力が表示されます。

    NAME           PHASE       LAST VALIDATED   AGE   DEFAULT
    dpa-sample-1   Available   3s               15s   true
  5. 次の例に示すように、Backup CR を設定します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace>

    ここでは、以下のようになります。

    <application_namespace>
    バックアップするアプリケーションの namespace を指定します。
  6. 次のコマンドを実行して Backup CR を作成します。

    $ oc apply -f <backup_cr_filename>

検証

  • 次のコマンドを実行して、バックアップオブジェクトが Completed フェーズにあることを確認します。詳細は、出力例を参照してください。

    $ oc describe backups.velero.io test-backup -n openshift-adp

    出力例

    Name:         test-backup
    Namespace:    openshift-adp
    # ....#
    Status:
      Backup Item Operations Attempted:  1
      Backup Item Operations Completed:  1
      Completion Timestamp:              2024-09-25T10:17:01Z
      Expiration:                        2024-10-25T10:16:31Z
      Format Version:                    1.1.0
      Hook Status:
      Phase:  Completed
      Progress:
        Items Backed Up:  34
        Total Items:      34
      Start Timestamp:    2024-09-25T10:16:31Z
      Version:            1
    Events:               <none>

5.5.5. OpenShift Container Platform を使用した OADP 上のワークロードのバックアップ

ROSA 上のワークロードのバックアップと復元には、OADP を使用できます。ワークロードのバックアップを作成し、バックアップから復元し、復元を検証することができます。OADPOperator、バックアップストレージ、および AWS リソースが不要になった場合は、それらをクリーンアップすることもできます。

5.5.5.1. 例:OADP と OpenShift Container Platform を使用したバックアップの実行

OpenShift Container Platform で OpenShift API for Data Protection (OADP) を使用してバックアップを実行します。次の hello-world アプリケーションの例では、永続ボリューム (PV) がアタッチされていません。

どちらの Data Protection Application (DPA) 設定も機能します。

手順

  1. 次のコマンドを実行して、バックアップするワークロードを作成します。

    $ oc create namespace hello-world
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
  2. 次のコマンドを実行してルートを公開します。

    $ oc expose service/hello-openshift -n hello-world
  3. 次のコマンドを実行して、アプリケーションが動作していることを確認します。

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    次の例のような出力が表示されます。

    Hello OpenShift!
  4. 次のコマンドを実行して、ワークロードをバックアップします。

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Backup
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        includedNamespaces:
        - hello-world
        storageLocation: ${CLUSTER_NAME}-dpa-1
        ttl: 720h0m0s
    EOF
  5. バックアップが完了するまで待ってから、次のコマンドを実行します。

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"

    次の例のような出力が表示されます。

    {
      "completionTimestamp": "2022-09-07T22:20:44Z",
      "expiration": "2022-10-07T22:20:22Z",
      "formatVersion": "1.1.0",
      "phase": "Completed",
      "progress": {
        "itemsBackedUp": 58,
        "totalItems": 58
      },
      "startTimestamp": "2022-09-07T22:20:22Z",
      "version": 1
    }
  6. 次のコマンドを実行して、デモワークロードを削除します。

    $ oc delete ns hello-world
  7. 次のコマンドを実行して、バックアップからワークロードを復元します。

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        backupName: hello-world
    EOF
  8. 次のコマンドを実行して、復元が完了するまで待ちます。

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"

    次の例のような出力が表示されます。

    {
      "completionTimestamp": "2022-09-07T22:25:47Z",
      "phase": "Completed",
      "progress": {
        "itemsRestored": 38,
        "totalItems": 38
      },
      "startTimestamp": "2022-09-07T22:25:28Z",
      "warnings": 9
    }
  9. 次のコマンドを実行して、ワークロードが復元されていることを確認します。

    $ oc -n hello-world get pods

    次の例のような出力が表示されます。

    NAME                              READY   STATUS    RESTARTS   AGE
    hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s
  10. 次のコマンドを実行して JSONPath を確認します。

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    次の例のような出力が表示されます。

    Hello OpenShift!
    注記

    トラブルシューティングのヒントについては、トラブルシューティングのドキュメント を参照してください。

5.5.5.2. OADP と ROSA STS を使用してバックアップ後のクラスターをクリーンアップする

OpenShift API for Data Protection (OADP) Operator を、hello-world サンプルで使用したバックアップと S3 バケットとともにアンインストールします。

手順

  1. 次のコマンドを実行して、ワークロードを削除します。

    $ oc delete ns hello-world
  2. 次のコマンドを実行して、Data Protection Application (DPA) を削除します。

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
  3. 次のコマンドを実行して、クラウドストレージを削除します。

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    警告

    このコマンドがハングした場合は、次のコマンドを実行してファイナライザーを削除する必要がある場合があります。

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
  4. Operator が不要になった場合は、次のコマンドを実行して削除します。

    $ oc -n openshift-adp delete subscription oadp-operator
  5. Operator から namespace を削除します。

    $ oc delete ns openshift-adp
  6. バックアップおよび復元リソースが不要になった場合は、次のコマンドを実行してクラスターからリソースを削除します。

    $ oc delete backups.velero.io hello-world
  7. AWS S3 のバックアップ、復元、およびリモートオブジェクトを削除するには、次のコマンドを実行します。

    $ velero backup delete hello-world
  8. カスタムリソース定義 (CRD) が不要になった場合は、次のコマンドを実行してクラスターから削除します。

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
  9. 次のコマンドを実行して、AWS S3 バケットを削除します。

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
  10. 次のコマンドを実行して、ロールからポリシーを切り離します。

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
  11. 以下のコマンドを実行してロールを削除します。

    $ aws iam delete-role --role-name "${ROLE_NAME}"

5.6. OADP のインストール

5.6.1. OADP のインストールについて

クラスター管理者は、OADP Operator をインストールして、OpenShift API for Data Protection (OADP) をインストールします。OADP Operator は Velero 1.16 をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

Kubernetes リソースと内部イメージをバックアップするには、次のいずれかのストレージタイプなど、バックアップロケーションとしてオブジェクトストレージが必要です。

個々の OADP デプロイメントごとに、同じ namespace 内に複数の Backup Storage Location を設定できます。

注記

特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。

MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。

スナップショットまたは File System Backup (FSB) を使用して、永続ボリューム (PV) をバックアップできます。

スナップショットを使用して PV をバックアップするには、ネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートするクラウドプロバイダー (次のいずれかのクラウドプロバイダーなど) が必要です。

注記

OCP 4.11 以降で CSI バックアップを使用する場合は、OADP 1.1.x をインストールします。

OADP 1.0.x は、OCP 4.11 以降での CSI バックアップをサポートしていません。OADP 1.0.x には Velero 1.7.x が含まれており、OCP 4.11 以降には存在しない API グループ snapshot.storage.k8s.io/v1beta1 が必要です。

クラウドプロバイダーがスナップショットをサポートしていない場合、またはストレージが NFS である場合は、オブジェクトストレージ上の File System Backup によるアプリケーションのバックアップ: Kopia または Restic を使用してアプリケーションをバックアップできます。

デフォルトの Secret を作成し、次に、Data Protection Application をインストールします。

5.6.1.1. AWS S3 互換のバックアップストレージプロバイダー

OADP は、多くの S3 互換オブジェクトストレージプロバイダーと連携します。OADP のリリースごとに、複数のオブジェクトストレージプロバイダーが認定およびテストされています。さまざまな S3 プロバイダーが OADP で動作することが知られていますが、テストおよび認定は特にされていません。これらのプロバイダーはベストエフォート方式でサポートされます。いくつかの S3 オブジェクトストレージプロバイダーには、このドキュメントに記載されている既知の問題と制限があります。

注記

Red Hat は、任意の S3 互換ストレージ上の OADP のサポートを提供しますが、S3 エンドポイントが問題の根本原因であると判断された場合はサポートが停止されます。

5.6.1.1.1. 認定バックアップストレージプロバイダー

次の AWS S3 互換オブジェクトストレージプロバイダーは、AWS プラグインを介して OADP によって完全にサポートされており、Backup Storage Location として使用できます。

  • MinIO
  • Multicloud Object Gateway (MCG)
  • Amazon Web Services (AWS) S3
  • IBM Cloud® Object Storage S3
  • Ceph RADOS ゲートウェイ (Ceph オブジェクトゲートウェイ)
  • Red Hat Container Storage
  • Red Hat OpenShift Data Foundation
  • NetApp ONTAP S3 Object Storage
  • Scality ARTESCA S3 オブジェクトストレージ
注記

次の互換オブジェクトストレージプロバイダーはサポートされており、独自の Velero オブジェクトストアプラグインがあります。

  • Google Cloud
  • Microsoft Azure
5.6.1.1.2. サポートされていないバックアップストレージプロバイダー

次の AWS S3 互換オブジェクトストレージプロバイダーは、AWS プラグインを介して Velero と連携し、Backup Storage Location として使用できることがわかっています。ただし、Red Hat ではサポートされておらず、テストも行われていません。

  • Oracle Cloud
  • DigitalOcean
  • NooBaa (Multicloud Object Gateway (MCG) を使用してインストールされていない場合)
  • Tencent Cloud
  • Ceph RADOS v12.2.7
  • Quobyte
  • Cloudian HyperStore
注記

特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。

MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。

5.6.1.1.3. 既知の制限があるバックアップストレージプロバイダー

次の AWS S3 互換オブジェクトストレージプロバイダーは、AWS プラグインを介して Velero と連携することがわかっていますが、機能セットが制限されています。

  • Swift - バックアップストレージの Backup Storage Location として使用できますが、ファイルシステムベースのボリュームバックアップおよび復元については Restic と互換性がありません。
5.6.1.2. OpenShift Data Foundation で障害復旧を行うための Multicloud Object Gateway (MCG) 設定

OpenShift Data Foundation 上の MCG バケット backupStorageLocation にクラスターストレージを使用する場合は、MCG を外部オブジェクトストアとして設定します。

警告

MCG を外部オブジェクトストアとして設定しない場合、バックアップが利用できなくなる可能性があります。

注記

特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。

MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。

手順

5.6.1.3. OADP 更新チャネルについて

OADPOperator をインストールする際には、更新チャネルを選択します。このチャネルにより、OADP Operator と Velero のどちらのアップグレードを受け取るかが決まります。

次の更新チャネルを利用できます。

  • stable-1.3 チャネルには、最新の OADP 1.3 ClusterServiceVersionOADP.v1.3.z が含まれています。
  • stable-1.4 チャネルには、最新の OADP 1.4 ClusterServiceVersionOADP.v1.4.z が含まれています。
  • OpenShift Container Platform v4.19 の OADP 1.5 以降では、OADP は特定の OpenShift Container Platform バージョンでサポートされている単一の OADP バージョンを含む 安定版 チャネルを再導入します。

詳細は、OpenShift Operator のライフサイクル を参照してください。

適切な更新チャネルはどれですか?

  • すでに 安定版 チャネルを使用している場合は、引き続き OADP.v1.5.z からのアップデートを受け取ることができます。
  • stable-1.y をインストールする OADP 1.y 更新チャネルを選択し、そのパッチを引き続き受け取ります。このチャネルを選択すると、バージョン 1.y.z のすべての z-stream パッチを受け取ります。

いつ更新チャネルを切り替える必要がありますか?

  • OADP 1.y がインストールされていて、その y-stream のパッチのみを受け取りたい場合は、stable 更新チャネルから stable-1.y 更新チャネルに切り替える必要があります。その後、バージョン 1.y.z のすべての z-stream パッチを受け取ります。
  • OADP 1.0 がインストールされていて、OADP 1.1 にアップグレードしたい場合、OADP 1.1 のみのパッチを受け取るには、stable-1.0 更新チャネルから stable-1.1 更新チャネルに切り替える必要があります。その後、バージョン 1.1.z のすべての z-stream パッチを受け取ります。
  • OADP 1.y がインストールされていて、y が 0 より大きく、OADP 1.0 に切り替える場合は、OADP Operator をアンインストールしてから、stable-1.0 更新チャネルを使用して再インストールする必要があります。その後、バージョン 1.0.z のすべての z-stream パッチを受け取ります。
注記

更新チャネルを切り替えて、OADP 1.y から OADP 1.0 に切り替えることはできません。Operator をアンインストールしてから再インストールする必要があります。

5.6.1.4. 複数の namespace への OADP のインストール

OpenShift API for Data Protection を同じクラスター上の複数の namespace にインストールすると、複数のプロジェクト所有者が独自の OADP インスタンスを管理できるようになります。このユースケースは、File System Backup (FSB) と Container Storage Interface (CSI) を使用して検証されています。

このドキュメントに含まれるプラットフォームごとの手順で指定されている OADP の各インスタンスを、以下の追加要件とともにインストールします。

  • 同じクラスター上の OADP のデプロイメントは、すべて同じバージョン (例: 1.4.0) である必要があります。同じクラスターに異なるバージョンの OADP をインストールすることは サポートされていません
  • OADP の個々のデプロイメントには、一意の認証情報セットと一意の BackupStorageLocation 設定が必要です。同じ namespace 内で、複数の BackupStorageLocation 設定を使用することもできます。
  • デフォルトでは、各 OADP デプロイメントには namespace 全体でクラスターレベルのアクセス権があります。OpenShift Container Platform 管理者は、同じ namespace へのバックアップと復元を同時に行わないことなど、潜在的な影響を慎重に検討する必要があります。
5.6.1.5. OADP がバックアップデータの不変性をサポートする

OADP 1.4 以降では、バージョン管理が有効になっている AWS S3 バケットに OADP バックアップを保存できます。バージョン管理のサポートは AWS S3 バケットのみに適用され、S3 互換バケットには適用されません。

特定のクラウドプロバイダーの制限については、次のリストを参照してください。

  • S3 オブジェクトロックはバージョン管理されたバケットにのみ適用されるため、AWS S3 サービスはバックアップをサポートします。新しいバージョンのオブジェクトデータを更新することもできます。ただし、バックアップは削除されても、オブジェクトの古いバージョンは削除されません。
  • OADP バックアップはサポートされておらず、Azure Storage Blob で不変性を有効にすると期待どおりに動作しない可能性があります。
  • Google Cloud ストレージポリシーは、バケットレベルの不変性のみをサポートしています。したがって、Google Cloud 環境で不変性を実装することは現実的ではありません。

ストレージプロバイダーに応じて、不変性オプションの呼び出し方法は異なります。

  • S3 オブジェクトロック
  • オブジェクト保持
  • バケットバージョン管理
  • Write Once Read Many (WORM) バケット

他の S3 互換オブジェクトストレージがサポートされていない主な理由は、OADP が最初にバックアップの状態を finalizing として保存し、その後、非同期操作が進行中かどうかを確認するためです。

5.6.1.6. 収集したデータに基づく Velero CPU およびメモリーの要件

以下の推奨事項は、スケールおよびパフォーマンスのラボで観察したパフォーマンスに基づいています。バックアップおよび復元リソースは、プラグインのタイプ、そのバックアップまたは復元に必要なリソースの量、そのリソースに関連する永続ボリューム (PV) に含まれるデータの影響を受けます。

5.6.1.6.1. 設定に必要な CPU とメモリー
Expand
設定タイプ[1] 平均使用量[2] 大量使用時resourceTimeouts

CSI

Velero:

CPU - リクエスト 200m、制限 1000m

メモリー - リクエスト 256 Mi、制限 1024 Mi

Velero:

CPU - リクエスト 200m、制限 2000m

メモリー - リクエスト 256 Mi、制限 2048 Mi

該当なし

Restic

[3] Restic:

CPU - リクエスト 1000m、制限 2000m

メモリー - リクエスト 16 Gi、制限 32 Gi

[4] Restic:

CPU - リクエスト 2000m、制限 8000m

メモリー - リクエスト 16 Gi、制限 40 Gi

900 m

[5] Data Mover

該当なし

該当なし

10m - 平均使用量

60m - 大量使用時

  1. 平均使用量 - ほとんどの状況下でこの設定を使用します。
  2. 大量使用時 - 大規模な PV (使用量 500 GB)、複数の namespace (100 以上)、または 1 つの namespace に多数の Pod (2000 Pod 以上) があるなどして使用量が大きくなる状況下では、大規模なデータセットを含む場合のバックアップと復元で最適なパフォーマンスを実現するために、この設定を使用します。
  3. Restic リソースの使用量は、データの量とデータタイプに対応します。たとえば、多数の小さなファイルや大量のデータがある場合は、Restic が大量のリソースを使用する可能性があります。Velero のドキュメントでは、指定されたデフォルト値である 500 m を参照していますが、ほとんどのテストではリクエスト 200 m、制限 1000 m が適切でした。Velero のドキュメントに記載されているとおり、正確な CPU とメモリー使用量は、環境の制限に加えて、ファイルとディレクトリーの規模に依存します。
  4. CPU を増やすと、バックアップと復元の時間を大幅に短縮できます。
  5. Data Mover - Data Mover のデフォルトの resourceTimeout は 10 m です。テストでは、大規模な PV (使用量 500 GB) を復元するには、resourceTimeout を 60m に増やす必要があることがわかりました。
注記

このガイド全体に記載されているリソース要件は、平均的な使用量に限定されています。大量に使用する場合は、上の表の説明に従って設定を調整してください。

5.6.1.6.2. 大量使用のための NodeAgent CPU

テストの結果、NodeAgent CPU を増やすと、OpenShift API for Data Protection (OADP) を使用する際のバックアップと復元の時間が大幅に短縮されることがわかりました。

重要

パフォーマンス分析と要件に応じて、OpenShift Container Platform 環境を調整できます。ファイルシステムのバックアップに Kopia を使用する場合は、ワークロードで CPU 制限を使用してください。

Pod で CPU 制限を使用しない場合、Pod は利用可能な場合に余剰の CPU を使用できます。CPU 制限を指定すると、Pod がその制限を超えたときに、Pod にスロットリングが適用される可能性があります。したがって、Pod で CPU 制限を使用することはアンチパターンと考えられています。

Pod が余剰の CPU を利用できるように、必ず CPU 要求を正確に指定してください。リソースの割り当ては、CPU 制限ではなく CPU 要求に基づいて保証されます。

テストの結果、20 コアと 32 Gi メモリーで Kopia を実行した場合、100 GB 超のデータ、複数の namespace、または単一 namespace 内の 2000 超の Pod のバックアップと復元操作がサポートされることが判明しました。テストでは、これらのリソース仕様では CPU の制限やメモリーの飽和は検出されませんでした。

環境によっては、デフォルト設定によりリソースが飽和状態になった場合に発生する Pod の再起動を回避するために、Ceph MDS Pod リソースを調整する必要があります。

Ceph MDS Pod で Pod リソース制限を設定する方法の詳細は、rook-ceph Pod の CPU およびメモリーリソースの変更 を参照してください。

5.6.2. OADP Operator のインストール

Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.20 に OpenShift API for Data Protection (OADP) Operator をインストールします。

OADP Operator は Velero 1.16 をインストールします。

5.6.2.1. OADP Operator のインストール

OpenShift Container Platform の Web コンソールを使用して OADPOperator をインストールします。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、EcosystemSoftware Catalog をクリックします。
  2. Filter by keyword フィールドを使用して、OADP Operator を検索します。
  3. OADP Operator を選択し、Install をクリックします。
  4. Install をクリックして、openshift-adp プロジェクトに Operator をインストールします。
  5. インストールを確認するには、EcosystemInstalled Operators をクリックします。
5.6.2.2. OADP、Velero、および OpenShift Container Platform の各バージョンの関係

OADP、Velero、および OpenShift Container Platform 間のバージョン関係を確認し、互換性のあるバージョンの組み合わせを決定します。これにより、クラスター環境に適した OADP バージョンを選択できます。

Expand
OADP のバージョンVelero のバージョンOpenShift Container Platform バージョン

1.3.0

1.12

4.12-4.15

1.3.1

1.12

4.12-4.15

1.3.2

1.12

4.12-4.15

1.3.3

1.12

4.12-4.15

1.3.4

1.12

4.12-4.15

1.3.5

1.12

4.12-4.15

1.4.0

1.14

4.14-4.18

1.4.1

1.14

4.14-4.18

1.4.2

1.14

4.14-4.18

1.4.3

1.14

4.14-4.18

1.5.0

1.16

4.19

5.7. AWS S3 互換ストレージを使用した OADP の設定

5.7.1. AWS S3 互換ストレージを使用した OpenShift API for Data Protection の設定

OADP Operator をインストールすることで、Amazon Web Services (AWS) S3 互換ストレージを使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.16 をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

Velero 用に AWS を設定し、デフォルトの Secret を作成してから、Data Protection Application をインストールします。詳細は、OADP Operator のインストール を参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。詳細は、非接続環境での Operator Lifecycle Manager の使用 を参照してください。

5.7.1.1. Amazon Simple Storage Service、Identity and Access Management、GovCloud について

バックアップストレージを適切なセキュリティー制御で設定するために、Amazon Simple Storage Service (S3)、アイデンティティー and Access Management (IAM)、および AWS GovCloud の要件を確認してください。これは、連邦政府のデータセキュリティー要件を満たし、適切なエンドポイントを使用するのに役立ちます。

AWS S3 は、Amazon が提供するインターネット向けストレージソリューションです。許可されたユーザーは、このサービスを使用して、Web 上のどこからでも、いつでも任意の量のデータを保存および取得できます。

AWS Identity and Access Management (IAM) Web サービスは、Amazon S3 やその他の Amazon サービスへのアクセスをセキュアに制御するために使用します。

IAM を使用すると、ユーザーがアクセスできる AWS リソースを制御する権限を管理できます。IAM は、ユーザーが本人であるかどうかを認証 (検証) するとともに、リソースを使用する権限を認可 (付与) するために使用します。

AWS GovCloud (US) は、米国連邦政府の厳格かつ特定のデータセキュリティー要件を満たすために開発された Amazon ストレージソリューションです。AWS GovCloud (US) は、次の点を除いて Amazon S3 と同じように動作します。

  • AWS GovCloud (米国) リージョンの Amazon S3 バケットの内容を、別の AWS リージョンに、または別の AWS リージョンから直接コピーすることはできません。
  • Amazon S3 ポリシーを使用する場合は、IAM ポリシー、Amazon S3 バケット名、API 呼び出しなど、AWS 全体で、AWS GovCloud (US) の Amazon Resource Name (ARN) 識別子を使用してリソースを明確に指定します。

    • AWS GovCloud (米国) リージョンでは、ARN には他の標準 AWS リージョンとは異なる識別子、arn:aws-us-gov が あります。US-West または US-East リージョンを指定する必要がある場合は、次のいずれかの ARN を使用します。

      • US-West の場合は、us-gov-west-1 を使用します。
      • US-East の場合は、us-gov-east-1 を使用します。
    • その他のすべての標準リージョンでは、ARN は arn:aws で始まります。
  • AWS GovCloud (US) リージョンでは、Amazon Simple Storage Service endpoints and quotas の "Amazon S3 endpoints" の AWS GovCloud (US-East) および AWS GovCloud (US-West) の行にリストされているエンドポイントを使用します。輸出規制対象のデータを処理している場合は、SSL/TLS エンドポイントのいずれかを使用します。FIPS 要件がある場合は、https://s3-fips.us-gov-west-1.amazonaws.comhttps://s3-fips.us-gov-east-1.amazonaws.com などの FIPS 140-2 エンドポイントを使用します。
  • AWS が課すその他の制限は、How Amazon Simple Storage Service Differs for AWS GovCloud (US) を参照してください。
5.7.1.2. Amazon Web Services の設定

OADP を使用して、Amazon Web Services (AWS) S3 ストレージと、バックアップストレージ用のアイデンティティー and Access Management (IAM) 認証情報を設定します。これにより、データ保護業務に必要な権限とストレージインフラストラクチャーが提供されます。

前提条件

  • AWS CLI がインストールされていること。

手順

  1. BUCKET 変数を設定します。

    $ BUCKET=<your_bucket>
  2. REGION 変数を設定します。

    $ REGION=<your_region>
  3. AWS S3 バケットを作成します。

    $ aws s3api create-bucket \
        --bucket $BUCKET \
        --region $REGION \
        --create-bucket-configuration LocationConstraint=$REGION

    ここでは、以下のようになります。

    LocationConstraint
    バケット設定の場所に関する制約を指定します。us-east-1LocationConstraint を サポートしていません。お住まいの地域が us-east-1 の場合は、--create-bucket-configuration LocationConstraint=$REGION を省略してください。
  4. IAM ユーザーを作成します。

    $ aws iam create-user --user-name velero

    ここでは、以下のようになります。

    velero
    ユーザー名を指定します。Velero を使用して複数の S3 バケットを持つ複数のクラスターをバックアップする場合は、クラスターごとに一意のユーザー名を作成します。
  5. velero-policy.json ファイルを作成します。

    $ cat > velero-policy.json <<EOF
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ec2:DescribeVolumes",
                    "ec2:DescribeSnapshots",
                    "ec2:CreateTags",
                    "ec2:CreateVolume",
                    "ec2:CreateSnapshot",
                    "ec2:DeleteSnapshot"
                ],
                "Resource": "*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:PutObject",
                    "s3:AbortMultipartUpload",
                    "s3:ListMultipartUploadParts"
                ],
                "Resource": [
                    "arn:aws:s3:::${BUCKET}/*"
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetBucketLocation",
                    "s3:ListBucketMultipartUploads"
                ],
                "Resource": [
                    "arn:aws:s3:::${BUCKET}"
                ]
            }
        ]
    }
    EOF
  6. ポリシーを添付して、velero ユーザーに必要最小限の権限を付与します。

    $ aws iam put-user-policy \
      --user-name velero \
      --policy-name velero \
      --policy-document file://velero-policy.json
  7. velero ユーザーのアクセスキーを作成します。

    $ aws iam create-access-key --user-name velero
    {
      "AccessKey": {
            "UserName": "velero",
            "Status": "Active",
            "CreateDate": "2017-07-31T22:24:41.576Z",
            "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
            "AccessKeyId": <AWS_ACCESS_KEY_ID>
      }
    }
  8. credentials-velero ファイルを作成します。

    $ cat << EOF > ./credentials-velero
    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
    EOF

    Data Protection Application をインストールする前に、credentials-velero ファイルを使用して AWS の Secret オブジェクトを作成します。

5.7.1.3. バックアップおよびスナップショットの場所、ならびにそのシークレットについて

DataProtectionApplication カスタムリソース (CR) のバックアップ場所、スナップショット場所、およびシークレット設定要件を確認してください。これは、データ保護業務におけるストレージオプションと認証情報管理を理解するのに役立ちます。

5.7.1.3.1. バックアップの場所

バックアップの場所として、次のいずれかの AWS S3 互換オブジェクトストレージソリューションを指定できます。

  • Multicloud Object Gateway (MCG)
  • Red Hat Container Storage
  • Ceph RADOS Gateway (別称 Ceph Object Gateway)
  • Red Hat OpenShift Data Foundation
  • MinIO

Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。

5.7.1.3.2. スナップショットの場所

クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。

Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。

File System Backup (FSB) を使用する場合、FSB がオブジェクトストレージ上にファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。

5.7.1.3.3. シークレット

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。

  • DataProtectionApplication CR で指定する、バックアップの場所用のカスタム Secret
  • DataProtectionApplication CR で参照されない、スナップショットの場所用のデフォルト Secret
重要

Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。

インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。

5.7.1.3.4. デフォルト Secret の作成

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

Secret のデフォルト名は cloud-credentials です。

注記

DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。

インストール時にバックアップ場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用して、デフォルト名の Secret を作成できます。

前提条件

  • オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
  • Velero のオブジェクトストレージを設定する必要があります。

手順

  1. Backup Storage Location の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。

    以下の例を参照してください。

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  2. デフォルト名で Secret カスタムリソース (CR) を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

    Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。

5.7.1.3.5. 異なる認証情報のプロファイルの作成

バックアップとスナップショットの場所で異なる認証情報を使用する場合は、credentials-velero ファイルに個別のプロファイルを作成します。

次に、Secret オブジェクトを作成し、DataProtectionApplication カスタムリソース (CR) でプロファイルを指定します。

手順

  1. 次の例のように、バックアップとスナップショットの場所に別々のプロファイルを持つ credentials-velero ファイルを作成します。

    [backupStorage]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
    
    [volumeSnapshot]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  2. credentials-velero ファイルを使用して Secret オブジェクトを作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero 
    1
  3. 次の例のように、プロファイルを DataProtectionApplication CR に追加します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
            config:
              region: us-east-1
              profile: "backupStorage"
            credential:
              key: cloud
              name: cloud-credentials
      snapshotLocations:
        - velero:
            provider: aws
            config:
              region: us-west-2
              profile: "volumeSnapshot"
5.7.1.3.6. データセキュリティーを強化するための OADP SSE-C 暗号鍵の作成

Amazon Web Services (AWS) S3 に保存されているバックアップデータに暗号化レイヤーを追加するために、お客様提供のキーを使用したサーバー側暗号化 (SSE-C) を設定します。これは、AWS 認証情報が漏洩した場合にバックアップデータを保護します。

Amazon Web Services (AWS) S3 は、Amazon S3 内のすべてのバケットの基本暗号化レベルとして、AWS S3 マネージドキー (SSE-S3) を使用したサーバー側暗号化を適用します。

OpenShift API for Data Protection (OADP) は、クラスターからストレージにデータを転送するときに、SSL/TLS、HTTPS、および velero-repo-credentials シークレットを使用してデータを暗号化します。AWS 認証情報の紛失または盗難に備えてバックアップデータを保護するには、追加の暗号化レイヤーを適用してください。

velero-plugin-for-aws プラグインで、いくつかの追加の暗号化方法を使用できます。プラグインの設定オプションを確認し、追加の暗号化を実装することを検討してください。

お客様提供の鍵を使用したサーバー側暗号化 (SSE-C) を使用することで、独自の暗号鍵を保存できます。この機能は、AWS 認証情報が漏えいした場合に追加のセキュリティーを提供します。

警告

暗号鍵は必ずセキュアな方法で保管してください。暗号鍵がない場合、暗号化されたデータとバックアップを復元できません。

前提条件

  • OADP が /credentials の Velero Pod に SSE-C 鍵を含むシークレットをマウントできるように、AWS のデフォルトのシークレット名 cloud-credentials を使用し、次のラベルの少なくとも 1 つを空のままにします。

注記

次の手順には、認証情報を指定しない spec:backupLocations ブロックの例が含まれています。この例では、OADP シークレットのマウントがトリガーされます。

  • バックアップの場所に cloud-credentials とは異なる名前の認証情報が必要な場合は、次の例のように、認証情報名を含まないスナップショットの場所を追加する必要があります。以下の例には認証情報名が含まれていないため、スナップショットの場所では、スナップショット取得のためのシークレットとして cloud-credentials が使用されます。

     snapshotLocations:
      - velero:
          config:
            profile: default
            region: <region>
          provider: aws
    # ...

手順

  1. SSE-C 暗号鍵を作成します。

    1. 次のコマンドを実行して乱数を生成し、sse.key という名前のファイルとして保存します。

      $ dd if=/dev/urandom bs=1 count=32 > sse.key
  2. OpenShift Container Platform シークレットを作成します。

    • OADP を初めてインストールして設定する場合は、次のコマンドを実行して、AWS 認証情報と暗号鍵シークレットを同時に作成します。

      $ oc create secret generic cloud-credentials --namespace openshift-adp --from-file cloud=<path>/openshift_aws_credentials,customer-key=<path>/sse.key
    • 既存のインストールを更新する場合は、次の例のように、DataProtectionApplication CR マニフェストの cloud-credential secret ブロックの値を編集します。

      apiVersion: v1
      data:
        cloud: W2Rfa2V5X2lkPSJBS0lBVkJRWUIyRkQ0TlFHRFFPQiIKYXdzX3NlY3JldF9hY2Nlc3Nfa2V5P<snip>rUE1mNWVSbTN5K2FpeWhUTUQyQk1WZHBOIgo=
        customer-key: v+<snip>TFIiq6aaXPbj8dhos=
      kind: Secret
      # ...
  3. 次の例のように、DataProtectionApplication CR マニフェストの backupLocations ブロックにある customerKeyEncryptionFile 属性の値を編集します。

    spec:
      backupLocations:
        - velero:
            config:
              customerKeyEncryptionFile: /credentials/customer-key
              profile: default
    # ...
    警告

    既存のインストール環境でシークレットの認証情報を適切に再マウントするには、Velero Pod を再起動する必要があります。

    インストールが完了すると、OpenShift Container Platform リソースをバックアップおよび復元できるようになります。AWS S3 ストレージに保存されるデータは、新しい鍵で暗号化されます。追加の暗号鍵がないと、AWS S3 コンソールまたは API からデータをダウンロードすることはできません。

検証

追加の鍵を含めずに暗号化したファイルをダウンロードできないことを確認するために、テストファイルを作成し、アップロードしてからダウンロードしてみます。

  1. 次のコマンドを実行してテストファイルを作成します。

    $ echo "encrypt me please" > test.txt
  2. 次のコマンドを実行してテストファイルをアップロードします。

    $ aws s3api put-object \
      --bucket <bucket> \
      --key test.txt \
      --body test.txt \
      --sse-customer-key fileb://sse.key \
      --sse-customer-algorithm AES256
  3. ファイルのダウンロードを試みます。Amazon Web コンソールまたはターミナルで、次のコマンドを実行します。

    $ s3cmd get s3://<bucket>/test.txt test.txt

    ファイルが追加の鍵で暗号化されているため、ダウンロードは失敗します。

  4. 次のコマンドを実行して、追加の暗号鍵を含むファイルをダウンロードします。

    $ aws s3api get-object \
        --bucket <bucket> \
        --key test.txt \
        --sse-customer-key fileb://sse.key \
        --sse-customer-algorithm AES256 \
        downloaded.txt
  5. 次のコマンドを実行してファイルの内容を読み取ります。

    $ cat downloaded.txt
    encrypt me please

SSE-C 暗号鍵を検証するときに、Velero によってバックアップされたファイルの追加の暗号鍵を含むファイルをダウンロードすることもできます。

手順

  • 次のコマンドを実行して、Velero によってバックアップされたファイルの追加の暗号鍵を含むファイルをダウンロードします。

    $ aws s3api get-object \
      --bucket <bucket> \
      --key velero/backups/mysql-persistent-customerkeyencryptionfile4/mysql-persistent-customerkeyencryptionfile4.tar.gz \
      --sse-customer-key fileb://sse.key \
      --sse-customer-algorithm AES256 \
      --debug \
      velero_download.tar.gz
5.7.1.4. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials を使用して Secret を作成する必要がある。
  • バックアップとスナップショットの場所で異なる認証情報を使用する場合は、デフォルト名である cloud-credentials を使用して Secret を作成する必要があります。これには、バックアップとスナップショットの場所の認証情報用の個別のプロファイルが含まれます。

    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - openshift
            - aws
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            nodeSelector: <node_selector>
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
            config:
              region: <region>
              profile: "default"
              s3ForcePathStyle: "true"
              s3Url: <s3_url>
            credential:
              key: cloud
              name: cloud-credentials
      snapshotLocations:
        - name: default
          velero:
            provider: aws
            config:
              region: <region>
              profile: "default"
            credential:
              key: cloud
              name: cloud-credentials

    ここでは、以下のようになります。

    namespace
    OADP のデフォルトの名前空間である openshift-adp を指定します。namespace は変数であり、設定可能です。
    openshift
    openshift プラグインが必須であることを指定します。
    リソースタイムアウト
    Velero CRD の可用性、ボリュームスナップショットの削除、バックアップリポジトリーの可用性など、複数の Velero リソースについてタイムアウトが発生するまでの待機時間を分単位で指定します。デフォルトは 10m です。
    ノードエージェント
    管理要求をサーバーにルーティングする管理エージェントを指定します。
    enable
    nodeAgent を有効にして File System Backup を実行する場合は、この値を true に設定します。
    アップローダータイプ
    アップローダーの種類を指定します。アップローダーとして kopia または restic と入力します。インストール後に選択を変更することはできません。組み込み DataMover の場合は、Kopia を使用する必要があります。nodeAgent はデーモンセットをデプロイします。これは、nodeAgent Pod が各ワーキングノード上で実行されることを意味します。File System Backup を設定するには、spec.defaultVolumesToFsBackup: trueBackup CR に追加します。
    nodeSelector
    Kopia または Restic が利用可能なノードを指定します。デフォルトでは、Kopia または Restic はすべてのノードで実行されます。
    bucket
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    prefix
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
    s3ForcePathStyle
    S3 オブジェクトの URL にパス形式を強制するかどうかを指定します (ブール値)。AWS S3 では必要ありません。S3 互換ストレージにのみ必要です。
    s3Url
    バックアップを保存するために使用するオブジェクトストアの URL を指定します。AWS S3 では必要ありません。S3 互換ストレージにのみ必要です。
    name
    作成した シークレット オブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名の cloud-credentials が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。
    snapshotLocations
    CSI スナップショットまたはファイルシステムバックアップ (FSB) を使用して PV をバックアップする場合を除き、スナップショットの場所を指定します。
    region
    スナップショットの場所は、PV と同じリージョン内にある必要があることを指定します。
    name
    作成した シークレット オブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名の cloud-credentials が使用されます。カスタム名を指定すると、スナップショットの場所にカスタム名が使用されます。バックアップとスナップショットの場所で異なる認証情報を使用する場合は、credentials-velero ファイルに個別のプロファイルを作成します。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
5.7.1.4.1. Velero の CPU とメモリーのリソース割り当てを設定

DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • 次の例のように、DataProtectionApplication CR マニフェストの spec.configuration.velero.podConfig.ResourceAllocations ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector>
            resourceAllocations:
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi

    ここでは、以下のようになります。

    nodeSelector
    Velero podSpec に渡すノードセレクターを指定します。
    resourceAllocations

    平均使用量に基づいて割り当てられたリソースを指定します。

    注記

    Kopia は OADP 1.3 以降のリリースで選択できます。Kopia はファイルシステムのバックアップに使用できます。組み込みの Data Mover を使用する Data Mover の場合は、Kopia が唯一の選択肢になります。

    Kopia は Restic よりも多くのリソースを消費するため、それに応じて CPU とメモリーの要件を調整しなければならない場合があります。

nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。

5.7.1.4.2. 自己署名 CA 証明書の有効化

certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • DataProtectionApplication CR マニフェストの spec.backupLocations.velero.objectStorage.caCert パラメーターと spec.backupLocations.velero.config パラメーターを編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string>
            config:
              insecureSkipTLSVerify: "false"
    # ...

    ここでは、以下のようになります。

    caCert
    Base64 エンコードされた CA 証明書文字列を指定します。
    insecureSkipTLSVerify
    insecureSkipTLSVerify の 設定を指定します。設定は true または false のいずれかに設定できます。"true" に設定すると、SSL/TLS セキュリティーが無効になります。"false" に設定すると、SSL/TLS セキュリティーが有効になります。
5.7.1.4.3. Velero デプロイメント用のエイリアス化した velero コマンドで CA 証明書を使用する

Velero CLI のエイリアスを作成することで、システムにローカルにインストールせずに Velero CLI を使用できます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. エイリアス化した Velero コマンドを使用するには、次のコマンドを実行します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
  2. 次のコマンドを実行して、エイリアスが機能していることを確認します。

    $ velero version
    Client:
    	Version: v1.12.1-OADP
    	Git commit: -
    Server:
    	Version: v1.12.1-OADP
  3. このコマンドで CA 証明書を使用するには、次のコマンドを実行して証明書を Velero デプロイメントに追加できます。

    $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
    $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
    $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
  4. バックアップログを取得するために、次のコマンドを実行します。

    $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

    このログを使用して、バックアップできないリソースの障害と警告を表示できます。

  5. Velero Pod が再起動すると、/tmp/your-cacert.txt ファイルが消去されます。そのため、前の手順のコマンドを再実行して /tmp/your-cacert.txt ファイルを再作成する必要があります。
  6. 次のコマンドを実行すると、/tmp/your-cacert.txt ファイルを保存した場所にファイルがまだ存在するかどうかを確認できます。

    $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
    /tmp/your-cacert.txt

    OpenShift API for Data Protection (OADP) の今後のリリースでは、この手順が不要になるように証明書を Velero Pod にマウントする予定です。

5.7.1.4.4. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.7.1.5. MD5 チェックサムアルゴリズムを使用して Backup Storage Location を設定する

Data Protection Application (DPA) の Backup Storage Location (BSL) を設定して、Amazon Simple Storage Service (Amazon S3) と S3 互換ストレージプロバイダーの両方で MD5 チェックサムアルゴリズムを使用できます。チェックサムアルゴリズムは、Amazon S3 へのオブジェクトのアップロードとダウンロードのチェックサムを計算します。DPA の spec.backupLocations.velero.config.checksumAlgorithm セクションの checksumAlgorithm フィールドを設定する際に、次のいずれかのオプションを使用できます。

  • CRC32
  • CRC32C
  • SHA1
  • SHA256

checksumAlgorithm フィールドを空の値に設定して、MD5 チェックサム確認をスキップすることもできます。checksumAlgorithm フィールドに値を設定しなかった場合、デフォルト値として CRC32 が設定されます。

前提条件

  • OADP Operator がインストールされている。
  • バックアップの場所として Amazon S3 または S3 互換のオブジェクトストレージが設定されている。

手順

  • 次の例に示すように、DPA で BSL を設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - name: default
        velero:
          config:
            checksumAlgorithm: ""
            insecureSkipTLSVerify: "true"
            profile: "default"
            region: <bucket_region>
            s3ForcePathStyle: "true"
            s3Url: <bucket_url>
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: aws
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - aws
          - csi

    ここでは、以下のようになります。

    チェックサムアルゴリズム
    チェックサム アルゴリズムを指定します。この例では、checksumAlgorithm フィールドは空の値に設定されています。CRC32CRC32CSHA1SHA256 から選択できます。
    重要

    Noobaa をオブジェクトストレージプロバイダーとして使用しており、DPA で spec.backupLocations.velero.config.checksumAlgorithm フィールドを設定していない場合、checksumAlgorithm の空の値が BSL 設定に追加されます。

    空の値は、DPA を使用して作成された BSL に対してのみ追加されます。他の方法で BSL を作成した場合、この値は追加されません。

5.7.1.6. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.7.1.7. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.7.1.8. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.7.1.9. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.7.1.10. ノードエージェントを非 root および非特権ユーザーとして設定する

ノードエージェントのセキュリティーを強化するには、DataProtectionApplication (DPA) カスタムリソース (CR) の spec.configuration.velero.disableFsBackup 設定を使用して、OADP Operator ノードエージェントデーモンセットを非 root および非特権ユーザーとして実行するように設定できます。

spec.configuration.velero.disableFsBackup 設定を true に設定すると、ノードエージェントのセキュリティーコンテキストによってルートファイルシステムが読み取り専用に設定され、privileged フラグが false に設定されます。

注記

spec.configuration.velero.disableFsBackuptrue に設定すると、特権コンテナーの必要性がなくなり、読み取り専用のルートファイルシステムが適用されるため、ノードエージェントのセキュリティーが強化されます。

ただし、Kopia によるファイルシステムバックアップ (FSB) も無効になります。ワークロードがネイティブスナップショットをサポートしていないボリュームのバックアップに FSB に依存している場合は、disableFsBackup 設定がユースケースに適合するかどうかを評価する必要があります。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の disableFsBackup フィールドを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - csi
          - gcp
          - openshift
          disableFsBackup: true

    ここでは、以下のようになります。

    ノードエージェント
    DPA でノードエージェントを有効にすることを指定します。
    disableFsBackup
    disableFsBackup フィールドを true に設定することを指定します。

検証

  1. 次のコマンドを実行して、ノードエージェントのセキュリティーコンテキストが非 root として実行するように設定され、root ファイルシステムが readOnly あることを確認します。

    $ oc get daemonset node-agent -o yaml

    出力例は次のとおりです。

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      ...
      name: node-agent
      namespace: openshift-adp
      ...
    spec:
      ...
      template:
        metadata:
          ...
        spec:
          containers:
          ...
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                - ALL
              privileged: false
              readOnlyRootFilesystem: true
            ...
          nodeSelector:
            kubernetes.io/os: linux
          os:
            name: linux
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          serviceAccount: velero
          serviceAccountName: velero
          ....

    ここでは、以下のようになります。

    allowPrivilegeEscalation
    allowPrivilegeEscalation フィールドが false であることを指定します。
    privileged
    特権 フィールドが false であることを指定します。
    readOnlyRootFilesystem
    ルートファイルシステムが読み取り専用であることを指定します。
    runAsNonRoot
    ノードエージェントを非 root ユーザーとして実行することを指定します。
5.7.1.11. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.7.1.12. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.7.1.13. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.7.1.14. DataProtectionApplication CR で CSI を有効にする

CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。

手順

  • 次の例のように、DataProtectionApplication CR を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi

    ここでは、以下のようになります。

    csi
    CSI の デフォルトプラグインを指定します。
5.7.1.15. DataProtectionApplication でノードエージェントを無効にする

バックアップに ResticKopia、または DataMover を使用していない場合は、DataProtectionApplication カスタムリソース (CR) の nodeAgent フィールドを無効にすることができます。nodeAgent を無効にする前に、OADP Operator がアイドル状態であり、バックアップを実行していないことを確認してください。

手順

  1. nodeAgent を無効にするには、enable フラグを false に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: false
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にします。
  2. nodeAgent を有効にするには、enable フラグを true に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable

    ノードエージェントを有効にします。

    ジョブをセットアップして、DataProtectionApplication CR の nodeAgent フィールドを有効または無効にすることができます。詳細は、「ジョブの使用による Pod でのタスクの実行」を参照してください。

5.8. IBM Cloud を使用した OADP の設定

5.8.1. IBM Cloud を使用した OpenShift API for Data Protection の設定

クラスター上のアプリケーションをバックアップおよび復元するには、IBM Cloud クラスターに OpenShift API for Data Protection (OADP) Operator をインストールします。バックアップを保存するには、IBM Cloud Object Storage (COS) を設定します。

5.8.1.1. COS インスタンスの設定

OADP バックアップデータを保存するために、IBM Cloud Object Storage (COS) インスタンスを作成します。COS インスタンスを作成したら、HMAC サービス認証情報を設定します。

前提条件

  • IBM Cloud Platform アカウントをもっている。
  • IBM Cloud CLI をインストールしている。
  • IBM Cloud にログインしている。

手順

  1. 次のコマンドを実行して、IBM Cloud Object Storage (COS) プラグインをインストールします。

    $ ibmcloud plugin install cos -f
  2. 次のコマンドを実行してバケット名を設定します。

    $ BUCKET=<bucket_name>
  3. 次のコマンドを実行してバケットリージョンを設定します。

    $ REGION=<bucket_region>

    ここでは、以下のようになります。

    <bucket_region>
    バケットリージョンを指定します。たとえば、eu-gb
  4. 次のコマンドを実行してリソースグループを作成します。

    $ ibmcloud resource group-create <resource_group_name>
  5. 次のコマンドを実行して、ターゲットリソースグループを設定します。

    $ ibmcloud target -g <resource_group_name>
  6. 次のコマンドを実行して、ターゲットリソースグループが正しく設定されていることを確認します。

    $ ibmcloud target

    出力例

    API endpoint:     https://cloud.ibm.com
    Region:
    User:             test-user
    Account:          Test Account (fb6......e95) <-> 2...122
    Resource group:   Default

    出力例では、リソースグループは Default に設定されています。

  7. 次のコマンドを実行してリソースグループ名を設定します。

    $ RESOURCE_GROUP=<resource_group>

    ここでは、以下のようになります。

    < リソースグループ >
    リソースグループ名を指定します。たとえば、default
  8. 次のコマンドを実行して、IBM Cloud service-instance リソースを作成します。

    $ ibmcloud resource service-instance-create \
    <service_instance_name> \
    <service_name> \
    <service_plan> \
    <region_name>

    ここでは、以下のようになります。

    < サービスインスタンス名 >
    サービスインスタンス リソースの名前を指定します。
    < サービス名 >
    サービス名を指定します。または、サービス ID を指定することもできます。
    < サービスプラン >
    IBM Cloud アカウントのサービスプランを指定します。
    < 地域名 >
    リージョン名を指定します。

    以下のコマンド例を参照してください。

    $ ibmcloud resource service-instance-create test-service-instance cloud-object-storage \
    standard \
    global \
    -d premium-global-deployment

    ここでは、以下のようになります。

    クラウドオブジェクトストレージ
    サービス名を指定します。
    -d プレミアムグローバルデプロイメント
    デプロイメント名を指定します。
  9. 次のコマンドを実行して、サービスインスタンス ID を抽出します。

    $ SERVICE_INSTANCE_ID=$(ibmcloud resource service-instance test-service-instance --output json | jq -r '.[0].id')
  10. 次のコマンドを実行して COS バケットを作成します。

    $ ibmcloud cos bucket-create \
    --bucket $BUCKET \
    --ibm-service-instance-id $SERVICE_INSTANCE_ID \
    --region $REGION

    $BUCKET$SERVICE_INSTANCE_ID$REGION などの変数は、以前に設定した値に置き換えられます。

  11. 次のコマンドを実行して HMAC 認証情報を作成します。

    $ ibmcloud resource service-key-create test-key Writer --instance-name test-service-instance --parameters {\"HMAC\":true}
  12. HMAC 認証情報からアクセスキー ID とシークレットアクセスキーを抽出し、credentials-velero ファイルに保存します。credentials-velero ファイルを使用して、Backup Storage Location の secret を作成できます。以下のコマンドを実行します。

    $ cat > credentials-velero << __EOF__
    [default]
    aws_access_key_id=$(ibmcloud resource service-key test-key -o json  | jq -r '.[0].credentials.cos_hmac_keys.access_key_id')
    aws_secret_access_key=$(ibmcloud resource service-key test-key -o json  | jq -r '.[0].credentials.cos_hmac_keys.secret_access_key')
    __EOF__
5.8.1.2. デフォルト Secret の作成

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

注記

DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。

インストール時にバックアップ場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用して、デフォルト名の Secret を作成できます。

前提条件

  • オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
  • Velero のオブジェクトストレージを設定する必要があります。

手順

  1. Backup Storage Location の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。
  2. デフォルト名で Secret カスタムリソース (CR) を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

    Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。

5.8.1.3. 異なる認証情報のシークレットの作成

バックアップ先とスナップショット先で異なる認証情報が必要な場合は、それぞれ別の シークレット オブジェクトを作成してください。これにより、安全な認証情報管理を維持しながら、ストレージの場所ごとに個別の認証を設定できます。

手順

  1. スナップショットの場所の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。
  2. デフォルト名でスナップショットの場所の Secret を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. オブジェクトストレージに適した形式で、バックアップロケーションの credentials-velero ファイルを作成します。
  4. カスタム名を使用してバックアップロケーションの Secret を作成します。

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 次の例のように、カスタム名の SecretDataProtectionApplication に追加します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            provider: <provider>
            default: true
            credential:
              key: cloud
              name: <custom_secret>
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>

    ここでは、以下のようになります。

    カスタムシークレット
    バックアップ場所を指定する Secret に、カスタム名を指定します。
5.8.1.4. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials を使用して Secret を作成する必要がある。

    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      namespace: openshift-adp
      name: <dpa_name>
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - aws
          - csi
      backupLocations:
        - velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            config:
              insecureSkipTLSVerify: 'true'
              profile: default
              region: <region_name>
              s3ForcePathStyle: 'true'
              s3Url: <s3_url>
            credential:
              key: cloud
              name: cloud-credentials

    ここでは、以下のようになります。

    provider
    IBM Cloud をバックアップストレージの場所として使用する場合に、プロバイダーが aws であることを指定します。
    bucket
    IBM Cloud Object Storage (COS) バケット名を指定します。
    region
    COS リージョン名を指定します。例: eu-gb
    s3Url
    COS バケットの S3 URL を指定します。たとえば、http://s3.eu-gb.cloud-object-storage.appdomain.cloud です。ここで、eu-gb はリージョン名です。バケットのリージョンに応じてリージョン名を置き換えます。
    name
    HMAC 認証情報に含まれるアクセスキーとシークレットアクセスキーを使用して作成したシークレットの名前を指定します。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
5.8.1.5. Velero の CPU とメモリーのリソース割り当てを設定

DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • 次の例のように、DataProtectionApplication CR マニフェストの spec.configuration.velero.podConfig.ResourceAllocations ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector>
            resourceAllocations:
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi

    ここでは、以下のようになります。

    nodeSelector
    Velero podSpec に渡すノードセレクターを指定します。
    resourceAllocations

    平均使用量に基づいて割り当てられたリソースを指定します。

    注記

    Kopia は OADP 1.3 以降のリリースで選択できます。Kopia はファイルシステムのバックアップに使用できます。組み込みの Data Mover を使用する Data Mover の場合は、Kopia が唯一の選択肢になります。

    Kopia は Restic よりも多くのリソースを消費するため、それに応じて CPU とメモリーの要件を調整しなければならない場合があります。

5.8.1.6. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.8.1.7. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.8.1.8. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.8.1.9. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.8.1.10. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.8.1.11. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.8.1.12. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.8.1.13. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.8.1.14. 複数の BSL を使用した DPA の設定

プロバイダー固有の認証情報を使用して、複数の BackupStorageLocation (BSL) リソースを使用して DataProtectionApplication (DPA) カスタムリソース (CR) を設定し、バックアップを異なる場所に保存します。これにより、バックアップの配布機能と、場所に応じた復元機能が提供されます。

たとえば、以下の 2 つの BSL を設定済みだとします。

  • DPA に 1 つの BSL を設定し、それをデフォルトの BSL として設定した。
  • BackupStorageLocation CR を使用して、別の BSL を別途作成した。

DPA を通じて作成された BSL をすでにデフォルトとして設定しているため、別途作成した BSL を再度デフォルトとして設定することはできません。つまり、任意の時点において、デフォルトの BSL として設定できる BSL は 1 つだけです。

前提条件

  • OADP Operator をインストールする。
  • クラウドプロバイダーによって提供される認証情報を使用してシークレットを作成する。

手順

  1. 複数の BackupStorageLocation CR を使用して DataProtectionApplication CR を設定します。以下の例を参照してください。

    DPA の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    backupLocations:
      - name: aws
        velero:
          provider: aws
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            region: <region_name>
            profile: "default"
          credential:
            key: cloud
            name: cloud-credentials
      - name: odf
        velero:
          provider: aws
          default: false
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            profile: "default"
            region: <region_name>
            s3Url: <url>
            insecureSkipTLSVerify: "true"
            s3ForcePathStyle: "true"
          credential:
            key: cloud
            name: <custom_secret_name_odf>
    #...

    ここでは、以下のようになります。

    名前: aws
    最初の BSL の名前を指定します。
    デフォルト: true
    この BSL がデフォルトの BSL であることを示します。Backup CR に BSL が設定されていない場合は、デフォルトの BSL が使用されます。デフォルトとして設定できる BSL は 1 つだけです。
    <bucket_name>
    バケット名を指定します。
    <prefix>
    Velero バックアップのプレフィックスを指定します。たとえば、velero
    < 地域名 >
    バケットの AWS リージョンを指定します。
    クラウド認証情報
    作成したデフォルトの Secret オブジェクトの名前を指定します。
    名前: odf
    2 番目の BSL の名前を指定します。
    <url>
    S3 エンドポイントの URL を指定します。
    <custom_secret_name_odf>
    シークレット の正しい名前を指定します。たとえば、custom_secret_name_odfSecret 名を指定しない場合は、デフォルトの名前が使用されます。
  2. バックアップ CR で使用する BSL を指定します。以下の例を参照してください。

    バックアップ CR の例

    apiVersion: velero.io/v1
    kind: Backup
    # ...
    spec:
      includedNamespaces:
      - <namespace>
      storageLocation: <backup_storage_location>
      defaultVolumesToFsBackup: true

    ここでは、以下のようになります。

    <namespace>
    バックアップする名前空間を指定します。
    < バックアップストレージの場所 >
    保存場所を指定します。
5.8.1.15. DataProtectionApplication でノードエージェントを無効にする

バックアップに ResticKopia、または DataMover を使用していない場合は、DataProtectionApplication カスタムリソース (CR) の nodeAgent フィールドを無効にすることができます。nodeAgent を無効にする前に、OADP Operator がアイドル状態であり、バックアップを実行していないことを確認してください。

手順

  1. nodeAgent を無効にするには、enable フラグを false に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: false
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にします。
  2. nodeAgent を有効にするには、enable フラグを true に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable

    ノードエージェントを有効にします。

    ジョブをセットアップして、DataProtectionApplication CR の nodeAgent フィールドを有効または無効にすることができます。詳細は、「ジョブの使用による Pod でのタスクの実行」を参照してください。

5.9. Azure を使用した OADP の設定

5.9.1. Microsoft Azure を使用した OpenShift API for Data Protection の設定

Microsoft Azure と連携して OpenShift API for Data Protection (OADP) を設定し、Azure ストレージを使用してクラスターリソースのバックアップと復元を行います。これにより、OpenShift Container Platform クラスターのデータ保護機能が提供されます。

OADP Operator は Velero 1.16 をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

Velero 用に Azure を設定し、デフォルトの Secret を作成してから、Data Protection Application をインストールします。詳細は、OADP Operator のインストール を参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。詳細は、非接続環境での Operator Lifecycle Manager の使用 を参照してください。

5.9.1.1. Microsoft Azure の設定

OADP を使用して、バックアップストレージ用の Microsoft Azure ストレージとサービスプリンシパルの認証情報を設定します。これにより、データ保護業務に必要な認証およびストレージインフラストラクチャーが提供されます。

前提条件

  • Azure CLI がインストールされていること。

Azure サービスを使用するツールには、Azure リソースの安全を確保するために、必ず制限された権限を付与する必要があります。そのため、Azure では、アプリケーションを完全な権限を持つユーザーとしてサインインさせる代わりに、サービスプリンシパルを提供しています。Azure サービスプリンシパルは、アプリケーション、ホストされたサービス、または自動化ツールで使用できる名前です。

このアイデンティティーはリソースへのアクセスに使用されます。

  • サービスプリンシパルを作成する
  • サービスプリンシパルとパスワードを使用してサインインする
  • サービスプリンシパルと証明書を使用してサインインする
  • サービスプリンシパルのロールを管理する
  • サービスプリンシパルを使用して Azure リソースを作成する
  • サービスプリンシパルの認証情報をリセットする

詳細は、Create an Azure service principal with Azure CLI を参照してください。

手順

  1. Azure にログインします。

    $ az login
  2. AZURE_RESOURCE_GROUP 変数を設定します。

    $ AZURE_RESOURCE_GROUP=Velero_Backups
  3. Azure リソースグループを作成します。

    $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS

    ここでは、以下のようになります。

    米国中部
    現在地を指定します。
  4. AZURE_STORAGE_ACCOUNT_ID 変数を設定します。

    $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
  5. Azure ストレージアカウントを作成します。

    $ az storage account create \
        --name $AZURE_STORAGE_ACCOUNT_ID \
        --resource-group $AZURE_RESOURCE_GROUP \
        --sku Standard_GRS \
        --encryption-services blob \
        --https-only true \
        --kind BlobStorage \
        --access-tier Hot
  6. BLOB_CONTAINER 変数を設定します。

    $ BLOB_CONTAINER=velero
  7. Azure Blob ストレージコンテナーを作成します。

    $ az storage container create \
      -n $BLOB_CONTAINER \
      --public-access off \
      --account-name $AZURE_STORAGE_ACCOUNT_ID
  8. velero のサービスプリンシパルおよび認証情報を作成します。

    $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv`
      AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv`
  9. 特定の --role--scopes を割り当てて、Contributor ロールを持つサービスプリンシパルを作成します。

    $ AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
                                                    --role "Contributor" \
                                                    --query 'password' -o tsv \
                                                    --scopes /subscriptions/$AZURE_SUBSCRIPTION_ID/resourceGroups/$AZURE_RESOURCE_GROUP`

    CLI によってパスワードが生成されます。パスワードを必ず記録してください。

  10. サービスプリンシパルを作成したら、クライアント ID を取得します。

    $ AZURE_CLIENT_ID=`az ad app credential list --id <your_app_id>`
    注記

    これを成功させるには、Azure アプリケーション ID を把握している必要があります。

  11. サービスプリンシパルの認証情報を credentials-velero ファイルに保存します。

    $ cat << EOF > ./credentials-velero
    AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
    AZURE_TENANT_ID=${AZURE_TENANT_ID}
    AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
    AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
    AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
    AZURE_CLOUD_NAME=AzurePublicCloud
    EOF

    credentials-velero ファイルを使用して、Azure をレプリケーションリポジトリーとして追加します。

5.9.1.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて

DataProtectionApplication カスタムリソース (CR) のバックアップ場所、スナップショット場所、およびシークレット設定要件を確認してください。これは、データ保護業務におけるストレージオプションと認証情報管理を理解するのに役立ちます。

5.9.1.2.1. バックアップの場所

バックアップの場所として、次のいずれかの AWS S3 互換オブジェクトストレージソリューションを指定できます。

  • Multicloud Object Gateway (MCG)
  • Red Hat Container Storage
  • Ceph RADOS Gateway (別称 Ceph Object Gateway)
  • Red Hat OpenShift Data Foundation
  • MinIO

Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。

5.9.1.2.2. スナップショットの場所

クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。

Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。

File System Backup (FSB) を使用する場合、FSB がオブジェクトストレージ上にファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。

5.9.1.2.3. シークレット

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。

  • DataProtectionApplication CR で指定する、バックアップの場所用のカスタム Secret
  • DataProtectionApplication CR で参照されない、スナップショットの場所用のデフォルト Secret
重要

Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。

インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。

5.9.1.3. Azure での OADP の認証について

Azure を使用した OADP の認証方法を確認し、セキュリティー要件に適した認証方法を選択してください。

Azure で OADP を認証するには、次の方法を使用できます。

  • シークレットベースの認証を使用する Velero 専用のサービスプリンシパル
  • シークレットベースの認証を使用する Velero 専用のストレージアカウントアクセスキー
  • Azure Security Token Service
5.9.1.4. サービスプリンシパルまたはストレージアカウントアクセスキーを使用する

デフォルトの Secret オブジェクトを作成し、Backup Storage Location のカスタムリソースでそれを参照します。Secret オブジェクトの認証情報ファイルには、Azure サービスプリンシパルまたはストレージアカウントアクセスキーに関する情報を含めることができます。

Secret のデフォルト名は cloud-credentials-azure です。

注記

DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。

インストール時にバックアップ場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用して、デフォルト名の Secret を作成できます。

前提条件

  • cluster-admin 特権を持つユーザーとして OpenShift クラスターにアクセスできる。
  • 適切な権限が付与された Azure サブスクリプションがある。
  • OADP をインストールした。
  • バックアップを保存するためのオブジェクトストレージを設定した。

手順

  1. Backup Storage Location の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。

    Azure で OADP を認証するには、次の 2 つの方法のいずれかを使用できます。

    • シークレットベースの認証でサービスプリンシパルを使用します。以下の例を参照してください。

      AZURE_SUBSCRIPTION_ID=<azure_subscription_id>
      AZURE_TENANT_ID=<azure_tenant_id>
      AZURE_CLIENT_ID=<azure_client_id>
      AZURE_CLIENT_SECRET=<azure_client_secret>
      AZURE_RESOURCE_GROUP=<azure_resource_group>
      AZURE_CLOUD_NAME=<azure_cloud_name>
    • ストレージアカウントアクセスキーを使用します。以下の例を参照してください。

      AZURE_STORAGE_ACCOUNT_ACCESS_KEY=<azure_storage_account_access_key>
      AZURE_SUBSCRIPTION_ID=<azure_subscription_id>
      AZURE_RESOURCE_GROUP=<azure_resource_group>
      AZURE_CLOUD_NAME=<azure_cloud_name>
  2. デフォルト名で Secret カスタムリソース (CR) を作成します。

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
  3. 次の例に示すように、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.velero.credential ブロック内の Secret を参照します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              storageAccount: <azure_storage_account_id>
              subscriptionId: <azure_subscription_id>
            credential:
              key: cloud
              name: <custom_secret>
            provider: azure
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
      snapshotLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              subscriptionId: <azure_subscription_id>
              incremental: "true"
            provider: azure

    ここでは、以下のようになります。

    <custom_secret>
    バックアップ場所を指定する Secret に、カスタム名を指定します。
5.9.1.5. Azure Security Token Service 認証で OADP を使用する

Microsoft Entra Workload ID を使用して、OADP バックアップおよび復元操作のために Azure ストレージにアクセスできます。この方法では、OpenShift クラスターの署名済み Kubernetes サービスアカウントトークンを使用します。このトークンは 1 時間ごとに自動的にローテーションされ、Azure Active Directory (AD) アクセストークンと交換されるため、長期的なクライアントシークレットが不要になります。

Azure Security Token Service (STS) 設定を使用するには、クラスターのインストール時に credentialsMode フィールドを Manual に設定する必要があります。この方法では、Cloud Credential Operator (ccoctl) を使用して、OpenID Connect (OIDC) プロバイダー、発行者設定、ユーザー割り当てマネージド ID などのワークロードアイデンティティーインフラストラクチャーをセットアップします。

注記

Azure STS 設定の OADP は、静的 ファイルシステムバックアップ (FSB) および復元をサポートしていません。

前提条件

  • Microsoft Entra Workload ID が設定された OpenShift クラスターが Microsoft Azure にインストールされている。詳細は、短期認証情報を使用するように Azure クラスターを設定する を参照してください。
  • Azure CLI (az) がインストールおよび設定されている。
  • cluster-admin 特権を持つユーザーとして OpenShift クラスターにアクセスできる。
  • 適切な権限が付与された Azure サブスクリプションがある。
注記

OpenShift クラスターが元から Microsoft Entra Workload ID を使用してインストールされていなかった場合は、インストール後に短期認証情報を有効にできます。このインストール後の設定がサポートされているのは、Azure クラスターだけです。

手順

  1. 長期認証情報を使用してクラスターをインストールした場合は、インストール後に Microsoft Entra Workload ID 認証に切り替えることができます。詳細は、既存のクラスターで Microsoft Entra Workload ID を有効にする を参照してください。

    重要

    既存の Azure クラスターで Microsoft Entra Workload ID を有効にした後、OADP を含め、クラウド認証情報を使用するすべてのクラスターコンポーネントを、新しい認証方法を使用するように更新する必要があります。

  2. 次の例に示すように、Azure STS 設定の環境変数を設定します。

    export API_URL=$(oc whoami --show-server) # Get cluster information
    export CLUSTER_NAME=$(echo "$API_URL" | sed 's|https://api\.||' | sed 's|\..*||')
    export CLUSTER_RESOURCE_GROUP="${CLUSTER_NAME}-rg"
    
    # Get Azure information
    export AZURE_SUBSCRIPTION_ID=$(az account show --query id -o tsv)
    export AZURE_TENANT_ID=$(az account show --query tenantId -o tsv)
    
    # Set names for resources
    export IDENTITY_NAME="velero"
    export APP_NAME="velero-${CLUSTER_NAME}"
    export STORAGE_ACCOUNT_NAME=$(echo "velero${CLUSTER_NAME}" | tr -d '-' | tr '[:upper:]' '[:lower:]' | cut -c1-24)
    export CONTAINER_NAME="velero"
  3. 次の例に示すように、OADP 用の Azure マネージド ID を作成します。

    az identity create \ # Create managed identity
        --subscription "$AZURE_SUBSCRIPTION_ID" \
        --resource-group "$CLUSTER_RESOURCE_GROUP" \
        --name "$IDENTITY_NAME"
    
    # Get identity details
    export IDENTITY_CLIENT_ID=$(az identity show -g "$CLUSTER_RESOURCE_GROUP" -n "$IDENTITY_NAME" --query clientId -o tsv)
    export IDENTITY_PRINCIPAL_ID=$(az identity show -g "$CLUSTER_RESOURCE_GROUP" -n "$IDENTITY_NAME" --query principalId -o tsv)
  4. 次の例に示すように、必要な Azure ロールをマネージド ID に付与します。

    export SUBSCRIPTION_ID=$(az account show --query id -o tsv) # Get subscription ID for role assignments
    
    # Required roles for OADP operations
    REQUIRED_ROLES=(
        "Contributor"
        "Storage Blob Data Contributor"
        "Disk Snapshot Contributor"
    )
    
    for role in "${REQUIRED_ROLES[@]}"; do
        echo "Assigning role: $role"
        az role assignment create \
            --assignee "$IDENTITY_PRINCIPAL_ID" \
            --role "$role" \
            --scope "/subscriptions/$SUBSCRIPTION_ID"
    done
  5. 次の例に示すように、Azure ストレージアカウントとコンテナーを作成します。

    az storage account create \ # Create storage account
        --name "$STORAGE_ACCOUNT_NAME" \
        --resource-group "$CLUSTER_RESOURCE_GROUP" \
        --location "$(az group show -n $CLUSTER_RESOURCE_GROUP --query location -o tsv)" \
        --sku Standard_LRS \
        --kind StorageV2
  6. 次の例に示すように、OpenShift クラスターから OIDC 発行者の URL を取得します。

    export SERVICE_ACCOUNT_ISSUER=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer)
    echo "OIDC Issuer: $SERVICE_ACCOUNT_ISSUER"
  7. 次の例に示すように、Microsoft Entra Workload ID Federation を設定します。

    az identity federated-credential create \ # Create federated identity credential for Velero service account
        --name "velero-federated-credential" \
        --identity-name "$IDENTITY_NAME" \
        --resource-group "$CLUSTER_RESOURCE_GROUP" \
        --issuer "$SERVICE_ACCOUNT_ISSUER" \
        --subject "system:serviceaccount:openshift-adp:velero" \
        --audiences "openshift"
    
    # Create federated identity credential for OADP controller manager
    az identity federated-credential create \
        --name "oadp-controller-federated-credential" \
        --identity-name "$IDENTITY_NAME" \
        --resource-group "$CLUSTER_RESOURCE_GROUP" \
        --issuer "$SERVICE_ACCOUNT_ISSUER" \
        --subject "system:serviceaccount:openshift-adp:openshift-adp-controller-manager" \
        --audiences "openshift"
  8. OADP の namespace が存在しない場合は、次のコマンドを実行して作成します。

    oc create namespace openshift-adp
  9. CloudStorage CR を使用して Azure クラウドストレージリソースを作成するには、次のコマンドを実行します。

    cat <<EOF | oc apply -f -
    apiVersion: oadp.openshift.io/v1alpha1
    kind: CloudStorage
    metadata:
      name: azure-backup-storage
      namespace: openshift-adp
    spec:
      name: ${CONTAINER_NAME}
      provider: azure
      creationSecret:
        name: cloud-credentials-azure
        key: azurekey
      config:
        storageAccount: ${STORAGE_ACCOUNT_NAME}
    EOF
  10. 次の例に示すように、DataProtectionApplication (DPA) カスタムリソース (CR) を作成し、Azure STS の詳細を設定します。

    cat <<EOF | oc apply -f -
    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: dpa-azure-workload-id-cloudstorage
      namespace: openshift-adp
    spec:
      backupLocations:
      - bucket:
          cloudStorageRef:
            name: <cloud_storage_cr>
          config:
            storageAccount: <storage_account_name>
            useAAD: "true"
          credential:
            key: azurekey
            name: cloud-credentials-azure
          default: true
          prefix: velero
        name: default
      configuration:
        velero:
          defaultPlugins:
          - azure
          - openshift
          - csi
          disableFsBackup: false
      logFormat: text
      snapshotLocations:
      - name: default
        velero:
          config:
            resourceGroup: <resource_group>
            subscriptionId: <subscription_ID>
          credential:
            key: azurekey
            name: cloud-credentials-azure
          provider: azure
    EOF

    ここでは、以下のようになります。

    <cloud_storage_cr>
    CloudStorage CR 名を指定します。
    < ストレージアカウント名 >
    Azure ストレージアカウント名を指定します。
    < リソースグループ >
    リソースグループを指定します。
    <subscription_ID>
    サブスクリプション ID を指定します。

検証

  1. OADP Operator Pod が実行されていることを確認します。

    $ oc get pods -n openshift-adp
  2. Azure ロールの割り当てを確認します。

    az role assignment list --assignee ${IDENTITY_PRINCIPAL_ID} --all --query "[].roleDefinitionName" -o tsv
  3. Microsoft Entra Workload ID 認証を確認します。

    $ VELERO_POD=$(oc get pods -n openshift-adp -l app.kubernetes.io/name=velero -o jsonpath='{.items[0].metadata.name}') # Check Velero pod environment variables
    
    # Check AZURE_CLIENT_ID environment variable
    $ oc get pod ${VELERO_POD} -n openshift-adp -o jsonpath='{.spec.containers[0].env[?(@.name=="AZURE_CLIENT_ID")]}'
    
    # Check AZURE_FEDERATED_TOKEN_FILE environment variable
    $ oc get pod ${VELERO_POD} -n openshift-adp -o jsonpath='{.spec.containers[0].env[?(@.name=="AZURE_FEDERATED_TOKEN_FILE")]}'
  4. アプリケーションのバックアップを作成し、バックアップが Azure ストレージに正常に保存されていることを確認します。
5.9.1.6. Velero の CPU とメモリーのリソース割り当てを設定

DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • 次の例のように、DataProtectionApplication CR マニフェストの spec.configuration.velero.podConfig.ResourceAllocations ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector>
            resourceAllocations:
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi

    ここでは、以下のようになります。

    nodeSelector
    Velero podSpec に渡すノードセレクターを指定します。
    resourceAllocations

    平均使用量に基づいて割り当てられたリソースを指定します。

    注記

    Kopia は OADP 1.3 以降のリリースで選択できます。Kopia はファイルシステムのバックアップに使用できます。組み込みの Data Mover を使用する Data Mover の場合は、Kopia が唯一の選択肢になります。

    Kopia は Restic よりも多くのリソースを消費するため、それに応じて CPU とメモリーの要件を調整しなければならない場合があります。

nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。

5.9.1.7. 自己署名 CA 証明書の有効化

certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • DataProtectionApplication CR マニフェストの spec.backupLocations.velero.objectStorage.caCert パラメーターと spec.backupLocations.velero.config パラメーターを編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string>
            config:
              insecureSkipTLSVerify: "false"
    # ...

    ここでは、以下のようになります。

    caCert
    Base64 エンコードされた CA 証明書文字列を指定します。
    insecureSkipTLSVerify
    insecureSkipTLSVerify の 設定を指定します。設定は true または false のいずれかに設定できます。"true" に設定すると、SSL/TLS セキュリティーが無効になります。"false" に設定すると、SSL/TLS セキュリティーが有効になります。
5.9.1.8. Velero デプロイメント用のエイリアス化した velero コマンドで CA 証明書を使用する

Velero CLI のエイリアスを作成することで、システムにローカルにインストールせずに Velero CLI を使用できます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. エイリアス化した Velero コマンドを使用するには、次のコマンドを実行します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
  2. 次のコマンドを実行して、エイリアスが機能していることを確認します。

    $ velero version
    Client:
    	Version: v1.12.1-OADP
    	Git commit: -
    Server:
    	Version: v1.12.1-OADP
  3. このコマンドで CA 証明書を使用するには、次のコマンドを実行して証明書を Velero デプロイメントに追加できます。

    $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
    $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
    $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
  4. バックアップログを取得するために、次のコマンドを実行します。

    $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

    このログを使用して、バックアップできないリソースの障害と警告を表示できます。

  5. Velero Pod が再起動すると、/tmp/your-cacert.txt ファイルが消去されます。そのため、前の手順のコマンドを再実行して /tmp/your-cacert.txt ファイルを再作成する必要があります。
  6. 次のコマンドを実行すると、/tmp/your-cacert.txt ファイルを保存した場所にファイルがまだ存在するかどうかを確認できます。

    $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
    /tmp/your-cacert.txt

    OpenShift API for Data Protection (OADP) の今後のリリースでは、この手順が不要になるように証明書を Velero Pod にマウントする予定です。

5.9.1.9. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials-azure を使用して Secret を作成する必要がある。
  • バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの Secrets を作成する必要がある。

    • バックアップの場所用のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    • スナップショットの場所用の別のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - azure
            - openshift
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            nodeSelector: <node_selector>
      backupLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              storageAccount: <azure_storage_account_id>
              subscriptionId: <azure_subscription_id>
            credential:
              key: cloud
              name: cloud-credentials-azure
            provider: azure
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
      snapshotLocations:
        - velero:
            config:
              resourceGroup: <azure_resource_group>
              subscriptionId: <azure_subscription_id>
              incremental: "true"
            name: default
            provider: azure
            credential:
              key: cloud
              name: cloud-credentials-azure

    ここでは、以下のようになります。

    namespace
    OADP のデフォルトの名前空間である openshift-adp を指定します。namespace は変数であり、設定可能です。
    openshift
    openshift プラグインが必須であることを指定します。
    リソースタイムアウト
    Velero CRD の可用性、ボリュームスナップショットの削除、バックアップリポジトリーの可用性など、複数の Velero リソースについてタイムアウトが発生するまでの待機時間を分単位で指定します。デフォルトは 10m です。
    ノードエージェント
    管理要求をサーバーにルーティングする管理エージェントを指定します。
    enable
    nodeAgent を有効にして File System Backup を実行する場合は、この値を true に設定します。
    アップローダータイプ
    アップローダーの種類を指定します。アップローダーとして kopia または restic と入力します。インストール後に選択を変更することはできません。組み込み DataMover の場合は、Kopia を使用する必要があります。nodeAgent はデーモンセットをデプロイします。これは、nodeAgent Pod が各ワーキングノード上で実行されることを意味します。File System Backup を設定するには、spec.defaultVolumesToFsBackup: trueBackup CR に追加します。
    nodeSelector
    Kopia または Restic が利用可能なノードを指定します。デフォルトでは、Kopia または Restic はすべてのノードで実行されます。
    resourceGroup
    Azure リソースグループを指定します。
    ストレージアカウント
    Azure ストレージアカウント ID を指定します。
    subscriptionId
    Azure サブスクリプション ID を指定します。
    name
    Secret オブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名の cloud-credentials-azure が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。
    bucket
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    prefix
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
    snapshotLocations
    スナップショットの保存場所を指定します。CSI スナップショットまたは Restic を使用して PV をバックアップする場合は、スナップショットの場所を指定する必要はありません。
    name
    作成した シークレット オブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名の cloud-credentials-azure が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
5.9.1.10. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.9.1.11. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.9.1.12. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.9.1.13. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.9.1.14. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.9.1.15. ノードエージェントを非 root および非特権ユーザーとして設定する

ノードエージェントのセキュリティーを強化するには、DataProtectionApplication (DPA) カスタムリソース (CR) の spec.configuration.velero.disableFsBackup 設定を使用して、OADP Operator ノードエージェントデーモンセットを非 root および非特権ユーザーとして実行するように設定できます。

spec.configuration.velero.disableFsBackup 設定を true に設定すると、ノードエージェントのセキュリティーコンテキストによってルートファイルシステムが読み取り専用に設定され、privileged フラグが false に設定されます。

注記

spec.configuration.velero.disableFsBackuptrue に設定すると、特権コンテナーの必要性がなくなり、読み取り専用のルートファイルシステムが適用されるため、ノードエージェントのセキュリティーが強化されます。

ただし、Kopia によるファイルシステムバックアップ (FSB) も無効になります。ワークロードがネイティブスナップショットをサポートしていないボリュームのバックアップに FSB に依存している場合は、disableFsBackup 設定がユースケースに適合するかどうかを評価する必要があります。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の disableFsBackup フィールドを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - csi
          - gcp
          - openshift
          disableFsBackup: true

    ここでは、以下のようになります。

    ノードエージェント
    DPA でノードエージェントを有効にすることを指定します。
    disableFsBackup
    disableFsBackup フィールドを true に設定することを指定します。

検証

  1. 次のコマンドを実行して、ノードエージェントのセキュリティーコンテキストが非 root として実行するように設定され、root ファイルシステムが readOnly あることを確認します。

    $ oc get daemonset node-agent -o yaml

    出力例は次のとおりです。

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      ...
      name: node-agent
      namespace: openshift-adp
      ...
    spec:
      ...
      template:
        metadata:
          ...
        spec:
          containers:
          ...
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                - ALL
              privileged: false
              readOnlyRootFilesystem: true
            ...
          nodeSelector:
            kubernetes.io/os: linux
          os:
            name: linux
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          serviceAccount: velero
          serviceAccountName: velero
          ....

    ここでは、以下のようになります。

    allowPrivilegeEscalation
    allowPrivilegeEscalation フィールドが false であることを指定します。
    privileged
    特権 フィールドが false であることを指定します。
    readOnlyRootFilesystem
    ルートファイルシステムが読み取り専用であることを指定します。
    runAsNonRoot
    ノードエージェントを非 root ユーザーとして実行することを指定します。
5.9.1.16. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.9.1.17. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.9.1.18. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.9.1.18.1. DataProtectionApplication CR で CSI を有効にする

CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。

手順

  • 次の例のように、DataProtectionApplication CR を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi

    ここでは、以下のようになります。

    csi
    CSI の デフォルトプラグインを指定します。
5.9.1.18.2. DataProtectionApplication でノードエージェントを無効にする

バックアップに ResticKopia、または DataMover を使用していない場合は、DataProtectionApplication カスタムリソース (CR) の nodeAgent フィールドを無効にすることができます。nodeAgent を無効にする前に、OADP Operator がアイドル状態であり、バックアップを実行していないことを確認してください。

手順

  1. nodeAgent を無効にするには、enable フラグを false に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: false
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にします。
  2. nodeAgent を有効にするには、enable フラグを true に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable

    ノードエージェントを有効にします。

    ジョブをセットアップして、DataProtectionApplication CR の nodeAgent フィールドを有効または無効にすることができます。詳細は、「ジョブの使用による Pod でのタスクの実行」を参照してください。

5.10. Google Cloud を使用した OADP の設定

5.10.1. Google Cloud を使用した OpenShift API for Data Protection の設定

OADP Operator をインストールすることで、Google Cloud を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.16 をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

Velero 用に Google Cloud を設定し、デフォルトの Secret を作成してから、Data Protection Application をインストールします。詳細は、OADP Operator のインストール を参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。詳細は、非接続環境での Operator Lifecycle Manager の使用 を参照してください。

5.10.1.1. Google Cloud の設定

OpenShift API for Data Protection (OADP) 用に Google Cloud を設定します。

前提条件

  • gcloud および gsutil CLI ツールがインストールされている必要があります。詳細は、Google Cloud のドキュメント をご覧ください。

手順

  1. Google Cloud にログインします。

    $ gcloud auth login
  2. BUCKET 変数を設定します。

    $ BUCKET=<bucket>

    ここでは、以下のようになります。

    bucket
    バケット名を指定します。
  3. ストレージバケットを作成します。

    $ gsutil mb gs://$BUCKET/
  4. PROJECT_ID 変数をアクティブなプロジェクトに設定します。

    $ PROJECT_ID=$(gcloud config get-value project)
  5. サービスアカウントを作成します。

    $ gcloud iam service-accounts create velero \
        --display-name "Velero service account"
  6. サービスアカウントをリスト表示します。

    $ gcloud iam service-accounts list
  7. email の値と一致するように SERVICE_ACCOUNT_EMAIL 変数を設定します。

    $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
        --filter="displayName:Velero service account" \
        --format 'value(email)')
  8. ポリシーを添付して、velero ユーザーに必要最小限の権限を付与します。

    $ ROLE_PERMISSIONS=(
        compute.disks.get
        compute.disks.create
        compute.disks.createSnapshot
        compute.snapshots.get
        compute.snapshots.create
        compute.snapshots.useReadOnly
        compute.snapshots.delete
        compute.zones.get
        storage.objects.create
        storage.objects.delete
        storage.objects.get
        storage.objects.list
        iam.serviceAccounts.signBlob
    )
  9. velero.server カスタムロールを作成します。

    $ gcloud iam roles create velero.server \
        --project $PROJECT_ID \
        --title "Velero Server" \
        --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"
  10. IAM ポリシーバインディングをプロジェクトに追加します。

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server
  11. IAM サービスアカウントを更新します。

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
  12. IAM サービスアカウントのキーを現在のディレクトリーにある credentials-velero ファイルに保存します。

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    Data Protection Application をインストールする前に、credentials-velero ファイルを使用して Google Cloud の Secret オブジェクトを作成します。

5.10.1.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて

DataProtectionApplication カスタムリソース (CR) のバックアップ場所、スナップショット場所、およびシークレット設定要件を確認してください。これは、データ保護業務におけるストレージオプションと認証情報管理を理解するのに役立ちます。

5.10.1.2.1. バックアップの場所

バックアップの場所として、次のいずれかの AWS S3 互換オブジェクトストレージソリューションを指定できます。

  • Multicloud Object Gateway (MCG)
  • Red Hat Container Storage
  • Ceph RADOS Gateway (別称 Ceph Object Gateway)
  • Red Hat OpenShift Data Foundation
  • MinIO

Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。

5.10.1.2.2. スナップショットの場所

クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。

Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。

File System Backup (FSB) を使用する場合、FSB がオブジェクトストレージ上にファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。

5.10.1.2.3. シークレット

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。

  • DataProtectionApplication CR で指定する、バックアップの場所用のカスタム Secret
  • DataProtectionApplication CR で参照されない、スナップショットの場所用のデフォルト Secret
重要

Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。

インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。

5.10.1.2.4. デフォルト Secret の作成

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

Secret のデフォルト名は cloud-credentials-gcp です。

注記

DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。

インストール時にバックアップ場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用して、デフォルト名の Secret を作成できます。

前提条件

  • オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
  • Velero のオブジェクトストレージを設定する必要があります。

手順

  1. Backup Storage Location の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。
  2. デフォルト名で Secret カスタムリソース (CR) を作成します。

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero

    Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。

5.10.1.2.5. 異なる認証情報のシークレットの作成

バックアップ先とスナップショット先で異なる認証情報が必要な場合は、それぞれ別の シークレット オブジェクトを作成してください。これにより、安全な認証情報管理を維持しながら、ストレージの場所ごとに個別の認証を設定できます。

手順

  1. スナップショットの場所の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。
  2. デフォルト名でスナップショットの場所の Secret を作成します。

    $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
  3. オブジェクトストレージに適した形式で、バックアップロケーションの credentials-velero ファイルを作成します。
  4. カスタム名を使用してバックアップロケーションの Secret を作成します。

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 次の例のように、カスタム名の SecretDataProtectionApplication に追加します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            provider: gcp
            default: true
            credential:
              key: cloud
              name: <custom_secret>
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
      snapshotLocations:
        - velero:
            provider: gcp
            default: true
            config:
              project: <project>
              snapshotLocation: us-west1

    ここでは、以下のようになります。

    カスタムシークレット
    バックアップ場所を指定する Secret に、カスタム名を指定します。
5.10.1.2.6. Velero の CPU とメモリーのリソース割り当てを設定

DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • 次の例のように、DataProtectionApplication CR マニフェストの spec.configuration.velero.podConfig.ResourceAllocations ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector>
            resourceAllocations:
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi

    ここでは、以下のようになります。

    nodeSelector
    Velero podSpec に渡すノードセレクターを指定します。
    resourceAllocations

    平均使用量に基づいて割り当てられたリソースを指定します。

    注記

    Kopia は OADP 1.3 以降のリリースで選択できます。Kopia はファイルシステムのバックアップに使用できます。組み込みの Data Mover を使用する Data Mover の場合は、Kopia が唯一の選択肢になります。

    Kopia は Restic よりも多くのリソースを消費するため、それに応じて CPU とメモリーの要件を調整しなければならない場合があります。

nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。

5.10.1.2.7. 自己署名 CA 証明書の有効化

certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • DataProtectionApplication CR マニフェストの spec.backupLocations.velero.objectStorage.caCert パラメーターと spec.backupLocations.velero.config パラメーターを編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string>
            config:
              insecureSkipTLSVerify: "false"
    # ...

    ここでは、以下のようになります。

    caCert
    Base64 エンコードされた CA 証明書文字列を指定します。
    insecureSkipTLSVerify
    insecureSkipTLSVerify の 設定を指定します。設定は true または false のいずれかに設定できます。"true" に設定すると、SSL/TLS セキュリティーが無効になります。"false" に設定すると、SSL/TLS セキュリティーが有効になります。
5.10.1.2.8. Velero デプロイメント用のエイリアス化した velero コマンドで CA 証明書を使用する

Velero CLI のエイリアスを作成することで、システムにローカルにインストールせずに Velero CLI を使用できます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. エイリアス化した Velero コマンドを使用するには、次のコマンドを実行します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
  2. 次のコマンドを実行して、エイリアスが機能していることを確認します。

    $ velero version
    Client:
    	Version: v1.12.1-OADP
    	Git commit: -
    Server:
    	Version: v1.12.1-OADP
  3. このコマンドで CA 証明書を使用するには、次のコマンドを実行して証明書を Velero デプロイメントに追加できます。

    $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
    $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
    $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
  4. バックアップログを取得するために、次のコマンドを実行します。

    $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

    このログを使用して、バックアップできないリソースの障害と警告を表示できます。

  5. Velero Pod が再起動すると、/tmp/your-cacert.txt ファイルが消去されます。そのため、前の手順のコマンドを再実行して /tmp/your-cacert.txt ファイルを再作成する必要があります。
  6. 次のコマンドを実行すると、/tmp/your-cacert.txt ファイルを保存した場所にファイルがまだ存在するかどうかを確認できます。

    $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
    /tmp/your-cacert.txt

    OpenShift API for Data Protection (OADP) の今後のリリースでは、この手順が不要になるように証明書を Velero Pod にマウントする予定です。

5.10.1.3. Google Workload Identity 連携のクラウド認証

Google Cloud の外で実行されているアプリケーションは、ユーザー名やパスワードなどのサービスアカウントキーを使用して、Google Cloud リソースにアクセスします。これらのサービスアカウントキーは、適切に管理されていない場合、セキュリティーリスクになる可能性があります。

Google Workload Identity 連携を使用すると、Identity and Access Management (IAM) を使用して、サービスアカウントに成り代わる機能などの IAM ロールを外部アイデンティティーに付与できます。これにより、サービスアカウントキーに関連するメンテナンスとセキュリティーのリスクが排除されます。

Workload Identity 連携は、証明書の暗号化と復号化、ユーザー属性の抽出、および検証を処理します。Identity 連携は認証を外部化し、それをセキュリティートークンサービス (STS) に渡すことで、個々の開発者の負担を軽減します。リソースへのアクセスの認可と制御は、引き続きアプリケーションが処理します。

注記

Google Workload Identity 連携は、OADP 1.3.x 以降で利用できます。

ボリュームをバックアップする場合、Google Workload Identity 連携認証を使用した Google Cloud 上の OADP は、CSI スナップショットのみをサポートします。

Google Workload Identity 連携認証を使用した Google Cloud 上の OADP は、Volume Snapshot Locations (VSL) バックアップをサポートしていません。Google Cloud ワークロードアイデンティティーフェデレーションが設定されている場合、VSL バックアップは 部分的に失敗した フェーズで終了します。

Google Workload Identity 連携クラウド認証を使用しない場合は、Data Protection Application のインストール に進みます。

前提条件

  • Google Cloud Workload Identity を設定 して、クラスターを手動モードでインストールした。
  • Cloud Credential Operator ユーティリティー (ccoctl) と、関連する Workload Identity プールにアクセスできる。

手順

  1. 次のコマンドを実行して、oadp-credrequest ディレクトリーを作成します。

    $ mkdir -p oadp-credrequest
  2. 次のように、CredentialsRequest.yaml ファイルを作成します。

    echo 'apiVersion: cloudcredential.openshift.io/v1
    kind: CredentialsRequest
    metadata:
      name: oadp-operator-credentials
      namespace: openshift-cloud-credential-operator
    spec:
      providerSpec:
        apiVersion: cloudcredential.openshift.io/v1
        kind: GCPProviderSpec
        permissions:
        - compute.disks.get
        - compute.disks.create
        - compute.disks.createSnapshot
        - compute.snapshots.get
        - compute.snapshots.create
        - compute.snapshots.useReadOnly
        - compute.snapshots.delete
        - compute.zones.get
        - storage.objects.create
        - storage.objects.delete
        - storage.objects.get
        - storage.objects.list
        - iam.serviceAccounts.signBlob
        skipServiceCheck: true
      secretRef:
        name: cloud-credentials-gcp
        namespace: <OPERATOR_INSTALL_NS>
      serviceAccountNames:
      - velero
    ' > oadp-credrequest/credrequest.yaml
  3. 次のコマンドを実行し、ccoctl ユーティリティーを使用して、oadp-credrequest ディレクトリー内の CredentialsRequest オブジェクトを処理します。

    $ ccoctl gcp create-service-accounts \
        --name=<name> \
        --project=<gcp_project_id> \
        --credentials-requests-dir=oadp-credrequest \
        --workload-identity-pool=<pool_id> \
        --workload-identity-provider=<provider_id>

    これで、次のステップで manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml ファイルを使用できるようになりました。

  4. 次のコマンドを実行して、namespace を作成します。

    $ oc create namespace <OPERATOR_INSTALL_NS>
  5. 次のコマンドを実行して、認証情報を namespace に適用します。

    $ oc apply -f manifests/openshift-adp-cloud-credentials-gcp-credentials.yaml
5.10.1.4. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials-gcp を使用して Secret を作成する必要がある。
  • バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの Secrets を作成する必要がある。

    • バックアップの場所用のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    • スナップショットの場所用の別のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: <OPERATOR_INSTALL_NS>
    spec:
      configuration:
        velero:
          defaultPlugins:
            - gcp
            - openshift
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            nodeSelector: <node_selector>
      backupLocations:
        - velero:
            provider: gcp
            default: true
            credential:
              key: cloud
              name: cloud-credentials-gcp
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
      snapshotLocations:
        - velero:
            provider: gcp
            default: true
            config:
              project: <project>
              snapshotLocation: us-west1
            credential:
              key: cloud
              name: cloud-credentials-gcp
      backupImages: true

    ここでは、以下のようになります。

    namespace
    OADP のデフォルトの名前空間である openshift-adp を指定します。namespace は変数であり、設定可能です。
    openshift
    openshift プラグインが必須であることを指定します。
    リソースタイムアウト
    Velero CRD の可用性、ボリュームスナップショットの削除、バックアップリポジトリーの可用性など、複数の Velero リソースについてタイムアウトが発生するまでの待機時間を分単位で指定します。デフォルトは 10m です。
    ノードエージェント
    管理要求をサーバーにルーティングする管理エージェントを指定します。
    enable
    nodeAgent を有効にして File System Backup を実行する場合は、この値を true に設定します。
    アップローダータイプ
    アップローダーの種類を指定します。アップローダーとして kopia または restic と入力します。インストール後に選択を変更することはできません。組み込み DataMover の場合は、Kopia を使用する必要があります。nodeAgent はデーモンセットをデプロイします。これは、nodeAgent Pod が各ワーキングノード上で実行されることを意味します。File System Backup を設定するには、spec.defaultVolumesToFsBackup: trueBackup CR に追加します。
    nodeSelector
    Kopia または Restic が利用可能なノードを指定します。デフォルトでは、Kopia または Restic はすべてのノードで実行されます。
    key
    認証情報を含むシークレットキーを指定します。Google Workload Identity 連携クラウド認証の場合は、service_account.json を使用します。
    name
    認証情報を含むシークレット名を指定します。この値を指定しない場合は、デフォルトの名前である cloud-credentials-gcp が使用されます。
    bucket
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    prefix
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
    snapshotLocations
    CSI スナップショットまたは Restic を使用して PV をバックアップする場合を除き、スナップショットの場所を指定します。
    スナップショットの場所
    スナップショットの場所は、PV と同じリージョン内にある必要があることを指定します。
    name
    作成した シークレット オブジェクトの名前を指定します。この値を指定しない場合は、デフォルトの名前である cloud-credentials-gcp が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。
    backupImages
    Google ワークロードアイデンティティーフェデレーションが内部イメージバックアップをサポートしていることを指定します。イメージのバックアップを使用しない場合は、このフィールドを false に設定します。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
5.10.1.5. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.10.1.6. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.10.1.7. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.10.1.8. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.10.1.9. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.10.1.10. ノードエージェントを非 root および非特権ユーザーとして設定する

ノードエージェントのセキュリティーを強化するには、DataProtectionApplication (DPA) カスタムリソース (CR) の spec.configuration.velero.disableFsBackup 設定を使用して、OADP Operator ノードエージェントデーモンセットを非 root および非特権ユーザーとして実行するように設定できます。

spec.configuration.velero.disableFsBackup 設定を true に設定すると、ノードエージェントのセキュリティーコンテキストによってルートファイルシステムが読み取り専用に設定され、privileged フラグが false に設定されます。

注記

spec.configuration.velero.disableFsBackuptrue に設定すると、特権コンテナーの必要性がなくなり、読み取り専用のルートファイルシステムが適用されるため、ノードエージェントのセキュリティーが強化されます。

ただし、Kopia によるファイルシステムバックアップ (FSB) も無効になります。ワークロードがネイティブスナップショットをサポートしていないボリュームのバックアップに FSB に依存している場合は、disableFsBackup 設定がユースケースに適合するかどうかを評価する必要があります。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の disableFsBackup フィールドを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - csi
          - gcp
          - openshift
          disableFsBackup: true

    ここでは、以下のようになります。

    ノードエージェント
    DPA でノードエージェントを有効にすることを指定します。
    disableFsBackup
    disableFsBackup フィールドを true に設定することを指定します。

検証

  1. 次のコマンドを実行して、ノードエージェントのセキュリティーコンテキストが非 root として実行するように設定され、root ファイルシステムが readOnly あることを確認します。

    $ oc get daemonset node-agent -o yaml

    出力例は次のとおりです。

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      ...
      name: node-agent
      namespace: openshift-adp
      ...
    spec:
      ...
      template:
        metadata:
          ...
        spec:
          containers:
          ...
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                - ALL
              privileged: false
              readOnlyRootFilesystem: true
            ...
          nodeSelector:
            kubernetes.io/os: linux
          os:
            name: linux
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          serviceAccount: velero
          serviceAccountName: velero
          ....

    ここでは、以下のようになります。

    allowPrivilegeEscalation
    allowPrivilegeEscalation フィールドが false であることを指定します。
    privileged
    特権 フィールドが false であることを指定します。
    readOnlyRootFilesystem
    ルートファイルシステムが読み取り専用であることを指定します。
    runAsNonRoot
    ノードエージェントを非 root ユーザーとして実行することを指定します。
5.10.1.11. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.10.1.12. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.10.1.13. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.10.1.13.1. DataProtectionApplication CR で CSI を有効にする

CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。

手順

  • 次の例のように、DataProtectionApplication CR を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi

    ここでは、以下のようになります。

    csi
    CSI の デフォルトプラグインを指定します。
5.10.1.13.2. DataProtectionApplication でノードエージェントを無効にする

バックアップに ResticKopia、または DataMover を使用していない場合は、DataProtectionApplication カスタムリソース (CR) の nodeAgent フィールドを無効にすることができます。nodeAgent を無効にする前に、OADP Operator がアイドル状態であり、バックアップを実行していないことを確認してください。

手順

  1. nodeAgent を無効にするには、enable フラグを false に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: false
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にします。
  2. nodeAgent を有効にするには、enable フラグを true に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable

    ノードエージェントを有効にします。

    ジョブをセットアップして、DataProtectionApplication CR の nodeAgent フィールドを有効または無効にすることができます。詳細は、「ジョブの使用による Pod でのタスクの実行」を参照してください。

5.11. MCG を使用した OADP の設定

5.11.1. Multicloud Object Gateway を使用した OpenShift API for Data Protection の設定

認証情報、シークレット、および Data Protection Application を設定することで、OpenShift Data Foundation のコンポーネントである Multicloud Object Gateway (MCG) をバックアップストレージの場所として使用するように、OpenShift API for Data Protection (OADP) を設定します。

OADP Operator をインストールすることで、MCG を使用する OpenShift API for Data Protection (OADP) をインストールできます。Operator は Velero 1.16 をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

バックアップ場所の Secret CR を作成し、Data Protection Application をインストールできます。詳細は、OADP Operator のインストール を参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。詳細は、非接続環境での Operator Lifecycle Manager の使用 を参照してください。

5.11.1.1. Multicloud Object Gateway の認証情報の取得

OpenShift API for Data Protection (OADP) 用の シークレット カスタムリソース (CR) を作成するために、Multicloud Object Gateway (MCG) バケットの認証情報を取得します。

注記

MCG Operator は 非推奨 ですが、MCG プラグインは OpenShift Data Foundation で引き続き利用できます。プラグインをダウンロードするには、Red Hat OpenShift Data Foundation のダウンロード を参照し、ご使用のオペレーティングシステムに適した MCG プラグインをダウンロードします。

前提条件

手順

  1. MCG バケットを作成します。詳細は、ハイブリッドおよびマルチクラウドリソースの管理 を参照してください。
  2. バケットリソースに対して oc describe コマンドを実行して、S3 エンドポイント、AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY、およびバケット名を取得します。
  3. credentials-velero ファイルを作成します。

    $ cat << EOF > ./credentials-velero
    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
    EOF

    Data Protection Application をインストールするときに、credentials-velero ファイルを使用して Secret オブジェクトを作成できます。

5.11.1.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて

DataProtectionApplication カスタムリソース (CR) のバックアップ場所、スナップショット場所、およびシークレット設定要件を確認してください。これは、データ保護業務におけるストレージオプションと認証情報管理を理解するのに役立ちます。

5.11.1.2.1. バックアップの場所

バックアップの場所として、次のいずれかの AWS S3 互換オブジェクトストレージソリューションを指定できます。

  • Multicloud Object Gateway (MCG)
  • Red Hat Container Storage
  • Ceph RADOS Gateway (別称 Ceph Object Gateway)
  • Red Hat OpenShift Data Foundation
  • MinIO

Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。

5.11.1.2.2. スナップショットの場所

クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。

Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。

File System Backup (FSB) を使用する場合、FSB がオブジェクトストレージ上にファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。

5.11.1.2.3. シークレット

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。

  • DataProtectionApplication CR で指定する、バックアップの場所用のカスタム Secret
  • DataProtectionApplication CR で参照されない、スナップショットの場所用のデフォルト Secret
重要

Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。

インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。

5.11.1.2.4. デフォルト Secret の作成

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

Secret のデフォルト名は cloud-credentials です。

注記

DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。

インストール時にバックアップ場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用して、デフォルト名の Secret を作成できます。

前提条件

  • オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
  • Velero のオブジェクトストレージを設定する必要があります。

手順

  1. Backup Storage Location の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。

    以下の例を参照してください。

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  2. デフォルト名で Secret カスタムリソース (CR) を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

    Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。

5.11.1.2.5. 異なる認証情報のシークレットの作成

バックアップ先とスナップショット先で異なる認証情報が必要な場合は、それぞれ別の シークレット オブジェクトを作成してください。これにより、安全な認証情報管理を維持しながら、ストレージの場所ごとに個別の認証を設定できます。

手順

  1. スナップショットの場所の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。
  2. デフォルト名でスナップショットの場所の Secret を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. オブジェクトストレージに適した形式で、バックアップロケーションの credentials-velero ファイルを作成します。
  4. カスタム名を使用してバックアップロケーションの Secret を作成します。

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 次の例のように、カスタム名の SecretDataProtectionApplication に追加します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: <region_name>
              s3Url: <url>
              insecureSkipTLSVerify: "true"
              s3ForcePathStyle: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  <custom_secret>
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>

    ここでは、以下のようになります。

    地域名
    オブジェクトストレージサーバーのドキュメントに記載されている命名規則に従って、リージョンを指定します。
    カスタムシークレット
    バックアップ場所を指定する Secret に、カスタム名を指定します。
5.11.1.2.6. Velero の CPU とメモリーのリソース割り当てを設定

DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • 次の例のように、DataProtectionApplication CR マニフェストの spec.configuration.velero.podConfig.ResourceAllocations ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector>
            resourceAllocations:
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi

    ここでは、以下のようになります。

    nodeSelector
    Velero podSpec に渡すノードセレクターを指定します。
    resourceAllocations

    平均使用量に基づいて割り当てられたリソースを指定します。

    注記

    Kopia は OADP 1.3 以降のリリースで選択できます。Kopia はファイルシステムのバックアップに使用できます。組み込みの Data Mover を使用する Data Mover の場合は、Kopia が唯一の選択肢になります。

    Kopia は Restic よりも多くのリソースを消費するため、それに応じて CPU とメモリーの要件を調整しなければならない場合があります。

nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。

5.11.1.2.7. 自己署名 CA 証明書の有効化

certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • DataProtectionApplication CR マニフェストの spec.backupLocations.velero.objectStorage.caCert パラメーターと spec.backupLocations.velero.config パラメーターを編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string>
            config:
              insecureSkipTLSVerify: "false"
    # ...

    ここでは、以下のようになります。

    caCert
    Base64 エンコードされた CA 証明書文字列を指定します。
    insecureSkipTLSVerify
    insecureSkipTLSVerify の 設定を指定します。設定は true または false のいずれかに設定できます。"true" に設定すると、SSL/TLS セキュリティーが無効になります。"false" に設定すると、SSL/TLS セキュリティーが有効になります。
5.11.1.2.8. Velero デプロイメント用のエイリアス化した velero コマンドで CA 証明書を使用する

Velero CLI のエイリアスを作成することで、システムにローカルにインストールせずに Velero CLI を使用できます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. エイリアス化した Velero コマンドを使用するには、次のコマンドを実行します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
  2. 次のコマンドを実行して、エイリアスが機能していることを確認します。

    $ velero version
    Client:
    	Version: v1.12.1-OADP
    	Git commit: -
    Server:
    	Version: v1.12.1-OADP
  3. このコマンドで CA 証明書を使用するには、次のコマンドを実行して証明書を Velero デプロイメントに追加できます。

    $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
    $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
    $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
  4. バックアップログを取得するために、次のコマンドを実行します。

    $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

    このログを使用して、バックアップできないリソースの障害と警告を表示できます。

  5. Velero Pod が再起動すると、/tmp/your-cacert.txt ファイルが消去されます。そのため、前の手順のコマンドを再実行して /tmp/your-cacert.txt ファイルを再作成する必要があります。
  6. 次のコマンドを実行すると、/tmp/your-cacert.txt ファイルを保存した場所にファイルがまだ存在するかどうかを確認できます。

    $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
    /tmp/your-cacert.txt

    OpenShift API for Data Protection (OADP) の今後のリリースでは、この手順が不要になるように証明書を Velero Pod にマウントする予定です。

5.11.1.3. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials を使用して Secret を作成する必要がある。
  • バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの Secrets を作成する必要がある。

    • バックアップの場所用のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    • スナップショットの場所用の別のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - aws
            - openshift
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            nodeSelector: <node_selector>
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: <region_name>
              s3Url: <url>
              insecureSkipTLSVerify: "true"
              s3ForcePathStyle: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name: cloud-credentials
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>

    ここでは、以下のようになります。

    namespace
    OADP のデフォルトの名前空間である openshift-adp を指定します。namespace は変数であり、設定可能です。
    aws
    ストレージの場所に対応するオブジェクトストアプラグインが必要であることを指定します。すべての S3 プロバイダーで、aws プラグインが必要です。Azure および Google Cloud オブジェクトストアの場合、azure または gcp プラグインが必要です。
    openshift
    openshift プラグインが必須であることを指定します。
    リソースタイムアウト
    Velero CRD の可用性、ボリュームスナップショットの削除、バックアップリポジトリーの可用性など、複数の Velero リソースについてタイムアウトが発生するまでの待機時間を分単位で指定します。デフォルトは 10m です。
    ノードエージェント
    管理要求をサーバーにルーティングする管理エージェントを指定します。
    enable
    nodeAgent を有効にして File System Backup を実行する場合は、この値を true に設定します。
    アップローダータイプ
    アップローダーの種類を指定します。アップローダーとして kopia または restic と入力します。インストール後に選択を変更することはできません。組み込み DataMover の場合は、Kopia を使用する必要があります。nodeAgent はデーモンセットをデプロイします。これは、nodeAgent Pod が各ワーキングノード上で実行されることを意味します。File System Backup を設定するには、spec.defaultVolumesToFsBackup: trueBackup CR に追加します。
    nodeSelector
    Kopia または Restic が利用可能なノードを指定します。デフォルトでは、Kopia または Restic はすべてのノードで実行されます。
    region
    オブジェクトストレージサーバーのドキュメントに記載されている命名規則に従って、リージョンを指定します。
    s3Url
    S3 エンドポイントの URL を指定します。
    name
    作成した シークレット オブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名の cloud-credentials が使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。
    bucket
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    prefix
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
5.11.1.4. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.11.1.5. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.11.1.6. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.11.1.7. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.11.1.8. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.11.1.9. ノードエージェントを非 root および非特権ユーザーとして設定する

ノードエージェントのセキュリティーを強化するには、DataProtectionApplication (DPA) カスタムリソース (CR) の spec.configuration.velero.disableFsBackup 設定を使用して、OADP Operator ノードエージェントデーモンセットを非 root および非特権ユーザーとして実行するように設定できます。

spec.configuration.velero.disableFsBackup 設定を true に設定すると、ノードエージェントのセキュリティーコンテキストによってルートファイルシステムが読み取り専用に設定され、privileged フラグが false に設定されます。

注記

spec.configuration.velero.disableFsBackuptrue に設定すると、特権コンテナーの必要性がなくなり、読み取り専用のルートファイルシステムが適用されるため、ノードエージェントのセキュリティーが強化されます。

ただし、Kopia によるファイルシステムバックアップ (FSB) も無効になります。ワークロードがネイティブスナップショットをサポートしていないボリュームのバックアップに FSB に依存している場合は、disableFsBackup 設定がユースケースに適合するかどうかを評価する必要があります。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の disableFsBackup フィールドを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - csi
          - gcp
          - openshift
          disableFsBackup: true

    ここでは、以下のようになります。

    ノードエージェント
    DPA でノードエージェントを有効にすることを指定します。
    disableFsBackup
    disableFsBackup フィールドを true に設定することを指定します。

検証

  1. 次のコマンドを実行して、ノードエージェントのセキュリティーコンテキストが非 root として実行するように設定され、root ファイルシステムが readOnly あることを確認します。

    $ oc get daemonset node-agent -o yaml

    出力例は次のとおりです。

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      ...
      name: node-agent
      namespace: openshift-adp
      ...
    spec:
      ...
      template:
        metadata:
          ...
        spec:
          containers:
          ...
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                - ALL
              privileged: false
              readOnlyRootFilesystem: true
            ...
          nodeSelector:
            kubernetes.io/os: linux
          os:
            name: linux
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          serviceAccount: velero
          serviceAccountName: velero
          ....

    ここでは、以下のようになります。

    allowPrivilegeEscalation
    allowPrivilegeEscalation フィールドが false であることを指定します。
    privileged
    特権 フィールドが false であることを指定します。
    readOnlyRootFilesystem
    ルートファイルシステムが読み取り専用であることを指定します。
    runAsNonRoot
    ノードエージェントを非 root ユーザーとして実行することを指定します。
5.11.1.10. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.11.1.11. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.11.1.12. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.11.1.12.1. DataProtectionApplication CR で CSI を有効にする

CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。

手順

  • 次の例のように、DataProtectionApplication CR を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi

    ここでは、以下のようになります。

    csi
    CSI の デフォルトプラグインを指定します。
5.11.1.12.2. DataProtectionApplication でノードエージェントを無効にする

バックアップに ResticKopia、または DataMover を使用していない場合は、DataProtectionApplication カスタムリソース (CR) の nodeAgent フィールドを無効にすることができます。nodeAgent を無効にする前に、OADP Operator がアイドル状態であり、バックアップを実行していないことを確認してください。

手順

  1. nodeAgent を無効にするには、enable フラグを false に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: false
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にします。
  2. nodeAgent を有効にするには、enable フラグを true に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable

    ノードエージェントを有効にします。

    ジョブをセットアップして、DataProtectionApplication CR の nodeAgent フィールドを有効または無効にすることができます。詳細は、「ジョブの使用による Pod でのタスクの実行」を参照してください。

5.12. ODF を使用した OADP の設定

5.12.1. OpenShift Data Foundation を使用した OpenShift API for Data Protection の設定

OpenShift Data Foundation に OpenShift API for Data Protection (OADP) をインストールするには、OADP Operator をインストールし、バックアップ場所とスナップショット場所を設定します。次に、Data Protection Application をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

Multicloud Object Gateway または任意の AWS S3 互換のオブジェクトストレージをバックアップの場所として設定できます。

バックアップ場所の Secret CR を作成し、Data Protection Application をインストールできます。詳細は、OADP Operator のインストール を参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。詳細は、非接続環境での Operator Lifecycle Manager の使用 を参照してください。

5.12.1.1. バックアップおよびスナップショットの場所、ならびにそのシークレットについて

DataProtectionApplication カスタムリソース (CR) のバックアップ場所、スナップショット場所、およびシークレット設定要件を確認してください。これは、データ保護業務におけるストレージオプションと認証情報管理を理解するのに役立ちます。

5.12.1.1.1. バックアップの場所

バックアップの場所として、次のいずれかの AWS S3 互換オブジェクトストレージソリューションを指定できます。

  • Multicloud Object Gateway (MCG)
  • Red Hat Container Storage
  • Ceph RADOS Gateway (別称 Ceph Object Gateway)
  • Red Hat OpenShift Data Foundation
  • MinIO

Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。

5.12.1.1.2. スナップショットの場所

クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。

Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。

File System Backup (FSB) を使用する場合、FSB がオブジェクトストレージ上にファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。

5.12.1.1.3. シークレット

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。

  • DataProtectionApplication CR で指定する、バックアップの場所用のカスタム Secret
  • DataProtectionApplication CR で参照されない、スナップショットの場所用のデフォルト Secret
重要

Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。

インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。

5.12.1.1.4. デフォルト Secret の作成

バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。

バックアップストレージプロバイダーに awsazure、または gcp などのデフォルトのプラグインがない限り、Secret のデフォルト名は cloud-credentials です。その場合、プロバイダー固有の OADP インストール手順でデフォルト名が指定されています。

注記

DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。

インストール時にバックアップ場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用して、デフォルト名の Secret を作成できます。

前提条件

  • オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
  • Velero のオブジェクトストレージを設定する必要があります。

手順

  1. Backup Storage Location の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。

    以下の例を参照してください。

    [default]
    aws_access_key_id=<AWS_ACCESS_KEY_ID>
    aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
  2. デフォルト名で Secret カスタムリソース (CR) を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

    Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。

5.12.1.1.5. 異なる認証情報のシークレットの作成

バックアップ先とスナップショット先で異なる認証情報が必要な場合は、それぞれ別の シークレット オブジェクトを作成してください。これにより、安全な認証情報管理を維持しながら、ストレージの場所ごとに個別の認証を設定できます。

手順

  1. スナップショットの場所の credentials-velero ファイルをクラウドプロバイダーに適した形式で作成します。
  2. デフォルト名でスナップショットの場所の Secret を作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
  3. オブジェクトストレージに適した形式で、バックアップロケーションの credentials-velero ファイルを作成します。
  4. カスタム名を使用してバックアップロケーションの Secret を作成します。

    $ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
  5. 次の例のように、カスタム名の SecretDataProtectionApplication に追加します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
    ...
      backupLocations:
        - velero:
            provider: <provider>
            default: true
            credential:
              key: cloud
              name: <custom_secret>
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>

    ここでは、以下のようになります。

    カスタムシークレット
    バックアップ場所を指定する Secret に、カスタム名を指定します。
5.12.1.1.6. Velero の CPU とメモリーのリソース割り当てを設定

DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • 次の例のように、DataProtectionApplication CR マニフェストの spec.configuration.velero.podConfig.ResourceAllocations ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      configuration:
        velero:
          podConfig:
            nodeSelector: <node_selector>
            resourceAllocations:
              limits:
                cpu: "1"
                memory: 1024Mi
              requests:
                cpu: 200m
                memory: 256Mi

    ここでは、以下のようになります。

    nodeSelector
    Velero podSpec に渡すノードセレクターを指定します。
    resourceAllocations

    平均使用量に基づいて割り当てられたリソースを指定します。

    注記

    Kopia は OADP 1.3 以降のリリースで選択できます。Kopia はファイルシステムのバックアップに使用できます。組み込みの Data Mover を使用する Data Mover の場合は、Kopia が唯一の選択肢になります。

    Kopia は Restic よりも多くのリソースを消費するため、それに応じて CPU とメモリーの要件を調整しなければならない場合があります。

nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。

5.12.1.1.6.1. 収集したデータに基づき Ceph の CPU およびメモリー要件を調整する

以下の推奨事項は、スケールおよびパフォーマンスのラボで観察したパフォーマンスに基づいています。この変更は、特に Red Hat OpenShift Data Foundation (ODF) に関連しています。ODF を使用する場合は、適切なチューニングガイドで公式の推奨事項を確認してください。

5.12.1.1.6.1.1. 設定に必要な CPU とメモリー

バックアップおよび復元操作には、大量の CephFS PersistentVolumes (PV) が必要です。out-of-memory (OOM) エラーによる Ceph MDS Pod の再起動を回避するためには、次の設定が推奨されます。

Expand
設定タイプ要求上限

CPU

要求が 3 に変更されました

上限は 3

メモリー

要求が 8 Gi に変更されました

上限は 128 Gi

5.12.1.1.7. 自己署名 CA 証明書の有効化

certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。

前提条件

  • OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。

手順

  • DataProtectionApplication CR マニフェストの spec.backupLocations.velero.objectStorage.caCert パラメーターと spec.backupLocations.velero.config パラメーターを編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
    spec:
    # ...
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket>
              prefix: <prefix>
              caCert: <base64_encoded_cert_string>
            config:
              insecureSkipTLSVerify: "false"
    # ...

    ここでは、以下のようになります。

    caCert
    Base64 エンコードされた CA 証明書文字列を指定します。
    insecureSkipTLSVerify
    insecureSkipTLSVerify の 設定を指定します。設定は true または false のいずれかに設定できます。"true" に設定すると、SSL/TLS セキュリティーが無効になります。"false" に設定すると、SSL/TLS セキュリティーが有効になります。
5.12.1.1.8. Velero デプロイメント用のエイリアス化した velero コマンドで CA 証明書を使用する

Velero CLI のエイリアスを作成することで、システムにローカルにインストールせずに Velero CLI を使用できます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. エイリアス化した Velero コマンドを使用するには、次のコマンドを実行します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
  2. 次のコマンドを実行して、エイリアスが機能していることを確認します。

    $ velero version
    Client:
    	Version: v1.12.1-OADP
    	Git commit: -
    Server:
    	Version: v1.12.1-OADP
  3. このコマンドで CA 証明書を使用するには、次のコマンドを実行して証明書を Velero デプロイメントに追加できます。

    $ CA_CERT=$(oc -n openshift-adp get dataprotectionapplications.oadp.openshift.io <dpa-name> -o jsonpath='{.spec.backupLocations[0].velero.objectStorage.caCert}')
    $ [[ -n $CA_CERT ]] && echo "$CA_CERT" | base64 -d | oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "cat > /tmp/your-cacert.txt" || echo "DPA BSL has no caCert"
    $ velero describe backup <backup_name> --details --cacert /tmp/<your_cacert>.txt
  4. バックアップログを取得するために、次のコマンドを実行します。

    $ velero backup logs  <backup_name>  --cacert /tmp/<your_cacert.txt>

    このログを使用して、バックアップできないリソースの障害と警告を表示できます。

  5. Velero Pod が再起動すると、/tmp/your-cacert.txt ファイルが消去されます。そのため、前の手順のコマンドを再実行して /tmp/your-cacert.txt ファイルを再作成する必要があります。
  6. 次のコマンドを実行すると、/tmp/your-cacert.txt ファイルを保存した場所にファイルがまだ存在するかどうかを確認できます。

    $ oc exec -n openshift-adp -i deploy/velero -c velero -- bash -c "ls /tmp/your-cacert.txt"
    /tmp/your-cacert.txt

    OpenShift API for Data Protection (OADP) の今後のリリースでは、この手順が不要になるように証明書を Velero Pod にマウントする予定です。

5.12.1.2. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials を使用して Secret を作成する必要がある。
  • バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの Secrets を作成する必要がある。

    • バックアップの場所用のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    • スナップショットの場所用の別のカスタム名を持つ Secret。この SecretDataProtectionApplication CR に追加します。
    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - aws
            - kubevirt
            - csi
            - openshift
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            nodeSelector: <node_selector>
      backupLocations:
        - velero:
            provider: gcp
            default: true
            credential:
              key: cloud
              name: <default_secret>
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>

    ここでは、以下のようになります。

    namespace
    OADP のデフォルトの名前空間である openshift-adp を指定します。namespace は変数であり、設定可能です。
    aws
    ストレージの場所に対応するオブジェクトストアプラグインが必要であることを指定します。すべての S3 プロバイダーで、aws プラグインが必要です。Azure および Google Cloud オブジェクトストアの場合、azure または gcp プラグインが必要です。
    kubevirt
    オプション: kubevirt プラグインは OpenShift Virtualization で使用されます。
    csi
    CSI スナップショットを使用して PV をバックアップする場合の、CSI デフォルトプラグインを指定します。csi プラグインは、Velero CSI ベータスナップショット API を使用します。スナップショットの場所を設定する必要はありません。
    openshift
    openshift プラグインが必須であることを指定します。
    リソースタイムアウト
    Velero CRD の可用性、ボリュームスナップショットの削除、バックアップリポジトリーの可用性など、複数の Velero リソースについてタイムアウトが発生するまでの待機時間を分単位で指定します。デフォルトは 10m です。
    ノードエージェント
    管理要求をサーバーにルーティングする管理エージェントを指定します。
    enable
    nodeAgent を有効にして File System Backup を実行する場合は、この値を true に設定します。
    アップローダータイプ
    アップローダーの種類を指定します。アップローダーとして kopia または restic と入力します。インストール後に選択を変更することはできません。組み込み DataMover の場合は、Kopia を使用する必要があります。nodeAgent はデーモンセットをデプロイします。これは、nodeAgent Pod が各ワーキングノード上で実行されることを意味します。File System Backup を設定するには、spec.defaultVolumesToFsBackup: trueBackup CR に追加します。
    nodeSelector
    Kopia または Restic が利用可能なノードを指定します。デフォルトでは、Kopia または Restic はすべてのノードで実行されます。
    provider
    バックアッププロバイダーを指定します。
    name
    バックアッププロバイダーにデフォルトのプラグインを使用する場合、シークレット の正しいデフォルト名を指定します。たとえば、cloud-credentials-gcp など です。カスタム名を指定すると、そのカスタム名がバックアップの場所に使用されます。Secret 名を指定しない場合は、デフォルトの名前が使用されます。
    bucket
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    prefix
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
5.12.1.3. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.12.1.4. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.12.1.5. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.12.1.6. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.12.1.7. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.12.1.8. ノードエージェントを非 root および非特権ユーザーとして設定する

ノードエージェントのセキュリティーを強化するには、DataProtectionApplication (DPA) カスタムリソース (CR) の spec.configuration.velero.disableFsBackup 設定を使用して、OADP Operator ノードエージェントデーモンセットを非 root および非特権ユーザーとして実行するように設定できます。

spec.configuration.velero.disableFsBackup 設定を true に設定すると、ノードエージェントのセキュリティーコンテキストによってルートファイルシステムが読み取り専用に設定され、privileged フラグが false に設定されます。

注記

spec.configuration.velero.disableFsBackuptrue に設定すると、特権コンテナーの必要性がなくなり、読み取り専用のルートファイルシステムが適用されるため、ノードエージェントのセキュリティーが強化されます。

ただし、Kopia によるファイルシステムバックアップ (FSB) も無効になります。ワークロードがネイティブスナップショットをサポートしていないボリュームのバックアップに FSB に依存している場合は、disableFsBackup 設定がユースケースに適合するかどうかを評価する必要があります。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の disableFsBackup フィールドを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - csi
          - gcp
          - openshift
          disableFsBackup: true

    ここでは、以下のようになります。

    ノードエージェント
    DPA でノードエージェントを有効にすることを指定します。
    disableFsBackup
    disableFsBackup フィールドを true に設定することを指定します。

検証

  1. 次のコマンドを実行して、ノードエージェントのセキュリティーコンテキストが非 root として実行するように設定され、root ファイルシステムが readOnly あることを確認します。

    $ oc get daemonset node-agent -o yaml

    出力例は次のとおりです。

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      ...
      name: node-agent
      namespace: openshift-adp
      ...
    spec:
      ...
      template:
        metadata:
          ...
        spec:
          containers:
          ...
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                - ALL
              privileged: false
              readOnlyRootFilesystem: true
            ...
          nodeSelector:
            kubernetes.io/os: linux
          os:
            name: linux
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          serviceAccount: velero
          serviceAccountName: velero
          ....

    ここでは、以下のようになります。

    allowPrivilegeEscalation
    allowPrivilegeEscalation フィールドが false であることを指定します。
    privileged
    特権 フィールドが false であることを指定します。
    readOnlyRootFilesystem
    ルートファイルシステムが読み取り専用であることを指定します。
    runAsNonRoot
    ノードエージェントを非 root ユーザーとして実行することを指定します。
5.12.1.9. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.12.1.10. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.12.1.11. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.12.1.11.1. OpenShift Data Foundation での障害復旧用のオブジェクトバケット要求の作成

OpenShift Data Foundation の Multicloud Object Gateway (MCG) バケット backupStorageLocation にクラスターストレージを使用する場合は、OpenShift Web コンソールを使用して Object Bucket Claim (OBC) を作成します。

警告

Object Bucket Claim (OBC) の設定に失敗すると、バックアップが利用できなくなる可能性があります。

注記

特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。

MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。

手順

5.12.1.11.2. DataProtectionApplication CR で CSI を有効にする

CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。

手順

  • 次の例のように、DataProtectionApplication CR を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          defaultPlugins:
          - openshift
          - csi

    ここでは、以下のようになります。

    csi
    CSI の デフォルトプラグインを指定します。
5.12.1.11.3. DataProtectionApplication でノードエージェントを無効にする

バックアップに ResticKopia、または DataMover を使用していない場合は、DataProtectionApplication カスタムリソース (CR) の nodeAgent フィールドを無効にすることができます。nodeAgent を無効にする前に、OADP Operator がアイドル状態であり、バックアップを実行していないことを確認してください。

手順

  1. nodeAgent を無効にするには、enable フラグを false に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: false
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にします。
  2. nodeAgent を有効にするには、enable フラグを true に設定します。以下の例を参照してください。

    DataProtectionApplication CR の例

    # ...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
    # ...

    ここでは、以下のようになります。

    enable

    ノードエージェントを有効にします。

    ジョブをセットアップして、DataProtectionApplication CR の nodeAgent フィールドを有効または無効にすることができます。詳細は、「ジョブの使用による Pod でのタスクの実行」を参照してください。

5.13. OpenShift Virtualization を使用した OADP の設定

5.13.1. OpenShift Virtualization を使用した OpenShift API for Data Protection の設定

OADP Operator をインストールし、バックアップの場所を設定することで、OpenShift Virtualization を使用した OpenShift API for Data Protection (OADP) をインストールできます。その後、Data Protection Application をインストールできます。

OpenShift API for Data Protection を使用して仮想マシンをバックアップおよび復元します。

OpenShift Virtualization を使用した OpenShift API for Data Protection は、バックアップおよび復元のストレージオプションとして次のものをサポートしています。

  • Container Storage Interface (CSI) バックアップ
  • DataMover による Container Storage Interface (CSI) バックアップ

次のストレージオプションは対象外です。

  • ファイルシステムのバックアップと復元
  • ボリュームスナップショットのバックアップと復元

詳細は、File System Backup を使用してアプリケーションをバックアップする: Kopia または Restic を参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。詳細は、非接続環境での Operator Lifecycle Manager の使用 を参照してください。

重要

Red Hat は、OADP バージョン 1.3.0 以降と OpenShift Virtualization バージョン 4.14 以降の組み合わせのみをサポートします。

バージョン 1.3.0 より前の OADP は、OpenShift Virtualization のバックアップと復元ではサポートされていません。

5.13.1.1. OpenShift Virtualization を使用した OADP のインストールと設定

クラスター管理者は、OADP Operator をインストールして OADP をインストールします。

最新バージョンの OADP Operator は、Velero 1.16 をインストールします。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。

手順

  1. ストレージプロバイダーの指示に従って、OADP Operator をインストールします。
  2. kubevirt および openshift OADP プラグインを使用して Data Protection Application (DPA) をインストールします。
  3. Backup カスタムリソース (CR) を作成して、仮想マシンをバックアップします。

    警告

    Red Hat のサポート対象は、次のオプションに限られています。

    • CSI バックアップ
    • DataMover による CSI バックアップ

    Restore CR を作成して Backup CR を復元します。

5.13.1.2. Data Protection Application のインストール

DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。

前提条件

  • OADP Operator をインストールする。
  • オブジェクトストレージをバックアップロケーションとして設定する必要がある。
  • スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
  • バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である cloud-credentials を使用して Secret を作成する必要がある。

    注記

    インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。デフォルトの Secret がない場合、インストールは失敗します。

手順

  1. EcosystemInstalled Operators をクリックし、OADPOperator を選択します。
  2. Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、DataProtectionApplication マニフェストのパラメーターを更新します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: <dpa_sample>
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - kubevirt
            - gcp
            - csi
            - openshift
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            nodeSelector: <node_selector>
      backupLocations:
        - velero:
            provider: gcp
            default: true
            credential:
              key: cloud
              name: <default_secret>
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>

    ここでは、以下のようになります。

    namespace
    OADP のデフォルトの名前空間である openshift-adp を指定します。namespace は変数であり、設定可能です。
    kubevirt
    OpenShift 仮想化には kubevirt プラグインが必須であることを指定します。
    gcp
    バックアッププロバイダー (例: gcp) 用のプラグインを指定します (存在する場合)。
    csi
    CSI スナップショットを使用して PV をバックアップするには、csi プラグインが必須であることを指定します。csi プラグインは、Velero CSI ベータスナップショット API を使用します。スナップショットの場所を設定する必要はありません。
    openshift
    openshift プラグインが必須であることを指定します。
    リソースタイムアウト
    Velero CRD の可用性、ボリュームスナップショットの削除、バックアップリポジトリーの可用性など、複数の Velero リソースについてタイムアウトが発生するまでの待機時間を分単位で指定します。デフォルトは 10m です。
    ノードエージェント
    管理要求をサーバーにルーティングする管理エージェントを指定します。
    enable
    nodeAgent を有効にして File System Backup を実行する場合は、この値を true に設定します。
    アップローダータイプ
    アップローダーの種類を指定します。組み込み DataMover を使用するには、アップローダーとして kopia と入力します。nodeAgent はデーモンセットをデプロイします。これは、nodeAgent Pod が各ワーキングノード上で実行されることを意味します。File System Backup を設定するには、spec.defaultVolumesToFsBackup: trueBackup CR に追加します。
    nodeSelector
    Kopia が利用可能なノードを指定します。デフォルトでは、Kopia はすべてのノードで実行されます。
    provider
    バックアッププロバイダーを指定します。
    name
    バックアッププロバイダーにデフォルトのプラグインを使用する場合、シークレット の正しいデフォルト名を指定します。たとえば、cloud-credentials-gcp など です。カスタム名を指定すると、そのカスタム名がバックアップの場所に使用されます。Secret 名を指定しない場合は、デフォルトの名前が使用されます。
    bucket
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    prefix
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
  4. Create をクリックします。

検証

  1. 次のコマンドを実行して OpenShift API for Data Protection (OADP) リソースを表示し、インストールを検証します。

    $ oc get all -n openshift-adp
    NAME                                                     READY   STATUS    RESTARTS   AGE
    pod/oadp-operator-controller-manager-67d9494d47-6l8z8    2/2     Running   0          2m8s
    pod/node-agent-9cq4q                                     1/1     Running   0          94s
    pod/node-agent-m4lts                                     1/1     Running   0          94s
    pod/node-agent-pv4kr                                     1/1     Running   0          95s
    pod/velero-588db7f655-n842v                              1/1     Running   0          95s
    
    NAME                                                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
    service/oadp-operator-controller-manager-metrics-service   ClusterIP   172.30.70.140    <none>        8443/TCP   2m8s
    service/openshift-adp-velero-metrics-svc                   ClusterIP   172.30.10.0      <none>        8085/TCP   8h
    
    NAME                        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/node-agent    3         3         3       3            3           <none>          96s
    
    NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/oadp-operator-controller-manager    1/1     1            1           2m9s
    deployment.apps/velero                              1/1     1            1           96s
    
    NAME                                                           DESIRED   CURRENT   READY   AGE
    replicaset.apps/oadp-operator-controller-manager-67d9494d47    1         1         1       2m9s
    replicaset.apps/velero-588db7f655                              1         1         1       96s
  2. 次のコマンドを実行して、DataProtectionApplication (DPA) が調整されていることを確認します。

    $ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
    {"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
  3. typeReconciled に設定されていることを確認します。
  4. 次のコマンドを実行して、Backup Storage Location を確認し、PHASEAvailable であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
    dpa-sample-1   Available   1s               3d16h   true
警告

Microsoft Windows 仮想マシン (VM) の再起動直後に仮想マシンのバックアップを実行すると、PartiallyFailed エラーが発生してバックアップが失敗する可能性があります。これは、仮想マシンの起動直後は、Microsoft Windows Volume Shadow Copy Service (VSS) と Guest Agent (GA) サービスが準備されていないためです。VSS および GA サービスが準備されていないため、バックアップは失敗します。このような場合は、仮想マシンの起動後数分後にバックアップを再試行してください。

5.13.1.3. 単一仮想マシンのバックアップ

複数の仮想マシンが含まれる namespace があり、そのうちの 1 つだけをバックアップする場合は、ラベルセレクターを使用して、バックアップに含める必要がある仮想マシンをフィルターできます。app: vmname ラベルを使用して仮想マシンをフィルタリングできます。

前提条件

  • OADP Operator がインストールされている。
  • namespace 内で複数の仮想マシンが実行されている。
  • DataProtectionApplication (DPA) カスタムリソース (CR) に kubevirt プラグインを追加した。
  • DataProtectionApplication CR で BackupStorageLocation CR を設定しており、BackupStorageLocation が使用可能である。

手順

  1. 次の例に示すように、Backup CR を設定します。

    Backup CR の例

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: vmbackupsingle
      namespace: openshift-adp
    spec:
      snapshotMoveData: true
      includedNamespaces:
      - <vm_namespace>
      labelSelector:
        matchLabels:
          app: <vm_app_name>
      storageLocation: <backup_storage_location_name>

    ここでは、以下のようになります。

    vm_namespace
    仮想マシンを作成した名前空間の名前を指定します。
    vm_app_name
    バックアップが必要な仮想マシン名を指定します。
    バックアップストレージの場所名
    BackupStorageLocation CR の名前を指定します。
  2. Backup CR を作成するには、次のコマンドを実行します。

    $ oc apply -f <backup_cr_file_name>

    ここでは、以下のようになります。

    バックアップ CR ファイル名
    バックアップ CR ファイルの名前を指定します。
5.13.1.4. 1 つの仮想マシンの復元

Backup カスタムリソース (CR) のラベルセレクターを使用して 1 つの仮想マシンをバックアップした後、Restore CR を作成してバックアップを指すように設定できます。この復元操作では、1 つの仮想マシンが復元されます。

前提条件

  • OADP Operator がインストールされている。
  • ラベルセレクターを使用して 1 つの仮想マシンをバックアップした。

手順

  1. 次の例に示すように、Restore CR を設定します。

    Restore CR の例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: vmrestoresingle
      namespace: openshift-adp
    spec:
      backupName: vmbackupsingle
      restorePVs: true

    ここでは、以下のようになります。

    VM バックアップシングル
    1 つの仮想マシンのバックアップ名を指定します。
  2. 1 つの仮想マシンを復元するには、次のコマンドを実行します。

    $ oc apply -f <restore_cr_file_name>

    ここでは、以下のようになります。

    復元 CR ファイル名

    復元 CR ファイルの名前を指定します。

    注記

    仮想マシンのバックアップを復元すると、復元に割り当てられた Ceph Storage 容量が予想よりも高いことに気付く場合があります。この動作は、kubevirt の復元中、および仮想マシンのボリュームタイプが block の場合にのみ発生します。

    rbd sparsify ツールを使用して、ターゲットボリューム上のスペースを再利用します。詳細は、ターゲットボリューム上のスペースの再利用 を参照してください。

5.13.1.5. 複数の仮想マシンのバックアップから 1 つの仮想マシンを復元する

複数の仮想マシン (仮想マシン) が含まれるバックアップがあり、そのうち 1 つの仮想マシンのみを復元する場合は、Restore CR の LabelSelectors セクションを使用して、復元する仮想マシンを選択できます。確実に仮想マシンにアタッチされた永続ボリューム要求 (PVC) が正しく復元され、復元された仮想マシンが Provisioning 状態でスタックすることを回避するためには、app: <vm_name>kubevirt.io/created-by ラベルの両方を使用します。kubevirt.io/created-by ラベルと一致させるには、仮想マシンの DataVolume の UID を使用します。

前提条件

  • OADP Operator がインストールされている。
  • バックアップする必要がある仮想マシンにラベル付けした。
  • 複数の仮想マシンのバックアップがある。

手順

  1. 多数の仮想マシンのバックアップを作成する前に、次のコマンドを実行して仮想マシンにラベルが付けられていることを確認します。

    $ oc label vm <vm_name> app=<vm_name> -n openshift-adp
  2. 次の例に示すように、Restore CR でラベルセレクターを設定します。

    Restore CR の例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: singlevmrestore
      namespace: openshift-adp
    spec:
      backupName: multiplevmbackup
      restorePVs: true
      LabelSelectors:
        - matchLabels:
            kubevirt.io/created-by: <datavolume_uid>
        - matchLabels:
            app: <vm_name>

    ここでは、以下のようになります。

    データボリューム UID
    復元する仮想マシンの データボリューム の UID を指定します。たとえば、b6…​53a-ddd7-4d9d-9407-a0c…​e5 です。
    VM 名
    復元したい仮想マシンの名前を指定します。たとえば、test-vm です。
  3. 仮想マシンを復元するには、次のコマンドを実行します。

    $ oc apply -f <restore_cr_file_name>

    ここでは、以下のようになります。

    復元 CR ファイル名
    復元 CR ファイルの名前を指定します。
5.13.1.6. クライアントバースト設定と QPS 設定を使用した DPA の設定

バースト設定は、制限が適用されるまで velero サーバーに送信できる要求の数を決定するものです。バースト制限に達した後は、1 秒あたりのクエリー数 (QPS) 設定によって、1 秒あたりに送信できる追加の要求の数が決定されます。

バースト値と QPS 値を使用して Data Protection Application (DPA) を設定することにより、velero サーバーのバースト値と QPS 値を設定できます。バースト値と QPS 値は、DPA の dpa.configuration.velero.client-burst フィールドと dpa.configuration.velero.client-qps フィールドを使用して設定できます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の client-burst フィールドと client-qps フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
        velero:
          client-burst: 500
          client-qps: 300
          defaultPlugins:
            - openshift
            - aws
            - kubevirt

    ここでは、以下のようになります。

    クライアントバースト
    クライアントバースト 値を指定します。この例では、client-burst フィールドは 500 に設定されています。
    クライアント QPS
    クライアント QPS 値を指定します。この例では、client-qps フィールドは 300 に設定されています。
5.13.1.7. ノードエージェントを非 root および非特権ユーザーとして設定する

ノードエージェントのセキュリティーを強化するには、DataProtectionApplication (DPA) カスタムリソース (CR) の spec.configuration.velero.disableFsBackup 設定を使用して、OADP Operator ノードエージェントデーモンセットを非 root および非特権ユーザーとして実行するように設定できます。

spec.configuration.velero.disableFsBackup 設定を true に設定すると、ノードエージェントのセキュリティーコンテキストによってルートファイルシステムが読み取り専用に設定され、privileged フラグが false に設定されます。

注記

spec.configuration.velero.disableFsBackuptrue に設定すると、特権コンテナーの必要性がなくなり、読み取り専用のルートファイルシステムが適用されるため、ノードエージェントのセキュリティーが強化されます。

ただし、Kopia によるファイルシステムバックアップ (FSB) も無効になります。ワークロードがネイティブスナップショットをサポートしていないボリュームのバックアップに FSB に依存している場合は、disableFsBackup 設定がユースケースに適合するかどうかを評価する必要があります。

前提条件

  • OADP Operator がインストールされている。

手順

  • 次の例に示すように、DPA の disableFsBackup フィールドを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - csi
          - gcp
          - openshift
          disableFsBackup: true

    ここでは、以下のようになります。

    ノードエージェント
    DPA でノードエージェントを有効にすることを指定します。
    disableFsBackup
    disableFsBackup フィールドを true に設定することを指定します。

検証

  1. 次のコマンドを実行して、ノードエージェントのセキュリティーコンテキストが非 root として実行するように設定され、root ファイルシステムが readOnly あることを確認します。

    $ oc get daemonset node-agent -o yaml

    出力例は次のとおりです。

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      ...
      name: node-agent
      namespace: openshift-adp
      ...
    spec:
      ...
      template:
        metadata:
          ...
        spec:
          containers:
          ...
            securityContext:
              allowPrivilegeEscalation: false
              capabilities:
                drop:
                - ALL
              privileged: false
              readOnlyRootFilesystem: true
            ...
          nodeSelector:
            kubernetes.io/os: linux
          os:
            name: linux
          restartPolicy: Always
          schedulerName: default-scheduler
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          serviceAccount: velero
          serviceAccountName: velero
          ....

    ここでは、以下のようになります。

    allowPrivilegeEscalation
    allowPrivilegeEscalation フィールドが false であることを指定します。
    privileged
    特権 フィールドが false であることを指定します。
    readOnlyRootFilesystem
    ルートファイルシステムが読み取り専用であることを指定します。
    runAsNonRoot
    ノードエージェントを非 root ユーザーとして実行することを指定します。
5.13.1.8. ノードエージェントとノードラベルの設定

Data Protection Application (DPA) は、nodeSelector フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector フィールドは、推奨される形式のノード選択制約です。

手順

  1. カスタムラベルを追加して、選択した任意のノードでノードエージェントを実行します。

    $ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
    注記

    指定したラベルが、各ノードのラベルと一致する必要があります。

  2. ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector フィールドで使用します。

    configuration:
      nodeAgent:
        enable: true
        podConfig:
          nodeSelector:
            node-role.kubernetes.io/nodeAgent: ""

    次の例は nodeSelector のアンチパターンです。この例は、node-role.kubernetes.io/infra: ""node-role.kubernetes.io/worker: "" の両方のラベルがノードに存在しない限り機能しません。

        configuration:
          nodeAgent:
            enable: true
            podConfig:
              nodeSelector:
                node-role.kubernetes.io/infra: ""
                node-role.kubernetes.io/worker: ""
5.13.1.9. ノードエージェントのロードアフィニティーの設定

DataProtectionApplication (DPA) カスタムリソース (CR) の spec.podConfig.nodeSelector オブジェクトを使用して、特定のノードにノードエージェント Pod をスケジュールできます。

次の例を参照してください。この例を使用すると、ラベル label.io/role: cpu-1 および other-label.io/other-role: cpu-2 を持つノードにノードエージェント Pod をスケジュールできます。

...
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
      podConfig:
        nodeSelector:
          label.io/role: cpu-1
          other-label.io/other-role: cpu-2
        ...

DPA 仕様の nodeagent.loadAffinity オブジェクトを使用して、ノードエージェント Pod のスケジューリングにさらに制限を追加できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様の nodegent.loadAffinity オブジェクトを設定します。

    この例では、ラベル label.io/role: cpu-1 とラベル label.io/hostnamenode1 または node2 のいずれかに一致するノードにのみ、ノードエージェント Pod がスケジュールされるようにします。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/role: cpu-1
                matchExpressions:
                  - key: label.io/hostname
                    operator: In
                    values:
                      - node1
                      - node2
                      ...

    ここでは、以下のようになります。

    ロードアフィニティー
    matchLabels オブジェクトmatchExpressions オブジェクトを追加することで、loadAffinity オブジェクトを指定します。
    matchExpressions
    ノードエージェント Pod のスケジューリングに制限を追加する matchExpressions オブジェクトを指定します。
5.13.1.10. ノードエージェントのロードアフィニティーのガイドライン

DataProtectionApplication (DPA) カスタムリソース (CR) でノードエージェント loadAffinity オブジェクトを設定するには、次のガイドラインを使用してください。

  • 単純なノードマッチングの場合は、spec.nodeagent.podConfig.nodeSelector オブジェクトを使用します。
  • より複雑な状況の場合は、podConfig.nodeSelector オブジェクトを使用せずに loadAffinity.nodeSelector オブジェクトを使用します。
  • podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を使用できます。ただし、loadAffinity オブジェクトには podConfig オブジェクトと同等かそれ以上の制限が必要です。この場合、podConfig.nodeSelector のラベルは、loadAffinity.nodeSelector オブジェクトで使用されるラベルのサブセットである必要があります。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定した場合、matchExpressions フィールドと matchLabels フィールドは使用できません。
  • DPA で podConfig.nodeSelector オブジェクトと loadAffinity.nodeSelector オブジェクトの両方を設定するには、次の例を参照してください。

    ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadAffinity:
            - nodeSelector:
                matchLabels:
                  label.io/location: 'US'
                  label.io/gpu: 'no'
          podConfig:
            nodeSelector:
              label.io/gpu: 'no'
5.13.1.11. ノードエージェントの同時実行の設定

クラスター内の各ノードで同時に実行できるノードエージェント操作の最大数を制御できます。

Data Protection Application (DPA) の次のフィールドのいずれかを使用して設定できます。

  • globalConfig: すべてのノードにおけるノードエージェントのデフォルトの同時実行制限を定義します。
  • perNodeConfig: nodeSelector ラベルに基づいて、特定のノードに対して異なる同時実行制限を指定します。これにより、特定のノードが異なるリソース容量やロールを持つ柔軟な環境が実現されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 特定のノードに対して同時実行を使用する場合は、それらのノードにラベルを追加します。

    $ oc label node/<node_name> label.io/instance-type='large'
  2. DPA インスタンスの同時実行フィールドを設定します。

      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          loadConcurrency:
            globalConfig: 1
            perNodeConfig:
            - nodeSelector:
                  matchLabels:
                     label.io/instance-type: large
              number: 3

    ここでは、以下のようになります。

    globalConfig
    グローバル同時接続数を指定します。デフォルト値は 1 です。これは同時実行がなく、1 つの負荷のみが許可されることを意味します。globalConfig 値に制限はありません。
    label.io/instance-type
    ノードごとの同時実行性を示すラベルを指定します。
    number
    ノードごとの同時接続数を指定します。たとえば、インスタンスのタイプとサイズに基づき、ノードごとに多数の同時実行数を指定できます。ノードごとの同時実行数の範囲は、グローバル同時実行数と同じです。設定ファイルにノードごとの同時実行数とグローバル同時実行数が含まれている場合、ノードごとの同時実行数が優先されます。
5.13.1.12. リポジトリーメンテナンスの設定

OADP リポジトリーのメンテナンスはバックグラウンドジョブであり、ノードエージェント Pod とは別に設定できます。そのため、ノードエージェントが実行されているノードでも実行されていないノードでも、リポジトリーメンテナンス Pod をスケジュールできます。

DataProtectionApplication (DPA) カスタムリソース (CR) 内のリポジトリーメンテナンスジョブのアフィニティー設定を使用できるのは、バックアップリポジトリーとして Kopia を使用する場合だけです。

すべてのリポジトリーに影響するグローバルレベルでロードアフィニティーを設定できます。または、リポジトリーごとにロードアフィニティーを設定することもできます。グローバル設定とリポジトリーごとの設定を組み合わせて使用することもできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の一方または両方の方法を使用して、DPA 仕様の loadAffinity オブジェクトを設定します。

    • グローバル設定: 次の例に示すように、すべてのリポジトリーのロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            global:
              podResources:
                cpuRequest: "100m"
                cpuLimit: "200m"
                memoryRequest: "100Mi"
                memoryLimit: "200Mi"
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/gpu: 'no'
                    matchExpressions:
                      - key: label.io/location
                        operator: In
                        values:
                          - US
                          - EU

      ここでは、以下のようになります。

      リポジトリーメンテナンス
      例に示すように、repositoryMaintenance オブジェクトを指定します。
      global
      すべてのリポジトリーのロードアフィニティーを設定するための グローバル オブジェクトを指定します。
    • リポジトリーごとの設定: 次の例に示すように、リポジトリーごとにロードアフィニティーを設定します。

      ...
      spec:
        configuration:
          repositoryMaintenance:
            myrepositoryname:
              loadAffinity:
                - nodeSelector:
                    matchLabels:
                      label.io/cpu: 'yes'

      ここでは、以下のようになります。

      私のリポジトリー名
      各リポジトリーの repositoryMaintenance オブジェクトを指定します。
5.13.1.13. Velero ロードアフィニティーの設定

OADP をデプロイするごとに、1 つの Velero Pod が作成されます。その主な目的は、Velero のワークロードをスケジュールすることです。Velero Pod をスケジュールするには、DataProtectionApplication (DPA) カスタムリソース (CR) 仕様の velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを使用できます。

Velero Pod を特定のノードに割り当てるには、podConfig.nodeSelector オブジェクトを使用します。velero.loadAffinity オブジェクトを設定して、Pod レベルのアフィニティーとアンチアフィニティーを指定することもできます。

OpenShift のスケジューラーがルールを適用し、Velero Pod のデプロイメントのスケジューリングを実行します。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OADP Operator がインストールされている。
  • DPA CR が設定されている。

手順

  • 次の例に示すように、DPA 仕様で velero.podConfig.nodeSelector および velero.loadAffinity オブジェクトを設定します。

    • velero.podConfig.nodeSelector オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            podConfig:
              nodeSelector:
                some-label.io/custom-node-role: backup-core
    • velero.loadAffinity オブジェクトの設定:

      ...
      spec:
        configuration:
          velero:
            loadAffinity:
              - nodeSelector:
                  matchLabels:
                    label.io/gpu: 'no'
                  matchExpressions:
                    - key: label.io/location
                      operator: In
                      values:
                        - US
                        - EU
5.13.1.14. DPA の imagePullPolicy 設定のオーバーライド

OADP 1.4.0 以前では、Operator はすべてのイメージで Velero およびノードエージェント Pod の imagePullPolicy フィールドを Always に設定します。

OADP 1.4.1 以降では、Operator はまず、各イメージに sha256 または sha512 ダイジェストがあるかを確認し、それに応じて imagePullPolicy フィールドを設定します。

  • イメージにダイジェストがある場合、Operator は imagePullPolicyIfNotPresent に設定します。
  • イメージにダイジェストがない場合、Operator は imagePullPolicyAlways に設定します。

Data Protection Application (DPA) の spec.imagePullPolicy フィールドを使用して、imagePullPolicy フィールドをオーバーライドすることもできます。

前提条件

  • OADP Operator がインストールされている。

手順

  • 以下の例のように、DPA の spec.imagePullPolicy フィールドを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
        - name: default
          velero:
            config:
              insecureSkipTLSVerify: "true"
              profile: "default"
              region: <bucket_region>
              s3ForcePathStyle: "true"
              s3Url: <bucket_url>
            credential:
              key: cloud
              name: cloud-credentials
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero
            provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - openshift
            - aws
            - kubevirt
            - csi
      imagePullPolicy: Never

    ここでは、以下のようになります。

    imagePullPolicy
    imagePullPolicy の値を指定します。この例では、imagePullPolicy フィールドが Never に設定されています。
5.13.1.15. 増分バックアップのサポートについて

OADP は、コンテナー化されたワークロードと OpenShift Virtualization ワークロードの両方で、block および Filesystem の永続ボリュームの増分バックアップをサポートしています。次の表は、File System Backup (FSB)、Container Storage Interface (CSI)、および CSI Data Mover のサポート状況をまとめたものです。

Expand
表5.4 コンテナー化されたワークロードの OADP バックアップのサポートマトリックス
ボリュームモードFSB - ResticFSB - KopiaCSICSI Data Mover

ファイルシステム

S [1]、I [2]

S [1]、I [2]

S [1]

S [1]、I [2]

ブロック

N [3]

N [3]

S [1]

S [1]、I [2]

Expand
表5.5 OpenShift Virtualization ワークロードの OADP バックアップのサポートマトリックス
ボリュームモードFSB - ResticFSB - KopiaCSICSI Data Mover

ファイルシステム

N [3]

N [3]

S [1]

S [1]、I [2]

ブロック

N [3]

N [3]

S [1]

S [1]、I [2]

  1. バックアップをサポート
  2. 増分バックアップをサポート
  3. サポート対象外
注記

CSI Data Mover バックアップでは、uploaderType に関係なく Kopia が使用されます。

5.14. 複数の Backup Storage Location を含む OADP の設定

5.14.1. 複数の Backup Storage Location を使用した OpenShift API for Data Protection (OADP) の設定

Data Protection Application (DPA) で複数のバックアップ保存場所 (BSL) を設定することで、バックアップを異なるリージョンやストレージプロバイダーに分散して保存できます。これにより、バックアップストラテジーに柔軟性と冗長性がもたらされます。

OADP は、複数の BSL を設定できるように、複数の認証情報をサポートしています。そのため、どの BSL でも使用する認証情報を指定できます。

5.14.1.1. 複数の BSL を使用した DPA の設定

プロバイダー固有の認証情報を使用して、複数の BackupStorageLocation (BSL) リソースを使用して DataProtectionApplication (DPA) カスタムリソース (CR) を設定し、バックアップを異なる場所に保存します。これにより、バックアップの配布機能と、場所に応じた復元機能が提供されます。

たとえば、以下の 2 つの BSL を設定済みだとします。

  • DPA に 1 つの BSL を設定し、それをデフォルトの BSL として設定した。
  • BackupStorageLocation CR を使用して、別の BSL を別途作成した。

DPA を通じて作成された BSL をすでにデフォルトとして設定しているため、別途作成した BSL を再度デフォルトとして設定することはできません。つまり、任意の時点において、デフォルトの BSL として設定できる BSL は 1 つだけです。

前提条件

  • OADP Operator をインストールする。
  • クラウドプロバイダーによって提供される認証情報を使用してシークレットを作成する。

手順

  1. 複数の BackupStorageLocation CR を使用して DataProtectionApplication CR を設定します。以下の例を参照してください。

    DPA の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    backupLocations:
      - name: aws
        velero:
          provider: aws
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            region: <region_name>
            profile: "default"
          credential:
            key: cloud
            name: cloud-credentials
      - name: odf
        velero:
          provider: aws
          default: false
          objectStorage:
            bucket: <bucket_name>
            prefix: <prefix>
          config:
            profile: "default"
            region: <region_name>
            s3Url: <url>
            insecureSkipTLSVerify: "true"
            s3ForcePathStyle: "true"
          credential:
            key: cloud
            name: <custom_secret_name_odf>
    #...

    ここでは、以下のようになります。

    名前: aws
    最初の BSL の名前を指定します。
    デフォルト: true
    この BSL がデフォルトの BSL であることを示します。Backup CR に BSL が設定されていない場合は、デフォルトの BSL が使用されます。デフォルトとして設定できる BSL は 1 つだけです。
    <bucket_name>
    バケット名を指定します。
    <prefix>
    Velero バックアップのプレフィックスを指定します。たとえば、velero
    < 地域名 >
    バケットの AWS リージョンを指定します。
    クラウド認証情報
    作成したデフォルトの Secret オブジェクトの名前を指定します。
    名前: odf
    2 番目の BSL の名前を指定します。
    <url>
    S3 エンドポイントの URL を指定します。
    <custom_secret_name_odf>
    シークレット の正しい名前を指定します。たとえば、custom_secret_name_odfSecret 名を指定しない場合は、デフォルトの名前が使用されます。
  2. バックアップ CR で使用する BSL を指定します。以下の例を参照してください。

    バックアップ CR の例

    apiVersion: velero.io/v1
    kind: Backup
    # ...
    spec:
      includedNamespaces:
      - <namespace>
      storageLocation: <backup_storage_location>
      defaultVolumesToFsBackup: true

    ここでは、以下のようになります。

    <namespace>
    バックアップする名前空間を指定します。
    < バックアップストレージの場所 >
    保存場所を指定します。
5.14.1.2. 異なるクラウド認証情報を使用して 2 つのバックアップ BSL を設定する

アプリケーションを複数のストレージターゲットにバックアップするために、異なるクラウド認証情報を使用して 2 つのバックアップストレージ場所を設定します。この設定により、冗長性を確保するために、バックアップを複数のストレージプロバイダーに分散させることができます。

前提条件

  • OADP Operator をインストールする。
  • Backup Storage Location として、AWS S3 と Multicloud Object Gateway (MCG) の 2 つを設定する。
  • Red Hat OpenShift クラスターにデータベースがデプロイされたアプリケーションがある。

手順

  1. 次のコマンドを実行して、AWS S3 ストレージプロバイダー用の最初の Secret をデフォルト名で作成します。

    $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=<aws_credentials_file_name>

    ここでは、以下のようになります。

    <aws_credentials_file_name>
    AWS S3 のクラウド認証情報ファイルの名前を指定します。
  2. 次のコマンドを実行して、カスタム名を持つ MCG 用の 2 番目の Secret を作成します。

    $ oc create secret generic mcg-secret -n openshift-adp --from-file cloud=<MCG_credentials_file_name>

    ここでは、以下のようになります。

    <MCG_ 認証情報ファイル名 >
    MCG のクラウド認証情報ファイルの名前を指定します。mcg-secret カスタムシークレットの名前をメモします。
  3. 次の例に示すように、2 つの BSL を使用して DPA を設定します。

    DPA の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: two-bsl-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - name: aws
        velero:
          config:
            profile: default
            region: <region_name>
          credential:
            key: cloud
            name: cloud-credentials
          default: true
          objectStorage:
            bucket: <bucket_name>
            prefix: velero
          provider: aws
      - name: mcg
        velero:
          config:
            insecureSkipTLSVerify: "true"
            profile: noobaa
            region: <region_name>
            s3ForcePathStyle: "true"
            s3Url: <s3_url>
          credential:
            key: cloud
            name: mcg-secret
          objectStorage:
            bucket: <bucket_name_mcg>
            prefix: velero
          provider: aws
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - openshift
          - aws

    ここでは、以下のようになります。

    < 地域名 >
    バケットの AWS リージョンを指定します。
    <bucket_name>
    AWS S3 バケット名を指定します。
    リージョン: < 地域名 >
    MCG のドキュメントに記載されている命名規則に従って、リージョンを指定します。
    <s3_url>
    MCG の S3 エンドポイントの URL を指定します。
    マクガシークレット
    MCG ストレージ用のカスタムシークレットの名前を指定します。
    <bucket_name_mcg>
    MCG バケット名を指定します。
  4. 次のコマンドを実行して DPA を作成します。

    $ oc create -f <dpa_file_name>

    ここでは、以下のようになります。

    <dpa_ ファイル名 >
    設定した DPA のファイル名を指定します。
  5. 次のコマンドを実行して、DPA が調整されたことを確認します。

    $ oc get dpa -o yaml
  6. 次のコマンドを実行して、BSL が使用可能であることを確認します。

    $ oc get bsl

    出力例

    NAME   PHASE       LAST VALIDATED   AGE     DEFAULT
    aws    Available   5s               3m28s   true
    mcg    Available   5s               3m28s

  7. デフォルトの BSL を使用してバックアップ CR を作成します。

    注記

    次の例では、バックアップ CR で storageLocation フィールドが指定されていません。

    バックアップ CR の例

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup1
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <mysql_namespace>
      defaultVolumesToFsBackup: true

    ここでは、以下のようになります。

    <mysql_namespace>
    クラスターにインストールされているアプリケーションの名前空間を指定します。
  8. 次のコマンドを実行してバックアップを作成します。

    $ oc apply -f <backup_file_name>

    ここでは、以下のようになります。

    < バックアップファイル名 >
    バックアップ CR ファイルの名前を指定します。
  9. 次のコマンドを実行して、デフォルトの BSL を使用したバックアップが完了したことを確認します。

    $ oc get backups.velero.io <backup_name> -o yaml

    ここでは、以下のようになります。

    <backup_name>
    バックアップの名前を指定します。
  10. MCG を BSL として使用してバックアップ CR を作成します。次の例では、2 番目の storageLocation 値をバックアップ CR の作成時に指定していることに注意してください。

    バックアップ CR の例

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup1
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <mysql_namespace>
      storageLocation: mcg
      defaultVolumesToFsBackup: true

    ここでは、以下のようになります。

    <mysql_namespace>
    クラスターにインストールされているアプリケーションの名前空間を指定します。
    マイクログラム
    2 番目の保存場所を指定します。
  11. 次のコマンドを実行して、2 番目のバックアップを作成します。

    $ oc apply -f <backup_file_name>

    ここでは、以下のようになります。

    < バックアップファイル名 >
    バックアップ CR ファイルの名前を指定します。
  12. 次のコマンドを実行して、保存場所が MCG であるバックアップが完了したことを確認します。

    $ oc get backups.velero.io <backup_name> -o yaml

    ここでは、以下のようになります。

    <backup_name>
    バックアップの名前を指定します。

5.15. 複数の Volume Snapshot Location を使用した OADP の設定

5.15.1. 複数の Volume Snapshot Location を使用した OpenShift API for Data Protection (OADP) を設定

Data Protection Application (DPA) で複数の Volume Snapshot Location (VSL) を設定することで、異なるクラウドプロバイダーのリージョンにボリュームスナップショットを保存できます。これにより、地理的な冗長性と地域的な障害復旧能力が確保されます。

5.15.1.1. 複数の VSL を使用した DPA の設定

永続ボリュームと同じリージョンにあるプロバイダー固有の認証情報を使用して、複数の Volume Snapshot Location (VSL) を指定して、DataProtectionApplication (DPA) カスタムリソース (CR) を設定します。これにより、ボリュームスナップショットを複数のストレージターゲットに分散させることができます。

手順

  • 次の例に示すように、DPA CR を複数の VSL で設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    snapshotLocations:
      - velero:
          config:
            profile: default
            region: <region>
          credential:
            key: cloud
            name: cloud-credentials
          provider: aws
      - velero:
          config:
            profile: default
            region: <region>
          credential:
            key: cloud
            name: <custom_credential>
          provider: aws
    #...

    ここでは、以下のようになります。

    < 領域 >
    リージョンを指定します。スナップショットの場所は、永続ボリュームと同じリージョンにある必要があります。
    < カスタム認証情報 >
    カスタム認証情報の名前を指定します。

5.16. OADP のアンインストール

5.16.1. OpenShift API for Data Protection のアンインストール

OpenShift API for Data Protection (OADP) をアンインストールするには、OADP Operator を削除します。詳細は、クラスターからの Operator の削除 を参照してください。

5.17. OADP のバックアップ

5.17.1. アプリケーションのバックアップ

Kopia または Restic を使用して、スナップショット、CSI、またはファイルシステムバックアップによる バックアップ カスタムリソース (CR) を作成することで、アプリケーションをバックアップします。

頻繁にバックアップを行うと、Backup Storage Location のストレージが消費される可能性があります。S3 バケットなどの非ローカルバックアップを使用する場合は、バックアップの頻度、保持期間、永続ボリューム (PV) のデータ量を確認してください。すべてのバックアップは有効期限が切れるまで保持されるため、スケジュールの有効期限 (TTL) 設定を確認してください。

OADP を使用してアプリケーションをバックアップする際の以下の情報を確認してください。

  • Backup CR は、Kubernetes リソースと内部イメージのバックアップファイルを S3 オブジェクトストレージに作成します。
  • Velero のスナップショット機能を使用して永続ボリュームに保存されているデータをバックアップする場合、OpenShift オブジェクトデータとともに、スナップショット関連の情報のみが S3 バケットに保存されます。
  • クラウドプロバイダーがネイティブスナップショット API を備えている場合、または CSI スナップショットをサポートしている場合、Backup CR はスナップショットを作成することによって永続ボリューム (PV) をバックアップします。CSI スナップショットの操作に関する詳細は、CSI スナップショットを使用した永続ボリュームのバックアップを 参照してください。CSI ボリュームスナップショットの詳細は、CSI ボリュームスナップショット を参照してください。
  • 基盤となるストレージまたはバックアップバケットが同じクラスターの一部である場合、障害発生時にデータが失われる可能性があります。バックアップストレージは必ずクラスター外に設定してください。
  • クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、Kopia または Restic を使用してバックアップを作成できます。ファイルシステムバックアップを使用したアプリケーションのバックアップ: Kopia または Restic を 参照してください。
  • バックアップ操作の前または後にコマンドを実行するためのバックアップフックを作成できます。バックアップフックの作成を 参照してください。
  • Backup CR の代わりに Schedule CR を作成することにより、バックアップをスケジュールできます。Schedule CR を使用したバックアップのスケジューリング設定 を参照してください。
  • OpenShift Container Platform 4.20 は、Restic 復元プロセス中に Pod の準備を妨げる可能性のある Pod セキュリティーアドミッション (PSA) ポリシーを適用します。

    この問題は OADP 1.1.6 および OADP 1.2.2 リリースで解決されており、これらのリリースにアップグレードすることが推奨されます。

    詳細は、PSA ポリシーの変更により Red Hat OpenShift Container Platform 4.15 で Restic リストアが部分的に失敗する を参照してください。

重要

OpenShift API for Data Protection (OADP) は、他のソフトウェアで作成されたボリュームスナップショットのバックアップをサポートしていません。

重要

…/.snapshot ディレクトリーは、複数の NFS サーバーによって使用されるスナップショットコピーディレクトリーです。このディレクトリーにはデフォルトで読み取り専用アクセスが設定されているため、Velero はこのディレクトリーに復元できません。

Velero に .snapshot ディレクトリーへの書き込みアクセス権を付与しないでください。また、このディレクトリーへのクライアントアクセスを無効にしてください。

5.17.1.1. バックアップと復元を実行する前にリソースをプレビューする

バックアップおよび復元操作の予行演習を行うことで、バックアップおよび復元リソースを事前に確認しておきましょう。これにより、完全バックアップまたは復元を実行する前に、どのリソースが含まれるかを確認できます。

OADP は、タイプ、namespace、またはラベルに基づいてアプリケーションリソースをバックアップします。そのため、バックアップが完了した後にリソースを確認できます。同様に、復元操作が完了した後も、namespace、永続ボリューム (PV)、またはラベルに基づいて、復元されたオブジェクトを確認できます。

前提条件

  • OADP Operator がインストールされている。

手順

  1. 実際のバックアップを実行する前に、バックアップに含まれるリソースをプレビューするには、次のコマンドを実行します。

    $ velero backup create <backup-name> --snapshot-volumes false

    --snapshot-volumes パラメーターの値を false に指定します。

  2. バックアップリソースの詳細を確認するには、次のコマンドを実行します。

    $ velero describe backup <backup_name> --details

    <backup_name> を バックアップの名前に置き換えてください。

  3. 実際の復元を実行する前に、復元に含まれるリソースをプレビューするには、次のコマンドを実行します。

    $ velero restore create --from-backup <backup_name>

    <backup_name> を バックアップの名前に置き換えてください。

    重要

    velero restore create コマンドは、クラスター内に復元リソースを作成します。リソースを確認した後、復元中に作成されたリソースを削除する必要があります。

  4. 復元リソースの詳細を確認するには、次のコマンドを実行します。

    $ velero describe restore <restore_name> --details

    <restore_name> を 復元の名前に置き換えてください。

5.17.2. Backup CR の作成

バックアップ カスタムリソース (CR) を作成することで、Kubernetes リソース、内部イメージ、および永続ボリューム (PV) をバックアップします。これは、障害復旧のためにアプリケーションデータと設定を保護するのに役立ちます。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールしている。
  • DataProtectionApplication CR が Ready 状態である。
  • バックアップロケーションの前提条件:

    • Velero 用に S3 オブジェクトストレージを設定する必要があります。
    • DataProtectionApplication CR でバックアップの場所を設定する必要があります。
  • スナップショットの場所の前提条件:

    • クラウドプロバイダーには、ネイティブスナップショット API が必要であるか、Container Storage Interface (CSI) スナップショットをサポートしている必要があります。
    • CSI スナップショットの場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成する必要があります。
    • DataProtectionApplication CR でボリュームの場所を設定する必要があります。

手順

  1. 次のコマンドを入力して、backupStorageLocations CR を取得します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp
    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    openshift-adp   velero-sample-1   Available   11s              31m
  2. 次の例のように、Backup CR を作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      labels:
        velero.io/storage-location: default
      namespace: openshift-adp
    spec:
      hooks: {}
      includedNamespaces:
      - <namespace>
      includedResources: []
      excludedResources: []
      storageLocation: <velero-sample-1>
      ttl: 720h0m0s
      labelSelector:
        matchLabels:
          app: <label_1>
          app: <label_2>
          app: <label_3>
      orLabelSelectors:
      - matchLabels:
          app: <label_1>
          app: <label_2>
          app: <label_3>

    ここでは、以下のようになります。

    <namespace>
    バックアップする名前空間の配列を指定します。
    includedResources
    オプション: バックアップに含めるリソースの配列を指定します。リソースは、短縮名 (podspo など) または完全修飾名で指定できます。指定しない場合、すべてのリソースが含まれます。
    excludedResources
    オプション: バックアップから除外するリソースの配列を指定します。リソースは、短縮名 (podspo など) または完全修飾名で指定できます。
    <velero-sample-1>
    backupStorageLocations CR の名前を指定します。
    labelSelector
    指定された すべての ラベルを持つバックアップリソースの{キー、値}ペアのマップを指定します。
    orLabelSelectors
    指定されたラベルを 1 つ以上 持つバックアップリソースの{キー、値}ペアのマップを指定します。
  3. Backup CR のステータスが Completed したことを確認します。

    $ oc get backups.velero.io -n openshift-adp <backup> -o jsonpath='{.status.phase}'

5.17.3. CSI スナップショットを使用した永続ボリュームのバックアップ

バックアップ CR を作成する前に VolumeSnapshotClass カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。これにより、クラウドネイティブのスナップショット機能を活用し、より高速かつ効率的なバックアップを実現できます。

詳細は、CSI ボリュームのスナップショット および バックアップ CR の作成を 参照してください。

5.17.3.1. CSI スナップショットを使用した永続ボリュームのバックアップ

永続ボリュームを Container Storage Interface (CSI) スナップショットでバックアップするために、VolumeSnapshotClass カスタムリソース (CR) を設定します。これは、CSI ベースのバックアップ操作のためにクラウドストレージを準備するのに役立ちます。

前提条件

  • クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
  • DataProtectionApplication CR で CSI を有効にする必要があります。

手順

  • metadata.labels.velero.io/csi-volumesnapshot-class: "true" のキー: 値ペアを VolumeSnapshotClass CR に追加します。

    設定ファイルのサンプル

    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshotClass
    metadata:
      name: <volume_snapshot_class_name>
      labels:
        velero.io/csi-volumesnapshot-class: "true"
      annotations:
        snapshot.storage.kubernetes.io/is-default-class: true
    driver: <csi_driver>
    deletionPolicy: <deletion_policy_type>

    ここでは、以下のようになります。

    velero.io/csi-volumesnapshot-class: "true"
    true に設定する必要があります。
    snapshot.storage.kubernetes.io/is-default-class: true
    同じドライバーを使用して別のクラスターでこのボリュームを復元する場合は、snapshot.storage.kubernetes.io/is-default-class パラメーターを true ではなく false に設定してください。そうしないと、復元が部分的に失敗します。
    < 削除ポリシータイプ >
    削除ポリシーの種類を指定します。OADP は、CSI および Data Mover のバックアップと復元に対して、Retain および Delete 削除ポリシータイプをサポートしています。

次のステップ

  • これで、Backup CR を作成できます。

5.17.4. File System Backup を使用してアプリケーションをバックアップする: Kopia または Restic

スナップショットが利用できない場合は、OADP ファイルシステムバックアップ (FSB) を Kopia または Restic と組み合わせて使用し、Pod にアタッチされた Kubernetes ボリュームのバックアップと復元を行います。これは、NFS やその他のスナップショット以外のストレージ上のアプリケーションデータを保護するのに役立ちます。

クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、FSB を使用してバックアップを作成できます。

FSB と OADP の統合により、ほぼすべてのタイプの Kubernetes ボリュームをバックアップおよび復元するためのソリューションが提供されます。この統合は OADP の追加機能であり、既存の機能を置き換えるものではありません。

Backup カスタムリソース (CR) を編集して、Kopia または Restic で Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。

DataProtectionApplication CR でスナップショットの場所を指定する必要はありません。

注記

OADP バージョン 1.3 以降では、アプリケーションのバックアップに Kopia または Restic を使用できます。

ビルトイン DataMover の場合は、Kopia を使用する必要があります。

OADP バージョン 1.2 以前の場合、アプリケーションのバックアップには Restic のみ使用できます。

重要

FSB は、hostPath ボリュームのバックアップをサポートしません。詳細は、FSB の制限事項 を参照してください。

重要

…/.snapshot ディレクトリーは、複数の NFS サーバーによって使用されるスナップショットコピーディレクトリーです。このディレクトリーにはデフォルトで読み取り専用アクセスが設定されているため、Velero はこのディレクトリーに復元できません。

Velero に .snapshot ディレクトリーへの書き込みアクセス権を付与しないでください。また、このディレクトリーへのクライアントアクセスを無効にしてください。

5.17.4.1. File System Backup を使用したアプリケーションのバックアップ

Kopia をアップローダーとして使用し、ファイルシステムバックアップ (FSB) を用いてアプリケーションをバックアップするための バックアップ カスタムリソース (CR) を作成します。これは、スナップショットが利用できない場合や NFS データボリュームを使用している場合に、Pod にアタッチされた Kubernetes ボリュームを保護するのに役立ちます。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールしている。
  • DataProtectionApplication CR で spec.configuration.nodeAgent.enablefalse に設定して、デフォルトの nodeAgent インストールを無効にしていない。
  • DataProtectionApplication CR で spec.configuration.nodeAgent.uploaderTypekopia または restic に設定して、Kopia または Restic をアップローダーとして選択している。
  • DataProtectionApplication CR が Ready 状態である。

手順

  • 次の例のように、Backup CR を作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      labels:
        velero.io/storage-location: default
      namespace: openshift-adp
    spec:
      defaultVolumesToFsBackup: true
    ...

    ここでは、以下のようになります。

    defaultVolumesToFsBackup: true
    OADP バージョン 1.2 以降において、仕様 ブロック内の FSB 設定を指定します。OADP バージョン 1.1 では、代わりに defaultVolumesToRestic: true を追加してください。

5.17.5. バックアップフックの作成

Backup カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのバックアップフックを作成します。これにより、データベースの静止やデータのディスクへの書き込みなど、バックアップ前およびバックアップ後の処理を実行できます。

コマンドは、カスタムアクション処理の前 (プリ フック)、またはすべてのカスタムアクションが完了し、カスタムアクションで指定された追加アイテムがバックアップされた後 (ポスト フック) に実行するように設定できます。

手順

  • 次の例のように、Backup CR の spec.hooks ブロックにフックを追加します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: <backup>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace>
            excludedNamespaces:
            - <namespace>
            includedResources: []
            - pods
            excludedResources: []
            labelSelector:
              matchLabels:
                app: velero
                component: server
            pre:
              - exec:
                  container: <container>
                  command:
                  - /bin/uname
                  - -a
                  onError: Fail
                  timeout: 30s
            post:
    ...

    ここでは、以下のようになります。

    <namespace>
    オプション: フックを適用する名前空間を指定します。この値が指定されていない場合、フックはすべての namespace に適用されます。
    除外された名前空間
    オプション: フックを適用しない名前空間を指定します。
    Pod
    現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
    excludedResources
    オプション: フックを適用しないリソースを指定します。
    labelSelector
    オプション: このフックは、ラベルに一致するオブジェクトにのみ適用されます。この値が指定されていない場合、フックはすべてのオブジェクトに適用されます。
    pre
    バックアップ前に実行するフックの配列を指定します。
    <container>
    オプション: コマンドを実行するコンテナーを指定します。コンテナーが指定されていない場合、コマンドは Pod 内の最初のコンテナーで実行されます。
    /bin/uname
    追加する 初期化 コンテナーのエントリーポイントを指定します。
    onError: 失敗
    エラー処理の動作を指定します。許容される値は FailContinue です。デフォルトは Fail です。
    タイムアウト:30 秒
    オプション: コマンドの実行を待つ時間を指定します。デフォルトは 30s です。
    post
    バックアップ後に実行するフックの配列を指定します。パラメーターはバックアップ前のフックと同じです。

5.17.6. Schedule CR を使用したバックアップのスケジュール設定

Cron 式を使用して スケジュール カスタムリソース (CR) を作成することで、バックアップ操作をスケジュールできます。これにより、アプリケーションデータの定期的なバックアップを自動化できます。

Backup CR の代わりに Schedule カスタムリソース (CR) を作成して、バックアップをスケジュールします。

警告

バックアップスケジュールでは、別のバックアップが作成される前にバックアップを数量するための時間を十分確保してください。

たとえば、namespace のバックアップに通常 10 分かかる場合は、15 分ごとよりも頻繁にバックアップをスケジュールしないでください。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールしている。
  • DataProtectionApplication CR が Ready 状態である。

手順

  1. backupStorageLocations CR を取得します。

    $ oc get backupStorageLocations -n openshift-adp
    NAMESPACE       NAME              PHASE       LAST VALIDATED   AGE   DEFAULT
    openshift-adp   velero-sample-1   Available   11s              31m
  2. 次の例のように、Schedule CR を作成します。

    $ cat << EOF | oc apply -f -
    apiVersion: velero.io/v1
    kind: Schedule
    metadata:
      name: <schedule>
      namespace: openshift-adp
    spec:
      schedule: 0 7 * * *
      template:
        hooks: {}
        includedNamespaces:
        - <namespace>
        storageLocation: <velero-sample-1>
        defaultVolumesToFsBackup: true
        ttl: 720h0m0s
    EOF

    ここでは、以下のようになります。

    スケジュール: 0 7 * * *

    バックアップをスケジュールするための cron 式を指定します。たとえば、0 7 * * * と指定 すると、毎日 7:00 にバックアップが実行されます。

    注記

    特定の間隔でバックアップをスケジュールするには、次の形式で <duration_in_minutes> を入力します。

      schedule: "*/10 * * * *"

    引用符 (" ") の間に分の値を入力します。

    <namespace>
    バックアップする名前空間の配列を指定します。
    <velero-sample-1>
    backupStorageLocations CR の名前を指定します。
    defaultVolumesToFsBackup: true
    オプション: OADP バージョン 1.2 以降では、Restic を使用してボリュームのバックアップを実行するときに、defaultVolumesToFsBackup: true キーと値のペアを設定に追加します。OADP バージョン 1.1 では、Restic でボリュームをバックアップするときに、defaultVolumesToRestic: true のキーと値のペアを追加します。

検証

  • スケジュールされたバックアップの実行後に、Schedule CR のステータスが Completed となっていることを確認します。

    $ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'

5.17.7. バックアップの削除

バックアップを削除するには、DeleteBackupRequest カスタムリソース (CR) を作成するか、velero backup delete コマンドを実行します。これにより、ストレージ容量を解放し、古いバックアップアーティファクトを削除することができます。

ボリュームバックアップアーティファクトは、バックアップ方法に応じて、異なるタイミングで削除されます。

  • Restic: アーティファクトは、バックアップが削除された後、次のフルメンテナンスサイクル中に削除されます。
  • Container Storage Interface (CSI): アーティファクトは、バックアップが削除されると直ちに削除されます。
  • Kopia: アーティファクトは、バックアップが削除されてから、Kopia リポジトリーのフルメンテナンスサイクルが 3 回実行された後に削除されます。
5.17.7.1. DeleteBackupRequest CR を作成してバックアップを削除する

DeleteBackupRequest カスタムリソース (CR) を作成してバックアップを削除します。これにより、特定のバックアップとその関連ボリュームアーティファクトをストレージから削除できます。

前提条件

  • アプリケーションのバックアップを実行した。

手順

  1. DeleteBackupRequest CR マニフェストファイルを作成します。

    apiVersion: velero.io/v1
    kind: DeleteBackupRequest
    metadata:
      name: deletebackuprequest
      namespace: openshift-adp
    spec:
      backupName: <backup_name>

    <backup_name> を バックアップの名前に置き換えてください。

  2. DeleteBackupRequest CR を適用してバックアップを削除します。

    $ oc apply -f <deletebackuprequest_cr_filename>
5.17.7.2. Velero CLI を使用してバックアップを削除する

Velero CLI を使用して velero backup delete コマンドを実行することで、バックアップを削除できます。これにより、バックアップとその関連ボリュームアーティファクトをストレージから迅速に削除できます。

前提条件

  • アプリケーションのバックアップを実行した。
  • Velero CLI がダウンロード済みであり、クラスター内の Velero バイナリーにアクセスできる。

手順

  • バックアップを削除するには、次の Velero コマンドを実行します。

    $ velero backup delete <backup_name> -n openshift-adp

    <backup_name> を バックアップの名前に置き換えてください。

5.17.7.3. Kopia リポジトリーのメンテナンスについて

Kopia リポジトリーのメンテナンスには、クイックとフルという 2 種類があり、インデックスのパフォーマンスを最適化し、ガベージコレクションを実行するために自動的に実行されます。この 2 つのタイプを理解することで、メンテナンスサイクルやバックアップアーティファクトが削除されるまでにかかる時間を把握しやすくなります。

クイックメンテナンス
  • インデックス Blob の数 (n) を抑えるために 1 時間ごとに実行されます。インデックスの数が多いと、Kopia 操作のパフォーマンスに悪影響が及びます。
  • 同じメタデータの別のコピーが存在することを確認してから、リポジトリーからメタデータを削除します。
フルメンテナンス
  • 不要になったリポジトリーコンテンツのガベージコレクションを実行するために、24 時間ごとに実行されます。
  • フルメンテナンスのタスクである snapshot-gc が、スナップショットマニフェストからアクセスできなくなったすべてのファイルとディレクトリーリストを検索し、それらを削除済みとしてマークします。
  • フルメンテナンスは、クラスター内でアクティブなすべてのスナップショット内のすべてのディレクトリーをスキャンする必要があるため、リソースを大量に消費する操作です。
5.17.7.3.1. OADP における Kopia のメンテナンス

repo-maintain-job ジョブは、次の例に示すように、OADP がインストールされている namespace で実行されます。

pod/repo-maintain-job-173...2527-2nbls                             0/1     Completed   0          168m
pod/repo-maintain-job-173....536-fl9tm                             0/1     Completed   0          108m
pod/repo-maintain-job-173...2545-55ggx                             0/1     Completed   0          48m

repo-maintain-job のログで、バックアップオブジェクトストレージ内のクリーンアップとアーティファクトの削除に関する詳細を確認できます。次の例に示すように、repo-maintain-job では、次のフルメンテナンスサイクルの予定日時に関する情報を確認できます。

not due for full maintenance cycle until 2024-00-00 18:29:4
重要

バックアップオブジェクトストレージからオブジェクトを削除するには、フルメンテナンスサイクルを 3 回正常に実行する必要があります。つまり、バックアップオブジェクトストレージ内のすべてのアーティファクトが削除されるまでに、最大 72 時間かかると予想されます。

5.17.7.4. バックアップリポジトリーの削除

バックアップ削除プロセスを完了するには、backuprepository カスタムリソース (CR) を削除してください。これにより、すべてのバックアップメタデータとアーティファクトがストレージから完全に削除されていることを確認できます。

バックアップを削除し、関連するアーティファクトを削除する Kopia リポジトリーのメンテナンスサイクルが完了すると、そのバックアップはどのメタデータオブジェクトやマニフェストオブジェクトからも参照されなくなります。

前提条件

  • アプリケーションのバックアップを削除した。
  • バックアップが削除されてから最大 72 時間待機した。この時間枠を確保することで、Kopia がリポジトリーのメンテナンスサイクルを実行できるようにします。

手順

  1. バックアップのバックアップリポジトリー CR の名前を取得するために、次のコマンドを実行します。

    $ oc get backuprepositories.velero.io -n openshift-adp
  2. バックアップリポジトリー CR を削除するために、次のコマンドを実行します。

    $ oc delete backuprepository <backup_repository_name> -n openshift-adp

    <backup_repository_name> を バックアップリポジトリーの名前に置き換えてください。

5.17.8. Kopia について

Kopia はオープンソースのバックアップおよび復元ツールで、データの暗号化されたスナップショットを作成し、リモートストレージまたはクラウドストレージに保存します。

Kopia は、ネットワークおよびローカルストレージの場所、および多くのクラウドまたはリモートストレージの場所をサポートしています。以下はその一部です。

  • Amazon S3 および S3 と互換性のあるクラウドストレージ
  • Azure Blob Storage
  • Google Cloud Storage プラットフォーム

Kopia は、スナップショットにコンテンツアドレスを指定できるストレージを使用します。

  • スナップショットは常に増分されます。すでに以前のスナップショットに含まれているデータは、リポジトリーに再アップロードされません。リポジトリーに再度アップロードされるのは、ファイルが変更されたときだけです。
  • 保存されたデータは重複排除されます。同じファイルのコピーが複数存在する場合、そのうちの 1 つだけが保存されます。
  • ファイルが移動された場合、またはファイルの名前が変更された場合、Kopia はそれらが同じコンテンツであることを認識し、それらを再度アップロードしません。
5.17.8.1. OADP と Kopia の統合

OADP 1.3 は、Pod ボリュームバックアップのバックアップメカニズムとして、Restic に加えて Kopia をサポートします。インストール時に、DataProtectionApplication カスタムリソース (CR) の uploaderType フィールドを設定して、どちらかを選択する必要があります。使用できる値は、restic または kopia です。uploaderType を指定しない場合、OADP 1.3 はデフォルトで Kopia をバックアップメカニズムとして使用します。データは統合リポジトリーに書き込まれ、統合リポジトリーから読み取られます。

重要

Kopia クライアントを使用して Kopia バックアップリポジトリーを変更することはサポートされていません。変更すると、Kopia バックアップの整合性に影響が生じる可能性があります。OADP は Kopia リポジトリーへの直接接続をサポートしておらず、ベストエフォートでのみサポートを提供できます。

次の例は、Kopia を使用するように設定された DataProtectionApplication CR を示しています。

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: dpa-sample
spec:
  configuration:
    nodeAgent:
      enable: true
      uploaderType: kopia
# ...

5.18. OADP の復元

5.18.1. アプリケーションの復元

アプリケーションのバックアップを復元するには、復元を実行する前にリソースをプレビューし、復元 カスタムリソース (CR) を作成し、復元された Pod でコマンドを実行するように復元フックを設定します。これにより、復元プロセスを制御しながら、アプリケーションデータと設定を復元できます。

5.18.1.1. バックアップと復元を実行する前にリソースをプレビューする

バックアップおよび復元操作の予行演習を行うことで、バックアップおよび復元リソースを事前に確認しておきましょう。これにより、完全バックアップまたは復元を実行する前に、どのリソースが含まれるかを確認できます。

OADP は、タイプ、namespace、またはラベルに基づいてアプリケーションリソースをバックアップします。そのため、バックアップが完了した後にリソースを確認できます。同様に、復元操作が完了した後も、namespace、永続ボリューム (PV)、またはラベルに基づいて、復元されたオブジェクトを確認できます。

前提条件

  • OADP Operator がインストールされている。

手順

  1. 実際のバックアップを実行する前に、バックアップに含まれるリソースをプレビューするには、次のコマンドを実行します。

    $ velero backup create <backup-name> --snapshot-volumes false

    --snapshot-volumes パラメーターの値を false に指定します。

  2. バックアップリソースの詳細を確認するには、次のコマンドを実行します。

    $ velero describe backup <backup_name> --details

    <backup_name> を バックアップの名前に置き換えてください。

  3. 実際の復元を実行する前に、復元に含まれるリソースをプレビューするには、次のコマンドを実行します。

    $ velero restore create --from-backup <backup_name>

    <backup_name> を バックアップの名前に置き換えてください。

    重要

    velero restore create コマンドは、クラスター内に復元リソースを作成します。リソースを確認した後、復元中に作成されたリソースを削除する必要があります。

  4. 復元リソースの詳細を確認するには、次のコマンドを実行します。

    $ velero describe restore <restore_name> --details

    <restore_name> を 復元の名前に置き換えてください。

5.18.1.2. Restore CR の作成

復元用カスタムリソース (CR) を作成することで、バックアップ れたカスタムリソース (CR) を復元します。

azurefile-csi ストレージクラスを使用するステートフルアプリケーションを復元すると、復元操作が Finalizing フェーズのままになります。

前提条件

  • OpenShift API for Data Protection (OADP) Operator をインストールしている。
  • DataProtectionApplication CR が Ready 状態である。
  • Velero Backup CR がある。
  • 永続ボリューム (PV) の容量は、バックアップ時に要求されたサイズと一致する必要があります。必要に応じて、要求されたサイズを調整します。

手順

  1. 次の例のように、Restore CR を作成します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      backupName: <backup>
      includedResources: []
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      restorePVs: true

    ここでは、以下のようになります。

    <backup>
    バックアップ CR の名前を指定します。
    includedResources
    オプション: 復元プロセスに含めるリソースの配列を指定します。リソースは、短縮名 (podspo など) または完全修飾名で指定できます。指定しない場合、すべてのリソースが含まれます。
    restorePVs: true
    オプション: restorePVs パラメーターを false に設定すると、コンテナーストレージインターフェイス (CSI) スナップショットの VolumeSnapshot から、または VolumeSnapshotLocation が設定されている場合はネイティブスナップショットからの PersistentVolumes の復元をオフにすることができます。
  2. 次のコマンドを入力して、Restore CR のステータスが Completed であることを確認します。

    $ oc get restores.velero.io -n openshift-adp <restore> -o jsonpath='{.status.phase}'
  3. 次のコマンドを入力して、バックアップリソースが復元されたことを確認します。

    $ oc get all -n <namespace>

    ここでは、以下のようになります。

    <namespace>
    バックアップした名前空間を指定します。
  4. ボリュームを使用して DeploymentConfig を復元する場合、または復元後のフックを使用する場合は、次のコマンドを入力して dc-post-restore.sh クリーンアップスクリプトを実行します。

    $ bash dc-restic-post-restore.sh -> dc-post-restore.sh
    注記

    復元プロセス中に、OADP Velero プラグインは DeploymentConfig オブジェクトをスケールダウンし、Pod をスタンドアロン Pod として復元します。これは、クラスターが復元された DeploymentConfig Pod を復元時にすぐに削除することを防ぎ、復元フックと復元後のフックが復元された Pod 上でアクションを完了できるようにするために行われます。以下に示すクリーンアップスクリプトは、これらの切断された Pod を削除し、DeploymentConfig オブジェクトを適切な数のレプリカにスケールアップします。

    #!/bin/bash
    set -e
    
    # if sha256sum exists, use it to check the integrity of the file
    if command -v sha256sum >/dev/null 2>&1; then
      CHECKSUM_CMD="sha256sum"
    else
      CHECKSUM_CMD="shasum -a 256"
    fi
    
    label_name () {
        if [ "${#1}" -le "63" ]; then
    	echo $1
    	return
        fi
        sha=$(echo -n $1|$CHECKSUM_CMD)
        echo "${1:0:57}${sha:0:6}"
    }
    
    if [[ $# -ne 1 ]]; then
        echo "usage: ${BASH_SOURCE} restore-name"
        exit 1
    fi
    
    echo "restore: $1"
    
    label=$(label_name $1)
    echo "label:   $label"
    
    echo Deleting disconnected restore pods
    oc delete pods --all-namespaces -l oadp.openshift.io/disconnected-from-dc=$label
    
    for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}')
    do
        IFS=',' read -ra dc_arr <<< "$dc"
        if [ ${#dc_arr[0]} -gt 0 ]; then
    	echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]}
    	cat <<EOF | oc patch dc  -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin
    spec:
      replicas: ${dc_arr[2]}
      paused: ${dc_arr[3]}
    EOF
        fi
    done
5.18.1.3. 復元フックの作成

リストア カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのリストアフックを作成します。

2 種類の復元フックを作成できます。

  • init フックは、init コンテナーを Pod に追加して、アプリケーションコンテナーが起動する前にセットアップタスクを実行します。

    Restic バックアップを復元する場合は、復元フック init コンテナーの前に restic-wait init コンテナーが追加されます。

  • exec フックは、復元された Pod のコンテナーでコマンドまたはスクリプトを実行します。

手順

  • 次の例のように、Restore CR の spec.hooks ブロックにフックを追加します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: <restore>
      namespace: openshift-adp
    spec:
      hooks:
        resources:
          - name: <hook_name>
            includedNamespaces:
            - <namespace>
            excludedNamespaces:
            - <namespace>
            includedResources:
            - pods
            excludedResources: []
            labelSelector:
              matchLabels:
                app: velero
                component: server
            postHooks:
            - init:
                initContainers:
                - name: restore-hook-init
                  image: alpine:latest
                  volumeMounts:
                  - mountPath: /restores/pvc1-vm
                    name: pvc1-vm
                  command:
                  - /bin/ash
                  - -c
                timeout:
            - exec:
                container: <container>
                command:
                - /bin/bash
                - -c
                - "psql < /backup/backup.sql"
                waitTimeout: 5m
                execTimeout: 1m
                onError: Continue

    ここでは、以下のようになります。

    <namespace>
    オプション: フックを適用する名前空間の配列を指定します。この値が指定されていない場合、フックはすべての namespace に適用されます。
    Pod
    現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
    labelSelector
    オプション: このフックは、ラベルセレクターに一致するオブジェクトにのみ適用されます。
    timeout
    オプション:Velero が initContainers の 完了を待つ最大時間を指定します。
    <container>
    オプション: コマンドを実行するコンテナーを指定します。コンテナーが指定されていない場合、コマンドは Pod 内の最初のコンテナーで実行されます。
    /bin/bash
    追加する初期化コンテナーのエントリーポイントを指定します。
    待機タイムアウト: 5 分
    オプション: コンテナーが準備完了になるまでの待機時間を指定します。これは、コンテナーが起動して同じコンテナー内の先行するフックが完了するのに十分な長さである必要があります。設定されていない場合、復元プロセスの待機時間は無期限になります。
    execTimeout: 1 分
    オプション: コマンドの実行を待つ時間を指定します。デフォルトは 30s です。
    エラー発生時: 続行

    エラー処理の動作を指定します。許容される値は FailContinue です。

    • Continue: コマンドの失敗のみがログに記録されます。
    • Fail: Pod 内のコンテナーで復元フックが実行されなくなりました。Restore CR のステータスは PartiallyFailed になります。

File System Backup (FSB) の復元操作中に、ImageStream を参照する Deployment リソースが適切に復元されません。FSB を実行する復元された Pod と postHook が途中で終了します。

これが発生するのは、復元操作中に、OpenShift コントローラーが Deployment リソースの spec.template.spec.containers[0].image フィールドを新しい ImageStreamTag ハッシュで更新するためです。更新により、新しい Pod のロールアウトがトリガーされ、velero が FSB と復元後のフックを実行する Pod が終了します。イメージストリームトリガーの詳細は、「イメージストリームの変更時の更新のトリガー」を参照してください。

この動作を回避するには、次の 2 段階の復元プロセスを実行します。

  1. まず、Deployment リソースを除外して復元を実行します。次に例を示します。

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --exclude-resources=deployment.apps
  2. 最初の復元が成功したら、次の例のように、次のリソースを含めて 2 回目の復元を実行します。

    $ velero restore create <RESTORE_NAME> \
      --from-backup <BACKUP_NAME> \
      --include-resources=deployment.apps

5.19. OADP Self-Service

5.19.1. OADP Self-Service

OADP セルフサービスを使用すると、名前空間管理者はクラスター管理者特権がなくてもアプリケーションのバックアップと復元を行うことができます。これにより、管理権限を維持しながらバックアップ操作を委任することが可能になります。

5.19.1.1. OADP Self-Service について

OADP 1.5.0 以降では、バックアップおよび復元操作を実行するために cluster-admin ロールは必要ありません。namespace admin ロールで OADP を使用できます。namespace admin ロールには、ユーザーが割り当てられている namespace のみへの管理者アクセスがあります。

Self-Service 機能は、クラスター管理者が OADP Operator をインストールし、必要なパーミッションを付与した後にのみ使用できます。

OADP Self-Service 機能は、適切なアクセス制御を維持しながら、cluster-admin 権限を持たないユーザーにセキュアなセルフサービスデータ保護機能を提供します。

OADP クラスター管理者は、namespace admin ロールを持つユーザーを作成し、OADP Self-Service アクションを実行するために必要なロールベースアクセス制御 (RBAC) をユーザーに提供します。cluster-admin ロールと比較して、このユーザーのアクセスは制限されているため、このユーザーは namespace admin ユーザーと呼ばれます。

namespace admin ユーザーとして、クラスター上の認可された namespace にデプロイされたアプリケーションをバックアップおよび復元できます。

OADP Self-Service には、次の利点があります。

  • クラスター管理者として以下を実行します。

    • namespace admin ユーザーに対して namespace スコープのバックアップおよび復元操作を許可します。つまり、namespace admin ユーザーは、許可されていない namespace にアクセスできません。
    • 管理者以外のユーザーの操作に対しても、DataProtectionApplication の設定とポリシーを通じて管理者の制御を維持できます。
  • namespace admin ユーザーとして、以下を実行できます。

    • 認可された namespace のバックアップおよび復元カスタムリソースを作成できます。
    • 認可された namespace に専用の Backup Storage Location を作成できます。
    • バックアップログとステータス情報にセキュアにアクセスできます。
5.19.1.2. namespace スコープのバックアップおよび復元の意味

OADP Self-Service は、namespace admin ユーザーが認可された namespace 内でのみ動作するようにします。たとえば、namespace admin ユーザーとして namespace にアクセスできない場合は、その namespace をバックアップできません。

namespace admin ユーザーは、他のユーザーのバックアップおよび復元データにアクセスできません。

クラスター管理者は、バックアップおよび復元操作をセキュアに管理するカスタムリソース (CR) を使用して、アクセス制御を適用します。

さらに、クラスター管理者は、CR 内で許可されるオプションを制御し、DataProtectionApplication (DPA) CR の spec 強制を使用して、セキュリティーを強化するために特定の操作を制限できます。

namespace admin ユーザーは、次の Self-Service 操作を実行できます。

  • 認可された namespace のバックアップの作成および管理。
  • 認可された namespace へのデータの復元。
  • 独自の Backup Storage Location の設定。
  • バックアップおよび復元のステータスの確認。
  • 関連するログの取得の要求。
5.19.1.3. OADP Self-Service カスタムリソース

OADP セルフサービスカスタムリソースを使用して、名前空間スコープのアプリケーションのバックアップ、復元、保存場所、およびダウンロード操作を制御します。これにより、ネームスペース管理者はセルフサービス型のデータ保護ツールを利用できるようになります。

OADP Self-Service 機能には、namespace admin ユーザーのバックアップと復元操作を実行するための次の新しいカスタムリソース (CR) があります。

Expand
表5.6 カスタムリソース

CR

説明

NonAdminController (NAC)

Self-Service 操作を制御およびオーケストレーションします。

NonAdminBackup (NAB)

namespace スコープのバックアップ操作を管理します。

NonAdminRestore (NAR)

namespace スコープの復元操作を管理します。

NonAdminBackupStorageLocation (NABSL)

ユーザー固有の Backup Storage Location を定義します。

NonAdminDownloadRequest (NADR)

namespace スコープのダウンロード要求操作を管理します。

5.19.1.4. OADP Self-Service の仕組み

OADP セルフサービスが、名前空間管理者の要求を検証し、対応する Velero バックアップオブジェクトを作成する NonAdminController (NAC) カスタムリソースを介してバックアップ要求を処理する方法を確認します。

この図では、以下のワークフローを説明しています。

  1. namespace admin ユーザーは、NonAdminBackup (NAB) カスタムリソース (CR) 要求を作成します。
  2. NonAdminController (NAC) CR は NAB CR 要求を受け取ります。
  3. NAC は要求を検証し、要求に関する NAB CR を更新します。
  4. NAC は Velero バックアップオブジェクトを作成します。
  5. NAC は Velero バックアップオブジェクトを監視し、ステータスを NAB CR にカスケードします。

図5.1 OADP Self-Service の仕組み

5.19.1.5. OADP Self-Service の前提条件

以下の前提条件を満たして、OADP セルフサービスによるバックアップおよびリストア操作を有効にするようにクラスター環境を設定してください。これは、名前空間管理者が割り当てられた名前空間内でデータ保護タスクを実行するのに役立ちます。

  • クラスター管理者が OADP DataProtectionApplication (DPA) CR を設定して Self-Service を有効化している。
  • クラスター管理者が以下のタスクを完了している。

    • namespace admin ユーザーアカウントを作成している。
    • namespace admin ユーザーの namespace を作成している。
    • namespace admin ユーザーの namespace に適切な権限が割り当てられている。これにより、namespace admin ユーザーには、割り当てられた namespace にアクセスし、バックアップおよび復元操作を実行する権限が与えられます。
  • 必要に応じて、クラスター管理者は namespace admin ユーザー用の NonAdminBackupStorageLocation (NABSL) CR を作成できます。
5.19.1.6. OADP Self-Service namespace パーミッション

名前空間管理者に名前空間権限を割り当て、割り当てられた名前空間内でバックアップ、復元、およびストレージ場所のリソースを作成および管理できるようにします。これにより、ネームスペース管理者はセルフサービス型データ保護操作に必要なアクセス権を取得できます。

クラスター管理者は、以下のオブジェクトリストに対する編集者ロールが、namespace で namespace admin ユーザーに割り当てられていることを確認します。

  • nonadminbackups.oadp.openshift.io
  • nonadminbackupstoragelocations.oadp.openshift.io
  • nonadminrestores.oadp.openshift.io
  • nonadmindownloadrequests.oadp.openshift.io

namespace admin ロールの詳細は、デフォルトのクラスターロール を参照してください。

クラスター管理者は、独自の仕様を定義して、ユーザーに project または namespace admin ロールと同様の権限を持たせることもできます。

5.19.1.6.1. バックアップ操作用の RBAC YAML の例

namespace admin ユーザーがバックアップ操作を実行できるようにするための、namespace パーミッションを含むロールベースアクセス制御 (RBAC) YAML ファイルの以下の例を参照してください。

RBAC マニフェストの例

...
- apiGroups:
      - oadp.openshift.io
    resources:
      - nonadminbackups
      - nonadminrestores
      - nonadminbackupstoragelocations
      - nonadmindownloadrequests
    verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
      - watch
  - apiGroups:
      - oadp.openshift.io
    resources:
      - nonadminbackups/status
      - nonadminrestores/status
    verbs:
      - get

5.19.1.7. OADP Self-Service の制限

OADP セルフサービスの制限事項とサポートされていない機能を確認し、ネームスペース管理者がどの操作を制限されているかを理解してください。これは、サポートされている機能の範囲内で、適切なバックアップおよび復元ストラテジーを計画するのに役立ちます。

次の機能は、OADP Self-Service ではサポートされていません。

  • クラスター間のバックアップと復元、または移行はサポートされていません。これらの OADP 操作はクラスター管理者に対してサポートされています。
  • namespace admin ユーザーは、VolumeSnapshotLocation (VSL) CR を作成できません。クラスター管理者は、namespace admin ユーザーの DataProtectionApplication (DPA) CR で VSL を作成して設定します。
  • ResourceModifiers CR とボリュームポリシーは、namespace admin ユーザーに対してはサポートされていません。
  • namespace admin ユーザーは、NonAdminBackupStorageLocation CR を使用するユーザーによってバックアップまたは復元が作成されている場合にのみ、NonAdminDownloadRequest CR を使用してバックアップまたは復元ログを要求できます。

    バックアップまたは復元 CR がクラスター全体のデフォルトの Backup Storage Location を使用して作成されている場合、namespace admin ユーザーはバックアップまたは復元ログを要求できません。

  • セキュアなバックアップおよび復元を確保するために、OADP Self-Service は次の CR がバックアップまたは復元されないように自動的に除外します。

    • NonAdminBackup
    • NonAdminRestore
    • NonAdminBackupStorageLocation
    • SecurityContextConstraints
    • ClusterRole
    • ClusterRoleBinding
    • CustomResourceDefinition
    • PriorityClasses
    • VirtualMachineClusterInstanceTypes
    • VirtualMachineClusterPreferences
5.19.1.8. OADP Self-Service のバックアップおよび復元フェーズ

バックアップおよび復元操作の進行状況と状態を追跡するには、NonAdminBackup (NAB) および NonAdminRestore (NAR) カスタムリソースのステータスフェーズを確認してください。これは、セルフサービスによるバックアップおよび復元要求の監視とトラブルシューティングに役立ちます。

CR のフェーズは前にのみ進みます。あるフェーズが次のフェーズに移行すると、前のフェーズに戻ることはできません。

Expand
表5.7 フェーズ

説明

New

NAB または NAR CR の作成要求が NAC によって受け付けられましたが、まだ NAC によって検証されていません。

BackingOff

NAB または NAR CR の無効な spec が原因で、NAC CR によって NAB または NAR CR が無効になります。

namespace admin ユーザーは、NAB または NAR spec を更新することで、管理者が設定するポリシーに準拠できます。namespace admin ユーザーが CR を編集した後、NAC は CR を再度調整します。

Created

NAB または NAR CR は NAC によって検証され、Velero バックアップまたは復元オブジェクトが作成されます。

Deletion

NAB または NAR CR が削除対象としてマークされています。NAC は、対応する Velero バックアップまたは復元オブジェクトを削除します。Velero オブジェクトが削除されると、NAB または NAR CR も削除されます。

5.19.1.9. NonAdminBackupStorageLocation CR について

名前空間管理者が管理者による作成、承認、または自動プロセスを通じてバックアップストレージの場所をどのように定義するかを理解するために 、NonAdminBackupStorageLocation (NABSL) カスタムリソース (CR) のワークフローを確認してください。これは、セキュリティー要件に基づいて適切なワークフローを選択するのに役立ちます。

NABSL CR が作成され、セキュアに使用されるようにするには、クラスター管理者の制御を使用します。クラスター管理者は、NABSL CR を管理し、会社ポリシーおよびコンプライアンス要件に準拠します。

次のワークフローのいずれかを使用して、NABSL CR を作成できます。

  • 管理者作成ワークフロー: このワークフローでは、クラスター管理者は namespace admin ユーザーの NABSL CR を作成します。次に、namespace admin ユーザーは NonAdminBackup CR の NABSL を参照します。
  • 管理者承認ワークフロー: クラスター管理者は、nonAdmin.requireApprovalForBSL フィールドを true に設定して、DPA でこのオプトイン機能を明示的に有効にする必要があります。クラスター管理者の承認プロセスは以下のように実行されます。

    1. namespace admin ユーザーは NABSL CR を作成します。管理者は DPA で承認プロセスを適用しているため、openshift-adp namespace での NonAdminBackupStorageLocationRequest CR の作成がトリガーされます。
    2. クラスター管理者は要求を確認し、要求を承認または拒否します。

      • 承認されると、Velero BackupStorageLocation (BSL) が openshift-adp namespace に作成され、NABSL CR のステータスが更新されて承認が反映されます。
      • 拒否されると、NABSL CR のステータスは、拒否を反映するように更新されます。
    3. クラスター管理者は、以前に承認された NABSL CR を取り消すこともできます。approve フィールドは、pending または reject に戻されます。これにより、Velero BSL が削除され、namespace admin ユーザーに拒否が通知されます。
  • 自動承認ワークフロー: このワークフローでは、DPA の nonAdmin.requireApprovalForBSL フィールドを false に設定して、クラスター管理者による NABSL CR の承認プロセスを強制しません。このフィールドのデフォルト値は false です。フィールドを設定しないと、NABSL が自動的に承認されます。そのため、namespace admin ユーザーは認可された namespace から NABSL CR を作成できます。
重要

セキュリティー上の理由から、管理者の作成または管理者の承認ワークフローのいずれかを使用してください。自動承認ワークフローは、管理者のレビューを必要としないため、安全性が低くなります。

5.19.2. OADP Self-Service クラスター管理者のユースケース

OADP セルフサービス機能を有効にし、バックアップストレージの場所要求を確認し、ポリシーテンプレートを適用することで、OADP セルフサービスを設定および管理します。これにより、管理権限を維持しながら、セルフサービス型のバックアップ機能を提供できます。

5.19.2.1. OADP Self-Service の有効化と無効化

OADP セルフサービス機能を有効または無効にすることで、名前空間管理者がクラスター管理者特権なしで自身のバックアップおよび復元操作を管理できるようにします。これにより、管理権限を維持しながら、バックアップの責任を委任することができます。

注記

NonAdminController (NAC) CR のインスタンスは、クラスター内に 1 つだけインストールできます。NAC CR の複数のインスタンスをインストールすると、次のエラーが発生します。

message: only a single instance of Non-Admin Controller can be installed across the entire cluster. Non-Admin controller is already configured and installed in openshift-adp namespace.

前提条件

  • cluster-admin ロールでクラスターにログイン済みである。
  • OADP Operator がインストールされている。
  • DPA が設定されている。

手順

  • OADP Self-Service を有効にするには、DPA CR を編集して nonAdmin.enable セクションを設定します。次の設定例を参照してください。

    DataProtectionApplication CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - aws
            - openshift
            - csi
          defaultSnapshotMoveData: true
      nonAdmin:
        enable: true
      backupLocations:
        - velero:
            config:
              profile: "default"
              region: noobaa
              s3Url: https://s3.openshift-storage.svc
              s3ForcePathStyle: "true"
              insecureSkipTLSVerify: "true"
            provider: aws
            default: true
            credential:
              key: cloud
              name:  <cloud_credentials>
            objectStorage:
              bucket: <bucket_name>
              prefix: oadp

    ここでは、以下のようになります。

    非管理者
    DPA の 仕様 セクション内の、セルフサービス機能を有効または無効にするセクションを指定します。
    enable
    セルフサービス機能を有効にするかどうかを指定します。この機能を有効にするには、true に設定してください。この機能を無効にするには、false に設定してください。

検証

  • NonAdminController (NAC) Pod が OADP namespace で実行されていることを確認するには、次のコマンドを実行します。

    $ oc get pod -n openshift-adp -l control-plane=non-admin-controller

    出力例

    NAME                                  READY   STATUS    RESTARTS   AGE
    non-admin-controller-5d....f5-p..9p   1/1     Running   0          99m

5.19.2.2. NonAdminBackupStorageLocation 管理者の承認ワークフローの有効化

名前空間管理者からのバックアップストレージ場所要求が適用される前に確認できるよう、NonAdminBackupStorageLocation カスタムリソースの管理者承認ワークフローを有効にします。これにより、バックアップストレージの設定を適切に管理できます。

前提条件

  • cluster-admin ロールでクラスターにログイン済みである。
  • OADP Operator がインストールされている。
  • DataProtectionApplication CR で OADP Self-Service を有効化している。

手順

  • NABSL 管理者承認ワークフローを有効にするには、以下の設定例を使用して DPA CR を編集します。

    DataProtectionApplication CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: oadp-backup
      namespace: openshift-adp
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
            - aws
            - openshift
            - csi
          noDefaultBackupLocation: true
      nonAdmin:
        enable: true
        requireApprovalForBSL: true

    ここでは、以下のようになります。

    noDefaultBackupLocation
    DPA CR にデフォルトのバックアップ保存場所が設定されていないことを指定します。名前空間管理者ユーザーが NABSL CR を作成し、承認のために CR リクエストを送信できるようにするには、true に設定します。
    BSL の承認が必要
    NABSL 管理者の承認ワークフローが有効になっているかどうかを指定します。承認ワークフローを有効にするには、true に設定してください。
5.19.2.3. NonAdminBackupStorageLocation 要求の承認

名前空間管理者からの非管理 者バックアップストレージ場所 (NABSL) カスタムリソース要求を承認し、指定されたバックアップストレージ場所へのアクセスを許可します。これにより、名前空間リソースのセルフサービスによるバックアップおよび復元操作が可能になります。

前提条件

  • cluster-admin ロールでクラスターにログイン済みである。
  • OADP Operator がインストールされている。
  • DataProtectionApplication (DPA) CR で OADP Self-Service を有効にしている。
  • DPA で NABSL CR 承認ワークフローを有効化している。

手順

  1. 管理者承認のためにキューにある NABSL CR 要求を表示するには、次のコマンドを実行します。

    $ oc -n openshift-adp get NonAdminBackupStorageLocationRequests

    出力例

    NAME                          REQUEST-PHASE   REQUEST-NAMESPACE     REQUEST-NAME               AGE
    non-admin-bsl-test-.....175   Approved        non-admin-bsl-test    incorrect-bucket-nabsl    4m57s
    non-admin-bsl-test-.....196   Approved        non-admin-bsl-test    perfect-nabsl             5m26s
    non-admin-bsl-test-s....e1a   Rejected        non-admin-bsl-test    suspicious-sample         2m56s
    non-admin-bsl-test-.....5e0   Pending         non-admin-bsl-test    waitingapproval-nabsl     4m20s

  2. NABSL CR 要求を承認するには、次のコマンドを実行して approvalDecision フィールドを approve に設定します。

    $ oc patch nabslrequest <nabsl_name> -n openshift-adp --type=merge -p '{"spec": {"approvalDecision": "approve"}}'

    <nabsl_name> をNonAdminBackupStorageLocationRequest CR の名前に置き換えてください。

検証

  • 次のコマンドを実行して、Velero Backup Storage Location が作成され、フェーズが Available であることを確認します。

    $ oc get velero.io.backupstoragelocation

    出力例

    NAME                         PHASE       LAST VALIDATED   AGE   DEFAULT
    test-nac-test-bsl-cd...930   Available   62s              62s

5.19.2.4. NonAdminBackupStorageLocation 要求の拒否

ネームスペース管理者からの非管理 者バックアップストレージ 場所 (NABSL) カスタムリソース (CR) 要求を拒否し、要件を満たさないバックアップストレージ場所へのアクセスを拒否します。これは、セキュリティーとコンプライアンス基準の維持に役立ちます。

前提条件

  • cluster-admin ロールでクラスターにログイン済みである。
  • OADP Operator がインストールされている。
  • DataProtectionApplication (DPA) CR で OADP Self-Service を有効にしている。
  • DPA で NABSL CR 承認ワークフローを有効化している。

手順

  1. 管理者承認のためにキューにある NABSL CR 要求を表示するには、次のコマンドを実行します。

    $ oc -n openshift-adp get NonAdminBackupStorageLocationRequests

    出力例

    $ oc get nabslrequest
    NAME                          REQUEST-PHASE   REQUEST-NAMESPACE     REQUEST-NAME               AGE
    non-admin-bsl-test-.....175   Approved        non-admin-bsl-test    incorrect-bucket-nabsl    4m57s
    non-admin-bsl-test-.....196   Approved        non-admin-bsl-test    perfect-nabsl             5m26s
    non-admin-bsl-test-s....e1a   Rejected        non-admin-bsl-test    suspicious-sample         2m56s
    non-admin-bsl-test-.....5e0   Pending         non-admin-bsl-test    waitingapproval-nabsl     4m20s

  2. NABSL CR 要求を拒否するには、次のコマンドを実行して、approvalDecision フィールドを reject に設定します。

    $ oc patch nabslrequest <nabsl_name> -n openshift-adp --type=merge -p '{"spec": {"approvalDecision": "reject"}}'

    <nabsl_name> をNonAdminBackupStorageLocationRequest CR の名前に置き換えてください。

5.19.2.5. OADP Self-Service 管理者 DPA 仕様の適用

名前空間管理者が作成した NonAdminBackupNonAdminRestore、および NonAdminBackupStorageLocation カスタムリソースを制御するために、DataProtectionApplication (DPA) カスタムリソース (CR) のポリシーテンプレートを適用します。これは、コンプライアンス基準を維持するのに役立ちます。

クラスター管理者は、DataProtectionApplication (DPA) CR で次のフィールドを使用して、会社またはコンプライアンスポリシーを適用できます。

enforceBSLSpec
NonAdminBackupStorageLocation CR でポリシーを適用する場合。
enforceBackupSpec
NonAdminBackup CR でポリシーを適用する場合。
enforceRestoreSpec
NonAdminRestore CR でポリシーを適用する場合。

強制可能なフィールドを使用することで、管理者は、namespace admin ユーザーが作成した NABSL、NAB、および NAR CR が管理者定義のポリシーに準拠することを確認できます。

5.19.2.6. NABSL の Self-Service 管理者仕様の適用

名前空間管理者が使用するストレージバケット、認証情報、設定、アクセスモード、および検証設定を制御するために、NonAdminBackupStorageLocation (NABSL) カスタムリソース (CR) の特定のフィールドを強制します。これは組織の方針を維持するのに役立ちます。

NABSL に対して、以下の項目を強制的に適用できます。

  • objectStorage
  • credential
  • config
  • accessMode
  • validationFrequency

たとえば、namespace admin ユーザーが特定のストレージバケットを使用するように適用する場合は、DataProtectionApplication (DPA) CR を以下のようにセットアップできます。

DataProtectionApplication CR の例

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  nonAdmin:
    enable: true
    enforceBSLSpec:
      config:
        checksumAlgorithm: ""
        profile: default
        region: us-west-2
      objectStorage:
        bucket: my-company-bucket
        prefix: velero
      provider: aws

ここでは、以下のようになります。

enforceBSLSpec
NonAdminBackupStorageLocation CR のポリシーを適用するセクションを指定します。
config
NABSL に適用する設定を指定します。この例では、us-west-2 リージョンの AWS S3 バケットの使用を強制しています。
objectStorage
my-company-bucket という名前の会社バケットを使用するようにオブジェクトストレージ設定を指定します。

namespace admin ユーザーが NABSL を作成する場合、DPA で設定されたテンプレートに従う必要があります。それ以外の場合は、NABSL CR の status.phase フィールドが BackingOff に設定され、NABSL は作成に失敗します。

5.19.2.7. NAB の Self-Service 管理者仕様の適用

名前空間管理者が使用するタイムアウト設定、リソースポリシー、ラベルセレクター、スナップショット設定、および有効期限値を制御するために、NonAdminBackup (NAB) カスタムリソース (CR) の特定のフィールドを強制的に適用します。これはバックアップ基準を維持するのに役立ちます。

NAB CR に対して、以下の項目を強制的に適用できます。

  • csiSnapshotTimeout
  • itemOperationTimeout
  • resourcePolicy
  • includedResources
  • excludedResources
  • orderedResources
  • includeClusterResources
  • excludedClusterScopedResources
  • excludedNamespaceScopedResources
  • includedNamespaceScopedResources
  • labelSelector
  • orLabelSelectors
  • snapshotVolumes
  • ttl
  • snapshotMoveData
  • uploaderConfig.parallelFilesUpload

namespace admin ユーザーの ttl 値と Data Mover バックアップを適用する場合は、次の例のように DataProtectionApplication (DPA) CR をセットアップできます。

DataProtectionApplication CR の例

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
...
spec:
  nonAdmin:
    enable: true
    enforceBackupSpec:
      snapshotMoveData: true
      ttl: 158h0m0s

ここでは、以下のようになります。

enforceBackupSpec
NonAdminBackup CR に対してポリシーを適用するセクションを指定します。
snapshotMoveData
データムーバーを適用するかどうかを指定します。データムーバーによるバックアップを強制するには、true に設定してください。
ttl
バックアップに適用する有効期限 (TTL) を指定します。この例では、158 時間 0 分 0 秒 に設定されています。

namespace admin ユーザーが NAB CR を作成する場合、DPA でセットアップされたテンプレートに従う必要があります。それ以外の場合は、NAB CR の status.phase フィールドが BackingOff に設定され、NAB CR は作成に失敗します。

5.19.2.8. NAR の Self-Service 管理者仕様の適用

名前空間管理者が使用するタイムアウト設定、リソースポリシー、ラベルセレクター、永続ボリュームの復元、ノードポート設定を制御するために、NonAdminRestore (NAR) カスタムリソース (CR) の特定のフィールドを強制的に適用します。これは復旧基準を維持するのに役立ちます。

NAR CR に対して、以下の項目を強制的に適用できます。

  • itemOperationTimeout
  • uploaderConfig
  • includedResources
  • excludedResources
  • restoreStatus
  • includeClusterResources
  • labelSelector
  • orLabelSelectors
  • restorePVs
  • preserveNodePorts

5.19.3. OADP Self-Service namespace admin のユースケース

名前空間管理者として OADP セルフサービスを使用すると、承認済み名前空間のバックアップ保存場所の作成、バックアップおよび復元操作の実行、操作ログの確認を行うことができます。これにより、クラスター管理者権限がなくても、データ保護を独自に管理できるようになります。

5.19.3.1. NonAdminBackupStorageLocation CR の作成

承認済みネームスペース内のバックアップストレージの場所を定義するには、NonAdminBackupStorageLocation (NABSL) カスタムリソース (CR) を作成します。この機能を使用すると、アプリケーションの要件を満たすクラウドストレージにバックアップを保存できます。

前提条件

  • namespace admin ユーザーとしてクラスターにログインしている。
  • クラスター管理者が OADP Operator をインストールしている。
  • クラスター管理者が DataProtectionApplication (DPA) CR を設定して OADP Self-Service を有効化している。
  • クラスター管理者が namespace を作成し、その namespace からの操作を許可されている。

手順

  1. クラウドプロバイダーのクラウド認証情報ファイルの内容を使用して Secret CR を作成します。以下のコマンドを実行します。

    $ oc create secret generic cloud-credentials -n test-nac-ns --from-file <cloud_key_name>=<cloud_credentials_file>

    ここでは、以下のようになります。

    < クラウドキー名 >
    クラウドプロバイダーのキー名を指定します。この例では、Secret 名は cloud-credentials で、認可された namespace 名は test-nac-ns です。
    <cloud_credentials_file>
    クラウド認証情報ファイル名を指定します。
  2. NonAdminBackupStorageLocation CR を作成するには、以下の設定で YAML マニフェストファイルを作成します。

    NonAdminBackupStorageLocation CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackupStorageLocation
    metadata:
      name: test-nabsl
      namespace: test-nac-ns
    spec:
      backupStorageLocationSpec:
        config:
          profile: default
          region: <region_name>
        credential:
          key: cloud
          name: cloud-credentials
        objectStorage:
          bucket: <bucket_name>
          prefix: velero
        provider: aws

    ここでは、以下のようになります。

    namespace
    操作を許可されている名前空間を指定します。たとえば、test-nac-ns などです。
    < 地域名 >
    クラウドプロバイダーのリージョン名を指定します。
    <bucket_name>
    バックアップを保存するバケット名を指定します。
  3. NABSL CR 設定を適用するには、次のコマンドを実行します。

    $ oc apply -f <nabsl_cr_filename>

    <nabsl_cr_filename> は、NABSL CR 設定を含むファイル名に置き換えます。

検証

  1. NABSL CR が New フェーズにあり、管理者承認が保留であることを確認するには、次のコマンドを実行します。

    $ oc get nabsl test-nabsl -o yaml

    出力例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackupStorageLocation
    ...
    status:
      conditions:
      - lastTransitionTime: "2025-02-26T09:07:15Z"
        message: NonAdminBackupStorageLocation spec validation successful
        reason: BslSpecValidation
        status: "True"
        type: Accepted
      - lastTransitionTime: "2025-02-26T09:07:15Z"
        message: NonAdminBackupStorageLocationRequest approval pending
        reason: BslSpecApprovalPending
        status: "False"
        type: ClusterAdminApproved
      phase: New
      veleroBackupStorageLocation:
        nacuuid: test-nac-test-bsl-c...d4389a1930
        name: test-nac-test-bsl-cd....1930
        namespace: openshift-adp

    ここでは、以下のようになります。

    message
    NonAdminBackupStorageLocationRequest の承認保留 メッセージが含まれています。
    phase
    フェーズの状態を指定します。この例では、フェーズは 新規 です。
  2. クラスター管理者が NonAdminBackupStorageLocationRequest CR 要求を承認した後、次のコマンドを実行して、NABSL CR が正常に作成されたことを確認します。

    $ oc get nabsl test-nabsl -o yaml

    出力例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackupStorageLocation
    metadata:
      creationTimestamp: "2025-02-19T09:30:34Z"
      finalizers:
      - nonadminbackupstoragelocation.oadp.openshift.io/finalizer
      generation: 1
      name: test-nabsl
      namespace: test-nac-ns
      resourceVersion: "159973"
      uid: 4a..80-3260-4ef9-a3..5a-00...d1922
    spec:
      backupStorageLocationSpec:
        credential:
          key: cloud
          name: cloud-credentials
        objectStorage:
          bucket: oadp...51rrdqj
          prefix: velero
        provider: aws
    status:
      conditions:
      - lastTransitionTime: "2025-02-19T09:30:34Z"
        message: NonAdminBackupStorageLocation spec validation successful
        reason: BslSpecValidation
        status: "True"
        type: Accepted
      - lastTransitionTime: "2025-02-19T09:30:34Z"
        message: Secret successfully created in the OADP namespace
        reason: SecretCreated
        status: "True"
        type: SecretSynced
      - lastTransitionTime: "2025-02-19T09:30:34Z"
        message: BackupStorageLocation successfully created in the OADP namespace
        reason: BackupStorageLocationCreated
        status: "True"
        type: BackupStorageLocationSynced
      phase: Created
      veleroBackupStorageLocation:
        nacuuid: test-nac-..f933a-4ec1-4f6a-8099-ee...b8b26
        name: test-nac-test-nabsl-36...11ab8b26
        namespace: openshift-adp
        status:
          lastSyncedTime: "2025-02-19T11:47:10Z"
          lastValidationTime: "2025-02-19T11:47:31Z"
          phase: Available

    ここでは、以下のようになります。

    メッセージ: NonAdminBackupStorageLocation 仕様の検証に成功しました
    NABSL 仕様が クラスター管理者によって検証および承認されていることを指定します。
    メッセージ: OADP 名前空間にシークレットが正常に作成されました
    シークレット オブジェクトが openshift-adp 名前空間に正常に作成されたことを示します。
    メッセージ: OADP 名前空間に BackupStorageLocation が正常に作成されました
    関連付けられた Velero BackupStorageLocation がopenshift-adp 名前空間に正常に作成されたことを指定します。
    ナキュイド
    NABSL CR をオーケストレーションする NAC を指定します。
    name
    関連付けられている Velero バックアップストレージの場所オブジェクトの名前を指定します。
    フェーズ: 利用可能
    NABSL が使用可能であることを示します。
5.19.3.2. NonAdminBackup CR の作成

承認済みネームスペース内のアプリケーションリソースをバックアップするために、非管理者バックアップ (NAB) カスタムリソース (CR) を作成します。これにより、クラスター管理者特権を必要とせずに、アプリケーションデータと設定を保護できます。

NAB CR の作成後、CR は次のフェーズを経ます。

  • CR の初期フェーズは New です。
  • CR 作成要求は、調整および検証のために NonAdminController (NAC) に送信されます。
  • Velero バックアップオブジェクトの検証と作成が正常に行われると、NAB CR の status.phase フィールドは次のフェーズ (Created) に更新されます。

NAB CR を作成する際は、以下の重要な点を確認してください。

  • NonAdminBackup CR は Velero バックアップオブジェクトをセキュアに作成し、他の namespace admin ユーザーが CR にアクセスできないようにします。
  • namespace admin ユーザーは、NAB CR で認可された namespace のみを指定できます。使用することを認可されていない namespace を指定すると、エラーが発生します。

前提条件

  • namespace admin ユーザーとしてクラスターにログインしている。
  • クラスター管理者が OADP Operator をインストールしている。
  • クラスター管理者が DataProtectionApplication (DPA) CR を設定して OADP Self-Service を有効化している。
  • クラスター管理者が namespace を作成し、その namespace からの操作を許可されている。
  • オプション: NonAdminBackupStorageLocation (NABSL) CR を作成して使用することで、バックアップデータを保存できます。NABSL CR を使用しない場合、バックアップは DPA で設定されたデフォルトの Backup Storage Location に保存されます。

手順

  1. NonAdminBackup CR を作成するには、次の設定で YAML マニフェストファイルを作成します。

    NonAdminBackup CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackup
    metadata:
      name: test-nab
    spec:
      backupSpec:
        defaultVolumesToFsBackup: true
        snapshotMoveData: false
        storageLocation: test-bsl

    ここでは、以下のようになります。

    name
    NAB CR の名前を指定します。たとえば、test-nab などです。
    defaultVolumesToFsBackup
    ファイルシステムバックアップ (FSB) を使用するかどうかを指定します。FSB を使用するには true に設定してください。
    snapshotMoveData
    データムーバーを使用してデータボリュームをバックアップするかどうかを指定します。データムーバーを使用するには、true に設定してください。この例では、バックアップに FSB を使用しています。
    保管場所
    保管場所として NABSL CR を指定します。storageLocation を設定しないと、DPA に設定されたデフォルトの Backup Storage Location が使用されます。
  2. NAB CR 設定を適用するには、次のコマンドを実行します。

    $ oc apply -f <nab_cr_filename>

    <nab_cr_filename> を NAB CR 設定を含むファイル名に置き換えてください。

検証

  • NAB CR が正常に作成されたことを確認するには、次のコマンドを実行します。

    $ oc get nab test-nab -o yaml

    出力例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackup
    metadata:
      creationTimestamp: "2025-03-06T10:02:56Z"
      finalizers:
      - nonadminbackup.oadp.openshift.io/finalizer
      generation: 2
      name: test-nab
      namespace: test-nac-ns
      resourceVersion: "134316"
      uid: c5...4c8a8
    spec:
      backupSpec:
        csiSnapshotTimeout: 0s
        defaultVolumesToFsBackup: true
        hooks: {}
        itemOperationTimeout: 0s
        metadata: {}
        storageLocation: test-bsl
        ttl: 0s
    status:
      conditions:
      - lastTransitionTime: "202...56Z"
        message: backup accepted
        reason: BackupAccepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "202..T10:02:56Z"
        message: Created Velero Backup object
        reason: BackupScheduled
        status: "True"
        type: Queued
      dataMoverDataUploads: {}
      fileSystemPodVolumeBackups:
        completed: 2
        total: 2
      phase: Created
      queueInfo:
        estimatedQueuePosition: 0
      veleroBackup:
        nacuuid: test-nac-test-nab-d2...a9b14
        name: test-nac-test-nab-d2...b14
        namespace: openshift-adp
        spec:
          csiSnapshotTimeout: 10m0s
          defaultVolumesToFsBackup: true
          excludedResources:
          - nonadminbackups
          - nonadminrestores
          - nonadminbackupstoragelocations
          - securitycontextconstraints
          - clusterroles
          - clusterrolebindings
          - priorityclasses
          - customresourcedefinitions
          - virtualmachineclusterinstancetypes
          - virtualmachineclusterpreferences
          hooks: {}
          includedNamespaces:
          - test-nac-ns
          itemOperationTimeout: 4h0m0s
          metadata: {}
          snapshotMoveData: false
          storageLocation: test-nac-test-bsl-bf..02b70a
          ttl: 720h0m0s
        status:
          completionTimestamp: "2025-0..3:13Z"
          expiration: "2025..2:56Z"
          formatVersion: 1.1.0
          hookStatus: {}
          phase: Completed
          progress:
            itemsBackedUp: 46
            totalItems: 46
          startTimestamp: "2025-..56Z"
          version: 1
          warnings: 1

    ここでは、以下のようになります。

    namespace
    NonAdminController CR がバックアップ対象の Velero バックアップオブジェクトに設定する名前空間名を指定します。
    メッセージ: バックアップが承認されました
    NAC が NAB CR を照合および検証し、Velero バックアップオブジェクトを作成したことを示します。
    fileSystemPodVolumeBackups
    FSB を使用してバックアップされるボリュームの数を指定します。
    フェーズ: 作成済み
    NAB CR が作成済み フェーズにあることを指定します。
    推定キュー位置
    バックアップオブジェクトのキュー上の位置を指定します。プロセス内に複数のバックアップが存在する可能性があり、各バックアップオブジェクトにはキューの位置が割り当てられます。バックアップが完了すると、キューの位置は 0 に設定されます。
    ナキュイド
    NAC が Velero バックアップオブジェクトを作成し、nacuuid フィールドの値を設定することを指定します。
    name
    関連付けられている Velero バックアップオブジェクトの名前を指定します。
    status
    Velero バックアップオブジェクトのステータスを指定します。
    フェーズ: 完了
    Velero バックアップオブジェクトが 完了 フェーズにあり、バックアップが正常に完了したことを示します。
5.19.3.3. 非管理者バックアップ CR の削除

名前空間管理者ユーザーであれば、非管理者バックアップ (NAB) カスタムリソース (CR) を削除できます。

前提条件

  • namespace admin ユーザーとしてクラスターにログインしている。
  • クラスター管理者が OADP Operator をインストールしている。
  • クラスター管理者が DataProtectionApplication (DPA) CR を設定して OADP Self-Service を有効化している。
  • クラスター管理者が namespace を作成し、その namespace からの操作を許可されている。
  • 承認されたネームスペースに NAB CR を作成しました。

手順

  1. 以下のコマンドを実行して、NonAdminBackup CR の YAML マニフェストファイルを編集します。

    $ oc edit <nab_cr> -n <authorized_namespace>

    ここでは、以下のようになります。

    <nab_cr>
    削除する NAB CR の名前を指定します。
    <authorized_namespace>
    承認されたネームスペースの名前を指定します。
  2. NAB CR YAML マニフェストファイルを更新し、次の例に示すように deleteBackup フラグを追加します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackup
    metadata:
      name: <nab_cr>
    spec:
      backupSpec:
        includedNamespaces:
        - <authorized_namespace>
        deleteBackup: true

    ここでは、以下のようになります。

    <nab_cr>
    削除する NAB CR の名前を指定してください。
    <authorized_namespace>
    承認済みネームスペースの名前を指定してください。
    deleteBackup: true
    deleteBackup フラグを追加し、true に設定します。

検証

  • 以下のコマンドを実行して、NAB CR が削除されたことを確認してください。

    $ oc get nab <nab_cr>

    <nab_cr> は、削除した NAB CR の名前です。

    以下のような出力が表示されるはずです。

    Error from server (NotFound): nonadminbackups.oadp.openshift.io "test-nab" not found
5.19.3.4. NonAdminRestore CR の作成

非管理者復元 (NAR) カスタムリソース (CR) を作成して、バックアップから承認済みネームスペースにアプリケーションリソースを復元します。これにより、クラスター管理者特権を必要とせずに、アプリケーションデータと設定を復元することが可能になります。

前提条件

  • namespace admin ユーザーとしてクラスターにログインしている。
  • クラスター管理者が OADP Operator をインストールしている。
  • クラスター管理者が DataProtectionApplication (DPA) CR を設定して OADP Self-Service を有効化している。
  • クラスター管理者が namespace を作成し、その namespace からの操作を許可されている。
  • NonAdminBackup (NAB) CR を作成することで、アプリケーションがバックアップされている。

手順

  1. NonAdminRestore CR を作成するには、次の設定で YAML マニフェストファイルを作成します。

    NonAdminRestore CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminRestore
    metadata:
      name: test-nar
    spec:
      restoreSpec:
        backupName: test-nab

    ここでは、以下のようになります。

    name
    NAR CR の名前を指定します。たとえば、test-nar
    バックアップ名
    復元元の NAB CR の名前を指定します。たとえば、test-nab などです。
  2. NAR CR 設定を適用するには、次のコマンドを実行します。

    $ oc apply -f <nar_cr_filename>

    <nar_cr_filename> は、NAR CR 設定を含むファイル名に置き換えます。

検証

  1. NAR CR が正常に作成されたことを確認するには、次のコマンドを実行します。

    $ oc get nar test-nar -o yaml

    出力例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminRestore
    metadata:
      creationTimestamp: "2025-..:15Z"
      finalizers:
      - nonadminrestore.oadp.openshift.io/finalizer
      generation: 2
      name: test-nar
      namespace: test-nac-ns
      resourceVersion: "156517"
      uid: f9f5...63ef34
    spec:
      restoreSpec:
        backupName: test-nab
        hooks: {}
        itemOperationTimeout: 0s
    status:
      conditions:
      - lastTransitionTime: "2025..15Z"
        message: restore accepted
        reason: RestoreAccepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2025-03-06T11:22:15Z"
        message: Created Velero Restore object
        reason: RestoreScheduled
        status: "True"
        type: Queued
      dataMoverDataDownloads: {}
      fileSystemPodVolumeRestores:
        completed: 2
        total: 2
      phase: Created
      queueInfo:
        estimatedQueuePosition: 0
      veleroRestore:
        nacuuid: test-nac-test-nar-c...1ba
        name: test-nac-test-nar-c7...1ba
        namespace: openshift-adp
        status:
          completionTimestamp: "2025...22:44Z"
          hookStatus: {}
          phase: Completed
          progress:
            itemsRestored: 28
            totalItems: 28
          startTimestamp: "2025..15Z"
          warnings: 7

    ここでは、以下のようになります。

    メッセージ: 復元が承認されました
    非管理者コントローラー (NAC) CR が NAR CR を調整および検証したことを指定します。
    fileSystemPodVolumeRestores
    復元されるボリュームの数を指定します。
    フェーズ: 作成済み
    NAR CR が 作成済み フェーズにあることを指定します。
    推定キュー位置
    復元オブジェクトのキュー上の位置を指定します。プロセス内に複数の復元が存在する可能性があり、各復元にはキューの位置が割り当てられます。復元が完了すると、キューの位置は 0 に設定されます。
    ナキュイド
    NAC が Velero 復元オブジェクトを作成し、nacuuid 値を設定することを指定します。
    name
    関連付けられた Velero リストアオブジェクトの名前を指定します。
    フェーズ: 完了
    Velero の リストアオブジェクトが 完了 フェーズにあり、リストアが成功したことを示します。
5.19.3.5. NonAdminDownloadRequest CR について

NonAdminDownloadRequest (NADR) カスタムリソース (CR) を使用して、バックアップおよび復元ログを確認します。これにより、クラスター管理者の支援なしに、バックアップと復元に関する問題のトラブルシューティングを行うことができます。

NADR CR は、クラスター管理者が velero backup describe --details コマンドを使用してアクセスできる情報と同等の情報を提供します。

NADR CR 要求が検証された後、要求された情報にアクセスするためのセキュアなダウンロード URL が生成されます。

次の NADR リソースをダウンロードできます。

Expand
表5.8 NADR リソース

Resource type

説明

以下に相当

BackupResourceList

バックアップに含まれるリソースの一覧

velero backup describe --details (リソースリスト)

BackupContents

バックアップされたファイルの内容

バックアップの詳細の一部

BackupLog

バックアップ操作からのログ

velero backup logs

BackupVolumeSnapshots

ボリュームスナップショットに関する情報

velero backup describe --details (スナップショットセクション)

BackupItemOperations

バックアップ中に実行されたアイテム操作に関する情報

velero backup describe --details (操作セクション)

RestoreLog

復元操作からのログ

velero restore logs

RestoreResults

復元結果の詳細

velero restore describe --details

5.19.3.6. NAB ログと NAR ログの確認

NonAdminBackup (NAB) および NonAdminRestore (NAR) 操作の詳細ログにアクセスして確認するために、NonAdminDownloadRequest (NADR) カスタムリソース (CR) を作成します。これにより、バックアップと復元に関する問題を独自にトラブルシューティングできるようになります。

注記

NAB ログは、バックアップの Backup Storage Location として NonAdminBackupStorageLocation (NABSL) CR を使用している場合にのみ確認できます。

前提条件

  • namespace admin ユーザーとしてクラスターにログインしている。
  • クラスター管理者が OADP Operator をインストールしている。
  • クラスター管理者が DataProtectionApplication (DPA) CR を設定して OADP Self-Service を有効化している。
  • クラスター管理者が namespace を作成し、その namespace からの操作を許可されている。
  • NAB CR の作成によるアプリケーションのバックアップがある。
  • NAR CR の作成によりアプリケーションを復元している。

手順

  1. NAB CR ログを確認するには、以下の例のように NonAdminDownloadRequest CR を作成し、NAB CR 名を指定します。

    NonAdminDownloadRequest CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminDownloadRequest
    metadata:
      name: test-nadr-backup
    spec:
      target:
        kind: BackupLog
        name: test-nab

    ここでは、以下のようになります。

    kind
    NADR CR の kind フィールドの値として BackupLog を 指定します。
    name
    NAB CR の名前を指定します。
  2. NADR CR が処理されたことを確認するには、次のコマンドを実行します。

    $ oc get nadr test-nadr-backup -o yaml

    出力例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminDownloadRequest
    metadata:
      creationTimestamp: "2025-03-06T10:05:22Z"
      generation: 1
      name: test-nadr-backup
      namespace: test-nac-ns
      resourceVersion: "134866"
      uid: 520...8d9
    spec:
      target:
        kind: BackupLog
        name: test-nab
    status:
      conditions:
      - lastTransitionTime: "202...5:22Z"
        message: ""
        reason: Success
        status: "True"
        type: Processed
      phase: Created
      velero:
        status:
          downloadURL: https://...
          expiration: "202...22Z"
          phase: Processed

    ここでは、以下のようになります。

    ダウンロード URL
    status.downloadURL フィールドには、NAB ログのダウンロード URL が含まれます。downloadURL を使用して NAB ログをダウンロードし、確認できます。
    phase
    status.phaseProcessed です。
  3. status.downloadURL URL を使用して、バックアップ情報をダウンロードして分析します。
  4. NAR CR ログを確認するには、NonAdminDownloadRequest CR を作成し、次の例に示すように NAR CR 名を指定します。

    NonAdminDownloadRequest CR の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminDownloadRequest
    metadata:
      name: test-nadr-restore
    spec:
      target:
        kind: RestoreLog
        name: test-nar

    ここでは、以下のようになります。

    kind
    NADR CR の kind フィールドの値として RestoreLog を 指定します。
    name
    NAR CR の名前を指定します。
  5. NADR CR が処理されたことを確認するには、次のコマンドを実行します。

    $ oc get nadr test-nadr-restore -o yaml

    出力例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminDownloadRequest
    metadata:
      creationTimestamp: "2025-03-06T11:26:01Z"
      generation: 1
      name: test-nadr-restore
      namespace: test-nac-ns
      resourceVersion: "157842"
      uid: f3e...7862f
    spec:
      target:
        kind: RestoreLog
        name: test-nar
    status:
      conditions:
      - lastTransitionTime: "202..:01Z"
        message: ""
        reason: Success
        status: "True"
        type: Processed
      phase: Created
      velero:
        status:
          downloadURL: https://...
          expiration: "202..:01Z"
          phase: Processed

    ここでは、以下のようになります。

    ダウンロード URL
    status.downloadURL フィールドには、NAR ログのダウンロード URL が含まれます。downloadURL を使用して NAR ログをダウンロードし、確認できます。
    phase
    status.phaseProcessed です。
  6. status.downloadURL URL を使用して、復元情報をダウンロードして分析します。

5.19.4. OADP Self-Service のトラブルシューティング

OADP セルフサービス使用時に発生する一般的なエラーや問題を解決するには、バックアップ保存場所とバックアップ操作に関するトラブルシューティング手順に従ってください。これにより、問題を迅速に特定し、自力で解決できるようになります。

5.19.4.1. 名前空間に NonAdminBackupStorageLocation が見つからないというエラーを解決しています

バックアップと同じ名前空間に属するバックアップストレージの場所を使用することで、NonAdminBackupStorageLocation が名前空間に見つかりません というエラーを解決できます。これはバックアップ操作の成功を確実にするのに役立ちます。

namespace admin バックアップの以下のシナリオを検討してください。

  • 2 つの異なる namespace (例: namespace-1nabsl-1 および namespace-2nabsl-2) に 2 つの NonAdminBackupStorageLocations (NABL) カスタムリソース (CR) を作成している。
  • namespace-1 のバックアップを取得し、NonAdminBackup (NAB) CR で nabsl-2 を使用している。

このシナリオでは、NAB CR を作成した後、次のエラーが発生します。このエラーの原因は、NABSL CR がバックアップしようとしている namespace に属していないことです。

apiVersion: oadp.openshift.io/v1alpha1
kind: NonAdminBackup
...
status:
  conditions:
  - lastTransitionTime: "2025-02-20T10:13:00Z"
  message: 'NonAdminBackupStorageLocation not found in the namespace: NonAdminBackupStorageLocation.oadp.openshift.io
    "nabsl2" not found'
  reason: InvalidBackupSpec
  status: "False"
  type: Accepted
  phase: BackingOff

手順

  • バックアップしようとしているのと同じ namespace に属する NABSL を使用します。

    このシナリオでは、NAB CR の nabsl-1 を使用して、namespace-1 をバックアップする必要があります。

5.19.4.2. エラー NonAdminBackupStorageLocation をデフォルトとして設定できませんを解決しています

NonAdminBackupStorageLocation (NABSL) カスタムリソース (CR) をデフォルトのバックアップ保存場所として設定したときに発生するエラーを解決します。これにより、検証エラーを解決し、バックアップ保存場所を正しく設定できます。

管理者権限を持たないユーザーの場合、承認された名前空間に NABSL CR を作成した場合、その NABSL CR をデフォルトのバックアップ保存場所として設定することはできません。

NABSL CR をデフォルトのバックアップ保存場所として設定すると、NABSL CR の検証に失敗し、NonAdminController (NAC) からエラーメッセージが表示されます。

NonAdminBackupStorageLocation cannot be used as a default BSL

手順

  • NABSL CR を正常に検証および調整するには、NABSL CR の デフォルト フィールドを false に設定してください。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: NonAdminBackupStorageLocation
    ...
    spec:
      backupStorageLocationSpec:
        credential:
          key: cloud
          name: cloud-credentials-gcp
        default: false
        objectStorage:
          bucket: oad..7l8
          prefix: velero
        provider: gcp

    ここでは、以下のようになります。

    default
    デフォルトの バックアップ保存場所が false に設定されていることを指定します。

5.20. OADP と ROSA

5.20.1. OADP を使用して ROSA クラスター上のアプリケーションをバックアップする

アプリケーションデータのバックアップと復元を行うには、Red Hat OpenShift Service on AWS (ROSA) クラスターで OpenShift API for Data Protection (OADP) を使用します。

ROSA は、フルマネージドのターンキーアプリケーションプラットフォームであり、アプリケーションを構築してデプロイすることにより、お客様に価値を提供することに集中できます。

ROSA は、幅広い Amazon Web Services (AWS) コンピュート、データベース、分析、機械学習、ネットワーク、モバイル、およびその他のサービスとのシームレスな統合を提供し、差別化されたエクスペリエンスの構築とお客様への提供をさらに高速化します。

AWS アカウントから直接サービスをサブスクライブできます。

クラスターを作成したら、OpenShift Container Platform の Web コンソールまたは Red Hat OpenShift Cluster Manager を使用してクラスターを操作できます。ROSA では、OpenShift API やコマンドラインインターフェイス (CLI) ツールも使用できます。

ROSA のインストールに関する詳細は、Red Hat OpenShift Service on AWS(ROSA) のインストール のインタラクティブな手順を参照してください。

OpenShift API for Data Protection (OADP) をインストールする前に、OADP が Amazon Web Services API を使用できるように、OADP のロールとポリシーの認証情報を設定する必要があります。

このプロセスは次の 2 段階で実行されます。

  1. AWS 認証情報を準備します。
  2. OADP Operator をインストールし、IAM ロールを付与します。
5.20.1.1. OADP 用の AWS 認証情報を準備する

OpenShift API for Data Protection (OADP) をインストールするために、Amazon Web Services アカウントを準備および設定します。

手順

  1. 次のコマンドを実行して、以下の環境変数を作成します。

    重要

    クラスターに一致するようにクラスター名を変更し、管理者としてクラスターにログインしていることを確認してください。続行する前に、すべてのフィールドが正しく出力されていることを確認します。

    $ export CLUSTER_NAME=<my_cluster>

    <my_cluster> を あなたのクラスター名に置き換えてください。

    $ export ROSA_CLUSTER_ID=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .id)
    $ export REGION=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .region.id)
    $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||')
    $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    $ export CLUSTER_VERSION=$(rosa describe cluster -c ${CLUSTER_NAME} -o json | jq -r .version.raw_id | cut -f -2 -d '.')
    $ export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials"
    $ export SCRATCH="/tmp/${CLUSTER_NAME}/oadp"
    $ mkdir -p ${SCRATCH}
    $ echo "Cluster ID: ${ROSA_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint:
      ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
  2. AWS アカウントで、AWS S3 へのアクセスを許可する IAM ポリシーを作成します。

    1. 以下のコマンドを実行して、ポリシーが存在するかどうかを確認します。

      $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text)
      • RosaOadp: RosaOadp は、実際のポリシー名に置き換えます。
    2. 次のコマンドを入力してポリシー JSON ファイルを作成し、ポリシーを作成します。

      注記

      ポリシー ARN が見つからない場合、コマンドはポリシーを作成します。ポリシー ARN がすでに存在する場合、if ステートメントはポリシーの作成を意図的にスキップします。

      $ if [[ -z "${POLICY_ARN}" ]]; then
        cat << EOF > ${SCRATCH}/policy.json
        {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Action": [
              "s3:CreateBucket",
              "s3:DeleteBucket",
              "s3:PutBucketTagging",
              "s3:GetBucketTagging",
              "s3:PutEncryptionConfiguration",
              "s3:GetEncryptionConfiguration",
              "s3:PutLifecycleConfiguration",
              "s3:GetLifecycleConfiguration",
              "s3:GetBucketLocation",
              "s3:ListBucket",
              "s3:GetObject",
              "s3:PutObject",
              "s3:DeleteObject",
              "s3:ListBucketMultipartUploads",
              "s3:AbortMultipartUpload",
              "s3:ListMultipartUploadParts",
              "ec2:DescribeSnapshots",
              "ec2:DescribeVolumes",
              "ec2:DescribeVolumeAttribute",
              "ec2:DescribeVolumesModifications",
              "ec2:DescribeVolumeStatus",
              "ec2:CreateTags",
              "ec2:CreateVolume",
              "ec2:CreateSnapshot",
              "ec2:DeleteSnapshot"
            ],
            "Resource": "*"
          }
        ]}
      EOF
      
        POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \
        --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \
        --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \
        --output text)
        fi
      • SCRATCH: SCRATCH は、環境変数用に作成された一時ディレクトリーの名前です。
    3. 以下のコマンドを実行してポリシー ARN を表示します。

      $ echo ${POLICY_ARN}
  3. クラスターの IAM ロール信頼ポリシーを作成します。

    1. 次のコマンドを実行して、信頼ポリシーファイルを作成します。

      $ cat <<EOF > ${SCRATCH}/trust-policy.json
        {
            "Version": "2012-10-17",
            "Statement": [{
              "Effect": "Allow",
              "Principal": {
                "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
              },
              "Action": "sts:AssumeRoleWithWebIdentity",
              "Condition": {
                "StringEquals": {
                  "${OIDC_ENDPOINT}:sub": [
                    "system:serviceaccount:openshift-adp:openshift-adp-controller-manager",
                    "system:serviceaccount:openshift-adp:velero"]
                }
              }
            }]
        }
      EOF
    2. 以下のコマンドを実行してロールを作成します。

      $ ROLE_ARN=$(aws iam create-role --role-name \
        "${ROLE_NAME}" \
        --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
        --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} \
               Key=rosa_openshift_version,Value=${CLUSTER_VERSION} \
               Key=rosa_role_prefix,Value=ManagedOpenShift \
               Key=operator_namespace,Value=openshift-adp \
               Key=operator_name,Value=openshift-oadp \
        --query Role.Arn --output text)
    3. 次のコマンドを実行して、ロール ARN を表示します。

      $ echo ${ROLE_ARN}
  4. 次のコマンドを実行して、IAM ポリシーを IAM ロールにアタッチします。

    $ aws iam attach-role-policy --role-name "${ROLE_NAME}" \
      --policy-arn ${POLICY_ARN}
5.20.1.2. OADP Operator のインストールおよび IAM ロールの指定

AWS STS を使用しているクラスターに OpenShift API for Data Protection (OADP) をインストールします。AWS Security Token Service (AWS STS) は、IAM またはフェデレーションされたユーザーの短期認証情報を提供するグローバル Web サービスです。STS を使用した OpenShift Container Platform は、推奨される認証情報モードです。

重要

Restic はサポートされていません。

Container Storage Interface (CSI) スナップショットをサポートしていないファイルシステムをバックアップする場合は、Kopia ファイルシステムバックアップ (FSB) がサポートされます。

ファイルシステムの例には次のものがあります。

  • Amazon Elastic File System (EFS)
  • Network File System (NFS)
  • emptyDir ボリューム
  • ローカルボリューム

ボリュームをバックアップする場合、AWS STS を使用する ROSA の OADP では、ネイティブスナップショットと Container Storage Interface (CSI) スナップショットが推奨されます。Data Mover バックアップはサポートされていますが、ネイティブスナップショットよりも遅くなる可能性があります。

STS 認証を使用する Amazon ROSA クラスターでは、別の AWS リージョンでのバックアップデータの復元はサポートされていません。

前提条件

  • 必要なアクセスとトークンを備えた OpenShift Container Platform クラスター。詳細は、前の手順である OADP 用の AWS 認証情報の準備 を参照してください。バックアップと復元に 2 つの異なるクラスターを使用する予定の場合は、ROLE_ARN を含む AWS 認証情報をクラスターごとに準備する必要があります。

手順

  1. 次のコマンドを入力して、AWS トークンファイルから OpenShift Container Platform シークレットを作成します。

    1. 認証情報ファイルを作成します。

      $ cat <<EOF > ${SCRATCH}/credentials
        [default]
        role_arn = ${ROLE_ARN}
        web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
        region = <aws_region>
      EOF

      <aws_region> は、STS エンドポイントに使用する AWS リージョンに置き換えます。

    2. OADP の namespace を作成します。

      $ oc create namespace openshift-adp
    3. OpenShift Container Platform シークレットを作成します。

      $ oc -n openshift-adp create secret generic cloud-credentials \
        --from-file=${SCRATCH}/credentials
      注記

      OpenShift Container Platform バージョン 4.15 以降では、OADP Operator は Operator Lifecycle Manager (OLM) および Cloud Credentials Operator (CCO) を通じて、標準化された新しい STS ワークフローをサポートします。このワークフローでは、上記シークレットの作成は必要ありません。OpenShift Container Platform Web コンソールを使用して、OLM で管理される Operator のインストール中にロール ARN のみ指定する必要があります。詳細は、Web コンソールを使用してソフトウェアカタログからインストールする を参照してください。

      前述のシークレットは CCO によって自動的に作成されます。

  2. OADP Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、EcosystemSoftware Catalog を参照します。
    2. OADP Operator を検索します。
    3. role_ARN フィールドに、前に作成した role_arn を貼り付け、Install をクリックします。
  3. 次のコマンドを入力し、AWS 認証情報を使用して AWS クラウドストレージを作成します。

    $ cat << EOF | oc create -f -
      apiVersion: oadp.openshift.io/v1alpha1
      kind: CloudStorage
      metadata:
        name: ${CLUSTER_NAME}-oadp
        namespace: openshift-adp
      spec:
        creationSecret:
          key: credentials
          name: cloud-credentials
        enableSharedConfig: true
        name: ${CLUSTER_NAME}-oadp
        provider: aws
        region: $REGION
    EOF
  4. 次のコマンドを入力して、アプリケーションのストレージのデフォルトストレージクラスを確認します。

    $ oc get pvc -n <namespace>
    NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
    mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h
  5. 次のコマンドを実行してストレージクラスを取得します。

    $ oc get storageclass
    NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
    gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    注記

    次のストレージクラスが機能します。

    • gp3-csi
    • gp2-csi
    • gp3
    • gp2

    すべてのアプリケーション、またはバックアップされるアプリケーションが Container Storage Interface (CSI) で永続ボリューム (PV) を使用している場合は、OADP DPA 設定に CSI プラグインを含めることをお勧めします。

  6. バックアップとボリュームスナップショットが保存されるストレージへの接続を設定するために、DataProtectionApplication リソースを作成します。

    1. CSI ボリュームのみを使用している場合は、次のコマンドを入力して Data Protection Application をデプロイします。

      $ cat << EOF | oc create -f -
        apiVersion: oadp.openshift.io/v1alpha1
        kind: DataProtectionApplication
        metadata:
          name: ${CLUSTER_NAME}-dpa
          namespace: openshift-adp
        spec:
          backupImages: true
          features:
            dataMover:
              enable: false
          backupLocations:
          - bucket:
              cloudStorageRef:
                name: ${CLUSTER_NAME}-oadp
              credential:
                key: credentials
                name: cloud-credentials
              prefix: velero
              default: true
              config:
                region: ${REGION}
          configuration:
            velero:
              defaultPlugins:
              - openshift
              - aws
              - csi
            nodeAgent:
              enable: false
              uploaderType: kopia
      EOF

      ここでは、以下のようになります。

      backupImages
      ROSA は内部イメージバックアップをサポートします。イメージのバックアップを使用しない場合は、このフィールドを false に設定します。
      ノードエージェント
      この手順の最後に記載されている nodeAgent 属性に関する重要な注意事項を参照してください。
      アップローダータイプ
      アップローダーの種類を指定します。ビルトイン Data Mover は、uploaderType フィールドの値に関係なく、デフォルトのアップローダーメカニズムとして Kopia を使用します。
    2. CSI ボリュームまたは非 CSI ボリュームを使用している場合は、次のコマンドを入力して Data Protection Application をデプロイします。

      $ cat << EOF | oc create -f -
        apiVersion: oadp.openshift.io/v1alpha1
        kind: DataProtectionApplication
        metadata:
          name: ${CLUSTER_NAME}-dpa
          namespace: openshift-adp
        spec:
          backupImages: true
          backupLocations:
          - bucket:
              cloudStorageRef:
                name: ${CLUSTER_NAME}-oadp
              credential:
                key: credentials
                name: cloud-credentials
              prefix: velero
              default: true
              config:
                region: ${REGION}
          configuration:
            velero:
              defaultPlugins:
              - openshift
              - aws
            nodeAgent:
              enable: false
              uploaderType: restic
          snapshotLocations:
            - velero:
                config:
                  credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials
                  enableSharedConfig: "true"
                  profile: default
                  region: ${REGION}
                provider: aws
      EOF

      ここでは、以下のようになります。

      backupImages
      ROSA は内部イメージバックアップをサポートします。イメージのバックアップを使用しない場合は、このフィールドを false に設定します。
      ノードエージェント
      この手順の最後に記載されている nodeAgent 属性に関する重要な注意事項を参照してください。
      credentialsFile
      バケット認証情報が Pod にマウントされる場所を指定します。
      enableSharedConfig
      スナップショットの場所が、 バケットに定義された認証情報を共有または再利用できるかどうかを指定します。
      profile
      AWS 認証情報ファイルに設定されているプロファイル名を指定します。
      region

      AWS リージョンを指定します。これはクラスターリージョンと同じである必要があります。

      これで、アプリケーションのバックアップ で説明されているとおり、OpenShift Container Platform アプリケーションをバックアップおよび復元する準備が整いました。

      重要

      OADP は ROSA 環境で Restic をサポートしていないため、resticenable パラメーターは false に設定されています。

    バックアップと復元に 2 つの異なるクラスターを使用する場合、クラウドストレージ CR と OADP DataProtectionApplication 設定の両方で、2 つのクラスターの AWS S3 ストレージ名が同じである必要があります。

5.20.1.3. OADP Operator サブスクリプションの IAM ロール ARN の更新

IAM ロールの Amazon Resource Name (ARN) が間違っているために発生するインストールエラーを修正するために、OADPOperator のサブスクリプションを更新します。

ROSA Security Token Service (STS) クラスターに OADP Operator をインストールするときに、IAM ロールの Amazon Resource Name (ARN) を誤って指定すると、openshift-adp-controller Pod でエラーが発生します。生成された認証情報リクエストに間違った IAM ロール ARN が含まれています。認証情報リクエストオブジェクトを正しい IAM ロール ARN で更新するには、OADP Operator サブスクリプションを編集し、IAM ロール ARN に正しい値を適用します。OADP Operator のサブスクリプションを編集すると、IAM ロール ARN を更新するために OADP をアンインストールして再インストールする必要がなくなります。

前提条件

  • 必要なアクセスとトークンを備えた Red Hat OpenShift Service on AWS STS クラスターがある。
  • ROSA STS クラスターに OADP がインストールされている。

手順

  1. OADP サブスクリプションに間違った IAM ロール ARN 環境変数が設定されていることを確認するには、次のコマンドを実行します。

    $ oc get sub -o yaml redhat-oadp-operator

    Subscription の例

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      annotations:
      creationTimestamp: "2025-01-15T07:18:31Z"
      generation: 1
      labels:
        operators.coreos.com/redhat-oadp-operator.openshift-adp: ""
      name: redhat-oadp-operator
      namespace: openshift-adp
      resourceVersion: "77363"
      uid: 5ba00906-5ad2-4476-ae7b-ffa90986283d
    spec:
      channel: stable-1.4
      config:
        env:
        - name: ROLEARN
          value: arn:aws:iam::11111111:role/wrong-role-arn
      installPlanApproval: Manual
      name: redhat-oadp-operator
      source: prestage-operators
      sourceNamespace: openshift-marketplace
      startingCSV: oadp-operator.v1.4.2

    ここでは、以下のようになります。

    ロールラーン
    更新する ROLEARN の値を確認します。
  2. 次のコマンドを実行して、サブスクリプションの ROLEARN フィールドを正しいロール ARN で更新します。

    $ oc patch subscription redhat-oadp-operator -p '{"spec": {"config": {"env": [{"name": "ROLEARN", "value": "<role_arn>"}]}}}' --type='merge'

    ここでは、以下のようになります。

    <role_arn>
    更新する IAM ロール ARN を指定します。たとえば、arn:aws:iam::160…..6956:role/oadprosa…..8wlf です。
  3. 次のコマンドを実行して、secret オブジェクトが正しいロール ARN 値で更新されていることを確認します。

    $ oc get secret cloud-credentials -o jsonpath='{.data.credentials}' | base64 -d

    出力例

    [default]
    sts_regional_endpoints = regional
    role_arn = arn:aws:iam::160.....6956:role/oadprosa.....8wlf
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

  4. 次の例に示すように、DataProtectionApplication カスタムリソース (CR) マニフェストファイルを設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: test-rosa-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - bucket:
          config:
            region: us-east-1
          cloudStorageRef:
            name: <cloud_storage>
          credential:
            name: cloud-credentials
            key: credentials
          prefix: velero
          default: true
      configuration:
        velero:
          defaultPlugins:
          - aws
          - openshift

    ここでは、以下のようになります。

    < クラウドストレージ >
    CloudStorage CR を指定します。
  5. 次のコマンドを実行して、DataProtectionApplication CR を作成します。

    $ oc create -f <dpa_manifest_file>
  6. 次のコマンドを実行して、DataProtectionApplication CR が調整され、status"True" に設定されていることを確認します。

    $  oc get dpa -n openshift-adp -o yaml

    DataProtectionApplication の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    status:
        conditions:
        - lastTransitionTime: "2023-07-31T04:48:12Z"
          message: Reconcile complete
          reason: Complete
          status: "True"
          type: Reconciled

  7. 次のコマンドを実行して、BackupStorageLocation CR が使用可能な状態であることを確認します。

    $ oc get backupstoragelocations.velero.io -n openshift-adp

    例: BackupStorageLocation

    NAME       PHASE       LAST VALIDATED   AGE   DEFAULT
    ts-dpa-1   Available   3s               6s    true

5.20.1.4. 例:OADP と OpenShift Container Platform を使用したバックアップの実行

OpenShift Container Platform で OpenShift API for Data Protection (OADP) を使用してバックアップを実行します。次の hello-world アプリケーションの例では、永続ボリューム (PV) がアタッチされていません。

どちらの Data Protection Application (DPA) 設定も機能します。

手順

  1. 次のコマンドを実行して、バックアップするワークロードを作成します。

    $ oc create namespace hello-world
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
  2. 次のコマンドを実行してルートを公開します。

    $ oc expose service/hello-openshift -n hello-world
  3. 次のコマンドを実行して、アプリケーションが動作していることを確認します。

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    次の例のような出力が表示されます。

    Hello OpenShift!
  4. 次のコマンドを実行して、ワークロードをバックアップします。

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Backup
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        includedNamespaces:
        - hello-world
        storageLocation: ${CLUSTER_NAME}-dpa-1
        ttl: 720h0m0s
    EOF
  5. バックアップが完了するまで待ってから、次のコマンドを実行します。

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"

    次の例のような出力が表示されます。

    {
      "completionTimestamp": "2022-09-07T22:20:44Z",
      "expiration": "2022-10-07T22:20:22Z",
      "formatVersion": "1.1.0",
      "phase": "Completed",
      "progress": {
        "itemsBackedUp": 58,
        "totalItems": 58
      },
      "startTimestamp": "2022-09-07T22:20:22Z",
      "version": 1
    }
  6. 次のコマンドを実行して、デモワークロードを削除します。

    $ oc delete ns hello-world
  7. 次のコマンドを実行して、バックアップからワークロードを復元します。

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        backupName: hello-world
    EOF
  8. 次のコマンドを実行して、復元が完了するまで待ちます。

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"

    次の例のような出力が表示されます。

    {
      "completionTimestamp": "2022-09-07T22:25:47Z",
      "phase": "Completed",
      "progress": {
        "itemsRestored": 38,
        "totalItems": 38
      },
      "startTimestamp": "2022-09-07T22:25:28Z",
      "warnings": 9
    }
  9. 次のコマンドを実行して、ワークロードが復元されていることを確認します。

    $ oc -n hello-world get pods

    次の例のような出力が表示されます。

    NAME                              READY   STATUS    RESTARTS   AGE
    hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s
  10. 次のコマンドを実行して JSONPath を確認します。

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

    次の例のような出力が表示されます。

    Hello OpenShift!
    注記

    トラブルシューティングのヒントについては、トラブルシューティングのドキュメント を参照してください。

5.20.1.5. OADP と ROSA STS を使用してバックアップ後のクラスターをクリーンアップする

OpenShift API for Data Protection (OADP) Operator を、hello-world サンプルで使用したバックアップと S3 バケットとともにアンインストールします。

手順

  1. 次のコマンドを実行して、ワークロードを削除します。

    $ oc delete ns hello-world
  2. 次のコマンドを実行して、Data Protection Application (DPA) を削除します。

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
  3. 次のコマンドを実行して、クラウドストレージを削除します。

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    警告

    このコマンドがハングした場合は、次のコマンドを実行してファイナライザーを削除する必要がある場合があります。

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
  4. Operator が不要になった場合は、次のコマンドを実行して削除します。

    $ oc -n openshift-adp delete subscription oadp-operator
  5. Operator から namespace を削除します。

    $ oc delete ns openshift-adp
  6. バックアップおよび復元リソースが不要になった場合は、次のコマンドを実行してクラスターからリソースを削除します。

    $ oc delete backups.velero.io hello-world
  7. AWS S3 のバックアップ、復元、およびリモートオブジェクトを削除するには、次のコマンドを実行します。

    $ velero backup delete hello-world
  8. カスタムリソース定義 (CRD) が不要になった場合は、次のコマンドを実行してクラスターから削除します。

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
  9. 次のコマンドを実行して、AWS S3 バケットを削除します。

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
  10. 次のコマンドを実行して、ロールからポリシーを切り離します。

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
  11. 以下のコマンドを実行してロールを削除します。

    $ aws iam delete-role --role-name "${ROLE_NAME}"

5.21. OADP と AWS STS

5.21.1. OADP を使用して AWS STS クラスター上のアプリケーションをバックアップする

OADP Operator をインストールすることで、Amazon Web Services (AWS) と連携した OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.16 をインストールします。

注記

OADP 1.0.4 以降、すべての OADP 1.0.z バージョンは Migration Toolkit for Containers Operator の依存関係としてのみ使用でき、スタンドアロン Operator として使用することはできません。

Velero 用に AWS を設定し、デフォルトの Secret を作成してから、Data Protection Application をインストールします。詳細は、OADP Operator のインストールを 参照してください。

制限されたネットワーク環境に OADP Operator をインストールするには、まずデフォルトのソフトウェアカタログソースを無効にし、Operator カタログをミラーリングする必要があります。非接続環境での Operator Lifecycle Manager の使用法を 参照してください。

OADP は、AWS Security Token Service (STS) (AWS STS) クラスターに手動でインストールできます。Amazon AWS は、ユーザーのために権限が限られた一時的な認証情報を要求できる AWS STS を Web サービスとして提供しています。STS を使用すると、API 呼び出し、AWS コンソール、または AWS コマンドラインインターフェイス (CLI) を介してリソースへの一時的なアクセスを信頼できるユーザーに提供できます。

OpenShift API for Data Protection (OADP) をインストールする前に、OADP が Amazon Web Services API を使用できるように、OADP のロールとポリシーの認証情報を設定する必要があります。

このプロセスは次の 2 段階で実行されます。

  1. AWS 認証情報を準備します。
  2. OADP Operator をインストールし、IAM ロールを付与します。
5.21.1.1. OADP 用の AWS STS 認証情報を準備する

Amazon Web Services アカウントを設定して、OpenShift API for Data Protection (OADP) をインストールします。次の手順に従って AWS 認証情報を準備します。

手順

  1. 次のコマンドを実行して、cluster_name 環境変数を定義します。

    $ export CLUSTER_NAME= <AWS_cluster_name>

    <AWS_cluster_name> を クラスター名に置き換えてください。

  2. 次のコマンドを実行して、AWS_ACCOUNT_ID, OIDC_ENDPOINT などの cluster の詳細をすべて取得します。

    $ export CLUSTER_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')
    $ export AWS_CLUSTER_ID=$(oc get clusterversion version -o jsonpath='{.spec.clusterID}{"\n"}')
    $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||')
    $ export REGION=$(oc get infrastructures cluster -o jsonpath='{.status.platformStatus.aws.region}' --allow-missing-template-keys=false || echo us-east-2)
    $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    $ export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials"
  3. 次のコマンドを実行して、すべてのファイルを保存するための一時ディレクトリーを作成します。

    $ export SCRATCH="/tmp/${CLUSTER_NAME}/oadp"
    mkdir -p ${SCRATCH}
  4. 次のコマンドを実行して、収集したすべての詳細を表示します。

    $ echo "Cluster ID: ${AWS_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint:
    ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
  5. AWS アカウントで、AWS S3 へのアクセスを許可する IAM ポリシーを作成します。

    1. 次のコマンドを実行して、ポリシーが存在するかどうかを確認します。

      $ export POLICY_NAME="OadpVer1"
      • POLICY_NAME: この変数は任意の値に設定できます。
      $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='$POLICY_NAME'].{ARN:Arn}" --output text)
    2. 次のコマンドを入力してポリシー JSON ファイルを作成し、ポリシーを作成します。

      注記

      ポリシー ARN が見つからない場合、コマンドはポリシーを作成します。ポリシー ARN がすでに存在する場合、if ステートメントはポリシーの作成を意図的にスキップします。

      $ if [[ -z "${POLICY_ARN}" ]]; then
      cat << EOF > ${SCRATCH}/policy.json
      {
      "Version": "2012-10-17",
      "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:CreateBucket",
           "s3:DeleteBucket",
           "s3:PutBucketTagging",
           "s3:GetBucketTagging",
           "s3:PutEncryptionConfiguration",
           "s3:GetEncryptionConfiguration",
           "s3:PutLifecycleConfiguration",
           "s3:GetLifecycleConfiguration",
           "s3:GetBucketLocation",
           "s3:ListBucket",
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject",
           "s3:ListBucketMultipartUploads",
           "s3:AbortMultipartUpload",
           "s3:ListMultipartUploadParts",
           "ec2:DescribeSnapshots",
           "ec2:DescribeVolumes",
           "ec2:DescribeVolumeAttribute",
           "ec2:DescribeVolumesModifications",
           "ec2:DescribeVolumeStatus",
           "ec2:CreateTags",
           "ec2:CreateVolume",
           "ec2:CreateSnapshot",
           "ec2:DeleteSnapshot"
         ],
         "Resource": "*"
       }
      ]}
      EOF
      
      POLICY_ARN=$(aws iam create-policy --policy-name $POLICY_NAME \
      --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \
      --tags Key=openshift_version,Value=${CLUSTER_VERSION} Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=oadp \
      --output text)
      fi
      • SCRATCH: ファイルを保存するために作成した一時ディレクトリーの名前。
    3. 以下のコマンドを実行してポリシー ARN を表示します。

      $ echo ${POLICY_ARN}
  6. クラスターの IAM ロール信頼ポリシーを作成します。

    1. 次のコマンドを実行して、信頼ポリシーファイルを作成します。

      $ cat <<EOF > ${SCRATCH}/trust-policy.json
      {
          "Version": "2012-10-17",
          "Statement": [{
            "Effect": "Allow",
            "Principal": {
              "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
              "StringEquals": {
                "${OIDC_ENDPOINT}:sub": [
                  "system:serviceaccount:openshift-adp:openshift-adp-controller-manager",
                  "system:serviceaccount:openshift-adp:velero"]
              }
            }
          }]
      }
      EOF
    2. 次のコマンドを実行して、クラスターの IAM ロール信頼ポリシーを作成します。

      $ ROLE_ARN=$(aws iam create-role --role-name \
        "${ROLE_NAME}" \
        --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
        --tags Key=cluster_id,Value=${AWS_CLUSTER_ID}  Key=openshift_version,Value=${CLUSTER_VERSION} Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=oadp --query Role.Arn --output text)
    3. 次のコマンドを実行して、ロール ARN を表示します。

      $ echo ${ROLE_ARN}
  7. 次のコマンドを実行して、IAM ポリシーを IAM ロールにアタッチします。

    $ aws iam attach-role-policy --role-name "${ROLE_NAME}" --policy-arn ${POLICY_ARN}
5.21.1.2. OADP Operator のインストールおよび IAM ロールの指定

AWS STS クラスターに OpenShift API for Data Protection (OADP) をインストールします。AWS Security Token Service (AWS STS) は、IAM またはフェデレーションされたユーザーの短期認証情報を提供するグローバル Web サービスです。

重要

Restic はサポートされていません。

Container Storage Interface (CSI) スナップショットをサポートしていないファイルシステムをバックアップする場合は、Kopia ファイルシステムバックアップ (FSB) がサポートされます。

ファイルシステムの例には次のものがあります。

  • Amazon Elastic File System (EFS)
  • Network File System (NFS)
  • emptyDir ボリューム
  • ローカルボリューム

ボリュームのバックアップには、AWS STS 上の OADP ではネイティブスナップショットと Container Storage Interface (CSI) スナップショットが推奨されます。Data Mover バックアップはサポートされていますが、ネイティブスナップショットよりも遅くなる可能性があります。

STS 認証を使用する AWS クラスターでは、バックアップデータを別の AWS リージョンに復元することはサポートされていません。

前提条件

  • 必要なアクセス権とトークンを備えた OpenShift Container Platform AWS STS クラスター。詳細は、前の手順である OADP 用の AWS 認証情報の準備 を参照してください。バックアップと復元に 2 つの異なるクラスターを使用する予定の場合は、ROLE_ARN を含む AWS 認証情報をクラスターごとに準備する必要があります。

手順

  1. 次のコマンドを入力して、AWS トークンファイルから OpenShift Container Platform シークレットを作成します。

    1. 認証情報ファイルを作成します。

      $ cat <<EOF > ${SCRATCH}/credentials
        [default]
        role_arn = ${ROLE_ARN}
        web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
        region = <aws_region>
      EOF

      <aws_region> は、STS エンドポイントに使用する AWS リージョンに置き換えます。

    2. OADP の namespace を作成します。

      $ oc create namespace openshift-adp
    3. OpenShift Container Platform シークレットを作成します。

      $ oc -n openshift-adp create secret generic cloud-credentials \
        --from-file=${SCRATCH}/credentials
      注記

      OpenShift Container Platform バージョン 4.14 以降では、OADP Operator は Operator Lifecycle Manager (OLM) および Cloud Credentials Operator (CCO) を通じて、標準化された新しい STS ワークフローをサポートします。このワークフローでは、上記シークレットの作成は必要ありません。OpenShift Container Platform Web コンソールを使用して、OLM で管理される Operator のインストール中にロール ARN のみ指定する必要があります。詳細は、Web コンソールを使用してソフトウェアカタログからインストールする を参照してください。

      前述のシークレットは CCO によって自動的に作成されます。

  2. OADP Operator をインストールします。

    1. OpenShift Container Platform Web コンソールで、EcosystemSoftware Catalog を参照します。
    2. OADP Operator を検索します。
    3. role_ARN フィールドに、前に作成した role_arn を貼り付け、Install をクリックします。
  3. 次のコマンドを入力し、AWS 認証情報を使用して AWS クラウドストレージを作成します。

    $ cat << EOF | oc create -f -
      apiVersion: oadp.openshift.io/v1alpha1
      kind: CloudStorage
      metadata:
        name: ${CLUSTER_NAME}-oadp
        namespace: openshift-adp
      spec:
        creationSecret:
          key: credentials
          name: cloud-credentials
        enableSharedConfig: true
        name: ${CLUSTER_NAME}-oadp
        provider: aws
        region: $REGION
    EOF
  4. 次のコマンドを入力して、アプリケーションのストレージのデフォルトストレージクラスを確認します。

    $ oc get pvc -n <namespace>
    NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
    mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h
  5. 次のコマンドを実行してストレージクラスを取得します。

    $ oc get storageclass
    NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
    gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
    gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
    注記

    次のストレージクラスが機能します。

    • gp3-csi
    • gp2-csi
    • gp3
    • gp2

    すべてのアプリケーション、またはバックアップされるアプリケーションが Container Storage Interface (CSI) で永続ボリューム (PV) を使用している場合は、OADP DPA 設定に CSI プラグインを含めることをお勧めします。

  6. バックアップとボリュームスナップショットが保存されるストレージへの接続を設定するために、DataProtectionApplication リソースを作成します。

    1. CSI ボリュームのみを使用している場合は、次のコマンドを入力して Data Protection Application をデプロイします。

      $ cat << EOF | oc create -f -
        apiVersion: oadp.openshift.io/v1alpha1
        kind: DataProtectionApplication
        metadata:
          name: ${CLUSTER_NAME}-dpa
          namespace: openshift-adp
        spec:
          backupImages: true
          features:
            dataMover:
              enable: false
          backupLocations:
          - bucket:
              cloudStorageRef:
                name: ${CLUSTER_NAME}-oadp
              credential:
                key: credentials
                name: cloud-credentials
              prefix: velero
              default: true
              config:
                region: ${REGION}
          configuration:
            velero:
              defaultPlugins:
              - openshift
              - aws
              - csi
            nodeAgent:
              enable: false
              uploaderType: kopia
      EOF

      ここでは、以下のようになります。

      backupImages
      イメージバックアップを使用するかどうかを指定します。イメージバックアップを使用しない場合は、false に設定してください。
      ノードエージェント
      ノードエージェントの設定を指定します。この手順の最後に記載されている nodeAgent 属性に関する重要な注意事項を参照してください。
      アップローダータイプ
      アップローダーの種類を指定します。ビルトイン Data Mover は、uploaderType フィールドの値に関係なく、デフォルトのアップローダーメカニズムとして Kopia を使用します。
    2. CSI ボリュームまたは非 CSI ボリュームを使用している場合は、次のコマンドを入力して Data Protection Application をデプロイします。

      $ cat << EOF | oc create -f -
        apiVersion: oadp.openshift.io/v1alpha1
        kind: DataProtectionApplication
        metadata:
          name: ${CLUSTER_NAME}-dpa
          namespace: openshift-adp
        spec:
          backupImages: true
          features:
            dataMover:
               enable: false
          backupLocations:
          - bucket:
              cloudStorageRef:
                name: ${CLUSTER_NAME}-oadp
              credential:
                key: credentials
                name: cloud-credentials
              prefix: velero
              default: true
              config:
                region: ${REGION}
          configuration:
            velero:
              defaultPlugins:
              - openshift
              - aws
            nodeAgent:
              enable: false
              uploaderType: restic
          snapshotLocations:
            - velero:
                config:
                  credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials
                  enableSharedConfig: "true"
                  profile: default
                  region: ${REGION}
                provider: aws
      EOF

      ここでは、以下のようになります。

      backupImages
      イメージバックアップを使用するかどうかを指定します。イメージバックアップを使用しない場合は、false に設定してください。
      ノードエージェント
      ノードエージェントの設定を指定します。この手順の最後に記載されている nodeAgent 属性に関する重要な注意事項を参照してください。
      credentialsFile
      バケット認証情報が Pod にマウントされる場所を指定します。
      enableSharedConfig
      スナップショットの場所が、 バケットに定義された認証情報を共有または再利用できるかどうかを指定します。
      profile
      AWS 認証情報ファイルに設定されているプロファイル名を指定します。
      region

      AWS リージョンを指定します。これはクラスターリージョンと同じである必要があります。

      これで、アプリケーションのバックアップ で説明されているとおり、OpenShift Container Platform アプリケーションをバックアップおよび復元する準備が整いました。

      重要

      OADP 1.2 を使用する場合は、次の設定を置き換えます。

      nodeAgent:
        enable: false
        uploaderType: restic

      次の設定に置き換えます。

      restic:
        enable: false

    バックアップと復元に 2 つの異なるクラスターを使用する場合、クラウドストレージ CR と OADP DataProtectionApplication 設定の両方で、2 つのクラスターの AWS S3 ストレージ名が同じである必要があります。

5.21.1.3. OADP と AWS STS を使用したバックアップの実行

Amazon Web Services (AWS) (AWS STS) と OpenShift API for Data Protection (OADP) を使用してバックアップを実行します。以下の ハローワールド サンプルアプリケーションには、永続ボリューム (PV) は接続されていません。

どちらの Data Protection Application (DPA) 設定も機能します。

手順

  1. 次のコマンドを実行して、バックアップするワークロードを作成します。

    $ oc create namespace hello-world
    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
  2. 次のコマンドを実行してルートを公開します。

    $ oc expose service/hello-openshift -n hello-world
  3. 次のコマンドを実行して、アプリケーションが動作していることを確認します。

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
    Hello OpenShift!
  4. 次のコマンドを実行して、ワークロードをバックアップします。

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Backup
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        includedNamespaces:
        - hello-world
        storageLocation: ${CLUSTER_NAME}-dpa-1
        ttl: 720h0m0s
    EOF
  5. バックアップが完了するまで待ってから、次のコマンドを実行します。

    $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
    {
      "completionTimestamp": "2022-09-07T22:20:44Z",
      "expiration": "2022-10-07T22:20:22Z",
      "formatVersion": "1.1.0",
      "phase": "Completed",
      "progress": {
        "itemsBackedUp": 58,
        "totalItems": 58
      },
      "startTimestamp": "2022-09-07T22:20:22Z",
      "version": 1
    }
  6. 次のコマンドを実行して、デモワークロードを削除します。

    $ oc delete ns hello-world
  7. 次のコマンドを実行して、バックアップからワークロードを復元します。

    $ cat << EOF | oc create -f -
      apiVersion: velero.io/v1
      kind: Restore
      metadata:
        name: hello-world
        namespace: openshift-adp
      spec:
        backupName: hello-world
    EOF
  8. 次のコマンドを実行して、復元が完了するまで待ちます。

    $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
    {
      "completionTimestamp": "2022-09-07T22:25:47Z",
      "phase": "Completed",
      "progress": {
        "itemsRestored": 38,
        "totalItems": 38
      },
      "startTimestamp": "2022-09-07T22:25:28Z",
      "warnings": 9
    }
  9. 次のコマンドを実行して、ワークロードが復元されていることを確認します。

    $ oc -n hello-world get pods
    NAME                              READY   STATUS    RESTARTS   AGE
    hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s
  10. 次のコマンドを実行して JSONPath を確認します。

    $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
    Hello OpenShift!
    注記

    トラブルシューティングのヒントについては、トラブルシューティングに関するドキュメント を参照してください。

5.21.1.3.1. OADP と AWS STS を使用してバックアップ後のクラスターをクリーンアップする

OpenShift API for Data Protection (OADP) Operator を 、hello-world サンプルで使用したバックアップと S3 バケットとともにアンインストールします。

手順

  1. 次のコマンドを実行して、ワークロードを削除します。

    $ oc delete ns hello-world
  2. 次のコマンドを実行して、Data Protection Application (DPA) を削除します。

    $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
  3. 次のコマンドを実行して、クラウドストレージを削除します。

    $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
    重要

    このコマンドがハングした場合は、次のコマンドを実行してファイナライザーを削除する必要がある場合があります。

    $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
  4. Operator が不要になった場合は、次のコマンドを実行して削除します。

    $ oc -n openshift-adp delete subscription oadp-operator
  5. 次のコマンドを実行して、Operator から namespace を削除します。

    $ oc delete ns openshift-adp
  6. バックアップおよび復元リソースが不要になった場合は、次のコマンドを実行してクラスターからリソースを削除します。

    $ oc delete backups.velero.io hello-world
  7. AWS S3 のバックアップ、復元、およびリモートオブジェクトを削除するには、次のコマンドを実行します。

    $ velero backup delete hello-world
  8. カスタムリソース定義 (CRD) が不要になった場合は、次のコマンドを実行してクラスターから削除します。

    $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
  9. 次のコマンドを実行して、AWS S3 バケットを削除します。

    $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
    $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
  10. 次のコマンドを実行して、ロールからポリシーを切り離します。

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}"  --policy-arn "${POLICY_ARN}"
  11. 以下のコマンドを実行してロールを削除します。

    $ aws iam delete-role --role-name "${ROLE_NAME}"

5.22. OADP と 3scale

5.22.1. OADP を使用した 3scale API Management のバックアップと復元

OpenShift API for Data Protection (OADP) を使用してアプリケーションリソース、永続ボリューム、および設定を保護し、Red Hat 3scale API Management デプロイメントのバックアップと復元を行います。これは、障害復旧のために 3scale コンポーネントを保護するのに役立ちます。

3scale のコンポーネントは、オンプレミスやクラウドに、またはマネージドサービスとしてデプロイできます。要件に応じてこれらを組み合わせてデプロイすることもできます。

OpenShift API for Data Protection (OADP) を使用すると、アプリケーションリソース、永続ボリューム、および設定をバックアップして、3scale API Management デプロイメントを保護できます。

注記

OpenShift API for Data Protection (OADP) Operator を使用すると、実行中のサービスに影響を与えることなく、3scale API Management のクラスター上のストレージデータベースをバックアップおよび復元できます。

3scale API Management を使用して次の操作を実行するように OADP を設定できます。

  • 3scale コンポーネントのバックアップを作成します。詳細は、3scale API Management のバックアップを 参照してください。
  • 3scale オペレーターとデプロイメントをスケールアップするために、コンポーネントを復元します。詳細は、3scale API 管理の復元を 参照してください。

5.22.2. OADP を使用した 3scale API Management のバックアップ

OpenShift API for Data Protection (OADP) を使用して、3scale Operator、MySQL データベース、Redis データベースなど、Red Hat 3scale API Management コンポーネントのバックアップを作成します。これは、API 管理インフラストラクチャーを保護し、データ損失が発生した場合の復旧に役立ちます。

Red Hat 3scale API Management のインストールと設定の詳細は、OpenShift および Red Hat 3scale API Managementへの 3scale API Management のインストールを 参照してください。

5.22.2.1. Data Protection Application の作成

Red Hat 3scale API Management のバックアップストレージと Velero 設定を設定するために、Data Protection Application (DPA) カスタムリソース (CR) を作成します。これは、3scale コンポーネントを保護するために必要なバックアップインフラストラクチャーを構築するのに役立ちます。

手順

  1. 次の設定で YAML ファイルを作成します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: dpa-sample
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - openshift
            - aws
            - csi
          resourceTimeout: 10m
        nodeAgent:
          enable: true
          uploaderType: kopia
      backupLocations:
        - name: default
          velero:
            provider: aws
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: <prefix>
            config:
              region: <region>
              profile: "default"
              s3ForcePathStyle: "true"
              s3Url: <s3_url>
            credential:
              key: cloud
              name: cloud-credentials

    ここでは、以下のようになります。

    <bucket_name>
    バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
    <prefix>
    バケットが複数の用途で使用される場合、Velero バックアップのプレフィックスを指定します。たとえば、velero など です。
    < 領域 >
    バックアップデータの保存場所となるリージョンを指定します。
    <s3_url>
    バックアップを保存するために使用するオブジェクトストアの URL を指定します。
  2. 次のコマンドを実行して DPA CR を作成します。

    $ oc create -f dpa.yaml
5.22.2.2. 3scale API Management Operator、シークレット、APIManager のバックアップ

バックアップ CR を作成することで、Secret および APIManager カスタムリソース (CR) を含む Red Hat 3scale API Management オペレーターリソースをバックアップします。これは、復旧シナリオに備えて 3scale オペレーターの設定を保持するのに役立ちます。

前提条件

  • Data Protection Application (DPA) を作成した。

手順

  1. 次の設定を含む YAML ファイルを作成して、3scale Operator の CR (operatorgroupnamespacessubscriptions など) をバックアップします。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: operator-install-backup
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup: false
      includedNamespaces:
      - threescale
      includedResources:
      - operatorgroups
      - subscriptions
      - namespaces
      itemOperationTimeout: 1h0m0s
      snapshotMoveData: false
      ttl: 720h0m0s

    ここでは、以下のようになります。

    オペレーターのインストールバックアップ
    バックアップ内の metadata.name パラメーターの値を指定します。これは、3scale オペレーターを復元する際に使用される metadata.backupName パラメーターで使用される値と同じです。
    3 スケール

    3scale オペレーターがインストールされている名前空間を指定します。

    注記

    ReplicationControllersDeploymentPod オブジェクトをバックアップおよび復元して、手動で設定されたすべての環境がバックアップおよび復元されるようにすることもできます。復元フローには影響ありません。

  2. 次のコマンドを実行してバックアップ CR を作成します。

    $ oc create -f backup.yaml

    出力例

    backup.velero.io/operator-install-backup created

  3. 次の設定を含む YAML ファイルを作成して、Secret CR をバックアップします。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: operator-resources-secrets
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup: false
      includedNamespaces:
      - threescale
      includedResources:
      - secrets
      itemOperationTimeout: 1h0m0s
      labelSelector:
        matchLabels:
          app: 3scale-api-management
      snapshotMoveData: false
      snapshotVolumes: false
      ttl: 720h0m0s
    name
    バックアップ内の metadata.name パラメーターの値を指定します。Secret を復元する際に、metadata.backupName パラメーターにこの値を使用してください。
  4. 次のコマンドを実行して、Secret バックアップ CR を作成します。

    $ oc create -f backup-secret.yaml

    出力例

    backup.velero.io/operator-resources-secrets created

  5. 次の設定の YAML ファイルを作成して、APIManager CR をバックアップします。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: operator-resources-apim
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup: false
      includedNamespaces:
      - threescale
      includedResources:
      - apimanagers
      itemOperationTimeout: 1h0m0s
      snapshotMoveData: false
      snapshotVolumes: false
      storageLocation: ts-dpa-1
      ttl: 720h0m0s
      volumeSnapshotLocations:
      - ts-dpa-1
    name
    バックアップ内の metadata.name パラメーターの値を指定します。APIManager を復元する際に、metadata.backupName パラメーターにこの値を使用してください。
  6. 次のコマンドを実行して APIManager CR を作成します。

    $ oc create -f backup-apimanager.yaml

    出力例

    backup.velero.io/operator-resources-apim created

5.22.2.3. MySQL データベースのバックアップ

MySQL データベースをバックアップするには、データベースダンプを保存するための永続ボリューム要求 (PVC) を作成します。これは、復旧シナリオに備えて 3scale システムのデータベースデータを保護するのに役立ちます。

前提条件

  • Red Hat 3scale API Management Operator をバックアップした。

手順

  1. さらに PVC を追加するには、次の設定で YAML ファイルを作成します。

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: example-claim
      namespace: threescale
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
      storageClassName: gp3-csi
      volumeMode: Filesystem
  2. 次のコマンドを実行して追加の PVC を作成します。

    $ oc create -f ts_pvc.yml
  3. MySQL ダンプを使用するように system-mysql デプロイメントを編集して、PVC をシステムデータベース Pod にアタッチします。

    $ oc edit deployment system-mysql -n threescale
      volumeMounts:
        - name: example-claim
          mountPath: /var/lib/mysqldump/data
        - name: mysql-storage
          mountPath: /var/lib/mysql/data
        - name: mysql-extra-conf
          mountPath: /etc/my-extra.d
        - name: mysql-main-conf
          mountPath: /etc/my-extra
        ...
          serviceAccount: amp
      volumes:
            - name: example-claim
              persistentVolumeClaim:
                claimName: example-claim
        ...
    claimName
    ダンプされたデータを含む PVC を指定します。
  4. MySQL データベースをバックアップするために、次の設定を含む YAML ファイルを作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: mysql-backup
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup: true
      hooks:
        resources:
        - name: dumpdb
          pre:
          - exec:
              command:
              - /bin/sh
              - -c
              - mysqldump -u $MYSQL_USER --password=$MYSQL_PASSWORD system --no-tablespaces
                > /var/lib/mysqldump/data/dump.sql
              container: system-mysql
              onError: Fail
              timeout: 5m
      includedNamespaces:
      - threescale
      includedResources:
      - deployment
      - pods
      - replicationControllers
      - persistentvolumeclaims
      - persistentvolumes
      itemOperationTimeout: 1h0m0s
      labelSelector:
        matchLabels:
          app: 3scale-api-management
          threescale_component_element: mysql
      snapshotMoveData: false
      ttl: 720h0m0s

    ここでは、以下のようになります。

    mysql-backup
    バックアップ内の metadata.name パラメーターの値を指定します。MySQL データベースを復元する際に、metadata.backupName パラメーターにこの値を使用してください。
    /var/lib/mysqldump/data/dump.sql
    データのバックアップ先ディレクトリーを指定します。
    includedResources
    バックアップするリソースを指定します。
  5. 次のコマンドを実行して、MySQL データベースをバックアップします。

    $ oc create -f mysql.yaml

    出力例

    backup.velero.io/mysql-backup created

検証

  • 次のコマンドを実行して、MySQL のバックアップが完了したことを確認します。

    $ oc get backups.velero.io mysql-backup -o yaml

    出力例

    status:
    completionTimestamp: "2025-04-17T13:25:19Z"
    errors: 1
    expiration: "2025-05-17T13:25:16Z"
    formatVersion: 1.1.0
    hookStatus: {}
    phase: Completed
    progress: {}
    startTimestamp: "2025-04-17T13:25:16Z"
    version: 1

5.22.2.4. バックエンドの Redis データベースのバックアップ

Velero のアノテーションを設定し、必要なリソースを含むバックアップ CR を作成することで、バックエンドの Redis データベースをバックアップします。これは、復旧シナリオに備えて 3scale バックエンドの Redis データを保持するのに役立ちます。

前提条件

  • Red Hat 3scale API Management Operator をバックアップした。
  • MySQL データベースをバックアップした。
  • バックアップを実行する前に、Redis キューが空になっている。

手順

  1. 次のコマンドを実行して、backend-redis デプロイメントのアノテーションを編集します。

    $ oc edit deployment backend-redis -n threescale
    annotations:
    post.hook.backup.velero.io/command: >-
             ["/bin/bash", "-c", "redis-cli CONFIG SET auto-aof-rewrite-percentage
             100"]
           pre.hook.backup.velero.io/command: >-
             ["/bin/bash", "-c", "redis-cli CONFIG SET auto-aof-rewrite-percentage
             0"]
  2. Redis データベースをバックアップするために、次の設定を含む YAML ファイルを作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: redis-backup
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup: true
      includedNamespaces:
      - threescale
      includedResources:
      - deployment
      - pods
      - replicationcontrollers
      - persistentvolumes
      - persistentvolumeclaims
      itemOperationTimeout: 1h0m0s
      labelSelector:
        matchLabels:
          app: 3scale-api-management
          threescale_component: backend
          threescale_component_element: redis
      snapshotMoveData: false
      snapshotVolumes: false
      ttl: 720h0m0s
    name
    バックアップ内の metadata.name パラメーターの値を指定します。Redis データベースを復元する際に、metadata.backupName パラメーターにこの値を使用してください。
  3. 次のコマンドを実行して、Redis データベースをバックアップします。

    $ oc create -f redis-backup.yaml

    出力例

    backup.velero.io/redis-backup created

検証

  • 次のコマンドを実行して、Redis のバックアップが完了したことを確認します。

    $ oc get backups.velero.io redis-backup -o yaml

    出力例

    status:
    completionTimestamp: "2025-04-17T13:25:19Z"
    errors: 1
    expiration: "2025-05-17T13:25:16Z"
    formatVersion: 1.1.0
    hookStatus: {}
    phase: Completed
    progress: {}
    startTimestamp: "2025-04-17T13:25:16Z"
    version: 1

5.22.3. OADP を使用した 3scale API Management の復元

バックアップ済みの 3scale オペレーターリソース、MySQL データベース、および Redis データベースを復元することにより、Red Hat 3scale API 管理コンポーネントを復元します。これにより、3scale のデプロイメントを復旧し、API 管理サービスを再開できます。

データが復元されたら、3scale Operator とデプロイメントをスケールアップできます。

5.22.3.1. 3scale API Management Operator、シークレット、APIManager の復元

シークレット および APIManager カスタムリソース (CR) を含む、Red Hat 3scale API Management オペレーターリソースを復元します。これにより、同じクラスターまたは別のクラスター上で 3scale オペレーターの設定を復元できます。

前提条件

  • 3scale Operator をバックアップした。
  • MySQL および Redis データベースをバックアップした。
  • バックアップされたのと同じクラスター上でデータベースを復元しようとしている。

    バックアップ元とは異なるクラスターに Operator を復元する場合は、復元先のクラスターで nodeAgent を有効にして OADP をインストールして設定します。OADP の設定がソースクラスターと同じであることを確認してください。

手順

  1. 次のコマンドを実行して、3scale Operator のカスタムリソース定義 (CRD) と threescale namespace を削除します。

    $ oc delete project threescale
    "threescale" project deleted successfully
  2. 3scale Operator を復元するために、次の設定を含む YAML ファイルを作成します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: operator-installation-restore
      namespace: openshift-adp
    spec:
      backupName: operator-install-backup
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      - csinodes.storage.k8s.io
      - volumeattachments.storage.k8s.io
      - backuprepositories.velero.io
      itemOperationTimeout: 4h0m0s

    ここでは、以下のようになります。

    オペレーターのインストールバックアップ
    3scale オペレーターを復元するためのバックアップの名前を指定します。
  3. 次のコマンドを実行して、3scale Operator を復元します。

    $ oc create -f restore.yaml
    restore.velerio.io/operator-installation-restore created
  4. 次のコマンドを実行して、s3-credentials Secret オブジェクトを手動で作成します。

    $ oc apply -f - <<EOF
    ---
    apiVersion: v1
    kind: Secret
    metadata:
          name: s3-credentials
          namespace: threescale
    stringData:
      AWS_ACCESS_KEY_ID: <ID_123456>
      AWS_SECRET_ACCESS_KEY: <ID_98765544>
      AWS_BUCKET: <mybucket.example.com>
      AWS_REGION: <us-east-1>
    type: Opaque
    EOF

    ここでは、以下のようになります。

    <AWS_ACCESS_KEY_ID>
    AWS 認証情報 ID を指定します。
    <AWS_SECRET_ACCESS_KEY>
    AWS 認証情報のキーを指定します。
    <mybucket.example.com>
    ターゲットバケット名を指定します。
    <us-east-1>
    バケットの AWS リージョンを指定します。
  5. 次のコマンドを実行して、3scale Operator をスケールダウンします。

    $ oc scale deployment threescale-operator-controller-manager-v2 --replicas=0 -n threescale
    deployment.apps/threescale-operator-controller-manager-v2 scaled
  6. Secret を復元するために、次の設定を含む YAML ファイルを作成します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: operator-resources-secrets
      namespace: openshift-adp
    spec:
      backupName: operator-resources-secrets
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      - csinodes.storage.k8s.io
      - volumeattachments.storage.k8s.io
      - backuprepositories.velero.io
      itemOperationTimeout: 4h0m0s

    ここでは、以下のようになります。

    オペレーターリソースシークレット
    シークレット を復元するバックアップの名前を指定します。
  7. 次のコマンドを実行して、Secret を復元します。

    $ oc create -f restore-secrets.yaml
    restore.velerio.io/operator-resources-secrets created
  8. APIManager を復元するために、次の設定を含む YAML ファイルを作成します。

    restore-apimanager.yaml ファイルの例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: operator-resources-apim
      namespace: openshift-adp
    spec:
      backupName: operator-resources-apim
      excludedResources:
      - nodes
      - events
      - events.events.k8s.io
      - backups.velero.io
      - restores.velero.io
      - resticrepositories.velero.io
      - csinodes.storage.k8s.io
      - volumeattachments.storage.k8s.io
      - backuprepositories.velero.io
      itemOperationTimeout: 4h0m0s

    ここでは、以下のようになります。

    オペレーターリソース APIM
    APIManager を復元するバックアップの名前を指定します。
    excludedResources
    復元したくないリソースを指定します。
  9. 次のコマンドを実行して、APIManager を復元します。

    $ oc create -f restore-apimanager.yaml
    restore.velerio.io/operator-resources-apim created
  10. 次のコマンドを実行して、3scale Operator をスケールアップします。

    $ oc scale deployment threescale-operator-controller-manager-v2 --replicas=1 -n threescale
    deployment.apps/threescale-operator-controller-manager-v2 scaled
5.22.3.2. MySQL データベースの復元

Red Hat 3scale API Management コンポーネントをスケールダウンし、Velero Restore カスタムリソース (CR) を作成することで、MySQL データベースを復元します。これにより、3scale MySQL のデータ、永続ボリューム、および関連リソースを復旧できます。

警告

データベースに関連付けられているデフォルトの PV と PVC は削除しないでください。削除すると、バックアップが削除されます。

前提条件

  • Secret および APIManager カスタムリソース (CR) を復元した。

手順

  1. 次のコマンドを実行して、Red Hat 3scale API Management Operator をスケールダウンします。

    $ oc scale deployment threescale-operator-controller-manager-v2 --replicas=0 -n threescale

    出力例

    deployment.apps/threescale-operator-controller-manager-v2 scaled

  2. 3scale Operator をスケールダウンするには、次のスクリプトを作成します。

    $ vi ./scaledowndeployment.sh

    スクリプトの例:

    for deployment in apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-searchd system-sidekiq zync zync-database zync-que; do
        oc scale deployment/$deployment --replicas=0 -n threescale
    done

  3. 次のスクリプトを実行して、すべてのデプロイメント 3scale コンポーネントをスケールダウンします。

    $ ./scaledowndeployment.sh

    出力例

    deployment.apps.openshift.io/apicast-production scaled
    deployment.apps.openshift.io/apicast-staging scaled
    deployment.apps.openshift.io/backend-cron scaled
    deployment.apps.openshift.io/backend-listener scaled
    deployment.apps.openshift.io/backend-redis scaled
    deployment.apps.openshift.io/backend-worker scaled
    deployment.apps.openshift.io/system-app scaled
    deployment.apps.openshift.io/system-memcache scaled
    deployment.apps.openshift.io/system-mysql scaled
    deployment.apps.openshift.io/system-redis scaled
    deployment.apps.openshift.io/system-searchd scaled
    deployment.apps.openshift.io/system-sidekiq scaled
    deployment.apps.openshift.io/zync scaled
    deployment.apps.openshift.io/zync-database scaled
    deployment.apps.openshift.io/zync-que scaled

  4. 次のコマンドを実行して、system-mysql Deployment オブジェクトを削除します。

    $ oc delete deployment system-mysql -n threescale

    出力例

    Warning: apps.openshift.io/v1 deployment is deprecated in v4.14+, unavailable in v4.10000+
    deployment.apps.openshift.io "system-mysql" deleted

  5. MySQL データベースを復元するための次の YAML ファイルを作成します。

    restore-mysql.yaml ファイルの例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: restore-mysql
      namespace: openshift-adp
    spec:
      backupName: mysql-backup
      excludedResources:
        - nodes
        - events
        - events.events.k8s.io
        - backups.velero.io
        - restores.velero.io
        - csinodes.storage.k8s.io
        - volumeattachments.storage.k8s.io
        - backuprepositories.velero.io
        - resticrepositories.velero.io
      hooks:
        resources:
          - name: restoreDB
            postHooks:
              - exec:
                  command:
                    - /bin/sh
                    - '-c'
                    - >
                      sleep 30
    
                      mysql -h 127.0.0.1 -D system -u root
                      --password=$MYSQL_ROOT_PASSWORD <
                      /var/lib/mysqldump/data/dump.sql
                  container: system-mysql
                  execTimeout: 80s
                  onError: Fail
                  waitTimeout: 5m
      itemOperationTimeout: 1h0m0s
      restorePVs: true

    ここでは、以下のようになります。

    mysql-backup
    復元する MySQL バックアップの名前を指定します。
    /var/lib/mysqldump/data/dump.sql
    データの復元元となるパスを指定します。
  6. 次のコマンドを実行して、MySQL データベースを復元します。

    $ oc create -f restore-mysql.yaml
    restore.velerio.io/restore-mysql created

検証

  1. 次のコマンドを実行して、PodVolumeRestore の復元が完了したことを確認します。

    $ oc get podvolumerestores.velero.io -n openshift-adp

    出力例

    NAME                    NAMESPACE    POD                     UPLOADER TYPE   VOLUME                  STATUS      TOTALBYTES   BYTESDONE   AGE
    restore-mysql-rbzvm     threescale   system-mysql-2-kjkhl    kopia           mysql-storage           Completed   771879108    771879108   40m
    restore-mysql-z7x7l     threescale   system-mysql-2-kjkhl    kopia           example-claim           Completed   380415       380415      40m

  2. 次のコマンドを実行して、追加の PVC が復元されたことを確認します。

    $ oc get pvc -n threescale

    出力例

    NAME                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
    backend-redis-storage   Bound    pvc-3dca410d-3b9f-49d4-aebf-75f47152e09d   1Gi        RWO            gp3-csi        <unset>                 68m
    example-claim           Bound    pvc-cbaa49b0-06cd-4b1a-9e90-0ef755c67a54   1Gi        RWO            gp3-csi        <unset>                 57m
    mysql-storage           Bound    pvc-4549649f-b9ad-44f7-8f67-dd6b9dbb3896   1Gi        RWO            gp3-csi        <unset>                 68m
    system-redis-storage    Bound    pvc-04dadafd-8a3e-4d00-8381-6041800a24fc   1Gi        RWO            gp3-csi        <unset>                 68m
    system-searchd          Bound    pvc-afbf606c-d4a8-4041-8ec6-54c5baf1a3b9   1Gi        RWO            gp3-csi        <unset>                 68m

5.22.3.3. バックエンドの Redis データベースの復元

不要なクラスターリソースを除外し た復元 カスタムリソース (CR) を作成することで、バックエンドの Redis データベースを復元します。これは、Red Hat 3scale API Management の復元プロセスの一環として、Redis データストアを復旧するのに役立ちます。

前提条件

  • Red Hat 3scale API Management Operator のリソースと、Secret および APIManager カスタムリソースを復元した。
  • MySQL データベースを復元した。

手順

  1. 次のコマンドを実行して、backend-redis デプロイメントを削除します。

    $ oc delete deployment backend-redis -n threescale
    Warning: apps.openshift.io/v1 deployment is deprecated in v4.14+, unavailable in v4.10000+
    
    deployment.apps.openshift.io "backend-redis" deleted
  2. Redis データベースを復元するために、次の設定を含む YAML ファイルを作成します。

    restore-backend.yaml ファイルの例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: restore-backend
      namespace: openshift-adp
    spec:
      backupName: redis-backup
      excludedResources:
        - nodes
        - events
        - events.events.k8s.io
        - backups.velero.io
        - restores.velero.io
        - resticrepositories.velero.io
        - csinodes.storage.k8s.io
        - volumeattachments.storage.k8s.io
        - backuprepositories.velero.io
      itemOperationTimeout: 1h0m0s
      restorePVs: true

    ここでは、以下のようになります。

    redis バックアップ
    復元する Redis バックアップの名前を指定します。
  3. 次のコマンドを実行して、Redis データベースを復元します。

    $ oc create -f restore-backend.yaml
    restore.velerio.io/restore-backend created

検証

  • 次のコマンドを実行して、PodVolumeRestore の復元が完了したことを確認します。

    $ oc get podvolumerestores.velero.io -n openshift-adp
    NAME                    NAMESPACE    POD                     UPLOADER TYPE   VOLUME                  STATUS      TOTALBYTES   BYTESDONE   AGE
    restore-backend-jmrwx   threescale   backend-redis-1-bsfmv   kopia           backend-redis-storage   Completed   76123        76123       21m
5.22.3.4. 3scale API Management Operator とデプロイメントのスケールアップ

Red Hat 3scale API Management オペレーターと、復元プロセス中に手動でスケールダウンされたデプロイメントをスケールアップします。これにより、バックアップされた設定に合わせて、3scale のインストール環境を完全に機能する状態に戻すことができます。

前提条件

  • 3scale Operator のリソースと、Secret および APIManager カスタムリソース (CR) の両方を復元した。
  • MySQL とバックエンドの Redis データベースを復元した。
  • スケールアップされたデプロイメントや、追加の Pod が実行されていないことを確認した。復元後、デプロイメントから切り離された状態で実行されている system-mysql または backend-redis Pod が存在する可能性がありますが、復元が成功したら削除できます。

手順

  1. 次のコマンドを実行して、3scale Operator をスケールアップします。

    $ oc scale deployment threescale-operator-controller-manager-v2 --replicas=1 -n threescale

    出力例

    deployment.apps/threescale-operator-controller-manager-v2 scaled

  2. 次のコマンドを実行して、3scale Pod が実行中であることを確認して、3scale Operator がデプロイされたかどうかを確認します。

    $ oc get pods -n threescale

    出力例

    NAME									                    READY        STATUS	  RESTARTS	 AGE
    threescale-operator-controller-manager-v2-79546bd8c-b4qbh	1/1	         Running  0          2m5s

  3. デプロイメントをスケールアップするためのスクリプトを作成します。

    $ vi ./scaledeployment.sh

    スクリプトファイルの例:

    for deployment in apicast-production apicast-staging backend-cron backend-listener backend-redis backend-worker system-app system-memcache system-mysql system-redis system-searchd system-sidekiq zync zync-database zync-que; do
        oc scale deployment/$deployment --replicas=1 -n threescale
    done

  4. 次のスクリプトを実行して、デプロイメントをスケールアップします。

    $ ./scaledeployment.sh

    出力例

    deployment.apps.openshift.io/apicast-production scaled
    deployment.apps.openshift.io/apicast-staging scaled
    deployment.apps.openshift.io/backend-cron scaled
    deployment.apps.openshift.io/backend-listener scaled
    deployment.apps.openshift.io/backend-redis scaled
    deployment.apps.openshift.io/backend-worker scaled
    deployment.apps.openshift.io/system-app scaled
    deployment.apps.openshift.io/system-memcache scaled
    deployment.apps.openshift.io/system-mysql scaled
    deployment.apps.openshift.io/system-redis scaled
    deployment.apps.openshift.io/system-searchd scaled
    deployment.apps.openshift.io/system-sidekiq scaled
    deployment.apps.openshift.io/zync scaled
    deployment.apps.openshift.io/zync-database scaled
    deployment.apps.openshift.io/zync-que scaled

  5. 次のコマンドを実行して、3scale UI にログインするための 3scale-admin ルートを取得します。

    $ oc get routes -n threescale

    出力例

    NAME                         HOST/PORT                                                                   PATH   SERVICES             PORT      TERMINATION     WILDCARD
    backend                      backend-3scale.apps.custom-cluster-name.openshift.com                         backend-listener     http      edge/Allow      None
    zync-3scale-api-b4l4d        api-3scale-apicast-production.apps.custom-cluster-name.openshift.com          apicast-production   gateway   edge/Redirect   None
    zync-3scale-api-b6sns        api-3scale-apicast-staging.apps.custom-cluster-name.openshift.com             apicast-staging      gateway   edge/Redirect   None
    zync-3scale-master-7sc4j     master.apps.custom-cluster-name.openshift.com                                 system-master        http      edge/Redirect   None
    zync-3scale-provider-7r2nm   3scale-admin.apps.custom-cluster-name.openshift.com                           system-provider      http      edge/Redirect   None
    zync-3scale-provider-mjxlb   3scale.apps.custom-cluster-name.openshift.com                                 system-developer     http      edge/Redirect   None

    この例では、3scale-admin.apps.custom-cluster-name.openshift.com が 3scale-admin URL です。

  6. この出力の URL を使用して、3scale Operator に管理者としてログインします。バックアップを作成したときのデータが利用可能かどうかを確認します。

5.23. OADP Data Mover

5.23.1. OADP Data Mover について

OpenShift API for Data Protection (OADP) に組み込まれているデータムーバーを使用して、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストレージに移動し、クラスター障害後にステートフルアプリケーションを復元します。これにより、コンテナー化されたワークロードと仮想マシンワークロードの両方に対して、障害復旧機能が提供されます。

データムーバーは、スナップショットデータを読み込み、統合リポジトリーに書き込むためのアップローダー機構として Kopia を 使用します。

OADP は、以下で CSI スナップショットをサポートします。

  • Red Hat OpenShift Data Foundation
  • Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のクラウドストレージプロバイダー
5.23.1.1. Data Mover のサポート

OADP の各バージョンにおけるデータムーバーのサポート状況と互換性を確認し、どのバックアップを復元できるかを理解してください。これは、バージョンアップグレードやバックアップストラテジーの計画に役立ちます。

OADP 1.3 でテクノロジープレビューとして導入された OADP 組み込みの Data Mover が、コンテナー化されたワークロードと仮想マシンのワークロードの両方で完全にサポートされるようになりました。

サポート対象
OADP 1.3 で取得したデータムーバーのバックアップは、OADP 1.3 以降のバージョンを使用して復元できます。
サポート対象外
Data Mover 機能を使用して OADP 1.1 または OADP 1.2 で作成したバックアップは、OADP 1.3 以降を使用して復元することはできません。

OADP 1.1 および OADP 1.2 はサポート対象外です。OADP 1.1 または OADP 1.2 の DataMover 機能はテクノロジープレビューであり、サポート対象ではありませんでした。OADP 1.1 または OADP 1.2 で作成した DataMover バックアップは、それ以降のバージョンの OADP では復元できません。

5.23.1.2. ビルトイン Data Mover の有効化

DataProtectionApplication カスタムリソース (CR) で CSI プラグインとノードエージェントを設定することにより、組み込みのデータムーバーを有効にします。これにより、Kopia アップローダーを使用してボリュームレベルのバックアップおよび復元操作が可能になります。

手順

  • 次の例に示すように、DataProtectionApplication カスタムリソース (CR) に CSI プラグインを含め、ノードエージェントを有効にします。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: dpa-sample
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        velero:
          defaultPlugins:
          - openshift
          - aws
          - csi
          defaultSnapshotMoveData: true
          defaultVolumesToFSBackup:
          featureFlags:
          - EnableCSI
    # ...

    ここでは、以下のようになります。

    enable
    ノードエージェントを有効にするフラグを指定します。
    アップローダータイプ
    アップローダーの種類を指定します。使用できる値は、restic または kopia です。ビルトイン Data Mover は、uploaderType フィールドの値に関係なく、デフォルトのアップローダーメカニズムとして Kopia を使用します。
    csi
    デフォルトプラグインのリストに含まれる CSI プラグインを指定します。
    defaultVolumesToFSBackup
    ボリュームのデフォルトの動作を指定します。OADP 1.3.1 以降では、fs-backup をオプトアウトするボリュームにのみ Data Mover を使用する場合、true に設定します。ボリュームにデフォルトで Data Mover を使用する場合は false に設定します。
5.23.1.3. ビルトイン Data Mover のコントローラーとカスタムリソース定義 (CRD)

組み込みのデータムーバーがボリュームスナップショットのバックアップおよび復元操作を管理するために使用するカスタムリソース定義 (CRD) を確認してください。これにより、Data Mover がデータのアップロード、ダウンロード、およびリポジトリー管理をどのように処理するかを理解できます。

ビルトイン Data Mover 機能には、バックアップと復元を管理するための CRD として定義された 3 つの新しい API オブジェクトが導入されています。

  • DataDownload: ボリュームスナップショットのデータダウンロードを表します。CSI プラグインは、復元するボリュームごとに 1 つの DataDownload オブジェクトを作成します。DataDownload CR には、ターゲットボリューム、指定された Data Mover、現在のデータダウンロードの進行状況、指定されたバックアップリポジトリー、プロセス完了後の現在のデータダウンロードの結果に関する情報が含まれます。
  • DataUpload: ボリュームスナップショットのデータアップロードを表します。CSI プラグインは、CSI スナップショットごとに 1 つの DataUpload オブジェクトを作成します。DataUpload CR には、指定されたスナップショット、指定された Data Mover、指定されたバックアップリポジトリー、現在のデータアップロードの進行状況、およびプロセス完了後の現在のデータアップロードの結果に関する情報が含まれます。
  • BackupRepository: バックアップリポジトリーのライフサイクルを表し、管理します。OADP は、namespace の最初の CSI スナップショットバックアップまたは復元が要求されると、namespace ごとにバックアップリポジトリーを作成します。
5.23.1.4. 増分バックアップのサポートについて

OADP は、コンテナー化されたワークロードと OpenShift Virtualization ワークロードの両方で、block および Filesystem の永続ボリュームの増分バックアップをサポートしています。次の表は、File System Backup (FSB)、Container Storage Interface (CSI)、および CSI Data Mover のサポート状況をまとめたものです。

Expand
表5.9 コンテナー化されたワークロードの OADP バックアップのサポートマトリックス
ボリュームモードFSB - ResticFSB - KopiaCSICSI Data Mover

ファイルシステム

S [1]、I [2]

S [1]、I [2]

S [1]

S [1]、I [2]

ブロック

N [3]

N [3]

S [1]

S [1]、I [2]

Expand
表5.10 OpenShift Virtualization ワークロードの OADP バックアップのサポートマトリックス
ボリュームモードFSB - ResticFSB - KopiaCSICSI Data Mover

ファイルシステム

N [3]

N [3]

S [1]

S [1]、I [2]

ブロック

N [3]

N [3]

S [1]

S [1]、I [2]

  1. バックアップをサポート
  2. 増分バックアップをサポート
  3. サポート対象外
注記

CSI Data Mover バックアップでは、uploaderType に関係なく Kopia が使用されます。

5.23.2. CSI スナップショットのバックアップおよび復元のデータ移動

OADP 1.3 Data Mover を使用して、永続ボリュームのバックアップと復元を実行できます。

5.23.2.1. CSI スナップショットを使用した永続ボリュームのバックアップ

OADP Data Mover を使用して、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。

前提条件

  • cluster-admin ロールでクラスターにアクセスできる。
  • OADP Operator がインストールされている。
  • CSI プラグインを組み込み、DataProtectionApplication カスタムリソース (CR) でノードエージェントを有効にしている。
  • 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。
  • metadata.labels.velero.io/csi-volumesnapshot-class: "true" のキー/値ペアを VolumeSnapshotClass CR に追加している。

手順

  1. 次の例のように、Backup オブジェクトの YAML ファイルを作成します。

    kind: Backup
    apiVersion: velero.io/v1
    metadata:
      name: backup
      namespace: openshift-adp
    spec:
      csiSnapshotTimeout: 10m0s
      defaultVolumesToFsBackup:
      includedNamespaces:
      - mysql-persistent
      itemOperationTimeout: 4h0m0s
      snapshotMoveData: true
      storageLocation: default
      ttl: 720h0m0s
      volumeSnapshotLocations:
      - dpa-sample-1
    # ...

    ここでは、以下のようになります。

    defaultVolumesToFsBackup
    fs-backup をオプトアウトするボリュームにのみ Data Mover を使用する場合、true に設定します。ボリュームにデフォルトで Data Mover を使用する場合は false に設定します。
    snapshotMoveData
    CSI スナップショットのリモートオブジェクトストレージへの移動を有効にするには、true に設定します。
  2. マニフェストを適用します。

    $ oc create -f backup.yaml

    スナップショットの作成が完了すると、DataUpload CR が作成されます。

    注記

    XFS ファイルシステムを使用してボリュームをフォーマットし、ボリュームの容量が 100% になっている場合は、no space left on device エラーが発生してバックアップが失敗します。以下に例を示します。

    Error: relabel failed /var/lib/kubelet/pods/3ac..34/volumes/ \
    kubernetes.io~csi/pvc-684..12c/mount: lsetxattr /var/lib/kubelet/ \
    pods/3ac..34/volumes/kubernetes.io~csi/pvc-68..2c/mount/data-xfs-103: \
    no space left on device

    このシナリオでは、バックアップが正常に完了するように、ボリュームのサイズを変更するか、ext4 などの別のファイルシステムタイプを使用することを検討してください。

検証

  • DataUpload CR の status.phase フィールドを監視して、スナップショットデータがリモートオブジェクトストアに正常に転送されたことを確認します。使用される値は、In ProgressCompletedFailed、または Canceled です。オブジェクトストアは、DataProtectionApplication CR の backupLocations スタンザで設定されます。

    • 次のコマンドを実行して、すべての DataUpload オブジェクトのリストを取得します。

      $ oc get datauploads -A

      出力例

      NAMESPACE       NAME                  STATUS      STARTED   BYTES DONE   TOTAL BYTES   STORAGE LOCATION   AGE     NODE
      openshift-adp   backup-test-1-sw76b   Completed   9m47s     108104082    108104082     dpa-sample-1       9m47s   ip-10-0-150-57.us-west-2.compute.internal
      openshift-adp   mongo-block-7dtpf     Completed   14m       1073741824   1073741824    dpa-sample-1       14m     ip-10-0-150-57.us-west-2.compute.internal

    • 次のコマンドを実行して、DataUpload オブジェクトの status.phase フィールドの値を確認します。

      $ oc get datauploads <dataupload_name> -o yaml

      出力例

      apiVersion: velero.io/v2alpha1
      kind: DataUpload
      metadata:
        name: backup-test-1-sw76b
        namespace: openshift-adp
      spec:
        backupStorageLocation: dpa-sample-1
        csiSnapshot:
          snapshotClass: ""
          storageClass: gp3-csi
          volumeSnapshot: velero-mysql-fq8sl
        operationTimeout: 10m0s
        snapshotType: CSI
        sourceNamespace: mysql-persistent
        sourcePVC: mysql
      status:
        completionTimestamp: "2023-11-02T16:57:02Z"
        node: ip-10-0-150-57.us-west-2.compute.internal
        path: /host_pods/15116bac-cc01-4d9b-8ee7-609c3bef6bde/volumes/kubernetes.io~csi/pvc-eead8167-556b-461a-b3ec-441749e291c4/mount
        phase: Completed
        progress:
          bytesDone: 108104082
          totalBytes: 108104082
        snapshotID: 8da1c5febf25225f4577ada2aeb9f899
        startTimestamp: "2023-11-02T16:56:22Z"

      ここでは、以下のようになります。

      フェーズ: 完了
      これは、スナップショットデータがリモートオブジェクトストアに正常に転送されたことを示しています。
5.23.2.2. CSI ボリュームスナップショットの復元

Restore CR を作成することで、ボリュームスナップショットを復元できます。

注記

OAPD 1.3 のビルトイン Data Mover を使用して、OADP 1.2 から Volsync バックアップを復元することはできません。OADP 1.3 にアップグレードする前に、Restic を使用してすべてのワークロードのファイルシステムバックアップを実行することが推奨されます。

前提条件

  • cluster-admin ロールでクラスターにアクセスできる。
  • データの復元元となる OADP Backup CR がある。

手順

  1. 次の例のように、Restore CR の YAML ファイルを作成します。

    Restore CR の例

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
      name: restore
      namespace: openshift-adp
    spec:
      backupName: <backup>
    # ...

  2. マニフェストを適用します。

    $ oc create -f restore.yaml

    復元が開始されると、DataDownload が作成されます。

検証

  • DataDownload CR の status.phase フィールドをチェックすることで、復元プロセスのステータスを監視できます。使用される値は、In ProgressCompletedFailed、または Canceled です。

    • すべての DataDownload オブジェクトのリストを取得するには、次のコマンドを実行します。

      $ oc get datadownloads -A

      出力例

      NAMESPACE       NAME                   STATUS      STARTED   BYTES DONE   TOTAL BYTES   STORAGE LOCATION   AGE     NODE
      openshift-adp   restore-test-1-sk7lg   Completed   7m11s     108104082    108104082     dpa-sample-1       7m11s   ip-10-0-150-57.us-west-2.compute.internal

    • 次のコマンドを入力して、特定の DataDownload オブジェクトの status.phase フィールドの値を確認します。

      $ oc get datadownloads <datadownload_name> -o yaml

      出力例

      apiVersion: velero.io/v2alpha1
      kind: DataDownload
      metadata:
        name: restore-test-1-sk7lg
        namespace: openshift-adp
      spec:
        backupStorageLocation: dpa-sample-1
        operationTimeout: 10m0s
        snapshotID: 8da1c5febf25225f4577ada2aeb9f899
        sourceNamespace: mysql-persistent
        targetVolume:
          namespace: mysql-persistent
          pv: ""
          pvc: mysql
      status:
        completionTimestamp: "2023-11-02T17:01:24Z"
        node: ip-10-0-150-57.us-west-2.compute.internal
        phase: Completed
        progress:
          bytesDone: 108104082
          totalBytes: 108104082
        startTimestamp: "2023-11-02T17:00:52Z"

      ここでは、以下のようになります。

      フェーズ: 完了
      CSI スナップショットデータが正常に復元されたことを示します。
5.23.2.3. OADP 1.3 の削除ポリシー

削除ポリシーは、システムからデータを削除するためのルールを決定します。保存期間、データの機密性、コンプライアンス要件などの要素に基づいて、削除をいつどのように行うかを指定します。規制を遵守し、貴重な情報を保護しながら、データの削除を効果的に管理します。

5.23.2.3.1. OADP 1.3 の削除ポリシーガイドライン

OADP 1.3 の次の削除ポリシーガイドラインを確認してください。

  • OADP 1.3.x でいずれかのタイプのバックアップおよびリストア方法を使用する場合は、VolumeSnapshotClass カスタムリソース (CR) の deletionPolicy フィールドを Retain または Delete に設定できます。

5.23.3. Data Mover のバックアップと復元 PVC の設定

データムーバーの操作を最適化するために、バックアップおよび復元用の永続ボリューム要求 (PVC) を設定します。CephFS のようなストレージクラスの場合、これらの中間 PVC を使用することで、システムはスナップショットから読み取り専用ボリュームを作成できるようになり、バックアップが大幅に高速化されます。

DataProtectionApplication (DPA) の nodeAgent.backupPVC セクションを使用して readonly バックアップ PVC を作成し、readOnly アクセスモードを true に設定します。

DPA の nodeAgent.backupPVC セクションで次のフィールドを使用して、バックアップ PVC を設定できます。

  • storageClass: バックアップ PVC に使用するストレージクラスの名前。
  • readOnly: バックアップ PVC を読み取り専用としてマウントする必要があるかどうかを示します。このフィールドを true に設定すると、spcNoRelabeling フィールドも true に設定する必要があります。
  • spcNoRelabeling: true に設定されている場合、ボリュームの自動再ラベル付けを無効にします。このフィールドは、readOnlytrue の場合にのみ true に設定できます。readOnly フラグが true の場合、ボリュームの SELinux の再ラベル付けはできません。これにより、Data Mover のバックアップが失敗します。したがって、CephFS ストレージクラスに readOnly アクセスモードを使用している場合は、再ラベル付けを無効にする必要があります。
5.23.3.1. Data Mover バックアップのバックアップ PVC の設定

DataProtectionApplication (DPA) でバックアップ永続ボリューム要求 (PVC) 設定を設定して、さまざまなストレージクラスにおける Data Mover のバックアップパフォーマンスを最適化します。この機能により、データ転送速度を向上させるための読み取り専用アクセスモードが利用可能になります。

前提条件

  • OADP Operator がインストールされている。

手順

  1. 次の例に示すように、DPA の nodeAgent.backupPVC セクションを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      backupLocations:
      - velero:
          credential:
            key: cloud
            name: cloud-credentials-gcp
          default: true
          objectStorage:
            bucket: oadp...2jw
            prefix: velero
          provider: gcp
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
          backupPVC:
            storage-class-1:
              readOnly: true
              spcNoRelabeling: true
              storageClass: gp3-csi
            storage-class-2:
              readOnly: false
              spcNoRelabeling: false
              storageClass: gp3-csi
        velero:
          defaultPlugins:
          - gcp
          - openshift
          - csi

    ここでは、以下のようになります。

    バックアップ PVC
    バックアップ PVC セクションを指定します。この例では、backupPVC セクションには、storage-class-1 および storage-class-2 の 2 つのストレージクラスの設定があります。
    readOnly
    ストレージクラス 1 のバックアップ PVC が 読み取り専用 として設定されていることを指定します。
    spcNoRelabeling
    ストレージクラス 1 のバックアップ PVC が 読み取り専用で あるため、spcNoRelabeling フィールドが true に設定されていることを指定します。
  2. 次の設定を使用して、Backup カスタムリソースを作成します。

    バックアップの例

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace>
      snapshotMoveData: true

    snapshotMoveData
    Data Mover バックアップの場合は true に設定します。

検証

  • 次のコマンドを実行して、バックアップ PVC が読み取り専用 (ROX) として作成されていることを確認します。

    コマンドの例

    $ oc get pvc -n openshift-adp -w

    test-backup1-l..d   Bound   pvc-1298.....22f8   2Gi        ROX            standard-csi   <unset>                 37s
    test-backup1-l..d   Bound   pvc-1298....022f8   2Gi        ROX            standard-csi   <unset>                 37s
5.23.3.2. Data Mover 復元用の restorePVC の設定

DataProtectionApplication (DPA) で復元永続ボリューム要求 (PVC) 設定を設定して、Data Mover の復元操作を最適化し、並列ボリューム復元を有効にします。これにより、復元 Pod を複数のノードに分散させることで、復元パフォーマンスが向上します。

restorePVC は、Data Mover の復元操作中にデータの書き込みに使用される中間 PVC です。

ignoreDelayBinding フィールドを使用して、DataProtectionApplication (DPA) オブジェクトで restorePVC を設定できます。ignoreDelayBinding フィールドを true に設定すると、復元操作は WaitForFirstConsumer バインディングモードを無視できます。続いて、データ移動型復元操作によって復元用 Pod が作成され、関連付けられたボリュームが任意のノードにプロビジョニングされます。

ignoreDelayBinding 設定は、複数のボリュームの復元が並行して行われるシナリオで役に立ちます。ignoreDelayBinding フィールドを true に設定すると、復元 Pod をすべてのノードに均等に分散できます。

前提条件

  • OADP Operator がインストールされている。
  • アプリケーションの Data Mover バックアップを作成している。

手順

  • 次の例に示すように、DPA で restorePVC セクションを設定します。

    Data Protection Application の例

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
    #  ...
      configuration:
        nodeAgent:
          enable: true
          uploaderType: kopia
        restorePVC:
          ignoreDelayBinding: true

    ここでは、以下のようになります。

    PVC を復元する
    restorePVC セクションを指定します。
    ignoreDelayBinding
    ignoreDelayBinding フィールドを true に設定します。

5.23.4. Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのオーバーライド

Data Protection Application (DPA) 内の特定の環境変数を使用することで、Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのデフォルト値を上書きできます。

VeleroPod 設定で環境変数を設定することにより、Data Protection Application (DPA) を設定して、デフォルトの Kopia ハッシュ、暗号化、およびスプリッターアルゴリズムを上書きします。これにより、Kopia のパフォーマンスを向上させ、バックアップ操作のパフォーマンスメトリクスを比較することができます。

注記

Data Protection Application (DPA) の分割、ハッシュ、および暗号化のための Kopia アルゴリズムの設定は、Kopia リポジトリーの初回作成時にのみ適用され、後で変更することはできません。

異なる Kopia アルゴリズムを使用するには、オブジェクトストレージに、バックアップの以前の Kopia リポジトリーが含まれていないことを確認してください。Backup Storage Location (BSL) で新しいオブジェクトストレージを設定するか、BSL 設定でオブジェクトストレージの一意の接頭辞を指定します。

前提条件

  • OADP Operator がインストールされている。
  • クラウドプロバイダーから提供された認証情報を使用してシークレットを作成した。

手順

  • 次の例に示すように、ハッシュ、暗号化、およびスプリッター用の環境変数を使用して DPA を設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    #...
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
      velero:
        defaultPlugins:
        - openshift
        - aws
        - csi
        defaultSnapshotMoveData: true
        podConfig:
          env:
            - name: KOPIA_HASHING_ALGORITHM
              value: <hashing_algorithm_name>
            - name: KOPIA_ENCRYPTION_ALGORITHM
              value: <encryption_algorithm_name>
            - name: KOPIA_SPLITTER_ALGORITHM
              value: <splitter_algorithm_name>

    ここでは、以下のようになります。

    enable
    nodeAgent を有効にするには、true に設定してください。
    アップローダータイプ
    アップローダーの種類を kopia として指定します。
    csi
    csi プラグインを含めます。
    < ハッシュアルゴリズム名 >
    ハッシュアルゴリズムを指定します。たとえば、BLAKE3-256 です。
    < 暗号化アルゴリズム名 >
    暗号化アルゴリズムを指定します。たとえば、CHACHA20-POLY1305-HMAC-SHA256 です。
    < スプリッターアルゴリズム名 >
    スプリッターアルゴリズムを指定します。たとえば、DYNAMIC-8M-RABINKARP です。

Kopia の環境変数を使用して、ハッシュ、暗号化、およびスプリッターを行い、アプリケーションをバックアップします。バックアップを AWS S3 バケットに保存し、Kopia リポジトリーに接続して環境変数を確認してください。

前提条件

  • OADP Operator がインストールされている。
  • Backup Storage Location として AWS S3 バケットが設定されている。
  • クラウドプロバイダーから提供された認証情報を使用してシークレットを作成した。
  • Kopia クライアントがインストールされている。
  • 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。

手順

  1. 次の例に示すように、Data Protection Application (DPA) を設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
    name: <dpa_name>
    namespace: openshift-adp
    spec:
    backupLocations:
    - name: aws
      velero:
        config:
          profile: default
          region: <region_name>
        credential:
          key: cloud
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: <bucket_name>
          prefix: velero
        provider: aws
    configuration:
      nodeAgent:
        enable: true
        uploaderType: kopia
      velero:
        defaultPlugins:
        - openshift
        - aws
        - csi
        defaultSnapshotMoveData: true
        podConfig:
          env:
            - name: KOPIA_HASHING_ALGORITHM
              value: BLAKE3-256
            - name: KOPIA_ENCRYPTION_ALGORITHM
              value: CHACHA20-POLY1305-HMAC-SHA256
            - name: KOPIA_SPLITTER_ALGORITHM
              value: DYNAMIC-8M-RABINKARP

    ここでは、以下のようになります。

    <dpa_name>
    DPA の名前を指定します。
    < 地域名 >
    バックアップデータの保存場所となるリージョンを指定します。
    クラウド認証情報
    デフォルトの Secret オブジェクトの名前を指定します。
    <bucket_name>
    AWS S3 バケット名を指定します。
    csi
    csi プラグインを含めます。
    ブレイク 3-256
    ハッシュアルゴリズムとして BLAKE3-256 を指定します。
    CHACHA20-POLY1305-HMAC-SHA256
    暗号化アルゴリズムを CHACHA20-POLY1305-HMAC-SHA256 として指定します。
    ダイナミック -8M- ラビンカルプ
    スプリッターアルゴリズムを DYNAMIC-8M-RABINKARP として指定します。
  2. 次のコマンドを実行して DPA を作成します。

    $ oc create -f <dpa_file_name>

    <dpa_file_name> を、設定した DPA のファイル名に置き換えてください。

  3. 次のコマンドを実行して、DPA が調整されたことを確認します。

    $ oc get dpa -o yaml
  4. 次の例に示すように、バックアップ CR を作成します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
      name: test-backup
      namespace: openshift-adp
    spec:
      includedNamespaces:
      - <application_namespace>
      defaultVolumesToFsBackup: true

    <application_namespace> を、クラスターにインストールされているアプリケーションの名前空間に置き換えてください。

  5. 次のコマンドを実行してバックアップを作成します。

    $ oc apply -f <backup_file_name>

    <backup_file_name> を バックアップ CR ファイルの名前に置き換えてください。

  6. 次のコマンドを実行して、バックアップが完了したことを確認します。

    $ oc get backups.velero.io <backup_name> -o yaml

    <backup_name> を バックアップの名前に置き換えてください。

検証

  1. 次のコマンドを実行して、Kopia リポジトリーに接続します。

    $ kopia repository connect s3 \
      --bucket=<bucket_name> \
      --prefix=velero/kopia/<application_namespace> \
      --password=static-passw0rd \
      --access-key="<aws_s3_access_key>" \
      --secret-access-key="<aws_s3_secret_access_key>"

    ここでは、以下のようになります。

    <bucket_name>
    AWS S3 バケット名を指定します。
    <application_namespace>
    アプリケーションの名前空間を指定します。
    static-passw0rd
    これはリポジトリーに接続するための Kopia パスワードです。
    <aws_s3_access_key>
    AWS S3 アクセスキーを指定します。
    <aws_s3_secret_access_key>
    AWS S3 ストレージプロバイダーのシークレットアクセスキーを指定します。

    AWS S3 以外のストレージプロバイダーを使用している場合は、コマンドにバケットエンドポイントの URL パラメーター --endpoint を追加する必要があります。

  2. 次のコマンドを実行して、バックアップ用に DPA で設定した環境変数を Kopia が使用していることを確認します。

    $ kopia repository status

    出力例

    Hash:                BLAKE3-256
    Encryption:          CHACHA20-POLY1305-HMAC-SHA256
    Splitter:            DYNAMIC-8M-RABINKARP
    Format version:      3

5.23.4.3. Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムのベンチマーク

Kopia コマンドを実行して、ハッシュ、暗号化、およびスプリッターアルゴリズムのベンチマークテストを実施します。ベンチマークの結果に基づいて、ワークロードに最も適したアルゴリズムを選択できます。Kopia のベンチマークコマンドは、クラスター上の Pod から実行します。ベンチマークの結果は、CPU 速度、使用可能な RAM、ディスク速度、現在の I/O 負荷などによって異なります。

注記

Data Protection Application (DPA) の分割、ハッシュ、および暗号化のための Kopia アルゴリズムの設定は、Kopia リポジトリーの初回作成時にのみ適用され、後で変更することはできません。

異なる Kopia アルゴリズムを使用するには、オブジェクトストレージに、バックアップの以前の Kopia リポジトリーが含まれていないことを確認してください。Backup Storage Location (BSL) で新しいオブジェクトストレージを設定するか、BSL 設定でオブジェクトストレージの一意の接頭辞を指定します。

前提条件

  • OADP Operator がインストールされている。
  • 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。
  • Container Storage Interface (CSI) スナップショットを使用してアプリケーションのバックアップを実行した。

手順

  1. 以下の例のように、must-gather Pod を設定します。必ず OADP バージョン 1.3 以降の oadp-mustgather イメージを使用してください。

    Pod 設定の例

    apiVersion: v1
    kind: Pod
    metadata:
      name: oadp-mustgather-pod
      labels:
        purpose: user-interaction
    spec:
      containers:
      - name: oadp-mustgather-container
        image: registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
        command: ["sleep"]
        args: ["infinity"]

    Kopia クライアントは oadp-mustgather イメージで利用できます。

  2. 以下のコマンドを実行して Pod を作成します。

    $ oc apply -f <pod_config_file_name>

    <pod_config_file_name> を、Pod 設定用の YAML ファイルの名前に置き換えてください。

  3. Kopia がリポジトリーに接続できるように、Pod の Security Context Constraints (SCC) が anyuid であることを確認します。

    $ oc describe pod/oadp-mustgather-pod | grep scc

    出力例

    openshift.io/scc: anyuid

  4. 次のコマンドを実行して、SSH 経由で Pod に接続します。

    $ oc -n openshift-adp rsh pod/oadp-mustgather-pod
  5. 次のコマンドを実行して、Kopia リポジトリーに接続します。

    sh-5.1# kopia repository connect s3 \
      --bucket=<bucket_name> \
      --prefix=velero/kopia/<application_namespace> \
      --password=static-passw0rd \
      --access-key="<access_key>" \
      --secret-access-key="<secret_access_key>" \
      --endpoint=<bucket_endpoint>

    ここでは、以下のようになります。

    <bucket_name>
    オブジェクトストレージプロバイダーのバケット名を指定します。
    <application_namespace>
    アプリケーションの名前空間を指定します。
    static-passw0rd
    これはリポジトリーに接続するための Kopia パスワードです。
    < アクセスキー >
    オブジェクトストレージプロバイダーのアクセスキーを指定します。
    < シークレットアクセスキー >
    オブジェクトストレージプロバイダーのシークレットアクセスキーを指定します。
    <bucket_endpoint>
    バケットのエンドポイントを指定します。ストレージプロバイダーとして AWS S3 を使用している場合は、バケットエンドポイントを指定する必要はありません。

    これはコマンドの例です。コマンドはオブジェクトストレージプロバイダーによって異なる場合があります。

  6. ハッシュアルゴリズムをベンチマークするには、次のコマンドを実行します。

    sh-5.1# kopia benchmark hashing

    出力例

    Benchmarking hash 'BLAKE2B-256' (100 x 1048576 bytes, parallelism 1)
    Benchmarking hash 'BLAKE2B-256-128' (100 x 1048576 bytes, parallelism 1)
    
    
    Fastest option for this machine is: --block-hash=BLAKE3-256

  7. 暗号化アルゴリズムをベンチマークするには、次のコマンドを実行します。

    sh-5.1# kopia benchmark encryption

    出力例

    Benchmarking encryption 'AES256-GCM-HMAC-SHA256'
    Benchmarking encryption 'CHACHA20-POLY1305-HMAC-SHA256'
    
    Fastest option for this machine is: --encryption=AES256-GCM-HMAC-SHA256

  8. スプリッターアルゴリズムをベンチマークするには、次のコマンドを実行します。

    sh-5.1# kopia benchmark splitter

    出力例

    splitting 16 blocks of 32MiB each, parallelism 1
    DYNAMIC                     747.6 MB/s count:107 min:9467 10th:2277562 25th:2971794 50th:4747177 75th:7603998 90th:8388608 max:8388608
    DYNAMIC-128K-BUZHASH        718.5 MB/s count:3183 min:3076 10th:80896 25th:104312 50th:157621 75th:249115 90th:262144 max:262144
    DYNAMIC-128K-RABINKARP      164.4 MB/s count:3160 min:9667 10th:80098 25th:106626 50th:162269 75th:250655 90th:262144 max:262144

5.24. OADP で使用される API

OADP では次の API を使用できます。

Velero API
Velero API ドキュメントは、Red Hat ではなく、Velero によって管理されています。詳細は、API types (Velero ドキュメント) を参照してください。
OADP API

OADP API は次のとおりです。

  • DataProtectionApplicationSpec
  • BackupLocation
  • SnapshotLocation
  • ApplicationConfig
  • VeleroConfig
  • CustomPlugin
  • ResticConfig
  • PodConfig
  • Features
  • DataMover

    詳細は、OADP Operator (Go ドキュメント) を参照してください。

5.24.1. DataProtectionApplicationSpec タイプ

以下は、DataProtectionApplicationSpec OADP API です。

Expand
表5.11 DataProtectionApplicationSpec
プロパティー説明

backupLocations

[] BackupLocation

BackupStorageLocations に使用する設定のリストを定義します。

snapshotLocations

[] SnapshotLocation

VolumeSnapshotLocations に使用する設定のリストを定義します。

unsupportedOverrides

map [ UnsupportedImageKey ] string

デプロイされた依存イメージを開発用にオーバーライドするために使用できます。オプションは、veleroImageFqinawsPluginImageFqinhypershiftPluginImageFqinopenshiftPluginImageFqinazurePluginImageFqingcpPluginImageFqincsiPluginImageFqindataMoverImageFqinresticRestoreImageFqinkubevirtPluginImageFqin、および operator-type です。

podAnnotations

map [ string ] string

Operator によってデプロイされた Pod にアノテーションを追加するために使用されます。

podDnsPolicy

DNSPolicy

Pod の DNS の設定を定義します。

podDnsConfig

PodDNSConfig

DNSPolicy から生成されたパラメーターに加えて、Pod の DNS パラメーターを定義します。

backupImages

*bool

イメージのバックアップと復元を有効にするためにレジストリーをデプロイメントするかどうかを指定するために使用されます。

configuration

*ApplicationConfig

Data Protection Application のサーバー設定を定義するために使用されます。

features

*Features

テクノロジープレビュー機能を有効にするための DPA の設定を定義します。

5.24.2. BackupLocation タイプ

以下は BackupLocation OADP API です。

Expand
表5.12 BackupLocation
プロパティー説明

velero

*velero.BackupStorageLocationSpec

Backup Storage Location で説明されているとおり、ボリュームスナップショットの保存場所。

bucket

*CloudStorageLocation

一部のクラウドストレージプロバイダーで、Backup Storage Location として使用するバケットの作成を自動化します。

重要

bucket パラメーターはテクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

5.24.3. SnapshotLocation タイプ

以下は SnapshotLocation OADP API です。

Expand
表5.13 SnapshotLocation
プロパティー説明

velero

*VolumeSnapshotLocationSpec

Volume Snapshot Location で説明されているとおり、ボリュームスナップショットの保存場所。

5.24.4. ApplicationConfig タイプ

以下は ApplicationConfig OADP API です。

Expand
表5.14 ApplicationConfig
プロパティー説明

velero

*VeleroConfig

Velero サーバーの設定を定義します。

restic

*ResticConfig

Restic サーバーの設定を定義します。

5.24.5. VeleroConfig タイプ

以下は VeleroConfig OADP API です。

Expand
表5.15 VeleroConfig
プロパティー説明

featureFlags

[] string

Velero インスタンスで有効にする機能のリストを定義します。

defaultPlugins

[] string

次のタイプのデフォルトの Velero プラグインをインストールできます: awsazurecsigcpkubevirt、および openshift

customPlugins

[]CustomPlugin

カスタム Velero プラグインのインストールに使用されます。

restoreResourcesVersionPriority

string

EnableAPIGroupVersions 機能フラグと組み合わせて使用するために定義されている場合に作成される config map を表します。このフィールドを定義すると、EnableAPIGroupVersions が Velero サーバー機能フラグに自動的に追加されます。

noDefaultBackupLocation

bool

デフォルトの Backup Storage Location を設定せずに Velero をインストールするには、インストールを確認するために noDefaultBackupLocation フラグを設定する必要があります。

podConfig

*PodConfig

Velero Pod の設定を定義します。

logLevel

string

Velero サーバーのログレベル (最も詳細なログを記録するには debug を使用し、Velero のデフォルトは未設定のままにします)。有効なオプションは、tracedebuginfowarningerrorfatal、および panic です。

5.24.6. CustomPlugin タイプ

以下は CustomPlugin OADP API です。

Expand
表5.16 CustomPlugin
プロパティー説明

name

string

カスタムプラグインの名前。

image

string

カスタムプラグインのイメージ。

5.24.7. ResticConfig タイプ

以下は ResticConfig OADP API です。

Expand
表5.17 ResticConfig
プロパティー説明

enable

*bool

true に設定すると、Restic を使用したバックアップと復元が有効になります。false に設定すると、スナップショットが必要になります。

supplementalGroups

[]int64

Restic Pod に適用される Linux グループを定義します。

timeout

string

Restic タイムアウトを定義するユーザー指定の期間文字列。デフォルト値は 1hr (1 時間) です。期間文字列は、符号付きの場合もある 10 進数のシーケンスであり、それぞれに 300ms-1.5h2h45m などのオプションの分数と単位接尾辞が付いています。有効な時間単位は、nsus (または µs)、mssm、および h です。

podConfig

*PodConfig

Restic Pod の設定を定義します。

5.24.8. PodConfig タイプ

以下は PodConfig OADP API です。

Expand
表5.18 PodConfig
プロパティー説明

nodeSelector

map [ string ] string

Velero podSpec または Restic podSpec に提供される nodeSelector を定義します。

tolerations

[]Toleration

Velero デプロイメントまたは Restic daemonset に適用される toleration のリストを定義します。

resourceAllocations

ResourceRequirements

「Velero の CPU とメモリーのリソース割り当てを設定」セクションの説明に従って、Velero Pod または Restic Pod の特定のリソースの limits および requests を設定します。

labels

map [ string ] string

Pod に追加するラベル。

5.24.9. Features タイプ

以下は Features OADP API です。

Expand
表5.19 Features
プロパティー説明

dataMover

*DataMover

Data Mover の設定を定義します。

5.24.10. DataMover タイプ

以下は DataMover OADP API です。

Expand
表5.20 DataMover
プロパティー説明

enable

bool

true に設定すると、ボリュームスナップショットムーバーコントローラーと変更された CSI Data Mover プラグインがデプロイされます。false に設定すると、これらはデプロイされません。

credentialName

string

Data Mover のユーザー指定の Restic Secret 名。

timeout

string

VolumeSnapshotBackupVolumeSnapshotRestore が完了するまでのユーザー指定の期間文字列。デフォルトは 10m (10 分) です。期間文字列は、符号付きの場合もある 10 進数のシーケンスであり、それぞれに 300ms-1.5h2h45m などのオプションの分数と単位接尾辞が付いています。有効な時間単位は、nsus (または µs)、mssm、および h です。

5.25. OADP の高度な特徴と機能

5.25.1. 同一クラスター上での異なる Kubernetes API バージョンの操作

バックアップおよびリストア操作中に、クラスター上の異なる Kubernetes API バージョンを管理します。Velero でサポートされているすべての API グループバージョンをバックアップするように設定することで、リソースを新しい宛先クラスターに移行する際に互換性を維持するのに役立ちます。

5.25.1.1. クラスター上の Kubernetes API グループバージョンのリスト表示

ソースクラスター上で推奨される Kubernetes API グループのバージョンを特定してください。これは、単一の API に対して複数の API バージョンが利用可能な場合に、適切な API バージョンを選択するのに役立ちます。

ソースクラスターは複数のバージョンの API を提供する場合があり、これらのバージョンの 1 つが優先 API バージョンになります。たとえば、Example という名前の API を持つソースクラスターは、example.com/v1 および example.com/v1beta2 API グループで使用できる場合があります。

Velero を使用してそのようなソースクラスターをバックアップおよび復元する場合、Velero は、Kubernetes API の優先バージョンを使用するリソースのバージョンのみをバックアップします。

上記の例では、example.com/v1 が優先 API である場合、Velero は example.com/v1 を使用するリソースのバージョンのみをバックアップします。さらに、Velero がターゲットクラスターでリソースを復元するには、ターゲットクラスターで使用可能な API リソースのセットに example.com/v1 が登録されている必要があります。

したがって、ターゲットクラスター上の Kubernetes API グループバージョンのリストを生成して、優先 API バージョンが使用可能な API リソースのセットに登録されていることを確認する必要があります。

手順

  • 以下のコマンドを実行します。

    $ oc api-resources
5.25.1.2. API グループバージョンの有効化について

API グループバージョン機能を有効にすると、優先バージョンだけでなく、クラスターでサポートされているすべての Kubernetes API バージョンがバックアップされます。これにより、データを宛先クラスターに復元する際に、完全な API 互換性を維持することができます。

デフォルトでは、Velero は Kubernetes API の優先バージョンを使用するリソースのみをバックアップします。しかし、Velero にはこの制限を克服する API グループバージョンの有効化機能も搭載されています。ソースクラスターでこの機能を有効にすると、Velero は優先バージョンだけでなく、クラスターでサポートされている すべて の Kubernetes API グループバージョンをバックアップします。バージョンがバックアップ .tar ファイルに保存されると、目的のクラスターで復元できるようになります。

たとえば、Example という名前の API を持つソースクラスターが、example.com/v1 および example.com/v1beta2 API グループで使用でき、example.com/v1 が優先 API だとします。

Enable API Group Versions 機能を有効にしないと、Velero は Example の優先 API グループバージョン (example.com/v1) のみをバックアップします。この機能を有効にすると、Velero は example.com/v1beta2 もバックアップします。

宛先クラスターで Enable API Group Versions 機能が有効になっている場合、Velero は、API グループバージョンの優先順位に基づいて、復元するバージョンを選択します。

注記

Enable API Group Versions はまだベータ版です。

Velero は次のアルゴリズムを使用して API バージョンに優先順位を割り当てます。この場合、1 は優先順位が最も高くなります。

  1. 宛先 クラスターの優先バージョン
  2. source_ クラスターの優先バージョン
  3. Kubernetes バージョンの優先順位が最も高い共通の非優先サポート対象バージョン
5.25.1.3. Enable API Group Versions の使用

EnableAPIGroupVersions 機能フラグを設定すると、優先バージョンだけでなく、クラスターでサポートされているすべての Kubernetes API グループバージョンがバックアップされます。これは、クラスター内の異なる API グループ間での互換性を維持するのに役立ちます。

注記

Enable API Group Versions はまだベータ版です。

手順

  • EnableAPIGroupVersions 機能フラグを設定します。

    apiVersion: oadp.openshift.io/vialpha1
    kind: DataProtectionApplication
    ...
    spec:
      configuration:
        velero:
          featureFlags:
          - EnableAPIGroupVersions

5.25.2. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する

OpenShift Container Platform クラスターからアプリケーションデータをバックアップし、別のクラスターに復元する方法について説明します。単一クラスターでの運用よりも複雑ではあるものの、OpenShift API for Data Protection は、このようなクラスター間データ復旧を管理するためのツールを提供します。

5.25.2.1. あるクラスターからのデータのバックアップと別のクラスターへの復元について

OADP を使用して、ある OpenShift Container Platform クラスターからアプリケーションデータをバックアップし、別のクラスターに復元します。

OpenShift API for Data Protection (OADP) は、同じ OpenShift Container Platform クラスター内のアプリケーションデータをバックアップおよび復元するように設計されています。Migration Toolkit for Containers (MTC) は、アプリケーションデータを含むコンテナーを 1 つの OpenShift Container Platform クラスターから別のクラスターに移行するように設計されています。

OADP を使用して、1 つの OpenShift Container Platform クラスターからアプリケーションデータをバックアップし、それを別のクラスターに復元できます。ただし、これを行うことは、MTC または OADP を使用して同じクラスター上でバックアップと復元を行うよりも複雑です。

OADP を使用して 1 つのクラスターからデータをバックアップし、それを別のクラスターに復元するには、OADP を使用して同じクラスター上でデータをバックアップおよび復元する場合に適用される前提条件と手順に加えて、次の要素を考慮する必要があります。

  • Operator
  • Velero の使用
  • UID と GID の範囲
5.25.2.1.1. Operator

バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。

5.25.2.1.2. Velero の使用

OADP が構築されている Velero は、クラウドプロバイダー間での永続ボリュームスナップショットの移行をネイティブにサポートしていません。クラウドプラットフォーム間でボリュームスナップショットデータを移行するには、ファイルシステムレベルでボリュームの内容をバックアップする Velero Restic ファイルシステムバックアップオプションを有効にする または CSI スナップショットに OADP Data Mover を使用する必要があります。

注記

OADP 1.1 以前では、Velero Restic ファイルシステムのバックアップオプションは restic と呼ばれます。OADP 1.2 以降では、Velero Restic ファイルシステムのバックアップオプションは file-system-backup と呼ばれます。

  • AWS リージョン間、または Microsoft Azure リージョン間でデータを移行するには、Velero のファイルシステムバックアップを使用する必要があります。
  • Velero は、ソースクラスターより の Kubernetes バージョンを使用したクラスターへのデータの復元をサポートしていません。
  • 理論的には、移行元よりも 新しい Kubernetes バージョンを備えた移行先にワークロードを移行することは可能ですが、カスタムリソースごとにクラスター間の API グループの互換性を考慮する必要があります。Kubernetes バージョンのアップグレードによりコアまたはネイティブ API グループの互換性が失われる場合は、まず影響を受けるカスタムリソースを更新する必要があります。
5.25.2.2. バックアップする Pod ボリュームの判断方法

ファイルシステムバックアップ (FSB) を開始する前に、バックアップ対象の Pod ボリュームを指定する必要があります。ベレロはこのプロセスをボリュームの発見と呼んでいる。Velero が FSB、ボリュームスナップショット、またはデータムーバーバックアップの中からどれを選択するかは、オプトイン方式またはオプトアウト方式のいずれかを選択できます。

  • オプトイン方式: オプトイン方式では、ボリュームがデフォルトでスナップショットまたは Data Mover を使用してバックアップされます。FSB は、アノテーションによってオプトインされた特定のボリュームで使用されます。
  • オプトアウト方式: オプトアウト方式では、ボリュームがデフォルトで FSB を使用してバックアップされます。スナップショットまたは Data Mover は、アノテーションによってオプトアウトされた特定のボリュームで使用されます。
5.25.2.2.1. 制限
  • FSB は、hostpath ボリュームのバックアップと復元をサポートしていません。ただし、FSB はローカルボリュームのバックアップと復元をサポートします。
  • Velero は、作成するすべてのバックアップリポジトリーに静的な共通暗号化キーを使用します。この静的キーは、バックアップストレージにアクセスできれば、誰でもバックアップデータを復号化できることを意味します。バックアップストレージへのアクセスを制限することが重要です。
  • PVC の場合、すべての増分バックアップチェーンは Pod が再スケジュールされても維持されます。

    emptyDir ボリュームなどの PVC ではない Pod ボリュームの場合、たとえば ReplicaSet やデプロイメントなどによって Pod が削除または再作成されると、そのボリュームの次回のバックアップは増分バックアップではなく完全バックアップになります。Pod ボリュームのライフサイクルは、その Pod によって定義されると想定されます。

  • バックアップデータは増分的に保存できますが、データベースなどの大きなファイルのバックアップには時間がかかることがあります。これは、FSB が重複排除を使用して、バックアップが必要な差分を見つけるためです。
  • FSB は、Pod が実行されているノードのファイルシステムにアクセスすることで、ボリュームからデータを読み書きします。そのため、FSB は Pod からマウントされたボリュームのみバックアップでき、PVC から直接バックアップすることはできません。一部の Velero ユーザーは、Velero バックアップを実行する前に、無限スリープがある BusyBox や Alpine コンテナーなどのステージング Pod を実行して PVC と PV のペアをマウントすることで、この制限を克服しています。
  • FSB では、ボリュームは <hostPath>/<pod UID> の下にマウントされ、<hostPath> が設定可能であると想定します。vCluster などの一部の Kubernetes システムでは、ボリュームを <pod UID> サブディレクトリーにマウントしないため、そのようなシステムでは VFSB は期待どおり機能しません。
5.25.2.2.2. オプトインメソッドを使用して Pod ボリュームをバックアップする

ファイルシステムバックアップ (FSB) を使用してバックアップする Pod ボリュームを正確に指定するには、オプトイン方式を使用します。特定のアノテーションを適用することで、必要なボリュームのみを選択的に含めることができ、ストレージとバックアップの効率管理に役立ちます。

手順

  • バックアップするボリュームを 1 つ以上含む各 Pod で、次のコマンドを入力します。

    $ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \
      backup.velero.io/backup-volumes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>

    ここでは、以下のようになります。

    <your_volume_name_x>
    Pod 仕様の x 番目のボリュームの名前を指定します。
5.25.2.2.3. オプトアウトメソッドを使用して Pod ボリュームをバックアップする

オプトアウト方式を使用して、特定の Pod ボリュームをデフォルトのファイルシステムバックアップ (FSB) から除外します。この方法ではすべての Pod ボリュームが自動的にバックアップされますが、バックアップ操作をカスタマイズするには、アノテーションを使用して特定のボリュームをスキップすることができます。

オプトアウトアプローチを使用する場合、いくつかの例外を除き、すべての Pod ボリュームが File System Backup (FSB) を使用してバックアップされます。

  • デフォルトのサービスアカウントトークン、シークレット、設定マップをマウントするボリューム。
  • hostPath volumes

オプトアウトメソッドを使用して、バックアップしない ボリュームを指定できます。これを行うには、backup.velero.io/backup-volumes-excludes コマンドを使用します。

手順

  • バックアップしないボリュームを 1 つ以上含む各 Pod で、次のコマンドを実行します。

    $ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \
      backup.velero.io/backup-volumes-excludes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>

    ここでは、以下のようになります。

    <your_volume_name_x>
    Pod 仕様の x 番目のボリュームの名前を指定します。
    注記

    --default-volumes-to-fs-backup フラグを指定して velero install コマンドを実行することで、すべての Velero バックアップに対してこの動作を有効にできます。

5.25.2.3. UID と GID の範囲

クラスター間でデータを移動する際に発生する可能性のあるユーザー ID(UID) とグループ ID(GID) の範囲の競合に対処します。これらの緩和策を見直すことで、アクセスに関する問題を回避し、復元後もセキュリティーコンテキストを維持することができます。

問題点のまとめ
宛先クラスターによっては、namespace の UID と GID の範囲が変更される場合があります。OADP は、OpenShift UID 範囲のメタデータをバックアップおよび復元しません。バックアップ対象のアプリケーションが特定の UID を必要とする場合は、復元時にその範囲が利用可能であることを確認してください。OpenShift の UID および GID の範囲に関する詳細は、OpenShift と UID に関するガイドを 参照してください。
問題の詳細

シェルコマンド oc create namespace を使用して OpenShift Container Platform で namespace を作成すると、OpenShift Container Platform は、使用可能な UID プールからの一意のユーザー ID (UID) 範囲、補助グループ (GID) 範囲、および一意の SELinux MCS ラベルを namespace に割り当てます。この情報は、クラスターの metadata.annotations フィールドに保存されます。この情報は、セキュリティーコンテキスト制約 (SCC) アノテーションの一部であり、次のコンポーネントで構成されています。

  • openshift.io/sa.scc.mcs
  • openshift.io/sa.scc.supplemental-groups
  • openshift.io/sa.scc.uid-range

OADP を使用して namespace を復元すると、宛先クラスターの情報をリセットせずに、metadata.annotations 内の情報が自動的に使用されます。その結果、次のいずれかに該当する場合、ワークロードはバックアップデータにアクセスできない可能性があります。

  • 他の SCC アノテーションを持つ既存の namespace が (たとえば別のクラスター上に) ある。この場合、OADP はバックアップ中に、復元する namespace ではなく既存の namespace を使用します。
  • バックアップ中にラベルセレクターが使用されたが、ワークロードが実行された namespace にそのラベルがない。この場合、OADP はその namespace をバックアップしませんが、バックアップされた namespace のアノテーションを含まない新しい namespace を復元中に作成します。これにより、新しい UID 範囲が namespace に割り当てられます。

    OpenShift Container Platform が、永続ボリュームデータのバックアップ後に変更された namespace アノテーションに基づいて Pod に securityContext UID を割り当てる場合、これはお客様のワークロードにとって問題になる可能性があります。

  • コンテナーの UID がファイル所有者の UID と一致しなくなった。
  • OpenShift Container Platform がバックアップクラスターデータと一致するように宛先クラスターの UID 範囲を変更していないため、エラーが発生する。その結果、バックアップクラスターは宛先クラスターとは異なる UID を持つことになり、アプリケーションは宛先クラスターに対してデータの読み取りまたは書き込みを行うことができなくなります。

    軽減策
    次の 1 つ以上の緩和策を使用して、UID 範囲および GID 範囲の問題を解決できます。
  • 簡単な緩和策:

    • Backup CR のラベルセレクターを使用して、バックアップに含めるオブジェクトをフィルター処理する場合は、必ずこのラベルセレクターをワークスペースを含む namespace に追加してください。
    • 同じ名前の namespace を復元する前に、宛先クラスター上の namespace の既存のバージョンを削除してください。
  • 高度な緩和策:

    • 移行後に 重複する UID 範囲を OpenShift 名前空間で解決することにより、移行後に UID 範囲 を修正します。ステップ 1 はオプションです。

OpenShift Container Platform における UID および GID の範囲について、あるクラスターでデータをバックアップし、別のクラスターに復元する際の問題の解決に重点を置いて詳細に解説した記事については、OpenShift と UID のガイドを 参照してください。

5.25.2.4. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する

あるクラスター上のデータを正常にバックアップし、別のクラスターに復元するために必要な前提条件と手順の違いを確認してください。これにより、標準的な OADP タスクをクラスター間データ復旧に対応させることができます。

前提条件

  • お使いのプラットフォーム (AWS、Microsoft Azure、Google Cloud など) でのバックアップと復元に関するすべての前提条件、特に Data Protection Application (DPA) の前提条件は、このガイドの関連セクションで説明されています。

手順

  1. お使いのプラットフォーム別の手順に加えて、次のステップを実行します。

    • リソースを別のクラスターに復元するには、Backup Store Location (BSL) と Volume Snapshot Location の名前とパスが同じであることを確認します。
    • 同じオブジェクトストレージの場所の認証情報をクラスター全体で共有します。
    • 最良の結果を得るには、OADP を使用して宛先クラスターに namespace を作成します。
    • Velero file-system-backup オプションを使用する場合は、次のコマンドを実行して、バックアップ中に使用する --default-volumes-to-fs-backup フラグを有効にします。

      $ velero backup create <backup_name> --default-volumes-to-fs-backup <any_other_options>
      注記

      OADP 1.2 以降では、Velero Restic オプションは file-system-backup と呼ばれます。

      重要

      CSI バックアップを復元する前に、VolumeSnapshotClass カスタムリソース (CR) を編集し、snapshot.storage.kubernetes.io/is-default-class パラメーターを false に設定してください。そうしないと、同じドライブのターゲットクラスターの VolumeSnapshotClass の値が同じであるため、復元が部分的に失敗します。

5.25.3. OADP ストレージクラスマッピング

OpenShift API for Data Protection を使用してストレージクラスをマッピングすることで、さまざまなデータタイプの保存方法に関するルールを定義できます。これにより、ストレージの割り当てを自動化し、バックアップおよび復元操作時のコストと効率を最適化できます。

5.25.3.1. ストレージクラスマッピング

ストレージクラスごとにルールを定義することで、さまざまなデータ型の保存方法を自動化できます。ストレージクラスをマッピングすることで、アクセス頻度とデータの重要度に基づいてストレージ効率を最適化し、コストを削減できます。

ストレージクラスマッピングを使用すると、さまざまな種類のデータにどのストレージクラスを適用するかを指定するルールまたはポリシーを定義できます。この機能は、アクセス頻度、データの重要性、コストの考慮事項に基づいて、ストレージクラスを決定するプロセスを自動化します。データがその特性と使用パターンに最適なストレージクラスに確実に保存されるようにすることで、ストレージの効率とコスト効率を最適化します。

change-storage-class-config フィールドを使用して、データオブジェクトのストレージクラスを変更できます。これにより、ニーズやアクセスパターンに応じて、標準ストレージからアーカイブストレージへなど、異なるストレージ層間でデータを移動することで、コストとパフォーマンスを最適化できます。

5.25.3.1.1. Migration Toolkit for Containers を使用したストレージクラスのマッピング

Migration Toolkit for Containers (MTC) を使用すると、アプリケーションデータを含むコンテナーを 1 つの OpenShift Container Platform クラスターから別のクラスターに移行したり、ストレージクラスのマッピングと変換を行うことができます。永続ボリューム (PV) のストレージクラスは、同じクラスター内で移行することで変換できます。これを行うには、MTC Web コンソールで移行計画を作成して実行する必要があります。

5.25.3.1.2. OADP を使用したストレージクラスマッピング

Velero 名前空間でストレージクラスマッピングを設定することにより、復元中に永続ボリューム (PV) のストレージクラスを変更できます。これにより、OADP を使用してアプリケーションを復元する際に、保存先をカスタマイズできます。

OADP を使用して ConfigMap をデプロイするには、change-storage-class-config フィールドを使用します。クラウドプロバイダーに基づいて、ストレージクラスマッピングを変更する必要があります。

手順

  1. 次のコマンドを実行して、ストレージクラスマッピングを変更します。

    $ cat change-storageclass.yaml
  2. 次の例に示すように、Velero namespace に config map を作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: change-storage-class-config
      namespace: openshift-adp
      labels:
        velero.io/plugin-config: ""
        velero.io/change-storage-class: RestoreItemAction
    data:
      standard-csi: ssd-csi

  3. 次のコマンドを実行して、ストレージクラスマッピング設定を保存します。

    $ oc create -f change-storage-class-config

5.26. OADP のトラブルシューティング

5.26.1. トラブルシューティング

Velero CLI、Webhook、must-gather カスタムリソースなどの診断ツールやその他の方法を使用して、OpenShift API for Data Protection (OADP) の問題をトラブルシューティングします。これは、バックアップおよび復元操作における問題を特定し、解決するのに役立ちます。

次の方法を使用して、OADP の問題をトラブルシューティングできます。

5.26.2. Velero CLI ツール

velero CLI ツールをダウンロードするか、クラスター内の velero バイナリーにアクセスして、カスタムリソース (CR) の バックアップ復元を デバッグし、ログを取得してください。これは、バックアップおよび復元操作の失敗に関するトラブルシューティングに役立ちます。

5.26.2.1. Velero CLI ツールのダウンロード

Velero のドキュメントページから Velero CLI ツールをダウンロードしてインストールしてください。macOS の場合は Homebrew と GitHub、Windows の場合は Chocolatey を使ったインストール手順が記載されています。これにより、バックアップおよびリストア操作のデバッグを行うための Velero CLI にアクセスできるようになります。

前提条件

  • DNS とコンテナーネットワークが有効になっている、v1.16 以降の Kubernetes クラスターにアクセスできる。
  • kubectl をローカルにインストールしている。

手順

  1. ブラウザーを開き、Velero Web サイト上の "Install the CLI" に移動します。
  2. macOS、GitHub、または Windows の適切な手順に従います。
  3. 使用している OADP および OpenShift Container Platform のバージョンに適切な Velero バージョンをダウンロードします。
5.26.2.1.1. OADP、Velero、および OpenShift Container Platform の各バージョンの関係

OADP、Velero、および OpenShift Container Platform 間のバージョン関係を確認し、互換性のあるバージョンの組み合わせを決定します。これにより、クラスター環境に適した OADP バージョンを選択できます。

Expand
OADP のバージョンVelero のバージョンOpenShift Container Platform バージョン

1.3.0

1.12

4.12-4.15

1.3.1

1.12

4.12-4.15

1.3.2

1.12

4.12-4.15

1.3.3

1.12

4.12-4.15

1.3.4

1.12

4.12-4.15

1.3.5

1.12

4.12-4.15

1.4.0

1.14

4.14-4.18

1.4.1

1.14

4.14-4.18

1.4.2

1.14

4.14-4.18

1.4.3

1.14

4.14-4.18

1.5.0

1.16

4.19

5.26.2.2. クラスター内の Velero デプロイメントで Velero バイナリーにアクセスする

シェルコマンドを使用して、クラスター内の Velero デプロイメントにある Velero バイナリーにアクセスします。

前提条件

  • DataProtectionApplication カスタムリソースのステータスが Reconcile complete である。

手順

  • 次のコマンドを使用して、必要なエイリアスを設定します。

    $ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
5.26.2.3. OpenShift CLI ツールを使用した Velero リソースのデバッグ

OpenShift CLI ツールを使用して Velero カスタムリソース (CR) と Velero Pod ログを確認することで、バックアップまたはリストアの失敗をデバッグします。

手順

  • 次の oc describe コマンドを使用して、Backup または Restore CR に関連する警告とエラーの概要を取得します。

    $ oc describe <velero_cr> <cr_name>
  • 次の oc logs コマンドを使用して、Velero Pod のログを取得します。

    $ oc logs pod/<velero>
  • 次の例に示すように、DataProtectionApplication リソースで Velero のログレベルを指定します。

    注記

    このオプションは、OADP 1.0.3 以降で使用できます。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: velero-sample
    spec:
      configuration:
        velero:
          logLevel: warning

    次の logLevel 値を使用できます。

    • trace
    • debug
    • info
    • warning
    • error
    • fatal
    • panic

      ほとんどのログには info logLevel 値を使用します。

5.26.2.4. Velero CLI ツールを使用した Velero リソースのデバッグ

Velero CLI ツールを使用して、カスタムリソース (CR) のデバッグ、バックアップ復元を 行い、ログを取得します。Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。

手順

  • oc exec コマンドを使用して、Velero CLI コマンドを実行します。

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      <backup_restore_cr> <command> <cr_name>

    oc exec コマンドの例

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

  • 次の velero --help オプションを使用して、すべての Velero CLI コマンドをリスト表示します。

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      --help
  • 次の velero logs コマンドを使用して、Backup または Restore CR のログを取得します。

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      <backup_restore_cr> logs <cr_name>

    velero logs コマンドの例

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

  • 次の velero describe コマンドを使用して、Backup または Restore CR に関連する警告とエラーの概要を取得します。

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      <backup_restore_cr> describe <cr_name>

    velero describe コマンドの例

    $ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \
      backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql

    次の種類の復元エラーと警告が、velero describe リクエストの出力に表示されます。

  • Velero: Velero 自体の操作に関連するメッセージのリスト (クラウドへの接続、バックアップファイルの読み取りなどに関連するメッセージなど)
  • Cluster: クラスタースコープのリソースのバックアップまたは復元に関連するメッセージのリスト
  • Namespaces: namespace に保存されているリソースのバックアップまたは復元に関連するメッセージのリスト

    これらのカテゴリーのいずれかで 1 つ以上のエラーが発生すると、Restore 操作のステータスが PartiallyFailed になり、Completed ではなくなります。警告によって完了ステータスが変化することはありません。

    これらの復元エラーは、次の点を考慮してください。

  • リソース固有のエラー、つまり Cluster および Namespaces エラーの場合、restore describe --details 出力には、Velero によって復元されたすべてのリソースを含むリソースリストが含まれています。このようなエラーが発生したリソースについて、そのリソースが実際にクラスター内にあるかどうかを確認してください。
  • リソース固有のエラー、つまり Cluster および Namespaces エラーの場合、restore describe --details 出力には、Velero によって復元されたすべてのリソースを含むリソースリストが含まれています。このようなエラーが発生したリソースについて、そのリソースが実際にクラスター内にあるかどうかを確認してください。
  • describe コマンドの出力に Velero エラーがあっても、リソース固有のエラーがない場合は、ワークロードの復元で実際に問題が発生することなく復元が完了した可能性があります。その場合は、復元後のアプリケーションを十分に検証してください。

    たとえば、出力に PodVolumeRestore またはノードエージェント関連のエラーが含まれている場合は、PodVolumeRestoresDataDownloads のステータスを確認します。これらのいずれも失敗しておらず、まだ実行中でもない場合は、ボリュームデータは完全に復元されている可能性があります。

5.26.3. メモリーまたは CPU の不足により Pod がクラッシュまたは再起動する

メモリーまたは CPU 不足が原因で発生する Velero または ResticPod のクラッシュを解決するには、DataProtectionApplication カスタムリソース (CR) でリソース要求を設定します。これにより、適切な CPU とメモリーのリソースを割り当てることができ、Pod の再起動を防ぎ、バックアップと復元操作の安定性を確保できます。

リソース要求フィールドの値が、Kubernetes のリソース要件と同じ形式になっていることを確認してください。

configuration.velero.podConfig.resourceAllocations または configuration.restic.podConfig.resourceAllocations を指定しない場合は、Velero または Restic Pod の次のデフォルトの resources 仕様の設定を参照してください。

requests:
  cpu: 500m
  memory: 128Mi
5.26.3.1. Velero Pod のリソースリクエストの設定

Velero Pod の特定のリソース要求を設定するには、oadp_v1alpha1_dpa.yaml ファイルの configuration.velero.podConfig.resourceAllocations 指定フィールドを使用します。

手順

  • CPUメモリーの リソース要求を、以下の例のように設定してください。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    configuration:
      velero:
        podConfig:
          resourceAllocations:
            requests:
              cpu: 200m
              memory: 256Mi

    リストされている resourceAllocations は、平均使用量です。

5.26.3.2. Restic Pod のリソースリクエストの設定

設定の configuration.restic.podConfig.resourceAllocations 指定フィールドを使用して、Restic Pod の特定のリソース要求を設定します。

注記

OADP 1.5.0 では、configuration.restic.podConfig.resourceAllocations 仕様フィールドが Data Protection Application (DPA) から削除されます。uploaderType フィールドが Restic ではなく Kopia に設定された nodeAgent セクションを使用します。

手順

  • CPUメモリーの リソース要求を、以下の例のように設定してください。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    ...
    configuration:
      restic:
        podConfig:
          resourceAllocations:
            requests:
              cpu: 1000m
              memory: 16Gi

    リストされている resourceAllocations は、平均使用量です。

5.26.3.3. nodeAgent Pod のリソース要求の設定

設定の configuration.nodeAgent.podConfig.resourceAllocations 指定フィールドを使用して、nodeAgent Pod の特定のリソース要求を設定します。

注記

OADP 1.5.0 では、configuration.restic.podConfig.resourceAllocations 仕様フィールドが Data Protection Application (DPA) から削除されます。uploaderType フィールドが Restic ではなく Kopia に設定された nodeAgent セクションを使用します。

手順

  1. YAML ファイルで cpu および memory リソース要求を設定します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
    spec:
      backupLocations:
      - velero:
          default: true
          objectStorage:
            bucket: oadp.....njph
            prefix: velero
          credential:
            key: cloud
            name: cloud-credentials-gcp
          provider: gcp
      configuration:
        velero:
          defaultPlugins:
          - gcp
          - openshift
          - csi
        nodeAgent:
          enable: true
          uploaderType: kopia
          podConfig:
            resourceAllocations:
              requests:
                cpu: 1000m
                memory: 16Gi

    ここでは、以下のようになります。

    resourceAllocations
    ここに示されているリソース割り当ての例は、平均的な使用状況を想定したものです。
    memory
    インフラストラクチャーや使用状況に応じて、このパラメーターを変更できます。
  2. 次のコマンドを実行して DPA CR を作成します。

    $ oc create -f nodeAgent.yaml

検証

  1. 次のコマンドを使用して、nodeAgent Pod が実行されていることを確認します。

    $ oc get pods

    出力例

    NAME                                                        READY   STATUS      RESTARTS   AGE
    node-agent-hbj9l                                            1/1     Running     0          97s
    node-agent-wmwgz                                            1/1     Running     0          95s
    node-agent-zvc7k                                            1/1     Running     0          98s
    openshift-adp-controller-manager-7f9db86d96-4lhgq           1/1     Running     0          137m
    velero-7b6c7fb8d7-ppc8m                                     1/1     Running     0          4m2s

  2. nodeAgent Pod のいずれかを記述して、リソース要求を確認します。

    $ oc describe pod node-agent-hbj9l | grep -C 5 Requests

    出力例

          --log-format=text
        State:          Running
          Started:      Mon, 09 Jun 2025 16:22:15 +0530
        Ready:          True
        Restart Count:  0
        Requests:
          cpu:     1
          memory:  1Gi
        Environment:
          NODE_NAME:            (v1:spec.nodeName)
          VELERO_NAMESPACE:    openshift-adp (v1:metadata.namespace)

5.26.4. アドミッション Webhook を使用する Velero バックアップの復元に関する回避策

Knative や IBM AppConnect リソースなどのワークロードに対して回避策を適用することで、アドミッション Webhook によって発生する復元失敗を解決します。これは、変更または検証を行うアドミッション Webhook を持つワークロードを正常に復元するのに役立ちます。

Velero では、復元中にアドミッション Webhook の問題を解決する機能が限られています。アドミッション Webhook を使用するワークロードがある場合は、追加の Velero プラグインを使用するか、ワークロードの復元方法を変更する必要がある場合があります。通常、アドミッション Webhook を使用するワークロードでは、最初に特定の種類のリソースを作成する必要があります。これはワークロードに子リソースがある場合に特に当てはまります。アドミッション Webhook は通常、子リソースをブロックするためです。

たとえば、service.serving.knative.dev などの最上位オブジェクトを作成または復元すると、通常、子リソースが自動的に作成されます。最初にこれを行う場合、Velero を使用してこれらのリソースを作成および復元する必要はありません。これにより、Velero が使用する可能性のあるアドミッション Webhook によって子リソースがブロックされるという問題が回避されます。

注記

Velero プラグインは個別のプロセスとして起動されます。Velero の操作は、成功したかどうかに関係なく完了すると終了します。デバッグログの received EOF, stopping recv loop メッセージは、プラグイン操作が完了したことを示します。エラーが発生したわけではありません。

5.26.4.1. Knative リソースの復元

Velero を使用して最上位の service.serving.knative.dev サービスリソースを復元することにより、アドミッション Webhook を使用する Knative リソースの復元に関する問題を解決します。これにより、Knative リソースがアドミッション Webhook エラーなしで正常に復元されることが保証されます。

手順

  • 以下のコマンドを使用して、最上位の サービスリソースである service.serving.knative.dev を復元します。

    $ velero restore <restore_name> \
      --from-backup=<backup_name> --include-resources \
      service.serving.knative.dev
5.26.4.2. IBM AppConnect リソースの復元

アドミッション Webhook を使用する IBM® AppConnect リソースにおける Velero リストアの失敗をトラブルシューティングします。復元を正常に完了するには、Webhook ルールを確認し、インストールされている Operator がバックアップのバージョンをサポートしていることを確認してください。

手順

  1. 次のコマンドを入力/実行して、クラスター内に kind: MutatingWebhookConfiguration の Mutating アドミッションプラグインがあるかどうかを確認します。

    $ oc get mutatingwebhookconfigurations
  2. kind: MutatingWebhookConfiguration の YAML ファイルを調べて、問題が発生しているオブジェクトの作成をブロックするルールがないことを確認します。詳細は、Kubernetes の公式ドキュメント を参照してください。
  3. バックアップ時に使用される type: Configuration.appconnect.ibm.com/v1beta1spec.version が、インストールされている Operator のサポート対象であることを確認してください。
5.26.4.3. Velero プラグインのパニックエラーの回避

イメージストリームの バックアップ中に発生する Velero プラグインのパニックエラーを解決するために、カスタムバックアップストレージロケーション (BSL) にラベルを付けます。これは、DataProtectionApplication (DPA) CR の外部で BSL を管理する場合に、OADP コントローラーが必要なレジストリーシークレットを作成することを保証するのに役立ちます。

シークレットが欠落していると、イメージストリームのバックアップ中に Velero プラグインでパニックエラーが発生する可能性があります。バックアップと BSL が DPA の範囲外で管理されている場合、OADP コントローラーは関連する oadp-<bsl_name>-<bsl_provider>-registry-secret パラメーターを作成しません。

バックアップ操作中に、OpenShift Velero プラグインが imagestream バックアップでパニックになり、次のパニックエラーが発生します。

024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item"
backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io,
namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked:
runtime error: index out of range with length 1, stack trace: goroutine 94…

手順

  1. 次のコマンドを使用して、カスタムの BSL に適切なラベルを付けます。

    $ oc label backupstoragelocations.velero.io <bsl_name> app.kubernetes.io/component=bsl
  2. BSL にラベルを付けた後、DPA がリコンサイルされるまで待ちます。

    注記

    DPA 自体に軽微な変更を加えることで、強制的に調整を行うことができます。

検証

  • DPA がリコンサイルされたら、次のコマンドを入力して、パラメーターが作成され、正しいレジストリーデータがそこに入力されていることを確認します。

    $ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
5.26.4.4. OpenShift ADP コントローラーのセグメンテーション違反の回避策

Data Protection Application (DPA) の設定で、velero または cloudstorage の いずれかを定義して、Pod の無期限クラッシュを防いでください。この設定により、両方のコンポーネントが有効になっている場合に発生する 、openshift-adp-controller-manager Pod 内のセグメンテーション違反が解消されます。

openshift-adp-controller-manager Pod は、以下の設定が原因でクラッシュループセグメンテーション違反により失敗します。

  • velerocloudstorage を両方とも定義すると、openshift-adp-controller-manager は失敗します。
  • velerocloudstorage を両方とも定義しないと、openshift-adp-controller-manager は失敗します。

詳細は、OADP-1054 を参照してください。

5.26.5. OADP インストールの問題

Data Protection Application (DPA) のインストールに関する一般的な問題 (無効なバックアップストレージディレクトリーや、クラウドプロバイダーの認証情報の誤りなど) を解決します。これは、お使いの環境に OADP を正常にインストールおよび設定するのに役立ちます。

5.26.5.1. バックアップストレージ内の無効なディレクトリーの解決

オブジェクトストレージに Velero 以外のディレクトリーが含まれている場合に発生する バックアップストレージに無効なトップレベルディレクトリーが含まれています エラーを解決します。これは、共有オブジェクトストレージの正しいバケットプレフィックスを設定するのに役立ちます。

手順

  • オブジェクトストレージが Velero 専用でない場合は、DataProtectionApplication マニフェストで spec.backupLocations.velero.objectStorage.prefix パラメーターを設定して、バケットの接頭辞を指定する必要があります。
5.26.5.2. 誤った AWS 認証情報の解決

credentials-velero ファイルのフォーマットが正しくない場合に発生する、InvalidAccessKeyIdNoCredentialProviders などの認証情報エラーを解決します。これは、OADP バックアップ操作に必要な有効な AWS 認証情報を設定するのに役立ちます。

Secret オブジェクトの作成に使用する credentials-velero ファイルのフォーマットが間違っている場合、以下のような複数のエラーが発生する可能性があります。

  • oadp-aws-registry Pod のログに次のエラーメッセージが表示されます。

    `InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.`
  • Velero Pod のログに次のエラーメッセージが表示されます。

    NoCredentialProviders: no valid providers in chain.

手順

  • 次の例に示すように、credentials-velero ファイルの形式が正しいことを確認します。

    [default]
    aws_access_key_id=AKIAIOSFODNN7EXAMPLE
    aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

    ここでは、以下のようになります。

    [default]
    AWS のデフォルトプロファイルを指定します。
    aws_access_key_id
    値を引用符 ("') で囲まないでください。

5.26.6. OADP Operator の問題

OpenShift API for Data Protection (OADP) Operator に関する問題 (正常な動作を妨げるサイレントエラーなど) を解決します。これにより、Operator の正常な機能を復元し、バックアップおよび復元操作を確実に成功させることができます。

5.26.6.1. OADP Operator のサイレント障害の解決

OADPOperator が 実行中 ステータスを報告しているにもかかわらず、クラウド認証情報の権限設定が誤っているために AWS S3 バケットが空のままになるという、サイレントエラーの問題を解決します。これは、バックアップ保存場所における認証情報のアクセス許可の問題を特定し、解決するのに役立ちます。

この問題を解決するには、Backup Storage Location (BSL) のリストを取得し、各 BSL のマニフェストで認証情報の問題を確認します。

手順

  1. OpenShift または Velero コマンドラインインターフェイス (CLI) を使用して、BSL のリストを取得します。

    1. OpenShift CLI (oc) を使用して BSL のリストを取得します。

      $ oc get backupstoragelocations.velero.io -A
    2. velero CLI を使用して BSL のリストを取得します。

      $ velero backup-location get -n <oadp_operator_namespace>
  2. 前のステップの BSL のリストを使用して、次のコマンドを実行し、各 BSL のマニフェストにエラーがないか調べます。

    $ oc get backupstoragelocations.velero.io -n <namespace> -o yaml
    apiVersion: v1
    items:
    - apiVersion: velero.io/v1
      kind: BackupStorageLocation
      metadata:
        creationTimestamp: "2023-11-03T19:49:04Z"
        generation: 9703
        name: example-dpa-1
        namespace: openshift-adp-operator
        ownerReferences:
        - apiVersion: oadp.openshift.io/v1alpha1
          blockOwnerDeletion: true
          controller: true
          kind: DataProtectionApplication
          name: example-dpa
          uid: 0beeeaff-0287-4f32-bcb1-2e3c921b6e82
        resourceVersion: "24273698"
        uid: ba37cd15-cf17-4f7d-bf03-8af8655cea83
      spec:
        config:
          enableSharedConfig: "true"
          region: us-west-2
        credential:
          key: credentials
          name: cloud-credentials
        default: true
        objectStorage:
          bucket: example-oadp-operator
          prefix: example
        provider: aws
      status:
        lastValidationTime: "2023-11-10T22:06:46Z"
        message: "BackupStorageLocation \"example-dpa-1\" is unavailable: rpc
          error: code = Unknown desc = WebIdentityErr: failed to retrieve credentials\ncaused
          by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus
          code: 403, request id: d3f2e099-70a0-467b-997e-ff62345e3b54"
        phase: Unavailable
    kind: List
    metadata:
      resourceVersion: ""

5.26.7. OADP タイムアウト

Restic、Velero、Data Mover、CSI スナップショット、およびアイテム操作の OADP タイムアウトパラメーターを設定することで、複雑な処理やリソースを大量に消費する処理が正常に完了するようにします。これにより、バックアップおよび復元操作の早期終了によって発生するエラー、再試行、および障害を減らすことができます。

過度に長いタイムアウトを設定しないように、論理的な方法でタイムアウト延長のバランスをとってください。過度に長いと、プロセス内の根本的な問題が隠れる可能性があります。プロセスのニーズとシステム全体のパフォーマンスに応じて適切なタイムアウト値を検討および監視してください。

以下の OADP タイムアウトに関する手順を確認してください。

5.26.7.1. Restic タイムアウトの実装

Restic のタイムアウトパラメーターを設定することで、大容量の永続ボリュームや長時間実行されるバックアップ操作におけるバックアップの失敗を防ぐことができます。これにより、500GB を超えるデータをバックアップする場合や、バックアップ時間がデフォルトの 1 時間制限を超える場合に発生するタイムアウトエラーを回避できます。

Restic のタイムアウトを設定するには、spec.configuration.nodeAgent.timeout パラメーターを使用します。デフォルト値は 1h です。

次に該当する場合は、nodeAgent セクションで Restic timeout パラメーターを使用してください。

  • PV データの使用量の合計が 500GB を超える Restic バックアップの場合。
  • バックアップが次のエラーでタイムアウトになる場合:

    level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"

手順

  • DataProtectionApplication カスタムリソース (CR) マニフェストの spec.configuration.nodeAgent.timeout ブロックの値を編集します。次に例を示します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
          timeout: 1h
    # ...
5.26.7.2. Velero リソースタイムアウトの実装

DataProtectionApplication カスタムリソース (CR) の resourceTimeout パラメーターを設定して、Velero がリソースの可用性を待つ時間を定義します。このタイムアウト値を調整することで、大規模なバックアップ、リポジトリーの準備状況チェック、および復元操作中に発生するエラーを防ぐことができます。

resourceTimeout は次の場合に使用してください。

  • PV データの合計使用量が 1 TB を超えるバックアップの場合。このパラメーターを、Velero がバックアップ完了とマークする前に、Container Storage Interface (CSI) スナップショットのクリーンアップまたは削除を試みる際のタイムアウト値として使用します。

    • このクリーンアップのサブタスクが VSC のパッチ適用を試行します。このタイムアウトはそのタスクに使用できます。
  • Restic または Kopia のファイルシステムベースのバックアップのバックアップリポジトリーを作成または準備できるようにするため。
  • カスタムリソース (CR) またはバックアップからリソースを復元する前に、クラスター内で Velero CRD が利用可能かどうかを確認します。

手順

  • 次の例に示すように、DataProtectionApplication CR マニフェストの spec.configuration.velero.resourceTimeout ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        velero:
          resourceTimeout: 10m
    # ...
5.26.7.2.1. Velero のデフォルトアイテム操作タイムアウトの実装

`DataProtectionApplication`カスタムリソース (CR) の defaultItemOperationTimeout パラメーターを設定して、Velero がバックアップおよびリストア操作の完了を待つ時間を定義します。このタイムアウト値を調整することで、Container Storage Interface (CSI) データムーバーのタスク中に発生するエラーを防ぐことができます。

デフォルト値は 1h です。

以下のシナリオでは、defaultItemOperationTimeout を使用します。

  • Data Mover 1.2.x のみ。
  • defaultItemOperationTimeout が、defaultItemOperationTimeout を使用して Data Protection Application (DPA) に定義されている場合、バックアップおよび復元操作の両方に適用されます。itemOperationTimeout では、以下の "Item operation timeout - restore" セクションおよび "Item operation timeout - backup" セクションで説明されているように、バックアップのみを定義するか、これらの CR の復元のみを定義できます。

手順

  • 次の例に示すように、DataProtectionApplication CR マニフェストの spec.configuration.velero.defaultItemOperationTimeout ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      configuration:
        velero:
          defaultItemOperationTimeout: 1h
    # ...
5.26.7.3. Data Mover タイムアウトの実装

バックアップおよびリストア操作の実行時間を定義するには、DataProtectionApplication カスタムリソース (CR) でデータムーバーの タイムアウト パラメーターを設定します。この値を調整することで、500GB を超える大規模環境や VolumeSnapshotMover プラグイン使用時のタイムアウトを防ぐことができます。デフォルト値は 10m です。

次のシナリオでは、Data Mover timeout を使用します。

  • VolumeSnapshotBackups (VSB) および VolumeSnapshotRestores (VSR) を作成する場合は、10 分後にタイムアウトします。
  • 合計 PV データ使用量が 500GB を超える大規模環境向け。1h のタイムアウトを設定します。
  • VolumeSnapshotMover (VSM) プラグインを使用します。

手順

  • 次の例に示すように、DataProtectionApplication CR マニフェストの spec.features.dataMover.timeout ブロックの値を編集します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
     name: <dpa_name>
    spec:
      features:
        dataMover:
          timeout: 10m
    # ...
5.26.7.4. CSI スナップショットタイムアウトの実装

バックアップ カスタムリソース (CR) の CSISnapshotTimeout パラメーターを設定して、CSI スナップショットが準備完了になるまで待機する時間を定義します。このタイムアウト値を調整することで、より多くの時間を要する大容量ストレージボリュームのスナップショットを CSI プラグインを使用して取得する際に発生するエラーを防ぐことができます。デフォルト値は 10m です。

注記

通常、CSISnapshotTimeout のデフォルト値は、デフォルト設定で大規模なストレージボリュームに対応できるため、調整する必要はありません。

手順

  • 次の例に示すように、Backup CR マニフェストの spec.csiSnapshotTimeout ブロックの値を編集します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
     name: <backup_name>
    spec:
     csiSnapshotTimeout: 10m
    # ...
5.26.7.5. アイテム操作タイムアウトの実装 - 復元

リストア カスタムリソース (CR) の ItemOperationTimeout パラメーターを設定して、リストア操作が完了するまで待機する時間を定義します。このタイムアウト値を調整することで、データムーバーが大容量のストレージデータをダウンロードするのに時間がかかる場合に発生する障害を防ぐことができます。デフォルト値は 1h です。

手順

  • 次の例に示すように、Restore CR マニフェストの Restore.spec.itemOperationTimeout ブロックの値を編集します。

    apiVersion: velero.io/v1
    kind: Restore
    metadata:
     name: <restore_name>
    spec:
     itemOperationTimeout: 1h
    # ...
5.26.7.6. アイテム操作タイムアウトの実装 - バックアップ

バックアップ カスタムリソース (CR) の ItemOperationTimeout パラメーターを設定して、非同期の BackupItemAction 操作が完了するまで待機する時間を定義します。このタイムアウト値を調整することで、データムーバーが大容量のストレージデータをアップロードするのに時間がかかる場合に発生する障害を防ぐことができます。デフォルト値は 1h です。

手順

  • 次の例に示すように、Backup CR マニフェストの Backup.spec.itemOperationTimeout ブロックの値を編集します。

    apiVersion: velero.io/v1
    kind: Backup
    metadata:
     name: <backup_name>
    spec:
     itemOperationTimeout: 1h
    # ...

5.26.8. バックアップおよび復元 CR の問題

ボリュームの取得失敗、バックアップが進行中または部分的に失敗した状態のままになるなど、バックアップ および 復元 カスタムリソース (CR) に関する一般的な問題を解決します。これは、OADP におけるバックアップおよびリストア操作の成功を確実にするのに役立ちます。

5.26.8.1. Backup CR がボリュームを取得できない問題のトラブルシューティング

永続ボリューム (PV) とスナップショットの場所が異なるリージョンにある場合に発生する InvalidVolume.NotFound エラーを解決します。これにより、バックアップ CR がボリュームを正常に取得できることを確認できます。

PV とスナップショットの場所が異なるリージョンにある場合、バックアップ カスタムリソース (CR) は次のエラーメッセージを表示します。

InvalidVolume.NotFound: The volume vol-xxxx does not exist.

手順

  1. DataProtectionApplication マニフェストの spec.snapshotLocations.velero.config.region キーの値を編集して、スナップショットの場所が PV と同じリージョンにあるようにします。
  2. 新しい Backup CR を作成します。
5.26.8.2. Backup CR のステータスが進行中のままになる問題のトラブルシューティング

バックアップが中断された結果、バックアップ CR のステータスが 進行中 のままになる問題を解決します。これにより、停止しているバックアップを削除し、新しいバックアップを作成して、バックアップ操作を完了できます。

手順

  1. 次のコマンドを実行して、Backup CR の詳細を取得します。

    $ oc -n {namespace} exec deployment/velero -c velero -- ./velero \
      backup describe <backup>
  2. 次のコマンドを実行して、Backup CR を削除します。

    $ oc delete backups.velero.io <backup> -n openshift-adp

    進行中の Backup CR によるオブジェクトストレージへのファイルアップロードは完了していないため、バックアップの場所をクリーンアップする必要はありません。

  3. 新しい Backup CR を作成します。
  4. 次のコマンドを実行して、Velero バックアップの詳細を表示します。

    $ velero backup describe <backup_name> --details
5.26.8.3. Backup CR のステータスが部分的に失敗のままになる問題のトラブルシューティング

VolumeSnapshotClass にラベルが欠落しているために Backup CR が CSI スナップショットを作成できない場合に発生する PartiallyFailed ステータスを解決します。これは、スナップショットクラスに適切なラベルを付けることで、バックアップの成功率を高めるのに役立ちます。

CSI スナップショットクラスに基づいて作成されたバックアップにラベルがない場合、CSI スナップショットプラグインがスナップショットの作成に失敗します。その結果、Velero Pod が次のメッセージに類似したエラーをログに記録します。

time="2023-02-17T16:33:13Z" level=error msg="Error backing up item" backup=openshift-adp/user1-backup-check5 error="error executing custom action (groupResource=persistentvolumeclaims, namespace=busy1, name=pvc1-user1): rpc error: code = Unknown desc = failed to get volumesnapshotclass for storageclass ocs-storagecluster-ceph-rbd: failed to get volumesnapshotclass for provisioner openshift-storage.rbd.csi.ceph.com, ensure that the desired volumesnapshot class has the velero.io/csi-volumesnapshot-class label" logSource="/remote-source/velero/app/pkg/backup/backup.go:417" name=busybox-79799557b5-vprq

手順

  1. 次のコマンドを実行して Backup CR を削除します。

    $ oc delete backups.velero.io <backup> -n openshift-adp
  2. 必要に応じて、BackupStorageLocation リソースに保存されているデータをクリーンアップして、領域を解放します。
  3. 次のコマンドを実行して、velero.io/csi-volumesnapshot-class=true ラベルを VolumeSnapshotClass オブジェクトに適用します。

    $ oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true
  4. 新しい Backup CR を作成します。

5.26.9. Restic の問題

アプリケーションのバックアップおよび復元中に発生する一般的な Restic の問題をトラブルシューティングし、信頼性の高いデータ保護を維持します。Restic でよく発生する問題としては、NFS のアクセス許可エラー、バックアップ時のカスタムリソースの再作成失敗、Pod のセキュリティーアクセスポリシーの変更による復元失敗などが挙げられます。

5.26.9.1. NFS データボリュームの Restic 権限エラーのトラブルシューティング

補助グループを作成し、そのグループ ID を DataProtectionApplication お客様リソース CR に追加することで、root_squash が有効になっている NFS データボリューム上の Restic 権限エラーを解決します。これにより、ルートスクワッシュを無効にすることなく、NFS ボリュームのバックアップ機能を復元できます。

NFS データボリュームで root_squash パラメーターが有効になっており、Restic マップが nfsnobody 値に設定されていて、バックアップを作成する権限がない場合、Restic Pod ログに次のエラーメッセージが表示されます。

controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied".

手順

  1. NFS データボリューム上に Restic の補足グループを作成します。
  2. NFS ディレクトリーに setgid ビットを設定して、グループの所有権が継承されるようにします。
  3. spec.configuration.nodeAgent.supplementalGroups パラメーターとグループ ID を DataProtectionApplication マニフェストに追加します。次に例を示します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    # ...
    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
          supplementalGroups:
          - <group_id>
    # ...

    ここでは、以下のようになります。

    < グループ ID>
    補助グループ ID を指定します。
  4. Restic Pod が再起動し、変更が適用されるまで待機します。

オブジェクトストレージバケットを空にした後に発生する、バックアップ カスタムリソース (CR) の再作成エラーを解決します。このエラーは、Velero が ResticRepository マニフェストから Restic リポジトリーを自動的に再作成しないために発生します。

詳細は、Velero issue 4421 を参照してください。

Velero Pod のログに以下のエラーメッセージが表示されます。

stderr=Fatal: unable to open config file: Stat: The specified key does not exist.\nIs there a repository at the following location?

手順

  • 次のコマンドを実行して、関連する Restic リポジトリーを namespace から削除します。

    $ oc delete resticrepository openshift-adp <name_of_the_restic_repository>

    次のエラーログでは、mysql-persistent が問題のある Restic リポジトリーです。リポジトリー名は、分かりやすくするために斜体で表示されています。

     time="2021-12-29T18:29:14Z" level=info msg="1 errors
     encountered backup up item" backup=velero/backup65
     logSource="pkg/backup/backup.go:431" name=mysql-7d99fc949-qbkds
     time="2021-12-29T18:29:14Z" level=error msg="Error backing up item"
     backup=velero/backup65 error="pod volume backup failed: error running
     restic backup, stderr=Fatal: unable to open config file: Stat: The
     specified key does not exist.\nIs there a repository at the following
     location?\ns3:http://minio-minio.apps.mayap-oadp-
     veleo-1234.qe.devcluster.openshift.com/mayapvelerooadp2/velero1/
     restic/mysql-persistent\n: exit status 1" error.file="/remote-source/
     src/github.com/vmware-tanzu/velero/pkg/restic/backupper.go:184"
     error.function="github.com/vmware-tanzu/velero/
     pkg/restic.(*backupper).BackupPodVolumes"
     logSource="pkg/backup/backup.go:435" name=mysql-7d99fc949-qbkds

OpenShift Container Platform 4.14 以降で、Pod Security Admission (PSA) ポリシーの適用によって発生する Restic リストアの部分的な失敗を解決するには、DataProtectionApplication (DPA) カスタムリソース (CR) の restore-resource-priorities フィールドを調整します。そうすることで、SecurityContextConstraints (SCC) リソースが Pod より先に復元されることが保証されます。これは、Velero リソースの復元命令が原因で PSA ポリシーが Pod の受け入れを拒否した場合でも、復元操作を正常に完了するのに役立ちます。

OpenShift Container Platform はバージョン 4.14 以降、Restic リストア処理中に Pod の準備状態を妨げる可能性のある PSA ポリシーを適用します。Pod 作成時に SCC リソースが見つからず、かつ Pod 上の PSA ポリシーが要求される基準を満たすように設定されていない場合、Pod の受け入れは拒否されます。

以下のエラー例を確認してください。

\"level=error\" in line#2273: time=\"2023-06-12T06:50:04Z\"
level=error msg=\"error restoring mysql-869f9f44f6-tp5lv: pods\\\
"mysql-869f9f44f6-tp5lv\\\" is forbidden: violates PodSecurity\\\
"restricted:v1.24\\\": privil eged (container \\\"mysql\\\
" must not set securityContext.privileged=true),
allowPrivilegeEscalation != false (containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.capabilities.drop=[\\\"ALL\\\"]), seccompProfile (pod or containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.seccompProfile.type to \\\
"RuntimeDefault\\\" or \\\"Localhost\\\")\" logSource=\"/remote-source/velero/app/pkg/restore/restore.go:1388\" restore=openshift-adp/todolist-backup-0780518c-08ed-11ee-805c-0a580a80e92c\n
velero container contains \"level=error\" in line#2447: time=\"2023-06-12T06:50:05Z\"
level=error msg=\"Namespace todolist-mariadb,
resource restore error: error restoring pods/todolist-mariadb/mysql-869f9f44f6-tp5lv: pods \\\
"mysql-869f9f44f6-tp5lv\\\" is forbidden: violates PodSecurity \\\"restricted:v1.24\\\": privileged (container \\\
"mysql\\\" must not set securityContext.privileged=true),
allowPrivilegeEscalation != false (containers \\\
"restic-wait\\\",\\\"mysql\\\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.capabilities.drop=[\\\"ALL\\\"]), seccompProfile (pod or containers \\\
"restic-wait\\\", \\\"mysql\\\" must set securityContext.seccompProfile.type to \\\
"RuntimeDefault\\\" or \\\"Localhost\\\")\"
logSource=\"/remote-source/velero/app/pkg/controller/restore_controller.go:510\"
restore=openshift-adp/todolist-backup-0780518c-08ed-11ee-805c-0a580a80e92c\n]",

手順

  1. DPA カスタムリソース (CR) で、Velero サーバーの restore-resource-priorities フィールドを確認または設定して、securitycontextconstraints がリソースのリストの pods の前に順番にリストされていることを確認します。

    $ oc get dpa -o yaml
    # ...
    configuration:
      restic:
        enable: true
      velero:
        args:
          restore-resource-priorities: 'securitycontextconstraints,customresourcedefinitions,namespaces,storageclasses,volumesnapshotclass.snapshot.storage.k8s.io,volumesnapshotcontents.snapshot.storage.k8s.io,volumesnapshots.snapshot.storage.k8s.io,datauploads.velero.io,persistentvolumes,persistentvolumeclaims,serviceaccounts,secrets,configmaps,limitranges,pods,replicasets.apps,clusterclasses.cluster.x-k8s.io,endpoints,services,-,clusterbootstraps.run.tanzu.vmware.com,clusters.cluster.x-k8s.io,clusterresourcesets.addons.cluster.x-k8s.io'
        defaultPlugins:
        - gcp
        - openshift

    ここでは、以下のようになります。

    リソースの優先順位を復元する
    既存のリストアリソース優先順位リストがある場合は、その既存のリストを完全なリストと組み合わせてください。
  2. デプロイメントの警告が発生しないように、Fixing PodSecurity Admission warnings for deployments で説明されているように、アプリケーション Pod のセキュリティー標準が調整されていることを確認します。アプリケーションがセキュリティー標準に準拠していない場合は、SCC に関係なくエラーが発生する可能性があります。 

    注記

    この解決策は一時的なものであり、現在、この問題に対処するための協議が進行中です。

5.26.10. OADP データ保護テスト

DataProtectionTest (DPT) カスタムリソース (CR) を使用して、OADP 設定を検証します。これにより、バックアップを実行する前に、データ保護環境が適切に設定され、要件どおりに動作していることを確認できます。

DPT は、オブジェクトストレージへのバックアップのアップロードパフォーマンス、永続ボリューム要求のための CSI スナップショットの準備状況、および暗号化やバージョン管理などのストレージバケット設定をチェックします。

5.26.10.1. OADP DataProtectionTest CR 仕様フィールド

DataProtectionTest (DPT) カスタムリソース (CR) で使用可能な仕様フィールドを確認し、バックアップ場所、アップロード速度テスト、CSI ボリュームスナップショットテスト、その他のオプションを設定してください。これにより、DPT CR をカスタマイズして、お客様固有の OADP 設定要件を検証することができます。

Expand
表5.21 DPT CR 仕様フィールド
フィールド説明

backupLocationName

string

DataProtectionApplication (DPA) CR で設定された BackupStorageLocation CR の名前。

backupLocationSpec

object

BackupStorageLocation CR のインライン仕様。

uploadSpeedTestConfig

object

オブジェクトストレージへのアップロード速度テストを実行するための設定。

csiVolumeSnapshotTestConfigs

list

スナップショットを取得し、スナップショットの準備状態を確認するための永続ボリューム要求のリスト。

forceRun

boolean

ステータスが Complete または Failed の場合でも、DPT CR を再実行します。

skipTLSVerify

boolean

true に設定すると、TLS 証明書の検証がバイパスされます。

5.26.10.2. OADP DataProtectionTest CR ステータスフィールド

DataProtectionTest (DPT) カスタムリソース (CR) のステータスフィールドを確認して、テストの進行状況、アップロード速度の結果、バケットのメタデータ、およびスナップショットのテスト結果を監視してください。これは、DPT CR の結果を解釈し、OADP 設定に関する問題を特定するのに役立ちます。

Expand
表5.22 DPT CR ステータスフィールド
フィールド説明

phase

string

DPT CR の現在のフェーズ。値は InProgressComplete、または Failed を使用できます。

lastTested

タイムスタンプ

DPT CR が最後に実行されたときのタイムスタンプ。

uploadTest

object

アップロード速度テストの結果。

bucketMetadata

object

ストレージバケットの暗号化とバージョン管理に関する情報。

snapshotTests

list

各永続ボリューム要求のスナップショットテストの結果。

snapshotSummary

string

スナップショットの合格/不合格をまとめた結果たとえば、2/2 passed などです。

s3Vendor

string

AWS S3 互換のストレージバケットベンダー。たとえば、AWS、MinIO、Ceph などです。

errorMessage

string

DPT CR が失敗した場合のエラーメッセージ。

5.26.10.3. DataProtectionTest カスタムリソースの使用

DataProtectionTest (DPT) カスタムリソース (CR) を設定して実行し、Container Storage Interface (CSI) スナップショットの準備状況と、ストレージバケットへのデータアップロードのパフォーマンスを確認します。これは、バックアップおよびリストア操作を実行する前に、OADP 環境を検証するのに役立ちます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。
  • OADP Operator がインストールされている。
  • DataProtectionApplication (DPA) CR が作成されている。
  • バックアップを保存するバックアップ保存場所 (BSL) を設定した。
  • 別の namespace で実行されている永続ボリューム要求 (PVC) を持つアプリケーションがある。

手順

  1. 例に示すように、DPT CR のマニフェストファイルを作成します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionTest
    metadata:
      name: dpt-sample
      namespace: openshift-adp
    spec:
      backupLocationName: <bsl_name>
      csiVolumeSnapshotTestConfigs:
      - snapshotClassName: csi-gce-pd-vsc
        timeout: 90s
        volumeSnapshotSource:
          persistentVolumeClaimName: <pvc1_name>
          persistentVolumeClaimNamespace: <pvc_namespace>
      - snapshotClassName: csi-gce-pd-vsc
        timeout: 120s
        volumeSnapshotSource:
          persistentVolumeClaimName: <pvc2_name>
          persistentVolumeClaimNamespace: <pvc_namespace>
      forceRun: false
      uploadSpeedTestConfig:
        fileSize: 200MB
        timeout: 120s

    ここでは、以下のようになります。

    <bsl_name>
    BSL の名前を指定します。
    csiVolumeSnapshotTestConfigs
    csiVolumeSnapshotTestConfigs のリストを指定します。この例では、2 つの PVC がテストされています。
    <pvc1_name>
    最初の PVC の名前を指定します。
    <pvc_namespace>
    PVC のネームスペースを指定します。
    <pvc2_name>
    2 番目の PVC の名前を指定します。
    forceRun
    OADP コントローラーにテストの再実行をスキップさせたい場合は、false に設定してください。
    uploadSpeedTestConfig
    ファイルサイズタイムアウトの フィールドを設定することで、アップロード速度テストを設定します。
  2. 次のコマンドを実行して DPT CR を作成します。

    $ oc create -f <dpt_file_name>

    <dpt_file_name> を DPT マニフェストのファイル名に置き換えてください。

検証

  1. 次のコマンドを実行して、DPT CR のフェーズが Complete であることを確認します。

    $ oc get dpt dpt-sample

    出力例は次のとおりです。

    NAME         PHASE      LASTTESTED   UPLOADSPEED(MBPS)   ENCRYPTION   VERSIONING   SNAPSHOTS    AGE
    dpt-sample   Complete   17m          546                 AES256       Enabled      2/2 passed   17m
  2. 次のコマンドを実行して、CSI スナップショットが準備され、データアップロードテストが成功したことを確認します。

    $ oc get dpt dpt-sample -o yaml

    出力例は次のとおりです。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionTest
    ....
    status:
      bucketMetadata:
        encryptionAlgorithm: AES256
        versioningStatus: Enabled
      lastTested: "202...:47:51Z"
      phase: Complete
      s3Vendor: AWS
      snapshotSummary: 2/2 passed
      snapshotTests:
      - persistentVolumeClaimName: mysql-data
        persistentVolumeClaimNamespace: ocp-mysql
        readyDuration: 24s
        status: Ready
      - persistentVolumeClaimName: mysql-data1
        persistentVolumeClaimNamespace: ocp-mysql
        readyDuration: 40s
        status: Ready
      uploadTest:
        duration: 3.071s
        speedMbps: 546
        success: true

    ここでは、以下のようになります。

    bucketMetadata
    バケットのメタデータ情報を指定します。
    s3Vendor
    S3 バケットのベンダーを指定します。
    snapshotSummary
    CSI スナップショットテストの概要を指定します。
    uploadTest
    アップロードテストの詳細を指定します。
5.26.10.4. バックアップ保存場所の仕様を設定してデータ保護テストを実行する

既存の BSL 名を参照する代わりに、インラインのバックアップストレージロケーション (BSL) 指定を指定して、DataProtectionTest (DPT) カスタムリソース (CR) を設定および実行します。これにより、別途 BSL リソースを作成することなく、データアップロードのパフォーマンスと CSI スナップショットの準備状況をテストできます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。
  • OADP Operator がインストールされている。
  • DataProtectionApplication (DPA) CR が作成されている。
  • バックアップを保存するためのバケットが設定されている。
  • バケットストレージにアクセスするための Secret オブジェクトが作成されている。
  • 別の namespace で実行されている永続ボリューム要求 (PVC) を持つアプリケーションがある。

手順

  1. 例に示すように、DPT CR のマニフェストファイルを作成します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionTest
    metadata:
      name: dpt-sample
      namespace: openshift-adp
    spec:
      backupLocationSpec:
        provider: aws
        default: true
        objectStorage:
          bucket: sample-bucket
          prefix: velero
        config:
          region: us-east-1
          profile: "default"
          insecureSkipTLSVerify: "true"
          s3Url: "https://s3.amazonaws.com/sample-bucket"
        credential:
          name: cloud-credentials
          key: cloud
      uploadSpeedTestConfig:
        fileSize: 50MB
        timeout: 120s
      csiVolumeSnapshotTestConfigs:
        - volumeSnapshotSource:
            persistentVolumeClaimName: mongo
            persistentVolumeClaimNamespace: mongo-persistent
          snapshotClassName: csi-snapclass
          timeout: 2m
      forceRun: true
      skipTLSVerify: true

    ここでは、以下のようになります。

    backupLocationSpec
    クラウドプロバイダーなどの詳細を指定することで、BSL 仕様を設定します。
    サンプルバケット
    バケット名を指定します。この例では、バケット名は sample-bucket です。
    us-east-1
    クラウドプロバイダーのリージョンを指定します。
    credential
    ストレージバケットのクラウド認証情報を指定します。
    uploadSpeedTestConfig
    (オプション) ファイルサイズタイムアウトの フィールドを設定することで、アップロード速度テストを設定します。
    csiVolumeSnapshotTestConfigs
    CSI ボリュームスナップショットテストを設定します。
    skipTLSVerify
    DPT CR 実行中に TLS 証明書の検証をスキップするには、true に設定します。
  2. 次のコマンドを実行して DPT CR を作成します。

    $ oc create -f <dpt_file_name>

    <dpt_file_name> を DPT マニフェストのファイル名に置き換えてください。

検証

  1. 次のコマンドを実行して、DPT CR のフェーズが Complete であることを確認します。

    $ oc get dpt dpt-sample

    出力例は次のとおりです。

    NAME         PHASE      LASTTESTED   UPLOADSPEED(MBPS)   ENCRYPTION   VERSIONING   SNAPSHOTS    AGE
    dpt-sample   Complete   17m          546                 AES256       Enabled      2/2 passed   17m
5.26.10.5. Azure オブジェクトストレージでデータ保護テストを実行する

必要な Azure 認証情報 (シークレットオブジェクト内の STORAGE_ACCOUNT_ID パラメーターを含む) を設定して、Azure オブジェクトストレージ上で DataProtectionTest (DPT) カスタムリソース (CR) を実行します。これにより、Azure クラスターにおける OADP 設定の検証と CSI スナップショットの準備状況の確認が可能になります。

前提条件

  • cluster-admin ロールを持つユーザーとして Azure クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。
  • OADP Operator がインストールされている。
  • バックアップを保存するためのバケットが設定されている。
  • 別の namespace で実行されている永続ボリューム要求 (PVC) を持つアプリケーションがある。

手順

  1. DPT 実行の失敗を回避するには、Azure storageAccount オブジェクトに Storage Blob Data Contributor ロールを追加します。以下のコマンドを実行します。

    $ az role assignment create \
    --assignee "$AZURE_CLIENT_ID" \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/$AZURE_SUBSCRIPTION_ID/resourceGroups/$AZURE_RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/$AZURE_STORAGE_ACCOUNT_ID"
  2. ターミナルで、Azure パラメーターをエクスポートし、次の例に示すようにパラメーターを含むシークレット認証情報ファイルを作成します。

    Azure で DPT CR を実行するには、シークレット認証情報ファイルで STORAGE_ACCOUNT_ID パラメーターを指定する必要があります。

    AZURE_SUBSCRIPTION_ID=<subscription_id>
    AZURE_TENANT_ID=<tenant_id>
    AZURE_CLIENT_ID=<client_id>
    AZURE_CLIENT_SECRET=<client_secret>
    AZURE_RESOURCE_GROUP=<resource_group>
    AZURE_STORAGE_ACCOUNT_ID=<storage_account>
  3. 次の例に示すように、Secret CR を作成します。

    $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=<credentials_file_path>
  4. 次の例に示す設定を使用して、DataProtectionApplication (DPA) CR を作成します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionApplication
    metadata:
      name: ts-dpa
      namespace: openshift-adp
    spec:
      configuration:
        velero:
          defaultPlugins:
            - azure
            - openshift
      backupLocations:
        - velero:
            config:
              resourceGroup: oadp-....-b7q4-rg
              storageAccount: oadp...kb7q4
              subscriptionId: 53b8f5...fd54c8a
            credential:
              key: cloud
              name: cloud-credentials-azure
            provider: azure
            default: true
            objectStorage:
              bucket: <bucket_name>
              prefix: velero

    名前をシークレット オブジェクトの名前に置き換えてください。この例では、名前は cloud-credentials-azure です。

  5. 次の例に示すように、バックアップストレージの場所 (BSL) の名前、VolumeSnapshotClass オブジェクト、および永続ボリューム要求の詳細を指定して、DPT CR を作成します。

    apiVersion: oadp.openshift.io/v1alpha1
    kind: DataProtectionTest
    metadata:
      name: dpt-sample
      namespace: openshift-adp
    spec:
      backupLocationName: <bsl_name>
      uploadSpeedTestConfig:
        fileSize: 40MB
        timeout: 120s
      csiVolumeSnapshotTestConfigs:
        - snapshotClassName: csi-azuredisk-vsc
          timeout: 90s
          volumeSnapshotSource:
            persistentVolumeClaimName: mysql-data
            persistentVolumeClaimNamespace: ocp-mysql
        - snapshotClassName: csi-azuredisk-vsc
          timeout: 120s
          volumeSnapshotSource:
            persistentVolumeClaimName: mysql-data1
            persistentVolumeClaimNamespace: ocp-mysql

    ここでは、以下のようになります。

    <bsl_name>
    BSL の名前を指定します。
    csi-azuredisk-vsc
    Azure スナップショットのクラス名を指定します。
    mysql-data
    永続ボリューム要求の名前を指定します。
    ocp-mysql
    永続ボリューム要求の名前空間の名前を指定します。
  6. DPT CR を実行して、スナップショットの準備状況を確認します。
5.26.10.6. DataProtectionTest カスタムリソースのトラブルシューティング

DataProtectionTest (DPT) カスタムリソース (CR) でよく発生する問題 (進行状況が停止したままになる、アップロードテストが失敗する、スナップショットテストが失敗するなど) のトラブルシューティングを行います。これは、DPT 設定に関する問題を特定し、解決するのに役立ちます。

Expand
表5.23 DPT CR トラブルシューティング
エラー理由ソリューション

DPT が InProgress 状態で停止している

バケットの認証情報またはバケットへのアクセス失敗

Secret オブジェクト、バケットの権限、およびログを確認します。

アップロードテストに失敗した

不正な Secret オブジェクトまたは S3 エンドポイント

BackupStorageLocation オブジェクトの設定とアクセスキーを確認します。

スナップショットテストが失敗する

CSI スナップショットコントローラーの設定が正しくありません

VolumeSnapshotClass オブジェクトの可用性と CSI ドライバーログを確認します。

バケットの暗号化またはバージョン管理が設定されていない

クラウドプロバイダーの制限

すべてのオブジェクトストレージプロバイダーがこれらのフィールドを一貫して公開するわけではありません。

5.26.11. must-gather ツールの使用

must-gather ツールを使用して、OADP カスタムリソースに関するログと情報を収集します。must-gather データはすべてのカスタマーケースに添付する必要があります。

must-gather ツールはコンテナーであり、常に実行される訳ではありません。このツールは 、must-gather コマンドを実行して起動した後、数分間だけ動作します。

5.26.11.1. must-gather ツールの使用

デフォルト設定、タイムアウト、および安全でない TLS オプションを使用して、must-gather ツールを実行します。オプションを使用するには、該当するオプションに対応するフラグを must-gather コマンドに追加します。

デフォルト設定
この設定は、OADP Operator がインストールされているすべての namespace の Pod ログ、OADP、および Velero カスタムリソース (CR) 情報を収集します。
Timeout
失敗した Backup CR が多数ある場合は、データ収集に長い時間がかかる可能性があります。タイムアウト値を設定することでパフォーマンスを向上させることができます。
非セキュアな TLS 接続
カスタム CA 証明書を使用する場合は、非セキュアな TLS 接続とともに must-gather ツールを使用します。

must-gather ツールは、収集した情報で Markdown 出力ファイルを生成します。Markdown ファイルはクラスターディレクトリーにあります。

サポートされるフラグの詳細は、次の例に示すように、must-gather ツールで help フラグを使用します。

$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5 -- /usr/bin/gather -h

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. must-gather データを保存するディレクトリーに移動します。
  2. 次のデータ収集オプションのいずれかに対して、oc adm must-gather コマンドを実行します。

    • must-gather ツールのデフォルト設定を使用するには、以下のコマンドを実行します。

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5
    • must-gather ツールで timeout フラグを使用するには、以下のコマンドを実行します。

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5 -- /usr/bin/gather --request-timeout 1m

      この例では、タイムアウトは 1 分です。

    • must-gather ツールで非セキュアな TLS 接続フラグを使用するには、以下のコマンドを実行します。

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5 -- /usr/bin/gather --skip-tls
    • 非セキュアな TLS 接続と timeout フラグの組み合わせを must-gather ツールで使用するには、以下のコマンドを実行します。

      $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5 -- /usr/bin/gather --request-timeout 15s --skip-tls

      この例では、タイムアウトは 15 秒です。デフォルトでは、--skip-tls フラグの値は false です。安全でない TLS 接続を許可するには、値を true に設定します。

検証

  1. Markdown 出力ファイルが次の場所に生成されていることを確認します: must-gather.local.89…​054550/registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5-sha256-0…​84/clusters/a4…​86/oadp-must-gather-summary.md
  2. Markdown プレビューワーでファイルを開き、Markdown ファイルで must-gather データを確認します。出力例は、以下のイメージを参照してください。この出力ファイルを Red Hat カスタマーポータル で作成したサポートケースにアップロードできます。

    図5.2 must-gather ツールのマークダウン出力の例

    must-gather マークダウン出力

5.26.12. OADP モニタリング

OpenShift Container Platform のモニタリングスタックを使用して、サービスモニターの作成、アラートルールの設定、およびメトリクスの表示を行うことで、OADP の操作を監視します。これにより、バックアップと復元のパフォーマンスを追跡したり、クラスターを管理したり、重要なイベントに関するアラートを受信したりすることができます。

5.26.12.1. OADP モニタリングの設定

ユーザーワークロード監視を有効にし、OpenShift Container Platform モニタリングスタックを設定して Velero メトリクスを取得するようにすることで、OADP 監視を設定します。これにより、アラートルールを作成したり、メトリクスを照会したり、必要に応じて Grafana などの Prometheus 互換ツールを使用してデータを視覚化したりすることができます。

メトリクスを監視するには、ユーザー定義プロジェクトの監視を有効にし、openshift-adp 名前空間ですでに有効になっている OADP サービスエンドポイントからメトリクスを収集するための ServiceMonitor リソースを作成する必要があります。

注記

Prometheus メトリクスに対する OADP サポートはベストエフォートで提供されており、完全にはサポートされていません。

モニタリングスタックの設定に関する詳細は、ユーザーワークロード監視の設定を 参照してください。

前提条件

  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。
  • クラスター監視 config map が作成されました。

手順

  1. 次のコマンドを使用して、openshift-monitoring namespace の cluster-monitoring-config ConfigMap オブジェクトを編集します。

    $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
  2. 次のコマンドを使用して、data セクションの config.yaml フィールドで enableUserWorkload オプションを追加または有効にします。

    apiVersion: v1
    kind: ConfigMap
    data:
      config.yaml: |
        enableUserWorkload: true
    metadata:
    # ...

    ここでは、以下のようになります。

    enableUserWorkload
    このオプションを追加するか、true に設定してください。
  3. しばらく待ってから、openshift-user-workload-monitoring namespace で次のコンポーネントが稼働していることを確認し、ユーザーワークロードモニタリングのセットアップを確認します。

    $ oc get pods -n openshift-user-workload-monitoring
    NAME                                   READY   STATUS    RESTARTS   AGE
    prometheus-operator-6844b4b99c-b57j9   2/2     Running   0          43s
    prometheus-user-workload-0             5/5     Running   0          32s
    prometheus-user-workload-1             5/5     Running   0          32s
    thanos-ruler-user-workload-0           3/3     Running   0          32s
    thanos-ruler-user-workload-1           3/3     Running   0          32s
  4. openshift-user-workload-monitoringuser-workload-monitoring-config ConfigMap が存在することを確認します。存在する場合、この手順の残りの手順はスキップしてください。

    $ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring
    Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
  5. ユーザーワークロードモニタリングの user-workload-monitoring-config ConfigMap オブジェクトを作成し、2_configure_user_workload_monitoring.yaml ファイル名に保存します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
  6. 次のコマンドを使用して、2_configure_user_workload_monitoring.yaml ファイルを適用します。

    $ oc apply -f 2_configure_user_workload_monitoring.yaml
    configmap/user-workload-monitoring-config created
5.26.12.2. OADP サービスモニターの作成

OADP サービスエンドポイントから Velero のメトリクスを収集するための ServiceMonitor リソースを作成します。これは、OpenShift Container Platform のモニタリングスタックにおけるバックアップおよびリストア操作を監視するためのメトリクスを収集するのに役立ちます。

OADP は 、openshift-adp-velero- メトリクス s-svc サービスを提供します。ユーザーワークロード監視サービスは 、openshift-adp-velero- メトリクス s-svc サービスを使用する必要があります。

手順

  1. openshift-adp-velero-metrics-svc サービスが存在することを確認します。このサービスには、ServiceMonitor オブジェクトのセレクターとして使用される app.kubernetes.io/name=velero ラベルが含まれているはずです。

    $ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero

    出力例

    NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
    openshift-adp-velero-metrics-svc   ClusterIP   172.30.38.244   <none>        8085/TCP   1h

  2. 既存のサービスラベルと一致する ServiceMonitor YAML ファイルを作成し、そのファイルを 3_create_oadp_service_monitor.yaml として保存します。サービスモニターは 、openshift-adp-velero- メトリクス s-svc サービスが存在する openshift-adp 名前空間に作成されます。

    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      labels:
        app: oadp-service-monitor
      name: oadp-service-monitor
      namespace: openshift-adp
    spec:
      endpoints:
      - interval: 30s
        path: /metrics
        targetPort: 8085
        scheme: http
      selector:
        matchLabels:
          app.kubernetes.io/name: "velero"
  3. 3_create_oadp_service_monitor.yaml ファイルを適用します。

    $ oc apply -f 3_create_oadp_service_monitor.yaml

    出力例

    servicemonitor.monitoring.coreos.com/oadp-service-monitor created

検証

  • OpenShift Container Platform Web コンソールの Administrator パースペクティブを使用して、新しいサービスモニターが Up 状態であることを確認します。サービスモニターが Up 状態になるまで数分間待ちます。

    1. ObserveTargets ページに移動します。
    2. Filter が選択されていないこと、または User ソースが選択されていることを確認し、Text 検索フィールドに openshift-adp と入力します。
    3. サービスモニターの Status のステータスが Up であることを確認します。

      図5.3 OADP のメトリクスターゲット

      OADP のメトリクスターゲット
5.26.12.3. アラートルールの作成

OADP バックアップ操作のアラートルールを設定するために、PrometheusRule リソースを作成します。これにより、バックアップの失敗やその他の問題が環境内で発生した際に通知を受け取ることができます。

OpenShift Container Platform モニタリングスタックは、アラートルールを使用して設定されたアラートを受信します。OADP プロジェクトのアラートルールを作成するには、ユーザーワークロード監視で取得したメトリクスのいずれかを使用します。

手順

  1. サンプルの OADPBackupFailing アラートを含む PrometheusRule YAML ファイルを作成し、4_create_oadp_alert_rule.yaml として保存します。

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: sample-oadp-alert
      namespace: openshift-adp
    spec:
      groups:
      - name: sample-oadp-backup-alert
        rules:
        - alert: OADPBackupFailing
          annotations:
            description: 'OADP had {{$value | humanize}} backup failures over the last 2 hours.'
            summary: OADP has issues creating backups
          expr: |
            increase(velero_backup_failure_total{job="openshift-adp-velero-metrics-svc"}[2h]) > 0
          for: 5m
          labels:
            severity: warning

    このサンプルでは、アラートは次の条件で表示されます。

    • 過去 2 時間において、失敗した新規バックアップの数が 0 よりも多く、その状態が少なくとも 5 分間持続した場合。
    • 失敗が最初に検知されてから 5 分未満の場合、アラートは Pending 状態になり、その後 Firing 状態に変わります。
  2. 4_create_oadp_alert_rule.yaml ファイルを適用して、openshift-adp namespace に PrometheusRule オブジェクトを作成します。

    $ oc apply -f 4_create_oadp_alert_rule.yaml

    出力例

    prometheusrule.monitoring.coreos.com/sample-oadp-alert created

検証

  • アラートがトリガーされた後は、次の方法でアラートを表示できます。

    • Developer パースペクティブで、Observe メニューを選択します。
    • ObserveAlerting メニューの下の Administrator パースペクティブで、Filter ボックスの User を選択します。それ以外の場合、デフォルトでは Platform アラートのみが表示されます。

      図5.4 OADP のバックアップ失敗アラート

      OADP のバックアップ失敗アラート
5.26.12.4. 利用可能なメトリクスのリスト

OADP が提供する Velero メトリクスとその タイプ のリストについては、以下の表を参照してください。

Expand
表5.24 Velero メトリクス
メトリクス名説明

velero_backup_tarball_size_bytes

バックアップのサイズ (バイト単位)

ゲージ

velero_backup_total

既存のバックアップの現在の数

ゲージ

velero_backup_attempt_total

試行されたバックアップの合計数

Counter

velero_backup_success_total

成功したバックアップの合計数

Counter

velero_backup_partial_failure_total

部分的に失敗したバックアップの合計数

Counter

velero_backup_failure_total

失敗したバックアップの合計数

Counter

velero_backup_validation_failure_total

検証に失敗したバックアップの合計数

Counter

velero_backup_duration_seconds

バックアップの完了にかかる時間 (秒単位)

ヒストグラム

velero_backup_duration_seconds_bucket

メトリクス velero_backup_duration_seconds のヒストグラムにおけるバケットの観測回数の合計

Counter

velero_backup_duration_seconds_count

メトリクス velero_backup_duration_seconds の観測回数の合計

Counter

velero_backup_duration_seconds_sum

メトリクス velero_backup_duration_seconds の観測値の合計

Counter

velero_backup_deletion_attempt_total

試行されたバックアップ削除の合計数

Counter

velero_backup_deletion_success_total

成功したバックアップ削除の合計数

Counter

velero_backup_deletion_failure_total

失敗したバックアップ削除の合計数

Counter

velero_backup_last_successful_timestamp

前回バックアップが正常に実行された時刻 (UNIX タイムスタンプ、秒単位)

ゲージ

velero_backup_items_total

バックアップされたアイテムの総数

ゲージ

velero_backup_items_errors

バックアップ中に発生したエラーの合計数

ゲージ

velero_backup_warning_total

警告されたバックアップの総数

Counter

velero_backup_last_status

バックアップの最終ステータス。値 1 は成功、0 は失敗です。

ゲージ

velero_restore_total

現在の既存のリストアの数

ゲージ

velero_restore_attempt_total

試行された復元の合計数

Counter

velero_restore_validation_failed_total

検証に失敗したリストアの失敗の合計数

Counter

velero_restore_success_total

成功した復元の合計数

Counter

velero_restore_partial_failure_total

部分的に失敗したリストアの合計数

Counter

velero_restore_failed_total

失敗したリストアの合計数

Counter

velero_volume_snapshot_attempt_total

試行されたボリュームスナップショットの総数

Counter

velero_volume_snapshot_success_total

成功したボリュームスナップショットの総数

Counter

velero_volume_snapshot_failure_total

失敗したボリュームスナップショットの総数

Counter

velero_csi_snapshot_attempt_total

CSI が試行したボリュームスナップショットの合計数

Counter

velero_csi_snapshot_success_total

CSI が成功したボリュームスナップショットの総数

Counter

velero_csi_snapshot_failure_total

CSI で失敗したボリュームスナップショットの総数

Counter

5.26.12.5. Observe UI を使用したメトリクスの表示

OpenShift Container Platform の Web コンソールで、管理者 または 開発者の 視点からメトリクスを確認してください。管理者または開発者は、openshift-adp プロジェクトへのアクセス権を持っている必要があります。

手順

  • ObserveMetrics ページに移動します。

    • Developer パースペクティブを使用している場合は、次の手順に従います。

      1. カスタムクエリー を選択するか、PromQL を表示 リンクをクリックしてください。
      2. クエリーを入力し、Enter をクリックします。
    • Administrator パースペクティブを使用している場合は、テキストフィールドに式を入力し、Run Queries を選択します。

      図5.5 OADP のメトリクスクエリー

      OADP のメトリクスクエリー

第6章 コントロールプレーンのバックアップおよび復元

6.1. etcd のバックアップ

etcd は OpenShift Container Platform のキーと値のストアであり、すべてのリソースオブジェクトの状態を保存します。

クラスターの etcd データを定期的にバックアップし、OpenShift Container Platform 環境外の安全な場所に保存するのが理想的です。インストールの 24 時間後に行われる最初の証明書のローテーションが完了するまで etcd のバックアップを実行することはできません。ローテーションの完了前に実行すると、バックアップに期限切れの証明書が含まれることになります。etcd スナップショットは I/O コストが高いため、ピーク使用時間以外に etcd バックアップを取得することも推奨します。

クラスターを更新する前に、必ず etcd のバックアップを作成してください。クラスターを復元するときに、同じ z-stream リリースから取得した etcd バックアップを使用する必要があるため、更新する前にバックアップを作成することが重要です。たとえば、OpenShift Container Platform 4.17.5 クラスターでは、4.17.5 から取得した etcd バックアップを使用する必要があります。

重要

コントロールプレーンホストでバックアップスクリプトの単一の呼び出しを実行して、クラスターの etcd データをバックアップします。各コントロールプレーンホストのバックアップを取得しないでください。

etcd のバックアップを作成したら、以前のクラスターの状態に復元 できます。

6.1.1. etcd データのバックアップ

以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。

重要

単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • クラスター全体のプロキシーが有効になっているかどうかを確認している。

    ヒント

    oc get proxy cluster -o yaml の出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxyhttpsProxy、および noProxy フィールドに値が設定されている場合に有効にされます。

手順

  1. コントロールプレーンノードの root としてデバッグセッションを開始します。

    $ oc debug --as-root node/<node_name>
  2. デバッグシェルで root ディレクトリーを /host に変更します。

    sh-4.4# chroot /host
  3. クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、NO_PROXYHTTP_PROXY、および HTTPS_PROXY 環境変数をエクスポートします。

    $ export HTTP_PROXY=http://<your_proxy.example.com>:8080
    $ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
    $ export NO_PROXY=<example.com>
  4. デバッグシェルで cluster-backup.sh スクリプトを実行し、バックアップの保存先となる場所を渡します。

    ヒント

    cluster-backup.sh スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save コマンドに関連するラッパーです。

    sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup

    スクリプトの出力例

    found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6
    found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7
    found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6
    found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3
    ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1
    etcdctl version: 3.4.14
    API version: 3.4
    {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"}
    {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
    {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"}
    {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
    {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459}
    {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"}
    Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db
    {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336}
    snapshot db and kube resources are successfully saved to /home/core/assets/backup

    この例では、コントロールプレーンホストの /home/core/assets/backup/ ディレクトリーにファイルが 2 つ作成されます。

    • snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。cluster-backup.sh スクリプトで、その有効性を確認します。
    • static_kuberesources_<datetimestamp>.tar.gz: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。

      注記

      etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。

      etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。

6.1.3. 自動 etcd バックアップの作成

etcd の自動バックアップ機能は、繰り返しバックアップとシングルバックアップの両方をサポートします。繰り返しバックアップでは、ジョブがトリガーされるたびにシングルバックアップを開始する cron ジョブが作成されます。

重要

etcd バックアップの自動化はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

etcd の自動バックアップを有効にするには、次の手順を実行します。

警告

クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、マイナーバージョンの更新ができなくなります。TechPreviewNoUpgrade 機能セットは無効にできません。実稼働クラスターではこの機能セットを有効にしないでください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) にアクセスできる。

手順

  1. 次の内容で、enable-tech-preview-no-upgrade.yaml という名前の FeatureGate カスタムリソース (CR) ファイルを作成します。

    apiVersion: config.openshift.io/v1
    kind: FeatureGate
    metadata:
      name: cluster
    spec:
      featureSet: TechPreviewNoUpgrade
  2. CR を適用し、自動バックアップを有効にします。

    $ oc apply -f enable-tech-preview-no-upgrade.yaml
  3. 関連する API を有効にするのに時間がかかります。次のコマンドを実行して、カスタムリソース定義 (CRD) が作成されたことを確認します。

    $ oc get crd | grep backup

    出力例

    backups.config.openshift.io 2023-10-25T13:32:43Z
    etcdbackups.operator.openshift.io 2023-10-25T13:32:04Z

6.1.3.1. 単一の自動化された etcd バックアップの作成

次の手順でカスタムリソース (CR) を作成して適用することで、シングル etcd バックアップを作成します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) にアクセスできる。

手順

  • 動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。

    1. 次の例のような内容で、etcd-backup-pvc.yaml という名前の永続ボリューム要求 (PVC) を作成します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: etcd-backup-pvc
        namespace: openshift-etcd
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi 
      1
      
        volumeMode: Filesystem
      1 1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
    2. 以下のコマンドを実行して PVC を適用します。

      $ oc apply -f etcd-backup-pvc.yaml
    3. 次のコマンドを実行して、PVC が作成されたことを確認します。

      $ oc get pvc

      出力例

      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
      etcd-backup-pvc   Bound                                                       51s

      注記

      動的 PVC は、マウントされるまで Pending 状態から遷移しません。

    4. 次の例のような内容で、etcd-single-backup.yaml という名前の CR ファイルを作成します。

      apiVersion: operator.openshift.io/v1alpha1
      kind: EtcdBackup
      metadata:
        name: etcd-single-backup
        namespace: openshift-etcd
      spec:
        pvcName: etcd-backup-pvc 
      1
      1
      バックアップを保存する PVC の名前。この値は、使用している環境に応じて調整してください。
    5. CR を適用してシングルバックアップを開始します。

      $ oc apply -f etcd-single-backup.yaml
  • 動的にプロビジョニングされたストレージが利用できない場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。

    1. 次の内容で、etcd-backup-local-storage.yaml という名前の StorageClass CR ファイルを作成します。

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: etcd-backup-local-storage
      provisioner: kubernetes.io/no-provisioner
      volumeBindingMode: Immediate
    2. 次のコマンドを実行して、StorageClass CR を適用します。

      $ oc apply -f etcd-backup-local-storage.yaml
    3. 次の例のような内容の etcd-backup-pv-fs.yaml という名前の PV を作成します。

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: etcd-backup-pv-fs
      spec:
        capacity:
          storage: 100Gi 
      1
      
        volumeMode: Filesystem
        accessModes:
        - ReadWriteOnce
        persistentVolumeReclaimPolicy: Retain
        storageClassName: etcd-backup-local-storage
        local:
          path: /mnt
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
            - key: kubernetes.io/hostname
               operator: In
               values:
               - <example_master_node> 
      2
      1
      PV が使用できるストレージの量。この値は、要件に合わせて調整します。
      2
      この値は、この PV をアタッチするノードに置き換えます。
    4. 次のコマンドを実行して、PV が作成されたことを確認します。

      $ oc get pv

      出力例

      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
      etcd-backup-pv-fs       100Gi      RWO            Retain           Available           etcd-backup-local-storage            10s

    5. 次の例のような内容で、etcd-backup-pvc.yaml という名前の PVC を作成します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: etcd-backup-pvc
        namespace: openshift-etcd
      spec:
        accessModes:
        - ReadWriteOnce
        volumeMode: Filesystem
        resources:
          requests:
            storage: 10Gi 
      1
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
    6. 以下のコマンドを実行して PVC を適用します。

      $ oc apply -f etcd-backup-pvc.yaml
    7. 次の例のような内容で、etcd-single-backup.yaml という名前の CR ファイルを作成します。

      apiVersion: operator.openshift.io/v1alpha1
      kind: EtcdBackup
      metadata:
        name: etcd-single-backup
        namespace: openshift-etcd
      spec:
        pvcName: etcd-backup-pvc 
      1
      1
      バックアップを保存する永続ボリューム要求 (PVC) の名前。この値は、使用している環境に応じて調整してください。
    8. CR を適用してシングルバックアップを開始します。

      $ oc apply -f etcd-single-backup.yaml
6.1.3.2. 定期的な自動 etcd バックアップの作成

etcd の自動繰り返しバックアップを作成するには、次の手順に従います。

可能であれば、動的にプロビジョニングされたストレージを使用して、作成された etcd バックアップデータを安全な外部の場所に保存します。動的にプロビジョニングされたストレージが利用できない場合は、バックアップの復元にアクセスしやすくするために、バックアップデータを NFS 共有に保存することを検討してください。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) にアクセスできる。

手順

  1. 動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、自動化された繰り返しバックアップを作成します。

    1. 次の例のような内容で、etcd-backup-pvc.yaml という名前の永続ボリューム要求 (PVC) を作成します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: etcd-backup-pvc
        namespace: openshift-etcd
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi 
      1
      
        volumeMode: Filesystem
        storageClassName: etcd-backup-local-storage
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
      注記

      次の各プロバイダーでは、accessModes キーと storageClassName キーを変更する必要があります。

      Expand
      ProvideraccessModesstorageClassName

      versioned-installer-efc_operator-ci プロファイルを持つ AWS

      - ReadWriteMany

      efs-sc

      Google Cloud

      - ReadWriteMany

      filestore-csi

      Microsoft Azure

      - ReadWriteMany

      azurefile-csi

    2. 以下のコマンドを実行して PVC を適用します。

      $ oc apply -f etcd-backup-pvc.yaml
    3. 次のコマンドを実行して、PVC が作成されたことを確認します。

      $ oc get pvc

      出力例

      NAME              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
      etcd-backup-pvc   Bound                                                       51s

      注記

      動的 PVC は、マウントされるまで Pending 状態から遷移しません。

  2. 動的にプロビジョニングされたストレージが使用できない場合は、次の手順を実行してローカルストレージ PVC を作成します。

    警告

    保存されているバックアップデータが格納されたノードを削除するか、該当ノードへのアクセスを失うと、データが失われる可能性があります。

    1. 次の内容で、etcd-backup-local-storage.yaml という名前の StorageClass CR ファイルを作成します。

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: etcd-backup-local-storage
      provisioner: kubernetes.io/no-provisioner
      volumeBindingMode: Immediate
    2. 次のコマンドを実行して、StorageClass CR を適用します。

      $ oc apply -f etcd-backup-local-storage.yaml
    3. 適用された StorageClass から、次の例のような内容の etcd-backup-pv-fs.yaml という名前の PV を作成します。

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: etcd-backup-pv-fs
      spec:
        capacity:
          storage: 100Gi 
      1
      
        volumeMode: Filesystem
        accessModes:
        - ReadWriteMany
        persistentVolumeReclaimPolicy: Delete
        storageClassName: etcd-backup-local-storage
        local:
          path: /mnt/
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - <example_master_node> 
      2
      1
      PV が使用できるストレージの量。この値は、要件に合わせて調整します。
      2
      この値は、この PV をアタッチするマスターノードに置き換えます。
      ヒント

      次のコマンドを実行して、使用可能なノードのリストを表示します。

      $ oc get nodes
    4. 次のコマンドを実行して、PV が作成されたことを確認します。

      $ oc get pv

      出力例

      NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS                REASON   AGE
      etcd-backup-pv-fs       100Gi      RWX            Delete           Available           etcd-backup-local-storage            10s

    5. 次の例のような内容で、etcd-backup-pvc.yaml という名前の PVC を作成します。

      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: etcd-backup-pvc
      spec:
        accessModes:
        - ReadWriteMany
        volumeMode: Filesystem
        resources:
          requests:
            storage: 10Gi 
      1
      
        storageClassName: etcd-backup-local-storage
      1
      PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
    6. 以下のコマンドを実行して PVC を適用します。

      $ oc apply -f etcd-backup-pvc.yaml
  3. etcd-recurring-backups.yaml という名前のカスタムリソース定義 (CRD) ファイルを作成します。作成された CRD の内容は、自動化されたバックアップのスケジュールと保持タイプを定義します。

    • 15 個のバックアップを保持する RetentionNumber のデフォルトの保持タイプでは、次の例のような内容を使用します。

      apiVersion: config.openshift.io/v1alpha1
      kind: Backup
      metadata:
        name: etcd-recurring-backup
      spec:
        etcd:
          schedule: "20 4 * * *" 
      1
      
          timeZone: "UTC"
          pvcName: etcd-backup-pvc
      1
      定期的なバックアップの CronTab スケジュール。この値は、必要に応じて調整します。
    • バックアップの最大数に基づいて保持を使用するには、次のキーと値のペアを etcd キーに追加します。

      spec:
        etcd:
          retentionPolicy:
            retentionType: RetentionNumber 
      1
      
            retentionNumber:
              maxNumberOfBackups: 5 
      2
      1
      保持タイプ。指定しない場合、デフォルトは RetentionNumber です。
      2
      保持するバックアップの最大数。この値は、必要に応じて調整します。指定しない場合、デフォルトは 15 個のバックアップです。
      警告

      既知の問題により、保持されるバックアップの数が設定された値に 1 を加えた数になります。

    • バックアップのファイルサイズに基いて保持する場合は、以下を使用します。

      spec:
        etcd:
          retentionPolicy:
            retentionType: RetentionSize
            retentionSize:
              maxSizeOfBackupsGb: 20 
      1
      1
      保持するバックアップの最大ファイルサイズ (ギガバイト単位)。この値は、必要に応じて調整します。指定しない場合、デフォルトは 10 GB になります。
      警告

      既知の問題により、保持されるバックアップの最大サイズが設定値より最大 10 GB 大きくなります。

  4. 次のコマンドを実行して、CRD で定義される cron ジョブを作成します。

    $ oc create -f etcd-recurring-backup.yaml
  5. 作成された cron ジョブを検索するには、次のコマンドを実行します。

    $ oc get cronjob -n openshift-etcd

6.2. 正常でない etcd メンバーの置き換え

このドキュメントでは、単一の正常でない etcd メンバーを置き換えるプロセスを説明します。

このプロセスは、マシンが実行されていないか、ノードが準備状態にないことによって etcd メンバーが正常な状態にないか、etcd Pod がクラッシュループしているためにこれが正常な状態にないかによって異なります。

注記

コントロールプレーンホストの大部分を損失した場合は、この手順ではなく、ディザスターリカバリー手順に従って、以前のクラスター状態への復元 を行います。

置き換えられるメンバー上のコントロールプレーン証明書が有効でない場合は、この手順ではなく、期限切れのコントロールプレーン証明書から回復 する手順を実行する必要があります。

コントロールプレーンノードが失われ、新規ノードが作成される場合、etcd クラスター Operator は新規 TLS 証明書の生成と、ノードの etcd メンバーとしての追加を処理します。

6.2.1. 前提条件

6.2.2. 正常でない etcd メンバーの特定

クラスターに正常でない etcd メンバーがあるかどうかを特定することができます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd のバックアップを取得している。詳細は、「etcd データのバックアップ」を参照してください。

手順

  1. 以下のコマンドを使用して EtcdMembersAvailable ステータス条件のステータスを確認します。

    $ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}{end}'
  2. 出力を確認します。

    2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy

    この出力例は、ip-10-0-131-183.ec2.internal etcd メンバーが正常ではないことを示しています。

6.2.3. 正常でない etcd メンバーの状態の判別

正常でない etcd メンバーを置き換える手順は、etcd メンバーが以下のどの状態にあるかによって異なります。

  • マシンが実行されていないか、ノードが準備状態にない
  • etcd Pod がクラッシュループしている。

以下の手順では、etcd メンバーがどの状態にあるかを判別します。これにより、正常でない etcd メンバーを置き換えるために実行する必要のある手順を確認できます。

注記

マシンが実行されていないか、ノードが準備状態にないものの、すぐに正常な状態に戻ることが予想される場合は、etcd メンバーを置き換える手順を実行する必要はありません。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • 正常でない etcd メンバーを特定している。

手順

  1. マシンが実行されていない かどうかを確認します。

    $ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running

    出力例

    ip-10-0-131-183.ec2.internal  stopped 
    1

    1
    この出力には、ノードおよびノードのマシンのステータスをリスト表示されます。ステータスが running 以外の場合は、マシンは実行されていません

    マシンが実行されていない 場合は、マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーの置き換え の手順を実行します。

  2. ノードの準備ができていない かどうかを確認します。

    以下のシナリオのいずれかが true の場合、ノードは準備状態にありません

    • マシンが実行されている場合は、ノードに到達できないかどうかを確認します。

      $ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable

      出力例

      ip-10-0-131-183.ec2.internal	node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable 
      1

      1
      ノードが unreachable テイントと共にリスト表示される場合、ノードの準備はできていません
    • ノードにまだ到達可能な場合は、ノードが NotReady としてリストされるかどうかを確認します。

      $ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"

      出力例

      ip-10-0-131-183.ec2.internal   NotReady   master   122m   v1.33.4 
      1

      1
      ノードが NotReady としてリスト表示されている場合、ノードの準備はできていません

    ノードの準備ができていない 場合は、マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え の手順を実行します。

  3. etcd Pod がクラッシュループしている かどうかを確認します。

    マシンが実行され、ノードが準備できている場合は、etcd Pod がクラッシュループしているかどうかを確認します。

    1. すべてのコントロールプレーンノードが Ready としてリスト表示されていることを確認します。

      $ oc get nodes -l node-role.kubernetes.io/master

      出力例

      NAME                           STATUS   ROLES    AGE     VERSION
      ip-10-0-131-183.ec2.internal   Ready    master   6h13m   v1.33.4
      ip-10-0-164-97.ec2.internal    Ready    master   6h13m   v1.33.4
      ip-10-0-154-204.ec2.internal   Ready    master   6h13m   v1.33.4

    2. etcd Pod のステータスが Error または CrashloopBackoff のいずれかであるかどうかを確認します。

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      出力例

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m 
      1
      
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

      1
      この Pod のこのステータスは Error であるため、etcd Pod はクラッシュループしています

    etcd Pod がクラッシュループしている 場合、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え に関する手順を実行します。

6.2.4. 正常でない etcd メンバーの置き換え

正常でない etcd メンバーの状態に応じて、以下のいずれかの手順を使用します。

マシンが実行されていない、またはノードの準備ができていない、正常ではない etcd メンバーを置き換える手順を説明します。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。

前提条件

  • 正常でない etcd メンバーを特定している。
  • マシンが実行されていないか、ノードが準備状態にないことを確認している。

    重要

    他のコントロールプレーンノードの電源をオフにする場合は、待機する必要があります。異常な etcd メンバーの交換が完了するまで、コントロールプレーンノードの電源をオフのままにしておく必要があります。

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd のバックアップを取得している。

    重要

    この手順を実行する前に、問題が発生した場合にクラスターを復元できるように、etcd のバックアップを作成してください。

手順

  1. 正常でないメンバーを削除します。

    1. 影響を受けるノード上にない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      出力例

      etcd-ip-10-0-131-183.ec2.internal                3/3     Running     0          123m
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

    2. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    3. メンバーのリストを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      正常でない etcd メンバーの ID と名前をメモしてください。これらの値はこの手順で後ほど必要になります。$ etcdctl endpoint health コマンドは、補充手順が完了し、新しいメンバーが追加されるまで、削除されたメンバーをリスト表示します。

    4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。

      sh-4.2# etcdctl member remove 6fc1e7c9db35841d

      出力例

      Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346

    5. メンバーのリストを再度表示し、メンバーが削除されたことを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これでノードシェルを終了できます。

  2. 次のコマンドを入力して、クォーラムガードをオフにします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

    重要

    クォーラムガードをオフにすると、設定の変更を反映するために残りの etcd インスタンスが再起動するまで、短時間クラスターにアクセスできなくなる可能性があります。

    注記

    etcd は、2 つのメンバーで実行されている場合、新たなメンバー障害を許容できません。残りのメンバーのいずれかを再起動すると、クォーラムが破棄され、クラスターでダウンタイムが発生します。クォーラムガードによって、ダウンタイムを引き起こす可能性のある設定変更による再起動から etcd が保護されるため、この手順を完了するには、クォーラムガードを無効にする必要があります。

  3. 次のコマンドを実行して、影響を受けるノードを削除します。

    $ oc delete node <node_name>

    コマンドの例

    $ oc delete node ip-10-0-131-183.ec2.internal

  4. 削除された正常でない etcd メンバーの古いシークレットを削除します。

    1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 
      1
      1
      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      出力例

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
      etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
      etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

    2. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
      2. サービングシークレットを削除します。

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
      3. メトリクスシークレットを削除します。

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
  5. 次のコマンドを入力して、コントロールプレーンマシンセットが存在するかどうかを確認します。

    $ oc -n openshift-machine-api get controlplanemachineset
    • コントロールプレーンマシンセットが存在する場合は、コントロールプレーンマシンを削除して再作成します。このマシンが再作成されると、新しいリビジョンが強制的に適用され、etcd は自動的にスケールアップします。詳細は、「マシンが実行されていないか、ノードの準備ができていない場合の正常でない etcd メンバーの置き換え」を参照してください。

      インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初にコントロールプレーンを作成したときと同じ方法を使用して、新しいコントロールプレーンを作成する必要があります。

      1. 正常でないメンバーのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 
        1
        
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1
        これは正常でないノードのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。
      2. 正常でないメンバーのマシンを削除します。

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
        1
        1
        正常でないノードのコントロールプレーンマシンの名前を指定します。

        正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

      3. 新しいマシンが作成されたことを確認します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
        clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running 
        1
        
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1
        新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

        新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

        注記

        マシンセットに使用しているサブネット ID を確認し、それが正しいアベイラビリティーゾーン内にあることを確認してください。

    • コントロールプレーンマシンセットが存在しない場合は、コントロールプレーンマシンを削除して再作成します。このマシンが再作成されると、新しいリビジョンが強制的に適用され、etcd は自動的にスケールアップします。

      インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初にコントロールプレーンを作成したときと同じ方法を使用して、新しいコントロールプレーンを作成する必要があります。

      1. 正常でないメンバーのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 
        1
        
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1
        これは正常でないノードのコントロールプレーンマシンです (ip-10-0-131-183.ec2.internal)。
      2. マシン設定をファイルシステムのファイルに保存します。

        $ oc get machine clustername-8qw5l-master-0 \ 
        1
        
            -n openshift-machine-api \
            -o yaml \
            > new-master-machine.yaml
        1
        正常でないノードのコントロールプレーンマシンの名前を指定します。
      3. 直前の手順で作成された new-master-machine.yaml ファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。

        1. status セクション全体を削除します。

          status:
            addresses:
            - address: 10.0.131.183
              type: InternalIP
            - address: ip-10-0-131-183.ec2.internal
              type: InternalDNS
            - address: ip-10-0-131-183.ec2.internal
              type: Hostname
            lastUpdated: "2020-04-20T17:44:29Z"
            nodeRef:
              kind: Node
              name: ip-10-0-131-183.ec2.internal
              uid: acca4411-af0d-4387-b73e-52b2484295ad
            phase: Running
            providerStatus:
              apiVersion: awsproviderconfig.openshift.io/v1beta1
              conditions:
              - lastProbeTime: "2020-04-20T16:53:50Z"
                lastTransitionTime: "2020-04-20T16:53:50Z"
                message: machine successfully created
                reason: MachineCreationSucceeded
                status: "True"
                type: MachineCreation
              instanceId: i-0fdb85790d76d0c3f
              instanceState: stopped
              kind: AWSMachineProviderStatus
        2. metadata.name フィールドを新規の名前に変更します。

          古いマシンと同じベース名を維持し、最後の番号を次の使用可能な番号に変更します。この例では、clustername-8qw5l-master-0clustername-8qw5l-master-3 に変更されています。

          以下に例を示します。

          apiVersion: machine.openshift.io/v1beta1
          kind: Machine
          metadata:
            ...
            name: clustername-8qw5l-master-3
            ...
        3. spec.providerID フィールドを削除します。

            providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
      4. 正常でないメンバーのマシンを削除します。

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
        1
        1
        正常でないノードのコントロールプレーンマシンの名前を指定します。
      5. マシンが削除されたことを確認します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

      6. new-master-machine.yaml ファイルを使用して新しいマシンを作成します。

        $ oc apply -f new-master-machine.yaml
      7. 新しいマシンが作成されたことを確認します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-154-204.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-164-97.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba   running
        clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-133-53.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8   running 
        1
        
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1
        新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

        新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

  6. 次のコマンドを入力して、クォーラムガードをオンに戻します。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  7. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。

    $ oc get etcd/cluster -oyaml
  8. シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

    出力例

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

検証

  1. すべての etcd Pod が適切に実行されていることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    出力例

    etcd-ip-10-0-133-53.ec2.internal                 3/3     Running     0          7m49s
    etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          123m
    etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          124m

    直前のコマンドの出力に 2 つの Pod のみがリスト表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 
    1
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。
  2. 3 つの etcd メンバーがあることを確認します。

    1. 実行中の etcd コンテナーに接続し、影響を受けるノードになかった Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    2. メンバーのリストを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 5eb0d6b8ca24730c | started |  ip-10-0-133-53.ec2.internal |  https://10.0.133.53:2380 |  https://10.0.133.53:2379 |
      | 757b6793e2408b6c | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

      警告

      必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。

6.2.4.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え

この手順では、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーを置き換える手順を説明します。

前提条件

  • 正常でない etcd メンバーを特定している。
  • etcd Pod がクラッシュループしていることを確認している。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd のバックアップを取得している。

    重要

    問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。

手順

  1. クラッシュループしている etcd Pod を停止します。

    1. クラッシュループしているノードをデバッグします。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc debug node/ip-10-0-131-183.ec2.internal 
      1
      1
      これを正常でないノードの名前に置き換えます。
    2. ルートディレクトリーを /host に変更します。

      sh-4.2# chroot /host
    3. 既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。

      sh-4.2# mkdir /var/lib/etcd-backup
      sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
    4. etcd データディレクトリーを別の場所に移動します。

      sh-4.2# mv /var/lib/etcd/ /tmp

      これでノードシェルを終了できます。

  2. 正常でないメンバーを削除します。

    1. 影響を受けるノード上に ない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc -n openshift-etcd get pods -l k8s-app=etcd

      出力例

      etcd-ip-10-0-131-183.ec2.internal                2/3     Error       7          6h9m
      etcd-ip-10-0-164-97.ec2.internal                 3/3     Running     0          6h6m
      etcd-ip-10-0-154-204.ec2.internal                3/3     Running     0          6h6m

    2. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    3. メンバーのリストを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 |
      | b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。

    4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。

      sh-4.2# etcdctl member remove 62bcf33650a7170a

      出力例

      Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346

    5. メンバーのリストを再度表示し、メンバーが削除されたことを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+------------------------------+---------------------------+---------------------------+
      |        ID        | STATUS  |             NAME             |        PEER ADDRS         |       CLIENT ADDRS        |
      +------------------+---------+------------------------------+---------------------------+---------------------------+
      | b78e2856655bc2eb | started |  ip-10-0-164-97.ec2.internal |  https://10.0.164.97:2380 |  https://10.0.164.97:2379 |
      | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 |
      +------------------+---------+------------------------------+---------------------------+---------------------------+

      これでノードシェルを終了できます。

  3. 次のコマンドを入力して、クォーラムガードをオフにします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

  4. 削除された正常でない etcd メンバーの古いシークレットを削除します。

    1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。

      $ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 
      1
      1
      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      出力例

      etcd-peer-ip-10-0-131-183.ec2.internal              kubernetes.io/tls                     2      47m
      etcd-serving-ip-10-0-131-183.ec2.internal           kubernetes.io/tls                     2      47m
      etcd-serving-metrics-ip-10-0-131-183.ec2.internal   kubernetes.io/tls                     2      47m

    2. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。

        $ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
      2. サービングシークレットを削除します。

        $ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
      3. メトリクスシークレットを削除します。

        $ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
  5. etcd の再デプロイメントを強制的に実行します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 
    1
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd クラスター Operator が再デプロイを実行する場合、すべてのコントロールプレーンノードで etcd Pod が機能していることを確認します。

  6. 次のコマンドを入力して、クォーラムガードをオンに戻します。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  7. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。

    $ oc get etcd/cluster -oyaml
  8. シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

    出力例

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

検証

  • 新しいメンバーが利用可能で、正常な状態にあることを確認します。

    1. 再度実行中の etcd コンテナーに接続します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
    2. すべてのメンバーが正常であることを確認します。

      sh-4.2# etcdctl endpoint health

      出力例

      https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms
      https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms
      https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms

以下の手順では、マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーを置き換える手順を説明します。

インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成したときと同じ方法で、新しいコントロールプレーンノードを作成する必要があります。

前提条件

  • 正常でないベアメタル etcd メンバーを特定している。
  • マシンが実行されていないか、ノードが準備状態にないことを確認している。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • etcd のバックアップを取得している。

    重要

    問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておく。

手順

  1. 正常でないメンバーを確認し、削除します。

    1. 影響を受けるノード上に ない Pod を選択します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide

      出力例

      etcd-openshift-control-plane-0   5/5   Running   11   3h56m   192.168.10.9   openshift-control-plane-0  <none>           <none>
      etcd-openshift-control-plane-1   5/5   Running   0    3h54m   192.168.10.10   openshift-control-plane-1   <none>           <none>
      etcd-openshift-control-plane-2   5/5   Running   0    3h58m   192.168.10.11   openshift-control-plane-2   <none>           <none>

    2. 実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。

      クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

      $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
    3. メンバーのリストを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      | ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
      | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/   | false |
      +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+

      これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。etcdctl endpoint health コマンドは、置き換えの手順が完了し、新規メンバーが追加されるまで、削除されたメンバーをリスト表示します。

    4. ID を etcdctl member remove コマンドに指定して、正常でない etcd メンバーを削除します。

      警告

      必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。

      sh-4.2# etcdctl member remove 7a8197040a5126c8

      出力例

      Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b

    5. メンバーのリストを再度表示し、メンバーが削除されたことを確認します。

      sh-4.2# etcdctl member list -w table

      出力例

      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      | ID               | STATUS  | NAME                      | PEER ADDRS                  | CLIENT ADDRS                | IS LEARNER |
      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
      | cc3830a72fc357f9 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false |
      | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false |
      +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+

      これでノードシェルを終了できます。

      重要

      メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。

  2. 次のコマンドを入力して、クォーラムガードをオフにします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'

    このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。

  3. 以下のコマンドを実行して、削除された正常でない etcd メンバーの古いシークレットを削除します。

    1. 削除された正常でない etcd メンバーのシークレット一覧を表示します。

      $ oc get secrets -n openshift-etcd | grep openshift-control-plane-2

      この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。

      以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。

      etcd-peer-openshift-control-plane-2             kubernetes.io/tls   2   134m
      etcd-serving-metrics-openshift-control-plane-2  kubernetes.io/tls   2   134m
      etcd-serving-openshift-control-plane-2          kubernetes.io/tls   2   134m
    2. 削除された正常でない etcd メンバーのシークレットを削除します。

      1. ピアシークレットを削除します。

        $ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd
        
        secret "etcd-peer-openshift-control-plane-2" deleted
      2. サービングシークレットを削除します。

        $ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd
        
        secret "etcd-serving-metrics-openshift-control-plane-2" deleted
      3. メトリクスシークレットを削除します。

        $ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd
        
        secret "etcd-serving-openshift-control-plane-2" deleted
  4. 正常でないメンバーのマシンを取得します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc get machines -n openshift-machine-api -o wide

    出力例

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                               PROVIDERID                                                                                              STATE
    examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 
    1
    
    examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
    examplecluster-control-plane-2    Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
    examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
    examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

    1
    これは正常でないノードのコントロールプレーンマシンです (examplecluster-control-plane-2)。
  5. 以下のコマンドを実行して、Bare Metal Operator が利用可能であることを確認します。

    $ oc get clusteroperator baremetal

    出力例

    NAME        VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    baremetal   4.20.0    True        False         False      3d15h

  6. 次のコマンドを実行して、古い BareMetalHost オブジェクトを削除します。

    $ oc delete bmh openshift-control-plane-2 -n openshift-machine-api

    出力例

    baremetalhost.metal3.io "openshift-control-plane-2" deleted

  7. 次のコマンドを実行して、異常なメンバーのマシンを削除します。

    $ oc delete machine -n openshift-machine-api examplecluster-control-plane-2

    BareMetalHost および Machine オブジェクトを削除すると、Machine コントローラーにより Node オブジェクトが自動的に削除されます。

    何らかの理由でマシンの削除が遅れたり、コマンドが妨げられて遅れたりする場合は、マシンオブジェクトのファイナライザーフィールドを削除することで強制的に削除できます。

    重要

    Ctrl+c を押してマシンの削除を中断しないでください。コマンドが完了するまで続行できるようにする必要があります。新しいターミナルウィンドウを開き、ファイナライザーフィールドを編集して削除します。

    正常でないメンバーのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

    1. 次のコマンドを実行して、マシン設定を編集します。

      $ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
    2. Machine カスタムリソースの次のフィールドを削除し、更新されたファイルを保存します。

      finalizers:
      - machine.machine.openshift.io

      出力例

      machine.machine.openshift.io/examplecluster-control-plane-2 edited

  8. 以下のコマンドを実行して、マシンが削除されていることを確認します。

    $ oc get machines -n openshift-machine-api -o wide

    出力例

    NAME                              PHASE     TYPE   REGION   ZONE   AGE     NODE                                 PROVIDERID                                                                                       STATE
    examplecluster-control-plane-0    Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned
    examplecluster-control-plane-1    Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
    examplecluster-compute-0          Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
    examplecluster-compute-1          Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

  9. 次のコマンドを実行して、ノードが削除されたことを確認します。

    $ oc get nodes
    
    NAME                     STATUS ROLES   AGE   VERSION
    openshift-control-plane-0 Ready master 3h24m v1.33.4
    openshift-control-plane-1 Ready master 3h24m v1.33.4
    openshift-compute-0       Ready worker 176m v1.33.4
    openshift-compute-1       Ready worker 176m v1.33.4
  10. 新しい BareMetalHost オブジェクトとシークレットを作成して BMC 認証情報を保存します。

    $ cat <<EOF | oc apply -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: openshift-control-plane-2-bmc-secret
      namespace: openshift-machine-api
    data:
      password: <password>
      username: <username>
    type: Opaque
    ---
    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: openshift-control-plane-2
      namespace: openshift-machine-api
    spec:
      automatedCleaningMode: disabled
      bmc:
        address: redfish://10.46.61.18:443/redfish/v1/Systems/1
        credentialsName: openshift-control-plane-2-bmc-secret
        disableCertificateVerification: true
      bootMACAddress: 48:df:37:b0:8a:a0
      bootMode: UEFI
      externallyProvisioned: false
      online: true
      rootDeviceHints:
        deviceName: /dev/disk/by-id/scsi-<serial_number>
      userData:
        name: master-user-data-managed
        namespace: openshift-machine-api
    EOF
    注記

    ユーザー名とパスワードは、他のベアメタルホストのシークレットで確認できます。bmc:address で使用するプロトコルは、他の bmh オブジェクトから取得できます。

    重要

    既存のコントロールプレーンホストから BareMetalHost オブジェクト定義を再利用する場合は、externallyProvisioned フィールドを true に設定したままにしないでください。

    既存のコントロールプレーン BareMetalHost オブジェクトが、OpenShift Container Platform インストールプログラムによってプロビジョニングされた場合には、externallyProvisioned フラグが true に設定されている可能性があります。

    検査が完了すると、BareMetalHost オブジェクトが作成され、プロビジョニングできるようになります。

  11. 利用可能な BareMetalHost オブジェクトを使用して作成プロセスを確認します。

    $ oc get bmh -n openshift-machine-api
    
    NAME                      STATE                  CONSUMER                      ONLINE ERROR   AGE
    openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
    openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
    openshift-control-plane-2 available              examplecluster-control-plane-3 true         47m
    openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
    openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m
    1. 新しいマシンが作成されたことを確認します。

      $ oc get machines -n openshift-machine-api -o wide

      出力例

      NAME                                   PHASE     TYPE   REGION   ZONE   AGE     NODE                              PROVIDERID                                                                                            STATE
      examplecluster-control-plane-0         Running                          3h11m   openshift-control-plane-0   baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e   externally provisioned 
      1
      
      examplecluster-control-plane-1         Running                          3h11m   openshift-control-plane-1   baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1   externally provisioned
      examplecluster-control-plane-2         Running                          3h11m   openshift-control-plane-2   baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135   externally provisioned
      examplecluster-compute-0               Running                          165m    openshift-compute-0         baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f         provisioned
      examplecluster-compute-1               Running                          165m    openshift-compute-1         baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9         provisioned

      1
      新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

      新規マシンが作成されるまでに数分の時間がかかります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。

    2. 以下のコマンドを実行して、ベアメタルホストがプロビジョニングされ、エラーが報告されていないことを確認します。

      $ oc get bmh -n openshift-machine-api

      出力例

      $ oc get bmh -n openshift-machine-api
      NAME                      STATE                  CONSUMER                       ONLINE ERROR AGE
      openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true         4h48m
      openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true         4h48m
      openshift-control-plane-2 provisioned            examplecluster-control-plane-3 true          47m
      openshift-compute-0       provisioned            examplecluster-compute-0       true         4h48m
      openshift-compute-1       provisioned            examplecluster-compute-1       true         4h48m

    3. 以下のコマンドを実行して、新規ノードが追加され、Ready の状態であることを確認します。

      $ oc get nodes

      出力例

      $ oc get nodes
      NAME                     STATUS ROLES   AGE   VERSION
      openshift-control-plane-0 Ready master 4h26m v1.33.4
      openshift-control-plane-1 Ready master 4h26m v1.33.4
      openshift-control-plane-2 Ready master 12m   v1.33.4
      openshift-compute-0       Ready worker 3h58m v1.33.4
      openshift-compute-1       Ready worker 3h58m v1.33.4

  12. 次のコマンドを入力して、クォーラムガードをオンに戻します。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'
  13. 次のコマンドを入力して、unsupportedConfigOverrides セクションがオブジェクトから削除されたことを確認できます。

    $ oc get etcd/cluster -oyaml
  14. シングルノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。

    出力例

    EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]

検証

  1. すべての etcd Pod が適切に実行されていることを確認します。

    クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc -n openshift-etcd get pods -l k8s-app=etcd

    出力例

    etcd-openshift-control-plane-0      5/5     Running     0     105m
    etcd-openshift-control-plane-1      5/5     Running     0     107m
    etcd-openshift-control-plane-2      5/5     Running     0     103m

    直前のコマンドの出力に 2 つの Pod のみがリスト表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 
    1
    1
    forceRedeploymentReason 値は一意である必要があります。そのため、タイムスタンプが付加されます。

    etcd メンバーがちょうど 3 つあることを確認するには、実行中の etcd コンテナーに接続し、影響を受けたノード上になかった Pod の名前を渡します。クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

    $ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
  2. メンバーのリストを確認します。

    sh-4.2# etcdctl member list -w table

    出力例

    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    |        ID        | STATUS  |        NAME        |        PEER ADDRS         |       CLIENT ADDRS        |    IS LEARNER    |
    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
    | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 |   false |
    | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 |   false |
    | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 |     false |
    +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+

    注記

    直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。

  3. 以下のコマンドを実行して、すべての etcd メンバーが正常であることを確認します。

    # etcdctl endpoint health --cluster

    出力例

    https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms
    https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms
    https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms

  4. 以下のコマンドを実行して、すべてのノードが最新のリビジョンであることを確認します。

    $ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'
    AllNodesAtLatestRevision

6.3. 障害復旧

6.3.1. 障害復旧について

この障害復旧ドキュメントでは、OpenShift Container Platform クラスターで発生する可能性のある複数の障害のある状態からの復旧方法に関する管理者向けの情報を提供しています。管理者は、クラスターの状態を機能する状態に戻すために、以下の 1 つまたは複数の手順を実行する必要がある場合があります。

重要

障害復旧には、少なくとも 1 つの正常なコントロールプレーンホストが必要です。

クォーラムの復元

このソリューションは、コントロールプレーンホストの大部分が失われ、etcd クォーラムが失われ、クラスターがオフラインになる状況に対処するものです。このソリューションでは、etcd のバックアップは必要ありません。

注記

コントロールプレーンノードの大部分がまだ使用可能であり、etcd のクォーラムがある場合は、1 つの異常な etcd メンバーを置き換えてください

以前のクラスター状態への復元

このソリューションは、管理者が重要なものを削除した場合など、クラスターを直前の状態に復元する必要がある状態に対応します。etcd のバックアップを作成した場合は、クラスターを以前の状態に復元できます。

該当する場合は、期限切れのコントロールプレーン証明書からの回復 も必要になる場合があります。

警告

以前のクラスター状態に復元することは、実行中のクラスターを不安定な状態にする破壊的な操作です。この手順は、最後の手段としてのみ使用してください。

復元の実行前に、クラスターへの影響の詳細について クラスターの復元 を参照してください。

コントロールプレーン証明書の期限切れの状態からのリカバリー
このソリューションは、コントロールプレーン証明書の期限が切れた状態に対応します。たとえば、インストールの 24 時間後に行われる最初の証明書のローテーション前にクラスターをシャットダウンする場合、証明書はローテーションされず、期限切れになります。以下の手順に従って、コントロールプレーン証明書の期限切れの状態からのリカバリーを実行できます。
6.3.1.1. 復元手順のテスト

自動化とワークロードが新しいクラスターの状態を適切に処理できるように、復元手順をテストすることが重要です。etcd クォーラムの複雑な性質と、etcd Operator による自動修復が原因で、クラスターを復元可能な状態に正しく戻すことが困難な場合がよくあります。

警告

クラスターへの SSH アクセス権が 必要 です。SSH アクセスがないと、クラスターが完全に失われる可能性があります。

前提条件

  • コントロールプレーンホストへの SSH アクセス権がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. SSH を使用してリカバリーノード以外の各ノードに接続し、次のコマンドを実行して etcd と kubelet サービスを無効にします。

    1. 次のコマンドを実行して etcd を無効にします。

      $ sudo /usr/local/bin/disable-etcd.sh
    2. 次のコマンドを実行して、etcd の変数データを削除します。

      $ sudo rm -rf /var/lib/etcd
    3. 次のコマンドを実行して、kubelet サービスを無効にします。

      $ sudo systemctl disable kubelet.service
  2. すべての SSH セッションを終了します。
  3. 次のコマンドを実行して、リカバリーノード以外のノードが NOT READY 状態であることを確認します。

    $ oc get nodes
  4. 「以前のクラスター状態への復元」の手順に従い、クラスターを復元します。
  5. クラスターを復元し、API が応答したら、SSH を使用してリカバリーノード以外の各ノードに接続し、kubelet サービスを有効にします。

    $ sudo systemctl enable kubelet.service
  6. すべての SSH セッションを終了します。
  7. 次のコマンドを実行して、ノードが READY 状態に戻ることを確認します。

    $ oc get nodes
  8. 次のコマンドを実行して、etcd が利用可能であることを確認します。

    $ oc get pods -n openshift-etcd

6.3.2. クォーラムの復元

quorum-restore.sh スクリプトを使用すると、クォーラムの喪失によりオフラインになっているクラスターの etcd クォーラムを復元できます。クォーラムが失われると、OpenShift Container Platform API が読み取り専用になります。クォーラムが復元されると、OpenShift Container Platform API は読み取り/書き込みモードに戻ります。

6.3.2.1. 高可用性クラスターの etcd クォーラムの復元

quorum-restore.sh スクリプトを使用すると、クォーラムの喪失によりオフラインになっているクラスターの etcd クォーラムを復元できます。クォーラムが失われると、OpenShift Container Platform API が読み取り専用になります。クォーラムが復元されると、OpenShift Container Platform API は読み取り/書き込みモードに戻ります。

quorum-restore.sh スクリプトは、ローカルのデータディレクトリーに基づいてシングルメンバーの新しい etcd クラスターを即座に戻し、以前のクラスター識別子を廃止して他のすべてのメンバーを無効としてマークします。コントロールプレーンを復元するために事前のバックアップは必要ありません。

高可用性 (HA) クラスターの場合、3 ノードの HA クラスターでは、クラスターの分割を回避するために、2 つのホストで etcd をシャットダウンする必要があります。4 ノードおよび 5 ノードの HA クラスターでは、3 つのホストをシャットダウンする必要があります。クォーラムにはノードの単純過半数が必要です。3 ノードの HA クラスターのクォーラムに必要なノードの最小数は 2 です。4 ノードおよび 5 ノードの HA クラスターでは、クォーラムに必要なノードの最小数は 3 です。リカバリーホスト上のバックアップから新しいクラスターを起動すると、他の etcd メンバーがクォーラムを形成してサービスを継続できる可能性があります。

警告

復元を実行するホストにすべてのデータがレプリケートされていない場合、データが失われる可能性があります。

重要

クォーラムの復元は、復元プロセス外のノード数を減らすために使用しないでください。ノードの数を減らすと、サポート対象外のクラスター設定になります。

前提条件

  • クォーラムを復元するために使用するノードへの SSH アクセス権がある。

手順

  1. リカバリーホストとして使用するコントロールプレーンホストを選択します。このホストで復元操作を実行します。

    1. 次のコマンドを実行して、実行中の etcd Pod をリスト表示します。

      $ oc get pods -n openshift-etcd -l app=etcd --field-selector="status.phase==Running"
    2. Pod を 1 つ選択し、次のコマンドを実行してその IP アドレスを取得します。

      $ oc exec -n openshift-etcd <etcd-pod> -c etcdctl -- etcdctl endpoint status -w table

      Raft インデックスが最も大きく、Learner ではないメンバーの IP アドレスをメモします。

    3. 次のコマンドを実行し、選択した etcd メンバーの IP アドレスに対応するノード名をメモします。

      $ oc get nodes -o jsonpath='{range .items[*]}[{.metadata.name},{.status.addresses[?(@.type=="InternalIP")].address}]{end}'
  2. SSH を使用して、選択したリカバリーノードに接続し、次のコマンドを実行して etcd クォーラムを復元します。

    $ sudo -E /usr/local/bin/quorum-restore.sh

    数分後、ダウンしたノードが、リカバリースクリプトを実行したノードと自動的に同期されます。残りのオンラインのノードは、quorum-restore.sh スクリプトによって作成された新しい etcd クラスターに自動的に再参加します。このプロセスには数分かかります。

  3. SSH セッションを終了します。
  4. いずれかのノードがオフラインの場合は、3 ノード設定に戻ります。オフラインになっているノードごとに次の手順を繰り返して、ノードを削除し、再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。

    • ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

    • installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。

      警告

      リカバリーホストのマシンを削除し、再作成しないでください。

      installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。

      1. いずれかのオフラインノードのマシンを取得します。

        クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。

        $ oc get machines -n openshift-machine-api -o wide

        出力例

        NAME                                        PHASE     TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
        clustername-8qw5l-master-0                  Running   m4.xlarge   us-east-1   us-east-1a   3h37m   ip-10-0-131-183.ec2.internal   aws:///us-east-1a/i-0ec2782f8287dfb7e   stopped 
        1
        
        clustername-8qw5l-master-1                  Running   m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
        clustername-8qw5l-master-2                  Running   m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
        clustername-8qw5l-worker-us-east-1a-wbtgd   Running   m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
        clustername-8qw5l-worker-us-east-1b-lrdxb   Running   m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
        clustername-8qw5l-worker-us-east-1c-pkg26   Running   m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

        1
        これは、オフラインノード ip-10-0-131-183.ec2.internal のコントロールプレーンマシンです。
      2. 次のコマンドを実行して、オフラインノードのマシンを削除します。

        $ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 
        1
        1
        オフラインノードのコントロールプレーンマシンの名前を指定します。

        オフラインノードのマシンを削除すると、新しいマシンが自動的にプロビジョニングされます。

  5. 以下を実行して、新しいマシンが作成されたことを確認します。

    $ oc get machines -n openshift-machine-api -o wide

    出力例

    NAME                                        PHASE          TYPE        REGION      ZONE         AGE     NODE                           PROVIDERID                              STATE
    clustername-8qw5l-master-1                  Running        m4.xlarge   us-east-1   us-east-1b   3h37m   ip-10-0-143-125.ec2.internal   aws:///us-east-1b/i-096c349b700a19631   running
    clustername-8qw5l-master-2                  Running        m4.xlarge   us-east-1   us-east-1c   3h37m   ip-10-0-154-194.ec2.internal    aws:///us-east-1c/i-02626f1dba9ed5bba  running
    clustername-8qw5l-master-3                  Provisioning   m4.xlarge   us-east-1   us-east-1a   85s     ip-10-0-173-171.ec2.internal    aws:///us-east-1a/i-015b0888fe17bc2c8  running 
    1
    
    clustername-8qw5l-worker-us-east-1a-wbtgd   Running        m4.large    us-east-1   us-east-1a   3h28m   ip-10-0-129-226.ec2.internal   aws:///us-east-1a/i-010ef6279b4662ced   running
    clustername-8qw5l-worker-us-east-1b-lrdxb   Running        m4.large    us-east-1   us-east-1b   3h28m   ip-10-0-144-248.ec2.internal   aws:///us-east-1b/i-0cb45ac45a166173b   running
    clustername-8qw5l-worker-us-east-1c-pkg26   Running        m4.large    us-east-1   us-east-1c   3h28m   ip-10-0-170-181.ec2.internal   aws:///us-east-1c/i-06861c00007751b0a   running

    1
    新規マシン clustername-8qw5l-master-3 が作成され、Provisioning から Running にフェーズが変更されると準備状態になります。

    新規マシンが作成されるまでに数分の時間がかかる場合があります。マシンまたはノードが正常な状態に戻ると、etcd クラスター Operator が自動的に同期します。

    1. オフラインになっているノードごとに上記の手順を繰り返します。
  6. 次のコマンドを実行して、コントロールプレーンが回復するまで待ちます。

    $ oc adm wait-for-stable-cluster
    注記

    コントロールプレーンが回復するまでに最大 15 分かかります。

トラブルシューティング

  • etcd 静的 Pod のロールアウトが進行していない場合は、次のコマンドを実行して、etcd クラスター Operator から強制的に再デプロイを実行できます。

    $ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge

6.3.3. 以前のクラスター状態への復元

クラスターを以前の状態に復元するには、スナップショットを作成して etcd データを事前にバックアップしておく必要があります。このスナップショットを使用して、クラスターの状態を復元します。詳細は、「etcd データのバックアップ」を参照してください。

6.3.3.1. 以前のクラスター状態への復元について

クラスターを以前の状態に復元するには、スナップショットを作成して etcd データを事前にバックアップしておく必要があります。このスナップショットを使用して、クラスターの状態を復元します。詳細は、「etcd データのバックアップ」を参照してください。

etcd バックアップを使用して、クラスターを直前の状態に復元できます。これは、以下の状況から回復するために使用できます。

  • クラスターは、大多数のコントロールプレーンホストを失いました (クォーラムの喪失)。
  • 管理者が重要なものを削除し、クラスターを復旧するために復元する必要があります。
警告

以前のクラスター状態に復元することは、実行中のクラスターを不安定な状態にする破壊的な操作です。これは、最後の手段としてのみ使用してください。

Kubernetes API サーバーを使用してデータを取得できる場合は、etcd が利用できるため、etcd バックアップを使用して復元することはできません。

etcd を効果的に復元すると、クラスターが時間内に元に戻され、すべてのクライアントは競合する並列履歴が発生します。これは、kubelet、Kubernetes コントローラーマネージャー、永続ボリュームコントローラー、OpenShift Container Platform Operator (ネットワーク Operator を含む) などの監視コンポーネントの動作に影響を与える可能性があります。

etcd のコンテンツがディスク上の実際のコンテンツと一致しないと、Operator チャーンが発生し、ディスク上のファイルが etcd のコンテンツと競合すると、Kubernetes API サーバー、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーなどの Operator が停止する場合があります。この場合は、問題の解決に手動のアクションが必要になる場合があります。

極端な場合、クラスターは永続ボリュームを追跡できなくなり、存在しなくなった重要なワークロードを削除し、マシンのイメージを再作成し、期限切れの証明書を使用して CA バンドルを書き換えることができます。

6.3.3.2. シングルノードで以前のクラスター状態に復元する

保存された etcd バックアップを使用して、シングルノードでクラスターの以前の状態を復元できます。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.20.2 クラスターは、4.20.2 から取得した etcd バックアップを使用する必要があります。

前提条件

  • インストール時に使用したものと同様、証明書ベースの kubeconfig ファイルを介して、cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。
  • コントロールプレーンホストへの SSH アクセス権がある。
  • etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。

手順

  1. SSH を使用してシングルノードに接続し、次のコマンドを実行して etcd バックアップを /home/core ディレクトリーにコピーします。

    $ cp <etcd_backup_directory> /home/core
  2. シングルノードで次のコマンドを実行し、以前のバックアップからクラスターを復元します。

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd_backup_directory>
  3. SSH セッションを終了します。
  4. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。

    $ oc adm wait-for-stable-cluster
    注記

    コントロールプレーンが回復するまでに最大 15 分かかります。

6.3.3.3. 複数のノードの以前のクラスター状態への復元

保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。

高可用性 (HA) クラスターの場合、3 ノードの HA クラスターでは、クラスターの分割を回避するために、2 つのホストで etcd をシャットダウンする必要があります。4 ノードおよび 5 ノードの HA クラスターでは、3 つのホストをシャットダウンする必要があります。クォーラムにはノードの単純過半数が必要です。3 ノードの HA クラスターのクォーラムに必要なノードの最小数は 2 です。4 ノードおよび 5 ノードの HA クラスターでは、クォーラムに必要なノードの最小数は 3 です。リカバリーホスト上のバックアップから新しいクラスターを起動すると、他の etcd メンバーがクォーラムを形成してサービスを継続できる可能性があります。

注記

クラスターがコントロールプレーンマシンセットを使用している場合は、「コントロールプレーンマシンセットのトラブルシューティング」の「劣化した etcd Operator のリカバリー」で etcd のリカバリー手順を参照してください。シングルノード上の OpenShift Container Platform は、「シングルノードで以前のクラスター状態に復元する」を参照してください。

重要

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.20.2 クラスターは、4.20.2 から取得した etcd バックアップを使用する必要があります。

前提条件

  • インストール時に使用したものと同様、証明書ベースの kubeconfig ファイルを介して、cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。
  • リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
  • コントロールプレーンホストへの SSH アクセス権がある。
  • etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。
  • ノードはアクセス可能またはブート可能である。
重要

非リカバリーコントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。

手順

  1. リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作の実行対象とするホストです。
  2. リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。

    kube-apiserver は復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。

    重要

    この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

  3. SSH を使用して各コントロールプレーンノードに接続し、次のコマンドを実行して etcd を無効にします。

    $ sudo -E /usr/local/bin/disable-etcd.sh
  4. etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。

    この手順では、etcd スナップショットおよび静的 Pod のリソースを含む backup ディレクトリーを、リカバリーコントロールプレーンホストの /home/core/ ディレクトリーにコピーしていることを前提としています。

  5. SSH を使用してリカバリーホストに接続し、次のコマンドを実行して以前のバックアップからクラスターを復元します。

    $ sudo -E /usr/local/bin/cluster-restore.sh /home/core/<etcd-backup-directory>
  6. SSH セッションを終了します。
  7. API が応答したら、次のコマンドを実行して etcd Operator のクォーラムガードをオフにします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
  8. 次のコマンドを実行して、コントロールプレーンの回復の進行状況を監視します。

    $ oc adm wait-for-stable-cluster
    注記

    コントロールプレーンが回復するまでに最大 15 分かかります。

  9. 回復したら、次のコマンドを実行してクォーラムガードを有効にします。

    $ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'

トラブルシューティング

etcd 静的 Pod のロールアウトが進行していない場合は、次のコマンドを実行して、cluster-etcd-operator から強制的に再デプロイを実行できます。

$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$(date --rfc-3339=ns )"'"}}' --type=merge
6.3.3.4. etcd バックアップからのクラスターの手動復元

「以前のクラスター状態への復元」セクションで説明されている復元手順は次のとおりです。

  • 2 つのコントロールプレーンノードを完全に再作成する必要があります。ただし、UPI インストール方式でインストールされたクラスターでは複雑な手順になる可能性があります。UPI インストールでは、コントロールプレーンノード用の Machine または ControlPlaneMachineset が作成されないためです。
  • /usr/local/bin/cluster-restore.sh スクリプトを使用して、シングルメンバーの新しい etcd クラスターを起動し、それを 3 つのメンバーに拡張します。

これに対し、この手順は次の点が異なります。

  • コントロールプレーンノードを再作成する必要はありません。
  • 3 つのメンバーからなる etcd クラスターを直接起動します。

クラスターがコントロールプレーンに MachineSet を使用する場合は、etcd の回復手順を簡素化するために、「以前のクラスター状態への復元」を使用することを推奨します。

クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.7.2 クラスターは、4.7.2 から取得した etcd バックアップを使用する必要があります。

前提条件

  • cluster-admin ロールを持つユーザー (例: kubeadmin ユーザー) としてクラスターにアクセスします。
  • すべて のコントロールプレーンホストへの SSH アクセス権があり、ホストユーザーが root (デフォルトの core ホストユーザーなど) になることが許可されている。
  • 同じバックアップからの以前の etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー。ディレクトリー内のファイル名は、snapshot_<datetimestamp>.db および static_kuberesources_<datetimestamp>.tar.gz の形式にする必要があります。

手順

  1. SSH を使用して各コントロールプレーンノードに接続します。

    Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、アクセスするコントロールプレーンホストごとに、別のターミナルで SSH 接続を使用することを推奨します。

    重要

    この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。

  2. etcd バックアップディレクトリーを各コントロールプレーンホストにコピーします。

    この手順では、etcd スナップショットと静的 Pod のリソースを含む backup ディレクトリーを各コントロールプレーンホストの /home/core/assets ディレクトリーにコピーしていることを前提としています。この assets フォルダーがまだ存在しない場合は、作成する必要がある場合があります。

  3. すべてのコントロールプレーンノード上の静的 Pod を、一度に 1 つのホストずつ停止します。

    1. 既存の Kubernetes API サーバーの静的 Pod マニフェストを kubelet マニフェストディレクトリーから移動します。

      $ mkdir -p /root/manifests-backup
      $ mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /root/manifests-backup/
    2. 次のコマンドを使用して、Kubernetes API Server コンテナーが停止したことを確認します。

      $ crictl ps | grep kube-apiserver | grep -E -v "operator|guard"

      コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。

    3. Kubernetes API サーバーコンテナーがまだ実行中の場合は、次のコマンドを使用して手動で終了します。

      $ crictl stop <container_id>
    4. 同じ手順を、kube-controller-manager-pod.yamlkube-scheduler-pod.yaml最後に etcd-pod.yaml に対して繰り返します。

      1. 次のコマンドで kube-controller-manager Pod を停止します。

        $ mv /etc/kubernetes/manifests/kube-controller-manager-pod.yaml /root/manifests-backup/
      2. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。

        $ crictl ps | grep kube-controller-manager | grep -E -v "operator|guard"
      3. 次のコマンドを使用して、kube-scheduler Pod を停止します。

        $ mv /etc/kubernetes/manifests/kube-scheduler-pod.yaml /root/manifests-backup/
      4. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。

        $ crictl ps | grep kube-scheduler | grep -E -v "operator|guard"
      5. 次のコマンドを使用して etcd Pod を停止します。

        $ mv /etc/kubernetes/manifests/etcd-pod.yaml /root/manifests-backup/
      6. 次のコマンドを使用して、コンテナーが停止しているかどうかを確認します。

        $ crictl ps | grep etcd | grep -E -v "operator|guard"
  4. 各コントロールプレーンホストで、現在の etcd データを backup フォルダーに移動して保存します。

    $ mkdir /home/core/assets/old-member-data
    $ mv /var/lib/etcd/member /home/core/assets/old-member-data

    このデータは、etcd バックアップの復元が機能せず、etcd クラスターを現在の状態に復元する必要がある場合に役立ちます。

  5. 各コントロールプレーンホストの正しい etcd パラメーターを確認します。

    1. <ETCD_NAME> の値は、各コントロールプレーンホストごとに一意であり、特定のコントロールプレーンホストのマニフェスト /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml ファイル内にある ETCD_NAME 変数の値と同じです。次のコマンドで確認できます。

      RESTORE_ETCD_POD_YAML="/etc/kubernetes/static-pod-resources/etcd-certs/configmaps/restore-etcd-pod/pod.yaml"
      cat $RESTORE_ETCD_POD_YAML | \
        grep -A 1 $(cat $RESTORE_ETCD_POD_YAML | grep 'export ETCD_NAME' | grep -Eo 'NODE_.+_ETCD_NAME') | \
        grep -Po '(?<=value: ").+(?=")'
    2. <UUID> の値は、次のコマンドを使用してコントロールプレーンホストで生成できます。

      $ uuidgen
      注記

      <UUID> の値は 1 回だけ生成する必要があります。1 つのコントロールプレーンホストで UUID を生成した後あ、他のホストで再度生成しないでください。次の手順では、すべてのコントロールプレーンホストで同じ UUID を使用します。

    3. ETCD_NODE_PEER_URL の値は、次の例のように設定する必要があります。

      https://<IP_CURRENT_HOST>:2380

      正しい IP は、次のコマンドを使用して、特定のコントロールプレーンホストの <ETCD_NAME> から確認できます。

      $ echo <ETCD_NAME> | \
        sed -E 's/[.-]/_/g' | \
        xargs -I {} grep {} /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env | \
        grep "IP" | grep -Po '(?<=").+(?=")'
    4. <ETCD_INITIAL_CLUSTER> の値は、次のように設定する必要があります。<ETCD_NAME_n> は各コントロールプレーンホストの <ETCD_NAME> です。

      注記

      使用するポートは 2379 ではなく 2380 である必要があります。ポート 2379 は etcd データベース管理に使用され、コンテナー内の etcd 起動コマンドで直接設定されます。

      出力例

      <ETCD_NAME_0>=<ETCD_NODE_PEER_URL_0>,<ETCD_NAME_1>=<ETCD_NODE_PEER_URL_1>,<ETCD_NAME_2>=<ETCD_NODE_PEER_URL_2> 
      1

      1
      各コントロールプレーンホストの ETCD_NODE_PEER_URL 値を指定します。

      <ETCD_INITIAL_CLUSTER> 値は、すべてのコントロールプレーンホストで同じです。次の手順では、すべてのコントロールプレーンホストで同じ値が必要です。

  6. バックアップから etcd データベースを再生成します。

    この操作は、各コントロールプレーンホストで実行する必要があります。

    1. 次のコマンドを使用して、etcd バックアップを /var/lib/etcd ディレクトリーにコピーします。

      $ cp /home/core/assets/backup/<snapshot_yyyy-mm-dd_hhmmss>.db /var/lib/etcd
    2. 続行する前に、正しい etcdctl イメージを特定します。次のコマンドを使用して、Pod マニフェストのバックアップからイメージを取得します。

      $ jq -r '.spec.containers[]|select(.name=="etcdctl")|.image' /root/manifests-backup/etcd-pod.yaml
      $ podman run --rm -it --entrypoint="/bin/bash" -v /var/lib/etcd:/var/lib/etcd:z <image-hash>
    3. etcdctl ツールのバージョンが、バックアップが作成された etcd サーバーのバージョンであることを確認します。

      $ etcdctl version
    4. 現在のホストの正しい値を使用して次のコマンドを実行し、etcd データベースを再生成します。

      $ ETCDCTL_API=3 /usr/bin/etcdctl snapshot restore /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db \
        --name "<ETCD_NAME>" \
        --initial-cluster="<ETCD_INITIAL_CLUSTER>" \
        --initial-cluster-token "openshift-etcd-<UUID>" \
        --initial-advertise-peer-urls "<ETCD_NODE_PEER_URL>" \
        --data-dir="/var/lib/etcd/restore-<UUID>" \
        --skip-hash-check=true
      注記

      etcd データベースを再生成する場合、引用符は必須です。

  7. added member ログに出力される値を記録します。次に例を示します。

    出力例

    2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "56cd73b614699e7", "added-peer-peer-urls": ["https://10.0.91.5:2380"], "added-peer-is-learner": false}
    2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "1f63d01b31bb9a9e", "added-peer-peer-urls": ["https://10.0.90.221:2380"], "added-peer-is-learner": false}
    2022-06-28T19:52:43Z    info    membership/cluster.go:421   added member    {"cluster-id": "c5996b7c11c30d6b", "local-member-id": "0", "added-peer-id": "fdc2725b3b70127c", "added-peer-peer-urls": ["https://10.0.94.214:2380"], "added-peer-is-learner": false}

    1. コンテナーから出ます。
    2. この手順を他のコントロールプレーンホストでも繰り返し、added member ログに出力される値がすべてのコントロールプレーンホストで同じであることを確認します。
  8. 再生成された etcd データベースをデフォルトの場所に移動します。

    この操作は、各コントロールプレーンホストで実行する必要があります。

    1. 再生成されたデータベース (以前の etcdctl snapshot restore コマンドによって作成された member フォルダー) を、デフォルトの etcd の場所 /var/lib/etcd に移動します。

      $ mv /var/lib/etcd/restore-<UUID>/member /var/lib/etcd
    2. /var/lib/etcd ディレクトリーの /var/lib/etcd/member フォルダーの SELinux コンテキストを復元します。

      $ restorecon -vR /var/lib/etcd/
    3. 残りのファイルとディレクトリーを削除します。

      $ rm -rf /var/lib/etcd/restore-<UUID>
      $ rm /var/lib/etcd/<snapshot_yyyy-mm-dd_hhmmss>.db
      重要

      完了すると、/var/lib/etcd ディレクトリーに含まれるフォルダーが member だけになります。

    4. 他のコントロールプレーンホストでもこの手順を繰り返します。
  9. etcd クラスターを再起動します。

    1. 次の手順は、すべてのコントロールプレーンホストで実行する必要があります。ただし、一度に 1 つのホストずつ 実行する必要があります。
    2. kubelet が関連コンテナーを起動するように、etcd 静的 Pod マニフェストを kubelet マニフェストディレクトリーに戻します。

      $ mv /root/manifests-backup/etcd-pod.yaml /etc/kubernetes/manifests
    3. すべての etcd コンテナーが起動していることを確認します。

      $ crictl ps | grep etcd | grep -v operator

      出力例

      38c814767ad983       f79db5a8799fd2c08960ad9ee22f784b9fbe23babe008e8a3bf68323f004c840                                                         28 seconds ago       Running             etcd-health-monitor                   2                   fe4b9c3d6483c
      e1646b15207c6       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd-metrics                          0                   fe4b9c3d6483c
      08ba29b1f58a7       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcd                                  0                   fe4b9c3d6483c
      2ddc9eda16f53       9d28c15860870e85c91d0e36b45f7a6edd3da757b113ec4abb4507df88b17f06                                                         About a minute ago   Running             etcdctl

      このコマンドの出力が空の場合は、数分待ってからもう一度確認してください。

  10. etcd クラスターのステータスを確認します。

    1. いずれかのコントロールプレーンホストで、次のコマンドを使用して etcd クラスターのステータスを確認します。

      $ crictl exec -it $(crictl ps | grep etcdctl | awk '{print $1}') etcdctl endpoint status -w table

      出力例

      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      |         ENDPOINT         |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
      | https://10.0.89.133:2379 | 682e4a83a0cec6c0 |   3.5.0 |   67 MB |      true |      false |         2 |        218 |                218 |        |
      |  https://10.0.92.74:2379 | 450bcf6999538512 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
      | https://10.0.93.129:2379 | 358efa9c1d91c3d6 |   3.5.0 |   67 MB |     false |      false |         2 |        218 |                218 |        |
      +--------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+

  11. 他の静的 Pod を再起動します。

    次の手順は、すべてのコントロールプレーンホストで実行する必要があります。ただし、一度に 1 つのホストずつ実行する必要があります。

    1. 次のコマンドを使用して、Kubernetes API サーバーの静的 Pod マニフェストを kubelet マニフェストディレクトリーに戻し、kubelet が関連するコンテナーを起動するようにします。

      $ mv /root/manifests-backup/kube-apiserver-pod.yaml /etc/kubernetes/manifests
    2. すべての Kubernetes API サーバーコンテナーが起動したことを確認します。

      $ crictl ps | grep kube-apiserver | grep -v operator
      注記

      次のコマンドの出力が空の場合は、数分待ってからもう一度確認してください。

    3. 同じ手順を、kube-controller-manager-pod.yaml ファイルと kube-scheduler-pod.yaml ファイルに対して繰り返します。

      1. 次のコマンドを使用して、すべてのノードで kubelet を再起動します。

        $ systemctl restart kubelet
      2. 次のコマンドを使用して、残りのコントロールプレーン Pod を起動します。

        $ mv /root/manifests-backup/kube-* /etc/kubernetes/manifests/
      3. kube-apiserverkube-scheduler、および kube-controller-manager Pod が正しく起動しているかどうかを確認します。

        $ crictl ps | grep -E 'kube-(apiserver|scheduler|controller-manager)' | grep -v -E 'operator|guard'
      4. 次のコマンドを使用して OVN データベースをワイプします。

        for NODE in  $(oc get node -o name | sed 's:node/::g')
        do
          oc debug node/${NODE} -- chroot /host /bin/bash -c  'rm -f /var/lib/ovn-ic/etc/ovn*.db && systemctl restart ovs-vswitchd ovsdb-server'
          oc -n openshift-ovn-kubernetes delete pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --wait
          oc -n openshift-ovn-kubernetes wait pod -l app=ovnkube-node --field-selector=spec.nodeName=${NODE} --for condition=ContainersReady --timeout=600s
        done
6.3.3.6. 永続ストレージの状態復元に関する問題および回避策

OpenShift Container Platform クラスターがいずれかの形式の永続ストレージを使用する場合に、クラスターの状態は通常 etcd 外に保存されます。etcd バックアップから復元する場合には、OpenShift Container Platform のワークロードのステータスも復元されます。ただし、etcd スナップショットが古い場合には、ステータスは無効または期限切れの可能性があります。

重要

永続ボリューム (PV) の内容は etcd スナップショットには含まれません。etcd スナップショットから OpenShift Container Platform クラスターを復元する時に、重要ではないワークロードから重要なデータにアクセスしたり、その逆ができたりする場合があります。

以下は、古いステータスを生成するシナリオ例です。

  • MySQL データベースが PV オブジェクトでバックアップされる Pod で実行されている。etcd スナップショットから OpenShift Container Platform を復元すると、Pod の起動を繰り返し試行しても、ボリュームをストレージプロバイダーに戻したり、実行中の MySQL Pod が生成したりされるわけではありません。この Pod は、ストレージプロバイダーでボリュームを復元し、次に PV を編集して新規ボリュームを参照するように手動で復元する必要があります。
  • Pod P1 は、ノード X に割り当てられているボリューム A を使用している。別の Pod がノード Y にある同じボリュームを使用している場合に etcd スナップショットが作成された場合に、etcd の復元が実行されると、ボリュームがノード Y に割り当てられていることが原因で Pod P1 が正常に起動できなくなる可能性があります。OpenShift Container Platform はこの割り当てを認識せず、ボリュームが自動的に切り離されるわけではありません。これが生じる場合には、ボリュームをノード Y から手動で切り離し、ノード X に割り当ててることで Pod P1 を起動できるようにします。
  • クラウドプロバイダーまたはストレージプロバイダーの認証情報が etcd スナップショットの作成後に更新された。これが原因で、プロバイダーの認証情報に依存する CSI ドライバーまたは Operator が機能しなくなります。これらのドライバーまたは Operator で必要な認証情報を手動で更新する必要がある場合があります。
  • デバイスが etcd スナップショットの作成後に OpenShift Container Platform ノードから削除されたか、名前が変更された。ローカルストレージ Operator で、/dev/disk/by-id または /dev ディレクトリーから管理する各 PV のシンボリックリンクが作成されます。この状況では、ローカル PV が存在しないデバイスを参照してしまう可能性があります。

    この問題を修正するには、管理者は以下を行う必要があります。

    1. デバイスが無効な PV を手動で削除します。
    2. 各ノードからシンボリックリンクを削除します。
    3. LocalVolume または LocalVolumeSet オブジェクトを削除します (ストレージ永続ストレージの設定ローカルボリュームを使用した永続ストレージローカルストレージ Operator のリソースの削除 を参照)。

6.3.4. コントロールプレーン証明書の期限切れの状態からのリカバリー

6.3.4.1. コントロールプレーン証明書の期限切れの状態からのリカバリー

クラスターはコントロールプレーン証明書の期限切れの状態から自動的に回復できます。

ただし、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。ユーザーによってプロビジョニングされるインストールの場合は、保留中の kubelet 提供の CSR を承認しないといけない場合があります。

保留中の CSR を承認するには、以下の手順に従います。

手順

  1. 現在の CSR の一覧を取得します。

    $ oc get csr

    出力例

    NAME        AGE    SIGNERNAME                                    REQUESTOR                                                                   CONDITION
    csr-2s94x   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending 
    1
    
    csr-4bd6t   8m3s   kubernetes.io/kubelet-serving                 system:node:<node_name>                                                     Pending
    csr-4hl85   13m    kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending 
    2
    
    csr-zhhhp   3m8s   kubernetes.io/kube-apiserver-client-kubelet   system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
    ...

    1
    保留中の kubelet サービス CSR (ユーザーがプロビジョニングしたインストール用)。
    2
    保留中の node-bootstrapper CSR。
  2. CSR の詳細をレビューし、これが有効であることを確認します。

    $ oc describe csr <csr_name> 
    1
    1
    <csr_name> は、現行の CSR のリストからの CSR の名前です。
  3. それぞれの有効な node-bootstrapper CSR を承認します。

    $ oc adm certificate approve <csr_name>
  4. ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。

    $ oc adm certificate approve <csr_name>
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る