© avian, 123RF.com

Glaubt man Red Hats Marketing, dann hat das Unternehmen mit der Version 2.1 seines Storage Servers das Speichern von Daten nicht weniger als revolutioniert. Die Wirklichkeit schaut anders aus.

Dass Admins es mit einem waschechten Hype zu tun haben, erkennen sie sicher daran, dass sich im Kielwasser einer Technologie häufig auch andere, weitaus dubiosere tummeln. Die Cloud ist hierfür ein gutes Beispiel: Aus dem Schatten der verschiedenen “As a Service”-Lösungen traten Projekte hervor, die bestimmte Funktionen in Software implementieren, von denen es bis dato in der Regel nur Hardware-Umsetzungen gab. “Software Defined Everything” lautet das Marketingcredo.

Enterprise-Cloudstorage hat so seine Nachteile

Zunehmend in den Fokus der IT-Gemeinde rückt derzeit auch Software Defined Storage: Im Wesentlichen will SDS Storage nicht mehr in Form typischer SANs betreiben, sondern die Speicherarbeit von Software auf Commodity-Hardware erledigen lassen. Viele SANs und klassische Single-Instance-Storages kommen ja bisweilen mit eher unangenehmen Begleiterscheinungen daher.

Die nachhaltigste davon ist der Lock-in-Effekt: Er bindet den Kunden langfristig an einen einzelnen Hersteller. Will der Kunde seinen Storage erweitern, so muss er das mit Hardware vom Hersteller tun, der den Preis diktieren kann. Auch zusätzliche Features lassen sich IBM, Netapp und Konsorten ordentlich vergüten – selbst dann, wenn ein neues Feature nicht mehr ist als nur das Freischalten einer Funktion der SAN-Firmware.

Red Hat steigt in den lukrativen Markt ein

Seit 2013 gibt es vom Milliardenkonzern Red Hat ein Produkt, das es Unternehmen ermöglichen soll, dem Lock-in zu entkommen: Der Red Hat Storage Server (Abbildungen 1 und 2, [1]). Funktional orientiert er sich an klassischen Storages – im Hintergrund lagern Daten auf einem Blockspeicher, nach außen hin exportiert das Device Daten über verschiedene Interfaces wie Fibre Channel, I-SCSI, NFS oder Samba. All diese Funktionen lassen sich in Software ziemlich leicht realisieren, natürlich auch auf Basis von freier Software.

Abbildung 1: Red Hat bietet den RHSS als Testdrive in VMs an, die auf Amazons AWS gehostet sind.

Abbildung 2: Wer den RHSS testen möchte, gelangt über einen eigens generierten SSH-Schlüssel auf die VMs und kann in einem virtuellen Umfeld testen.

Wenig überraschend war Red Hat keineswegs das erste Unternehmen mit der Idee, daraus ein Produkt mit Enterprise-Level-Support zu stricken, auch nicht mit dem Versprechen, dem Lock-in-Effekt bei SANs ein Schnippchen zu schlagen. Schon länger ist das Wiener Unternehmen Linbit auf dem gleichen Markt mit DRBD [2] aktiv, auch andere Firmen haben SANs in Software nachgebaut.

Open-Stack-Cloudspeicher

Dass sich mit einem weiteren Produkt dieser Art nur schwerlich ein Blumentopf gewinnen lässt, musste Red Hat also klar sein. Und so baute das Unternehmen in den Red Hat Storage Server (RHSS) einige zusätzliche Features ein, die den Funktionsumfang klassischer Storages tatsächlich übertreffen – das Marketing der roten Hüte spricht von “nahtloser Skalierbarkeit” und “perfekter Anbindung an die Cloud”.

Damit wird klar, in welchem Kundenbecken Red Hat mit RHSS fischen will: Big Data, massiv skalierbarer Speicher – kurzum im Speicher für die Cloud. Die im September erschienene RHSS-Version 2.1 bewirbt Red Hats PR-Apparat beispielsweise mit deren guter Open-Stack-Anbindung.

Das ist insofern beachtlich, da Red Hat den Open-Stack-Trend lange Zeit konsequent verschlafen hat und sehr spät überhaupt in die Open-Stack-Entwicklung eingestiegen ist. Die Amerikaner aus Raleigh haben dazugelernt und mausern sich eigenen Angaben zufolge zum “Top Committer” bei Open Stack.

Viele alte Bekannte auf der RHEL-Basis

Im Test zeigt sich der RHSS 2.1 auch schnell als ein Ansammlung von guten alten Bekannten. Als Grundlage dient dem System Red Hats eigenes Betriebssystem für Unternehmenskunden RHEL. Das liegt nahe, weil das Enterprise Linux die Basis für fast alle Enterprise-Produkte von Red Hat bildet und sich jederzeit in einem zertifiziert ordentlichen und sicheren Zustand befindet.

Mit dieser Eigenschaft geht einher, dass sich auch RHSS nahtlos in alle bekannten Enterprise-Dienste von Red Hat integrieren lässt, selbstverständlich auch in das Remote-Management und die Update-Verwaltung. Um RHSS zu einer modernen und leistungsstarken Komponente zu machen, bedarf es allerdings einer Zusatzkomponente.

An dieser Stellt kommt Gluster-FS ins Spiel (Abbildungen 3 und 4). Red Hat hatte die Firma Gluster Ende 2011 gekauft [3] und sich deren einziges Produkt, Gluster-FS, damit einverleibt. Kurz darauf krempelte Red Hat das Projekt in weiten Teilen um, installierte ein Release- und Feature-Management und ließ eigene Entwickler an neuen Funktionen für den verteilten Speicher arbeiten.

Abbildung 3: Intern setzt RHSS auf Gluster-Software. Dementsprechend viele Gluster-Befehle bieten sich an, um den Storage zu verwalten.

Abbildung 4: Auch das Anlegen eines neuen Volume erledigt der Admin über die vorhandene Infrastruktur für Gluster-FS.

Gluster-FS in Vollendung

In Form des RHSS erreicht Gluster-FS nun gewissermaßen seine Vollendung, ist es doch die Kernkomponente von RHSS und von elementarer Bedeutung für das Produkt. Auf den ersten Blick kommt Gluster-FS im RHSS als Standardversion daher, also in der Version, die auf der Gluster-FS-Website auch öffentlich zur Verfügung steht. Man darf aber wohl mit hoher Wahrscheinlichkeit davon ausgehen, dass der RHSS Vorfahrt bei der internen Entwicklung hat und Fixes erst für den RHSS gebaut werden, bevor sie später in den offiziellen Tree von Gluster-FS einfließen.

Damit erbt der RHSS alle Funktionen von Gluster-FS: Mindestens zwei Knoten sind für einen redundanten Speicher notwendig, wobei dieser redundante Speicher eine Vielzahl Storage-Spielarten ermöglicht. Gluster-FS kann über die so genannten Translators beispielsweise replizierte – also gespiegelte – Volumes verwalten, Volumes mit Striping funktionieren ebenso, und nicht zuletzt beherrscht Gluster-FS auch verteiltes Speichern. Überdies lassen sich diese Speichermodi kombinieren, sodass beispielsweise ein repliziertes verteiltes Volume für Gluster-FS kein Problem darstellt.

Client-Frontends

In Sachen Frontends hat Red Hat Gluster-FS in den letzten Monaten spürbar weiterentwickelt. Neben dem nativen Gluster-FS-Fuse-Treiber bietet Gluster-FS auch ein NFS-Frontend an, das den NFSv3-Zugriff erlaubt. Im RHSS bietet Red Hat zudem die Möglichkeit, vorhandene Gluster-FS-Volumes so über ein vorinstalliertes Samba zu exportieren, dass auch Windows-Hosts darauf zugreifen können. Leider hat Red Hat sich für den RHSS nicht die Mühe gemacht, das als Betaversion schon vorhandene Samba-VFS-Modul in Gluster [4] zu integrieren – damit könnte das Gluster-FS-Dateisystem selbst Samba-Exporte erzeugen, ohne auf Samba angewiesen zu sein.

Objektzugriff

Red Hat bewirbt seinen Storage Server auch mit der Funktion des so genannten Objektzugriffs. Der Begriff ist ziemlich wolkig und bezieht sich auf einen Trend, nach dem Speicherdienste nativ ein Restful Interface anbieten, über das die Benutzer Dateien hochladen. Anders formuliert soll der RHSS auf diese Weise ein vollwertiges Äquivalent zu Amazons S3 oder Googles Drive werden, bei dem Benutzer Dateien über ein Webinterface auf den Speicher laden.

UFO: Unified File and Objectstore

Auch hierbei hält Red Hat an Gluster-FS fest und setzt auf den UFO-Ansatz: Der Unified File and Objectstore beschreibt eine Technik, bei der der Swift-Proxy von Open Stacks Objectstore Swift (Abbildung 5) im Hintergrund Daten auf Gluster-FS ablegt statt auf Swifts eigenen Ring-Servern. An diesem Patch hat Red Hat maßgeblich gearbeitet und dazu beigetragen, dass es stabil wird und die benötigte Funktionalität ihren Weg in Gluster-FS findet.

Abbildung 5: Über den Swift-Proxy, der eigentlich zu Open Stack und gar nicht zu Gluster gehört, bietet Gluster-FS dem Anwender Objektzugriff an.

Im RHSS liefert Red Hat ein passend gepatchtes Gluster-FS und ein vorbereitetes Open-Stack-Modul von Swift aus, damit sich die Objectstore-Funktion schnell nutzen lässt. Letztlich ist es Anwendern möglich, über das Open-Stack-Swift-Protokoll direkt auf die Daten zuzugreifen, Clients wie Cyberduck [5] bieten sich hierfür an.

Geo-Replikation

Red Hat legt in seiner Werbung besonders viel Wert darauf, das Feature für Geo-Replikation zu betonen. Es soll Gluster-FS um die Option für standortübergreifende Failover-Szenarien erweitern. Fällt ein komplettes RZ aus, weil es unter Wasser steht, bleiben die Daten verfügbar, weil die Software bereits zuvor per Geo-Replikation alles auf Gluster-Ebene in ein anderes RZ kopiert hat. Ein simpler Failover auf DNS-Ebene oder per BGP würde dafür sorgen, die eingehenden Anfragen an das andere Rechenzentrum weiterzuleiten, wo ein etwaiges Setup auf Grundlage der aktuellen Daten die Funktionen der Plattform anbietet, als sei nichts gewesen.

Auch Geo-Replikation ist eine Gluster-FS-Kernfunktion, die RHSS nur geerbt hat. Leider auch eine unschöne Begleiterscheinung: Ein Follow-the-Sun-Szenario ist mit der Geo-Replikation von Gluster-FS nämlich nicht möglich. Nach dem Failover von einem Rechenzentrum woanders hin muss der Speicher der “alten” Seite von der “neuen” Seite einmal komplett neu synchronisiert werden – so als seien die Daten am alten Standort auch physikalisch unbrauchbar geworden, selbst wenn das nicht der Fall ist. Dennoch ist die Geo-Replikation ein nützliches Feature um Desaster-Szenarien passend vorzubeugen.

An der Gretchenfrage, ob bunte GUIs nötig oder nur lästig sind, scheiden sich die Geister. Die Verwaltungswerkzeuge der klassischen SAN-Storages erfreuen sich großer Beliebtheit, die Hersteller der Geräte führen ihre ausgefeilten Managementwerkzeuge gern als Argument für die eigene Technik ins Feld.

Eingefleischte Admins fühlen sich hingegen meist auf der Kommandozeile wohl und können mit grafischen Werkzeugen wenig anfangen. Für sie ist RHSS die optimale Lösung, denn irgendeine Art von grafischem Konfigurationswerkzeug ist beim Storage Server von vornherein nicht vorgesehen. Der Administration Guide für RHSS ist fast 200 Seiten stark und erläutert detailliert, wie sich bestimmte Funktionen nutzen und konfigurieren lassen; zum Einsatz kommt dabei allerdings ausschließlich die Kommandozeile. Der RHSS richtet sich also zumindest aktuell an erfahrene Storage-Profis, die lieber mit der Tastatur arbeiten.

Open-Stack-Kompatibilität

Red Hat hat in den letzten Monaten die Entwicklung verschiedener Open-Stack-Komponenten stark vorangetrieben, damit diese auch Gluster-FS unterstützen. Die Gluster-FS-Integration in Nova, Open Stacks Computing-Komponente, kommt beispielsweise direkt aus Raleigh, ebenso das Patch für Qemu, das Gluster-FS ohne umständlichen Mount als Storage-Backend für virtuelle Maschinen möglich macht. Und dann ist da noch Cinder, das mittlerweile ebenfalls ein Gluster-FS-Backend hat. Mehr zu den Modulen und ihrer Gluster-Integration findet sich auf der Open-Stack-Webseite http://6.

Dank all dieser Features funktioniert ein Gluster quasi als Storage-Tausendsassa für Open Stack mit direktem Anschluss an die wichtigen Komponenten. Dass diese Integration gewollt ist, beweist auch die sehr ausführliche Doku zum Thema “RHSS und Open Stack” im RHSS-Guide (Abbildung 6).

Abbildung 6: Unzertrennbar verbunden, geht es nach Red Hat, sind Open Stack und der Red Hat Storage Server als Storage-Backend.

Wer soll das bezahlen?

Nach einigen Testtagen kam auch die Preisliste aus Red Hats Deutschland-Niederlassung im Testlabor des Linux-Magazins an – ungläubiges Stirnrunzeln, glaubten manche Tester doch zunächst an ein Missverständnis. Laut Liste schlägt ein Zwei-Knoten-Cluster mit Support an Werktagen bereits mit mehr als 9000 Euro zu Buche; der gleiche Cluster mit 24×7-Support liegt bei 14000 Euro. Realistisch wird allerdings niemand einen Cloudstorage mit nur zwei Knoten betreiben, geht man von vier Storage-Hosts aus, dann kostet die 1-Jahres-Lizenz mit 24×7-Support bereits 26000 Euro. Wer gleich auf einen 3-Jahres-Kontrakt umschwenkt, zahlt für das gleiche System fast 70000 Euro.

Wohlgemerkt: Die Preise beziehen sich ausschließlich auf die Lizenz für den Red Hat Storage Server. Die notwendige Hardware dürfte die Kosten für die Lösung nochmals in die Höhe katapultieren. Vor diesem Hintergrund erscheint es sogar fraglich, ob rechnerisch überhaupt ein Vorteil übrig bleibt, wenn Kunden statt auf klassische SANs auf den RHSS setzen. Ob Red Hat ebenso über ähnlich aggressive Rabattstrategien wie die Konkurrenz (die damit in letzter Zeit viele Geräte unters Volk bringen konnte) setzen wird, ist noch nicht bewiesen.

Es stellt sich die Frage, ob die stattlichen Preise denn überhaupt angemessen sind oder ob der Hersteller hier den Bogen nicht einfach überspannt. Zwar hat Red Hat einige Arbeit unmittelbar in die Entwicklung der Komponenten gesteckt, die nun integrale Teile des RHSS sind. Doch sind jene Komponenten eben auch ohne RHSS frei auf den jeweiligen Projekt-Websites verfügbar. Admins können sie sogar ganz ähnlich miteinander kombinieren und so einen RHSS nachbauen (der Kasten “Ein RHSS im Eigenbau” nennt die Details), ohne dafür Tausende Euro loszuwerden.

Ein nachgebauter Storage Server unterscheidet sich – das sollte an dieser Stelle nicht fehlen – freilich in einem maßgeblichen Punkt von einem echten RHSS: Letzterer kommt mit einem Supportvertrag, der im Falle von Schwierigkeiten dem Admin die Möglichkeit bietet, bei Red Hat um Hilfe zu bitten. Da Gluster-FS die Kernkomponente des RHSS ist und Red Hat Gluster gekauft hat, erhalten Supportkunden also die Unterstützung direkt vom Gluster-Upstream. Besser geht’s nicht.

Ein Ruhmesblatt ist das für Red Hat aber dennoch nicht, belegt die Preisgestaltung doch, dass Red Hat selbst kaum liberaler handelt als die SAN-Anbieter, die das Unternehmen in der PR für den RHSS massiv kritisiert. Auch bei denen entfällt ja ein stattlicher Teil der Kosten auf den notwendigen Support, ohne den ein Profi-Storage gar nicht zu bekommen ist. Red Hat bewirbt den RHSS zwar für den Einsatz auf Hardware von der Stange, langt aber beim Support genauso hin wie die ach so teure Konkurrenz.

Wer sich den RHSS genauer anschauen will, bevor er eine Stange Geld dafür ausgibt, hat dazu übrigens in einem Testdrive [7] die Gelegenheit. Red Hat bietet auf AWS gehostete VMs an, die einen Eindruck von den Fähigkeiten des RHSS vermitteln sollen (Abbildungen 1 und 2). Per Mausklick startet ein komplettes RHSS-Setup aus sechs Speicherknoten, auf dem der Tester dann die einzelnen Gluster-FS- und Swift-Funktionen ausprobieren kann. Eine sehr ausführliche Anleitung erläutert, wie das funktioniert; sie steht im Testdrive-GUI ebenfalls zur Verfügung.

Insgesamt kann ein Tester sich 15 Stunden lang RHSS aus der Nähe anschauen, wobei die 15 Stunden in drei eigene Testläufe aufgeteilt sind, die jeweils nicht länger als fünf Stunden dauern dürfen.Die Registrierung für den Test kann übrigens einige Zeit in Anspruch nehmen; offensichtlich müssen die Anmeldungen zum Test auf irgendeine Weise händisch verarbeitet werden. Die Redaktion erhielt ihren Zugang ungefähr zwölf Stunden nach der Anmeldung (immerhin nur ein Viertel des angekündigten 48-Stunden-Zeitraums). Die Zugänge bearbeitet wohl ein Kollege in den USA – das Passwort ging mitten in der Nacht ein.

Praktisch ist im Rahmen des Testdrive, dass Red Hat nicht nur VMs für die Serverkomponenten zur Verfügung stellt, sondern auch Clients auf Basis von Windows und Linux. Linux nutzt Fuse, um Gluster-FS-Mounts lokal zu aktivieren; der Windows-Client verwendet hingegen SMB, um auf Gluster-FS-Dateien zuzugreifen. Beide Mechanismen lassen sich im Rahmen des Testdrive entsprechend nachvollziehen.

Fazit

Red Hat liefert mit dem Storage Server technisch solide Arbeit ab. Auf dem Fundament RHEL bekommt der Benutzer im RHSS Gluster-FS und Open Stack Swift, die auch gemeinsam laufen können und so alle Speicherdienste anbieten, die Open Stack benötigt. Dass Red Hat selbst viel Arbeit in eben jene Dienste investiert hat, ist der Firma hoch anzurechnen, denn sowohl der RHSS wie auch die Projekte selbst profitieren von diesen Verbesserungen in erheblichem Maße – auch fernab von Red Hats eigenen Produkten ist Gluster-FS qualitativ viel besser geworden, besonders in den vergangenen anderthalb Jahren.

Eingedenk des Preises, den Red Hat für das Produkt aufruft, reichen Solidität und Fleiß allein nicht. Überhaupt ist fraglich, ob Red Hat den RHSS so aufbohren könnte, dass ein Preis von über 9000 Euro für ein System mit zwei Knoten angebracht wäre. Abgesehen von Gluster-FS und Swift sowie Samba enthält das Produkt augenblicklich keine Zusatzkomponenten – also auch nichts, das ein eventuelles Alleinstellungsmerkmal sein könnte, etwa eine einfach zu nutzende Konfigurationsoberfläche.

Stattdessen betätigt sich der Admin als Kommandozeilen-Jockey, was in vielen Fällen gar nicht unerwünscht sein dürfte. Allein: Für diese Erfahrung muss niemand so viel Geld auf den Tisch legen.

Technisch ist ein vergleichbarer Cluster auf Basis von Ubuntu oder Suse in kürzester Zeit nachbaubar. Was als Unterschied bliebe, wäre der Support, der bei Red Hat im Preis enthalten ist. Nachdem Gluster-FS mittlerweile zu Red Hat gehört, kommt der Support quasi vom Upstream.

Es bleibt jedenfalls der fade Beigeschmack, dass die Preise für den RHSS auf jene Kunden abzielen, die ansonsten ein SAN gekauft hätten und auf Supportverträge aufgrund interner Vorgaben zwingend angewiesen sind. Im direkten Vergleich mit einem SAN sparen sie zwar noch immer Geld, weil sie nicht auf spezielle Hardware angewiesen sind, ein Schnäppchen ist der RHSS aber wahrlich nicht (mfe).