Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

IET installieren und konfigurieren

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.

Das große Ganze: die Pacemaker-Konfiguration

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.

Abbildung 5: Mittels
Abbildung 4: Wenn Pacemaker wie im Beispiel beschrieben konfiguriert ist, sollte die Ausgabe von
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019