Die besten 9 OpenShift ETCD Lösungen zur Sicherung und Wiederherstellung

RedHat OpenShift ermöglicht es Anwendern, ein modulares Paket aus einer Computing-Plattform und einer Reihe von Anwendungen bereitzustellen, zu instanziieren, auszuführen und zu verwalten. Dadurch wird die Komplexität des Aufbaus und der Pflege der Infrastruktur, die wahrscheinlich mit der Entwicklung und dem Start der benötigten Anwendungen und Dienste verbunden wäre, erheblich reduziert.

OpenShift stellt einen besonderen Ansatz dar, wie virtuelle Maschinen, Container und Platform-as-a-Service-Umgebungen zusammenarbeiten können. Die Plattform als Ganzes ist oft sowohl für Unternehmen als auch für Einzelpersonen nützlich, die in der Lage sind, sie zu nutzen.

Da OpenShift aus einer Familie von Software besteht, ist es wichtig, das Flaggschiff zu erwähnen – die OpenShift Container Platform.

OpenShift Container Platform, oder OSCP, ist eine hybride Cloud-Plattform als Service, die mit Linux-Containern arbeitet, die von Kubernetes verwaltet werden. Meistens wird sie als „OpenShift“ bezeichnet, obwohl es innerhalb der gleichen Familie mehrere andere Produkte gibt – darunter OpenShift Online, OpenShift Dedicated und andere. Der Kontinuität halber werden wir die OpenShift Container Platform im weiteren Verlauf dieses Artikels einfach als „OpenShift“ bezeichnen, da die meisten der folgenden Dienste und Lösungen mit OSCP arbeiten.

OpenShift ist so konzipiert, dass es modular und flexibel ist, was eine Reihe von Vorteilen für die verschiedenen Bereitstellungen bringt, die OpenShift nutzen. Dieser flexible und vielseitige Ansatz hat jedoch auch seine Tücken. Das erste Problem ist, dass dieser Ansatz zwar sehr effektiv sein kann, aber auch anfällig für Fehler und Ausfälle ist. Daher ist ein gutes Sicherungssystem eine Voraussetzung für die meisten, wenn nicht sogar alle OpenShift-Implementierungen, insbesondere wenn wertvolle, dauerhafte Daten erstellt und/oder verarbeitet werden.

Die Notwendigkeit eines Sicherungssystems stellt ein weiteres großes Problem für OpenShift-Implementierungen dar – nicht alle Sicherungslösungen sind in der Lage, OpenShift-Umgebungen angemessen zu schützen – und einige sind schlichtweg nicht in der Lage, dies überhaupt zu tun.

Daher sollte eine Sicherungs- und Wiederherstellungslösung von vornherein vollständig mit OpenShift kompatibel sein. Typischerweise sind Backup-Funktionen wie Backup-Automatisierung, Unterstützung für verschiedene Backup-Standorte und -Medien sowie Datenmigrationsfunktionen eine wichtige Ergänzung zu den bestehenden OpenShift-Backup- und Recovery-Funktionen.

Eingebaute OpenShift-Funktionen zur Sicherung

Es gibt nicht so viele umfassende Backup-Lösungen auf dem Markt, die auch in der Lage sind, OpenShift-Sicherungen und -Wiederherstellungen durchzuführen – aber zunächst müssen wir uns ansehen, wie viel RedHat selbst kann. Auf diese eingebaute Sicherungsfunktionalität werden wir zunächst näher eingehen.

OpenShift-Cluster-Sicherung und -Wiederherstellung

Hier gibt es zwei mögliche Wege – Sicherungs- und Wiederherstellungsvorgänge für Cluster und dieselben Vorgänge für Anwendungen. Die Sicherung von Clustern basiert vollständig auf etcd-Daten – einem Key-Value-Store von OSCP (OpenShift Container Platform), der Informationen über alle Ressourcenobjekte innerhalb eines Clusters enthält.

Ein Cluster-Administrator muss Cluster in bestimmten Situationen herunterfahren oder neu starten, sei es zu Wartungszwecken oder einfach, um Ressourcen zu sparen, indem er weniger Cluster auf einmal betreibt. Der Prozess des Herunterfahrens eines OpenShift-Clusters wird manchmal als „Graceful Shutdown“ bezeichnet und umfasst das Herunterfahren der Knoten des Clusters mit einem speziellen Shutdown-Befehl sowie das Herunterfahren aller Abhängigkeiten, die nicht mehr verwendet werden, wenn der Cluster abgeschaltet wird.

Es gibt noch einen weiteren Prozess, den „sanften Neustart“, der natürlich das direkte Gegenteil eines sanften Herunterfahrens ist, da er den Cluster startet, anstatt ihn zu stoppen. Dieser spezielle Prozess kann jedoch etwas komplizierter sein als sein Gegenteil und umfasst Schritte wie:

• Einschalten aller zuvor deaktivierten Cluster-Abhängigkeiten;
• Starten der Cluster-Maschine selbst;
• Überprüfen, ob die Knoten der Steuerungsebene bereit sind;
• Prüfen, ob die Worker-Knoten bereit sind;
• Prüfen, ob der Cluster als Ganzes ordnungsgemäß gestartet wurde oder nicht.

Wenn der Cluster nicht ordnungsgemäß gestartet wurde, besteht die einzige Lösung darin, eine etcd-Sicherung zu verwenden, um den vorherigen Zustand des Clusters wiederherzustellen.

Es stimmt zwar, dass das „Graceful Shutdown“ einen Neustart des Clusters mit minimalem Aufwand ermöglichen sollte, doch sollte vor jedem Herunterfahren des Clusters eine etcd-Sicherung durchgeführt werden. Etcd-Backups spielen eine wichtige Rolle bei Disaster Recovery-Szenarien, und es wäre nicht möglich, ein fehlerhaftes OSCP wiederherzustellen, ohne dass eine etcd-Sicherung in den Prozess eingebunden ist.

Der etcd-Backup-Prozess selbst ist recht einfach und umfasst drei Hauptschritte – das Starten einer Debug-Sitzung, das Ändern Ihres Root-Verzeichnisses in /host, und das Starten eines Skripts namens „cluster-backup.sh„, wobei auch der Speicherort der Sicherung eingegeben wird.

Der Prozess der Cluster-Wiederherstellung ist dagegen etwas komplizierter, vor allem weil die Cluster-Wiederherstellung über eine etcd-Sicherung als „letzter Ausweg“ betrachtet wird, der normalerweise nur verwendet werden sollte, wenn nichts anderes zur Wiederherstellung des Arbeitszustands des Clusters funktioniert. Sie umfasst mehrere Schritte, wie zum Beispiel:

• Auswahl eines Steuerebenen-Hosts, der die Wiederherstellungsoperationen durchführen soll;
• Einrichten einer SSH-Verbindung mit allen Knoten der Steuerungsebene, einschließlich desjenigen, der für die Wiederherstellung verwendet wird;
• Manuelles Kopieren der etcd-Sicherung auf den einen Host, der als Wiederherstellungshost ausgewählt wurde;
• Zugriff auf den fraglichen Rechner;
• Ausführen des Wiederherstellungsskripts „cluster-restore.sh„;
• Prüfen, ob sich die Knoten im Zustand „bereit“ befinden;
• Neustart des kubelet Dienstes für alle Hosts der Steuerungsebene, einschließlich des Wiederherstellungshosts;
• Zustimmung ausstehender CSRs, Überprüfung, ob die Single-Member-Kontrollebene betriebsbereit ist;
• Löschen und Neuanlegen aller Computer der Steuerungsebene, mit Ausnahme des für die Wiederherstellung ausgewählten Computers.

Damit kommen wir zum zweiten Teil dieses langen Prozesses. Er beginnt damit, dass sich derselbe Benutzer in einem separaten Terminalfenster mit der Rolle „cluster-admin“ anmeldet. Die folgenden Vorgänge sind:

• Erzwingen der Neuverteilung von etcd;
• Überprüfen, ob die Knoten auf dem neuesten Stand sind;
• Erzwingen neuer Rollouts auf der Steuerungsebene (dies sollte Kubernetes API auf allen Knoten neu installieren, da ein interner Load Balancer verwendet wird, um das Kubelet mit dem API-Server zu verbinden);
• Und zu guter Letzt wird überprüft, ob alle neu installierten Control Plane Hosts funktionieren und dem Cluster beigetreten sind.

Wie Sie unschwer erkennen können, ist der Wiederherstellungsprozess für die etcd-Sicherung ziemlich langwierig und schwierig, was einer der Gründe dafür ist, dass sie als letzte Möglichkeit behandelt wird.

Nachdem wir nun erklärt haben, wie die Sicherung und Wiederherstellung von Containern funktioniert, lassen Sie uns nun einen Blick auf die Sicherung und Wiederherstellung von Anwendungen werfen.

OpenShift Anwendungssicherung und -wiederherstellung

Die Erstellung von Anwendungssicherungen in OpenShift kann ebenfalls recht kompliziert sein, aber wir werden nicht besonders tief darauf eingehen, da die Schwerpunkte dieses Artikels auf etcd und Clustern liegen. Dennoch werden wir die Logik des Ganzen untersuchen.

Sicherungen und Wiederherstellungen von Anwendungen in OpenShift können mit Hilfe von OADP, der OpenShift API for Data Protection, durchgeführt werden. Sie verwendet Velero, um Sicherungs- und Wiederherstellungsaufgaben für Ressourcen und/oder interne Images durchzuführen, und ist außerdem in der Lage, mit persistenten Volumes über Restic oder mit Snapshots zu arbeiten.

Es gibt eine sehr spezifische Liste von Speichervarianten, die mit OADP gesichert werden können – diese Liste umfasst MS Azure, AWS, GCP, Multicloud Object Gateway sowie mehrere S3-kompatible Objektspeichervarianten (Minio, Noobaa usw.). Gleichzeitig können Snapshot-Sicherungen nur für AWS, Azure, GCP und CSI Snapshot-fähige Cloud-Speicher (Ceph FS, Ceph RBD usw.) durchgeführt werden, da nur diese die erforderliche Snapshot-API auf nativer Ebene unterstützen.

Der Sicherungsprozess selbst umfasst die Erstellung einer CR oder einer benutzerdefinierten Ressource für Sicherungs- oder Wiederherstellungszwecke. Mit dieser Option können Sie Restic-Backups und geplante Backups durchführen sowie Backup/Restore-Hooks einrichten, die entweder vor oder nach Abschluss des Backup/Restore-Prozesses ausgeführt werden.

OpenShift-Sicherungsoptionen von Drittanbietern

Die zuvor erwähnte Methode zur Sicherung/Wiederherstellung ist zwar möglich, birgt aber auch potenzielle Probleme, vor allem weil zusätzliche Funktionen fehlen und sie für viele Benutzer etwas kompliziert sein kann. Aus diesem Grund werden wir uns auch die Sicherungslösungen für OpenShift ETCD von Drittanbietern ansehen und mit IBM Spectrum beginnen.

IBM Spectrum Protect Plus

IBM Spectrum Protect Plus ist eine umfassende Datensicherungslösung, die eine Vielzahl von Funktionen im Bereich der Datensicherheit bietet – einschließlich Sicherung, Wiederherstellung, Aufbewahrung und Replikation für alle Arten von Zielorten, seien es Datenbanken, Anwendungen, virtuelle Maschinen, SaaS-Workloads oder sogar Container.

IBM Spectrum Protect ist eine ziemlich vielseitige Lösung, weshalb sie auch mit OpenShift-Systemen arbeiten kann. Die Lösung von IBM ist in der Lage, nicht nur persistente Volumes, sondern auch andere OpenShift-Cluster-abhängige Ressourcen zu schützen. Es gibt zwar eine Reihe von Anforderungen, damit OpenShift-Backups überhaupt funktionieren, aber die Anforderungen selbst sind nicht besonders streng und umfassen meist nur die Anforderung, dass die verschiedenen Teile des Virtualisierungssystems bis zu einem bestimmten Grad aktuell sein müssen.

IBM Spectrum Protect ermöglicht es seinen Nutzern, OpenShift-Cluster manuell zu registrieren, Sicherungen von OpenShift-Containerdaten zu erstellen und diese entweder aus einem Snapshot oder einer regulären Sicherungskopie wiederherzustellen. Darüber hinaus können bestimmte Namespace- und Cluster-scoped-Ressourcen wiederhergestellt oder sogar die Aufbewahrungseinstellungen für bestimmte Sicherungen oder Snapshots außer Kraft gesetzt werden, indem OpenShift-Backup-Jobsitzungen ablaufen.

CronJob

Anders als der Rest dieser Liste ist CronJob keine eigenständige Sicherungslösung. Ein CronJob ist ein Task, der in Unix-basierten Systemen bestimmte Aktionen nach einem bestimmten Zeitplan ausführen kann. In diesem speziellen Kontext verwendet ein Benutzer auf GitHub CronJob, um eine Reihe von Operationen auszuführen, die dazu führen, dass eine OpenShift-Sicherung mit der gleichen Methode erstellt wird, die wir bereits erwähnt haben (Ausführung von cluster-backup.sh).

Dieser spezielle CronJob erstellt einen Pod, der das oben erwähnte Skript ausführt, um die Sicherung selbst zu erstellen. Außerdem kopiert er die gesamte Sicherung in ein vorkonfiguriertes PV und lässt dann den Sicherungsauftrag selbst auslaufen, um zukünftige Konflikte zu vermeiden. Es werden zwei separate Dateien erstellt – eine davon ist die Sammlung der statischen Pods als Ganzes mit ihren privaten Schlüsseln und Zertifikaten, die andere ist der etcd-Snapshot. Daher kann diese „Methode“ als OpenShift ETCD-Sicherungslösung bezeichnet werden.

Kasten K10

Kasten K10 ist eine Datenverwaltungsplattform, die nativ in der Cloud als Speichertyp arbeitet und eine Vielzahl verschiedener Optionen wie Sicherung, Wiederherstellung, Anwendungsmobilität und Disaster Recovery für Kubernetes-Anwendungen bietet. Gleichzeitig ist sie in der Lage, sich in eine Vielzahl verschiedener Datenbanktypen zu integrieren, unterstützt mehrere Cloud-Speicheranbieter und kann mit den meisten Kubernetes-Distributionen arbeiten.

K10 kann auch OpenShift-Sicherungen und -Wiederherstellungen relativ einfach durchführen. Der größte Unterschied ist die Erstellung eines Secret – Kastens eigene Version einer Sicherungsliste, die Informationen über etcd-Pod-Labels, etcd-Cluster-Endpunkte und alles andere, was gesichert werden muss, enthält. Abgesehen davon ähnelt der Prozess in gewisser Weise der Art und Weise, wie K10 normalerweise Sicherungen durchführt – die Erstellung eines Blueprints und die Verwendung eines Secret mit einem Blueprint zur Ausführung der Sicherungsaufgabe. Der Wiederherstellungsprozess hingegen ähnelt dem, was wir im Abschnitt „Integrierte Methoden“ dieses Artikels besprochen haben.

Storware Sicherung und Wiederherstellung

Storware Backup and Recovery ist eine Cloud-native Datensicherungssoftware, die sehr gut funktioniert, wenn es darum geht, Sicherungen von persistenten Volumes oder Metadaten zu erstellen, die an OpenShift-Pods angehängt sind. Sie hat den Status eines zertifizierten Red Hat OpenShift Operators und bietet eine konsistente Datensicherung in Kombination mit Funktionen wie Zeitplanung, Änderung von Sicherungsrichtlinien, Sicherungsautomatisierung und so weiter. Es ist eine großartige Lösung für die Sicherung und Wiederherstellung von OpenShift ETCD, die mehrere verschiedene Ebenen der OpenShift-Daten abdeckt – das bereits erwähnte etcd, Metadaten, persistente Volumes und mehr.

Portworx Backup

Portworx ist eine Plattform für Datendienste, die sich auf die Entwicklung von Lösungen für Kubernetes-Nutzer konzentriert, um den Betrieb von Anwendungen in Containern ohne Unterbrechungen und Datenverluste zu ermöglichen. Sie bietet einen einfacheren Zugang zu Anwendungssicherungen mit Konsistenz und zahlreichen Funktionen wie Backup-Planung, RBAC, Benutzerverwaltung und mehr. Portworx bietet außerdem Disaster Recovery-Funktionen, CSI-Implementierung, clusterweite Verschlüsselung, Snapshots sowie viele weitere Funktionen für OpenShift-Cluster und -Anwendungen.

Cloudcasa

Cloudcasa ist ein belastbarer und leistungsstarker Sicherungsdienst mit großer Skalierbarkeit und einer benutzerfreundlichen Oberfläche. Er bietet eine Multi-Cloud-Datensicherung, mehrere Cyber-Resilienz-Optionen und mehrere verschiedene Sicherungsarten innerhalb Ihrer OpenShift-Umgebungen (Kubernetes-Ressourcen, etcd-Backups und CSI-Snapshots). Cloudcasa kann auch verschiedene Wiederherstellungsoperationen durchführen, sei es auf granularer oder auf Cluster-Ebene, was es zu einer recht praktischen und nützlichen Lösung für die Sicherung und Wiederherstellung von OpenShift ETCD macht.

Dell EMC PowerProtect Data Manager

Dell EMC ist ein technologisches Kraftpaket, das eine Vielzahl von Produkten und Dienstleistungen für unterschiedliche Märkte anbietet. Der PowerProtect Data Manager von Dell EMC ist eine vielseitige Datensicherungslösung, die mehrere Umgebungstypen unterstützt und mit einer Vielzahl unterschiedlicher Speicherorte arbeiten kann. Er unterstützt auch OpenShift-Umgebungen und bietet Schutz für deren Workloads und ist gleichzeitig eine zuverlässige und nützliche Lösung für die Sicherung und Wiederherstellung. Es integriert die OpenShift-Umgebungen in seine eigene zentralisierte Schnittstelle und bietet die Möglichkeit, Namespaces, Clustern und allem anderen, was OpenShift hat, Schutzrichtlinien zuzuweisen.

Bacula Enterprise

Bacula Enterprise ist eine einzigartige, hochsichere Lösung für die Sicherung von Unternehmen, die über ihr „Modulsystem“ eine besonders breite Palette von Umgebungen und Funktionen unterstützt. Eines dieser Module wurde speziell für umfassende OpenShift-Sicherungs- und Wiederherstellungsvorgänge entwickelt und bietet eine Vielzahl von Datenschutzfunktionen für OpenShift-Umgebungen. Dieses spezielle Modul bietet Funktionen wie die Sicherung des Cluster-Status, die effektive Neuverteilung von Cluster-Ressourcen, die Wiederherstellung von Anwendungen, die gezielte Wiederherstellung von PV-Daten, die Übertragung von Konfigurationen für andere Operationen und so weiter. Bacula Enterprise kann nicht nur bei der Sicherung Ihrer OpenShift-Daten als Ganzes hilfreich sein, sondern auch Disaster Recovery-Pläne erleichtern, zusätzliche Sicherheit für Ihre Daten bieten, bei Cluster-Migrationsaufgaben helfen, Umgebungsreplikationsfunktionen bieten und vieles mehr. Es ist erwähnenswert, dass sein abonnementbasiertes Lizenzierungsmodell und seine hohe Skalierbarkeit es für mittelgroße und große Implementierungen vorteilhaft machen.

Abschluss

OpenShift-Umgebungen sind in bestimmten Bereichen und Anwendungsgebieten äußerst nützlich, aber es ist auch relativ neu, was bedeutet, dass die Sicherung von Daten darin etwas problematisch sein kann. Da Kubernetes-Umgebungen jeglicher Art immer häufiger eingesetzt werden, wird die Sicherung ihrer Daten – insbesondere ihrer persistenten Daten – immer wichtiger. In diesem Artikel werden verschiedene Lösungen zur Sicherung von OpenShift besprochen, darunter sowohl integrierte als auch Drittanbieter-Optionen, die zur Verfügung stehen, und die hilfreich sein können, um eine Lösung für einen bestimmten Anwendungsfall des Benutzers zu finden.