Eine OpenStack-Storage-Cloud aufbauen

Mit den OpenStack-Komponenten Cinder und Swift lassen sich Block- und Object-Storage innerhalb einer Private Cloud installieren.

Auf dem Weg zum Web-Scale-Computing haben wichtige Technologien wie Virtualisierung, x86-Architekturen und die Verbreitung der DevOps-Methodologie das IT-Eco-System nachhaltig transformiert. Die Anzahl implementierter Systeme steigt nach wie vor an und die nächste Herausforderung ist somit effiziente und effektive Orchestrierung und Management von Compute-, Storage- und Netzwerk-Ressourcen, um die Services einer Private Cloud bereitzustellen.

OpenStack ist ein Open-Source-Cloud-Plattform-Projekt, das 2010 als gemeinsames Projekt von der NASA und RackSpace ins Leben gerufen wurde. Die OpenStack Foundation verwaltet den Quell-Code, verteilt wird die Software mittels Apache-Lizenz. Das erlaubt freie Distribution sowie Modifizierung des Codes, wobei die originalen Copyright-Notizen vorgehalten werden müssen.

OpenStack erlangte seine Popularität als Plattform zur Implementierung von Scale-out-Applikationen und wird von zahlreichen Service-Providern verwendet, um Public Clouds zu realisieren. Ebenso nutzen große Firmen diese Plattform, um Private-Cloud-Infrastrukturen zu implementieren. 

Es ist wichtig, zu wissen, dass OpenStack konzipiert wurde, um mit Scale-Out-Anwendungen zu arbeiten. Es eignet sich nicht unbedingt für die Installation traditioneller monolothischer Applikationen wie beispielsweise Microsoft Exchange oder jene, die auf Datenbanken wie Oracle basieren.

Die OpenStack-Software umfasst viele verschiedene Module, die unterschiedliche Aspekte von Cloud-Umgebungen adressieren. Dazu gehören:

  • Swift: Object Storage
  • Cinder: Block Storage
  • Nova: virtuelle Maschinen (VMs)/Compute
  • Neutron: Networking
  • Horizon: Dashboard
  • Keystone: Identity Services
  • Glance: Image Service
  • Ceilometer: Telemetry
  • Heat: Orchestration
  • Trove: Database as a Service (DBaaS)

Mit der Veröffentlichung des OpenStack-Codes (aktuell in der 10. Version) entstehen neue Projekte oder bestehende werden erweitert oder neu gestartet. Dazu gehören Ironic für Bare Metal Provisioning und Sahara für Elastic MapReduce, welches im Juno-Release von OpenStack enthalten war.

Daten-Service werden über fünf Komponenten realisiert. Swift ist das Sub-Projekt, das Object Storage für die OpenStack-Infrastruktur bereitstellt. Block-Storage wird durch Cinder mit Standard-IP-Protokollen wie NFS oder iSCSI umgesetzt. 

Glance stellt ein Repository für VM-Images zur Verfügung und nutzt das darunter liegende Storage eines File-Systems oder Swift. Trove gewährleistet DBaaS (Data-Base-as-a-Service)-Funktionalitäten und Sahara Elastic MapReduce-Feature, die man herkömmlich als Storage für Hadoop-Cluster kennt. In diesem Beitrag konzentrieren wir uns auf die beiden wichtigsten Storage-Plattformen Swift und Cinder.

Cinder für Block-Storage

Block-Storage ist eine essentielle Komponente für virtuelle Infrastrukturen und bildet die Basis, um VM-Images und von virtuellen Maschinen genutzte Datenbanken zu speichern.

Bis zum Zeitpunkt des Folsom-Release und der Einführung von Cinder, waren virtuelle Maschinen kurzlebig und ihr Storage hielt auch nur für die Lebensdauer der jeweiligen VM. Cinder unterstützt das Management von Block-Storage. Dies wird mittels iSCSI, Fibre Channel oder NFS und andere proprietäre Protokolle mit Backend-Konnektivität an den Compute-Layer (Nova) gegeben.

Das Cinder-Interface garantiert einige Standard-Funktionen, welche die Erstellung von Block-basierten Geräten und deren Verbindung zu den VMs ermöglicht. Das sind unter anderem „create volume“, „delete volume“ und „attach volume“. Weitere Funktionen unterstützen die Möglichkeit Volumes zu vergrößern, Snapshots anzulegen und Clones von VM-Images zu erstellen

Viele Hersteller unterstützen Cinder Block-Storage mit ihren bestehenden Hardware-Plattformen mithilfe von Cinder-Treibern, die das Cinder API in Kommandos für die speziell eingesetzte Hardware übersetzt. Zu diesen Anbietern gehören EMC (VMAX, VNX), Hewlett-Packard (3PAR StoreServ, StoreVirtual), Hitachi Data Systems, IBM (alle Storage-Plattformen), NetApp, Pure Storage und SolidFire. Ebenso gibt es Software-basierte Lösungen von Herstellern wie EMC (ScaleIO) und Nexenta.

Zusätzlich dazu lassen sich zahlreiche Storage-Software-Installationen, darunter auch Open-Source-Plattformen, für Cinder-Support nutzen, beispielsweise Red Hat mit Ceph und GlusterFS. Ceph wurde in den Linux-Kernel integriert, was der einfachste Weg ist, Block-Storage für eine OpenStack-Implementation bereitzustellen.

NFS-Support kam 2013 mit dem siebten OpenStack-Release (Grizzly) auf den Markt, obwohl bereits in Folsom „experimenteller“ Support verfügbar war. NFS behandelt die VM-Volumes als individuelle Files, ähnlich wie es in VMware ESXi Hypervisor oder VHDs auf Microsofts Hyper-V geschieht. Die Einkapselung der VM-Volumes als Files erlaubt den Einsatz von Funktionen wie Snapshots oder Cloning.

Storage-Features wurden in nachfolgenden Cinder-Releases eingeführt und letztlich von den Herstellern unterstützt. Eine umfassende Liste von Hersteller-Plattformen und unterstützten Funktionen kann man auf der OpenStack Wiki-Seite finden, die auch OpenStack-Block-Storage-Treiber auflistet.

Swift Object Storage

Object Storage wird in OpenStack durch Swift realisiert, welches verteiltes Scale-out Object Storage über viele Nodes eines OpenStack-Clusters hinweg gewährleistet. Objekt-Storage speichert Daten als binäre Objekte, ohne spezielle Referenz oder bestimmtes Format. 

Objekt- und Block-Storage

OpenStack-Implementationen teilen sich in Objekt- und Block-basierte Systeme auf. Die Swift-Komponente ermöglicht Object Storage, Cinder Block Storage. Beide Plattformen lassen sich mit Standard-Hardware oder über Integration in traditionelle Storage-Arrays installieren.

Objekte werden von Swift mittels einfacher Kommandos gespeichert und wiedergeholt. Die Kommandos wie „PUT“ oder „GET“ basieren auf dem HTTP-Protokoll, auch bekannt als RESTful API.

Die Swift-Architektur teilt sich in verschiedene logische Services auf. Dazu gehören Objekt-Server, Proxy-Server, Container-Server und Account-Server, die zusammen als Ring klassifiziert werden. Daten werden zusammen mit anderen Komponenten auf Objekt-Servern abgelegt. Die Komponenten nutzt man, um Metadaten zu verfolgen, die zu jedem gespeicherten Objekt gehören, und um den Datenzugriff zu verwalten.

Die Daten-Zuverlässigkeit (resiliency) wird innerhalb Swifts mittels Zonen gemanagt. Eine Zone stellt eine Sub-Komponente des Rings dar und speichert seine Kopie der Daten. Um redundante Datenkopien – so genannte Replicas – abzulegen verwendet man multiple Zonen, (mindestens drei sind als Standard festgelegt). Swift kann eine einzige Festplatte oder einen Server als Zone nutzen. Ebenso lassen sich Daten geografisch zwischen unterschiedlichen Standorten/Rechenzentren verteilen.

Genau wie viele Object-Storage-Konzepte nutzt Swift die Idee der „eventual consistency“, um die Datenzuverlässigkeit zu gewährleisten. Das heißt, die Daten werden nicht synchron innerhalb eines OpenStack-Clusters repliziert, was sich mit Block-Storage umsetzen ließe. Vielmehr werden die Daten zwischen Zonen repliziert. Dies erfolgt als Background-Aufgabe, die aber bei zu hohen Workloads oder einem Systemausfall ausgesetzt werden kann.

Verglichen mit Block-Storage, bei dem synchrone Replikation einen hohen Grad an Datenverfügbarkeit garantiert, erscheint „eventual consistency“ eher riskant. Nichtsdestotrotz muss der Anwender Abstriche bei der Skalierbarkeit, Performance und Datenzuverlässigkeit machen. 

„Eventual consistency“ erlaubt es, Archive viel einfacher zu skalieren als mit Block-basierten Systemen. Im Falle von Swift garantiert der Proxy-Server, dass Daten zurückgeholt werden, selbst wenn einige Server im Cluster nicht mehr verfügbar sein sollten.

Wie alle OpenStack-Projekte wird auch Swift mit jedem Release weiterentwickelt und mit neuen Funktionen und Verbesserungen versehen. OpenStack Grizzly führte granularere Replika-Kontrollen ein, die es ermöglichen, eine anpassbare Anzahl an Replikas in einem Ring zu haben. Ebenso wurde die Lese-Performance der Objekte durch ein Zeit-basiertes Sortieren des Objekt-Servers verbessert. Dadurch können Daten an den Objekt-Server gesendet werden, der am schnellsten reagiert, was wiederum für die Skalierbarkeit größerer Netzwerke wichtig ist.

Da Swift das HTTP-Protokoll nutzt, wäre es durchaus praktisch, Storage-Lösungen von Drittanbietern für Object Storage in OpenStack zu verwenden. Das umfasst Produkte von Cleversafe, Scality oder Public Clouds wie Amazon Web Services Simple Storage Service (S3).

Swift oder Cinder? Die richtige Wahl treffen

Es ist offensichtlich, dass Swift und Cinder unterschiedliche Datenanforderungen bedienen. Swift Object Storage wurde für hoch skalierbaren Speicher für Objekt-basierte Daten wie Media-Daten, Images und Files konzipiert. Der Fokus dieser Systeme ist hohe Skalierbarkeit für große Datensätze bereitzustellen, ohne dabei an traditionelle Storage-Funktionen gebunden zu sein, wie beispielsweise RAID. Allerdings macht das Konzept der „eventual consistency“ Swift-Systeme ungeeignet, um zum Beispiel virtuelle Maschinen zu speichern.

Obwohl Swift Metadaten nutzt, um Objekte und ihre Versionen zu verfolgen, benötigt Object Storage immer noch zusätzliche Logik, um die Nutzer-Metadaten der gespeicherten Objekte verwenden zu können. Dies müsste dann in der Anwendung integriert sein, die der Anwender nutzt.

OpenStack Support-Netzwerk

Mittlerweile sind mehr als 200 Firmen am OpenStack-Projekt beteiligt, die finanzielle Mittel und Mitarbeiter für die Code-Entwicklung in ihren jeweiligen Bereichen zur Verfügung stellen. Traditionelle Hersteller haben darüber hinaus damit begonnen, ihre eigenen Versionen von OpenStack zu entwickeln und veröffentlichen, wie zum Beispiel HP mit seiner Helion-Software. Andere Hersteller offerieren Software oder die Cinder- und Swift-Komponenten zusammen mit ihrer Hardware, um OpenStack-Installationen zu unterstützen.

Cinder gewährleistet die Block-Storage-Komponente, um persistente Objekte wie virtuelle Maschinen und Daten, die stetig wie in Datenbanken aktualisiert werden, zu speichern. Block-Storage-Funktionen lassen sich über ein OpenStack-Cluster hinweg implementieren. 

Dabei können Standard-Komponenten zum Einsatz kommen, die integrierte Tools wie Logical Volume Managers oder NFS nutzen, um Storage-Ressourcen bereitzustellen. Alternativ dazu können Open-Source-Lösungen wie Ceph oder GlusterFS den openStack-Storage vom hauptsächlichen OpenStack-Code separieren, während die Flexibilität, Open-Source-Software zu verwenden, bestehen bleibt.

Da Cinder-Support weit verbreitet ist, lassen sich traditionelle Storage-Lösungen dafür nutzen, Storage-Services in die OpenStack-Installation zu bringen. Das kann von Vorteil sein, wenn eine IT-Gruppe bereits Hardware-Plattformen verwendet und diese entsprechend kennt und managen kann. 

Bereits bestehende Storage-Plattformen sind hoch entwickelt und unterstützen eine Menge Funktionen für die Storage-optimierung, beispielsweise Thin Provisioning, Deduplizierung und Kompression. 

Viele offerieren Quality of Service (wie zum Beispiel HP 3PAR StoreServ und SolidFire), wodurch sich diese Lösungen für gemischte Workloads eignen und nicht nur für den dedizierten Einsatz für OpenStack-Installationen. Das hat den großen Vorteil, dass man die „schweren“ Verarbeitungsaufgaben an externe Storage-Systeme geben kann.

Will der IT-Verantwortliche eine Entscheidung für eine bestimmte Plattform treffen, so müssen System-Architekten das Risiko gegen die Kosten für die „kostenfreie“ OpenStack-Lösung stellen (denn auch die benötigt Hardware) und abwägen, welche Funktionen ihnen dedizierte Hardware bringen würde.

Backup für OpenStack Storage

Nicht zuletzt sollten sich Anwender über ein Backup in OpenStack Gedanken machen. Die Details, wie man die wichtigen Konfigurations-Komponenten der OpenStack-Umgebung sichert, sind bereits gut dokumentiert. Allerdings fällt das Backup der Daten innerhalb eines OpenStack-Clusters in die Verantwortlichkeit des Anwenders. 

Ein Backup ließe sich einfach über externe Storage-Provider installieren: so offeriert beispielsweise SolidFire die Möglichkeit, ganze Cluster in Amazon S3 oder einen Swift-kompatiblen Object Storage zu sichern. Alternativ können EDV-Verantwortliche bestehende Backup-Produkte in Betracht ziehen, die ihren OpenStack-Hypervisor unterstützen.

Raksha ist ein neues Projekt, das Backup-as-a-Service-Funktionen in das OpenStack-Framework bringt. Das umfasst vollständige und inkrementelle Backups von VMs an einem Swift-Endpunkt und ermöglicht gleichzeitig Anwendungskonsistenz. Raksha ist derzeit ein eigenständiges Projekt und kein Teil des OpenStack-Kerns. 

Hier bedarf es intensiver Entwicklungsarbeit, um die Integration in übliche Hypervisor-Plattformen wie vSphere oder Hyper-V umzusetzen. Allerdings könnte es dann eine besser integrierte Data-Protection-Lösung für OpenStack-Umgebungen bieten.

Über den Autor:
Chris Evans ist ein unabhängiger Consultant bei Langton Blue.

Folgen Sie SearchStorage.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Januar 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Data-Center-Storage

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close