PGS - Intenție, Probleme și Compromis

Intenție

Scopul inițial a fost simplu: - să se poată salva starea guest-urilor active înainte de lucrări de mentenanță; - să se poată restaura după revenirea nodurilor; - să se evite pornirea guest-urilor care erau deja suspendate sau oprite înainte de operație.

Pentru VM-uri QEMU, asta a însemnat qm suspend --todisk 1. Pentru containere LXC, asta a însemnat pct shutdown, urmat de pct start la restaurare.

Abordarea inițială

Prima variantă a fost automată: - systemd apela suspend la oprirea nodului; - systemd apela resume la revenirea nodului; - un fișier JSON local păstra lista guest-urilor care trebuiau restaurate.

Motivația a fost să existe un flux "hands-off" pentru reboot și shutdown.

Probleme întâmpinate

În practică, abordarea automată a fost fragilă pe un cluster Proxmox real.

Problemele observate: - imagini stale de suspend: - disk image '...state-suspend-....raw' already exists - scrieri eșuate în pmxcfs / /etc/pve: - Permission denied - Device or resource busy - ferestre fără quorum în timpul opririi sau revenirii nodurilor; - VM-uri care porneau, dar rămâneau cu lock: suspended; - restaurări parțiale, cu numai o parte din guest-uri repornite; - comportament dependent de ordinea exactă în care reveneau rețeaua, corosync, storage-ul și pve-cluster.

Problema structurală a fost aceasta: - qm suspend și qm resume nu sunt operații pur locale; - ele au nevoie de scrieri coerente în /etc/pve; - /etc/pve depinde de pmxcfs și de starea clusterului; - în scenarii în care mai multe noduri se opresc sau pornesc în același timp, această dependență devine sursă de curse și inconsistențe.

Am adăugat mai multe remedieri tactice: - cleanup pentru imagini stale; - retry după eșec; - relaxare temporară de quorum cu pvecm expected 1; - curățare automată pentru lock: suspended.

Aceste remedieri au redus unele erori, dar nu au schimbat faptul că modelul automat rămânea nedeterminist în scenarii de mentenanță pe întregul cluster.

Concluzie

Automatizarea la shutdown/boot nu a fost suficient de robustă pentru mediul real.

Mai exact: - pentru reboot de un singur nod, putea funcționa uneori acceptabil; - pentru lucrări în care mai multe noduri sau întregul cluster sunt oprite, rezultatele nu au fost suficient de predictibile.

Problema nu mai era un bug punctual, ci o nepotrivire între design și condițiile reale de operare.

Compromisul ales

A fost aleasă o variantă mai simplă și mai controlabilă: - fără automatizare systemd; - fără hook-uri la shutdown sau boot; - suspendarea se rulează manual înainte de mentenanță; - restaurarea se rulează manual după revenirea clusterului.

Comenzile sunt:

/usr/local/sbin/pgs suspend -v
/usr/local/sbin/pgs resume -v

De ce acest compromis este acceptabil

Se pierde comoditatea automatizării, dar se câștigă: - control explicit asupra momentului execuției; - posibilitatea de a aștepta revenirea clusterului înainte de resume; - debug mai simplu; - mai puține efecte surprinzătoare în timpul shutdown-ului; - separare clară între pregătirea mentenanței și restaurarea ulterioară.

Practic, operatorul decide când clusterul este suficient de stabil pentru restaurare, în loc să lase asta pe seama ordinii de pornire a serviciilor.

Ce rămâne intenționat în cod

Deși automatizarea a fost eliminată, scriptul păstrează unele protecții utile: - detecție și cleanup pentru imagini stale de suspend; - tratament pentru guest-uri deja pornite sau deja suspendate; - cleanup pentru lock: suspended când este posibil; - jurnalizare clară în journalctl -t pgs.

Acestea rămân utile și în fluxul manual.

Ce nu mai face proiectul

Proiectul nu mai încearcă: - să orchestreze reboot-ul nodurilor; - să decidă automat momentul corect pentru restore; - să garanteze restaurare automată după revenirea clusterului.

Acesta este acum un utilitar manual de guest state, nu un manager de reboot.