NAS vs. SAN vs. DAS: Storage-Architektur fuer KMU richtig entscheiden

Warum diese Entscheidung so oft falsch getroffen wird

In den meisten Schweizer KMU faellt die Storage-Entscheidung nicht bewusst, sondern historisch: Irgendwann stand ein NAS im Serverraum, weil es einfach und guenstig war, und zehn Jahre spaeter laeuft darauf die komplette Virtualisierung, drei Fileserver-Freigaben und das Backup-Ziel - alles auf einer Kiste, die urspruenglich fuer Dateiablage gedacht war. Umgekehrt gibt es Betriebe, die sich ein SAN gekauft haben, weil “das macht man halt so bei Servern”, und die dafuer zahlen, ohne die Performance-Vorteile jemals auszunutzen.

Die Wahl zwischen NAS, SAN und DAS ist keine Glaubensfrage, sondern haengt von drei Dingen ab: welches Protokoll dein Workload spricht (Block oder File), wie viele Hosts gleichzeitig auf denselben Speicher zugreifen muessen, und wie viel Ausfallsicherheit und Wachstum du in den naechsten fuenf Jahren wirklich brauchst. Dieser Artikel ordnet die drei Architekturen entlang genau dieser Kriterien ein - inklusive der Hybrid-Modelle, die im KMU-Alltag mittlerweile den Normalfall darstellen.

Die drei Architekturen im Kern

DAS - Direct Attached Storage

DAS ist Speicher, der direkt an genau einen Host haengt - interne Festplatten, ein per SAS/SATA angeschlossenes Disk-Array oder eine per USB/Thunderbolt angebundene externe Platte. Es gibt kein Storage-Netzwerk dazwischen, keine Protokoll-Uebersetzung, keine gemeinsame Nutzung durch mehrere Server gleichzeitig (Ausnahme: Cluster-faehige SAS-Shelfs mit Dual-Path, die aber technisch schon an der Grenze zum SAN liegen).

Vorteile: minimale Latenz, keine Netzwerkabhaengigkeit, geringste Kosten pro TB, keine Lizenzkosten fuer Storage-Software. Nachteil: Das Storage ist an genau den einen Server gebunden. Faellt der Server aus, ist der Storage bis zur Reparatur nicht erreichbar (ausser bei geteilten SAS-Shelfs), und eine zweite Maschine kann nicht “mal eben” mitnutzen.

NAS - Network Attached Storage

Ein NAS ist ein eigenstaendiges Speichersystem im normalen Ethernet-Netzwerk, das auf Dateiebene (File-Level) arbeitet. Clients und Server sprechen SMB (Windows-Welt) oder NFS (Linux/Unix-Welt) mit dem NAS, und das NAS selbst verwaltet das Dateisystem. Der anfragende Host sieht keine Bloecke, sondern Dateien und Ordner - das NAS uebernimmt Locking, Berechtigungen und Metadaten.

Das macht NAS zur natuerlichen Wahl fuer alles, wo mehrere Clients gleichzeitig dieselben Dateien lesen und schreiben sollen: Fileserver-Ersatz, Abteilungslaufwerke, Home-Verzeichnisse, einfache Backup-Ziele.

SAN - Storage Area Network

Ein SAN liefert Block-Storage ueber ein dediziertes (oder zumindest logisch getrenntes) Netzwerk - entweder klassisch per Fibre Channel oder per iSCSI ueber Ethernet. Der anfragende Host sieht keine Dateien, sondern ein rohes Blockgeraet (LUN), das er selbst formatiert und mit einem eigenen Dateisystem versieht (NTFS, ReFS, VMFS, ext4 …). Das SAN selbst weiss nichts vom Inhalt der Bloecke - es liefert nur Lese-/Schreibzugriff auf Sektorebene.

Diese Blockebene ist der entscheidende Unterschied zu NAS: Mehrere Hosts koennen gleichzeitig auf dasselbe Speicher-Array zugreifen, aber in der Regel greift pro LUN nur ein Host exklusiv zu (Ausnahme: Cluster-Dateisysteme wie VMFS oder CSV, die genau fuer gleichzeitigen Mehrfachzugriff gebaut sind). Das macht SAN zur Grundlage fuer Server-Virtualisierung, Datenbank-Cluster und Failover-Cluster-Instanzen.

Block vs. File im Detail: Protokolle, Ports, Overhead

Fibre Channel braucht eigene Host Bus Adapter (HBAs), FC-Switches und in der Regel Glasfaserverkabelung - das treibt die Kosten pro Port deutlich ueber Ethernet, dafuer laeuft das Protokoll komplett in Hardware und ist von Ethernet-Netzwerklast vollstaendig isoliert. iSCSI nutzt die vorhandene Ethernet-Infrastruktur (oder ein dediziertes 10/25 GbE-Segment) und ist deshalb im KMU meist die pragmatischere Wahl, weil kein separates FC-Fabric mit eigenem Know-how aufgebaut werden muss.

Ein typisches iSCSI-Target unter Windows Server richtest du so ein:

# iSCSI Target Server Feature installieren
Install-WindowsFeature -Name FS-iSCSITarget-Server -IncludeManagementTools

# Virtuelle Disk (VHDX) als iSCSI-Target-Speicher anlegen
New-IscsiVirtualDisk -Path "E:\iSCSIVirtualDisks\LUN01_SQL.vhdx" -Size 500GB

# iSCSI Target mit erlaubtem Initiator (per IQN) anlegen
New-IscsiServerTarget -TargetName "sql-cluster-lun01" `
    -InitiatorIds "IQN:iqn.1991-05.com.microsoft:sql01.kmu.local"

# Virtuelle Disk dem Target zuweisen
Add-IscsiVirtualDiskTargetMapping -TargetName "sql-cluster-lun01" `
    -Path "E:\iSCSIVirtualDisks\LUN01_SQL.vhdx"

Auf der Client-Seite (Initiator) verbindest du dich so:

# iSCSI-Initiator-Dienst starten und Discovery-Portal eintragen
Start-Service -Name MSiSCSI
Set-Service -Name MSiSCSI -StartupType Automatic
New-IscsiTargetPortal -TargetPortalAddress 10.10.30.10

# Verbindung zum Target aufbauen und dauerhaft persistieren
Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:sql-target:sql-cluster-lun01"
Get-IscsiTarget | Set-IscsiTarget -IsPersistent $true

Kostenmodelle: Wo das Geld wirklich hinfliesst

Die Anschaffungskosten sind nur die halbe Wahrheit. Die drei Architekturen unterscheiden sich massiv in den laufenden Kosten und im Skalierungsverhalten:

DAS skaliert linear und guenstig, aber mit einer harten Grenze: irgendwann sind alle Schaechte im Server voll, und Erweiterung heisst neuer Server. Keine Lizenzkosten fuer Storage-Software, aber jede Kapazitaetserweiterung bedeutet Downtime am jeweiligen Host.

NAS skaliert meist per Erweiterungs-Shelf (bei Enterprise-NAS) oder Festplattentausch (bei SMB-NAS wie Synology/QNAP). Die Kosten pro TB sind niedrig, weil NAS-Systeme meist auf Standard-Hardware und offenen Dateisystemen basieren. Der versteckte Kostentreiber: Enterprise-Features wie Snapshots, Replikation oder erweiterte Sicherheit sind bei manchen Herstellern lizenzpflichtig zusaetzlich.

SAN hat die hoechsten Einstiegskosten - dediziertes Array, ggf. FC-Switches/HBAs, oft eine Storage-Management-Software mit eigener Lizenz pro Kapazitaet oder pro Feature (Deduplizierung, Snapshots, Replikation, Multipathing). Dafuer skaliert SAN am saubersten fuer viele gleichzeitig zugreifende Hosts, weil die Performance nicht durch File-System-Overhead gebremst wird.

Anwendungsfaelle: Was passt wohin

Virtualisierung (Hyper-V, VMware ESXi, Proxmox)

Fuer VM-Datastores ist Block-Storage (SAN) der klassische Ansatz, weil Hypervisoren mit Cluster-Dateisystemen (VMFS bei VMware, CSV bei Hyper-V) genau fuer gleichzeitigen Mehrfachzugriff mehrerer Hosts auf dieselbe LUN gebaut sind - Voraussetzung fuer Live-Migration und automatisches Failover. iSCSI reicht fuer die meisten KMU-Cluster locker aus; Fibre Channel lohnt sich erst bei sehr I/O-intensiven Workloads (grosse Datenbank-Cluster, viele gleichzeitige VMs mit hohem IOPS-Bedarf).

Aber: Moderne Hypervisoren unterstuetzen auch NFS-Datastores direkt (VMware seit Jahren produktiv, Proxmox ueber NFS-Storage-Backend). Das ist technisch File-Storage, funktioniert aber im Virtualisierungskontext fast wie Block-Storage, weil der Hypervisor die VM-Disk-Dateien (VMDK, qcow2) selbst verwaltet. Fuer kleinere KMU-Cluster mit zwei bis drei Hosts ist ein NFS-Datastore auf einem guten NAS oft die pragmatischste und guenstigste Loesung - siehe auch Virtualisierung Grundlagen und VMware ESXi Grundlagen.

Fileserver und Abteilungslaufwerke

Klarer NAS-Fall. SMB-Freigaben mit AD-Integration, Quotas, Snapshots fuer versehentlich geloeschte Dateien - das ist die Kernkompetenz von NAS-Systemen. Ein SAN waere hier reine Verschwendung, weil du auf dem SAN sowieso wieder einen Dateiserver mit SMB-Freigabe drauf betreiben muesstest (SAN-LUN an einen Windows-Server anbinden, NTFS formatieren, Freigabe einrichten) - genau das, was ein NAS von Haus aus mitbringt. Details zur Freigabe-Konfiguration unter Windows Server Freigaben.

Backup-Target

Beide Architekturen kommen als Backup-Ziel infrage, aber mit unterschiedlichen Rollen: NAS als direktes Backup-Repository (z.B. Veeam-Repository per SMB oder NFS-Mount) ist im KMU der Standardfall - guenstig, gross, WORM-/Immutable-faehig bei modernen NAS-Betriebssystemen. SAN-LUNs als Backup-Ziel machen dann Sinn, wenn die Backup-Software (z.B. fuer synthetische Volltage oder sehr hohe Restore-Geschwindigkeit) direkten Blockzugriff verlangt.

Hybrid-Ansaetze: Unified Storage

Die meisten modernen Enterprise- und auch gehobenen SMB-Storage-Systeme (Synology Unified Controller, QNAP mit iSCSI-LUN-Support, Dell PowerStore, NetApp ONTAP, TrueNAS) sprechen heute beide Welten gleichzeitig: Dasselbe physische Array liefert File-Shares per SMB/NFS UND Block-LUNs per iSCSI (teils auch FC) - Unified Storage. Ein Controller, ein Management-Interface, ein Storage-Pool, aus dem beide Protokolle bedient werden.

Fuer KMU ist das oft der wirtschaftlich sinnvollste Weg: ein Array fuer Fileserver-Freigaben, VM-Datastores per iSCSI und Backup-Repository gleichzeitig, statt getrennter NAS- und SAN-Hardware. Der Kompromiss: Ein einzelnes Array ist ein einzelner Single Point of Failure fuer beide Workload-Typen - faellt der Controller aus, sind File- UND Block-Zugriff gleichzeitig weg. Bei kritischen Workloads lohnt sich deshalb ein Unified-System mit redundanten Controllern (Active/Active oder Active/Passive) statt eines einzelnen Controllers mit blossem RAID-Schutz auf Disk-Ebene.

Ausfallsicherheit und Wachstumsplanung

Unabhaengig von der gewaehlten Architektur gelten dieselben Grundprinzipien, aber mit unterschiedlicher Umsetzung:

RAID/Erasure Coding auf Disk-Ebene schuetzt vor dem Ausfall einzelner Laufwerke, nicht vor Controller- oder Netzwerk-Ausfall. Details zu RAID-Leveln findest du unter RAID-Level im Detail.

Controller-Redundanz ist bei SAN und Unified Storage Pflicht fuer produktive Workloads - ein Array mit nur einem Controller ist ein Single Point of Failure, egal wie gut das RAID darunter ist. Enterprise-Arrays bieten Active/Active-Controller mit automatischem Failover innerhalb von Sekunden.

Pfad-Redundanz (Multipathing) verhindert, dass ein einzelnes defektes Kabel, ein Switch oder ein HBA den Storage-Zugriff kappt. Bei iSCSI heisst das MPIO (Multipath I/O) mit mindestens zwei physisch getrennten NICs pro Host, bei Fibre Channel zwei unabhaengige Fabrics (Fabric A/B) mit je eigenem HBA-Port.

# MPIO-Feature installieren und fuer iSCSI aktivieren
Install-WindowsFeature -Name Multipath-IO
Enable-MSDSMAutomaticClaim -BusType iSCSI
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR   # Round Robin

Wachstumsplanung unterscheidet sich deutlich: DAS wächst durch neue/groessere Server, NAS meist durch Erweiterungs-Shelfs oder Plattentausch (Vorsicht: Controller-CPU/RAM-Limits werden oft vor der Kapazitaet zum Flaschenhals), SAN durch zusaetzliche Shelfs am bestehenden Controller-Paar bis zur Controller-Grenze, danach durch Scale-Out (zusaetzliche Controller-Knoten im selben Cluster, bei modernen Arrays wie PowerStore oder ONTAP AFF Standard).

Entscheidungsmatrix nach Workload

Entscheidungsbaum fuer die Praxis

Frage 1: Greifen mehrere Hosts GLEICHZEITIG auf denselben Datenbestand zu?
│
├─ NEIN (nur ein Server nutzt den Storage exklusiv)
│   └─ DAS oder lokales RAID reicht meist.
│       Ausnahme: geplantes zukuenftiges Clustering -> gleich SAN/NAS einplanen.
│
└─ JA, mehrere Hosts brauchen Zugriff
    │
    Frage 2: Brauchen die Hosts Datei-Zugriff (SMB/NFS) oder rohe Bloecke?
    │
    ├─ Datei-Zugriff (Fileserver, Freigaben, NFS-Datastore)
    │   └─ NAS. Guenstiger, einfacher, ausreichend fuer die meisten Faelle.
    │
    └─ Block-Zugriff (Cluster-Dateisystem, DB-Cluster, hohe IOPS)
        │
        Frage 3: Ist die vorhandene Ethernet-Infrastruktur ausreichend
        (min. 10GbE, dediziertes VLAN, kein Overbooking)?
        │
        ├─ JA -> iSCSI-SAN. Guenstigster Einstieg in Block-Storage.
        │
        └─ NEIN, hoechste Performance/Isolation noetig
            -> Fibre-Channel-SAN. Hoehere Kosten, aber
               vollstaendig getrenntes Netzwerk und Hardware-Offload.

Zusatzfrage in jedem Fall: Deckt ein einzelnes Unified-Storage-System
(File + Block auf einem Array) beide Anforderungen wirtschaftlicher ab
als zwei getrennte Systeme? Bei mittleren KMU-Groessen (20-150 MA)
meist JA.

Sicherheitsaspekte, die oft uebersehen werden

Storage-Sicherheit endet nicht bei RAID. Ein paar Punkte, die in der Praxis regelmaessig fehlen:

• LUN-Masking und Zoning: Ohne saubere Zuordnung, welcher Host welche LUN sehen darf, kann ein falsch konfigurierter Host versehentlich eine fremde LUN einbinden und formatieren. Bei Fibre Channel per Zoning auf Switch-Ebene, bei iSCSI per IQN-basiertem Initiator-Whitelisting (wie im obigen PowerShell-Beispiel) durchsetzen.
• CHAP-Authentifizierung fuer iSCSI: iSCSI-Verbindungen ohne CHAP sind nur durch IP/IQN-Filterung geschuetzt, was sich leicht spoofen laesst. Fuer produktive Umgebungen gehoert mindestens Ein-Weg-CHAP, besser gegenseitiges CHAP dazu.
• Verschluesselung im Ruhezustand: Sowohl NAS- als auch SAN-Systeme bieten heute Data-at-Rest-Encryption. Gerade bei NAS-Systemen, die auch mal ins Aussenlager oder in eine Zweigstelle wandern, ist das Pflicht, nicht Kuer.
• Management-Interface-Isolation: Das Storage-Management-Interface (Web-GUI, SSH, REST-API) gehoert in ein separates Management-VLAN ohne Erreichbarkeit aus dem normalen Client-Netz - ein kompromittierter Client sollte niemals direkten Zugriff auf die Storage-Verwaltung haben.

# Beispiel: CHAP-Konfiguration fuer ein iSCSI-Target (Auszug, herstellerunabhaengiges Schema)
targets:
  - name: sql-cluster-lun01
    chap:
      enabled: true
      mutual: true
      username: "sql01-initiator"
      secret: "MindestensZwoelfZeichenLangesGeheimnis!"
    allowed_initiators:
      - iqn.1991-05.com.microsoft:sql01.kmu.local
      - iqn.1991-05.com.microsoft:sql02.kmu.local

Praxis-Szenario: Ein typisches Schweizer KMU

Ein Ingenieurbuero mit 45 Mitarbeitenden betreibt CAD-Arbeitsplaetze, ein ERP-System auf zwei virtualisierten Servern und klassische Office-Fileshares. Die Ausgangslage: ein in die Jahre gekommener Einzelserver mit DAS, der zunehmend zum Flaschenhals wird, weil CAD-Projektdateien direkt darauf liegen und gleichzeitig die VMs darauf laufen.

Die gewaehlte Architektur: Ein Unified-Storage-System mit zwei redundanten Controllern, SSD-Cache-Tier, das gleichzeitig eine SMB-Freigabe fuer CAD-Projektdaten und Office-Dokumente bereitstellt UND per iSCSI zwei LUNs an einen kleinen Hyper-V-Cluster (2 Hosts) fuer die ERP-VMs liefert. Das Backup laeuft auf ein separates, guenstigeres NAS im Nebenraum mit immutable Snapshots - physisch getrennt vom Produktiv-Array, aber im selben Gebaeude, ergaenzt durch eine Cloud-Kopie fuer den Fall eines Totalschadens.

Diese Loesung deckt sowohl die File- als auch die Block-Anforderung mit einem Hauptsystem ab, haelt die Kosten durch die Unified-Architektur im Rahmen und trennt Backup sauber vom Produktivsystem - ohne die Komplexitaet eines dedizierten Fibre-Channel-SAN, das fuer diese Groessenordnung ueberdimensioniert waere.

Weiterlernen

• What is a SAN? - Microsoft-Dokumentation zu Storage-Optionen unter Windows Server
• iSCSI Target Server Overview - offizielle Doku zur iSCSI-Target-Konfiguration
• Fibre Channel - INCITS T11 Standards - Standardisierungsgremium fuer Fibre-Channel-Technologien
• VMware Storage Documentation - Datastore-Typen und Multipathing bei ESXi
• Synology Unified Controller / iSCSI Manager - Beispiel fuer Unified-Storage im SMB-Segment
• NIST Guide to Storage Encryption Technologies - Grundlagen zu Data-at-Rest-Encryption

Verwandte Themen: NAS Grundlagen, SAN Grundlagen: iSCSI und Fibre Channel, RAID-Level im Detail, Backup-Strategie 3-2-1-Regel, Virtualisierung Grundlagen, VLAN Grundlagen

Videos

YouTube