Disaster Recovery für Openstack
Für den Notfall gerüstet
Disaster Recovery für Openstack ist der Oberbegriff für Aktivitäten, mit denen sich Cloud-Applikationen und -Services nach einem Systemausfall wiederherstellen lassen. Die Implementierung von Disaster-Recovery-Maßnahmen erfordert APIs in den Openstack-Storage-Komponenten, mit denen Administratoren gezielt Funktionen aufrufen und steuern können.Die Anforderungen an die Unternehmens-IT ändern sich schneller als je zuvor. In immer kürzeren Abständen besteht Bedarf, vorhandene Applikation zu erweitern und die Applikationslandschaft um externe, komplexe Pakete sowie um neuartige Apps zu ergänzen. Gleichzeitig steigen damit auch die Anforderung an das Backup und die Wiederherstellung der Daten nach einem Systemausfall. Im Cloud-Zeitalter nimmt die Komplexität weiter zu, besonders in einem Hybrid-Cloud-Betriebsmodell. Wenn es um die Planung und Implementierung von Open-Hybrid-Cloud-Infrastrukturen geht, fassen immer mehr Unternehmen Openstack als Fundament einer Cloud-Integrationsstrategie ins Auge. Openstack ist ein Projekt, das gemeinsam von Entwicklern und Cloud-Computing-Anbietern gestartet wurde und das in der Zwischenzeit ein breiter Kreis von IT-Anbietern, darunter beispielsweise auch Red Hat, unterstützt und weiterentwickelt. Konsens besteht darin, dass Unternehmen mit dem Openstack-Framework unterschiedliche Arten von Cloud-Infrastrukturen aufbauen und bereitstellen können. Eine Openstack-Cloud-Infrastruktur besteht aus Rechenleistungen (Compute), Speicherkapazitäten (Storage) und Netzwerkkomponenten. Openstack unterstützt drei Storage-Modi: "File"-, "Block"- und "Object"-Storage. In aller Regel kommt File Storage für unstrukturierte Daten wie Dokumente, Präsentationen oder Spreadsheets zum Einsatz. Block Storage eignet sich für strukturierte Datenbanken und lässt sich wie eine externe Festplatte mit einer virtuellen Instanz verbinden. Einsatzgebiet von Object Storage wiederum ist das langfristige Speichern statischer Daten. Typische Anwendungsszenarien dafür sind die Archivierung und das Backup virtueller Maschinen, Images, E-Mails und Fotos. Das Hybrid-Cloud-Modell In einem Hybrid-Cloud-Modell verbleiben Teile der IT-Systemlandschaft On-Premise im eigenen Rechenzentrum und andere werden in die Cloud verlagert. Allerdings stellt diese Kombination von traditionellen und Cloud-basierenden Applikationen nur eine von mehreren Hybrid-Cloud-Varianten dar. Weitere Formen sind die Verzahnung von Private und Public Clouds sowie der gleichzeitige Einsatz von IaaS- (Infrastructure as a Service) und PaaS-Clouds (Platform as a Service). Aufgaben wie eine automatische Provisionierung und das Hybrid-Management spielen eine wichtige Rolle, wenn Unternehmen ihre On-Site-Ressourcen mit Hosted-Private- oder Public-Cloud-Ressourcen kombinieren. Das Hybrid-Management kombiniert Private und Public Cloud, IaaS- und PaaS-Clouds sowie herkömmliche und Cloud-fähige Workloads, wie dies beispielsweise Red Hat Cloudforms beherrscht. Ist die Sicherstellung von Business Continuity und Service-Verfügbarkeit in einer reinen On-Premise-Landschaft schon höchst anspruchsvoll, steigen die Anforderungen in einer Hybrid-Cloud-Umgebung erheblich an. Zur Vorbereitung auf das Worst-Case-Szenario gehören grundlegende Funktionen für die Wiederherstellung einer arbeitsfähigen IT-Infrastruktur nach einem Systemausfall. Letzterer kann durch einzelne oder auch eine Kombination aus schwerwiegenden Hardwarefehlern verursacht sein, aber auch Sturmschäden, Hochwasser oder Feuer lassen sich nie gänzlich ausschließen. Im Umfeld von Cloud Computing bedeutet Disaster Recovery eine Zusammenfassung von Aktivitäten, um im Notfall die Workloads wie Cloud-Applikationen und -Services wiederherstellen zu können. Disaster Recovery für eine Workload umfasst Infrastruktur und Software sowie deren Zusammenwirken. Zur Implementierung von Disaster-Recovery-Maßnahmen sind Schnittstellen (APIs) in den Openstack-Komponenten sowie Skripte außerhalb von Openstack erforderlich, mit denen Administratoren komponentenspezifische Funktionen aufrufen und steuern können. Das Disaster-Recovery-Ziel ist nicht die Wiederbeschaffung von Hardware, sondern die Wiederherstellung von Applikationen, Services und Daten. Disaster Recovery zwischen einem primären und einem sekundären Standort - dies können beispielsweise auch eine Primary Cloud und eine Target Cloud sein - erfordert, dass die Daten zumindest an zwei geografisch unterschiedlichen Lokationen vorhanden sind. Bei Openstack lassen sich beispielswiese folgende Replikationsziele unterscheiden: von einer On-Premise-Umgebung in eine Private Cloud, von einer Private Cloud zu einer zweiten Private Cloud, von einer Private Cloud in die Public Cloud sowie von einer Public Cloud in eine zweite Public Cloud. Als Wiederherstellungsziel geht es in diesem Zusammenhang um eine Workload beziehungsweise um bestimmte Cloud-Applikationen und Cloud-Services. Für ein Unternehmen sehr wichtige Applikationsdaten müssen mit einem kürzestmöglichen Recovery Time Objective (RTO: Zeit vom Moment des Ausfalls bis zur Wiederherstellung) und einem ebenfalls kleinstmöglichen Recovery Point Objective (RPO: Datenmenge, die zwischen der letzten Sicherung und dem Systemausfall höchstens verloren gehen darf) wieder zur Verfügung stehen. Dazu kann ein Hot-Backup-Modus oder zumindest die synchrone Replikation erforderlich sein. Bei einer periodischen Replikation akzeptiert der Anwender, dass mehr Daten verloren gehen können als bei einer synchronen oder asynchronen Replikation. Die Aktualisierung der Kopien erfolgt zeitverzögert, was bei Daten, die einmal geschrieben und danach nicht mehr geändert werden, durchaus akzeptabel sein kann. Die synchrone Replikation ermöglicht letztlich das Erzeugen einer 100-prozentig identischen Zweitkopie der Daten als Basis für Business Continuity. Sie kommt üblicherweise innerhalb eines Rechenzentrums, zwischen Brandabschnitten oder zwischen getrennten, aber relativ nahen Gebäuden zum Einsatz, um die Latenzzeiten für Applikation möglichst gering zu halten. Die asynchrone Replikation (Geo-Replication) wiederum findet üblicherweise über weitere Strecken statt und hat keinen Einfluss auf Latenzzeiten, garantiert jedoch nicht immer 100-prozentige Datenkonsistenz. Ziel ist es, über eine Online-Kopie der Produktionsdaten zu verfügen, die sich für eine schnelle Notfallwiederherstellung kurzfristig nutzen lässt. Storage für Openstack Openstack unterstützt eine Reihe von Storage Backends, darunter Ceph (Block Storage), Cinder (Block Storage), Glance (Image Service), Glusterfs (File und Object Storage) sowie Netapp (File und Block Storage). Beim Object Storage geht es um das Backup und beim Systemausfall um die Wiederherstellung von unstrukturierten Daten. Software wie Glusterfs und Ceph sorgt dafür, dass Daten verteilt geschrieben werden und so ein stabiles Fundament für die Datenintegrität und Replikation entsteht. Im Vergleich zu Ceph ist Glusterfs eher modular und einfacher aufgebaut, Architektur und Arbeitsweise sind weniger komplex. Während bei Ceph das Disaster Recovery von der Komplexität der Regeln für die Ausfallsicherheit abhängt, bietet Glusterfs eine einfachere Lösung. Sind Server-Nodes nicht mehr verfügbar, greift der Administrator auf die Daten im Backend File zurück. Sowohl mit Glusterfs als auch mit Ceph können Unternehmen eine Open Hybrid Cloud aufbauen, betreiben und verwalten.
Lesen Sie mehr zum Thema
