Storage-Cluster vs. NAS vs. SAN: Unterschiede und Einsatz

Kurz gesagt: Ein NAS stellt Dateien aus einem einzelnen Gerät bereit, ein SAN liefert Blockgeräte aus einem zentralen Speichersystem über ein eigenes Speichernetz, und ein Storage-Cluster verteilt die Daten per Software auf mehrere gleichberechtigte Server. NAS und SAN bündeln die Redundanz in einem Gerät, der Cluster verteilt sie über mehrere. Im Homelab reicht meist ein NAS oder ein ZFS-Server. Ein Cluster lohnt sich, wenn kein einzelnes Speichergerät mehr ausfallen darf, und ein klassisches SAN ist zuhause die Ausnahme.

Die drei Begriffe tauchen in Foren, Produktbeschreibungen und Stellenanzeigen ständig nebeneinander auf und werden dabei gern vermischt. Dieser Guide stellt sie sauber nebeneinander: wie sie technisch arbeiten, was sie bei Ausfällen leisten, wie sie wachsen und was sie im Betrieb verlangen. Was ein Storage-Cluster grundsätzlich ist, erklärt Was ist ein Storage-Cluster?.

Für wen ist dieser Guide? #

• Du willst Speicher für mehrere Hypervisoren oder Container-Hosts aufbauen und suchst die passende Architektur.
• Du hast ein NAS und fragst dich, ob ein Cluster ein sinnvoller nächster Schritt ist.
• Du kennst SAN aus dem Beruf und willst wissen, wie sich verteilter Speicher davon unterscheidet.

Voraussetzungen #

Du solltest wissen, was ein Node, Replikation und Quorum sind. Falls nicht, lies zuerst Was ist ein Storage-Cluster?.

Was du lernst #

• den technischen Unterschied zwischen Datei- und Blockzugriff,
• wie NAS, SAN und Storage-Cluster aufgebaut sind,
• welche Ausfälle welche Architektur übersteht,
• wodurch die Kosten jeweils entstehen und wie du sie für dich rechnest,
• welcher Ansatz zu Homelab, kleiner Firma oder Rechenzentrum passt.

Die technische Grundlage: Datei oder Block? #

Der wichtigste Unterschied steckt eine Ebene tiefer als die Gerätefrage. Es geht darum, wo das Dateisystem liegt.

Dateizugriff. Der Speicher verwaltet das Dateisystem selbst. Clients fragen nach Dateien und Verzeichnissen, etwa „öffne /projekte/plan.odt“. Die gängigen Protokolle sind NFS (vor allem unter Linux) und SMB (unter Windows, aber auch überall sonst). Weil der Server das Dateisystem kontrolliert, können viele Clients gleichzeitig dieselben Dateien nutzen.

Blockzugriff. Der Speicher stellt eine Art virtuelle Festplatte bereit, in der Fachsprache eine LUN (Logical Unit Number). Der Client sieht ein leeres Blockgerät, formatiert es selbst und verwaltet das Dateisystem darauf. Die gängigen Protokolle sind iSCSI (SCSI-Befehle über ein normales IP-Netz) und Fibre Channel (ein eigenes Speichernetz mit eigener Hardware). Ein Blockgerät mit einem gewöhnlichen Dateisystem darf nur ein Client zur selben Zeit beschreiben, sonst zerstören sich die Schreibzugriffe gegenseitig.

Proxmox VE zeigt in seiner Speicherübersicht gut, wie sich das in der Praxis auswirkt:

Interessant ist die Zeile ZFS over iSCSI: Proxmox weist selbst darauf hin, dass du dafür sorgen musst, dass die ZFS-Appliance nicht zum Single Point of Failure wird.Belegt Gemeinsamer Speicher heißt also noch nicht ausfallsicherer Speicher.

Die drei Architekturen #

NAS: ein Gerät, das Dateien bereitstellt #

Ein NAS (Network Attached Storage) ist ein Server, dessen Hauptaufgabe Dateifreigaben sind. Ob fertiges Gerät, selbst gebauter Rechner mit TrueNAS oder ein Unraid-Server: Das Prinzip ist gleich. Mehrere Platten bilden per RAID oder ZFS einen ausfallsicheren Verbund, darauf liegt ein Dateisystem, und das NAS gibt Verzeichnisse per NFS oder SMB frei. Viele NAS-Systeme können zusätzlich iSCSI-Blockgeräte anbieten.

Die Redundanz steckt im Gerät: Fällt eine Platte aus, übernimmt die Parität oder der Spiegel. Fällt das Netzteil, das Mainboard oder das Betriebssystem aus, ist der Speicher weg, bis das Gerät wieder läuft. Welche NAS-Software zu dir passt, vergleicht Unraid vs. Proxmox vs. TrueNAS.

SAN: Blockgeräte aus einem zentralen Speichersystem #

Ein SAN (Storage Area Network) ist zuerst ein Netz: ein eigenes, vom normalen Datenverkehr getrenntes Netz, über das Server auf Blockspeicher zugreifen. Am anderen Ende steht ein Speichersystem, oft Storage-Array genannt, das seine Platten in LUNs aufteilt und diese bestimmten Servern zuweist. Klassisch läuft das über Fibre Channel mit eigenen Switches und Adapterkarten, heute oft auch über iSCSI im Ethernet.

Unternehmens-Arrays haben häufig zwei Controller, damit der Ausfall eines Controllers den Zugriff nicht unterbricht, und Server binden sie über zwei getrennte Wege an (Multipathing). Trotzdem bleibt das Array ein zentrales System an einem Ort. Die Redundanz steckt auch hier im Gerät, nur aufwendiger gebaut.

Im Homelab begegnet dir das SAN-Prinzip meist ohne SAN-Hardware: Ein NAS exportiert eine iSCSI-LUN, und ein Hypervisor nutzt sie als Blockspeicher. Technisch ist das Blockzugriff wie im SAN, architektonisch bleibt es ein einzelnes Gerät.

Storage-Cluster: Software verteilt die Daten #

Ein Storage-Cluster hat kein zentrales Speichergerät. Mehrere gleichwertige Server, die Nodes, bringen jeweils eigene Datenträger mit. Eine Software wie Ceph, LINSTOR mit DRBD oder Longhorn verteilt jeden Datenblock in mehreren Kopien auf verschiedene Nodes und stellt das Ganze als Block-, Datei- oder Objektspeicher bereit.

Die Redundanz steckt zwischen den Geräten. Fällt ein ganzer Node aus, liegen die Kopien auf den anderen. Dafür braucht der Cluster ein schnelles Netz zwischen den Nodes und mindestens drei Teilnehmer, damit bei Störungen eine Mehrheit entscheiden kann. Proxmox verlangt für hyperkonvergentes Ceph ausdrücklich mindestens drei, möglichst identische Server.

Vergleich nach Kriterien #

Ausfallsicherheit im Detail #

Die Frage „Ist das hochverfügbar?“ lässt sich nur pro Ausfallart beantworten. Die folgende Tabelle geht von einem sauber gebauten System aus: NAS mit RAID oder ZFS-Redundanz, Array mit zwei Controllern, Cluster mit drei Nodes und dreifacher Replikation.

Drei Dinge fallen auf. Erstens: Gegen Raum- oder Standortausfälle schützt keine der drei Varianten, solange alles am selben Ort steht. Zweitens: Ein Cluster ist nur so redundant wie sein Netz. Hängen alle Nodes an einem Switch, ist dieser Switch der neue Single Point of Failure. Drittens: Gegen Fehlbedienung und Ransomware hilft nur ein getrenntes Backup, siehe Replikation ist kein Backup.

Für die Hochverfügbarkeit von VMs zählt außerdem die Hypervisor-Seite. Proxmox nennt für sein HA-System mindestens drei Cluster-Nodes, gemeinsamen Speicher und Hardware-Redundanz als Voraussetzung und gibt typische Erkennungs- und Umschaltzeiten von etwa zwei Minuten an. Hochverfügbarkeit heißt also „VM startet nach kurzer Unterbrechung woanders neu“, nicht „nichts merkt etwas“. Mehr dazu in Hochverfügbarkeit im Storage-Cluster.

Skalierung #

NAS wächst nach oben: größere Platten, mehr Einschübe, eine Erweiterungseinheit. Irgendwann sind die Einschübe voll, und die Netzwerkanbindung eines einzelnen Geräts begrenzt, wie viele Clients gleichzeitig schnell bedient werden. Eine Migration auf ein größeres Gerät ist dann ein Umzug aller Daten.

SAN wächst ebenfalls nach oben, mit zusätzlichen Platteneinschüben am Array. Die Controller bleiben der Flaschenhals, bis das Array gegen ein größeres getauscht wird.

Storage-Cluster wachsen zur Seite. Jeder neue Node bringt Platten, Prozessor, RAM und Netzwerkanschlüsse mit. Das klingt unbegrenzt, hat aber einen Haken: Nach jeder Erweiterung verteilt der Cluster vorhandene Daten neu, damit die Kopien gleichmäßig liegen. Dieses Umverteilen erzeugt viel Netzverkehr und Last auf den Datenträgern. Wie man das steuert, beschreibt Storage-Cluster erweitern.

Performance: worauf es ankommt #

Seriöse Zahlen lassen sich nur für ein konkretes System mit einer konkreten Last messen. Deshalb hier keine Werte, sondern die Faktoren, die du verstehen solltest:

• NAS: Die Leistung hängt an einem Gerät: seinen Platten, seinem Arbeitsspeicher als Cache und seiner Netzwerkkarte. Für Dateifreigaben im Heimnetz reicht das in aller Regel.
• SAN: Ein eigenes Speichernetz trennt Speicherverkehr von allem anderen. Das macht die Latenz vorhersehbar, also die Wartezeit bis zur Antwort auf eine Anfrage.
• Storage-Cluster: Lesen lässt sich über viele Nodes verteilen. Beim Schreiben wartet der Client, bis alle beteiligten Kopien bestätigt sind. Jede Schreiboperation enthält damit mindestens einen zusätzlichen Weg durchs Netz. Ceph weist darauf hin, dass dicht bestückte oder NVMe-Nodes 10- oder sogar 25-Gbit-Schnittstellen auslasten können, und Proxmox empfiehlt für Aufbauten mit modernen NVMe-SSDs mindestens 25 Gbit/s.

Wie du Performance selbst misst, statt fremden Zahlen zu glauben, erklärt IOPS, Durchsatz und Latenz mit dem fio-Command-Builder.

Verwaltungsaufwand #

Der größte Unterschied im Alltag ist nicht die Technik, sondern die Pflege.

• NAS: Eine Weboberfläche, ein Gerät, ein Update-Knopf. Die meisten Fehler sind einfach zu verstehen: Platte defekt, Freigabe falsch berechtigt, Netz weg.
• SAN: Hier kommt Fachwissen dazu. LUNs müssen den richtigen Servern zugewiesen werden, im Fibre-Channel-Netz regelt Zoning, wer wen sieht, und Multipathing muss auf jedem Server korrekt konfiguriert sein.
• Storage-Cluster: Viele Dienste auf vielen Nodes, ein eigener Gesundheitszustand mit Warnungen, die man deuten können muss, Updates in vorgeschriebener Reihenfolge und Wartung mit Bedacht, damit beim Herunterfahren eines Nodes nicht unnötig Daten umkopiert werden. Dafür erledigt der Cluster vieles selbst, etwa das Wiederherstellen fehlender Kopien.

Kosten: woraus sie entstehen #

Konkrete Preise ändern sich zu schnell und hängen zu stark von Gebraucht- oder Neuware ab, um sie hier zu nennen. Hilfreicher ist zu wissen, was du bezahlst:

Den Strom rechnest du am besten mit eigenen Werten durch. Die Formel ist einfach: Leistungsaufnahme aller Geräte in Watt mal 8 760 Stunden im Jahr, geteilt durch 1 000, ergibt die Kilowattstunden pro Jahr. Mal deinem Strompreis ergibt die Jahreskosten. Setz für die Leistung Werte ein, die du an deinen eigenen Geräten gemessen hast, zum Beispiel mit einem Zwischenstecker-Messgerät, oder rechne verschiedene Annahmen im Stromkosten-Rechner durch.

Bei der Kapazität hilft der Storage-Cluster-Kapazitätsrechner: Er zeigt, wie viel von den gekauften Terabytes nach Replikation, Füllgrenze und Ausfallreserve tatsächlich nutzbar bleibt. Für ein NAS mit RAID macht das der RAID-Rechner.

Proxmox nennt übrigens für drei bis fünf Nodes ein Full-Mesh-Netz als Option, wenn keine Switches mit 10 Gbit/s oder mehr vorhanden sind. Dabei ist jeder Node direkt mit jedem anderen verbunden. Das spart den Switch, kostet aber Netzwerkports und skaliert nicht über wenige Nodes hinaus. Details in Netzwerk für Storage-Cluster.

Homelab, kleine Firma, Rechenzentrum #

Im Homelab ist ein NAS oder ein einzelner ZFS-Server fast immer der vernünftige Start. Er ist sparsam, gut verstanden und mit einem ordentlichen Backup sehr sicher. Ein Storage-Cluster ist dort vor allem ein Lern- und Spielfeld, oder er lohnt sich, wenn du mehrere Hypervisoren betreibst und ernsthaft willst, dass VMs bei einem Hardwareausfall auf einem anderen Host weiterlaufen. Ein Fibre-Channel-SAN ist zuhause meist Überdimensionierung, iSCSI vom NAS dagegen ein üblicher Kompromiss.

In kleinen Firmen entscheidet oft, wie teuer eine Stunde Stillstand ist. Reicht es, nach einem Ausfall das NAS zu reparieren und aus dem Backup zurückzuholen, ist ein redundantes NAS mit Backup günstiger und einfacher. Muss der Betrieb weiterlaufen, sind ein hyperkonvergenter Cluster aus drei Servern oder ein Speichersystem mit zwei Controllern die Kandidaten.

Im Rechenzentrum existieren alle drei nebeneinander: SAN-Arrays für klassische Virtualisierung und Datenbanken, verteilter Speicher für große, wachsende Datenmengen, Objektspeicher und Container-Plattformen, NAS für Dateifreigaben.

Mischformen, die in der Praxis vorkommen #

• Cluster plus NAS. Der Storage-Cluster trägt die VM-Disks, ein NAS dient als Backup-Ziel. Das ist eine sehr sinnvolle Kombination, weil das Backup physisch getrennt vom Cluster liegt.
• Hyperkonvergenz. Hypervisor und Storage-Cluster laufen auf denselben Servern, etwa Proxmox VE mit integriertem Ceph. Das spart Geräte, verlangt aber Ressourcen für beides auf jedem Node.
• Zwei Server mit Replikation. Proxmox kann VM-Disks auf lokalem ZFS in Intervallen ab einer Minute auf einen zweiten Node kopieren. Laut Proxmox-Doku können bei einem Ausfall die Änderungen seit dem letzten Lauf verloren gehen. Das ist kein Cluster-Speicher, aber für viele Homelabs ein guter Mittelweg.
• Cluster stellt NFS bereit. Ceph kann über einen NFS-Dienst Dateien für Clients anbieten, die kein Ceph sprechen.

Vorgehen: deine Situation einordnen #

Bevor du dich für eine Architektur entscheidest, beantworte diese Fragen schriftlich. Das klingt bürokratisch, verhindert aber die häufigste Fehlentscheidung, nämlich eine Architektur nach Begeisterung statt nach Bedarf zu wählen.

1. Was soll gespeichert werden? Dateien für Menschen (Dokumente, Fotos, Medien), VM-Disks, Container-Volumes oder Objekte für Anwendungen?
2. Wie lange darf der Speicher ausfallen? Stunden, Minuten oder gar nicht? Sei ehrlich: Im Homelab ist „bis ich Zeit habe“ oft eine akzeptable Antwort.
3. Wie viele Hosts greifen zu? Ein Server mit lokalen Platten braucht keinen gemeinsamen Speicher.
4. Wie viel Kapazität brauchst du in drei Jahren? Rechne mit dem Kapazitätsrechner nach, wie viel Rohkapazität das in jeder Architektur bedeutet.
5. Wie viele Geräte willst du dauerhaft betreiben? Und wie viel Strom und Lautstärke ist dafür in Ordnung?
6. Wie viel Zeit willst du in Wartung stecken? Ein Cluster belohnt Neugier und bestraft Nachlässigkeit.

Wenn du bei Frage 2 „Minuten oder gar nicht“ und bei Frage 3 „mehrere“ antwortest, kommt ein Cluster ernsthaft in Betracht. Sonst ist ein NAS oder ZFS-Server mit Backup in aller Regel die bessere Wahl. Die ausführliche Entscheidungsmatrix mit Beispielrechnung steht in Wann lohnt sich ein Storage-Cluster wirklich?.

Bestehende Speicher in Proxmox erkennen #

Betreibst du schon Proxmox VE, zeigt die Speicherkonfiguration, welche Architektur du heute nutzt. Die Datei liegt im Cluster-Dateisystem und lässt sich gefahrlos lesen:

cat /etc/pve/storage.cfg

Einträge vom Typ nfs oder cifs sind Dateifreigaben eines NAS, iscsi steht für Blockspeicher aus einem SAN oder NAS, zfspool für lokales ZFS und rbd oder cephfs für Ceph. Ändere die Datei nicht von Hand, solange du nicht genau weißt, was du tust; Speicher bearbeitest du über die Oberfläche oder die Proxmox-Werkzeuge.

Sicherheitshinweise #

• Speicherprotokolle gehören nicht ins offene Netz. NFS, SMB und iSCSI sind für vertrauenswürdige Netze gedacht. Trenne Speicherverkehr per VLAN oder eigener Netzwerkkarte vom übrigen Netz und gib ihn nie ins Internet frei.
• Freigaben eng berechtigen. Erlaube NFS-Exporte nur für die Adressen der Hosts, die sie brauchen, und nutze die Zugriffssteuerung des jeweiligen Protokolls.
• Cluster-Netz isolieren. Ceph empfiehlt, sein Cluster-Netz weder aus dem öffentlichen Netz noch aus dem Internet erreichbar zu machen.
• Ein Blockgerät, ein Schreiber. Binde eine iSCSI-LUN mit gewöhnlichem Dateisystem nie gleichzeitig auf zwei Hosts ein, die beide schreiben. Das zerstört das Dateisystem. Proxmox löst das bei gemeinsamem iSCSI über LVM.
• Backup bleibt Pflicht, egal welche Architektur. Am besten liegt es auf einem getrennten Gerät, siehe Backup-Strategie für zuhause.

So prüfst du deine Entscheidung #

Deine Architekturwahl ist tragfähig, wenn du für sie diese Sätze ohne Zögern vervollständigen kannst:

• „Wenn das Speichergerät oder ein Node ausfällt, passiert Folgendes: …“
• „Wenn der Switch ausfällt, passiert Folgendes: …“
• „Wenn ich versehentlich Daten lösche, hole ich sie zurück aus: …“
• „Nutzbar bleiben von meiner Rohkapazität: … TB, nachgerechnet mit: …“
• „Dauerhaft laufen … Geräte mit zusammen etwa … Watt, gemessen oder angenommen als: …“

Bleibt eine Lücke, ist das kein Grund zur Sorge, sondern genau die Stelle, an der du weiter planen solltest.

Typische Fehlentscheidungen #

Cluster auf 1-Gbit-Netz. Funktioniert im Test, wird aber beim ersten Ausfall zäh, weil die Wiederherstellung die Leitung füllt. Die Ceph-Doku nennt für das Replizieren von 1 TiB über 1 Gbit/s rund drei Stunden.

NAS als „Hochverfügbarkeit“. Drei Proxmox-Hosts mit HA, aber alle VM-Disks auf einem einzigen NAS. Fällt das NAS aus, hilft das HA der Hypervisoren nicht.

Ein Switch für alles. Cluster-Nodes redundant, aber alle hängen an einem Switch. Fällt er aus, ist der Cluster getrennt.

RAID-Controller unter dem Cluster. Software-defined Storage will die Platten direkt sehen. Proxmox rät ausdrücklich zu einem HBA statt eines RAID-Controllers.

Offizielle Quellen #

• Proxmox VE: Storage
• Proxmox VE: Deploy Hyper-Converged Ceph Cluster
• Proxmox VE: Cluster Manager
• Proxmox VE: High Availability
• Ceph Hardware Recommendations (Tentacle)
• Ceph Network Configuration Reference (Tentacle)

Weiterlesen #

• Wann lohnt sich ein Storage-Cluster wirklich?: die ausführliche Entscheidungsmatrix mit Architekturvergleich für ein Beispiel-Homelab.
• Was ist ein Storage-Cluster?: die Grundbegriffe, falls dir beim Lesen etwas gefehlt hat.
• Netzwerk für Storage-Cluster: warum das Netz beim Cluster wichtiger ist als bei NAS und SAN.
• Unraid vs. Proxmox vs. TrueNAS: wenn es am Ende doch ein NAS oder ein einzelner Server wird.