In questo articolo facciamo chiarezza su 5 cose da sapere sul funzionamento del Cluster Proxmox VE a Due Nodi.
5 Cose da sapere sul cluster Proxmox VE a Due Nodi
1. Cosa succede se cade un nodo
Partendo sempre dallo schema con il nodo PBS (Proxmox Backup Server), il Nodo A e Nodo B.
Supponendo che uno dei tre nodi venga meno.
Non succede assolutamente nulla a livello di cluster, perché devi pensare al cluster a due nodi come se fosse un cluster a 3 nodi dal punto di vista del quorum.
Ad esempio se il Proxmox Backup Server cade improvvisamente, non succede assolutamente nulla, l’importante è mantenere almeno due nodi live su 3, esattamente come da specifiche Proxmox.
Inoltre, si può migrare agevolmente una macchina virtuale dal Nodo A al Nodo B e dal Nodo B al Nodo A con la modalità live, ovvero senza spegnere la risorsa.
Ad esempio, una VM in running si può migrare live dal Nodo A al Nodo B, indipendentemente dalle repliche che siano schedulato o no.
Se le repliche sono schedulate, quando si segue la migrazione di una macchina virtuale dal Nodo A al Nodo B, il task di replica automaticamente verrà invertito, quindi sarà dal Nodo B al Nodo A.
2. Come determinare la quantità di storage
Facciamo un esempio pratico per capire quanto storage allocare.
Supponiamo di avere 6 macchine virtuali sul Cluster: 3 VM sul Nodo A e 3 VM sul Nodo B, e che ogni macchina virtuale (per semplicità) sia a 100 GB.
Complessivamente sullo storage del Nodo A ci saranno allocati circa 300 GB. Stessa cosa per il nodo B.
Supponendo di schedulare le repliche di tutte le VM, dal Nodo A al Nodo B, e viceversa. Si devono considerare su ogni nodo 300GB per le VM e 300 GB per le repliche.
L’occupazione totale di ogni nodo sarà quindi di 600 GB.
Il file system cercherà di ottimizzare lo spazio, per cui non saranno 600 GB ma sarà un po’ meno. Nelle valutazioni, stiamo un pochettino più larghi per sicurezza, quindi consideriamo 600 GB.
Ovviamente non è obbligatorio avere le repliche di tutte le risorse (VM o CT) dal Nodo A al Nodo B.
Ad esempio, se una delle macchine virtuali sul Nodo A è una macchina con servizi poco importanti e per questo non si vuole replicare sul Nodo B, (il Nodo B potrebbe forse essere considerato come puramente un nodo di backup).
In tal caso non si crea il Task di replica della risorsa, e conseguentemente alle repliche si devono togliere 100GB. Quindi complessivamente sul Nodo B (host destinazione) non ci saranno più 600GB ma ci saranno 500GB occupati.
Dipende quindi da come è imposto il Cluster ed in particolare le repliche: se si vuole che tutto sia ridondato dal Nodo A al Nodo B e viceversa.
Un calcolo spanno-metricamente potrebbe essere considerare sempre il doppio dello storage allocato.
3. Ripristino delle risorse: in quanto tempo si torna operativi
Il tempo impiegato per ripristinare un backup da Proxmox Backup Server verso i nodi dipende dall’hardware utilizzato ed in particolare dagli switch, dalle schede di rete e soprattutto dai tipi di dischi implementati per lo storage del PBS.
Tuttavia, un ordine di grandezza molto spannometrico, può andare dal minuto a 20 minuti.
4. Ripristinare una VM da un attacco ransomware
Per ripristinare una macchina da un attacco ransomware, sarà sufficiente ripristinare una delle versioni disponibili sul PBS ottenute grazie alle schedulazioni impostate sul sistema.
Ad esempio, se un CryptoLocker cifra una macchina virtuale io posso tornare al tempo T-1, andando a selezionare una versione delle versioni precedenti.
Mentre si fa il restore della macchina virtuale con Proxmox Backup Server, si può mandarla in running e in tal modo già controllare se quella versione è compromessa o no, senza aspettare tutto il restore della macchina virtuale .
5. Nessun Single Point Of Failure
Il Cluster Proxmox VE a Due Nodi non ha Single Point of Failure perché è completamente ridondato.
Di default configuriamo schede di rete, dischi e networking in modalità ridondata, ovvero con doppio switch e più schede di rete per ogni servizio.
Anche il Proxmox Backup Server avrà tutti i link ridondati.
Avere un sistema senza Single Point of Failure rappresenta un grande vantaggio per la continuità operativa di un’azienda.
