Container und Kubernetes brauchen neue Storage- und Backup-Ansätze

Hierarchie der Container-Anforderungen

Der oben erwähnte IDC-Bericht definiert Container-Datenmanagement-Produkte als solche, die sich ausschließlich auf Container, Datenmanagement-Funktionen wie Disaster Recovery und Migrationsfunktionen sowie Container-Storage-Management für den dauerhaften Datenzugriff konzentrieren.

Um diese Anforderungen zu erfüllen, sollten Speicheradministratoren nicht zu Experten für Kubernetes oder andere Container-Plattformen werden müssen, so Yu. Stattdessen wünschen sich diese Kunden ein gewisses Maß an Abstraktion der Kubernetes-Speicher- oder -Systemanforderungen in die allgemein verwendete Infrastrukturterminologie und -software.

DevOps, das sich auf die Softwareentwicklung konzentriert, und Platform Engineering, das sich auf die Schaffung abstrahierter Ressourcen für Entwickler konzentriert, haben andere Bedürfnisse als das von IDC vorgeschlagene Container-Datenmanagement. Container-Storage und Container-Data-Protection werden nicht wie im traditionellen Storage unterschieden, so der Bericht, da der Container-Markt noch nicht an einem Punkt angelangt ist, an dem diese Trennung notwendig ist und die meisten Kunden sie auch nicht aktiv anstreben.

Zu den spezifischen Produkten, die laut IDC die Definition für Container-Datenmanagement erfüllen, gehören Portworx von Pure Storage, die Container-Storage-Angebote von NetApp und Longhorn von SUSE. Zu den anderen genannten Unternehmen gehören Veritas, IBM, Veeam und Catalogic.

Viele Storage-Administratoren wurden von der frühen Einführung von Containern durch Entwickler überrascht und müssen nun sehr komplexe und vernetzte Systeme von Anwendungen unterstützen.

Diese frühen Container-Anwendungen haben vielleicht Open-Source-Software wie Velero verwendet, um in die Kubernetes-Technologie einzutauchen, so Yu, aber diese Anwendungen haben sich zu geschäftskritischen Workloadsentwickelt, die eine angemessene Datenverwaltung erfordern.

„Wenn eine neue Technologie auftaucht, gibt es die Idee, sie zuerst zu implementieren und einzusetzen, um die Vorteile zu nutzen, und später Fragen zu stellen“, erklärt Yu. „Wenn Unternehmen in Container einsteigen, müssen sie wirklich vorausplanen und sehen, was ihre Roadmap für die nächsten drei bis fünf Jahre ist.“

Container-Planung

Der Aufschwung von Containern – insbesondere Kubernetes – in Unternehmen wurde unkontrolliert betrieben, was sich nachteilig auf einen Gesamtplan oder die Ressourcenzuweisung auswirkte, sagt Brent Ellis, Analyst bei Forrester Research.

Container wurden als eine komplizierte neue Technologie angesehen, die nicht in den Bereich der Infrastruktur fällt, so Ellis.

„Die IT-Verantwortlichen, die vor fünf Jahren mit Kubernetes experimentierten, hatten freie Hand“, erläutert Ellis. „Die zentralisierte IT wollte damit nichts zu tun haben.“

Dennis Smith, Analyst bei Gartner, fügt hierzu an, dass die Ängste der Unternehmens-IT in Bezug auf Anwendungen und die vorgeschriebene Betriebszeit des Speichers sinnvoll waren, da die Unterstützung von Container-Anwendungen nicht zum Fachwissen der meisten IT-Abteilungen gehörte.

„Vor einigen Jahren hätte ich typischerweise keine zustandsbehafteten (stateful) Container-Anwendungen empfohlen, außer für bestimmte Organisationen, die sehr erfahren sind“, so Smith. „Container sind inzwischen viel allgegenwärtiger, aber viele Unternehmen sind noch nicht bereit. Sie haben nicht die Zeit oder die internen Fähigkeiten.“

Weder in der Studie von Forrester noch in der von Gartner wurde der Infrastrukturbedarf für Container-Plattformen im Vergleich zu reinen Container-Orchestrierungsplattformen getrennt. Aber sowohl Smith als auch Ellis wiederholten Yus Aussage, dass die Planung der Skalierung und Anpassung von Container-Workloads der Schlüssel zur Vermeidung zukünftiger logistischer Probleme ist.Die Einführung eines standardisierten Container-Storage-Interface-Treibers (CSI) in Kubernetes vereinfachte die Verwaltung für Infrastrukturteams, so Ellis. Dieser Standard ermöglichte es mehr Anbietern von Speicher- oder Datensicherungslösungen, ihre Produkte miteinander zu verbinden, und hat sich unter den Speicherunternehmen weiter verbreitet.

Die IT-Mitarbeiter, die vor fünf Jahren mit Kubernetes experimentierten, hatten freie Hand. Die zentralisierte IT wollte damit nichts zu tun haben.

„Ich würde nicht sagen, dass das Speichermanagement in Kubernetes einfach ist, aber es ist viel besser als noch vor zwei oder drei Jahren“, betont Ellis.

Bei der Planung der Infrastruktur zur Unterstützung von Containern sollte die IT-Abteilung überlegen, welche Workloads mit einem Container-Ansatz im Vergleich zu traditioneller IT oder VMs am besten bedient werden können, so Smith. In den Anfängen von Containern versprachen die Anbieter, ähnlich wie bei der Cloud, einen Lift-and-Shift-Ansatz, aber die Kunden mussten letztlich feststellen, dass ihre Anwendungen nicht die gewünschte Leistung erbrachten, während sie zu viel bezahlten.

„Es gibt Anbieter, die das Lift and Shift von Legacy-Workloads in Container forciert haben“, bemerkt Smith. „Gartner hat sehr deutlich auf die Risiken aus betrieblicher Sicht hingewiesen.“

Viele dieser Aufgaben werden sich wahrscheinlich unter die Kontrolle von Plattformingenieuren verlagern, die ein besseres Verständnis dafür haben, wie Entwickler bestimmte Technologien nutzen und wie Dienste in Anspruch genommen werden sollten. Die IT-Infrastruktur- und Speicheradministratoren könnten sich dann auf die Betriebszeit und Verfügbarkeit von Speicher konzentrieren, anstatt sich mit spezifischen Preis- oder Rationierungsproblemen zu beschäftigen.

„Die Platform-Engineering-Bewegung ist die neue Bewegung der IT-Zentralisierung“, meint Ellis. „Plattform-Ingenieure werden die Funktionalität offenlegen.“