kalafoto - Fotolia
Data Protection für Container: Docker-Backups richtig umsetzen
Container wie die von Docker sind flexibel und einfach, müssen aber geschützt werden. Wir zeigen hier die wichtigsten verfügbaren Optionen für ein Docker-Backup.
Container sind eine gute Option, Anwendungen mit viel weniger Overhead auszuführen als mit herkömmlichen Bare-Metal- oder virtualisierten Umgebungen. Aber Anwender sollten auch die Data Protection der Container in Betracht ziehen und sich die Frage stellen, ob Container nicht auch ins Backup integriert werden müssen. Die Antwort ist ja – und nein. Dieser Artikel erklärt die Möglichkeiten, wie Container und deren Daten gesichert werden, und welche Produkte derzeit verfügbar sind.
Container gibt es seit vielen Jahren, aber der Einsatz von Containertechnologie wurde in den letzten fünf Jahren insbesondere durch Docker so populär gemacht. Die Docker-Plattform bietet ein Framework zum Erstellen, Konfigurieren und Starten von Anwendungen. Dies mit Docker umzusetzen, ist wesentlich einfacher als mit nativen Funktionen der Betriebssysteme Linux und Windows, auf denen sie laufen.
Eine Anwendung ist eine Sammlung von Binärdateien, die auf einem Betriebssystem ausgeführt werden. Die Anwendung spricht die Daten über das Betriebssystem an, um diese in den persistenten Speicher zu lesen und zu schreiben oder um auf Anfragen aus dem gesamten Netzwerk zu reagieren. In den letzten 15 Jahren war die typische Methode der Anwendungsbereitstellung, Anwendungen innerhalb einer virtuellen Maschine (VM) auszuführen.
VMs erfordern Aufwand beim Einrichten und der Verwaltung. Sie müssen repariert und aktualisiert werden. Virtuelle Maschinen können Lizenzgebühren verursachen, wie zum Beispiel Betriebssystem-Lizenzen und Anwendungslizenzen pro VM, die daher effizient verwaltet werden müssen.
Container bieten eine viel leichtere Möglichkeit, Anwendungen zu betreiben. Anstatt eine ganze VM für jede Anwendung zu reservieren, ermöglichen Container es mehreren Anwendungen, auf derselben Betriebssysteminstanz zu laufen. Diese werden voneinander isoliert, indem die Prozesse, aus denen sich jede Anwendung zusammensetzt ist, getrennt werden.
Container wurden für den Betrieb von Mikroservices entwickelt, sind kurzlebig und benötigen keine dauerhafte Speicherung. Die Datenrobustheit oder Resilienz wird üblicherweise von der Anwendung verarbeitet, aber in der Praxis hat sich dies als unpraktisch erwiesen. Dadurch können Container nun problemlos mit persistenten Speicher-Volumes zum Einsatz kommen oder mit anderen verteiltem Storage zusammen arbeiten.
Data Protection für Container
Ein Container wird von einem Container-Image gestartet, das die für die Anwendung erforderlichen Binärdateien enthält. Beim Start können Zeitparameter an den Container übergeben werden, um Komponenten wie Datenbanken oder Netzwerkports zu konfigurieren. Dazu gehört das Verbinden an persistente Data Volumes an den Container oder das Mappen von File Shares.
In der Welt der virtuellen Maschinen werden die VMs und die Daten gesichert. Die Sicherung einer virtuellen Maschine dient der Sicherheit und anderen möglichen Einsatzzwecken. So können beispielsweise bei einer Beschädigung der VM oder dem Löschen einzelner Dateien diese wiederhergestellt werden. Alternativ kann die gesamte VM und ihre Daten schnell wiederhergestellt werden. In der Praxis kann es jedoch bei einem gut konfigurierten System schneller gehen, die VM aus einem Gold Master (oder auch Gold Image) neu zu erstellen und über Automatisierung oder Skripte zu konfigurieren.
Mit Containern ist ein Restore der Anwendung aus Code noch schneller, so dass es nicht notwendig ist, den Container selbst zu sichern. Tatsächlich wäre der Aufwand für die Wiederherstellung eines Container-Backups aufgrund der Art und Weise, wie Container von Plattformen wie Docker gestartet werden, wahrscheinlich viel größer, als nur ein neues Container-Image neu zu starten. Die Plattform ist einfach nicht für das Recovery bereits vorhandener Container ausgelegt.
Während also eine laufende Containerinstanz nicht gesichert werden muss, so müssen Basis-Image und die Konfigurationsdaten ins Backup. Ohne diese kann die Anwendung nicht neu gestartet werden.
Das Gleiche gilt für die Umsetzung einer Disaster-Recovery-Strategie. Der Neustart einer Anwendung an anderer Stelle (zum Beispiel in der Public Cloud oder einem anderen Rechenzentrum) erfordert ebenfalls Zugriff auf das Container-Image und die Laufzeitkonfiguration. Diese Komponenten müssen hochverfügbar und repliziert oder standortübergreifend zugänglich sein.
Anwendungsdaten
Container bieten mehrere Möglichkeiten, Anwendungszustände oder Daten zu speichern.
Auf der einfachsten Ebene – am Beispiel von Docker – können Daten in das Root-Dateisystem geschrieben (keine gute Idee) oder in einem Docker-Volume auf dem Host gespeichert werden, auf dem der Container läuft. Es ist möglich, dass dieser Host auch eine virtuelle Maschine ist.
Ein Docker-Volume ist ein Verzeichnis auf dem Root-Dateisystem des Hosts, der den Container ausführt. Es ist möglich, diese Daten zu sichern und in einem laufenden Container wiederherzustellen, aber dies ist keine praktische Lösung oder einfach zu verwalten, da Container auf vielen Hosts laufen können.
Es wäre sehr schwierig, den Überblick zu behalten, wo ein Container zu einem bestimmten Zeitpunkt läuft, um zu wissen, welchen Server man für die Wiederherstellung verwenden soll. Die Backup-Software kennt den Container selbst nicht, nur eine Reihe von Verzeichnissen.
Andere Alternativen
Eine Alternative ist die Verwendung eines anderen Dateisystems auf dem Host, das entsprechend der Anwendung strukturiert wurde. Anstatt Verzeichnisse mit zufälligen GUIDs zu benennen, können Verzeichnisnamen auch mit Anwendungskomponenten übereinstimmen.
Wenn also ein Container gestartet wird, wird ein Verzeichnis in den Container mit einem Namen gemappt, der über den Neustart des Containers hinweg konsistent ist und in der herkömmlichen Backup-Software leicht identifiziert werden kann. Dies bietet immer noch keine vollständige Wiederherstellung und Disaster Recovery im Falle eines Serverausfalls.
In diesem Fall bieten Docker und Kubernetes die Möglichkeit, externen Speicher mit einem Container zu verbinden. Der Speicher wird von einem gemeinsamen Array oder einer softwaredefinierten Speicherlösung bereitgestellt, die unabhängig von einem einzelnen Host existiert.
Externe Speicherung bietet zwei Vorteile:
Für die Data Protection lassen sich die Funktionen eines externen Arrays nutzen, wie zum Beispiel Snapshots oder Remote-Replikation nutzen. Dadurch wird die Persistenz nach unten in den Speicher gebracht und der Container-Host kann effektiv zustandslos sein.
Daten können auf einem externen Gerät vorhanden sein und mit der traditionellen Infrastruktur wie virtuellen Maschinen ausgetauscht werden. Dies bietet einen möglichen Datenmigrationsweg von VMs in Container für bestimmte Teile einer Anwendung.
Der Speicher, der auf dem Shared Storage vorgehalten wird, kann block- oder dateibasiert sein. Generell haben sich die Lösungen der Anbieter für die Anbindung von blockbasierten Systemen mit einem einzigen Container entschieden. Bei gemeinsam genutzten Arrays besteht der Prozess darin, eine Logical Unit Number (LUN) auf den Host zu mounten, sie mit einem Dateisystem zu formatieren und dann an den Container anzuhängen. Bei Kubernetes können diese Volumes beispielsweise bereits vorhanden sein oder bei Bedarf erstellt werden.
Für softwaredefinierte Speicherlösungen werden viele Volumes nativ in die Container-Orchestrierungsplattform integriert, um Dateisysteme anzubieten, die ohne die Komplexität und Verwaltungskonfiguration externer Geräte auskommen.
Lösungen für die Container Data Protection
Was machen die Hersteller in diesem Bereich? Docker bietet eine Reihe von Best Practices für die Sicherung der Docker-Infrastruktur, obwohl dies nicht für Anwendungsdaten gilt. In der Zwischenzeit verwendet Kubernetes etcd zur Verwaltung des Status, so dass auf der Kubernetes-Website Anweisungen zur Konfiguration von Backups zu finden sind.
Bestehende Backup-Anbieter haben mittlerweile begonnen, Container-Backups anzubieten. Asigra war wahrscheinlich einer der ersten Hersteller im Jahr 2015. Commvault bietet die Sicherung von Daten auf containerbasierten Hosts an.
Anbieter wie Pure Storage, HPE Nimble, HPE 3PAR und NetApp bieten alle Docker-Plugins an, um traditionelle LUNs in die Container-Infrastruktur einzubinden. Dies ermöglicht es, Snapshots auf Array-Ebene für das Backup zu erstellen und die LUNs bei Bedarf auf andere Hardware zu replizieren.
Portworx, StorageOS, ScaleIO, Ceph und Gluster bieten alle native Volumes für Kubernetes. Diese Plattformen arbeiten auch mit Docker zusammen und bieten Hochverfügbarkeit aus Clustering-Perspektive und die Möglichkeit, Backups über Snapshots und Repliken zu erstellen. Kubernetes setzt auf die Unterstützung des Container Storage Interface, was ermöglichen soll, zusätzliche Funktionen wie Data Protection in die Spezifikation aufzunehmen.
Wenn Container innerhalb virtueller Maschinen ausgeführt werden, kann die VM selbst gesichert und einzelne Dateien wiederhergestellt werden. Wenn die Backup-Lösung jedoch nicht containerfähig ist, kann es sehr schwierig sein, einzelne Dateien aufzuspüren, es sei denn, sie wurden in die bereits oben beschriebene Struktur eingefügt.
Cloud: Eine Lücke in der Containersicherung?
Die Diskussion über die Containersicherung konzentriert sich auf den Einsatz von Containern im Rechenzentrum. Die Public Cloud stellt eine größere Herausforderung dar. Lösungen wie AWS Fargate (Container-Orchestrierung) bieten bisher keine Datenpersistenz und sind zustandslos konzipiert.
Dies stellt eine potenzielle Lücke dar, wenn es darum geht, Container-Workloads in die Public Cloud zu verschieben. Wie immer muss jede Lösung alle Bereitstellungsoptionen berücksichtigen, was die Einführung einiger Public-Cloud-Funktionen erschweren und das Daten-Management näher an den Entwickler heranführen könnte.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
