Die von Unternehmen zu verarbeitenden und zu speichernden Datenmengen wachsen auch nach dem Ende der Internet-Hysterie kontinuierlich weiter. Dies hat dazu geführt, dass die Art der Datenspeicherung einem Wandel unterliegt. Bisher wurden zusätzliche Dateiserver installiert, um mehr Plattenspeicherplatz zur Verfügung zu stellen. Doch diese Art der Speicherung (DASD, direct access storage devices) erweist sich mit den steigenden Datenmengen zunehmend als unpraktikabel.
Mit NAS und SAN offeriert die Industrie zwei Alternativen, die wiederum ihre eigene Probleme mitbringen: NAS bietet zu wenig Performance für anspruchsvolle Applikationen, in die teure Fibre-Channel-Infrastruktur von SANs wollen und können viele Anwender nicht investieren. Mit iSCSI wird jetzt ein SAN-Transportprotokoll marktreif, das trotz moderater Anschaffungskosten eine hohe Performance bietet. TCP/IP Offload Engines sorgen dabei für Durchsatzraten, die mit Fibre Channel konkurrieren können.
SCSI
Im professionellen Umfeld verwenden Speichergeräte wie Festplatten, Bandlaufwerke oder auch optische Laufwerke in der Regel das SCSI-Interface. Bei SCSI handelt es sich um ein I/O-Protokoll nach dem Client/Server-Prinzip. Die Kommunikation basiert also auf Kommandos und Antworten.
Die Kommandos werden in sogenannte Command Descriptor Blocks (CDB) eingepackt und zwischen Client und Server ausgetauscht. Der Client schickt CDBs an den Server, der die darin enthaltenen Befehle ausführt. Dabei kann es sich beispielsweise um Schreib- oder Leseanforderungen für bestimmte Speicherbereiche (Sektoren) oder die Anforderung eines Medienwechsel handeln. Als Antwort sendet der Server gegebenenfalls die gelesenen Daten sowie eine Statusmeldung an den Client zurück.
Die SCSI-Standards definieren nicht nur das logische Verfahren, sondern auch die physikalischen Schnittstellen. SCSI basiert derzeit noch auf einem parallelen Bus, an dem sich bis zu 15 Geräte anschließen lassen. Die Länge des Busses darf 12 Meter nicht übersteigen. Die Transfergeschwindigkeit beträgt nach der letzten Standarderweiterung, Ultra320 SCSI, bis zu 320 Mbit/s. Alternativ lassen sich SCSI-CDBs aber auch über andere Schnittstellen, wie etwa FireWire (IEEE-1394) oder USB, transportieren.
Problem DASD
Speicher nach dem DASD-Konzept führt zu einer ausufernden Anzahl an Servern. Das trieb bisher die Kosten für das Speichermanagement - sie betragen typischerweise das Zwei- bis Fünffache der Anschaffungskosten für die Speicher-Hardware - immer weiter in die Höhe.
Neben diesen Kosten verursacht die herkömmliche Art der Speichervorhaltung eine ganze Reihe technischer und administrativer Probleme. Dazu zählen etwa:
mangelnde Skalierbarkeit auf Grund der limitierten Geräteanzahl pro Bus und der Längenbeschränkungen
mangelnde Aggregationsmöglichkeit von freiem Speicherplatz über Server hinweg
aufwändige Verfahren zur Datenspiegelung, um gegen Katastrophen geschützt zu sein
eingeschränkte Möglichkeiten zur Datensicherung auf Grund zu geringer Zugriffsgeschwindigkeiten und der resultierenden hohen Backup-Zeiten
Als Antwort auf diese Herausforderungen wurde das Konzept des Network Storage ins Leben gerufen. Hier stehen sich im Prinzip zwei komplementäre Ansätze gegenüber: Network Attached Storage (NAS) und Storage Area Networks (SAN).
NAS und SAN
Das Konzept des Network Attached Storage beruht darauf, sogenannte Appliances direkt an das Unternehmensnetzwerk anzuschließen. Die bestehenden Clients und Server sowie die NAS-Appliances müssen sich die verfügbare LAN-Bandbreite teilen. Das reduziert die Geschwindigkeit von NAS im Vergleich zu SAN deutlich.
NAS-Appliances stellen ihre Dateidienste über Protokolle wie CIFS oder NFS im Netz bereit. Diese Daten lassen sich damit, wie von Fileservern gewohnt, im Dateimodus ansprechen (File I/O). Direkter Zugriff auf die einzelnen Speicherblöcke oder auch Sektoren ist damit nicht möglich. Gerade diese Art des Zugriffs erfordern jedoch Datenbanken zur Geschwindigkeitssteigerung. Damit schließen sich der Einsatz von großen, performanten Datenbanken und von NAS-Filern eher aus. Für Datei-orientierte Anwendungen stellen NAS-Appliances hingegen ein ideales Mittel dar, um die Anzahl der Server zu reduzieren und Speicherplatzaggregation zu betreiben.
NAS-Geräte bieten in der Regel eine Ethernet-Schnittstellen und nutzen IP als Transportprotokoll für ihre CIFS- und NFS-Dienste. Da sich IP über praktisch jedes Link-Layer-Netzwerk transportieren lässt, steht auch dem WAN-Einsatz von NAS für entfernte Datensicherung (remote backup) oder zur Anbindung von Zweigstellen nichts entgegen.
Storage Area Networks dagegen stellen den Anwendungs-Servern ein dediziertes Hochgeschwindigkeitsnetzwerk zur Verfügung, um darüber auf ein oder mehrere Datenspeicher zuzugreifen. Dabei garantiert eine komplette Trennung des Speichernetzwerks vom Unternehmensnetz (LAN/WAN) hohe Bandbreite, Servicequalität und Verfügbarkeit des Speicherzugriffs.
Fibre Channel
Mit dem SAN-Konzept eng gekoppelt ist der Fibre Channel (FC). Bei FC handelt es sich um einen ANSI-Standard aus den 90er Jahren. Er stellt schnelle Glasfaser-basierende Punkt-zu-Punkt-Verbindungen zwischen Servern und Speichern oder auch zwischen den Massenspeichern selbst zur Verfügung.
Über sogenannte FC-Hubs, FC-Switches oder auch FC-Directors werden mehrere Server und Speicher zusammengeschaltet. So lassen sich durch Ergänzung weiterer Massenspeicher die Kapazitäten einfach und für die Server transparent aufrüsten. Eine Datensicherung kann zwischen Bandlaufwerken und Plattenspeichern direkt, also ohne Serverbeteiligung, erfolgen - meist sogar ohne Beeinträchtigung der Anwendungen.
Die Fibre-Channel-Technologie basierend auf einem in fünf Schichten (FC-0 bis FC-4) aufgebauten Kommunikationsmodell und nutzt SCSI zum Zugriff auf Speichergeräte. Dazu werden SCSI-CDBs in Fibre Channel eingepackt, über ein Fibre Channel Netz verschickt, und am Ende originär als SCSI-CDBs an eine SCSI-Festplatte übergeben. Für die SCSI-Geräte ist die Nutzung von Fibre Channel transparent, also nicht sichtbar.
Vor- und Nachteile
Die Größe der übertragenen Datenmenge pro CDB darf bis zu 2048 Byte betragen. Bei Anforderung größerer Datenmengen werden entsprechend viele CDBs verwendet. Fibre Channel spricht die Speichergeräte damit im sogenannten Block I/O Mode an - eine Grundvoraussetzung für leistungsfähige Datenbankanwendungen.
Fibre Channel erlaubt Verbindungen über Distanzen bis zu 10 Kilometern und behebt damit eine der gravierendsten Limitierungen von SCSI. Aktuelle FC-Produkte bieten Übertragungsbandbreiten bis zu 2 Gbit/s, was eine hohe Anzahl gleichzeitige aktiver SCSI-Geräten pro FC-Node erlaubt.
Damit erfüllen FC-basierende SANs alle Anforderungen unternehmenskritischer Anwendungen in Bezug auf Geschwindigkeit, Verfügbarkeit und Skalierbarkeit. Nachteile dieser Art von Speichernetzen stellen die damit verbunden sehr hohen Kosten durch spezielle FC-basierende Hardware sowie notwendiges Spezial-Know-how zur Installation und Betrieb dar.
iSCSI
In Zeiten knapper IT-Budgets versuchen Hersteller und Anwender die Vorteile eines SAN ohne die Kostennachteile von FC zu realisieren. Dabei liegt naturgemäß nahe, die überall präsenten Technologien IP und Ethernet als alternative Verbindungsschicht zu Fibre Channel einzusetzen. Bei der IETF Working Group IP-based Storage (ips) liegen dazu derzeit drei Ansätze vor. Sowohl FCIP, iFCP als auch iSCSI nutzen IP-Netze zur Verbindung zwischen Speichergeräten und Storage-Netzen.
iSCSI (Internet SCSI), seit kurzem ein IETF-Standard, macht sich wie Fibre Channel SCSI als Protokoll zur Geräteansprache zunutze. Dazu verschickt es SCSI-CDBs über TCP/IP-Netze. Die lokale Verbindung erfolgt dabei über Ethernet. Einen Vergleich der Übertragungsbandbreiten mit Fibre Channel braucht Ethernet - zumindest seit der Verabschiedung von 10-Gigabit-Ethernet als IEEE-Standard 802.3ae - nicht zu scheuen. Bei Fibre Channel wird erst jetzt an einer Erweiterung des Standards auf ebenfalls 10 Gbit/Sekunde gearbeitet.
Beide Standards sehen Übertragungsdistanzen bis zu 40 Kilometer vor - das sollte für lokale und stadtweite Verbindungen ausreichen. iSCSI lässt sich, da auf IP aufsetzend, sogar weltumspannend einsetzen - dann allerdings mit höheren Latenzzeiten.
Namensauflösung
Ähnlich wie andere IP-Dienste kann iSCSI symbolische Namen für das Ansprechen der angeschlossenen Geräte verwenden. Ein iSCSI-Name darf bis zu 255 Zeichen lang sein und kann entweder ein iSCSI Qualified Name (IQN) sein oder alternativ dem IEEE-EUI-64-Format folgen.
Ein gültiger IQN wäre beispielsweise "iqn.storagepool.com.wrs:storage.array20.disk42". Der iSCSI-Name wird nur zum Auffinden des Geräts benutzt, die eigentliche Kommunikation erfolgt mittels IP-Adressen.
Die Auflösung von Namen in IP-Adressen kann über mehrere Wege erfolgen: Neben statischen Konfigurationen bieten sich etwa DHCP oder iSNS an. DHCP dient der Konfiguration von IP-Geräten. Bei iSNS (Internet Storage Name Service) handelt es sich um einen zu DNS vergleichbaren Dienst. Meist lassen sich iSNS-Namensauflösungen über vorhandene DNS-Server erledigen.
Login und Logout
Im iSCSI-Kontext heißen SCSI-Clients (Rechner) iSCSI-Initators, SCSI-Server (Speichergeräte) dagegen iSCSI-Targets. Zwischen Initiator und Target besteht eine iSCSI-Session. Um ein Mindestmaß an Sicherheit zu ermöglichen, wird eine iSCSI-Session authentifiziert (iSCSI login phase).
Dies geschieht mittels eines iSCSI-Logins, ähnlich einem Fibre Channel Port Login. Ein Teil des Login-Vorgangs besteht aus dem Aushandeln von Verbindungsparametern. Dazu zählen etwa die maximale Anzahl paralleler TCP-Verbindungen, die Datenblockgröße pro iSCSI-Paket oder die Anzahl der ausstehenden Kommandos.
Um neben der Authentifizierung eine weitergehende Datensicherheit zu gewährleisten, kann auch eine Datenverschlüsselung auf IP-Ebene mittels IPSec für iSCSI transparent zum Einsatz kommen.
Schlägt die Anmeldung fehl, zum Beispiel aufgrund falscher Logindaten, dann wird die TCP-Verbindung beendet. Wird eine iSCSI-Sitzung hingegen außerplanmäßig unterbrochen (beispielsweise durch Netzwerkfehler oder defekte Netzwerkkarten), sieht iSCSI entsprechende Ausnahmebehandlungen vor.
Nach dem erfolgreichen Login steht die iSCSI-Verbindung bereit, um Daten zwischen Initator und Target auszutauschen (iSCSI full feature phase). Analog zur Anmeldung existiert auch eine Abmelde-Prozedur (iSCSI-Logout). Logouts sind etwa notwendig, um ein iSCSI-Gerät für die Wartung außer Betrieb zu nehmen.
Session
Eine Initiator Session ID (ISID) beziehungsweise eine Target Session ID (TSID) ermöglicht die eindeutige Bezeichnung jeder iSCSI-Sitzung. Die Session besteht aus einer oder mehreren TCP-Verbindungen, wobei zur Vereinfachung dieselbe Verbindung für ein Kommando und die Antwort darauf zum Einsatz kommt. Die SCSI-CDBs werden in iSCSI Protocol Data Units (PDUs) verpackt und als TCP-Segment an das IP zur Übertragung übergeben. Anschließend erfolgt der Versand des IP-Pakets über Ethernet oder eine andere IP-geeignete Verbindungsschicht.
Ein besonderes Augenmerk legt iSCSI auf die Fehlerbehandlung. SCSI setzt eine quasi fehlerfreie Verbindung zwischen Rechner und Speichergerät voraus. Mit dem parallelen, kurzen SCSI-Bus war das gegeben. IP hingegen bietet einen "best effort" genannten Ansatz: Ein IP-Paket kann sein Ziel erreichen, aber auch unterwegs aufgrund von Bandbreiten- oder Router-Engpässen verworfen werden.
Deshalb nutzt iSCSI zum Transport der SCSI-CDBs TCP. Dieses sichert die immanent unsichere Übertragung mittels IP durch Bestätigungen ab. Das gewährleistet, dass kein Paket unbemerkt verschwindet. Jeder Verlust wird erkannt und das Paket daraufhin neu versendet. Zudem stellt iSCSI über CRC32-Prüfsummen die Datenintegrität sicher. Neben diesen prinzipiellen Designmaßnahmen sieht iSCSI die separate Fehlerbehandlung innerhalb jeder iSCSI-PDU, TCP-Verbindung und Session vor.
TCP/IP Off-loading
Trotz des Gigabit-Ethernet-Interfaces weisen aktuelle iSCSI-Geräte im Vergleich zu Fibre-Channel-Geräten meist einen deutlich geringen Durchsatz auf. Hauptgrund dafür ist die Nutzung von software-basierenden TCP/IP-Stacks. Hier muss die CPU die Verarbeitung der TCP/IP-Daten übernehmen.
Selbst bei aktuellen Rechnern beschäftigt sich die CPU in diesem Fall praktisch ausschließlich mit der Bearbeitung des TCP/IP-Datenstroms. Somit fehlen ihr die Reserven, um sich mit iSCSI (im Falle des Targets) oder mit der eigentlichen Applikation (auf dem Initiator) zu beschäftigen. Die unvermeidliche Folge: Die Datenraten bleiben weit unter den theoretischen Möglichkeiten von Gigabit-Ethernet.
Abhilfe schaffen sogenannte TCP/IP Offload Engines (TOEs). Hier arbeitet nicht die CPU den TCP/IP-Stack ab, sondern eine intelligenten Einsteckkarte mit eigener dedizierter CPU. Indem diese intelligenten Netzwerkkarten (iNICs) praktischerweise auch noch ein oder zwei Gigabit-Ethernet-Schnittstellen beherbergen, ersetzen sie gleichzeitig Standard-Ethernetkarten.
Performance durch TOEs
Vergleichstests haben ergeben, dass eine Gigabit-TOE den Datendurchsatz von rund 350 Mbit/s (bei Standard-Hardware) auf bis zu 981 Mbit/s steigert. Bei Einsatz zweier Gigabit-Kanäle steigt auch die Leistung entsprechend. Gleichzeitig sinkt die Belastung der Rechner-CPU von nahe 100 Prozent auf unter 10 Prozent.
Damit kann der Rechner wieder seinen eigentlichen Aufgaben nachkommen: beispielsweise Applikationen ausführen oder Datenbanken durchforsten. Spätestens mit der Einführung von 10-Gigabit-Ethernet werden TOEs im Rechner unumgänglich, möchte man nicht nur einen Bruchteil der Bandbreiten nutzen.
Funktion der TOE
Um dem Rechner TCP/IP Offloading beizubringen, installiert man zunächst einmal einen Socket-Class-Treiber, der die Socket-Aufrufe der IP-Anwendungen abfängt und an die TOE weiterleitet. Dort arbeitet die spezielle CPU sie dann ab. Dabei realisieren hardware-basierende TCP-Segmentierung und CRC-Prüfsummenberechnung für TCP und IP deutliche Geschwindigkeitsvorteile. Eine Unterstützung für Jumbo-Ethernet-Frames (9,000 statt 1,500 Byte) ermöglicht speziell bei der Übertragung großer Datenmengen (NFS) einen weiteren Durchsatzgewinn.
Da iSCSI noch aufwändiger zu bearbeiten ist als reines TCP/IP, drängt sich auch dafür die TOE geradezu auf. Statt einem Socket-Class-Treiber residiert hier ein spezieller SCSI-Treiber im Rechner bzw. im iSCSI-Gerät. Für das System stellt er sich wie ein normales SCSI-Gerät dar. Der Treiber fängt alle SCSI-Kommandos ab und leitet sie an die iSCSI-Karte weiter.
Die iSCSI-Karte kümmert sich um alle weiteren Schritte, also das Erzeugen und Verwalten der iSCSI-PDUs, den Versand, sowie gegebenenfalls um die Fehlerbehandlung. iSCSI-TOEs eignen sich damit sowohl für Rechner als auch für iSCSI-Geräte: Beide müssen praktisch dieselben Schritte bei der Kommunikation durchlaufen.
Entsprechende iSCSI-Host-Bus-Adapter (HBA) sind im Handel bereits zu haben. So liefert Adaptec seinen Full-Duplex-fähigen ASA-7211 in Varianten für Kupfer- und Glasfaserverkabelung samt Offload-ASIC aus. Der Kostenpunkt für die Fiber-Variante (7211F) liegt bei 812 Euro, der 7211C für Copper-Verbindungen ist für 754 Euro zu haben. Für einen vergleichbaren FC-HBA etwa von HP (Storageworks 176479-B21) wandern dagegen rund 2500 Euro über den Ladentisch.
Fazit
Doch nicht nur die iSCSI-Host-Bus-Adapter sind preisgünstiger zu haben als ihre Fibre-Channel-Pendants. Während die zum Aufbau von FC-basierten Storage Networks notwendigen FC-Switches und Directors mit mehreren zehntausend Euro zu Buche schlagen, dienen iSCSI handelsübliche Gigabit-Ethernet-Switches und Router als Infrastrukturkomponenten.
Indem iSCSI mit IP und Ethernet bekannte und bewährte Technologien nutzt, senkt es zudem die Kosten für Schulung, Wartung und Management: Administration und Support haben es weitgehend mit bekannten Komponenten und Tools zu tun. Damit birgt iSCSI das Potential, SAN-Türen in IT-Bereiche zu öffnen, die bisher aufgrund der hohen Kosten für Fibre-Channel-basierte Systeme verschlossen waren.
Das Hardware-basierte Off-loading von TCP/IP verschafft iSCSI Datendurchsatzraten, die mit Fibre Channel durchaus konkurrieren können. Dabei schließen sich die beiden Verfahren keineswegs gegenseitig aus: Ähnlich wie bei SAN und NAS wird sich über kurz oder lang auch ein Nebeneinander der Übertragungsprotokolle iSCSI und FC im SAN ergeben. (jlu)
Zum Autor: Hans Jürgen Rauscher arbeitet als System Architect Networking für Wind River Inc. und weist mehr als 12 Jahre Erfahrung als Berater, Projektleiter und freier Autor in der IT- und Kommunikations-Branche auf.