Infrastructure as Code
Die Zukunft des Backups
Fortsetzung des Artikels von Teil 1
Das wilde Pferd zähmen
Die meisten Workloads von heute sind sehr dynamisch, verteilt, groß, virtualisiert und werden traditionelle Backups schnell an ihre Grenzen bringen. Wer diese wilden Pferde zähmen will, sollte Hersteller auf seine Shortlist setzen, die zuerst einmal in der Lage sind, die vielen Workloads überhaupt zu sichern. Dies lässt sich anhand einfacher Checks schnell prüfen.
Werden neben den klassischen Legacy-Plattformen und den virtuellen Stacks bereits moderne Workloads wie Mongo DB, Sap HANA, Hadoop oder Open Stack abgedeckt? Wie schnell ist der Backup-Hersteller darin, neue Workloads zu unterstützen? Arbeitet der Anbieter mit den Cloud-Providern zusammen und liefert zertifizierte Module, um mit ihnen und deren Cloud-Snapshots und Data Movern zu interagieren? Welche Historie hat er auf diesem Gebiet? Welche Strategie verfolgt er? Es ist recht simpel: Das schönste Backup-Konzept versagt, wenn es manche Plattformen schlicht nicht unterstützt.
Das Backup-Konzept eines Herstellers muss skalieren, und zwar horizontal wie vertikal. Die Datenmengen werden weiter massiv wachsen und sich geographisch noch stärker auf verschiedenste Infrastrukturen verteilen. Der Hersteller muss in der Lage sein, an Orten, an denen sich große Datenmengen konzentrieren, leicht skalierbare und hochperformante Backup-Systeme zu liefern, die diese Mengen in den knappen Zeitfenstern wegschreiben können. Und sie müssen leicht in die Fläche skalieren, um den verteilten mehrstufigen Applikationen und ihren Daten folgen zu können. Denn schließlich haben Entfernung und Datenmenge massive Auswirkungen auf die Backup-Leistung.
Außerdem sollte das Backup-Konzept in der Lage sein, die Verantwortung für die Daten und Workloads und ihre Wiederherstellung auf mehrere Schultern zu verteilen. So wollen Mitglieder der DevOPs-Teams sicher ihre eigenen virtuellen Ressourcen kontrollieren und auf frühere Versionen zurückschalten, ohne auf die Backup-Teams angewiesen zu sein. Der Prozess sollte für die DevOps-Teams in wenigen Klicks und ohne Backup-Schulung abzuwickeln sein. Sie sollen sich auf ihre Kernaufgabe konzentrieren und keine Zeit mit Nebenaufgaben vergeuden.
Die Evolution des Backups hin zum Code
All diese wichtigen Voraussetzungen sind essenziell, um in der heutigen Umgebung zu bestehen. Mittelfristig wird sich das Backup aber weiterentwickeln müssen, um tatsächlich software defined als Prozess in der Entwicklung gleich mitdefiniert zu werden.
Was ist aber nötig, damit eine Backup-Landschaft diese Reife erlangt? Sie muss – ähnlich wie bei der Virtualisierung – die physische Welt im Idealfall völlig ausklammern und vor dem Anwender verbergen können.
Dazu sind Automatismen sowohl bei der Erstimplementierung wie im Betrieb unabdingbar. Für diese Aufgabe bedarf es ausgesprochen komplexer Algorithmen, die die Backup-Soft- und Hardware mithilfe von Machine Learning und Artifical Intelligence durch die Erstkonfiguration leiten, sobald die Parameter aus der Infrastructure as Code zu ihnen durchgereicht werden.
Die Backup-Systeme müssen sich auf dieser Grundlage autonom konfigurieren und dabei selbst entscheiden, wieviel Storage- und CPU-Ressourcen sie an welchem genauen Ort in der Umgebung brauchen. Sie müssen dann beispielsweise selbst entscheiden, dass ein Umschalten auf den Backup-Server in Hamburg für diese Systeme nicht sinnvoll ist, weil die Latenzzeit dann zu hoch wird.
Die Backup-Systeme im Verbund müssen miteinander sprechen, um sich über ihren aktuellen Zustand zu informieren, und gleichzeitig mit künstlicher Intelligenz Trends analysieren, um künftige Aufgaben, Lastspitzen und Engpässe zu identifizieren und entsprechend darauf zu reagieren. Dank der künstlichen Intelligenz entsteht aus der physischen Backup-Infrastruktur ein kluger und dynamischer Verbund, der wie bei einem guten Team Stärken und Schwächen eines jeden Mitglieds berücksichtigt und sich Aufgaben dynamisch und agil gegenseitig zuspielen kann. All das muss möglichst autonom passieren, ohne dass menschliche Interaktionen nötig sind.
Sollte der Erstfall dennoch eintreten und ein Eingriff durch einen IT-Spezialisten nötig sein, so muss dieser sämtliche Systeme über eine einzelne Konsole verwalten können. Idealerweise ist deren Dashboard so einfach gestaltet, dass über ein einfaches Ampelsystem - rot, gelb und grün - der Mitarbeiter den nötigen Überblick bekommt und mit nur einem Mausklick das System wieder in einen betriebsbereiten Zustand bringen kann. Zudem sollten klare Handlungsanweisungen erfolgen, welche Komponente auszutauschen ist. So werden in einem derartigen Szenario deutlich weniger hochspezialisierte Experten benötigt, die dann nur noch sehr anspruchsvolle Probleme lösen müssen.
Diese Abstraktion des Komplexen hin zu einem einfach administrierbaren, selbstheilenden System leitet die wichtigen nächsten Schritte ein, um das Backup und die Wiederherstellung von Daten als Prozess im Infrastracture as Code definieren zu können. Die physische Welt wird sozusagen ausgeklammert. Veritas als Marktführer auf dem Gebiet Backup arbeitet genau an solchen Automatismen, damit die Kunden ihre Daten in modernen DevOps und Infrastructrure as Code zuverlässig wiederherstellen können.
Mathias Wenig ist Senior Manager Technology Sales und Digital Transformation Specialists, DACH bei Veritas Technologies
- Die Zukunft des Backups
- Das wilde Pferd zähmen
Lesen Sie mehr zum Thema
