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.