6 Installation des iSCSI Gateways #
  iSCSI ist ein Storage Area Network (SAN)-Protokoll, das Clients (genannt
  Initiators) das Senden von SCSI-Kommandos an
  SCSI-Speichergeräte (Targets) auf Remote Servern
  ermöglicht. SUSE Enterprise Storage 7 umfasst eine Funktion, die die
  Ceph-Speicherverwaltung für heterogene Clients wie Microsoft Windows* und
  VMware* vSphere über das iSCSI-Protokoll öffnet. Multipath iSCSI-Zugriff
  ermöglicht die Verfügbarkeit und Skalierbarkeit für diese Clients. Das
  standardisierte iSCSI-Protokoll stellt außerdem eine zusätzliche Ebene der
  Sicherheitsisolation zwischen Clients und dem SUSE Enterprise
  Storage 7-Cluster zur Verfügung. Die Konfigurationsfunktion wird
  ceph-iscsi genannt. Über
  ceph-iscsi definieren
  Ceph-Speicheradministratoren für schlanke Speicherzuweisung geeignete,
  reproduzierte, hochverfügbare Volumes, die schreibgeschützte Snapshots,
  Lesen-Schreiben-Klone und eine automatische Anpassung der Größe über Ceph
  RADOS Block Device(RBD) unterstützen. Administratoren können dann Volumes
  entweder über einen einzelnen
  ceph-iscsi Gateway Host oder über
  mehrere Gateway Hosts exportieren, die Multipath Failover unterstützen.
  Linux, Microsoft Windows und VMware Hosts stellen über das iSCSI-Protokoll
  eine Verbindung zu den Volumes her. Dadurch werden sie verfügbar wie jedes
  andere SCSI-Blockgerät. Dies bedeutet, dass Kunden von SUSE Enterprise
  Storage 7 auf Ceph effizient ein vollständiges
  Blockspeicher-Infrastruktur-Teilsystem ausführen können, das alle Funktionen
  und Vorteile eines konventionellen SAN bietet und zukünftiges Wachstum
  ermöglicht.
 
In diesem Kapitel erhalten Sie detaillierte Informationen zum Einrichten einer Ceph-Cluster-Infrastruktur mit einem iSCSI Gateway, sodass die Client-Hosts über das iSCSI-Protokoll dezentral gespeicherte Daten als lokale Speichergeräte verwenden können.
6.1 iSCSI-Blockspeicher #
iSCSI ist eine Implementierung des Small Computer System Interface (SCSI)-Kommandos, das mit dem in RFC 3720 angegebenen Internet Protocol (IP) festgelegt wird. iSCSI ist als Service implementiert, in dem ein Client (der Initiator) über eine Sitzung auf TCP-Port 3260 mit einem Server (dem Target) kommuniziert. Die IP-Adresse und der Port eines iSCSI-Ziels werden als iSCSI Portal bezeichnet, wobei ein Ziel über einen oder mehrere Portale sichtbar gemacht werden kann. Die Kombination aus einem Ziel und einem oder mehreren Portalen wird als Zielportalgruppe (Target Portal Group, TPG) bezeichnet.
Das zugrunde liegende Daten-Link-Schicht-Protokoll für iSCSI ist meistens Ethernet. Genauer gesagt, moderne iSCSI-Infrastrukturen verwenden 10 GigE-Ethernet oder schnellere Netzwerke für optimalen Durchsatz. 10 Gigabit Ethernet-Konnektivität zwischen dem iSCSI Gateway und dem Back-End Ceph-Cluster wird dringend empfohlen.
6.1.1 iSCSI-Ziel des Linux-Kernels #
    Das iSCSI-Ziel des Linux-Kernels wurde ursprünglich LIO genannt. Es steht
    für linux-iscsi.org, die ursprüngliche Domäne und
    Website des Projekts. Einige Zeit standen für die Linux-Plattform nicht
    weniger als vier konkurrierende Target-Implementierungen zur Verfügung,
    doch LIO hat sich schließlich als einziges iSCSI-Referenz-Target
    durchgesetzt. Der hauptsächliche Kernel-Code für LIO verwendet den
    einfachen, doch in gewisser Weise zweideutigen Namen „Target“ und
    unterscheidet dabei zwischen „Target Core“ und einer Vielzahl an Frontend-
    und Back-End Target-Modulen.
   
Das am häufigsten verwendete Frontend-Modul ist wohl iSCSI. LIO unterstützt jedoch auch Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) und verschiedene andere Frontend-Protokolle. Zum gegenwärtigen Zeitpunkt unterstützt SUSE Enterprise Storage nur das iSCSI-Protokoll.
Das am häufigsten verwendete Target Back-End-Modul kann einfach jedes verfügbare Blockgerät am Target-Host neu exportieren. Dieses Modul wird iblock genannt. LIO verfügt jedoch auch über ein RBD-spezifisches Back-End-Modul. Es unterstützt den parallelisierten Multipath-E/A-Zugriff auf RBD-Images.
6.1.2 iSCSI Initiatoren #
In diesem Abschnitt erhalten Sie einen kurzen Überblick über die iSCSI Initiator, die auf Linux-, Microsoft Windows und VMware-Plattformen verwendet werden.
6.1.2.1 Linux #
     Der Standard-Initiator für die Linux-Plattform ist
     open-iscsi. open-iscsi
     ruft einen Daemon auf (iscsid), den Benutzer zum
     Ermitteln von iSCSI Targets auf jedem vorhandenen Portal, zum Anmelden bei
     Targets und zum Zuordnen von iSCSI Volumes verwenden können.
     iscsid kommuniziert mit der mittleren
     SCSI-Schicht, um Kernel-interne Blockgeräte zu erstellen, die der Kernel
     dann wie jedes andere SCSI-Blockgerät im System behandeln kann. Der
     open-iscsi Initiator kann zusammen mit der
     Funktion Device Mapper Multipath (dm-multipath)
     bereitgestellt werden, um ein hochverfügbares iSCSI-Blockgerät zur
     Verfügung zu stellen.
    
6.1.2.2 Microsoft Windows und Hyper-V #
Der standardmäßige iSCSI Initiator für das Microsoft Windows Betriebssystem ist der Microsoft iSCSI Initiator. Der iSCSI-Service kann über die grafische Bedienoberfläche (GUI) konfiguriert werden und unterstützt Multipath E/A für Hochverfügbarkeit.
6.1.2.3 VMware #
     Der standardmäßige iSCSI Initiator für VMware vSphere und ESX ist der
     VMware ESX Software iSCSI Initiator, vmkiscsi.
     Wenn er aktiviert ist, kann er entweder vom vSphere Client oder mit dem
     Kommando vmkiscsi-tool konfiguriert werden. Sie können
     dann Speicher-Volumes formatieren, die über den vSphere iSCSI
     Speicheradapter mit VMFS verbunden sind, und diese wie jedes andere
     VM-Speichergerät verwenden. Der VMware Initiator unterstützt auch
     Multipath E/A für Hochverfügbarkeit.
    
6.2 Allgemeine Informationen zu ceph-iscsi #
   ceph-iscsi vereint die Vorteile von
   RADOS Block Devices mit der universellen Vielseitigkeit von iSCSI. Durch
   Anwenden von ceph-iscsi auf einem
   iSCSI-Zielhost (als iSCSI Gateway bezeichnet) kann jede Anwendung, die die
   Blockspeicherung nutzen muss, von Ceph profitieren, auch wenn sie kein
   Ceph-Client-Protokoll kennt. Stattdessen können Benutzer iSCSI oder ein
   beliebiges anderes Target Frontend-Protokoll verwenden, um eine Verbindung
   zu einem LIO Target herzustellen, das alle Target E/A in
   RBD-Speicheroperationen überträgt.
  
   ceph-iscsi ist von Natur aus
   hochverfügbar und unterstützt Multipath-Operationen. Somit können Downstream
   Initiator Hosts mehrere iSCSI Gateways für Hochverfügbarkeit sowie
   Skalierbarkeit verwenden. Bei der Kommunikation mit einer
   iSCSI-Konfiguration mit mehr als einem Gateway sorgen Initiator
   möglicherweise für eine Lastausgleich von iSCSI-Anforderungen über mehrere
   Gateways hinweg. Falls ein Gateway ausfällt und zeitweise nicht erreichbar
   ist oder zu Wartungszwecken deaktiviert wird, werden E/A-Operationen
   transparent über ein anderes Gateway weiter ausgeführt.
  
6.3 Überlegungen zur Bereitstellung #
   Eine Mindestkonfiguration von SUSE Enterprise Storage 7 mit
   ceph-iscsi setzt sich aus folgenden
   Komponenten zusammen:
  
Einem Ceph Storage Cluster Der Ceph-Cluster besteht aus mindestens vier physischen Servern, auf denen jeweils mindestens acht Objektspeicher-Daemons (OSDs) gehostet werden. In einer derartigen Konfiguration fungieren drei OSD-Knoten auch als Monitor(MON)-Host.
Ein iSCSI-Zielserver, auf dem das LIO-iSCSI-Ziel ausgeführt wird und das über
ceph-iscsikonfiguriert wurde.Einem iSCSI-Initiator-Host, auf dem
open-iscsi(Linux), der Microsoft iSCSI Initiator (Microsoft Windows) oder eine beliebige andere iSCSI-Initiator-Implementierung ausgeführt wird.
   Eine empfohlene Produktionskonfiguration von SUSE Enterprise Storage 7 mit
   ceph-iscsi besteht aus:
  
Einem Ceph Storage Cluster Ein Ceph-Cluster für die Produktionsumgebung besteht aus einer beliebigen Anzahl (normalerweise mehr als 10) von OSD-Knoten. Auf jedem werden normalerweise 10 bis 12 Objektspeicher-Daemons (OSDs) ausgeführt, mit mindestens drei dedizierten MON-Hosts.
Einige iSCSI-Zielserver, auf denen das LIO-iSCSI-Ziel ausgeführt wird und die über
ceph-iscsikonfiguriert wurden. Zum Zweck von iSCSI-Failover und -Lastausgleich müssen diese Server einen Kernel ausführen, der dastarget_core_rbd-Modul unterstützt. Update-Pakete sind im SUSE Linux Enterprise Server-Wartungskanal verfügbar.Eine beliebige Anzahl von iSCSI-Initiator-Hosts, auf denen
open-iscsi(Linux), der Microsoft iSCSI Initiator (Microsoft Windows) oder eine beliebige andere iSCSI-Initiator-Implementierung ausgeführt wird.
6.4 Installation und Konfiguration #
In diesem Abschnitt werden die Schritte zum Installieren und Konfigurieren eines iSCSI Gateways zusätzlich zu SUSE Enterprise Storage beschrieben.
6.4.1 Bereitstellen des iSCSI Gateways auf einem Ceph-Cluster #
Die Bereitstellung des Ceph iSCSI Gateways erfolgt nach dem gleichen Verfahren wie die Bereitstellung anderer Ceph-Services, nämlich mit cephadm. Weitere Informationen finden Sie unter Abschnitt 5.4.3.5, „Bereitstellen von iSCSI-Gateways“.
6.4.2 Erstellen von RBD-Images #
    RBD-Images werden im Ceph Store erstellt und anschließend zu iSCSI
    exportiert. Wir empfehlen zu diesem Zweck einen dedizierten RADOS-Pool. Sie
    können mit dem Ceph rbd-Kommandozeilenprogramm ein
    Volume von jedem Host aus erstellen, der eine Verbindung zu Ihrem
    Speicher-Cluster herstellen kann. Dazu benötigt der Client mindestens eine
    ceph.conf-Datei mit Mindestkonfiguration und den
    entsprechenden CephX-Berechtigungsnachweis zur Authentifizierung.
   
    Erstellen Sie ein neues Volume für den späteren Export über iSCSI mit dem
    Kommando rbd create und geben Sie die Volume-Größe in
    Megabyte an. Beispiel: Führen Sie zum Erstellen eines Volumes mit 100 GB
    und der Bezeichnung testvol im Pool
    iscsi-images folgendes Kommando aus:
   
cephuser@adm > rbd --pool iscsi-images create --size=102400 testvol6.4.3 Exportieren von RBD-Images über iSCSI #
    Zum Exportieren von RBD-Images über iSCSI stehen zwei Möglichkeiten zur
    Auswahl: die Ceph-Dashboard-Weboberfläche oder das
    ceph-iscsi-Dienstprogramm „gwcli“.
    Dieser Abschnitt befasst sich ausschließlich mit „gwcli“, wobei erläutert
    wird, wie Sie ein iSCSI-Ziel erstellen, mit dem ein RBD-Image über die
    Kommandozeile exportiert wird.
   
RBD-Images mit den folgenden Eigenschaften können nicht über iSCSI exportiert werden:
Images mit aktivierter
Journaling-FunktionImages mit einer
Stripe-Einheitvon weniger als 4096 Byte
    Geben Sie den iSCSI-Gateway-Container als
    root ein:
   
root # cephadm enter --name CONTAINER_NAME
    Starten Sie die Kommandozeilenschnittstelle für das iSCSI Gateway als
    root:
   
root # gwcli
    Wechseln Sie zu iSCSI-Ziele und erstellen Sie ein Ziel
    namens
    iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol:
   
gwcli >/> cd /iscsi-targetsgwcli >/iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol
    Erstellen Sie die iSCSI-Gateways. Geben Sie hierzu den Namen
    (name) und die IP-Adresse (ip) des
    Gateways an:
   
gwcli >/iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/gatewaysgwcli >/iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli >/iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
     Mit dem Kommando help rufen sie eine Liste der
     verfügbaren Kommandos im aktuellen Konfigurationsknoten ab.
    
    Nehmen Sie das RBD-Image namens testvol in den Pool
    iscsi-images auf:
   
gwcli >/iscsi-target...tvol/gateways> cd /disksgwcli >/disks> attach iscsi-images/testvol
Ordnen Sie das RBD-Image dem Ziel zu:
gwcli >/disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/disksgwcli >/iscsi-target...testvol/disks> add iscsi-images/testvol
     Sie können die lokale Konfiguration mit systemnahen Werkzeugen wie
     targetcli abfragen, jedoch nicht bearbeiten.
    
     Mit dem Kommando ls können sie die Konfiguration
     prüfen. Einige Konfigurationsknoten unterstützen auch das Kommando
     info, mit dem Sie ausführlichere Informationen
     erhalten.
    
Es ist zu beachten, dass die ACL-Authentifizierung standardmäßig aktiviert ist, weshalb der Zugriff auf dieses Ziel noch nicht möglich ist. Weitere Informationen zur Authentifizierung und zur Zugriffssteuerung finden Sie in Abschnitt 6.4.4, „Authentifizierung und Zugriffssteuerung“.
6.4.4 Authentifizierung und Zugriffssteuerung #
Die iSCSI-Authentifizierung ist flexibel und deckt zahlreiche Authentifizierungsmöglichkeiten ab.
6.4.4.1 Deaktivieren der ACL-Authentifizierung #
Keine Authentifizierung bedeutet, dass jeder Initiator·auf alle LUNs·im entsprechenden Ziel zugreifen kann.· Sie können Keine Authentifizierung aktivieren, indem Sie die ACL-Authentifizierung deaktivieren:
gwcli >/> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hostsgwcli >/iscsi-target...testvol/hosts> auth disable_acl
6.4.4.2 Verwenden der ACL-Authentifizierung #
Bei der ACL-Authentifizierung anhand des Initiatornamens dürfen lediglich die definierten Initiatoren eine Verbindung herstellen. So definieren Sie einen Initiator:
gwcli >/> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hostsgwcli >/iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20
Definierte Initiatoren können eine Verbindung herstellen, erhalten den Zugriff jedoch nur auf die RBD-Images, die dem Initiator explizit hinzugefügt wurden:
gwcli >  /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol6.4.4.3 Aktivieren der CHAP-Authentifizierung #
Neben der ACL-Authentifizierung können Sie die CHAP-Authentifizierung aktivieren. Geben Sie hierzu einen Benutzernamen und ein Passwort für die einzelnen Initiatoren an:
gwcli >/> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20gwcli >/iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
      Die Benutzernamen müssen 8 bis 64 Zeichen lang sein und dürfen
      alphanumerische Zeichen enthalten, .,
      @, -, _ oder
      :.
     
      Die Passwörter müssen 12 bis 16 Zeichen lang sein und dürfen
      alphanumerische Zeichen enthalten, , @,
      -, _ oder /.
     
     Optional können Sie außerdem die gegenseitige CHAP-Authentifizierung
     aktivieren. Geben Sie hierzu die Parameter
     mutual_username und mutual_password im
     Kommando auth an.
    
6.4.4.4 Konfigurieren der Ermittlungsauthentifizierung und der gegenseitigen Authentifizierung #
Die Ermittlungsauthentifizierung ist unabhängig von den obigen Authentifizierungsverfahren. Es ist ein Berechtigungsnachweis für die Suche erforderlich, die Suche ist optional und sie wird wie folgt konfiguriert:
gwcli >/> cd /iscsi-targetsgwcli >/iscsi-targets> discovery_auth username=du123456 password=dp1234567890
      Die Benutzernamen müssen 8 bis 64 Zeichen lang sein und dürfen nur
      Buchstaben enthalten, ., @,
      -, _ oder :.
     
      Die Passwörter müssen 12 bis 16 Zeichen lang sein und dürfen nur
      Buchstaben enthalten, @, -,
      _ oder /.
     
     Optional können Sie auch die Parameter mutual_username
     und mutual_password im Kommando
     discovery_auth angeben.
    
Die Ermittlungsauthentifizierung wird mit folgendem Kommando deaktiviert:
gwcli >  /iscsi-targets> discovery_auth nochap6.4.5 Konfigurieren von erweiterten Einstellungen #
    ceph-iscsi kann mit erweiterten
    Parametern konfiguriert werden, die anschließend an das LIO-E/A-Ziel
    übergeben werden. Die Parameter sind in Ziel- und
    Datenträger-Parameter aufgeteilt.
   
Soweit nicht anders angegeben, ist es nicht zu empfehlen, die Standardeinstellung dieser Parameter zu ändern.
6.4.5.1 Anzeigen der Zieleinstellungen #
     Mit dem Kommando info rufen Sie den Wert dieser
     Einstellungen ab:
    
gwcli >/> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.SYSTEM-ARCH:testvolgwcli >/iscsi-target...i.SYSTEM-ARCH:testvol> info
     Mit dem Kommando reconfigure ändern Sie eine
     Einstellung:
    
gwcli >  /iscsi-target...i.SYSTEM-ARCH:testvol> reconfigure login_timeout 20
     Die folgenden Ziel-Einstellungen stehen zur Auswahl:
    
- default_cmdsn_depth
 Standardmäßige CmdSN (Command Sequence Number)-Tiefe. Beschränkt die Anzahl der Anforderungen, die für einen iSCSI Initiator zu einem beliebigen Zeitpunkt ausstehend sein können.
- default_erl
 Standardmäßige Fehlerwiederherstellungsstufe.
- login_timeout
 Wert der Zeitüberschreitung bei der Anmeldung in Sekunden.
- netif_timeout
 NIC-Fehler-Zeitüberschreitung in Sekunden.
- prod_mode_write_protect
 Wert
1verhindert das Schreiben in LUNs.
6.4.5.2 Anzeigen der Datenträgereinstellungen #
     Mit dem Kommando info rufen Sie den Wert dieser
     Einstellungen ab:
    
gwcli >/> cd /disks/rbd/testvolgwcli >/disks/rbd/testvol> info
     Mit dem Kommando reconfigure ändern Sie eine
     Einstellung:
    
gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0
     Die folgenden Datenträger-Einstellungen stehen zur
     Auswahl:
    
- block_size
 Blockgröße des zugrundeliegenden Geräts.
- emulate_3pc
 Wert
1aktiviert das Drittanbieterexemplar.- emulate_caw
 Wert
1aktiviert „Vergleichen“ und „Schreiben“.- emulate_dpo
 Wert 1 schaltet „Disable Page Out“ ein.
- emulate_fua_read
 Wert
1aktiviert das Lesen von „Force Unit Access“ (Zugriff auf Einheit erzwingen).- emulate_fua_write
 Wert
1aktiviert das Schreiben von „Force Unit Access“ (Zugriff auf Einheit erzwingen).- emulate_model_alias
 Wert
1verwendet den Back-End-Gerätenamen für den Modell-Alias.- emulate_pr
 Beim Wert 0 ist die Unterstützung für SCSI-Reservierungen (auch permanente Gruppenreservierungen) deaktiviert. Ist diese Option deaktiviert, kann das iSCSI Gateway den Reservierungsstatus ignorieren, sodass die Anforderungslatenz verbessert wird.
TippWenn die iSCSI-Initiatoren keine Unterstützung für die SCSI-Reservierung benötigen, wird empfohlen, den Wert
0fürbackstore_emulate_prfestzulegen.- emulate_rest_reord
 Bei Wert
0weist der Queue Algorithm Modifier (Warteschlangenalgorithmus-Modifizierer) die Option „Restricted Reordering“ auf.- emulate_tas
 Wert
1aktiviert „Task Aborted Status“.- emulate_tpu
 Wert
1aktiviert „Thin Provisioning Unmap“.- emulate_tpws
 Wert
1aktiviert „Thin Provisioning Write Same“.- emulate_ua_intlck_ctrl
 Wert
1aktiviert „Unit Attention Interlock“.- emulate_write_cache
 Wert
1schaltet „Write Cache Enable“ ein.- enforce_pr_isids
 Wert
1erzwingt ISIDs für permanente Reservierungen.- is_nonrot
 Bei Wert
1ist der Backstore ein sich nicht drehendes Gerät.- max_unmap_block_desc_count
 Maximale Anzahl der Blockbeschreibungen für UNMAP.
- max_unmap_lba_count:
 Maximale Anzahl der LBAs für UNMAP.
- max_write_same_len
 Maximale Länge für WRITE_SAME.
- optimal_sectors
 Optimale Anforderungsgröße in Sektoren.
- pi_prot_type
 DIF-Schutz-Typ.
- queue_depth
 Warteschlangentiefe.
- unmap_granularity
 UNMAP-Granularität.
- unmap_granularity_alignment
 Abstimmung der UNMAP-Granularität.
- force_pr_aptpl
 Ist diese Option aktiviert, schreibt LIO stets den Status der permanenten Reservierung in den permanenten Speicher, unabhängig davon, ob der Client diesen Status mit
aptpl=1angefordert hat. Dies wirkt sich nicht auf das Kernel-RBD-Back-End für LIO aus – hier wird der PR-Status in jedem Fall beibehalten. Im Idealfall sollte die Optiontarget_core_rbdden Wert „1“ erzwingen und einen Fehler auslösen, wenn ein Benutzer versucht, die Option über die Konfiguration zu deaktivieren.- unmap_zeroes_data
 Diese Option gibt an, ob LIO den SCSI-Initiatoren gegenüber LBPRZ bekannt gibt, also dass Nullen aus einem Bereich nach UNMAP oder WRITE SAME mit einem Bit zum Aufheben der Zuordnung gelesen werden.
6.5 Exportieren von RADOS-Blockgeräte-Images mit tcmu-runner #
   ceph-iscsi unterstützt sowohl den
   Backstore rbd (kernelbasiert) als auch den Backstore
   user:rbd (tcmu-runner), sodass die gesamte Verwaltung
   transparent und unabhängig vom Backstore abläuft.
  
    tcmu-runner-basierte
    iSCSI-Gateway-Bereitstellungen sind aktuell ein Technology Preview.
   
   Im Gegensatz zur Kernel-basierten iSCSI-Gateway-Bereitstellung unterstützen
   tcmu-runner-basierte iSCSI Gateways keine Multipath
   E/A oder permanente SCSI-Reservierungen.
  
   Soll ein RADOS Block Device.Image mit tcmu-runner
   exportiert werden, müssen Sie lediglich den
   user:rbd-Backstore angeben, wenn Sie den Datenträger
   anhängen:
  
gwcli >  /disks> attach rbd/testvol backstore=user:rbd
    Zur Verwendung von tcmu-runner muss die Funktion
    exclusive-lock für das exportierte RBD-Image aktiviert
    sein.
   

