Container-Backups garantieren Datenpersistenz

Die Notwendigkeit von Persistenz

Container haben in den letzten vier Jahren enorm an Popularität gewonnen. Mit der zunehmenden Verbreitung ist gleichzeitig allerdings auch klar geworden, dass ein Container-Konzept mit seiner vollständig flüchtigen Anwendungsausführung nicht mit Unternehmensanforderungen kompatibel ist – zumindest nicht in der Art und Weise, wie die IT normalerweise Services liefert. Selbst die 12-Faktor-Methodik für die Anwendungsentwicklung besagt, dass Anwendungen zwar zustandslos (Faktor sechs) und persistent sein sollen, die Daten aber auf einem Backup-Dienst gespeichert werden müssen.

Die neueste Implementierung der von Docker standardisierten Container-Technologie speichert Anwendungsdaten auf dem gleichen Host wie der Container – nämlich in einem dem Container zugeordneten Ordner. Verlieren man den Container, dann verliert man auch die Daten. Viele Unternehmen gingen bisher davon aus, der Schutz von Container-Daten besteht darin, die Daten über viele Container hinweg auf einer robusten Infrastruktur zu replizieren. Schlägt eine einzelne Container-Anwendung fehl, können die Daten aus den restlichen Anwendungen wiederhergestellt werden.

Dieser Ansatz ist jedoch in mehrfacher Hinsicht fehlerhaft:

• Erstens wird davon ausgegangen, dass Container-Anwendungen immer ausgeführt werden. Was aber passiert mit Daten, die für ein paar Tage, Wochen oder Monate nicht benötigt werden?
• Zweitens wird der Aufwand für die Wiederherstellung fehlgeschlagener Datenspeicherungen nicht berücksichtigt. Stellen Sie sich eine schlecht codierte 1 TB Datenbankanwendung vor, die einmal täglich abstürzt. Das bedeutet mindestens 1 TB Datentransfer pro Tag, der sich auf die Produktionsleistung auswirken kann. Es wäre schneller und einfacher, einen neuen Container zu starten und auf vorhandene Daten zu verweisen, als Daten über viele Container hinweg zu replizieren.
• Und Drittens: Weil Container zustandslos sind, ist es schwierig, Technologien wie traditionelle Backup-Produkte zu verwenden. Da sie einen Agenten benötigen, müssten Sie Container-Backups und andere Datensicherungen innerhalb des Containers bereitstellen.

Die Container-Anbieter haben darauf reagiert und sich schnell geändert. Inzwischen können persistente Volumes und Dateifreigaben an Container-Instanzen angehängt werden – selbst unter der 12-Faktor-Methode. Externer oder gemeinsam genutzter Storage auf traditionellen Plattformen wird nun zunehmend an Container-Umgebungen angebunden.

Die externe Speicherung bietet eine Reihe von Vorteilen. Dazu gehören:

• Die Lebensdauer der Daten ist nicht an den Host gebunden, auf dem der Container läuft. Mit Shared Storage kann der Host, auf dem die Container laufen, effektiv zustandslos werden.
• Shared Storage kann auch bei der Skalierbarkeit, Ausfallsicherheit und Performance, wie man sie von traditionellen SAN- und NAS-Plattformen kennt, von hohem Nutzen sein.
• Sie können verschiedene Medien-Performance-Typen verwenden und Performance-Level pro Container anwenden.
• Externer Storage, insbesondere SAN, bietet Datenschutz.
• Externer Storage sorgt für mehr Datenmobilität, insbesondere im Kontext einer Public Cloud.

Unternehmen wollen Daten gesichert, geschützt und geprüft haben: Wenn Sie Container-Daten auf externen Speichermedien vorhalten, werden alle diese Anforderungen erfüllt.

Trennung von Daten und Code

Bevor wir fortfahren, ist es wichtig zu klären, was mit Container-Daten gemeint ist. Ein laufender Container besteht aus zwei Teilen: dem Anwendungscode, zum Beispiel einer Datenbank oder einem Webserver, und den Daten in der Anwendung. Der Anwendungscode oder das Container-Image muss nicht auf externen oder persistenten Medien gespeichert werden. Jedes Mal, wenn ein Container läuft, prüft die Laufzeitumgebung, ob das Image lokal verfügbar ist. Wenn nicht, lädt er es herunter.

Dieser Prozess ist einer der Schlüsselprozesse von Containern. Container-Anwendungen können überall und jederzeit ausgeführt werden, aber nur, wenn ihre Images heruntergeladen werden können oder bereits lokal gespeichert sind.

Man kann nun argumentieren, dass Container-Images angepasst werden müssen. Zum Beispiel kann ein Webserver bestimmte Performance-Einstellungen benötigen oder eine Datenbank muss autorisierte Benutzer hinzufügen können. Diese Änderungen können jedoch per Skript automatisiert werden und lassen sich leicht auf ein Image anwenden, wenn es startet. Es gibt keinen Grund, ein Container-Image nur für die Konfigurationsdaten zu speichern. Es geht immer um die Anwendungsdaten selbst.

Container sind keine VMs

Die bisher beschriebene Implementierung von persistenten Daten erwecken den Anschein, Container sind virtuelle Maschinen. Eine VM auf einer traditionellen Infrastruktur wie VMware kann durchaus ein Boot-Laufwerk und ein oder mehrere Datenlaufwerke haben. Die VM und die Daten sind aber in der Regel lebenslang miteinander verbunden, obwohl es natürlich auch möglich ist, ein Data Volume auf eine andere VM zu verschieben.

Container sind jedoch keine virtuellen Maschinen. Es ist wichtig, sich dessen bewusst zu sein, wenn man tiefer in das Container-Datenmodell einsteigt. Die Anbindung eines externen Speichers bietet die bereits beschriebenen Vorteile, Daten unabhängig von der Container-Anwendung zu halten und sollte nicht als Möglichkeit genutzt werden, Container in VMs umzuwandeln.

Daten für Container

Container-Anwendungsdaten – nicht der Container selbst – müssen geschützt werden. Schauen wir uns an, wie die Container-Daten implementiert werden, um zu verdeutlichen, wie die Container-Sicherung funktioniert:

• Innerhalb des Containers. Auf der Docker-Plattform können Daten im Dateisystem des Container-Images gespeichert werden. Docker verwendet allerdings ein Union-Dateisystem, um die Erstellung von Images zu optimieren. Damit ist das Speichern von Daten innerhalb des Container-Images eine schlechte Idee. Es macht die Container-Sicherung schwierig, da der Zugriff auf die Daten über die Container-Anwendung selbst erfolgt.
• Als Volume. Im Docker-Ökosystem wird ein Volume auf dem lokalen Host gespeichert, auf dem der Container läuft; unter Linux wird es im Ordner /var/lib/docker/volumes gespeichert. Das Volume wird innerhalb des Containers an einem bestimmten Mount-Punkt im Dateisystem gemountet. Kubernetes verwendet ebenfalls das Konzept eines Volumes, das in einer Kapsel (Pod) gespeichert ist. Ein Pod ist ein Objekt, das einen oder mehrere Container enthält und länger als die Lebensdauer eines einzelnen Containers existiert.
• Als Bind-Mount. Docker erlaubt das Mounten eines beliebigen Host-Verzeichnisses in einen Container. Das ist sowohl gut als auch schlecht. Der Host kann eine Dateistruktur haben, um persistente Daten zu halten, aber auch Systemordner und Dateien können versehentlich oder absichtlich auf einen Container abgebildet und verändert werden.
• Durch ein Plug-in. Docker und Kubernetes bieten beide Volume-Plugins, die eine LUN und ein Volume auf einen Container abbilden. Dies kann ein Volume oder eine Dateifreigabe sein, die vor dem Anlegen des Containers existierte oder gleichzeitig mit dem Container angelegt wurde. Einige Storage-Anbieter verwenden Plug-ins, um Storage direkt in einem Container bereitzustellen, entweder von softwaredefinierten oder traditionellen Plattformen.

Wenn Ihre Daten innerhalb des Container-Dateisystems liegen, dann ist die Antwort: Nutzen Sie entweder die Anwendung oder den Container, um die Daten zu sichern. Dieser Ansatz der Container-Sicherung ist beispielsweise für eine Datenbank-Plattform möglich, auf der es einen Standard-Backup-Mechanismus gibt. Aber im Allgemeinen ist es nicht der praktikabelste Ansatz für den Betrieb von Containern.

Volumes, wie die von Docker implementierten, können durch eine Kopie der Daten aus dem Dateisystem des Hosts gesichert werden. Dasselbe gilt für Bind Mounts auf dem Host. In beiden Fällen besteht die Herausforderung darin, den Namen des Volumes oder des Mounts an die Anwendung anzupassen. Docker-Volumes können mit beliebigen Namen erstellt werden, daher ist ein guter Namensstandard unerlässlich.

Das Problem mit Docker-Volumes tritt auf, wenn Sie Daten wiederherstellen müssen. Wenn noch ein Volume auf dem Host vorhanden ist, dann ist es in Ordnung, die Daten mit einer Standard-Wiederherstellung in dieses Verzeichnis zurückzuladen. Wenn das Volume nicht existiert, muss es neu erstellt werden, bevor die Daten wieder eingefügt werden. Dies ist für Bind Mounts weniger problematisch, da der Verzeichnisname außerhalb der Docker-Struktur liegt und jederzeit gesichert und wiederhergestellt werden kann.

Plug-ins ermöglichen das Mappen von Daten auf externen Speichermedien auf einen Container. Das Container Storage Interface – eine Open-Source-Initiative der führenden Container-Orchestrierungs-Anbieter – soll einen einheitlichen Ansatz für diesen Mapping-Prozess entwickeln. Das Plug-in hat die Aufgabe, alle externen Arbeiten auszuführen, die erforderlich sind, um den Storage auf den Container-Host und dann auf den Container selbst abzubilden.

Viele Plug-in-Implementierungen konzentrieren sich darauf, eine LUN und ein Volume aus einem externen Speicher an einen Container anzuschließen. So kann das Volume auch in den Host gemountet und mit herkömmlicher Backup-Software gesichert werden. Alternativ kann das Volume durch einen Snapshot auf dem Storage-Array geschützt und an anderer Stelle wieder gemounted werden, von wo aus es sich sichern lässt.

Das Mounten von Snapshots auf einen Backup-Server ist eine bewährte Technik zum Schutz von Daten. Es bedeutet allerdings, dass das Backup wie eine Absturzkopie aussieht, wenn es wiederhergestellt wird, falls die Container-Anwendung zu diesem Zeitpunkt lief. Auch hier hilft es, LUNs oder Volumes entsprechend zu benennen, um die Daten in Zukunft wiederherstellen zu können. Plug-in-Definitionen erlauben es, vorhandene Volumes auf einen neuen Container abzubilden. Wenn eine LUN aus einem Backup oder Snapshot wiederhergestellt werden kann, ist es einfach, sie dem Host zurückzugeben.

Container-Daten müssen wie alle Unternehmensdaten geschützt werden. Wie Sie die Datensicherung und das Container-Backup am besten implementieren, hängt davon ab, wie Sie Ihr Container-Ökosystem gestaltet haben. Klar ist: Weil sich der Backup-Prozess bei der Migration auf VMs vom Client und Gast entfernt hat, stellen Container die Backup-Daten nicht direkt den traditionellen Backup-Anwendungen zur Verfügung. Stattdessen kann dies auf der darunterliegenden Orchestrierungs-Plattform erreicht werden – entweder auf dem Host oder auf der Storage-Schicht.

Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!