PowerFlex 4.X : Comment effectuer un redémarrage normal sur les machines virtuelles de gestion PFMP MVM

Le redémarrage des machines virtuelles MVM peut résoudre certains problèmes de Pod, d’échecs de déploiement et d’autres erreurs

Les commandes de cette procédure sont exécutées à partir d’un shell bash racine. Pour mettre en miroir les étapes ci-dessous, connectez-vous aux MVM à l’aide de delladmin puis exécutez sudo -s pour passer à un nouveau shell racine.

Exemple:

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

1. Répertoriez toutes les instances de base de données Postgres et identifiez le nom du pod avec le rôle Leader. Le nœud leader doit être le dernier nœud à être vidé et redémarré :  

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'

Exécutez la commande suivante pour identifier le MVM qui exécute le pod leader Postgres . Il s’agit du dernier nœud à être vidangé et redémarré :

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

Exemple de résultat 

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. Ouvrez un terminal sur le MVM3 (l’un des nœuds non leaders). Exécutez la commande suivante :

kubectl get nodes

3. Étiquette MVM3 pour maintenance :

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

4. Vidangez le nœud MVM03 où les pods en cours d’exécution sont correctement supprimés du nœud. Les pods planifient et s’exécutent sur un autre nœud. Une fois le processus de purge terminé, le nœud redémarre. Attendez que le nœud revienne.

5. Exécutez la commande suivante pour vider le nœud :

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

6. Une fois le nœud déchargé, redémarrez-le :

sudo reboot

7. Établissez une connexion SSH avec MVM02 et exécutez la commande suivante pour surveiller le nœud que vous avez redémarré et atteindre l’ÉTAT Ready :

watch kubectl get nodes

8. Une fois que MVM03 signale un état Ready, établissez une connexion SSH avec MVM03 et exécutez la commande suivante pour débrancher et retirer l’étiquette de maintenance .

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

9. Patientez 5 à 20 minutes, puis exécutez la commande à l’étape 1 pour afficher l’intégrité du cluster de base de données. Vous pouvez répéter les étapes pour le MVM suivant une fois que le résultat correspond à l’exemple de base de données saine ci-dessous. 
10. Répétez les étapes 3 à 8 sur MVM02, puis MVM01. 

Lorsque vous avez terminé la procédure sur les trois MVM, exécutez la commande à l’étape 1 pour vérifier l’intégrité de la base de données postgres . Un pod doit être leader et en état d’exécution. Il doit y avoir un décalage de 0 Mo et les deux membres de secours de synchronisation doivent avoir un état de streaming.

Exemple de base de données saine 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 |
+-------------------------+------------------------------------------+--------------+-----------+----+-----------+