Creare un Cluster Iperconvergente (HCI)

1. Software, hardware e risorse utilizzati

Abbiamo realizzato un ambiente di test 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.

• Proxmox VE 6.1-8
• Ceph versione 14-2.6 (stable)
• Raccomandiamo l’utilizzo di un Appliance A3 Server Aluminum, acquistata già configurati e pronti all’uso ed equipaggiato con:
  a) 2 dischi SSD da 2 TB.
  b) 1 disco SATA da 10 TB
  c) RAM: 128 GB
  d) numero CPU: 16Sistema Operativo: Proxmox 6.1-8
• Risorse per ogni VM (nodo):
  a) nome: miniserver-pve1
  b) spazio disco: 64 GB per S.O.
  c) RAM: 16 GB
  d) numero CPU: 4

2. Ceph: I 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).

3. Ceph: il cluster

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

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

l’ambiente di test è 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

4. 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:

• 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.

• 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.

 

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.

5. 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.

6. Configurazione OSD (Object Storage Daemon)

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.

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”).

7. 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):

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.

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.

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:

8. 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.

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.

Vediamo nell’immagine seguente (fig.19) come abbiamo impostato l’interfaccia di 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):

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

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.