検索

4.2. OADP リリースノート

download PDF

4.2.1. OADP 1.4 リリースノート

OpenShift API for Data Protection (OADP) のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。

4.2.1.1. OADP 1.4.1 リリースノート

OpenShift API for Data Protection (OADP) 1.4.1 リリースノートには、新機能、解決された問題とバグ、既知の問題が記載されています。

4.2.1.1.1. 新機能

クライアントの QPS とバーストを更新するための新しい DPA フィールド

新しい Data Protection Application (DPA) フィールドを使用して、Velero Server Kubernetes API の 1 秒あたりのクエリー数とバースト値を変更できるようになりました。新しい DPA フィールドは、spec.configuration.velero.client-qpsspec.configuration.velero.client-burst です。どちらもデフォルトは 100 です。OADP-4076

Kopia でデフォルト以外のアルゴリズムを有効にする

この更新により、Kopia のハッシュ、暗号化、およびスプリッターアルゴリズムを設定して、デフォルト以外のオプションを選択し、さまざまなバックアップワークロードのパフォーマンスを最適化できるようになりました。

これらのアルゴリズムを設定するには、DataProtectionApplication (DPA) 設定の podConfig セクションで velero Pod の env 変数を設定します。この変数が設定されていない場合、またはサポートされていないアルゴリズムが選択されている場合、Kopia はデフォルトで標準アルゴリズムを使用します。OADP-4640

4.2.1.1.2. 解決した問題

Pod なしでバックアップを正常に復元できるようになる

以前は、Pod なしでバックアップを復元し、StorageClass VolumeBindingModeWaitForFirstConsumer に設定すると、PartiallyFailed ステータスになり、fail to patch dynamic PV, err: context deadline exceeded というエラーが発生していました。この更新により、動的 PV のパッチ適用がスキップされ、バックアップの復元が成功するようになり、PartiallyFailed ステータスが発生しなくなりました。OADP-4231

PodVolumeBackup CR が正しいメッセージを表示するようになる

以前は、PodVolumeBackup カスタムリソース (CR) によって、get a podvolumebackup with status "InProgress" during the server starting, mark it as "Failed" という誤ったメッセージが生成されていました。この更新により、次のメッセージが生成されるようになりました。

found a podvolumebackup with status "InProgress" during the server starting,
mark it as "Failed".

OADP-4224

DPA で imagePullPolicy をオーバーライドできるようになる

以前は、OADP がすべてのイメージに対して imagePullPolicy パラメーターを Always に設定していました。この更新により、OADP が各イメージに sha256 または sha512 ダイジェストが含まれているかどうかを確認し、imagePullPolicyIfNotPresent に設定するようになりました。含まれていない場合、imagePullPolicyAlways に設定されます。このポリシーは、新しい spec.containerImagePullPolicy DPA フィールドを使用してオーバーライドできるようになりました。OADP-4172

OADP Velero が、最初の更新が失敗した場合に復元ステータスの更新を再試行できるようになる

以前は、OADP Velero が復元された CR ステータスの更新に失敗していました。これにより、ステータスが無期限に InProgress のままになっていました。バックアップおよび復元 CR のステータスに依存して完了を判断するコンポーネントも失敗していました。この更新により、復元の際に、復元 CR のステータスが Completed または Failed ステータスに正しく移行するようになりました。OADP-3227

別のクラスターからの BuildConfig ビルド復元がエラーなしで正常に処理されるようになる

以前は、別のクラスターから BuildConfig ビルドリソースの復元を実行すると、アプリケーションが内部イメージレジストリーへの TLS 検証時にエラーを生成していました。結果として、failed to verify certificate: x509: certificate signed by unknown authority エラーが発生していました。この更新により、別のクラスターへの BuildConfig ビルドリソース復元が正常に処理されるようになり、failed to verify certificate エラーが生成されなくなりました。OADP-4692

空の PVC が正常に復元されるようになる

以前は、空の永続ボリューム要求 (PVC) を復元中にデータのダウンロードが失敗していました。次のエラーで失敗していました。

data path restore failed: Failed to run kopia restore: Unable to load
    snapshot : snapshot not found

この更新により、空の PVC を復元するときにデータのダウンロードが正しく終了するようになり、エラーメッセージが生成されなくなりました。OADP-3106

CSI および DataMover プラグインで Velero のメモリーリークが発生しなくなる

以前は、CSI および DataMover プラグインの使用によって Velero のメモリーリークが発生していました。バックアップが終了したときに、Velero プラグインインスタンスが削除されず、Velero Pod で Out of Memory (OOM) 状態が生成されるまで、メモリーリークによってメモリーが消費されていました。この更新により、CSI および DataMover プラグインの使用時に Velero のメモリーリークが発生しなくなりました。OADP-4448

関連する PV が解放されるまで、ポストフック操作が開始されなくなる

以前は、Data Mover 操作の非同期性により、関連する Pod の永続ボリューム (PV) が Data Mover の永続ボリューム要求 (PVC) によって解放される前に、ポストフックが試行されることがありました。この問題により、バックアップが PartiallyFailed ステータスで失敗していました。この更新により、関連する PV が Data Mover PVC によって解放されるまでポストフック操作が開始されなくなり、PartiallyFailed バックアップステータスが発生しなくなりました。OADP-3140

DPA のデプロイが、37 文字を超える namespace でも期待どおりに機能するようになる

新しい DPA を作成するために、37 文字を超える namespace に OADP Operator をインストールすると、"cloud-credentials" シークレットのラベル付けが失敗し、DPA によって次のエラーが報告されていました。

The generated label name is too long.

この更新により、名前が 37 文字を超える namespace でも DPA の作成が失敗しなくなりました。OADP-3960

タイムアウトエラーをオーバーライドすることで復元が正常に完了するようになる

以前は、大規模な環境で、復元操作の結果が Partiallyfailed ステータスになり、fail to patch dynamic PV, err: context deadline exceeded というエラーが発生していました。この更新により、Velero サーバー引数の resourceTimeout を使用してこのタイムアウトエラーをオーバーライドすることで、復元が成功するようになりました。OADP-4344

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

4.2.1.1.3. 既知の問題

OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる

OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、CrashLoopBackOff エラー状態を返す StatefulSet Pod を削除します。その後、StatefulSet コントローラーがこれらの Pod を再作成し、正常に動作するようになります。OADP-4407

ImageStream を参照するデプロイメントが適切に復元されず、Pod とボリュームの内容が破損する

File System Backup (FSB) の復元操作中に、ImageStream を参照する Deployment リソースが適切に復元されません。FSB を実行する復元された Pod と postHook が途中で終了します。

復元操作中に、OpenShift Container Platform コントローラーが、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

    OADP-3954

4.2.1.2. OADP 1.4.0 リリースノート

OpenShift API for Data Protection (OADP) 1.4.0 リリースノートには、解決された問題と既知の問題が記載されています。

4.2.1.2.1. 解決した問題

OpenShift Container Platform 4.16 では復元が正しく機能します

以前は、削除されたアプリケーションの namespace を復元する際に、OpenShift Container Platform 4.16 で resource name may not be empty エラーが発生し、復元操作が部分的に失敗していました。この更新により、OpenShift Container Platform 4.16 で復元が期待どおりに機能するようになりました。OADP-4075

OpenShift Container Platform 4.16 クラスターでは、Data Mover バックアップが正常に動作します。

以前は、Velero は Spec.SourceVolumeMode フィールドが存在しない以前のバージョンの SDK を使用していました。その結果、バージョン 4.2 の外部スナップショットの OpenShift Container Platform 4.16 クラスターで Data Mover バックアップが失敗しました。この更新により、外部スナップショットインスタンスはバージョン 7.0 以降にアップグレードされました。その結果、OpenShift Container Platform 4.16 クラスターではバックアップが失敗しなくなります。OADP-3922

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

4.2.1.2.2. 既知の問題

MCG に checksumAlgorith が設定されていない場合、バックアップが失敗する

バックアップロケーションとして Noobaa を使用してアプリケーションのバックアップを実行するときに、checksumAlgorithm 設定パラメーターが設定されていない場合は、バックアップは失敗します。この問題を解決するために、バックアップ保存場所 (BSL) の設定で checksumAlgorithm の値を指定しなかった場合、空の値が追加されます。空の値は、Data Protection Application (DPA) カスタムリソース (CR) を使用して作成された BSL に対してのみ追加され、他の方法を使用して BSL が作成された場合、この値は追加されません。OADP-4274

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

4.2.1.2.3. アップグレードの注意事項
注記

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

4.2.1.2.3.1. OADP 1.3 から 1.4 への変更点

Velero サーバーが、バージョン 1.12 から 1.14 に更新されました。Data Protection Application (DPA) には変更がない点に注意してください。

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

  • velero-plugin-for-csi コードが Velero コードで利用可能になりました。つまり、プラグインに init コンテナーが不要になりました。
  • Velero は、クライアントのバーストと QPS のデフォルトをそれぞれ 30 と 20 から 100 と 100 に変更しました。
  • velero-plugin-for-aws プラグインは、BackupStorageLocation オブジェクト (BSL) の spec.config.checksumAlgorithm フィールドのデフォルト値を "" (チェックサム計算なし) から CRC32 アルゴリズムに更新しました。詳細は、AWS Backup Storage Location の Velero プラグイン を参照してください。チェックサムアルゴリズムタイプは AWS でのみ動作することがわかっています。いくつかの S3 プロバイダーでは、チェックサムアルゴリズムを "" に設定して md5sum を無効にする必要があります。ストレージプロバイダーで md5sum アルゴリズムのサポートと設定を確認してください。

    OADP 1.4 では、この設定の DPA 内で作成される BSL のデフォルト値は "" です。このデフォルト値は、md5sum がチェックされないことを意味し、OADP 1.3 と一致しています。DPA 内で作成された BSL の場合は、DPA の spec.backupLocations[].velero.config.checksumAlgorithm フィールドを使用して更新します。BSL が DPA の外部で作成された場合は、BSL で spec.config.checksumAlgorithm を使用してこの設定を更新できます。

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

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

手順

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

    コマンドの例

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

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

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

手順

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

OADP 1.3 から 1.4 にアップグレードする場合、Data Protection Application (DPA) を変更する必要はありません。

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

アップグレードの確認 セクションの手順に従ってインストールを確認します。

4.2.2. OADP 1.3 リリースノート

OpenShift API for Data Protection (OADP) のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。

4.2.2.1. OADP 1.3.3 リリースノート

OpenShift API for Data Protection (OADP) 1.3.3 リリースノートには、解決された問題と既知の問題が記載されています。

4.2.2.1.1. 解決した問題

namespace 名が 37 文字を超えると OADP が失敗する

37 文字を超える文字を含む namespace に OADP Operator をインストールし、新しい DPA を作成すると、cloud-credentials シークレットのラベル付けに失敗します。このリリースでは、この問題が修正されています。OADP-4211

OADP image PullPolicy を Alwaysに設定

OADP の以前のバージョンでは、adp-controller-manager および Velero Pod の image PullPolicy が Always に設定されていました。これは、レジストリーにネットワーク帯域幅が制限されている可能性があるエッジシナリオで問題があり、Pod の再起動後にリカバリー時間が遅くなることがありました。OADP 1.3.3 では、openshift-adp-controller-manager および Velero Pod の image PullPolicy は IfNotPresent に設定されます。

このリリースに含まれるセキュリティー修正のリストは RHSA-2024:4982 アドバイザリーに記載されています。

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

4.2.2.1.2. 既知の問題

OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる

OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackOff 状態を返す StatefulSet Pod を削除します。StatefulSet コントローラーがこれらの Pod を再作成し、正常に動作するようになります。

OADP-3767

4.2.2.2. OADP 1.3.2 リリースノート

OpenShift API for Data Protection (OADP) 1.3.2 リリースノートには、解決された問題と既知の問題が記載されています。

4.2.2.2.1. 解決した問題

BSL に有効なカスタムシークレットが使用されている場合、DPA は調整に失敗します。

Backup Storage Location (BSL) に有効なカスタムシークレットが使用されているが、デフォルトのシークレットが見つからない場合、DPA は調整に失敗します。回避策は、最初に必要なデフォルトの cloud-credentials を作成することです。カスタムシークレットが再作成されると、それを使用してその存在を確認できます。

OADP-3193

CVE-2023-45290: oadp-velero-container: Golang net/http: Request.ParseMultipartForm でのメモリー不足

net/http Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。multipart フォームを解析する場合、明示的に Request.ParseMultipartForm を使用するか、または暗黙的に Request.FormValueRequest.PostFormValue、または Request.FormFile を使用するかにかかわらず、解析されたフォームの合計サイズの制限は、単一のフォーム行の読み取り中に消費されるメモリーには適用されません。これにより、長い行を含む悪意のある入力により、任意の大量のメモリーが割り当てられ、メモリー不足につながる可能性があります。この不具合は OADP 1.3.2 で解決されました。

詳細は、CVE-2023-45290 を参照してください。

CVE-2023-45289: oadp-velero-container: Golang net/http/cookiejar: HTTP リダイレクト時の機密ヘッダーと Cookie の不適切な転送

net/http/cookiejar Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。 サブドメインが一致しない、または初期ドメインと完全に一致しないドメインへの HTTP リダイレクトに従う場合、http.ClientAuthorizationCookie などの機密ヘッダーを転送しません。悪意を持って作成された HTTP リダイレクトにより、機密ヘッダーが予期せず転送される可能性があります。この不具合は OADP 1.3.2 で解決されました。

詳細は、CVE-2023-45289 を参照してください。

CVE-2024-24783: oadp-velero-container: Golang crypto/x509: 不明な公開鍵アルゴリズムを持つ証明書の検証パニック

crypto/x509 Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。不明な公開鍵アルゴリズムを持つ証明書を含む証明書チェーンを検証すると、Certificate.Verify がパニックになります。これは、Config.ClientAuthVerifyClientCertIfGiven または RequireAndVerifyClientCert に設定するすべての crypto/tls クライアントおよびサーバーに影響します。デフォルトの動作では、TLS サーバーはクライアント証明書を検証しません。この不具合は OADP 1.3.2 で解決されました。

詳細は、CVE-2024-24783 を参照してください。

CVE-2024-24784: oadp-velero-plugin-container: Golang net/mail: 表示名内のコメントが正しく処理されない

net/mail Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。ParseAddressList 関数は、コメント、括弧内のテキスト、および表示名を正しく処理しません。これは準拠するアドレスパーサーとの不整合であるため、異なるパーサーを使用するプログラムによって異なる信頼の決定が行われる可能性があります。この不具合は OADP 1.3.2 で解決されました。

詳細は、CVE-2024-24784 を参照してください。

CVE-2024-24785: oadp-velero-container: Golang: html/template: MarshalJSON メソッドから返されるエラーにより、テンプレートのエスケープが壊れる可能性がある

html/template Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。 MarshalJSON メソッドから返されるエラーにユーザーが制御するデータが含まれている場合、そのエラーは HTML/テンプレートパッケージのコンテキスト自動エスケープ動作の中断に使用される可能性があり、後続のアクションにより、予期しないコンテンツがテンプレートに挿入される可能性があります。 この不具合は OADP 1.3.2 で解決されました。

詳細は、CVE-2024-24785 を参照してください。

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

4.2.2.2.2. 既知の問題

OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる

OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackOff 状態を返す StatefulSet Pod を削除します。StatefulSet コントローラーがこれらの Pod を再作成し、正常に動作するようになります。

OADP-3767

4.2.2.3. OADP 1.3.1 リリースノート

OpenShift API for Data Protection (OADP) 1.3.1 リリースノートには、新機能と解決された問題が記載されています。

4.2.2.3.1. 新機能

OADP 1.3.0 Data Mover が完全にサポートされるようになりました

OADP 1.3.0 でテクノロジープレビューとして導入された OADP 組み込みの Data Mover が、コンテナー化されたワークロードと仮想マシンのワークロードの両方で完全にサポートされるようになりました。

4.2.2.3.2. 解決した問題

IBM Cloud (R) Object Storage がバックアップストレージプロバイダーとしてサポートされるようになりました

IBM Cloud® Object Storage は、これまでサポートされていなかった AWS S3 互換のバックアップストレージプロバイダーの 1 つです。この更新により、IBM Cloud® Object Storage が AWS S3 互換のバックアップストレージプロバイダーとしてサポートされるようになりました。

OADP-3788

OADP Operator が missing region エラーを正しく報告するようになりました

以前は、AWS Backup Storage Location (BSL) 設定で region を指定せずに profile:default を指定すると、OADP Operator が Data Protection Application (DPA) カスタムリソース (CR) での missing region エラーを報告できませんでした。この更新により、AWS の DPA BSL 仕様の検証が修正されました。その結果、OADP Operator が missing region エラーを報告するようになりました。

OADP-3044

カスタムラベルが openshift-adp namespace から削除されなくなりました

以前は、openshift-adp-controller-manager Pod が openshift-adp namespace に割り当てられたラベルをリセットしていました。これにより、Argo CD などのカスタムラベルを必要とするアプリケーションで同期の問題が発生し、機能が適切に動作しませんでした。この更新により、この問題が修正され、カスタムラベルが openshift-adp namespace から削除されなくなりました。

OADP-3189

OADP must-gather イメージが CRD を収集するようになりました

以前は、OADP must-gather イメージが、OADP によって提供されるカスタムリソース定義 (CRD) を収集しませんでした。その結果、omg ツールを使用してサポートシェルでデータを抽出することができませんでした。この修正により、must-gather イメージが OADP によって提供される CRD を収集し、omg ツールを使用してデータを抽出できるようになりました。

OADP-3229

ガベージコレクションのデフォルト頻度値の記述が修正されました

以前は、garbage-collection-frequency フィールドのデフォルト頻度値の記述が間違っていました。この更新により、garbage-collection-frequencygc-controller 調整のデフォルト頻度値が 1 時間という正しい値になりました。

OADP-3486

FIPS モードフラグが OperatorHub で利用可能になりました

fips-compatible フラグを true に設定すると、OperatorHub の OADP Operator リストに FIPS モードフラグが追加されます。この機能は OADP 1.3.0 で有効になりましたが、Red Hat Container Catalog には FIPS 対応と表示されていませんでした。

OADP-3495

csiSnapshotTimeout を短い期間に設定した場合に nil ポインターによる CSI プラグインのパニックが発生しなくなりました

以前は、csiSnapshotTimeout パラメーターを短い期間に設定すると、CSI プラグインで plugin panicked: runtime error: invalid memory address or nil pointer dereference というエラーが発生していました。

この修正により、バックアップが Timed out awaiting reconciliation of volumesnapshot エラーで失敗するようになりました。

OADP-3069

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

4.2.2.3.3. 既知の問題

IBM Power (R) および IBM Z(R) プラットフォームにデプロイされたシングルノード OpenShift クラスターのバックアップおよびストレージの制限

IBM Power® および IBM Z® プラットフォームにデプロイされたシングルノード OpenShift クラスターのバックアップおよびストレージ関連の次の制限を確認してください。

Storage
現在、IBM Power® および IBM Z® プラットフォームにデプロイされたシングルノードの OpenShift クラスターと互換性があるのは、NFS ストレージのみです。
バックアップ
バックアップおよび復元操作では、kopiarestic などのファイルシステムバックアップを使用したアプリケーションのバックアップのみがサポートされます。

OADP-3787

OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる

OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackoff 状態の StatefulSet Pod を削除します。StatefulSet コントローラーがこれらの Pod を再作成し、正常に動作するようになります。

OADP-3767

4.2.2.4. OADP 1.3.0 リリースノート

OpenShift API for Data Protection (OADP) 1.3.0 のリリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。

4.2.2.4.1. 新機能
Velero ビルトイン DataMover

Velero ビルトイン DataMover は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

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

OADP 1.3 には、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアに移動するために使用できる、ビルトイン Data Mover が含まれています。ビルトイン Data Mover を使用すると、クラスターの障害、誤削除、または破損が発生した場合に、リモートオブジェクトストアからステートフルアプリケーションを復元できます。スナップショットデータを読み取り、統合リポジトリーに書き込むためのアップローダーメカニズムとして Kopia を使用します。

ファイルシステムバックアップを使用してアプリケーションをバックアップする: Kopia または Restic

Velero のファイルシステムバックアップ (FSB) は、Restic パスと Kopia パスという 2 つのバックアップライブラリーをサポートしています。

Velero を使用すると、ユーザーは 2 つのパスから選択できます。

バックアップの場合は、インストール中に uploader-type フラグを使用してパスを指定します。有効な値は、restic または kopia です。値が指定されていない場合、このフィールドのデフォルトは kopia です。インストール後に選択を変更することはできません。

GCP クラウド認証

Google Cloud Platform (GCP) 認証を使用すると、有効期間の短い Google 認証情報を使用できます。

GCP と Workload Identity Federation を使用すると、Identity and Access Management (IAM) を使用して、サービスアカウントに成り代わる機能などの IAM ロールを外部アイデンティティーに付与できます。これにより、サービスアカウントキーに関連するメンテナンスとセキュリティーのリスクが排除されます。

AWS ROSA STS 認証

Red Hat OpenShift Service on AWS (ROSA) クラスターで OpenShift API for Data Protection (OADP) を使用して、アプリケーションデータをバックアップおよび復元できます。

ROSA は、幅広い AWS コンピュート、データベース、分析、機械学習、ネットワーク、モバイル、およびその他のサービスとのシームレスな統合を提供し、差別化されたエクスペリエンスの構築とお客様への提供をさらに高速化します。

AWS アカウントから直接サービスをサブスクライブできます。

クラスターの作成後、OpenShift Web コンソールを使用してクラスターを操作できます。ROSA サービスは、OpenShift API およびコマンドラインインターフェイス (CLI) ツールも使用します。

4.2.2.4.2. 解決した問題

ACM アプリケーションが削減され、復元後にマネージドクラスター上で再作成される

マネージドクラスター上のアプリケーションは削除され、復元をアクティブ化すると再作成されていました。OpenShift API for Data Protection (OADP 1.2) のバックアップおよび復元のプロセスは、古いバージョンよりも高速です。OADP のパフォーマンスが変わったことで、ACM リソースの復元時にこのような動作が発生するようになりました。一部のリソースは他のリソースより前に復元され、その結果、マネージドクラスターからアプリケーションが削除されていました。OADP-2686

Pod セキュリティー標準が原因で Restic の復元が部分的に失敗する

相互運用性のテスト中に、OpenShift Container Platform 4.14 の Pod セキュリティーモードが enforce に設定されていたため、Pod が拒否されました。これは、復元順序が原因で発生します。Pod が security context constraints (SCC) リソースの前に作成されることで podSecurity 標準に違反していたため、Pod が拒否されました。Velero サーバーで復元優先度フィールドを設定すると、復元は成功します。OADP-2688

Velero が複数の namespace にインストールされている場合、Pod ボリュームのバックアップが失敗する可能性がある

Velero が複数の namespace にインストールされている場合、Pod Volume Backup (PVB) 機能でリグレッションが発生していました。PVB コントローラーは、その namespace 内の PVB に適切に制限されませんでした。OADP-2308

OADP Velero プラグインが "received EOF, stopping recv loop" のメッセージを返す

OADP では、Velero プラグインは別のプロセスとして開始されました。Velero 操作が完了すると、成功しても失敗しても終了します。そのため、デバッグログに received EOF, stopping recv loop メッセージが表示された場合、それはエラーの発生ではなく、プラグイン操作の完了を意味しました。OADP-2176

CVE-2023-39325 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱である

OADP の以前のリリースでは、リクエストのキャンセルにより複数のストリームがすぐにリセットされる可能性があるため、HTTP/2 プロトコルはサービス拒否攻撃の影響を受けやすかった。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要がありました。これにより、サーバーリソースの消費によりサービス拒否が発生しました。

詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。

このリリースで解決された問題の一覧は、Jira の OADP 1.3.0 解決済みの問題 に記載されているリストを参照してください。

4.2.2.4.3. 既知の問題

csiSnapshotTimeout が短く設定されている場合、nil ポインターで CSI プラグインエラーが発生する

csiSnapshotTimeout の期間が短く設定されている場合、CSI プラグインが nil ポインターでエラーを引き起こします。短時間でスナップショットを完了できることもありますが、多くの場合、バックアップ PartiallyFailed でパニックが発生し、エラー plugin panicked: runtime error: invalid memory address or nil pointer dereference が表示されます。

volumeSnapshotContent CR にエラーがある場合、バックアップは PartiallyFailed としてマークされる

いずれかの VolumeSnapshotContent CR に VolumeSnapshotBeingCreated アノテーションの削除に関連するエラーがある場合、バックアップは WaitingForPluginOperationsPartiallyFailed フェーズに遷移します。OADP-2871

初めて 30,000 個のリソースの復元する際に、パフォーマンスの問題が発生する

既存のリソースポリシーを使用せずに 30,000 個のリソースを初めて復元する際に、既存のリソースポリシーを update に設定して 2 回目と 3 回目の復元を実行する場合と比べて、2 倍の時間がかかります。OADP-3071

Datadownload 操作が関連する PV を解放する前に、復元後のフックが実行を開始する可能性がある

Data Mover 操作は非同期のため、関連する Pod の永続ボリューム (PV) が Data Mover の永続ボリューム要求 (PVC) によって解放される前に、ポストフックが試行される可能性があります。

GCP-Workload Identity Federation VSL バックアップで PartiallyFailed が発生する

GCP Workload Identity が GCP 上で設定されている場合、VSL バックアップで PartiallyFailed が発生します。

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

4.2.2.4.4. アップグレードの注意事項
注記

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

4.2.2.4.4.1. OADP 1.2 から 1.3 への変更点

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

OpenShift API for Data Protection (OADP) 1.3 は、VolumeSnapshotMover (VSM) や Volsync Data Mover の代わりに Velero のビルトイン Data Mover を使用します。

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

  • spec.features.dataMover フィールドと VSM プラグインは OADP 1.3 と互換性がないため、それらの設定を DataProtectionApplication (DPA) 設定から削除する必要があります。
  • Volsync Operator は Data Mover の機能には不要になったため、削除できます。
  • カスタムリソース定義の volumesnapshotbackups.datamover.oadp.openshift.io および volumesnapshotrestores.datamover.oadp.openshift.io は不要になったため、削除できます。
  • OADP-1.2 Data Mover に使用されるシークレットは不要になったため、削除できます。

OADP 1.3 は、Restic の代替ファイルシステムバックアップツールである Kopia をサポートしています。

  • Kopia を使用するには、次の例に示すように、新しい spec.configuration.nodeAgent フィールドを使用します。

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

  • spec.configuration.restic フィールドは OADP 1.3 で非推奨となり、今後の OADP バージョンで削除される予定です。非推奨の警告が表示されないようにするには、restic キーとその値を削除し、次の新しい構文を使用します。

    spec:
      configuration:
        nodeAgent:
          enable: true
          uploaderType: restic
    # ...

注記

今後の OADP リリースでは、kopia ツールが uploaderType のデフォルト値になる予定です。

4.2.2.4.4.2. OADP 1.2 の Data Mover (テクノロジープレビュー) からアップグレードする

OpenShift API for Data Protection (OADP) 1.2 Data Mover のバックアップは、OADP 1.3 では 復元できません。アプリケーションのデータ保護にギャップが生じることを防ぐには、OADP 1.3 にアップグレードする前に次の手順を実行します。

手順

  1. クラスターのバックアップが十分で、Container Storage Interface (CSI) ストレージが利用可能な場合は、CSI バックアップを使用してアプリケーションをバックアップします。
  2. クラスター外のバックアップが必要な場合:

    1. --default-volumes-to-fs-backup=true or backup.spec.defaultVolumesToFsBackup オプションを使用するファイルシステムバックアップで、アプリケーションをバックアップします。
    2. オブジェクトストレージプラグイン (velero-plugin-for-aws など) を使用してアプリケーションをバックアップします。
注記

Restic ファイルシステムバックアップのデフォルトのタイムアウト値は 1 時間です。OADP 1.3.1 以降では、Restic および Kopia のデフォルトのタイムアウト値は 4 時間です。

重要

OADP 1.2 Data Mover バックアップを復元するには、OADP をアンインストールし、OADP 1.2 をインストールして設定する必要があります。

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

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

手順

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

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

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

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

手順

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

Data Mover を使用してバックアップをクラスター外に移動する必要がある場合は、次のように DataProtectionApplication (DPA) マニフェストを再設定します。

手順

  1. Operators Installed Operators をクリックして、OADP Operator を選択します。
  2. Provided APIs セクションで、View more をクリックします。
  3. DataProtectionApplication ボックスの Create instance をクリックします。
  4. YAML View をクリックして、現在の DPA パラメーターを表示します。

    現在の DPA の例

    spec:
      configuration:
        features:
          dataMover:
          enable: true
          credentialName: dm-credentials
        velero:
          defaultPlugins:
          - vsm
          - csi
          - openshift
    # ...

  5. DPA パラメーターを更新します。

    • DPA から、features.dataMover キーと値を削除します。
    • VolumeSnapshotMover (VSM) プラグインを削除します。
    • nodeAgent キーと値を追加します。

      更新された DPA の例

      spec:
        configuration:
          nodeAgent:
            enable: true
            uploaderType: kopia
          velero:
            defaultPlugins:
            - csi
            - openshift
      # ...

  6. DPA が正常に調整するまで待機します。
4.2.2.4.4.6. アップグレードの検証

アップグレードを検証するには、次の手順を使用します。

手順

  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. 次のコマンドを実行して、バックアップ保存場所を確認し、PHASEAvailable であることを確認します。

    $ oc get backupStorageLocation -n openshift-adp

    出力例

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

OADP 1.3 では、DataProtectionApplication (DPA) 設定を作成するのではなく、バックアップごとにクラスター外へのデータ移動を開始できます。

$ velero backup create example-backup --include-namespaces mysql-persistent --snapshot-move-data=true

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: example-backup
  namespace: openshift-adp
spec:
  snapshotMoveData: true
  includedNamespaces:
  - mysql-persistent
  storageLocation: dpa-sample-1
  ttl: 720h0m0s
# ...

4.2.3. OADP 1.2 リリースノート

OpenShift API for Data Protection (OADP) 1.2 のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。

4.2.3.1. OADP 1.2.5 リリースノート

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

4.2.3.1.1. 解決した問題

CVE-2023-2431: oadp-velero-plugin-for-microsoft-azure-container: seccomp プロファイル適用のバイパス

Kubernetes に不具合が見つかり、OADP の以前のバージョンに影響します。この不具合は、seccomp プロファイルに localhost タイプを使用し、空のプロファイルフィールドを指定する場合の不具合によって、Kubernetes がローカル認証された攻撃者にセキュリティー制限の回避を許可した場合に発生します。攻撃者は、悪用目的で作成されたリクエストを送信することで、seccomp プロファイルの適用を回避できます。 この不具合は OADP 1.2.5 で解決されました。

詳細は、(CVE-2023-2431) を参照してください。

CSI 復元が 'PartiallyFailed' ステータスで終了し、PVC が作成されない

CSI 復元が PartiallyFailed ステータスで終了しました。PVC は作成されず、Pod のステータスは Pending です。この問題は OADP 1.2.5 で解決されました。

(OADP-1956)

完了した Pod ボリュームで PodVolumeBackup が失敗する

OADP 1.2 の以前のバージョンでは、Restic podvolumebackup または Velero バックアップで使用される namespace にボリュームをマウントした完了した Pod がある場合、バックアップは正常に完了しません。これは、defaultVolumesToFsBackuptrue に設定されている場合に発生します。この問題は OADP 1.2.5 で解決されました。

(OADP-1870)

4.2.3.1.2. 既知の問題

データ保護アプリケーション (DPA) は、認証情報のシークレットが更新されても調整を行いません。

現在、OADP Operator は cloud-credentials シークレットを更新しても調整を行いません。これは、cloud-credentials シークレットに OADP 固有のラベルまたは所有者参照がないことが原因です。 空のデータなどの誤った認証情報を使用して cloud-credentials シークレットを作成すると、Operator はその空のデータを使用して調整し、Backup Storage Location (BSL) とレジストリーデプロイメントを作成します。その結果、正しい認証情報で cloud-credentials シークレットを更新しても、OADP Operator はすぐに調整して新しい認証情報を取得することはしません。

回避策: OADP 1.3 に更新します。

(OADP-3327)

4.2.3.2. OADP 1.2.4 リリースノート

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

4.2.3.2.1. 解決した問題

OADP 1.2.4 には解決された問題はありません。

4.2.3.2.2. 既知の問題

OADP 1.2.4 には次の既知の問題があります。

データ保護アプリケーション (DPA) は、認証情報のシークレットが更新されても調整を行いません。

現在、OADP Operator は cloud-credentials シークレットを更新しても調整を行いません。これは、cloud-credentials シークレットに OADP 固有のラベルまたは所有者参照がないことが原因です。 空のデータなどの誤った認証情報を使用して cloud-credentials シークレットを作成すると、Operator はその空のデータを使用して調整し、Backup Storage Location (BSL) とレジストリーデプロイメントを作成します。その結果、正しい認証情報で cloud-credentials シークレットを更新しても、Operator はすぐに調整して新しい認証情報を取得することはしません。

回避策: OADP 1.3 に更新します。

(OADP-3327)

4.2.3.3. OADP 1.2.3 リリースノート

4.2.3.3.1. 新機能

OpenShift API for Data Protection (OADP) 1.2.3 のリリースに新機能はありません。

4.2.3.3.2. 解決した問題

以下で強調表示された問題は、OADP 1.2.3 で解決されています。

複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です

OADP 1.2 の以前のリリースでは、リクエストのキャンセルにより複数のストリームがすぐにリセットされる可能性があるため、HTTP/2 プロトコルはサービス拒否攻撃の影響を受けやすかった。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要がありました。これにより、サーバーリソースの消費によりサービス拒否が発生しました。この CVE に関連するすべての OADP 問題のリストは、次の Jira リスト を参照してください。

詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。

OADP 1.2.3 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.2.3 で解決された問題 のリストを参照してください。

4.2.3.3.3. 既知の問題

OADP 1.2.3 には次の既知の問題があります。

データ保護アプリケーション (DPA) は、認証情報のシークレットが更新されても調整を行いません。

現在、OADP Operator は cloud-credentials シークレットを更新しても調整を行いません。これは、cloud-credentials シークレットに OADP 固有のラベルまたは所有者参照がないことが原因です。 空のデータなどの誤った認証情報を使用して cloud-credentials シークレットを作成すると、Operator はその空のデータを使用して調整し、Backup Storage Location (BSL) とレジストリーデプロイメントを作成します。その結果、正しい認証情報で cloud-credentials シークレットを更新しても、Operator はすぐに調整して新しい認証情報を取得することはしません。

回避策: OADP 1.3 に更新します。

(OADP-3327)

4.2.3.4. OADP 1.2.2 リリースノート

4.2.3.4.1. 新機能

OpenShift API for Data Protection (OADP) 1.2.2 のリリースに新機能はありません。

4.2.3.4.2. 解決した問題

以下で強調表示された問題は、OADP 1.2.2 で解決されています。

Pod セキュリティー標準が原因で Restic の復元が部分的に失敗します

OADP 1.2 の以前のリリースでは、OpenShift Container Platform 4.14 は、Restic 復元プロセス中に Pod の readiness を妨げる可能性がある Pod Security Admission (PSA) ポリシーを強制していました。

この問題は、OADP 1.2.2 と OADP 1.1.6 のリリースで解決されました。ユーザーは、これらのリリースにアップグレードすることが推奨されます。

詳細は、PSA ポリシーの変更により、OCP 4.14 で部分的に Restic 復元が失敗する を参照してください。(OADP-2094)

内部イメージを使用したアプリケーションのバックアップが、プラグインパニックエラーにより部分的に失敗します

OADP 1.2 の以前のリリースでは、内部イメージを使用したアプリケーションのバックアップが部分的に失敗し、プラグインパニックエラーが返されました。バックアップが部分的に失敗し、Velero ログに次のエラーが記録されます。

time="2022-11-23T15:40:46Z" level=info msg="1 errors encountered backup up item" backup=openshift-adp/django-persistent-67a5b83d-6b44-11ed-9cba-902e163f806c logSource="/remote-source/velero/app/pkg/backup/backup.go:413" name=django-psql-persistent
time="2022-11-23T15:40:46Z" level=error msg="Error backing up item" backup=openshift-adp/django-persistent-67a5b83d-6b44-11ed-9cba-902e163f8

この問題は、OADP 1.2.2 で解決されました。(OADP-1057)

復元順序が原因で、ACM クラスターの復元が期待どおりに機能しません

OADP 1.2 の以前のリリースでは、復元順序が原因で、ACM クラスターの復元が期待どおりに機能しませんでした。ACM アプリケーションは、復元を有効にした後に削除され、マネージドクラスター上で再作成されました。(OADP-2505)

ボリュームサイズの不一致により、filesystemOverhead を使用している仮想マシンが、バックアップおよび復元時に失敗します

OADP 1.2 の以前のリリースでは、選択したストレージプロバイダー実装が原因で、アプリケーションの永続ボリューム要求 (PVC) のストレージ要求と同じ PVC のスナップショットサイズが異なると、バックアップおよび復元時に filesystemOverhead を使用する仮想マシンが失敗していました。 この問題は、OADP 1.2.2 の Data Mover で解決されました。(OADP-2144)

OADP には、VolSync レプリケーションソースのプルーニング間隔を設定するオプションが含まれていませんでした

OADP 1.2 の以前のリリースでは、VolSync レプリケーションソースの pruneInterval を設定するオプションがありませんでした。(OADP-2052)

Velero が複数の namespace にインストールされている場合、Pod ボリュームのバックアップが失敗する可能性がありました

OADP 1.2 の以前のリリースでは、Velero が複数の namespace にインストールされている場合、Pod ボリュームのバックアップが失敗する可能性がありました。(OADP-2409)

VSL がカスタムシークレットを使用する場合、Backup Storage Locations が使用不可フェーズに遷移しました

OADP 1.2 の以前のリリースでは、Volume Snapshot Location がカスタムシークレットを使用した場合、Backup Storage Locations が使用不可フェーズに遷移しました。(OADP-1737)

OADP 1.2.2 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.2.2 で解決された問題 のリストを参照してください。

4.2.3.4.3. 既知の問題

以下で強調表示されている問題は、OADP 1.2.2 のリリースにおける既知の問題です。

Must-gather コマンドが ClusterRoleBinding リソースの削除に失敗します

oc adm must-gather コマンドは、アドミッション Webhook が原因で、クラスター上に残っている ClusterRoleBinding リソースの削除に失敗します。したがって、ClusterRoleBinding リソースの削除要求は拒否されます。(OADP-27730)

admission webhook "clusterrolebindings-validation.managed.openshift.io" denied the request: Deleting ClusterRoleBinding must-gather-p7vwj is not allowed

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

4.2.3.5. OADP 1.2.1 リリースノート

4.2.3.5.1. 新機能

OpenShift API for Data Protection (OADP) 1.2.1 のリリースには新機能はありません。

4.2.3.5.2. 解決した問題

OADP 1.2.1 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.2.1 で解決された問題 のリストを参照してください。

4.2.3.5.3. 既知の問題

OADP 1.2.1 のリリースでは、次の問題が既知の問題として強調表示されています。

DataMover Restic の保持ポリシーとプルーニングポリシーが期待どおりに機能しない

VolSync と Restic によって提供される保持機能とプルーニング機能が期待どおりに動作しません。VolSync レプリケーションにはプルーニング間隔を設定する有効なオプションがないため、OADP の外部の S3 ストレージにリモートで保存されたバックアップを管理し、プルーニングする必要があります。詳細は、以下を参照してください。

重要

OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

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

このリリースのすべての既知の問題の完全なリストは、Jira の OADP 1.2.1 の既知の問題 のリストを参照してください。

4.2.3.6. OADP 1.2.0 リリースノート

OADP 1.2.0 リリースノートには、新機能、バグ修正、既知の問題に関する情報が含まれています。

4.2.3.6.1. 新機能

リソースタイムアウト

新しい resourceTimeout オプションは、さまざまな Velero リソースを待機するタイムアウト期間を分単位で指定します。このオプションは、Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性などのリソースに適用されます。デフォルトの期間は 10 分です。

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

AWS S3 互換プロバイダーでオブジェクトとスナップショットをバックアップできます。

4.2.3.6.1.1. テクニカルプレビュー機能

Data Mover

OADP Data Mover を使用すると、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。Data Mover を有効にすると、クラスターの偶発的な削除、クラスター障害、またはデータ破損が発生した場合に、オブジェクトストアから取得した CSI ボリュームスナップショットを使用してステートフルアプリケーションを復元できます。

重要

OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

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

4.2.3.6.2. 解決した問題

このリリースで解決された問題の一覧は、Jira の OADP 1.2.0 解決済みの問題 に記載されているリストを参照してください。

4.2.3.6.3. 既知の問題

以下で強調表示されている問題は、OADP 1.2.0 のリリースにおける既知の問題です。

複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です

HTTP/2 プロトコルは、リクエストのキャンセルによって複数のストリームがすぐにリセットされる可能性があるため、サービス拒否攻撃の影響を受けやすくなっています。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要があります。これにより、サーバーのリソースが消費され、サービス拒否が発生します。

この問題を解決する OADP 1.2.3 にアップグレードすることを推奨します。

詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。

生成されたルートのホスト名を変更すると、不正なホスト名が作成される場合があります。

デフォルトでは、OpenShift Container Platform クラスターは、openshift.io/host.generated: true アノテーションがオンになっていることを確認し、生成されたルートと生成されていないルートの両方のフィールドに値を入力します。

.spec.host フィールドの値を、生成されたルートと生成されていないルートのクラスターのベースドメイン名に基づいて変更することはできません。

.spec.host フィールドの値を変更する場合、OpenShift Container Platform クラスターによって生成されたデフォルト値を復元することはできません。OpenShift Container Platform クラスターを復元した後、Operator がそのフィールドの値をリセットします。

4.2.3.6.4. アップグレードの注意事項
注記

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

4.2.3.6.4.1. OADP 1.1 から 1.2 への変更点

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

OADP 1.2 では、DataProtectionApplication (DPA) 設定の dpa.spec.configuration.velero.args に、次の変更が加えられました。

  • default-volumes-to-restic フィールドの名前が default-volumes-to-fs-backup に変更されました。dpa.spec.configuration.velero.args を使用する場合は、OADP のアップグレード後に、新しい名前で DPA に再度追加する必要があります。
  • restic-timeout フィールドの名前が fs-backup-timeout に変更されました。dpa.spec.configuration.velero.args を使用する場合は、OADP のアップグレード後に、新しい名前で DPA に再度追加する必要があります。
  • restic デーモンセットの名前が node-agent に変更されました。OADP は、デーモンセットの名前を自動的に更新します。
  • カスタムリソース定義 resticrepositories.velero.io の名前が backuprepositories.velero.io に変更されました。
  • カスタムリソース定義 resticrepositories.velero.io は、クラスターから削除できます。
4.2.3.6.5. アップグレード手順
4.2.3.6.5.1. DPA 設定をバックアップする

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

手順

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

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

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

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

手順

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

spec.configuration.velero.args スタンザで更新されたフィールドを使用する場合は、新しいパラメーター名を使用するように DataProtectionApplication (DPA) マニフェストを設定する必要があります。

手順

  1. Operators Installed Operators をクリックして、OADP Operator を選択します。
  2. Provided APIs を選択し、DataProtectionApplication ボックスの Create instance をクリックします。
  3. YAML View をクリックして、現在の DPA パラメーターを表示します。

    現在の DPA の例

    spec:
      configuration:
        velero:
          args:
            default-volumes-to-fs-backup: true
            default-restic-prune-frequency: 6000
            fs-backup-timeout: 600
    # ...

  4. DPA パラメーターを更新します。
  5. DPA パラメーターの値は変更せずに、名前を更新します。

    1. default-volumes-to-restic キーを、default-volumes-to-fs-backup に変更します。
    2. default-restic-prune-frequency キーを、default-repo-maintain-frequency に変更します。
    3. restic-timeout キーを、fs-backup-timeout に変更します。

    更新された DPA の例

    spec:
      configuration:
        velero:
          args:
            default-volumes-to-fs-backup: true
            default-repo-maintain-frequency: 6000
            fs-backup-timeout: 600
    # ...
  6. DPA が正常に調整するまで待機します。
注記

Restic ファイルシステムバックアップのデフォルトのタイムアウト値は 1 時間です。OADP 1.3.1 以降では、Restic および Kopia のデフォルトのタイムアウト値は 4 時間です。

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

アップグレードを検証するには、次の手順を使用します。

手順

  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/restic-9cq4q                                         1/1     Running   0          94s
    pod/restic-m4lts                                         1/1     Running   0          94s
    pod/restic-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
    
    NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
    daemonset.apps/restic   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. 次のコマンドを実行して、バックアップ保存場所を確認し、PHASEAvailable であることを確認します。

    $ oc get backupStorageLocation -n openshift-adp

    出力例

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

4.2.4. OADP 1.1 リリースノート

OpenShift API for Data Protection (OADP) 1.1 のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。

4.2.4.1. OADP 1.1.8 リリースノート

OpenShift API for Data Protection (OADP) 1.1.8 リリースノートには、既知の問題がすべて記載されています。本リリースで解決された問題はありません。

4.2.4.1.1. 既知の問題

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

4.2.4.2. OADP 1.1.7 リリースノート

OADP 1.1.7 リリースノートには、解決された問題と既知の問題がリストされています。

4.2.4.2.1. 解決した問題

以下で強調表示された問題は、OADP 1.1.7 で解決されています。

複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です

OADP 1.1 の以前のリリースでは、リクエストのキャンセルにより複数のストリームがすぐにリセットされる可能性があるため、HTTP/2 プロトコルはサービス拒否攻撃の影響を受けやすかった。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要がありました。これにより、サーバーリソースの消費によりサービス拒否が発生しました。この CVE に関連するすべての OADP 問題のリストは、次の Jira リスト を参照してください。

詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。

OADP 1.1.7 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.1.7 で解決された問題 のリストを参照してください。

4.2.4.2.2. 既知の問題

OADP 1.1.7 のリリースには既知の問題はありません。

4.2.4.3. OADP 1.1.6 リリースノート

OADP 1.1.6 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。

4.2.4.3.1. 解決した問題

Pod セキュリティー標準が原因で Restic の復元が部分的に失敗します

OCP 4.14 では、privileged プロファイルが enforced になる Pod セキュリティー標準が導入されました。以前の OADP リリースでは、このプロファイルが原因で Pod が permission denied エラーを受信していました。この問題は、復元順序が原因で発生していました。Pod は security context constraints (SCC) リソースの前に作成されました。この Pod が Pod のセキュリティー標準に違反するため、Pod は拒否され、その後失敗しました。OADP-2420

ジョブリソースの復元が部分的に失敗します

以前の OADP リリースでは、OCP 4.14 でジョブリソースの復元が部分的に失敗していました。この問題は古い OCP バージョンでは確認されませんでした。この問題は、ジョブリソースに追加のラベルが存在するために発生しましたが、これは古い OCP バージョンには存在していませんでした。OADP-2530

このリリースで解決された問題の一覧は、Jira の OADP 1.1.6 解決済みの問題 に記載されているリストを参照してください。

4.2.4.3.2. 既知の問題

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

4.2.4.4. OADP 1.1.5 リリースノート

OADP 1.1.5 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。

4.2.4.4.1. 新機能

このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。

4.2.4.4.2. 解決した問題

このリリースで解決された問題の一覧は、Jira の OADP 1.1.5 解決済みの問題 に記載されているリストを参照してください。

4.2.4.4.3. 既知の問題

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

4.2.4.5. OADP 1.1.4 リリースノート

OADP 1.1.4 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。

4.2.4.5.1. 新機能

このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。

4.2.4.5.2. 解決した問題

すべての velero デプロイメントサーバー引数のサポートを追加しました

以前の OADP リリースでは、OADP はアップストリームのすべての Velero サーバー引数のサポートを促進しませんでした。この問題は OADP 1.1.4 で解決され、アップストリームのすべての Velero サーバー引数がサポートされるようになりました。OADP-1557

復元名と PVC 名に複数の VSR がある場合、Data Mover は誤ったスナップショットから復元できます

以前のリリースの OADP では、クラスター内に同じ Velero restore 名と PersistentVolumeClaim (pvc) 名の Volume Snapshot Restore (VSR) リソースが複数ある場合、OADP Data Mover が間違ったスナップショットから復元できる可能性がありました。OADP-1822

Cloud Storage API BSL には OwnerReference が必要です

OADP の以前のリリースでは、dpa.spec.backupLocations.bucket で作成された Backup Storage Location (BSL) で OwnerReference が欠落しているため、ACM BackupSchedules が検証に失敗しました。OADP-1511

このリリースで解決された問題の一覧は、Jira の OADP 1.1.4 解決済みの問題 に記載されているリストを参照してください。

4.2.4.5.3. 既知の問題

本リリースには、以下の既知の問題があります。

UID/GID 範囲がクラスター上で変更された可能性があるため、OADP バックアップが失敗する可能性があります

アプリケーションがリストアされたクラスター上で UID/GID 範囲が変更された可能性があるため、OADP バックアップが失敗する可能性があり、その結果、OADP が OpenShift Container Platform の UID/GID 範囲メタデータをバックアップおよびリストアしません。この問題を回避するには、バックアップされたアプリケーションに特定の UUID が必要な場合、復元時にその範囲が使用可能であることを確認してください。追加の回避策として、OADP が復元操作で namespace を作成できるようにすることが挙げられます。

ArgoCD で使用されるラベルが原因で ArgoCD がプロセス中に使用されると、復元が失敗する場合があります。

ArgoCD の app.kubernetes.io/instance で使用されるラベルが原因で ArgoCD がプロセス中に使用されると、復元が失敗する場合があります。このラベルは、ArgoCD が管理する必要があるリソースを識別します。これにより、復元時にリソースを管理するための OADP の手順と競合が発生する可能性があります。この問題を回避するには、ArgoCD YAML の .spec.resourceTrackingMethodannotation+label または annotation に設定します。問題が解決しない場合は、復元を開始する前に ArgoCD を無効にし、復元が完了したら再び有効にします。

OADP Velero プラグインが "received EOF, stopping recv loop" のメッセージを返す

Velero プラグインは、別のプロセスとして開始されます。Velero 操作が完了すると、成功したかどうかにかかわらず終了します。つまり、デバッグログに received EOF, stopping recv loop メッセージが表示されても、エラーが発生したことを意味するものではありません。このメッセージは、プラグイン操作が完了したことを示します。OADP-2176

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

4.2.4.6. OADP 1.1.3 リリースノート

OADP 1.1.3 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。

4.2.4.6.1. 新機能

このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。

4.2.4.6.2. 解決した問題

このリリースで解決された問題の一覧は、Jira の OADP 1.1.3 解決済みの問題 に記載されているリストを参照してください。

4.2.4.6.3. 既知の問題

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

4.2.4.7. OADP 1.1.2 リリースノート

OADP 1.1.2 リリースノートには、製品の推奨事項、修正されたバグのリスト、および既知の問題の説明が含まれています。

4.2.4.7.1. 製品の推奨事項

VolSync

VolSync 0.5.1 から VolSync stable チャネルから入手可能な最新バージョンへのアップグレードを準備するには、次のコマンドを実行して、このアノテーションを openshift-adp namespace に追加する必要があります。

$ oc annotate --overwrite namespace/openshift-adp volsync.backube/privileged-movers='true'

Velero

このリリースでは、Velero がバージョン 1.9.2 からバージョン 1.9.5 にアップグレードされました。

Restic

このリリースでは、Restic がバージョン 0.13.1 からバージョン 0.14.0 にアップグレードされました。

4.2.4.7.2. 解決した問題

このリリースでは、次の問題が解決されました。

4.2.4.7.3. 既知の問題

本リリースには、以下の既知の問題があります。

  • OADP は現在、Velero で restic を使用した AWS EFS ボリュームのバックアップと復元をサポートしていません (OADP-778)。
  • PVC ごとの VolumeSnapshotContent スナップショットの Ceph 制限により、CSI バックアップが失敗する場合があります。

    同じ永続ボリューム要求 (PVC) のスナップショットを複数作成できますが、スナップショットの定期的な作成をスケジュールすることはできません。

    • CephFS の場合、PVC ごとに最大 100 スナップショットを作成できます。(OADP-804)
    • RADOS ブロックデバイス (RBD) の場合は、PVC ごとに最大 512 個のスナップショットを作成できます。(OADP-975)

    詳細は、ボリュームのスナップショット を参照してください。

4.2.4.8. OADP 1.1.1 リリースノート

OADP 1.1.1 リリースノートには、製品の推奨事項と既知の問題の説明が含まれています。

4.2.4.8.1. 製品の推奨事項

OADP 1.1.1 をインストールする前に、VolSync 0.5.1 をインストールするか、それにアップグレードすることを推奨します。

4.2.4.8.2. 既知の問題

本リリースには、以下の既知の問題があります。

  • 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です

    HTTP/2 プロトコルは、リクエストのキャンセルによって複数のストリームがすぐにリセットされる可能性があるため、サービス拒否攻撃の影響を受けやすくなっています。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要があります。これにより、サーバーのリソースが消費され、サービス拒否が発生します。この CVE に関連するすべての OADP 問題のリストは、次の Jira リスト を参照してください。

    この問題を解決するには、OADP 1.1.7 または 1.2.3 にアップグレードすることを推奨します。

    詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。

  • OADP は現在、Velero で restic を使用した AWS EFS ボリュームのバックアップと復元をサポートしていません (OADP-778)。
  • PVC ごとの VolumeSnapshotContent スナップショットの Ceph 制限により、CSI バックアップが失敗する場合があります。

    同じ永続ボリューム要求 (PVC) のスナップショットを複数作成できますが、スナップショットの定期的な作成をスケジュールすることはできません。

    • CephFS の場合、PVC ごとに最大 100 スナップショットを作成できます。
    • RADOS ブロックデバイス (RBD) の場合は、PVC ごとに最大 512 個のスナップショットを作成できます。(OADP-804) および (OADP-975)

      詳細は、ボリュームのスナップショット を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.