SAN-Grundlagen: iSCSI und Fibre Channel im Vergleich

Warum ueberhaupt ein SAN

Ein Storage Area Network (SAN) loest ein einziges Grundproblem: Mehrere Server sollen auf denselben Block-Storage zugreifen koennen, so als haetten sie eine eigene, lokal angeschlossene Festplatte – aber physisch liegt der Speicher zentral auf einem Storage-System. Das ist die Voraussetzung fuer Hyper-V- oder VMware-Cluster mit Live Migration, fuer SQL-Server-Failover-Cluster-Instanzen und fuer jede Umgebung, in der mehrere Hosts dieselben Daten mit garantierter Konsistenz sehen muessen.

Der Unterschied zu einem NAS ist entscheidend: Ein NAS liefert Dateien ueber SMB oder NFS aus (File-Level), ein SAN liefert rohe Bloecke aus (Block-Level) und laesst den anfragenden Host selbst entscheiden, welches Dateisystem er darauf anlegt. Fuer den Host sieht eine SAN-LUN aus wie eine lokale Festplatte – kein Netzlaufwerk, sondern ein Datentraeger unter Datentraegerverwaltung.

Zwei Transportwege haben sich am Markt durchgesetzt: iSCSI (SCSI-Kommandos verpackt in TCP/IP, laeuft ueber normales Ethernet) und Fibre Channel (ein eigenes, dediziertes Protokoll mit eigener Verkabelung und eigenen Switches). Dazwischen steht FCoE als selten gewordener Hybrid. Dieser Artikel zeigt beide Wege im Detail, inklusive der Sicherheits- und Multipathing-Mechanismen, die in der Praxis über Stabilität und Performance entscheiden.

iSCSI: Block-Storage ueber Standard-Ethernet

Initiator und Target

iSCSI transportiert SCSI-Kommandos innerhalb von TCP/IP-Paketen zwischen zwei Rollen:

• Initiator: der Client, der Speicher anfordert – typischerweise ein Windows- oder Linux-Server. Windows bringt den Software-iSCSI-Initiator seit Windows Server 2008 vorinstalliert mit (iscsicpl.exe beziehungsweise das Cmdlet-Modul MSDSM).
• Target: das Speichersystem, das eine oder mehrere LUNs anbietet – ein SAN-Array, ein NAS mit iSCSI-Feature (Synology, QNAP), oder unter Windows Server die Rolle “iSCSI-Zielserver” (Install-WindowsFeature FS-iSCSITarget-Server).

Jeder Initiator und jedes Target hat einen eindeutigen Namen im IQN-Format (iSCSI Qualified Name), zum Beispiel iqn.2026-01.ch.firma:srv-sql01-initiator. Dieser Name ersetzt bei iSCSI, was bei Fibre Channel der WWPN ist – er identifiziert einen Teilnehmer eindeutig, unabhaengig von der IP-Adresse.

# iSCSI-Initiator-Dienst starten und IQN des Servers auslesen
Start-Service MSiSCSI
Get-InitiatorPort | Select-Object NodeAddress

# Target per IP/Portal entdecken (Standardport 3260/TCP)
New-IscsiTargetPortal -TargetPortalAddress 10.20.30.10 -TargetPortalPortNumber 3260

# Verfuegbare Targets auf diesem Portal auflisten
Get-IscsiTarget

# Verbindung zu einem Target aufbauen
Connect-IscsiTarget -NodeAddress "iqn.2010-01.ch.synology:storage01.target1"

CHAP-Authentifizierung

iSCSI-Traffic laeuft standardmaessig unverschluesselt und ohne Authentifizierung ueber das Netzwerk – jeder Initiator, der das Portal erreicht, kann sich theoretisch mit einem Target verbinden, wenn keine weiteren Schranken existieren. CHAP (Challenge Handshake Authentication Protocol) schliesst diese Luecke, indem Initiator und Target sich gegenseitig mit einem gemeinsamen Geheimnis (Secret) authentifizieren, ohne das Secret selbst über das Netz zu senden.

Es gibt zwei Auspraegungen:

• Einweg-CHAP (One-way): Nur das Target prueft den Initiator. Reicht fuer die meisten KMU-Szenarien.
• Gegenseitiges CHAP (Mutual CHAP): Zusaetzlich prueft der Initiator, dass er wirklich mit dem erwarteten Target spricht – schuetzt vor einem untergeschobenen, gefaelschten Target im selben Netzsegment (Spoofing).

# CHAP-Zugangsdaten beim Verbindungsaufbau setzen (Einweg-CHAP)
Connect-IscsiTarget -NodeAddress "iqn.2010-01.ch.synology:storage01.target1" `
  -AuthenticationType ONEWAYCHAP `
  -ChapUsername "srv-sql01" `
  -ChapSecret "Ch4ngeMe-LangesSecret!"

# Bestehende Session pruefen
Get-IscsiConnection | Format-Table -AutoSize

CHAP ersetzt keine Netzwerksegmentierung. Es verhindert unautorisierte Verbindungen, verschluesselt aber den eigentlichen Datenverkehr nicht (dafuer gibt es IPsec, das bei iSCSI selten produktiv eingesetzt wird, weil es Performance kostet). In der Praxis kombiniert man CHAP daher immer mit einem isolierten Storage-VLAN – dazu weiter unten mehr.

MPIO: Multipathing fuer iSCSI

Ein einzelner Netzwerkpfad zwischen Server und Storage ist ein Single Point of Failure und begrenzt zusaetzlich den Durchsatz auf eine NIC. MPIO (Multipath I/O) loest beides: Der Windows-Server sieht dieselbe LUN ueber mehrere physische Pfade (mehrere NICs, mehrere Switches, mehrere Storage-Controller-Ports) und buendelt sie zu einem logischen Datentraeger.

# MPIO-Feature installieren
Install-WindowsFeature -Name Multipath-IO -IncludeManagementTools

# Unterstuetzung fuer iSCSI-Geraete in MPIO aktivieren (Neustart erforderlich)
Enable-MSDSMAutomaticClaim -BusType iSCSI

# Load-Balancing-Policy fuer eine bestimmte LUN setzen
Get-MSDSMSupportedHW
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

# MPIO-Pfade zu einer LUN pruefen
mpclaim -s -d

Wichtige Load-Balancing-Policies:

Fuer belastbares Multipathing gilt als Minimalarchitektur: zwei physische NICs pro Server, zwei unabhaengige Storage-Switches (kein Single-Switch-Design!), zwei Controller-Ports auf dem Array. Fallen ein Switch oder eine NIC aus, bleibt der zweite Pfad aktiv und der Betrieb laeuft unterbrechungsfrei weiter.

Fibre Channel: Das dedizierte Storage-Fabric

Grundarchitektur und WWPN

Fibre Channel (FC) ist ein eigenstaendiges Netzwerkprotokoll, das nicht auf Ethernet oder IP aufbaut. Es braucht eigene Host Bus Adapter (HBA) in den Servern, eigene FC-Switches (“Fabric”) und meist Glasfaserverkabelung (LC-Duplex bei den ueblichen 8/16/32-Gbit/s-Geschwindigkeiten). Jeder FC-Port hat einen weltweit eindeutigen WWPN (World Wide Port Name) – ein 8-Byte-Bezeichner, vergleichbar mit einer MAC-Adresse, der den physischen Anschluss identifiziert, unabhaengig von IP oder Hostname.

Zusaetzlich gibt es den WWNN (World Wide Node Name), der das gesamte Geraet (z.B. einen HBA mit mehreren Ports) identifiziert. Fuer Zoning und Masking arbeitet man in der Praxis fast ausschliesslich mit dem WWPN, weil Zoning port-genau erfolgen soll.

# WWPN eines FC-HBA-Ports unter Linux auslesen
cat /sys/class/fc_host/host0/port_name

# Unter Windows: FC-Adapterinformationen inkl. WWPN anzeigen
Get-InitiatorPort | Where-Object {$_.ConnectionType -eq "Fibre Channel"} | Format-Table NodeAddress, PortAddress

Ein typischer WWPN sieht so aus: 50:06:0e:80:12:34:56:78. Die ersten drei Byte (OUI) identifizieren den Hersteller, der Rest ist geraetespezifisch.

Zoning: Wer darf mit wem sprechen

Zoning ist die Zugriffskontrolle auf FC-Switch-Ebene und legt fest, welche WWPNs sich innerhalb der Fabric ueberhaupt “sehen” koennen. Ohne Zoning sieht theoretisch jeder Initiator jedes Target in derselben Fabric – das ist fehleranfaellig, weil unterschiedliche Betriebssysteme und HBA-Treiber sich gegenseitig stoeren koennen, wenn sie sich gegenseitig entdecken.

Best Practice ist Single Initiator Zoning (SIZ), manchmal auch Single-Initiator-Single-Target-Zoning genannt: Jede Zone enthaelt genau einen Initiator-WWPN und die dazugehoerigen Target-WWPNs. Das minimiert die “Sichtbarkeitsflaeche” – faellt ein HBA aus oder sendet fehlerhafte Frames, ist der Blast Radius auf eine einzige Zone begrenzt.

# Beispiel: Zoning-Konfiguration auf einem Brocade-FC-Switch (CLI)
zonecreate "Z_SRV-SQL01_HBA0_ARRAY01-CTRLA", "50:0a:aa:bb:cc:dd:ee:01;50:06:0e:80:12:34:56:78"
zonecreate "Z_SRV-SQL01_HBA1_ARRAY01-CTRLB", "50:0a:aa:bb:cc:dd:ee:02;50:06:0e:80:12:34:56:79"

# Zonen einer Konfiguration hinzufuegen und aktivieren
cfgadd "PROD_CFG", "Z_SRV-SQL01_HBA0_ARRAY01-CTRLA"
cfgadd "PROD_CFG", "Z_SRV-SQL01_HBA1_ARRAY01-CTRLB"
cfgenable "PROD_CFG"

Zwei Zoning-Varianten sind ueblich: WWPN-Zoning (empfohlen, weil unabhaengig vom physischen Switch-Port) und Port-Zoning (basierend auf der physischen Switch-Port-Nummer, unflexibel bei Kabeltausch, heute kaum noch verwendet).

LUN-Masking: Die zweite Schutzschicht

Zoning regelt, wer in der Fabric ueberhaupt kommunizieren kann – LUN-Masking regelt danach, welche konkreten LUNs ein Host auf dem Storage-Array tatsaechlich sehen und mounten darf. Beide Mechanismen sind komplementaer und sollten immer gemeinsam eingesetzt werden: Zoning auf Switch-Ebene, Masking auf Array-Ebene.

LUN-Masking wird typischerweise ueber sogenannte Host-Gruppen oder Initiator-Gruppen auf dem Storage-Array konfiguriert: Ein oder mehrere Host-WWPNs werden einer Gruppe zugeordnet, und dieser Gruppe werden dann bestimmte LUNs freigegeben.

Beispiel-Konfiguration auf einem Storage-Array (Konzept, herstellerunabhaengig):

Host-Gruppe "HG-SRV-SQL01"
  Mitglieder: 50:0a:aa:bb:cc:dd:ee:01, 50:0a:aa:bb:cc:dd:ee:02
  Sichtbare LUNs: LUN10 (Datenbank-Volume), LUN11 (Log-Volume)

Host-Gruppe "HG-HYPERV-CLUSTER"
  Mitglieder: alle WWPNs der Cluster-Knoten
  Sichtbare LUNs: LUN20 (CSV1), LUN21 (CSV2), LUN99 (Quorum)

Multipathing bei Fibre Channel

Genau wie bei iSCSI braucht FC redundante physische Pfade und einen Mechanismus, der sie koordiniert. Unter Windows uebernimmt das derselbe MPIO-Stack wie bei iSCSI (Multipath-IO-Feature), haeufig ergaenzt durch einen herstellerspezifischen DSM (Device Specific Module) von HPE, Dell, NetApp oder Pure Storage, der genauere Kenntnis der Array-Eigenheiten hat als der generische Microsoft-DSM.

Ein zentrales Konzept dabei ist ALUA (Asymmetric Logical Unit Access): Viele moderne Arrays haben zwei Controller, aber nur einer besitzt zu einem Zeitpunkt den “optimalen” (direkten) Pfad zu einer LUN – der andere Pfad funktioniert zwar, geht aber ueber eine interne Controller-zu-Controller-Verbindung und ist dadurch langsamer. ALUA meldet dem Host, welche Pfade “Active/Optimized” und welche “Active/Non-Optimized” sind, damit MPIO bevorzugt die schnellen Pfade nutzt.

# ALUA-/Pfadstatus einer LUN unter Windows pruefen
mpclaim -s -d
Get-PhysicalDisk | Select-Object DeviceId, FriendlyName, HealthStatus, OperationalStatus

FCoE: Der selten gewordene Zwischenweg

FCoE (Fibre Channel over Ethernet) kapselt native FC-Frames direkt in Ethernet-Frames, ohne den Umweg ueber TCP/IP – anders als iSCSI, das vollstaendig auf dem TCP/IP-Stack aufbaut. Das Ziel war, FC-Traffic und regulaeren Ethernet-Traffic ueber dieselbe physische Infrastruktur (Converged Network Adapters, CNAs) zu fahren und so Kabel, Switch-Ports und HBAs einzusparen.

FCoE braucht dafuer zwingend Data Center Bridging (DCB), eine Erweiterung von Ethernet um verlustfreie Uebertragung (Priority Flow Control, PFC) und Bandbreitenreservierung (Enhanced Transmission Selection, ETS) – normales, “bestes Bemuehen”-Ethernet ist fuer FC-Traffic ungeeignet, weil FC keine eigene Wiederholungslogik auf dieser Ebene hat wie TCP.

In der Praxis hat sich FCoE nicht in der Breite durchgesetzt. Die Kombination aus hoher Komplexitaet (DCB-Konfiguration auf jedem beteiligten Switch), dem gesunkenen Preis von 25/40/100-GbE-Infrastruktur fuer iSCSI und der weiterhin bestehenden Beliebtheit von “reinem” FC bei High-End-Workloads hat FCoE zu einer Nischenloesung gemacht, die man heute primaer in bestehenden, aelteren Blade-Server-Umgebungen (z.B. Cisco UCS mit FEX/Fabric-Interconnects) noch antrifft.

Jumbo Frames und dediziertes Storage-VLAN

Fuer iSCSI (und generell fuer jeden IP-basierten Storage-Traffic) sind zwei Netzwerk-Massnahmen praktisch obligatorisch:

Jumbo Frames erhoehen die maximale Uebertragungseinheit (MTU) von den ueblichen 1500 Byte auf meist 9000 Byte. Weniger Frames fuer dieselbe Datenmenge bedeuten weniger CPU-Overhead fuer Framing/Header-Verarbeitung auf Server und Switch – bei Storage-Workloads mit vielen grossen, sequenziellen I/Os ein spuerbarer Effekt.

# Jumbo Frames auf einem Windows-Server-NIC aktivieren
Get-NetAdapterAdvancedProperty -Name "Storage-NIC1" -DisplayName "Jumbo Packet"
Set-NetAdapterAdvancedProperty -Name "Storage-NIC1" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"

# MTU-Pfad end-to-end testen (kein Fragmentieren erlaubt = "-f" unter Windows ping)
ping -f -l 8972 10.20.30.10

Ein dediziertes Storage-VLAN trennt iSCSI-Traffic physisch oder zumindest logisch vom normalen LAN-Verkehr der Anwender. Gruende dafuer:

• Sicherheit: CHAP schuetzt vor unautorisierten Verbindungen, aber nicht vor Sniffing im selben Broadcast-Domain. Ein separates VLAN reduziert die Angriffsflaeche erheblich.
• Performance-Isolation: Ein Broadcast-Sturm oder ein ueberlasteter Uplink im Anwender-LAN darf niemals den Storage-Traffic beeintraechtigen – Storage-I/O ist meist latenzsensitiver als normaler Datenverkehr.
• Klarheit im Troubleshooting: Ein isoliertes Storage-VLAN mit eigenem IP-Subnetz macht sofort ersichtlich, welcher Traffic zum SAN gehoert, ohne ihn aus einem gemischten Netz herausfiltern zu muessen.

; Beispiel: Storage-VLAN auf einem Switch-Port konfigurieren (Cisco-aehnliche Syntax)
interface GigabitEthernet1/0/10
 description Uplink-zu-SRV-SQL01-Storage-NIC1
 switchport mode access
 switchport access vlan 30
 spanning-tree portfast
 mtu 9216

Entscheidungsbaum: iSCSI oder Fibre Channel?

Ist bereits FC-Infrastruktur (HBAs, Switches, Verkabelung) vorhanden?
├── Ja  -> Bei FC bleiben, solange die Kapazitaet reicht.
│         Erweiterung meist guenstiger als Parallelbetrieb zweier Fabrics.
└── Nein -> Neuanschaffung noetig. Weiter pruefen:

Braucht die Workload nachweislich extreme, konstante Low-Latency-IOPS
(z.B. grosse OLTP-Datenbank, viele kleine synchrone Schreibvorgaenge)?
├── Ja  -> Fibre Channel evaluieren, trotz hoeherer Anfangsinvestition.
└── Nein -> Weiter pruefen:

Ist im Haus 10/25-GbE-Netzwerk-Know-how vorhanden,
aber kein FC-spezifisches Wissen?
├── Ja  -> iSCSI. Nutzt vorhandenes Ethernet-Skillset,
│         Betrieb durch bestehendes Netzwerk-Team moeglich.
└── Nein (weder noch) -> iSCSI ist trotzdem meist der pragmatischere Einstieg,
          weil Ethernet-Wissen breiter verfuegbar und guenstiger aufzubauen ist
          als FC-spezifisches Fachwissen.

Budget stark limitiert, bestehende Switches sollen mitgenutzt werden?
├── Ja  -> iSCSI (ggf. mit separatem VLAN statt komplett neuer Switches).
└── Nein -> Beide Optionen offen, Entscheidung nach Performance-Anforderung.

Kostenvergleich und Einsatzszenarien im KMU

Fuer die grosse Mehrheit der Schweizer KMU mit 20 bis 300 Arbeitsplaetzen ist iSCSI die pragmatischere Wahl: Die Performance-Anspruche liegen selten im Bereich, wo der Latenzunterschied zu Fibre Channel spuerbar wird, waehrend die Einsparung bei Hardware und die breitere Verfuegbarkeit von Ethernet-Fachwissen im Team klar zugunsten von iSCSI sprechen. Fibre Channel bleibt die richtige Wahl, wenn entweder bereits eine FC-Fabric besteht und amortisiert werden soll, oder wenn eine konkrete, messbare Latenz-/IOPS-Anforderung existiert, die iSCSI auch mit 25-GbE-Netzwerk nicht zuverlaessig erreicht (z.B. durchgehend hohe Transaktionsraten in einer grossen ERP-Datenbank).

Typische Fallstricke in der Praxis

• CHAP aktiviert, aber Secret in Klartext-Skripten abgelegt: CHAP nuetzt wenig, wenn das Secret in einem ungeschuetzten PowerShell-Skript oder einer Konfigurationsdatei im Netzlaufwerk liegt. Secrets gehoeren in einen Passwort-Tresor oder zumindest in ein zugriffsbeschraenktes Verzeichnis.
• Zoning erstellt, aber nie aktiviert: Auf vielen FC-Switches muss eine Zoning-Konfiguration explizit mit einem Befehl wie cfgenable aktiv geschaltet werden. Eine erstellte, aber nicht aktivierte Zone hat keinerlei Wirkung – ein haeufiger Grund, warum ein neu angeschlossener Host “das Storage nicht sieht”.
• Asymmetrisches MPIO nach Storage-Wartung: Nach einem Controller-Failover oder Firmware-Update auf dem Array bleiben manchmal einzelne Pfade im Zustand “Degraded” haengen, ohne dass das sofort auffaellt – regelmaessige Pfadpruefung (mpclaim -s -d) gehoert ins Monitoring, nicht nur in die Fehlersuche.
• Storage-Traffic ohne QoS im gemeinsamen Netz: Wird das Storage-VLAN doch ueber gemeinsame Uplinks mit LAN-Traffic gefuehrt (z.B. aus Kostengruenden), muss zwingend Priorisierung (QoS/DCB) konfiguriert werden – sonst kann ein grosser Backup-Job im LAN das SAN ausbremsen.
• LUN zu frueh geloescht: LUN-Masking entfernt zwar die Sichtbarkeit fuer einen Host, aber das eigentliche Loeschen einer LUN auf dem Array ist ein separater, destruktiver Schritt. Vor jedem LUN-Loeschvorgang gehoert eine zweite Bestaetigung der LUN-ID gegen die Dokumentation – falsche LUN geloescht ist ein Klassiker mit Totalschaden.
• Kein Monitoring auf Fabric-Ebene: Ein einzelner “flapping” FC-Port oder eine schleichend ansteigende CRC-Fehlerrate auf einem Kabel bleibt ohne aktives Monitoring oft monatelang unbemerkt, bis der zweite Pfad ebenfalls ausfaellt und der Cluster tatsaechlich Downtime hat.

Weiterlernen

• Internet Small Computer Systems Interface (iSCSI) – Microsoft Learn
• Multipath I/O Overview – Microsoft Learn
• Fibre Channel SAN Zoning Best Practices – Thomas-Krenn-Wiki
• ISCSI Grundlagen – Thomas-Krenn-Wiki
• Fibre Channel and FCoE zoning concept – NetApp ONTAP Doku (deutsch)
• Fibre Channel oder iSCSI? – ComputerWeekly

Verwandte Seiten:

• NAS vs. SAN vs. DAS – die Entscheidung – Grundsatzentscheidung vor jedem SAN-Projekt
• RAID-Level im Detail – wie die LUNs hinter iSCSI/FC intern abgesichert sind
• Windows Failover Cluster Grundlagen – der haeufigste Anwendungsfall fuer Shared Storage
• VLAN-Grundlagen – Basis fuer das dedizierte Storage-VLAN
• Backup-Strategie: die 3-2-1-Regel – SAN ersetzt kein Backup
• Virtualisierung: Hochverfuegbarkeit – Hyper-V/VMware-Cluster auf SAN-Storage