© unopix, 123RF

Wer Cloudumgebungen baut, braucht nicht nur eine skalierbare Infrastruktur, sondern auch eine performante Storagekomponente. Zu den relevanten Speicherlösungen, die dieser Schwerpunkt vorstellt, gehört auch der Newcomer Ceph, der als Objectstore für die Cloud ein schönes Paar mit Open Stack abgibt.

So sehr “Cloud” als Buzzword abgedroschen ist, der Popularität vor allem für Unternehmen tut dies keinen Abbruch: Open Nebula, Open QRM oder Eucalyptus sind bekannte Vertreter von Enterprise-Clouds. Keine Lösung steht aber zurzeit so im Mittelpunkt der Aufmerksamkeit wie Open Stack, das aus einer Kooperation der amerikanischen Raumfahrtbehörde Nasa und des US-Hosters Rackspace hervorging.

In den letzten zwei Jahren hat sich das Projekt vom Underdog zum Standard gemausert, ziehen die Open-Stack-Konferenzen deutlich mehr Besucher an als viele traditionelle Community-Events. Selbst die Verantwortlichen der Open Stack Foundation [1] sind vom Erfolg überrascht. Unternehmen evaluieren ihre Cloudlösungen häufig bereits mit Präferenz für Open Stack (siehe Kasten “Open Stack im Unternehmen”).

Das leidige Thema Speicher

Allen Cloudsystemen ist gemein, dass sich der Admin beim Planen für das Setup der Wolke mit dem Thema Speicher befassen muss – Open Stack macht hier keine Ausnahme. Der Einsatz klassischer Storagesysteme greift im Cloud Computing wegen zweier Faktoren zu kurz: Skalierbarkeit und Automatisierung.

Während ein Admin klassischen Storage in automatisierte Abläufe einbinden kann, lässt sich das Thema Skalierbarkeit schwieriger beherrschen: Steht ein SAN erstmal im Rack, wird eine mögliche Erweiterung häufig teuer, wenn sie überhaupt noch umsetzbar ist.

Für den Anbieter einer Public Cloud kommt erschwerend hinzu, dass er den benötigten Plattenplatz kaum voraussagen kann. Aus dem Bedarf der letzten Zeit vermag er zwar ein wahrscheinliches Wachstum zu errechnen, was aber wenig hilft, wenn plötzlich ein neuer Kunde auftaucht, der von jetzt auf gleich 5 TByte Speicherplatz für seinen Imagehosting-Dienst benötigt. Wie die Computing-Komponenten muss der Anbieter auch den Cloudspeicher unkompliziert erweitern dürfen, und hier kommt die freie Software Ceph ins Spiel.

Ceph regiert

Der Quellcode des verteilten Dateisystems Ceph [3] steht größtenteils unter LGPL und BSD-Lizenz. Die Software gilt zurzeit als ein heißes Eisen in der Storage-Szene, weil sie genau diese Fähigkeiten in sich vereint. Dank ihrer Features könnte Inktank, der Anbieter der Storagelösung, alteingesessenen Unternehmen wie EMC und Netapp Marktanteile streitig machen.

Ein vorhandener Ceph-Cluster lässt sich problemlos um zusätzliche Platten erweitern. Die dürfen auch in neuen Computern stecken, denn zum Einsatz kommt ausschließlich Commodity Hardware. Normale SATA-Platten ergänzen den Verbund, was dem Projektbudget deutlich weniger wehtut als eine (meist sehr viel kleinere) SAS-Platte.

Den Admins hilft es, dass Inktank in den letzten Monaten die reibungslose Integration von Open Stack und Ceph vorangetrieben hat und gewissermaßen schon ab Werk darauf schaut, dass Open Stack die Funktionen von Ceph optimal nutzt. Um den idealen Einsatzort von Ceph und Open Stack zu ermitteln, hilft ein Blick darauf, was die Open-Stack-Komponenten an Daten verarbeiten und wie sie mit Speicher umgehen.

Wer speichert was?

Bei Open-Stack-Diensten fallen im Prinzip zwei Arten von Daten an: Metadaten und die tatsächlichen Nutzdaten. Technisch umfassen die Metadaten die Cloud-spezifische Konfiguration. Um sie kümmert sich in der Regel eine eigene Datenbank, etwa MySQL. Die meisten der in Open Stack zu Virtualisierungszwecken eingesetzten Dienste speichern langfristig ausnahmslos Metadaten, dazu gehören Keystone (Identity Service), Neutron (Network as a Service), Heat (Orchestration) und Ceilometer (Monitoring).

Das Open-Stack-Dashboard alias Horizon legt keine Daten an, weder Metadaten noch tatsächliche Nutzdaten. Einen Sonderfall bildet auch der Compute-Service Nova: Die Komponente kümmert sich um die Verwaltung virtueller Maschinen. Sie legt neben persistenten Metadaten temporäre Images von virtuellen Maschinen ab. Flüchtig sind die Images von VMs in Open Stack quasi per Definition, im Fachjargon ist von “Ephemeral Storage” die Rede. Will Nova eine VM langfristig speichern, muss es die Hilfe eines zusätzlichen Dienstes beanspruchen.

Bleiben noch die beiden Dienste Glance und Cinder, die neben ihren eigenen Meta- auch Nutzdaten ablegen. Glance heißt der Imagedienst. Er soll Abbilddateien redundant anbieten, aus denen sich neue VMs starten lassen. Cinder ist der eben erwähnte Dienst für Blockstorage, der Nova zu Hilfe eilt, wenn die VMs persistenten Speicher benötigen. Es gilt also, Ceph mit diesen beiden Dienste zu verheiraten, um eine optimale Open-Stack-Integration zu erreichen.

Swift versus Ceph

Wer sich bereits ein wenig mit Open Stack beschäftigt hat, stellt sich vermutlich die Frage, welche Rolle Swift in diesem Szenario spielt, Open Stacks hauseigener Speicherdienst. Es wirkt auf den ersten Blick widersinnig, eine externe Lösung zu integrieren, wenn Open Stack eine vermeintlich vergleichbare Funktion anbietet. Das Schlüsselwort lautet “vermeintlich”, denn tatsächlich gibt es zwischen Swift und Ceph ein paar große Unterschiede.

Die Gemeinsamkeiten dagegen sind schnell erzählt: Wie Ceph ist auch Swift ein Objectstore, speichert Daten also in Form binärer Dateien ab und ermöglicht so das Skalieren des Speichers in die Breite. Das native Swift-Interface stellt ein API bereit, das sowohl das hauseigene Swift-Protokoll versteht als auch Amazons Simple Storage Service (S3). Auf Ceph-Ebene erreicht der Admin ein vergleichbares Verhalten, wenn er zusätzlich das Ceph-Gateway [4] einsetzt. Das bietet fast die gleichen Funktionen wie der Swift-Proxy.

Frappierend sind jedoch die Unterschiede zwischen beiden Lösungen. Das beginnt damit, dass Ceph unter der Haube ganz anders tuckert als Swift: Die komplette Crush-Funktionalität (Controlled Replication under Scalable Hashing), die sich in Ceph um das Aufteilen und Verteilen von Daten auf verschiedene Platten kümmert, fehlt Open Stacks nativem Objektspeicher.

Vielmehr entscheidet Swift auf Grundlage eines eigenen Algorithmus, welche hochgeladene Datei wo genau landet. Eine Aufteilung oder ein gleichzeitiges Lesen einzelner Objekte von mehreren Zielservern findet nicht statt. Wer also von einem Swift-Cluster Daten liest, tut dies stets von einer einzelnen Platte und ist Performance-seitig auf das beschränkt, was jene Platte liefert.

Nicht zuletzt unterscheiden sich Ceph und Swift auch in der Anzahl der angebotenen Interfaces, denn Swift spricht außer den beiden genannten Protokollen, die nach dem Restful-Prinzip arbeiten, keine weitere Sprache.

Zum Ceph-Gateway gesellt sich hingegen der RDB-Treiber (Rados Block Device), der sich entweder über das Kernelmodul »rbd« oder über die RBD-Bibliothek in Stellung bringen lässt. Ceph bietet damit ein Interface auf Blocklevel-Ebene und eignet sich so unmittelbar als Blockspeicher für virtuelle Maschinen. Diese Möglichkeit fehlt Swift völlig, erweist sich im Open-Stack-Kontext aber als wichtig.

Die Konsistenzfrage

Schließlich wäre da noch die Datenkonsistenz. Ceph setzt auf ein Konzept, bei dem alle Daten immer zu 100 Prozent konsistent sind. Dazu nutzt es intern verschiedene Funktionen, welche die Integrität der eingesetzten Daten schützen. Zusätzlich erzwingt es ein Quorum: Bricht ein Ceph-Cluster auseinander, bleiben nur jene Teile funktionsfähig, die sich in der Mehrheitspartition befinden, die also die Mehrzahl der Knoten im Cluster auf ihrer Seite wissen. Alle anderen Knoten verweigern den Dienst.

Im ungünstigsten Fall kann das bedeuten, dass ein Ceph-Cluster ausfällt und unbenutzbar wird, weil die verbliebenen Knoten kein Quorum mehr erreichen. Der Administrator hat andererseits stets die Garantie, dass der Zugriff auf den Speicher zu jedem Zeitpunkt koordiniert ist und es nicht zu einem Split-Brain-Szenario kommt, bei dem unerwünschte Inkonsistenzen entstehen.

Swift verfolgt im Gegensatz dazu einen “Eventual Consistent”-Ansatz: Bei einem Swift-Cluster dürfen von 100 Knoten 95 ausfallen. Die fünf verbliebenen Knoten würden noch immer den Schreibzugriff erlauben und Leseanfragen bedienen, sofern sie lokal über das angeforderte Objekt verfügen.

Bräche ein solcher Swift-Cluster auseinander, könnte der Betreiber divergierend auf die Knoten der unterschiedlichen Cluster-Partitionen schreiben. Im Moment einer Wiedervereinigung würde Swift dann Cluster-weit voneinander abweichende Daten einfach durch die jeweils neueste Version eines Datensatzes ersetzen. Swift-Cluster bleiben also fast immer verfügbar, garantieren aber keine Konsistenz der Daten, was in Enterprise-Setups oft zum Problem wird.

Open-Stack- und Ceph-Grundlagen

Wie genau die Cloudbetreiber ihre Installation von Open Stack und Ceph über die Bühne bringen, ist ihnen selbst überlassen, in dieser Frage führen verschiedene Wege zum Ziel. Auf Open-Stack-Seite bietet sich neben der händischen auch die Installation mittels Packstack [5] oder auch Kickstack [6] an. Ceph lässt sich inzwischen recht komfortabel unter Zuhilfenahme des Werkzeugs »ceph-deploy« installieren – auch automatisch über Chef und Puppet.

Besondere Sorgfalt sollten Admins beim Planen des Clusters für Ceph walten lassen. Wie immer geht es bei Storage maßgeblich um Performance, und bei den virtuellen Maschinen kommt später auch nur die Performance an, die der Cluster zu liefern imstande ist. Einen performanten Ceph-Cluster auf die Beine zu stellen ist allen Unkenrufen zum Trotz nicht allzu kompliziert (siehe Kasten “Clusterperformance”).

Clusterperformance

Der einfachste Trick zur Leistungssteigerung eines Clusters besteht darin, jedem Ceph-OSD – also jedem Object-based Storage Device – ein performantes Journal zu spendieren. Ein Journal bringt ohnehin jedes OSD mit, es funktioniert auch genauso wie ein Journal für Dateisysteme: Es speichert die zu schreibenden Daten zwischen, bis sie auf dem echten Spinner landen.

Ceph kann OSD-Journale auf SSDs auslagern (Abbildung 1), mehr als vier OSD-Journale pro SSD sollten es aber nicht sein. Wer sich an dieses Limit hält, erreicht pro OSD Schreibraten von 250 MByte pro Sekunde und mehr.

Abbildung 1: Gut zu erkennen: Das Journal des OSD befindet sich auf einer separaten Partition – diese gehört zu einer Solid State Disk, was üblicherweise zu einem deutlichen Performancegewinn führt.

Auch das Thema Netzwerk spielt eine Rolle – schließlich wandern Daten von den VMs auf den Virtualisierungshosts über das Netzwerk zum Ceph-Cluster. Wer den Ceph-Hosts ein eigenes Netzwerk für den OSD-Datenstrom zur Verfügung stellt, sorgt dafür, dass der Replikations-Traffic zwischen den OSDs nicht die Performance des Datenverkehrs zwischen dem Ceph-Cluster und den VM-Hosts in Mitleidenschaft zieht. Möchte der Admin ein besonders vorbildliches Setup aufbauen, setzt er für das Netz zwischen Ceph und den VM-Hosts 10-Gigabit-Ethernet ein und stellt so sicher, dass Bandbreite kein Limit bildet.

Sind Open Stack und Ceph fachgerecht installiert und verfügt der Ceph-Cluster über ordentlich Rumms unter’m Blech, braucht das restliche Setup lediglich noch die Open-Stack-Dienste Cinder sowie Glance an Ceph anzubinden. Beide Dienste bringen ein natives Backend für Ceph mit, das der Administrator in der Konfiguration aktiviert. Der Schritt berührt allerdings auch die Sicherheit: Inktank empfiehlt für Cinder und Glance jeweils eigene Cephx-Nutzer anzulegen (Abbildung 2).

Abbildung 2: Die Datei »ceph.conf« enthält Einträge zu den Schlüsselringen der Cinder- und Glance-Benutzer. Der Admin schiebt sie zusammen mit den Schlüsseldateien selbst auf die betroffenen Hosts.

Gäste am Pool

Bei Cephx [7] handelt es sich um Cephs interne Funktion zur Benutzerauthentifizierung. Hat der Ceph-Installateur den Cluster mit »ceph-deploy« ausgeliefert, ist diese Authentifizierungsschicht standardmäßig aktiviert. Der erste Schritt beim Verheiraten von Open Stack und Ceph sollte darin bestehen, für Cinder und Glance separate Cephx-Benutzer anzulegen. Für diese definiert der Admin dann jeweils eigene Pools innerhalb von Ceph, die ausschließlich der zugehörige Dienst nutzen darf. Die folgenden Befehle erzeugen die beiden Pools, der Pool-Boy muss sie mit Berechtigung des »client.admin« -Benutzers ausführen:

ceph osd pool create cinder 1000
ceph osd pool create images 1000

Dann legt der Admin die zugehörigen Nutzer mitsamt Keyring an (Listing 1). Für Glance und dessen User erledigt er das am besten auf dem Host, auf dem »glance-api« werkelt, weil Glance dort nach dem Keyring sucht. Soll »glance-api« – etwa im Rahmen eines HA-Setups – auf mehreren Hosts laufen, muss er die Datei »/etc/ceph/ceph.client.glance.keyring« auf alle betroffenen Hosts kopieren. Fast identisch sehen die Befehle für den Cinder-Nutzer aus (Listing 2). Die Datei »ceph.client.cinder.keyring« sollte äquivalent auf dem Host oder den Hosts vorhanden sein, auf denen »cinder-volume« im Einsatz ist.

01 ceph auth get-or-create client.cinder mds 'allow' osd 'allow * pool=cinder' mon 'allow *' > /etc/ceph/ceph.client.cinder.keyring
02 chmod 0640 /etc/ceph/ceph.client.cinder.keyring

01 ceph auth get-or-create client.glance mds 'allow' osd
   'allow * pool=images' mon 'allow *' >    /etc/ceph/ceph.client.glance.keyring
02 chmod 0640 /etc/ceph/ceph.client.glance.keyring

Anschließend empfiehlt es sich, die Konfigurationsdatei »/etc/ceph/ceph.conf« um einen Eintrag für den neuen Key zu erweitern (Listing 3).

01 [client.glance]
02 keyring = /etc/ceph/ceph.client.glance.keyring
03
04 [client.cinder]
05 keyring = /etc/ceph/ceph.client.cinder.keyring

Glance vorbereiten

Nach diesen Schritten ist Ceph bereit für Open Stack. Die Komponenten der Cloudsoftware müssen nun lernen, Ceph im Hintergrund zu nutzen. Für Glance ist das denkbar einfach: Hier richtet der Admin einfach die Komponente »glance-api« ein. In deren Konfigurationsdatei, die er üblicherweise im Pfad »/etc/glance/glance-api.conf« vorfindet, knöpft er sich den Parameter »default_store« vor (Abbildung 3). Dieser bestimmt darüber, wo Glance in der Standardeinstellung Images deponiert. Trägt der Admin hier den Wert »rbd« ein, landen Images zukünftig in Ceph. Nach einem Neustart von » glance-api« sind die Änderungen bereits aktiv.

Abbildung 3: Der Eintrag »file« steht als Standardwert in der »glance-api.conf«. Damit Glance RBD verwendet, muss der Admin anstelle von »file« einfach »rbd« eintragen.

Weiter unten in der erwähnten Datei finden sich übrigens auch einige Parameter, die das Verhalten von Glance’ »rbd« -Backend steuern. Zum Beispiel lässt sich hier der Name des Pools festlegen, den Glance nutzen soll (Abbildung 4). Das abgebildete Beispiel verwendet so weit wie möglich die Standardwerte.

Abbildung 4: In der Konfigurationsdatei »glance-api.conf« finden sich einige zusätzliche RBD-Optionen, die das Verhalten des »rbd«-Backends kontrollieren.

Cinder startklar machen

Die Konfiguration von Cinder erweist sich als aufwändiger als die von Glance, weil sie mehr Komponenten involviert. Sicher ist, dass der Host, der »cinder-volume« betreibt, mit Ceph reden muss. Schließlich wird es später seine Aufgabe sein, RBD-Images in Ceph anzulegen, die der Admin den VMs als virtuelle Festplatten unterschiebt.

In einem typischen Ceph-Setup müssen aber auch die Hosts, auf denen die VMs laufen – sprich die Hypervisoren –, kooperieren. Denn Ceph arbeitet dezentral: Der Host, auf dem »cinder-volume« läuft, fungiert nicht als Proxy zwischen den VM-Hosts und Ceph, das wäre ein unnötiges Nadelöhr. Stattdessen reden die VM-Hosts später direkt mit Ceph. Dafür müssen sie wissen, wie sie sich mit Cephx bei Ceph anmelden.

Das folgende Beispiel beschreibt die Konfiguration anhand von KVM [8] und Libvirt [9], die über eine Cephx-Anbindung verfügen. Andere Virtualisierer steuern eigene Mechanismen bei, um mit Ceph zu reden – für weitere Hypervisoren gibt es derzeit keine direkten Ceph-Backends –, etwa für VMware [10].

Der erste Konfigurationsschritt für den Hypervisor besteht darin, eine funktionierende »ceph.conf« -Datei von einem bestehenden Ceph-Host zu kopieren. Auch eventuell benötigte Cephx-Schlüsseldateien sollten ihren Weg auf die Hypervisor finden. Für die Ceph-orientierte Konfiguration von Libvirt braucht der Admin zunächst eine UUID, die er auf der Kommandozeile mittels »uuidgen« generiert, im Beispiel lautet sie »2a5b08e4-3dca-4ff9-9a1d-40389758d081« . Die Cinder-Konfiguration in der Datei »/etc/cinder/cinder.conf« passt er dann so an, dass die vier farbig hinterlegten Einträge aus Abbildung 5 darin enthalten sind. Nach einem Neustart der Cinder-Dienste »cinder-api« , »cinder-volume« und »cinder-scheduler« ist die Arbeit auf dem Cinder-Host abgeschlossen.

Abbildung 5: Auch »cinder.conf« benötigt zusätzliche Einstellungen, damit die Kooperation mit Ceph klappt.

Hypervisor plus Cephx

Fehlt noch die Cephx-Konfiguration auf den Hypervisor-Systemen. Über einen Trick integriert der Admin diese, indem er jeden Hypervisor mit einer Datei namens »ceph-secret.xml« bestückt, die er mit dem Inhalt aus Listing 4 füllt. Über den Befehl »virsh secret-define ceph-secret.xml« legt er den Eintrag für das Passwort in der Libvirt-internen Datenbank an. Es handelt sich jedoch nur um einen Blanko-Eintrag ohne Passwort. Letzteres besteht aus dem Cephx-Schlüssel des Benutzers »client.cinder« , der Befehl

01 <secret ephemeral="no" private="no">
02   <uuid>2a5b08e4-3dca-4ff9-9a1d-40389758d081</uuid>
03     <usage type="ceph">
04     <name>client.cinder secret</name>
05   </usage>
06 </secret>

ceph-authtool --id client.cinder --print- key /etc/ceph/ceph.client.cinder.keyring

holt es auf den Bildschirm. Schließlich weist der Admin dem angelegten Blanko- das eigentliche Passwort zu – im Beispiel lautet es »AQA5jhZRwGPhBBAAa3t78yY/0+1QB5Z/9iFK2Q==« :

virsh secret-set-value 2a5b08e4-3dca-4ff9-9a1d-40389758d081 AQA5jhZRwGPhBBAAa3t78yY/0+1QB5Z/9iFK2Q==

Den Workflow vom Anlegen der »ceph-secret.xml« bis hin zur Eingabe des »virsh« -Befehls wiederholt der Admin auf jedem Host. Zumindest merkt sich Libvirt das Passwort nach dem ersten Eintrag. Lohn der Mühe sind VMs, die direkt und ohne Umwege auf Ceph zugreifen.

High-Speed-Storage

Eine denkbare Möglichkeit, um dem Gespann aus Cinder und Ceph noch eine Performance-Steigerung zu entlocken, besteht darin, dass die Benutzer mehrere Volumes in ihren virtuellen Maschinen konfigurieren und diese dann in der VM zu einem virtuellen Raid-0 zusammenfassen. So ließe sich die jeweils von einem Objectstorage-Device gebotene Performance sogar bündeln, was innerhalb der VMs Schreibraten von 500 MByte pro Sekunde und mehr ermöglichen würde.

Fazit

Open Stack und der Objectstore Ceph mögen momentan Hype-Themen sein, technisch sind die Projekte sicherlich keine Eintagsfliegen. Die Cloud-Storage-Lösung, die der Admin aus der Kombination des verteilten Objektspeichers und des Computing-Teils von Open Stack erzeugt, beeindruckt durch ihre Stabilität, Redundanz und Performance – herkömmliche Virtualisierungssysteme übertrifft sie deutlich.

Wer also in nächster Zeit den Aufbau einer offenen Cloud plant und von Anfang an das Thema Storage richtig angehen möchte, sollte der Hochzeitszeremonie von Open Stack und Ceph einen Besuch abstatten.

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei Hastexo. Er beschäftigt sich dort intensiv mit den Themen HA, Distributed Storage und Open Stack. In seiner Freizeit pflegt er Pacemaker für die Debian-Distribution.