🥇Ceph über iSCSI — oder Skifahren im Liegestuhl

Gibt es unter uns (Ceph-Nutzern) wirklich jemanden, der "professionellen Extremismus" nicht mag?

Wahrscheinlich nicht – sonst würden wir uns nicht mit diesem äußerst interessanten und unterhaltsamen Produkt beschäftigen.

Viele, die sich mit Ceph auseinandergesetzt haben, sind auf einen eher seltenen (eigentlich sehr seltenen), aber manchmal gefragten Anwendungsfall gestoßen – Ceph über iSCSI oder FC anzuschließen. Warum? Nun, beispielsweise, um ein Image von Ceph auf einen Server mit Windows oder Solaris zu bringen, der aus irgendeinem Grund noch nicht virtualisiert ist. Oder auf einen virtualisierten, aber über einen Hypervisor, der Ceph nicht unterstützt – und davon gibt es bekanntermaßen viele. Zum Beispiel? Nun, zum Beispiel HyperV oder ESXi, die weit verbreitet sind. Und wenn die Aufgabe besteht, ein Image von Ceph an eine virtuelle Maschine zu übermitteln, wird dies zu einer recht spannenden Herausforderung.

Also, gegeben:

ein bereits funktionierender Ceph-Cluster
ein bereits vorhandenes Image, das über iSCSI bereitgestellt werden muss
Name des Pools mypool, Name des Images myimage

Fangen wir an?

Zunächst einmal, wenn wir über FC oder iSCSI sprechen, tauchen solche Entitäten wie Initiator und Ziel auf. Das Ziel ist tatsächlich der Server, der Initiator — der Client. Unsere Aufgabe ist es, mit minimalem Aufwand ein Ceph-Image auf den Initiator zu bringen. Das bedeutet, wir müssen das Ziel bereitstellen. Aber wo, auf welchem Computer?

Glücklicherweise haben wir im Ceph-Cluster mindestens eine Komponente, deren IP-Adresse festgelegt ist und auf der eine der wichtigsten Komponenten von Ceph konfiguriert ist, und diese Komponente ist der Monitor. Daher installieren wir das iSCSI-Ziel auf dem Monitor (und auch den Initiator, zumindest für Tests). Ich habe das auf CentOS gemacht, aber für jede andere Distribution ist die Lösung ebenfalls geeignet — es reicht, die Pakete auf die Art zu installieren, die für Ihre Distribution akzeptabel ist.

# yum -y install iscsi-initiator-utils targetcli

Was ist der Zweck der installierten Pakete?

targetcli — ein Verwaltungswerkzeug für den in den Linux-Kernel integrierten SCSI-Ziel
iscsi-initiator-utils — ein Paket mit Werkzeugen zur Verwaltung des ebenfalls in den Linux-Kernel integrierten iSCSI-Initiators

Um ein Image über iSCSI an den Initiator zu übergeben, gibt es zwei Möglichkeiten: Entweder nutzen wir das userspace Backend des Targets oder montieren das Image als Blockgerät, das für das Betriebssystem sichtbar ist, und exportieren es über iSCSI. Wir wählen den zweiten Weg, da das userspace Backend derzeit im "experimentellen" Zustand ist und für den produktiven Einsatz noch nicht ganz bereit ist. Zudem gibt es einige Fallstricke, über die man viel diskutieren und (oh Schreck!) streiten kann.

Wenn wir eine einigermaßen stabile Distribution mit langem Support-Zyklus verwenden, haben wir einen Kernel einer sehr alten Version. Zum Beispiel in CentOS7 ist es 3.10.*, in CentOS8 ist es 4.19. Uns interessiert aber mindestens ein Kernel 5.3 (eher 5.4) oder neuer. Warum? Weil standardmäßig die Images in Ceph mit einer Optionsbündelung verbunden sind, die nicht mit alten Kernen kompatibel ist. Das bedeutet, dass wir ein Repository für einen neuen Kernel für unsere Distribution hinzufügen (zum Beispiel für CentOS ist das elrepo), installieren den neuen Kernel und starten das System neu, um mit dem neuen Kernel zu arbeiten:

Wir verbinden uns mit dem ausgewählten Monitor für das Experiment.
Wir binden die elrepo-Repositories gemäß der Anleitung ein — elrepo.org/tiki/tiki-index.php
Wir installieren den Kernel: yum -y —enablerepo=elrepo-kernel install kernel-ml
Wir starten den Server neu mit Monitor (wir haben doch drei Monitore, richtig?)

Wir verbinden das Image als Blockgerät

# rbd-Karte mypool/myimage /dev/rbd0

Jetzt müssen wir nur noch das Target konfigurieren. In diesem Beispiel konfiguriere ich das Target im sogenannten Demo-Modus — ohne Authentifizierung, sichtbar und zugänglich für alle. In einer Produktionsumgebung möchten Sie wahrscheinlich Authentifizierung einrichten — aber das ist für heute nicht das Thema dieses kleinen, spaßigen Übungsprojekts.

Wir erstellen ein Backend mit dem Namen disk1, das der Datei /dev/rbd/mypool/myimage zugeordnet ist. Die angegebene Datei ist ein automatisch vom udev-Daemon erstellter symbolischer Link zu /dev/rbd0. Wir verwenden genau diesen symbolischen Link, da der rbd-Gerätename sich aufgrund der Reihenfolge des Anschlusses von Ceph-Images an den Host ändern kann.

Wir erstellen das Backend:

# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage

Wir erstellen das iSCSI-Target:

# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool

Wir verbinden das Backend als LUN mit dem Target:

# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns erstellen /backstores/block/disk1

Wir passen das Target für den Demo-Modus an:

# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set > Attribut demo_mode_write_protect=0 # targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set > Attribut generate_node_acls=1 # targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set > Attribut cache_dynamic_acls=1

Wir speichern die Konfiguration:

# targetcli saveconfig

Wir überprüfen das Vorhandensein des Targets:

# iscsiadm -m discovery -t st -p 127.0.0.1:3260 127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool

Wir verbinden das Target:

# iscsiadm -m node --login Anmeldung bei [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (mehrere) Anmeldung bei [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] erfolgreich.

Wenn alles richtig gemacht wurde, erscheint ein neues Laufwerk auf dem Server, das wie ein SCSI-Gerät aussieht, aber tatsächlich ein Image aus Ceph ist, auf das über das iSCSI-Ziel zugegriffen wird. Um Probleme beim Booten zu vermeiden, sollten Sie das angeschlossene Laufwerk und das entdeckte Ziel vom lokalen Initiator entfernen:

# iscsiadm -m node --logout # iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260

Alles, was noch bleibt, ist die Konfiguration zu persistieren, damit das Image automatisch verbunden wird und nach der Verbindung das Ziel gestartet wird. Der Start des Ziels besteht aus zwei Schritten – der Verbindung von RBD und dem eigentlichen Start des Ziels.

Zuerst konfigurieren wir die automatische Verbindung von RBD-Images zum Host. Dies geschieht durch das Hinzufügen von Zeilen zur Datei /etc/ceph/rbdmap:

# katze /etc/ceph/rbdmap # RbdDevice Parameters meinpool/meinbild id=admin # systemctl aktivieren rbdmap

Die Wiederherstellung der Zielkonfiguration ist etwas komplizierter – wir müssen eine Unit für systemd schreiben, die die Konfiguration wiederherstellt:

# cat /usr/lib/systemd/system/scsi-target.service [Unit] Beschreibung=Starten Sie das iSCSI-Ziel

After=network-online.target rbdmap.service
Before=remote-fs-pre.target
Wants=network-online.target remote-fs-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/targetcli restoreconfig

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl enable scsi-target

Der finale Test – wir starten unseren Monitor (der jetzt auch iSCSI-Ziel ist) erneut neu. Es ist anzumerken, dass wir die Initiator-Datenbank nicht mit dem Befehl bereinigt hätten iscsiadm -n discoverydb -o delete … Sonst könnte es zu einem Server kommen, der nicht hochfährt oder lange benötigt, um hochzufahren.

Was bleibt übrig?

Den Initiator auf dem Server konfigurieren, an den wir das Ziel übergeben möchten.

Wie gewährleisten wir die Ausfallsicherheit unseres Ziels?

Ähnlich können Ziele auf anderen Monitoren konfiguriert und eine Multipath-Verbindung eingerichtet werden (VMware versteht das und funktioniert sogar, Hyper-V versteht es nicht — dort sind SCSI-Sperren erforderlich). Da der Ceph-Client im Kernel kein Caching verwendet, ist das durchaus funktionsfähig. Eine andere Möglichkeit wäre, eine Clusterressource aus drei Komponenten zu erstellen — einem dedizierten Ziel und den Diensten rbdmap und scsi-target, und diese Ressource über Cluster-Management-Tools zu verwalten (wer hat pacemaker gesagt?) IP-Adressen Wie klar ist, ist dieser Artikel ein bisschen ein Scherz — aber darin habe ich versucht, „schnell und an Beispielen“ gleichzeitig mehrere recht beliebte Themen zu betrachten — iSCSI-Ziel, das nicht unbedingt Ceph-Images exportieren muss — aber zum Beispiel LVM-Volumes exportieren kann, Grundlagen der Arbeit mit dem iSCSI-Initiator (wie man das Ziel scannt, wie man sich mit dem Ziel verbindet, trennt und den Eintrag über das Ziel aus der Datenbank löscht), das Schreiben einer eigenen Einheit für systemd und einige andere.

Anstelle eines Schlussworts

Wie klar ist, ist dieser Artikel ein wenig ein Scherz — aber ich habe versucht, "schnell und anhand von Beispielen" mehrere ziemlich populäre Themen gleichzeitig zu behandeln — iSCSI-Target, das nicht unbedingt Images von Ceph exportieren muss — sondern zum Beispiel LVM-Volumes exportieren kann, Grundlagen der Arbeit mit dem iSCSI-Initiator (wie man das Target scannt, sich mit dem Target verbindet, trennt und den Eintrag über das Target aus der Datenbank entfernt), das Schreiben einer eigenen Einheit für systemd und einige andere.

Ich hoffe, dass Sie auch, wenn Sie nicht das gesamte Experiment in vollem Umfang wiederholen, aus diesem Artikel zumindest etwas Nützliches herausziehen können.

Quelle: habr.com

Ceph über iSCSI – oder wie man im Hängematten-Ski steht

Anstelle eines Schlussworts