Ceph nel cluster Proxmox: alta disponibilità senza SAN separata

Ceph nel cluster Proxmox può distribuire i dati delle VM su SSD locali di più host, sostituendo una SAN separata. Conta ciò che accade alle copie dopo il guasto di un host: quorum, capacità libera e rete bastano a ripristinare in tempo la ridondanza richiesta? Il calcolo seguente distingue dati raggiungibili, riavvii automatici delle VM e tempi effettivi di ripristino.

Questo articolo approfondisce la meccanica operativa di Ceph. La distinta HPE concreta richiede un progetto hardware dedicato; scegliere fra Ceph, replica ZFS e storage esterno richiede un confronto applicativo distinto. Lo scenario base usa SSD enterprise locali come singoli OSD Ceph, un pool VM replicato e l’host come dominio di guasto. Supporti di avvio e backup esterno non fanno parte del pool.

Come gli SSD locali rendono accessibili i dati delle VM?

Ceph distribuisce oggetti dati sugli OSD tramite Placement Group. La regola CRUSH determina su quali host risiedono le copie. Nell’esempio impostiamo esplicitamente size=3 e min_size=2: tre copie inclusa la primaria, I/O con almeno due copie raggiungibili. Copie su tre OSD dello stesso host non darebbero protezione tripla dal guasto dell’host. Quorum dei monitor, stato degli OSD e accessibilità dei dati VM vanno verificati separatamente. Il cluster Proxmox necessita di almeno tre voti per un quorum HA affidabile; si aggiungono quorum dei monitor Ceph e regole HA delle VM.

Se si guasta uno di esattamente tre host, una replica distribuita correttamente lascia due copie su host. Con i presupposti citati, il pool può fornire I/O degradato, ma una terza copia su un terzo dominio host nasce solo al rientro o alla sostituzione di un host. Con quattro host Ceph può ricostruirla sul quarto, se dispone di spazio e prestazioni. È la differenza pratica fra «dati ancora accessibili» e «ridondanza ripristinata durante il guasto». Anche con Ceph una VM può fermarsi e riavviarsi solo su un altro host; non ne consegue un’interruzione di zero secondi.

Calcolare la capacità con riserva per i guasti

Si ipotizzano quattro SSD dati locali da 1,92 TB decimali per host. Tre host forniscono 23,04 TB lordi, quattro 30,72 TB. Con tre copie, prima di metadati, snapshot e riserve operative, risultano teoricamente 7,68 o 10,24 TB logici. Un limite di pianificazione ipotetico del 70 per cento dà inizialmente 5,38 o 7,17 TB. Non è un valore predefinito Ceph né una capacità utile garantita.

Per mantenere il cluster di quattro host sotto il limite scelto anche dopo il guasto di un host, una volta completata la ricostruzione, nell’esempio si pianificano quindi al massimo circa il 70 per cento della capacità residua: 5,38 TB logici, non 7,17 TB. Contano inoltre gli OSD più pieni e le soglie Ceph per nearfull, backfillfull e full. Un solo OSD pieno può bloccare scritture o backfill anche se il totale sembra buono. I TB decimali non sono TiB binari.

Quanto dura la ricostruzione?

Con ad esempio 5 TB logici e tre copie, il cluster di quattro host contiene 15 TB lordi, idealmente ripartiti in 3,75 TB per host. Se uno si guasta, per la terza copia vanno trasferiti circa 3,75 TB sui tre host restanti. A una velocità di ricostruzione effettiva misurata di 250 MB/s, 3,75 TB ÷ 250 MB/s = circa 4 ore 10 minuti è un limite inferiore aritmetico; a 125 MB/s circa 8 ore 20 minuti. Peering, distribuzione, I/O delle VM concorrenti, limiti di recovery e nuove scritture allungano il tempo reale. La velocità nominale di una scheda da 25 Gbit non costituisce questa misura.

DAXS richiederebbe una prova di guasto con carico applicativo attivo: osservare ceph health detail, ceph osd df e l’andamento dei Placement Group, registrare byte effettivamente recuperati e durata e misurare latenza e disponibilità delle VM. Nel funzionamento normale i PG devono tornare active+clean . La prova deve mostrare se il guasto di switch, collegamento o percorso elettrico colpisce contemporaneamente quorum Corosync o traffico Ceph. Proxmox raccomanda almeno 10 Gbit/s esclusivi per Ceph e di più con SSD veloci; il piano porte concreto dipende da throughput OSD, obiettivo di recovery e percorsi fisici separati.

Quanto costa il dominio aggiuntivo per ricostruire?

Per il budget, sia h il prezzo offerto di un host completamente equipaggiato, n la rete ridondante già dimensionata per quattro collegamenti e b un server di backup esterno con supporti. Per host si ipotizzano p euro annui per assistenza, energia e housing. Solo nel modello assumiamo allestimento e collaudo di 100 ore × 90 € = 9.000 € e gestione di 60 ore × 90 € = 5.400 € l’anno. Si presume lo stesso lavoro per tre e quattro host, da ristimare nell’offerta reale. I listini ufficiali Proxmox VE Standard e Proxmox Backup Server Standard sono rispettivamente 550 € per socket CPU occupato e anno e 2.240 € per server di backup e anno. Si assume esattamente un socket occupato per host. Tutti i valori sono netti; offerte e lavoro effettivi devono sostituirli.

La formula somma ogni anno socket Proxmox, PBS e 5.400 € di gestione: con tre host 9.290 € più 3p, con quattro 9.840 € più 4p. Un prezzo per host maggiore di 1.000 € aumenta entrambi gli orizzonti a quattro host di 4.000 €; 1.000 € annui in più per host aggiungono 12.000 o 20.000 €. Se la variante a quattro host richiede switch diversi, la differenza va aggiunta a n . Le copie Ceph non sono comunque backup: sistema separato, copia esterna e restore verificato fanno parte del collaudo. Il contributo DAXS Proxmox Backup Server: verifica, conservazione e ripristino descrive questa prova.

Si decide solo dopo misure di latenza, interruzione e ricostruzione e un’offerta solida di hardware, rete e gestione. DAXS può definire con l’azienda questo protocollo di misura e collaudo tramite Contatti .

Fonti: Proxmox VE Administration Guide: cluster e Ceph · Ceph: size e min_size · Ceph: controlli di salute e riempimento · Ceph: recovery e backfill · Proxmox VE: prezzi · Proxmox Backup Server: prezzi.