第1章 ビジネス継続性

クラスターのバックアップと復元 Operator のソリューションは、マネージドクラスター、アプリケーション、ポリシーなど、すべてのハブクラスターリソースのバックアップと復元のサポートを提供します。このソリューションを使用して、基本的なハブクラスターのインストールを拡張するサードパーティーリソースをバックアップします。このバックアップソリューションを使用すると、cron ベースのバックアップスケジュールを定義します。これは、指定された時間間隔で実行し、ハブクラスターのコンテンツの最新バージョンを継続的にバックアップします。

ハブクラスターを交換する必要がある場合、またはハブクラスターに障害が発生したときに障害シナリオにある場合は、新しいハブクラスターをデプロイし、バックアップデータを新しいハブクラスターに移動できます。

次のクラスターのバックアップおよび復元プロセスのリストと、バックアップデータを識別するためにリソースとグループをバックアップまたは除外する方法を確認します。

Red Hat Advanced Cluster Management スケジュールを使用して、リソースタイプまたはラベルアノテーションに基づいて個別のバックアップファイルにグループ化されたハブクラスターリソースをバックアップできます。

BackupSchedule.cluster.open-cluster-management.io リソースは、4 つの Schedule.velero.io リソースのセットを作成します。これらの schedule.velero.io リソースは、リソースとも呼ばれるバックアップファイルを生成します。

スケジュールされたバックアップファイルの一覧を表示するには、oc get schedules -A | grep acm のコマンドを実行します。

スケジュールされたバックアップファイルは backup.velero.io です。これらのスケジュールされたバックアップファイルの説明を表示するには、次の表を参照してください。

リソースに cluster.open-cluster-management.io/backup ラベルを追加すると、そのリソースは自動的に acm-resources-generic-schedule バックアップに追加されます。ただし、Secrets および ConfigMap リソースは、backup acm-credentials-schedule- にバックアップされます。マネージドクラスターを新しいハブクラスターに移動した後、および復元されたリソースで veleroManagedClustersBackupName:latest を使用する場合は、ラベル値を cluster-activation に設定します。

cluster.open-cluster-management.io/backup ラベルを cluster-activation に設定すると、マネージドクラスターをアクティブ化しない限り、リソースが復元されないようになります。以下の例を参照してください。

apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

注記: マネージドクラスターの namespace またはその namespace 内のリソースは、クラスターのアクティブ化ステップで、どちらかを復元する必要があります。したがって、マネージドクラスターの namespace に作成されたバックアップリソースに追加する必要がある場合は、cluster.open-cluster-management.io/backup ラベルの cluster-activation 値を使用してください。復元プロセスを理解するには、次の情報を参照してください。

cluster.open-cluster-management.io/backup: cluster-activation ラベルを使用して識別され、acm-resources-generic-schedule バックアップによって保存されるアクティベーションデータリソースとは別に、クラスターのバックアップおよび復元 Operator には、デフォルトでは、アクティベーションセット内のいくつかのリソースが含まれます。次のリソースは、acm-managed-clusters-schedule バックアップによってバックアップされます。

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

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

アクティブ/パッシブ設定では、アクティブなハブクラスターが 1 つと、パッシブなハブクラスターが複数あります。アクティブなハブクラスターは、プライマリーハブクラスターとも見なされ、プライマリーハブクラスターは、BackupSchedule.cluster.open-cluster-management.io リソースを使用して、クラスターを管理し、定義された時間間隔でリソースをバックアップします。

注: プライマリーハブクラスターのデータをバックアップするには、アクティブ/パッシブ 設定は必要ありません。ハブクラスターデータのバックアップと保存のみが可能です。これにより、問題や障害が発生した場合に、新しいハブクラスターをデプロイし、この新しいハブクラスター上にプライマリーハブクラスターデータを復元できます。プライマリーハブクラスターのデータを回復する時間を短縮するには、アクティブ/パッシブ 設定を使用します。ただし、これは必須ではありません。

パッシブハブクラスターは、最新のバックアップを継続的に取得し、パッシブデータを復元します。パッシブハブは、Restore.cluster.open-cluster-management.io リソースを使用して、新規バックアップデータが利用可能な場合に、プライマリーハブクラスターからパッシブデータを復元します。これらのハブクラスターは、プライマリーハブクラスターで障害が発生した場合にプライマリーハブに切り替えられるように、スタンバイ状態にあります。

アクティブ/パッシブのハブクラスターは同じストレージの場所に接続されており、プライマリーハブクラスターは、プライマリーハブクラスターは、バックアップにアクセスするために、パッシブハブクラスターのデータをバックアップします。この自動復元を設定する方法の詳細は、バックアップの確認中にパッシブリソースを復元する を参照してください。

以下の図は、アクティブなハブクラスターがローカルクラスターを管理し、ハブクラスターデータを一定間隔でバックアップします。

パッシブハブクラスターは、マネージドクラスターをパッシブハブクラスターに移動するマネージドクラスターアクティベーションデータを除いて、このデータを復元します。パッシブハブクラスターは、パッシブデータを継続的に復元できます。パッシブハブクラスターは、パッシブデータを 1 回限りの操作として復元できます。詳細は、パッシブリソースの復元 を参照してください。

プライマリーハブクラスターに障害が発生した場合、ハブ管理者は、マネージドクラスターを引き継ぐパッシブハブクラスターを選択できます。次の 障害復旧図 では、ハブクラスター N を新しいプライマリーハブクラスターとして使用する方法を示しています。

ハブクラスター N は、マネージドクラスターのアクティブ化データを復元します。マネージドクラスターは ハブクラスター N に接続します。BackupSchedule.cluster.open-cluster-management.io リソースを作成し、最初のプライマリーハブクラスターと同じストレージの場所にバックアップを保存することにより、新しいプライマリーハブクラスターである ハブクラスター N のバックアップをアクティブ化します。

その他のパッシブハブクラスターはすべて、新しいプライマリーハブクラスターが作成したバックアップデータを使用してパッシブデータを復元するようになりました。ハブクラスター N がプライマリーハブクラスターとなり、クラスターの管理とデータのバックアップを行います。

重要:

パッシブリソースの詳細は、次の復元オプションを参照してください。

バックアップおよび復元 Operator を使用するには、ハブクラスターを設定する必要があります。ハブクラスターを設定するには、次のセクションを順番に完了します。

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

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

バックアップおよび復元 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

ハブクラスターのステータスがパッシブハブクラスターからプライマリーハブクラスターに、またはプライマリーハブクラスターからパッシブに変更され、異なるハブクラスターが同じストレージの場所にデータをバックアップすると、バックアップの競合が発生する可能性があります。

その結果、最新のバックアップは、プライマリーハブクラスターではなくなったハブクラスターによって生成されます。BackupSchedule.cluster.open-cluster-management.io リソースがまだ有効であるため、このハブクラスターは引き続きバックアップを生成します。

障害復旧テスト操作などの制御された環境で復元操作を実行する場合は、バックアップハブクラスターで BackupSchedule paused プロパティーを使用すると、バックアップの競合を防ぐことができます。新しいハブクラスターにリソースを復元する前に、BackupSchedule リソースで paused=true プロパティーを設定して、バックアップハブの BackupSchedule リソースを一時停止します。

バックアップの競合を引き起こす可能性のある 2 つのシナリオは、次のリストを参照してください。

バックアップの競合を防止および報告するには、BackupSchedule.cluster.open-cluster-management.io リソースの BackupCollision 状態を使用します。コントローラーは、保管場所の最新のバックアップが現在のハブクラスターから生成されたかどうかを定期的に確認します。そうでない場合は、別のハブクラスターが最近バックアップデータを保存場所に書き込んだことになり、ハブクラスターが別のハブクラスターと競合していることを示します。

バックアップ競合シナリオでは、現在のハブクラスターの BackupSchedule.cluster.open-cluster-management.io リソースのステータスが BackupCollision に設定されます。データの破損を防ぐために、このリソースは Schedule.velero.io リソースを削除します。バックアップポリシーは BackupCollision を報告します。

同じシナリオで、管理者はどのハブクラスターがストレージの場所に書き込むかを確認します。管理者は、無効なハブクラスターから BackupSchedule.cluster.open-cluster-management.io リソースを削除する前にこの検証を実行します。その後、管理者は有効なプライマリーハブクラスターに新しい BackupSchedule.cluster.open-cluster-management.io リソースを作成し、バックアップを再開できます。

バックアップの競合があるかどうかを確認するには、次のコマンドを実行します。

oc get backupschedule -A

バックアップの競合がある場合は、出力は次の例のようになります。

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

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

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

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

注記: 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 状態のままであり、新しいハブクラスターにインポートし直す必要があります。詳細は、インポートしたマネージドクラスターの復元 を参照してください。

クラスター上のバックアップデータを復元する必要がある場合は、プライマリーハブクラスターまたは復元操作の前にユーザーリソースが作成されたハブクラスターを使用する代わりに、新しいクラスターを作成します。ハブクラスターの復元操作中に、復元されるバックアップデータの一部でない場合に、既存のリソースをクリーンアップするようにハブクラスターのバックアップの復元を設定できます。復元では、以前のバックアップによって作成されたリソースは消去されますが、ユーザーリソースは消去されません。その結果、このハブクラスター上でユーザーが作成したリソースは消去されないため、このハブクラスター上のデータには、復元されたリソースで使用可能なデータが反映されません。

パッシブハブでの復元操作のみを検証し、その後プライマリーハブクラスターの使用に戻る障害復旧テストは、プライマリーハブクラスターをパッシブクラスターとして使用できる状況の 1 つです。この復元テストシナリオでは、ハブバックアップシナリオのみをテストします。新しいリソースを作成するためにプライマリーハブクラスターは使用しません。代わりに、バックアップデータはプライマリーハブクラスターからパッシブハブクラスターに一時的に移動しました。すべてのリソースをこのハブクラスターに復元すると、最初のプライマリーハブクラスターを再びプライマリーハブクラスターにすることができます。この操作により、復元後の操作が実行し、マネージドクラスターがこのハブクラスターに戻されます。

ハブクラスターでバックアップデータを復元する必要がある場合は、プライマリーハブクラスターまたは復元操作の前に以前のユーザーがリソースを作成したハブクラスターを使用する代わりに、新しいハブクラスターを作成します。

障害復旧シナリオでは、バックアップをパッシブハブクラスターに復元するときに、障害発生中に失敗したハブクラスターと同じハブクラスターが必要になります。アプリケーション、ポリシー、追加のマネージドクラスターなど、その他のユーザーリソースは必要ありません。

このハブクラスターでバックアップを復元する場合、このハブクラスターによって管理されるマネージドクラスターがあると、復元操作によってそれらのクラスターがデタッチされ、クラスターリソースが削除される可能性があります。復元操作では、復元されたバックアップに含まれないリソースをクリーンアップするためにこれを行います。その結果、このハブクラスターのコンテンツは最初のハブクラスターと同じになります。この場合、マネージドクラスターのワークロードがデタッチアクションによってデタッチされるため、ユーザーデータが失われる可能性があります。

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

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

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

バックアップが作成されたハブクラスターよりも新しいバージョンの Red Hat Advanced Cluster Management を使用するハブクラスターで復元操作を実行する場合でも、次の手順で復元操作を実行できます。

現在復元されているバックアップで既存のリソースが変更されている場合、Velero は既存のリソースを更新します。Velero はデルタリソースをクリーンアップしません。これは、以前の復元によって作成されたリソースであり、現在復元されているバックアップの一部ではありません。これにより、新しいハブクラスターでハブクラスターデータを復元するときに使用できるシナリオが制限されます。復元が 1 回だけ適用されない限り、新しいハブクラスターをパッシブ設定として確実に使用することはできません。ハブクラスターのデータは、復元されたリソースで利用できるデータを反映していません。

この制限に対処するために、Restore.cluster.open-cluster-management.io リソースが作成されると、バックアップ Operator は、ハブクラスターをクリーンアップする復元後の操作を実行します。この操作は、現在復元されているバックアップの一部ではない、以前の Red Hat Advanced Cluster Management 復元によって作成されたすべてのリソースを削除します。

復元後のクリーンアップでは、cleanupBeforeRestore プロパティーを使用して、クリーンアップするオブジェクトのサブセットを識別します。復元後のクリーンアップには、次のオプションを使用できます。

注記:

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

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

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

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

復元操作の完了後に同じ復元操作を再度実行する場合は、同じ spec オプションで新しい restore.cluster.open-cluster-management.io リソースを作成する必要があります。

たとえば、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

パッシブ設定でハブクラスターリソースを復元するには、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

パッシブハブクラスターにアクティベーションデータを復元する前に、バックアップが作成された以前のハブクラスターをシャットダウンします。プライマリーハブクラスターがまだ実行中の場合は、このハブクラスターで実行されている調整手順に基づいて、使用できなくなったマネージドクラスターへの再接続を試行します。

ハブクラスターでクラスターを管理する場合は、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

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

cluster.open-cluster-management.io/backup: cluster-activation ラベルを使用すると、マネージドクラスターのアクティベーションデータまたはその他のアクティベーションデータリソースは、マネージドクラスターのバックアップおよび resource-generic バックアップにより保存されます。アクティベーションデータが新しいハブクラスターに復元すると、マネージドクラスターは、復元が実行するハブクラスターによりアクティブに管理されます。Operator の使用方法は、バックアップのスケジュールと復元 を参照してください。

すべてのデータを復元するには、次の restore-acm サンプルを使用します。

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

ハブクラスターに restore.cluster.open-cluster-management.io リソースを作成した後、次のコマンドを実行して復元操作のステータスを取得します。

oc describe -n open-cluster-management-backup restore-acm

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

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

復元操作中に新しいハブクラスターにインポートされたクラスターを再接続するには、BackupSchedule で自動インポート機能を有効にします。詳細は、自動インポートの有効化 を参照してください。

以下の YAML の例を参照して、さまざまなタイプのバックアップファイルを復元します。

velero.io.restore 仕様では、高度な復元オプションが定義されています。これらの高度な復元オプションを使用すると、復元するリソースを除外できます。

たとえば、次の YAML サンプルを使用して、マネージドクラスターの namespace vb-managed-cls-2 からのみリソースを復元し、グローバルの Managedluster リソースを除外することができます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-filter-sample
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
  veleroManagedClustersBackupName: latest
  excludedResources:
    - ManagedCluster
  includedNamespaces:
    - vb-managed-cls-2

Red Hat Advanced Cluster Management for Kubernetes の復元リソースを作成するときに、velero.io.restore 仕様のオプションがさらに必要な場合は、次の復元フィルターを参照してください。

spec:
  includedResources
  includedNamespaces
  excludedResources
  excludedNamespaces
  LabelSelector
  OrLabelSelector

注記: どの Velero 復元フィルターでも、cleanupBeforeRestore フィールドを None に設定してください。これは、復元されるバックアップの一部であるが、適用されるフィルターによって復元対象外となるハブクラスターリソースをクリーンアップする必要性を回避するためです。

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

oc describe -n open-cluster-management-backup <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

マネージドサービスアカウントコンポーネントを使用した自動インポート機能は、デフォルトでは無効になっています。自動インポート機能を有効にするには、次の手順を実行します。

自動インポート機能を有効にすると、バックアップコンポーネントは以下を作成して、インポートされたマネージドクラスターの処理を開始します。

トークンは、マネージドサービスアカウントの作成時にマネージドクラスターにアクセスできる場合にのみ作成されます。それ以外の場合は、後でマネージドクラスターが利用可能になったときに作成されます。

次のシナリオでは、新しいハブクラスターに移動するときに、マネージドクラスターが自動的にインポートされなくなる可能性があります。

BackupSchedule リソースで useManagedServiceAccount パラメーターを false に設定することで、クラスターの自動インポート機能を無効にすることができます。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false

デフォルト値は false です。値を false に設定した後、バックアップ Operator は、ManagedServiceAddon、ManagedServiceAccount、および ManifestWork を含む、作成されたすべてのリソースを削除します。リソースを削除すると、ハブクラスターとマネージドクラスターの自動インポートトークンが削除されます。

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

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

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 がサポートするストレージプロバイダー を参照してください。

復元操作を実行してハブクラスターをアクティブにする前に、プライマリーハブクラスターを準備する必要があります。

プライマリーハブクラスターを準備するには、次の手順を実行します。

プライマリーハブクラスターを準備したら、新しいハブクラスターで復元操作を実行し、マネージドクラスターを移動します。バックアップハブクラスターで自動インポート機能が無効になっているため、マネージドクラスターは新しいハブクラスターに接続され、最初のハブクラスターに戻りません。

次の手順を実行して、新しいハブクラスターで復元操作を実行します。

復元後、マネージドクラスターが新しいハブクラスターに正常に接続したら、初期バックアップハブクラスターからマネージドクラスターリソースを消去します。リカバリーテストが完了した後にそのデータをバックアップに復元する場合は、リソースのクリーンアップをスキップしてください。

バックアップハブクラスターからマネージドクラスターをクリーンアップするには、次の手順を実行します。

重要:

Velero の初回インストール時に、Velero Pod は以下のサンプルで定義されるデフォルトの CPU およびメモリー制限に設定されます。

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi

前のサンプルの制限は一部のシナリオでうまく機能しますが、クラスターが多数のリソースをバックアップする場合には更新する必要がある場合があります。たとえば、2000 個のクラスターを管理するハブクラスターでバックアップを実行すると、メモリー不足 (OOM) エラーが原因で、Velero Pod が失敗します。以下の設定では、このシナリオでバックアップを完了できます。

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

Velero Pod リソースの制限および要求を更新するには、DataProtectionApplication リソースを更新し、Velero Pod の resourceAllocation テンプレートを挿入する必要があります。以下のサンプルを参照してください。

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi

復元操作に使用する予定のハブクラスターがすでにクラスターを管理しており、cleanupBeforeRestore オプションを CleanupRestored に設定して復元操作を実行すると、次の結果になることが予想されます。

以前にユーザーが作成したデータを使用してハブクラスターを復元し、復元操作の cleanupBeforeRestore オプションが CleanupRestored に設定されている場合、復元ハブクラスターのリソースはプライマリーハブクラスターのリソースと一致しません。ユーザーデータには、policy、application、credential、またはユーザーが定義したカスタムリソースのリソースが含まれます。リソースは、ユーザーが作成したもので、以前のバックアップによって作成されたものではないため、クリーンアップされません。

既存のハブクラスターを復元ハブクラスター設定に使用し、復元の完了後にハブクラスターの内容がバックアップハブクラスターと同じになることが予想される場合は、ハブクラスターバックアップに含めるリソースにタグを付けます。詳細は、リソースのタグ付け を参照してください。

復元ハブクラスター上のユーザーが作成したリソースに velero.io/backup-name: backupName ラベルのタグを付けるには、復元ハブクラスターで次の手順を実行します。

Operator は、ハブクラスターバックアップに含まれる各リソースを調べ、velero.io/backup-name: backupName のタグを付けます。ここで、backupName は最新のバックアップの名前です。

リソースにタグを付けた後、ハブクラスターを復元クラスターとして使用できます。DataProtectionApplication の保存場所を更新してバックアップハブクラスターの保存場所を参照するようにすることで、プライマリーハブクラスターからデータを復元できるようになり、ハブクラスターのバックアップリソースを使用する復元操作を実行できるようになりました。

すべての復元ハブクラスターリソースには velero.io/backup-name ラベル のタグが付いているため、ハブクラスターは以前の復元によって生成されたものとして表示されます。したがって、cleanupBeforeRestore オプションを CleanupRestored に設定して既存のハブクラスターで実行する復元操作では、復元されたバックアップに含まれないデータが消去されます。

重要:

復元操作のためにバックアップハブクラスターを準備して復元を実行するには、復元プロセス中にプライマリーハブクラスターをアクティブに保つ ドキュメントの内容を完了します。

シミュレーションを開始するには、次の手順を実行して、新しいハブクラスターをアクティブハブクラスターにする必要があります。

障害復旧テストが完了したら、プライマリーハブクラスターに戻り、それをクラスターフリートを管理するアクティブハブクラスターにできます。そうする場合は、次のセクションの内容を完了してプライマリークラスターに戻ります。

次の手順を実行すると、クラスター上で実行されている仮想マシンをバックアップしたり、クラスターに仮想マシンを復元したりできます。

バックアップ Operator を有効にすると、Red Hat Advanced Cluster Management のポリシーと ConfigMap のセットがハブクラスターにインストールされます。ポリシーを無効にするか、クラスターから削除すると、ポリシーによって作成されたすべてのリソースが削除されます。利用可能なさまざまな種類のポリシーの詳細を確認するには、次のセクションを参照してください。

ハブクラスターにポリシーをインストールすると、ハブクラスターの open-cluster-management-backup namespace に次の ConfigMap が作成されます。ハブクラスターまたはマネージドクラスターに仮想化ポリシーを適用すると、次の ConfigMap によって仮想化ポリシーのバックアップおよび復元設定が定義されます。

apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
 name: managed-cluster-name
 labels:
   acm-virt-config: acm-dr-virt-config-new

apiVersion: v1
kind: ConfigMap
    metadata:
        name: acm-dr-virt-schedule-cron
        namespace: open-cluster-management-backup
    data:
        hourly: "0 */1 * * *"
        every_2_hours: "0 */2 * * *"
        every_3_hours: "0 */3 * * *"
        every_4_hours: "0 */4 * * *"
        every_5_hours: "0 */5 * * *"
        every_6_hours: "0 */6 * * *"
        twice_a_day: "0 */12 * * *"
        daily_8am: "0 8 * * *"
        every_sunday: "0 0 * * 0"

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm-name
  labels:
    cluster.open-cluster-management.io/backup-vm: daily_8am

kind: ConfigMap
apiVersion: v1
metadata:
 name: acm-dr-virt-restore-config
 namespace: open-cluster-management-backup
data:
 2a054d24-3235-4249-9c81-f58ebc6110c7_backupName: acm-rho-virt-schedule-every-10-hours-20250120230438 1
 2a054d24-3235-4249-9c81-f58ebc6110c7_restoreName: restore-20250120230438 2
 2a054d24-3235-4249-9c81-f58ebc6110c7_vmsUID: 2a054d24-3235-4249-9c81-f58ebc6110c7 3

復元操作のために仮想化ポリシーをインストールする場合は、次の状況を考慮してください。