Die Containerisierung erhält immer mehr Einzug in die Unternehmen. Während sich die großen Konzerne schon seit längerer Zeit mit der neuen/alten Art der Virtualisierung auseinandersetzen und bereits einiges an Erfahrung sammeln sowie Optimierungen vornehmen konnten, befinden sich viele kleine und mittelständische Unternehmen aktuell noch im Anfangsstadium. Dies betrifft sowohl das Wissen um die Art und Weise der Entwicklung von modernen Applikationen sowie den Betrieb von Applikationen auf Kubernetes.
Während klassische Applikationen starr und stark an die vorhandene Infrastruktur gebunden sind, geht die heutige Art der Applikationsentwicklung einen wesentlich flexibleren Ansatz. Aus diesem Grund dürften neue, cloud-native Applikationen, welche sich an der „12-Factor App“ [1] orientieren, in Bezug auf die Fehleranfälligkeit von Infrastruktur-Komponenten weniger kritisch zu betrachten sein. Diese Applikationen sind von Natur aus robuster gegen das plötzliche Wegbrechen von z.B. Infrastruktur-Komponenten ausgelegt.
Neben der Neuentwicklung hat sich die Anpassung vorhandener Applikationen auf die neue Infrastruktur als ein zunehmender Trend entwickelt – im Klartext: Die Containerisierung von klassischen Applikationen. Ein Refactoring, also die Anpassung der klassischen Applikation an die „12-Factor App“, erfolgt aus unterschiedlichsten Gründen meist nicht. Ziel der Containerisierung von Applikationen ist die erhöhte Flexibilität, z.B. in Bezug auf Aktualisierung und Portabilität. Dennoch löst diese schnelle und einfache Art der Modernisierung ohne Anpassung der Applikation an „12-Factor“ nur einen kleinen Teil der Bedürfnisse, um für den Betrieb auf zukunftsorientierten Infrastrukturen gerüstet zu sein.
Klassische Applikationen im Container-Format sind weiterhin stark fehleranfällig, noch dazu, wenn diese Daten persistieren (stateful). Demnach müssen weiterhin klassische Szenarien, wie z.B. Backup und Restore betrachten werden. Der klassische Ansatz, z.B. ein Restore von virtuellen Maschinen (VMs), kann in einem hoch-automatisierten und dynamischen Ökosystem jedoch nur in Einzelfällen gewählt werden.
Backup-Möglichkeiten innerhalb des VMware TKGi Ökosystems
Stehen die klassischen Möglichkeiten (z.B. VM Snapshot) eines Backups gar nicht oder nur in limitiertem Umfang zur Verfügung, werden andere Lösungen benötigt. Es sollte nicht groß verwundern, dass die Sicherung der Applikation und der Daten im Gesamtökosystem eine bevorzugte Bedeutung zugeordnet bekommt. Denn sollte die zugrunde liegende Infrastruktur ausfallen oder Fehler aufweisen, möchte man sich die, durch die Containerisierung neu gewonnene Flexibilität und Portabilität, ja auch zu Nutze machen können.
Sehen wir uns die einzelnen Ebenen des „Tanzu Kubernetes Grid Integrated Edition“ Ökosystems und der Backup-Möglichkeiten einmal an:
- Kubernetes Workload (Applikation)
- Kubernetes Cluster
- Tanzu Kubernetes Grid Management Plane (Opsman, BOSH Director, TKGi)
- Virtuelle Infrastruktur (vSphere, NSX-T, vSAN)
- Physische Infrastruktur (x86 Server, Netzwerk, Storage)
Physische und virtuelle Infrastruktur sind nur der Vollständigkeit halber aufgeführt, bleiben bei dieser Betrachtung jedoch unberücksichtigt.
Kubernetes Workload
Bei Kubernetes Workload spricht man von Applikationen, welche den wesentlichen Grund für den Betrieb einer solchen innovativen Infrastruktur darstellen. Cloud-native Applikationen bringen in der Regel die für den sicheren Betrieb notwendigen Mechanismen, wie Replizierung oder der dezentralen Sicherung von Daten, mit sich. Leider sind bisher nicht alle Applikationen einem frequenziellen Lebenszyklus unterworfen worden und kleiden sich nahezu im gleichen Gewand auf der neuen innovativeren Infrastruktur.
Um weiterhin entsprechende Datensicherheit bei Ausfall gewährleisten zu können, werden diese klassischen Applikationen mit Hilfe von Velero und Restic gesichert. Hierbei werden die entsprechenden Kubernetes-Ressourcen sowie persistenten Daten gesichert und können im Falle einer notwendigen Wiederherstellung verwendet werden.
Hinweis:
Es gilt zu berücksichtigen, dass sämtliche Ressourcen auf deren Notwendigkeit und Möglichkeit der Sicherung hin untersucht werden müssen. Dies betrifft zum Beispiel die Berechtigung für den Zugriff auf Cluster-Ressourcen oder individuell erzeugte Custom Resource Definitions. Velero bietet zudem keine Mandantenfähigkeit.
Kubernetes Cluster
Innerhalb von TKGi werden Kubernetes-Cluster durch die Komponente BOSH ausgerollt. Bei BOSH handelt es sich um ein Tool zur Automatisierung von VM Deployments und deren Konfiguration (Day 1 – Deployment) sowie der Möglichkeit von Aktualisierungen, Monitoring und Self-Healing (Day 2 – Operation).
Die Sicherung des BOSH Deployments (K8s-Cluster Manifest) und die Sicherung eines essentiellen Cluster-Bestandteils, der ETCD Datenbank, übernimmt das Tool „BOSH Backup and Restore (BBR)“.
Hinweis:
Auch wenn man augenscheinlich davon ausgehen könnte, dass bei der Wiederherstellung eines Clusters, z.B. die notwendigen Netzwerkkonfigurationen mit umgesetzt werden, ist dem leider nicht so. Auch hier gilt es weitere Untersuchung vorzunehmen, um zu prüfen, ob weitere Komponenten gesichert werden müssen.
Tanzu Kubernetes Grid Integrated Edition
Die TKGi Management Plane besteht aus den Komponenten Operations Manager (Opsman), BOSH und dem eigentlichen TKGi.
Der OpsManager kann über einen Export der Konfiguration gesichert werden, während BOSH und TKGi über das bekannte „BOSH Backup and Restore (BBR)“ gesichert werden.
Komplexität
Sämtliche Backup-Lösungen und Mechanismen bedürfen je nach Ausfallszenario einer individuellen Betrachtung zum Backup sowie zur Wiederherstellung. Die enthaltenen Hinweise sind nur ein Auszug von möglichen Fallstricken.
Es gilt die komplexen Zusammenhänge zu betrachten, z.B. die automatisch angelegten Objekte und deren Referenzierung durch andere Komponenten. Sind diese Objekte z.B. versehentlich gelöscht worden, kann nicht zwangsläufig sichergestellt werden, dass diese beim Wiederherstellungsprozess neu erstellt und entsprechend neu referenziert werden.
Eben jene komplexen Zusammenhänge erschweren ein manuelles Restore-Szenario. Ist die Wiederherstellung grundsätzlich keine unlösbare Aufgabe, so lässt sich zumindest in Bezug auf den zeitlichen Aspekt sagen, dass es hierbei zu einer ungewollt langen Ausfallzeit kommen kann. Eine Verzögerung durch einen manuellen Restore kann durch eine entsprechende Automatisierung aufgefangen werden, doch die Vielfalt der möglichen Szenarien erschwert die partielle Wiederherstellungs-Automatisierung, sodass hierbei ein wesentlich simplerer Ansatz gefunden werden muss.
Auch wenn es ein wenig nach der Holzhammer-Methode klingt: Das buchstäbliche Abreißen und Neubauen des Ökosystems ist in vielen Szenarien eine gute Alternative. Die Basis für diese Wiederherstellungs-Methode ist meistens schon gelegt, zumal Infrastructure as Code und Nutzung von CI/CD Pipelines in den Unternehmen immer mehr Einzug nehmen und darauf zurückgegriffen werden kann.
Fazit
Führt man sich vor Augen, dass im Zeitalter von cloud-nativen Anwendungen im Fehlerfall nach dem „Cattle-Prinzip“ verfahren wird, bei dem das Wegwerfen und Neuerstellen von defekten Bausteinen erzwungen wird, könnte dieser Ansatz ebenso Einzug in das darunterliegende Ökosystem finden. Eine pauschale Aussage lässt sich hierzu nicht treffen, denn hierbei müssen eine Menge auschlaggebender Faktoren berücksichtigt werden. Ob nun die Sicherung und Wiederherstellung einzelner Komponenten oder das komplette Abreißen und Neubauen des Ökosystems die richtige Lösung darstellt, muss genauestens untersucht werden. Daher bleibt zum Schluss nur zu sagen: „Es kommt darauf an.“
Quellen: