Bei der Speicherung von Daten ist SCSI praktisch das einzige Protokoll bei professionell eingesetzten Speichergeräten. Die Internet-Protokollfamilie IP ist der maßgebliche Standard in Nahbereichs- und Weitverkehrsnetzen, LANs und WANs. iSCSI soll nun beide Protokolle verbinden und so den kostengünstigen Aufbau von Speichernetzwerken auf Basis von gängigen Ethernet-Netzwerkkomponenten ermöglichen.
Die Kombination des 20 Jahre alten SCSI und der 40 Jahre alten IP-Familie tritt damit direkt gegen den jungen Fibre Channel an, der seit etwa sechs Jahren auf dem Markt ist. Auch das Fibre Channel Protocol (FCP) basiert auf seriellem SCSI, wurde aber speziell an die Anforderungen in einem SAN angepasst. Die damit aufgebauten Fiber-Channel-Speichernetze sind inzwischen etabliert und weit verbreitet. iSCSI hingegen tut sich momentan noch unerwartet schwer, in der IT-Landschaft Fuß zu fassen.
Im Folgenden erläutern wir die prinzipielle Funktionsweise und Vor- und Nachteile von iSCSI. Detaillierte Grundlagen über Storage Area Networks finden Sie in unserem Beitrag SANs - Standards und Lösungen.
Motivation für iSCSI
Global gesehen finden sich um Größenordnungen mehr Ethernet-Ports mit TCP/IP als FC-Ports mit Fibre Channel Protocol. Jeder Administrator ist heute in der Lage, problemlos ein IP-basiertes LAN einzurichten. Dazu kann er aus einem breiten Angebot an preisgünstigen und kompatiblen Infrastruktur-Komponenten auswählen. Mit Gbit-Ethernet und erst recht mit 10-Gbit-Ethernet offerieren moderne LAN/WAN-Techniken zudem mehr als genug Bandbreite für Speichernetze.
Warum also nicht auch den Speicherdatenverkehr über Ethernet mit TCP/IP abwickeln? Statt einer völlig neuen, hoch komplexen und noch immer mit Kompatibilitätsproblemen behafteten Technologie wie Fibre Channel könnten in iSCSI-SANs bewährte Komponenten und eine bekannte Topologie zum Einsatz kommen.
Dabei verspricht iSCSI zum einen den Vorteil, anstatt teurer FC-Infrastruktur-Komponenten weit verbreitete (und bei künftiger Auslieferung in Stückzahlen entsprechend kostengünstige) Gbit-Ethernet- oder 10GE-Switches zu verwenden. Zum anderen handelt es sich um gängige LAN-Technologie, so dass statt speziell ausgebildeten Personals jeder LAN-Administrator die Wartung und Pflege des iSCSI-SAN übernehmen könnte. Daher sollten die Betriebskosten eines iSCSI-Speichernetzes deutlich unter denen eines FC-SANs liegen.
Status quo
Alle großen Hersteller wie etwa Dell, EMC, HDS, HP, IBM oder SUN haben ihre iSCSI-Aktivitäten entweder noch nicht begonnen oder auf Sparflamme zurückgedreht. SUN, der Erfinder des Wahlspruchs "Das Netz ist der Computer" lehnt iSCSI entschieden ab. IBM hatte als erster Hersteller ein Jahr früher als alle anderen (Anfang 2001) ein iSCSI-System (IP Storage 200i) auf den Markt gebracht. Die aktive Vermarktung dafür wurde vor einigen Monaten eingestellt. Eine amerikanische Fachzeitschrift glaubt, einen der Gründe zu kennen: IBM hatte bis August 2002 keinen einzigen zahlenden Kunden in den USA für diese iSCSI-Speicherbox gefunden. Derzeit arbeiten nur Adaptec, einige Host-Bus-Adapter-Hersteller und mehr als ein Dutzend Startups in den USA aktiv an Produkten für IP-Storage (Host-Bus-Adapter, Netzwerkkarten, Switches und TOEs).
Ist iSCSI also eine Entwicklung ohne Zukunft? Die oben genannten Vorteile gelten prinzipiell durchaus. Es kommt auf den Schwerpunkt der jeweiligen Anwendung an, ob iSCSI für die Speichervernetzung nützlich und preiswert ist. Nachfolgend werden die aus heutiger Sicht bekannten, technischen Kriterien für oder gegen einen Einsatz von iSCSI erläutert.
TCP/IP
TCP/IP arbeitet paketvermittelnd und geht dabei von einem unzuverlässigen Transportweg aus. Die Datenpakete werden ohne durchgehende Verbindung zur Gegenstelle in der Hoffnung auf den Weg gebracht, dass sie irgendwann (über möglicherweise unterschiedliche Wege) beim Empfänger ankommen. Erst dieser bringt die eintreffenden Pakete wieder in die richtige Reihenfolge und setzt sie zu einer Datei zusammen. Bei Überlastung einer Transportstrecke oder Übermittlungsfehlern kann TCP einzelne Datenpakete auch einfach verwerfen (also nicht übertragen). Sie müssen dann später nochmals angefordert werden.
Bis vor einigen Jahren wurden Ethernet-LANs meist als über Hubs gekoppelte Netze mit geteilter Bandbreite implementiert. In dieser Topologie verursacht das Ethernet-typische, nicht deterministische Zugriffsverfahren (CSMA/CD) zahlreiche Kollisionen von Datenpaketen und damit Übertragungsverzögerungen. Diese Art der Datenübertragung ist für den Betrieb zwischen Rechner und Massenspeicher grundsätzlich nicht geeignet. Moderne, über Switches mikrosegmentierte Ethernets stellen allen Teilnehmern die volle Bandbreite des Netzes zur Verfügung und schalten Kollisionen weit gehend aus. Zudem sorgen neue LAN-Techniken wie VLANs (IEEE 802.1q) und QoS (IEEE 802.1p) für logische Netztrennung und Priorisierung, so dass sich zur Not ein Ethernet-SAN sogar physikalisch auf derselben Verkabelung wie das LAN betreiben lässt. Typische lokale Netze tendieren jedoch erfahrungsgemäß zur "Verstopfung" durch Broad- und Multicasts. Daher sollte der Speicherdatenverkehr aus Leistungsgründen immer über ein eigenes physikalisches Netz laufen.
LAN oder SAN?
LAN und SAN entstammen völlig verschiedenen Zielsetzungen und sind jeweils für ihren Anwendungsschwerpunkt optimiert. TCP/IP-LANs transportieren kleine Datenpakete über beliebige, gerade freie Netzsegmente zeit- und reihenfolgenunabhängig ans Ziel. Bei Überlastung einer Teilstrecke werden Datenpakete verworfen, Reassemblierung und Fehlerkorrektur erfolgt fast ausschließlich via TCP am Ziel. Es werden vorwiegend Dateien als Byte-Strom übertragen, der gesamte Datenverkehr ist Software-gesteuert. Ein SAN befördert Daten auf dem kürzesten Weg und in der ursprünglichen Reihenfolge ans Ziel. Eventuell notwendige Fehlerkorrekturen geschehen bereits dort, wo die Fehler auftreten: unterwegs. Datenpakete werden nur versandt, wenn der Empfänger diese auch annehmen kann. Die Übertragung erfolgt vorwiegend als Datenblöcke oder als Serie von in Blöcken gegliederte Dateien. Gesteuert wird der Datenverkehr per Hardware. Diese Technik eignet sich ideal für große Datenmengen sowie den High-Performance-Datenbank- und Streaming-Betrieb. Diese großen Unterschiede machen es den beiden Technologien nicht gerade leicht, das jeweils andere Anforderungsprofil effektiv umzusetzen. Entsprechend schwierig ist iSCSI als LAN-Technik für den SAN-Betrieb anzupassen.
Block- oder Dateiübertragung?
Alle Daten werden als Blöcke gespeichert und dazu üblicherweise gleich im Betriebs- oder Filesystem des Rechners entsprechend aufgeteilt. Auch Hochleistungsdatenbanken operieren bei der Speicherübertragung in dieser Weise. In Speichernetzen bringt eine Übernahme der Blockübertragung offensichtlich Vorteile.
Bei der herkömmlichen Speicherung im DAS- oder NAS-Betrieb erfolgt die Einteilung in Blöcke erst kurz vor dem Ziel in einem speziellen Server direkt am Speicher. Es werden also unzerstückelte Dateien übertragen. Für die bequeme Handhabung und für den Zugriff von mehreren Rechnern auf die gleichen Daten ist die Datei-Orientierung von Vorteil.
SCSI überall
SCSI, das Protokoll für die Speicherung von Datenblöcken auf Speichermedien, entstand ursprünglich zusammen mit der Definition für das parallele Hardware-Interface gleichen Namens. Parallel-SCSI ist auch heute noch die Schnittstelle für direkt angeschlossene Speichergeräte (DAS) oder im Inneren von RAID-Systemen. Die Zerlegung der Dateien in Blöcke geschieht dabei im Datei- oder Datenbanksystem des Rechners. Im Falle von NAS wird zunächst die Datei auf den NAS Filer oder NAS Head übertragen und dort in Blöcke aufgeteilt.
iSCSI setzt das SCSI-Protokoll fast unverändert auf TCP/IP auf. Damit kann der Speicherdatenverkehr direkt über ein vorhandenes Ethernet-LAN laufen. Die Umsetzung gestaltet sich jedoch sehr komplex und lastintensiv. Um die Zerlegung der Blockdaten in Pakete zu beschleunigen und die Rechner-CPU von dieser Aufgabe zu entlasten, setzt man für iSCSI idealerweise so genannte TCP/IP Offload Engines (TOE) ein.
iSCSI-Spezifikation
Bei allen Standards rund um SCSI und Fibre Channel handelt es sich um US-Normen der ANSI-Komitees T10 (SCSI) und T11 (FC). Ethernet-Normen kommen dagegen vom IEEE, das als Organisation dem ANSI untersteht. Dagegen zeichnet für alle Richtlinien in Verbindung der IP-gestützten Übertragung von Speicherdaten die IETF verantwortlich, ein loser Zusammenschluss von Fachexperten. Sie definiert Normen wie FCIP, iFCP, mFCP, iSNS und nicht zuletzt auch iSCSI. Für Letzteres hat sich IETF ganz bestimmte Ziele gesetzt:
TCP muss als Transport-Protokoll für iSCSI genutzt werden.
SCSI-Geräte müssen im IP-Netz zusammenarbeiten können.
Ethernet und IP dürfen für iSCSI nicht verändert werden.
Die Spezifikation muss es zulassen, dass die Leistungen der SCSI-Geräte im IP-Netz verbessert werden können.
Initiatoren (Rechner/Server) müssen unter iSCSI gleichzeitig über verschiedene Wege im Netz auf Targets (Geräte) zugreifen können.
TCP-Verbindungen dürfen nur sparsam genutzt werden.
Die Rechner-Software darf nicht mit komplexen Abläufen belastet werden.
iSCSI fungiert quasi als virtuelle Kabelverlängerung für die Verbindung zwischen SCSI-Initiator und SCSI-Target. Neben Daten werden über die Verbindung auch Botschaften (SCSI-Befehle, Statusmeldungen) ausgetauscht. Während einer logischen Verbindung laufen all diese Inhalte über den gleichen logischen Kanal. Dynamische IP-Adressänderung erlaubt iSCSI nicht. Auch bei parallelen Mehrfachverbindungen müssen Befehle und Daten in der ursprünglichen Reihenfolge und mit Zugehörigkeitskennung übertragen werden.
iSCSI-Protokoll
Das iSCSI-Protokoll entspricht nicht exakt dem SCSI-Protokoll, wie es für SCSI und Fibre Channel eingesetzt wird. Mit iSCSI ist aus protokoll-technischen Gründen kein "Streaming Video" oder ähnlicher Dauerdatenverkehr machbar. Auch ein "Serverless"-Betrieb, also die direkte Datenübertragung, beispielsweise zwischen Band und Platte, ohne Umweg über den Server, ist mit iSCSI nicht möglich.
Zur Identifikation verwendet iSCSI die World Wide Unique Names und IP-Adressen. Diese Identifikation ist unabhängig von Ort oder Anschluss. Außerdem existieren Adressen, die einen definierten Weg zum iSCSI Target identifizieren. Es gibt noch Debatten wegen der Vielfalt an Formaten und historischen Gegebenheiten.
Für iSCSI sind IQN ( iSCSI Qualified Name) und EUI ( Extended Unique Identifier) im internationalen UTF-8-Format zugelassen. Dieses Zeichenformat entspricht weit gehend dem ASCII-Zeichenformat. SCSI-Laufwerke verwenden einen 8-Byte-Code, Fibre Channel verwendet zusätzliche Identifikatoren. Nicht jeder Code kann in den anderen Code umgewandelt werden.
Bisher gab es keine Notwendigkeit, Speichergeräte, -elektronik oder virtuelle Identifikatoren in einer Ethernet-TCP/IP-Umgebung einzusetzen oder umgekehrt. So sind Konflikte nicht zu vermeiden. Die eindeutige Identifikation der Elemente im Netz ist besonders wichtig. Ein bestimmtes Element im Netz muss eindeutig zugeordnet werden, unabhängig davon, ob es im LAN oder SAN, unter SCSI, FCP, TCP/IP oder iSCSI angesprochen wird.
Die konvertierten SCSI-Befehle überträgt TCP einzeln oder gebündelt in unterschiedlicher Länge als iSCSI Protocol Data Unit. TCP ist für die Übertragung von ungebrochenen Byte-Strömen eingerichtet. Es gibt für TCP keinen Mechanismus, die Befehls-Blockgrenzen im Byte-Strom zu erkennen. Daher verwendet iSCSI in seinem Header ein Feld, in dem die Befehls-Blocklänge steht. Im herkömmlichen TCP kann der Byte-Strom die Länge unendlich annehmen. Für iSCSI wird eine maximale Länge von 2³²-1 festgelegt. Zur Sicherheit in einem überall zugänglichen Netz wurde die Verwendung von IPsec unter iSCSI als Option definiert. Weitere Sicherheitsmechanismen einschließlich Verschlüsselung wurden vorgesehen.
iSCSI-Hardware
iSCSI mit TCP/IP in Software zu realisieren, wäre praktisch unbrauchbar: Die CPU-Last wäre für einen flüssigen Betrieb zu hoch. Daher wurde schon sehr früh der Einsatz der bereits erwähnten TOEs vorgeschlagen. Dabei handelt es sich praktisch um Netzwerkkarten, die einen Koprozessor für das De- und Reassemblieren der Speicherdatenblöcke mitbringen.
Das Sortieren der TCP-Pakete in die richtige Reihenfolge erfordert reichlich schnellen Halbleiterspeicher und bedingt zudem eine gewisse Verzögerung. Der Aufwand für die Konvertierung von SCSI in iSCSI und zurück erforderte bei den ersten Versionen der Spezialchips etwa vier Millionen Gatter. Ein Fibre-Channel-Chip benötigt etwa 500.000 Gatter für eine ähnliche Funktionalität. Die Gatter-Zahl ist also für TOEs um den Faktor acht höher als für Fibre-Channel-HBAs.
Um den TCP/IP-Flaschenhals aufzuweiten, existieren drei grundlegende Ansätze. Bei der Verwendung einer Netzwerkkarte als iSCSI-"HBA" muss schlicht der Host mit schnellen Prozessoren und optimierter Software die Zusatzlast auffangen. Im Fall echter TOEs unterscheidet man zwischen der Sparversion Data-Path Offload und dem Full Offload. Letzterer lagert die gesamte Netz- und Datenverarbeitung auf den Adapter aus. Das erhöht nicht nur die Kosten, sondern bringt auch gewisse Probleme mit sich: Der Host bleibt dadurch vom direkten Zugriff auf eine Reihe übergeordneter Funktionen (Routing, Failover, Load-Balancing, usw.) abgeschnitten. Data-Path Offload lagert dagegen nur die Datenübertragung aus. Die Entscheidungslogik bleibt in gewohnter Weise als Software im Rechner.
Es existiert bereits eine Vielzahl von Konvertern und Switches, mit denen sich Schnittstellen und Protokolle in jeder denkbaren Kombination umwandeln lassen. So wandelt etwa SANrad wahlweise zwischen SCSI, FC und iSCSI und gibt das Ergebnis über eine passende Schnittstelle aus. Daneben übernimmt die Box noch die Virtualisierung für ein ganzes SAN. Das alles wird von einem Echtzeit-Prozessor unter einem Echtzeit-Betriebssystem ausgeführt.
Übertragungsraten
Derzeit weisen die Hersteller bezüglich der iSCSI-Übertragungsraten häufig auf "Wire Speed" hin. Das besagt jedoch nur, dass Sender und Empfänger mit der angegebenen Transferrate TCP/IP-Pakete übertragen. Wichtig für den Anwender ist aber die Nutzdatenrate. Die liegt jedoch bei iSCSI wesentlich niedriger als bei der Fibre-Channel-Übertragung. IBM gibt in diversen Whitepapers an, dass im realen Betrieb die Nettodatenraten einer 1 Gbit/s-Verbindung bei etwa 80 MByte/s für den Fibre Channel und bis zu 30 MByte/s für iSCSI liegen. Letzteres gilt speziell auch für das eigene iSCSI-Produkt, den IP Storage 200i. In künftigen Versionen soll dieser jedoch mit bis zu 60 MByte/s operieren.
Bei Fujitsu Siemens hat man eine andere Maßzahl ermittelt: Für einen Durchlauf durch einen SCSI-Treiber benötigt ein Rechner etwa 5000 CPU-Zyklen, selbst für den kleinsten TCP/IP-Stack jedoch benötigt er 50.000. Dazu kommt noch der iSCSI-Stack-Overhead, für den noch keine konkreten Einschätzungen vorliegen. LAN-Experten verwenden gern folgende Faustregel: Die Übertragung von einem Bit beansprucht 1 Hz Taktfrequenz des Prozessors. Eine TCP/IP-Übertragung mit 1 Gbit/s lastet also einen Prozessor mit 1 GHz Taktrate fast voll aus. Zwar relativiert ein Busmastering der Netzwerkkarte diese Regel, dennoch sind für den Einsatz von iSCSI über 10-Gbit-Ethernet Lastprobleme zu erwarten. Dort werden also vermutlich besonders leistungsstarke TOEs benötigt. Bei Fibre Channel beträgt die Auslastung auf Grund der völlig anderen Übertragungstechnik dagegen nur rund drei bis fünf Prozent.
Übertragungsreichweite
Sehr häufig finden sich in der Literatur Hinweise auf die kürzere Reichweite von Fibre Channel gegenüber IP oder iSCSI. Hier werden jedoch Äpfel mit Birnen verglichen: Alle physikalischen Übertragungsstrecken - ob Ethernet oder Fibre Channel unterliegen Naturgesetzen und damit Längenbeschränkungen.
Bei TCP, iSCSI oder auch dem Fibre Channel Protocol TCP handelt es sich um Protokolle, die nur indirekt physikalischen Begrenzungen unterliegen. Typische Reichweiten für eine physikalische Verbindung mit preiswerten Adaptern und Multimode-Glasfaser liegen bei 550 Meter für 1000Base-SX und 500 Meter für Fibre Channel. Mit (teuren) langwelligen Lasern und Monomode-Fasern lassen sich fünf Kilometer bei Gbit-Ethernet und zehn Kilometer bei Fibre Channel überbrücken. Durch die Verwendung spezieller Transceiver und die Erhöhung der Puffergrößen kann die Reichweite von Fibre Channel sogar auf rund 100 Kilometer erhöht werden. Dabei fallen allerdings erhebliche Kosten an.
Risiko Langstrecke
Für größere Distanzen nutzen sowohl Fibre Channel Protocol als auch iSCSI die etablierten Verfahren ATM, SONET / SDH oder DWDM. Hier ist iSCSI als TCP/IP-basierte Technik im Vorteil, denn die entsprechende Hardware- und Protokoll-Konvertierung zählt seit langem zum gängigen Standard. Fibre Channel muss dagegen getunnelt werden (Fibre Channel over IP). Lediglich für DWDM gibt es Konverter, die FCP direkt auf DWDM übertragen. Die Kosten für Fibre Channel sind also höher, beziehungsweise es fehlt die passende Infrastruktur.
Generell ist zudem zu überlegen, wie viel Sinn Blockübertragung über größere Distanzen überhaupt macht. Die Dateien sind ja während dieser Zeit offen und fehlergefährdet, physikalische Laufzeiten und Verzögerungen in den Zwischenstationen lassen sich nicht eliminieren. Da erscheint es naheliegender, die Files, wie seit Jahrzehnten üblich, als geschlossene Einheit zu übertragen. So versenden etwa große Internet-Dienstleister laufend Duplikate der aktuellen Dateien und Datenbanken von ihrer Zentrale an Server, die geografisch näher am Kunden sind. Prinzipiell sollte der Speicherdatenverkehr in einem eigenen Netz (LAN oder SAN) ablaufen. Bei der Integration von Außenstellen mit wenig Datenverkehr lässt sich mit iSCSI zunächst auch ein vorhandenes Ethernet-LAN nutzen.
Ausblick
Zurzeit gibt es nur wenig iSCSI-Produkte beim Endkunden. Fibre-Channel-SANs sind etabliert und weit verbreitet. Die Aktivität konzentriert sich, mit Unterstützung durch die SNIA, auf die Lösung der Speicherverwaltungsprobleme. Diese sind unabhängig von Ethernet oder LAN, FCP-SCSI oder TCP/IP-iSCSI. Nachdem es bis vor kurzem die Speichervernetzung nicht gab, werden jetzt erst die dazu nötigen Verwaltungsprozeduren entwickelt. Wegen der grundsätzlich unterschiedlichen Anforderungen des LAN- beziehungsweise SAN-Betriebs lassen sich die vorhandenen LAN-Verwaltungsprozeduren zwar für iSCSI-Infrastrukturen, jedoch nicht für die Speicherverwaltung übernehmen. Allerdings werden, so weit möglich, vorhandene objektorientierte Techniken wie WBEM (Web Based Enterprise Management) oder CIM (Common Information Model) für den Speicherbetrieb ergänzt oder angepasst und in bestehende Frameworks wie beispielsweise OpenView integriert.
Die Entwicklung von iSCSI ist komplex und langwierig. Experten rechnen nicht vor Ende 2003 oder Anfang 2004 mit einem nennenswerten Einsatz im Alltagsbetrieb. Auf der Geräteseite wird es in absehbarer Zeit keine Laufwerke geben, die direkt mit einer iSCSI-Schnittstelle ausgerüstet sind. Es bleibt also bei Laufwerken mit SCSI- und Fibre-Channel-Schnittstelle. Externe RAID-Systeme in eigenen Schränken werden möglicherweise iSCSI am Ein-/Ausgang haben, intern aber mit SCSI- oder Fibre-Channel-Laufwerken bestückt sein.
IBM ging bislang davon aus, dass nach drei Jahren iSCSI-Einsatz etwa ein Anteil von 15 Prozent am SAN-Markt erreicht würde. Entwicklungsprobleme und die damit einhergehende Verzögerung eines breiten Produktangebots dämpfen jedoch momentan die zunächst hochgesteckten Erwartungen. Dies könnte sich aber ab Ende 2003 mit einer breiteren Produktauswahl schnell ändern.
Bei der Performance muss iSCSI auf Grund der komplexeren Protokollumsetzung Fibre Channel den Vortritt überlassen. Aber ein SAN auf iSCSI-Basis dürfte, wenn die nötigen Komponenten in Stückzahlen verfügbar sind, um wenigstens 30 Prozent günstiger zu realisieren sein als sein FC-Pendant. Dies eröffnet auch mittelständischen Unternehmen die Möglichkeit zum Einsatz von Speichernetzen und zur Virtualisierung ihrer Storage-Architekturen. Zudem verspricht die Verwendung gängiger LAN-Komponenten für die Infrastruktur hohe Kompatibilität und Investitionsschutz sowie leichte Wartbarkeit und damit eine geringe TCO. (jlu/mje)
Der Autor
Hermann Strass ist Berater für neue Technologien, insbesondere für Bus-Architekturen, Massenspeicher und industrielle Netzwerke, Mitglied in nationalen und internationalen Normungsgremien, in der IEEE Computer Society sowie Technical Coordinator der VITA in Europa. Daneben ist er Autor von Büchern, Zeitschriftenartikeln und organisiert Seminare.