Ce garantează modurile vzdump din Proxmox

Proxmox oferă trei moduri de copiere de siguranță într-o singură listă derulantă, ceea ce le face să pară trei viteze ale aceluiași lucru. Nu sunt. Ele diferă prin ce se întâmplă cu invitatul care rulează și, prin urmare, prin ceea ce copiază de fapt arhiva.

Versiunea scurtă, apoi cea lungă:

Cuvântul care face toată treaba în acel tabel este crash-consistent. Înseamnă că arhiva arată cum ar fi arătat discul dacă cineva ar fi smuls cablul de alimentare în acea clipă. Un sistem de fișiere cu jurnal își revine din asta. O bază de date care avea o tranzacție în curs s-ar putea să nu își revină, iar o aplicație care își ține starea în două fișiere nu va ști că unul dintre ele este mai vechi decât celălalt.

snapshot nu înseamnă sistem de fișiere înghețat

snapshot este modul implicit și este singurul care nu întrerupe nimic. Proxmox face un instantaneu la nivel de stocare și citește copia de siguranță din acesta, așa că invitatul scrie în volumul viu tot timpul.

Există o cale de a face acea arhivă mai bună: agentul QEMU din invitat poate îngheța sistemul de fișiere pentru clipa în care se ia instantaneul, ceea ce golește scrierile în așteptare și vă dă o arhivă pe care invitatul însuși o consideră curată. Dacă agentul este instalat, rulează și răspunde, asta se întâmplă.

Capcana stă în acel „dacă”. Nimic din rezultatul API-ului nu vă spune dacă înghețarea a avut loc. Sarcina vzdump întoarce un ID de sarcină și, la final, o stare. Dacă qemu-guest-agent a răspuns cererii de înghețare este o linie în jurnalul sarcinii, nu un câmp pe care să îl citiți înapoi.

Acesta este un punct de decizie pentru oricine automatizează deasupra și merită tratat deliberat. Când am construit calea de copiere de siguranță pentru integrarea noastră Proxmox, am ajuns să consemnăm consistența ca fiind ceea ce s-a întâmplat, niciodată ceea ce s-a cerut: o copie stop este consemnată drept consistentă, iar snapshot și suspend sunt amândouă consemnate drept crash-consistent, punct. Există o valoare pentru „invitatul a fost înghețat” în schema noastră, iar agentul nu o emite niciodată, pentru că a o emite ar însemna să pretindem că știm despre o înghețare pe care nu o putem verifica din API.

O arhivă descrisă ca fiind puțin mai proastă decât este nu vă costă nimic. O arhivă descrisă ca fiind mai bună decât este vă costă exact restaurarea care contează.

suspend pune invitatul în pauză, fără cale de mijloc

suspend sună mai bine decât se poartă. Lumea presupune că este „snapshot, dar mai sigur”, un compromis între zero timp de nefuncționare și oprire completă. Ce face de fapt este să pună invitatul în pauză cât timp se citesc datele.

Vă dă aceeași garanție de crash-consistency ca snapshot, pentru că a pune o mașină în pauză nu este același lucru cu a o lăsa să golească ce are în așteptare și să se așeze. Primiți o întrerupere și nicio promisiune mai puternică. Motivul de a-l folosi este îngust: un backend de stocare care nu poate face deloc instantanee, unde modul snapshot nu are din ce să facă instantaneul.

stop este singura garanție sinceră

stop oprește invitatul, îl salvează și îl pornește din nou. Este cea mai lungă întrerupere și singurul mod în care arhiva este fără echivoc copia unui sistem de fișiere în care nu scria nimeni.

Pentru un server de baze de date pe care cineva îl va restaura sub presiune la trei dimineața, acesta nu este un preț mare. Pentru o flotă de servere web este un preț pe care nimeni nu îl va plăti în fiecare noapte. Amândouă sunt răspunsuri corecte la întrebări diferite, motiv pentru care modul aparține politicii și nu unei singure setări globale.

Un detaliu de implementare contează aici. Pentru că stop și suspend întrerup amândouă o mașină care rulează, o valoare de mod lipsă sau nerecunoscută nu trebuie să cadă niciodată pe unul dintre ele. În schema noastră de comenzi, modul călătorește ca fiind cuvântul Proxmox literal (snapshot, suspend, stop) și nu un vocabular propriu, iar o valoare nesetată se rezolvă la snapshot. Un tabel de traducere între cuvintele noastre și ale lor ar pune o traducere greșită exact acolo unde o traducere greșită oprește mașina unui client.

Parametrii care decid dacă sarcina pornește

Înaintea consistenței vine o întrebare mai plictisitoare: va porni vzdump măcar. Patru lucruri din cerere decid asta, iar trei dintre ele eșuează în feluri greu de citit.

Stocarea de destinație trebuie să accepte copii de siguranță. Stocarea din Proxmox are o listă content, iar doar o stocare a cărei listă include backup poate primi un vzdump. Nu este o recomandare. Trimiteți sarcina către o stocare care ține doar imagini de disc și Proxmox o refuză cu un mesaj de forma storage 'x' does not support vzdump backups. Exact, și fără sens pentru clientul care a apăsat butonul. Merită verificat înainte de a trimite, ca refuzul să poată spune în schimb „această stocare nu acceptă copii de siguranță”.

Un caz înrudit: o stocare care apare în lista de resurse a clusterului cu starea unknown este configurată, dar nu răspunde. O partajare NFS căzută arată exact ca o destinație validă, până în clipa în care sarcina eșuează.

Compresia are o valoare care nu este cuvântul la care vă așteptați.

Proxmox scrie „fără compresie” ca 0, nu ca none. Trimiterea lui none este genul de greșeală care produce un refuz tăcut în loc de unul clar și este motivul pentru care suita noastră de teste verifică șirul exact care pleacă de la agent, nu doar faptul că apelul a reușit.

Notificarea prin e-mail este implicit zgomotoasă și către persoana greșită. Fără un mailnotification=failure explicit, Proxmox trimite un e-mail către root@pam după fiecare copie de siguranță. Pe o mașină administrată dintr-o platformă, acela este un e-mail către furnizor despre ceva ce a făcut clientul.

Două câmpuri opționale merită cunoscute. notes-template atașează o notă arhivei, iar Proxmox extinde în interiorul ei propriii lui substituenți, precum {{guestname}}. protected=1 marchează o arhivă ca protejată, iar Proxmox va refuza apoi să o curețe. Acesta este mecanismul pe care îl vreți pentru copia pe care cineva o face înaintea unei schimbări riscante și exact valoarea implicită greșită pentru o sarcină de noapte.

Retenția nu este un parametru vzdump

Nu există o setare de retenție pe cererea de copiere. Curățarea se configurează pe stocare, în Proxmox, iar proprietarul stocării decide cât trăiesc copiile.

Asta are o consecință de proiectare pentru oricine construiește deasupra: un panou care oferă un câmp „păstrează 7 copii” fie intră în configurația stocării, fie șterge singur arhivele. Noi nu am ales niciuna dintre variante și o spunem, în loc să sugerăm altceva cu un câmp care nu face nimic.

Expirarea timpului nu este același lucru cu eșecul

Un vzdump al unei mașini mari poate trăi mai mult decât orice timeout rezonabil de cerere. Când se întâmplă, lucrul important de înțeles este că nu s-a anulat nimic: sarcina rulează mai departe pe hipervizor și se va termina sau va eșua după propriul ei program.

Așadar, un timeout este o afirmație despre conexiunea dumneavoastră, nu despre copia de siguranță. Rularea rămâne deschisă, ID-ul sarcinii este în continuare valid, iar lucrul cinstit pentru o interfață este să spună „încă rulează” și să reconcilieze mai târziu. Alternativa, adică marcarea ei ca eșuată și lăsarea cuiva să pornească o a doua, pune două sarcini vzdump pe aceeași stocare pentru aceeași mașină.

Cât rulează, progresul real este disponibil: vzdump scrie în jurnalul sarcinii linii precum 12% (1.2 GiB of 10.0 GiB). O bară de progres alimentată de acolo este sinceră. O bară de progres alimentată de o estimare este o presupunere cu un semn de procent pe ea.

La restaurare, unique este cel de nimerit

Întrebarea despre mod se termină când arhiva există. Restaurarea are propria capcană, iar ea ține de rețea.

Restaurați o arhivă într-o mașină nouă fără să cereți identificatori noi și mașina nouă moștenește adresele MAC ale originalului. Dacă originalul încă rulează, aveți acum două mașini cu același MAC pe aceeași punte, iar simptomul nu este „restaurarea a eșuat”, ci „rețeaua mașinii de producție s-a purtat ciudat”. Indicatorul unique din apelul de restaurare este cel care previne asta, iar pe o platformă care restaurează alături de un original care rulează nu este o opțiune, ci o precondiție.

Încă două lucruri merită știute înaintea primei restaurări:

• storage înseamnă altceva aici. La copiere este locul unde ajunge arhiva și are nevoie de backup în lista sa de conținut. La restaurare este locul unde aterizează discurile restaurate și are nevoie de images. Același nume de câmp, altă cerință.
• Se întorc doar discurile. O mașină restaurată este o mașină cu discuri și componente din arhivă. Atribuirile de adrese, regulile de firewall și orice automatizare atașată originalului trăiesc în propriile dumneavoastră sisteme, nu în fișierul vzdump, și nu călătoresc cu el.

Ce nu este măsurat aici

Tot ce este mai sus despre forma apelurilor vine din schema API-ului Proxmox și din construirea față de ea; semantica modurilor este a Proxmox și este descrisă în documentația sa.

Ce nu afirmăm în mod deliberat este cât costă fiecare mod ca durată. Nu avem o durată de pauză măsurată pentru suspend și niciun timp de nefuncționare măsurat pentru stop: asta depinde de invitat, de stocare și de cantitatea de memorie modificată, iar un număr măsurat pe o singură mașină ar fi citat ca fiind unul general. Acelea trebuie să vină din propriul dumneavoastră hardware.

Încă două goluri merită numite. Tot ce este aici privește invitații QEMU; copiile de siguranță ale containerelor au propriile reguli legate de punctele de montare și de montările bind, iar noi nu le-am măsurat. Și nu există nicio cale incrementală în nimic din toate acestea: un vzdump către o stocare obișnuită scrie de fiecare dată o arhivă completă. Copierea incrementală este scopul pentru care există Proxmox Backup Server, iar acela este alt software, cu alt set de promisiuni.

Aceasta a rezultat din construirea căii de copiere de siguranță Proxmox pentru Provibr, un panou de administrare a serverelor pentru furnizorii de găzduire, unde o copie descrisă ca fiind mai bună decât este ar fi cea mai gravă eroare posibilă. Notele de configurare pentru partea de hipervizor sunt în documentația Proxmox, iar pagina integrării Proxmox acoperă ce poate face agentul.