FC, iSCSI oder SAS: Welche Speicherschnittstelle sollten Sie für Ihre Server wählen?

Wenn ein Speichersystem mit einem oder zwei Servern im selben Rack verbunden wird, ist SAS meistens der naheliegende erste Ansatz: Es ist eine einfache und verständliche Lösung ohne separate SAN-Infrastruktur. Für einen kleinen oder mittelgroßen Cluster ist iSCSI häufig die rationalere Wahl, jedoch nur mit einem dedizierten Storage-Netzwerk und Multipath-Anbindung. Für kritische Datenbanken, große Virtualisierungsumgebungen, VDI und Systeme, bei denen vorhersehbare Latenzen und Ausfallsicherheit wichtig sind, sollte eher FC in Betracht gezogen werden.

Den Anschluss eines Speichersystems nur nach der Portgeschwindigkeit auszuwählen, ist ein Fehler. In der Praxis sind andere Faktoren wichtiger:

• wie viele Server jetzt und in einem Jahr angeschlossen werden sollen;
• ob ein Clusterbetrieb erforderlich ist;
• wie kritisch Latenzen sind;
• ob es ein separates Storage-Netzwerk gibt;
• welche Ports das Speichersystem bereits besitzt;
• ob HBAs, Netzwerkkarten, SFP-Module, Kabel und Switches vorhanden sind;
• wer diese Architektur nach der Einführung administrieren wird.

Deshalb sollte man FC, iSCSI und SAS nicht einfach als „schneller oder langsamer“ vergleichen, sondern als drei unterschiedliche Anschlussarchitekturen.

Our most popular storage systems

Was genau vergleichen wir?

FC, iSCSI und SAS können eine ähnliche Aufgabe lösen: Sie geben einem Server blockbasierten Zugriff auf ein Speichersystem. Technisch sind es jedoch unterschiedliche Ansätze.

FC: ein dediziertes Storage-Netzwerk

FC, oder Fibre Channel, ist ein separates Netzwerk, das in der Regel für Datenspeicherung verwendet wird. Eine typische Konfiguration umfasst:

• FC-Adapter in den Servern;
• FC-Switches;
• SFP-Module;
• Glasfaserkabel oder DAC-Kabel;
• Zonierung für Zugriffsrechte;
• Multipath-Anbindung.

FC wird häufig für kritische Systeme gewählt, bei denen stabile Latenzen und vorhersehbares Verhalten unter Last wichtig sind. Diese Schnittstelle eignet sich gut für große Virtualisierungscluster, Datenbanken, ERP-Systeme, VDI und andere Infrastrukturen, in denen Ausfallzeiten teuer sind.

FC hat jedoch eine höhere Einstiegshürde. Man muss nicht nur das Speichersystem kaufen, sondern auch Adapter, Switches, Module, Kabel und Portlizenzen. Außerdem muss der Administrator verstehen, wie ein SAN funktioniert: Zonen, WWPN-Kennungen, zwei unabhängige Fabrics und Pfadrichtlinien auf dem Server.

iSCSI: Blockspeicher über ein IP-Netzwerk

iSCSI überträgt SCSI-Befehle über TCP/IP. Das ist im Standard IETF RFC 7143 beschrieben. Vereinfacht gesagt greift der Server über ein Ethernet-Netzwerk auf Blockspeicher zu.

Der wichtigste Vorteil von iSCSI ist die Verfügbarkeit. In vielen Infrastrukturen sind Ethernet-Switches, Netzwerkkarten, SFP-Module oder DAC-Kabel bereits vorhanden, und auch Routing des Datenverkehrs ist möglich. Deshalb kann iSCSI zu Beginn günstiger sein als FC.

Daraus folgt aber nicht, dass man iSCSI „an einen beliebigen freien Port eines Büro-Switches“ anschließen sollte. Natürlich funktioniert iSCSI auch in einem normalen Gigabit-Netzwerk, aber stabil und leistungsfähig ist diese Lösung nicht. Für Stabilität wird ein separates Storage-Netzwerk benötigt:

• separate VLANs, besser noch separate physische Switches;
• mindestens zwei unabhängige Pfade;
• dedizierte Ports am Server;
• separate IP-Subnetze;
• Kontrolle von Paketverlusten, Portfehlern und Latenzen;
• einheitliche MTU über den gesamten Pfad, wenn Jumbo Frames aktiviert werden.

iSCSI eignet sich gut für kleine und mittelgroße VMware-/Hyper-V-Cluster, Backup, Dateidienste, Testumgebungen und universelle Infrastruktur. Die Qualität hängt jedoch direkt vom Netzwerkdesign ab.

SAS: direkte Anbindung ohne SAN

SAS, oder Serial Attached SCSI, wird am häufigsten für die direkte Verbindung eines Servers mit einem Speichersystem oder einer Disk-Shelf verwendet. IBM beschreibt SAS als serielle Schnittstelle und Protokollgruppe für den Datenaustausch zwischen Storage-Geräten.

Eine typische Konfiguration erfordert:

• einen SAS-HBA oder RAID-Controller im Server;
• externe Mini-SAS- oder Mini-SAS-HD-Kabel;
• ein Speichersystem mit Host-SAS-Ports;
• ein korrektes Anschlussschema zu einem oder zwei Controllern.

SAS ist praktisch, wenn das Speichersystem direkt neben dem Server steht und ein einzelner Server oder ein kleines Serverpaar angebunden werden soll. In dieser Architektur werden weder FC-Switches noch ein separates Ethernet-Storage-Netzwerk benötigt. Die Nachteile sind ebenfalls klar: weniger Flexibilität, begrenzte Reichweite und Beschränkungen bei der Zahl der anschließbaren Server. Es ist erwähnenswert, dass sich auch mit SAS ein Storage-Netzwerk aufbauen lässt und spezielle SAS-Switches existieren. Diese Geräte sind jedoch selten und sehr spezifisch, sodass dieser Weg in den meisten Fällen nicht sinnvoll ist.

Wie wählt man die passende Schnittstelle für die eigene Umgebung?

Man sollte nicht mit der Frage „welche Schnittstelle ist schneller?“ beginnen, sondern mit der Topologie.

Ein Server und ein Speichersystem im selben Rack

Zuerst sollte SAS geprüft werden.

Es eignet sich für:

• einen Dateiserver;
• eine kleine Datenbank;
• einen Backup-Server;
• kompakte Virtualisierung;
• die direkte Anbindung einer Disk-Shelf;
• kleine Infrastruktur ohne separates SAN.

Vor dem Kauf ist wichtig zu prüfen, ob das Speichersystem tatsächlich Host-SAS-Ports für den Serveranschluss besitzt. SAS-Anschlüsse auf der Rückseite können für Erweiterungsshelves gedacht sein und nicht für Server. Das sind unterschiedliche Szenarien.

2–4 Server in einem kleinen Cluster

Hier fällt die Wahl meistens zwischen iSCSI und FC.

iSCSI eignet sich, wenn:

• bereits eine 10/25-GbE-Infrastruktur vorhanden ist;
• ein separates Storage-Netzwerk bereitgestellt werden kann;
• die Last moderat ist;
• das Team Ethernet administrieren kann;
• das Budget begrenzt ist.

FC sollte geprüft werden, wenn:

• Latenzen kritisch sind;
• Infrastrukturausfälle teuer sind;
• der Cluster wachsen soll;
• Budget für ein SAN vorhanden ist;
• im Unternehmen bereits Erfahrung mit FC besteht.

SAS ist ebenfalls möglich, aber nur dann, wenn das konkrete Speichersystem und die Server ein solches Anschlussschema unterstützen. Für künftiges Wachstum ist SAS weniger flexibel.

VMware, Hyper-V und andere Virtualisierungscluster

Für Virtualisierung ist nicht nur Geschwindigkeit wichtig, sondern auch stabiler Zugriff auf LUNs, Unterstützung für Multipath I/O (MPIO), Kompatibilität mit dem Hypervisor und das Verhalten bei einem Pfadausfall.

Die VMware-Dokumentation von Broadcom zu FC SAN beschreibt gesondert die Arbeit von ESXi mit Fibre Channel und Empfehlungen für die SAN-Anbindung.

Für einen kleinen Cluster mit 2–6 Hosts reicht iSCSI oft aus, wenn der Storage-Datenverkehr isoliert ist. Für kritischere Virtualisierung, eine größere Zahl von Hosts und strenge SLAs wird häufiger FC gewählt.

SAS ist in einem Cluster nicht immer möglich. Es muss anhand der Kompatibilitätsmatrix des Speichersystems, der Controller, der Server und des Hypervisors geprüft werden.

Datenbank mit kritischen Latenzanforderungen

Für eine stark belastete Produktionsdatenbank wird häufiger FC gewählt. Der Grund ist nicht nur die Geschwindigkeit, sondern auch das vorhersehbare Verhalten bei Lastspitzen.

Das bedeutet jedoch nicht, dass iSCSI für Datenbanken nicht verwendet werden kann. Wenn das Netzwerk korrekt aufgebaut ist, 25 GbE oder mehr genutzt werden, separate Pfade eingerichtet sind und keine Konkurrenz mit Benutzerdatenverkehr besteht, kann iSCSI eine funktionierende Option sein.

SAS eignet sich gut für eine Datenbank auf einem einzelnen Server, wenn das Speichersystem direkt angeschlossen wird und keine Skalierung auf viele Hosts erforderlich ist.

Backup, Archiv und Dateidienste

Für Backups sind stabile Durchsatzraten und das Backup-Fenster oft wichtiger als minimale Latenz.

In der Regel reicht:

• iSCSI — wenn ein dediziertes Netzwerk vorhanden ist und flexible Anbindung benötigt wird;
• SAS — wenn Backup-Server und Speichersystem nebeneinander stehen;
• FC — wenn bereits ein SAN vorhanden ist oder Backup über die bestehende FC-Infrastruktur laufen soll.

Hier sollte man die Rolle der Schnittstelle nicht überschätzen. Ein langsamer Disk-Pool, Deduplizierung, ein schwacher Controller oder ein überlastetes Netzwerk können die Geschwindigkeit stärker begrenzen als der Anschlusstyp selbst.

VDI und Arbeitsplätze

Bei VDI sind Lastspitzen gefährlich: Massenanmeldung der Benutzer am Morgen, gleichzeitiges Booten von Desktops, Updates und Antivirus-Prüfungen.

Für eine kleine VDI-Umgebung kann iSCSI in einem dedizierten Netzwerk genutzt werden. Für eine große VDI-Infrastruktur oder strenge Latenzanforderungen sollte eher FC geprüft werden. SAS kann für eine kompakte Installation geeignet sein, stößt aber schnell an Wachstumsgrenzen.

Bild: HPE MSA 2060/2050.

Bildquelle: hpe.com

Vergleich von FC, iSCSI und SAS

Portgeschwindigkeit ist nicht gleich Anwendungsgeschwindigkeit. Die reale Performance wird von Storage-Controllern, Disk-Gruppen, Cache, RAID-Typ, Queue Depth, Betriebssystemeinstellungen, Pfadrichtlinien und Konkurrenz mit anderem Traffic beeinflusst.

Zum Beispiel kann iSCSI über 25 GbE besser funktionieren als ein schlecht geplantes FC-Netzwerk. Und SAS kann rationaler sein als FC, wenn es um einen einzelnen Server und ein Speichersystem im selben Rack geht.

Praktische Anschlussschemata

Ein Pfad zum Speichersystem

Das Schema sieht einfach aus:

Server → ein Kabel oder ein Switch → ein Storage-Port

Für eine Testumgebung ist diese Lösung akzeptabel. Für Produktion ist sie fast immer ungeeignet.

Das Problem: Jedes Element wird zu einem Single Point of Failure:

• Kabel;
• Serverport;
• HBA oder Netzwerkkarte;
• Switch;
• Storage-Port;
• Storage-Controller.

Selbst ein teures Speichersystem bietet keine Ausfallsicherheit, wenn der Server nur über einen einzigen Pfad angebunden ist.

FC mit zwei unabhängigen Fabrics

Ein korrekteres FC-Schema ist:

Server, HBA 1 → FC-Switch A → Storage-Controller A
Server, HBA 2 → FC-Switch B → Storage-Controller B

In dieser Architektur ist wichtig:

• die beiden Fabrics nicht so zu verbinden, dass der Ausfall eines Elements beide betrifft;
• Zonen für den Zugriff zu konfigurieren;
• die Sichtbarkeit der LUN über jeden Pfad zu prüfen;
• Multipath-Anbindung auf dem Server zu aktivieren;
• die Pfadauswahlrichtlinie im Betriebssystem oder Hypervisor zu prüfen;
• zu dokumentieren, welcher Port wohin verbunden ist.

Dieser Ansatz ist komplexer als ein einzelnes Kabel, aber genau dadurch ergibt FC in kritischer Infrastruktur Sinn.

iSCSI in einem separaten Storage-Netzwerk

Ein korrektes iSCSI-Schema sieht üblicherweise so aus:

Server, NIC 1 → iSCSI-Switch A oder VLAN A → Storage-Port A
Server, NIC 2 → iSCSI-Switch B oder VLAN B → Storage-Port B

Für iSCSI ist besonders wichtig, Storage-Traffic nicht mit dem normalen Büronetzwerk zu mischen. Microsoft behandelt in seinen Materialien zur iSCSI-Diagnose Netzwerkursachen für Verbindungsprobleme und Instabilität gesondert: iSCSI Storage Connectivity Troubleshooting Guidance.

In der Praxis sollte man für iSCSI im Voraus bereitstellen:

• separate VLANs oder physische Switches;
• separate IP-Subnetze;
• dedizierte Netzwerkports am Server;
• zwei unabhängige Pfade;
• Monitoring von Portfehlern, Paketverlusten und Latenzen;
• klare Regeln für MTU-Änderungen.

Jumbo Frames sollten nur aktiviert werden, wenn sie über den gesamten Pfad einheitlich konfiguriert sind: Server, Switch und Storage-Port. Eine teilweise Konfiguration verursacht oft mehr Probleme als Nutzen.

SAS direct-attached

Das SAS-Schema ist in der Regel einfacher:

Server, SAS-HBA → Mini-SAS-HD-Kabel → Storage-Controller A
Server, zweiter SAS-HBA-Port → Mini-SAS-HD-Kabel → Storage-Controller B

Diese Verbindung ist praktisch, wenn Server und Speichersystem nah beieinander stehen. Es werden keine Switches benötigt, und es muss kein separates Storage-Netzwerk geplant werden. Wichtig ist aber, im Voraus zu verstehen, wie viele Server an das konkrete Speichersystem angeschlossen werden können und ob eine ausfallsichere Variante mit zwei Controllern unterstützt wird.

Im Storage-Katalog findet man unterschiedliche Varianten derselben Produktlinie mit verschiedenen Schnittstellen. Für den Vergleich der Entscheidungslogik ist es beispielsweise sinnvoll, FC/iSCSI- und SAS-Modelle getrennt zu betrachten: HPE MSA 2050 FC/iSCSI 24SFF Storage-System und HPE MSA 2050 HD-SAS 24SFF Storage-System.

Wann sollte man FC wählen?

FC-HBA / Fibre-Channel-Adapter.

Bildquelle: offizielle Oracle-Dokumentation

FC sollte gewählt werden, wenn die Infrastruktur kritisch ist und die Zahl zufälliger Faktoren im Storage-Netzwerk reduziert werden soll.

Geeignete Szenarien:

• Produktionscluster mit VMware oder Hyper-V;
• Datenbanken mit hoher Last;
• ERP-, Buchhaltungs- und Finanzsysteme;
• VDI;
• stark belastete Dateidienste;
• Infrastruktur mit vielen Servern;
• eine Umgebung, in der FC bereits genutzt und vom Team unterstützt wird.

FC ist nützlich, weil Storage-Traffic bereits physisch vom normalen Ethernet-Netz getrennt ist. Er konkurriert nicht mit Benutzerdatenverkehr, Office-Services, Backup über LAN oder anderen Anwendungen.

Gleichzeitig entstehen zusätzliche Kosten:

• FC-HBA in jedem Server;
• mindestens zwei FC-Switches;
• SFP-Module;
• Glasfaserkabel;
• Portlizenzen;
• Ersatzmodule und Ersatzkabel;
• Zeit für Zonierung und Pfadkonfiguration.

FC ist nicht deshalb gerechtfertigt, weil es „teurer“ ist, sondern weil es ein ausgereiftes und vorhersehbares SAN-Modell für Systeme bietet, bei denen Ausfallzeiten und instabile Latenzen mehr kosten als die Hardware.

Wann sollte man iSCSI wählen?

iSCSI sollte gewählt werden, wenn eine flexible und vergleichsweise günstige Anbindung an das Speichersystem benötigt wird und die Infrastruktur bereits eine solide Ethernet-Basis besitzt.

Es eignet sich für:

• kleine und mittelgroße Virtualisierungscluster;
• Backup-Infrastruktur;
• Dateidienste;
• Test- und Entwicklungsumgebungen;
• kleine Datenbanken;
• universelle Server-Workloads;
• Unternehmen ohne eigene FC-Kompetenz.

Vor der Einführung muss geprüft werden, dass iSCSI nicht im gemeinsamen Büronetzwerk läuft, sondern in einer separaten Storage-Umgebung.

Die Mindestvoraussetzungen sind:

• 10 GbE als vernünftige Mindestbasis für moderne Aufgaben;
• 25 GbE oder mehr für dichtere Lasten;
• zwei unabhängige Pfade;
• separate VLANs oder separate Switches;
• dedizierte NIC-Ports;
• aktivierte Multipath-Anbindung;
• Monitoring von Latenzen und Fehlern;
• ein klares IP-Adressierungsschema.

Das Hauptrisiko von iSCSI ist nicht das Protokoll selbst, sondern ein schlechtes Netzwerk. Wenn Storage-Traffic über einen gemeinsamen Switch zusammen mit Benutzern, Kameras, Telefonie, WLAN und Dateikopien läuft, werden Latenzen zufällig. Auf Ebene der virtuellen Maschinen kann das wie „Hänger“ aussehen, obwohl Laufwerke und Speichersystem in Ordnung sind.

Wann sollte man SAS wählen?

SAS sollte für kompakte Architekturen gewählt werden, in denen das Speichersystem direkt an einen Server oder ein kleines Serverpaar angeschlossen wird.

Gute Szenarien:

• ein physischer Server;
• kleine Virtualisierung;
• ein Dateiserver;
• ein Backup-Server;
• direkte Anbindung einer Disk-Shelf;
• Infrastruktur in einem Rack;
• begrenztes Budget ohne das Ziel, ein SAN aufzubauen.

Die Vorteile von SAS sind klar:

• weniger Komponenten;
• kein separates SAN;
• niedrige Latenz;
• ein einfacheres Anschlussschema;
• einfachere Diagnose des physischen Pfads.

Vor dem Kauf müssen jedoch mehrere Punkte geprüft werden:

• ob das Speichersystem Host-SAS-Ports besitzt;
• wie viele Server angeschlossen werden können;
• ob die Anbindung an zwei Controller unterstützt wird;
• welche Kabel genau benötigt werden;
• welcher Steckertyp verwendet wird;
• welche Kabellänge zulässig ist;
• ob ein HBA oder RAID-Controller erforderlich ist;
• ob Betriebssystem oder Hypervisor die gewählte Architektur unterstützen;
• ob sich die Konfiguration später erweitern lässt.

SAS ist eine gute Wahl für direkte Anbindung, ersetzt aber kein SAN, wenn in einem Jahr zehn Server angebunden, in verschiedenen Racks platziert und Volumes flexibel zwischen Hosts verteilt werden sollen.

Auswahl nach Workload-Typ

Wenn die Infrastruktur von Grund auf beschafft wird, sollte man nicht nur den Preis des Speichersystems selbst vergleichen, sondern das komplette Anschlusskit. In einem Katalog für Storage-Systeme sollte man nicht nur Formfaktor und Kapazität prüfen, sondern auch Controller-Schnittstellen, Ausstattung, verfügbare Kabel, Porttypen und Erweiterungsmöglichkeiten.

Storage systems

Versteckte Anschlusskosten

Eine Schnittstelle hat nicht nur eine technische, sondern auch eine finanzielle Seite. Manchmal wirkt eine Lösung nur bis zu dem Moment günstig, in dem Kabel, Module und Lizenzen beschafft werden müssen.

Was bei FC berücksichtigt werden muss

Im Budget sollten enthalten sein:

• FC-HBA für jeden Server;
• zwei FC-Switches;
• SFP-Module;
• Glasfaserkabel;
• Portlizenzen;
• Ersatz-SFPs;
• Ersatzkabel;
• Arbeiten zur Zonenkonfiguration;
• Kompatibilitätsprüfung;
• Multipath-Konfiguration.

FC ist am Anfang selten die günstigste Variante, kann aber in einer kritischen Umgebung wirtschaftlicher sein, wenn die Kosten eines Ausfalls höher sind als die Infrastrukturkosten.

Was bei iSCSI berücksichtigt werden muss

Für iSCSI muss man einplanen:

• 10/25-GbE-Netzwerkkarten;
• Switches mit ausreichender Durchsatzleistung;
• SFP+, SFP28 oder DAC;
• separate VLANs oder physische Switches;
• Pfadredundanz;
• Zeit für die MPIO-Konfiguration;
• Monitoring des Storage-Netzwerks;
• mögliche Modernisierung der Netzwerkinfrastruktur.

Wenn iSCSI auf schwachen Büro-Switches aufgebaut wird, wird die Einsparung schnell zu Instabilität.

Was bei SAS berücksichtigt werden muss

Bei SAS darf man Folgendes nicht vergessen:

• einen SAS-HBA oder RAID-Controller;
• externe Mini-SAS-Kabel des passenden Typs;
• ausreichend viele Ports am Speichersystem;
• die Möglichkeit, an zwei Controller anzuschließen;
• Begrenzung der Kabellänge;
• künftiges Wachstum;
• Kompatibilität mit Server und Betriebssystem.

SAS kann für eine kompakte Umgebung die rationalste Variante sein, muss aber mit Blick auf künftige Erweiterung bewertet werden.

Typische Fehler bei der Auswahl

iSCSI im gemeinsamen Büronetzwerk

Das ist einer der häufigsten Fehler. Storage-Traffic darf nicht mit Benutzerdatenverkehr, WLAN, IP-Telefonie, Kameras, Druckern und normalem Dateiaustausch gemischt werden.

Die Folgen:

• zufällige Latenzen;
• Paketverluste;
• Hänger virtueller Maschinen;
• schwierige Diagnose;
• der falsche Eindruck, dass das Problem im Speichersystem liegt.

Der richtige Ansatz ist ein separates Storage-Netzwerk, zwei Pfade, Monitoring und ein klares IP-Adressierungsschema.

Ein Pfad zum Speichersystem

Ein Kabel zum Array ist ein Single Point of Failure. Ein Switch ebenfalls. Ein HBA oder eine NIC ebenfalls.

Für Produktionsumgebungen sollten mindestens zwei unabhängige Pfade geplant werden. Andernfalls kann der Ausfall eines physischen Elements den Zugriff auf den Speicher stoppen.

Kauf eines Speichersystems ohne benötigte Ports

Dieselbe Produktlinie eines Speichersystems kann mit unterschiedlichen Controllern verkauft werden: FC, iSCSI, SAS oder kombinierte Varianten. Deshalb muss vor dem Kauf nicht nur die Modellbezeichnung, sondern die konkrete Konfiguration geprüft werden.

In einem Angebot sollte man gesondert prüfen:

• Typ der Host-Ports;
• Portgeschwindigkeit;
• Anzahl der Ports pro Controller;
• Verfügbarkeit von SFPs;
• Kompatibilität der SFPs mit dem Switch;
• Vorhandensein von HBAs oder NICs in den Servern;
• Kabeltyp;
• Lizenzen für Ports und Funktionen.

Verwechslung von SAS-Host-Ports und Erweiterungsports

Auf der Rückseite eines Speichersystems können SAS-Anschlüsse vorhanden sein. Das bedeutet aber nicht immer, dass Server daran angeschlossen werden können. Manchmal sind es Ports für Erweiterungsshelves.

Vor dem Kauf sollte ausdrücklich geklärt werden:

• ob Server an diese SAS-Ports angeschlossen werden können;
• wie viele Server unterstützt werden;
• ob eine ausfallsichere Anbindung unterstützt wird;
• welche Kabel und Adapter benötigt werden.

Auswahl nach maximaler Portgeschwindigkeit

16/32 Gb FC, 10/25 GbE iSCSI oder 12 Gb SAS garantieren diese Geschwindigkeit nicht auf Anwendungsebene.

Die Begrenzung kann durch Folgendes entstehen:

• Disk-Gruppe;
• RAID-Typ;
• Storage-Cache;
• Controller;
• Anfrage-Queue;
• ein aktiver Pfad;
• ein überlasteter Switch;
• Einstellungen des Betriebssystems oder Hypervisors.

Die Schnittstelle ist wichtig, aber sie korrigiert keine schwache Storage-Architektur.

LACP verwenden, um den iSCSI-Durchsatz zu erhöhen

Ein ziemlich häufiger Fall: Zwei 10-GbE-Ports werden zu LACP gebündelt, in der Erwartung, daraus 20 GbE Durchsatz zu erhalten. Die Portbündelung bietet in diesem Fall jedoch nur Ausfallsicherheit, keine Skalierung. Für höheren Durchsatz muss MPIO verwendet werden.

Checkliste vor dem Kauf von Speichersystemen und Servern

Vor der Beschaffung sollte man diese Liste durchgehen:

• Wie viele Server werden jetzt angeschlossen?
• Wie viele Server müssen in 1–2 Jahren angeschlossen werden?
• Ist ein VMware-, Hyper-V- oder anderer Hypervisor-Cluster erforderlich?
• Welche Schnittstellen hat das Speichersystem: FC, iSCSI, SAS?
• Welche Portgeschwindigkeit gibt es?
• Wie viele Ports gibt es an jedem Controller?
• Gibt es zwei Controller?
• Sind HBAs oder Netzwerkkarten in den Servern vorhanden?
• Werden FC-Switches benötigt?
• Werden separate Ethernet-Switches für iSCSI benötigt?
• Werden SFP, DAC, Glasfaser- oder SAS-Kabel benötigt?
• Gibt es Lizenzen für Ports und Funktionen?
• Unterstützt das Betriebssystem oder der Hypervisor die gewählte Architektur?
• Ist Multipath-Anbindung konfiguriert?
• Gibt es Monitoring für Latenzen, Fehler und Pfadausfälle?
• Wurde die Kompatibilitätsmatrix des Herstellers geprüft?

Wenn auf mehrere dieser Fragen keine Antwort vorliegt, ist die Wahl der Schnittstelle noch nicht abgeschlossen.

Wie trifft man die Entscheidung?

Für kleine Infrastrukturen, in denen das Speichersystem neben einem Server oder einem Serverpaar steht, ist SAS oft die einfachste und wirtschaftlichste Option. Es erfordert kein separates SAN-Netzwerk, ist leicht zu verstehen und eignet sich gut für kompakte Lösungen.

Für einen kleinen oder mittelgroßen Cluster sollte man meistens zuerst iSCSI betrachten. Allerdings nur unter der Bedingung, dass Storage-Traffic vom normalen Netzwerk isoliert wird und die Anbindung mindestens über zwei Pfade erfolgt. iSCSI ist kein „billiges FC“, sondern ein eigener Ansatz, der bei korrekter Netzwerkarchitektur gut funktioniert.

Für kritische Systeme, große Cluster, Datenbanken, VDI und Infrastrukturen mit hohen Latenzanforderungen ist FC meist die bessere Wahl. Es ist komplexer und teurer in der Einführung, bietet aber ein ausgereiftes Modell eines dedizierten Storage-Netzwerks und vorhersehbares Verhalten in der Produktion.

Die richtige Schnittstelle für die Anbindung eines Speichersystems ist nicht die teuerste und auch nicht die auf dem Papier schnellste Option. Es ist die Schnittstelle, die zu Topologie, Workload, Budget, Teamkompetenz und Wachstumsplänen passt. Fehler entstehen meist nicht wegen FC, iSCSI oder SAS selbst, sondern wegen ungeprüfter Ports, eines einzelnen Pfads zum Speichersystem, eines gemeinsamen Netzwerks für iSCSI, vergessener Kabel und Lizenzen sowie falscher Erwartungen an die Skalierbarkeit.