1.6. バックアップおよびリストア Operator の管理

クラスターのバックアップおよび復元 Operator は自動的にインストールされません。MultiClusterHub リソースで cluster-backup パラメーターを true に設定して、バックアップコンポーネントを有効にします。有効にすると、クラスターのバックアップと復元のオペレーターが open-cluster-management-backup namespace にインストールされます。クラスターバックアップオペレーターをインストールすると、クラスターバックアップおよび復元オペレーターと同じ namespace に OADP Operator も自動的にインストールされます。

注記:

  • OADP Operator 1.0 はマルチアーキテクチャービルドをサポートしなくなり、公式リリース用に x86_64 ビルドのみを生成します。その結果、x86_64 以外のアーキテクチャーを使用している場合は、バックアップコンポーネントでインストールされた OADP Operator を正しいバージョンに置き換える必要があります。バージョンを置き換えるには、OADP Operator をアンインストールし、アーキテクチャーに一致するオペレーターを見つけてからインストールします。
  • 以前に OADP Operator をハブクラスターにインストールして使用していた場合は、バックアップコンポーネントの namespace とは異なる namespace で、このバージョンをアンインストールしてください。これは、バックアップコンポーネントが、コンポーネントの namespace にインストールされた OADP で動作するようになったためです。バックアップコンポーネントでインストールされた OADP Operator が所有する DataProtectionApplication リソースと同じストレージの場所を使用します。これは、前回の Operator と同じバックアップデータにアクセスします。Velero バックアップリソースが、このハブクラスターの新しい OADP Operator namespace 内に読み込まれるようになりました。

Velero は、Red Hat Advanced Cluster Management ハブクラスターの OADP Operator と共にインストールされます。Velero は、Red Hat Advanced Cluster Management ハブクラスターリソースのバックアップおよび復元に使用されます。

Velero のサポートされるストレージプロバイダーの一覧は、S3-Compatible オブジェクトストアプロバイダー を参照してください。

1.6.1. 前提条件

バックアップおよび復元 operator を有効にして使用するには、次の前提条件を満たしている必要があります。

  • バックアップの保存先となるクラウドストレージの 認証情報シークレットの作成 手順を必ず実行します。シークレットリソースは、バックアップコンポーネントの namespace にある OADP Operator の namespace に作成する必要があります。
  • アクティブ/パッシブハブクラスターの両方の場合:

    • Red Hat OpenShift Container Platform クラスターから、Red Hat Advanced Cluster Management for Kubernetes Operator バージョン 2.6.x をインストールします。MultiClusterHub リソースは、Red Hat Advanced Cluster Management のインストール時に自動的に作成され、Running のステータスを表示します。
    • クラスターのバックアップおよび復元 Operator は手動でインストールする必要があります。クラスターのバックアップおよび復元 Operator (cluster-backup) を有効にします。cluster-backup パラメーターを true に設定して MultiClusterHub リソースを編集します。これにより、バックアップコンポーネントと同じネームスペースに OADP オペレータがインストールされます。
  • パッシブハブクラスターの場合:

    • パッシブハブクラスターで復元操作を実行する前に、ハブクラスターを手動で設定し、すべての Operator をアクティブなハブクラスターと同じ namespace にインストールする必要があります。
    • Red Hat Advanced Cluster Management Operator が、初期ハブクラスターと同じ namespace にインストールされていることを確認します。次に DataProtectionApplication リソースを作成し、初期ハブクラスターがデータをバックアップしたのと同じストレージの場所に接続します。
  • DataProtectionAppliation リソースの作成時に作成したシークレットを使用します。

    以下の手順を実行して、DataProtectionApplication リソースのインスタンスを作成します。

    1. Red Hat OpenShift Container Platform コンソールから、Operators > Installed Operators を選択します。
    2. DataProtectionApplication の下の Create instance をクリックします。
    3. {ocp-short) コンソールを使用して設定を選択するか、DataProtectionApplication の例で説明されているように YAML ファイルを使用して、Velero インスタンスを作成します。
    4. DataProtectionApplication namespaceを open-cluster-management-backup に設定します。
    5. DataProtectionApplication リソースの仕様 (spec:) 値を適切に設定します。次に、Create をクリックします。

      デフォルトのバックアップストレージの場所を使用する場合は、backupStorageLocations セクションで値 default: true を設定します。以下の DataProtectionApplication リソースの例を確認します。

      apiVersion: oadp.openshift.io/v1alpha1
      kind: DataProtectionApplication
      metadata:
        name: dpa-sample
      spec:
        configuration:
          velero:
            defaultPlugins:
            - openshift
            - aws
          restic:
            enable: true
        backupLocations:
          - name: default
            velero:
              provider: aws
              default: true
              objectStorage:
                bucket: my-bucket
                prefix: my-prefix
              config:
                region: us-east-1
                profile: "default"
              credential:
                name: cloud-credentials
                key: cloud
        snapshotLocations:
          - name: default
            velero:
              provider: aws
              config:
                region: us-west-2
                profile: "default"

      DataProtectionApplication リソース を作成する例を参照してください。

  • 復元操作を実行する前に、Ansible Automation Platform、Red Hat OpenShift Container Platform GitOps、または証明書マネージャーなどの他の Operator がインストールされていることを確認します。これにより、新しいハブクラスターが初期のハブクラスターと同じように設定されます。
  • パッシブハブクラスターは、バックアップと復元 Operator、および前のハブクラスターで設定された他の Operator をインストールするときに、最初のハブクラスターと同じ namespace 名を使用する必要があります。

1.6.2. バックアップおよびリストア Operator の有効化

クラスターのバックアップおよび復元 Operator は、MultiClusterHub リソースの初回作成時に有効にできます。cluster-backup パラメーターは true に設定します。Operator を有効にすると、Operator リソースがインストールされます。

MultiClusterHub リソースがすでに作成されている場合には、MultiClusterHub リソースを編集して、クラスターバックアップ Operator をインストールまたはアンインストールできます。クラスターバックアップ Operator をアンインストールする場合は、cluster-backupfalse に設定します。

バックアップおよび復元 Operator が有効にされている場合には、MultiClusterHub リソースは以下の YAML ファイルのようになります。

apiVersion: operator.open-cluster-management.io/v1
  kind: MultiClusterHub
  metadata:
    name: multiclusterhub
    namespace: open-cluster-management
  spec:
    availabilityConfig: High
    enableClusterBackup: false
    imagePullSecret: multiclusterhub-operator-pull-secret
    ingress:
      sslCiphers:
        - ECDHE-ECDSA-AES256-GCM-SHA384
        - ECDHE-RSA-AES256-GCM-SHA384
        - ECDHE-ECDSA-AES128-GCM-SHA256
        - ECDHE-RSA-AES128-GCM-SHA256
    overrides:
      components:
        - enabled: true
          name: multiclusterhub-repo
        - enabled: true
          name: search
        - enabled: true
          name: management-ingress
        - enabled: true
          name: console
        - enabled: true
          name: insights
        - enabled: true
          name: grc
        - enabled: true
          name: cluster-lifecycle
        - enabled: true
          name: volsync
        - enabled: true
          name: multicluster-engine
        - enabled: true <<<<<<<<
          name: cluster-backup
    separateCertificateManagement: false

1.6.3. バックアップおよびリストア Operator の使用

バックアップをスケジュールおよび復元するには、以下の手順を実行します。

  1. バックアップおよび復元 Operator backupschedule.cluster.open-cluster-management.io を使用してバックアップスケジュールを作成し、restore.cluster.open-cluster-management.io リソースを使用してバックアップを復元します。
  2. 次のコマンドを実行して、backupschedule.cluster.open-cluster-management.io リソースを作成します。

    kubectl create -f cluster_v1beta1_backupschedule.yaml

    cluster_v1beta1_backupschedule.yaml リソースは、次のファイルのようになる場合があります。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: BackupSchedule
    metadata:
      name: schedule-acm
      namespace: open-cluster-management-backup
    spec:
      veleroSchedule: 0 */2 * * * # Create a backup every 2 hours
      veleroTtl: 120h # deletes scheduled backups after 120h; optional, if not specified, the maximum default value set by velero is used - 720h

    backupschedule.cluster.open-cluster-management.io spec プロパティーに関する以下の説明を確認してください。

    • veleroSchedule は必須のプロパティーで、バックアップをスケジュールする cron ジョブを定義します。
    • veleroTtl は任意のプロパティーで、スケジュールされているバックアップリソースの有効期限を定義します。指定されていない場合には、Velero で設定された最大デフォルト値 (720h) が使用されます。
  3. backupschedule.cluster.open-cluster-management.io リソースの状態をチェックします。3 つの schedule.velero.io リソースの定義が表示されます。以下のコマンドを実行します。

    oc get BackupSchedule -n open-cluster-management-backup
  4. 注意: 復元操作は、復元シナリオ向けに別のハブクラスターで実行します。復元操作を開始するには、バックアップを復元するハブクラスターに restore.cluster.open-cluster-management.io リソースを作成します。

    注意: 新しいハブクラスターにバックアップを復元する場合には、バックアップを作成した、前のバブクラスターがシャットダウンされていることを確認します。実行中の場合には、前のハブクラスターは、マネージドクラスターの調整機能により、マネージドクラスターが使用できなくなったことが検出されるとすぐに、マネージドクラスターの再インポートが試行されます。

    クラスターのバックアップおよび復元 Operator、backup schedule.cluster.open-cluster-management.io および restore.cluster.open-cluster-management.io リソースを使用して、バックアップまたは復元リソースを作成できます。cluster-backup-operator サンプル を参照してください。

  5. 次のコマンドを実行して、restore.cluster.open-cluster-management.io リソースを作成します。

    kubectl create -f cluster_v1beta1_backupschedule.yaml

    リソースは以下のファイルのようになります。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: latest
      veleroCredentialsBackupName: latest
      veleroResourcesBackupName: latest
  6. 以下のコマンドを実行して Velero Restore リソースを表示します。

    oc get restore.velero.io -n open-cluster-management-backup
  7. 次のコマンドを実行して、Red Hat Advanced Cluster Management Restore イベントを表示します。

    oc describe restore.cluster.open-cluster-management.io -n open-cluster-management-backup

Restore YAML リソースのパラメーターとサンプルの説明については、Restoring a backup セクションを参照してください。

1.6.4. Extending backup data

cluster.open-cluster-management.io/backup ラベルをリソースに追加することで、クラスターのバックアップおよび復元を使用してサードパーティーのリソースをバックアップできます。ラベルの値は、空の文字列を含む任意の文字列にすることができます。バックアップするコンポーネントを識別するのに役立つ値を使用してください。たとえば、コンポーネントが IDP ソリューションによって提供される場合は、cluster.open-cluster-management.io/backup: idp ラベルを使用します。

注意: マネージドクラスターのアクティブ化リソースが復元されたときにリソースを復元する場合は、cluster.open-cluster-management.io/backup ラベルに cluster-activation 値を使用します。マネージドクラスターのアクティブ化リソースを復元すると、マネージドクラスターは、復元が開始されたハブクラスターによってアクティブに管理されます。

1.6.5. Scheduling a cluster backup

backupschedule.cluster.open-cluster-management.io リソースを作成すると、バックアップスケジュールが有効になります。以下の backupschedule.cluster.open-cluster-management.io サンプルを表示します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm
  namespace: open-cluster-management-backup
spec:
  veleroSchedule: 0 */2 * * *
  veleroTtl: 120h

backupschedule.cluster.open-cluster-management.io リソースを作成したら、以下のコマンドを実行してスケジュールされたクラスターバックアップのステータスを取得します。

oc get BackupSchedule -n open-cluster-management-backup

1 つ前のコマンドの <oadp-operator-ns> パラメーターは、BackupSchedule が作成される namespace で、OADP Operator がインストールされている namespace と同じです。backupschedule.cluster.open-cluster-management.io リソースは、バックアップの生成に使用される schedule.velero.io リソースを 6 つ作成します。以下のコマンドを実行して、スケジュールされるバックアップの一覧を表示します。

os get schedules -A | grep acm

リソースは、以下のグループで個別にバックアップされます。

  • Credentials backup は、Hive 認証情報、Red Hat Advanced Cluster Management、およびユーザー作成の認証情報と ConfigMap を保存するバックアップファイルです。
  • リソースバックアップ: Red Hat Advanced Cluster Management リソースのバックアップと汎用リソース用のバックアップが含まれています。これらのリソースは、cluster.open-cluster-management.io/backup というラベルを使用します。
  • マネージドクラスターのバックアップ。これには、バックアップが復元されるハブクラスターへのマネージドクラスター接続をアクティブにするリソースのみが含まれます。

注記: リソースバックアップ ファイルには、マネージドクラスター固有のリソースが含まれますが、マネージドクラスターをハブクラスターに接続するリソースのサブセットは含まれません。マネージドクラスターを接続するリソースは、アクティベーションリソースと呼ばれ、マネージドクラスターのバックアップに含まれます。新しいハブクラスターで 認証情報 および リソース のバックアップのみのバックアップを復元すると、新しいハブクラスターには、Hive API で作成されたすべてのマネージドクラスターが切り離された状態で表示されます。ただし、インポート操作を使用してプライマリーハブクラスターにインポートされたマネージドクラスターは、アクティベーションデータがパッシブハブクラスターに復元された場合にのみ表示されます。この時点で、マネージドクラスターは、バックアップファイルを作成した元のハブクラスターに引き続き接続されます。

アクティベーションデータが復元されると、Hive API を使用して作成されたマネージドクラスターのみが新しいハブクラスターに自動的に接続されます。他のすべてのマネージドクラスターは 保留 状態で表示されるため、新しいクラスターに手動で再接続する必要があります。

1.6.6. バックアップの復元

一般的な復元のシナリオでは、バックアップが実行されるハブクラスターが利用できなくなり、バックアップデータを新しいハブクラスターに移動する必要があります。これには、新しいハブクラスターでクラスター復元操作を実行します。この場合、復元操作はバックアップが作成される場所とは異なるハブクラスターで実行します。

また、以前のスナップショットからのデータを復元できるように、バックアップデータを取得したハブクラスターでデータを復元するケースもあります。この場合、復元とバックアップ操作の両方が同じハブクラスターで実行されます。

ハブクラスターで restore.cluster.open-cluster-management.io リソースを作成した後に、oc get restore -n open-cluster-management-backup のコマンドを実行して復元操作のステータスを取得できます。また、バックアップファイルに含まれるバックアップのリソースが作成されていることを確認できる必要があります。

注記: Restore passive resources セクションで説明されているように、syncRestoreWithNewBackups オプションを使用して true に設定しない限り、restore.cluster.open-cluster-management.io リソースは 1 回実行されます。復元操作の完了後に同じ復元操作を再度実行する場合は、同じ spec オプションで新しい restore.cluster.open-cluster-management.io リソースを作成する必要があります。

復元操作を使用して、バックアップ操作で作成される全バックアップタイプ 3 つを復元します。ただし、特定の種類のバックアップ (マネージドクラスターのみ、ユーザー資格情報のみ、またはハブクラスターリソースのみ) のみをインストールするように選択できます。

復元では、以下の 3 つの必要な spec プロパティーを定義します。ここでは、バックアップしたファイルのタイプに対して復元ロジックが定義されます。

  • veleroManagedClustersBackupName は、マネージドクラスターのアクティベーションリソースの復元オプションを定義するのに使用されます。
  • veleroCredentialsBackupName は、ユーザーの認証情報の復元オプションを定義するために使用されます。
  • veleroResourcesBackupName は、ハブクラスターリソース (ApplicationsPolicy、その他のハブクラスターリソース (マネージドクラスターパッシブデータなど)) の復元オプションを定義するのに使用されます。

    前述のプロパティーの有効な値は次のとおりです。

    • latest: このプロパティーは、このタイプのバックアップで使用可能な、最後のバックアップファイルを復元します。
    • skip: このプロパティーは、現在の復元操作でこのタイプのバックアップの復元は試行ません。
    • <backup_name>: このプロパティーは、名前で参照する指定のバックアップを復元します。

restore.cluster.open-cluster-management.io で作成された restore.velero.io リソースの名前は、<restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name> のテンプレートルールを使用して生成されます。以下の説明を参照してください。

  • restore.cluster.open-cluster-management.io は、復元を開始する現在の restore.cluster.open-cluster-management.io リソースの名前です。
  • Velero-backup-resource-name は、データの復元に使用される Velero バックアップファイルの名前です。たとえば、restore.cluster.open-cluster-management.io リソース restore-acmrestore.velero.io 復元リソースを作成します。フォーマットについては、以下の例を参照してください。

    • restore-acm-acm-managed-clusters-schedule-20210902205438 は、マネージドクラスターのアクティベーションデータのバックアップを復元するのに使用されます。このサンプルでは、リソースの復元に使用される backup.velero.io バックアップ名は acm-managed-clusters-schedule-20210902205438 です。
    • restore-acm-acm-credentials-schedule-20210902206789 は、認証情報バックアップの復元に使用されます。このサンプルでは、リソースの復元に使用される backup.velero.io バックアップ名は acm-managed-clusters-schedule-20210902206789 です。
    • restore-acm-acm-resources-schedule-20210902201234 は、アプリケーション、ポリシー、およびマネージドクラスターパッシブデータバックアップなどの他のハブクラスターリソースを復元するのに使用されます。このサンプルでは、リソースの復元に使用される backup.velero.io バックアップ名は acm-managed-clusters-schedule-20210902201234 です。

注記: skip がバックアップタイプに使用されている場合は、restore.velero.io は作成されません。

以下の YAML サンプルで、クラスターの リストア リソースを参照してください。この例では、利用可能な最新のバックアップファイルを使用して、3 つのタイプのバックアップファイルがすべて復元されています。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

注記 Hive API によって作成されたマネージドクラスターのみが、マネージドクラスターのバックアップからの acm-managed-clusters バックアップが別のハブクラスターに復元されるときに、新しいハブクラスターに自動的に接続されます。他のすべてのマネージドクラスターは Pending Import 状態のままであり、新しいハブクラスターにインポートし直す必要があります。詳細は、Restoring imported managed clusters (Technology Preview) を参照してください。

1.6.6.1. Preparing the new hub cluster

新しいハブクラスターで復元操作を実行する前に、ハブクラスターを手動で設定し、初期ハブクラスターと同じ Operator をインストールする必要があります。Red Hat Advanced Cluster Management Operator は、初期ハブクラスターと同じ namespace にインストールし、DataProtectionApplication リソースを作成してから、初期ハブクラスターがデータをバックアップしたのと同じストレージの場所に接続する必要があります。

MultiClusterEngine リソースへの変更を含め、Red Hat Advanced Cluster Management オペレーターによって作成された MultiClusterHub リソースの最初のハブクラスターと同じ設定を使用します。

たとえば、初期ハブクラスターに Ansible Automation Platform、Red Hat OpenShift GitOps、cert-manager などの他の Operator がインストールされている場合は、復元操作を実行する前にそれらをインストールする必要があります。これにより、新しいハブクラスターが初期のハブクラスターと同じ方法で設定されます。

1.6.6.2. 復元前のハブクラスターのクリーニング

Velero は現在、ハブクラスターの既存のバックアップリソースを省略します。これにより、新しいハブクラスターでハブクラスターデータを復元する時に使用可能なシナリオが制限されます。新しいハブクラスターが使用され、復元が複数回適用される場合は、復元が実行する前にデータがクリーンアップされない限り、ハブクラスターをパッシブ設定として使用することは推奨されません。新しいハブクラスターのデータは、復元されたリソースで利用可能なデータを反映していません。

restore.cluster.open-cluster-management.io リソースが作成されると、クラスターのバックアップおよび復元 Operator は一連の手順を実行し、Velero 復元を開始する前にハブクラスターを消去して復元の準備を行います。

cleanup オプションは cleanupBeforeRestore プロパティーを使用して、クリーンアップするオブジェクトのサブセットを特定します。このクリーンアップには、以下の 3 つのオプションを設定できます。

  • None: クリーンアップは必要なく、Velero の復元を開始するだけです。これは、新しいハブクラスターで使用されます。
  • CleanupRestored: 以前の Red Hat Advanced Cluster Management の復元で作成されたすべてのリソースを消去します。このプロパティーは、CleanupAll プロパティーよりも影響範囲が少ないので、こちらを使用することが推奨されます。
  • CleanupAll: 復元操作を実行してからリソースが作成されていなくても、Red Hat Advanced Cluster Management バックアップとして含まれている可能性のある、ハブクラスター上の全リソースを消去します。これは、ハブクラスターに追加のコンテンツが作成された場合にクリーンアップが必要となるため、使用されます。このオプションは、以前のバックアップではなく、ユーザーによって作成されたハブクラスター上のリソースを消去するため、このオプションは注意して使用してください。CleanupRestored オプションを使用し、ハブクラスターが災害シナリオのパッシブクラスターとして指定されている場合は、ハブクラスターのコンテンツを手動で更新しないことを強くお勧めします。最終的な選択肢として、CleanupAll オプションを使用するようにしてください。

注記:

  • Velero は、復元されたバックアップにリソースがない場合に、velero 復元リソースのステータス PartiallyFailed を設定します。これは、対応するバックアップが空であるために作成された restore.velero.io リソースのいずれかによりリソースが復元されない場合には、restore.cluster.open-cluster-management.io リソースが PartiallyFailed ステータスになる可能性があることを意味します。
  • syncRestoreWithNewBackups:true を使用して新規バックアップが利用可能な場合にパッシブデータの復元を継続しない限り、restore.cluster.open-cluster-management.io リソースは 1 回実行されます。この場合、同期サンプルで復元パッシブに従います。Restoring passive resources while checking for backups を参照してください。復元操作が完了し、同じハブクラスターで別の復元操作を実行する場合は、新しい restore.cluster.open-cluster-management.io リソースを作成する必要があります。
  • 複数の restore.cluster.open-cluster-management.io リソースを作成できますが、いつでもアクティブにできるのは 1 つだけです。

1.6.6.3. Restoring passive resources while checking for backups

新しいバックアップが利用可能かどうかを引き続き確認し、それらを自動的に復元しながら、restore-passive-sync サンプルを使用してパッシブデータを復元します。新しいバックアップを自動的に復元するには、syncRestoreWithNewBackups パラメーターを true に設定する必要があります。また、最新のパッシブデータだけを復元する必要もあります。サンプルの例は、このセクションの最後にあります。

VeleroResourcesBackupName および VeleroCredentialsBackupName パラメーターを latest に設定し、VeleroManagedClustersBackupName パラメーターを省略して スキップ します。VeleroManagedClustersBackupNamelatest に設定された直後に、マネージドクラスターは新しいハブクラスターでアクティベートされ、プライマリーハブクラスターになります。

アクティベートされたマネージドクラスターがプライマリーハブクラスターになると、復元リソースが Finished に設定され、true に設定されていても syncRestoreWithNewBackups は無視されます。

デフォルトでは、コントローラーは syncRestoreWithNewBackupstrue に設定されると、30 分ごとに新規バックアップをチェックします。新しいバックアップが見つかった場合は、バックアップされたリソースを復元します。restoreSyncInterval パラメーターを更新してチェックの期間を変更できます。

たとえば、10 分ごとにバックアップをチェックする次のリソースを参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-sync
  namespace: open-cluster-management-backup
spec:
  syncRestoreWithNewBackups: true # restore again when new backups are available
  restoreSyncInterval: 10m # check for new backups every 10 minutes
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

1.6.6.4. Restoring passive resources

パッシブ設定でハブクラスターリソースを復元するには、restore-acm-passive サンプルを使用します。パッシブデータは、シークレット、ConfigMap、アプリケーション、ポリシー、およびすべてのマネージドクラスターカスタムリソースなどのバックアップデータで、マネージドクラスターとハブクラスター間の接続をアクティブ化しません。バックアップリソースは、認証情報のバックアップおよび復元リソースによりハブクラスターで復元されます。

以下のサンプルを参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: skip
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

1.6.6.5. アクティベーションリソースの復元

ハブクラスターでクラスターを管理する場合は、restore-acm-passive-activate サンプルを使用します。この場合、パッシブリソースを使用するハブクラスターで他のデータがすでに復元されていることを前提とします。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm-passive-activate
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: skip
  veleroResourcesBackupName: skip

パッシブリソースを復元した方法に応じて、アクティベーションリソースを復元するいくつかのオプションがあります。

  • Restore passive resources while checking for backups to restore passive data セクションに記載されているように、restore-acm-passive-sync cluster.open-cluster-management.io リソースを使用した場合は、このリソースで veleroManagedClustersBackupName の値を latest の値に更新します。その結果、マネージドクラスターリソースと restore-acm-passive-sync リソースが復元されます。
  • パッシブリソースを 1 回限りの操作で復元した場合、またはリソースをまだ復元していない場合は、Restoring all resources セクションで指定されているように、すべてのリソースを復元することを選択します。

1.6.6.6. Restoring all resources

一度にすべてのデータを復元し、ハブクラスターがマネージドクラスターを 1 つのステップで管理するようにする場合は、restore-acm サンプルを使用します。ハブクラスターに restore.cluster.open-cluster-management.io リソースを作成したら、次のコマンドを実行して復元操作のステータスを取得します。

oc get restore -n open-cluster-management-backup

サンプルは、次のリソースに酷似している可能性があります。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

ハブクラスターから、バックアップファイルに含まれるバックアップされたリソースが作成されていることを確認します。

1.6.6.7. Restoring imported managed clusters

Hive API を使用してプライマリーハブクラスターに接続されたマネージドクラスターのみが、アクティベーションデータが復元される新しいハブクラスターに自動的に接続されます。これらのクラスターは、Clusters タブの Create cluster ボタンを使用して、プライマリーハブクラスター上に作成されています。Import cluster ボタンを使用して最初のハブクラスターに接続されたマネージドクラスターは、アクティベーションデータが復元されると Pending Import として表示され、新しいハブクラスターにインポートし直す必要があります。

Hive がマネージドクラスター kubeconfig をハブクラスターのマネージドクラスター namespace に格納するため、Hive マネージドクラスターを新しいハブクラスターに接続できます。これは、新しいハブクラスターでバックアップおよび復元されます。次に、インポートコントローラーは、復元された設定を使用してマネージドクラスターのブートストラップ kubeconfig を更新します。これは、Hive API を使用して作成されたマネージドクラスターでのみ使用できます。インポートされたクラスターでは使用できません。

インポートされたクラスターを新しいハブクラスターに再接続するには、復元操作の開始後に auto-import-secret リソースを手動で作成します。詳細は、Importing the cluster with the auto import secret を参照してください。

Pending Import 状態のクラスターごとに、マネージドクラスターの namespace に auto-import-secret リソースを作成します。インポートコンポーネントが新しいハブクラスターで自動インポートを開始するのに十分な権限を持つ kubeconfig またはトークンを使用します。マネージドクラスターに接続するには、トークンを使用して各マネージドクラスターにアクセスできる必要があります。トークンには、klusterlet ロールバインディングまたは同じアクセス権限を持つロールが必要です。

1.6.6.8. 他の復元サンプルの使用

次の復元セクションを参照して、さまざまな種類のバックアップファイルを復元するための YAML の例を確認してください。

  • 3 種類のバックアップリソースをすべて復元します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupSchedule: latest
      veleroCredentialsBackupSchedule: latest
      veleroResourcesBackupSchedule: latest
  • マネージドクラスターリソースのみを復元します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: latest
      veleroCredentialsBackupName: skip
      veleroResourcesBackupName: skip
  • acm-managed-clusters-schedule-20210902205438 バックアップを使用して、マネージドクラスターのリソースのみを復元します。

    apiVersion: cluster.open-cluster-management.io/v1beta1
    kind: Restore
    metadata:
      name: restore-acm
      namespace: open-cluster-management-backup
    spec:
      veleroManagedClustersBackupName: acm-managed-clusters-schedule-20210902205438
      veleroCredentialsBackupName: skip
      veleroResourcesBackupName: skip

    注記:

    • restore.cluster.open-cluster-management.io リソースは 1 回実行されます。復元操作が完了したら、オプションで同じハブクラスターで別の復元操作を実行できます。新しい復元操作を実行するには、restore.cluster.open-cluster-management.io リソースを新規作成する必要があります。
    • 複数の restore.cluster.open-cluster-management.io を作成できますが、同時に実行できるのは 1 つのみです。

1.6.6.9. 復元イベントの表示

以下のコマンドを使用して、復元イベントに関する情報を取得します。

oc describe -n <oadp-n> <restore-name>

イベント一覧は以下の例のようになります。

Spec:
  Cleanup Before Restore:               CleanupRestored
  Restore Sync Interval:                4m
  Sync Restore With New Backups:        true
  Velero Credentials Backup Name:       latest
  Velero Managed Clusters Backup Name:  skip
  Velero Resources Backup Name:         latest
Status:
  Last Message:                     Velero restores have run to completion, restore will continue to sync with new backups
  Phase:                            Enabled
  Velero Credentials Restore Name:  example-acm-credentials-schedule-20220406171919
  Velero Resources Restore Name:    example-acm-resources-schedule-20220406171920
Events:
  Type    Reason                   Age   From                Message
  ----    ------                   ----  ----                -------
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406155817
  Normal  Prepare to restore:      76m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-generic-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-resources-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-cluster-schedule-20220406155817
  Normal  Velero restore created:  74m   Restore controller  example-acm-credentials-hive-schedule-20220406155817
  Normal  Prepare to restore:      64m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406165328
  Normal  Prepare to restore:      62m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-cluster-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-generic-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-resources-schedule-20220406165328
  Normal  Velero restore created:  61m   Restore controller  example-acm-credentials-hive-schedule-20220406165328
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-generic-schedule-20220406171920
  Normal  Prepare to restore:      38m   Restore controller  Cleaning up resources for backup acm-resources-schedule-20220406171920
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-hive-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-cluster-schedule-20220406171919
  Normal  Prepare to restore:      36m   Restore controller  Cleaning up resources for backup acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-cluster-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-schedule-20220406171919
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-generic-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-resources-schedule-20220406171920
  Normal  Velero restore created:  36m   Restore controller  example-acm-credentials-hive-schedule-20220406171919

1.6.6.10. プライマリークラスターのシャットダウン

新しいハブクラスターにバックアップを復元する場合には、バックアップを作成した、前のバブクラスターがシャットダウンされていることを確認します。そのクラスターが実行中の場合には、前のハブクラスターは、マネージドクラスターの調整機能により、マネージドクラスターが使用できなくなったことが検出されると、マネージドクラスターの再インポートが試行されます。

1.6.7. バックアップまたは復元設定の検証

クラスターのバックアップおよび復元 Operator の Helm チャート (cluster-backup-chart) は、ハブクラスターに backup-restore-enabled ポリシーをインストールし m バックアップと復元のコンポーネントに関する問題について通知するために使用されます。backup-restore-enabled ポリシーには、以下の制約を確認するテンプレートセットが含まれます。

  • Pod の検証

    以下のテンプレートは、Pod のステータスでバックアップコンポーネントおよび依存関係の有無を確認します。

    • acm-backup-pod-running テンプレートは、バックアップおよび復元 Operator Pod が実行されているかどうかを確認します。
    • OADP-pod-running テンプレートは、OADP Operator Pod が実行されているかどうかを確認します。
    • velero-pod-running テンプレートは Velero Pod が実行されているかどうかを確認します。
  • Data Protection Application の検証

    • data-protection-application-available テンプレートは、DataProtectioApplicatio.oadp.openshift.io リソースが作成されるかどうかを確認します。この OADP リソースは Velero 設定をセットアップします。
  • バックアップストレージの検証

    • backup-storage-location-available テンプレートは、BackupStorageLocation.velero.io リソースが作成され、ステータス値が Available かどうかを確認します。これは、バックアップストレージへの接続が有効であることを意味します。
  • BackupSchedule 競合検証

    • acm-backup-clusters-collision-report テンプレートは、BackupSchedule.cluster.open-cluster-management.io が現在のハブクラスターに存在する場合に、ステータスが BackupCollision ではないことを検証します。これにより、バックアップデータをストレージの場所に書き込むときに、現在のハブクラスターが他のハブクラスターと競合していないことを確認できます。

      BackupCollision 状態の定義については、Backup Collisions セクションを参照してください。

  • BackupSchedule および復元ステータスの検証

    • acm-backup-phase-validation テンプレートは、BackupSchedule.cluster.open-cluster-management.io が現在のクラスターに存在する場合に、ステータスが Failed でないこと、または の状態であることを確認します。これにより、このクラスターがプライマリーハブクラスターであり、バックアップを生成している場合に BackupSchedule.cluster.open-cluster-management.io ステータスが正常であることが保証されます。
    • 同じテンプレートは、Restore.cluster.open-cluster-management.io が現在のクラスターに存在する場合に、ステータスが 失敗 でないこと、または の状態にないことを確認します。これにより、このクラスターがセカンダリーハブクラスターであり、バックアップを復元する場合に、Restore.cluster.open-cluster-management.io のステータスが正常であることが保証されます。
  • バックアップの存在検証

    • acm-managed-clusters-schedule-backups-available テンプレートは、BackupStorageLocation.velero.io で指定された場所で Backup.velero.io リソースが利用可能かどうかを確認し、バックアップが BackupSchedule.cluster.open-cluster-management.io リソースによって作成されるかどうかを確認します。これにより、バックアップが少なくとも 1 回実行され、バックアップと復元 Operator が検証されます。
  • 完了するためのバックアップ

    • acm-backup-in-progress-report テンプレートは、Backup.velero.io リソースが InProgress 状態で停止していないか確認します。この検証が追加されるのは、多数のリソースがある場合、バックアップの実行中に velero Pod が再起動し、バックアップが完了せずに進行中のままになるためです。通常のバックアップ中、バックアップリソースは、実行中のどこかの時点で進行中になりますが、停止しているわけではなく、完了まで実行されます。スケジュールの実行中およびバックアップの進行中に acm-backup-in-progress-report テンプレートが警告を報告するのは正常です。
  • cron ジョブとしてアクティブに実行されるバックアップ

    • BackupSchedule.cluster.open-cluster-management.io はアクティブに実行され、ストレージの場所に新しいバックアップを保存します。この検証は、backup-schedule-cron-enabled ポリシーテンプレートにより行われます。テンプレートは、ストレージの場所に velero.io/schedule-name: acm-validation-policy-schedule ラベルの付いた Backup.velero.io があることを確認します。

      acm-validation-policy-schedule バックアップは、バックアップ cron スケジュールの時刻が設定された後に期限切れになるように設定されています。バックアップを作成するために実行されている cron ジョブがない場合には、古い acm-validation-policy-schedule バックアップは期限切れになり、新しいバックアップが作成されないので削除されます。したがって、現在 acm-validation-policy-schedule backups が存在しない場合には、アクティブな cron ジョブがバックアップを生成することはありません。

      このポリシーは、ハブクラスターがアクティブで、バックアップを作成または復元するときに、バックアップの問題をハブクラスター管理者に通知することを目的としています。

1.6.8. サーバー側の暗号化を使用したデータの保護

サーバー側の暗号化は、保存場所でデータを受信するアプリケーションまたはサービスのデータ暗号化です。バックアップメカニズム自体は、転送中 (バックアップストレージの場所との間を移動するとき) または保存中 (バックアップストレージの場所のディスクに保存されている間) にデータを暗号化しません。代わりに、オブジェクトおよびスナップショットシステムのネイティブメカニズムに依存しています。

ベストプラクティス: 使用可能なバックアップストレージのサーバー側の暗号化を使用して、宛先でデータを暗号化します。バックアップには、認証情報や設定ファイルなど、ハブクラスターの外部に保存するときに暗号化する必要があるリソースが含まれています。

serverSideEncryption パラメーターおよび kmsKeyId パラメーターを使用して、Amazon S3 に保存されているバックアップの暗号化を有効にすることができます。詳細は、バックアップストレージの場所 YAML を参照してください。次のサンプルは、DataProtectionApplication リソースを設定するときに AWS KMS キー ID を指定します。

spec:
  backupLocations:
    - velero:
        config:
          kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
          profile: default
          region: us-east-1

他のストレージプロバイダーの設定可能なすべてのパラメーターについては、Velero がサポートするストレージプロバイダー を参照してください。