© Jeff Crow, 123RF.com

Mit Version 2.6.38 hält ein modular aufgebautes I-SCSI Storage Target Einzug in den offiziellen Kernel. Dieser Artikel zeigt, wie Admins damit flexiblere und schnellere Fileserver aufsetzen.

Um Storage-Systeme kostengünstig ananzubinden, hat sich I-SCSI [1] längst etabliert, fast alle modernen Betriebssysteme bringen Clients dafür mit. Auf Server-Seite, also bei den I-SCSI-Zielen (Targets), hat der Linux-Admin die Wahl zwischen mehreren Lösungen, zum Beispiel den altbewährten Net-BSD-Userland-Targets oder dem I-SCSI Enterprise Target IET [2]. Eine weitere Variante hat sich in letzter Zeit zu einem ausgewachsenen Multiprotocol Storage Target entwickelt: die Implementierung von Linux-iscsi.org – kurz Lio [3].

Dieses Framework ist ab Kernel 2.6.38 vollständig im Kernel enthalten und beherrscht über seine Fabric Modules unter anderem Protokolle wie Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) oder Infiniband (IB) und eignet sich damit zum Einrichten flexibler Storage Area Networks (SAN).

Seine Leistungsfähigkeit stellt das Lio-Target in Storage-Appliances von Netgear, QNAP oder Synology unter Beweis. Der folgende Workshop gibt einen Überblick über Architektur, Installation sowie die Konfiguration und lässt sich am besten mit der virtuellen Maschine auf der Linux-Magazin-DVD nachvollziehen.

Lio-Framework

Lio ist modular aufgebaut und besteht aus dem Target Core Module (TCM), das zum einen mit der Generic Target Engine die grundlegende SCSI-Funktionalität implementiert und die Schnittstelle zu den Fabric Modules bereitstellt, zum anderen mit der Storage Management Engine die Verwaltung der physikalischen Speicherobjekte übernimmt (Abbildung 1). Mehr Details zum Aufbau liefert das Lio-Wiki [4].

Abbildung 1: Die modulare Architektur von Lio enthält das Storage-Management und eine Generic Target Engine mit zahlreichen Fabric Modules zum Anbinden von Clients.

Die Generic Target Engine entspricht den SPC-3- und SPC-4-Standards (SCSI Primary Commands, [5]) und bietet mit Persistent Reservations (PR) und Asymmetric Logical Unit Assignment (ALUA) auch Funktionen, die für Admins hochverfügbarer Clustersysteme relevant sind. In der Storage Management Engine sorgen die Backstore-Plugins (Kasten “Lio-Backstore-Plugins”) für die eigentlichen physikalischen Speicherobjekte.

Zu den Fabric Modules als Protokolltreiber des Framework gehören neben dem namengebenden I-SCSI unter anderem auch FCoE, Fibre Channel mit Host Bus Adaptern (HBA) der Qla2xxx-Serie von Qlogic, Infiniband oder ein Loopback-Modul. Die I-SCSI-Implementierung ist bereits erfolgreich für VMware ESX 4.0 und VMware V-Sphere 4.0 zertifiziert, funktioniert aber auch bestens mit dem nativen Initiator von Virtualbox.

Einzug in den Kernel

Den Anfang im SCSI-Subsystem des Kernels 2.6.38 [6] macht zunächst das Target Core Module (TCM, [7]). Mit 2.6.39 sollen die Protokolltreiber für I-SCSI, FC für Qlogic HBA sowie FCoE folgen. Damit ersetzt langfristig das Lio-Target das bereits im Kernel enthaltene STGT (SCSI Target Framework).

Zur Konfiguration nutzen TCM und die zugehörigen Protokolltreiber das mit Kernel 2.6.15 im Rahmen von OCFS2 eingeführte Config-FS. Es stellt über das Dateisystem eine Konfigurationsschnittstelle für Kernelobjekte bereit. Durch Anlegen, Verändern und Löschen von Dateien und Verzeichnissen innerhalb des Config-FS konfiguriert der Admin das TCM und die Fabric Modules. Mit den quelloffenen Lio-utils [8] steht dafür eine Reihe von Python-Skripten bereit.

Kernel 2.6.39

Das in 2.6.38 enthaltene Target trägt die Versionsnummer 4.0.0-rc7. Wenn in 2.6.39 dann auch die ersten Fabric Modules hinzukommen, dürfte das Framework auf Version 4.1.0 klettern. Wer gerne auf der Bleeding-Edge-Welle reitet, checkt aus dem Repository des Projekts von [9] den aktuellen Entwicklungsstand des Kernels nebst Lio-Framework aus. Für die Lio-utils gibt es dort ein eigenes Repository [10], das auch Tools zur Konfiguration beinhaltet. Den aktuellen Sourcecode des Lio-Kernels lädt anschließend der folgende Befehl herunter:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git

Danach folgt die übliche Prozedur zum Bau eines eigenen Kernels. Die Lio-Module verbergen sich hinter »Device Drivers | Generic Target Core Mod (TCM) and Config-FS Infrastructure« , darunter die Module der verschiedenen Backstores sowie die Fabric Modules.

Für die ersten I-SCSI-Gehversuche sollte der Admin seinen Kernel mit folgenden Moduloptionen kompilieren und installieren:

CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
CONFIG_LIO_TARGET=m

Wer sich keinen eigenen Kernel bauen kann oder will, findet bei der Firma Rising Tide [11], die das Projekt maßgeblich vorantreibt, ein Backports-Repository auf Basis der stabilen Release 3.5.2 des Target für diverse Standardkernel der Distributionen [12]. Damit kann er das TCM nebst I-SCSI-Fabric-Modulen problemlos für Kernel ab Version 2.6.18 nachrüsten. Passende Lio-utils gibt es bereits fertig paketiert für Open Suse/SLES 11 [13], RHEL 6 [14] und Fedora 13 [15]. Die weiteren Beispiele wie auch das virtuelle Image auf der DELUG-DVD basieren auf Fedora 13 mit dem Kernel 2.6.34.8 sowie den fertigen Lio-utils.

Installation

Für ein erfolgreiches Kompilieren des Target sind neben den üblichen Verdächtigen »make« und »gcc« auch das »kernel-devel« -Paket sowie Git nötig. Ein

git clone git://risingtidesystems.com/lio-core-backports.git

erzeugt eine lokale Kopie des Backports-Repository, das der Admin später bei Bedarf mit »git pull« aktualisiert.

Nach einem Wechsel in das Verzeichnis des lokalen Repository lassen sich die Kernelmodule für TCM- und I-SCSI-Transport als Root mit »make« gefolgt von »make install« für den laufenden Kernel der eigenen Distribution übersetzen und installieren. Die Module befinden sich dann in »/lib/modules/Kernel/extra/« . Ältere Kernel vor Version 2.6.27 bekommen so auch gleich das notwendige Config-FS passend nachgerüstet.

Selbstverständlich lassen sich die Kernelmodule auch als RPM- und Deb-Pakete bauen, allerdings hakt das zuständige Skript (zumindest unter Fedora) und verlangt ein wenig Starthilfe:

mkdir -p /usr/src/redhat/SPECS
mkdir /usr/src/redhat/SOURCES
ln -s /usr/src/redhat /root/rpmbuild
make kernel_rpms

Die fertigen Pakete liegen anschließend unter »/root/rpmbuild/RPMS/Architektur/« . Ein beherztes »modprobe iscsi_target_mod« lädt das I-SCSI-Modul nebst den darunterliegenden »target_core_mod« und »configfs« . Das Kommando initialisiert auch gleich die im TCM einkompilierten Backstore-Plugins.

Wer – wie oben beschrieben – den aktuellen Entwicklerkernel kompiliert hat, muss die Backstore-Plugins, die in diesem Fall mit den restlichen Modulen unter »/lib/modules/Kernel/kernel/drivers/target« liegen, separat nachladen. Der Config-FS-Aktivierung dient:

mount -t configfs configfs /sys/kernel/config

Damit sind die Verzeichnisstrukturen unterhalb des »configfs« -Mountpoint sichtbar und der Admin kann das Target darüber konfigurieren, allerdings funktioniert das etwas umständlich.

Konfiguration mit Hilfe der Lio-utils

Besser klappt die Konfiguration mit Hilfe der Python-Skripte aus den Lio-utils (RPM-Pakete sind in den Repositories zu finden): »tcm_node« konfiguriert das TCM, »lio_node« das I-SCSI-Modul und »iscsi-name« erzeugt noch einen eindeutigen I-SCSI-Node-Namen. Das RC-Skript »/etc/init.d/target« startet beim Booten das Target und mountet das Config-FS automatisch. Permanent integriert »chkconfig –add target« das RC-Skript in die Runlevel.

Mit dem Kompilieren und Starten der Dienste ist es aber noch nicht getan. Mittels Tcm_node legt der Admin jetzt einen neuen Hostadapter mit einem der Backstores und einem zugehörigen Storage-Device an:

tcm_node --fileio fileio_0/myfileio /data/lio-file 1024000000

Damit erzeugt er einen HBA für das Fileio-Backstore mit einer Datei von knapp 1 GByte Größe als Storage-Device. Die angegebene Datei muss dabei nicht vorhanden sein, Tcm_node legt sie beim erstmaligen Erzeugen des HBA an. Jetzt bedarf es für das Anlegen der I-SCSI-LUN noch eines eindeutigen I-SCSI-Node-Namens, den Iscsi-name nennt:

iscsi-name iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e

Den zuvor angelegten HBA nebst Device weist der Admin jetzt bei einem I-SCSI-Target mit dem angegebenen Node Name einer Target Portal Group (TPG) 1 als LUN 0 mit dem Alias »lunfile« zu:

lio_node --addlun iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e 1 0lunfile fileio_0/myfileio

Die TPG stellt dabei eine Kombination aus LUNs auf der einen Seite und Netzwerkanbindungen, so genannten Network Portals, auf der anderen Seite dar. Das Network-Portal für das I-SCSI-Target und dessen TPG soll auf die lokale IP-Adresse 192.168.10.45 der Target-Maschine und den Standard-I-SCSI-Port 3260 hören:

lio_node --addnp iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e 1 192.168.10.45:3260

Die Authentifizierung zwischen einem I-SCSI-Target und dem Client, auch Initiator genannt, erfolgt zum Beispiel via CHAP. Für erste Gehversuche und den Testbetrieb empfiehlt es sich, diese potenzielle Fehlerquelle auszuschalten, wodurch aber zunächst nur Read-only-Zugriffe auf das Target möglich sind.

Testweise offen

Für Read-write-Zugriffe auf einzelne LUNs bedarf es einer ACL für den Initiator-Namen des Clients und der Freigabe der LUN 0 des Target als LUN 0 für den Client. Im folgenden Beispiel ist der Client ein weiteres Fedora-System mit dem Paket »iscsi-initiator-utils« . Der Initiator-Name findet sich in der Datei »/etc/iscsi/initiatorname.iscsi« und lautet hier »iqn.2005-03.com.redhat:01.52bdfdffb14a« :

lio_node --disableauth iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e 1
lio_node --addlunacl iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e 1 iqn.2005-03.com.redhat:01.52bdfdffb14a 0 0

Alternativ dazu lassen sich mit »–addnodeacl« auch alle LUNs der TPG für einen Initiator freigeben. Zu guter Letzt muss der Admin die TPG und das gesamte I-SCSI-Target noch aktivieren:

lio_node --enabletpg iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e 1

Das RC-Skript der Lio-utils zeigt nun den Status des Target (Abbildung 2). Alle Konfigurationen des Ziels sind auch in Form von Dateien und Verzeichnissen im Config-FS vorhanden. Ein erster Überblick ist mit dem Befehl »tree -d /sys/kernel/config/target/« möglich.

Abbildung 2: Statusausgabe des RC-Skripts für ein konfiguriertes I-SCSI-Target.

Discovery

Auf Client-Seite muss jetzt einmalig eine Discovery des Target laufen, anschließend kann sich der Initiator beim neu gefundenen Server einloggen:

iscsiadm -m discovery -t sendtargets-p 192.168.10.45:3260
iscsiadm -m node -T iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e-p 192.168.10.45:3260 --login

Die LUN des I-SCSI-Target taucht jetzt als »/dev/sdX« im Client auf und lässt sich wie eine lokale Disk ansprechen. Parallel dazu protokolliert das Syslog der Target-Maschine den Verbindungsaufbau.

Der Befehl »tcm_dump -o« sichert – nach einer Sicherheitsabfrage gegen versehentliches Überschreiben – die aktuelle Konfiguration für das gesamten Target in zwei Shellskripten. Damit stellt das System beim Booten die Konfiguration wieder her und das Target ist sofort einsatzbereit.

Als weiteres Konfigurationswerkzeug steht dem Administrator Rtsadmin zur Seite [16], es liegt bisher allerdings nur als Binary-RPM für Open Suse/SLES, RHEL und Fedora in den oben genannten Quellen vor.

Rtsadmin

Unter der Haube bedient sich Rtsadmin teilweise der Lio-utils, bietet aber mit einem CLI sowie einem interaktiven Modus mit kontextabhängiger [Tab]-Completion eine sehr komfortable Möglichkeit, um Targets zu verwalten. Vor allem angesichts der langen I-SCSI-Terminologie erweist sich die [Tab]-Completion als große Hilfe. Für eine ausführliche Beschreibung aller vorhandenen Befehle empfiehlt sich das Rtsadmin-Manual [17].

Im interaktiven Modus lässt sich beispielsweise mit »list« – ähnlich wie im Config-FS – die aktuelle Konfiguration des vorher mit den Lio-utils erstellten Target ausgeben (Abbildung 3). Mit den Befehlen »cd« und »enter« wechselt der Admin in den zu konfigurierenden Kontext und bearbeitet dort mit »create« und »delete« die Objekte.

Abbildung 3: Im interaktiven Modus des Rtsadmin konfiguriert der Administrator seine LUNs. An der Kommandozeile vervollständigt das Tool dabei auch die ellenlangen I-SCSI-Targetnamen.

CLI-Modus

Im CLI-Modus verketten Kundige mehrere Kommandos, was Rtsadmin auch via Skript akzeptiert. Das Beispiel in Listing 1 (auch auf der DELUG-DVD) erstellt – aufgerufen mit »rtsadmin ./rtsadmin.create« – dasselbe I-SCSI-Target wie die Kommandos der Lio-utils weiter oben in diesem Artikel. Es legt das passende Network-Portal beim Erzeugen des Target automatisch an und erstellt zusätzlich eine Iblock-LUN auf Basis eines LVM-Volume sowie eine Pscsi-LUN mit einer SCSI-Disk. Ein abschließendes »rtsadmin saveconfig« macht auch hier das Target wieder Reboot-sicher.

01 # File: rtsadmin.create
02 # Create FILEIO Storage
03 #
04 create hba fileio 0
05 enter hba fileio 0 , create storage myfileio /data/lio-file 1024000000
06 #
07 # Create iSCSI Target and map LUN
08 #
09 create target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e
10 enter target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e , enter tpg 1 , create lun fileio0/myfileio 0
11 #
12 # Create IBLOCK Storage and map LUN
13 #
14 create hba iblock 0
15 enter hba iblock 0 , create storage myiblock /dev/vg_data/lv_iscsi
16 enter target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e , enter tpg 1 , create lun iblock0/myiblock 2
17 #
18 # Create PSCSI Storage and map LUN
19 #
20 create hba pscsi 0
21 enter hba pscsi 0 , create storage mypscsi /dev/sdc
22 enter target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e , enter tpg 1 , create lun pscsi0/mypscsi 4
23 #
24 # Create ACLs for Initiators
25 #
26 enter target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e , enter tpg 1 , create nodeacl iqn.2005-03.com.redhat:01.52bdfdffb14a
27 enter target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e , enter tpg 1 , create nodeacl iqn.2009-08.com.sun.virtualbox.initiator:01:192.168.10.173

Die so eingerichteten I-SCSI-Targets eignen sich hervorragend als virtuelle Disks für Virtualisierungen wie VMware ESX oder Virtualbox, die einen nativen I-SCSI-Initiator im Gepäck haben. Vor allem in Version 4 des freien Virtualbox haben die Entwickler diesen noch einmal grundlegend überarbeitet. Der Initiator-Name für 4.0.x bildet sich nach dem Schema »iqn.2009-08.com.sun.virtualbox.initiator:01:Virtualbox-Host-IP« .

Virtualbox und VMware

Auch hier erzeugt das oben genannte Skript eine ACL für die virtuelle Schachtel. Um einer Vbox-VM mit Namen »Linux-VM« am ersten virtuellen SATA-Adapter die LUN 4 aus dem oben erwähnten Beispiel zuzuweisen, ist folgender Befehl auf der Kommandozeile des Vbox-Host notwendig:

vboxmanage storageattach Linux-VM--storagectl SATA-Controller --port 0--device 0 --type hdd --medium iscsi--server 192.168.10.45 --target iqn.2003-01.org.linux-iscsi.fedora13.x86:sn.307c94a3c58e --lun 4

Das Ergebnis zeigt Abbildung 4 im Virtualbox-GUI, Abbildung 5 jenes für eine VMware V-Sphere.

Abbildung 4: Virtualisierungen wie Virtualbox binden I-SCSI-Targets unkompliziert via GUI ein.

Abbildung 5: Auch Marktführer VMware beherrscht I-SCSI, zumindest in den teureren Produkten.

Das Lio-Framework ist auf einem guten Weg, sich als universelles Storage-Target zu etablieren. Die reichhaltigen Features und die komfortablen Konfigurationswerkzeuge machen es sowohl im heimischen Netzwerk als auch in Enterprise-Umgebungen einsatzfähig. Durch die vollständige Implementierung im Kernelspace lässt sich zudem eine hohe Performance erreichen, die im 10-GBit-Ethernet sogar aktuelle Fibre-Channel-Storages abhängt. Dennoch können Admins das Target über das Fibre Channel Fabric Module auch in bestehende SAN-Infrastrukturen einbinden.

Das Lio-Framework sowie die Lio-utils sind Teil des Lisog Open Source Cloud Stack [18], in Kombination mit den HA-Komponenten des Stack – DRBD und Pacemaker – lassen sich hochverfügbare Open-Source-Storage-Cluster aufbauen. Rising Tide [11] bietet mit dem RTS Director ein auf Lio aufsetzendes Storage-Cluster-Framework nebst Verwaltungswerkzeugen an, allerdings nur als Closed Source. Ein schickes Demovideo dazu gibt’s auf Youtube [19].

KVM mit Virt-IO

Als weiteres Projekt arbeitet Rising Tide derzeit gemeinsam mit IBMs Linux Technology Center an einer Lösung, um die bei KVM für den I/O-Zugriff notwendige Qemu-Zwischenschicht zu umgehen. IBM entwickelt einen »virtio-scsi« -Treiber für KVM-Gäste, Rising Tide ein passendes Fabric Module »tcm_vhost« . Damit können KVM-Gäste ohne Umwege und Performanceverlust auf Lio-Targets als Storage-Backend zugreifen. (mfe)