OpenShift Data Foundation を使用する VPC ワーカーノードの更新または置換

Virtual Private Cloud

OpenShift Data Foundation などのストレージソリューションを採用している VPC クラスターの場合、各ワーカーノードに対して、順次、隔離、データの排出、および更新を行う必要があります。ベアメタルのワーカーノードについては、 worker replace の代わりに worker reload コマンドを使用できるようになりました。 OpenShift Data Foundationをクラスター内のワーカーノードの一部にのみ展開した場合、ワーカーノードを更新した後は、 ocscluster リソースを編集して、新しいワーカーノードを追加する必要があります。

以下のチュートリアルでは、メジャーアップデートとマイナーアップデート、ワーカーノードのアップデートの両方を扱います。

Major update: このラベルのステップを実行して、メジャー・アップデートを適用します。例えば、ワーカー・ノードを新しいメジャー・バージョン ( 4.11 から 4.12 へ、 OpenShift Data Foundation を 4.11 から 4.12 へなど) に更新する場合です。
Minor update: このラベルのステップを実行して、パッチ更新を適用します。例えば、 OpenShift Data Foundation をバージョン 4.12 のままにして、 4.12.15_1542_openshift から 4.12.16_1544_openshift に更新する場合などです。更新したい各ノードについて、これらの手順を繰り返す必要があります。
Worker replace: 同じパッチ・バージョンのワーカー・ノードを置き換える場合は、このラベルのステップを実行します。置き換えたい各ノードについて、これらの手順を繰り返す必要があります。

バージョンアップ時にバージョンを飛ばすことはサポートされていません。例えば、バージョンから 4.8 へのアップグレードはサポート 4.12 されていません。

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。

ワーカー・ノードを更新する前に、必ずアプリ・データをバックアップしてください。また、一度に 1 つのワーカー・ノードに対して以下のステップを実行することも計画してください。更新するワーカー・ノードごとに上記の手順を繰り返します。

ストレージクラスタの状態を確認する

Major update Minor update Worker replace

次のコマンドを実行して、ポッドの一覧を表示してください。 openshift-storage ネームスペース内のすべてのポッドが良好な状態であることを確認する。 Running または Completed の状態ではないすべてのポッドに対処してください。
```
	oc get pods -n openshift-storage
```

以下のコマンドを実行し、 ocs-storagecluster の Phase が Ready であることを確認する。

	oc get storagecluster -n openshift-storage

出力例

	NAME                 AGE     PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   3m49s   Ready              2025-04-06T09:37:49Z   4.16.9

次のコマンドを実行して、Ceph ストレージの状態を確認してください。ヘルスが HEALTH_OK であること、すべてのOSDが up と IN であること、すべての pgs が active+clean であることを確認する。これらのチェックに失敗した場合は、サポートケースを開いてください。ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。続行する前に問題を解決する。

	oc rsh -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-operator) ceph status -c /var/lib/rook/openshift-storage/openshift-storage.config

出力例

	health: HEALTH_OK  # Verify health is HEALTH_OK
	services:
		mon: 3 daemons, quorum a,b,c (age 3h)
		mgr: a(active, since 6h)
		mds: ocs-storagecluster-cephfilesystem:1 {0=ocs-storagecluster-cephfilesystem-b=up:active} 1 up:standby-replay
		osd: 27 osds: 27 up (since 2h), 27 in (since 111m) # Verify OSDs are “up” and “in”
		rgw: 2 daemons active (ocs.storagecluster.cephobjectstore.a, ocs.storagecluster.cephobjectstore.b)
	data:
		pools:   10 pools, 1136 pgs
		objects: 5.50M objects, 3.3 TiB
		usage:   9.9 TiB used, 43 TiB / 53 TiB avail
		pgs:     1136 active+clean   # Verify psgs are active+clean
	io:
		client:   93 KiB/s rd, 2.0 MiB/s wr, 5 op/s rd, 29 op/s wr

追加ノードの更新手順を繰り返す前に、これらのヘルスチェックを繰り返します。一度に複数のOSDポッドを停止させると、ユーザーデータに支障をきたす恐れがあります。

クラスター・マスターの更新

Major update

ワーカー・ノードを新しいメジャー・バージョン ( 4.11 から 4.12 など) に更新する場合は、まずクラスター・マスターを更新します。

	ibmcloud oc cluster master update --cluster CLUSTER_NAME --version MAJOR.MINOR.PATCH --force-update

コマンド例:

	ibmcloud oc cluster master update --cluster mycluster --version 4.21.31 --force-update

数分待ってから、マスターの更新が完了したことを確認してください。
```
	  ibmcloud oc cluster ls
```

更新または交換するストレージノードを決める

Major update Minor update Worker replace

oc get nodes を使用してワーカーノードの一覧を表示し、更新対象のストレージノードを特定してください。

oc get nodes

出力例

NAME           STATUS   ROLES           AGE    VERSION
10.241.0.4     Ready    master,worker   106s   v1.21.6+4b61f94
10.241.128.4   Ready    master,worker   22d    v1.21.6+bb8d50a
10.241.64.4    Ready    master,worker   22d    v1.21.6+bb8d50a

ストレージクラスタが正常に動作していることを確認してください

Major update Minor update Worker replace

以下のコマンドを実行して、ストレージ・クラスターの健全性を確認します。

oc get storagecluster -n openshift-storage
oc get cephcluster -n openshift-storage

続行する前に、ストレージクラスタが健全であることを確認する。

OpenShift Data Foundationの機能制限と縮小

Major update Minor update Worker replace

rook-ceph-mon、 rook-ceph-osd、およびcrashcollectorのデプロイメントを、ドレイン処理の前にスケールダウンすることで、これらのストレージプロセスが強制的に終了させられることなく、正常にシャットダウンされるようになります。 OSDおよびモニターポッドを実行している場合は、ノードがオフラインになっている間もCephが安全にI/Oを停止させ、データの整合性を維持できるよう、これらを正常にシャットダウンする必要があります。更新または置換されたノードがクラスタに再参加すると、 Rook の-Cephオペレーターが自動的にこれらのデプロイメントを元のレプリカ数までスケールアップします。

ノードを閉鎖します。ノードをコーディングすることで、ODFのデプロイメントをスケールダウンしている間、このノードへのポッドのスケジューリングが防止されます。
```
	oc adm cordon NODE_NAME
```
出力例
```
	node/10.241.0.4 cordoned
```
更新対象のノード上で実行中の「 rook-ceph-mon 」および「 rook-ceph-osd 」のポッドを特定してください。出力にあるポッド名に注意してください。次の手順で必要になります。
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
デプロイメント名は、末尾の「 ReplicaSet 」ハッシュおよびポッド ID のサフィックスを除いたポッド名です。たとえば、 rook-ceph-osd-1-6d9f99c68f-pgvxt という名前のポッドはデプロイメント rook-ceph-osd-1 に属しており、 rook-ceph-mon-e-85fbb8bcc-kttbt という名前のポッドはデプロイメント rook-ceph-mon-e に属しています。
前の手順で特定したポッドのデプロイメントを縮小してください。 ROOK_CEPH_MON_DEPLOYMENT および ROOK_CEPH_OSD_DEPLOYMENT を、Pod 名から導出したデプロイ名に置き換えてください。前のコマンドの実行結果として、このノード上に rook-ceph-mon または rook-ceph-osd のポッドが検出されなかった場合は、これら2つのコマンドをスキップして、crashcollectorコマンドに進んでください。
```
	oc scale deployment ROOK_CEPH_MON_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment ROOK_CEPH_OSD_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE_NAME --replicas=0 -n openshift-storage
```
コマンドの実行結果が「 error: no objects passed to scale 」となった場合は、 oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep crashcollector を実行して、このノード上でcrashcollectorポッドが実行されていないことを確認してください。ポッドが返されない場合は、このコマンドをスキップして、そのまま続行しても問題ありません。

ワーカー・ノードをドレーンします。

Major update Minor update Worker replace

ノードをドレーンして、すべてのポッドを削除します。ワーカー・ノードをドレーンすると、ポッドは他のワーカー・ノードに移動するため、ダウン時間は発生しません。また、ドレーンにより、ポッドの中断予算が中断されないようにすることもできます。

	oc adm drain NODE_NAME --force --delete-emptydir-data --ignore-daemonsets

出力例

	evicting pod "managed-storage-validation-webhooks-7fd79bc9f7-pdpv6"
	evicting pod "calico-kube-controllers-647dbbd685-fmrp9"
	evicting pod "certified-operators-2v852"
	evicting pod "csi-snapshot-controller-77fbf474df-47ddt"
	evicting pod "calico-typha-8574d89b8c-7f2cc"
	evicting pod "dns-operator-6d48cbff67-vrrsw"
	evicting pod "router-default-6fc798b98b-9m6kh"
	evicting pod "prometheus-adapter-5b77ffdd5f-hzqrp"
	evicting pod "alertmanager-main-1"
	evicting pod "prometheus-k8s-0"
	evicting pod "network-check-source-66c7fbb86-2r78z"

NooBaa のポッドがドレイン中に停止してしまった場合は、別のノードで再スケジュールされるよう、以下の順序でそれらを削除してください。

	oc delete pod -n openshift-storage -l app=noobaa-db

	oc delete pod -n openshift-storage -l app=noobaa-core

	oc delete pod -n openshift-storage -l app=noobaa-endpoint

	oc delete pod -n openshift-storage -l app=noobaa-operator

ドレインが完了するまで待ち、その後、以下の手順に従ってワーカーノードを更新してください。

ベアメタルワーカーノードのパーシステントボリュームをクリーンアップする

Major update Minor update Worker replace

ベアメタル・ワーカーノードのみ ：ベアメタル・ワーカーノードを更新または交換する場合は、以下の手順に従ってODFディスクを消去し、新しいデプロイメントに向けてノードを準備してください。仮想サーバーインスタンス（VSI）のワーカーノードを使用している場合は、このセクションをスキップして、「ワーカーノードの更新」に進んでください。

作業を開始する前に、ワーカーノードの隔離と排水に関する前の手順をすべて完了していることを確認してください。

新しい永続ボリュームの作成に備えて、ベアメタルノード上のODFディスクを消去してください。更新対象のノードでデバッグポッドを起動します。 NODE_NAME を、お使いのベアメタル・ワーカーノードの名前に置き換えてください。
```
	kubectl debug node/NODE_NAME -it --image=registry.access.redhat.com/ubi8/ubi
```
コマンド例
```
	kubectl debug node/kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -it --image=registry.access.redhat.com/ubi8/ubi
```
デバッグポッド内で、ホストのルートディレクトリに移動します。
```
	chroot /host
```

ODFで使用されていた各NVMeディスクを初期化してください。構成内のディスク数に応じて、ディスク範囲（nvme{0..7}n1 ）を調整してください。

	for disk in /dev/nvme{0..7}n1; do
	  echo "Wiping $disk..."
	  wipefs -af $disk
	  dd if=/dev/zero of=$disk bs=1M count=100
	  sgdisk --zap-all $disk 2>/dev/null || true
	done

ディスクがクリーンであり、ファイルシステムの痕跡が一切残っていないことを確認してください。
```
	for disk in /dev/nvme{0..7}n1; do
	  echo "=== $disk ==="
	  blkid $disk 2>&1 || echo "Clean"
	done
```
各ディスクの出力には「Clean」と表示されるはずで、これはすべてのファイルシステムのシグネチャが削除されたことを示しています。
デバッグポッドを終了します。
```
	exit
	exit
```

localvolumediscoveryresults のリソース一覧を表示し、更新対象のノードのエントリを探してください。

	kubectl get localvolumediscoveryresults -n openshift-local-storage

出力例

	NAME                                                                      AGE
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3   5d
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000004a1   5d

更新するノードの「 localvolumediscoveryresults 」リソースを削除してください。「 DISCOVERY_RESULT_NAME 」を、前の手順で指定した名前に置き換えてください。

	kubectl delete localvolumediscoveryresults DISCOVERY_RESULT_NAME -n openshift-local-storage

コマンド例

	kubectl delete localvolumediscoveryresults discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -n openshift-local-storage

これらの手順を完了したら、次のセクションに進んでワーカーノードを更新してください。ベアメタルノードが再読み込みされると、新しいパーシステントボリュームが自動的に作成され、スケジュールされます。

ワーカーノードの更新

Major update Minor update Worker replace

ibmcloud oc worker ls コマンドを使用してワーカー・ノードをリストし、前のステップで閉鎖してドレーンしたワーカー・ノードを見つけます。

	ibmcloud oc worker ls -c CLUSTER

出力例

	ID                                                 Primary IP     Flavor     State    Status   Zone        Version
	kube-c85ra07w091uv4nid9ug-vpcoc-default-000001c1   10.241.128.4   bx2.4x16   normal   Ready    us-east-3   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000288   10.241.0.4     bx2.4x16   normal   Ready    us-east-1   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000352   10.241.64.4    bx2.4x16   normal   Ready    us-east-2   4.8.29_1544_openshift*

ワーカーノードを更新する。ベアメタルワーカーノードの場合は、 worker reload コマンドを使用します。仮想サーバーインスタンス（VSI）ワーカーノードの場合は、 worker replace コマンドを使用します。

ベアメタルワーカーノード ： worker reload コマンドを使用して、ワーカーノードをリロードする。このコマンドは、VPC ベアメタルワーカーでサポートされています。 sh {: pre} ibmcloud oc worker reload --worker NODE_NAME VSI ワーカーノード ： Major update Minor update ワーカーノードを置き換え、最新のパッチを適用するためのコマンド例。 sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME --update VSI ワーカーノード ： Worker replace 最新のパッチ更新を適用せずにワーカーノードを置き換えるためのコマンド例。 sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME VSIワーカーノード交換の出力例： sh {: screen} The replacement worker node is created in the same zone with the same flavor, but gets new public or private IP addresses. During the replacement, all pods might be rescheduled onto other worker nodes and data is deleted if not stored outside the pod. To avoid downtime, ensure that you have enough worker nodes to handle your workload while the selected worker nodes are being replaced. Replace worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288? [y/N]> y Deleting worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288 and creating a new worker node in cluster

ワーカーノードが再ロードまたは交換されるのを待ち、ワーカーノードをリストアップします。このプロセスには 20 分以上かかる場合があることに留意してください。

	oc get nodes

出力例

	NAME           STATUS   ROLES           AGE   VERSION
	10.241.0.4     Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.128.4   Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.64.4    Ready    master,worker   22d   v1.21.6+bb8d50a

古いノードからリソースをクリーンアップします

Major update Minor update Worker replace

ノードがクラスタに再参加すると、 Rook-Ceph オペレーターが、 rook-ceph-mon、 rook-ceph-osd、および crashcollector のデプロイメントを自動的にスケールアップします。続行する前に、ODFポッドが実行中であることを確認してください。

先ほどスケールダウンした rook-ceph-mon および rook-ceph-osd のポッドが、更新後のノード上で再び Running 状態になっていることを確認してください。 NODE_NAME を、更新または置換されたノードの名前に置き換えてください。
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
出力に、状態が「 Running 」の「 rook-ceph-mon 」および「 rook-ceph-osd 」ポッドが表示されていることを確認してください。まだポッドが欠けている場合や、 Running になっていない場合は、数分待ってからコマンドを再度実行し、その後、次の手順に進んでください。
交換したノード上で、OSDポッドが Running 状態で起動していることを確認してください。「 NODE_NAME 」を、新しい代替ノードの名前に置き換えてください。
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep osd
```
ポッドが実行中の場合は、新しいノードを使用して OcsCluster リソースの更新を続けてください。ポッドに障害が発生した場合は、以下の手順を実行してください。 OSDポッドが複数あり、そのすべてが Running ではない場合は、処理を停止し、サポートに連絡してください。サポート Case を開きます。ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。
openshift-storage プロジェクトにナビゲートします。
```
	oc project openshift-storage
```
障害のある OSD をクラスターから除去します。必要であれば、失敗したOSDを複数指定することもできる。
```
	oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
FAILED_osd_id 値は、 rook-ceph-osd 接頭部の直後のポッド名の整数です。 OSD が 3 つしかないクラスター、または OSD が削除された後にデータの 3 つすべてのレプリカをリストアするための十分なスペースがないクラスターでは、 FORCE_OSD_REMOVAL 値を true に変更する必要があります。
ocs-osd-removal-job ポッドの状況を調べて、OSD が正常に削除されたことを確認します。
```
	oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

OSD の除去が完了したことを確認します。

	oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

出力例

	2023-03-10 06:50:04.501511 I | cephosd: completed removal of OSD 0

ベアメタルワーカーノードのみ ：OSDが削除された後、「 Released 」状態にある、 localblock ストレージクラスに関連付けられている永続ボリューム（PV）を特定してください。 OSDの取り外しにより、これらのPVは Released 状態になるため、この手順はOSDを取り外した後に行う必要があります。
```
	oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
```
出力例
```
	local-pv-d6bf175b  1490Gi  RWO  Delete  Released  openshift-storage/ocs-deviceset-0-data-0-6c5pw  localblock  2d22h  compute-1
```
ベアメタルワーカーノードのみ ： Released 状態のPVがある場合は、それらを削除してください。「 PERSISTENT_VOLUME 」を、前の手順で指定したPVの名前に置き換えてください。
```
	oc delete pv PERSISTENT_VOLUME
```
コマンド例
```
	oc delete pv local-pv-d6bf175b
```
出力例
```
	persistentvolume "local-pv-d6bf175b" deleted
```

OcsCluster リソースを新しいノードで更新する

次の手順に進む前に、クラスタ内の次のノードに移る前に、このストレージノードに関する前の手順をすべて完了していることを確認してください。

Major update Minor update Worker replace

インストール時にノード名を指定して ODF デプロイメントをワーカー・ノードのサブセットに制限した場合は、新しい名前を含めるように ocscluster CRD を更新する必要があります。すべてのワーカーノードにODFを適用し、ノードの一部にのみ展開を限定しなかった場合は、この手順をスキップして、「 OpenShift Data Foundation」アドオンの更新に進んでください。

特定のワーカーノードだけに設定を限定していない場合は、 ocscluster CRDを更新する必要はありません。
```
	oc edit ocscluster
```
```
	apiVersion: ocs.ibm.io/v1
	kind: OcsCluster
	metadata:
	name: ocscluster-auto
	spec:
	. . .
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-metro-10iops-tier
	workerNodes:
	- NODE-NAME # Example 10.248.128.42
	- NODE-NAME
	- NODE-NAME
```
OpenShift Data Foundation ポッドが新しいワーカーにデプロイされるまで待ちます。新しい永続ボリュームが作成されたこと、およびすべてのポッドが Running 状態であることを確認します。
```
	oc get pv
	oc get ocscluster
	oc get pods -n openshift-storage
```

その他の必要な OpenShift Data Foundation ポッドがすべて「実行中」状態であることを確認します。

	oc get pod -n openshift-storage | grep mon

出力例:

	rook-ceph-mon-a-cd575c89b-b6k66         2/2     Running
	0          38m
	rook-ceph-mon-b-6776bc469b-tzzt8        2/2     Running
	0          38m
	rook-ceph-mon-d-5ff5d488b5-7v8xh        2/2     Running
	0          4m8s

新しいOSDポッドが交換ノード上で実行されていることを確認する。
```
	oc get pods -o wide -n openshift-storage| egrep -i NEW_NODE_NAME | egrep osd
```

OpenShift Data Foundation アドオンの更新

Major update

既存のバージョンを確認します。

	ibmcloud oc cluster addon ls --cluster CLUSTER

アドオンを更新します。

	ibmcloud oc cluster addon update openshift-data-foundation --cluster CLUSTER --version VERSION

アドオンが最新版に更新されていることを確認してください。
```
	ibmcloud oc cluster addon ls --cluster CLUSTER
```

クラスター・リソースの更新

Major update

ocscluster リソースの名前を取得します。

	oc get ocscluster

出力例

	NAME             AGE
	ocscluster-vpc   19d

ocscluster リソースを編集するには、次のコマンドを実行してください。
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

ocsUpgrade パラメータを true に設定してください。

	...
	spec:
		billingType: hourly
	monSize: 20Gi
	monStorageClassName: ibmc-vpc-block-10iops-tier
	numOfOsd: 1
	ocsUpgrade: true
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-10iops-tier
	status:
		storageClusterStatus: Decreasing the capacity not allowed

ファイルを保存して閉じます。
更新が完了するまでお待ちください。

storagecluster リソースと cephcluster リソースの両方が正しくデプロイされていることを確認します。

	oc get storagecluster -n openshift-storage

出力例。

	NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   43h   Ready              2023-06-21T09:22:00Z   4.11.0

	oc get cephcluster -n openshift-storage

出力例。

	NAME                             DATADIRHOSTPATH   MONCOUNT   AGE   PHASE   MESSAGE                        HEALTH      EXTERNAL
	ocs-storagecluster-cephcluster   /var/lib/rook     3          43h   Ready   Cluster created successfully   HEALTH_OK

	oc get csv -n openshift-storage

出力例。

	NAME                              DISPLAY                       VERSION   REPLACES                          PHASE
	mcg-operator.v4.11.8              NooBaa Operator               4.11.8    mcg-operator.v4.11.7              Succeeded
	ocs-operator.v4.11.8              OpenShift Container Storage   4.11.8    ocs-operator.v4.11.7              Succeeded
	odf-csi-addons-operator.v4.11.8   CSI Addons                    4.11.8    odf-csi-addons-operator.v4.11.7   Succeeded
	odf-operator.v4.11.8              OpenShift Data Foundation     4.11.8    odf-operator.v4.11.7              Succeeded