13.7. アップグレード前のクラスターリソースのバックアップの作成
単一ノードの OpenShift の場合、Topology Aware Lifecycle Manager (TALM) は、アップグレード前にデプロイメントのバックアップを作成できます。アップグレードが失敗した場合は、以前のバージョンを回復し、アプリケーションの再プロビジョニングを必要とせずにクラスターを動作状態に復元できます。
バックアップ機能を使用するには、最初に backup フィールドを true に設定して ClusterGroupUpgrade CR を作成します。バックアップの内容が最新であることを確認するために、ClusterGroupUpgrade CR の enable フィールドを true に設定するまで、バックアップは取得されません。
TALM は BackupSucceeded 条件を使用して、ステータスと理由を次のように報告します。
trueすべてのクラスターのバックアップが完了したか、バックアップの実行が完了したが、1 つ以上のクラスターで失敗しました。いずれかのクラスターでバックアップが失敗した場合、そのクラスターの更新は続行されません。
false1 つ以上のクラスターのバックアップがまだ進行中か、すべてのクラスターのバックアップが失敗しました。スポーククラスターで実行されているバックアッププロセスには、次のステータスがあります。
PreparingToStart最初の調整パスが進行中です。TALM は、失敗したアップグレード試行で作成されたスポークバックアップネームスペースとハブビューリソースをすべて削除します。
Startingバックアップの前提条件とバックアップジョブを作成しています。
Activeバックアップが進行中です。
Succeededバックアップは成功しました。
BackupTimeoutアーティファクトのバックアップは部分的に行われます。
UnrecoverableErrorバックアップはゼロ以外の終了コードで終了しました。
クラスターのバックアップが失敗し、BackupTimeout または UnrecoverableError 状態になると、そのクラスターのクラスター更新は続行されません。他のクラスターへの更新は影響を受けず、続行されます。
13.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フィールドとenableフィールドを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: true 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": "Failed" 1 } }, "computedMaxConcurrency": 1, "conditions": [ { "lastTransitionTime": "2022-04-05T10:37:19Z", "message": "Backup failed for 1 cluster", 2 "reason": "PartiallyDone", 3 "status": "True", 4 "type": "Succeeded" } ], "precaching": { "spec": {} }, "status": {}
13.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 の展開のステータスを確認します。
$ 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 ..............