Das IET-iSCSI-Target gehört auf Debian-basierten Distributionen zum Lieferumfang. Red Hat unterstützt offiziell nur STGT, für CentOS finden sich aber passende Zusatzpakete. Für SLES stehen ebenfalls Drittanbieter-Pakete zur Verfügung. Die folgende Beschreibung bezieht sich auf Debian GNU/Linux.
Um IET auf Debian zu nutzen, sind sowohl die Userland-Utilities im Paket »iscsitarget
«
zu installieren wie auch das entsprechende Kernel-Modul, das zuvor händisch gebaut gehört. Die Installation von »iscsitarget-source
«
holt den Modul-Quelltext, mittels »apt-get install module-assistant && m-a prepare && m-a -t a-i iscsitarget
«
wird das Modulpaket gebaut und installiert. Das fertige ».deb
«
-File findet sich dann in »/usr/src
«
für die Installation auf dem zweiten Clusterknoten.
Vorsicht: Der Module-Assistant bringt einige Development-Pakete mit. Wer auf seinem Server keine Development-Pakete dauerhaft installiert haben will, baut das Modul entweder gleich woanders, oder räumt anschließend händisch auf.
Wenn IET installiert ist, schaltet »ISCSITARGET_ENABLE=true
«
in » /etc/default/iscsitarget
«
auf beiden Hosts IET scharf.
Nun, da alle Software-Komponenten für den iSCSI-Cluster-Betrieb installiert sind, ist der letzte Schritt die Konfiguration der Dienste in Pacemaker. Weil einige Dienste zu konfigurieren sind, empfiehlt sich die CRM-Shell: Über den Befehl »crm
«
einmal gestartet, führt »configure
«
in den Abschnitt für die Konfiguration, und »edit
«
öffnet die aktuelle Konfiguration in einem Editor. Erst wenn alle Konfigurationseinträge fertig sind, sorgt »commit
«
dafür, dass die Änderungen im Clustermanager aktiv werden – eine zusätzliche Sicherheitsstufe ist in der CRM-Shell quasi eingebaut. Der Vorteil dieser Methode ist, dass die benötigten Ressourcen in Ruhe und nacheinander in den Cluster-Manager gelangen, unvollständige Einträge oder Tippfehler sorgen nicht automatisch für Chaos.
Listing 2
Die CRM-Shell-Konfiguration
Am Anfang der Pacemaker-Konfiguration steht die DRBD-Ressource. Die dafür benötigten Pacemaker-Einträge bestehen aus zwei Teilen, wie im zweiten Teil der HA-Serie erläutert wurde: zum einen der »primitive
«
-Ressource, zu anderen dem dazugehörigen »Master/Slave
«
-Setup.
Im Beispiel heißt die DRBD-Ressource »iscsivg01
«
, die Pacemaker-Konfiguration dafür kann so aussehen:
primitive res_drbd_iscsivg01 ocf:linbit:drbd \ params drbd_resource="iscsivg01" \ op monitor interval="10s" role="Master" \ op monitor interval="20s" role="Slave" \ op start interval="0" timeout="240" \ op stop interval="0" timeout="240" ms ms_drbd_iscsivg01 res_drbd_iscsivg01 \ meta clone-max="2" master-max="1" master-node-max="1" clone-node-max="1" notify="true" target-role="Master"
Die Konfiguration sorgt dafür, dass die DRBD-Ressouce auf einem der zwei Cluster-Knoten stets »Primary
«
ist. Weiter geht es mit der LVM-VG, die Pacemaker aktivieren muss, um an ihre LVs heranzukommen. Pacemaker verfügt über einen eigenen Resource Agent für LVM namens »ocf:heartbeat:LVM
«
. Dieser Konfigurationseintrag greift für die Volume Group »iscsivg01
«
:
primitive res_lvm_iscsivg01 ocf:heartbeat:LVM params volgrpname="iscsivg01" op monitor interval="30s"
Nun folgt die Konfiguration der iSCSI-Dienste. Sie ist in zwei einzelne Teile getrennt: Einerseits startet der Resource Agent »ocf:heartbeat:iSCSITarget
«
den IET-Daemon »ietd
«
, andererseits sorgt »ocf:heartbeat:iSCSILogicalUnit
«
dafür, dass »ietd
«
weiß, welche Devices er exportieren soll.
In diesem Beispiel sind zwei Logical Volumess zu exportieren, »lun1
«
und »lun2
«
. Mitsamt dem »ietd
«
-Start erledigen das die folgenden Einträge:
primitive res_target_iscsivg01 ocf:heartbeat:iSCSITarget params iqn="iqn.2001-04.com.example:storage.example.iscsivg01" op monitor interval="10s" primitive res_lu_iscsivg01_lun1 ocf:heartbeat:iSCSILogicalUnit params target_iqn="iqn.2001-04.com.example:storage.example.iscsivg01" lun="1" path="/dev/iscsivg01/lun1" op monitor interval="10s" primitive res_lu_iscsivg01_lun2 ocf:heartbeat:iSCSILogicalUnit params target_iqn="iqn.2001-04.com.example:storage.example.iscsivg01" lun="2" path="/dev/iscsivg01/lun2" op monitor interval="10s"
Der String »iqn.2001-04.com.example:storage.example.iscsivg01
«
wirkt zuerst etwas kryptisch. Es handelt sich um den iSCSI Qualified Name. Der Eintrag sollte der Syntax »iqn.yyyy-mm.reversed domainname[:identifier]
«
folgen.
Schließlich fehlt eine IP-Adresse, über die diese iSCSI-Targets zu erreichen sind. Diese sieht in Pacemaker so aus:
primitive res_ip_iscsivg01 ocf:heartbeat: IPaddr2 params ip="192.168.122.115" cidr_netmask="24" op monitor interval="20s"
Damit sind alle Ressourcen komplett – nun muss Pacemaker noch wissen, wie die einzelnen Ressourcen zusammenhängen. Schließlich ist der iSCSI-Server dort zu starten, wo auch das dazugehörige DRBD-Device primär ist. Und zwar erst dann, wenn die LVM-VG erfolgreich aktiviert und deren LVs verfügbar sind. Die einfachste Lösung ist ein »group
«
-Eintrag für die angelegten Ressourcen:
group g_iscsivg01 res_lvm_iscsivg01 res_target_iscsivg01 res_lu_iscsivg01_lun1 res_lu_iscsivg01_lun2 res_ip_iscsivg01
Die DRBD-Ressource kann aufgrund ihrer Master/Slave-Eigenschaft nicht Teil einer Gruppe werden, sondern ist mit der angelegten Gruppe mittels Colocation- und Order-Constraint zu verbinden. DRBD muss auf einem Host im »Primary
«
-Modus laufen, bevor die Gruppe startbar ist. Diese Constraints stellen das sicher:
colocation co_g_iscsivg01_always_with_ms_drbd_iscsivg01 inf: g_iscsivg01 ms_drbd_iscsivg01:Master order o_g_iscsivg01_always_after_ms_drbd_iscsivg01 inf: ms_drbd_iscsivg01:promote g_iscsivg01:start
Wenn diese Einträge in der CRM-Shell gelandet sind, lädt Pacemaker wie oben beschrieben nach einem »commit
«
die neue Konfiguration. Ein »crm_mon -1 -rf
«
sollte danach wie in Abbildung 4 aussehen, und »cat /proc/net/iet/volume
«
sollte eine ähnliche Liste wie in Abbildung 5 hervorbringen. Wenn dem so ist, ist die Konfiguration des iSCSI-Targets abgeschlossen.