4.7. OADP の高度な特徴と機能
このドキュメントでは、OpenShift API for Data Protection (OADP) の高度な特徴と機能に関する情報を提供します。
4.7.1. 同一クラスター上での異なる Kubernetes API バージョンの操作
4.7.1.1. クラスター上の Kubernetes 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
4.7.1.2. API グループバージョンの有効化について
デフォルトでは、Velero は Kubernetes API の優先バージョンを使用するリソースのみをバックアップします。ただし、Velero には、この制限を克服する機能 (Enable API Group Versions) も含まれています。ソースクラスターでこの機能を有効にすると、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
は優先順位が最も高くなります。
- 宛先 クラスターの優先バージョン
- source_ クラスターの優先バージョン
- Kubernetes バージョンの優先順位が最も高い共通の非優先サポート対象バージョン
4.7.1.3. Enable API Group Versions の使用
Velero の Enable API Group Versions 機能を使用して、優先バージョンだけでなく、クラスターでサポートされている すべての Kubernetes API グループバージョンをバックアップできます。
Enable API Group Versions はまだベータ版です。
手順
-
EnableAPIGroupVersions
機能フラグを設定します。
apiVersion: oadp.openshift.io/vialpha1 kind: DataProtectionApplication ... spec: configuration: velero: featureFlags: - EnableAPIGroupVersions
4.7.2. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する
4.7.2.1. あるクラスターからのデータのバックアップと別のクラスターへの復元について
{oadp-first} は、同じ 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 の範囲
4.7.2.1.1. Operator
バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。
4.7.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
と呼ばれます。
Velero のファイルシステムバックアップ機能は Kopia と Restic の両方をサポートしていますが、現在 OADP は Restic のみをサポートしています。
- AWS リージョン間または Microsoft Azure リージョン間でデータを移行するには、Velero の File System Backup も使用する必要があります。
- Velero は、ソースクラスターより 前の Kubernetes バージョンを使用したクラスターへのデータの復元をサポートしていません。
- 理論的には、移行元よりも 新しい Kubernetes バージョンを備えた移行先にワークロードを移行することは可能ですが、カスタムリソースごとにクラスター間の API グループの互換性を考慮する必要があります。Kubernetes バージョンのアップグレードによりコアまたはネイティブ API グループの互換性が失われる場合は、まず影響を受けるカスタムリソースを更新する必要があります。
4.7.2.1.3. UID と GID の範囲
あるクラスターからデータをバックアップし、それを別のクラスターに復元する場合、UID (ユーザー ID) および GID (グループ ID) の範囲に関して潜在的な問題が発生する可能性があります。次のセクションでは、これらの潜在的な問題と軽減策について説明します。
- 問題点のまとめ
- namespace の UID 範囲および GID 範囲は、宛先クラスターで変更される可能性があります。OADP は、OpenShift UID 範囲のメタデータをバックアップおよび復元しません。バックアップされたアプリケーションに特定の UID が必要な場合は、復元時にその範囲が使用可能であることを確認してください。OpenShift の UID 範囲および GID 範囲の詳細は、A Guide to OpenShift and UIDs を参照してください。
- 問題の詳細な説明
シェルコマンド
oc create namespace
を使用して OpenShift Container Platform でネームスペースを作成すると、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 範囲の修正の手順 1 ~ 4 を実行して、移行後に UID 範囲を修正します。ステップ 1 はオプションです。
あるクラスターでのデータのバックアップと別のクラスターでのリストアの問題の解決に重点を置いた、OpenShift Container Platform の UID 範囲および GID 範囲の詳細な説明は、A Guide to OpenShift and UIDs を 参照してください。
4.7.2.2. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する
一般に、同じクラスターにデータをバックアップおよび復元するのと同じ方法で、1 つの OpenShift Container Platform クラスターからデータをバックアップし、別の OpenShift Container Platform クラスターに復元します。ただし、ある OpenShift Container Platform クラスターからデータをバックアップし、それを別のクラスターにリストアする場合は、追加の前提条件と手順の違いがいくつかあります。
前提条件
- プラットフォーム (AWS、Microsoft Azure、GCP など) でのバックアップと復元に関連するすべての前提条件、特にデータ保護アプリケーション (DPA) の前提条件については、このガイドの関連セクションで説明されています。
手順
ご使用のプラットフォームに指定されている手順に次の追加を加えます。
- リソースを別のクラスターに復元するには、バックアップストアの場所 (BSL) とボリュームスナップショットの場所が同じ名前とパスを持つようにしてください。
- 同じオブジェクトストレージの場所の認証情報をクラスター全体で共有します。
- 最良の結果を得るには、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
と呼ばれます。
4.7.3. 関連情報
API グループのバージョンの詳細は、同一クラスター上での異なる Kubernetes API バージョンの操作 を参照してください。
OADP Data Mover の詳細は、CSI スナップショットに Data Mover を使用する を参照してください。
OADP での Restic の使用の詳細は、Restic を使用したアプリケーションのバックアップ を参照してください。