Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 6

10 Installation des iSCSI Gateway Edit source

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 6 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 6-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 6 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.

10.1 iSCSI-Blockspeicher Edit source

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 Targets werden als iSCSI Portal bezeichnet, wobei ein Target über einen oder mehrere Portale sichtbar gemacht werden kann. Die Kombination aus einem Target und einem oder mehreren Portalen wird als Target Portal Group (TPG) bezeichnet.

Das zugrundeliegende Daten-Link-Schicht-Protokoll für iSCSI ist normalerweise Ethernet. Genauer gesagt, moderne iSCSI-Infrastrukturen verwenden 10 Gigabit Ethernet oder schnellere Netzwerke für optimalen Durchsatz. 10 Gigabit Ethernet-Konnektivität zwischen dem iSCSI Gateway und dem Backend Ceph Cluster wird dringend empfohlen.

10.1.1 Linux Kernel iSCSI Target Edit source

Das Linux Kernel iSCSI Target 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 Backend 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 Backend-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 Backend-Modul. Es unterstützt den parallelisierten Multipath-E/A-Zugriff auf RBD-Images.

10.1.2 iSCSI Initiator Edit source

In diesem Abschnitt erhalten Sie einen kurzen Überblick über die iSCSI Initiator, die auf Linux-, Microsoft Windows und VMware-Plattformen verwendet werden.

10.1.2.1 Linux Edit source

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.

10.1.2.2 Microsoft Windows und Hyper-V Edit source

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.

10.1.2.3 VMware Edit source

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.

10.2 Allgemeine Informationen zu ceph-iscsi Edit source

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 Cluster mit einem einzigen iSCSI Gateway
Abbildung 10.1: Ceph Cluster mit einem einzigen iSCSI Gateway

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.

Ceph Cluster mit mehreren iSCSI Gateways
Abbildung 10.2: Ceph Cluster mit mehreren iSCSI Gateways

10.3 Überlegungen zur Bereitstellung Edit source

Eine Mindestkonfiguration von SUSE Enterprise Storage 6 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-Nodes auch als Monitor (MON)-Host.

  • Ein iSCSI-Zielserver, auf dem das LIO-iSCSI-Ziel ausgeführt wird und das über ceph-iscsi konfiguriert 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 6 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-Nodes. 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-iscsi konfiguriert wurden. Zum Zweck von iSCSI Failover und Lastausgleich müssen diese Server einen Kernel ausführen, der das target_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.

10.4 Installation und Konfiguration Edit source

In diesem Abschnitt werden die Schritte zum Installieren und Konfigurieren eines iSCSI Gateways zusätzlich zu SUSE Enterprise Storage beschrieben.

10.4.1 Bereitstellen des iSCSI Gateway auf einem Ceph Cluster Edit source

Sie können das iSCSI-Gateway entweder im Zug der Ceph Cluster-Bereitstellung bereitstellen oder es mittels DeepSea zu einem bestehenden Cluster hinzufügen.

Informationen zur Bereitstellung während des Cluster-Bereitstellungsvorgangs finden Sie in Abschnitt 5.5.1.2, „Rollenzuweisung“.

Informationen zum Hinzufügen des iSCSI Gateways zu einem bestehenden Cluster finden Sie in Abschnitt 2.2, „Hinzufügen neuer Rollen zu Nodes“.

10.4.2 Erstellen von RBD-Images Edit source

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“ das folgende Kommando aus:

cephadm@adm > rbd --pool iscsi-images create --size=102400 'testvol'

10.4.3 Exportieren von RBD-Images über iSCSI Edit source

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.

Anmerkung
Anmerkung

Es werden lediglich die folgenden RBD-Image-Funktionen unterstützt: layering, striping (v2), exclusive-lock, fast-diff und data-pool. RBD-Images, bei denen andere Funktionen aktiviert sind, können nicht exportiert werden.

Starten Sie die Kommandozeilenschnittstelle für das iSCSI-Gateway als root:

root # gwcli

Wechseln Sie zu iscsi-targets und erstellen Sie das Ziel iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol:

gwcli >  /> cd /iscsi-targets
gwcli >  /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.x86: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.x86:testvol/gateways
gwcli >  /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104
gwcli >  /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105
Tipp
Tipp

Mit dem Kommando help rufen sie eine Liste der verfügbaren Kommandos im aktuellen Konfigurationsknoten ab.

Nehmen Sie das RBD-Image „testvol“ in den Pool „iscsi-images“ auf:

gwcli >  /iscsi-target...tvol/gateways> cd /disks
gwcli >  /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.x86:testvol/disks
gwcli >  /iscsi-target...testvol/disks> add iscsi-images/testvol
Anmerkung
Anmerkung

Sie können die lokale Konfiguration mit systemnahen Werkzeugen wie targetcli abfragen, jedoch nicht bearbeiten.

Tipp
Tipp

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 10.4.4, „Authentifizierung und Zugriffssteuerung“.

10.4.4 Authentifizierung und Zugriffssteuerung Edit source

Die iSCSI-Authentifizierung ist flexibel und deckt zahlreiche Authentifizierungsmöglichkeiten ab.

10.4.4.1 Keine Authentifizierung Edit source

„Keine Authentifizierung“ bedeutet, dass jeder Initiator·auf alle LUNs·im entsprechenden Ziel zugreifen kann.· Soll „Keine Authentifizierung“ aktiviert werden, deaktivieren Sie die ACL-Authentifizierung:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hosts
gwcli >  /iscsi-target...testvol/hosts> auth disable_acl

10.4.4.2 ACL-Authentifizierung Edit source

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.x86:testvol/hosts
gwcli >  /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/testvol

10.4.4.3 CHAP-Authentifizierung Edit source

Neben der ACL 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.x86:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20
gwcli >  /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678
Anmerkung
Anmerkung

Die Benutzernamen müssen 8 bis 64 Zeichen enthalten, wobei lediglich Buchstaben und die Sonderzeichen „.“, „@“, „-“, „_“ oder „:“ zulässig sind.

Die Passwörter müssen 12 bis 16 Zeichen enthalten, wobei lediglich Buchstaben und die Sonderzeichen „@“, „-“, „_“ oder „/“ zulässig sind.

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.

10.4.4.4 Ermittlung und gegenseitige Authentifizierung Edit source

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-targets
gwcli >  /iscsi-targets> discovery_auth username=du123456 password=dp1234567890
Anmerkung
Anmerkung

Die Benutzernamen müssen 8 bis 64 Zeichen enthalten, wobei lediglich Buchstaben und die Sonderzeichen „.“, „@“, „-“, „_“ oder „:“ zulässig sind.

Die Passwörter müssen 12 bis 16 Zeichen enthalten, wobei lediglich Buchstaben und die Sonderzeichen „@“, „-“, „_“ oder „/“ zulässig sind.

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 nochap

10.4.5 Erweiterte Einstellungen Edit source

ceph-iscsi kann mit erweiterten Parametern konfiguriert werden, die anschließend an das LIO-E/A-Ziel übergeben werden. Die Parameter sind in „target“- und „disk“-Parameter unterteilt.

Warnung
Warnung

Soweit nicht anders angegeben, ist es nicht zu empfehlen, die Standardeinstellung dieser Parameter zu ändern.

10.4.5.1 Zieleinstellungen Edit source

Mit dem Kommando info rufen Sie den Wert dieser Einstellungen ab:

gwcli >  /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol
gwcli >  /iscsi-target...i.x86:testvol> info

Mit dem Kommando reconfigure ändern Sie eine Einstellung:

gwcli >  /iscsi-target...i.x86:testvol> reconfigure login_timeout 20

Die folgenden „target“-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 1 verhindert das Schreiben in LUNs.

10.4.5.2 Datenträgereinstellungen Edit source

Mit dem Kommando info rufen Sie den Wert dieser Einstellungen ab:

gwcli >  /> cd /disks/rbd/testvol
gwcli >  /disks/rbd/testvol> info

Mit dem Kommando reconfigure ändern Sie eine Einstellung:

gwcli >  /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Die folgenden „disk“-Einstellungen stehen zur Auswahl:

block_size

Blockgröße des zugrundeliegenden Geräts.

emulate_3pc

Wert 1 aktiviert das Drittanbieterexemplar.

emulate_caw

Wert 1 aktiviert „Vergleichen“ und „Schreiben“.

emulate_dpo

Wert 1 schaltet „Disable Page Out“ ein.

emulate_fua_read

Wert 1 aktiviert das Lesen von „Force Unit Access“.

emulate_fua_write

Wert 1 aktiviert das Schreiben von „Force Unit Access“.

emulate_model_alias

Wert 1 verwendet den Backend-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 der iSCSI-Gateway den Reservierungsstatus ignorieren, sodass die Anforderungslatenz verbessert wird.

Tipp
Tipp

Wenn die iSCSI-Initiatoren keine Unterstützung für die SCSI-Reservierung benötigen, wird empfohlen, den Wert 0 für „backstore_emulate_pr“ festzulegen.

emulate_rest_reord

Bei Wert 0 weist der Queue Algorithm Modifier eingeschränkte Neusortierung auf.

emulate_tas

Wert 1 aktiviert „Task Aborted Status“.

emulate_tpu

Wert 1 aktiviert „Thin Provisioning Unmap“.

emulate_tpws

Wert 1 aktiviert „Thin Provisioning Write Same“.

emulate_ua_intlck_ctrl

Wert 1 aktiviert „Unit Attention Interlock“.

emulate_write_cache

Wert 1 schaltet „Write Cache Enable“ ein.

enforce_pr_isids

Wert 1 erzwingt ISIDs für permanente Reservierungen.

is_nonrot

Bei Wert 1 ist der Backstore eine sich nicht drehende Festplatte.

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=1 angefordert hat oder nicht. 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 Option target_core_rbd den Wert „1“ erzwingen und einen Fehler auslösen, wenn ein Benutzer versucht, die Option über configfs 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.

10.5 Exportieren von RADOS Block Device-Images mit tcmu-runner Edit source

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.

Warnung
Warnung: Technology Preview

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
Anmerkung
Anmerkung

Zur Verwendung von tcmu-runner muss die Funktion exclusive-lock für das exportierte RBD-Image aktiviert sein.

Diese Seite drucken