Ceph - Software Defined Storage - Primi passi

Nel mondo IT di oggi, dove la RAM e i dischi costano sempre di più e gli storage proprietari spesso ti obbligano a comprare i loro hardware specifici a prezzi fuori mercato avere un’alternativa flessibile e davvero scalabile è diventato un lusso quasi indispensabile.
Proprio in questo scenario ci viene in aiuto Ceph: un sistema di storage distribuito open source che permette di costruire soluzioni robuste su hardware comune, eliminando i vincoli dei vendor e sfruttando al meglio le risorse che già hai in datacenter.

Ceph nasce da un’idea universitaria: il progetto prende vita nel 2004 nel laboratorio di ricerca del prof. Sage Weil presso l’Università della California, Santa Cruz, come parte della sua tesi di dottorato su storage distribuito altamente scalabile.
L’obiettivo era dimostrare che era possibile costruire un sistema di storage affidabile e senza single point of failure usando hardware comune, coordinate da un’architettura software intelligente.

In questo articolo vi mostrerò come eseguire il deploy di un cluster Ceph utilizzando Cephadm, il metodo ufficiale e oggi considerato standard per la gestione e l’installazione di Ceph in ambienti moderni.

Prerequisiti Hardware

Risorse mimine per un installazione standalone:

1 macchina fisica/virtuale con:

• 4 CPU
• 8 GB di RAM
• 1 Disco per il sistema operativo
• 1 Disco dedicato allo storage
• 1 NIC
• Sistema operativo linux (consigliato Ubuntu)
• Collegamento ad internet richiesto

Conoscenza minima di:

• Linux bash
• Docker
• Networking L2

Cosa utilizzerò per questa guida?

Per questa guida utilizzerò una macchina virtuale con le seguenti caratteristiche:

3 macchine virtuali su VMware

• 8 CPU
• 16 GB di RAM
• 1 Disco per il sistema operativo (25GB)
• 3 Dischi dedicati allo storage (50GB)
• 2 NIC
• Sistema operativo: Ubuntu 24.04 LTS
• Nome delle macchine: "overflowjournal-ceph0[1-2-3]"

In questo tutorial effettuerò un deploy di un cluster Ceph in alta affidabilità.
In questo caso ogni macchina virtuali avrà 3 ruoli:

• Monitor
• Manager
• OSD

Questi ruoli verranno approfonditi più avanti, per ora mi limito a sottolineare che in un ambiente di produzione è opportuno separare il ruolo di OSD su macchine dedicate, isolandolo dagli altri componenti del cluster.
In ogni caso la configurazioni che vi mostrerò oggi è perfetta anche per piccoli cluster in ambiente di produzione che non richiedono molte performance.

Negli articoli successivi vi mostrerò come effettuare delle installazioni più complesse.

Pronti ad iniziare?

Fase 1 - Installazione dei prerequisiti

Per installare e configurare il nostro cluster utilizzeremo Cephadm, lo strumento ufficiale di orchestrazione fornito da Ceph.
A differenza dei vecchi metodi di installazione, Cephadm semplifica drasticamente il processo, si occupa infatti di gestire l'intero ciclo di vita del cluster, collegandosi ai vari nodi e distribuendo automaticamente i servizi di Ceph all'interno di container Docker su tutte le nostre macchine virtuali.

Di seguito uno schema che spiega in maniera semplificata le fasi di installazione di un cluster Ceph tramite il tool Cephadm

Per rendere la guida più scorrevole non specificherò nel testo sempre su quale macchina operare di volta in volta.
Troverete invece un comodo riferimento direttamente prima di ogni blocco di codice che vi indicherà esattamente su quale nodo lanciare i comandi.

Aggiornamento del Sistema operativo

Come prima cosa è buona norma assicurarsi che le proprie macchine siano aggiornate.
Eseguire quindi i seguenti comandi su tutte e tre le macchine virtuali:

sudo apt update
sudo apt dist-upgrade -y
sudo reboot

Il reboot è importante perché ci permette di riavviare la macchina e caricare il kernel più aggiornato.

Docker

Come primo requisito è necessario installare Docker in tutte le nostre macchine virtuali.

Per installare Docker consiglio sempre di consultare la guida: https://docs.docker.com/engine/install/ubuntu/
Per praticità riporterò qua di seguito i comandi da eseguire

sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Per verificare che Docker sia stato installato con successo lanciare il seguente comando: sudo docker ps

Il risultato dovrebbe essere simile al seguente:

Connettività SSH

Un altro requisito fondamentale per l'utilizzo di Cephadm è la capacità di connettersi via SSH a tutti i nodi e di disporre dei privilegi di escalation (tramite sudo) per gestire e avviare i container Docker.
Per soddisfare questa condizione creeremo un utente dedicato su ogni macchina virtuale e configureremo una coppia di chiavi SSH per consentire l'accesso automatizzato.

Dovremmo scegliere una macchina da dove eseguire il bootstrap.
Nel mio caso, avendo 3 macchine virtuali a disposizione, il bootstrap verrà effettuato dalla macchina overflowjorunal-ceph01

Eseguire i seguenti comandi dalla macchina bootstrap:

sudo adduser cephadm
su - cephadm
ssh-keygen -b 4096

Impostate una password a vostra scelta per l'utente cephadm e ricordatevi di lasciare vuota la passphrase durante la generazione della chiave SSH (premete semplicemente Invio).
Il risultato dovrebbe essere simile al seguente:

Anche sulle altre macchine virtuali dovremo creare l'utente cephadm.
Ricordate di impostare la stessa password su tutti i nodi.
Questo passaggio faciliterà enormemente la configurazione della chiave SSH.
Vediamo il comando da lanciare sulle restanti 2 VM:

sudo adduser cephadm

Il risultato dovrebbe essere simile al seguente:

Una volta configurato l'utente cephadm su tutte le macchine virtuali, dovremo assegnargli i privilegi di sudo per consentirgli di gestire il deployment del cluster.
Per farlo, eseguiamo il comando seguente su ogni nodo:

sudo echo 'cephadm ALL=(ALL) NOPASSWD: ALL' | sudo tee /etc/sudoers.d/cephadm

Il risultato dovrebbe essere simile al seguente:

Torniamo un attimo sulla macchina di bootstrap per creare un file di configurazione SSH.
Questo file ci servirà in seguito per iniettare i parametri all'interno della configurazione del cluster Ceph.
Eseguiamo quindi il comando seguente sul nodo di bootstrap:

su - cephadm
cat > /home/cephadm/.ssh/ssh_config <<'EOF'
Host *
User cephadm
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
EOF

Il risultato dovrebbe essere simile al seguente output:

Come ultima operazione non ci resta che copiare la chiave pubblica generata sul nodo di bootstrap verso le altre due macchine del cluster.
Per farlo in modo semplice e veloce utilizzeremo il comando ssh-copy-id, il quale provvederà a trasferire automaticamente la chiave.
L'operazione richiederà ovviamente di inserire la password dell'utente cephadm impostata in precedenza.

Eseguiamo quindi i comandi seguenti dalla macchina di bootstrap:

su - cephadm
ssh-copy-id overflowjournal-ceph01
ssh-copy-id overflowjournal-ceph02
ssh-copy-id overflowjournal-ceph03

Il risultato dovrebbe essere simile al seguente:

A questo punto l'utente cephadm dovrebbe essere in grado di connettersi via SSH agli altri nodi del cluster senza la necessità di inserire una password.

Disattivazione della memoria di Swap

Ceph è particolarmente sensibile alla memoria in quanto viene utilizzata dai processi per la scrittura/lettura dei dischi.
La swap potrebbe rallentare questi processi influendo negativamente sulle performance del cluster.
Il mio consiglio è quello di disabilitarla su tutti i nodi.

Per farlo eseguire i seguenti comandi su tutte le macchine virtuali:

sudo swapoff -a
sudo sed -i '/swap/s/^/#/' /etc/fstab

Fase 2 - Installazione di Cephadm

Completata la configurazione dei prerequisiti sulle macchine virtuali, possiamo procedere ora con l'installazione del tool Cephadm.

Dal nodo di boostrap eseguire il seguente comando:

CEPH_RELEASE=20.2.4
sudo curl --silent --remote-name --location https://download.ceph.com/rpm-${CEPH_RELEASE}/el9/noarch/cephadm
sudo chmod +x cephadm
sudo mv cephadm /usr/local/bin
sudo cephadm version

Il risultato dovrebbe essere simile al seguente:

Ok, ora siamo pronti per installare il nostro cluster Ceph!

Fase 3 - Deploy del cluster Ceph

Prima di procedere con l'installazione pratica facciamo un passo indietro per capire come funziona Ceph e come è strutturato internamente.

A differenza dei sistemi di storage tradizionali Ceph è uno storage software-defined altamente scalabile e resiliente progettato per non avere un singolo punto di fallimento (SPOF).
All'interno di un cluster Ceph i componenti operano come demoni distribuiti suddivisi in ruoli specifici:

• MON (Monitor): È il gestore dello stato del cluster.
  Mantiene le mappe definitive di tutto il sistema (come la cluster map).
  Tutti i nodi del cluster si sincronizzano tramite i monitor per sapere costantemente dove risiedono i dati.
• MGR (Manager): Lavora a stretto contatto con i Monitor.
  Il suo compito principale è raccogliere le metriche di runtime, lo stato generale del cluster, l'utilizzo dello spazio e le performance, esponendo dashboard (come quella web) e interfacce di telemetria.
• OSD (Object Storage Daemon): È il cuore pulsante e di Ceph.
  Gestisce i dischi fisici sottostanti associati a ciascun nodo, occupandosi della memorizzazione effettiva dei dati, della loro replica, della gestione del recupero (recovery) e del bilanciamento in caso di guasti.

La gestione delle reti in Ceph

Un altro aspetto fondamentale da pianificare prima del deploy è la segmentazione del traffico di rete.
Ceph distingue solitamente tre reti logiche principali per evitare che il traffico intenso dei dati saturi la gestione del cluster:

• Public Network (Rete Pubblica): È la rete attraverso cui i client (le applicazioni o le macchine virtuali) comunicano con il cluster Ceph per leggere e scrivere i dati, oltre a gestire l'accesso amministrativo.
• Cluster Network (Rete di Backend / di Replica): È la rete privata e isolata dedicata interamente al traffico interno tra i demoni OSD.
  Viene usata per la replica dei dati tra i nodi e per le attività di recovery e backfill.
  Isolare questa rete evita che il traffico di replica rallenti le performance percepite dai client sulla rete pubblica.
• Heartbeat Network: Spesso configurata come sottoinsieme della rete cluster (o gestita direttamente da essa), serve a monitorare lo stato di salute (heartbeat) e la raggiungibilità costante tra i nodi, permettendo al cluster di accorgersi immediatamente se una macchina o un servizio cade.

Di seguito uno schema che sintetizza il funzionamento di un cluster Ceph:

Per questa guida ho configurato ciascuna macchina virtuale con due interfacce di rete dedicate

• 1 interfaccia dedicata alla rete pubblica (10.100.144.0/24)
• 1 interfaccia dedicata alla cluster/network (192.168.1.0/24)

Il traffico di heartbeat sarà invece condiviso sull'interfaccia della rete pubblica.
Per comodità, riporto qui sotto la configurazione di rete (Netplan) utilizzata:

network:
  ethernets:
    ens192:
      addresses:
      - 10.100.144.21/24
      nameservers:
        addresses:
        - 1.1.1.1
        - 8.8.8.8
        search: []
      routes:
      - to: default
        via: 10.100.144.1
    ens224:
      addresses:
      - 192.168.1.21/24
  version: 2

Bootstrap del primo nodo

Fatte le premesse necessarie per comprendere i passaggi successivi possiamo ora lanciare il primo comando di deploy.
Sulla macchina di boostrap lanciare il seguente comando:

sudo cephadm bootstrap --mon-ip=10.100.144.21 --cluster-network 192.168.1.0/24 --initial-dashboard-password="overflowjournal" --dashboard-password-noupdate --allow-fqdn-hostname --ssh-user cephadm

Terminato il comando di boostrap il risultato dovrebbe essere simile all'output seguente:

Il comando cephadm shell permette di accedere alla shell amministrativa del cluster.
Verrà avviato un container con tutto l'occorrente per interagire con Ceph.
Una volta all'interno, potrete eseguire i seguenti comandi:

sudo cephadm shell
ceph orch ls
ceph -s

Il risultato dovrebbe essere simile all'output seguente:

• ceph orch ls: Elenca i servizi gestiti dall'orchestratore di Ceph (cephadm). Mostra lo stato di esecuzione, le porte utilizzate, il numero di istanze attive rispetto a quelle desiderate (RUNNING) e la regola di posizionamento (PLACEMENT) all'interno del cluster.
• ceph -s: Mostra lo stato generale (status) del cluster in tempo reale.
  Fornisce una panoramica sintetica della salute del sistema (health), degli ID, dei demoni attivi (come i monitor mon e i manager mgr), dello stato degli OSD (dischi) e dell'utilizzo dello spazio di archiviazione.

Lo stato di avviso (HEALTH_WARN) accompagnato dal messaggio OSD count 0 < osd_pool_default_size 3 è del tutto normale in questa fase del deployment.

Significa semplicemente che:

1. Non sono ancora stati configurati gli OSD (Object Storage Daemon), ovvero i dischi fisici o le partizioni dedicati allo storage (infatti il conteggio degli OSD è 0).
2. Ceph richiede per impostazione predefinita che ogni dato sia replicato almeno 3 volte (osd_pool_default_size 3).
   Poiché il cluster rileva zero dischi a disposizione per memorizzare i dati, segnala giustamente un allarme.

Questo avviso scomparirà non appena procederemo ad aggiungere i nodi aggiuntivi ed aver configurato i relativi dischi.

Aggiunta dei restanti 2 nodi

Terminato il bootstrap del cluster Ceph possiamo procedere aggiungendo i restanti due nodi.
Sempre dalla macchina di bootstrap eseguiamo i comandi seguenti:

sudo cephadm add-repo --release tentacle
sudo cephadm install ceph-common

sudo ceph config-key set mgr/cephadm/ssh_identity_key -i /home/cephadm/.ssh/id_ed25519
sudo ceph config-key set mgr/cephadm/ssh_identity_pub -i /home/cephadm/.ssh/id_ed25519.pub
sudo ceph cephadm set-ssh-config -i /home/cephadm/.ssh/ssh_config

sudo ceph orch host add overflowjournal-ceph02 10.100.144.22
sudo ceph orch host add overflowjournal-ceph03 10.100.144.23

sudo ceph orch host label add overflowjournal-ceph02 mon
sudo ceph orch host label add overflowjournal-ceph03 mon
sudo ceph orch host label add overflowjournal-ceph02 mgr
sudo ceph orch host label add overflowjournal-ceph03 mgr

sudo ceph orch apply mon 3
sudo ceph orch apply mgr 3

Il risultato sarà simile al seguente output:

Il primo comando installa il repository della release Tentacle sulla macchina virtuale overflowjournal-ceph01 e successivamente installa il binario di ceph
direttamente sul sistema operativo.
Questa operazione è molto comoda perché ci permette di gestire tutto il cluster senza entrare tutte le volte nel container di amministrazione di cephadm sudo cephadm shell come fatto in precedenza.

Successivamente la configurazione SSH insieme alle chiavi private e pubbliche che abbiamo preparato in precedenza vengono caricate all'interno del database di configurazione di Ceph per permettere a Cephadm di autenticarsi anche sugli altri nodi.

Una volta predisposta l'infrastruttura di accesso i nodi aggiuntivi vengono registrati nell'orchestratore di Ceph e ad essi vengono assegnate le label per i ruoli di monitor (mon) e manager (mgr)

A questo punto dovremmo avere tutti e 3 i nodi correttamente registrati al cluster con i seguenti ruoli:

• overflowjournal-ceph01: monitor e manager
• overflowjournal-ceph02: monitor e manager
• overflowjournal-ceph03: monitor e manager

Possiamo verificarlo eseguendo i seguenti comandi:

sudo ceph orch ps
sudo ceph -s

Come si può notare dallo screen in sottostante, le macchine sono correttamente configurate e hanno appreso i ruoli correttamente:

Aggiunta dei dischi

Terminata la configurazione della control plane in alta affidabilità è arrivato il momento di aggiungere i dischi.

All'interno dell'architettura di Ceph ogni singolo disco viene gestito come un processo indipendente chiamato OSD (Object Storage Daemon).
Di conseguenza ad ogni OSD corrisponde un disco fisico.
In questa guida le macchine che compongono il control plane fungeranno anche da nodi OSD, ospitando direttamente i dischi fisici da integrare nel cluster.

Nel mio caso ogni nodo ha a bordo 3 dischi da 50GB l'uno (oltre al disco riservato per il sistema operativo) per un totale di 9 dischi:

Ceph dovrebbe in automatico effettuare un discovery di tutti i potenziali dischi che possono essere inseriti nel cluster e diventare degli OSD.
Eseguendo il seguente comando dalla macchina di boostrap è possibile vedere la lista dei dischi sui cui è stato eseguito il discovery:

sudo ceph orch device ls

Il risultato dovrebbe essere simile al seguente output:

Per aggiungere i dischi al cluster e farli diventare OSD eseguire i seguenti comandi dalla macchina boostrap:

sudo ceph orch daemon add osd overflowjournal-ceph01:/dev/sdb
sudo ceph orch daemon add osd overflowjournal-ceph01:/dev/sdc
sudo ceph orch daemon add osd overflowjournal-ceph01:/dev/sdd

sudo ceph orch daemon add osd overflowjournal-ceph02:/dev/sdb
sudo ceph orch daemon add osd overflowjournal-ceph02:/dev/sdc
sudo ceph orch daemon add osd overflowjournal-ceph02:/dev/sdd

sudo ceph orch daemon add osd overflowjournal-ceph03:/dev/sdb
sudo ceph orch daemon add osd overflowjournal-ceph03:/dev/sdc
sudo ceph orch daemon add osd overflowjournal-ceph03:/dev/sdd

Il comando è strutturato nel seguente modo:

ceph orch daemon add osd <host>:<device-path>

Nel mio caso, avendo 3 dischi per ogni macchine virtuali, ho dovuto ripetere il comando nove volte specificando di volta in volta il nome della macchina e il device da utilizzare.

Il risultato è simile al seguente output:

Se tutte le operazioni di aggiunta dischi sono andate a buon fine il nostro cluster ora è pienamente operativo e pronto per essere utilizzato.

Verifica dello stato del cluster

Possiamo verificare ora lo stato di salute del cluster eseguendo i seguenti comandi dalla macchina bootstrap:

sudo ceph -s
sudo ceph osd tree

Il risultato dovrebbe essere simile al seguente output:

Analizzando l'output del primo comando si può notare che il cluster si trova ora nello stato HEALTH_OK.
Questo cambiamento è dovuto all'aggiunta dei demoni OSD che ha dato il via alla replica dei dati di sistema.

Per impostazione predefinita Ceph richiede che ogni dato venga replicato tre volte.
Questa replica tuttavia non avviene casualmente tra i dischi ma viene distribuita a livello di host.
In questo modo, se un'intera macchina dovesse guastarsi, non perderemo la disponibilità dei dati anche qualora tutti gli oggetti risiedessero sui dischi di quel singolo nodo.

Osservando il secondo comando è possibile visualizzare la cluster map:
una mappa interna che traccia tutti gli OSD e i rispettivi host di appartenenza.
Questa struttura consente al cluster di distribuire i dati in modo intelligente seguendo le policy definite dall'utente.

Infine, nel riquadro evidenziato in rosso, si nota che il demone MGR (Manager) ha iniziato a popolare le metriche statistiche mostrando parametri chiave come lo spazio utilizzato, il numero di PG (Placement Groups) e il totale degli oggetti presenti nel cluster.

Conclusioni

La guida che vi ho mostrato rappresenta solo una piccola introduzione al vasto ecosistema di Ceph.
Ci siamo concentrati sull'installazione e sulla preparazione di un cluster in alta affidabilità.
Una volta completato il deploy è possibile configurare il cluster in base alle specifiche esigenze e sfruttandolo in diverse modalità come RBD (RADOS Block Device), Object Storage o filesystem condivisi.

Nei prossimi articoli pubblicherò guide dettagliate dedicate alle singole configurazioni e ai casi d'uso avanzati.

Vi ringrazio per aver letto fino in fondo questa guida e spero vi sia servito come primo approccio al mondo Openstack.
Per qualunque domanda potete scrivermi a [email protected]