18.7. アップグレード前のクラスターリソースのバックアップの作成
単一ノードの OpenShift の場合、Topology Aware Lifecycle Manager (TALM) は、アップグレード前にデプロイメントのバックアップを作成できます。アップグレードが失敗した場合は、以前のバージョンを回復し、アプリケーションの再プロビジョニングを必要とせずにクラスターを動作状態に復元できます。
コンテナーイメージのバックアップは、ClusterGroupUpgrade CR で バックアップ フィールドが true に設定されている場合に開始されます。
バックアッププロセスは、次のステータスになる可能性があります。
BackupStatePreparingToStart- 最初の調整パスが進行中です。TALM は、失敗したアップグレード試行で作成されたスポークバックアップネームスペースとハブビューリソースをすべて削除します。
BackupStateStarting- バックアップの前提条件とバックアップジョブを作成しています。
BackupStateActive- バックアップが進行中です。
BackupStateSucceeded- バックアップは成功しました。
BackupStateTimeout- アーティファクトのバックアップは部分的に行われました。
BackupStateError- バックアップはゼロ以外の終了コードで終了しました。
バックアップが失敗し、BackupStateTimeout または BackupStateError 状態になると、クラスターのアップグレードは続行されません。
18.7.1. バックアップを含む ClusterGroupUpgrade CR の作成
単一ノードの OpenShift の場合、アップグレード前にデプロイメントのバックアップを作成できます。アップグレードが失敗した場合は、Topology Aware Lifecycle Manager (TALM) によって生成された upgrade-recovery.sh スクリプトを使用して、システムをアップグレード前の状態に戻すことができます。バックアップは次の項目で設定されます。
- クラスターのバックアップ
-
etcdと静的 Pod マニフェストのスナップショット。 - コンテンツのバックアップ
-
/etc、/usr/local、/var/lib/kubeletなどのフォルダーのバックアップ。 - 変更されたファイルのバックアップ
-
変更された
machine-configによって管理されるすべてのファイル。 - Deployment
-
固定された
ostreeデプロイメント。 - イメージ (オプション)
- 使用中のコンテナーイメージ。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin権限を持つユーザーとしてログインしている。 - Red Hat Advanced Cluster Management 2.2.4 をインストールします。
リカバリーパーティションを作成することを強く推奨します。以下は、50 GB のリカバリーパーティションの SiteConfig カスタムリソース (CR) の例です。
nodes:
- hostName: "snonode.sno-worker-0.e2e.bos.redhat.com"
role: "master"
rootDeviceHints:
hctl: "0:2:0:0"
deviceName: /dev/sda
........
........
#Disk /dev/sda: 893.3 GiB, 959119884288 bytes, 1873281024 sectors
diskPartition:
- device: /dev/sda
partitions:
- mount_point: /var/recovery
size: 51200
start: 800000手順
clustergroupupgrades-group-du.yamlファイルで、backupフィールドをtrueに設定してClusterGroupUpgradeCR の内容を保存します。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: du-upgrade-4918 namespace: ztp-group-du-sno spec: preCaching: true backup: true clusters: - cnfdb1 - cnfdb2 enable: false managedPolicies: - du-upgrade-platform-upgrade remediationStrategy: maxConcurrency: 2 timeout: 240更新を開始するには、次のコマンドを実行して
ClusterGroupUpgradeCR を適用します。$ oc apply -f clustergroupupgrades-group-du.yaml
検証
以下のコマンドを実行して、ハブクラスターのアップグレードのステータスを確認します。
$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'出力例
{ "backup": { "clusters": [ "cnfdb2", "cnfdb1" ], "status": { "cnfdb1": "Succeeded", "cnfdb2": "Succeeded" } }, "computedMaxConcurrency": 1, "conditions": [ { "lastTransitionTime": "2022-04-05T10:37:19Z", "message": "Backup is completed", "reason": "BackupCompleted", "status": "True", "type": "BackupDone" } ], "precaching": { "spec": {} }, "status": {}
18.7.2. アップグレードが失敗した後のクラスターのリカバリー
クラスターのアップグレードが失敗した場合は、手動でクラスターにログインし、バックアップを使用してクラスターをアップグレード前の状態に戻すことができます。次の 2 つの段階があります。
- ロールバック
- 試行されたアップグレードにプラットフォーム OS 展開への変更が含まれていた場合は、回復スクリプトを実行する前に、以前のバージョンにロールバックする必要があります。
ロールバックは、TALM および単一ノード OpenShift からのアップグレードにのみ適用されます。このプロセスは、他のアップグレードタイプからのロールバックには適用されません。
- 復元
- リカバリーはコンテナーをシャットダウンし、バックアップパーティションのファイルを使用してコンテナーを再起動し、クラスターを復元します。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
- Red Hat Advanced Cluster Management 2.2.4 をインストールします。
-
cluster-admin権限を持つユーザーとしてログインしている。 - バックアップ用に設定されたアップグレードを実行します。
手順
次のコマンドを実行して、以前に作成した
ClusterGroupUpgradeカスタムリソース (CR) を削除します。$ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
- リカバリーするクラスターにログインします。
次のコマンドを実行して、プラットフォーム OS の展開のステータスを確認します。
$ oc ostree admin status
出力例
[root@lab-test-spoke2-node-0 core]# ostree admin status * rhcos c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9.0 Version: 49.84.202202230006-0 Pinned: yes 1 origin refspec: c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9- 1
- 現在の展開は固定されています。プラットフォーム OS 展開のロールバックは必要ありません。
[root@lab-test-spoke2-node-0 core]# ostree admin status * rhcos f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa.0 Version: 410.84.202204050541-0 origin refspec: f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa rhcos ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca.0 (rollback) 1 Version: 410.84.202203290245-0 Pinned: yes 2 origin refspec: ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52caプラットフォーム OS 展開のロールバックをトリガーするには、次のコマンドを実行します。
$ rpm-ostree rollback -r
復元の最初のフェーズでは、コンテナーをシャットダウンし、ファイルをバックアップパーティションから対象のディレクトリーに復元します。リカバリーを開始するには、次のコマンドを実行します。
$ /var/recovery/upgrade-recovery.sh
プロンプトが表示されたら、次のコマンドを実行してクラスターを再起動します。
$ systemctl reboot
再起動後、次のコマンドを実行してリカバリーを再開します。
$ /var/recovery/upgrade-recovery.sh --resume
リカバリーユーティリティーが失敗した場合は、--restart オプションを使用して再試行できます。
$ /var/recovery/upgrade-recovery.sh --restart
検証
リカバリーのステータスを確認するには、次のコマンドを実行します。
$ oc get clusterversion,nodes,clusteroperator
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.9.23 True False 86d Cluster version is 4.9.23 1 NAME STATUS ROLES AGE VERSION node/lab-test-spoke1-node-0 Ready master,worker 86d v1.22.3+b93fd35 2 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/authentication 4.9.23 True False False 2d7h 3 clusteroperator.config.openshift.io/baremetal 4.9.23 True False False 86d ..............
