© Rudi van der Walt, Fotolia.com

Storage ist teuer. Schon eine SAN-Testumgebung mit Glasfaserkabeln und Switches aufbauen geht ordentlich ins Geld. I-SCSI dagegen genießt den Ruf einer einfachen und flexiblen Technologie, die gleichzeitig günstig und leistungsfähig ist. Das Block-basierte Storage-Protokoll auf TCP/IP-Basis vereinfacht nicht nur das Management, es ermöglicht dem Administrator sogar eine kostenlose Testlandschaft. Die Rolle des Storage-Servers übernimmt dabei einfach ein Rechner oder eine virtuelle Instanz.

Storage-Know-how

Bei Block-basierten Storage-Protokollen wie Fibre Channel, ATA oder SCSI senden Clients Anfragen an den Storage in einer Form wie: Gib mir Block 4711 von Lun 0815. NFS (Network File System) oder SMB (Server Message Block) dagegen sind Datei-basierte Storage-Protokolle, bei denen die Anfrage lauten könnte: Gib mir Datei »/tmp/foo« vom Share »allfiles«. Dass diese Kommunikation über unterschiedliche Medien laufen kann, stiftet bisweilen einige Verwirrung und verursacht zahlreiche Abkürzungen: SCSI über Internet (genauer über TCP/IP) nennt sich I-SCSI. Auch Fibre Channel und ATA können über Ethernet kommunizieren. FC over Ethernet heißt dann FCoE, ATA wird zu AoE. Tabelle 1 gibt einen kleinen Überblick dazu.

Der Storage-Bereich kennt eigene Begrifflichkeiten für die Duos Terminal/Host beziehungsweise Client/Server: Die Komponente, die Anfragen stellt (der Client) heißt bei I-SCSI Initiator, die Anfragen beantwortet ein Target, also der Fileserver. Wie Tabelle 1 zeigt, beruhen ATA over Ethernet, Fibre Channel over Ethernet und I-SCSI auf demselben Grundgedanken: Target und Initiator liegen auf unterschiedlichen Boxen und sind durch klassische Netzwerkkomponenten miteinander verbunden. Dadurch ersetzen gängige Standardkomponenten die IDE-Kabel (im Fall von ATA over Ethernet) oder die Glasfasern (bei FCoE).

Tabelle 1: Storage-Matrix

Allerdings bauen diese Lösungen nicht auf TCP/IP auf, sondern auf der niedrigeren Ethernet-Schicht. Das soll den Protokoll-Overhead reduzieren, andererseits macht es aber Routing unmöglich. In einer typischen Installation müssen Target und Initiator also am selben Netzwerk-Switch angeschlossen sein, was bisweilen eine problematische Einschränkung bedeutet. Dafür entlasten moderne Technologien wie TCP Offload Engines (TOE) die CPU vom Protokoll-Overhead.

Gigabit-LAN oder doch lieber Glasfaserkabel?

Im Gegensatz zu NFS erlaubt I-SCSI ein beliebiges Dateisystem. Das ermöglicht das einfache Testen von Cluster-Filesystemen wie OCFS2 und die Einrichtung von Clustern, die auf einem Shared Storage basieren. Anders als bei Fibre Channel ist keine Anschaffung spezieller Switches, HBAs und Kabel fällig [1].

Bei der Übertragungsgeschwindigkeit hat das klassische Netzwerk die des Fibre Channel in den letzten Jahren überholt, und NFS und I-SCSI profitieren von dieser technischen Entwicklung. Während Fibre Channel seine Geschwindigkeit von 2 auf 8 GBit/s vervierfacht hat, hat sich die Ethernet-Übertragungsrate von 1 auf 10 GBit/s verzehnfacht.

Abbildung 1: Das Target (der Server) soll I-SCSI beim Booten automatisch starten und die Firewall den Zugriff auf den Port erlauben.

Targets und Initiatoren

I-SCSI bezeichnet Targets und Initiatoren mit so genannten IQNs (I-SCSI Qualified Names). Ihr Format ist »iqn.{yyyy}-{mm}.{Domainname in vertauschter Reihenfolge}«, also zum Beispiel »iqn.2010-02.com.acme:helloworld«. Der Bestandteil »:helloworld« in dieser IQN ist optional und dient der einfacheren Wiedererkennung. I-SCSI als einfacher Netzwerkservice läuft auf dem TCP-Port 3260 und verschickt Datenblöcke vom Festspeicher. Der Server (genauer der Sockel des I-SCSI-Dienstes) heißt in der I-SCSI-Terminologie Portal. Auf einem solchen Portal können mehrere Targets bereitstehen. Tabelle 2 versucht einen Überblick über die Begriffe und Abkürzungen der I-SCSI-Welt zu vermitteln.

Um einen I-SCSI-Storage aufzubauen ([2], [3]), verwendet der Interessierte zwei Maschinen, am leichtesten wie im folgenden Beispiel mit zwei Open-Suse-11.2-Default-Installationen. Eine, die als Storage-Target agiert, und eine weitere, die als Initiator dient. Hier reichen auch virtuelle Maschinen völlig aus, im Beispiel hat die Target-Instanz die IP 192.168.0.10, der Initiator die 192.168.0.11. Als Hostnamen verwendet das Beispiel »target« beziehungsweise »initiator«.

Tabelle 2: I-SCSI-Glossar

Zunächst erstellt der Administrator eine 1 GByte große Datei, die später als Blockdevice vom Initiator aus zu sehen sein wird:

target: # dd if=/dev/zero of=/tmp/iscsi-
content bs=1024 count=1000000

Dann installiert er das Modul zur I-SCSI-Konfiguration mit »yast -i yast2-iscsi-server« oder »zypper in yast2-iscsi-server«. Erst jetzt existiert das optionale Yast-Modul »Netzwerkdienste | iSCSI-Ziel«, das beim ersten Start fragt, ob der Nutzer das erforderliche Paket »iscsitarget« installieren möchte. Iscsitarget [4] ist eine von vier verschiedenen Linux-I-SCSI-Implementierungen. Im Zusammenspiel mit Suse ist diese Variante definitiv am einfachsten zu konfigurieren. Eine Tabelle auf [5] vergleicht die Features verschiedener I-SCSI-Versionen, darunter auch die in [6] beschriebene Variante Lio von Rising Tide.

Abbildung 1 zeigt das Modul mit den drei Reitern »Dienste«, »Global« und »Ziele«. Während er Boot- und Grundeinstellungen auf den ersten beiden Tabs tätigt, fügt der Admin auf »Target« mit »Add« neue Luns hinzu oder bearbeitet sie mit »Edit« und »Delete« (Abbildung 2).

Abbildung 2: Als Lun kann jede einfache Datei dienen, die auf dem Ziel angelegt ist. I-SCSI exportiert diese als Blockdevice zum Initiator.

Die als Lun sichtbaren Daten soll das System in der Datei »/tmp/iscsi-content« speichern. Danach ist die Konfiguration des I-SCSI-Target abgeschlossen, mit einigen Klicks auf »OK« und »Next« startet auch der Service »iscsitarget« auf Wunsch neu. Der I-SCSI-Server ist fertig, das Target steht bereit.

Der Initiator

Jetzt geht’s an den Client. Um das I-SCSI-Target zu testen, braucht es einen Initiator. Den legt ebenfalls ein Yast-Modul an, doch zunächst sollte der Admin sicherstellen, dass noch kein I-SCSI-Blockdevice vorhanden ist. Hwinfo auf »initiator« sollte eine Antwort geben wie in Listing 1. Das virtuelle System kennt offenbar nur eine SCSI-Festplatte, und zwar jene, auf der das Root-Dateisystem gespeichert ist (»/dev/sda«). Es gibt noch kein I-SCSI-Blockdevice. Das wird sich gleich ändern.

01 initiator # hwinfo --block --short
02 disk:
03  /dev/sda  VMware Virtual S
04 partition:
05  /dev/sda1 Partition
06 cdrom:
07  /dev/sr0  NECVMWar VMware IDE CDR10
08 floppy:
09  /dev/fd0  Floppy Disk
10 [...]

Zur Einrichtung des Initiators startet der Administrator Yast und wählt das Modul »Netzwerkdienste | iSCSI-Initiator«. Das Angebot, »open-iscsi« zu installieren, sollte er annehmen, Yast dient hier als Frontend für die Konfiguration der Initiator-Software Open-iscsi [7]. Der Konfigurationsvorgang ist einigermaßen selbsterklärend, nur die Reihenfolge der Tabs stimmt nicht ganz mit der Vorgehensweise überein. Nach der Bootkonfiguration und der Namensvergabe auf »Dienste« empfiehlt sich zunächst das Suchen nach einem Target auf dem dritten Reiter »Ermittelte Ziele«.

Abbildung 3 zeigt den Startbildschirm beim Konfigurieren des I-SCSI-Initiators. Auch dieser Service soll nach dem Booten zur Verfügung stehen. Weiter geht es mit dem Reiter »Ermittelte Ziele« und der Schaltfläche »Erkennen«.

Die IP-Adresse in diesem Beispiel ist 192.168.0.10. I-SCSI unterstützt einen Authentisierungsmechanismus, bei dem sich Rechner zunächst beim Target anmelden müssen. Deshalb muss der Admin hier – auch ohne Passwort – jetzt auf »Anmelden« klicken. Nach dem nächsten »Weiter« steht das Ergebnis wie in Abbildung 4. Hwinfo zeigt jetzt (Listing 2): Der Admin kann Yast schließen, das Blockdevice steht zur Verfügung.

Abbildung 3: In Suses Initiator-Konfiguration sollte der Admin vom ersten Reiter »Dienst« gleich »Ermittelte Ziele« auf dem dritten Tab suchen, bevor er sie auf »Verbundene Ziele« aktiviert.

Abbildung 4: Der Initiator hat das Target gefunden, ganz wichtig nach der erfolgreichen Discovery ist jetzt das Login.

01 initiator # hwinfo --block --short
02 disk:
03   /dev/sda             VMware Virtual S
04   /dev/sdb             IET VIRTUAL-DISK
05 [...]
06 initiator:~ # fdisk -l /dev/sdb
07 Disk /dev/sdb: 1024 MB, 1024000000 bytes
08 [...]

Spieltrieb und Benchmark

Nun ist es Zeit, dem Spieltrieb nachzugeben und ein wenig zu testen. Dafür fährt der Benutzer den Initiator herunter, er hat seine Aufgabe getan und bewiesen, dass der Zugriff aufs I-SCSI-Target übers Netzwerk möglich ist. Jetzt setzt der Admin nach der obigen Beschreibung einen Initiator auf dem Host »target« auf und richtet das I-SCSI-Device »/dev/sdb« ein. Das vermeintliche Blockdevice »sdb« zeigt so auf die Datei »/tmp/iscsi-content«. Schreibt Root jetzt »Hallo Welt« auf die I-SCSI-Platte, kann er es später aus der Target-Datei (»/tmp/iscsi-content«) auslesen (Listing 3).

01 target:~ # cat /tmp/iscsi-content
02 ^C
03 target:~ # dd of=/dev/sdb
04 hallo Welt
05 0+1 records in
06 0+1 records out
07 15 bytes (15 B) copied, 3.82671 s,U
08  0.0 kB/s
09 target:~ # cat /tmp/iscsi-content
10 hallo Welt

Jetzt soll das System die maximale Schreibgeschwindigkeit ermitteln. Dadurch, dass Target und Initiator auf demselben Computer liegen, bleibt die Netzwerklatenz bei der Messung außen vor, siehe Listing 4. Natürlich ist dies kein allgemeingültiger Benchmark, dagegen sprechen viele Gründe, nicht nur die fehlende Hardware-Disclosure. Das Vorgehen untersucht auch nur den sequenziellen Zugriff.

01 target:~ # dd if=/dev/zero of=/dev/sdb bs=4096

03 250001+0 records in
04 250000+0 records out
05 1024000000 bytes (1.0 GB) copied, 5.711 s, 179 MB/s
06 target:~ # dd if=/dev/zero of=/tmp/test bs=4096 count=1000000
07 1000000+0 records in
08 1000000+0 records out
09 4096000000 bytes (4.1 GB) copied, 10.7513 s, 381 MB/s

Der gemessene Durchsatz ist auch deutlich höher als bei einer Messung auf der physischen Hardware, was darauf schließen lässt, dass die virtuelle Maschine nicht bis auf die Platte selbst geschrieben hat. Das Entscheidende an der Messung ist aber, dass der Admin sie unter gleichen Bedingungen auf der gleichen Hardware durchführt, einmal mit I-SCSI und einmal ohne.

Der Durchsatz ist, wie zu erwarten war, auf purer Hardware deutlich höher, 381 MByte/s im Vergleich zu 179 MByte/s über I-SCSI. Das gibt eine Größenordnung an, mit der sich planen lässt, der Admin muss mit einem Geschwindigkeitsverlust um die Hälfte eher rechnen als mit einem Einbruch um 90 Prozent.

So ist es möglich, ein Testsystem aufzusetzen, ohne dass der Zeitplan aus dem Ruder läuft, weil die Rechner oder die Infrastruktur nicht fertig werden. Wem 50 Prozent Performanceverlust zu viel sind, der sollte sich lieber einen professionellen, aber auch deutlich teuereren I-SCSI-Storage zulegen.

Troubleshooting: Wenn’s nicht gleich läuft

Nicht immer läuft die Einrichtung von I-SCSI so problemlos wie oben beschrieben. Der folgende grobe Überblick soll helfen Fehler einzugrenzen. Natürlich muss der Target-Service erreichbar sein, dies kann schon ein simpler Portscan prüfen:

# nmap target -p 3260
[...]
3260/tcp open  iscsi

Außerdem muss der Initiator-Service laufen, im obigen Beispiel prüft das:

# /etc/init.d/open-iscsi status
Checking for I-Scsi initiator service: 
 running

Die entsprechende IQN muss für die Clientsoftware (»iscsiadm« ist Teil von »open-iscsi«) sichtbar sein:

# iscsiadm --mode discovery --type 
sendtargets --portal 192.168.0.110 
192.168.0.110:3260,1 iqn.2001-04.com.
example:storage.disk2.sys1.xyz

Nun sollte nach einem Login das entsprechende Device sichtbar sein (Listing 5).

01 # iscsiadm --mode node --targetname
   iqn.2001-04.com.example:storage.disk2.sys1.xyz
   --portal 192.168.0.110:3260 --logout
02 # dmesg -c
03 # iscsiadm --mode node --targetname
   iqn.2001-04.com.example:storage.disk2.sys1.xyz
   --portal 192.168.0.110:3260 --login
04 # dmesg
05 [...]
06 [684841.235407] sd 7:0:0:0: [sde] 2000000
   512-byte logical blocks: (1.02 GB/976 MiB)
07 [...]

Zukunftssicher?

Bei I-SCSI handelt es sich um eine ausgereifte, unternehmensfähige Technologie. Sie wird vom ganzen Markt getragen, es existieren entsprechend optimierte Netzwerkkarten und -switche sowie professionelle Storage-Lösungen und Software für Linux und Windows. Damit steht I-SCSI auf einer Stufe mit Fibre Channel und NAS. Das spiegelt sich auch in der Fülle der unterstützten Features.

Vieles spricht dafür, das oben geschilderte Szenario nur für Testsysteme und Experimente zu nutzen und sich ansonsten einen professionellen I-SCSI-Storage anzuschaffen. So ist Software-Raid über I-SCSI-Devices meist problematisch [8], der Administrator handelt sich zudem viel Arbeit ein, wenn einmal im unternehmensweiten Einsatz die Forderung nach Persistent Reservations aufkommt. Die braucht er fürs Windows-Server- Failover-Clustering, Iscsitarget unterstützt sie aber nicht [9].

Im schlimmsten Fall muss er mit der Einrichtung neu beginnen, allerdings wohl mit einer Target-Software, für die es keinen derart simplen Konfigurator wie Yast 2 gibt. Erfahrungsgemäß beheben die Hersteller professioneller Storage-Produkte solche Probleme schnell und es ist fast immer einfacher, ein Firmware-Update einzuspielen, als sich mit kniffligen Problemen dieser Art auseinanderzusetzen.

Für den Unternehmenseinsatz ebenfalls wichtig ist Boot from SAN (I-SCSI Boot Firmwar Table (IBFT), [10]), da sich damit eine Provisioning-Infrastruktur einrichten lässt. Ob sich ein Computer in die SAP-Landschaft integriert oder als Webserver zum Einsatz kommt, entscheidet dann das Bootimage, das der Admin ihm zur Verfügung stellt. Eine weitere Voraussetzung ist die Fähigkeit zu Snapshots, die eine Downtime für die Datensicherung unnötig macht. Das System arbeitet weiter, während der Admin in aller Ruhe vom Snapshot ein Backup anfertigt. Auch dafür steht in Yast ein eigener Reiter parat (Abbildung 3).

Ein weiteres Unternehmens-Feature, das professionelle I-SCSI-Storages bieten, ist die Authentisierung von Nutzern mittels ihrer IP-Adressen, Initiator-Namen oder mit Chap-Authentisierung. Falsch ist dagegen die verbreitete Einschätzung, dass Cluster unbedingt Blockdevices verlangen. Beispielsweise arbeitet Oracles Real Application Cluster auch mit NFS-Storages zusammen. Mit NFS verschiebt sich sogar das Problem des File Locking elegant an eine zentrale Stelle. Falls hier OCFS2 mit Block-basierten Devices zum Einsatz kommt, müssen die Clusterknoten das File Locking über das Netzwerk untereinander ausmachen.

Elegant und günstig

I-SCSI ist nur eines von vielen Storage-Protokollen. Ein Admin, der auf der Suche nach einer zukunftssicheren Lösung ist, die von mehreren großen Herstellerfirmen getrieben und von künftigen Betriebssystemen mit großer Wahrscheinlichkeit unterstützt wird, ist mit I-SCSI, NFS oder Fibre Channel gut beraten.

Innerhalb dieser Auswahl kommt es dann auf den Preis-Leistungs-Vergleich an. Auf der einen Seite landen dabei Anschaffung und Trainingsaufwand in der Waagschale. Die Leistung dagegen setzt sich zusammen aus Storage-Kapazität und -Performance und nicht zuletzt der gewünschten Applikation. Setzt eine Anwendung, zum Beispiel ein spezieller Cluster, Block-basierte Devices voraus, dann scheidet NFS aus.

Vielerorts sind Anschaffung und Know-how-Aufwand für Fibre Channel zu aufwändig. Der Einsatz von professionellen I-SCSI-Storages statt der Software-Targets ist sinnvoll, da diese meist eine höhere Performance bieten und Features wie Netzwerkkarten-Teaming, Snapshots und Authentisierung leicht zugänglich machen. Probleme bei der Interoperabilität mit neuen Betriebssystemen räumen die Hersteller meist ohne viel Arbeit für den Besitzer aus.

Aber eines bleibt: Die Vereinigung zweier Welten, der auf TCP/IP-basierenden mit der Block-based-Storage-Welt ist elegant. Außerdem erweist sich I-SCSI als praktische Möglichkeit, ohne Hardware-Anschaffungen einen Shared Storage aufzusetzen. Ganz ohne Budget kann der interessierte Nutzer sich so einen Prototyp aufbauen und schnell Cluster-File-systeme wie OCFS2 oder High-Availability-Cluster wie Heartbeat unter die Lupe nehmen. (mfe)