© Melissa Schalke, 123RF

Mit Hyperstore will der Hersteller Cloudian den etablierten Cloudspeicher-Techniken wie Ceph oder Open Stack Swift die Nutzer abspenstig machen. Ein Pluspunkt ist schon mal ein benutzerfreundliches GUI, dagegen fehlt eine Anbindung an Open Stack Cinder.

Kaum ein Bereich der IT ist derzeit so stark im Umbruch wie der Storage-Markt. Bräsige Riesenspeicher nach dem SAN-Prinzip finden noch durchaus Abnehmer, aber Unternehmen, denen skalierende Setups vorschweben, schauen sich nach Alternativen um. Denn in genau dieser Hinsicht sind klassische Massenspeicher schlecht: Wenn erst einmal alle Plattenschächte innerhalb eines SAN voll sind, ist das Ende der Fahnenstange in Sachen Skalierbarkeit erreicht.

Die Preise, die Hersteller wie EMC oder Netapp für ihre Geräte abrufen, dämpfen die Popularität weiter. Oft genug benötigen SAN-Appliances speziell zertifizierte Hardware, und die lassen sich deren Hersteller in aller Regel teuer bezahlen.

Ceph, Gluster-FS & Co.

Die Zukunft gehört offenbar jenen Lösungen, die auf preiswerter Commodity-Hardware aufbauen und ihre Speichermagie durch Software erzeugen. Gleich mehrere Lösungen dieser Art haben in der Vergangenheit für Furore gesorgt: Ceph [1] und Gluster-FS [2] beispielsweise hat sich Red Hat mit jeweils viel Geld einverleibt.

Das amerikanische Unternehmen Cloudian steuert nun mit seinem Produkt Hyperstore [3] in die gleiche Richtung: Mit einer Nachimplementation des S3-Protokolls will Cloudian Admins skalierbaren Speicher für die Cloud bieten und so auch ein Stückchen vom neuen Storage-Markt abbekommen. Das Linux-Magazin hat sich das Produkt genau angesehen und stellt es im Folgenden vor.

Ein Objektspeicher als Grundlage

Auf seiner Produkt-Website [4] bietet Cloudian die Community-Variante des Hyperstore an, die alle wesentlichen Funktionen bietet, jedoch auf eine Gesamtgröße von 10 Terabyte beschränkt ist. Auf sie bezieht sich dieser Artikel. Die Grundlage der Lösung ist wie bei Ceph ein typischer Objektspeicher. Der unterscheidet sich ja von älteren Storage-Konzepten dadurch, dass er zwischen dem Dateisystem auf den Datenträgern und der Schnittstelle zum Nutzer eine zusätzliche Ebene einzieht: die Ebene der binären Objekte.

Objektspeicher hantieren also nicht mit Dateien, sondern betrachten diese als binäre Objekte, die bei Bedarf auch in kleine Teilobjekte zerlegbar sind. Aus einzelnen Fragmenten einer Datei, also den binären Objekten, lässt sich die ursprüngliche Datei später wiederherstellen. Der Vorteil: Die einzelnen binären Objekte können auf viele Platten irgendwo im System verteilt sein.

Bei Bedarf ist es möglich, neue Festplatten in neuen Servern darzustellen, um die Gesamtkapazität des Speichers zu erweitern. Der Umweg über binäre Objekte ist so die Voraussetzung dafür, dass Objektspeicher kontinuierlich in die Breite skalieren können. Und auf genau dieses Prinzip setzt auch Hyperstore.

Appliance oder Software

Wer Cloudian ausprobieren möchte, kann das Produkt von Hyperstore auf zweierlei Wegen beziehen. Variante eins ist eine fertige Appliance: Der Hersteller liefert in diesem Fall die gewünschte Speicherhardware gleich mit. Cloudian versichert allerdings, dass es sich tatsächlich um Commodity-Hardware handelt, die der Anbieter für seine Kunden lediglich in passender Weise zu fertigen Servern kombiniert. Das Hauptaugenmerk dabei liegt auf der Storage-Dichte: Bis zu 480 Terabyte bringt der Anbieter – laut eigener Aussage – in vier Höheneinheiten im Rack unter (Abbildung 1). Das ist durchaus beachtlich und zumindest mit klassischer Server-Hardware so nicht ohne Weiteres möglich.

Abbildung 1: Bis zu 480 Terabyte will Cloudian in einem einzelnen Knoten der Hyperstore-Appliances unterbringen. Das ist eine beachtliche Packungsdichte.

Wer die Hardware lieber selbst anschafft, greift alternativ zum Hyperstore Operating Environment. Hinter dem sperrigen Namen steckt eine reine Softwarelösung, die sich auf jedem System mit Centos 6.6 installieren lässt. Ärgerlich: Cloudian unterstützt mit Ausnahme des schon etwas angestaubten Centos 6.6 keine einzige der anderen Linux-Distributionen offiziell. Der Fokus auf Centos wäre noch damit zu erklären, dass sich das Produkt am amerikanischen Linux-Markt orientiert, wo Red Hat Enterprise Linux oder kompatible Distributionen wie eben Centos klar dominieren. Dass es aber unbedingt Centos 6.6 sein muss, gibt wohl manchem Admin zu denken.

Wer sich damit abgefunden hat, erhält von Cloudian im Gegenzug das Wunschlos-glücklich-Shellskript: Ein einzelner Befehl setzt den Cluster von Hyperstore passend auf und führt zu einem funktionierenden Massenspeicher (Abbildung 2). Die bereits erwähnte Vielzahl von Komponenten, die für den Betrieb von Hyperstore notwendig sind, kümmern zumindest beim Setup den Admin also praktisch nicht.

Abbildung 2: Mit Hyperstore kommt ein Installationswerkzeug, das aus Centos 6.6 einen fertigen Hyperstore-Knoten macht.

Verbindliche Preise für die einzelnen Varianten waren beim Hersteller nicht zu finden. Im Falle eines Falles müssen Unternehmen, die Hyperstore bei sich im Setup nutzen wollen, also direkt mit Cloudian verhandeln.

Das richtige Blech

Wer die Software nutzen und die Hardware selbst anschaffen will, beachtet am besten ein paar Grundregeln in Sachen skalierbarer Speicher. Denn erstens gilt, dass jeder Traffic zwischen Client und Storage sowie zwischen den einzelnen Knoten des Storage durchs Netz muss – das sollte also die nötige Bandbreite haben. Unter 10 GBit/Sekunde geht praktisch nichts, 25 GBit/Sekunde oder mehr wären zukunftssicher.

In Sachen RAM und CPU sollten die Rechner mit hinreichend großen Reserven ausgestattet sein, ähnlich wie Ceph oder andere Lösungen dieser Art erledigt auch Hyperstore einen Großteil seiner Arbeit auf der Host-CPU und dem dort vorhandenen RAM.

Wichtig: Hyperstore geht davon aus, dass die Hosts für den Speicher vom Rest der Plattform getrennt sind. Der Betrieb eines Hyperconverged Storage, bei dem der Speicherdienst und eine eventuell vorhandene Applikation (etwa Open Stack) auf derselben Hardware laufen, sieht Cloudian jedenfalls nicht vor.

Unter der Haube

Wer sich zum ersten Mal mit dem Innenleben von Hyperstore beschäftigt, wird über einige Komponenten stolpern, die im Cloudumfeld mehr oder weniger weit verbreitet sind. Hyperstore braucht wie jeder andere Vertreter der verteilten Systeme mehrere Dienste, um sinnvoll zu funktionieren, darunter etwa eine Cluster-weite Datenbank, die über den Zustand der Daten überall im Cluster Bescheid weiß. Hyperstore setzt hier auf die NoSQL-Datenbank Redis [5] und Apache Cassandra [6] und kombiniert gleich zwei entsprechende Dienste.

Das sind aber bei Weitem nicht die einzigen Komponenten, die zu einer Hyperstore-Installation gehören: Das Installationsskript von Hyperstore installiert gleich auch das Konfigurationsmanagement-Tool Puppet mit, das sich um die Installation der benötigten Software auf allen beteiligten Rechnern im Cluster kümmert. Selbst wenn Admins also ihren Hyperstore-Master auf einem Centos 6.6 installieren, bleibt vom eigentlichen Grundsystem wenig übrig.

Performance durch Parallelisierung

In Sachen Performance kann sich die Lösung durchaus sehen lassen, denn sie setzt wie andere Produkte der gleichen Art auf massive Parallelisierung von Lese- und Schreibzugriffen. Logisch: Die Schicht binärer Objekte sorgt schließlich dafür, dass beide Zugriffsarten stets auf viele physische Platten im Hintergrund gleichzeitig zugreifen, auf denen die einzelnen Objekte verteilt sind.

Gerade beim Durchsatz profitiert Hyperstore davon, mehrere Spindeln gleichzeitig zu nutzen. In Sachen Latenz wird es ebenfalls erwartbar durch Ethernet als Zugriffskanal ausgebremst. Bei NFS oder S3 ist das aber nicht so problematisch – denn die meiste Latenz entsteht so oder so auf dem Weg vom Nutzer zum Server.

Die Client-Seite: S3 oder NFS

Der schönste Speicher ist freilich nichts wert, wenn er keine Schnittstelle zum Nutzer bietet. Hyperstore lässt sich auf Client-Seite über zwei Protokolle ansprechen: via S3 oder über NFS. Das Hauptaugenmerk scheint jedoch auf der S3-Implementation von Hyperstore zu liegen – diese stellt Cloudian jedenfalls energisch in den Vordergrund.

Kernfunktion fehlt: Kein Speicher für Root der VM

So oder so gilt, dass Hyperstore eine Kernfunktion von Ceph und vergleichbaren Lösungen offensichtlich fehlt: Die Möglichkeit, als Backend-Storage für VMs im Hintergrund zu funktionieren. Oder anders formuliert: Eine virtuelle Maschine kann ihre virtuelle Root-Festplatte nicht in Form einer Partition oder eines Qcow2-Abbilds direkt in Hyperstore einrichten. Das S3-Protokoll ist nämlich für diesen Einsatzzweck ungeeignet und NFS ist viel zu langsam.

Damit scheidet Hyperstore im Grunde automatisch als General-Purpose-Speicher für Cloudinstallationen aus, denn es kann sich nun lediglich um den On-Demand-Storage einer Cloud gut kümmern. Für die Ablage von VM-Rootdisks muss zwangsläufig eine zweite Lösung her, was mehr administrativen Aufwand und Arbeit verursacht.

Im Gegenzug hat Hyperstore sich bei der Qualität der S3-Implementation aber nicht lumpen lassen. Der Hersteller verspricht “hundertprozentige Kompatibilität mit S3” – und das ist durchaus bemerkenswert. Den S3-Standard selbst hat Amazon nämlich nie offengelegt, nur eine ausführliche API-Beschreibung ist öffentlich auf der S3-Website zugänglich. Sämtliche am Markt vorhandenen S3-Implementationen außerhalb von Amazon sind im Wesentlichen auf der Basis dieser API-Dokumentation und per Reverse Engineering entstanden, was die zum Teil sehr großen qualitativen Unterschiede erklärt.

Ein gewisses Set an Grundfunktionen wie Up- und Downloads beherrschen aber praktisch alle Lösungen am Markt, etwa auch die S3-Umsetzung für Ceph, die auf den Namen Ceph Object Gateway oder Rados Gateway hört. Gerade weil eine öffentliche Dokumentation der vollständigen S3-Funktionalität fehlt, darf die von Hyperstore getroffene Aussage, sie sei hundertprozentig kompatibel mit S3, zumindest als zweifelhaft gelten.

Der S3-Modus ist möglicherweise vollständig kompatibel mit dem S3-API, auch das erwähnt Cloudian übrigens mehrere Male. Er beherrscht deshalb aber noch lange nicht jede Funktion, die in S3 verfügbar ist. Für alle alltägliche Aufgaben, die das S3-Protokoll nutzen, reicht es aber allemal.

Komfortables Management als oberste Maxime

Insgesamt zieht sich der Faktor einfache Bedienung wie ein roter Faden durch das gesamte Produkt Hyperstore. Hier hat die Lösung Alternativen wie dem omnipräsenten Ceph tatsächlich etwas voraus: Ist Hyperstore erst einmal auf allen beteiligten Hosts installiert, steht dem Admin die Cloudian Management Console (CMC) zur Verfügung. Das ist eine grafische Oberfläche, in der der Zustand aller Nodes und aller Festplatten ebenso grafisch aufbereitet darstellt ist wie der Status aller relevanten Dienste innerhalb des Clusters.

Das Management der vorhandenen Nutzer erfolgt genauso über die Managementkonsole wie das Festlegen von Storage-Policies oder die Verwaltung vorhandener Buckets (Untereinheiten des Objektspeichers). Hyperstore richtet sich also besonders auch an jene Unternehmen, die beim Storage nicht großartig hinter die Kulissen blicken wollen, sondern die lediglich eine leicht zu steuernde Lösung mit dennoch großem Funktionsumfang suchen.

Dazu gehört auch, dass Hyperstore diverse Self-Healing-Features kennt und selber nutzt. Interne Replikation ist mittlerweile Standard, auch bei Hyperstore ist jede im Cluster abgelegte Information mehrmals vorhanden. Der Ausfall einer einzelnen Festplatte sorgt also nicht dafür, dass das System stillsteht. Obendrein kompensiert Hyperstore den Ausfall von Festplatten durch automatische Re-Replikation: Wenn Speichergeräte ausfallen, gibt es innerhalb des Clusters ja automatisch binäre Objekte, deren Replikations-Vorgaben nicht mehr erfüllt sind. Nach einem konfigurierbaren Timeout kümmert sich Hyperstore automatisch darum, dass neue Replikate der betroffenen Objekte auf anderen Platten angelegt werden.

Geo-Replikation und Storage-Policies

Stark an Bedeutung gewonnen hat im Storage-Kontext die Bedeutung der Policies. Gemeint ist die Möglichkeit, Daten zu klassifizieren und auf Grundlage der festgelegten Klassen bestimmten Regeln zuzuordnen. Für eine Klasse könnte etwa festgelegt sein, dass sie dreifach repliziert ist, sodass jedes binäre Objekt in ihr Cluster-weit dreimal vorhanden sein muss. Die Objekte einer anderen Gruppe könnten einen niedrigeren Replikationswert haben.

Eine anderes alltägliches Beispiel ist die Idee, Speicherinhalte je nach Relevanz der Daten auf unterschiedlich schnelle Ziel-Festplatten zu verteilen. Auch die Antwort auf die Frage, wie viel Geld ein Kunde für die Leistung zahlen möchte, kann diese Entscheidung beeinflussen. Um all diese Eigenschaften auf der Storage-Ebene tatsächlich abbilden zu können, müssen entsprechende Policies die Datenspeicherung regeln.

Hyperstore ermöglicht genau das – vorrangig, damit Admins die Replikationseinstellungen im Hinblick auf spezifische Racks oder RZs fein granuliert einstellen können (Abbildung 3). Spannend: In Hyperstore ist es beim Hochladen von Dateien in den Objektspeicher möglich, für das jeweilige Bucket – also das “Fach” im Objektspeicher, in dem die jeweiligen Objekte landen – eine eigene Policy auszuwählen. In Ceph geht das jeweils nur auf der Administratorebene.

Abbildung 3: Mittels Storage-Policies lässt sich festlegen, wie Replikation in Hyperstore funktioniert.

Praktisch: Weil das Thema Latenz in Sachen S3 praktisch keine Rolle spielt, ist die Replikation an andere Standorte ohne Performance-Einbußen auf Seiten der Nutzer möglich. Entsprechend bietet Hyperstore diese Funktion auch an; das GUI hilft mittels eines eigenen Assistenten sogar dabei, passende Policies für Inter-RZ-Verbindungen (Abbildung 4) zu definieren.

Abbildung 4: Setups, die mehrere Rechenzentren überspannen, sind in Hyperstore vorgesehen und lassen sich per Storage-Policy einrichten.

Selbstverständlich offeriert Hyperstore über sein Managementwerkzeug auch die Funktion, den Cluster um neue Festplatten zu erweitern. Das geht im laufenden Betrieb und führt nicht automatisch dazu, dass der Cluster im Hintergrund eine umfassende Reorganisation der gespeicherten Daten unternimmt. Auch wenn neue Platten hinzukommen, bleibt der Cluster also performant.

Effiziente Nutzung des vorhandenen Platzes

Apropos neue Platten: Weil Hyperstore Erasure Coding unterstützt, sind die vielleicht gar nicht so oft nötig. Denn neben der klassischen Replikation ganzer Objekte ermöglicht Hyperstore auch Datenreplikation nach dem Prinzip von Raid-5. Anders formuliert: Kommt Erasure Coding zum Einsatz, organisiert sich Hyperstore intern so, dass die Replikate einzelner Objekte weniger als 100 Prozent der ursprünglichen Objektgröße auf der Platte an Speicher belegen. Wenn wegen des Ausfalls einer Platte ein Restore notwendig ist, errechnet sich Hyperstore stattdessen aus den vorhandenen Daten die fehlenden Informationen.

Letztlich sind Erasure Codes ein Kompromiss: Die Nettokapazität des Clusters steigt bei gleichbleibender Bruttokapazität; im Gegenzug nehmen Admins deutlich höhere Recovery-Zeiten in Kauf. Denn für den Restore muss Hyperstore im Falle von Erasure Coding einige Daten durch die Gegend schaufeln und benötigt obendrein einiges an Rechenleistung auf den betroffenen Systemen. Immerhin: Erasure Codes sind in Hyperstore optional. Wer also lieber die klassische Replikation will und auf schnelle Recovery-Zeiten angewiesen ist, aktiviert Erasure Coding erst gar nicht.

QoS und Billing nach Regelwerk

Zwei weitere Funktionen sind in Hyperstore für den alltäglichen Betrieb sehr interessant: Einerseits kann die Lösung Quality-of-Service-Regeln (QoS) umsetzen, andererseits bietet sie umfassende Billing-Funktionen.

Dass QoS in einem skalierbaren Speicher sinnvoll ist, leuchtet ein: Gerade im produktiven Betrieb wäre es unpraktisch, könnte ein einzelner Nutzer durch übertriebene Up- oder Downloads die Funktionalität des Clusters beeinflussen. Deshalb bietet Hyperstore verschiedene Metriken an, anhand derer sich das Verhalten von Nutzern steuern lässt: Beispielsweise im Hinblick auf den verursachten Traffic im Zeitraum x oder den Durchsatz über den Zeitraum y lassen sich Drosseln setzen. Sprengt ein Client die ihm gesetzten Grenzen, dann begrenzt Hyperstore diese Verbindung entsprechend.

Das funktioniert natürlich nur, weil Hyperstore intern das Monitoring und die Trendberechnung beherrscht. Denn von irgendwoher müssen die Daten für die genutzten Metriken schließlich kommen. Auch mit der eingebauten Billing-Funktion lassen sich das Nutzerverhalten detailliert nachvollziehen und genutzte Ressourcen entsprechend verrechnen.

Hybride Clouds

Schließlich sei noch das Hyperstore-Feature für hybride Clouds erwähnt: Die Hyperstore-Umgebung bietet die Möglichkeit, binäre Objekte per S3 nach festgelegten Regeln in einen anderen S3-Speicher zu verschieben. Das könnte etwa das echte Amazon S3 sein: Bestimmte Daten liegen dann auf dem lokalen Hyperstore während andere Informationen eventuell billiger bei Amazon landen.

Als beispielhaftes Einsatzszenario für diese Kombination erwähnen die Entwickler Tiering: Weniger häufig genutzte Daten könnten im langsamen S3 von Amazon landen, während der Hyperstore-Cluster Anfragen schneller bedient, dafür aber auch einen höheren Preis pro GByte hat. Das gesamte Regelwerk für diese Vorgänge ist innerhalb des Hyperstore-GUI zu erreichen.

Wertung und Fazit

Eine Lösung wie Hyperstore wandelt auf einem schmalen Grad. Einerseits ist der Speichermarkt durch Produkte wie Ceph oder Gluster-FS aktuell schon gut mit freien Lösungen versorgt. Die Produkte unter Red Hats Ägide werben ja geradezu damit, zu 100 Prozent Open-Source-Software zu sein. Deren Kunden zahlen im Gegenzug auch nur für den Support, den sie vom Anbieter vielleicht brauchen. Hyperstore geht einen anderen Weg: Es ist nicht quelloffen und ohne den Einwurf von großen Münzen lediglich in der Community-Variante zu verwenden, deren praktischer Nutzen durch das 10-Terabyte-Limit allerdings begrenzt ist. Wer Hyperstore produktiv und sinnvoll nutzen will, braucht eine entsprechende Lizenz.

Genau hier wird die Sache kompliziert: Auf den ersten Blick beherrscht die Cloudian-Lösung keine Funktionen, die der Platzhirsch Ceph nicht ebenfalls bereitstellt. Denn eine S3-Implementation hat Ceph auch – die entsprechende Komponente heißt Ceph Object Gateway oder Rados Gateway. Die Ceph-Autoren werben zwar nicht mit hundertprozentiger S3-Kompatibilität, im Alltag hat sich die Qualität der Ceph-S3-Umsetzung aber als gut funktionierend erwiesen.

Im Gegensatz zu Ceph fehlt Hyperstore gar eine wichtige Funktion, weil sich das Cloudian-Produkt nicht als General-Purpose-Speicher in Clouds nutzen lässt. Wer etwa eine Open-Stack-Cloud betreiben möchte, kann Hyperstore für S3 auf Kundenseite nutzen – denn mit Keystone, der Open-Stack-Komponente für die komplette Nutzerverwaltung, kommt Hyperstore zurecht. Aber für das Hosting virtueller Maschinen ist dann in jedem Falle eine weitere, zweite Speichertechnik nötig, weil sich Hyperstore gerade nicht als Speicher an Open Stack Cinder anbinden lässt.

Tatsächlich ist Hyperstore also umgeben von diversen Lösungen, die zumeist einen größeren Funktionsumfang haben (Ceph) oder exakt die gleichen Ziele wie Hyperstore selbst verfolgen (Open Stack Swift), dabei aber den Vorteil haben, kostenlos zu sein. Den einen, den schlagenden Grund dafür, Hyperstore zu nutzen, liefert Cloudian leider nicht. Außer vielleicht in jenen Fällen, in denen Kunden wie bisher die gesamte Speicherlösung von einem Anbieter kaufen wollen, ohne sich mit Details zu beschäftigen und ohne die Vorteile massiv skalierbarer Speicher zu verlieren.

Für jene Einsatzzwecke ist die Hyperstore-Appliance eine gute Alternative, zumal sie mit einem GUI daherkommt (Abbildung 5), das mit dem GUI vieler ANs in Sachen Funktionalität und Komfort auf Augenhöhe ist. Im direkten Vergleich mit dem Ceph-GUI Calamari trumpft das Hyperstore-GUI jedenfalls wie David gegen Goliath auf.

Abbildung 5: In seinem GUI bietet Hyperstore ein schönes und übersichtliches Werkzeug, um aktuelle Nutzungsstatistiken anzuzeigen.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.