© Joerg Hackemann, 123RF

Für Blockspeicher ist in Open Stack das Modul Cinder verantwortlich, doch das weiß mit populären Shared-Dateisystemen nichts anzufangen. Dank Manila lassen sich nun aber auch NFS und CIFS als Ressourcen in Open Stack verwalten und nutzen.

Wer sich mit Open Stack beschäftigt, kann schnell den Eindruck bekommen, dass das Thema Cloudstorage abschließend gelöst sei. Denn an zentraler Stelle im Setup kümmert sich Open Stack Cinder darum, dass die virtuellen Maschinen Speicher in Form von persistenten Blockgeräten bereitgestellt bekommen (Abbildung 1).

Abbildung 1: Cinder kümmert sich in Open Stack zwar auch um Storage, deckt aber nur den Bereich persistenter Blockspeicher ab.

Cinder folgt zentralen Designvorgaben des Open-Stack-Projekts: Auf der einen Seite stellt es eine Verbindung zum physischem Speicher her, also etwa zu einem SAN oder einer Ceph-Installation. Auf der anderen Seite, die zu den VMs weist, ist Cinder so mit den anderen Open-Stack-Diensten verwoben, dass der Admin eine VM wahlweise per Mausklick mit einem Volume verbindet oder sie von Anfang an von solch einem Volume startet.

Dass Cinder dennoch Defizite hat, merken Admins allerdings sehr schnell, nämlich in dem Moment, in dem die Anforderung nicht mehr nur “persistenter Speicher” lautet, sondern “persistenter, geteilter Speicher”. In klassischen Computing-Umgebungen realisieren NFS oder CIFS diesen Shared Storage. In Cinder gibt es für diesen Usecase aber überhaupt keine Lösung und die Nutzer schauen in die Röhre.

Bedarf an geteiltem Storage gibt es jedoch in Cloudumgebungen genauso wie in klassischen Setups. Deshalb sollte es auch für Kunden der Cloud möglich sein, von mehreren VMs aus – und gegebenenfalls auch über die Grenze des eigenen Projekts hinaus – auf den gleichen, geteilten Speicher zuzugreifen.

Eine der größten Stärken von Open Stack ist seine Modularität. So nimmt es nicht Wunder, dass auch eine Komponente entwickelt wurde, die das Problem des geteilten Speichers angeht: Open Stack Manila [1]. Sie will NFS- und CIFS für VMs in Open Stack nutzbar machen (Abbildung 2). Der vorliegende Artikel erklärt dieses Projekt im Detail, zeigt auch die Schwachstellen der Implementierung und erläutert, welche Setups sich mit Manila in Open Stack realisieren lassen.

Abbildung 2: Manila hängt die Shares von geteilten Dateisystemen an VMs an und erlaubt so deren Nutzung.

Mögliche Einsatzszenarien

Warum sind Shared-Filesysteme in Clouds überhaupt von Bedeutung? Es gibt schließlich andere Möglichkeiten, Dateien für mehrere VMs gleichzeitig bereitzuhalten. Etwa durch Amazons S3-Protokoll: Die Anwendungen legen dabei statische Nutzdaten in einem Objektspeicher ab. Klassisches Beispiel sind Assets von Webshops, zum Beispiel Produktbilder. Sie ändern sich selten, werden aber zeitgleich von vielen Clients benötigt.

Weil Bilder ohnehin binäre Objekte sind, eignen sie sich so gut für Objektspeicher. Jedes Bild liegt also in S3 und wird aus der Anwendung heraus mit seinem vollen S3-Pfad referenziert. Der Webbrowser des Kunden lädt sich das jeweilige Bild direkt aus S3 herunter, im Endeffekt sieht die Website so aus, wie der Anbieter es sich wünscht.

Leider hat die Sache einen Haken, wenn es um Legacy-Applikationen geht: Webshops sind hier wiederum ein gutes Beispiel. Die gehen nämlich meist davon aus, dass ihre Assets auf einem zentralen Shared Filesystem liegen, worauf dann auch die Links innerhalb der Website verweisen. Meist kommt hier NFS zum Einsatz. Wer eine solche Applikation in die Cloud bringen möchte, hat mehrere Möglichkeiten.

Eine Option ist die Webshop-Software so umzubauen, dass sie ihre statischen Daten von S3-kompatiblen Speichern laden kann. Nach der reinen Lehre ist das zwar der richtige Weg, das Vorhaben scheitert in der Realität aber oft schon daran, dass die Webshops proprietäre Software sind und der Quelltext dem Webshop-Betreiber gar nicht zur Verfügung steht.

Aber selbst wenn der Quelltext vorliegt, ist die Portierung auf S3-Fähigkeit kein Pappenstiel: Für die gängigen Skriptsprachen im Webdesign stehen zwar S3-Module bereit, zum Beispiel für PHP. Bis eine große Umgebung wie ein Webshop allerdings vollständig auf diesen Weg umgestellt und durchgetestet ist, vergehen Wochen bis Monate.

Aus Sicht des Website-Betreibers gibt es also gewichtige Gründe dafür, in der Webapplikation nicht allzu viel zu verändern und lieber extern jene Funktionen nachzurüsten, mit denen sich die Applikation bestmöglich betreiben lässt.

Clash of Culture: NFS und Open Stack

Grundsätzlich lassen sich Open Stack und NFS auch ohne separate Komponenten zusammen betreiben. Das einfachste Szenario besteht darin, die VMs eines Setups in einem privaten Netzwerk zu starten und auf einer der VMs dann einen NFS-Server zu betreiben.

Was in der Theorie gut klingt, erweist sich aber nur beschränkt als praktikabel: Solch ein Setup bietet nämlich nicht die Option, die Inhalte des NFS-Servers auch VMs zur Verfügung zu stellen, die nicht im selben privaten Netzwerk hängen. Konkret kann das bedeuten, dass der Anbieter auch solche Bilder in der Cloud an mehreren Stellen vorhalten muss, die eigentlich völlig identisch sind. Vor dem Hintergrund der üblichen Methode zur Verrechnung in Clouds – Pay per Use – ist das wenig attraktiv.

Das Problem verdeutlicht den fundamentalen Widerspruch in der Kombination aus Open Stack und Shared-Filesystemen, den Manila zu lösen antritt: Open Stack sieht nicht vor, Dateisysteme über die Grenzen von privaten Netzen hinaus verschiedenen Clients verfügbar zu machen. Manila will jedoch genau das erreichen – und pocht nebenbei auch darauf, NFS- oder auch CIFS-Shares zu qualifizierten Ressourcen zu machen.

Qualifizierte Ressourcen

Im Begriff der qualifizierten Ressource versteckt sich der zweite, große Unterschied zu einer Eigenbaulösung: Open Stack Manila bietet die Option, NFS- oder CIFS-Shares direkt auf der Open-Stack-Ebene zu verwalten. Der Admin darf nunmehr NFS-Shares durch Befehle direkt über die APIs der Cloud anlegen und löschen; auch den Zugriff auf sie kann er direkt auf der API-Ebene konfigurieren. Den Betrieb des NFS-Servers übernimmt folglich Manila, der Benutzer muss sich um das Thema nicht mehr kümmern. Im besten Fall ist ein Mausklick im Open-Stack-Dashboard ausreichend, um zu einem NFS-Share zu gelangen, der sich im Anschluss an alle eigenen VMs anbinden lässt.

Und es gibt noch einen weiteren Vorteil: Prinzipiell ist es möglich, Open-Stack-Ressourcen aus den verschiedenen Automatisierungs- und Orchestrierungslösungen heraus direkt zu nutzen. In einem Template für die Open-Stack-Orchestrierung Heat, das viele VMs zur gleichen Zeit startet und passende Netze dafür selbst anlegt, kann der Nutzer also gleichzeitig auch einen NFS-Share automatisiert anlegen. Liefe das NFS stattdessen in einer händisch installierten VM des Projekts, wäre genau diese Art der externen Kontrolle unmöglich.

Begriffswirrwarr

Wer mit Open Stack Manila beginnt, sieht sich einer Flut an Begriffen und Bezeichnungen gegenüber, die im Manila-Kontext ihre eigene Bedeutung haben. Allen voran steht der Share: Dabei handelt es sich um die tatsächliche Open-Stack-Ressource, mit welcher der Benutzer auf der API-Ebene von Open Stack hantiert. Er legt Shares an oder löscht sie, fertigt von Shares Snapshots an oder schränkt die Zugriffsberechtigungen für die eigenen Shares ein. Shares unterstützen verschiedene Protokolle, darunter eben auch CIFS und NFS.

Unmittelbar mit dem Share verbunden ist das Backend: Als Backend firmiert in Manila eine Instanz des Dienstes Manila Share, die mit einer externen Speicherlösung redet. Dabei bedient sie sich der so genannten Share Servers: Damit ist ein Manila-spezifischer Dienst gemeint, der ein Backend mit einem Share verbindet. Backends können alle Geräte oder Dienste sein, die auf Zuruf Storage bereitstellen.

Die Share Servers sind eine Brückenkonstruktion: Meist handelt es sich um echte VMs, die das jeweilige Backend auf Basis der Nutzervorgaben automatisch startet. Wenn ein Backend seine Share Servers selbst verwaltet, kann es diese von Anfang an so starten, dass sie im passenden virtuellen Netz laufen und der Zugriff durch die Ziel-VMs klappt.

Im Hinblick auf Share Servers gibt es eine Besonderheit. Nicht alle Backends können mit Share Servers überhaupt umgehen. Viele Backends für spezielle Storage-Geräte, etwa von Netapp oder EMC, setzen stattdessen darauf, Shares ohne die Zwischenstation einer separaten VM direkt an die Ziel-VMs anzuschließen. In jenen Backend-Treibern ist das dann auch entsprechend vermerkt und Manila kümmert sich automatisch darum, dass bei der Verbindung von VMs mit diesen Shares andere Netzwerkeinstellungen zum Einsatz kommen.

Ein Fork von Cinder

Am Anfang der Manila-Entwicklung steht ein Fork von Open Stack Cinder – also der Komponente für Blockspeicher. Das leuchtet ein: Zwar ist das Ziel von Manila die Verwaltung von geteilten Dateisystemen, doch grundlegende Gemeinsamkeiten gibt es zwischen den beiden Speichertypen natürlich auch. Etwa das Handling von Speicher für spezifische VMs: Hier ist sowohl bei Cinder wie auch bei Manila die Notwendigkeit gegeben, einen Speicher per fester Zuweisung an eine (oder, im Manila-Falle, mehrere) VMs anzuschließen.

Auch das Handling von Speicher im Hintergrund haben Manila und Cinder gemeinsam. Beide Dienste bieten selbst keinen Speicher an, weder Manila noch Cinder verfügen also über eigenen Plattenplatz. Stattdessen gehen beide Dienste davon aus, dass sie vom Admin konfigurierbaren Speicher zur Verfügung gestellt bekommen, den sie nach Bedarf in kleine Scheiben spalten und danach an einzelne VMs weitergeben.

Da wundert es nicht, dass sich das Design von Manila insgesamt stark an dem von Cinder orientiert. Wie Cinder besteht Manila aus einem API, also der Open-Stack-typischen Lösung, um Benutzern das Senden von Befehlen an den Dienst zu ermöglichen. Hinzu kommt eine eigene Komponente, die aus den verfügbaren Storage-Backends eines auswählt. Auf diesem wird dann »manila-share« aktiv. Dieser Dienst konfiguriert einen Dateisystem-Share, der anschließend VMs zur Verfügung steht. Manila ist in das Konzept von VMs in Open Stack allerdings deutlich enger integriert, als Nutzer es von Cinder in Open Stack kennen – oder erwarten würden.

Das heikle Thema Netzwerk

Grund dafür ist einmal mehr das heikle Thema SDN. Open Stack bringt dafür eine eigene Komponente namens Neutron mit, die sich um alle Belange des Software Defined Networking kümmert. Typische Open-Stack-Clouds setzen auf die rigorose Trennung der privaten Netzwerke einzelner Kunden: Hier ist die grundlegende Annahme, dass der Traffic eines Kundennetzwerks niemals mit dem Traffic eines anderen Netzes in Berührung kommt.

Für Cinder ist das kein Problem: Cinder redet direkt mit der Open-Stack-Virtualisierungskomponente Nova und jubelt VMs neue Blockgeräte über die Hotplug-Funktion des Hypervisors unter, in den meisten Fällen also über KVM. Dafür genügt es, wenn Nova und Cinder über das Management-Netz der Cloud miteinander reden können.

Manila hingegen ist darauf angewiesen, dass die VMs in einem privaten Netz mit einem NFS-Share kommunizieren können, der sich – je nach Setup – in einem anderen privaten Netz befindet. Das Problem lässt sich in Open Stack auf mehreren Wegen lösen. Eine Variante sieht vor, ein Shared-Netz anzulegen, auf das alle angebundenen VMs zugreifen dürfen. Möglichkeit zwei besteht darin, den Zugriff über Router in Open Stack zu ermöglichen.

Variante drei baut auf dem Ansatz auf, einen Share unmittelbar in ein privates Netz zu hängen, sodass nur VMs innerhalb des Netzes an den Share herankommen. Die Variante ist zwar einerseits die sicherste, weil sie unbefugten Zugriff von außen unmöglich macht. Sie verhindert aber auch, Shares in mehreren Projekten gleichzeitig zu nutzen.

Welche Netzwerkoptionen in einem Setup zur Verfügung stehen, hängt zuerst vom genutzten Backend ab. Treiber, die Share Servers unterstützen, sind naturgemäß flexibel: Hier wird eine separate VM gestartet, die sich beliebig in die vorhandenen virtuellen Netze einklinkt. Wer stattdessen auf einen der Hersteller-spezifischen Treiber setzt, muss auf diesen Luxus meist verzichten: Das Storage-Netz und die privaten Kundennetze liegen auf unterschiedlichen Layern im Netzwerkstack (Layer 2 vs. Layer 3). Manila disponiert dann um und baut eine Brückenkonstruktion, etwa über einen Open-Stack-Router oder über ein zuvor festgelegtes Shared-Netz.

Generisches Backend

Böse Zungen unterstellen den Open-Stack-Entwicklern gerne, dass sie bei jeder sich bietenden Gelegenheit das Rad neu erfinden. Die Manila-Entwickler entlarven das als Vorurteil: Wer Manila ohne besonderen Storage nutzen will, greift auf das Generic Backend zurück – das bei richtiger Konfiguration (Abbildung 3) direkt mit Cinder verwoben ist. Dieses Backend konfiguriert auf Basis der Konfiguration, die der Admin der Cloud für Manila hinterlegt hat, zunächst ein Volume in Cinder auf Basis von dessen Storage. Es startet danach per Nova eine VM, die dieses Volume nutzt.

Abbildung 3: Wer Manila mit dem Generic-Backend betreibt, stellt sicher, dass der Dienst mit Nova, Neutron und Cinder reden kann.

In diesem Szenario nimmt Nova Manila die gesamte Netzwerkarbeit ab: Die frisch gestartete VM bekommt einfach einen eigenen Port im virtuellen Kundennetz. Dann konfiguriert das Backend auf eben jener VM einen Dienst für das gewünschte Protokoll, meist NFS oder CIFS, und zeigt schließlich an, unter welchem Pfad das angelegte Volume erreichbar ist. Auf den VMs, die es nutzen sollen, fehlt dann bloß noch der obligatorische »mount« -Befehl, um das Shared Filesystem zu nutzen.

Hersteller-spezifische Backends

Dabei produziert das Generic Backend aber naturgemäß eine Menge Overhead; bereits die eigene VM frisst Ressourcen und kostet – je nach Modell der Verrechnung – bares Geld. Viele Hersteller von Storage-Lösungen haben aus diesem Grund ein gesteigertes Interesse daran, Manila-Nutzern alternative Treiber für ihre Produkte anzubieten. Etwa Netapp: Der Netapp-Treiber für Manila sorgt beispielsweise dafür, dass die Shares einer ONTAP-Instanz sich direkt in Manila einfügen und durch Manila hindurch VMs zur Verfügung stehen. EMC und HP verfolgen für ihre Storage-Lösungen (Isilon, 3PAR) ähnliche Ansätze.

Für IBMs GPFS existiert genauso ein Backend-Treiber wie für Gluster-FS und den Objektspeicher Quobyte, der selbst ebenfalls Posix-kompatibel ist. Effektiv spricht Manila damit praktisch jedes Open-Stack-Setup an: Wer eine der Speicherlösungen nutzt, für die ein eigener Treiber bereitsteht, setzt auf eben diesen Treiber. Alternativ bietet sich der generische Treiber für Cinder an.

Shares effizient nutzen

Das Anlegen eines Share ist die eine Sache, das effiziente Verwalten des Laufwerks allerdings eine andere: Im Alltag kann es notwendig sein, einen existierenden Share zu vergrößern oder zu verkleinern. Zu Backup-Zwecken will der Admin außerdem möglicherweise Snapshots des jeweiligen Share anlegen, auf die er später beim Restore zurückgreift.

Die gute Nachricht ist, dass im Manila-Code die genannten Features bereits vorgesehen sind. Die schlechte Nachricht ist, dass die im Einzelfall verfügbaren Features stark vom Treiber für den Backend-Storage abhängen, der zum Einsatz kommt. Technisch ist das jedoch nicht anders machbar. Denn wie soll Manila Snapshots zum Beispiel auf einem ONTAP-Gerät von Netapp anlegen, ohne die Netapp-internen Werkzeuge für diesen Zweck zu nutzen?

Praktisch bedeutet das jedoch, dass einzig die Qualität des Manila-Treibers für den jeweiligen Backend-Storage den Ausschlag gibt. Es ist gute Tradition, dass jene Unternehmen ihre Manila-Treiber selber pflegen, die mit ihrer Storage-Lösung an Manila andocken wollen. Wer die entsprechenden Features also effektiv nutzen möchte, wirft am besten schon bei der Planung seines Setups einen Blick auf die entsprechende Tabelle [2] in der Manila-Dokumentation, um zu prüfen, ob der Treiber für den Storage der eigenen Präferenz den Anforderungen tatsächlich entspricht (Abbildung 4).

Abbildung 4: Auf der Open-Stack-Website bietet das Manila-Projekt einen guten Überblick über die vorhandenen Treiber und ihre Features.

In Sachen Sicherheit

Das Konzept des Zugriffs über ein geteiltes Netzwerk wirft in den Setups Fragen auf, in denen das Backend seine Share Servers nicht selbst verwaltet. Denn jene Treiber setzen entweder geteilte Netze oder Gateway-Funktionalität voraus, und zwar gerade in jenen Setups, die eigentlich auf strikte Trennung von Netzwerken ausgelegt sind.

Das provoziert die wichtige Frage: Wie lassen sich nicht autorisierte Zugriffe verhindern? Solange rein virtuelle private Netze zum Einsatz kommen, kümmert sich die SDN-Lösung darum, aber im konkreten Fall ist ja gerade dieser Mechanismus durch das Shared-Netz ausgehebelt. Die Antwort der Manila-Entwickler ist ein ACL-System, das auf IP-Basis funktioniert: Für jeden Share lässt sich dabei der IP-Raum festlegen, aus dem heraus der Zugriff möglich sein soll. Im letzten Schritt hat ein Nutzer hier also auch die Möglichkeit, Zugriff nur für eine einzelne IP-Adresse zu erlauben.

Sicherheits-Plus

Selbst wenn ein Client dann theoretisch an einen Manila-Share herankommt, bedeutet das noch nicht, dass er ihn auch tatsächlich nutzen darf. Denn Manila implementiert ein eigenes Zugriffssystem mit Login und Passwort, an dem sich potenzielle Clients zunächst anmelden müssen. Doch ist die Qualität der Implementierung hier strikt abhängig von den Fähigkeiten, die der jeweilige Storage-Treiber beherrscht. Das Framework in Manila selbst ist maximal flexibel: LDAP, Kerberos sowie Active Dierctory stehen bereit. Über diese Protokolle definiert der Admin einen Security Service, mit dem die jeweiligen Storagetreiber kommunizieren müssen.

Bei den verfügbaren Treibern ist in Sachen Support für jene Security-Dienste allerdings bald der Ofen aus. Lediglich Netapps ONTAP-Treiber verfügt über alle drei Modi. Der für CIFS entworfene Treiber lässt sich zumindest via Active Directory ansprechen. Schlecht schneidet der Generic-Treiber ab, der keinen der drei beschriebenen Mechanismen beherrscht. In solchen Fällen bleibt dem Admin letztlich nichts anderes übrig, als die Kontrolle durch einen Security Service auszuschalten, was zwar das Setup einfacher macht, in Sachen Sicherheit allerdings ein Rückschlag ist.

Im Dashboard: Ja, aber

Auch wenn in der schönen neuen Welt der Cloud bekanntlich alles über die APIs der Open-Stack-Dienste zu regeln ist, fühlen sich viele Admins noch immer wohler, wenn sie – zumindest am Anfang – auch einen grafischen Zugang zu einer ihnen unbekannten Technik haben. Dafür gibt es das Open-Stack-Dashboard alias Horizon. Wer die Vanilla-Version des Dashboards installiert, muss auf Manila allerdings verzichten. Denn das UI-Plugin für Manila in Horizon hat es bisher nicht in den offiziellen Horizon-Quelltext geschafft.

Das Problem lässt sich auf der Kommandozeile zwar unkompliziert lösen, allerdings involviert die Lösung die händische Installation des UI-Moduls in Horizon. Admins, die ihre Cloud vollständig automatisiert haben, müssen im Zweifelsfall vom Manila-Plugin für Horizon selbst ein Paket für das eigene System bauen. Immerhin: Wer Erfahrung im Paketbau hat, wird bei dieser Aufgabe nicht vor unlösbare Probleme gestellt. Ein fader Beigeschmack ist aber nicht zu leugnen (Abbildung 5).

Abbildung 5: Ein UI-Modul für Horizon existiert zwar, allerdings muss der Admin es separat nachinstallieren.

Fazit

Manila ist fast schon eine archetypische Lösung in Open Stack: Das Design der Komponente ist im Kern gelungen und eigentlich wäre Manila auch in der Lage, Open-Stack-Nutzern einen echten Mehrwert zu bieten. Denn früher oder später sehen sich viele Cloudanwender mit der Anforderung konfrontiert, ein geteiltes Dateisystem einrichten zu sollen.

Aus Admin-Sicht zeigt sich Manila allerdings alles andere als optimal: Die Dokumentation ist – Open-Stack-typisch – eher unvollständig und obendrein schwer zu durchdringen. Hinzu kommen diverse Fallstricke: Unvollständige Treiber für die Speicher der großen Hersteller, komplexe Konfigurationsarbeit und auch das fehlende UI-Modul für Horizon trüben die Laune empfindlich.

Positiv sei deshalb nochmals Netapp hervorgehoben, das für Manila viele Entwickler beschäftigt und obendrein mit dem Treiber für die eigenen ONTAP-Geräte quasi eine Blaupause für einen perfekten Backend-Treiber vorlegt. Bei den Treibern für viele andere Lösungen gilt: Mehr Schein als Sein.

Immerhin dürfen Nutzer auf Besserung hoffen, mittlerweile folgt Manila den offiziellen Open-Stack-Releasezyklen. Obendrein zieht die Lösung kontinuierlich neue Entwickler an, sodass mehr Entwicklungspower verfügbar ist. Bis es Manila auf einen Level mit den etablierten Standardkomponenten von Open Stack geschafft hat – etwa Neutron, Nova oder Cinder –, dürfte allerdings noch ein Weilchen vergehen.