PowerFlex 4.X: Come eseguire un riavvio normale sulle VM di gestione MVM PFMP

Il riavvio delle VM MVM può risolvere alcuni problemi di pod, errori di deployment e altri errori

I comandi di questa procedura vengono eseguiti da una shell bash root. Per eseguire il mirroring della procedura riportata di seguito, accedere agli MVM utilizzando delladmin quindi esegui sudo -s per passare a una nuova shell root.

Esempio:

delladmin@pfmp-mvm03:~> whoami
delladmin
delladmin@pfmp-mvm03:~> sudo -s
pfmp-mvm03:/home/delladmin # whoami
root

1. Elencare tutte le istanze del database Postgres e identificare il nome pod con il ruolo Leader; il nodo leader deve essere l'ultimo nodo da svuotare e riavviare:  

1. 1. PFMP 4.6 

kubectl exec -n powerflex -c database $(kubectl get pods -n powerflex -l='postgres-operator.crunchydata.com/role=master, postgres-operator.crunchydata.com/instance-set' | grep Running | cut -d' ' -f1) -- sh -c 'patronictl list'

Eseguire il seguente comando per identificare quale MVM esegue il Pod Leader Postgres . Questo è l'ultimo nodo da svuotare e riavviare:

for x in `kubectl get pods -n powerflex | grep "postgres-ha-cmo" |awk '{print $1}'` ; do echo $x; kubectl get pods -n powerflex $x -o json | grep '"nodeName"' | cut -d ':' -f2 ; echo " "; done

1. 2. PFMP 4.8 

kubectl exec -it -n powerflex $(kubectl get pods -n powerflex | grep postgres-monitor | awk '{print $1'}) -- kubectl cnpg status postgres-ha-cnpg

Esempio di output 

delladmin@node2:~> kubectl exec -it -n powerflex $(kubectl get pods -n powerflex | grep postgres-monitor | awk '{print $1'}) -- kubectl cnpg status postgres-ha-cnpg
Cluster Summary
Name                 powerflex/postgres-ha-cnpg
System ID:           7570829541331841052
PostgreSQL Image:    dockerrepo:30500/cnpg/cnpg-postgres:14.18-22-53.6b63004-22-9.0
Primary instance:    postgres-ha-cnpg-1
Primary start time:  2025-11-09 22:33:09 +0000 UTC (uptime 3803h6m21s)
Status:              Cluster in healthy state
Instances:           3
Ready instances:     3
Size:                11G
Current Write LSN:   B/6211B568 (Timeline: 3 - WAL File: 000000030000000B00000062)

Continuous Backup status
Not configured

Streaming Replication status
Replication Slots Enabled
Name                Sent LSN    Write LSN   Flush LSN   Replay LSN  Write Lag        Flush Lag        Replay Lag       State      Sync State  Sync Priority  Replication Slot
----                --------    ---------   ---------   ----------  ---------        ---------        ----------       -----      ----------  -------------  ----------------
postgres-ha-cnpg-2  B/6211B568  B/6211B568  B/6211B568  B/6211B568  00:00:00.000365  00:00:00.001507  00:00:00.001618  streaming  async       0              active
postgres-ha-cnpg-3  B/6211B568  B/6211B568  B/6211B568  B/6211B568  00:00:00.000321  00:00:00.001511  00:00:00.001575  streaming  async       0              active

Instances status
Name                Current LSN  Replication role  Status  QoS        Manager Version  Node
----                -----------  ----------------  ------  ---        ---------------  ----
postgres-ha-cnpg-1  B/6211B568   Primary           OK      Burstable  1.26.1           pfmp-mvm01
postgres-ha-cnpg-2  B/6211B568   Standby (async)   OK      Burstable  1.26.1           pfmp-mvm02
postgres-ha-cnpg-3  B/6211B568   Standby (async)   OK      Burstable  1.26.1           pfmp-mvm03

2. Aprire un terminale sull MVM3 (uno dei nodi non leader). Eseguire il seguente comando:

kubectl get nodes

3. Etichettare MVM3 per la manutenzione:

kubectl label node pfmp-mvm03 cmo.maintenance.mode=true

4. Svuotare il nodo MVM03 in cui i pod in esecuzione vengono rimossi gradualmente dal nodo. I pod pianificano ed eseguono su un nodo diverso. Al termine del processo di svuotamento, il nodo si riavvia. Attendere che il nodo venga riattivato.

5. Eseguire il seguente comando per svuotare il nodo:

kubectl drain pfmp-mvm03 --ignore-daemonsets --delete-emptydir-data

6. Una volta svuotato il nodo, riavviarlo:

sudo reboot

7. Connettersi tramite SSH a MVM02 ed eseguire il comando seguente per monitorare il nodo riavviato e raggiungere lo STATO Ready:

watch kubectl get nodes

8. Una volta che MVM03 riporta uno STATO pronto, connettersi con SSH a MVM03 ed eseguire il seguente comando per annullare e rimuovere l'etichetta di manutenzione .

kubectl uncordon pfmp-mvm03 ; kubectl label node pfmp-mvm03 cmo.maintenance.mode-

9. Attendere da 5 a 20 minuti, quindi eseguire il comando nel passaggio 1 per visualizzare lo stato del cluster del database. È possibile ripetere i passaggi per l'MVM successivo una volta che l'output corrisponde all'esempio di database integro riportato di seguito. 
10. Ripetere i passaggi da 3 a 8 su MVM02, quindi su MVM01. 

Dopo aver completato la procedura su tutti e tre gli MVM, eseguire il comando nel passaggio 1 per verificare lo stato del database postgres . Un pod dovrebbe essere il leader e in uno stato di esecuzione. Dovrebbe esserci un ritardo di 0 MB ed entrambi i membri dello standby di sincronizzazione dovrebbero avere uno stato di streaming.

Esempio di database integro PFMP 4.6:

+ Cluster: postgres-ha-ha +------------------------------------------+--------------+-----------+----+-----------+
| Member                  | Host                                     | Role         | State     | TL | Lag in MB |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+
| postgres-ha-cmo1-8t2v-0 | postgres-ha-cmo1-8t2v-0.postgres-ha-pods | Leader       | running   | 10 |           |
| postgres-ha-cmo1-h4hx-0 | postgres-ha-cmo1-h4hx-0.postgres-ha-pods | Sync Standby | streaming | 10 |         0 |
| postgres-ha-cmo1-pb88-0 | postgres-ha-cmo1-pb88-0.postgres-ha-pods | Sync Standby | streaming | 10 |         0 |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+