Passendes Verhalten
Block, File, Object, lokal oder verteilt verhalten sich sehr unterschiedlich. Wir wählen Storage nach Workload, Latenz, Wachstum und Wiederherstellungsziel, nicht nach Produktkategorie.
Datacenter
Storage ist ein Betriebsverhalten, kein Regal voller Disks.
Storage entscheidet sich nicht am Terabyte-Preis. Für VMs, Datenbanken, Backups und Archive zählen Latenz, nutzbare Kapazität, Ausfallverhalten und ein Recovery-Pfad, der im Ernstfall bereits getestet wurde.
Was Storage entscheidet
Offene Betriebsmodelle
Ceph, ZFS und offene Protokolle machen Abhängigkeiten sichtbar. Das reduziert Black-Box-Risiken und erleichtert Monitoring, Recovery und Kapazitätsplanung.
Kosten transparent
Replikationsfaktor, Erasure Coding, NVMe-Anteil, Support, Netzwerk und Backup entscheiden über die realen Kosten pro nutzbarem Terabyte.
Wann Storage zum Thema wird
Wenn das Storage schneller wächst als der Plan dahinter.
VMs, Datenbanken oder Backups wachsen schneller als das bestehende Storage-System.
SAN- oder Appliance-Lizenzen werden teuer, während Kapazität und Performance weiter steigen müssen.
Snapshots, Replikation, Object Lock oder S3-kompatible Ablage werden für Backup und Compliance relevant.
Ein Cluster soll ohne Single Point of Failure laufen, aber das Storage-Netz ist noch nicht dafür ausgelegt.
RTO und RPO sind fachlich gewünscht, technisch aber noch nicht getestet oder dokumentiert.
Lösungswege
Nicht jedes Storage-Problem braucht dieselbe Plattform.
Ceph, ZFS, SAN und Object Storage haben unterschiedliche Stärken. Entscheidend sind Zugriffsmuster, Betriebsteam, Ausfallmodell und Kosten pro nutzbarem Terabyte.
Ceph für verteiltes Storage
RBD für VM-Blockstorage, CephFS für File-Workloads und RGW für S3-kompatibles Object Storage. Stark, wenn Cluster, Netzwerk und Betrieb sauber geplant sind.
ZFS für lokale Pools
Sehr stark für einzelne Hosts, Backup-Ziele, Snapshots, Replikation und Datenintegrität. Nicht automatisch ein Ersatz für ein verteiltes HA-Storage.
SAN / Appliance gezielt
NetApp, Dell, Pure oder andere Enterprise-Systeme bleiben sinnvoll, wenn Supportvertrag, bekannte Betriebsabläufe oder Spezialfunktionen wichtiger sind als maximale Offenheit.
Vorgehen
Erst das Datenverhalten verstehen, dann die Plattform wählen.
01
02
03
04
05
Daten & Workloads
VMs, Datenbanken, Files, Backups, Object-Daten, Wachstum, IOPS, Durchsatz und Latenz erfassen.
RTO / RPO klären
Festlegen, wie viel Datenverlust und Wiederanlaufzeit fachlich akzeptabel sind.
Architektur & Sizing
Ceph, ZFS, SAN oder Object Storage mit Kapazität, Redundanz, Netzwerk und Medienmix dimensionieren.
Aufbau & Tests
Cluster, Pools, Netztrennung, Monitoring, Scrubbing, Snapshots und Recovery-Abläufe technisch prüfen.
Betrieb & Wachstum
Kapazitätsgrenzen, Austausch defekter Medien, Updates und Restore-Tests in den Betrieb übernehmen.
01
Daten & Workloads
VMs, Datenbanken, Files, Backups, Object-Daten, Wachstum, IOPS, Durchsatz und Latenz erfassen.
02
RTO / RPO klären
Festlegen, wie viel Datenverlust und Wiederanlaufzeit fachlich akzeptabel sind.
03
Architektur & Sizing
Ceph, ZFS, SAN oder Object Storage mit Kapazität, Redundanz, Netzwerk und Medienmix dimensionieren.
04
Aufbau & Tests
Cluster, Pools, Netztrennung, Monitoring, Scrubbing, Snapshots und Recovery-Abläufe technisch prüfen.
05
Betrieb & Wachstum
Kapazitätsgrenzen, Austausch defekter Medien, Updates und Restore-Tests in den Betrieb übernehmen.
Technische Bausteine
Bausteine, die zu Latenz und Recovery passen.
Eine Auswahl typischer Bausteine, herstellerunabhängig und bewusst nicht abschließend. Wir favorisieren diese Optionen, legen uns aber nicht darauf fest.
Verteiltes Storage
CephRBDCephFSRGW / S3CRUSHErasure Coding
Lokales Storage
ZFSSnapshotszfs send/recvScrubMirrorRAIDZ
Protokolle
iSCSINFSSMBS3NVMe/TCPFibre Channel
Medien
NVMeSSDHDDHybrid PoolsWrite Endurance
Datenschutz
SnapshotsObject LockImmutable BackupReplikationOffsite Copy
Betrieb
MonitoringCapacity PlanningRecovery-TestAnsibleDokumentation
Was Storage wirklich kostet
Der Terabyte-Preis ist die harmloseste Zahl.
Nutzbare statt roher Kapazität, das Storage-Netz, der NVMe-Anteil und getestete Restores bestimmen den realen Preis pro Terabyte. Diese Posten machen wir vor der Entscheidung sichtbar.
Faustregel
Storage ist eine Kette aus Medien, Netz und getestetem Restore. Die schwächste Stelle bestimmt das Verhalten.
Nutzbare statt rohe Kapazität
Bei drei Replikas wird aus 300 TB roh grob 100 TB nutzbar, mit Reserve für Rebuild und Betrieb etwas weniger. Erasure Coding nutzt den Platz effizienter, eignet sich aber eher für Object Storage, Backup und Archiv als für latenzkritischen VM-Block-Storage.
NVMe dort, wo es wirkt
Komplette NVMe-Cluster sind teuer. Oft reicht ein gezielter Mix aus NVMe, SSD und HDD, wenn Hot Data, DB-Workloads und Backup sauber getrennt werden.
Netzwerk ist Teil des Storage
Ceph, iSCSI und NVMe/TCP werden durch ein schlechtes Netzwerk langsam oder instabil. Storage-Kosten müssen Switches, Optiken und Design enthalten.
Backup ist keine HA
Ein hochverfügbarer Cluster schützt nicht vor Löschung, Verschlüsselung oder Bedienfehlern. Backup, Object Lock und Restore-Tests bleiben eigene Kostenpositionen.
Einsatzszenarien
Wofür wir Storage bauen.
VM-Storage
RBD, SAN oder NVMe/TCP für Virtualisierungs-Cluster mit klaren Latenz- und HA-Zielen.
Backup-Ziel
ZFS, Object Storage oder S3-kompatible Targets mit Snapshots, Immutability und Restore-Tests.
Dateidienste
CephFS, NFS, SMB oder Appliance-Storage für gemeinsame Daten und strukturierte Berechtigungen.
Object Storage
S3-kompatible Ablage für Anwendungen, Backups, Archivierung oder Kubernetes-Workloads.
Bevor Sie Storage kaufen.
Fragen, die das Sizing entscheiden.
Antworten auf typische Fragen zu Ceph, ZFS, SAN, Object Storage, RTO/RPO, Backup und getesteten Recovery-Pfaden.
Storage-Architektur besprechenNein. Ceph ist stark für verteiltes, skalierbares Storage, braucht aber mehrere Nodes, saubere Netzwerke, Monitoring und Betriebserfahrung. Für kleinere Setups, Backup-Ziele oder lokale Performance ist ZFS oft einfacher und wirtschaftlicher. Für bestimmte Enterprise-Anforderungen kann auch ein klassisches SAN sinnvoll bleiben.
Für produktive Hochverfügbarkeit ist ein Drei-Node-Design der typische Einstieg, weil Mehrheiten, Replikation und Ausfallverhalten sonst schnell schwierig werden. Es gibt Sonderfälle, aber die planen wir bewusst und nicht als Standard.
Block Storage stellt virtuelle Platten bereit, zum Beispiel für VMs. File Storage stellt Dateisysteme bereit, etwa NFS oder SMB. Object Storage speichert Daten als Objekte über APIs wie S3. Die Wahl entscheidet über Performance, Zugriffsmuster, Rechte, Backup und Kosten.
Wir planen Restore-Tests als Teil des Betriebs. Snapshots, Replikation und Object Lock sind nur dann belastbar, wenn Wiederherstellung, Rechte, Zeitbedarf und Datenkonsistenz regelmäßig geprüft werden.
Der nächste Schritt
Prüfen wir, welches Storage-Verhalten Ihre Workloads wirklich brauchen.
Wir bewerten Performance, Wachstum, RTO/RPO, Backup und Kosten und entwickeln daraus eine tragfähige Storage-Architektur.
Storage-Anfrage senden oder Formular ausfüllen