Aktualisieren oder Ersetzen von VPC-Worker-Knoten, die OpenShift Data Foundation nutzen

Virtual Private Cloud

Bei VPC-Clustern mit einer Speicherlösung wie der OpenShift Data Foundation müssen Sie jeden Worker-Knoten nacheinander isolieren, leeren und aktualisieren. Bei Bare-Metal-Worker-Knoten können Sie nun den Befehl „ worker reload “ anstelle von „ worker replace “ verwenden. Wenn Sie OpenShift Data Foundation auf einer Teilmenge der Worker-Knoten in Ihrem Cluster bereitgestellt haben, müssen Sie nach der Aktualisierung des Worker-Knotens die Ressource ocscluster bearbeiten, um den neuen Worker-Knoten einzubeziehen.

Die folgende Anleitung behandelt sowohl größere als auch kleinere Aktualisierungen und Aktualisierungen der Arbeitsknoten.

Major update: Führen Sie die Schritte mit dieser Bezeichnung aus, um eine Hauptaktualisierung anzuwenden; zum Beispiel, wenn Sie Ihre Arbeitsknoten auf eine neue Hauptversion aktualisieren, wie von 4.11 auf 4.12 sowie OpenShift Data Foundation von 4.11 auf 4.12.
Minor update: Führen Sie die Schritte mit dieser Bezeichnung aus, um eine Patchaktualisierung anzuwenden, z. B. wenn Sie eine Aktualisierung von 4.12.15_1542_openshift auf 4.12.16_1544_openshift durchführen und dabei OpenShift Data Foundation in Version 4.12 beibehalten. Sie müssen diese Schritte für jeden Knoten wiederholen, den Sie aktualisieren möchten.
Worker replace: Führen Sie die Schritte mit dieser Bezeichnung aus, falls Sie einen Workerknoten mit derselben Patchversion ersetzen. Sie müssen diese Schritte für jeden Knoten wiederholen, den Sie ersetzen möchten.

Das Überspringen von Versionen während eines Upgrades, beispielsweise von 4.8 auf, 4.12 wird nicht unterstützt.

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

Bevor Sie Ihre Workerknoten aktualisieren, stellen Sie sicher, dass Sie Ihre App-Daten sichern. Planen Sie außerdem, die folgenden Schritte für jeweils einen Workerknoten auszuführen. Wiederholen Sie die Schritte für jeden Workerknoten, den Sie aktualisieren wollen.

Überprüfen Sie den Status Ihres Speicherclusters

Major update Minor update Worker replace

Listen Sie die Pods auf, indem Sie den folgenden Befehl ausführen. Überprüfen Sie, ob alle Pods im Namespace openshift-storage in einem guten Zustand sind. Behandeln Sie alle Pods, die sich nicht im Zustand Completed Running oder befinden.
```
	oc get pods -n openshift-storage
```

Führen Sie den folgenden Befehl aus und überprüfen Sie, ob die Phase der ocs-storagecluster Ready ist.

	oc get storagecluster -n openshift-storage

Beispielausgabe

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

Überprüfen Sie den Status des Ceph-Speichers, indem Sie den folgenden Befehl ausführen. Vergewissern Sie sich, dass der Gesundheitszustand HEALTH_OK ist, dass alle OSDs up und IN sind und dass alle pgs active+clean sind. Wenn eine dieser Prüfungen fehlschlägt, öffnen Sie einen Support-Fall. Geben Sie in den Falldetails unbedingt alle relevanten Protokolldateien, Fehlermeldungen oder Befehlsausgaben an. Lösen Sie alle Probleme, bevor Sie fortfahren.

	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

Beispielausgabe

	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

Wiederholen Sie diese Zustandsprüfungen, bevor Sie den Aktualisierungsvorgang für weitere Knoten wiederholen. Das gleichzeitige Herunterfahren von mehr als einem OSD-Pod kann die Benutzerdaten gefährden.

Cluster-Master aktualisieren

Major update

Wenn Sie Ihre Workerknoten auf eine neue Hauptversion aktualisieren, z. B. von 4.11 auf 4.12, aktualisieren Sie zuerst den Cluster-Master.

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

Beispielbefehl:

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

Warten Sie einige Minuten und überprüfen Sie anschließend, ob die Master-Aktualisierung abgeschlossen ist.
```
	  ibmcloud oc cluster ls
```

Entscheiden Sie, welche Speicherknoten Sie aktualisieren oder ersetzen möchten

Major update Minor update Worker replace

Listen Sie Ihre Worker-Knoten mithilfe von auf und oc get nodes legen Sie fest, welche Speicherknoten Sie aktualisieren möchten.

oc get nodes

Beispielausgabe

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

Stellen Sie sicher, dass der Speichercluster einwandfrei funktioniert

Major update Minor update Worker replace

Führen Sie die folgenden Befehle aus, um den Zustand des Speicher-Clusters zu überprüfen.

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

Vergewissern Sie sich, dass der Speichercluster in Ordnung ist, bevor Sie fortfahren.

OpenShift-Datenbasis in Cordon- und Scale-Down-Umgebungen

Major update Minor update Worker replace

Das Herunterfahren der rook-ceph-mon, rook-ceph-osd, und crashcollector-Bereitstellungen vor dem Leeren stellt sicher, dass diese Speicherprozesse ordnungsgemäß beendet werden, anstatt zwangsweise beendet zu werden. Laufende OSD- und Monitor-Pods müssen ordnungsgemäß heruntergefahren werden, damit Ceph die E/A-Vorgänge sicher abschließen und die Datenintegrität gewährleisten kann, während der Knoten offline ist. Nachdem der aktualisierte oder ersetzte Knoten wieder dem Cluster beigetreten ist, skaliert der Rook-Ceph-Operator diese Bereitstellungen automatisch wieder auf ihre ursprüngliche Replikanzahl hoch.

Riegeln Sie den Knoten ab. Durch das Sperren des Knotens wird verhindert, dass Pods auf diesem Knoten eingeplant werden, während Sie die ODF-Bereitstellungen verkleinern.
```
	oc adm cordon NODE_NAME
```
Beispielausgabe
```
	node/10.241.0.4 cordoned
```
Ermitteln Sie die und rook-ceph-mon Pods rook-ceph-osd, die auf dem Knoten laufen, den Sie aktualisieren. Notieren Sie sich die Pod-Namen in der Ausgabe – Sie benötigen sie im nächsten Schritt.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
Der Bereitstellungsname entspricht dem Pod-Namen ohne die an das Ende angehängten Suffixe ReplicaSet und die Pod-ID. Beispielsweise rook-ceph-osd-1-6d9f99c68f-pgvxt``rook-ceph-mon-e-85fbb8bcc-kttbt gehört ein Pod mit dem Namen zum Deployment rook-ceph-osd-1 und ein Pod mit dem Namen zum Deployment rook-ceph-mon-e.
Reduzieren Sie die Bereitstellungen für die Pods, die Sie im vorherigen Schritt gefunden haben. Ersetzen Sie und ROOK_CEPH_MON_DEPLOYMENT ROOK_CEPH_OSD_DEPLOYMENT durch die Deployment-Namen, die Sie aus den Pod-Namen abgeleitet haben. Falls der vorherige Befehl keine oder rook-ceph-mon rook-ceph-osd Pods auf diesem Knoten zurückgegeben hat, überspringen Sie diese beiden Befehle und fahren Sie mit dem Befehl crashcollector fort.
```
	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
```
Wenn der Befehl zurückgibt error: no objects passed to scale, überprüfen Sie, ob auf diesem Knoten kein crashcollector-Pod ausgeführt wird, indem Sie ausführen oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep crashcollector. Wenn kein Pod zurückgegeben wird, können Sie diesen Befehl getrost überspringen und fortfahren.

Bereinigen Sie den Workerknoten:

Major update Minor update Worker replace

Bereinigen Sie den Knoten, um alle Pods zu entfernen. Wenn Sie den Workerknoten bereinigen, werden die Pods auf die anderen Workerknoten verschoben, um sicherzustellen, dass keine Ausfallzeit auftritt. Durch das Entleeren wird außerdem sichergestellt, dass das Budget für Podunterbrechungen nicht beeinträchtigt wird.

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

Beispielausgabe

	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"

Sollten während des Drain-Vorgangs NooBaa-Pods hängen bleiben, löschen Sie diese in der folgenden Reihenfolge, damit sie auf einem anderen Knoten neu eingeplant werden.

	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

Warten Sie, bis der Entleerungsvorgang abgeschlossen ist, und führen Sie anschließend die folgenden Schritte aus, um den Worker-Knoten zu aktualisieren.

Persistente Volumes für Bare-Metal-Worker-Knoten bereinigen

Major update Minor update Worker replace

Nur Bare-Metal-Worker-Knoten: Wenn Sie einen Bare-Metal-Worker-Knoten aktualisieren oder ersetzen, führen Sie die folgenden Schritte aus, um die ODF-Festplatten zu löschen und den Knoten für die neue Bereitstellung vorzubereiten. Wenn Sie mit Worker-Knoten in Form von virtuellen Serverinstanzen (VSI) arbeiten, überspringen Sie diesen Abschnitt und fahren Sie mit dem Abschnitt „Worker-Knoten aktualisieren“ fort.

Bevor Sie beginnen, stellen Sie sicher, dass Sie die vorherigen Schritte zum Isolieren und Entleeren des Worker-Knotens abgeschlossen haben.

Löschen Sie die ODF-Datenträger auf dem Bare-Metal-Knoten, um die Erstellung eines neuen persistenten Volumes vorzubereiten. Starten Sie einen Debug-Pod auf dem Knoten, den Sie aktualisieren. Ersetzen Sie „ NODE_NAME “ durch den Namen Ihres Bare-Metal-Worker-Knotens.
```
	kubectl debug node/NODE_NAME -it --image=registry.access.redhat.com/ubi8/ubi
```
Beispielbefehl
```
	kubectl debug node/kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -it --image=registry.access.redhat.com/ubi8/ubi
```
Wechseln Sie im Debug-Pod in das Stammverzeichnis des Hosts.
```
	chroot /host
```

Löschen Sie jede NVMe-Festplatte, die von ODF verwendet wurde. Passen Sie den Festplattenbereich (nvme{0..7}n1) entsprechend der Anzahl der Festplatten in Ihrer Konfiguration an.

	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

Stellen Sie sicher, dass die Festplatten sauber sind und keine Dateisystem-Signaturen mehr aufweisen.
```
	for disk in /dev/nvme{0..7}n1; do
	  echo "=== $disk ==="
	  blkid $disk 2>&1 || echo "Clean"
	done
```
In der Ausgabe sollte bei jeder Festplatte „Clean“ angezeigt werden, was bedeutet, dass alle Dateisystem-Signaturen entfernt wurden.
Verlassen Sie den Debug-Pod.
```
	exit
	exit
```

Rufen Sie die „ localvolumediscoveryresults “-Ressourcen ab, um den Eintrag für den Knoten zu finden, den Sie aktualisieren möchten.

	kubectl get localvolumediscoveryresults -n openshift-local-storage

Beispielausgabe

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

Löschen Sie die Ressource „ localvolumediscoveryresults “ für den Knoten, den Sie aktualisieren. Ersetzen Sie „ DISCOVERY_RESULT_NAME “ durch den Namen aus dem vorherigen Schritt.

	kubectl delete localvolumediscoveryresults DISCOVERY_RESULT_NAME -n openshift-local-storage

Beispielbefehl

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

Nachdem Sie diese Schritte abgeschlossen haben, fahren Sie mit dem nächsten Abschnitt fort, um den Worker-Knoten zu aktualisieren. Neue persistente Volumes werden nach dem Neuladen des Bare-Metal-Knotens automatisch erstellt und eingeplant.

Aktualisieren Sie den Arbeitsknoten

Major update Minor update Worker replace

Listen Sie Ihre Workerknoten mit dem Befehl ibmcloud oc worker ls auf und suchen Sie den Workerknoten, den Sie im vorherigen Schritt gesperrt und bereinigt haben.

	ibmcloud oc worker ls -c CLUSTER

Beispielausgabe

	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*

Aktualisieren Sie den Arbeitsknoten. Für Bare Metal Worker Nodes verwenden Sie den Befehl worker reload. Für VSI-Arbeitsknoten (Virtual Server Instance) verwenden Sie den Befehl worker replace.

Bare Metal Worker Nodes: Verwenden Sie den Befehl worker reload, um den Worker Node neu zu laden. Dieser Befehl wird für VPC-Bare-Metal-Worker unterstützt. sh {: pre} ibmcloud oc worker reload --worker NODE_NAME VSI-Worker-Knoten: Major updateMinor update Beispielbefehl zum Ersetzen des Worker-Knotens und zum Anwenden des neuesten Patch-Updates. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME --update VSI-Worker-Knoten: Worker replace Beispielbefehl zum Ersetzen des Worker-Knotens ohne Installation des neuesten Patch-Updates. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker NODE_NAME Beispielausgabe für die Ersetzung von VSI-Arbeitsknoten: 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

Warten Sie, bis der Worker Node neu geladen oder ersetzt wurde, und listen Sie dann Ihre Worker Nodes auf. Beachten Sie, dass dieser Prozess 20 Minuten oder länger dauern kann.

	oc get nodes

Beispielausgabe

	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

Ressourcen auf dem alten Knoten bereinigen

Major update Minor update Worker replace

Nachdem der Knoten wieder dem Cluster beigetreten ist, skaliert der Rook-Ceph-Operator die Deployments von rook-ceph-mon, rook-ceph-osd, und crashcollector automatisch wieder hoch. Stellen Sie sicher, dass die ODF-Pods laufen, bevor Sie fortfahren.

Stellen Sie sicher, dass die rook-ceph-mon und Pods rook-ceph-osd, die zuvor verkleinert wurden, auf dem aktualisierten Knoten wieder den Status Running haben. Ersetzen Sie durch NODE_NAME den Namen des aktualisierten oder ersetzten Knotens.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
Stellen Sie sicher, dass die Ausgabe und rook-ceph-mon Pods rook-ceph-osd im Status Running anzeigt. Falls noch Pods fehlen oder noch nicht bereit sind Running, warten Sie einige Minuten und führen Sie den Befehl erneut aus, bevor Sie fortfahren.
Stellen Sie sicher, dass der OSD-Pod auf dem ausgetauschten Knoten in einem bestimmten Zustand Running gestartet wurde. Ersetzen Sie durch NODE_NAME den Namen des neuen Ersatzknotens.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep osd
```
Wenn der Pod läuft, fahren Sie fort mit dem Aktualisieren der Ressource OcsCluster mit dem neuen Knoten. Falls der Pod ausgefallen ist, führen Sie die folgenden Schritte aus. Falls mehr als ein OSD-Pod nicht verfügbar ist Running, brechen Sie den Vorgang ab und wenden Sie sich an den Support. Öffnen Sie einen Supportfall. Fügen Sie den Falldetails unbedingt alle relevanten Protokolldateien, Fehlermeldungen oder Befehlsausgaben bei.
Navigieren Sie zum Projekt openshift-storage.
```
	oc project openshift-storage
```
Entfernen Sie das fehlerhafte OSD aus dem Cluster. Sie können bei Bedarf mehrere fehlgeschlagene OSDs angeben.
```
	oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
Der Wert FAILED_osd_id ist die ganze Zahl im Podnamen direkt nach dem Präfix rook-ceph-osd. Der Wert FORCE_OSD_REMOVAL muss in Clustern mit nur drei OSDs in true geändert werden oder in Clustern mit nicht ausreichendem Speicherplatz, um alle drei Replikate der Daten nach dem Entfernen des OSD wiederherzustellen.
Überprüfen Sie, ob das OSD erfolgreich entfernt wurde, indem Sie den Status des Pods ocs-osd-removal-job überprüfen.
```
	oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

Überprüfen Sie, ob das Entfernen des OSD abgeschlossen ist.

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

Beispielausgabe

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

Nur Bare-Metal-Worker-Knoten: Identifizieren Sie nach dem Entfernen des OSD alle persistenten Volumes (PVs) im Status Released, die der localblock Speicherklasse zugeordnet sind. Durch das Entfernen des OSD werden diese PVs in den Status Released versetzt, daher muss dieser Schritt erst nach dem Entfernen des OSD durchgeführt werden.
```
	oc get pv -L kubernetes.io/hostname | grep localblock | grep Released
```
Beispielausgabe
```
	local-pv-d6bf175b  1490Gi  RWO  Delete  Released  openshift-storage/ocs-deviceset-0-data-0-6c5pw  localblock  2d22h  compute-1
```
Nur Bare-Metal-Worker-Knoten: Falls sich PVs im Zustand Released befinden, löschen Sie diese. Ersetzen Sie durch PERSISTENT_VOLUME den Namen des PV aus dem vorherigen Schritt.
```
	oc delete pv PERSISTENT_VOLUME
```
Beispielbefehl
```
	oc delete pv local-pv-d6bf175b
```
Beispielausgabe
```
	persistentvolume "local-pv-d6bf175b" deleted
```

Aktualisieren Sie die Ressource OcsCluster mit dem neuen Knoten

Bevor Sie mit den folgenden Schritten fortfahren, stellen Sie sicher, dass Sie die vorherigen Schritte für diesen Speicherknoten abgeschlossen haben, bevor Sie zum nächsten Knoten im Cluster übergehen.

Major update Minor update Worker replace

Wenn Sie Ihre ODF-Bereitstellung auf eine Untergruppe von Workerknoten begrenzt haben, indem Sie während der Installation Knotennamen angegeben haben, müssen Sie die ocscluster-CRD so aktualisieren, dass sie den neuen Namen enthält. Wenn Sie ODF auf alle Ihre Worker-Knoten angewendet und die Bereitstellung nicht auf eine Teilmenge von Knoten beschränkt haben, überspringen Sie diesen Schritt und fahren Sie mit dem Aktualisieren des Add-ons OpenShift Data Foundation fort.

Wenn Sie Ihre Konfiguration nicht auf bestimmte Arbeitsknoten beschränkt haben, müssen Sie das ocscluster CRD nicht aktualisieren.
```
	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
```
Warten Sie, bis die OpenShift Data Foundation-Pods auf dem neuen Worker bereitgestellt wurden. Überprüfen Sie, ob die neuen persistenten Datenträger erstellt wurden und sich alle Pods im Status Running befinden.
```
	oc get pv
	oc get ocscluster
	oc get pods -n openshift-storage
```

Überprüfen Sie, ob sich alle anderen erforderlichen OpenShift Data Foundation-Pods im Status 'Aktiv' befinden.

	oc get pod -n openshift-storage | grep mon

Beispielausgabe:

	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

Überprüfen Sie, ob die neuen OSD-Pods auf dem Ersatzknoten ausgeführt werden.

	oc get pods -o wide -n openshift-storage| egrep -i NEW_NODE_NAME | egrep osd

OpenShift Data Foundation-Add-on aktualisieren

Major update

Überprüfen Sie die vorhandene Version.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Aktualisieren Sie das Add-on.

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

Stellen Sie sicher, dass das Add-on auf dem neuesten Stand ist.
```
	ibmcloud oc cluster addon ls --cluster CLUSTER
```

Clusterressource aktualisieren

Major update

Rufen Sie den Namen Ihrer Ressource ocscluster ab.

	oc get ocscluster

Beispielausgabe

	NAME             AGE
	ocscluster-vpc   19d

Führen Sie den folgenden Befehl aus, um Ihre Ressource ocscluster zu bearbeiten.
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

Setzen Sie den Parameter ocsUpgrade auf 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

Speichern und schließen Sie die Datei.
Warten Sie, bis die Aktualisierung abgeschlossen ist.

Stellen Sie sicher, dass die Ressourcen storagecluster und cephcluster ordnungsgemäß implementiert sind.

	oc get storagecluster -n openshift-storage

Beispielausgabe.

	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

Beispielausgabe.

	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

Beispielausgabe.

	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