Blockstorage, Objektstorage oder Netzwerkdateisystem: Speicher im Serverbetrieb richtig wählen

Speicher wird in Infrastrukturprojekten oft spät betrachtet. Der Server steht, die Anwendung läuft, und dann stellt sich heraus, dass die Datenbank auf einem Netzwerkdateisystem liegt oder dass Uploads sich nicht zwischen zwei Webservern teilen lassen. Solche Entscheidungen sind nachträglich teuer, weil sie Datenmigration und Ausfallzeiten bedeuten. Dieser Beitrag ordnet die drei gängigen Speicherarten ein und beschreibt, woran Sie die passende Wahl festmachen.

Drei Speicherarten, drei Aufgaben

Die Begriffe werden im Alltag unscharf verwendet. Technisch unterscheiden sich die Varianten darin, auf welcher Ebene das Betriebssystem sie sieht und welche Zugriffssemantik sie garantieren.

Blockstorage

Blockstorage stellt dem Server ein rohes Blockgerät bereit, vergleichbar mit einer lokalen Festplatte. Das Betriebssystem legt ein Dateisystem darauf an und verwaltet alles Weitere selbst. Ob die Blöcke physisch in der Maschine stecken oder über ein Speichernetz angebunden sind, merkt die Anwendung in der Regel nicht.

Kennzeichnend ist, dass ein Blockgerät normalerweise nur von einem Server gleichzeitig beschrieben wird. Zwei Systeme können dasselbe Volume nicht ohne Weiteres parallel einhängen, ohne das Dateisystem zu zerstören. Dafür bekommen Sie niedrige Latenz und volle POSIX-Semantik mit Sperren, Rechten und direktem Schreibzugriff.

Blockstorage ist deshalb die richtige Wahl für Betriebssystem, Datenbanken, Suchindizes und alles, was viele kleine, zufällige Schreibzugriffe erzeugt.

Objektstorage

Objektstorage speichert Dateien als Objekte mit Metadaten und spricht über HTTP an, meist über eine S3-kompatible Schnittstelle. Es gibt kein Dateisystem, keine Verzeichnisse im klassischen Sinn und keine Teilschreibzugriffe. Ein Objekt wird vollständig geschrieben oder ersetzt.

Der Vorteil liegt in der Skalierung und im parallelen Zugriff. Beliebig viele Clients können gleichzeitig lesen und schreiben, die Kapazität wächst ohne Planung mit, und die Replikation übernimmt das System. Die Latenz pro Anfrage ist höher als bei lokalem Speicher, der Gesamtdurchsatz bei vielen parallelen Zugriffen dagegen sehr gut.

Typische Einsatzfälle sind Benutzeruploads, Mediendateien, Backups, Archive und Artefakte aus Build-Prozessen.

Netzwerkdateisysteme

NFS und SMB stellen ein Dateisystem über das Netz bereit. Mehrere Server sehen dieselben Verzeichnisse und können gleichzeitig darauf zugreifen. Für Anwendungen, die zwingend Dateipfade erwarten und nicht auf eine Objektschnittstelle umgestellt werden können, ist das oft der einzige Weg zu geteiltem Speicher.

Der Preis sind Latenz und Fehlermodi. Jede Dateioperation wird zu einem Netzwerkaufruf. Sperrmechanismen funktionieren über das Netz anders als lokal, und fällt der Server aus, hängen Prozesse auf den Clients unter Umständen blockierend fest. Netzwerkdateisysteme brauchen deshalb ein stabiles, kurzes Netzsegment und saubere Mount-Optionen.

Die Entscheidung hängt am Zugriffsmuster

Statt nach Speicherart zu fragen, lohnt sich die Frage nach dem Zugriffsmuster der Anwendung. Drei Punkte reichen meist für eine Einordnung.

• Greifen mehrere Server gleichzeitig schreibend auf dieselben Daten zu oder nur einer?
• Werden Dateien vollständig geschrieben und gelesen oder an beliebigen Stellen verändert?
• Wie viele Operationen pro Sekunde entstehen und wie groß ist die einzelne Operation?

Eine Datenbank verändert ständig kleine Bereiche großer Dateien und verlangt verlässliche Sperren. Sie gehört auf Blockstorage, idealerweise auf lokalen NVMe-Speicher. Ein Dokumentenarchiv schreibt Dateien einmal und liest sie selten. Es gehört in Objektstorage. Eine Legacy-Anwendung, die ein gemeinsames Upload-Verzeichnis braucht und sich nicht anpassen lässt, landet auf NFS.

Der häufigste und teuerste Fehler ist, Datenbanken auf Netzwerkdateisysteme zu legen, weil der geteilte Zugriff bequem erscheint. Das funktioniert im Test und bricht unter Last zusammen, weil Sperren und Fsync-Verhalten über das Netz nicht die gleichen Garantien liefern.

Kennzahlen, die wirklich etwas aussagen

Kapazität in Gigabyte ist die am einfachsten zu beschaffende und am wenigsten aussagekräftige Zahl. Im Betrieb zählen drei andere Werte.

IOPS beschreiben, wie viele Ein- und Ausgabeoperationen pro Sekunde möglich sind. Sie sind der begrenzende Faktor bei Datenbanken und bei vielen kleinen Dateien. Durchsatz in Megabyte pro Sekunde zählt bei großen sequentiellen Zugriffen, etwa bei Backups und Videodateien. Latenz beschreibt die Zeit bis zur Antwort einer einzelnen Operation und bestimmt, wie reaktiv eine Anwendung wirkt.

Diese Werte stehen in Konkurrenz. Ein System kann hohen Durchsatz und trotzdem schlechte Latenz liefern. Wenn Sie Speicher auswählen, prüfen Sie, welcher der drei Werte Ihr Engpass ist, und messen Sie mit einem realistischen Profil statt mit sequentiellen Tests, die jedes System gut aussehen lassen.

Redundanz ersetzt kein Backup

Replizierter Objektstorage und RAID-Verbünde schützen vor Hardwareausfällen. Sie schützen nicht vor versehentlichem Löschen, fehlerhaften Deployments oder Verschlüsselungstrojanern, denn all das wird zuverlässig mitrepliziert.

Wer Backups in Objektstorage ablegt, sollte deshalb mit Versionierung und Objektsperren arbeiten, damit bestehende Sicherungen nicht von einem kompromittierten Zugang überschrieben werden können. Die Zugangsdaten für das Backupziel gehören nicht auf den Server, der gesichert wird, zumindest nicht mit Löschrechten.

Snapshots richtig einordnen

Blockstorage-Snapshots sind praktisch, weil sie in Sekunden entstehen und ein schnelles Zurückrollen erlauben. Sie liegen allerdings meist im selben System wie die Originaldaten und sind damit kein unabhängiges Backup.

Zweiter Punkt: Ein Snapshot auf Blockebene friert den Zustand der Blöcke ein, nicht den Zustand der Anwendung. Eine Datenbank, die im Moment des Snapshots Schreibvorgänge im Puffer hat, ist danach zwar meist wiederherstellbar, aber der Zustand entspricht einem Absturz. Für konsistente Sicherungen braucht es entweder ein kurzes Einfrieren der Schreibvorgänge oder einen Dump über die Datenbankwerkzeuge.

Wachstum früh einplanen

Speicher wächst selten linear und selten dort, wo man es erwartet. Logdateien, Mailarchive und Benutzeruploads sind die üblichen Verdächtigen. Entscheidend ist weniger die exakte Prognose als die Frage, wie teuer eine spätere Vergrößerung wird.

Ein Blockvolume lässt sich in der Regel online vergrößern, aber nicht verkleinern. Objektstorage wächst ohne Eingriff, kostet dafür pro gespeichertem Volumen und manchmal pro Anfrage. Planen Sie deshalb eine Aufräumstrategie mit ein: Lebenszyklusregeln für alte Objekte, Rotation für Logs und ein klar definiertes Aufbewahrungsende für Archive.

Überwachung

Zwei Alarme gehören in jedes Monitoring: freier Speicherplatz und freie Inodes. Der zweite Wert wird gern vergessen und sorgt für Fehler, bei denen das Dateisystem voll meldet, obwohl Gigabyte frei sind. Hinzu kommen Latenz und Wartezeiten auf Ein- und Ausgabe, weil steigende Werte hier oft der erste Hinweis auf einen Engpass sind, lange bevor Nutzer etwas bemerken.

Für Objektstorage lohnt sich zusätzlich die Beobachtung der Fehlerraten. Ein steigender Anteil fehlgeschlagener Anfragen deutet auf Probleme hin, die auf Serverseite als stille Wiederholungen untergehen und erst spät auffallen.

Kurz zusammengefasst

Blockstorage für alles, was schnell und exklusiv sein muss. Objektstorage für alles, was groß, geteilt und unveränderlich ist. Netzwerkdateisysteme nur dort, wo eine Anwendung Dateipfade erzwingt. Wer diese Zuordnung vor dem Aufbau trifft, erspart sich die Migration unter Zeitdruck.