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

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.

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

  1. 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-storage

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

  3. Ü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

  1. 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.21.27 --force-update

  2. Warten Sie, bis die Masteraktualisierung abgeschlossen ist.

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

Großes Update Kleines Update Arbeiter ersetzen

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

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

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

  2. Löschen Sie alle verbleibenden Noobaa-Pods in der folgenden Reihenfolge.

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

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

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

  2. 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"

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

Großes Update Kleines Update Arbeiter ersetzen

Nur für Bare-Metal-Worker-Knoten: Wenn Sie einen Bare-Metal-Worker-Knoten aktualisieren oder ersetzen, führen Sie die folgenden Schritte aus, um persistente Volumes zu bereinigen 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.

  1. Ermitteln Sie alle persistenten Volumes (PVs) im Status „ Released “, die der Speicherklasse „ localblock “ auf dem Knoten zugeordnet sind, den Sie aktualisieren.

    	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

  2. Falls sich PVs im Status „ 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

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

  4. Wechseln Sie im Debug-Pod in das Stammverzeichnis des Hosts.

    	chroot /host

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

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

  7. Verlassen Sie den Debug-Pod.

    	exit
	exit

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

  9. 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 diese Schritte abgeschlossen sind, werden auf dem Bare-Metal-Knoten nach dessen Neustart automatisch neue persistente Volumes erstellt und eingeplant. Fahren Sie mit dem nächsten Abschnitt fort, um den Worker-Knoten zu aktualisieren.

Aktualisieren Sie den Arbeitsknoten

Großes Update Kleines Update Arbeiter ersetzen

  1. 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*

  2. 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 kube-*** VSI-Arbeitsknoten: Minor update Beispielbefehl, um den Arbeitsknoten zu ersetzen und das neueste Patch-Update anzuwenden. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update VSI-Arbeiter-Knoten: Worker replace Beispielbefehl zum Ersetzen des Worker-Knotens ohne Anwendung des letzten Patch-Updates. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** 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

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

Großes Update Kleines Update Arbeiter ersetzen

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

  2. Navigieren Sie zum Projekt openshift-storage.

    	oc project openshift-storage

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

  4. Ü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

  5. Ü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

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

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

  3. Ü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

  4. Ü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

  1. Überprüfen Sie die vorhandene Version.

    	ibmcloud oc cluster addon ls --cluster CLUSTER

  2. Aktualisieren Sie das Add-on.

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

  3. Stellen Sie sicher, dass das Add-on auf dem neuesten Stand ist.

    	ibmcloud oc cluster addon ls --cluster CLUSTER

Clusterressource aktualisieren

Wichtiges Update

  1. Rufen Sie den Namen Ihrer Ressource ocscluster ab.

    	oc get ocscluster

    Beispielausgabe

    	NAME             AGE
	ocscluster-vpc   19d

  2. Führen Sie den folgenden Befehl aus, um Ihre Ressource ocscluster zu bearbeiten.

    	oc edit ocscluster OCS-CLUSTER-NAME

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

  4. Speichern und schließen Sie die Datei.

  5. Warten Sie, bis die Aktualisierung abgeschlossen ist.

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