Opslag is de plek waar de meeste private-cloudprojecten in stilte slagen of falen. Compute is makkelijk te doorgronden en makkelijk te vervangen. Netwerken is goed begrepen. Opslag is de laag die uw state vasthoudt, uw nalevingsverplichtingen draagt en het lastigst te migreren is zodra ze vol zit. Als u een soevereine of private cloud bouwt, is opslag het fundament en meestal het diepste deel van de bouw.
Dit is een leverancieronafhankelijke verkenning van wat soevereine opslag werkelijk betekent, de lagen waarvoor u moet ontwerpen, en een eerlijke kaart van de open-source opties. Wij bouwen deze systemen voor de kost en verkopen geen opslagproduct, dus het doel hier is u helpen goed te kiezen, niet u een stack opdringen.
Waarom opslag het moeilijke deel is
Drie dingen maken opslag de lastige hoek van een private cloud.
Ten eerste is ze stateful. U kunt een compute-node in minuten leegmaken en opnieuw opbouwen. Met de enige kopie van uw data kan dat niet. Elke ontwerpkeuze rond replicatie, erasure coding en back-up is een keuze over hoeveel dataverlies en downtime u kunt verdragen.
Ten tweede is het de plek waar soevereiniteit concreet wordt. Een workload die in een EU-datacenter draait, lekt nog steeds soevereiniteit als de opslaglaag wordt beheerd door een entiteit die onder buitenlandse openbaarmakingswetgeving valt. Dataresidentie en datasoevereiniteit zijn niet hetzelfde. Residentie gaat over waar bytes fysiek staan. Soevereiniteit gaat over wie er juridische en technische controle over heeft. Data die in een Frankfurt-regio van een Amerikaans geëxploiteerde hyperscaler staat, kan nog steeds onder de US CLOUD Act vallen, die een Amerikaans bedrijf kan dwingen data te overleggen ongeacht waar ze is opgeslagen. De EDPB is expliciet geweest dat sterke encryptie met sleutels die uitsluitend onder EER-controle worden gehouden, de aanvullende maatregel is die deze blootstelling adresseert. Opslag is precies waar u die controle implementeert.
Ten derde is ze operationeel onverbiddelijk. Gedistribueerde opslagsystemen hebben faalmodi die alleen op schaal of onder belasting verschijnen: split-brain, trage rebuilds, write amplification, full-cluster-condities. Dit goed krijgen vraagt om bewust ontwerp, niet om defaults.
De drie lagen: block, file, object
Een volledige private cloud heeft meestal alle drie de opslagtypen nodig. Ze zijn niet uitwisselbaar.
Blockopslag presenteert ruwe volumes aan een host, zoals een virtuele schijf. Het is wat virtuele machines en databases willen: lage latentie, willekeurig lezen en schrijven, single-writer-semantiek. Block is de ruggengraat voor hypervisor-workloads en stateful Kubernetes-pods.
Fileopslag presenteert een gedeeld POSIX-bestandssysteem dat veel clients tegelijk kunnen mounten. Het past bij gedeelde applicatiedata, home-directory’s, mediapipelines en oudere software die een pad op schijf verwacht. De afweging is dat gedistribueerde POSIX-semantiek echt lastig is, dus bestandssystemen zijn doorgaans de meest complexe laag om goed te beheren.
Objectopslag presenteert data als objecten in platte buckets, benaderd via HTTP met een S3-achtige API. Er is geen in-place overschrijven en geen bestandssysteemhiërarchie. In ruil daarvoor krijgt u effectief onbeperkte horizontale schaal, ingebouwde metadata en een schone pasvorm voor back-ups, datalakes, logs, AI-trainingscorpora en applicatie-assets. Objectopslag is de natuurlijke thuishaven voor het gros van de ongestructureerde data, en daarom staat ze centraal in de meeste soevereine-opslagontwerpen.
Software-defined storage, kort
Software-defined storage (SDS) ontkoppelt de opslaglogica van de hardware. In plaats van een propriëtaire appliance draait u open software over commodity-servers en laat u die de plaatsing, replicatie en healing afhandelen. Dat is wat soevereine opslag haalbaar maakt: de intelligentie is open, auditeerbaar en van u, en de hardware is uitwisselbaar. De kostprijs is dat u de operationele complexiteit zelf draagt, ofwel met uw eigen team ofwel via een managed-servicespartner.
Twee databeschermingsstrategieën lopen door alles hieronder:
- Replicatie houdt N volledige kopieën van elk stukje data. Eenvoudig, snel te herstellen, maar opslag-hongerig: 3x-replicatie betekent 3 TB ruwe schijf per 1 TB bruikbare data.
- Erasure coding splitst data in chunks plus pariteit, zodat u storingen overleeft terwijl u veel minder ruwe capaciteit gebruikt. Een typisch erasure-profiel geeft u vergelijkbare veerkracht als 3x-replicatie terwijl het ruwweg 1,5x ruwe capaciteit nodig heeft. De afweging is meer CPU, tragere kleine schrijfacties en langere rebuilds.
Een brede kaart van open-source opties
Er bestaat geen enkele juiste tool. De juiste keuze hangt af van schaal, de protocollen die u nodig heeft, de diepgang van uw team en waar de workload leeft. Hier is een eerlijk landschap.
Ceph is het referentieplatform voor unified SDS. Eén cluster bedient alle drie de lagen: RBD voor block, CephFS voor file en de RADOS Gateway (RGW) voor S3- en Swift-compatibele objectopslag. Het schaalt naar petabytes, ondersteunt replicatie en erasure coding, en heelt zichzelf. De kostprijs is reële operationele complexiteit: het is het veeleisendste systeem hier om veilig te draaien, en het is hongerig naar RAM en CPU. Rook is de operator die Ceph native binnen Kubernetes draait en veel van het dag-twee-werk wegneemt. Ceph is het standaardantwoord wanneer u één platform voor alles op schaal wilt.
LINSTOR met DRBD kiest een ander pad: blockreplicatie op kernelniveau, in essentie synchrone RAID-1 over servers, georkestreerd door LINSTOR. Het levert bijna-native schijfprestaties met zeer lage overhead, wat het sterk maakt voor latentiegevoelige databases en VM’s. Het is block-only, en de opzet omvat kernelmodules en LVM, dus het is minder plug-and-play. Piraeus brengt LINSTOR naar Kubernetes.
Specifiek voor S3-compatibele objectopslag is het veld recent verschoven en dat is goed om te weten:
- MinIO was jarenlang de standaard lichtgewicht S3-server. De community-editie is nu effectief end-of-life: de adminconsole werd eruit gestript, de binaire distributie stopte, en de GitHub-repository werd in februari 2026 gearchiveerd. De AGPL-licentie die het aannam betekent dat de code geforkt kan worden (en is geforkt), maar de upstream community-editie wordt niet meer onderhouden. Behandel bestaande deployments als iets dat een migratieplan nodig heeft.
- Garage is een lichtgewicht, gedistribueerde objectstore ontworpen voor geo-redundante deployments over gescheiden sites. Geen master-node, alleen peers, zone-bewuste replicaplaatsing, draait op bescheiden hardware en ARM. Uitstekend voor multi-site- en edge-soevereiniteit. AGPL-3.0.
- SeaweedFS is volwassen, snel en bijzonder goed met zeer grote aantallen kleine objecten. Het biedt S3, FUSE en WebDAV, heeft solide Kubernetes-integratie en is gelicentieerd onder Apache-2.0. Een sterke generieke keuze op schaal.
Voor Kubernetes-native persistente volumes:
- Longhorn is de eenvoudigste gedistribueerde blockopslag voor Kubernetes: makkelijk te draaien, goede UI, snapshots en back-ups ingebouwd. Het best voor edge en kleine tot middelgrote clusters; de latentie kan pieken onder zware belasting.
- OpenEBS is modulair; de Mayastor-engine geeft hoge IOPS met lagere CPU-kost dan Ceph, gericht op block, zonder objectfuncties.
Voor het opslagsubstraat zelf:
- ZFS is het gouden standaard lokale bestandssysteem: checksumming, snapshots, compressie, native encryptie. Het vormt de onderlaag van veel van de bovengenoemde systemen als de per-node-laag.
- GlusterFS is een scale-out netwerkbestandssysteem dat nog steeds in productie wordt aangetroffen, hoewel het momentum duidelijk is verschoven richting Ceph en object-first-ontwerpen voor nieuwe bouwen.
S3-compatibele opslag als het soevereine alternatief voor AWS S3
De S3-API is de de facto standaard voor objectopslag geworden, wat goed nieuws is voor soevereiniteit. Omdat zoveel software S3 spreekt, kunt u een S3-compatibele store op uw eigen infrastructuur draaien (Ceph RGW, Garage, SeaweedFS) en dezelfde applicatiecode, dezelfde back-uptooling en dezelfde datalake-engines behouden, terwijl uw data binnen uw jurisdictie onder uw sleutels blijft. U krijgt de developer-ergonomie van S3 zonder de juridische blootstelling van een buitenlands geëxploiteerde cloud. Dit is de zet met de meeste hefboomwerking in de meeste soevereine-opslagontwerpen.
Encryptie, sleutelcontrole en residentie
Soevereiniteit wordt afgedwongen aan de sleutelgrens, niet aan de muur van het datacenter.
- Encryptie at rest zou aan moeten staan op elke laag die het ondersteunt, van ZFS tot aan de objectgateway.
- Sleutelcontrole is de kern. Als een derde partij uw data kan ontsleutelen, bent u niet soeverein, ongeacht waar de schijven staan. Houd sleutels in een EU-gecontroleerde KMS of HSM, gescheiden van de opslagbeheerder, zodat geen buitenlandse entiteit openbaarmaking van bruikbare data kan afdwingen.
- Residentie blijft van belang: pin de plaatsing vast op EU-regio’s en bewijs het. Maar residentie zonder sleutelcontrole is theater.
Back-up en disaster recovery
Replicatie is geen back-up. Ze kopieert uw fouten getrouw mee. Een echt soeverein opslagontwerp heeft onafhankelijke back-ups (idealiter immutable, in object-lock-stijl) en een geteste DR-plan: cross-site-replicatie voor objectdata, snapshot-gebaseerd herstel voor block en file, en regelmatige restore-oefeningen. De storing die u niet hebt geoefend is degene die pijn zal doen.
Zelf draaien of managed
Open-source SDS verwijdert de licentie-lock-in, niet de operationele last. De eerlijke splitsing:
- Zelf draaien wanneer u een opslag-capabel platformteam heeft en volledige controle wilt. Budgetteer voor echte on-call en diepe expertise; Ceph in het bijzonder bestraft krappe bezetting.
- Managed wanneer u soevereine, open-source opslag wilt maar geen pieper om 3 uur ‘s nachts voor een gedegradeerd cluster. Een leverancieronafhankelijke partner kan de stack ontwerpen, bouwen en beheren op uw infrastructuur, binnen uw jurisdictie, met uw sleutels, en deze teruggeven wanneer u maar wilt.
FAQ
Is objectopslag op zichzelf genoeg? Zelden. Object dekt het gros van de ongestructureerde data, maar VM’s en databases hebben block nodig, en gedeelde applicatiedata heeft vaak file nodig. De meeste private clouds draaien alle drie.
Ceph of iets lichters? Ceph als u één platform voor block, file en object op schaal wilt en het kunt bemensen. Lichtere, single-purpose tools (Garage of SeaweedFS voor object, Longhorn of LINSTOR voor block) zijn makkelijker te draaien wanneer u geen unified platform nodig heeft.
Betekent S3-compatibel precies hetzelfde als AWS S3? De kern-API is grotendeels compatibel, en daarom verlopen migraties meestal soepel. Randfuncties en consistentiegaranties verschillen, dus valideer de specifieke operaties waarvan uw applicaties afhankelijk zijn.
Hoe zit het met de MinIO-situatie? De community-editie wordt sinds begin 2026 niet meer onderhouden. Bestaande gebruikers zouden een migratie naar een onderhouden alternatief of een ondersteunde fork moeten plannen.
Waar Rapid Solutions past
Wij zijn een leverancieronafhankelijke engineeringconsultancy en managed-servicespartner, geen cloudprovider. Wij ontwerpen en beheren soevereine, open-source-first opslag op infrastructuur die u beheert, met EU-dataresidentie en sleutels die in uw handen blijven. Wij passen ons aan uw stack aan in plaats van u de onze te verkopen.
Plant u een private cloud of denkt u opnieuw na over waar uw data leeft? Neem contact met ons op.