In questo articolo ti mostriamo come creare un Cluster Proxmox a 3 nodi illustrando il funzionamento dell’HA (Hight Avaibility) delle VM (Virtual Machine) mediante la configurazione avanzata di Ceph.

Contenuti dell’articolo Cluster Proxmox:

  1. Software e hardware utilizzati e risorse per ogni VM (nodo)
  2. Introduzione del Custer Proxmox
  3. Ceph: primi passi
  4. Ceph: il cluster
  5. Configurazione Network
  6. Configurazione del Monitoring
  7. Configurazione OSD
  8. Creazione del Ceph Pool
  9. Creazionne degli storage

Abbiamo realizzato un laboratorio finalizzato a visionare le possibili configurazioni di Ceph, composto da 3 macchine virtuali Proxmox VE già configurate in cluster con Ceph. NON’E’ adatto ad ambienti di produzione, in quanto si tratta della virtualizzazione di un ambiente virtuale, tuttavia rappresenta una soluzione versatile per scopi di test.

1. Software utilizzato per il Cluster Proxmox

  • Proxmox VE 6.1-8
  • Ceph versione 14-2.6 (stable)

Hardware utilizzato per il Cluster Proxmox

Per la creazione di un ambiente di produzione, si raccomanda l’utilizzo 3 Virtual Appliance A3 Server Aluminum, che possono essere acquistata già configurati e pronti all’uso.

Il server è equipaggiato con:

  • 2 dischi SSD da 2 TB.
  • 1 disco SATA da 10 TB
  • RAM: 128 GB
  • numero CPU: 16Sistema Operativo: Proxmox 6.1-8

Risorse per ogni VM (nodo)

  • nome: miniserver-pve1
  • spazio disco: 64 GB per S.O.
  • RAM: 16 GB
  • numero CPU: 4

2. Introduzione

Leggi come creare il Cluster Proxmox a 3 nodi con Ceph

D’ora in poi daremo per scontato che il cluster Proxmox composto da 3 nodi sia funzionante e configurato e funzionante.

3. Ceph: primi passi

Ceph è un file system distribuito che è stato progettato per migliorare ed aumentare scalabilità e affidabilità in ambienti server cluster.
Ceph permette di eseguire l’archiviazione dei dati (nel nostro caso i dischi delle VM) direttamente sul nodo dell’hypervisor, permettendo la replica su altri nodi del cluster, evitando l’utilizzo di una SAN.

La configurazione di Ceph su ogni nodo del nostro cluster è stata fatta nel seguente modo:

  • un Pool Ceph su dischi SSD
  • un Pool Ceph su dischi HDD
  • configurazione di una Public Network
  • configurazione di una Cluster Network

Vedremo dopo più nel dettaglio queste configurazioni. Ovviamente essendo un cluster virtuale creato con 3 macchine virtuali, il Pool Ceph con dischi SSD è simulato (vedremo di seguito).

4. Ceph: il cluster

Nella fig. di seguito è rappresentata un’immagine del cluster chiamato Miniserver, costituito da 3 nodi:

  • miniserver-pve1
  • miniserver-pve2
  • miniserver-pve3

il Laboratorio è raggiungibile su uno di questi 3 indirizzi (essendo un Cluster è indifferente quale).

  • 192.168.131.150:8006
  • 192.168.131.151:8006
  • 192.168.131.152:8006

Proxmox Cluster Ceph

5. Configurazione Network

Al fine di garantire un l’alta affidabilità e quindi sfruttare al massimo le caratteristiche di Ceph, come già anticipato, abbiamo deciso di separare la Cluster Network e la Public Network.

Public network: è la rete dedicata alla gestione del monitoring di Ceph, ovvero tutti i dati e controlli che servono ai nodi per capire in che “stato” si trovano.

Cluster network: è la rete dedicata alla gestione degli OSD e al traffico heartbeat, ovvero è la rete che si occupa di sincronizzare tutti i “dati” dei dischi virtuali delle VM.

Tuttavia, non è obbligatorio separare il traffico in due reti ma fortemente consigliato in produzione dove le grandezze del cluster iniziano ad essere considerevoli.

Esistono due motivazioni principali per usare due reti separate:

  1. Prestazioni: quando i demoni OSD Ceph gestiscono le repliche dei dati sul cluster, il traffico di rete può introdurre latenza al traffico dei Ceph client creando anche un possibile disservizio.Inoltre anche il traffico per il monitoring sarebbe rallentato impedendo una visione veritiera dello stato del cluster. Ricordiamo che il recupero e il riequilibrio del cluster, in caso di guasto, deve essere fatto nel minore tempo possibile, ovvero i PG (Placement Group) devono essere spostati dagli OSD in modo rapido per recuperare una situazione critica.
  2. Sicurezza: un attacco DoS (Denial of Service) potrebbe saturare le risorse di rete per la gestione delle repliche e questo comporterebbe anche ad un rallentamento (o addirittura un completo arresto) del traffico di monitoring.Ricordiamo che i Ceph monitor permettono ai Client Ceph di leggere e scrivere i dati sul cluster: possiamo immaginare dunque cosa potrebbe succedere a fronte di una congestione della rete usata per il Monitoring. Separando le due reti invece, il traffico di monitoring non verrebbe minimamente congestionato.

Si consiglia fortemente, per ragioni di sicurezze ed efficienza, di non collegare a Internet la Cluster Network e la Public network: mantenendole quindi “nascoste” dall’esterno e separate da tutte le altre reti.

Nelle immagini di seguito viene riportata la configurazione delle schede di rete per le 3 macchine virtuali, ovvero i 3 nodi del cluster.
Per visualizzare la configurazione andare sul nodo desiderato, poi cliccare sul pulsante network.

Proxmox Cluster Ceph

Proxmox Cluster Ceph

Proxmox Cluster Ceph

Come si osserva nelle 3 figure precedenti, la LAN 192.168.131.0/24 è utilizzata come rete per gli Host e le macchine virtuali, mentre la subnet 192.168.20.0/24 e la 192.168.30.0/24 sono state utilizzate per la Public Network e per la Cluster Network rispettivamente.

6. Configurazione del Monitoring

Selezionando uno dei nodi del cluster, poi Ceph, Monitor, si arriva al menù dove sarà possibile creare più Monitor e Manager.
Come già anticipato, il monitoring è fondamentale per poter capire lo stato del cluster. In particolare i Ceph Monitor mantengono una mappa del cluster ed in base a quest’ultima i Ceph client possono scrivere o leggere su un determinato spazio di archiviazione del cluster.

È facile dunque capire che avere un solo Ceph Monitor non è una soluzione sicura da implementare. Occorre quindi configurare un cluster di monitor per garantire l’alta affidabilità anche del monitoring. Sarà sufficiente cliccare su create ed aggiungere i monitor desiderati.

Nell’immagine di seguito viene mostrato come il Ceph Monitor cluster sia implementato: Vediamo che tutte e tre i monitor sono sulla rete 192.168.20.0/24, ovvero sulla Public Network

Proxmox Cluster Ceph

7. Configurazione OSD

L’elemento OSD (Object Storage Daemon) è uno layer software che si preoccupa di storicizzare i dati, gestire le repliche, il recovery e il rebalancing dei dati. Inoltre fornisce tutte le informazioni ai Ceph Monitor e Ceph Manager.

E’ consigliabile associare un OSD per ogni disco (ssd o hdd): in questo modo un singolo OSD gestirà solo il disco associato. Per creare gli OSD cliccare su uno dei nodi del Cluster, poi Ceph, poi OSD. Vediamo nell’immagine successiva, come sono stati creati gli OSD.

Proxmox Cluster Ceph

Su ogni host sono presenti tre dischi dedicati a Ceph, di cui:

  • HDD da 200 GB
  • HDD da 200 GB
  • SSD da 200 GB

Per ragioni di “spazio” nell’ambiente di test sono in realtà 5 GB cadauno.

Su ogni disco quindi sono stati allocati i rispettivi OSD.
Nell’immagine precedente notiamo infatti che ci sono 3 OSD allocati su 3 SSD e 6 OSD allocati su 6 HDD rispettivamente (guardare la colonna “Class”).

8. Creazione dei Ceph Pool

Quando si crea un Pool dall’interfaccia di Proxmox, di default si può solamente utilizzare la regola CRUSH chiamata replicated_rule. Selezionando questa regola, le repliche dei dati, all’interno di quel pool, verranno distribuite sia sui dischi SSD che sugli HDD.

Il nostro obiettivo invece è quello di creare 2 Pool:

  • un primo pool costituito da soli SSD
  • un secondo pool costituito da soli HDD

Per fare questo però occorre creare prima due regole CRUSH diverse rispetto a quella di default.
Purtroppo è un’operazione che non si può gestire dalla GUI di Proxmox, ma lo si può fare lanciando questi due comandi su uno dei tre host del cluster (non importa quale):

Copy

 

Copy

 

Per accedere al menù di creazione del pool cliccare su uno dei nodi, poi Ceph, poi Pools.

 

Nell’immagine seguente notiamo che ora possiamo selezionare le regole CRASH da noi create precedentemente.

 

Proxmox Cluster Ceph

 

Di default, un pool viene creato con 128 PG (Placement Group). Questo è un numero che può variare ma dipende da alcuni fattori. Vedremo più avanti come settarlo in base ai criteri di Ceph.

 

Gli oggetti del File System RDB vengono posizionati all’interno dei PG, i quali sono collezionati all’interno di un Pool. Vedremo dopo la creazione dello storage di tipo RDB.

 

Come evidenziato nella figura di seguito, Il Pool è di fatto un raggruppamento logico dei PG. Infatti i PG vengono fisicamente distribuiti tra i dischi gestiti dagli OSD.

 

Proxmox Cluster Ceph

 

Ricordiamo che esiste un solo OSD per ogni disco dedicato a Ceph (vedi figura 12 precedente).

 

Selezionando il campo Size = 3, si sta specificando che ogni PG dovranno essere replicati 3 volte nel cluster.

 

Questo è un valore da tenere in considerazione quando dobbiamo stimare la dimensione dei dischi (vediamo dopo nel dettaglio) durante il dimensionamento del cluster.

 

Ricordarsi di non selezionare Add as Storage, in quanto lo storage di Proxmox dedicato a Ceph lo andremo ad inserire manualmente.

 

Una volta creati i due poll Ceph avremo la seguente situazione:

 

Proxmox Cluster Ceph

 

9. Creazione degli storage per il Proxmox Cluster

 

Ora siamo pronti per creare i due storage che ospiteranno le nostre macchine virtuali. Andiamo su Datacenter, Sotorage, selezionare RBD, ovvero lo Storage a Blocchi che utilizza Ceph.

 

Vediamo nella figura di seguito che per lo storage “ceph_storage_hdd” selezioniamo il “ceph_pool_hdd” creato precedentemente. Stessa cosa faremo per lo storage di soli SSD “ceph_storage_ssd”.

 

 

Abbiamo quindi creato i due storage

 

  • ceph_storage_hdd
  • ceph_storage_ssd

 

Ora andiamo a calcolare quanto spazio ho a disposizione per ciascun storage.

 

  • 6 dischi HDD da 200 GB = 1.2 TB

 

Considerando che devo garantire 3 repliche (campo Size, figura 13), avrò: ceph_storage_hdd = 1.2 TB / 3 ⋍ 400 GB

 

  • 3 dischi SSD da 200 GB = 600 GB

 

Considerando che devo garantire 2 repliche (campo Size, figura 13), avrò: ceph_storage_ssd = 600 GB / 2 ⋍ 300 GB

 

Andiamo a verificare quanto calcolato, selezionando dalla GUI di Proxmox gli storage. Vediamo nelle due figure di seguito, le dimensioni effettive degli storage.

 

Proxmox Cluster Ceph

 

Vediamo che le dimensioni effettive sono 377.86 GB e 283.49 GB, molto simili a quelle che abbiamo calcolato in modo approssimativo precedentemente.

 

Il numero di PG per ogni Pool è stimabile in base alla formula che mette a disposizione Ceph sul sito ufficiale.

 

Vediamo nell’immagine seguente (fig.19) come abbiamo impostato l’interfaccia di Ceph.

 

Proxmox Cluster Ceph

 

Notare che ci vengono suggeriti 256 PG per quel pool.
Avendo quindi 128 PG per quel pool avremo un numero di PG per ogni OSD pari a :

 

 

Per capire il meccanismo facciamo un caso con 10 OSD (fig:21):

 

Proxmox Cluster Ceph

 

Ci vengono suggeriti 256 PG per quel pool.
Abbiamo quindi un numero di PG per ogni OSD pari a (fig.22):

 

Proxmox Cluster Ceph

 

All’aumentare quindi del numero di OSD, il carico di PG da gestire per ogni OSD diminuisce favorendo una migliore scalabilità sul cluster.
In generale quindi, è meglio avere più OSD per distribuire meglio il carico dei PG.

 

A tal proposito, il numero massimo di default per Ceph di PG per OSD è settato a 250 PG per OSD. Tuttavia è un parametro che si può variare nei file di configurazione di Ceph ma lo sconsigliamo, a meno che non si sappia esattamente cosa si stia facendo.

 

Sistema Ceph VS Sistema RAID
Seppur diversi nella tecnologia e nella sostanza è tuttavia possibile paragonare queste due tecnologie a livello di “spazio utile” a parità di dischi.

 

Facciamo un confronto dello spazio tra un sistema RAID e un sistema Ceph: se state pensando che Ceph “bruci” un sacco di spazio inutilmente dovete pensare a cosa sarebbe successe se aveste utilizzato una soluzione classica con un controller raid.

 

Prendiamo come esempio il caso che stiamo trattando in questo articolo: Nel caso degli HDD avreste avuto 3 server con 2 dischi cad. in raid 1.
Lo spazio utile totale sarebbe stato 200 GB X n. 3 server = 600 GB. Ma attenzione, non avreste avuto il sistema di replica tra i server ed un unico spazio centralizzato!

 

Facciamo ora il calcolo con un sistema cluster Proxmox reale di piccole dimensioni:
n. 4 server con 4 dischi da 8 TB cadauno.

 

Configurazione RAID 10: spazio untile totale 64 TB. Se pensiamo che ogni macchina debba avere almeno una replica, lo spazio scende a 32 TB.
Quindi alla fine avrò circa 32 TB di spazio utilizzabile al netto delle ridondanze e delle repliche.

 

Configurazione Ceph: spazio totale dei 3 nodi: 128 TB.
Poniamo il caso di utilizzare n. 3 repliche (parametro size 3 del pool), dobbiamo calcolare lo spazio totale diviso 3.
Alla fine dei conti avrò circa 40 TB di spazio contro i 32 TB della soluzione RAID,
Nel caso di Ceph, avrò anche 3 repliche al posto delle 2 della soluzione RAID.

 

Notare che con Ceph abbiamo anche risparmiato i controller raid. Se ne deduce che Ceph è leggermente più dispendioso di risorse ma è più versatile in soluzioni di piccole dimensioni, mentre è molto più efficiente dai 3 nodi a salire.

 

Arrivati a questo punto, con le info che avete, potete “giocare” simulando la variazione del parametro size e confrontare il “consumo” di spazio effettivo con una configurazione classica di dischi in RAID. Noterete che i vantaggi di una soluzione con Ceph sono significativi al crescere del numero dei server e di dischi.

 

Nel video che trovate all’inizio andiamo a simulare dei “guasti” del sistema e vediamo come il nostro cluster reagisce alle perturbazioni. Potete scaricare l’ambiente di test e simulare guasti e malfunzionamenti.

 

Vi ricordiamo che presso la nostra azienda è possibile organizzare dei corsi di approfondimento sull’argomento Proxmox VE.
Vi invitiamo a compilare il form per richiedere le informazioni.

Corso Proxmox VE

Corso Gratuito

Corso gratuito che ti guiderà passo passo nell’utilizzo di Proxmox VE, la gestione di un Cluster, configurazione di Proxmox Backup Server, scelta dell’hardware per un’infrastruttura efficiente.

Alla fine del corso sarai in grado di utilizzare il celebre hipervisor Open Source.

Ambiente di Test Cluster Proxmox VE con Ceph

Ambiente di Test Cluster Proxmox VE con Ceph

Con un Cluster Proxmox i dati vengono distribuiti e replicati real time su altri server, mediante il framework Ceph. Garantendo così affidabilità, continuita e scalabilità del business.

Hai trovato utile questo articolo? Invialo a un amico o condividilo sui social!


Articoli correlati