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

仮想プライベートクラウド

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

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

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

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

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

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

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

メジャーアップデートマイナーアップデート作業員の交代

次のコマンドを実行して、ポッドの一覧を表示してください。 openshift-storage ネームスペース内のすべてのポッドが良好な状態であることを確認する。実行中」または「完了」状態でないポッドに対処する。
```
	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ポッドをダウンさせると、ユーザーデータが危険にさらされる可能性があります。

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

メジャーアップデート

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

	ibmcloud oc cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

コマンド例:

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

マスターの更新が終了するまで待ちます。

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

メジャーアップデートマイナーアップデート作業員の交代

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

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

メジャーアップデートマイナーアップデート作業員の交代

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

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

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

OpenShift Data Foundation のスケールダウン

メジャーアップデートマイナーアップデート作業員の交代

前のステップで確認したワーカー・ノードごとに、 rook-ceph-mon デプロイメントと rook-ceph-osd デプロイメントを見つけます。
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```
Noobaaポッドがドレイン中にスタックした場合、手動でポッド NooBaa を削除できます。これにより、別のノードでスケジュールされるようになります。

次の順序で残りのヌーバ・ポッドを削除する。

   noobaa-db
   noobaa-core
   noobaa-endpoint
   noobaa-operator

前のステップで確認したデプロイメントをスケールダウンします。

	oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage

	oc scale deployment rook-ceph-osd-2 --replicas=0 -n openshift-storage

	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE-NAME --replicas=0 -n openshift-storage

ワーカー・ノードを閉鎖およびドレーンします

メジャーアップデートマイナーアップデート作業員の交代

ノードを閉鎖します。ノードを閉鎖すると、このノードでポッドがスケジュールされなくなります。
```
oc adm cordon NODE_NAME
```
出力例
```
node/10.241.0.4 cordoned
```

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

	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"

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

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

メジャーアップデートマイナーアップデート作業員の交代

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

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

更新対象のノード上で、 localblock ストレージクラスに関連付けられている、 Released 状態のパーシステントボリューム（PV）を特定します。

	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
```
新しい永続ボリュームの作成に備えて、ベアメタルノード上の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

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

ワーカーノードの更新

メジャーアップデートマイナーアップデート作業員の交代

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 kube-*** VSI ワーカーノード ：マイナーアップデートワーカーノードを交換し、最新のパッチアップデートを適用するコマンド例。 sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update VSIワーカーノード ： Worker replace 最新のパッチアップデートを適用せずにワーカーノードを置き換えるコマンド例。 sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** 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

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

メジャーアップデートマイナーアップデート作業員の交代

OSD pod が running の状態で交換されたノード上に立ち上がったことを確認する。ポッドが作動している場合は、ステップ7に進みます。ポッドが故障した場合は、以下を実行してください。 steps.If 複数の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

新しいストレージノードを追加する

新しいストレージノードを追加する前に、クラスタ内のすべてのストレージノードについて前の手順が完了していることを確認します。

メジャーアップデートマイナーアップデート作業員の交代

インストール時にノード名を指定して ODF デプロイメントをワーカー・ノードのサブセットに制限した場合は、新しい名前を含めるように ocscluster CRD を更新する必要があります。

特定のワーカーノードだけに設定を限定していない場合は、 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 アドオンの更新

メジャーアップデート

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

	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
```

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

メジャーアップデート

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