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

Virtuelle private Cloud

Bei VPC-Clustern mit einer Speicherlösung wie OpenShift Data Foundation müssen Sie jeden Worker-Knoten nacheinander isolieren, entleeren und ersetzen. Wenn Sie OpenShift Data Foundation auf einer Untergruppe von Workerknoten in Ihrem Cluster bereitgestellt haben, müssen Sie nach dem Ersetzen des Workerknotens die Ressource ocscluster bearbeiten, um den neuen Workerknoten einzuschließen.

Das folgende Lernprogramm behandelt sowohl Haupt-als auch Nebenaktualisierungen und Workeraustausch.

Wichtiges 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.
Kleinere Aktualisierung: 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.
Arbeiter ersetzen: 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

Großes Update Kleines Update Arbeiter ersetzen

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. Wenden Sie sich an alle Pods, die sich nicht im Zustand "Laufen" oder "Abgeschlossen" befinden.
```
	oc get pods -n openshift-storge
```

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 mehrerer OSD-Pods kann die Benutzerdaten gefährden.

Cluster-Master aktualisieren

Wichtiges 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 [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Beispielbefehl:

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

Warten Sie, bis die Masteraktualisierung abgeschlossen ist.

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

Großes Update Kleines Update Arbeiter ersetzen

Listen Sie Ihre Worker-Knoten mit auf oc get nodes und 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 fehlerfrei ist

Großes Update Kleines Update Arbeiter ersetzen

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.

Scale-down für OpenShift Data Foundation durchführen

Großes Update Kleines Update Arbeiter ersetzen

Suchen Sie für jeden Workerknoten, den Sie im vorherigen Schritt gefunden haben, die Bereitstellungen rook-ceph-mon und rook-ceph-osd.
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```
Wenn die Noobaa-Pods beim Entleeren hängen bleiben, können Sie die NooBaa Pods manuell löschen, damit sie auf einem anderen Knoten geplant werden.
Löschen Sie alle verbleibenden Noobaa-Pods in der folgenden Reihenfolge.
```
noobaa-db
noobaa-core
noobaa-endpoint
noobaa-operator
```

Führen Sie ein Scale-down für die Bereitstellungen durch, die Sie im vorherigen Schritt gefunden haben.

	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

Workerknoten anschnallen und bereinigen

Großes Update Kleines Update Arbeiter ersetzen

Riegeln Sie den Knoten ab. Durch das Abriegeln des Knotens wird verhindert, dass Pods auf diesem Knoten geplant werden.
```
oc adm cordon NODE_NAME
```
Beispielausgabe
```
node/10.241.0.4 cordoned
```

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"

Warten Sie, bis das Entleeren abgeschlossen ist, und führen Sie dann die folgenden Schritte aus, um den Workerknoten auszutauschen.

Workerknoten ersetzen

Großes Update Kleines Update Arbeiter ersetzen

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*

Ersetzen Sie den Workerknoten.

Unbedeutende Aktualisierung Beispielbefehl zum Ersetzen des Workerknotens und zum Anwenden der neuesten Patchaktualisierung.

ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update

Workerknoten ersetzen Beispielbefehl zum Ersetzen des Workerknotens, ohne die neueste Patchaktualisierung anzuwenden.

ibmcloud oc worker replace -c CLUSTER --worker kube-***

Beispielausgabe

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 Ersatzknoten bereitgestellt wurde, und listen Sie dann Ihre Worker-Knoten 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

Großes Update Kleines Update Arbeiter ersetzen

Vergewissern Sie sich, dass der OSD-Pod auf dem ersetzten Knoten im Zustand running hochgefahren wurde. Wenn der Pod in Betrieb ist, fahren Sie mit Schritt 7 fort. Wenn der Pod ausgefallen ist, gehen Sie wie folgt vor steps.If mehr als ein OSD-Pod ist nicht Running, halten Sie an 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

Fügen Sie den neuen Speicherknoten hinzu

Bevor Sie neue Speicherknoten hinzufügen, stellen Sie sicher, dass Sie die vorherigen Schritte für alle Speicherknoten im Cluster abgeschlossen haben.

Großes Update Kleines Update Arbeiter ersetzen

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

Wichtiges 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

Überprüfen Sie, ob das Add-on aktualisiert wurde.
```
	ibmcloud oc cluster addon ls --cluster CLUSTER
```

Clusterressource aktualisieren

Wichtiges Update

Rufen Sie den Namen Ihrer ocscluster Ressource ab.

	oc get ocscluster

Beispielausgabe

	NAME             AGE
	ocscluster-vpc   19d

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

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