Object Storage-tiers en lifecycle: twee redundantieklassen, geen archieftier
Kort antwoord
Worldstream Object Storage heeft twee tiers, en allebei zijn het redundantieklassen: Distributed Storage en Geo-Redundant Storage. Er is geen cold of archieftier en geen Glacier-achtig product, dus er is geen goedkopere tier om oudere data naartoe te schuiven en geen transitieregel om te schrijven. Archiveren doe je óp Object Storage, het is geen aparte storageklasse die je afneemt.
Twee tiers, allebei over redundantie
Als mensen het over "tiers" in object storage hebben, bedoelen ze meestal een van twee dingen. Het eerste is toegangsfrequentie: hot data op snelle opslag, cold data op iets goedkopers en tragers. Het tweede is redundantie: hoeveel kopieën er bestaan en welke storing die overleven. Worldstream Object Storage kent alleen dat tweede soort.
| Tier | Waar het tegen beschermt | Gepositioneerd als |
|---|---|---|
| Distributed Storage | Redundante servers, schijven en netwerk binnen één datacenter. Wordt read-only als dat datacenter wegvalt. | Standaard |
| Geo-Redundant Storage | Multi-site replicatie. Kan een volledige datacenteruitval overleven. | Premium |
Je kiest er één per project, op het moment dat je het project aanmaakt, en beide zijn op dit moment beschikbaar in de regio eu-west-1. Lezen en schrijven gaat op allebei hetzelfde. Geen van beide tiers maakt je data trager op te halen of zet er een restore-stap voor.
Wat er verandert als je van Amazon S3 komt
Op Amazon S3 verwacht je een ladder van storageklassen, van Standard via Infrequent Access naar Glacier, met lifecycle-regels die objecten die ladder aflopen naarmate ze ouder worden. Worldstream Object Storage heeft die ladder niet. Geen archiefklasse, geen cold klasse, en niets wat een restore vereist voordat je een object weer kunt lezen.
Dat heeft twee praktische gevolgen. Ten eerste heeft een transitieregel hier geen bestemming, dus het kostenpatroon "bewaren, maar dan goedkoop" bestaat niet als productfunctie. Ten tweede loop je ook nooit tegen de keerzijde van die afspraak aan: geen wachttijd bij ophalen, geen restore-aanvraag, geen verrassing als het compliance-archief dat je drie jaar niet hebt aangeraakt vandaag ineens nodig is.
"Archivering" op Worldstream Object Storage is een use case, geen storageklasse. Langlopende archieven staan op dezelfde opslag als al het andere, en je kiest er een redundantieklasse bij zoals je dat voor de rest ook doet. Ga je overstappen, dan behandelt Migreren van AWS S3 naar Worldstream Object Storage de overige verschillen.
Lifecycle-regels op Object Storage
Eén ding staat vast: geen enkele lifecycle-regel kan een object naar een goedkopere tier verplaatsen, want die tier bestaat niet. Alles wat je op een ander platform hebt geschreven om tussen storageklassen te schuiven, heeft hier geen tegenhanger.
Welke lifecycle-regels de S3-compatible API wél accepteert, vervalregels inbegrepen, staat niet in deze kennisbank, en ernaar gokken kost je een deployment. Check de Object Storage CLI & SDK-gids in Portal onder Support → Documentation voor het actuele beeld, of open een supportticket, voordat je een beleid bouwt waar je opschoning van afhangt.
Test het beleid, ga er niet van uit: Hoeveel van het bredere S3-API-oppervlak ondersteund wordt, verschilt per onderdeel. Zet je een lifecycle-configuratie weg, lees die dan terug met
aws s3api get-bucket-lifecycle-configurationen controleer of het platform bewaard heeft wat je hebt gestuurd. Een aanroep die geen fout gaf, heeft niet automatisch gedaan wat je bedoelde.
Datagroei beheersen zonder cold tier
Zonder tiering blijven de gewone knoppen over, en die werken:
| Knop | Hoe het hier werkt |
|---|---|
| Verwijder wat je niet meer nodig hebt | Bij Pay per use betaal je voor wat je daadwerkelijk opslaat, dus data weggooien die je hebt laten vervallen is de meest directe besparing die er is. |
| Regel retentie waar de data ontstaat | Laat je backuptool of log shipper zijn eigen oude generaties laten vervallen, in plaats van te verwachten dat de bucket dat voor je doet. |
| Splits op redundantieklasse | Niets houdt je tegen om één Geo-Redundant project te draaien voor wat een siteuitval moet overleven en een Distributed project voor wat dat niet hoeft. Dat komt het dichtst bij een tiering-keuze. |
| Zet vast wat niet weg mag | Object Lock zet je aan bij het aanmaken van een bucket en kun je daarna niet meer uitzetten. Het is het juiste middel voor een compliance-archief, en het is een keuze die je maakt voordat het eerste object binnenkomt. |
Hoe lang je welke backup-generatie bewaart, is een andere vraag dan waar die staat. Hoeveel backups heb je écht nodig? Een gids voor je retentiestrategie behandelt de retentiekant.
Volgende stap: open Object Storage in Portal, check welke redundantieklasse je bestaande projecten gebruiken, en klopt die verdeling niet bij wat je opslaat, maak dan een tweede project aan met de andere klasse. De standaardwaarden voor buckets en keys per project staan in Limieten en quota's van Object Storage uitgelegd.