Natives Backup und Disaster Recovery in Container-Umgebungen Kubernetes und die Rolle von „Day-2-Operations“

Anbieter zum Thema

PoINT Software & Systems GmbH

Scality

Cohesity GmbH

Kubernetes hat sich so zum De-facto-Standard für Container-Orchestrierung und -Management entwickelt. Beim Einsatz einer solchen Lösung sollte man sich allerdings frühzeitig über Folgeaufgaben, sogenannte „Day-2-Operations“, Gedanken machen.

Immer mehr Unternehmen setzen für die digitale Struktur der eigenen Anwendungen auf Container. Für viele ist der einfachste Weg, diese zu verwalten, Kubernetes als Framework zu verwenden.

Durch die ohnehin breite Verwendung und die Menge an Hilfsmaterialien ist es ein oft gewählter Ansatzpunkt für Unternehmen, um Container in die eigenen Prozesse einzubinden. Erfahrungsgemäß ist Backup nicht das erste Thema, über das man sich Gedanken macht, wenn man eine neue Technologie einführt, daher spricht man dabei von „Day-2-Operations“.

Ursprünglich waren Container dazu gedacht „stateless“, sprich zustandslose Anwendungen zu verwalten. Kubernetes als Framework entstammt dem Software-Giganten Google, und wenn man sich die Suchmaschine ansieht, ist es hier nicht notwendig, die Daten, also die Suchanfragen, persistent zu speichern. „Stirbt“ ein Container oder das System, auf dem dieser läuft, wird einfach ein neuer Container gestartet, und der User muss seine Suchanfrage neu absetzen oder die Website aktualisieren.

Wollte man Daten behalten, mussten diese in Datenbanken oder Speicherorten außerhalb von Containern gespeichert werden. Dann wurden jedoch persistente Volumes eingeführt, also Speicherplatz, der den „Tod“ eines Containers überdauert und von einem neugestarteten Container weiterverwendet werden kann. Hier gab es lange einen Kampf der Philosophien: stateless vs. stateful.

Datensicherung im Stateful-Kontext

Mittlerweile gibt es immer mehr Datenbanken und Applikationen, die stateful auf Kubernetes laufen und eben auch ihre Daten in der Containerwelt ablegen. Spätestens dann muss man sich Gedanken um eine Datensicherung machen, sollte es sich dabei um wichtige Daten handeln.

Wollen Unternehmen eine gewisse Verfügbarkeit ihrer Entwicklungsumgebung gewährleisten, müssen sie – spätestens wenn produktive Workloads auf Kubernetes betrieben werden – auch darüber nachdenken, wo und wie diese gespeichert werden sollen. Wird hier nämlich falsch konfiguriert oder nicht auch für den Ernstfall geplant, so droht dem Unternehmen der Verlust von wichtigen Daten, welcher immer auch mit dem einem finanziellen Verlust und einem Vertrauensverlust der Kunden einhergeht.

Wer es also vermeiden will, dass die sprichwörtlichen Fließbänder des eigenen Unternehmens zum Erliegen kommen, statt dem erhofften Boost durch die Adaption einer neuen und agileren Technologie, der sollte auch „Day-2-Operations“ mit höchster Priorität angehen. Für Kubernetes bedeutet das, dass Backups und Disaster Recovery nativ in Kubernetes geschehen sollten.

Die gewählte Backup-Management-Lösung sollte dabei selbstständig erkennen, welche Applikationen auf dem Kubernetes-Cluster laufen, auf dem sie aktiv sind. Eine Applikation in Kubernetes besteht in der Regel aus verschiedenen Komponenten (Pods, Services, Deployments, Namespace und so weiter), und entsprechend sollte die Lösung in der Lage sein, diese Workloads Policy-basiert zu sichern und bei Bedarf auch wiederherzustellen.

Stolpersteine können dabei Wiederherstellungen sein, die über verschiedene Kubernetes-Versionen hinweg geschehen – moderne Lösungen sind allerdings in der Lage, die Backups entsprechend zu transformieren. Dadurch sind Unternehmen in der Lage, die Bandbreite an Vorteilen, die die Container-Technologie und Kubernetes anbieten, besser zu nutzen, während sie gleichzeitig gegen Ausfälle und Probleme gerüstet sind.

*Der Autor: Thomas Sandner ist Senior Director Technical Sales bei Veeam Software.

(ID:47641532)