Souveräner Speicher: Software-Defined und Object Storage für die Private Cloud

Speicher ist der Punkt, an dem die meisten Private-Cloud-Projekte still und leise gelingen oder scheitern. Compute ist leicht zu durchdenken und leicht zu ersetzen. Netzwerk ist gut verstanden. Speicher ist die Schicht, die Ihren Zustand hält, Ihre Compliance-Pflichten trägt und am schwersten zu migrieren ist, sobald sie voll ist. Wenn Sie eine souveräne oder Private Cloud bauen, ist Speicher das Fundament und meist der tiefste Teil des Aufbaus.

Dies ist ein herstellerneutraler Rundgang durch das, was souveräner Speicher tatsächlich bedeutet, durch die Schichten, für die Sie entwerfen müssen, und durch eine ehrliche Übersicht der Open-Source-Optionen. Wir bauen diese Systeme beruflich und verkaufen kein Speicherprodukt, daher ist das Ziel hier, Ihnen bei einer guten Wahl zu helfen, nicht Ihnen einen Stack aufzudrängen.

Warum Speicher der schwierige Teil ist

Drei Dinge machen Speicher zur schwierigen Ecke einer Private Cloud.

Erstens ist er zustandsbehaftet. Sie können einen Compute-Knoten in Minuten leeren und neu aufbauen. Mit der einzigen Kopie Ihrer Daten können Sie das nicht. Jede Designentscheidung rund um Replikation, Erasure Coding und Backup ist eine Entscheidung darüber, wie viel Datenverlust und Ausfallzeit Sie tolerieren können.

Zweitens ist es der Ort, an dem Souveränität konkret wird. Eine Arbeitslast, die in einem EU-Rechenzentrum läuft, verliert dennoch ihre Souveränität, wenn die Speicherschicht von einer Einheit betrieben wird, die ausländischem Offenlegungsrecht unterliegt. Datenresidenz und Datensouveränität sind nicht dasselbe. Residenz ist, wo die Bytes physisch liegen. Souveränität ist, wer rechtliche und technische Kontrolle über sie hat. Daten, die in einer Frankfurt-Region eines US-betriebenen Hyperscalers liegen, können dennoch unter den US CLOUD Act fallen, der ein US-Unternehmen zur Herausgabe von Daten zwingen kann, unabhängig davon, wo sie gespeichert sind. Der EDSA hat ausdrücklich klargestellt, dass starke Verschlüsselung mit Schlüsseln, die ausschließlich unter EWR-Kontrolle gehalten werden, die ergänzende Maßnahme ist, die dieses Risiko adressiert. Speicher ist genau der Ort, an dem Sie diese Kontrolle umsetzen.

Drittens ist er im Betrieb unnachgiebig. Verteilte Speichersysteme haben Fehlerzustände, die nur bei großer Skalierung oder unter Last auftreten: Split-Brain, langsame Rebuilds, Write Amplification, Vollauslastung des Clusters. Das richtig hinzubekommen erfordert bewusstes Design, keine Standardeinstellungen.

Die drei Schichten: Block, File, Object

Eine vollständige Private Cloud benötigt in der Regel alle drei Speichertypen. Sie sind nicht austauschbar.

Block-Storage präsentiert einem Host rohe Volumes, ähnlich einer virtuellen Festplatte. Genau das wollen virtuelle Maschinen und Datenbanken: geringe Latenz, wahlfreies Lesen und Schreiben, Single-Writer-Semantik. Block ist das Rückgrat für Hypervisor-Workloads und zustandsbehaftete Kubernetes-Pods.

File-Storage präsentiert ein gemeinsames POSIX-Dateisystem, das viele Clients gleichzeitig einhängen können. Es passt zu gemeinsam genutzten Anwendungsdaten, Home-Verzeichnissen, Medien-Pipelines und Altsoftware, die einen Pfad auf der Festplatte erwartet. Der Kompromiss ist, dass verteilte POSIX-Semantik wirklich schwierig ist, weshalb Dateisysteme tendenziell die komplexeste Ebene sind, um sie gut zu betreiben.

Object-Storage präsentiert Daten als Objekte in flachen Buckets, die über HTTP mit einer S3-artigen API angesprochen werden. Es gibt kein In-Place-Überschreiben und keine Dateisystemhierarchie. Im Gegenzug erhalten Sie praktisch unbegrenzte horizontale Skalierung, integrierte Metadaten und eine saubere Eignung für Backups, Data Lakes, Logs, KI-Trainingskorpora und Anwendungsassets. Object-Storage ist die natürliche Heimat für den Großteil unstrukturierter Daten, weshalb es im Zentrum der meisten souveränen Speicherdesigns steht.

Software-Defined Storage, kurz erklärt

Software-Defined Storage (SDS) entkoppelt die Speicherlogik von der Hardware. Statt einer proprietären Appliance betreiben Sie offene Software über Standardserver hinweg und lassen sie Platzierung, Replikation und Healing übernehmen. Genau das macht souveränen Speicher erreichbar: Die Intelligenz ist offen, prüfbar und gehört Ihnen, und die Hardware ist austauschbar. Der Preis dafür ist, dass Ihnen die operative Komplexität gehört, entweder mit dem eigenen Team oder über einen Managed-Services-Partner.

Zwei Datenschutzstrategien ziehen sich durch alles Folgende:

• Replikation hält N vollständige Kopien jedes Datenstücks. Einfach, schnell wiederherstellbar, aber speicherhungrig: 3-fache Replikation bedeutet 3 TB rohe Festplattenkapazität pro 1 TB nutzbarer Daten.
• Erasure Coding teilt Daten in Chunks plus Parität auf, sodass Sie Ausfälle überstehen und dabei weit weniger Rohkapazität verbrauchen. Ein typisches Erasure-Profil bietet Ihnen ähnliche Ausfallsicherheit wie 3-fache Replikation, benötigt aber nur etwa die 1,5-fache Rohkapazität. Der Kompromiss ist mehr CPU-Last, langsamere kleine Schreibvorgänge und längere Rebuilds.

Eine breite Übersicht der Open-Source-Optionen

Es gibt nicht das eine richtige Werkzeug. Die richtige Wahl hängt von der Skalierung, den benötigten Protokollen, der Tiefe Ihres Teams und davon ab, wo die Arbeitslast läuft. Hier eine ehrliche Landschaft.

Ceph ist die Referenzplattform für vereinheitlichtes SDS. Ein Cluster bedient alle drei Schichten: RBD für Block, CephFS für File und das RADOS Gateway (RGW) für S3- und Swift-kompatiblen Object-Storage. Es skaliert auf Petabytes, unterstützt Replikation und Erasure Coding und heilt sich selbst. Der Preis ist echte operative Komplexität, es ist das anspruchsvollste System hier, um es sicher zu betreiben, und es ist hungrig auf RAM und CPU. Rook ist der Operator, der Ceph nativ innerhalb von Kubernetes betreibt und einen Großteil der Day-2-Mühen abnimmt. Ceph ist die Standardantwort, wenn Sie eine Plattform für alles bei großer Skalierung wollen.

LINSTOR mit DRBD geht einen anderen Weg: Blockreplikation auf Kernel-Ebene, im Wesentlichen synchrones RAID-1 über Server hinweg, orchestriert durch LINSTOR. Es liefert nahezu native Festplattenleistung mit sehr geringem Overhead, was es stark für latenzempfindliche Datenbanken und VMs macht. Es ist nur für Block, und das Setup umfasst Kernelmodule und LVM, daher ist es weniger Plug-and-Play. Piraeus bringt LINSTOR zu Kubernetes.

Speziell für S3-kompatiblen Object-Storage hat sich das Feld kürzlich verschoben, und es lohnt sich, das zu wissen:

• MinIO war jahrelang der Standard-S3-Server der Leichtgewichtsklasse. Seine Community-Edition ist nun faktisch am Ende ihres Lebenszyklus: Die Admin-Konsole wurde entfernt, die Binärverteilung eingestellt und das GitHub-Repository im Februar 2026 archiviert. Die AGPL-Lizenz, die es übernommen hat, bedeutet, dass der Code geforkt werden kann (und wurde), aber die Upstream-Community-Edition wird nicht mehr gepflegt. Behandeln Sie bestehende Deployments als solche, die einen Migrationsplan benötigen.
• Garage ist ein leichtgewichtiger, verteilter Objektspeicher, der für georedundante Deployments über getrennte Standorte hinweg konzipiert ist. Kein Master-Knoten, alles Peers, zonenbewusste Platzierung der Replikas, läuft auf bescheidener Hardware und ARM. Hervorragend für Multi-Site- und Edge-Souveränität. AGPL-3.0.
• SeaweedFS ist ausgereift, schnell und besonders gut bei sehr großen Mengen kleiner Objekte. Es bietet S3, FUSE und WebDAV, hat eine solide Kubernetes-Integration und ist unter Apache-2.0 lizenziert. Eine starke Allzweckwahl bei großer Skalierung.

Für Kubernetes-native persistente Volumes:

• Longhorn ist der einfachste verteilte Block-Storage für Kubernetes: leicht zu betreiben, gute UI, Snapshots und Backups integriert. Am besten für Edge und kleine bis mittlere Cluster geeignet; die Latenz kann unter starker Last ausschlagen.
• OpenEBS ist modular; seine Mayastor-Engine bietet hohe IOPS mit geringeren CPU-Kosten als Ceph, mit Fokus auf Block, ohne Object-Funktionen.

Für das Speichersubstrat selbst:

• ZFS ist der Goldstandard unter den lokalen Dateisystemen: Checksumming, Snapshots, Komprimierung, native Verschlüsselung. Es bildet die Grundlage vieler der oben genannten Systeme als Schicht pro Knoten.
• GlusterFS ist ein Scale-out-Netzwerkdateisystem, das noch in Produktion zu finden ist, auch wenn die Dynamik für neue Builds klar in Richtung Ceph und Object-First-Designs gegangen ist.

S3-kompatibler Speicher als souveräne Alternative zu AWS S3

Die S3-API ist zum De-facto-Standard für Object-Storage geworden, was eine gute Nachricht für die Souveränität ist. Weil so viel Software S3 spricht, können Sie einen S3-kompatiblen Speicher auf Ihrer eigenen Infrastruktur betreiben (Ceph RGW, Garage, SeaweedFS) und denselben Anwendungscode, dasselbe Backup-Tooling, dieselben Data-Lake-Engines behalten, während Ihre Daten in Ihrer Jurisdiktion unter Ihren Schlüsseln bleiben. Sie erhalten die Entwicklerergonomie von S3 ohne das rechtliche Risiko einer ausländisch betriebenen Cloud. Dies ist der hebelstärkste Schritt in den meisten souveränen Speicherdesigns.

Verschlüsselung, Schlüsselkontrolle und Residenz

Souveränität wird an der Schlüsselgrenze durchgesetzt, nicht an der Wand des Rechenzentrums.

• Verschlüsselung im Ruhezustand sollte auf jeder Schicht aktiviert sein, die sie unterstützt, von ZFS bis hinauf zum Object-Gateway.
• Schlüsselkontrolle ist der Kernpunkt. Wenn ein Dritter Ihre Daten entschlüsseln kann, sind Sie nicht souverän, egal wo die Festplatten liegen. Halten Sie Schlüssel in einem EU-kontrollierten KMS oder HSM, getrennt vom Speicherbetreiber, damit keine ausländische Einheit die Offenlegung nutzbarer Daten erzwingen kann.
• Residenz spielt weiterhin eine Rolle: Verankern Sie die Platzierung in EU-Regionen und weisen Sie es nach. Aber Residenz ohne Schlüsselkontrolle ist Theater.

Backup und Disaster Recovery

Replikation ist kein Backup. Sie kopiert Ihre Fehler getreu mit. Ein echtes souveränes Speicherdesign hat unabhängige Backups (idealerweise unveränderlich, im Object-Lock-Stil) und einen getesteten DR-Plan: standortübergreifende Replikation für Objektdaten, snapshotbasierte Wiederherstellung für Block und File sowie regelmäßige Restore-Übungen. Der Ausfall, den Sie nicht geprobt haben, ist der, der wehtun wird.

Selbst betrieben oder verwaltet

Open-Source-SDS beseitigt das Lizenz-Lock-in, nicht die operative Last. Die ehrliche Aufteilung:

• Selbst betrieben, wenn Sie ein speicherfähiges Plattformteam haben und volle Kontrolle wollen. Planen Sie Budget für echte Rufbereitschaft und tiefe Expertise ein; insbesondere Ceph bestraft dünne Personaldecke.
• Verwaltet, wenn Sie souveränen Open-Source-Speicher wollen, aber keinen Pager um 3 Uhr nachts für einen degradierten Cluster. Ein herstellerneutraler Partner kann den Stack auf Ihrer Infrastruktur, in Ihrer Jurisdiktion, mit Ihren Schlüsseln entwerfen, aufbauen und betreiben und ihn jederzeit an Sie zurückgeben, wann immer Sie wollen.

FAQ

Reicht Object-Storage allein aus? Selten. Object deckt den Großteil unstrukturierter Daten ab, aber VMs und Datenbanken benötigen Block, und gemeinsam genutzte Anwendungsdaten benötigen oft File. Die meisten Private Clouds betreiben alle drei.

Ceph oder etwas Leichteres? Ceph, wenn Sie eine Plattform für Block, File und Object bei großer Skalierung wollen und sie personell besetzen können. Leichtere, zweckgebundene Werkzeuge (Garage oder SeaweedFS für Object, Longhorn oder LINSTOR für Block) sind einfacher zu betreiben, wenn Sie keine vereinheitlichte Plattform brauchen.

Bedeutet S3-kompatibel genau wie AWS S3? Die Kern-API ist weitgehend kompatibel, weshalb Migrationen meist reibungslos verlaufen. Randfunktionen und Konsistenzgarantien variieren, daher validieren Sie die konkreten Operationen, von denen Ihre Anwendungen abhängen.

Was ist mit der MinIO-Situation? Die Community-Edition wird seit Anfang 2026 nicht mehr gepflegt. Bestehende Nutzer sollten eine Migration zu einer gepflegten Alternative oder einem unterstützten Fork planen.

Wo Rapid Solutions ins Bild passt

Wir sind eine herstellerneutrale Engineering-Beratung und ein Managed-Services-Partner, kein Cloud-Anbieter. Wir entwerfen und betreiben souveränen, Open-Source-First-Speicher auf einer Infrastruktur, die Sie kontrollieren, mit EU-Datenresidenz und Schlüsseln, die in Ihren Händen bleiben. Wir passen uns an Ihren Stack an, statt Ihnen unseren zu verkaufen.

Wenn Sie eine Private Cloud planen oder neu überdenken, wo Ihre Daten liegen, sprechen Sie mit uns.