OpenStack Storage: Swift und Cinder
OpenStack Swift und OpenStack Cinder sind zwei Open-Source-Module, die das Speichern in der Cloud vereinfachen sollen.
Die Server-Virtualisierung hat das Rechenzentrum grundlegend verändert und das Wachstum sowie die Konsolidierung in x86-Workloads angekurbelt. Da die virtualisierten Infrastrukturen einen gewissen Reifegrad erreicht haben, hat sich auch das damit verbunden Ökosystem soweit verändert, dass es nun die Anforderungen der Organisationen erfüllt, die ihren Nutzern eine Provider-ähnliche Umgebung bieten wollen: die private Cloud.
OpenStack ist ein Open-Source-Projekt, das über ein komplettes Ökosystem verfügt, um Privat Cloud-Infrastruktur-Funktionalitäten zur Verfügung zu stellen. OpenStack besteht aus zahlreichen verschiedenen Modulen die unterschiedliche Infrastruktur-Bereiche abdecken: Nova für virtuelle Maschinen (VM) und Compute; Swift für Object Storage; Cinder für Block Storage; Neutron fürs Netzwerk; Horizon fürs Dashboard; Keystone für Identity Services; Glance für Image Services; Ceilometer für Telemetrie und Heat für Orchestration.
Speicherfunktionalität wird von drei dieser Komponenten abgedeckt: Swift ist ein Teilprojekt, das Object Storage gewährleistet. Es bietet ähnliche Funktionalitäten wie Amazon S3. Cinder ist die Block-Speicher-Komponente, die unter anderem Standard-Protokolls wie iSCSI bietet. Glance stellt ein Repository für VM-Images zur Verfügung und speichert einfache File-Systeme oder Swift.
OpenStack entwickelte sich aus einer Kollaborationsarbeit von Rackspace und NASA heraus und erreichte als Plattform für die Entwicklung von Scale-out-Applikationen einen gewissen Bekanntheitsgrad. Heute wird es von Service Providern genutzt, um Public Clouds zu offerieren oder von großen Unternehmen, um private Cloud-Infrastrukturen aufzubauen.
Bis heute haben sich mehr als 200 Firmen für OpenStack engagiert und dabei Finanzen und andere Ressourcen eingebracht, um das Projekt weiter zu entwickeln. Seit der ersten Veröffentlichung 2010 unter dem Codenamen Austin, das damals nur Block-Storage unterstützte, sind nach und nach weitere Funktionen hinzugekommen, wie zum Beispiel Cinder-Support im Folsom-Release 2012. Die Verfügbarkeit von Cinder ermöglichte es traditionellen Herstellern und Start-ups, ihre Produkte so anzupassen, das diese Storage in OpenStack-Umgebungen integrieren können.
OpenStack Cinder für Block Storage
Block Storage ist eine der grundlegenden Anforderungen virtueller Infrastrukturen. Es ist die Basis, um virtuelle Maschinen zu sichern und ebenso die Daten, die von diesen VMs genutzt werden. Bevor Block-Storage-Support verfügbar war, nutzten die OpenStack-VMs so genannten „vergänglichen“ oder kurzfristigen (ephemeren) Storage. Das bedeutete aber, dass der Inhalt der VM verloren ging, wenn die VM heruntergefahren wurde.
Cinder ist die OpenStack-Komponente, die den Zugriff auf den Block-Storage und dessen Management gewährleistet. Für einen OpenStack-Host präsentiert sich der Speicher als Block-basiertes Gerät, das iSCSI, Fibre Channel, NFS oder andere proprietäre Protokolle für die Backend- und Frontend-Verbindungen nutzt.
Das Cinder-Interface spezifiziert eine Anzahl diskreter Funktionen, darunter grundsätzliche Funktionalitäten wie Volumes erstellen, Volumes löschen und anhängen. Darüber hinaus gibt es noch komplexere Funktionen wie das Erweitern von Volumes, Snapshots, Clones sowie das Erstellen eines Volumes von einem VM-Image.
Viele Storage-Array-Hersteller bieten mittlerweile den Support für Cinder Block Storage an. Dazu gehören unter anderem EMC, Hitachi Data Systems, HP, IBM und NetApp. Zudem unterstützen zahlreiche Start-ups wie SolidFire, Pure Storage und Zadara Storage. Die meisten Anbieter gewährleisten Unterstützung für iSCSI, einige unter ihnen auch Fibre Channel und NFS.
OpenStack-Implementationen werden normalerweise bei Scale-out-Server-Konfigurationen eingesetzt, was Fibre Channel nicht zur besten Wahl beim Protokoll macht. Es ist meist zu teuer und zu komplex zu implementieren, was an den Hardware-Kosten und den Problemen liegt, die bei der Fibre-Channel-Skalierung über viele Storage-Nodes hinweg auftreten können.
Die Einführung des NFS-Support erfolgte mit dem Grizzly-Release, obwohl es schon experimentell in der Folsom-Version steckte. VM-Volumes auf NFS-Storage werden als individuelle Files behandelt, ähnlich wie bei der Implementation von NFS-Storage auf VMware oder VHDS auf Hyper-V.
Durch die Einkapselung der Virtual Disk (virtuelle Festplatte) als File können Systeme Snapshots anlegen oder andere Funktionen auf File-Level können Eigenschaften wie Cloning bieten.
Einige Start-ups unterstützen Cinder mit ihren eigenen Protokollen, so zum Scality oder Coraid. Ebenso gibt es Open-Source-Speicherlösungen von Ceph und GlusterFS, die den Cinder-Support mittels Ceph RADOS Block Device (RBD) bzw. das native GlusterFS-Protokoll realisieren.
Die Ceph-Implementation ist interessant, da sie Code verwendet, der bereits im Linux-Kernel integriert ist, was wiederum die Konfiguration und den Support erleichtert. Ceph lässt sich zudem als Target (Ziel) für Glance VM-Images nutzen.
OpenStack Swift Object Storage
Der Support für Object Storage in OpenStack wird über die Swift-Komponente realisiert. Swift stellt einen Scale-out Object Store bereit, der über mehrere Nodes in einem OpenStack-Cluster verteilt ist. Hier sind die Referenzdaten als binäre Objekte (und nicht als Files oder LUNs), die typischerweise mit nur einem Kommando als ganzes Objekt gespeichert oder abgerufen werden. Objekte werden über HTTP-Protokolle mit einfachen Kommandos wie „PUT“ und „GET“ gesichert und aufgeführt.
Bei Swift werden Objekte physisch auf Objekt-Servern gespeichert, eine Einheit von vielen, die einen Ring bilden, der ebenso Proxy-Server, Container-Server und Account-Server umfasst. Ein Ring repräsentiert Komponenten, die den Swift-Service bereitstellen. Die Server-Komponenten verwalten die Zugriffe und verfolgen den Standort von Objekten in einem Swift-Store. Metadaten werden genutzt, um Informationen über das Objekt abzulegen. Swift verwendet erweiterte Attribute eines Files, um Metadaten zu speichern.
Um Stabilität zu gewährleisten, lassen sich Ringe in Zonen aufteilen, in denen Daten repliziert werden, um für Hardware-Ausfälle gewappnet zu sein. Standardmäßig werden drei Repliken der Daten angelegt, die jeweils in einer anderen Zone gespeichert sind. Bei Swift kann eine Zone eine einzelne Festplatte, ein Server oder ein Gerät in einem anderen Rechenzentrum sein.
Swift macht sich die Idee der möglichen Beständigkeit bei der Replikation für Datenintegrität zunutze. Das heißt, Daten werden nicht synchron im OpenStack-Cluster repliziert, sondern eher als im Hintergrund dupliziert. Die Replikation von Objekten kann fehlschlagen oder ausgesetzt werden, wenn ein Server ausfällt oder das System eine große Workload zu verarbeiten hat.
Die Idee der möglichen Beständigkeit mag riskant erscheinen und es ist möglich, dass in bestimmten Szenarien Daten inkonsistent sein können, wenn ein Server ausfällt bevor diese an eine andere Node im OpenStack-Cluster repliziert wurden. Der Proxy-Server in Swift ist dafür verantwortlich, I/O-Anfragen an den Server zu leiten, der die aktuellste Kopie eines Objektes hat. Sollte ein Server nicht verfügbar sein, so leitet der Proxy-Server die Anfrage an eine andere Stelle im Cluster.
Die Swift-Plattform hat sich weiterentwickelt und verfügt nun über neue und verbesserte Funktionen. Das Grizzly-Release von OpenStack erlaubt eine granularere Replikationskontrolle, bei der Ringe über eine anpassbare Anzahl an Repliken verfügen. Darüber hinaus wurde das Zeit-basierte Sortieren von Objekt-Servern vorgestellt, bei dem die Lese-Anfragen vom dem Swift-Server bedient werden, der am schnellsten antwortet. Das ist vor allem dort nützlich, wo Swift-Server übers WAN verteilt werden.
Da Swift mittels HTTP-Protokoll implementiert wird, muss man die Objekte nicht zwingend lokal ablegen, sondern kann sie in einer anderen Plattform sichern, wie beispielsweise in Cleversafe, Scality oder Amazon S3. Swift ermöglicht es, zuverlässigen Scale-out-Storage auf Standard-Hardware bereit zu stellen und dies ist wohl besser und kosteneffizienter als eine externe Lösung.
OpenStack-Storage wählen
Objekt- und Block-Storage haben sehr unterschiedliche Charakteristika und deswegen eignen sie sich für das Speichern unterschiedlicher Datentypen. Swift wurde konzipiert, ein hoch skalierbarer und weitgehend konsistenter Object Store zu sein. Dadurch eignet es sich für das Speichern großer Datenbestände und Volumes wie zum Beispiel Bilder, Medieninhalte oder Files. Es ähnelt der Amazon-S3-Plattform und verwendet ähnliche Protokolle und Kommandos, um Daten zu sichern und um auf sie zuzugreifen. Swift eignet sich nicht für das Sichern virtueller Maschinen, da es ganze Objekte liest und schreibt, ohne wirkliche Datenintegrität garantieren zu können.
Cinder offeriert ein Block-Storage-Interface, das eher traditionelle Speicherressourcen bereitstellt und eignet sich so für das Speichern persistenter Kopien von virtuellen Maschinen innerhalb einer OpenStack-Umgebung. Cinder kann auf lokalen Servern laufen und internen Support für Open-Source-Projekte wie Ceph und GlusterFS bieten. Ebenso lassen sich integrierte Tools nutzen, um Speicher für ein OpenStack-Cluster bereit zu stellen. Zu diesen Tools zählen unter anderen Server Logical Volume Manager oder NFS-Server. Wer eine zuverlässigere und skalierbare Block-Lösung benötigt, der kann externe Storage-Arrays nutzen. Hier gibt es viele Hersteller, die Cinder-Treiber anbieten. Die jeweilige Effizienz einer Hersteller-Implementation variiert je nach Plattform. So ist zum Beispiel das Scale-out-System von SolidFire völlig API-getrieben, was die Implementation der Cinder-Treiber leicht macht. Andere herkömmliche Hardware-Hersteller verfügen möglicherweise nicht über eine solch einfache Implementation und nutzen in einigen Fällen SMI-S als Interface zum Storage.
Externe Storage-Arrays zu verwenden, um Cinder-Support zu erhalten hat folgende Vorteile: Performance und Verfügbarkeit kann über das Array verwaltet werden und das Array lässt sich nutzen, um Funktionen wie Thin Provisioning, Kompression und Deduplizierung verfügbar zu machen, was Kosten sparen kann.
Nicht alle Hersteller-Implementationen sind gleich und einige benötigen mehr Integrationsaufwand als andere. Aus diesem Grund sollten Sie die Hersteller befragen, wie Cinder implementiert wird.
Fazit
OpenStack bietet einen kontinuierlich wachsenden und reifer werdenden Funktionsumfang, der die Anforderungen von Block, File und Object Storage erfüllt. Obwohl die Optionen komplex scheinen, zeigen die vielen Produkte, die den Support bieten, dass OpenStack durchaus einfach in eine existierende Storage-Architektur zu integrieren ist. Das wiederum gewährleistet Konsistenz beim Storage-Management in Enterprise-Installationen.
