Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第1章 ビジネス継続性

障害復旧ソリューション、ハブクラスター、およびマネージドクラスターは、次のトピックを参照してください。

1.1. バックアップおよび復元
リンクのコピー

クラスターのバックアップおよび復元 Operator は、ハブクラスターで実行され、Red Hat Advanced Cluster Management for Kubernetes ハブクラスターの障害に対する障害復旧ソリューションを提供します。ハブクラスターに障害が発生すると、管理対象クラスターがすべて動作していても、一部の機能は動作しなくなります。ハブクラスターが使用できない場合は、回復が可能かどうか、または新しく展開されたハブクラスター上のデータを回復する必要があるかどうかを判断するための回復計画が必要です。

クラスターのバックアップおよび復元の Operator は、ハブクラスターのインストールを拡張するサードパーティーリソースのバックアップをサポートします。このバックアップソリューションを使用すると、指定した時間間隔で実行する cron ベースのバックアップスケジュールを定義できます。ハブクラスターに障害が発生した場合は、新しいハブクラスターをデプロイし、バックアップされたデータをその新しいハブクラスターに移動できます。

次のトピックを完了して、バックアップおよび復元 Operator の詳細を確認してください。

1.1.1. バックアップおよび復元 Operator のアーキテクチャー
リンクのコピー

バックアップおよび復元 Operator は、Red Hat Advanced Cluster Management ハブクラスターのバックアップおよび復元プロセスを管理します。Operator は以下のカスタムリソースを実装します。

  • BackupSchedule.cluster.open-cluster-management.io。Red Hat Advanced Cluster Management バックアップスケジュールを設定します。
  • restore.cluster.open-cluster-management.io。これらのバックアップを処理および復元します。

Operator を使用すると、復元する必要があるリモートおよびハブクラスターリソースをバックアップするために必要なオプションを定義する Velero リソースが得られます。

このプロセスを視覚的に表すには、次のアーキテクチャー図を参照してください。

Backup and restore architecture diagram

バックアップおよび復元コンポーネントは、問題を報告するための一連のポリシーを提供します。バックアップソリューションが機能しない場合は、ポリシーテンプレートを使用してハブクラスター管理者へのアラートを作成します。

クラスターのバックアップと復元の Operator は、OADP Operator に依存して Velero をインストールし、ハブクラスターからデータが保存されているバックアップストレージの場所への接続を作成します。Velero は、バックアップおよび復元操作を実行するコンポーネントです。クラスターのバックアップと復元の Operator ソリューションは、マネージドクラスター、アプリケーション、およびポリシーを含むすべての Red Hat Advanced Cluster Management ハブクラスターリソースのバックアップと復元のサポートを提供します。

1.1.1.1. バックアップされるリソース
リンクのコピー

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

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

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

  • MultiClusterHub namespace のすべてのリソースを除外します。これは、現在のハブクラスター ID にリンクされているため、バックアップする必要のないインストールリソースのバックアップを回避するためです。
  • API バージョンの接尾辞が .open-cluster-management.io および .hive.openshift.io であるすべてのリソースをバックアップします。これらの接尾辞は、すべての Red Hat Advanced Cluster Management リソースがバックアップされていることを示します。

  • API グループ (argoproj.io、app.k8s.io、core.observatorium.io、hive.openshift.io) からすべてのリソースをバックアップします。agent-install.openshift.io API グループのリソースを除き、リソースは acm-resources-schedule バックアップ内でバックアップされます。agent-install.openshift.io API グループのリソースは、acm-managed-clusters-schedule バックアップ内でバックアップされます。以下に示す hive.openshift.io および hiveinternal.openshift.io API グループのリソースも、acm-managed-clusters-schedule バックアップによってバックアップされます。

    • clusterdeployment.hive.openshift.io
    • machinepool.hive.openshift.io
    • clusterpool.hive.openshift.io
    • clusterclaim.hive.openshift.io
    • clusterimageset.hive.openshift.io
    • clustersync.hiveinternal.openshift.io

  • 次の API グループからすべてのリソースを除外します。

    • internal.open-cluster-management.io
    • operator.open-cluster-management.io
    • work.open-cluster-management.io
    • search.open-cluster-management.io
    • admission.hive.openshift.io
    • proxy.open-cluster-management.io
    • action.open-cluster-management.io
    • view.open-cluster-management.io
    • clusterview.open-cluster-management.io
    • velero.io

  • 含まれる API グループの一部であるが、必要ではないか、バックアップもされている所有者リソースによって再作成される次のリソースをすべて除外します。

    • clustermanagementaddon.addon.open-cluster-management.io
    • backupschedule.cluster.open-cluster-management.io
    • restore.cluster.open-cluster-management.io
    • clusterclaim.cluster.open-cluster-management.io
    • discoveredcluster.discovery.open-cluster-management.io
  • 次のいずれかのラベルがあるシークレットまたは ConfigMaps をバックアップします: cluster.open-cluster-management.io/type、hive.openshift.io/secret-type、cluster.open-cluster-management.io/backup。

  • バックアップするその他のリソースで、前述の基準に含まれていないか、除外された API グループの一部である場合は、cluster.open-cluster-management.io/backup ラベルを使用します。以下の例を参照してください。 

    apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
   labels:
    cluster.open-cluster-management.io/backup: ""
    Copy to Clipboard Toggle word wrap

    注記: hive.openshift.io.ClusterDeployment リソースで使用されるシークレットはバックアップする必要があり、コンソールを使用してクラスターを作成する場合にのみ、cluster.open-cluster-management.io/backup ラベルで自動的にアノテーションが付けられます。代わりに GitOps を使用して Hive クラスターをデプロイする場合は、ClusterDeployment リソースで使用されるシークレットに cluster.open-cluster-management.io/backup ラベルを手動で追加する必要があります。cluster.open-cluster-management.io/backup: cluster-activation ラベルを持つシークレットおよび config map リソースは、クラスターのアクティブ化時に復元されます。

  • バックアップしたくない特定のリソースを除外します。バックアッププロセスから Velero リソースを除外するには、次の例を参照してください。 

    apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    velero.io/exclude-from-backup: "true"
    Copy to Clipboard Toggle word wrap

1.1.1.2. Red Hat Advanced Cluster Management スケジュールで作成されたバックアップファイル
リンクのコピー

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 です。これらのスケジュールされたバックアップファイルの説明を表示するには、次の表を参照してください。

Expand
表1.1 スケジュールされたバックアップの表
スケジュールされたバックアップ説明

Credentials backup

Hive 認証情報、Red Hat Advanced Cluster Management、ユーザーが作成した認証情報、および ConfigMap を保存します。このバックアップファイルの名前は、acm-credentials-schedule-<timestamp> です。

Resources backup

Red Hat Advanced Cluster Management リソースのバックアップが 1 つ (acm-resources-schedule-<timestamp> backup)、汎用リソースのバックアップが 1 つ (acm-resources-generic-schedule-<timestamp>) 含まれています。cluster.open-cluster-management.io/backup バックアップラベルでアノテーションが付けられたリソースはすべて、acm-resources-generic-schedule- backup バックアップの下に保存されます。例外は、バックアップ acm-credentials-schedule-<timestamp> の下に保存される Secret または ConfigMap リソースです。

Managed clusters backup

バックアップが復元されるハブクラスターへのマネージドクラスター接続をアクティブにするリソースのみ格納されています。このバックアップファイルの名前は、acm-managed-clusters-schedule-<timestamp> です。

1.1.1.3. マネージドクラスターのアクティブ化時に復元されるリソース
リンクのコピー

リソースに 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
Copy to Clipboard Toggle word wrap

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

  • namespace を復元すると、managedcluster-import-controller によって namespace が削除されます。
  • managedCluster カスタムリソースを復元すると、cluster-manager-registration-controller によって namespace が作成されます。

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

  • managedcluster.cluster.open-cluster-management.io
  • klusterletaddonconfig.agent.open-cluster-management.io
  • managedclusteraddon.addon.open-cluster-management.io
  • managedclusterset.cluster.open-cluster-management.io
  • managedclusterset.clusterview.open-cluster-management.io
  • managedclustersetbinding.cluster.open-cluster-management.io
  • clusterpool.hive.openshift.io
  • clusterclaim.hive.openshift.io
  • clustercurator.cluster.open-cluster-management.io

1.1.1.4. バックアップ ラベル機能
リンクのコピー

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

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

1.1.1.5. 関連情報
リンクのコピー

バックアップおよび復元コンポーネントのポリシーと機能の詳細は バックアップまたは復元設定の検証 を参照してください。

1.1.2. アクティブ/パッシブハブクラスターの設定
リンクのコピー

アクティブ/パッシブハブクラスター設定を設定します。この設定では、最初のハブクラスターがデータをバックアップし、アクティブクラスターが使用できなくなったときにパッシブハブクラスターがマネージドクラスターを制御します。

1.1.2.1. アクティブ/パッシブ設定
リンクのコピー

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

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

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

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

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

Active-passive configuration diagram

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

1.1.2.2. 障害復旧
リンクのコピー

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

Disaster recovery diagram

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

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

重要:

  • 前述の 障害復旧図 の最初のプロセスは、次の理由により自動化されていません。

    • プライマリーハブクラスターに障害が発生して交換する必要があるか、またはハブクラスターとマネージドクラスターの間にネットワーク通信エラーがあるかを判断する必要があります。
    • どのパッシブハブクラスターをプライマリーハブクラスターにするかを決定する必要があります。Red Hat Ansible Automation Platform ジョブとのポリシー統合により、バックアップポリシーがバックアップエラーを報告した場合にジョブが実行されるようにすることで、この手順を自動化できます。

  • 前述の 障害復旧図 の 2 番目のプロセスは手動で実行します。新しいプライマリーハブクラスターでバックアップスケジュールを作成していない場合、backup-restore-enabled ポリシーは backup-schedule-cron-enabled ポリシーテンプレートを使用して違反を示します。この 2 番目のプロセスでは、次のアクションを実行できます。

    • backup-schedule-cron-enabled ポリシーテンプレートを使用して、新しいプライマリーハブクラスターに cron ジョブとして実行されているバックアップがあるか確認します。
    • Ansible とのポリシー統合を使用して、backup-schedule-cron-enabled ポリシーテンプレートが違反を報告した場合に実行できる Ansible ジョブを定義します。
  • backup-restore-enabled ポリシーテンプレートの詳細は、バックアップまたは復元設定の検証 を参照してください。

1.1.2.3. 関連情報
リンクのコピー

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

1.1.3. バックアップおよび復元 Operator のインストール
リンクのコピー

クラスターのバックアップおよび復元 Operator は自動的にインストールされません。次のセクションを完了し、Operator をインストールして有効にします。

1.1.3.1. バックアップおよび復元 Operator 用のハブクラスターのセットアップ
リンクのコピー

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

1.1.3.2. 前提条件
リンクのコピー

  • Red Hat OpenShift Container Platform クラスターから、Red Hat Advanced Cluster Management Operator バージョン 2.15 をインストールしておく。MultiClusterHub リソースは、Red Hat Advanced Cluster Management のインストール時に自動的に作成され、Running のステータスを表示します。

1.1.3.3. ハブクラスターのバックアップ Operator を有効にする
リンクのコピー

アクティブ/パッシブハブクラスターのバックアップ Operator を有効にするには、以下の手順を実行します。

  1. MultiClusterHub リソースを更新し、cluster-backup パラメーターを true に設定して、クラスターのバックアップおよび復元 Operator、cluster-backup を有効にします。

    1. OpenShift API for Data Protection (OADP) Operator をインストールする場合、自動インストールがデフォルトです。このデフォルトの状況では、OADP Operator は cluster-backup コンポーネントを有効にしたのと同じ namespace に自動的にインストールされます。
    2. 特定のケースでは、OADP Operator を手動でインストールする必要があります。ハブクラスターが AWS クラウドで実行され、AWS Security Token Service (STS)認証を使用する場合は、バックアップコンポーネントを有効にする前に、OADP Operator を手動でインストールする必要があります。STS 設定には、OADP Operator のインストール中に設定する必要のある Amazon Resource Name (ARN)トークンが必要です。
  2. 復元ハブクラスターが、バックアップハブクラスターが使用するものと同じ Red Hat Advanced Cluster Management バージョンを使用していることを確認します。バックアップハブクラスターで使用されているバージョンよりも前のバージョンのハブクラスターでバックアップを復元することはできません。

  3. 次の手順を実行して、復元ハブクラスターを手動で設定します。

    1. アクティブハブクラスターと、そのアクティブハブクラスターと同じ namespace にインストールされているすべての Operator をインストールします。
    2. 新しいハブクラスターがバックアップハブクラスターと同じように設定されていることを確認します。
    3. バックアップおよび復元 Operator と、バックアップハブクラスターで設定する Operator をインストールするときは、バックアップハブクラスターと同じ namespace 名を使用します。

  4. 次の手順を実行して、パッシブハブクラスターに DataProtectionApplication リソースを作成します。

    1. アクティブハブクラスターとパッシブハブクラスターの両方に DataProtectionApplication リソースを作成します。
    2. 復元ハブクラスターの場合、DataProtectionApplication リソースを作成するときに、バックアップハブと同じストレージの場所を使用します。

1.1.3.4. ストレージの場所シークレットの作成
リンクのコピー

ストレージの場所のシークレットを作成するには、以下の手順を実行します。

  1. バックアップが保存されるクラウドストレージ のデフォルトシークレットの作成 の 手順を完了します。
  2. バックアップコンポーネントの namespace にある OADP Operator の namespace にシークレットリソースを作成します。

1.1.3.5. OADP Operator のインストール
リンクのコピー

AWS Security Token Service (STS) オプションを有効にしたハブクラスターの場合は、ハブクラスターにクラスターのバックアップおよび復元 Operator をインストールしても、OADP Operator はインストールされません。STS role_arn を OADP Operator に渡すには、OADP Operator を手動でインストールする必要があります。

STS オプションを有効にしなかったハブクラスターの場合は、ハブクラスターにクラスターバックアップおよび復元 Operator をインストールすると、OADP Operator が自動的にインストールされます。

MultiClusterHub リソースからバックアップオプションを有効にすると、OADP Operator を open-cluster-management-backup namespace にインストールするまで、バックアップオプションは Pending 状態のままになります。ハブクラスターで AWS STS オプションを有効にしていない場合は、バックアップチャートとともに OADP Operator が自動的にインストールされます。それ以外の場合は、OADP Operator を手動でインストールする必要があります。

クラスターが STS モードの場合、バックアップチャートは、open-cluster-management-backup namespace に acm-redhat-oadp-operator-subscription という名前の config map を作成します。この config map には、OADP チャネルと環境情報も含まれています。この config map を使用して、インストールする必要がある OADP バージョンを取得し、OADP サブスクリプションに設定する環境オプションを取得します。

STS オプションを使用して OADP Operator をインストールする方法の詳細については、OpenShift Container Platform のドキュメントの Backing up workload on OADP ROSA with an optional backup を参照してください。

重要:

OADP Operator をインストールするときは、次の注意事項を参照してください。

  • カスタムリソース定義はクラスタースコープであるため、同じクラスターに 2 つの異なるバージョンの OADP または Velero をインストールすることはできません。2 つの異なるバージョンがある場合、一方のバージョンは間違ったカスタムリソース定義で実行されます。
  • MultiClusterHub リソースを作成すると、Velero カスタムリソース定義 (CRD) はハブクラスターに自動的にインストールされません。OADP Operator をインストールすると、Velero CRD がハブクラスターにインストールされます。その結果、Velero CRD リソースは MultiClusterHub リソースによって調整および更新されなくなります。
  • バックアップコンポーネントは、コンポーネントの namespace にインストールされている OADP Operator と連携して動作します。
  • OADP Operator を手動でインストールする場合、OADP Operator と Velereo のカスタムリソース定義バージョンは一致する必要があります。これらのバージョンが互いに完全に一致しない場合は、問題が発生します。
  • Velero と OADP Operator は、Red Hat Advanced Cluster Management for Kubernetes ハブクラスターにインストールされます。これは、Red Hat Advanced Cluster Management ハブクラスターリソースのバックアップおよび復元に使用されます。
  • Velero のサポートされているストレージプロバイダーの一覧は、About installing OADP を参照してください。

1.1.3.6. カスタム OADP バージョンのインストール
リンクのコピー

MultiClusterHub リソースにアノテーションを設定すると、特定のニーズに合わせて OADP バージョンをカスタマイズできます。以下の手順を実行します。

  1. バックアップおよび復元 Operator によってインストールされた OADP バージョンを上書きするには、MultiClusterHub リソースで次のアノテーションを使用します。 

    installer.open-cluster-management.io/oadp-subscription-spec: '{"channel": "stable-1.4"}'
    Copy to Clipboard Toggle word wrap

    重要: このオプションを使用して、バックアップおよび復元 Operator によってデフォルトでインストールされたものとは異なる OADP バージョンを取得する場合は、このバージョンがハブクラスターによって使用される Red Hat OpenShift Container Platform バージョンでサポートされていることを確認してください。このオーバーライドオプションを使用すると、サポート対象外の設定になる可能性があるため、注意して使用してください。

  2. オプション: Operator の特定の OADP バージョンをインストールするには、アノテーションを設定します。たとえば、stable-1.5 チャネルから OADP をインストールし、特定のバージョンの Operator を選択する場合は、installer.open-cluster-management.io/oadp-subscription-spec アノテーションで startingCSV プロパティーを設定します。MultiClusterHub リソースは次の例のようになります。 

    apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  annotations:
    installer.open-cluster-management.io/oadp-subscription-spec: '{"channel": "stable-1.5","installPlanApproval": "Automatic","name":
      "redhat-oadp-operator","source": "redhat-operators","sourceNamespace": "openshift-marketplace" "startingCSV": “oadp-operator.v5.0.2”}'
  name: multiclusterhub
spec: {}
    Copy to Clipboard Toggle word wrap
  3. cluster-back を true に設定して、MultiClusterHub リソースの cluster-backup オプションを有効にします。
  4. OADP Operator が oadp-subscription-spec アノテーションプロパティーを使用していることを確認するには、OADP Operator のサブスクリプション YAML に、アノテーションで指定されたプロパティーが含まれていることを確認します。

1.1.3.7. DataProtectionApplication リソースの作成
リンクのコピー

アクティブ/パッシブハブクラスターの DataProtectionApplication リソースのインスタンスを作成するには、以下の手順を実行します。

  1. Red Hat OpenShift Container Platform コンソールから、Operators > Installed Operators を選択します。
  2. DataProtectionApplication の下の Create instance をクリックします。
  3. OpenShift Container Platform コンソールを使用して設定を選択するか、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"
    Copy to Clipboard Toggle word wrap

1.1.3.8. 非接続環境でのバックアップおよび復元コンポーネントの有効化
リンクのコピー

非接続環境で Red Hat OpenShift Container Platform を使用してバックアップおよび復元コンポーネントを有効にするには、以下の手順を実行します。

  1. 次のアノテーションを使用して MultiClusterHub リソースを更新し、OADP Operator のインストール元のソースをオーバーライドします。MultiClusterHub リソースで cluster-backup コンポーネントを有効にする前に、アノテーションを作成します。 

    apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
  annotations:
    installer.open-cluster-management.io/oadp-subscription-spec: '{"source": "redhat-operator-index"}'
    Copy to Clipboard Toggle word wrap

  2. redhat-operator-index はカスタム名であり、非接続環境で Red Hat OpenShift Operator にアクセスするために定義および使用する CatalogSource リソースの名前を表します。次のコマンドを実行して、catalogsource を取得します。 

    oc get catalogsource -A
    Copy to Clipboard Toggle word wrap

    出力は次の例のような内容になります。 

    NAMESPACE               NAME                         DISPLAY                       TYPE   PUBLISHER   AGE
openshift-marketplace   acm-custom-registry          Advanced Cluster Management   grpc   Red Hat     42h
openshift-marketplace   multiclusterengine-catalog   MultiCluster Engine           grpc   Red Hat     42h
openshift-marketplace   redhat-operator-index                                      grpc               42h
    Copy to Clipboard Toggle word wrap

1.1.3.9. バックアップおよび復元 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
Copy to Clipboard Toggle word wrap

1.1.3.10. 関連情報
リンクのコピー

1.1.4. バックアップのスケジュール
リンクのコピー

バックアップをスケジュールすることで、データが保護され、アクセス可能な状態を維持できるようになります。バックアップをスケジュールするには、次の手順を実行します。

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

    oc create -f cluster_v1beta1_backupschedule.yaml
    Copy to Clipboard Toggle word wrap

    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 * * *
    1 
    
  veleroTtl: 120h
    2 
    
  useManagedServiceAccount: true
    3 
    
  paused: false
    4
    Copy to Clipboard Toggle word wrap
    1
    veleroSchedule は必須のプロパティーで、バックアップをスケジュールする cron ジョブを定義します。前の例では、2 時間ごとにバックアップが作成されます。
    2
    オプション: veleroTtl は任意のプロパティーで、スケジュールされているバックアップリソースの有効期限を定義します。指定されていない場合には、Velero で設定された最大デフォルト値 (720h) が使用されます。スケジュールされたバックアップは 120 時間 後に削除されます。
    3
    オプション: useManagedServiceAccount は、自動インポート機能を有効にして、復元操作でクラスターをインポートできるオプションのプロパティーです。true に設定すると、自動インポート機能が有効になり、復元操作でクラスターがインポートされます。
    4
    オプション: paused は、バックアップスケジュールを一時停止できるオプションのプロパティーです。true に設定すると、バックアップスケジュールが一時停止され、このリソースによって作成されたすべての Velero スケジュールが削除されます。

  2. backupschedule.cluster.open-cluster-management.io リソースの状態をチェックします。3 つの schedule.velero.io リソースの定義が表示されます。以下のコマンドを実行します。 

    oc get BackupSchedule -n open-cluster-management-backup
    Copy to Clipboard Toggle word wrap

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

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

backupschedule.cluster.open-cluster-management.io リソースは、バックアップの生成に使用される schedule.velero.io リソースを 6 つ作成します。以下のコマンドを実行して、スケジュールされるバックアップのリストを表示します。 

oc get schedules -A | grep acm
Copy to Clipboard Toggle word wrap

次の表が示すとおり、リソースはグループ内で個別にバックアップされます。

Expand
表1.2 リソースグループの表
リソース説明

Credentials バックアップ

Hive 認証情報、Red Hat Advanced Cluster Management、ユーザーが作成した認証情報と ConfigMap を格納するバックアップファイル。

Resources バックアップ

Red Hat Advanced Cluster Management リソースと汎用リソースのバックアップが 1 つずつ格納されています。これらのリソースには cluster.open-cluster-management.io/backup ラベルが使用されます。

ManagedClusters バックアップ

バックアップが復元されるハブクラスターへのマネージドクラスター接続をアクティブにするリソースのみ格納されています。

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

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

さまざまな BackupSchedule ステータスの説明は、次の表を参照してください。

Expand
表1.3 BackupSchedule ステータスの表
BackupSchedule ステータス説明

Enabled

BackupSchedule が実行し、バックアップが生成されています。

FailedValidation

エラーにより、BackupSchedule を実行できません。その結果、BackupSchedule はバックアップを生成せず、代わりに調整を行ってエラーが修正されるのを待ちます。リソースが無効である理由は、BackupSchedule ステータスセクションを参照してください。エラーが解決されると、BackupSchedule ステータスが Enabled に変わり、リソースはバックアップの生成を開始します。

BackupCollision

BackupSchedule はバックアップを生成していません。リソースステータスが BackupCollision である理由は、BackupSchedule ステータスセクションを参照してください。バックアップの作成を開始するには、このリソースを削除して新しいリソースを作成してください。

Paused

BackupSchedule.paused プロパティーを使用して Red Hat Advanced Cluster Management バックアップスケジュールを一時停止した場合、BackupSchedule リソースによって作成された Velero スケジュールは削除され、新しいハブバックアップは生成されません。BackupSchedule.paused プロパティーを False に更新した場合、BackupSchedule リソースのステータスは Enabled に戻り、Velero スケジュールが再作成されます。

1.1.4.1. バックアップ競合の理解
リンクのコピー

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

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

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

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

  1. プライマリーハブクラスターが予期せず失敗する。これは、次の状況で発生します。

    • プライマリーハブクラスターから初期ハブクラスターへの通信が失敗します。
    • 最初のハブクラスターのバックアップデータは、セカンダリーハブクラスターと呼ばれるセカンダリーハブクラスターに復元されます。
    • 管理者がセカンダリーハブクラスター上に BackupSchedule.cluster.open-cluster-management.io リソースを作成します。セカンダリーハブクラスターがプライマリーハブクラスターとなり、共通のストレージ場所にバックアップデータを生成します。

    • 初期ハブクラスターが予期せず再び動作を開始します。

      初期ハブクラスターでは BackupSchedule.cluster.open-cluster-management.io リソースがまだ有効になっているため、初期ハブクラスターはセカンダリーハブクラスターと同じストレージの場所にバックアップの書き込みを再開します。両方のハブクラスターが同じストレージ場所にバックアップデータを書き込んでいます。この保存場所から最新のバックアップを復元するハブクラスターは、セカンダリーハブクラスターデータではなく、初期ハブクラスターデータを使用する場合があります。

  2. 管理者は、セカンダリーハブクラスターをプライマリーハブクラスターにして、次の条件によって発生する災害シナリオをテストします。

    • 初期ハブクラスターが停止します。
    • 最初のハブクラスターのバックアップデータは、セカンダリーハブクラスターに復元されます。
    • 管理者がセカンダリーハブクラスター上に BackupSchedule.cluster.open-cluster-management.io リソースを作成します。セカンダリーハブクラスターがプライマリーハブクラスターとなり、共通のストレージ場所にバックアップデータを生成します。
    • 災害テストが完了したら、管理者は以前の状態に戻して、最初のハブクラスターを再びプライマリーハブクラスターにします。

    • セカンダリーハブクラスターがアクティブである間に、初期ハブクラスターが起動します。

      BackupSchedule.cluster.open-cluster-management.io リソースはセカンダリーハブクラスターでまだ有効になっているため、同じストレージの場所にバックアップが書き込まれ、バックアップデータが破損します。この場所から最新のバックアップを復元するハブクラスターは、初期ハブクラスターデータの代わりにセカンダリーハブクラスターデータを使用する場合があります。このシナリオでは、バックアップの競合の問題を回避するために、最初のハブクラスターを起動する前に、まずセカンダリーハブクラスターを停止するか、セカンダリーハブクラスター上の BackupSchedule.cluster.open-cluster-management.io リソースを一時停止します。

  3. 管理者は、最初に初期ハブクラスターを停止せずに、セカンダリーハブクラスターをプライマリーハブクラスターにして、次の状態を発生させる災害シナリオをテストします。

    • 初期ハブクラスターはまだ実行中です。
    • マネージドクラスターのバックアップを含む、初期ハブクラスターのバックアップデータは、セカンダリーハブクラスターに復元されます。したがって、セカンダリーハブクラスターがアクティブクラスターになります。
    • BackupSchedule.cluster.open-cluster-management.io リソースは初期ハブクラスターでまだ有効になっているため、同じストレージの場所にバックアップが書き込まれ、バックアップデータが破損します。たとえば、この場所から最新のバックアップを復元するハブクラスターは、セカンダリーハブクラスターデータではなく、初期ハブクラスターデータを使用する場合があります。データの破損を回避するために、初期ハブクラスターの BackupSchedule リソースのステータスは自動的に BackupCollision に変更になります。このシナリオでは、バックアップの衝突状態を回避するために、まず初期ハブクラスターを停止するか、初期ハブクラスター上の BackupSchedule.cluster.open-cluster-management.io リソースを削除してから、セカンダリーハブクラスターでマネージドクラスターのデータを復元します。

1.1.4.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
Copy to Clipboard Toggle word wrap

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

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.
Copy to Clipboard Toggle word wrap

1.1.4.3. 関連情報
リンクのコピー

1.1.5. バックアップの復元
リンクのコピー

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

バックアップが収集された同じハブクラスターでデータを復元する場合は、以前のスナップショットからデータを回復します。その場合は、復元とバックアップ操作の両方が同じハブクラスターで実行されます。

バックアップを完全に復元するには、次の手順を実行します。

1.1.5.1. バックアップタイプの復元操作の使用
リンクのコピー

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

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

  • veleroManagedClustersBackupName は、マネージドクラスターのアクティベーションリソースの復元オプションを定義するのに使用されます。
  • veleroCredentialsBackupName は、ユーザーの認証情報の復元オプションを定義するために使用されます。

  • veleroResourcesBackupName は、ハブクラスターリソース (Applications、Policy、その他のハブクラスターリソース (マネージドクラスターパッシブデータなど)) の復元オプションを定義するのに使用されます。

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

    • 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-acm は restore.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
Copy to Clipboard Toggle word wrap

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

1.1.5.2. 新規ハブクラスターの準備
リンクのコピー

ハブクラスターを復元し、それが最初のハブクラスターと同じであることを確認するには、ハブ復元操作を実行するときに新しいハブクラスターを使用します。

新しいハブクラスターを使用すると、既存のユーザーデータが復元に干渉するのを防ぐことができます。また、新しいハブクラスターにはバックアップデータのみが含まれるようにし、クラスターを最初のハブクラスターと同じにします。

障害復旧シミュレーションでは、新しいハブクラスターを使用する代わりに、最初のハブクラスターに戻る必要がある場合があります。最初のハブクラスターに戻るには、プライマリーハブクラスターに戻る の手順を完了します。

重要: マネージドクラスターが古いハブクラスターと新しいハブクラスターの間を行ったり来たりするのを防ぐため、復元操作を実行して新しいクラスターがアクティブなハブクラスターになる前に、最初のハブクラスターを停止してください。復元操作中または復元操作後に最初のハブクラスターをアクティブに保つには、プライマリーハブクラスターの準備 の手順を完了します。

新しいハブクラスターで復元操作を実行する前に、ハブクラスターを手動で設定し、初期ハブクラスターと同じ 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 がインストールされている場合は、復元操作を実行する前にそれらをインストールする必要があります。これにより、新しいハブクラスターが初期のハブクラスターと同じ方法で設定されます。

1.1.5.3. 新しいバージョンのハブクラスターで復元操作を実行する
リンクのコピー

データをバックアップしたハブクラスターと同じ Red Hat Advanced Cluster Management Operator バージョンを使用するハブクラスターで復元操作を実行します。新しい Red Hat Advanced Cluster Management Operator バージョンを使用するハブクラスターで復元操作を実行する場合は、次の手順を実行します。

  1. 復元ハブクラスターに、バックアップを作成したハブクラスターと同じバージョンの Red Hat Advanced Cluster Management Operator をインストールします。
  2. 復元ハブクラスターでバックアップデータを復元します。
  3. 復元ハブクラスターで、アップグレード操作を使用して、使用する Red Hat Advanced Cluster Management オペレーターバージョンにアップグレードします。

1.1.5.4. 復元後のハブクラスターのクリーニング
リンクのコピー

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

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

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

  • None: クリーンアップは必要なく、Velero の復元を開始するだけです。真新しいハブクラスターでは None を使用します。
  • CleanupRestored: 現在復元されているバックアップの一部ではない、以前の Red Hat Advanced Cluster Management 復元によって作成されたすべてのリソースをクリーンアップします。

  • CleanupAll: Red Hat Advanced Cluster Management バックアップの一部である可能性があるハブクラスター上のすべてのリソースを、復元操作の結果として作成されたものではない場合でもクリーンアップします。

    重要: CleanupAll オプションは、ユーザーが作成したコンテンツを含むすべてのハブクラスターデータを削除します。

    重要: 復元オプションの excludedResource、excludedNamespaces、excludedResources、または復元されたリソースを除外するその他のオプションを使用して除外した復元されたリソースが失われないようにするには、常に cleanupBeforeRestore = None を使用してください。

    ベストプラクティス: CleanupAll オプションは使用しないでください。細心の注意を払って最後の手段としてのみ使用してください。CleanupAll は、以前に復元されたバックアップによって作成されたリソースに加えて、ユーザーによって作成されたハブクラスター上のリソースもクリーンアップします。代わりに、CleanupRestored オプションを使用して、ハブクラスターが災害シナリオのパッシブ候補として指定されている場合に、ハブクラスターのコンテンツを更新しないようにします。クリーンハブクラスターをパッシブクラスターとして使用します。

注記:

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

1.1.5.5. バックアップの確認中にパッシブリソースを復元する
リンクのコピー

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

VeleroResourcesBackupName および VeleroCredentialsBackupName パラメーターを Latest に設定し、VeleroManagedClustersBackupName パラメーターを Skip に設定します。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
Copy to Clipboard Toggle word wrap

1.1.5.6. パッシブリソースを復元する
リンクのコピー

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

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

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

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

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

  • 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.1.5.8. マネージドクラスターのアクティベーションデータの復元
リンクのコピー

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

1.1.5.9. 全リソースの復元
リンクのコピー

すべてのデータを復元するには、次の 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
Copy to Clipboard Toggle word wrap

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

oc describe -n open-cluster-management-backup restore-acm
Copy to Clipboard Toggle word wrap

1.1.5.10. インポートされたマネージドクラスターの復元
リンクのコピー

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

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

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

1.1.5.11. 他の復元サンプルの使用
リンクのコピー

以下の 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
    Copy to Clipboard Toggle word wrap

  • マネージドクラスターリソースのみを復元します。 

    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
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap

    注記:

    • フェーズが Enabled または Running の場合、restore.cluster.open-cluster-management.io リソースはまだアクティブです。リソースの実行は完了すると、フェーズが Finished に変わります。復元操作が完了したら、同じハブクラスターで別の復元操作を実行できます。
    • 一度に実行できる restore.cluster.open-cluster-management.io は 1 つだけです。

  • velero.io.restore の詳細オプションを使用して、復元するリソースを除外します。vb-managed-cls-2 マネージドクラスター namespace からのみリソースを復元し、グローバル MultiCluster リソースを除外するには、velero.io.restore spec オプションを含む次のサンプルを使用します。 

    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
orLabelSelectors:
  - matchExpressions:
  - values:
  - vb-managed-cls-2
key: name
operator: In
    Copy to Clipboard Toggle word wrap

  • Red Hat Advanced Cluster Management 復元リソースを作成するときに、次の velero.io.restore spec オプションを設定します。 

    spec:
  includedResources
  includedNamespaces
  excludedResources
  excludedNamespaces
  LabelSelector
  OrLabelSelector
    Copy to Clipboard Toggle word wrap

    注記:

    • これらの Velero 復元フィルターのいずれかを設定する場合は、cleanupBeforeRestore を None に設定してください。これは、復元されるバックアップの一部であるが、適用されるフィルターによって復元対象外となるハブクラスターリソースのクリーンアップを回避するためです。

1.1.5.12. 高度な復元オプションの使用
リンクのコピー

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
Copy to Clipboard Toggle word wrap

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

spec:
  includedResources
  includedNamespaces
  excludedResources
  excludedNamespaces
  LabelSelector
  OrLabelSelector
Copy to Clipboard Toggle word wrap

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

1.1.5.13. 復元イベントの表示
リンクのコピー

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

oc describe -n open-cluster-management-backup <restore-name>
Copy to Clipboard Toggle word wrap

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

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
Copy to Clipboard Toggle word wrap

1.1.5.14. 関連情報
リンクのコピー

1.1.6. ManagedServiceAccount を使用してバックアップ用にクラスターを接続
リンクのコピー

バックアップコントローラーは、マネージドサービスアカウントコンポーネントを使用して、インポートされたクラスターを新しいハブクラスターに自動的に接続します。マネージドサービスアカウントは、マネージドクラスターの namespace ごとに、それぞれのインポートされたクラスターにバックアップされるトークンを作成します。

トークンは klusterlet-bootstrap-kubeconfig ClusterRole バインディングを使用するため、自動インポート操作でトークンを実装できます。klusterlet-bootstrap-kubeconfig ClusterRole は、bootstrap-hub-kubeconfig シークレットのみを取得または更新できます。

アクティベーションデータが新しいハブクラスターに復元されると、復元コントローラーは復元後の操作を実行し、Pending Import 状態のすべてのマネージドクラスターを探します。マネージドサービスアカウントによって生成された有効なトークンが見つかった場合、コントローラーは、インポートコンポーネントをマネージドクラスターに再接続するトークンを使用して auto-import-secret を作成します。クラスターにアクセスできる場合、操作は成功です。

1.1.6.1. Enabling automatic import
リンクのコピー

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

  1. MultiClusterEngine リソースで managedserviceaccount enabled パラメーターを true に設定して、マネージドサービスアカウントコンポーネントを有効にします。以下の例を参照してください。 

    apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
  name: multiclusterengine
spec:
  overrides:
    components:
      - enabled: true
        name: managedserviceaccount
    Copy to Clipboard Toggle word wrap

  2. useManagedServiceAccount パラメーターを true に設定して、BackupSchedule.cluster.open-cluster-management.io リソースの自動インポート機能を有効にします。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: true
    Copy to Clipboard Toggle word wrap

    デフォルトのトークン有効期間は、ライフサイクル全体にわたってトークンを保存するすべてのバックアップに対してトークンが有効になる可能性を高くするために、veleroTtl の値の 2 倍に設定されます。場合によっては、オプションの managedServiceAccountTTL プロパティーの値を設定することで、トークンの有効期間を制御する必要がある場合があります。

    生成されたトークンのデフォルトのトークン有効期限を更新する必要がある場合は、注意して managedServiceAccountTTL を使用してください。トークンの有効期限をデフォルト値から変更すると、バックアップのライフサイクル中に有効期限が切れるように設定されたトークンを使用してバックアップが作成される可能性があります。その結果、インポート機能はマネージドクラスターでは機能しません。

    重要: トークンの有効期間を制御する必要がない限り、managedServiceAccountTTL を使用しないでください。

    managedServiceAccountTTL プロパティーの使用例は、次の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: true
  managedServiceAccountTTL: 300h
    Copy to Clipboard Toggle word wrap

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

  • managed-serviceaccount という名前の ManagedServiceAddon。
  • auto-import-account という名前の ManagedServiceAccount。
  • マネージドクラスターで ManagedServiceAccount トークンの klusterlet-bootstrap-kubeconfig RoleBinding を設定するための、各 ManagedServiceAccount の ManifestWork。

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

1.1.6.2. 自動インポートに関する考慮事項
リンクのコピー

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

  • ManagedServiceAccount トークンを使用せずにハブバックアップを実行する場合 (たとえば、マネージドクラスターにアクセスできないときに ManagedServiceAccount リソースを作成する場合)、マネージドクラスターを自動インポートするためのトークンがバックアップに含まれません。
  • auto-import-account シークレットトークンが有効でバックアップされている場合、自動インポート操作は失敗しますが、バックアップで使用可能なトークンの有効期限がすでに切れている場合、復元操作が実行されます。restore.cluster.open-cluster-management.io リソースは、各マネージドクラスターの無効なトークンの問題を報告します。

  • 復元時に作成される auto-import-secret は ManagedServiceAccount トークンを使用してマネージドクラスターに接続するため、マネージドクラスターは kube apiserver 情報も提供する必要があります。ManagedCluster リソースに apiserver を設定する必要があります。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1
kind: ManagedCluster
metadata:
  name: managed-cluster-name
spec:
  hubAcceptsClient: true
  leaseDurationSeconds: 60
  managedClusterClientConfigs:
      url: <apiserver>
    Copy to Clipboard Toggle word wrap

    クラスターがハブクラスターにインポートされると、apiserver は OpenShift Container Platform クラスターでのみ自動的にセットアップされます。EKS クラスターなどの他のタイプのマネージドクラスターでは、apiserver を手動で設定する必要があります。そうしないと、自動インポート機能でクラスターが無視されます。その結果、クラスターを復元ハブクラスターに移動すると、クラスターは Pending Import 状態のままになります。

  • ManagedServiceAccount シークレットにバックアップラベルが設定される前にバックアップスケジュールが実行された場合、ManagedServiceAccount シークレットがバックアップに含まれない可能性があります。ManagedServiceAccount シークレットには、作成時に設定されたクラスター open-cluster-management.io/backup ラベルがありません。このため、バックアップコントローラーはマネージドクラスターの namespace で ManagedServiceAccount シークレットを定期的に検索し、見つからない場合はバックアップラベルを追加します。

1.1.6.3. 自動インポートの無効化
リンクのコピー

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
Copy to Clipboard Toggle word wrap

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

1.1.6.4. 関連情報
リンクのコピー

1.1.7. バックアップまたは復元設定の検証
リンクのコピー

MultiClusterHub リソースで cluster-backup オプションを true に設定すると、マルチクラスターエンジン Operator により、クラスターのバックアップおよび復元 Operator の Helm チャートがインストールされます。この Helm チャートは cluster-backup-chart という名前です。このチャートは、backup-restore-enabled および backup-restore-auto-import ポリシーをインストールします。これらのポリシーを使用して、バックアップおよび復元コンポーネントの問題に関する情報を表示します。

重要: ハブクラスターは、local-cluster として自動的にインポートされ、自己管理されます。MultiClusterHub リソースで、disableHubSelfManagement を true に設定して自己管理を無効にすると、ローカルクラスター機能が無効になり、backup-restore-enabled ポリシーがハブクラスターに配置されず、ポリシーテンプレートによってレポートが生成されなくなります。

ハブクラスターがグローバルハブクラスターによって管理されている場合、またはマネージドクラスターインスタンスにインストールされている場合は、disableHubSelfManagement を true に設定することで、自己管理オプションが無効になります。このインスタンスの場合でも、ハブクラスターで backup-restore-enabled ポリシーを有効にすることができます。ローカルクラスターを表す ManagedCluster リソースに is-hub=true ラベルを設定します。

backup-restore-enabled ポリシーには、以下の制約を確認するテンプレートセットが含まれます。

  • OADP チャネルの検証

    • MultiClusterHub でバックアップコンポーネントを有効にすると、クラスターバックアップおよび復元 Operator の Helm チャートは、OADP Operator を open-cluster-management-backup namespace に自動的にインストールできます。namespace に OADP Operator を手動でインストールすることもできます。
    • 手動インストール用に選択した OADP-channel は、Red Hat Advanced Cluster Management のバックアップおよび復元 Operator Helm チャートによって設定されたバージョンと一致するか、それを超えている必要があります。
    • OADP Operator と Velero Custom Resource Definition (CRD) は cluster-scoped であるため、同じクラスター上に複数のバージョンを持つことはできません。open-cluster-management-backup namespace とその他の namespace に同じバージョンをインストールする必要があります。

    • 次のテンプレートを使用して、可用性を確認し、OADP のインストールを検証します。

      • oadp-operator-exists: このテンプレートを使用して、OADP Operator が open-cluster-management-backup namespace にインストールされているかどうかを確認します。
      • oadp-channel-validation: このテンプレートを使用して、open-cluster-management-backup namespace の OADP Operator のバージョンが、Red Hat Advanced Cluster Management バックアップおよび復元 Operator によって設定されたバージョンと一致するか、それを超えていることを確認します。
      • custom-oadp-channel-validation: このテンプレートを使用して、他の namespace の OADP Operator が open-cluster-management-backup namespace のバージョンと一致するかどうかを確認します。

  • 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 の定義は、バックアップの競合の防止 を参照してください。

  • 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 テンプレートが警告を報告するのは正常です。

  • バックアップスケジュールがプライマリーハブクラスターでバックアップを生成する

    • backup-schedule-cron-enabled ポリシーテンプレートは、プライマリーハブクラスターが新しいバックアップを作成していないことをハブクラスター管理者に通知します。このポリシーは、BackupSchedule.cluster.open-cluster-management.io リソースがプライマリーハブクラスターで無効になっているか、スケジュールされたバックアップを作成できないことを示しています。
    • BackupSchedule cron ジョブ定義で新しいバックアップが作成されると想定されており、プライマリーハブクラスターのバックアップスケジュールで新しいバックアップが生成されなかった場合、backup-schedule-cron-enabled ポリシーテンプレートは違反になります。これは、BackupSchedule が存在しない、一時停止されている、または BackupSchedule 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 バックアップが存在しない場合は、バックアップを生成するアクティブな cron ジョブは存在しません。

backup-restore-auto-import ポリシーには、次の制約を確認するテンプレートのセットが含まれています。

  • 自動インポートのシークレット検証

    • auto-import-account-secret テンプレートは、ManagedServiceAccount シークレットが <your-local-cluster-name> namespace 以外のマネージドクラスターの namespace に作成されているかどうかを確認します。バックアップコントローラーにより、インポートされたマネージドクラスターが定期的にスキャンされます。マネージドクラスターが検出されるとすぐに、バックアップコントローラーはマネージドクラスターの namespace に ManagedServiceAccount リソースを作成します。このプロセスにより、マネージドクラスター上でトークンの作成が開始されます。ただし、この操作の時点でマネージドクラスターにアクセスできない場合、ManagedServiceAccount はトークンを作成できません。たとえば、マネージドクラスターが休止状態の場合、トークンを作成できません。したがって、この期間中にハブのバックアップが実行されると、マネージドクラスターを自動インポートするためのトークンがバックアップに不足します。

  • 自動インポートのバックアップラベル検証

    • auto-import-backup-label テンプレートは、<your-local-cluster-name> namespace 以外のマネージドクラスターの namespace に ManagedServiceAccount シークレットが存在することを検証します。このテンプレートが ManagedServiceAccount シークレットを検出した場合、テンプレートはシークレットに cluster.open-cluster-management.io/backup ラベルを適用します。このラベルは、Red Hat Advanced Cluster Management のバックアップに ManagedServiceAccount シークレットを含める場合に重要です。

1.1.7.1. サーバー側の暗号化を使用したデータの保護
リンクのコピー

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

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

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
Copy to Clipboard Toggle word wrap

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

1.1.7.2. 関連情報
リンクのコピー

1.1.8. プライマリーハブクラスターがアクティブな状態で復元操作の実行
リンクのコピー

一般的な障害復旧の復元操作では、プライマリーハブクラスターは非アクティブであり、復元ハブクラスターとの競合は発生しません。復元操作中または復元操作後に元のハブクラスターをアクティブにしておく必要がある場合があります。たとえば、障害復旧シミュレーションテストを実行する場合は通常、これを実行する必要があります。

プライマリーハブクラスターがアクティブな間に新しいハブクラスターにデータを復元すると、両方のハブクラスターが同じクラスターフリートを管理しようとします。プライマリーハブクラスターがマネージドクラスターを制御する場合は、新しいハブクラスターに対して行ったポリシーまたはアプリケーションの変更がオーバーライドされる可能性があります。

プライマリーハブクラスターをアクティブなまま、新しいハブクラスターでハブデータを安全に復元するには、障害復旧テストを実行する前にプライマリーハブクラスターを設定します。以下のタスクを完了します。

1.1.8.1. プライマリーハブクラスターの準備
リンクのコピー

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

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

  1. paused プロパティーを true に設定して、BackupSchedule リソースを一時停止します。以下の例を参照してください。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
 name: schedule-acm-msa
 namespace: open-cluster-management-backup
spec:
 veleroSchedule: 0 */1 * * *
 veleroTtl: 120h
 useManagedServiceAccount: true
 paused: true
    Copy to Clipboard Toggle word wrap

    注記: - プライマリーハブクラスターでバックアップスケジュールを一時停止せずに次の手順に進んだ場合、import.open-cluster-management.io/disable-auto-import アノテーションがリソースに設定されているときにバックアップを実行すると、このアノテーションが設定された ManagedCluster リソースのバックアップを作成する可能性があります。

    • import.open-cluster-management.io/disable-auto-import アノテーションを使用して ManagedCluster リソースをバックアップすると、新しいハブクラスターでバックアップデータを復元するときに、マネージドクラスターは自動的にインポートできません。

  2. プライマリーハブクラスターリソースにバックアップアノテーションのタグを付けます。以下の手順を実行します。

    1. restore-acm.yaml という名前のファイルを作成します。

    2. 以下の内容をファイルに追加します。 

      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
      Copy to Clipboard Toggle word wrap

    3. 次のコマンドを実行してファイルを適用し、復元操作を実行します。 

      oc -f apply restore-acm.yaml
      Copy to Clipboard Toggle word wrap

      注記: Restore リソースを実行すると、BackupSchedule を有効にした場合にバックアップされるすべてのハブクラスターリソースにタグが付けられます。リソースには、velero.io/backup-name: backupName ラベルがタグ付けされます。ここで、backupName はプライマリーハブクラスターによって作成された最新のバックアップの名前に置き換えます。

      その結果、cleanupBeforeRestore オプションが CleanupRestored に設定された Restore リソースを使用してプライマリークラスターで実行される復元操作は、これらのリソースを処理して、最新のバックアップに含まれない場合はすべてのリソースを削除します。

  3. マネージドクラスターの自動インポートを無効にします。

    1. 復元ハブクラスターに移動するすべてのマネージドクラスターの ManagedCluster グローバルリソースに次のアノテーションを設定します。アノテーションを設定すると、マネージドクラスターが復元ハブクラスターに移動した後、バックアップハブクラスターがマネージドクラスターを回復できなくなります。 
    annotations:
   import.open-cluster-management.io/disable-auto-import: ''
    Copy to Clipboard Toggle word wrap

1.1.8.2. 新しいハブクラスターでの復元操作
リンクのコピー

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

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

  1. restore-acm.yaml ファイルに次の内容を追加します。 

    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
    Copy to Clipboard Toggle word wrap

    注記: veleroManagedClustersBackupName を latest に設定すると、マネージドクラスターが復元され、セカンダリーハブクラスターに接続されます。

  2. 次のコマンドを実行してファイルを適用し、復元操作を実行します。 

    oc -f apply restore-acm.yaml
    Copy to Clipboard Toggle word wrap

1.1.8.3. バックアップハブクラスター上のマネージドクラスターリソースのクリーンアップ
リンクのコピー

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

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

  1. ManagedCluster グローバルリソースを削除する前に、プライマリーハブでマネージドクラスターのステータスが Unknown であることを確認してください。ステータスが Unknown でない場合、ワークロードはマネージドクラスターからアンインストールされます。
  2. ManagedCluster グローバルリソースを削除するかどうかを決定します。これを行うと、マネージドクラスターの namespace が削除されます。
  3. 復元操作を使用して新しいハブクラスターに移動した各マネージドクラスターのバックアップハブクラスターから ManagedCluster グローバルリソースを削除します。

重要:

  • ManagedCluster グローバルリソースを削除する前に、プライマリーハブでマネージドクラスターのステータスが Unknown であることを確認してください。ステータスが Unknown でない場合、ワークロードはマネージドクラスターからアンインストールされます。
  • ManagedCluster グローバルリソースを削除すると、マネージドクラスターの namespace も削除されます。

1.1.9. Velero リソース要求と制限の設定
リンクのコピー

バックアップおよび復元 Operator をインストールすると、ハブクラスター上の Velero デプロイメントを管理するために DataProtectionApplication リソースが作成されます。

Velero Pod はデフォルトの CPU およびメモリー制限に設定されています。クラスターが大量のリソースをバックアップする場合は、Velero リソース要求と制限の更新が必要になる場合があります。値を更新しないと、メモリー不足エラーにより Velero Pod が失敗する可能性があります。

1.1.9.1. より多くのクラスターをサポートするためのリソースの増加
リンクのコピー

  1. DataProtectionApplication リソースを更新し、次の resourceAllocations テンプレートを追加します。次の例は 2000 個のクラスターで機能します。 

    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
    Copy to Clipboard Toggle word wrap

1.1.9.2. 関連情報
リンクのコピー

1.1.10. 既存のハブクラスターを復元ハブクラスターとして使用するシナリオ
リンクのコピー

復元操作の前に、以前作成したリソースを含む既存のハブクラスターを復元ハブクラスターとして使用する場合は、次のシナリオを検討してください。

  • 復元プロセス中に、既存のマネージドクラスターがデタッチされる可能性があります。
  • 復元ハブクラスターには、バックアップハブクラスターよりも多くのリソースが存在する可能性があります。

1.1.10.1. 既存のマネージドクラスターが復元プロセス中にデタッチされる
リンクのコピー

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

  • ManagedCluster リソースが復元されたバックアップによって作成された場合、リソースには velero.io/backup-name: backupName ラベルアノテーションが設定されます。ユーザーが復元操作を実行し、cleanupBeforeRestore=CleanupRestored オプションを使用すると、マネージドクラスターはハブクラスターからデタッチされ、これらのマネージドクラスター上のワークロードがクリーンアップされます。
  • ユーザーが ManagedCluster リソースを作成した場合、リソースに velero.io/backup-name: backupName ラベルアノテーションは設定されません。復元操作を実行し、cleanupBeforeRestore=CleanupRestored オプションを使用すると、リソースが復元された現行バックアップの一部でない場合でも、マネージドクラスターリソースはクリーンアップされません。

ユーザーが作成したデータを含むハブクラスターでデータを復元する場合に、復元操作の cleanupBeforeRestore オプションが CleanupRestored に設定されていれば、そのデータはクリーンアップされません。これは、データが以前の復元ではなくユーザーによって作成されたためです。

ユーザーが作成したリソースがクリーンアップされない場合でも、既存のハブクラスターを、復元ハブクラスター設定用として引き続き使用できます。バックアップと復元のハブクラスター内のコンテンツを相互に一致させることができます。リソースに cluster.open-cluster-management.io/backup ラベルのタグを付けると、ユーザーが作成したすべてのリソースが、以前の復元操作によって生成されたかのように同じように表示されます。

リソースにタグを付ける方法については、ユーザーリソースにバックアップラベルをタグ付けする を完了して詳細を確認してください。

1.1.11. ユーザーリソースにバックアップラベルをタグ付けする
リンクのコピー

既存のハブクラスターを復元ハブクラスター設定に使用する場合は、ハブクラスターに含めるユーザー作成リソースを決定し、そのリソースに velero.io/backup-name: backupName ラベルのタグを付けます。これらのリソースに Velero アノテーションのタグを付けると、リソースが以前の復元によって生成されたように見えます。

Velero アノテーションのため、ハブ復元操作を実行し、復元リソースで cleanupBeforeRestore オプションを CleanupRestored に設定すると、現在復元されたバックアップの一部ではないユーザーリソースがクリーンアップされます。その結果、既存のクラスターでハブデータを復元し、最初のハブと同じクラスターを作成できます。

1.1.11.1. 前提条件
リンクのコピー

  • 復元操作の前に作成したリソースを使用して、既存のハブクラスターを復元ハブクラスターとして使用するシナリオを確認します。既存のハブクラスターを復元ハブクラスターとして使用するシナリオ を参照してください。
  • 復元ハブクラスターで、DataProtectionApplication リソースを更新し、ストレージの場所を新しい一時的な場所に設定する。復元ハブクラスターリソースにタグを付けるために使用されるバックアップを、バックアップハブクラスターと同じストレージの場所に作成しないでください。
  • リソースにタグを付ける前に、ストレージの場所をバックアップハブクラスターとは別の場所に設定してください。

1.1.11.2. velero ラベルの付いたリソースのタグ付け
リンクのコピー

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

  1. 次の YAML を使用して、これらすべてのハブクラスターリソースを含むバックアップを生成する BackupSchedule リソースを作成します。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule: 0 */1 * * *
  veleroTtl: 120h
  useManagedServiceAccount: true
  paused: false
    Copy to Clipboard Toggle word wrap
  2. BackupSchedule によってハブクラスターバックアップリソースが作成され、リソースのステータスが Completed になっていることを確認します。

  3. schedule-acm-msa BackupSchedule で paused=true プロパティーを設定して、BackupSchedule スケジュールを一時停止し、バックアップの生成を停止します。

    注意: BackupSchedule が有効になっている場合、ハブクラスターで復元操作を実行することはできません。

  4. 次の YAML を使用して復元操作を実行します。 

    kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
  excludedResources:
    1 
    
    - ManagedCluster
  excludedNamespaces:
    2 
    
    - managed-cls-1
    - managed-cls-2
    - managed-cls-n
    Copy to Clipboard Toggle word wrap
    1
    除外するリソース。この例では、マネージドクラスターリソースは除外されます。
    2
    除外する namespace。この例では、マネージドクラスターの namespace は除外されます。

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

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

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

重要:

  • 以前の復元操作によって作成された復元ハブクラスター上に、復元されたバックアップに含まれないマネージドクラスターがある場合は、cleanupBeforeRestore オプションを CleanupRestored に設定して復元操作を使用しないでください。そうしないと、復元ハブクラスター上のマネージドクラスターがハブクラスターからデタッチされ、マネージドクラスターのリソースが削除されます。

  • 復元ハブクラスターのリソースがバックアップハブクラスターのリソースよりも多い場合、次の状況では既存のハブクラスターを復元ハブクラスターとして使用できます。

    • この復元ハブクラスターにはマネージドクラスターがない。
    • 復元ハブクラスターにはマネージドクラスターがあり、復元ハブクラスターのユーザーデータが、復元されたバックアップで使用可能なデータと同じであると必要はない。
    • 復元ハブクラスターのマネージドクラスターの名前は、バックアップハブクラスターのマネージドクラスターの名前と競合しない。

1.1.12. 最初のハブクラスターへのデータの復元
リンクのコピー

ハブクラスターの障害復旧シミュレーションを実行した後、データを最初のハブクラスターに復元し、それをプライマリーハブクラスターとして使用できます。

障害復旧操作テストを実施するときは、プライマリーハブクラスターの障害をシミュレートし、そのデータを新しいハブクラスターに復元して、バックアップと復元のプロセスが機能することを確認します。障害復旧テストのシミュレーションが完了したら、プライマリーハブクラスターに戻り、それをクラスターフリートを管理するアクティブハブクラスターにします。

障害復旧シミュレーションを実行した後、データを最初のハブクラスターに復元するには、次のセクションを完了します。

1.1.12.1. プライマリーハブクラスターの準備
リンクのコピー

復元プロセス中にプライマリーハブクラスターがアクティブな状態を維持するように準備するには、プライマリーハブクラスターがアクティブな状態での復元操作の実行 というタスクを完了します。

1.1.12.2. 新しいハブクラスターをアクティブハブクラスターにする
リンクのコピー

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

  1. 新しいハブクラスターで復元操作を実行して、アクティブなハブクラスターにします。
  2. マネージドクラスターが新しいハブクラスターに接続されていることを確認するには、クラスターコンソールからマネージドクラスターのステータスを確認します。
  3. 新しいハブクラスターで障害復旧シミュレーションテストを実行します。

1.1.12.3. プライマリーハブクラスターに戻る
リンクのコピー

障害復旧テストが終了したら、次の手順を実行してプライマリーハブクラスターに戻り、クラスターフリートを管理するアクティブハブクラスターにします。

  1. 次のリソースを適用して、復元ハブクラスターにバックアップを作成します。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
 name: schedule-acm-msa
 namespace: open-cluster-management-backup
spec:
 veleroSchedule: "0 */1 * * *"
 veleroTtl: 120h
 useManagedServiceAccount: true
 paused: false
    Copy to Clipboard Toggle word wrap
  2. Red Hat Advanced Cluster Management バックアップが生成され、そのステータスが Complete になっていることを確認します。
  3. schedule-acm-msa BackupSchedule リソースで paused=true プロパティーを設定してバックアップスケジュールを一時停止します。
  4. プライマリーハブクラスターに戻された ManagedCluster リソースが初期ハブクラスターに接続されないようにするには、すべての ManagedCluster リソースに import.open-cluster-management.io/disable-auto-import: '' アノテーションを追加します。

  5. 次の復元リソースを適用して、セカンダリーハブクラスターバックアップからすべてのリソースを復元します。 

    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
    Copy to Clipboard Toggle word wrap

    注記: cleanupBeforeRestore プロパティーを CleanupRestored に設定すると、すべてのリソースが復元された後にクリーンアップ操作が実行されます。このクリーンアップ操作により、復元されたバックアップに含まれないハブリソースがすべて削除されます。

1.1.12.4. プライマリーハブクラスターでバックアップスケジュールを有効にする
リンクのコピー

これで初期ハブクラスターが再びプライマリーハブクラスターになりました。次に以下の手順を実行して、プライマリーハブクラスターでバックアップスケジュールを有効にします。

  1. プライマリーハブクラスターに移動します。

  2. 次の BackupSchedule リソースを適用します。 

    apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
 name: schedule-acm-msa
 namespace: open-cluster-management-backup
spec:
 veleroSchedule: "0 */1 * * *"
 veleroTtl: 120h
 useManagedServiceAccount: true
 paused: false
    Copy to Clipboard Toggle word wrap

    注記: 2 番目のハブクラスターは、active-passive 設定のセカンダリーハブクラスターとして再度使用できます。

1.1.13. Hosted Control Plane およびホステッドクラスターのバックアップと復元
リンクのコピー

OpenShift Container Platform の Hosted Control Plane の障害復旧ドキュメントを参照してください。これは、OpenShift API for Data Protection Operator のインストール、OpenShift API for Data Protection リソースの作成、OpenShift API for Data Protection を使用してホスト型クラスターをバックアップおよび復元する際に役立ちます。次に、Red Hat Advanced Cluster Management プロセスの違いに注意してください。

Red Hat Advanced Cluster Management を使用してホステッドクラスターをバックアップおよび復元するには、次の情報を参照してください。

  • Red Hat Advanced Cluster Management ハブクラスターを復元する前に、ホステッドクラスターを復元します。手順については、OpenShift Hosted Control Plane Disaster Recovery のドキュメント を参照してください。
  • Red Hat Advanced Cluster Management の場合、バックアップと復元を有効にし、バックアップおよび復元コンポーネントによってインストールされる OpenShift API for Data Protection Operator を使用します。
  • ホステッドクラスターの DataProtectionApplication、BackupSchedule、Backup および Restore などのデータ保護リソース用の OpenShift API は、open-cluster-management-backup 名前空間に作成されます。
  • 詳細は、Hosted Cluster のバックアップと復元のプロセスの概要 を参照してください。

1.1.14. 可観測性のバックアップと復元の設定
リンクのコピー

可観測性サービスは、S3 互換オブジェクトストアを使用して、マネージドクラスターから収集されたすべての時系列データを保持します。可観測性 はステートフルサービスであるため、アクティブおよびパッシブのバックアップパターンの影響を受けます。データの安全性を確保し、ハブクラスターの移行またはバックアップ中にその継続性を維持するには、Oservability を設定する必要があります。

注記:

  • マネージドクラスターがプライマリーハブクラスターから切り離され、バックアップハブクラスターに再アタッチされると、メトリクスは収集されません。メトリクスの接続に役立つように、大規模なフリートのクラスター移行のスクリプトを作成できます。
  • 製品のバックアップおよび復元の場合、可観測性サービスはそのリソースに cluster.open-cluster-management.io/backup ラベルで自動的にラベルを付けます。
Expand
表1.4 可観測性のために自動的にバックアップおよび復元されたリソース
Resource typeリソース名

ConfigMap

observability-metrics-custom-allowlist、thanos-ruler-custom-rules、alertmanager-config、policy-acs-central-status、grafana-custom-dashboardのラベルが付けられた ConfigMap

シークレット

thanos-object-storage、observability-server-ca-certs、observability-client-ca-certs、observability-server-certs、observability-grafana-certs、alertmanager-byo-ca、alertmanager-byo-cert、proxy-byo-ca、proxy-byo-cert

1.1.14.1. 関連情報
リンクのコピー

1.1.15. 可観測性サービスのバックアップおよび復元
リンクのコピー

可観測性サービスをバックアップおよび復元して、データを安全に維持し、ハブクラスターの移行またはバックアップ中の継続性をサポートします。メトリックデータ収集の中断を容易にするために、プライマリークラスターとバックアップハブクラスターの両方に同じ S3 互換オブジェクトストアを使用します。

前提条件

手順

次の手順を実行して、可観測性サービスをバックアップおよび復元します。

  1. 可観測性サービスがハブクラスターを local-cluster （マネージドハブクラスター）として認識できるようにするには、MultiClusterHub カスタムリソースの spec.disableHubSelfManagement パラメーターを false に変更します。

    注記： local-cluster のデフォルト名を別の値に設定すると、結果が変更されたローカルクラスター名に表示されます。

  2. observatorium リソースを手動でバックアップして復元する際に、observatorium リソースのテナント ID を保持するには、次のコマンドを実行します。 

    oc get observatorium -n open-cluster-management-observability -o yaml > observatorium-backup.yaml
    Copy to Clipboard Toggle word wrap

  3. 可観測性 デプロイメントをバックアップするには、以下のコマンドを実行します。 

    oc get mco observability -o yaml > mco-cr-backup.yaml
    Copy to Clipboard Toggle word wrap

  4. 以下のコマンドを実行して、プライマリーハブクラスターの Thanos コンパクターをシャットダウンします。 

    oc scale statefulset observability-thanos-compact -n open-cluster-management-observability --replicas=0
    Copy to Clipboard Toggle word wrap
    1. 次のコマンドを実行して、コンパクターがアクティブでないことを確認します。 
    oc get pods observability-thanos-compact-0 -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap
  5. 可観測性の バックアップ およびリストア設定にリストされている自動バックアップ ConfigMap とシークレットなどのバックアップリソースを復元します。

  6. メトリクス取り込みおよびクエリーで継続性を維持するために、テナント ID を保持するには、observatorium リソースをバックアップハブクラスターに復元します。以下のコマンドを実行します。 

    oc apply -f observatorium-backup.yaml
    Copy to Clipboard Toggle word wrap

  7. バックアップされた MultiClusterObservability カスタムリソースを適用して、新しく復元されたハブクラスターで可観測性サービスを起動します。以下のコマンドを実行します。 

    oc apply -f mco-cr-backup.yaml
    Copy to Clipboard Toggle word wrap

    Operator は可観測性サービスを開始し、既存の observatorium リソースを検出し、新しいリソースを作成する代わりに、保存されたテナント ID を再利用します。

  8. 可観測性サービスが新しいハブクラスターで実行されていることを確認します。以下のコマンドを実行します。 

    oc get pods -n open-cluster-management-observability
    Copy to Clipboard Toggle word wrap

  9. observability-controller managedclusteraddon のステータスが DEGRADED 列になく、PROGRESSING ステータスが False に設定されていないことを確認します。以下のコマンドを実行します。 

    oc get managedclusteraddons -A | awk 'NR==1 || /observability-controller/
    Copy to Clipboard Toggle word wrap
  10. Grafana にアクセスして、マネージドクラスターからのメトリクスコレクションを確認します。
  11. 各マネージドクラスターの Available ステータスをチェックして、マネージドクラスターが新しいハブクラスターに接続されていることを確認します。

  12. リソースを削除して、以前のハブクラスター上の可観測性サービスをシャットダウンします。以下のコマンドを実行します。 

    oc delete mco observability
    Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る