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

10 Installation des iSCSI Gateway

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 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 Cluster zur Verfügung. Die Konfigurationsfunktion wird lrbd genannt. Über lrbd 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 lrbd 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 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

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

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

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

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

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

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 lrbd

lrbd vereint die Vorteile von RADOS Block Devices mit der universellen Vielseitigkeit von iSCSI. Durch Anwenden von lrbd auf einem iSCSI Target Host (als lrbd-Gateway bekannt) 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

lrbd 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

Eine Mindestkonfiguration von SUSE Enterprise Storage mit lrbd 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.

  • Einem iSCSI Target-Server, auf dem das LIO iSCSI Target ausgeführt wird und das über lrbd 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 mit lrbd 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 Target-Server, auf denen das LIO iSCSI Target ausgeführt wird und die über lrbd 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

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

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 4.5.1.2, „Rollenzuweisung“.

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

10.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 namens iscsi das folgende Kommando aus:

root # rbd --pool iscsi create --size=102400 testvol

Dieses Kommando erstellt ein RBD-Volume im Standardformat 2.

Anmerkung
Anmerkung

Ab SUSE Enterprise Storage 3 ist 2 das Standardformat für Volumes. Format 1 ist veraltet. Sie können jedoch mit der Option --image-format 1 immer noch Volumes im veralteten Format 1 erstellen.

10.4.3 Exportieren von RBD-Images über iSCSI

Exportieren Sie RBD-Images über iSCSI mit dem lrbd-Dienstprogramm. Mit lrbd erstellen, überprüfen und bearbeiten Sie die iSCSI Target-Konfiguration, die ein JSON-Format verwendet.

Tipp
Tipp: Importieren von Änderungen in openATTIC

Änderungen, die mit dem lrbd-Kommando an der iSCSI Gateway-Konfiguration vorgenommen werden, sind für DeepSea und openATTIC nicht sichtbar. Zum Importieren Ihrer manuellen Änderungen müssen Sie die iSCSI Gateway-Konfiguration in eine Datei exportieren:

root@minion > lrbd -o /tmp/lrbd.conf

Kopieren Sie diese dann zum Salt Master, sodass sie von DeepSea und openATTIC gesehen wird:

root@minion > scp /tmp/lrbd.conf ses5master:/srv/salt/ceph/igw/cache/lrbd.conf

Bearbeiten Sie schließlich /srv/pillar/ceph/stack/global.yml und legen Sie Folgendes fest:

igw_config: default-ui

Bearbeiten Sie die Konfiguration mit lrbd -e oder lrbd --edit. Durch dieses Kommando wird der Standardeditor aufgerufen, wie durch die Umgebungsvariable EDITOR definiert. Sie können dieses Verhalten durch Festlegen der Option -E zusätzlich zu -e außer Kraft setzen.

Nachfolgend sehen Sie ein Konfigurationsbeispiel für

  • zwei iSCSI Gateway-Hosts namens iscsi1.example.com und iscsi2.example.com,

  • die ein einzelnes iSCSI Target mit dem iSCSI Qualified Name (IQN) iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol definieren,

  • mit einem einzelnen iSCSI Logical Unit (LU),

  • gesichert durch ein RBD Image namens testvol im RADOS-Pool rbd,

  • wobei das Target über zwei Portale namens "east" und "west" exportiert wird:

{
    "auth": [
        {
            "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol",
            "authentication": "none"
        }
    ],
    "targets": [
        {
            "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol",
            "hosts": [
                {
                    "host": "iscsi1.example.com",
                    "portal": "east"
                },
                {
                    "host": "iscsi2.example.com",
                    "portal": "west"
                }
            ]
        }
    ],
    "portals": [
        {
            "name": "east",
            "addresses": [
                "192.168.124.104"
            ]
        },
        {
            "name": "west",
            "addresses": [
                "192.168.124.105"
            ]
        }
    ],
    "pools": [
        {
            "pool": "rbd",
            "gateways": [
                {
                    "target": "iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol",
                    "tpg": [
                        {
                            "image": "testvol"
                        }
                    ]
                }
            ]
        }
    ]
    }

Beachten Sie, dass ein Hostname, auf den Sie sich bei der Konfiguration beziehen, mit der Kommandoausgabe uname -n des iSCSI Gateways übereinstimmen muss.

Die bearbeitete JSON-Datei wird in den erweiterten Attributen (xattrs) eines einzelnen RADOS-Objekts pro Pool gespeichert. Dieses Objekt steht den Gateway-Hosts zur Verfügung, auf denen die JSON-Datei bearbeitet wurde, sowie allen Gateway-Hosts, die mit demselben Ceph Cluster verbunden sind. Es werden keine Konfigurationsinformationen lokal auf dem lrbd Gateway gespeichert.

Zum Aktivieren der Konfiguration müssen Sie diese im Ceph Cluster speichern und einen der folgenden Vorgänge (als root) ausführen:

  • Führen Sie das Kommando lrbd (ohne weitere Optionen) an der Kommandozeile aus

oder

  • Starten Sie den lrbd-Service neu mit service lrbd restart.

Der lrbd"Service" betreibt keinen Hintergrund-Daemon. Er löst nur das Kommando lrbd aus. Diese Art von Service wird als "One-Shot"-Service bezeichnet.

Sie sollten auch lrbd zur automatischen Konfiguration bei Systemstart aktivieren. Führen Sie dazu das Kommando systemctl enable lrbd aus.

Die oben genannte Konfiguration spiegelt eine einfache Einrichtung mit einem Gateway wider. Eine lrbd-Konfiguration kann sehr viel komplexer und leistungsstärker sein. Das lrbd RPM-Paket enthält ein umfangreiches Set von Konfigurationsbeispielen, auf die Sie sich möglicherweise beziehen möchten, wenn Sie den Inhalt des Verzeichnisses /usr/share/doc/packages/lrbd/samples nach der Installation überprüfen. Die Beispiele sind auch verfügbar unter https://github.com/SUSE/lrbd/tree/master/samples.

10.4.4 Optionale Einstellungen

Die folgenden Einstellungen sind möglicherweise in einigen Umgebungen nützlich. Für Images stehen die Attribute uuid, lun, retries, sleep und retry_errors zur Verfügung. Die ersten beiden, uuid und lun, lassen für ein bestimmtes Image die feste Programmierung von "uuid" oder "lun" zu. Sie können eines der beiden Attribute für ein Image angeben. Die Attribute retries, sleep und retry_errors beziehen sich auf Versuche zum Zuordnen eines RBD-Image.

"pools": [
    {
        "pool": "rbd",
        "gateways": [
        {
        "host": "igw1",
        "tpg": [
                    {
                        "image": "archive",
                        "uuid": "12345678-abcd-9012-efab-345678901234",
                        "lun": "2",
                        "retries": "3",
                        "sleep": "4",
                        "retry_errors": [ 95 ],
                        [...]
                    }
                ]
            }
        ]
    }
]

10.4.5 Erweiterte Einstellungen

lrbd kann mit erweiterten Parametern konfiguriert werden, die anschließend an das LIO E/A-Target übergeben werden. Die Parameter sind unterteilt in iSCSI- und Sicherungsspeicher-Komponenten, die dann entsprechend in den Abschnitten "targets" und "tpg" der lrbd-Konfiguration angegeben werden können.

Warnung
Warnung

Es ist nicht zu empfehlen, die Standardeinstellung dieser Parameter zu ändern.

"targets": [
    {
        [...]
        "tpg_default_cmdsn_depth": "64",
        "tpg_default_erl": "0",
        "tpg_login_timeout": "10",
        "tpg_netif_timeout": "2",
        "tpg_prod_mode_write_protect": "0",
    }
]

Eine Beschreibung der Optionen finden Sie nachfolgend:

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

tpg_default_erl

Standardmäßige Fehlerwiederherstellungsstufe.

tpg_login_timeout

Wert der Zeitüberschreitung bei der Anmeldung in Sekunden.

tpg_netif_timeout

NIC-Fehler-Zeitüberschreitung in Sekunden.

tpg_prod_mode_write_protect

Wert 1 verhindert das Schreiben in LUNs.

"pools": [
    {
        "pool": "rbd",
        "gateways": [
        {
        "host": "igw1",
        "tpg": [
                    {
                        "image": "archive",
                        "backstore_block_size": "512",
                        "backstore_emulate_3pc": "1",
                        "backstore_emulate_caw": "1",
                        "backstore_emulate_dpo": "0",
                        "backstore_emulate_fua_read": "0",
                        "backstore_emulate_fua_write": "1",
                        "backstore_emulate_model_alias": "0",
                        "backstore_emulate_rest_reord": "0",
                        "backstore_emulate_tas": "1",
                        "backstore_emulate_tpu": "0",
                        "backstore_emulate_tpws": "0",
                        "backstore_emulate_ua_intlck_ctrl": "0",
                        "backstore_emulate_write_cache": "0",
                        "backstore_enforce_pr_isids": "1",
                        "backstore_fabric_max_sectors": "8192",
                        "backstore_hw_block_size": "512",
                        "backstore_hw_max_sectors": "8192",
                        "backstore_hw_pi_prot_type": "0",
                        "backstore_hw_queue_depth": "128",
                        "backstore_is_nonrot": "1",
                        "backstore_max_unmap_block_desc_count": "1",
                        "backstore_max_unmap_lba_count": "8192",
                        "backstore_max_write_same_len": "65535",
                        "backstore_optimal_sectors": "8192",
                        "backstore_pi_prot_format": "0",
                        "backstore_pi_prot_type": "0",
                        "backstore_queue_depth": "128",
                        "backstore_unmap_granularity": "8192",
                        "backstore_unmap_granularity_alignment": "4194304"
                    }
                ]
            }
        ]
    }
]

Eine Beschreibung der Optionen finden Sie nachfolgend:

backstore_block_size

Blockgröße des zugrundeliegenden Geräts.

backstore_emulate_3pc

Wert 1 aktiviert das Drittanbieterexemplar.

backstore_emulate_caw

Wert 1 aktiviert "Vergleichen" und "Schreiben".

backstore_emulate_dpo

Wert 1 schaltet "Disable Page Out" ein.

backstore_emulate_fua_read

Wert 1 aktiviert das Lesen von "Force Unit Access".

backstore_emulate_fua_write

Wert 1 aktiviert das Schreiben von "Force Unit Access".

backstore_emulate_model_alias

Wert 1 verwendet den Backend-Gerätenamen für den Modell-Alias.

backstore_emulate_rest_reord

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

backstore_emulate_tas

Wert 1 aktiviert "Task Aborted Status".

backstore_emulate_tpu

Wert 1 aktiviert "Thin Provisioning Unmap".

backstore_emulate_tpws

Wert 1 aktiviert "Thin Provisioning Write Same".

backstore_emulate_ua_intlck_ctrl

Wert 1 aktiviert "Unit Attention Interlock".

backstore_emulate_write_cache

Wert 1 schaltet "Write Cache Enable" ein.

backstore_enforce_pr_isids

Wert 1 erzwingt ISIDs für permanente Reservierungen.

backstore_fabric_max_sectors

Maximale Anzahl der Sektoren, die die Fabric sofort übertragen kann.

backstore_hw_block_size

Hardware-Blockgröße in Byte.

backstore_hw_max_sectors

Maximale Anzahl der Sektoren, die die Hardware sofort übertragen kann.

backstore_hw_pi_prot_type

Wenn der Wert ungleich Null ist, wird der DIF-Schutz auf der zugrundeliegenden Hardware aktiviert.

backstore_hw_queue_depth

Hardware-Warteschlangentiefe.

backstore_is_nonrot

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

backstore_max_unmap_block_desc_count

Maximale Anzahl der Blockbeschreibungen für UNMAP.

backstore_max_unmap_lba_count:

Maximale Anzahl der LBAs für UNMAP.

backstore_max_write_same_len

Maximale Länge für WRITE_SAME.

backstore_optimal_sectors

Optimale Anforderungsgröße in Sektoren.

backstore_pi_prot_format

DIF-Schutz-Format.

backstore_pi_prot_type

DIF-Schutz-Typ.

backstore_queue_depth

Warteschlangentiefe.

backstore_unmap_granularity

UNMAP-Granularität.

backstore_unmap_granularity_alignment

Abstimmung der UNMAP-Granularität.

Bei Targets lassen die tpg-Attribute die Abstimmung der Kernelparameter zu. Gehen Sie dabei jedoch sehr sorgfältig vor.

"targets": [
{
    "host": "igw1",
    "target": "iqn.2003-01.org.linux-iscsi.generic.x86:sn.abcdefghijk",
    "tpg_default_cmdsn_depth": "64",
    "tpg_default_erl": "0",
    "tpg_login_timeout": "10",
    "tpg_netif_timeout": "2",
    "tpg_prod_mode_write_protect": "0",
    "tpg_t10_pi": "0"
}
Tipp
Tipp

Wenn eine Site statisch zugewiesene LUNs benötigt, weisen Sie jedem LUN eine Nummer zu.

10.5 Exportieren von RADOS Block Device Images mit tcmu-runner

Ab Version 5 ist im Lieferumfang von SUSE Enterprise Storage ein Benutzerbereich-RBD-Backend für tcmu-runner enthalten (weitere Informationen finden Sie unter man 8 tcmu-runner).

Warnung
Warnung: Technology Preview

tcmu-runner-basierte iSCSI Gateway-Bereitstellungen sind aktuell ein Technology Preview. In Kapitel 10, Installation des iSCSI Gateway finden Sie Anweisungen zur Kernel-basierten iSCSI Gateway-Bereitstellung mit lrbd.

Im Gegensatz zur Kernel-basierten lrbd iSCSI Gateway-Bereitstellung unterstützen tcmu-runner-basierte iSCSI Gateways keine Multipath E/A oder permanente SCSI-Reservierungen.

Da DeepSea und openATTIC aktuell keine tcmu-runner-Bereitstellungen unterstützen, müssen Sie Installation, Bereitstellung und Überwachung manuell vornehmen.

10.5.1 Installation

Installieren Sie in Ihrem iSCSI Gateway Node das Paket tcmu-runner-handler-rbd aus den SUSE Enterprise Storage 5-Medien zusammen mit den Paketabhängigkeiten libtcmu1 und tcmu-runner. Installieren Sie zu Konfigurationszwecken das Paket targetcli-fb. Beachten Sie, dass das Paket targetcli-fb mit der "non-fb"-Version des Pakets targetcli nicht kompatibel ist.

Bestätigen Sie, dass der Service tcmu-runner systemd ausgeführt wird:

root # systemctl enable tcmu-runner
tcmu-gw:~ # systemctl status tcmu-runner
● tcmu-runner.service - LIO Userspace-passthrough daemon
  Loaded: loaded (/usr/lib/systemd/system/tcmu-runner.service; static; vendor
  preset: disabled)
    Active: active (running) since ...

10.5.2 Konfiguration und Bereitstellung

Erstellen Sie ein RADOS Block Device Image auf Ihrem bestehenden Ceph Cluster. Im folgenden Beispiel verwenden wir ein 10G Image namens "tcmu-lu", das sich im "rbd"-Pool befindet.

Führen Sie nach dem Erstellen des RADOS Block Device Image targetcli aus und stellen Sie sicher, dass tcmu-runner RBD Handler (Plugin) verfügbar ist:

root # targetcli
targetcli shell version 2.1.fb46
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> ls
o- / ................................... [...]
  o- backstores ........................ [...]
...
  | o- user:rbd ......... [Storage Objects: 0]

Erstellen Sie einen Backstore-Konfigurationseintrag für das RBD-Image:

/> cd backstores/user:rbd
/backstores/user:rbd> create tcmu-lu 10G /rbd/tcmu-lu
Created user-backed storage object tcmu-lu size 10737418240.

Erstellen Sie einen iSCSI-Transportkonfigurationseintrag. Im folgenden Beispiel wird die Target-IQN "iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a" mit targetcli automatisch generiert. Sie wird als eindeutige Kennung für das iSCSI Target verwendet:

/backstores/user:rbd> cd /iscsi
/iscsi> create
Created target iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.

Erstellen Sie einen ACL-Eintrag für den/die iSCSI Initiator, der/die mit dem Target verbunden werden soll. Im folgenden Beispiel wird eine Initiator-IQN von "iqn.1998-01.com.vmware:esxi-872c4888" verwendet:

/iscsi> cd
iqn.2003-01.org.linux-iscsi.tcmu-gw.x8664:sn.cb3d2a3a/tpg1/acls/
/iscsi/iqn.20...a3a/tpg1/acls> create iqn.1998-01.com.vmware:esxi-872c4888

Verknüpfen Sie schließlich die vorher erstellte RBD-Backstore-Konfiguration mit dem iSCSI Target:

/iscsi/iqn.20...a3a/tpg1/acls> cd ../luns
/iscsi/iqn.20...a3a/tpg1/luns> create /backstores/user:rbd/tcmu-lu
Created LUN 0.
Created LUN 0->0 mapping in node ACL iqn.1998-01.com.vmware:esxi-872c4888

Beenden Sie die Shell, um die bestehende Konfiguration zu speichern:

/iscsi/iqn.20...a3a/tpg1/luns> exit
Global pref auto_save_on_exit=true
Last 10 configs saved in /etc/target/backup.
Configuration saved to /etc/target/saveconfig.json

10.5.3 Verwendung

Stellen Sie von Ihrem iSCSI Initiator (Client) Node aus eine Verbindung zum neu bereitgestellten iSCSI Target her. Verwenden Sie dazu die oben konfigurierte IQN und den Hostnamen.

Diese Seite drucken