Ceph
Il team Proxmox ha predisposto una serie di tool specifici per gestire al meglio ceph. In particolare, il file di configurazione principale /etc/ceph/ceph.conf viene replicato automaticamente tra i nodi.
Installazione
Per l'installazione si veda la documentazione di Proxmox al riguardo.
Gestione dell'OOM
Ceph è abbastanza esoso di RAM, ed è bene effettuare un fine-tuning dell'OOM, ovvero del sistema di gestione della condizione di Out-Of-Memory. In particolare è bene aumentare la memoria minima riservata:
# ma sembra sia necessario anche aumentare la memoria riservata... # vm.min_free_kbytes = 262144
e magari anche agire sulle percentuali di spazio occupato dalle dirty pages, di modo da fargli fare cache in modo un po' più aggressivo, ma contemporaneamente senza arrivare alla saturazione:
# Per info si veda: https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ # vm.dirty_background_ratio = 5 vm.dirty_ratio = 40
Tutto questo può essere inserito in un file in sysctl, ad esempio /etc/sysctl.d/local.conf.
Note di configurazione
La modifica del file ceph.conf deve essere ricaricata con un restart dei servizi (MON o OSD). O con un riavvio del server...
Sincronizzazione oraria
Ceph è strettamente dipendente da una ottima sincronizzazione oraria tra le macchine del cluster; si raccomanda una attenta configurazione delle fonti NTP.
Tecnicamente è possibile rilassare il vincolo di clock drift con l'opzione mon clock drift allowed (di default è a .050 secondi), ma mi avventurerei per questa strada con la massima prudenza...
Calcolo dei PG
Ottimizzazioni del Journal
Il journal di default è 5MB. Lo si può aumentare con:
osd journal size = 47104
(ma se è un FS/device esterno, basta che questo sia più grosso...) ma poi ovviamente occorre anche usarlo: esisono i due parametri:
filestore max sync interval = 60 filestore min sync interval = 1
che indicano, in secondi, i tempi massimi e minimi per il flush del journal. Se ho una banda di 50MB/s, il mio journal deve essere più grande di 50MB/s*60s=3GB.
Ottimizzazioni/priorizzazioni della gestione dei dati
Se la rete di cluster e di storage coincidono, l'attivazione della operazione di rebalancing potrebbe pesare parecchio sulle prestazioni del cluster. In questo caso è possibile ridurne gli effetti depriorizzandola, ad esempio con:
osd scrub during recovery = false osd recovery op priority = 1 osd recovery max active = 5 osd max backfills = 1
Posso inoltre limitare ad orario l'operazione di scrubbing:
osd scrub begin hour = 18 osd scrub end hour = 7
Oppure non fare scrubbing se il load va sopra al valore di questo parametro:
osd scrub load threshold = 3
Un approccio diverso è quello di depriorizzare le operazioni a livello di scheduler, ad esempio con:
osd disk thread ioprio class = idle osd disk thread ioprio priority = 7
ma queste opzioni sono utilizzate solo se si utilizza uno scheduler per l'I/O su disco, in particolare CFQ.
Utilizzo in Proxmox
Per utilizzare i pool Ceph in Proxmox occorre copiarne le chiavi. Fare riferimento a https://pve.proxmox.com/wiki/Storage:_Ceph#Configure_Proxmox_to_use_the_ceph_cluster .
Gestione
In generale, sulla gestione di Ceph è bene fare rifeimento alla documentazione ufficiale; occorre però tenere sempre in considerazione che per alcune operazioni è possibile/preferibile usare i tool specifici di Proxmox che mantengono la compatibilità poi con l'interfaccia web.
Inoltre esiste questo interessante tutorial.
OSD
Gli Object Storage Daemon (OSD, appunto) sono il servizio di Ceph che, più a basso livello, gestisce il disco e quindi i dati; anche se sono possibili diverse configurazioni, normalmente ogni disco è associato alla sua OSD.
Indubbiamente sulle OSD verranno effettuate le principali operazioni di manutenzione.
Prima di cominciare
Ceph è un sistema di storage altamente efficiente, e per fare questo gestisce in modo sitewide lo spazio su disco: questo implica che, in caso di assenza (temporanea o permanente) di uno degli OSD, il sistema attiva il ribilanciamento dei dati, spostandoli tra tutti gli OSD attivi.
Questo implica in particolare che, anche un semplice riavvio di un server, triggera (quasi) immediatamente l'operazione di rebalancing, e questo ovviamente per le manutenzioni ordinarie non è proprio ideale.
Per questo, prima di ogni operazione di manutenzione, è necessario impartire (su uno qualsiasi dei nodi) il comando:
ceph osd set noout
in questo modo si istruisce Ceph, semplicemente, a non iniziare il ribilanciamento; altrettanto ovviamente il cluster finisce in stato degradato, perché in buona sostanza la mappa di allocazione non viene modificata ed eventuali copie dei dati nelle OSD inattive vengono accodate.
Una volta effettuate le operazioni di manutenzione sugli OSD, è possibile ripristinare il comportamento normale:
ceph osd unset noout
questo ovviamente attiverà un rebalancing, ma di entità minore (specie se non si sono modificati gli OSD, ad esempio per un reboot).
Altri flag utili
È anche possibile disabilitare temporaneamente alcune operazioni, ad esempio lo scrubbing, usando i flag noscrub e noscrub-deep. Si veda anche https://sabaini.at/pages/ceph-cheatsheet.html .
Creazione di un OSD
L'attivazione di nuovi OSD può essere fatta tranquillamente da interfaccia web, ma con alcune limitazioni; in particolare, non sempre il riconoscimento delle partizioni di journal funziona, e quindi è possibile usare la commandline.
Oltre a questo, alcuni tipi di device, ad esempio i device multidisk (MD, RAID software) non vengono risconosciuti.
Per attivare un OSD con journal in partizone RAID occorre quindi innazitutto partizionare il device raid /dev/mdY con tabella delle partizioni GPT; è sufficiente creare una singola partizione grande come tutto il disco, il tipo è ininfluente (solitamente 82, Linux).
In questo modo viene creata la partizione /dev/mdYp1.
Occorre quindi preparare il disco per l'uso con Ceph (sia il disco /dev/sdX); questo passo è strettamente necessario se il disco era stato in precedenza usato:
ceph-disk zap /dev/sdX
Quindi è possibile creare l'OSD con il comando:
pveceph createosd /dev/sdX --journal_dev /dev/mdYp1
Durante la creazione dell'OSD viene emesso il warning:
WARNING:ceph-disk:Journal /dev/mdYp1 was not prepared with ceph-disk. Symlinking directly.
La cosa è del tutto normale...
Modifica del journal
Se è necessario aggiungere o modificare il journal su un OSD non è necessario distruggere l'OSD e rifarlo: il journal infatti è un file (o un link a un device) all'interno del filesystem dell'OSD. È quindi sufficiente fare, considerando con $ID l'ID dello specifico OSD (e dopo aver ovviamente anestetizzato il rebalancing!):
service ceph stop osd.$ID ceph-osd -i osd.$ID --flush-journal rm -f /var/lib/ceph/osd/$ID/journal ln -s /var/lib/ceph/osd/$ID/journal /dev/<ssd-partition-for-your-journal> ceph-osd -i osd.$ID —mkjournal service ceph start osd.$ID
Aggiornamento
(ovviamente non sto parlando dell'aggiornamento di una major revision, ma solo aggiornamenti minori)
L'aggiornamento NON prevede alcun restart/reload dei servizi, che va fatto manualmente.
Prima dell'aggiornamento è ovviamente preferibile mettere il cluster in noout mode, si veda Gestione:Proxmox#Prima_di_cominciare.
Inoltre è preferibile tenere d'occhio i log di ceph (solitamente con:
tail -f /var/log/ceph/ceph.log
ed effettuare le operazioni una per una (ovvero, riavviare il secondo monitor quando il primo è tornato a funzionare e similmente per gli OSD).
Monitor
Per i monitor la cosa è piuttosto semplice, è sufficiente un:
systemctl restart ceph-mon.<MON-ID>.<UNIQUE ID>.service
(si usi la tab completition per il nome esatto del monitor).
OSD
Allo stesso modo è necessario far ripartire i singoli OSD:
systemctl restart ceph-osd.<MON-ID>.<UNIQUE ID>.service
(si usi la tab completition per il nome esatto dell'OSD).
Avanzate
Stimare la quantità di oggetti da spostare
Se si modifica la crushmap, sicuramente alcuni oggetti verranno spostati. Ma quanti? E Come? Il tutto può essere calcolato (non stimato) avendo la crushmap di partenza e la crusmap di arrivo con il comando crush compare. Per maggiori info si veda http://ceph.com/planet/how-many-objects-will-move-when-changing-a-crushmap/ .
