ProHoster > Blog > Administration > Ceph ĂŒber iSCSI – oder auf Skiern im HĂ€ngemattensitz

Ceph ĂŒber iSCSI – oder auf Skiern im HĂ€ngemattensitz

Gibt es unter uns (Ceph-Nutzern) diejenigen, die keinen "professionellen Extremismus" lieben?

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

Viele, die mit Ceph gearbeitet haben, sind auf einen nicht sehr hĂ€ufigen (eher sogar sehr seltenen) aber manchmal gefragten Anwendungsfall gestoßen – Ceph ĂŒber iSCSI oder FC anzubinden. Warum? Nun, zum Beispiel, um ein Image von Ceph auf einen aus irgendeinem Grund noch nicht virtualisierten Windows- oder Solaris-Server zu bringen. Oder auf einen virtualisierten, aber ĂŒber einen Hypervisor, der Ceph nicht kann – und davon gibt es, wie wir wissen, genug. Zum Beispiel? Nun, beispielsweise HyperV oder ESXi, die aktiv genutzt werden. Und wenn die Aufgabe darin besteht, ein Image von Ceph an eine virtuelle Maschine bereitzustellen, verwandelt sich dies in eine sehr interessante Herausforderung.

Also, gegeben:

  1. ein bereits funktionierender Ceph-Cluster
  2. ein bereits existierendes Image, das ĂŒber iSCSI bereitgestellt werden muss
  3. Name des Pools mypool, Name des Images myimage

Fangen wir an?

Vor allem, wenn wir von FC oder iSCSI sprechen, entstehen solche EntitĂ€ten wie Initiator und Ziel. Das Ziel ist tatsĂ€chlich der Server, der Initiator – der Client. Unsere Aufgabe ist es, das Ceph-Image mit minimalem Aufwand an den Initiator zu ĂŒbergeben. 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. Folglich installieren wir das iSCSI-Ziel (und den Initiator als Mindestsatz fĂŒr Tests) auf dem Monitor. Ich habe dies unter CentOS gemacht, aber fĂŒr jede andere Distribution ist die Lösung ebenfalls geeignet – es reicht aus, die Pakete auf die Weise zu installieren, die in Ihrer Distribution akzeptabel ist.

# yum -y install iscsi-initiator-utils targetcli

Was ist der Zweck der installierten Pakete?

  • targetcli – ein Verwaltungstool fĂŒr das in den Linux-Kernel integrierte SCSI-Ziel
  • iscsi-initiator-utils – Paket mit Tools zur Verwaltung des ebenfalls in den Linux-Kernel integrierten iSCSI-Initiators

Um ein Abbild ĂŒber iSCSI an den Initiator zu ĂŒbermitteln, gibt es zwei Möglichkeiten: entweder das benutzerseitige Back-End des Targets zu verwenden oder das Abbild als BlockgerĂ€t anzuschließen, das vom Betriebssystem sichtbar ist, und es ĂŒber iSCSI zu exportieren. Wir werden den zweiten Weg gehen, da das benutzerseitige Back-End sich noch im „experimentellen“ Zustand befindet und fĂŒr den produktiven Einsatz nicht ganz bereit ist. Zudem gibt es einige Fallstricke, ĂŒber die man viel reden und (oh Gott!) diskutieren kann.

Wenn wir einen einigermaßen stabilen Distribution mit langem Support-Zyklus verwenden, dann haben wir einen Kernel einer ziemlich alten Version. Zum Beispiel ist der Kernel in CentOS7 3.10.*, in CentOS8 4.19. Wir interessieren uns jedoch fĂŒr einen Kernel von mindestens 5.3 (oder eher 5.4) und neuer. Warum? Weil standardmĂ€ĂŸig Abbilder in Ceph mit einem Satz von Optionen verbunden sind, die mit Ă€lteren Kernen nicht kompatibel sind. Das bedeutet, dass wir ein Repository mit einem neuen Kernel fĂŒr unsere Distribution (zum Beispiel fĂŒr CentOS das elrepo) hinzufĂŒgen, den neuen Kernel installieren und das System neu starten, um mit dem neuen Kernel zu arbeiten.

  • Wir verbinden uns mit dem ausgewĂ€hlten Monitor fĂŒr das Experiment.
  • Wir fĂŒgen die elrepo-Repositories gemĂ€ĂŸ der Anleitung hinzu — elrepo.org/tiki/tiki-index.php
  • Wir installieren den Kernel: yum -y —enablerepo=elrepo-kernel install kernel-ml
  • Wir starten den Server mit dem Monitor neu (wir haben schließlich drei Monitore, oder?)

Wir verbinden das Abbild als BlockgerÀt.

# rbd Karte mypool/myimage
/dev/rbd0

Es bleibt nur noch, das Target zu konfigurieren. In diesem Beispiel werde ich das Target im sogenannten Demo-Modus konfigurieren — ohne Authentifizierung, sichtbar und fĂŒr alle zugĂ€nglich. In einer Produktionsumgebung werden Sie wahrscheinlich die Authentifizierung konfigurieren wollen — aber das liegt etwas außerhalb des heutigen, nur-zu-Spaß-Übung.

Wir erstellen ein Back-End 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 Name des rbd-GerÀtes sich aufgrund der Reihenfolge, in der die Ceph-Abbilder an den Host angeschlossen werden, Àndern kann.

Wir erstellen das Back-End:

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

Wir erstellen das iSCSI-Target:

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

Wir verbinden das Back-End als LUN mit dem Target:

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

Wir konfigurieren das Target fĂŒr den Demo-Modus:

# 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 die VerfĂŒgbarkeit 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
Anmelden 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 Sie alles richtig gemacht haben, wird auf dem Server eine neue Disk angezeigt, die wie ein SCSI-GerĂ€t aussieht, aber tatsĂ€chlich ein Abbild von Ceph ist, auf das ĂŒber ein iSCSI-Target zugegriffen wird. Um Probleme beim Booten zu vermeiden, sollten Sie die angeschlossene Disk und das erkannte Target vom lokalen Initiator entfernen:

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

Alles, was ĂŒbrig bleibt, ist die Konfiguration zu persistieren, damit das Abbild automatisch verbunden wird und das Target nach der Verbindung gestartet wird. Der Start des Targets besteht aus zwei Schritten – der Verbindung des RBD und tatsĂ€chlich dem Start des Targets.

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

# katze /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl rbdmap aktivieren

Mit der Wiederherstellung der Target-Konfiguration ist es etwas komplizierter – wir mĂŒssen eine Einheit 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 abschließende Test – starten Sie unseren Monitor (der jetzt auch iSCSI-Target ist) erneut neu. Es ist zu beachten, dass wir, wenn wir die Datenbank des Initiators nicht mit dem Befehl iscsiadm -n discoverydb -o delete 
 bereinigt hĂ€tten, einen nicht bootfĂ€higen oder lange bootenden Server erhalten könnten.

Was bleibt zu tun?

Den Initiator auf dem Server konfigurieren, auf den wir das Target bereitstellen möchten.

Wie gewÀhrleisten wir die Ausfallsicherheit unseres Targets?

Wir können die Targets auch auf anderen Monitoren Ă€hnlich konfigurieren und Multipath einrichten (VMware wird das verstehen und es wird sogar funktionieren, Hyper-V wird es nicht verstehen – dort sind SCSI-Sperren erforderlich). Da der Ceph-Client im Kernel kein Caching verwendet, ist dies durchaus funktionsfĂ€hig. Eine andere Möglichkeit besteht darin, eine Cluster-Ressource aus drei Komponenten zu erstellen – einem dedizierten IP-Adressen Target und den Diensten rbdmap und scsi-target, und dieses Ressourcenverwaltungs ĂŒber Cluster-Werkzeuge (wer hat pacemaker gesagt?)

Anstatt eines Nachworts

Wie zu erkennen ist, ist dieser Artikel ein kleiner Scherz – aber ich habe versucht, „schnell und an Beispielen“ gleichzeitig mehrere ziemlich populĂ€re Themen zu betrachten: iSCSI-Target, das nicht unbedingt Ceph-Abbilder exportieren muss – sondern beispielsweise LVM-Volumes exportieren kann, die Grundlagen der Arbeit mit einem iSCSI-Initiator (wie man das Target scannt, sich mit dem Target verbindet, sich trennt, den Eintrag ĂŒber das Target aus der Datenbank löscht), das Schreiben einer eigenen Einheit fĂŒr systemd und einige andere.

Ich hoffe, dass selbst wenn Sie dieses Experiment nicht in vollem Umfang wiederholen, wenigstens etwas aus diesem Artikel fĂŒr Sie nĂŒtzlich sein wird.

Quelle: habr.com

60GB SSD 8Gb DDR4