Stor IT Back - Ihr Speicherspezialist
iSCSI V1.15 (c) Stor IT Back 2024
iSCSI oder "Internet SCSI" transportiert blockbasierten Speicherplatz über LAN (Ethernet, TCP/IP) nutzt das SCSI-Protokoll (also SCSI over TCP/IP). Das iSCSI Protokoll wurde 2004 entwickelt und basiert auf Standard-Protokollen wie TCP/IP, Ethernet und SCSI. So wurde in kurzer Zeit eine sehr gute Kompatibilität auch zwischen den unterschiedlichen Herstellern erreicht. Vorhandene Netzwerkkarten konnten dafür genutzt werden, es wurde nur ein Treiber benötigt.
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 Clients (bei iSCSI sind es eher Server) über das LAN mit dem NAS Storage-System
verbunden. Die Protokolle beim NAS sind NFS
und CIFS/SMB, bei iSCSI das (i)SCSI-Protokoll.
Mit dem SAN gibt es eine noch enge Verwandtschaft. Eigentlich ist nur das
Übertragungsmedium ein anderes. Beim SAN wird das SCSI-Protokoll in Fibre Channel
verpackt, bei iSCSI in TCP/IP. In beiden Fällen werden Blöcke übertragen.
Das Betriebssystem behandelt die iSCSI-Festplatten wie interne Festplatten.
iSCSI ist also nicht wie bei einem NAS eine dateibasierende,
sondern eine blockbasierende Übertragung. Dieser Unterschied ist sehr wichtig.
Das obige Bild zeigt eine Anwendung der iSCSI-Technologie. Die Server sind
über ein Ethernet-LAN angebunden. Der iSCSI-Router übernimmt die Umwandlung
von iSCSI in SAS bzw. Fibre Channel, je nach Modell des Routers. Das linke Storagesystem 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).
Der Anschluss kann sogar mit Gigabit Ethernet ausgeführt werden, ausreichend bei kleinen Umgebungen oder Testaufbauten mit geringen Anforderungen an die Performance und den Durchsatz.
Produktive Umgebungen sollten mindestens mit 10 Gbit/s Ethernet (oder höher) aufgebaut werden, dann auch für hohe Anforderungen an die Performance, zum Beispiel für Datenbanken.
Wichtig ist in jedem Fall, dass das iSCSI Netz vom Client-LAN getrennt wird. Einmal wegen der Performance, denn wenn im Client-LAN die höchste Last herrscht,
dann wird sie auch im iSCSI LAN am größten sein. Zum anderen steigt die Gefahr des Datenmissbrauchs im iSCSI Netzwerk extrem an. In jedem Windows
System (auch Clients wie Windows 8, 10 oder 11) ist der iSCSI Client schon enthalten. Ein Fehler in der Konfiguration und schon kann nicht nur jeder
auf die Daten zugreifen, auch jeder kann die Daten löschen oder zerstören.
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 die Storage-Umgebung ist redundant
angeschlossen. Das iSCSI Storage 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
mit den Multipathing Treiber im Server vorgenommen.
Mit iSCSI sind also ähnliche Topologien wie im Fibre Channel SAN möglich. Auch in der Verfügbarkeit ist iSCSI ähnlich Fibre Channel, es ist also
schon lange nicht mehr so, dass im Enterprise 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 filebasierenden Dienste wie SMB/CIFS und NFS anbieten, aber auch das blockbasierende iSCSI. Wichtig beim Kauf von NAS Systemen ist eine genaue Prüfung der Features, wenn sie auch iSCSI können sollen. Nicht jedes NAS kann auch wirklich iSCSI und wenn es das kann, eventuell nicht gut genug für die Performance-Anforderungen.
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 Block-Devices, auf die immer nur ein Server zugreifen kann (Ausnahme sind Cluster). Sollen also verschiedene Server auf die gleiche 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.
Blockbasierender Speicher ist die Anwendung von iSCSI. Das übertragende 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 in der Server Virtualisierung. Und natürlich für alle Anwendungen die exklusiv Blockdevices benötigen, wie zum Beispiel Datenbanken. 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.
Trotz eines geringeren Durchsatz und einer höheren Latenzzeit als bei Fibre Channel ist iSCSI für viele Anwendungen vollkommen ausreichend, es können in vielen Fällen auch Kosten gegenüber von Fibre Channel eingespart werden.
Auch in der Virtualisierung (VMware vSphere oder Microsoft Hyper-V) werden iSCSI Systeme
als Shared Storage eingesetzt. In diesem Falle greifen verschiedene Server per iSCSI
auf den gleichen Datenbereich zu. Dies funktioniert reibungslos, da die Server in einem
Cluster arbeiten und gemeinsame Schreibzugriffe abstimmen und koordinieren.
| Betriebssysteme | ||
| iSCSI Initiator für Linux |  |
21.10.2018 |
| iSCSI Initiator für Mac OS | |
15.02.2012 |
| iSCSI Initiator für HP-UX | |
26.10.2018 |
| iSCSI Initiator für IBM AIX | |
26.10.2018 |
| iSCSI Initiator für Oracle / SUN Solaris | |
10.02.2012 |
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-HBA bzw. der iSCSI Software-Initiator wird als SCSI-3 Adapter vom Betriebssystem erkannt und kann normale SCSI-Kommandos weiterleiten. Von außen erscheint diese Karte als ein Netzwerkadapter (NIC). Sie bekommt eine IP-Adresse und nutzt die TCP/IP-Kommunikation. Damit ist dieses Protokoll routingfähig und wird über normale Ethernet-Hardware, wie z.B. einen LAN Switch und einen Ethernet Router transportiert. Eine Entfernungsbeschränkung existiert also nicht, 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. Selbst Gigabit-Ethernet ist bei großen Datenbankanwendungen schnell überfordert, daher hat die iSCSI-Hardware erst mit der Verbreitung des 10 Gigabit-Ethernet neue Einsatzmöglichkeiten erreicht.
Einiges lässt sich aber optimieren. So kann durch die Aktivierung von Jumbo-Frames eine deutliche Steigerung des Durchsatzes erzielt werden. Hierbei sollte die MTU der beteiligten Geräte auf 9216 erhöht werden. Dies ist ein optimaler Wert in Sicht auf die 32 bit Checksumme zum Transport von 8 Kilobyte-Paketen plus die Header-Informationen. Bei Jumbo Frames steigt allerdings auch die Latenzzeit, dies muss abgewogen werden.
An einem Punkt im Netzwerk muss iSCSI wieder in SAS oder Fibre Channel umgesetzt werden. Dies übernimmt entweder ein iSCSI Server (iSCSI RAID System) oder eine Netzwerkhardware (iSCSI Router, iSCSI Bridge). Beide Varianten sind von kostengünstiger Einstiegs-Version bis zur Enterprise-Lösung erhältlich.
Der iSCSI Server ist wie ein NAS System aufgebaut, er stellt seine internen Festplatten
(oder Teile davon) über iSCSI den anderen Nutzern 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. Es wird ein spezielles Betriebssystem
zur Steigerung der Performance eingesetzt. 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 filebasierende und blockbasierende Storage-Dienste konsolidieren.
Fibre Channel ist ein optimiertes Protokoll für den Transport großer Datenmengen und wurde speziell für diesen Zweck entwickelt. Die Ethernet Entwicklung ist deutlich älter und wurde für Transaktionen, mit meist sehr kleinem Inhalt, entworfen. Beide verfügen über eine Übertragungsgeschwindigkeit von 1.065 Bit/s (damit sind sie soweit vergleichbar), jedoch ist der Nutzdateninhalt sehr unterschiedlich, wie auch die Ansteuerung durch den Prozessor. Im Gigabit-Ethernet kann eine Übertragungsrate von etwa 50 bis 80 MB/s erreicht werden. Dies variiert je nach Anzahl der Teilnehmer und der Datenstruktur (Blockgröße, IO Verhalten).
Bei Fibre Channel können auch bei ungünstigen Verhältnissen Übertragungsraten der Nutzdaten
von 90 MB/s erreicht werden. Ein weiterer Vorteil für FC ist die Prozessor-Belastung
bei der Übertragung von Daten. Sie liegt bei Ethernet um Faktoren höher als
beim Fibre Channel. Eine sehr starke Belastung für den Server. Dies lässt sich
durch die speziellen iSCSI-Karten (iSCSI HBAs) verhindern. Sie übernehmen
die gesamte Umwandlung. Beim Software-Initiator (also der Nutzung einer "normalen"
Netzwerkkarte) wird der Prozessor mit der Verpackung der SCSI-Pakete belastet.
Diese zusätzliche Nutzung der CPU ist die eigentliche Begrenzung der iSCSI-Performance.
Bei iSCSI können durch die Nutzung von 10 Gigabit-Karten und Netzen ähnliche Übertragungsgeschwindigkeiten
wie beim 8 Gbit/s Fibre Channel erreichen, jedoch zwingt dies auch aktuelle
Prozessoren in die Knie. Dort müssen iSCSI HBAs verwendet werden.
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 evtl. so lange mit dem nächsten
IO, bis der vorherige auf der Platte angekommen ist (= der Write OK 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. Bei 10 Gbit/s sind die Latenzzeiten
von der Physik her geringer. Weiterhin steigt die Latenzzeit, wenn der Übertragungsweg
belastet wird. Eine zu 50% ausgelastete Strecke kann eine 5 Mal höhere
Latenzzeit als eine 10% ausgelastete Strecke besitzen. Weiterhin erhöht
die Kabellänge die Latenzzeit. Je länger der Übertragungsweg
ist, desto größer die Latenzzeit. Aber auch eine größere
Frame-Size erhöht die Latenzzeit. 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. Es ist eben abhängig
von Fall zu Fall, deswegen findet man im Internet viele gegenläufige Verbesserungsvorschläge.
Mal zeigen sich gute Ergebnisse bei Tuning-Versuchen, mal wird die Leistung
aber auch geringer.
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/iSCSI-Karten, getrennte Switche und eigene Verkabelung. Der Vorteil liegt trotzdem in den kostengünstigeren Preisen der Hardware.
Die Kosten für die Storage-Hardware hält sich in etwa die Waage. Ein ganz klarer Vorteil ist die Entfernungsunabhängigkeit 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 kleineren Datenmengen (geringer Durchsatz) und unwichtiger Latenzzeit hingegen ist iSCSI genauso schnell wie Fibre Channel. Bleibt man in den Grenzen, so gibt es im Blick auf die Latenzzeit wenig Nachteile. Dies verdeutlicht der Vergleich mit einer Autobahn. Bei wenig Verkehr können die Fahrzeuge auch auf einer einspurigen Straße (= 1 Gbit/s iSCSI) mit der maximalen Geschwindigkeit fahren. Wird der Verkehr aber dichter, so kommt es auf einspurigen Straßen schnell zu einem Stau. Ist die Autobahn aber vierspurig (= 4 Gbit/s Fibre Channel), so können wesentlich mehr Fahrzeuge bei maximaler Geschwindigkeit ohne Stau fahren. Auch die höhere Latenzzeit bei iSCSI kann mit 10 Gbit/s Ethernet etwas verbessert werden. Die Latenzzeit kann sich gerade bei Datenbanken extrem negativ auswirken.
SCSI-Daten (und damit auch iSCSI) werden im Klartext ü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 sollte diese Verbindungen eigentlich verschlüsselt werden. iSCSI bietet hierfür geeignete Verfahren an, um eine Endpunkt-zu-Endpunkt-Verschlüsselung aufzubauen. Die Verschlüsselung benötigt aber zusätzlich Ressourcen, ein geschütztes Netz ist die bessere Alternative. Ein Transport der iSCSI Daten zum Beispiel über ein VPN wird in den meisten Fällen an der benötigten Übertragungsrate scheitern.
Wie kann man aber die Zugriffe der verschiedenen iSCSI Initiatoren kontrollieren? Erst einmal kann jeder iSCSI Client auf ein iSCSI Target zugreifen. Also für produktive Umgebungen nicht geeignet, schon alleine durch einen Konfigurationsfehler können Daten zerstört werden, wenn zum Beispiel zwei Server auf das gleiche Target zugreifen.
Dafür wurde CHAP integegriert. Auf dem Target wird für jede LUN ein User und ein Passwort generiert. Nur
ein Initiator mit dem User und Passwort 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
Mutal CHAP entwickelt. Da kontrolliert der Initiator, ob das Target das richtige Passwort sendet.
iSCSI ist eine zuverlässige Technologie, die auf altbekanntem und bewährtem basiert.
Dies sind SCSI, TCP/IP und Ethernet. Jeder Server, jedes Betriebssystem beherrscht
diese Medien, Ethernet-Netze werden überall verwendet, vorhandene Hardware und Know How
kann 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
Storageherstellern, die neben Fibre Channel auch iSCSI anbieten, über NAS Anbieter (Hardware und Software), die ihre
Funktionalität mit iSCSI erweitern, bis zu Software defined Storage Entwicklern. Der große
Schub in der Verbreitung, auch in großen Rechenzentren, kam mit der Verbreitung von 10 Gigabit-Ethernet.
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 Server. Dabei sind iSCSI Target (in diesem Beispiel
ein Open-E DSS Server), und der Windows Server (Software Initiator) über zwei
unterschiedliche Netze miteinander verbunden. In den beiden weiteren Videos sehen Sie
die Konfiguration einen Windows Server 2019 mit iSCSI Initiator, über Multipathing
und CHAP (im dritten Video).
iSCSI Multipathing unter Open-E DSS v7
iSCSI Multipathing unter Windows Server 2019 (Teil 1)
iSCSI Multipathing unter Windows Server 2019 mit CHAP und Mutal-Chap (Teil 2)
