Volumi a blocchi (RBD) per macchine virtuali e container.
Supporto Ceph — certificati Red Hat
Storage distribuito che non si ferma mai
Progettiamo e gestiamo cluster Ceph, e interveniamo quando smettono di funzionare. Siamo certificati Red Hat.
Le nostre competenze
Cos’è Ceph
Un sistema di storage che distribuisce i dati su più macchine invece di tenerli su un apparato solo. Se un disco o un intero nodo si guastano, i dati restano accessibili e il sistema si ripara da sé. Cresce aggiungendo macchine, senza fermare nulla.
- Tipo
- Storage distribuito, senza punto singolo di guasto
- Blocchi
- RBD — dischi per macchine virtuali e container
- File
- CephFS — filesystem condiviso, montabile da più macchine
- Oggetti
- RGW — object storage compatibile con S3 e Swift
- Crescita
- Si aggiungono nodi a caldo, senza fermi
- Ridondanza
- Repliche o erasure coding, configurabili
- Integrazione
- Nativa in Proxmox VE, e anche su cluster a sé
- Licenza
- LGPL — software libero
Un solo storage, molti modi di usarlo
Ceph parla a vSphere via iSCSI o NFS: cambia lo storage, resta l’hypervisor.
Amazon S3
Compatibile con S3 e Swift: object storage on premise, i dati restano in azienda.
Kubernetes
Storage persistente via CSI, che sopravvive al riavvio di un pod o di un nodo.
Object Lock
Copie immutabili che il ransomware non può cifrare, nemmeno con le credenziali di amministratore. Funziona con Veeam.
CephFS
Un filesystem che si monta da più macchine insieme, senza un server NFS a fare da collo di bottiglia.
Snapshot
Istantanee di volumi e filesystem, e cloni che ripartono da quelle.
Seconda sede
Replica remota fra datacenter: se una sede cade, i dati sono già altrove.
Archivi
Da qualche TB a decine di petabyte, aggiungendo nodi a caldo senza fermare nulla.
Commodity hardware
Gira su macchine ordinarie, anche su server che il produttore non supporta più.
Come lo mettiamo in opera
Bare metal
Ceph su macchine sue, senza livelli di virtualizzazione in mezzo: la scelta quando lo storage deve reggere carichi pesanti o crescere per conto suo.
Proxmox VE
Integrazione nativa: calcolo e storage nello stesso cluster, gestiti dalla stessa interfaccia.
PetaSAN
Distribuzione con interfaccia dedicata per chi vuole Ceph pronto all’uso, senza rinunciare al controllo di come è fatto sotto.
Cosa possiamo fare per voi
ContattaciEmergenza
Cluster fermo o degradato, adesso.
- Intervento diretto sul cluster
- Anche su installazioni fatte da altri
- Relazione su cosa è successo
Assistenza continuativa
Un cluster Ceph va seguito, non installato e dimenticato.
- Aggiornamenti di versione
- Sostituzione dischi e riequilibrio
- Espansione con nuovi nodi
- Controllo periodico dello stato
Progetto
Un cluster da dimensionare e mettere in opera.
- Dimensionamento
- Messa in opera
- Prove di guasto prima della produzione
- Formazione di chi lo gestirà
Non pubblichiamo un listino perché dipende da quanti nodi avete e da cosa vi serve: un preventivo lo facciamo dopo aver guardato la situazione, non prima.
Formiamo anche chi il cluster lo gestisce
Vedi il corsoCorsi su misura per chi Ceph deve amministrarlo tutti i giorni: come si legge lo stato, cosa si fa quando un disco cade, quando chiamare aiuto e quando no. In aula da noi, da voi, o a distanza.
Anche su cluster che non abbiamo installato noi
ContattaciÈ il caso più frequente. Non serve che ci raccontiate com’è stato messo su né perché: quello lo guardiamo noi. Capita spesso di essere chiamati su cluster montati da qualcuno che nel frattempo non c’è più.
Lo storage è fermo adesso?
Vai in emergenzaDomande che ci arrivano
Che tipo di attività fate su Ceph?
Progettazione e dimensionamento, messa in opera, manutenzione ordinaria — aggiornamenti di versione, sostituzione dei dischi, riequilibrio dei dati, espansione con nuovi nodi — recupero di cluster degradati, interventi d’emergenza e formazione di chi il cluster deve gestirlo tutti i giorni.
Fate anche gli aggiornamenti di versione?
Sì, ed è la parte del lavoro dove si sbaglia più spesso: un aggiornamento va fatto nell’ordine giusto — monitor, manager, OSD, poi i gateway — e su un cluster in produzione conviene provarlo prima di lanciarlo. Chi ci lascia seguire il cluster non ci pensa: lo pianifichiamo noi.
Intervenite anche su cluster installati da altri?
Sì, ed è il caso più frequente. Non serve che ci raccontiate com’è stato messo su né perché: servono l’accesso, l’output di ceph -s, la versione e come è fatta la rete. Da lì vi diciamo cosa vediamo, e decidete voi. Capita spesso di essere chiamati su cluster montati da qualcun altro che nel frattempo non c’è più.
Migrate uno storage esistente su Ceph?
Sì. Si fa a servizio acceso, spostando i dati un pezzo alla volta: le macchine virtuali continuano a lavorare mentre il trasferimento va avanti. Il fermo, quando serve, si riduce alla commutazione finale e si concorda con voi.
Da quanti nodi conviene partire?
Tre è il minimo perché il cluster regga la perdita di un nodo senza fermarsi. Si può iniziare da lì e aggiungerne altri quando servono, senza rifare niente. Sotto i tre nodi Ceph non ha senso, e ve lo diciamo invece di vendervelo lo stesso.
Serve hardware particolare?
Non c’è una lista di modelli approvati: Ceph gira su hardware standard, e non siete vincolati a un fornitore. Ci sono però caratteristiche che servono davvero — una rete dedicata e veloce, dischi pensati per lavorare sempre — perché sono quelle che determinano se il cluster va bene tutti i giorni. Non è questione di marca, è questione di come è fatto: lo verifichiamo insieme prima che compriate qualcosa.
Cosa succede se un nodo si guasta?
Niente che dobbiate fare voi nell’immediato. I dati sono su più nodi, quindi le macchine virtuali continuano a lavorare e il cluster si ricostruisce da solo le copie mancanti. Il nodo va sostituito con calma, nei tempi vostri, non di notte. Se invece l’I/O si è fermato, il cluster non si sta ricostruendo: è un’emergenza.