zhu difeng - Fotolia
Storage für Container im Aufwind
Storage für Container ist immer stärker gefragt. Aber auch wenn Container viele Vorteile bringen, sind noch nicht alle anfallenden Speicherprobleme gelöst.
Seit Jahrzehnten gilt in der Speicherverwaltung das Bestreben, zuverlässige, langlebige und Hardware-basierte Datenspeichersysteme zu erschaffen. In den vergangenen 20 Jahren bedeutete dies eine gemeinsame Speicherplattform als primären Speicherort für Daten.
Da die Speicherformfaktoren jedoch fragmentierter werden, bieten einige Anbieter sogar dauerhaften Speicher auf Grundlage temporärer Einheiten wie Container an. Ist dies sinnvoll und wie kann Langlebigkeit mit solch einem flüchtigen Konstrukt erreicht werden?
Shared Storage entstand aus der Notwendigkeit heraus, Kosten zu reduzieren, den Verwaltungsaufwand für Speicher zu konsolidieren und eliminieren, der auf Hunderten oder sogar Tausenden von Servern im Rechenzentrum benötigt wird.
Dafür war ein Shared Storage Array eine gute Lösung. Fibre Channel und Ethernet-Netzwerke bieten die Möglichkeit, Server über große Entfernungen miteinander zu verbinden, ohne dass Probleme mit Kabelverbindungen auftreten. Zudem reduziert der Unterhalt von ein oder zwei physischen Geräten – anstatt Hunderten – nicht nur die Wartung, sondern auch die Kosten für Kunden und Lieferanten.
Inzwischen leben wir in einem anderen Zeitalter. Heutzutage werden Anwendungen meist virtualisiert und die Containertechnologie beginnt an Bedeutung zu gewinnen. Gemeinsam genutzter Speicher wird inzwischen als schwierig zu nutzen eingestuft, da er darauf ausgelegt ist, physische Server mit physischem Speicher zu verbinden.
Moderne Anwendungen arbeiten jedoch mit logischen Volumen, Dateisystemen und Objektspeichern. Public Cloud Computing erweitert dieses Modell und verschleiert die physische Sicht auf die Hardware insgesamt.
Die Persistenz, also Langlebigkeit, von Daten ist jedoch weiterhin wichtig. Wie können wir dies erreichen und gleichzeitig die Anforderungen neuer Methoden für die Bereitstellung von Anwendungen erfüllen? Dafür ist es lohnenswert, die neuen Anforderungen zu betrachten.
Container, Speicher-Array, I/O-Blender
Die Virtualisierung brachte uns das Problem des I/O-Blenders – eine zunehmend zufällige Arbeitslast, die von vielen virtuellen Maschinen erzeugt wurde, die auf dieselbe LUN (Logical Unit Number) oder Dateifreigabe zugreifen. Um die Probleme mit gemeinsam genutztem Speicher in virtualisierten Umgebungen zu lösen, führte beispielsweise VMware ein eigenes Dateisystem mit spezifischen zusätzlichen Befehlen ein, um Konflikte und Fragmentierung zu reduzieren. Daneben wurden weitere Features wie VMware Virtual Volumes (VVOLs) etabliert, die speziell darauf abzielen, die physische LUN zu eliminieren und virtuelle Maschinen als Objekte zu behandeln.
Die Probleme mit dem Speicherzugriff, die bei der Server-Virtualisierung auftreten, werden mit Containern noch weiter verschärft. In der Container-Welt kann ein einzelner physischer Host Hunderte von Containern ausführen, die jeweils um Speicherressourcen konkurrieren. Wenn jeder Container Zugriff auf einen langen und komplexen Speicherstapel hat, führt dies zu Konflikten und widerspricht den Vorteilen des leichtgewichtigen Charakters eines Containers.
Aber genau das bieten viele Lieferanten an. Volume-Plug-ins für Docker erlauben beispielsweise eine Automatisierung, um LUNs und Volumes auf physischen Arrays physischen Hosts und dann einem einzelnen Container zuzuordnen.
Mit der zunehmenden Einführung von öffentlichen und hybriden Cloud-Architekturen wird die Idee eines zentralen festen Speicherarrays zu einem Problem. Anwendungen sind portabler geworden und können Container in Sekundenschnelle und an vielen verschiedenen Standorten im Rechenzentrum hochfahren. Dieses Modell steht im deutlichen Gegensatz zu dem von physischen Servern, die typischerweise installiert und jahrelang nicht verschoben werden, bevor sie schließlich stillgelegt werden.
Wie wir nun feststellen, bringt die Bereitstellung von Speicher für Containerumgebungen neue Anforderungen mit sich, darunter:
- Datenmobilität – Container bewegen sich, auch Daten müssen das können. Das heißt, im Idealfall nicht nur zwischen Hosts in einem Rechenzentrum, sondern über geografische Standorte hinweg.
- Datensicherheit – Container müssen auf einer logischen oder Anwendungsebene und nicht auf LUN-Ebene gesichert werden, da Container regelmäßig recycelt werden.
- Performance – Container führt die Idee von Hunderten von nicht miteinander verwandten Anwendungen ein, die auf demselben physischen Host arbeiten. I/O muss effizient und leicht zu priorisieren sein.
Speicherplatz für Container bereitstellen
Eine Lösung für das Problem von persistentem Speicher und Containern ist, Container selbst als Speicherplattform zu verwenden.
Auf den ersten Blick scheint dies jedoch eine schlechte Idee zu sein. Denn ein Container ist für einen temporären Gebrauch konzipiert und kann daher jederzeit verworfen werden.
Darüber hinaus ist die Identität eines einzelnen Containers nicht in einer Form festgelegt, wie sie von traditionellen Storage-Systemen verwendet werden. Außerdem gibt es kein Konzept von Host-WWNs oder iSCSI-IQNs. Wie kann also ein persistenter Speicher mit Containern erzielt werden und warum lohnt es sich, dies zu tun?
Lassen Sie uns zuerst die „Warum“-Frage beantworten.
Wie wir bereits festgestellt haben, können Container kurzlebig sein und wurden auf Effizienz ausgelegt. Die größtmögliche Eliminierung des I/O-Stacks trägt zur Gesamtleistung einer Containerumgebung bei.
Wenn Speicher über einen Container bereitgestellt wird, ist der Kommunikationspfad zwischen Anwendung und Speicher sehr leicht – einfach zwischen Prozessen auf demselben Server. Wenn sich eine Anwendung verschiebt, kann ein Container auf dem neuen Host Zugriff auf den Speicher bereitstellen, einschließlich des Hochfahrens eines dedizierten Speicher-Containers, falls noch keiner vorhanden ist.
Sicherlich gibt es eine Menge Backend-Arbeiten zu erledigen, um die Daten geschützt und auf mehreren Hosts verfügbar zu halten. Dies ist jedoch weniger herausfordernd, als bei herkömmlichen Speicher-Arrays, da für viele Anwendungen nur ein Container auf ein Datenvolumen nur einmal zugreift.
Durch die Auflösung (Disaggregation) des Speicherzugriffs wird in gewisser Hinsicht eines der Probleme beseitigt, das mit NVMe (Non-Volatile Memory Express) häufig auftritt, und zwar dass Daten über einen gemeinsamen Controller übertragen werden.
NVMe ist wesentlich leistungsfähiger als herkömmliches SAS/SATA. Dadurch wird jedoch ein gemeinsam genutzter Controller zum neuen Engpass für den Speicher. Disaggregation hilft dabei, dieses Problem zu beheben, genau wie hyperkonvergente Systeme die Kapazität und Leistung für den Speicher über eine horizontal skalierte Serverarchitektur verteilen.
Die Frage nach dem „Wie“ kann beantwortet werden, indem man den Ort der Persistenz betrachtet.
Die Medien bieten hierfür die Antwort: entweder HDDs oder Flash-Laufwerke, die diese Fähigkeit bieten. Konfigurationen, Zugriffe und so weiter können über mehrere Knoten und Medien verteilt werden, wobei Konsensus-Algorithmen verwendet werden, um sicherzustellen, dass Daten über mehrere Knoten und Geräte hinweg geschützt sind.
Auf diese Weise kann, wenn ein Host oder Container ausfallen würde, der den Speicher liefert, ein anderer hochgefahren werden oder die Arbeitslast auf die verbleibenden Knoten, einschließlich der Anwendung selbst, neu verteilt werden. Dadurch könnten die Daten mit der Anwendung verschoben werden.
Anbieter von Container Storage
Diese Art der Architektur wird von Start-up-Unternehmen wie Portworx, OpenEBS, Red Hat und StorageOS implementiert. Jedes verwendet eine verteilte knotenbasierte Scale-Out-Architektur mit Speicher und Anwendungen, die auf derselben Plattform ausgeführt werden. Im Wesentlichen handelt es sich um ein hyperkonvergentes Modell für Container.
Einige Anbieter wie Scality (mit RING) und Cisco HyperFlex (früher Springpath) verwenden für die Skalierbarkeit Container innerhalb der Architektur, obwohl die Produkte nicht nur für Container-Umgebungen geeignet sind.
Für alle Lieferanten ist die Integration mit Container-Orchestrierungsplattformen unerlässlich. Kubernetes ist in diesem Bereich führend, wobei Kubernetes Volumes der wahrscheinlichste Weg ist, Speicher in diesen Umgebungen zu erfassen.
Kinderkrankheiten
Es gibt einige Probleme, die noch angegangen werden müssen, wenn die Technologie weiter ausreift.
Erstens ist es die Frage nach den Datendiensten. Offensichtlich wirken sich Komprimierung und Deduplizierung negativ auf die Leistung aus. Die Effizienz dieser Funktionen wird der Schlüssel für eine wachsende Akzeptanz sein, dies haben wir bereits im All-Flash-Markt gesehen. Endbenutzer werden Datenschutz wie Snapshots, Klone und Replikation erwarten.
Dann gibt es auch das Thema der Integration mit der Public Cloud. Die heutigen Lösungen konzentrieren sich hauptsächlich auf Single-Site-Implementierungen, aber echte Mobilität bedeutet, dass Daten in einer hybriden Umgebung verschoben werden können, was eine größere Herausforderung darstellt.
Schließlich sollten wir Sicherheitsaspekte hervorheben. Die aktuelle Meltdown-Schwachstelle birgt ein besonderes Risiko für Container sowie die Möglichkeit, auf Daten von einem Container auf einen anderen bei ungepatchten Systemen zuzugreifen. Dies wirft Fragen bezüglich der Datensicherheit und der Verwendung von Techniken wie In-Memory-Verschlüsselung auf, die zum Schutz vor unbeabsichtigten Datenlecks erforderlich sein kann.
Hier besteht eine besondere Herausforderung für Start-ups, die diese Probleme lösen müssen, bevor sich Container-basierten Speichersysteme durchsetzen können. Es kann auch dazu führen, dass einige Unternehmen denken, dass die Idee der physischen Isolation (geteilter Speicher) einen Weg darstellt, unvorhergesehene Risiken abzumildern, wenn sie entdeckt und gemeldet werden.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
