SAN-Speichernetzwerk: Checkliste für die Planung

Bei uns im Support beginnt es oft mit dem gleichen Satz: „Wir virtualisieren gerade unsere Serverlandschaft, und die lokalen Platten der Hosts kommen nicht mehr mit." Drei ESXi-Hosts wurden zu sieben, die Datenbank kämpft mit unerklärlichen Latenzspitzen, nachts laufen die Backup-Fenster aus dem Ruder. Genau in dieser Phase stellt sich die Frage nach einem dedizierten Speichernetzwerk, und genau hier trennt sich gute von schlechter SAN-Planung. Wer hier nur ein Stück Hardware kauft, kauft später doppelt.

Anforderungsanalyse: Wann sich ein dediziertes SAN für Unternehmen lohnt

Ein Storage Area Network ist kein Speicher, den man „einfach mal mitnimmt", wenn das NAS zu klein wird. Es ist eine eigene Infrastruktur-Klasse, die ihre Berechtigung aus drei klaren Auslösern zieht. Der erste Auslöser ist die Anzahl der Virtualisierungshosts: Ab etwa fünf Hosts mit Live-Migration und Hochverfügbarkeit wird es technisch und betrieblich sinnvoll, den geteilten Speicher aus den Servergehäusen herauszuziehen und in eine zentrale, blockbasierte Plattform zu legen. Der zweite Auslöser sind Anwendungen mit harten Latenzanforderungen, typischerweise Datenbank- oder ERP-Systeme, die konstant unter zwei Millisekunden am Storage-Layer antworten müssen. Der dritte Auslöser ist schlicht das Datenvolumen, sobald die produktive Datenmenge deutlich über 50 Terabyte wächst und mehrere Hosts gleichzeitig schreibend darauf zugreifen.

Das bedeutet für die Praxis: Wer unterhalb dieser Schwellen bleibt, also zwei bis drei Hosts mit überschaubaren Workloads, fährt mit gut konfiguriertem DAS oder einem leistungsfähigen NAS oft günstiger und einfacher. Die Fehlplanung, die wir am häufigsten sehen, ist genau die umgekehrte Richtung: Man hat sich früh für SAN-Hardware entschieden, weil „Enterprise klingt sicher", und betreibt dann ein 80.000-Euro-System für vier VMs. Umgekehrt warten Mittelständler oft zu lange und versuchen, mit Workarounds auf direkt angeschlossenen SSDs zu überleben, bis ein Storage-Ausfall den kompletten Cluster stilllegt. Eine ehrliche Anforderungsanalyse vor dem Projekt ist die einzige Methode, die richtige Klasse zu treffen, und sie ist der Punkt, an dem jede vernünftige SAN-Checkliste beginnt.

Protokollwahl und Performance: Fibre Channel, iSCSI und NVMe-oF im Vergleich

Sobald die Entscheidung für ein SAN steht, geht es um die Transportebene, und hier treffen drei Welten aufeinander: Fibre Channel, iSCSI und NVMe-oF. Fibre Channel ist seit Jahrzehnten der Standard für anspruchsvolle Enterprise-Workloads, mit klar definierten Geschwindigkeitsstufen 16 GFC, 32 GFC (Gen 6) und 64 GFC (Gen 7). Der Vorteil liegt in der deterministischen Latenz, dem dedizierten Stack und einer ausgereiften Werkzeugkette für Zoning, Monitoring und Troubleshooting. Der Nachteil liegt auf der Hand: separate Switches, SFPs, Kabelinfrastruktur und ein separates Know-how, das in vielen Häusern erst aufgebaut werden muss.

iSCSI nutzt das vorhandene Ethernet und ist in vielen mittelständischen Umgebungen die wirtschaftlich rationale Wahl. Auf 25-GbE-Adaptern liefert iSCSI heute mehr als genug Durchsatz für virtualisierte Workloads, SQL-Datenbanken und Fileservices, vorausgesetzt das Netz ist sauber segmentiert, Jumbo-Frames sind konsistent aktiv, und die Storage- sowie Host-Ports sind korrekt für Flow-Control konfiguriert. NVMe-oF, also NVMe over Fabrics, geht den konsequentesten Schritt und überträgt das NVMe-Protokoll über FC oder TCP. Im Vergleich zu iSCSI erreicht NVMe-oF eine um rund 50 Prozent geringere Latenz, weil der SCSI-Übersetzungslayer entfällt und der I/O-Pfad deutlich kürzer wird.

Das bedeutet für die Praxis: Die Wahl ist keine Glaubensfrage, sondern eine Frage der bestehenden Infrastruktur, der Latenzanforderungen und des verfügbaren Budgets. Wer bereits eine FC-Fabric betreibt, bleibt dabei und ergänzt allenfalls 32-GFC-Komponenten, wer ein modernes Ethernet mit 25 GbE im RZ hat, kann mit iSCSI sehr weit kommen, und wer Performance-Datenbanken konsolidiert, sollte NVMe-oF ernsthaft in Betracht ziehen. Wichtig ist, dass man die Entscheidung nicht nach dem Kauf des Speichersystems trifft, sondern davor, denn die Protokollwahl bestimmt HBA-Typen, Switches und das gesamte Kabeldesign.

Architektur und Hochverfügbarkeit: Vermeidung von Single Points of Failure

Ein SAN, das nur eine Fabric besitzt, ist kein hochverfügbares SAN, es ist ein Shared Risk. Die Architekturentscheidung mit der größten Tragweite ist die Frage, wie Redundanz auf den drei Ebenen Controller, Fabric und Host-Anbindung umgesetzt wird. Auf der Speicherseite beginnt es mit Dual-Controller-Systemen, also zwei aktiven Controllern, die sich gegenseitig übernehmen können. Steigt die Anforderung, kommen Metro-Cluster oder Stretch-Cluster mit synchroner Replikation zwischen Standorten hinzu, doch der Grundstock ist immer das redundante Controllerpaar.

Auf der Netzwerkseite heißt das: zwei physisch getrennte Fabrics, in der SAN-Sprache Fabric A und Fabric B. Jeder Host bekommt zwei HBAs, jeder HBA geht in genau eine Fabric, jede Fabric geht in genau einen Controller des Storage-Systems. Multipathing-Software auf dem Server, sei es ALUA bei FC und iSCSI oder ANA bei NVMe-oF, sorgt dafür, dass bei Ausfall eines Pfads der andere automatisch übernimmt, ohne dass der I/O ins Stocken gerät. Wer an dieser Stelle spart und nur eine Fabric baut, schafft sich den Single Point of Failure, der genau in dem Moment zuschlägt, in dem man ihn am wenigsten gebrauchen kann.

Wer ein SAN plant, das mehr als eine Testumgebung versorgen soll, plant immer zwei Fabrics, zwei HBAs pro Host und Multipathing von Anfang an ein, nicht als nachträgliche Korrektur.

Ein zweiter Engpass, den wir regelmäßig in Bestandsumgebungen sehen, liegt in den Inter-Switch-Links. Wenn die ISL-Strecken zwischen den FC-Switches überbucht werden, weil zu viele Hosts über zu wenige Uplinks an die Core-Switches angeschlossen sind, entstehen I/O-Spitzen, die sich als sporadische Fehler in den Logs zeigen, ohne dass die einzelne Komponente defekt wäre. Für produktiven Host-zu-Storage-Datenverkehr sollte das ISL-Überbuchungsverhältnis maximal 7:1 betragen, alles darüber hinaus verschiebt Engpässe an eine Stelle, an der sie sich nur schwer diagnostizieren lassen. Die Konsequenz aus dieser Architekturlogik: Wer Hochverfügbarkeit will, plant sie vor dem ersten Kabel und kontrolliert sie nach jedem Schritt mit Pfadprüfungen, Failover-Tests und dokumentierten Failback-Prozeduren.

Sicherheit im SAN: Zoning, LUN-Masking und Zugriffskontrolle

In einem blockbasierten Speichernetzwerk sieht man nicht, wer zugreift, wenn nicht aktiv dafür sorgt, dass man es sieht. SAN-Sicherheit ruht auf zwei Säulen, die beide sauber umgesetzt sein müssen. Die erste Säule ist Zoning auf Switch-Ebene. Dabei werden WWPNs oder Aliasse so zu Zonen zusammengefasst, dass ausschließlich die Hosts einen LUN sehen, die ihn auch sehen sollen. Hard Zoning setzt die Zonenregeln hardwareseitig direkt im Switch durch, also anhand von WWPN, Domain-ID oder Port-Adresse, und ist damit die zuverlässigere Variante. Soft Zoning wird hingegen nur per Software im Name-Server des Switches konfiguriert und lässt sich im Fehlerfall leichter aushebeln, etwa bei einer Kompromittierung der Management-Software. Ohne sauberes Zoning landet im Ernstfall ein falsch konfigurierter Host direkt auf fremden Volumes.

Hard Zoning erzwingt die Zutrittsregeln im Switch-Chip selbst, Soft Zoning nur im Name-Server – der Unterschied entscheidet, ob ein Konfigurationsfehler zur Datenpanne wird oder nicht.

Die zweite Säule ist LUN-Masking auf Speicherebene. Selbst wenn Zoning im Switch korrekt greift, definiert der Storage-Administrator zusätzlich, welche Hosts auf welche logischen Laufwerke zugreifen dürfen. LUN-Masking ist die letzte Verteidigungslinie und gehört in jede SAN-Planung als verbindlicher Schritt mit dokumentierter Zuordnungstabelle. Beide Mechanismen zusammen sind kein Overkill, sondern Pflicht, denn sie adressieren unterschiedliche Angriffspunkte und unterschiedliche Fehlerquellen: Zoning trennt am Switch, was sich überhaupt sehen darf, Masking regelt am Storage, was davon tatsächlich genutzt werden darf. Das bedeutet für die Praxis: Jede LUN bekommt eine eindeutige ID, jede Zuordnung wird in einer versionssicheren Datei gepflegt, und Änderungen am Zoning oder Masking laufen über einen formellen Change-Prozess mit Vier-Augen-Prinzip.

Investitionsplanung: Kostenstrukturen von Einstiegs- bis Enterprise-Systemen

SAN-Budgets sind nicht linear, sie staffeln sich nach Kapazität, Performance-Anspruch und Redundanz-Level. Wer in eine SAN-Storage-Implementierung einsteigt, sollte mit Größenordnungen rechnen, die deutlich über klassischer Server-Hardware liegen, und genau das ist der Punkt, an dem eine realistische Investitionsplanung zwischen IT und Einkauf oft Reibung erzeugt. Die folgende Aufstellung spiegelt die typischen Bandbreiten aus 2026 wider, basierend auf üblichen Konfigurationen für den jeweiligen Einsatzzweck.

Nicht in diesen Zahlen enthalten sind in der Regel Lizenzkosten für erweiterte Features wie Snapshots, Replikation oder Data-Services, die je nach Hersteller pro Terabyte, pro Feature oder pro Array abgerechnet werden. Ebenso fehlen meist die Kosten für die SAN-Switches, HBAs, Kabel, RZ-Strom und Kühlung, die in einer Gesamtbetrachtung nicht unterschlagen werden dürfen. Das bedeutet für die Praxis: Eine ehrliche TCO-Rechnung über drei bis fünf Jahre bezieht Strom, Wartung, Lizenzverlängerungen und den personellen Aufwand für Administration mit ein, sonst entstehen Überraschungen, die das Projekt nachträglich politisch beschädigen.

Datensicherung: Warum Snapshots kein Ersatz für die 3-2-1-1-0-Backup-Strategie sind

Der häufigste und gefährlichste Irrtum, der uns im Support bei SAN-Themen begegnet, ist die Annahme, der Storage selbst sei schon das Backup. Snapshots auf einem SAN sind ein hervorragendes Werkzeug, um in Sekunden einen früheren konsistenten Zustand wiederherzustellen, etwa nach einem fehlerhaften Patch oder einer versehentlich gelöschten Datei. Sie sind aber kein Backup, weil sie auf derselben Storage-Plattform leben wie die produktiven Daten, denselben Controller, dieselbe Firmware, im Ernstfall denselben Fehler teilen. Wer den Snapshot gegen Ransomware als Sicherung versteht, verliert im Ernstfall Daten und Backup gleichzeitig.

Die Konsequenz aus dieser Überlegung ist eine unabhängige Backup-Strategie, die nach der 3-2-1-1-0-Regel aufgebaut ist: drei Kopien der Daten, auf zwei unterschiedlichen Medientypen, eine Kopie offsite, eine Kopie offline oder immutable, und null ungetestete Restore-Pfade. Konkret heißt das: Ein zweiter Storage-Tier oder eine Backup-Appliance, die nicht vom produktiven SAN abhängt, ein Offsite-Standort oder Cloud-Speicher, ein Air-Gap oder Immutable-Storage, der nicht überschrieben werden kann, und regelmäßig durchgespielte Restore-Tests, die beweisen, dass die Daten im Ernstfall tatsächlich wiederherstellbar sind. Das SAN liefert die Plattform für performante Wiederherstellung, die Backup-Strategie liefert die Versicherung gegen Verlust.

Position zum Abschluss

Ein SAN ist dann gut geplant, wenn es genau die Anforderungen erfüllt, die ohne es nicht mehr erfüllbar waren, und wenn es gleichzeitig so viel Redundanz und Disziplin mitbringt, dass ein einzelner Ausfall keine Katastrophe auslöst. Wer diese Checkliste durchgeht, sollte am Ende eine ehrliche Anforderungsanalyse vorliegen haben, eine begründete Protokollwahl, eine redundante Architektur, sauberes Zoning und LUN-Masking, ein realistisches Budget und eine Backup-Strategie, die wirklich unabhängig vom SAN funktioniert. Genau in dieser Reihenfolge entsteht ein Speichernetzwerk, das im Alltag verlässlich arbeitet, und nicht eines, das teuer gekauft und beim ersten Ernstfall teuer bereut wird.