sommersby - stock.adobe.com
OpenStack Speicher-Update 2018
Snapshots und Container-Storage-Support gehören zu den Funktionen der Open-Source-Private-Cloud-Plattform, aber der Support herstellerspezifischer Treiber gilt nicht generell.
Seit der Veröffentlichung der ersten Version von OpenStack sind fast acht Jahre vergangen. Mit ihr wurde uns eine Plattform versprochen, die eine neue Ära in der Open-Source Private-Cloud einläuten würde. Über die Zeit konnten wir beobachten, wie der OpenStack-Stern auf und ab ging, wobei das Projekt inzwischen in eine Phase eintrat, die man nun als reifere Phase bezeichnen kann.
So ergeben sich neue Fragen: Welche Veränderungen und Entwicklungen gab es bei OpenStack im Hinblick auf den Speicherverbrauch, seitdem wir uns vor etwa drei Jahren das letzte Mal mit den Speicherkomponenten beschäftigt haben? Wie passt OpenStack in das breitere Speicher-Ökosystem, wenn das Projekt immer mehr zum Mainstream wird?
OpenStack im Überblick
Die erste OpenStack-Plattform war eine gemeinsame Zusammenarbeit zwischen Rackspace und der NASA, die ein Open-Source-Ökosystem für den Betrieb von Private-Clouds entwickelte. OpenStack wird unter der Apache-Softwarelizenz entwickelt und vertrieben, die eine kostenlose Verteilung und die Möglichkeit, den ursprünglichen Code zu ändern, ermöglicht.
Die Plattform besteht aus einer Reihe von Projekten, die jeweils einen typischen Teil der Private-Cloud-Infrastruktur verwalten. Die ersten, die entwickelt wurden, konzentrierten sich auf virtuelle Instanzen, Vernetzung und Objektspeicherung. Jedem Projekt ist ein Name zugewiesen – Nova ist die Orchestrierungs-Engine für virtuelle Maschinen, während Neutron die Vernetzung implementiert.
Die drei wichtigsten Speicherprojekte sind:
- Cinder – Lösungen für Block-orientierte Speicherung
- Swift – Lösungen für Objektspeicherung
- Manila – das Projekt für dateiorientierte Speicherung
Man darf diese drei Projekte mit Recht als den Kern der Speicherinfrastruktur beschreiben. Es gibt auch andere Projekte, die sich auf Anwendungsdaten konzentrieren, darunter Trove (Database as a Service) und Sahara für Big Data. Einige der Projekte lassen sich mit anderen OpenStack-Diensten integrieren, wie beispielsweise mit Keystone für das Identitäts-Management.
OpenStack veröffentlicht neue Software-Releases in einem halbjährlichen Zyklus, wobei jedes Release einen Codenamen erhält. Dabei folgen die Autoren den Buchstaben des Alphabets. Die aktuelle 18. Version „Rocky“ wurde Ende August 2018 veröffentlicht. Allerdings ist es etwas verwirrend, da einzelne Projekte ebenso während eines größeren Releases eigene, unterschiedliche neue Versionen herausgeben. Swift nutzt zum Beispiel diesen Ansatz.
Im folgenden werden einige der Updates für Speicherprojekte besprochen, wobei wir einige bemerkenswerte Updates und Verbesserungen hervorheben. Aufgrund der Anzahl der Updates ist es nicht sinnvoll, alle in diesem Artikel aufzulisten. Wir empfehlen dazu die Online-Versionshinweise, die es für jede Version von OpenStack gibt, zu lesen, sobald sie veröffentlicht wird.
Unterstützung für Blockspeicher
Das Cinder-Projekt bietet Unterstützung für persistenten Blockspeicher, der an virtuelle Instanzen (virtuelle Maschinen) angeschlossen werden kann, auf denen die Anwendungen laufen. Die Blockspeicher-Funktionalitäten sind in eine native Unterstützung durch LVMs (Logical Volume Managers) auf der OpenStack-Serverinfrastruktur und in Plug-ins zur Unterstützung externer Speicherplattformen von traditionellen Anbietern unterteilt.
Wie bei allen OpenStack-Komponenten wird die Bereitstellung von Speicher über die API gesteuert, wobei herstellerbasierte Plug-ins eine Übersetzungsschicht bereitstellen, die Cinder-Volumes auf Speicher-Volumes auf der Herstellerplattform abbildet.
Cinder wurde ursprünglich in der Folsom-Version von OpenStack (September 2012) eingeführt, und die Anbieter haben im Laufe der Zeit die Unterstützung weiterer Treiber hinzugefügt. Der Grad der Unterstützung ist jedoch sehr unterschiedlich. Zum Beispiel wird die Möglichkeit, einen Snapshot als neue virtuelle Maschine anzuhängen, von vielen Anbietern nicht unterstützt.
Selbst innerhalb desselben Unternehmens ist die Unterstützung von Funktionen nicht einheitlich. Dell EMC PowerMax unterstützt beispielsweise viele Funktionen mehr als die PS-Serie von Dell EMC. Dies könnte die Prioritäten der einzelnen Entwicklergruppen innerhalb des Unternehmens und die langfristige Unterstützung bestimmter Speicherplattformen widerspiegeln. Natürlich wird nicht jeder Storage-Anbieter in der Lage sein, Funktionen anzubieten, die es in seinen Produkten nicht gibt – Quality-of-Service wird zum Beispiel nur von einem kleinen Teil der Storage-Anbieter implementiert.
Man kann sagen, dass die in Cinder eingeführten Funktionen in den letzten OpenStack-Versionen eher schrittweise als revolutionär von statten ging. Viele schließen Lücken, die in anderen Ökosystemen allgemein vorhanden sind, oder setzen neue Impulse für neue Produktplattformen.
Objektorientierte Datenspeicherung
Die Objektunterstützung übernimmt Swift, eine Scale-Out-Objektspeicherplattform. Sie verspricht eine hohe Lebensdauer und Verfügbarkeit für objektartige Daten.
Im Vergleich zu dateiorientierten Speichersystemen bieten Objektablagen im Allgemeinen eine höhere Skalierbarkeit und einen verteilten Datenzugriff. Allerdings gehen die Vorteile der POSIX-Compliance verloren. Für große Mengen an allgemein statischen oder schreibgeschützten Inhalten können Objektspeicher eine viel kostengünstigere Lösung sein als Scale-Out-Dateisysteme.
Während Cinder hauptsächlich als Schnittstelle für Plattformen von Storage-Anbietern verwendet wird, ist Swift eine eigenständige Objektspeicher-Technologie. Unternehmen wie SwiftStack bauen auf OpenStack Swift auf, um weitere Lösungen zu entwickeln.
Speicheranbieter mit Plattformen mit nativer OpenStack-Unterstützung können allerdings einfach anstelle der nativen Swift-Implementierung in die Infrastruktur gestellt werden. Dies liegt daran, dass die Objektspeicherplattformen nativ über APIs, die entweder dem Swift- oder dem S3-Standard folgen, gesteuert werden.
Swift wird häufiger aktualisiert als Cinder oder Manila, wobei dann mehrere Updates (normalerweise alle zwei Monate) jeweils zusammen mit jeder größeren OpenStack-Version veröffentlicht werden. Zu den jüngsten neuen Funktionen, die in 2.18 mit Rocky eingeführt wurden, gehören das Container Sharding (eine verbesserte Funktion zur Verteilung von Metadaten) und die S3-API-Kompatibilität. Es gab zudem interne Optimierungen, um dem Wachstum der individuellen Speicherlaufwerkskapazität und der Serverspeicherdichte Rechnung zu tragen.
Unterstützung für dateiorientierte Speicher
Die File-orientierte Speicherung erfolgt über das OpenStack-Projekt Manila. Ursprünglich sollten die Dateidienste als Teil von Cinder bereitgestellt werden. 2013 wurde Manila als separates Projekt abgetrennt. Die typischen Use-Cases für datei- im Vergleich zu Block-orientiertem Speicher existieren sowohl in der Public-Cloud als auch auf anderen Plattformen wie VMWare. Normalerweise können unterschiedliche virtuelle Maschinen oder Instanzen nicht gemeinsam und gleichzeitig auf Block-Devices zugreifen. Dateiorientierte Speicherdienste erlauben das und fügen weitere erweiterte Funktionen wie Sicherheit und bessere Skalierbarkeit hinzu.
Manila passt sich dem Design von Cinder dahin gehend an, dass Anbieter Plug-ins für die Automatisierung der Bereitstellung und Zuordnung von Dateisystemen zu virtuellen Instanzen schreiben. Während Cinder jedoch eine Matrix von Funktionen bietet, die von allen Treibern unterstützt werden, sind Manila-Treiber mit spezifischen Optionen für jeden unterstützten Dateisystemanbieter maßgeschneidert.
Anfangs hat Manila Standard-Dateisysteme, darunter NFS und CIFS, unterstützt. Im Laufe der Zeit wurden diese um weitere proprietäre Lösungen wie Gluster, Ceph, Hadoop File System und MapR erweitert.
Mit dem Ocata-Release von OpenStack kam eine ganze Anzahl an Snapshot-Funktionen hinzu. Dazu gehörten Mount-fähige (temporäre) Snapshots zur Wiederherstellung von Daten, die Möglichkeit zum Zurücksetzen von Dateifreigaben auf einen früheren Snapshot und Funktionen für den Umzug von Snapshots von einer Plattform auf eine andere. Die Migrations-API wurde auf einen zweistufigen Prozess erweitert, der den Zugriff auf Daten während der Migration ermöglicht.
Herausforderungen
Da OpenStack als eine Reihe unabhängiger Projekte entwickelt wird, sind die Implementierungen von Funktionen nicht immer konsistent. Das Ökosystem der Treiber für Cinder ist größer als das für Manila und besser dokumentiert.
Ein großes Problem, das sich bei der Entwicklung aller OpenStack-Speicherprojekte zeigt, ist die Notwendigkeit der Softwareaktualisierung, damit neue Treiber oder Treiberfunktionen von Anbietern funktionieren. Dies sorgt für einen erheblichen Aufwand, wenn man bei der Unterstützung externer Speicherplattformen up to date bleiben möchte.
Im Container-Ökosystem war die Lösung dafür die Entwicklung eines Container Storage Interface (CSI), die die Treiberspezifikation vom Treiber selbst abstrahiert. Einzelne herstellerspezifische Treiber können dann installiert, ersetzt oder aktualisiert werden, ohne dass die Kern-Container-Software aktualisiert werden muss. Diese Vorgehensweise ist in den OpenStack-Speicherprojekten dringend erforderlich.
Schlussfolgerungen
Da ein Großteil der Hauptentwicklungsarbeiten zur Integration von Storage inzwischen abgeschlossen ist, konzentriert man sich künftig auf die Entwicklung zusätzlicher Funktionen und der Unterstützung neuer Plattformen.
Das OpenStack-Projekt konzentriert sich damit stärker auf operative Datendienste als auf die Infrastruktur. Neuentwicklungen beziehen sich auf Projekte wie Freezer für Backup und Disaster Recovery.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
