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)

Das iSCSI-Target nutzen

Das hochverfügbare iSCSI-Target ist fertig, nun bleibt noch zu klären, wie es sich auf Clients und insbesondere bei den Virtualisierungs-Frontends nutzen lässt. Grundvoraussetzung dafür ist, dass das Paket »open-iscsi« installiert ist. So, wie "echtes" SCSI, braucht auch iSCSI einen Initiator auf der Client-Seite. Der Open-iSCSI-Connector liegt praktisch jeder aktuellen Distribution bei. Nach der Paketinstallation auf Debian ist sein Daemon noch mittels »/etc/init.d/open-iscsi start« zu starten. Danach lässt sich das iSCSI-Device verbinden – im Beispiel mit dem Befehl

scsiadm -m node -T iqn.2001-04.com.example:storage.example.iscsivg01 -p 192.168.122.115:3260 --login

auf dem Knoten, auf dem das iSCSI-Target nicht gestartet ist (im Zweifelsfall gibt »crm_mon -1 -rf« Auskunft). Der Befehl sollte »Successful!« zurückliefern, in »dmesg« sind dann die neuen Devices als »Virtual Disk« zu sehen. Damit ist der lokale Zugriff auf sie möglich.

Es gibt für Pacemaker auch einen Ressource-Agent, der über »open-iscsi« die Verbindung mit einem iSCSI-Target herstellt. Er heißt »ocf:heartbeat:iscsi « und setzt ein installiertes »open-iscsi« voraus. Der entsprechende Eintrag in der CRM-Shell braucht zwei Parameter, nämlich »portal=« mit der IP-Adresse des Targets (im Beispiel 192.168.122.115) und andererseits » target=« mit dem Target-Namen (gemeint ist der IQN, im Beispiel wäre das »iqn.2001-04.com.example:storage.example.iscsivg01« ). Ein vollständiger Eintrag für dieses Beispiel wäre dieses:

primitive res_connect_iSCSI_iscsivg01 ocf:heartbeat:iscsi \
params portal="192.168.122.115:3260" target="iqn.2001-04.com.example:storage. example.iscsivg01" \op monitor interval="10s"

Der Eintrag gehört allerdings nicht in die Pacemaker-Konfiguration auf dem iSCSI-Cluster, sondern in die der Virtualisierungs-Frontends.

Die letzte noch zu klärende Frage betrifft die Virtualisierungs-Frontends selbst. Denn der iSCSI-Cluster kann nur Storage-Devices zur Verfügung stellen; er kann sich nicht unmittelbar darum kümmern, dass auf den Frontends wirklich auch virtuelle Maschinen laufen.

Auch die Virtualisierungs-Frontends müssen deshalb im Hinblick auf HA noch ein paar Besonderheiten beachten. Verschiedene Konzepte bieten sich an. Die einfachste Variante besteht darin, auf den Frontends eine Linux-Distribution einzusetzen, die KVM oder Xen beherrscht. Aus den Frontends wird dank Pacemaker ebenfalls ein Cluster.

Auf dem Laufenden

Mittels eines Konfigurationsverwaltungstools wie Puppet oder Chef ist dafür gesorgt, dass die notwendigen Konfigurationsdateien überall und immer auf dem aktuellen Stand sind. Der iSCSI-Cluster exportiert pro VM ein iSCSI-Target (im Beispiel weitere Devices analog zu »iscsivg01« ). Und der Pacemaker auf den Virtualisierungs-Frontends sorgt mit Colocation- und Order-Constraints dafür, dass die Pärchen aus iSCSI-Target und VM jeweils auf dem gleichen Host laufen. Ein Beispiel für die Anbindung eines iSCSI-Targets auf dem lokalen System findet sich weiter oben, wie VMs in Pacemaker zu integrieren sind, erklärte der vierte Artikel der Serie [1].

Wer es lieber bunter mag oder auf eine fertige Lösung für die Frontends zurückgreifen möchte, kann das ebenso tun. Sowohl VMware ESX als auch der weit verbreitete Citrix Xenserver können auf iSCSI-Devices als Datenquelle zurückgreifen. Mit der iSCSI-Lösung steht storage-seitig eine sehr vielfältige Lösung zur Verfügung. (jcb)

Die Linux-iSCSI-Targets

Ein Motto der FOSS-Bewegung ist, dass es mehr als einen Weg gibt, um etwas zu tun. Von dieser Regel machen die Entwickler auch bei iSCSI keine Ausnahme. So existiert nicht ein einzelnes iSCSI-Target, sondern es gibt gleich vier verschiedene, die um die Gunst der Admins buhlen.

Generische Storage-Targets

Dreh- und Angelpunkt von diversen Diskussionen, die sich um iSCSI und die dazugehörigen Targets abgespielt haben, ist die Frage, wie generisch ein iSCSI-Target sein soll. Oder anders: Soll ein Target außer iSCSI grundsätzlich auch andere Protokolle beherrschen? Und darf das im Prinzip so weit gehen, dass das eigentliche Target bloß noch dazu da ist, Plugins für verschiedene Protokolle zu laden – eines davon dann iSCSI?

Bei den Debatten auf verschiedenen Entwickler-Mailinglisten zeichnete sich ab, dass die Idee von generischen Targets die meisten Fans hat. Nicht zuletzt hat auch Linux-Erfinder Linus Torvalds in anderen Fällen schon einige Male festgehalten, dass er generische Frameworks im Kernel bevorzugt, um dann möglichst viele hochspezifische Treiber die gleichen Funktionen nutzen zu lassen. Ob ein Storage-Target zum Bestandteil des offiziellen Kernels wird, hängt also zum großen Teil auch davon ab, wie gut es sich an diese Vorgabe hält.

Der Veteran: IET

Den Anfang dieses Überblicks macht IET, das älteste Target. Die Abkürzung IET steht für iSCSI Enterprise Target. Der Name verrät bereits, dass es sich nicht um ein generisches Target handelt: IET kann nur iSCSI, und die Entwickler planen auch nicht, das zu ändern, weil sie dazu riesige Teile der Treiberstruktur umbauen müssten. IET basiert auf der Arbeit von Ardis, das vor einigen Jahren ebenfalls ein eigenes iSCSI-Target am Markt etablieren wollte, dann aber das Interesse daran verlor. Die Köpfe hinter IET sind derzeit vor allem Arne Redlich und Ross S. W. Walker. Lange beteiligt war auch Fujita Tomonori, der sich als eifriger Poster auf der LKML mittlerweile auch auf anderen Themengebieten einen Namen gemacht hat.

IET ist nicht Bestandteil des offiziellen Linux-Kernels. Die Lösung besteht aus einem Kernel-Modul und dazugehörigen Userland-Utilities. IET steht im Ruf, besonders stabil zu sein, und seine Entwickler sind sehr schnell, wenn es auftretende Probleme zu reparieren gilt. Außerdem ist die IET-Konfiguration verhältnismäßig leicht und lässt sich mittels eines Resource Agents für Pacemaker praktisch vollständig in der CRM des Cluster-Managers erledigen. Wer noch nicht mit iSCSI in Kontakt gekommen ist, findet mit IET einen guten Einstieg.

Der Klassiker: STGT

STGT ist ein zwar nicht von Red Hat entwickeltes, wohl aber von Red Hat sehr unterstütztes Storage-Target. Als Einziges der vier "großen" Targets ist STGT Bestandteil des Linux-Kernels, wobei die Aussage streng genommen so nicht stimmt: Der Teil von STGT, der im Kernel ist, hat für die eigentliche Funktion von STGT praktisch keinen Nutzen, sondern ist ein Stub. Sämtliche Funktionen wickelt STGT über die Userland-Programme ab, weshalb es in den meisten Benchmarks schlechter wegkommt als die anderen Targets, die sich in den Kernel einklinken. Im Gegensatz zu IET ist STGT ein generisches Target, das prinzipiell auch andere Protokolle als iSCSI zur Verfügung stellen kann. Im Gegensatz zu IET unterstützt STGT iSER – also iSCSI mitsamt RDMA.

Der aufsteigende Stern: LIO

Der Name LIO steht als Abkürzung für Linux-ISCSI.org. Gemeint ist ein generisches Storage-Target, das von den Linux-Entwicklern als Ersatz für STGT auserkoren worden ist. Anders als STGT spielt sich bei LIO der große Teil der Funktionen direkt im Kernel ab, ein passendes LIO-Modul im Kernel ist also Pflicht. Glücklich darf sich schätzen, wer von seinem Distributor einen Linux-Kernel 2.6.38 oder höher mitgeliefert bekommt; ab dieser Kernel-Revision ist LIO nämlich fester Bestandteil des Vanilla-Kernels.

Treibende Kraft hinter LIO ist die Firma Rising Tide, deren Anteil an der kürzlichen Mainline-Integration riesig ist. Wie üblich haben die Kernel-Entwickler die Patches der LIO-Leute nämlich nicht einfach ohne Murren akzeptiert, sondern viele, teils tiefgehende Änderungen erbeten.

LIO kommt mit einem iSCSI-Target, das SRP beherrscht und mithin auch Infiniband als Transportweg einsetzen kann – RDMA-Funktion inbegriffen. Auch Fibre Channel-HBAs von QLogic und LSI lassen sich mit LIO nutzen. Manche Funktionen sind bei LIO allerdings noch nicht so ausgereizt, wie man es sich als Admin wünschen würde. Die schon erwähnte SRP-Funktion ist hierfür ein gutes Beispiel: Bei Redaktionsschluss konnte LIO zwar SRP sprechen, im Rahmen eines Pacemaker-Clusters ließ sich die Funktion allerdings noch nicht nutzen – denn dafür fehlten ein paar Funktionen.

Der böse Bube: SCST

Schließlich ist noch SCST zu erwähnen: Auch bei SCST handelt es sich um ein Target mit Split-Design. Ein Teil der Funktionen liegt im Kernel, der Rest wird von entsprechenden Userland-Werkzeugen erledigt. SCST hat hohe Ansprüche an sich selbst: Auf der Website des Targets findet sich eine Vergleichstabelle, in der es für sich in Anspruch nimmt, das beste, schnellste und tollste Target zu sein. Sein Hauptentwickler, Vladislav Bolkhovitin, ist auf der LKML allerdings eher durch andere Ereignisse bekannt geworden, denn er fetzt sich dort regelmäßig mit den anderen Entwicklern. Die haben seinen Bestrebungen, SCST in den Mainline-Kernel zu hieven, dann bisher auch erwartungsgemäß eine Absage erteilt. Für schwache Nerven ist SCST aber ohnehin nichts: Um die versprochenen Performance-Gewinne zu erreichen, braucht es einen Kernel-Patch – und schon das dürfte SCST in vielen Firmen aus der engeren Wahl befördern.

Pacemaker-Integration

Die Pacemaker-Integration von iSCSI ist grundsätzlich gut. Florian Haas von hastexo hat schon 2009, damals noch bei LINBIT, zwei RAs auf OCF-Basis vorgestellt, die sowohl IET als auch STGT und LIO verwenden können. Lediglich die Unterstützung für SCST fehlt. Wer Pacemaker mit den anderen Targets betreiben möchte, ist aber fein raus.

Infos

  1. Martin Gerhard Loschwitz, "Eigene Clouds" ADMIN 05/2011, S. 98

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei hastexo. Er beschäftigt sich dort intensiv mit Hochverfügbarkeitslösungen.

comments powered by Disqus
Mehr zum Thema

iSCSI mit Linux

Virtualisierungslösungen und Cloud-Computing befeuern die Nachfrage nach Storage-Netzwerken, in denen mehrere Hosts auf gemeinsamen Plattenplatz zugreifen können, um so die Migration von VMs zu ermöglichen. Eine flexible und kostengünstige Alternative für ein solches Speichernetz bietet iSCSI. Dieser Beitrag behandelt en Detail die Installation und Administration verschiedener iSCSI-Implementierungen unter Linux.

Artikel der Woche

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 /2018