In questo articolo esploreremo le maggiori differenza tra un cluster iperconvergente Proxmox a 3 nodi e un cluster Proxmox a 2 nodi con modalità Replica.

1. I concetti dei cluster a 2 e 3 nodi

È importante fin da subito comprendere che il cluster a 3 nodi è un sistema iperconvergente, mentre il cluster a 2 nodi utilizza le repliche per implementare l’alta affidabilità.

In realtà il cluster a 2 nodi è comunque composto da 3 nodi, dove il terzo nodo è rappresentato dal PBS. La trattazione del PBS non è argomento di questo articolo, dunque verrà completamente ignorato da qui in poi.

Approfondisci i concetti con le nostre guide e video, le funzionalità del cluster Proxmox VE a 2 nodi, e la creazione di un cluster Iperconvergente Proxmox VE a 3 nodi.

Andiamo a vedere complessivamente quale è la differenza tra Ceph e le repliche gestite da ZFS.

Partiamo da una semplice schermata per chiarire meglio i concetti. Disegniamo un cluster a 3 nodi, chiamandoli A, B e C.

Poi disegniamo uno cluster a 2 nodi, ovvero A e B, e poi colleghiamoli con uno switch. Lo schema dei due sistemi risultanti è visibile nello schema seguente:

2. Come vengono gestiti i cluster a 2 e 3 nodi

Un cluster iperconvergente Proxmox VE a 3 nodi, lo storage viene gestito con il framework Ceph, mentre Il cluster a 2 nodi viene gestito con ZFS.

Nel caso del Cluster iperconvergente Proxmox VE a 3 nodi, una macchina virtuale in running sul nodo A, si trova nella condizione in cui viene replicati in “Real time” sul nodo B e sul nodo C.

Nel cluster a 2 nodi, una macchina virtuale in running sul nodo A, si trova nella condizione in cui viene replicata sul nodo B e viceversa, attraverso una task di replica in un intervallo di tempo che abbiamo definito delta T deciso in base alle nostre necessità.

Di seguito riportiamo uno schema che aiuta la comprensione delle differenze.

Si parla di “iperconvergenza” del cluster Proxmox VE a 3 nodi gestito con Ceph, perché i dati vengono replicati “real time” su tutti i nodi.

Ciò significa che ogni nodo Proxmox vedrà un unico storage.

Sul cluster a 2 nodi ZFS, non possiamo parlare di iperconvergenza perché i dati vengono spostati attraverso una task di replica asincrono.

3. La live migration

In entrambi i casi possiamo usufruire della funzione di “live migration”, che offre la possibilità di spostare una macchina virtuale da un nodo all’altro, senza preoccuparsi d dove sono effettivamente i dati.

Si può spostare una macchina virtuale dal nodo A al nodo B di un cluster a 2 nodi ZFS perché Proxmox VE supporta la “live migration”.

Se esiste già un task di replica configurato dal nodo A al nodo B, nel momento della live migration, Proxmox VE si occuperà di spostare gli ultimi dati in modo incrementale.

Ovviamente, anche su cluster iperconvergente si può fare la live migration. Inoltre, avendo i dati sincronizzati real time, la macchina virtuale può spostarsi più velocemente senza eseguire le sincronizzazioni incrementali come nel caso del cluster a 2 nodi.

4. Consigli per il networking

Nel caso di un sistema iperconvergente, il networking sarà sicuramente più impegnativo dal punto di vista prestazionale.

Ceph, ha bisogno di alte performance, pertanto è consigliabile una configurazione che parte da 10GB in su. Meglio se 25GB, 40GB, oppure 100GB.

Per la gestione di un cluster a 2 nodi sarà sufficiente una connessione a 10GB o 25GB per avere ottime performances.

, rimandiamo alle guide e video che trattano questo specifico argomento

(link alle guide ad ai video)

5. l’Alta affidabilità

Un cluster iperconvergente che utilizza Ceph ha un minino di nodi pari a 3. Questo fattore garantisce l’alta affidabilità.

Nel caso del cluster gestito con ZFS, il numero minimo numero di nodi è 2, anche se il quorum si raggiungerà solo con 3 nodi, per questo è necessario dotare il nostro cluster di un PBS (o un terzo nodo).

In entrambi i casi, l’alta affidabilità di Proxmox VE è garantita. Si può configurare l’alta affidabilità sul panello di Proxmox VE sia per il cluster a 3 nodi, sia per il cluster a 2 nodi.

L’alta affidabilità è il sistema mediante il quale Proxmox VE può migrare le macchine virtuali in caso di fault di un nodo.

In un cluster a 2 nodi ZFS, dobbiamo considerare i task di replica da un nodo all’altro. Come detto prima ci sarà una differenza di dati derivante dal tempo che passa tra una sincronizzazione e l’altra.

Nel caso peggiore, in caso di fault di un nodo, si potrà perdere una quantità di dati prodotta nell’arco di un tempo delta T. Pertanto, si devono considerare anche i parametri di RPO (Recovery Point Objective) e RTO (Recovery Point Objective) che l’azienda può sostenere.

Nel caso del cluster iperconvergente Proxmox VE a 3 Nodi, non è necessario preoccuparsi molto perché i dati sono sincronizzati in real time su tutti i nodi.