Storage. Backup. Virtualisierung.
iSCSI · Version 1.18 · aktualisiert 2026 · © Stor IT Back
iSCSI ist ein Protokoll für blockbasierten Speicherzugriff über IP-Netze. Server greifen dabei als Initiatoren auf LUNs eines iSCSI-Targets zu. Die Technik wird unter anderem für Virtualisierung, Datenbanken, Cluster und zentral bereitgestellten Block-Storage eingesetzt.
iSCSI steht für Internet Small Computer Systems Interface und transportiert SCSI-Kommandos für blockbasierten Speicherzugriff über IP-Netze. iSCSI wurde 2004 durch die IETF als Standard veröffentlicht. Es basiert auf Standardprotokollen wie TCP/IP, Ethernet und SCSI. So wurde in kurzer Zeit eine sehr gute Kompatibilität auch zwischen den unterschiedlichen Herstellern erreicht. Auf dem Host genügt häufig ein Software-Initiator in Verbindung mit einer normalen Netzwerkkarte. Alternativ können iSCSI-HBAs eingesetzt werden.
Mit seiner Hilfe können Storage-Systeme
über TCP/IP an Server angeschlossen werden. Dies hört sich wie eine Mischung
aus SAN (Storage Area Network)
und NAS
(Network Attached Storage) an. Dies ist es auf den ersten Blick auch. Wie
beim NAS werden die Initiatoren, in der Regel Server oder Virtualisierungshosts, über das LAN mit dem iSCSI-Target beziehungsweise Storage-System verbunden.
Die Protokolle beim NAS sind NFS
und CIFS/SMB, bei iSCSI das (i)SCSI-Protokoll.
iSCSI ist selbst eine SAN-Technologie. Der wesentliche Unterschied zu Fibre Channel liegt im verwendeten Transportnetz.
Bei Fibre Channel werden SCSI-Kommandos über ein Fibre-Channel-Netz transportiert, bei iSCSI über TCP/IP. In beiden Fällen werden Blöcke übertragen.
Das Betriebssystem behandelt die iSCSI-Festplatten wie interne Festplatten.
iSCSI ist also, anders als NAS, keine dateibasierende,
sondern eine blockbasierte Übertragung. Dieser Unterschied ist sehr wichtig.
Das obige Bild zeigt eine Anwendung der iSCSI-Technologie. Die Server sind
über ein Ethernet-LAN angebunden. Eine iSCSI-Bridge beziehungsweise ein Storage-Gateway übernimmt die Protokollumsetzung
von iSCSI in SAS bzw. Fibre Channel,
je nach Modell des Routers. Das linke Storage-System ist in diesem Fall per
Fibre Channel angebunden. Am häufigsten werden die Storage-Systeme aber direkt per iSCSI angebunden (im Beispiel das rechte Storage-System).
Der Anschluss kann sogar mit 1-Gbit/s-Ethernet ausgeführt werden. Dies kann für kleine Testumgebungen mit geringen Anforderungen ausreichend sein.
Für produktive Umgebungen sollte der iSCSI-Verkehr über ein eigenes, klar segmentiertes Storage-Netz geführt werden.
Dann sollte es auch für hohe Anforderungen an die Performance, zum Beispiel für Datenbanken, ausreichend sein.
Wichtig ist in jedem Fall, dass das iSCSI-Netz vom Client-LAN getrennt wird.
Anderenfalls konkurriert der Storage-Verkehr mit dem normalen Client- und Serververkehr um Bandbreite und Switch-Ressourcen.
Zum anderen steigt die Gefahr des Datenmissbrauchs im iSCSI-Netzwerk extrem an. In jedem Windows
System (auch Clients wie Windows 10 oder 11) ist der iSCSI-Client schon enthalten. Fehlerhafte LUN-Zuordnungen oder unzureichende Zugriffsbeschränkungen können
Dateisystemschäden und Datenverlust verursachen.
Natürlich kann ein iSCSI SAN auch redundant aufgebaut werden.
Im obigen Beispiel ist die Umgebung mit zwei LAN-Switches ausgestattet und sowohl die Server als auch das Storage-System sind redundant angeschlossen.
Das iSCSI Storage-System kann, wenn es über zwei Controller verfügt, ohne Single Point of Failure (SPoF) betrieben werden. Es kann ein Switch ausfallen,
dann greifen die Server nur noch über den anderen Switch auf das Storage zu. Sollte ein Controller im Storage oder ein iSCSI-HBA im Server ausfallen,
so wird jeweils der alternative Weg genutzt. Die Steuerung des Failovers bzw. die Lastverteilung wird wie im Fibre Channel SAN auch
durch die Multipathing-Software beziehungsweise MPIO-Treiber auf den Servern vorgenommen.
Mit iSCSI sind also ähnliche Topologien wie im Fibre Channel SAN möglich. Auch in der Verfügbarkeit ist iSCSI ähnlich wie Fibre Channel, es ist also
schon lange nicht mehr so, dass in Enterprise-Umgebungen nur Fibre Channel und im kleinen Mittelstand nur iSCSI genutzt wird.
Die Lösung muss nicht zwangsläufig so aussehen. Viele NAS-Systeme bieten auch das iSCSI-Protokoll mit an. Ein NAS kann also in diesem Falle die dateibasierten Dienste wie SMB/CIFS und NFS anbieten, aber auch das blockbasierte iSCSI. Wichtig beim Kauf von NAS-Systemen ist eine genaue Prüfung der Features, wenn sie auch iSCSI können sollen. Nicht jedes NAS-System bietet die für produktives iSCSI erforderliche Performance, Verfügbarkeit und Verwaltungsfunktionalität.
Aber warum ist es so wichtig, die Unterschiede zwischen NAS und iSCSI zu kennen? Bei iSCSI werden die Speicherbereiche (LUNs) wie interne Platten im Server erkannt. Also reine Blockgeräte, auf denen ein herkömmliches Dateisystem normalerweise nur von einem Host gleichzeitig schreibend verwendet werden darf. Mehrere Hosts benötigen dafür ein Cluster-Dateisystem oder eine Anwendung, die gemeinsame Blockzugriffe koordiniert. Sollen also verschiedene Server auf dieselbe Datenbasis zugreifen können, so ist ein NAS deutlich einfacher zu nutzen (Performance beachten!). Der gemeinsame Zugriff per SMB/CIFS oder NFS ist auch ohne Cluster möglich.
iSCSI wird eingesetzt, um Servern zentral verwalteten Block-Storage über ein IP-Netz bereitzustellen. Das bereitgestellte Device (die LUN) wird vom Betriebssystem des Servers wie eine interne Platte behandelt, also die ideale Lösung für Datenbanken, aber auch für den Storage für die Servervirtualisierung. Und natürlich für Anwendungen, die direkt auf Blockgeräte zugreifen, beispielsweise Datenbanken und Virtualisierungsplattformen. Da sich der Storage einfach und kostengünstig zentralisieren lässt, können vorhandene DAS-Systeme zusammengefasst werden. Dadurch kann der Administrationsaufwand reduziert werden, es kann Energie gespart werden ("Green IT"), da mit einem Storage-System viele einzelne DAS-Systeme abgelöst werden können.
Je nach Netzwerkdesign, Bandbreite und Implementierung kann iSCSI einen höheren Protokoll- und CPU-Overhead als Fibre Channel verursachen. iSCSI für viele Anwendungen vollkommen ausreichend, es können in vielen Fällen auch Kosten im Vergleich zu Fibre Channel eingespart werden.
Auch in der Virtualisierung
(VMware vSphere, Microsoft Hyper-V, Proxmox VE und andere Virtualisierungsplattformen) werden iSCSI-Systeme
als Shared Storage eingesetzt. In diesem Falle greifen verschiedene Server per iSCSI
auf auf denselben gemeinsam bereitgestellten Speicherbereich. Dies funktioniert reibungslos, da die Server in einem
Cluster arbeiten und gemeinsame Schreibzugriffe abstimmen und koordinieren.
| Betriebssysteme | ||
| iSCSI-Initiator für Linux |  |
28.07.2025 |
| iSCSI-Initiator für Windows | |
17.01.2026 |
| iSCSI-Initiator für macOS | |
15.02.2023 |
| iSCSI-Initiator für HP-UX | |
28.07.2025 |
| iSCSI-Initiator für IBM AIX | |
28.07.2025 |
| iSCSI-Initiator für Oracle / SUN Solaris | |
28.07.2025 |
iSCSI ist ein transparentes Protokoll für die Netzwerk-Hardware. Der Server benötigt entweder eine spezielle iSCSI-Karte (iSCSI HBA, in vielen Netzwerkkarten schon integriert), oder einen zusätzlichen Treiber für eine herkömmliche Netzwerkkarte (iSCSI-Software-Initiator). Die Serverbelastung lässt sich auch durch TCP Offload Engines und iSCSI Offload Engines auf Netzwerkkarten verringern. Viele Hersteller von Netzwerkkarten bieten diese Funktionen an, zum Teil als Zusatzlizenzen. Bei einer "normalen" Netzwerkkarte übernimmt dann ein Software-Initiator (iSCSI-Treiber) die Umwandlung.
Der iSCSI-Stack stellt die entfernten LUNs dem Betriebssystem als SCSI-Blockgeräte bereit. Der iSCSI-Stack stellt die entfernten LUNs dem Betriebssystem als SCSI-Blockgeräte bereit. Sie bekommt eine IP-Adresse und nutzt die TCP/IP-Kommunikation. Damit ist dieses Protokoll routingfähig und wird über normale Ethernet-Hardware, wie beispielsweise über LAN-Switches und Router transportiert. iSCSI ist routingfähig und kann grundsätzlich auch über größere Entfernungen eingesetzt werden. Bandbreite, Latenz, Paketverluste und Sicherheit setzen jedoch praktische Grenzen. Der Server steht in Europa und der Storage in den USA und es fallen nur die Internet-Kosten an... Zu schön, um wahr zu sein, aber einen Haken gibt es beim Betrieb über ein WAN (bzw. das Internet). Das ist die Performance beziehungsweise die Latenzzeit. Sie setzt sich aus der Übertragungsrate des Mediums und der Zeitverzögerung bei Transaktionen zusammen. 1-Gbit/s-Ethernet ist für moderne produktive Storage-Workloads meist zu knapp dimensioniert. Mit 10-, 25-, 40- und 100-Gbit/s-Ethernet stehen heute deutlich höhere Bandbreiten zur Verfügung.
Einiges lässt sich auch optimieren. Jumbo Frames können bei bestimmten Workloads den CPU-Overhead reduzieren und den Durchsatz verbessern. Der tatsächliche Nutzen sollte jedoch durch Messungen geprüft werden. Alle Komponenten eines iSCSI-Pfades müssen dieselbe unterstützte MTU verwenden. Häufig wird eine IP-MTU von 9000 Byte eingesetzt; einige Switches geben stattdessen die maximale Ethernet-Frame-Größe, beispielsweise 9216 Byte, an. Bei Jumbo-Frames steigt allerdings auch die Latenzzeit, dies muss abgewogen werden.
Im iSCSI-Target werden die über TCP empfangenen SCSI-Kommandos verarbeitet und den bereitgestellten LUNs zugeordnet. Als Target können native iSCSI-Storage-Systeme, Unified-Storage-Systeme, Software-defined-Storage-Lösungen oder spezielle Storage-Gateways dienen. Diese Varianten sind von kostengünstigen Einstiegsversion bis zur Enterprise-Lösung erhältlich.
Der iSCSI-Server ist wie ein NAS-System aufgebaut,
stellt definierte LUNs den autorisierten Initiatoren zur Verfügung. Ein iSCSI-Router
wandelt zum Beispiel iSCSI in Fibre Channel um. Der Vorteil dieser Lösungen
ist die Optimierung auf gerade diese Aufgaben. Storage-optimierte Betriebssysteme übernehmen unter anderem RAID, Caching, Snapshots,
Thin Provisioning und Hochverfügbarkeit. Beispiele für
iSCSI-Lösungen finden Sie in den Angeboten der Stor IT Back. Auch fast
jedes bessere NAS-System bietet zusätzlich iSCSI-Services an. Eine kostengünstige
Alternative, wenn beide Dienste benötigt werden.
Damit lassen sich dann dateibasierte und blockbasierte Storage-Dienste konsolidieren.
Die nominale Übertragungsrate allein erlaubt keinen zuverlässigen Vergleich zwischen iSCSI und Fibre Channel. Entscheidend sind unter anderem Latenz, IOPS, Blockgröße, Queue-Tiefe, CPU-Last, NIC- beziehungsweise HBA-Offloads, Switch-Auslastung und die Leistungsfähigkeit des Storage-Systems. Fibre Channel bietet ein speziell für Storage optimiertes Netzwerk. iSCSI nutzt dagegen die weitverbreitete Ethernet-Infrastruktur und kann mit 10-, 25- oder 100-Gbit/s-Ethernet ebenfalls sehr hohe Leistungen erreichen. Für eine belastbare Entscheidung sind Messungen mit dem vorgesehenen Workload erforderlich.
Gerade bei Datenbanken ist eine geringe Latenzzeit absolut wichtig. Wenn von einer Datenbank ein kleiner Block auf die Festplatte (= LUN) übertragen werden soll, dann wartet die Anwendung gegebenenfalls so lange mit dem nächsten I/O, bis der vorherige auf der Platte angekommen ist (= die Schreibbestätigung angekommen ist). Selbst kleine Verzögerungen können sich in der Gesamtperformance negativ bemerkbar machen. Aber was beeinflusst die Latenzzeit?
Ein großer Unterschied besteht zwischen 1 Gbit/s Ethernet und 10 Gbit/s Ethernet. Eine höhere Bandbreite reduziert die Übertragungsdauer eines Frames, beseitigt jedoch nicht automatisch alle Ursachen für Latenz. Weiterhin steigt die Latenzzeit, wenn der Übertragungsweg belastet wird. Mit steigender Auslastung können Warteschlangen in Netzwerkkarten und Switches zu stark zunehmenden Latenzzeiten führen. ie physische Entfernung trägt zur Laufzeit bei, ist innerhalb eines lokalen Rechenzentrums jedoch meist weniger relevant als Warteschlangen, Paketverluste und zusätzliche Netzwerk-Hops. Je länger der Übertragungsweg ist, desto größer die Latenzzeit. Die optimale Frame-Größe hängt vom Workload und von der gesamten Netzwerkarchitektur ab. So können sich zum Beispiel Jumbo-Frames auch nachteilig auswirken. Wenn sie aber gleichzeitig die Auslastung der Strecke reduzieren, können sie auch positive Wirkungen haben. Die Auswirkungen sind workload- und umgebungsabhängig, deswegen findet man im Internet viele gegenläufige Verbesserungsvorschläge. Mal zeigen sich gute Ergebnisse bei Tuning-Versuchen, in anderen Umgebungen können dieselben Änderungen wirkungslos sein oder die Stabilität verschlechtern.
Ein häufig vorgebrachter Vorteil von iSCSI ist die Nutzung der vorhandenen Hardware im Netzwerk. Um eine gute Performance zu erreichen, muss aber ein getrenntes Netz eingesetzt werden, also eigene Netzwerkkarten beziehungsweise iSCSI-HBAs, getrennte Switches und eigene Verkabelung. Der Vorteil liegt trotzdem in den kostengünstigeren Preisen der Hardware.
Die tatsächlichen Kosten hängen von Bandbreite, Redundanz, Switches, Lizenzen, Support und vorhandener Infrastruktur ab. Ein ganz klarer Vorteil ist die Routingfähigkeit über IP-Netze dieser Lösung und die verbreitete Technologie des Ethernet (IP, TCP/IP). Ein Nachteil ist die geringere Performance bei Gigabit-Ethernet, die jedoch bei vielen Anwendungen absolut ausreichend ist.
Bei moderaten Lasten können beide Technologien die Anforderungen vollständig erfüllen. Die tatsächliche Leistung hängt jedoch von der jeweiligen Implementierung ab. Bleibt man in den Grenzen, so gibt es im Blick auf die Latenzzeit wenig Nachteile. Höhere Ethernet-Bandbreiten können Engpässe reduzieren; für niedrige Latenzen bleiben jedoch Netzwerkdesign, Auslastung und Storage-Antwortzeiten entscheidend. Die Latenzzeit kann sich gerade bei Datenbanken extrem negativ auswirken.
iSCSI-Nutzdaten werden ohne zusätzliche Schutzmaßnahmen grundsätzlich unverschlüsselt über das IP-Netz übertragen. Für die Punkt-zu-Punkt-Verbindung (bei SCSI) war dies auch nie ein Problem, keiner konnte "mithören". Aber mit iSCSI werden die Daten jetzt über ein Netz transportiert. Deswegen sollten diese Verbindungen eigentlich verschlüsselt werden .CHAP schützt nur die Anmeldung. Für die Verschlüsselung des Netzwerkverkehrs können beispielsweise IPsec oder entsprechend abgesicherte Netzwerkpfade eingesetzt werden. Die Verschlüsselung benötigt aber zusätzlich Ressourcen. Ein dediziertes und segmentiertes Storage-Netz ist die Grundlage der Absicherung, ersetzt bei entsprechenden Anforderungen jedoch keine Verschlüsselung. VPN- oder IPsec-Verbindungen können Durchsatz und Latenz beeinflussen. Die Auswirkungen hängen stark von Hardwarebeschleunigung, Bandbreite und Implementierung ab.
Wie kann man aber die Zugriffe der verschiedenen iSCSI-Initiatoren kontrollieren? Ein iSCSI-Target sollte Zugriffe durch LUN-Masking, Initiator-IQNs, Netzwerk-ACLs und optional CHAP auf autorisierte Hosts begrenzen.
Dafür wurde CHAP integriert. Je nach Storage-System wird einem Initiator oder einer Initiatorgruppe ein CHAP-Benutzer beziehungsweise ein gemeinsames Kennwort zugewiesen.
Nur ein Initiator Initiator mit den passenden Zugangsdaten kann auf die LUN zugreifen. Eine einfache, aber effektive Funktion.
Damit kann das Target also bestimmen und kontrollieren, wer auf eine LUN zugreifen darf. Wenn jetzt aber
der Initiator auch noch kontrollieren soll, ob er auf das richtige Target zugreift, dafür wurde
Mutual CHAP entwickelt. Dabei authentifiziert der Initiator zusätzlich das Target.
iSCSI ist eine zuverlässige Technologie, die auf Altbekanntem und Bewährtem basiert.
Dies sind SCSI, TCP/IP und Ethernet. Die meisten verbreiteten Server-Betriebssysteme verfügen über integrierte iSCSI-Initiatoren.
Ethernet-Netze werden überall verwendet, vorhandene Ethernet-Hardware und vorhandenes Netzwerk-Know-how können genutzt werden. Dies alles sind gute Vorzeichen für die Nutzung und Weiterentwicklung
von iSCSI. Alle namhaften Hersteller bieten Hardware in diesem Bereich an. Dies geht von den klassischen
Storage-Herstellern, die neben Fibre Channel auch iSCSI anbieten, über NAS-Anbieter (Hardware und Software), die ihre
Funktionalität mit iSCSI erweitern, bis zu Entwicklern von Software-defined Storage. Mit der Verbreitung von 10-, 25- und schnelleren Ethernet-Netzen
wurde iSCSI auch für anspruchsvolle Rechenzentrums- und Virtualisierungsumgebungen attraktiv.
Für NVMe-basierte Workloads gewinnt parallel NVMe/TCP an Bedeutung. iSCSI bleibt jedoch wegen seiner breiten Unterstützung,
ausgereiften Werkzeuge und hohen Kompatibilität weiterhin relevant.
Sie möchten sich erst einmal umfangreich informieren?
Wir bieten Praxisschulungen speziell zum Bereich iSCSI an.
Im ersten der folgenden Videos sehen Sie die Konfiguration eines iSCSI-Targets für
den Zugriff eines Windows-Servers. Dabei sind iSCSI-Target (in diesem Beispiel
ein Open-E DSS Server), und der Windows-Server (Software-Initiator) über zwei
unterschiedliche Netze miteinander verbunden.
iSCSI Multipathing unter Open-E DSS v7
In diesen beiden weiteren Videos sehen Sie
die Konfiguration eines Windows Servers 2019 mit mit iSCSI-Initiator einschließlich Multipathing und CHAP (im dritten Video).
Im ersten Video das Target und jetzt den Initiator.
iSCSI Multipathing unter Windows Server 2019 (Teil 1)
iSCSI Multipathing unter Windows Server 2019 mit CHAP und Mutual Chap (Teil 2)
iSCSI steht für Internet Small Computer Systems Interface. Das Protokoll ermöglicht den blockbasierten Zugriff auf Speicher über ein IP-Netzwerk. Ein Server greift dabei als Initiator auf ein Speichersystem, das sogenannte Target, zu und erkennt dessen LUNs wie lokal angeschlossene Datenträger. Typische Einsatzbereiche sind Virtualisierung, Datenbanken, Cluster und zentral bereitgestellter Block-Storage.
NAS-Systeme stellen Dateien über Protokolle wie SMB oder NFS bereit. iSCSI stellt dagegen blockbasierten Speicher zur Verfügung. Bei iSCSI verwaltet das Betriebssystem des Servers das Dateisystem, die Partitionen und die Zugriffsrechte. NAS eignet sich besonders für gemeinsam genutzte Dateien, während iSCSI häufig für Datenbanken, Virtualisierung und Cluster eingesetzt wird.
Der Initiator ist der Server oder Virtualisierungshost, der auf den Speicher zugreift. Das Target ist das Storage-System oder der iSCSI-Server, der den Speicher bereitstellt. Eine LUN, kurz für Logical Unit Number, ist ein logisch bereitgestellter Speicherbereich, den der Initiator wie einen lokalen Datenträger erkennt. Welche Initiatoren auf eine LUN zugreifen dürfen, wird über die Konfiguration des Storage-Systems festgelegt.
iSCSI eignet sich für Unternehmen, die zentralen Block-Storage über eine Ethernet-Infrastruktur bereitstellen möchten. Typische Einsatzbereiche sind Datastores für VMware vSphere, Microsoft Hyper-V oder Proxmox VE, Datenbankserver, Windows-Failover-Cluster sowie Test- und Entwicklungsumgebungen. Auch als kostengünstige Alternative zu Fibre Channel kann iSCSI eingesetzt werden.
Für produktive Umgebungen ist ein dediziertes oder eindeutig segmentiertes Storage-Netzwerk empfehlenswert. Dadurch konkurriert der iSCSI-Verkehr nicht mit normalem Client- und Serververkehr um Bandbreite und Switch-Ressourcen. Eigene Netzwerkschnittstellen, getrennte Switches und mehrere Netzwerkpfade verbessern außerdem Verfügbarkeit, Leistung und Fehleranalyse.
Typische Ursachen für Performance-Probleme sind ausgelastete Netzwerkpfade, Paketverluste, TCP-Neuübertragungen, falsch konfigurierte Switches, uneinheitliche MTU-Werte und eine zu geringe Bandbreite. Auch hohe Antwortzeiten des Storage-Systems können die iSCSI-Latenz erhöhen. Änderungen an Jumbo Frames, Queue-Tiefen oder Offload-Funktionen sollten deshalb immer mit realistischen Workloads getestet werden.
MPIO steht für Multipath I/O. Dabei verwendet ein Server mehrere unabhängige Netzwerkpfade zur gleichen iSCSI-LUN. Fällt ein Kabel, Netzwerkport, Switch, Storage-Port oder Storage-Controller aus, kann der Zugriff über einen anderen Pfad fortgesetzt werden. Abhängig von der eingesetzten Multipathing-Software können die Pfade außerdem zur Lastverteilung genutzt werden.
iSCSI sollte über ein getrenntes und kontrolliertes Storage-Netz betrieben werden. Zusätzlich lassen sich Zugriffe durch LUN-Masking, Initiator-IQNs, Netzwerk-ACLs und CHAP begrenzen. CHAP authentifiziert einen Initiator gegenüber dem Target, verschlüsselt jedoch nicht die übertragenen Nutzdaten. Falls eine Verschlüsselung erforderlich ist, können beispielsweise IPsec oder andere abgesicherte Netzwerkverbindungen eingesetzt werden.
Wichtige Kennzahlen sind Latenz, IOPS, Datendurchsatz, Paketverluste, TCP-Neuübertragungen und die Auslastung der Netzwerkpfade. Auf dem Server sollten außerdem der MPIO-Status, Queue-Längen und Ereignisprotokolle überwacht werden. Auf den Switches sind Fehlerzähler, verworfene Pakete und Port-Auslastungen relevant. Das Storage-System sollte insbesondere hinsichtlich LUN-Latenz, Controller-Auslastung, Cache-Trefferquote und Datenträgerauslastung kontrolliert werden.
Vor der Einführung sollten Anforderungen an Leistung, Verfügbarkeit, Kapazität und Sicherheit festgelegt werden. Wichtige Entscheidungen betreffen die Netzwerkbandbreite, die Anzahl der MPIO-Pfade, die Trennung vom übrigen Netzwerk, die Auswahl zwischen All-Flash- und Hybrid-Storage sowie die Zuordnung der LUNs. Ebenso wichtig sind eine nachvollziehbare Dokumentation, einheitliche Namenskonventionen und geplante Wartungs- und Firmware-Zeiträume.
