Ceph biedt diverse methoden om gegevens binnen een gedistribueerde cluster te beveiligen, maar twee benaderingen vormen het grootste deel van de praktische keuzes: replicatie met drie kopieën, vaak aangeduid als Replica 3, en Erasure Coding, een techniek die gegevens opsplitst in fragmenten en pariteit toevoegt voor herstel bij storingen. De keuze is niet onbelangrijk. Het beïnvloedt de kosten per nuttige terabyte, prestaties, latentie, CPU-verbruik, operationele complexiteit en het soort workloads dat je het beste kunt hosten.
In een tijd waarin de prijs van capaciteit, datagroei en de druk om kosten te besparen steeds zwaarder wegen in opslagarchitecturen, is Erasure Coding opnieuw een veelbesproken onderwerp. Maar het vervangt Replica 3 niet zomaar. In Ceph heeft elke methode z’n eigen scenario’s waarin deze het beste tot zijn recht komt. Een verkeerde keuze kan een kostenbesparing op schijf opslag veranderen in problemen met prestaties of beschikbaarheid.
Replica 3: eenvoudig, snel en kostbaar in capaciteit
Replica 3 is de meest eenvoudige aanpak. Elk stuk data wordt opgeslagen in drie kopieën, verspreid over verschillende OSD’s, meestal verdeeld over knooppunten of foutdomeinen zoals bepaald door CRUSH. Bij een fout in een schijf blijven de andere twee kopieën beschikbaar. Als er een tweede OSD uitvalt onder gecontroleerde omstandigheden, blijft er altijd één kopie over. Deze eenvoud verklaart waarom het zo populair is in virtuele omgevingen, databases, VM-opslag en latency-gevoelige workloads.
Het grote voordeel is ook het grootste nadeel: voor elke 1 TB nuttige data worden 3 TB bruto opslag gebruikt. Met andere woorden, de overhead is 200%. Deze redundantie maakt de operatie overzichtelijker, minder rekencapaciteit nodig en voorspelbaar in lees- en schrijfsnelheid. Voor RBD, virtuele machines, virtuele schijven en kritieke diensten blijft Replica 3 een solide keuze.
De nadelen worden duidelijk bij groei van de gegevensvolumes. Honderden of duizenden terabytes in Replica 3 vereisen grote capaciteit, wat kostbaar kan zijn. Voor ‘koude’ data, grote repositories, kantoorbestanden, video, secundaire back-ups of workloads met veel lezen en weinig schrijven is deze aanpak mogelijk te duur.
Erasure Coding: meer nuttige capaciteit, meer rekentijd en meer planning
Erasure Coding werkt anders. In plaats van volledige kopieën op te slaan, splitst Ceph elk object in data-fragmenten, bepaald door de parameter k, en voegt pariteitsfragmenten toe, bepaald door m. Met deze fragmenten kan het systeem gegevens herstellen, zelfs als er een bepaald aantal OSD’s of foutdomeinen uitvallen. Volgens de documentatie van Ceph wordt dit model uitgelegd als het opsplitsen van een object in datachunks en codecchunks, opgeslagen op verschillende OSD’s.
Een profiel 4+2, bijvoorbeeld, verdeelt de data in vier fragmenten en voegt twee pariteitsfragmenten toe. Hierdoor is het mogelijk twee fragmenten te verliezen zonder data te verliezen, en vermindert de bruto opslagbehoefte vergeleken met Replica 3. Praktisch betekent dit dat om 100 TB nuttige data op te slaan, je ongeveer 150 TB bruto opslag nodig hebt, tegenover 300 TB bij Replica 3. De efficiëntie neemt toe, maar brengt ook extra kosten met zich mee: elke schrijfbewerking vereist pariteitsberekeningen, meer coördinatie tussen OSD’s en verhoogde gevoeligheid voor latentie, CPU-belasting, netwerk en blokgrootte.
| Profiel | Geschatte bruto capaciteit voor 100 TB nuttig | Storingen getolereerd | Gebruik |
|---|---|---|---|
| Replica 3 | 300 TB | 2 kopieën kunnen verloren gaan voordat data onbereikbaar wordt | Virtuele machines, databases, kritieke services |
| EC 2+1 | 150 TB | 1 fragment | Testomgevingen, niet-kritieke workloads |
| EC 4+2 | 150 TB | 2 fragmenten | Grote bestanden, koude data, repositories, back-ups |
| EC 6+3 | 150 TB | 3 fragmenten | High-capacity opslag met meer redundantie |
| EC 8+3 | 137,5 TB | 3 fragmenten | Kragende koude data op grote schaal |
| EC 8+4 | 150 TB | 4 fragmenten | Grote volumes met hogere fouttolerantie |
De tabel illustreert een vaak over het hoofd geziene realiteit: Erasure Coding vermindert niet altijd de capaciteit méér door extra pariteit. Wat verandert, is de balans tussen efficiëntie, redundantie, minimaal aantal OSD’s of knooppunten, en hersteltijd. Hoe ambitieuzer het profiel, des te crucialer de juiste klustering en ontwerp van het systeem.
Ceph beveelt aan dat de meeste deployments met Erasure Coded pools minimaal k+m foutdomeinen volgens CRUSH hebben, vaak bestaande uit hosts of racks. Belangrijk: het gaat niet alleen om schijven. Als alle fragmenten te geconcentreerd liggen, kan het verlies van één knooppunt meer fragmenten aantasten dan het profiel aankan.
Prestaties: waar wint elke methode
Replica 3 presteert meestal beter bij kleine writes, willekeurige workloads en latency-gevoelige diensten. Er hoeven geen pariteitsberekeningen of hersteloperaties uit te voeren te worden voor reguliere bewerkingen. Het systeem schrijft volledige kopieën, repliceert en bevestigt volgens de configuratie. Dit maakt het uitermate geschikt voor RBD, VM-schijven, databases, queues en transactiegedreven applicaties met veel kleine writes.
Erasure Coding blinkt uit wanneer capaciteitsefficiëntie en grote data belangrijker zijn dan absolute snelheid. Grote bestanden, object storage, document-repositories, multimedia, secundaire backups, wetenschappelijke datasets of archiefdata kunnen profiteren van minder overhead. Ceph’s documentatie omschrijft bijvoorbeeld een koud opslagpool met grote objecten en weinig writes als een ideaal scenario voor EC.
Het probleem ontstaat wanneer Erasure Coding ten onrechte wordt gebruikt alsof het Replica 3 is. Kleine writes kunnen vertraging veroorzaken, herstel na storingen kost meer CPU en netwerk, en in gedegradeerde situaties moet het systeem meerdere fragmenten lezen en opnieuw berekenen, wat de belastingsdruk verhoogt.
RBD, CephFS en allow_ec_overwrites
Jarenlang was een beperking van EC-pools dat ze vooral geschikt waren voor volledige objectschrijfsessies, zoals bij RGW. Sinds Ceph Luminous is het mogelijk allow_ec_overwrites aan te zetten, zodat ook partiale writes in EC-pools mogelijk worden, waardoor RBD, CephFS en RADOS kunnen opslaan in deze pools.
Dit betekent niet dat EC overal automatisch geschikt is voor VM-schijven. In RBD is het gebruikelijk een gerepliceerde pool te behouden voor metadata en een EC-pool voor data. Hoewel dit een pragmatische opzet is, vereist het begrip van de implicaties. Voor lichte VM-loads, grote bestanden of weinig gewijzigde data kan het zinvol zijn. Voor databases, actieve mailservers, ERP en workloads met veel kleine I/O’s blijft Replica 3 meestal de veiligere keuze.
In virtualisatie moet men niet vragen “Kan ik Erasure Coding gebruiken?”, maar “Wat voor I/O-patronen heeft deze workload?”. Bij veel kleine writes en lage latency-eisen wordt de besparing op disk vaak tenietgedaan door hogere CPU-belasting en complexere hersteltijden. Bij weinig writes en grote data kunnen EC-arrangementen voordelig zijn.
Praktische afweging: kosten versus gedrag
De vergelijking tussen Replica 3 en Erasure Coding begint vaak bij capaciteit, maar zou eindigen bij de dienstvereisten. Replica 3 verbruikt meer schijfcapaciteit, maar biedt eenvoudiger beheer en betere prestaties bij actieve workloads. EC bespaart ruimte, maar vereist meer rekenkracht, een snellere netwerkinfrastructuur, en een zorgvuldig ontwerp van foutdomeinen en profielen.
| Criterion | Replica 3 | Erasure Coding |
|---|---|---|
| Capaciteitsefficiëntie | Lage: 3 TB bruto per 1 TB nuttig | Hoog: afhankelijk van k+m |
| Latentie | Betere, vooral bij kleine writes | Hoger door rekening en distributie |
| CPU-verbruik | Lager | Hoger door pariteitsberekeningen en herstel |
| Operationele eenvoud | Hoger | Middel tot laag, afhankelijk van profiel |
| Herstel na storingen | Meer direct | Meer reken- en netwerkbelasting |
| Kritische VM’s | Aanbevolen | Enkel met voorzichtigheid en passende setup |
| Databases | Aanbevolen | Over het algemeen niet aanbevolen |
| Grote, koude data | Kan kostbaar zijn | Bij uitstek geschikt |
| Sekundaire back-ups | Idee, maar kostbaar | Geschikt, afhankelijk van prestatieniveau |
De beste architectuur combineert vaak beide benaderingen. Een Ceph-cluster kan Replica 3 pools gebruiken voor kritieke VM’s, databases en latency-gevoelige diensten, en EC-pools voor koude data, grote repositories en object storage. Deze scheiding optimiseert kosten en prestaties en voorkomt dat het hele systeem een riskante, uniforme strategie wordt.
Bovendien moet je niet vergeten dat Erasure Coding niet de strategie voor backups vervangt. Het beschermt tegen schijf- of knooppuntstoringen binnen het cluster, maar niet tegen per ongeluk verwijderen, logische corruptie, ransomware, menselijke fout of applicatieproblemen. Back-ups, retentie, hersteltests en off-site opslag blijven essentieel.
Ceph biedt grote flexibiliteit, maar die vraagt om zorgvuldig ontwerp. Replica 3 is de conservatieve keuze voor kritieke en actieve workloads. Erasure Coding is een krachtig hulpmiddel om nuttige capaciteit te vergroten, mits het patroon van gegevens dat toelaat. De juiste beslissing is niet een ‘winnende technologie’, maar het toewijzen van elke techniek op de plek waar het meeste waarde oplevert.
Veelgestelde vragen
Wat is het verschil tussen Replica 3 en Erasure Coding in Ceph?
Replica 3 bewaart drie volledige kopieën van de data. Erasure Coding deelt data op in fragmenten en voegt pariteit toe voor herstel bij storingen. Replica 3 verbruikt meer capaciteit, maar heeft doorgaans lagere latentie en minder complexiteit.
Wat betekent een EC-profiel 4+2?
Het betekent dat elk object is opgesplitst in vier data-fragmenten en twee pariteitsfragmenten. Het kan twee fragmenten verliezen en biedt betere capaciteitsefficiëntie dan Replica 3.
Kan ik Erasure Coding gebruiken voor virtuele machines?
Dat kan, mits de juiste configuraties zoals allow_ec_overwrites en gescheiden pools voor metadata en data. Maar het is niet altijd de beste keuze voor kritieke VM’s, databasestoepassingen of workloads met veel kleine writes.
Wanneer is het zinvol om Erasure Coding te gebruiken?
Voor grote bestanden, koude data, document-repositories, object storage, secundaire back-ups of data die weinig wijzigt en veel opslag vergt. Voor transactie-intensieve workloads of die met hoge latency-eisen is Replica 3 doorgaans veiliger en efficiënter.