Container bieten viele Vorteile. Sie können mit einer viel höheren Dichte als herkömmliche virtuelle Workloads ausgeführt werden, was bedeutet, dass weniger Server erforderlich sind. Dies hat den Nebeneffekt, dass die Lizenzkosten und vor allem der Energiebedarf sinken. Aus diesen Gründen werden Container zunehmend zur Grundlage von Initiativen zur Kostensenkung und von breiter angelegten Geschäftsprozessen. Unternehmen streben dabei in der Regel 25 bis 40 Prozent der Anwendungen als einen üblichen Ausgangspunkt an.
Viele Experten sind sich einig, dass in Container gepackte Anwendungen – die über eine Orchestrierungsplattform wie Kubernetes oder Docker bereitgestellt und verwaltet werden – eine zentrale Rolle in der Weiterentwicklung der IT des nächsten Jahrzehnts spielen werden. Laut Gartner werden bis zum Jahr 2025 85 Prozent der Unternehmen Container produktiv einsetzen, während es im Jahr 2019 erst 35 Prozent waren.
Aber was ist mit Storage, Data Protection, Backups, Snapshots, Replication, Hochverfügbarkeit (High Availability (HA)) und Disaster Recovery (DR)? Diese Bereiche sind für die Infrastruktur von Anwendungen eines Unternehmens von entscheidender Bedeutung, können aber eine Herausforderung bei Container-Prozessen darstellen.
Warum sind Container wichtig und wie funktionieren sie?
Man nehme an, das Kerngeschäft eines Unternehmens konzentriert sich auf die häufige Einführung vieler neuer Produkte mit schnellen Nachfragespitzen und den damit verbundenen Anforderungen an Analysen. Es könnte sich beispielsweise um einen Betrieb für Ticketverkauf mit plötzlichen und massiven Umsatzspitzen handeln. Herkömmliche Anwendungen auf einer dreistufigen Architektur (Client-Server-Datenbank) würden sich nur langsam implementieren lassen, wären nicht gut skalierbar und würden bei hoher Nachfrage zusammenbrechen. Container wurden entwickelt, um genau eine solche Situation zu bewältigen.
Das liegt daran, dass Container die unzähligen Komponenten einer Anwendung kapseln – was bedeutet, dass viele solcher Microservices wiederverwendbar sind, wenn neue Anwendungen entwickelt werden. Und sie können sich schnell vermehren, um den Anforderungen einer Skalierung gerecht zu werden. Darüber hinaus enthalten Container die gesamte API-Konnektivität (Application Programming Interface) zu jenen Komponenten, von denen sie abhängen, und können auf zahlreiche Betriebsumgebungen portiert werden. So kann zum Beispiel ein plötzlicher Anstieg der Nachfrage nach Veranstaltungstickets durch eine schnelle Vervielfältigung miteinander verbundener Service-Instanzen von Containern aufgefangen und auf mehrere Rechenzentren, auch in einer Public Cloud, übertragen werden.
Die technischen Grundlagen von Containern bestehen – stark vereinfacht – darin, dass es sich um eine Form der Virtualisierung handelt. Im Gegensatz zu virtuellen Servern laufen sie direkt auf dem Host-Betriebssystem und ohne einen dazwischengeschalteten Hypervisor. Das bedeutet, dass Container eine besonders granulare, leichtgewichtige virtuelle Maschine sind, die in der Regel bestimmte Komponenten der gesamten Anwendung bereitstellt, die durch Code (d. h. Application Programming Interfaces (APIs)) miteinander verbunden sind.
Während es keinen Hypervisor und damit auch keinen daraus folgenden Overhead gibt, profitieren Container von einer Orchestrierungsschicht, die von Tools wie Kubernetes bereitgestellt wird und die einen oder mehrere laufende Container – jeweils mit ihrem Code, ihrer Laufzeit, ihren Abhängigkeiten und Ressource Calls – in Pods organisiert. Die Intelligenz zur Ausführung von Pods befindet sich über ihnen in einem oder mehreren Kubernetes-Clustern.
Die Herausforderungen von Kubernetes an Storage und Backup
Eine der größten Herausforderungen, die es mit Kubernetes zu bewältigen gilt, betrifft Storage und Data Protection. Die Wurzeln dieser Problematik gehen auf die Ursprünge von Containern zurück, die ursprünglich als flüchtige Instanz auf dem Laptop eines Entwicklers laufen sollten und für die die Datenspeicherung nur so lange existierte, wie der Container ausgeführt wurde. Seitdem sich Container in der Anwendungsentwicklung von Unternehmen durchgesetzt haben, ist dies jedoch nicht mehr möglich. Die meisten Anwendungen einer Unternehmensorganisation sind zustandsorientiert, d.h. sie erstellen, beeinflussen und speichern Daten.
Orchestrierung oberhalb des Orchestrators
Unternehmen, die Container mit Storage und Data Protection der Unternehmensklasse bereitstellen möchten, müssen sich daher mit einer neu aufkommenden Klasse von Produkten befassen. Dabei handelt es sich um die Management-Plattform von Container Storage, von der aus sie Kubernetes betreiben und deren Bedürfnisse an Storage und Data Protection erfüllen und verwalten können.
Worauf sollten Unternehmen bei dieser Produktkategorie achten?
Ein wichtiger Punkt ist, dass jedes Kubernetes-Speicherprodukt container-nativ sein sollte. Das bedeutet, dass die Speicheranforderungen einer Anwendung selbst als Microservices in Container-Form bereitgestellt werden. Ihre Anforderungen an Bereitstellung, Konnektivität und Leistung werden als Code geschrieben, mit all der Dynamik und Geschwindigkeit, die dies mit sich bringt. Dies steht im Gegensatz zu anderen Methoden – wie CSI oder Container Storage Interface – die auf fest programmierte Treiber für den an die Container zugewiesenen Speicher angewiesen sind.
Inzwischen sollte eine software-definierte, container-native Kubernetes-Speicherplattform Zugriff auf Block-, Datei- und Object-Storage zur Verfügung stellen und in der Lage sein, auch auf Cloud-Storage zurückzugreifen. Dabei sollte sie die zentralen Merkmale und Vorteile der Verpackung in Container und von Kubernetes nachbilden. Das bedeutet, dass die Daten genauso portabel sein sollten wie die der Anwendung im Container, dass sie über eine gemeinsame Control Plane verwaltet werden sollten und dass sie autonom skalieren und sich anpassen sollten.
Was die Data Protection betrifft, so sollte ein solches Produkt nach Meinung von Pure Storage alle wichtigen Methoden zur Sicherung von Daten bieten, einschließlich Backups und Snapshots, synchroner und asynchroner Replikation und Migrationsfunktionen. Auch hier sollte die Cloud als Quelle oder Ziel in diesen Vorgängen berücksichtigt werden. Um die Skalierbarkeit von Kubernetes-Umgebungen zu bewältigen, sollte das Produkt in der Lage sein, Cluster, Knoten und Container zu verwalten, die jeweils zu Hunderten, Tausenden bzw. Hunderttausenden laufen, mit einer verwaltbaren Speicherkapazität von mehreren zehn Petabyte.
Schließlich sollte es intelligent reagieren und über eine regelbasierte, automatisierte Verwaltung verfügen, die zum Beispiel das Erstellen, Replizieren und Löschen von Containern entsprechend den voreingestellten Kontrollmechanismen sowie die Bereitstellung und Anpassung der Volumina von Storage nach Bedarf ermöglicht. Wenn man eine Lösung gefunden und implementiert hat, die all diese Kriterien erfüllt, wird man bald selbst erkennen, warum 85 Prozent der Unternehmen bis zum Jahr 2025 auf Container setzen werden.
Malware SmokeLoader wird weiterhin von Bedrohungsakteuren genutzt, um Payloads über neue C2-Infrastrukturen zu verbreiten.
Bankhaus Metzler und Telekom-Tochter MMS testen, inwieweit Bitcoin-Miner das deutsche Stromnetz stabilisieren könnten.
Mit 1,7 Exaflops ist El Capitan nun der dritte Exascale-Supercomputer weltweit. Deutschland stellt erneut den…
Der deutsche Hyperscaler erweitert sein Server-Portfolio um vier Angebote mit den neuen AMD EPYC 4004…
Beim Online-Gaming kommt es nicht nur auf das eigene Können an. Auch die technischen Voraussetzungen…
Fast jedes zweite Unternehmen bietet keinerlei Schulungen an. In den übrigen Betrieben profitieren oft nur…