SCSI target framework

Eine alternative iSCSI-Implementierung stellt das SCSI Target Framework (TGT) dar. Gängige Distributionen stellen hierfür ebenfalls Pakete zur Verfügung. Unter Lenny lautet der Paketname »tgt« und unter Distributionen der RHEL-Familie »scsi‑target‑utils«. Die Pakete beinhalten auch hier sowohl einen Target-Daemon als auch entsprechende Userspace-Verwaltungswerkzeuge. Die Konfiguration erfolgt in der Datei »/etc/tgt/ targets.conf«, lässt sich jedoch auch in mehrere Dateien auslagern, die man dann in die »target. conf« einbindet: »include /etc/tgt/conf.d/*.conf« Die Verwaltung der Targets bewerkstelligt der Admin mit den Kommandozeilenbefehlen »tgt‑admin« und »tgtadm« zur Laufzeit des TGT-Daemon. Dauerhafte Konfigurationen setzen auch hier auf Änderungen in den Konfigurationsdateien des Daemon, wobei die Verwaltungswerkzeuge diese indirekt erzeugen können. Der Befehl »tgtadm« folgt fast immer dieser Syntax:

tgtadm ‑‑lld iscsi ‑‑op op ‑‑mode mode ...

Mit der Option »‑‑op« wird eine Operation definiert, zur Verfügung stehen: »new«, »delete«, »show«, »bin«, »unbind« und »update«. Um welche Art von Konfigurationsparameter es sich handelt, wird mit der Mode-Option festgelegt. Sie kann die Werte »target«, »logicalunit«, »account« und »sys« annehmen. Eine neues Target wird mit einem Aufruf wie dem folgenden erstellt:

tgtadm ‑‑lld iscsi ‑‑op new ‑‑mode target ‑‑tid=1 ‑‑targetname iqn.2010‑05.de.os‑t:target_tgt

Das Target enthält als LUN 0 immer einen Controller, der bereits durch den vorherigen Befehl automatisch hinzugefügt wurde. Alle weiteren LUNs sollte man daher immer mit einen Wert größer Null versehen. Die aktuellen Target-Konfiguration zeigt der folgende Befehl an:

tgtadm ‑‑lld iscsi ‑‑op show ‑‑mode target

Möchte der Administrator diesem Target eine LUN hinzufügen, dann kann er die folgende Anweisung benutzen:

tgtadm ‑‑lld iscsi ‑‑op new ‑‑mode logicalunit ‑‑tid=1 ‑‑lun=1 ‑‑backing‑store=/storage/storage.tgt

Es gibt praktisch keine Beschränkung für die Anzahl an LUNs pro Target. Es muss lediglich jedes LUN separat hinzugefügt werden. Die IP-Zugriffsberechtigung lässt sich auch beim TGT für jedes Target separat definieren, jedoch erfolgt die Konfiguration innerhalb der TargetDefinition. Die Zugriffsbeschränkung legt ein Aufruf wie

tgtadm ‑‑lld iscsi ‑‑op bind ‑‑mode target ‑‑tid tid ‑I ALL|IP‑Adresse

fest. Anstelle einer einzelnen IP-Adresse kann der Admin auch direkt ein ganzes Netzsegment zum Beispiel »192.168.0.0/24« angegeben. Zum Entfernen einer Beschränkung ersetzt man lediglich »bind« durch »unbind«. Das Werkzeug taugt auch für die Verwaltung der Benutzerberechtigungen. Zunächst legt man die Benutzer an und weist sie anschließend einem Target zu.

tgtadm ‑‑lld iscsi ‑‑op new ‑‑mode account ‑‑user=thorsten ‑‑password=0123456
tgtadm ‑‑lld iscsi ‑‑op bind ‑‑mode account ‑‑tid=1 ‑‑user=thorsten

Listing 1: Target-Konfiguration mit »tgt«

# tgtadm ‑‑lld iscsi ‑‑op show ‑‑mode target
Target 1: iqn.2010‑05de.os‑t:target_tgt
   System information:
       Driver: iscsi
       State: ready
   I_T nexus information:
   LUN information:
       LUN: 0
           Type: controller
           SCSI ID: IET 00010000
           SCSI SN: beaf10
           Size: 0 MB
           Online: Yes
           Removable media: No
           Backing store type: rdwr
           Backing store path: None
       LUN: 1
           Type: disk
           SCSI ID: IET 0010001
           SCSI SN: beaf11
           Size: 1573 MB
           Online: Yes
           Removable media: No
           Backing store type: rdwr
           Backing store path: /storage/storage.tgt
   Account information:
       thorsten
       thorsten (outgoing)
   ACL information:
       10.11.255.55

Der Benutzer ist nun als eingehender Benutzer an das Target gebunden. Will man ihn auch ausgehend an ein Target knüpfen, verwendet man lediglich zusätzlich die Option »‑‑outgoing«. Eine Discovery-Authentifizierung wird vom TGT-Daemon nicht unterstützt. Das Target hat nun eine Konfiguration wie sie Listing 1 zeigt.

Mit diesem Target ist aktuell noch kein Initiator gekoppelt, deshalb ist der Bereich »I_T nexus information« in Listing 1 leer. Nach einem Neustart des »tgt«-Daemon, verschwände dieses Target wieder. Um es dauerhaft anzulegen, kommt eine von zwei unterschiedliche Herangehensweisen in Frage. Der erste Wege besteht darin die aktuelle Konfiguration als Dump auszugeben (Listing 2) und zu speichern. Der TGT-Daemon erwartet die Target-Konfiguration in Form einfacher XMLformatierter Blöcke. Neben »backing‑store«, das für virtuelle Geräte Anwendung findet, ließe sich auch »direct‑store« angeben. Direct-Store definiert ein Mapping auf vorhandene Geräte und das Target Framework übernimmt hierbei die Hardwarevoreinstellung wie zum Beispiel den Gerätehersteller, die Seriennummer und SCSI-IDs. Im Falle eines »backing‑store« lassen sich dagegen Parameter wie die »vendor_id«, »removable«, »device_type« und weitere für jedes Target separat angepassen. Der Adminstrator speichert diesen Dump in eine Konfigurationsdatei und kann anschließend den Daemon neu starten. Um Datenverlusten vorzubeugen, verweigert der Daemon jedoch einen Neustart, solange Sessions aktiv sind.

Listing 2: TGT-Konfiguration dumpen

# tgt‑admin ‑‑dump default‑driver iscsi
<target iqn.2010‑05de.os‑t:target_tgt>
backing‑store /storage/storage.tgt
incominguser thorsten PLEASE_CORRECT_THE_PASSWORD
outgoinguser thorsten PLEASE_CORRECT_THE_PASSWORD
initiator‑address 192.168.0.4
initiator‑address 192.168.0.3
</target>

Statt die Konfiguration zu dumpen und zu speichern, kann man auch die Befehle zum Erstellen des Target in der richtigen Reihenfolge in das lokale Startskript »/etc/rc.local« eintragen, von wo aus sie das System beim Booten ausführt. Der Vorteil dieses zweiten Weges liegt darin, das der Administrator dann ausschließlich über die Kommandozeilenwerkzeuge Targets verwalten kann und keinen Abgleich der Konfigurationen nach Änderungen vornehmen muss. Mit dem Befehl »tgt‑admin« können Targets zur Laufzeit des Daemon deaktiviert oder vollständig gelöscht werden. Die möglichen Optionen zeigt der Kasten tgt‑admin. Dieselben Kommandozeilenwerkzeuge dienen auch der Verwaltung bestehender Sessions. So zeigt der folgende Befehl alle Parameter einer Session:

tgtadm ‑‑lld iscsi ‑‑op show ‑‑mode session ‑‑tid <tid> ‑‑sid 3

Der Administrator kann neben der Target-ID auch die Targetnamen zur Administration ver wenden. Dies ist im Gegensatz zur iSCSI Enterprise Target-Implementierung hier möglich und vereinfacht die Administration mehrerer Targets deutlich.

Mit den Targets sprechen

Das Gegenstück zu den Targets ist der Initiator. Neben reinen Hardware-iSCSI-Lösungen gibt es hier mit Open iSCSI auch einen verbreiteten Software-Initiator. Die Verwaltung und Steuerung der Zugriffe auf die Targets kontrolliert der Administrator mit dem Kommandozeilenbefehl »iscsiadm«. Open iSCSI seinerseits besteht aus einem Daemon und dem bereits erwähnten Kommandozeilenwerkzeug. Die allgemeine Administration des Initiator-Daemons benutzt die Datei »/etc/ iscsi/iscsid.conf«. Der Daemon kontrolliert bestehende Verbindungen zu Targets. Er prüft Verbindungen und übernimmt im Fehlerfalle automatische Reconnects.

»tgt‑admin«

# Zeigt die momentan verbundenen
# Initiatoren für die jeweiligen Targets:
tgt‑admin ‑s.
# Erstellt Targets wie in der Konfigurationsdatei:
tgt‑admin ‑e
# Deaktiviert einzelne oder alle Targets:
tgt‑admin ‑‑offline tid=TID|Targetname|ALL
# Aktiviert einzelne oder alle Targets:
tgt‑admin ‑‑ready tid=TID|Targetname|ALL
# Löscht einzelne oder alle Targets:
tgt‑admin ‑‑delete tid=TID|Targetname|ALL
# Aktualisiert einzelne oder alle Targets, wenn Anpassungen in der
# Konfiguration vorgenommen wurden:
tgt‑admin ‑‑update tid=TID|Targetname|ALL
# Gibt eine vollständige Konfiguration
# für alle Targets im XML‑Format aus:
tgt‑admin ‑‑dump

Bevor der Administrator mit der Einrichtung von Verbindungen zu Targets beginnt, sollte er für jeden Initiator in der Konfigurationsdatei »/etc/iscsi/initiatorname.iscsi« eine weltweit einmalige IQN vergeben. Erst nach diesem Schritt empfiehlt sich ein Start des zugehörigen Daemon, der dann mit der Verwaltung der iSCSITargets beginnt. Die verbreiteten Distributionen legen von sich aus einen IQN für den Client an. Wird jedoch eine bestimmte Namenskonvention im Unternehmen vorausgesetzt, sollte man ihn vor weiteren administrativen Schritten zunächst anpassen. Wo das keine Rolle spielt, lässt sich genauso gut die automatisch generierte IQN verwenden.

Damit der Daemon nach dem Booten wahlweise automatisch oder manuell auf iSCSI-Targets zugreifen kann gilt es, die Konfiguration anzupassen. In der Datei »/etc/iscsi/iscsid.conf« wird zunächst der automatische Start des Daemon eingeschaltet. Der Administrator muss hierfür den Wert des Parameter »node.startup« auf »manual« oder »automatic« setzen. Auch die Konfiguration für die Default-Authentifizierung wird hier zentral geregelt, ist jedoch für jedes Target einzeln anpassbar. Vor allem die Einstellungen für ein Discovery – zum Finden von Targets eines Portals – sollte man hier konfigurieren. Dies kann der Administrator anhand der gut dokumentierten Standardkonfiguration im Abschnitt CHAP-Settings einfach an das vorhandene SAN anpassen. Anschließend wird mit dem Aufruf

iscsiadm ‑m discovery ‑t st ‑p portal‑ip

das Portal nach Targets durchsucht. Jedes Target landet beim ersten Finden als eigenständiger Node im Unterverzeichnis »nodes«. Der Administrator sollte nach einer individuellen Anpassungen des Target kein Discovery mehr durchführen, weil dadurch Anpassungen verloren gehen könnten. Die Optionen zur Abfrage alle gesetzten Parameter für ein Target listet der Kasten »iscsiadm« auf. Das Ändern des Benutzernamens erledigt der Aufruf:

iscsiadm ‑m node ‑T iqn.2010‑05.de.os‑t:target_tgt ‑o update ‑n node.session.auth.username ‑v torsten

»iscsiadm«

# Gibt alle bekannten Targets aus:
iscsiadm ‑‑mode node
# Gibt alle aktiven Sessions aus:
iscsiadm ‑‑mode session
# Zeigt alle Parameter für ein
Speichergerät an:
iscsiadm ‑‑mode node ‑‑targetname iqn.2010‑05.de.os‑t:storage
# Ausführliche Ansicht aller aktiven
Sessions:
iscsiadm ‑‑mode session ‑P 1|2|3|4

Auf dieselbe Weise lassen sich auch andere Parameter entsprechend anpassen. Der Administrator gibt dabei wie im Beispiel mit der Option »‑n« den Parameter an, den er ändern möchte und mit der Option »‑v« den neuen Wert. Die Änderungen landen dann direkt in der entsprechenden Konfiguration für das Target. Damit der Anwender iSCSI-Targets verwenden kann ist eine Authentifizierung erforderlich. Das Ein- und Ausloggen geschieht dabei mit dem Befehl:

iscsiadm ‑‑mode node ‑‑targetname iqn.2010‑05de.os‑t:storage ‑login|‑logout

Wenn iSCSI nicht nur reale SCSI-Geräte sondern auch virtuelle Geräte oder Dateien als SCSI-Geräte zur Verfügung stellt, kann es auf Seite des Initiators zu dem Problem einer fehlenden Partitionstabelle kommen. Ein Aufruf von »fdisk ‑l« bei einem solchen virtuellen Gerät hat meist zur Folge, dass das System eine fehlende Partitionstabelle bemängelt. Trotzdem ist es aber möglich, das iSCSI-Target in den Verzeichnisbaum einzubinden und darauf Daten zu speichern. Eine einmalige Formatierung des Speichergerätes ist dennoch erforderlich. Üblicherweise initiiert sie der Anwender auf dem Client. Open iSCSI ist prinzipiell auch in der Lage, seine Targets hochverfügbar und redundant mittels Multipathing anzubinden. Die Administration dieses HA-Features wird ausführlich in der Dokumentation von Open iSCSI ausführlich erläutert [4]. Weitere hilfreiche Informationen findet die Administratorin mit »lsscsi« und »sg_map«. Die Ansicht aller SCSI-Geräte liefert »lsscsi«

[0:0:0:0] disk ATA WDC  WD1600AAJS‑6 58.0 /dev/sda
[2:0:0:0] cd/dvd HL‑DT‑ST DVD‑RAM GSA‑H60L R90C /dev/sr0
[4:0:0:0] storage IET Controller 0001 -
[4:0:0:1] disk IET VIRTUAL‑DISK 0001 /dev/sdb

Sg_map hingegen stellt die Informationen des internen Mappings von Controllern und Speichergeräten zur Verfügung.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019