Ceph i en Proxmox-klynge: høj tilgængelighed uden separat SAN

Ceph i en Proxmox-klynge kan fordele VM-data på lokale SSD’er i flere værter og erstatte et separat SAN. Det afgørende er, hvad der sker med kopierne efter et værtsnedbrud: er quorum, fri kapacitet og netværk nok til at genskabe den ønskede redundans i tide? Regneeksemplet skelner mellem tilgængelige data, automatiske VM-genstarter og faktisk genopretningstid.

Artiklen fokuserer på Cephs mekanik i drift. Den konkrete HPE-stykliste kræver sit eget hardwaredesign; valget mellem Ceph, ZFS-replikering og eksternt lager kræver en separat anvendelsessammenligning. Basisscenariet bruger lokale enterprise-SSD’er som enkelte Ceph-OSD’er, en replikeret VM-pool og vært som fejldomæne. Bootmedier og ekstern backup indgår ikke i poolen.

Hvordan gør lokale SSD’er VM-data tilgængelige?

Ceph fordeler dataobjekter via placement groups på OSD’er. CRUSH-reglen bestemmer, hvilke værter kopierne ligger på. I eksemplet sætter vi udtrykkeligt size=3 og min_size=2: tre kopier inklusive den primære, I/O ved mindst to tilgængelige kopier. Kopier på tre OSD’er i samme vært giver ikke tredobbelt beskyttelse mod værtsnedbrud. Monitorquorum, OSD-status og VM-datas tilgængelighed skal kontrolleres separat. Proxmox-klyngen skal have mindst tre stemmer for pålideligt HA-quorum; Ceph-monitorquorum og VM-HA-regler kommer oveni.

Efter nedbrud på én af præcis tre værter er to værtskopier tilbage ved korrekt fordeling. Under de nævnte betingelser kan poolen levere degraderet I/O, men en tredje kopi på et tredje værtsfejldomæne opstår først, når en vært vender tilbage eller erstattes. Med fire værter kan Ceph genopbygge den på den fjerde, hvis plads og ydelse er fri. Det er forskellen mellem »data er fortsat tilgængelige« og »redundansen genskabes under nedbruddet«. Også med Ceph kan en VM stoppe og først genstarte på en anden vært; det giver ikke nul sekunders afbrydelse.

Beregn kapacitet med fejlreserve

Antag fire lokale data-SSD’er på hver 1,92 TB decimal pr. vært. Tre værter giver 23,04 TB råt, fire 30,72 TB. Med tre kopier er det før metadata, snapshots og driftsreserver teoretisk 7,68 eller 10,24 TB logiske data. En hypotetisk planlægningsgrænse på 70 procent giver først 5,38 eller 7,17 TB. Det er hverken Ceph-standard eller en lovet brugbar kapacitet.

For at holde fireværtsklyngen under den valgte grænse selv efter en værts nedbrud, når genopbygningen er afsluttet, planlægges i eksemplet højst cirka 70 procent af restkapaciteten: 5,38 TB logiske data, ikke 7,17 TB. De mest fyldte OSD’er og Cephs tærskler for nearfull, backfillfull og fuller også afgørende. En enkelt fuld OSD kan blokere skrivning eller backfill, selv om totalsummen ser god ud. Decimale TB er ikke binære TiB.

Hvor lang tid tager genopbygningen?

Med eksempelvis 5 TB logiske data og tre kopier ligger 15 TB rådata i fireværtsklyngen, ideelt fordelt med 3,75 TB pr. vært. Ved tab af én skal cirka 3,75 TB overføres til de tre resterende for at genskabe den tredje kopi. Ved en målt effektiv genopbygningsrate på 250 MB/s er 3,75 TB ÷ 250 MB/s = cirka 4 timer 10 minutter en beregnet nedre grænse; ved 125 MB/s cirka 8 timer 20 minutter. Peering, fordeling, konkurrerende VM-I/O, recoverygrænser og nye skrivninger forlænger tiden. Den nominelle hastighed for et 25-Gbit-kort er ikke den måling.

DAXS ville kræve en fejltest med aktiv applikationsbelastning: observer ceph health detail, ceph osd df og placement-gruppernes forløb, registrer faktiske recoverybytes og varighed samt mål latenstid og VM-tilgængelighed. I normal drift skal PG’erne igen nå active+clean . Testen skal også vise, om et switch-, link- eller strømvejsnedbrud samtidig rammer Corosync-quorum eller Ceph-trafik. Proxmox anbefaler mindst 10 Gbit/s udelukkende til Ceph og mere ved hurtige SSD’er; portplanen afhænger af OSD-gennemløb, genopretningsmål og fysisk separate veje.

Hvad koster det ekstra genopbygningsdomæne?

Til budgettet lader vi h være tilbudsprisen på en fuldt bestykket vært, n det redundante netværk, som allerede er dimensioneret til fire forbindelser, og b en ekstern backupserver med medier. Pr. vært antages p euro årligt til service, strøm og colocation. Kun i modellen sættes opbygning og godkendelse til 100 timer × 90 € = 9.000 €, løbende drift til 60 timer × 90 € = 5.400 € årligt. Samme arbejde antages for tre og fire værter og skal estimeres igen i tilbuddet. De officielle listepriser for Proxmox VE Standard og Proxmox Backup Server Standard er henholdsvis 550 € pr. bestykket CPU-sokkel om året og 2.240 € pr. backupserver om året. Der antages præcis én bestykket sokkel pr. vært. Alt er netto; erstat med reelle tilbud og arbejdsestimater.

Formlen lægger årligt Proxmox-sokler, PBS og 5.400 € drift sammen: ved tre værter 9.290 € plus 3p, ved fire 9.840 € plus 4p. En 1.000 € højere stykpris pr. vært øger begge fireværtshorisonter med 4.000 €; 1.000 € højere årlige omkostninger pr. vært med 12.000 eller 20.000 €. Kræver fireværtsvarianten andre switche, lægges forskellen oven i n . Ceph-kopier er stadig ikke backup: separat system, ekstern kopi og testet gendannelse indgår i godkendelsen. DAXS-artiklen Proxmox Backup Server: verificering, opbevaring og gendannelse beskriver denne kontrol.

Beslut først efter måling af latenstid, nedetid og genopbygning samt et solidt tilbud på hardware, netværk og drift. DAXS kan konkretisere måle- og godkendelsesprotokollen med virksomheden via Kontakt .

Kilder: Proxmox VE Administration Guide: klynge og Ceph · Ceph: size og min_size · Ceph: helbredskontrol og fyldningsgrader · Ceph: recovery og backfill · Proxmox VE: priser · Proxmox Backup Server: priser.