Immer mehr Unternehmen setzen OpenStack ein, um eine Cloud-Infrastruktur aufzubauen. Dabei haben sie die Wahl zwischen drei Speicher-Modellen: Object Storage mit Swift, Block Storage mit Cinder oder File Storage mit Manila. Welche Lösung die richtige ist, hängt dabei vom Anwendungsfall ab.
Mit OpenStack können Unternehmen flexible und skalierbare Cloud-Umgebungen aufbauen. Das Software-Projekt bietet eine frei verfügbare Architektur und setzt sich aus einer Vielzahl von Modulen zusammen. Diese stellen zum Beispiel virtuelle Maschinen, virtuelle Netzwerke oder Speicher bereit und dienen deren Verwaltung. Für den Storage haben Anwender die Wahl zwischen den Modulen Swift, Cinder und Manila. Jedes von ihnen hat seine Vorteile und eignet sich für bestimmte Anwendungsszenarien.
Swift für Backup und Archivierung
Swift stellt Object Storage unter OpenStack zur Verfügung: Daten werden in Objekte gepackt und über verschiedene Speicherknoten im Cluster verteilt. Anhand von Metadaten, die zusammen mit den Objekten gespeichert werden, lassen sich die Daten eindeutig zuordnen. Dadurch können Anwender Daten aufrufen, ohne ihren Standort zu kennen. Object Storage ist horizontal skalierbar und lässt sich gut mit Standard-Hardware umsetzen. Damit ist die Lösung preiswert und ermöglicht sehr große Repositories bei geringem Platzbedarf. Sie unterstützt jedoch keine virtuellen Maschinen. Außerdem ist sie langsamer als Block Storage oder File Storage. Deshalb eignet sich Swift vor allem für Daten, die selten oder gar nicht aktualisiert werden müssen. Die Lösung ist ideal für Backups und Archive.
Cinder für Anwendungen, bei denen es auf die Performance ankommt
Das OpenStack-Modul Cinder ermöglicht Block Storage für virtuelle Maschinen. Das Speichern der Daten erfolgt dabei in virtuellen Volumes, die jeweils wie eine Festplatte behandelt werden. Eine virtuelle Maschine kann allerdings immer nur auf das Volume zugreifen, das ihr zugewiesen ist. Geteilte Volumes sind nicht möglich. Block Storage ist sehr schnell und eignet sich daher ideal für performancekritische Primärworkloads wie SQL- oder NoSQL-Datenbanken oder Anwendungen der Datenanalyse oder Transaktionsverarbeitung. Als Backend lassen sich unterschiedliche Speichermedien einsetzen.