Adressen und Authentifizierung

Target und Initiators tragen einen weltweit einmaligen Namen, den so genannten iSCSI Qualified Name (IQN). Er beginnt mit der Bezeichnung »iqn« gefolgt von einem Punkt und der Angabe eines Datums in der Form yyyy-mm, wie es der iSCSI-RFC 3720 vorschreibt. Als Datum kommt der erste Monat nach Nutzungsbeginn der Netzwerk-Domain zum Zug. Daran schließt sich – ebenfalls durch einen Punkt getrennt – die rückwärts notierte Domain an. Anschließend wird durch einen Doppelpunkt ein optionaler Teil separiert. Dieser optionale Teil dient der einfacheren Organisation und Verwaltung von iSCSI-SANs. Diese Regeln ergeben beispielsweise einen IQN wie:

Iqn.2010‑05.de.os‑t:storage_isos

Auch bei den Initiators wird der optionale Teil für eine eindeutige Benennung verwendet. Die IQN der Initiators lassen sich in Access Control Lists (ACL) zur Steuerung der Zugriffsberechtigung verwenden, schon aus diesem Grund sollten sie eindeutig, einmalig und dauerhaft sein. Daher sollte der IQN auch keine IP-Adressen oder NIC-Zuordnungen enthalten, denn die könnten sich im Laufe der Zeit ändern. Target und Initiator sind in der Lage, sich via CHAP-Protokoll gegenseitig zu authentifizieren. CHAP kann die Passwörter durch Hashing verschleiern.

Abbildung 1: iSCSI verpackt SCSI-Kommandos für Speichersysteme in TCPSegmente innerhalb von IP-Datagrammen.

Für die Authentifizierung gibt es unterschiedliche Szenarien: Zum einen kann sie einem Discovery vorangehen, also der Suche nach Targets auf einem System, zum anderen dient sie der wechselseitigen Authentifizierung von Target und Initiator beim Aufbau einer Verbindung. iSCSI nutzt den Port 3260. Über diesen Port kommunizieren die Initiators mit den Targets. Dieser Socket des iSCSI-Servers wird in der iSCSI-Terminologie auch als Portal bezeichnet. Jedes Portal kann mehrere Targets zur Verfügung stellen. Softwareseitig werden derzeit im wesentlichen zwei Implementierungen für iSCSI-Targets für Linux eingesetzt: Zum einen die iSCSI Enterprise Target-Implementierung (IET) [2] und als Alternative das SCSI Target Framework (TGT) [3]. Es gibt zwar weitere Target-Implementierungen, jedoch sind dafür keine Pakete in großen Distributionen vorhanden.

iSCSI Enterprise Target

Das iSCSI Enterprise Target (IET) ist die am häufigsten anzutreffende Target-Version. Die Installation von IET gestaltet sich etwa unter Debian Lenny sehr einfach. Der Systembetreuer installiert lediglich die Pakete »iscsitarget« und »iscsitarget‑modules« für die verwendete Kernelversion.

iSCSI-Begriffe

  • HBA: Der Host Bus Adpater ist eine Hardwareschnittstelle, die die Rolleeines Initiator/Target hardwareseitig realisieren kann.
  • LUN: Logical Unit Number. Eine LUN definiert ein SCSI-Zugriffsobjekt, beispielsweise ein CD-Laufwerk. Ein LUN ist ein Blockdevice mit der typischen Bezeichnung »/dev/sdX«
  • CHAP: Das Challenge Handshake Authentication Protocol schützt Passwörter mittels Einweg-Hashfunktionen bei der Übertragung schützt.
  • SAN: Storage Area Network. Ein SAN stellt Speichergeräte über Netzwerke zur Verfügung.
  • IQN: iSCSI Qualified Name. Standard zur Benennung von Targets und Initiator.
  • Initiator: iSCSI-Komponente, die eine Verbindung zu einem iSCSI-Speicher aufbaut und konkrete SCSI-Kommandos absetzt. Der Initiator fungiert als Client.
  • Target: iSCSI-Target nimmt SCSI-Commands über TCP/IP entgegen und führt sie aus. Das Target ist das Gegenstück zum Initiator.
  • Portal: Auf Ebene eines Betriebssystem würde von Socket gesprochen, in der iSCSI-Welt ist der Netzwerksocket ein Portal. Ein Portal besteht aus IP-Adresse und einem Port – Default-Port ist 3260. Jedes Portal kann mehrere Targets anbieten.
  • NIC: Network Interface Controller. Dient der Herstellung einer physischen Verbindung zu einem Netzwerk. Meist handelt es sich um eine Ethernet-Karte.

Sie enthalten sowohl Userspace-Werkzeuge als auch Kerneltreiber. In anderen Distributionen gibt es entsprechende Pakete. IET basiert auf der Ardis iSCSI-Implementierung und benötigt wenigstens einen Kernel der Version 2.6.14. Sollte für den laufenden Kernel kein passendes Modul im Repository enthalten sein, installiert und kompiliert der Anwender die Sourcen aus dem Paket »iscsitarget‑modules‑source«. Danach kann er mit mit der Konfiguration der Targets beginnen. Unter Lenny setzt der Admin hier zunächst in der Datei »/etc/default/iscsitarget« die Variable »ISCSITARGET_ENABLE=true«. Andernfalls startet der zugehörige Daemon nicht. Für einen ersten Test genügt eine Datei als virtuelle Festplatte. Der folgenden Befehl erstellt eine solche Datei mit 1,5 GByte Größe.

mkdir /storage
dd if=/dev/zero of=/storage/iet_storage bs=1024k count=1500

Neben der einzelnen Datei wären auch ganze Festplatten, Partitionen, aber auch RAID-Volumes als Target verwendbar. Nachdem die Datei angelegt ist, kann man den IET-Daemon in der Datei »/etc/ietd.conf« konfigurieren. Neben der Definition aller Targets für ein gesamtes Portal legt der Admin dort auch globale Einstellungen fest. Eine Minimalkonfiguration besteht in der Definition eines entsprechenden Targets mit zugeordneter Logical Unit Number (LUN):

Target iqn.2010‑05.de.os‑t:storage.iet Lun 0 Path=/storage/ietstorage,Type=fileio

Als Typ ist hier neben dem Defaultwert »fileio« auch die Angabe »blockio« verwendbar. Der Typ »fileio« ist dabei sowohl für normale Blockdevices wie Partitionen oder ganze Festplatten, als auch für virtuelle Geräte wie RAIDs oder LVM und normale Dateien wie im Beispiel einsetzbar. Anwendungen, die einen direkten Zugriff auf die Speichergeräte benötigen, sollten im Untersdchied dazu ausschließlich den »blockio«Mode benutzen. Eine Authentifizierung für das gesamte Portal erfolgt im globalen Abschnitt der Konfigurationsdatei. Ein Discovery, das ermittelt, ob und welche Blockgeräte ein Portal exportiert, lässt sich so auf bestimmte Benutzer eingeschränken. Der Administrator definiert die erlaubten Benutzer mit zwei Parametern:

IncomingUser <username> <password>
OutgoingUser <username> <password>

Zusätzlich kann der Systemverwalter IP-basierte Zugriffsberechtigungen in den Dateien »/etc/initiators.allow« und »/etc/initiators.deny« festlegen. Generell ist zu empfehlen, die Einschränkungen entweder als White- oder Blacklists zu verwalten. Im folgenden Falle werden alle Zugriffe mit einer speziellen Ausnahme verweigert. Dafür enthält die Datei »/etc/initiators.deny« den Eintrag »ALL ALL« und im File »/etc/initiators.allow« findet man

iqn.2010‑05.de.os‑t:storage.iet 10.211.55.5

Nach einem Neustart des iSCSI-Target-Daemon fungiert dieser Rechner als Portal. Dieses Portal wiederum stellt ein Target zur Verfügung, das nur durch den Client mit der IP-Adresse 10.211.55.5 ansprechbar ist. Änderungen in der Konfigurationsdatei erfordern einen Neustart des Daemon. Um zur Laufzeit Änderungen vorzunehmen, nutzt der Admin als Verwaltungswerkzeug für das iSCSIEnterprise-Target den Kommandozeilenbefehl »ietadm«.

Mit diesem Befehl legt der Betreuer zur Laufzeit Targets neu an und löscht vorhandene. Auch kann er einzelne Parameter so im laufenden Betrieb möglich festlegen oder ändern. Für die persistente Speicherung muss er diese Einstellungen aber dennoch in die Konfigurationsdatei eintragen. Kasten »ietadm« zeigt die wesentlichen Optionen für die Verwaltung von Targets und Parametern.

»ietadm«

# Neues Target mit der Target‑ID tid und einer
Target‑Bezeichnung anlegen:
ietadm ‑‑op new ‑‑tid tid ‑‑parmas Name=iqn.2010‑05.de.os‑t:target
# Hinzufügen einer LUN 0 zum Target mit der ID tid:
ietadm ‑‑op new ‑‑tid tid ‑‑lun 0 ‑‑params Path=/storage/target2
# Löschen der LUN 1:
ietadm ‑‑op delete ‑‑tid tid ‑‑lun 1
# Anzeige aller konfigurierten Parameter für das Target tid:
ietadm ‑‑op show ‑‑tid tid ‑‑sid 0
# Anzeige aller Parameter für eine konkrete Session.
# SessionIDs sind zu finden
# in /proc/net/iet/session:
ietadm ‑‑op show ‑‑tid tid ‑‑sid <sessionid>
# Manuelles Beenden einer Session:
ietadm ‑‑op delete ‑‑tid tid ‑‑sid <sessionid> ‑‑cid <connectionid>
# Modifizierung einzelner Parameter für ein Target:
ietadm ‑‑op update ‑‑tid tid ‑‑params key1=value
# Anlegen eines neuen [user], welcher durch IncomingUser, OutgoingUser
# spezifiziert wird, für ein Target. Wird keine Target‑ID angeben, wird ein neues
# Benutzerkonto für Discovery‑Sitzungen angelegt:
ietadm ‑‑op new ‑‑tid tid ‑‑user ‑‑params=[user]=[name],Password=[pass]
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