© Martin Konopka, 123RF

Das Multiprotokoll-SCSI-Target LIO eignet sich wegen seiner breiten Unterstützung von SCSI-Standards gerade für komplexe Testumgebungen sehr gut.

Gegenwärtig beherrschen drei Netzwerktechnologien das SAN: Fibre Channel (FC), I-SCSI und neuerdings Fibre Channel over Ethernet (FCoE). Von den dreien lässt sich nur I-SCSI ohne Weiteres auf einem Standard-LAN einrichten. FCoE erfordert dagegen Anpassungen im Ethernet, und Fibre Channel setzt ein ganz anderes Netzwerk voraus. I-SCSI hingegen tunnelt SCSI-Kommandos über gewöhnliche TCP-Verbindungen und lässt sich damit sogar wie viele andere Protokolle über IP routen.

Dadurch ist I-SCSI nicht nur als kostengünstige Alternative zum bislang dominanten Fibre Channel zu sehen, sondern bietet sich auch an, wenn es darum geht, Testaufbauten einzurichten. So lässt sich zum Beispiel ein Speicherschrank mittels einer virtuellen Maschine simulieren, indem der Admin ein geeignetes I-SCSI-Target innerhalb des Betriebssystems der VM installiert. Diesen Anwendungsfall möchte der vorliegende Artikel näher unter die Lupe nehmen. Besonderen Wert legt er auf die Praxis.

Bis vor 2011 war I-SCSI Enterprise Target (IET) das Standard-SCSI-Target innerhalb des Linux-Kerns [1]. Abgelöst wurde es dann durch LIO (das ist ein Handelsname der Datera Inc., Näheres auf der Projektseite [2]). Eine wesentliche Verbesserung war die breitere Unterstützung diverser SCSI-Standards, insbesondere die von Asymmetric Logical Unit Assignment (ALUA) und von SCSI 3 Persistent Reservations [3]. Von Letzteren wird später noch die Rede sein.

LIO wurde bereits früher einmal im Linux Magazin vorgestellt [4]. Dieser Artikel behandelte auch die Konfigurationsmöglichkeiten mit Hilfe der »lio-utils« . Die wurden jedoch inzwischen von dem neuen Tool »targetcli« abgelöst, dessen Installation und Verwendung nun dieser Artikel beschreibt.

Die Installation

Als Betriebssystem für das I-SCSI-Target wird hier Open Suse 13.2 verwendet. Zumindest in Testaufbauten sollte der Admin zu den neuesten Versionen der Software greifen. Das ist auch der Grund für die Empfehlung, das Tool »targetcli« aus den Sourcen zu kompilieren. Die im Internet verfügbaren RPMs sind offenbar zurzeit noch älter als die Version 3. Wer sich auf die unten beschriebene Weise ein eigenes Paket mit der neuesten Version herstellen will, für den wären allerdings Vorkenntnisse im Bau von RPM-Paketen empfehlenswert.

Wenn Open Suse 13.2 für den Test neu aufgesetzt wird, dann empfiehlt es sich, auch die C/C++- sowie Python-Entwicklungsumgebung gleich mitzuinstallieren. Ebenso werden »rpmbuild« und Git benötigt, die Zypper leicht holen kann. Zusätzlich sind mehrere Python-Pakete nachzuinstallieren, wiederum mit Hilfe von Zypper:

zypper in git
zypper in rpmbuild
zypper in python-parsing
zypper in epydoc
zypper in python-netifaces
zypper in python-ipaddr
zypper in python urwid
zypper in python-prettytable

Die Sourcen von »targetcli« sowie der benötigten »rtslib« beziehungsweise »configshell« sind auf Github zu finden (Abbildung 1).

Abbildung 1: Aus Github besorgt sich der Installateur die Quellen von »configshell«, »rtslib« und »targetcli«.

Im nächsten Schritt gilt es, mit dem Kommando »make rpm« die RPM-Pakete von »configshell« und »rtslib« zu bauen. Kommt es dabei zu Fehlern, so liegt das vermutlich daran, dass in den erzeugten Spec-Dateien Verweise auf »pyparsing« statt auf »python-parsing« enthalten sind. Als Workaround passt der Paketbauer die erzeugten Spec-Dateien an und wiederholt den Build.

Zum Schluss lassen sich die soeben erzeugten RPM-Pakete installieren, außerdem das RPM-Paket von »targetcli« bauen und installieren sowie der Target-Service starten:

# rpm -qa | egrep -e targetcli\|configshell\|rtslib
python-rtslib-3.0.pre4.9~g6fd0bbf-1.noarch
targetcli-3.0.pre4.3~g0fba804-1.noarch
python-configshell-1.6.1~g020d540-1.noarch
# chkconfig target on
# service target start

Mit etwas Übung erweist es sich als kein Problem, »targetcli« zu verwenden, und mit Hilfe des Help-Kommandos findet jedermann sich gut zurecht. Es gibt dazu auch eine Dokumentation auf der LIO-Projektseite [5].

Auf mehreren Wegen

Das »targetcli« kann verschiedene Backstores verwenden, die die Daten letztlich speichern. Das können beispielsweise Disks oder Partitionen, aber auch Volumes sein. Diese Backstores kann der Admin über I-SCSI für Clients verfügbar machen, indem er zunächst ein I-SCSI-Target erzeugt. Das Kommando »targetcli« generiert dabei den I-SCSI Qualified Name (IQN), der als Adresse für das Target innerhalb von I-SCSI fungiert, automatisch.

Danach ist nur noch ein Portal mit einer IP-Adresse anzulegen, an der das I-SCSI-Target auf TCP-Aufrufe warten soll. Den Port 3260 extra anzugeben ist nicht nötig, da er Default ist. Wie auch in der Praxis, soll hier dasselbe Volume über zwei IP-Adressen erreichbar sein – Stichwort Hochverfügbarkeit der Pfade (Abbildung 2). Günstig für Testaufbauten ist es, die I-SCSI-Authentifizierung auszuschalten und LIO in den so genannten Demo-Modus zu versetzen (Abbildung 3).

Abbildung 2: Ein Target mit einem I-SCSI Qualified Name (IQN) enthält zwei so genannte Target Portal Groups (TPGs) und ist damit auch über zwei Wege (IP-Adressen) erreichbar.

Abbildung 3: Das Abschalten der Authentifizierung vereinfacht den Konfigurationsprozess und empfiehlt sich deshalb zumindest für Testaufbauten.

Im Client-Betriebssystem wird ein I-SCSI-Initiator benötigt, mit dessen Hilfe man sich in das I-SCSI-Target einloggen kann. Unter Linux gibt es dafür das »open-iscsi« -Paket mit seinem Kommando »iscsiadm« . Der I-SCSI-Initiator benötigt eine Konfiguration, die wieder mindestens einen IQN vergibt. Den kann aber das Betriebssystem auch selbst erzeugen. Das Discovery und das Einloggen eines Clients könnte in obigem Beispiel geschehen wie in Listing 1.

01 initiator # iscsiadm -m discovery -t st -p 10.20.10.1
02 10.20.10.1:3260,1 iqn.2003-01.org.linux-iscsi.target.x8664:sn.71604388deb0
03 10.30.10.1:3260,1 iqn.2003-01.org.linux-iscsi.target.x8664:sn.71604388deb0
04 [...]
05 initiator # iscsiadm -m mode -p 10.20.10.1 -l
06 Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target.x8664:sn.71604388deb0, portal: 10.20.10.1,3260] (multiple)
07 Logging to [iface: default, target: iqn.2003-01.org.linux-iscsi.target.x8664:sn.71604388deb0, portal: 10.20.10.1,3260] successful.
08 [...]
09 initiator # fdisk -l
10 [...]
11 Disk /dev/sda: 107,4 GB, 107373133824 Bytes
12 25 heads, 63 sectors/track, 13054 cylinders, total 209713152 sectors
13 Unist = sectors of 1 * 512 = 512 bytes
14 Sector size (logical/physical): 512 bytes / 512 bytes
15 I/O size (minimum/optimal): 512 bytes / 4194304 bytes
16 Disk identifier: 0x00000000
17
18 Disk /dev/sda doens't contain a valid partition table.
19
20 Disk /dev/sdb: 107,4 GB, 107373133824 Bytes
21 [...]

Manchen aufmerksamen Lesern wird auffallen, dass das Beispiel zu dem einen Volume Client-seitig zwei Devices erzeugt hat, da ja auch zwei Pfade vorhanden sind. Es wäre jetzt Aufgabe einer Multipathing-Software auf dem Client, zu erkennen, dass beide Devices dieselbe LUN repräsentieren.

Fazit

Es gelingt mit der hier vorgestellten Idee, etwa einen Symantec Cluster [6] mittels virtueller Maschinen zu bauen, inklusive Multipathing und SCSI3-Fencing. Ein wesentliches Element ist dabei die Unterstützung von SCSI 3 Persistent Reservations seitens LIO. Ohne dieses Fencing, das andere I-SCSI-Targets nicht bieten, würde der Symantec-Cluster nicht funktionieren. SCSI 3 Persistent Reservations verlangen zudem auch andere Produkte, zum Beispiel neuerdings die In-Memory-Datenbank SAP HANA.