Thought Leadership
Software-defined Storage entwickelt sich immer weiter und es gibt viele Option, aus denen Unternehmen wählen können. Container Native Storage beispielsweise hat sich als Lösung herauskristallisiert, die alle Vorteile einer hochverfügbaren, skalierbaren und hyperkonvergenten Hybrid-Cloud-Infrastruktur bietet.
Software-defined Storage erobert weitere Bereiche, in denen es um die Speicherung von Audio- und Videoaufzeichnungen, Daten aus meteorologischen Beobachtungen oder Archive für medizinische Daten etwa beim Gene Sequencing geht. Neu hinzugekommen ist beispielsweise der Einsatz von Software-defined Storage als Ersatz für die Speicherung von Backups auf technisch veralteten Bandlaufwerken mit vergleichsweise teuren Appliances. Eine Software-defined-Storage-Lösung ist flexibler, besser skalierbar und bietet eine höhere Effizienz bei der Umsetzung anspruchsvoller Recovery-Time-Objective (RTO)-, Recovery-Point-Objective (RPO)- und Service-Level-Agreement (SLA)-Ziele.
Big Data Analytics und Object Storage
Große Finanzdienstleister, Einzelhändler, Fertigungsunternehmen sowie E-Commerce- und Telekommunikationsunternehmen haben alle riesige Datenmengen zunächst in umfangreichen und eigens dafür angelegten Daten-Silos gelagert, die beachtliche Hardware-Anforderungen stellen. Meistens werden diese Daten-Silos aufgrund der unstrukturierten Natur der Daten auf Basis von Filesystemen eingerichtet.
Um diese Daten analysieren zu können, muss im Prinzip jeder einzelne Datensatz zuerst aus dem Daten-Silo ausgelesen und dann in die Analytics-Umgebung zur weiteren Analyse kopiert werden. Dies verschwendet Ressourcen und verlangsamt zudem den Analysevorgang. Außerdem stoßen die meisten Filesysteme aufgrund der schieren Datenmenge an Skalierbarkeitsgrenzen. Eine Alternative zu diesen Filesystem-basierten Daten-Silos kann eine Open-Source-basierte Object-Storage-Lösung sein, die sehr große Datenmengen deutlich effizienter als Filesysteme speichern kann..
Object Storage wird üblicherweise mit dem S3-Protokoll zur Verfügung gestellt. Die bekannten Big-Data-Analytics-Frameworks haben hierfür auch eine S3-kompatible Schnittstelle eingeführt: S3A. Über S3A können Analyse-Frameworks einheitlich Daten per S3 aus dem Object Storage lesen. Bei großen Internet-Händlern wird dies heute beispielsweise schon zur Analyse von Kundenverhalten und Kaufinteresse eingesetzt. Auch durch das Internet of Things (IoT) werden enorme Datenmengen produziert. Um diese effizient speichern und analysieren zu können, werden skalierbare und offene Ansätze wie Object Storage benötigt.
[widgetkit id=”112″ name=”Red Hat- Fokus Storage”]
Container-Technologie verzahnt Entwicklung und Betrieb
Die stärkere Verbreitung der Container-Technologie in den letzten beiden Jahren hat auch die Art und Weise beeinflusst, wie Entwickler Rechen- und Speicherressourcen für neue Applikationen kombinieren. Linux-Container bieten eine komfortable und effiziente Methode zur Entwicklung und Auslieferung von Applikationen. In einem nach außen hin abgeschlossenen Paket verkapseln Container die Applikationslogik und Konfigurationsangaben. Im Hinblick auf die Applikationsarchitektur werden große monolithische Einheiten in kleine, unabhängig voneinander einsetzbare Konstrukte – sogenannte Microservices – verwandelt. Container gelten damit als Schlüsseltechnologie zur Einführung von Microservices.
Mit Container-basierten Umgebungen können Entwickler einfach Microservices einzurichten und diese mit Applikationen verbinden; vor allem sind sie dabei nicht mehr auf die Unterstützung von IT-Infra¬strukturspezialisten angewiesen. Die verbesserte Koordination und letztlich die Verzahnung von Applikationsentwicklung und Betrieb der IT-Infrastruktur ermöglichen kürzere Testzyklen, eine schnellere Bereitstellung von Applikationen, eine höhere Softwarequalität und ein vereinfachtes Applikations-Management.
Container eignen sich hervorragend für die Verkapselung einer Anwendung und der Laufzeitumgebung. Jedoch waren Container bis vor kurzem „stateless“. Das heißt, es fehlte die Möglichkeit, Applikationsdaten über den gesamten Lebenszyklus eines Containers und darüber hinaus zu speichern. Mit Cloud-APIs wie zum Beispiel S3 lässt sich diese Anforderung umsetzen, allerdings müssen Entwickler dazu ihre Applikationen entsprechend anpassen. Software-defined Storage wird der Herausforderung, persistenten Speicher bereitzustellen, besser gerecht, denn Software-defined Storage steht in physischen Umgebungen, virtualisiert und auch in Form von Software-Containern bereit. Um in Applikations-Containern persistenten Speicher bereitzustellen, gibt es zwei Möglichkeiten: Shared Storage und Container Native Storage.
Auf Basis eines verteilten Filesystems können Infrastruktur-Admi-nistratoren gemeinsam genutzte Speicherkapazitäten für Applikations-Container bereitstellen. Ein typisches Anwendungsszenarium für ein Shared Persistent File System ist die Analyse großer Datenmengen durch mehrere Clients, bei der je nach Bedarf Speicher und Rechenpower dynamisch hinzugefügt werden kann. Storage Appliances sind in derartigen Szenarien bei Weitem nicht so flexibel wie eine Software-defined Storage-Lösung.
Persistenter Storage für Applikations-Container
Der Übergang zu Microservices in den Applikations-Architekturen hat auch Auswirkungen auf die Art der Bereitstellung von Storage. Im Hinblick auf Packing und Deployment sollte Storage selbst containerisiert werden, das heißt, Storage steht ebenfalls als Microservice, verpackt in einem Container, bereit. Gleichzeitig erfordert die stärkere Verbreitung von Microservices eine zentrale Verwaltung von persistentem Storage über eine einheitliche Control Plane.
Mit Red Hat OpenShift Container Platform etwa können Unternehmen neben Applikations- auch persistente Storage-Container (Container Native Storage) bereitstellen, die über das Orchestrierungsframework Kubernetes verwaltet werden. Admini-stratoren sind in der Lage, mit dem Kubernetes Persistent Volume (PV) Framework persistenten Speicher für einen Pool von Anwendungs-Containern, die auf verteilten Servern laufen, bereitzustellen. Mit Hilfe von Persistent Volume Claims (PVCs) können Entwickler PV-Ressourcen anfordern, ohne dass sie über genaue Kenntnisse der zugrundeliegenden Storage-Infrastruktur verfügen müssen. Damit werden der Einsatz und die Provisionierung von Storage für Applikations-Container deutlich vereinfacht. Red Hat OpenShift Container Platform unterstützt die folgenden PV Plug-ins: GlusterFS, Ceph RBD, AWS Elastic Block Store (EBS), OpenStack Cinder, HostPath, NFS, GCE Persistent Disk, iSCSI und Fibre Channel; jedoch kann derzeit nur GlusterFS als Container Native Storage – also containerisiert – eingesetzt werden.
Container Native Storage unterstützt die dynamische Storage-Provisio¬nierung und stellt verschiedene Speichertypen und Multi-Tier-Spei¬cher über Quality-of-Service-Labels in Kubernetes bereit. Mit Container Native Storage profitieren OpenShift-Anwender zusätzlich von einer softwaredefinierten, hochverfügbaren und skalierbaren Speicherlösung, die sowohl On-Premise als auch in Public-Cloud-Um¬gebungen läuft und dabei kostengünstiger sein kann als herkömmliche hardwarebasierte oder vollständig Cloud-basierte Speicherlösungen.
Zudem müssen Anwender keine Storage- oder Infrastruktur-Experten mehr sein, um eine realistische Storage- Umgebung für Enterprise-Anwendungen aufzubauen, sondern konsumieren Storage einfach als Service (StaaS).
Hyperkonvergente Infrastrukturen verbinden Server und Storage
Mehrere Entwicklungsprojekte, Applikationen und Lifecycle-Umge¬bungen können vollständig isoliert voneinander auf einem einzigen Kubernetes-Cluster auf einer Container-Plattform laufen und Ressourcen gemeinsam nutzen. Implementiert in einer hyperkonver¬genten Architektur sind Kubernetes-Knoten in der Lage, Storage- und Applikations-Container auszuführen. Infrastruktur-Administratoren können Storage-Container beispielsweise als Gluster Storage Bricks implementieren, die gemeinsam ein hochverfügbares GlusterFS Volume bilden. Da sich über dieses Volume die Storage-Anforderungen einzelner Server-Knoten bedienen lassen, besteht dann kein Bedarf mehr für dedizierte Storage-Hardware.
Auch native Storage-Container können auf dem gleichen Knoten, auf dem eine Infrastrukturplattform für den Betrieb von Applikations-Containern läuft, implementiert werden. Als Speicherkapazitäten stehen die in den Applikations-Servern verbauten Festplatten beziehungsweise die SSDs zur Verfügung. Unternehmen sparen sich damit eine separate Storage-Infrastruktur. Hyperkonvergenter Storage in Form von Container Native Storage ermöglicht Entwicklern, Speicherkapa¬zitäten granularer zu steuern und zu überwachen. Auch unter DevOps-Aspekten bringen hyperkonvergente Systeme Vorteile, denn Storage- und IT-Administratoren können dann Rechen- und Speicherkapazitäten gemeinsam verwalten.
Autor: Gerald Sternagl ist EMEA Business Unit Manager Storage bei Red Hat
