Aggiornamento o sostituzione dei nodi di lavoro VPC che utilizzano OpenShift Data Foundation

Cloud privato virtuale

Per i cluster VPC con una soluzione di archiviazione come OpenShift Data Foundation, è necessario cordonare, svuotare e aggiornare ogni nodo worker in modo sequenziale. Per i nodi di lavoro bare metal, ora è possibile utilizzare il comando worker reload al posto di worker replace``. Se si è distribuito OpenShift Data Foundation a un sottoinsieme di nodi worker nel cluster, dopo aver aggiornato il nodo worker, è necessario modificare la risorsa ocscluster per includere il nuovo nodo worker.

La seguente esercitazione tratta gli aggiornamenti maggiori e minori e gli aggiornamenti dei nodi worker.

Aggiornamento importante: Completa la procedura con questa etichetta per applicare un aggiornamento principale; ad esempio, se stai aggiornando i tuoi nodi di lavoro a una nuova versione principale, come ad esempio da 4.11 a 4.12 e OpenShift Data Foundation da 4.11 a 4.12.
Aggiornamento minore: Completa la procedura con questa etichetta per applicare un aggiornamento della patch, ad esempio se stai eseguendo l'aggiornamento da 4.12.15_1542_openshift a 4.12.16_1544_openshift mantenendo OpenShift Data Foundation alla versione 4.12. È necessario ripetere questi passi per ogni nodo che si desidera aggiornare.
Sostituzione del lavoratore: Completa i passi con questa etichetta se stai sostituendo un nodo di lavoro alla stessa versione di patch. È necessario ripetere queste operazioni per ogni nodo che si desidera sostituire.

Il salto di versioni durante un aggiornamento, ad esempio da 4.8 a, non 4.12 è supportato.

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Prima di eseguire l'aggiornamento dei tuoi nodi di lavoro, assicurati di eseguire il backup dei tuoi dati dell'applicazione. Inoltre, pianifica di completare la seguente procedura per un nodo di lavoro alla volta. Ripetere questi passaggi per ogni nodo di lavoro che si desidera aggiornare.

Controllare lo stato del cluster di archiviazione

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Elenca i pod eseguendo il seguente comando. Verificare che tutti i pod nello spazio dei nomi openshift-storage siano in buono stato. Rivolgersi a tutti i pod che non sono in stato "In esecuzione" o "Completato".
```
	oc get pods -n openshift-storage
```

Eseguire il seguente comando e verificare che Phase di ocs-storagecluster sia Ready.

	oc get storagecluster -n openshift-storage

Output di esempio

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

Verificare lo stato di Ceph Storage eseguendo il seguente comando. Verificare che lo stato di salute sia HEALTH_OK, che tutti gli OSD siano up e IN e che tutti gli pgs siano active+clean. Se uno di questi controlli non riesce, aprire un caso di assistenza. Nei dettagli del caso, assicurarsi di includere tutti i file di log, i messaggi di errore o gli output dei comandi pertinenti. Risolvere eventuali problemi prima di continuare.

	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

Output di esempio

	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

Ripetere questi controlli prima di ripetere la procedura di aggiornamento per altri nodi. L'abbattimento di più pod OSD alla volta potrebbe mettere a rischio i dati degli utenti.

Aggiorna il master cluster

Aggiornamento importante

Se stai aggiornando i tuoi nodi di lavoro a una nuova versione principale, ad esempio da 4.11 a 4.12, aggiorna prima il master cluster.

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

Comando di esempio:

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

Attendere il completamento dell'aggiornamento master.

Decidere quali nodi di archiviazione si desidera aggiornare o sostituire

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Elenca i tuoi nodi di lavoro utilizzando oc get nodes e determina quali nodi di archiviazione vuoi aggiornare.

	oc get nodes

Output di esempio

	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

Assicurarsi che il cluster di storage sia sano

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Eseguire i seguenti comandi per verificare lo stato del cluster di storage.

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

Assicurarsi che il cluster di storage sia sano prima di continuare.

Riduci OpenShift Data Foundation

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Per ogni nodo di lavoro trovato nel passo precedente, trova le distribuzioni rook-ceph-mon e rook-ceph-osd.
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```
Se i pod Noobaa si bloccano durante lo scaricamento, è possibile eliminarli NooBaa manualmente, in modo che vengano pianificati su un nodo diverso.

Eliminare i pod Noobaa rimanenti nel seguente ordine.

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

Riduci le distribuzioni che hai trovato nel passo precedente.

	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

Cordone e scarico del nodo di lavoro

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Cordone il nodo. La cordonatura del nodo impedisce la pianificazione di qualsiasi pod su questo nodo.
```
oc adm cordon NODE_NAME
```
Output di esempio
```
node/10.241.0.4 cordoned
```

Svuotare il nodo per rimuovere tutti i pod. Quando scarichi il nodo di lavoro, i pod si spostano sugli altri nodi di lavoro assicurandoti che non vi sia alcun tempo di inattività. Il drenaggio garantisce inoltre che non vi sia alcuna interruzione del budget di interruzione del pod.

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

Output di esempio

	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"

Attendere il termine del drenaggio, quindi completare i passaggi seguenti per aggiornare il nodo worker.

Ripulire i volumi persistenti dei nodi di lavoro bare metal

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Solo per i nodi worker bare metal: se si sta aggiornando o sostituendo un nodo worker bare metal, seguire la procedura riportata di seguito per ripulire i volumi persistenti e preparare il nodo alla nuova distribuzione. Se stai lavorando con nodi di lavoro basati su istanze di server virtuali (VSI), salta questa sezione e passa alla sezione " Aggiornamento del nodo di lavoro ".

Prima di iniziare, assicurati di aver completato i passaggi precedenti relativi all’isolamento e allo svuotamento del nodo di lavoro.

Individuare eventuali volumi persistenti (PV) in stato “ Released ” associati alla classe di archiviazione “ localblock ” sul nodo che si sta aggiornando.

	oc get pv -L kubernetes.io/hostname | grep localblock | grep Released

Output di esempio

	local-pv-d6bf175b  1490Gi  RWO  Delete  Released  openshift-storage/ocs-deviceset-0-data-0-6c5pw  localblock  2d22h  compute-1

Se sono presenti PV in stato " Released ", eliminali. Sostituisci " <persistent_volume> " con il nome del PV indicato nel passaggio precedente.
```
	oc delete pv <persistent_volume>
```
Comando di esempio
```
	oc delete pv local-pv-d6bf175b
```
Output di esempio
```
	persistentvolume "local-pv-d6bf175b" deleted
```
Cancella i dischi ODF sul nodo bare metal per prepararlo alla creazione di un nuovo volume persistente. Avvia un pod di debug sul nodo che stai aggiornando. Sostituisci " <node-name> " con il nome del tuo nodo worker bare metal.
```
	kubectl debug node/<node-name> -it --image=registry.access.redhat.com/ubi8/ubi
```
Comando di esempio
```
	kubectl debug node/kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -it --image=registry.access.redhat.com/ubi8/ubi
```
All'interno del pod di debug, passare alla directory principale dell'host.
```
	chroot /host
```

Cancella tutti i dischi NVMe utilizzati da ODF. Regolare l'intervallo dei dischi (nvme{0..7}n1) in base al numero di dischi presenti nella configurazione.

	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

Verificare che i dischi siano puliti e non presentino più alcuna traccia del file system.
```
	for disk in /dev/nvme{0..7}n1; do
	  echo "=== $disk ==="
	  blkid $disk 2>&1 || echo "Clean"
	done
```
Per ogni disco, nell'output dovrebbe comparire la dicitura "Clean", a indicare che tutte le firme del filesystem sono state rimosse.
Esci dal pod di debug.
```
	exit
	exit
```

Elenca le risorse localvolumediscoveryresults per individuare la voce relativa al nodo che stai aggiornando.

	kubectl get localvolumediscoveryresults -n openshift-local-storage

Output di esempio

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

Elimina la risorsa “ localvolumediscoveryresults ” relativa al nodo che stai aggiornando. Sostituisci " <discovery-result-name> " con il nome indicato nel passaggio precedente.

	kubectl delete localvolumediscoveryresults <discovery-result-name> -n openshift-local-storage

Comando di esempio

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

Una volta completati questi passaggi, i nuovi volumi persistenti verranno creati automaticamente e pianificati sul nodo bare metal dopo il suo riavvio. Passa alla sezione successiva per aggiornare il nodo di lavoro.

Aggiornare il nodo worker

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Elenca i tuoi nodi di lavoro utilizzando il comando ibmcloud oc worker ls e trova il nodo di lavoro che hai isolato e svuotato nel passo precedente.

	ibmcloud oc worker ls -c CLUSTER

Output di esempio

	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*

Aggiornare il nodo worker. Per i nodi worker bare metal, utilizzare il comando worker reload. Per i nodi worker dell'istanza di server virtuale (VSI), utilizzare il comando worker replace.

Nodi worker in metallo nudo: Utilizzare il comando worker reload per ricaricare il nodo worker. Questo comando è supportato per i worker bare metal di VPC. sh {: pre} ibmcloud oc worker reload --worker kube-*** Nodi worker VSI: Minor update Esempio di comando per sostituire il nodo worker e applicare l'ultimo aggiornamento della patch. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update nodi worker VSI: Worker replace Esempio di comando per sostituire il nodo worker senza applicare l'ultimo aggiornamento della patch. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** Esempio di output per la sostituzione del nodo worker 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

Attendere che il nodo worker venga ricaricato o sostituito e quindi elencare i nodi worker. Tenere presente che questo processo potrebbe richiedere 20 minuti o più.

	oc get nodes

Output di esempio

	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

Ripulisci le risorse dal vecchio nodo

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Verificare che il pod OSD sia stato creato sul nodo sostituito in uno stato running. Se il pod è in funzione, continuare al punto 7. Se il pod si è guastato, eseguire le seguenti operazioni steps.If più di un pod OSD non è Running, fermarsi e contattare l'assistenza. Apri un caso di supporto. Nei dettagli del caso, assicurarsi di includere qualsiasi file di registro, messaggio di errore o output di comando pertinente.
Passare al progetto openshift-storage.
```
	oc project openshift-storage
```
Rimuovere l'OSD non riuscito dal cluster. Se necessario, è possibile specificare più OSD falliti.
```
	oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
Il valore FAILED_osd_id è il numero intero nel nome pod immediatamente dopo il prefisso rook-ceph-osd. Il valore FORCE_OSD_REMOVAL deve essere modificato in true nei cluster che hanno solo tre OSD o nei cluster con spazio insufficiente per ripristinare tutte e tre le repliche dei dati dopo la rimozione di OSD.
Verifica che l'OSD sia stato rimosso correttamente controllando lo stato del pod ocs-osd-removal-job.
```
	oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

Verificare che la rimozione OSD sia stata completata.

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

Output di esempio

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

Aggiungere il nuovo nodo di memoria

Prima di aggiungere nuovi nodi di archiviazione, accertarsi di aver completato i passaggi precedenti per tutti i nodi di archiviazione del cluster.

[Aggiornamento importante] {: tag-red}[ Aggiornamento minore] {: tag-blue} Sostituzione operatore

Se hai limitato la tua distribuzione ODF a un sottoinsieme di nodi di lavoro specificando i nomi dei nodi durante l'installazione, devi aggiornare il CRD ocscluster per includere il nuovo nome.

Se non si è limitata la configurazione solo ad alcuni nodi worker, non è necessario aggiornare il CRD ocscluster.
```
	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
```
Attendi che i pod OpenShift Data Foundation vengano distribuiti al nuovo nodo di lavoro. Verifica che i nuovi volumi persistenti siano stati creati e che tutti i pod siano in uno stato Running.
```
	oc get pv
	oc get ocscluster
	oc get pods -n openshift-storage
```

Verifica che tutti gli altri pod OpenShift Data Foundation richiesti siano in stato In esecuzione.

	oc get pod -n openshift-storage | grep mon

Output di esempio:

	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

Verificare che i nuovi pod OSD siano in esecuzione sul nodo sostitutivo.

	oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd

Aggiorna il componente aggiuntivo OpenShift Data Foundation

Aggiornamento importante

Verificare la versione esistente.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Aggiornare il componente aggiuntivo.

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

Verificare che il componente aggiuntivo sia aggiornato.
```
	ibmcloud oc cluster addon ls --cluster CLUSTER
```

Aggiorna la risorsa cluster

Aggiornamento importante

Ottieni il nome della tua risorsa ocscluster.

	oc get ocscluster

Output di esempio

	NAME             AGE
	ocscluster-vpc   19d

Esegui il seguente comando per modificare la tua risorsa ocscluster.
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

Impostare il parametro ocsUpgrade su 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

Salva e chiudi il file.
Attendere il completamento dell'aggiornamento.

Verificare che le risorse storagecluster e cephcluster siano distribuite correttamente.

	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