Gyakorlati tapasztalatok

Ceph, ZFS-replikáció vagy külső tároló: melyik alkalmazásnak mi kell?

Ceph, ZFS-replikáció és külső tároló összevetése Proxmoxban: RPO, RTO, hibatartományok és három-/ötéves költségek különböző alkalmazásokhoz.

DAXS-logó Ceph-, ZFS- és SAN/NAS-feliratok felett, három absztrakt tárolójellel

A Ceph, ZFS-replikáció és külső SAN vagy NAS segíthet átvészelni a Proxmox-VM-ek gazdagéphibáját. Az adatfrissesség, újraindulás és hibatartomány azonban eltér. A „magas rendelkezésre állás” kipipálása gyakran elfedi a tényleges igényt: hány perc adatvesztés elfogadható az alkalmazásnak (RPO), és mikor kell újra használhatónak lennie (RTO)?

Ugyanahhoz a hipotetikus háromgépes klaszterhez három tárolási utat vetünk össze. Hogyan építi újra a Ceph a másolatokat gazdagéphiba után – ezt külön cikk tárgyalja. Itt az alkalmazásokból és igazolható helyreállítási céljaikból indulunk ki. Mindhárom út mellett külön mentés és visszaállítási teszt szükséges.

Három architektúra, három eltérő kiesési út

A Ceph helyi SSD-ken elosztott, a klaszterben közösen elérhető blokktárolóként adja a VM-lemezt. A replikált pool több gazdagépen tart másolatokat; kvórum, poolszabály, hálózat és szabad kapacitás feleljen meg a választott gazdagép-hibatartománynak. VM-gazdagép kiesésekor a Proxmox HA másik gépen indíthatja újra a VM-et, ha van kvórum és erőforrás. A folyamatban lévő írást, vendégalkalmazást és tranzakcióit így is értékelni kell a tesztben. A Ceph-redundancia önmagában sem megszakításmentes VM-et, sem minden alkalmazásnak garantált nulla RPO-t nem ígér.

A helyi ZFS Proxmox-tárolóreplikációval időközönként pillanatképpel másik gépre továbbítja a VM-köteteket. A célon a legutóbbi sikeresen befejezett replikáció állapota van. A Proxmox engedi a HA és replikáció együttes használatát, de kifejezetten figyelmeztet az utolsó szinkron óta lehetséges adatvesztésre. A beállított ötperces ütem ezért nem általános RPO-vállalás: késés, sikertelen feladat és alkalmazásállapot is számít. Szinkron közös lemez nélkül az újraindult VM-nek pontosan ezzel a régebbi állapottal kell működnie.

A külső megosztott tároló például NFS vagy iSCSI több gépnek elérhetővé teszi a VM-lemezeket, és jellemzően lemezmásolás nélkül enged élő migrációt. Gazdagéphibánál az adatkockázat a tényleges tárolótervtől függ. Két vezérlőt, külön adat- és tápútvonalakat, iSCSI-multipathingot vagy redundáns NFS-hálózati utakat, támogatást és tesztelt vezérlőváltást kell ellenőrizni; egyetlen NAS továbbra is központi hibatartomány. A Proxmox dokumentációja kifejezetten óv attól, hogy a ZFS-over-iSCSI eszköz egyetlen hibapont legyen. A „Shared” konfiguráció nem bizonyít redundáns készüléket.

Melyik terhelés milyen RPO-t és RTO-t visel el?

Az RPO a legnagyobb elfogadott adatvesztést, az RTO a használható alkalmazásig elfogadott leghosszabb időt méri. Az alábbiak döntési kérdések, nem termék-SLA-k. Minden szolgáltatásnál együtt kell tesztelni adatbázist, VM-újraindítást, DNS-t, bejelentkezést és függő rendszereket.

Példabeli alkalmasság: terhelésmérés, hibatartomány- és újraindítási teszt után dönteni
Alkalmazás és cél Életszerű út Döntő ellenőrzés
Tranzakciós ERP-adatbázis; alig elfogadható adatvesztés Ceph vagy bizonyíthatóan redundáns megosztott tároló; szükség esetén további alkalmazásreplikáció Írási késleltetés, tranzakciókonzisztencia, kvórum és valós újraindítás gazdagép-/tárolóhibánál
Belső teszt-VM vagy visszaállítható webszolgáltatás; percek adatvesztése elfogadott Helyi ZFS replikációval elegendő lehet Utolsó sikeres pillanatkép kora, késési riasztás, indulás régebbi adatokkal
Meglévő támogatott SAN/NAS megfelelő tartalékkal További használata megosztott tárolóként gazdaságos lehet Vezérlőket, utakat, áramot, firmware-t, karbantartási szerződést és élő hibaváltást együtt tesztelni

Nagyon szigorú RPO-jú éles adatbázisnál az aszinkron ZFS-replikáció alkalmatlan lehet, még működő HA-újraindítás mellett is. Visszaállítható tesztszolgáltatás viszont nem indokol automatikusan Ceph-et. Három Proxmox-gép nem tesz redundánssá egyetlen tárolószervert. A választást az elfogadott adatvesztés és mért kiesés vezérli, a terméknéven túl.

Három- és ötéves számítás kitalált piaci árak nélkül

A hipotetikus összevetés három azonos egyfoglalatos gazdagépet feltételez h gépenkénti vételárral és külön mentőszervert adathordozókkal b áron. A gyártó aktuális listája szerint a Proxmox VE Standard évi 550 € foglalt CPU-foglalatonként, a Proxmox Backup Server Standard évi 2 240 € szerverenként. A közös támogatás így 3 × 550 + 2 240 = 3 890 € évente. A modell nettó 90 € munkadíjat használ óránként. Ellenőrzés nélkül nem feltételez azonos IOPS-ot vagy hasznos kapacitást: a valós ajánlatokat először azonos terhelésre kell normalizálni.

d a gépenkénti további Ceph-adat-SSD-ket jelöli, z a gépenkénti helyi ZFS-SSD-felszerelést, a a redundánsra tervezett külső készüléket, nc, nz és ns az egyes utakhoz szükséges hálózati vagy fabric-beruházásokat. ec, ez és es az éves további áram-/kolokációs költségek; s a külső készülék éves gyártói szervizszerződése. Minden betű nettó eurós ajánlati érték, nem állított piaci ár.

Hipotetikus nettó összköltség; azonos gazdagép- és mentési alap
Út Kiépítés / éves üzemeltetés 3 év 5 év
Ceph 80 h / 50 h 3h + b + 3d + nc + 32 370 + 3ec € 3h + b + 3d + nc + 49 150 + 5ec €
ZFS-replikáció 50 h / 30 h 3h + b + 3z + nz + 24 270 + 3ez € 3h + b + 3z + nz + 37 450 + 5ez €
Külső tároló 60 h / 35 h 3h + b + a + ns + 26 520 + 3s + 3es € 3h + b + a + ns + 40 600 + 5s + 5es €

A munkaórák puszta modellfeltételezések, nem DAXS-átalány. Példa: évi 1 000 € többlet készülékszerviz három év alatt 3 000 €-val, öt év alatt 5 000 €-val növeli a külső változatot. Meglévő készülék csökkentheti az a értékét az időszakban, de hátralévő élettartam, támogatás, alkatrész és bővítés az s értékébe vagy külön beruházási sorba tartozik. Hardverár, tárolóhasználat, teljesítményprofil, hálózat, adó és üzemeltetési hely ajánlattal igazolandó. A legkisebb képletérték nem vásárlási döntés azonos hasznos kapacitás, IOPS, RPO és RTO nélkül.

Átvétel: minden hibatartományban valóban végigjátszani egy kiesést

A DAXS négy bizonyítékot kérne minden szóba jövő architektúrához: (1) az utolsó konzisztens alkalmazásállapot idejének rögzítése, (2) gazdagépkiesés és VM-újraindítás mérése terheléssel, (3) a kritikus tároló- vagy hálózati út célzott megszakítása és (4) VM és egyedi alkalmazásadatok visszaállítása különálló mentésből. ZFS-nél sikertelen vagy késő replikációs feladatot is tesztelni kell; Ceph-nél csökkent redundanciájú poolt és újjáépítését; SAN/NAS-nál vezérlő- és útváltást. A mérések döntik el az RPO és RTO teljesülését.

A Ceph-másolat, replikációs pillanatkép és tömbtükrözés a törlést és hibás adatot is továbbviszi. Nem helyettesít verziózást, külső másolatot vagy visszaállítási tesztet. A DAXS Proxmox Backup Server: ellenőrzés, megőrzés és visszaállítás cikke mélyíti a mentési átvételt. Alkalmazáslistával és RPO/RTO-célokkal a Kapcsolat oldalon egyeztethető a három út DAXS általi mérése a valós terheléshez és meglévő szerződésekhez.

Források: Proxmox VE Administration Guide: tárolás, tárolóreplikáció és HA · Proxmox VE: aktuális támogatási árak · Proxmox Backup Server: aktuális támogatási árak.