Monitoring, Backup und Recovery in virtualisierten Umgebungen (3)
Beim Betrieb einer Virtualisierungsinfrastruktur müssen IT-Verantwortliche auch dafür sorgen, dass die Umgebung verfügbar ist und im Fehlerfall schnell und ohne Datenverluste wieder anläuft. Hier kommen Monitoring, Backup, Ausfallsicherheit und Desaster-Recovery-Strategien ins Spiel. In der dritten und letzten Folge des Workshops erklären wir, wie Sie mit einem Backupplan für stufenweisen Schutz der Daten sorgen, warum Replikation nicht gleich Backup ist und wie Sie ein effizientes Desaster-Recovery vorbereiten.
Zu einer der grundlegendsten Aufgaben, die leider immer noch häufig ignoriert wird, gehört das Backup von wichtigen Systemen. Hier gibt es mittlerweile einige sehr gute Produkte für das Backup einer virtuellen Infrastruktur, die auch die Wiederherstellung von Daten und Systemen sehr einfach machen.
Egal ob Sie vor einem Upgrade Ihrer Infrastruktur, einem Wechsel auf einen neuen Hypervisor oder bei einer generellen Betrachtung der Umgebung stehen, häufig finden sich in der vorhandenen Backupinfrastruktur Ansätze zum Anpassen, Verbessern oder gar einer kompletten Überarbeitung. Es ist nach wie vor keine Seltenheit, dass virtuelle Server nachts heruntergefahren und mittels Skripten wegkopiert werden. Dies führt nicht nur zu einer Downtime der Systeme, sondern auch dazu, dass keine ordentliche Versionierung stattfindet und die Admins bei einer Wiederherstellung eventuell stundenlang suchen müssen, bis sie die benötigten Daten wiederherstellen können.
Die Nutzung eines professionellen Backuptools führt dazu, dass Sie Ihre VMs während des Betriebs sichern können, bei Bedarf auch mehrmals am Tag. Nachdem ein vollständiges Backup der VM erzeugt wurde, werden danach nur noch die Änderungen gegenüber dem letzten Backupjob geschrieben. Dies verkürzt die Dauer des Backups enorm und reduziert die Belastung von VM und Hypervisor spürbar.
Stufenweiser Schutz der Daten
Unabhängig von der Software, die Sie einsetzen, sollten Sie immer mehrere Grundregeln bei einem Backup einhalten. Sie sollten grundsätzlich mehr als eine Kopie der Daten besitzen. Wenn Sie Ihre VMs täglich sichern, die Daten auf einem Backupserver mit viel Speicherkapazität ablegen und dieser Server ausfällt, haben Sie zu diesem Zeitpunkt keine Backupdaten mehr und können auch keine neuen Backups erzeugen, bis der Server wieder zur Verfügung steht. Fahren Sie mindestens ein weiteres Backup, haben Sie auch beim Ausfall des Backup-Storage den Vorteil, dass Sie noch auf das sekundäre System zugreifen können. Je nach Größe und Wichtigkeit der Daten ergibt es Sinn, sogar drei oder vier Kopien vorzuhalten.
Speichern Sie Ihre Daten auf mindestens zwei unterschiedlichen Gerätetypen. Das heißt, Sie sollten bewusst einen Medienbruch einführen. Als primären Backupspeicher empfiehlt sich fast immer ein Backup-to-Disk-System mit Festplatten (und gegebenenfalls SSDs als Cache), um die Daten möglichst schnell wegschreiben zu können. Danach sollten die Daten auf ein weiteres Medium abgelegt werden, zum Beispiel ein LTO-Tape oder eine Dedup-Appliance. Diese schreiben Daten häufig in einem anderen Format beziehungsweise in einer anderen Technik. So haben Bänder, virtuelle Tape-Libraries oder Dedup-Systeme mit einem Schreibschutz den Vorteil, dass bei einer Ransomware-Attacke und der ungewollten Verschlüsselung von Daten die Backupdaten nicht überschrieben und verschlüsselt werden können. Besitzen Sie zwei Backupserver, die jeweils eine Kopie der Daten halten, und beide Systeme sind dauerhaft eingeschaltet, würden im schlimmsten Fall beide Backupstände zerstört. Bei der Auslagerung der Daten auf eine Technik oder ein Medium, das nicht dauerhaft online ist, kann dies nicht passieren.
Sie sollten weiterhin mindestens eine Kopie der Backupdaten aus dem Raum oder noch besser aus dem Gebäude schaffen. Kommt es zu einem Brand oder einem massiven Wasserschaden, haben Sie immer noch eine Kopie der Daten an einem zweiten Standort. Dies können Monats- oder Wochensicherungen auf Band in einem Bankschließfach sein oder auch der Transfer der Backupdaten per VPN/Internet an einen anderen Standort oder in ein Rechenzentrum. Je nach Bandbreite und Art der Anbindung wäre auch die Auslagerung der Daten zu einem Anbieter wie Microsoft Azure oder Amazon AWS möglich, wenn dies für Sie in Frage kommt. Die Daten sollten bei einem solchen Vorgang natürlich verschlüsselt sein, bevor sie hochgeladen werden. Beachten Sie aber bitte immer, dass solch ein Backup immer zusätzlich erfolgt. Niemand kann Ihnen zu 100 Prozent garantieren, dass die Daten bei dem Anbieter zuverlässig und dauerhaft gespeichert werden. Haben Sie einen Verlust von Daten und müssen auf das Backup in der Cloud zugreifen und merken dann, dass sich das Archiv nicht öffnen lässt, ist das genauso, wie kein Backup zu besitzen.
Verifizierung der Backupdaten
Ein Backup zu besitzen heißt leider nicht zwangsläufig, dass sich dieses Backup auch wiederherstellen lässt. Um die erzeugten Sicherungen zu testen, bieten einige Hersteller die Möglichkeit, das Backup automatisiert und zeitgesteuert in einer Sandbox wiederherzustellen. So lässt sich verifizieren, ob ein Backup auch wirklich funktioniert und im Problemfall nutzbar ist.
Für diese Funktion benötigen Sie neben einer unterstützten Software auch einen Backupspeicher, der die erhöhte IO-Belastung während dieses Tests abfängt. Dies sollten Sie bei der Anschaffung und der Auswahl des Speichers beachten. Nicht möglich ist solch ein Test zum Beispiel von einem Bandlaufwerk.
Replikation ist kein Backup
Viele Hypervisor- und auch diverse Backupprodukte unterstützen die Replikation einer virtuellen Maschine vom primären Hypervisor, auf dem das System produktiv läuft, zu einem zweiten Hypervisor. Das zweite System kann entweder im gleichen Raum, im gleichen Gebäude in einem zweiten Raum oder auch viel weiter entfernt stehen, zum Beispiel in einem Rechenzentrum. Nach einer initialen Übertragung aller Daten werden die Änderungen am Live-System kontinuierlich zum zweiten System transferiert und dort eingepflegt. Dies passiert entweder in sehr kurzen Intervallen (etwa alle 30 Sekunden, alle fünf Minuten oder alle 15 Minuten wie bei Hyper-V) oder nur ein oder zwei Mal am Tag. Mit Hilfe dieser Technik haben Sie ein annährend identisches System auf einem zweiten Hypervisor laufen, häufig ohne Bedarf an massiver Bandbreite zwischen den beiden Systemen.
Gegen eine Replikation ist grundsätzlich nichts einzuwenden, Sie sollten sich aber immer über eine Sache im Klaren sein: Ein Replikat ist kein Backup! Da Änderungen am Live-System immer auf das sekundäre übertragen werden, unterliegen auch ungewollte Änderungen wie das Löschen von Dateien oder eine ungewollte Verschlüsselung der Daten durch Ransomware diesem Vorgang. Trotzdem kann es sinnvoll sein, diese Technik einzusetzen, zum Beispiel für ein Backup der VMs auf dem zweiten Hypervisor-Host. Dies führt zu einer Entlastung des primären Systems, trotzdem haben Sie eine Sicherung (und Archivierung) der Daten.
Steht zum Beispiel der Umzug auf neue Hardware an, die an einem anderen Standort betrieben wird, lassen sich, um die Downtime möglichst klein zu halten, im Vorfeld alle VMs auf den neuen Hypervisor replizieren. Dieser Vorgang kann einige Zeit in Anspruch nehmen, stellt aber kein Problem dar, da sich mit dem Live-System weiter arbeiten lässt. Zum Zeitpunkt des Umzugs werden die Server am Standort A heruntergefahren (dadurch sind die Daten konsistent und werden nicht mehr geändert), danach ein weiterer Replikationsvorgang initiiert, bevor dann die VMs an Standort B wieder starten.
Desaster-Recovery vorbereiten
Bei Desaster-Recovery-Plänen spielen zahlreiche Faktoren eine Rolle, die wir bereits in diesem Artikel besprochen haben:
Nutzen Sie ein bewährtes und den Anforderungen Ihrer Infrastruktur entsprechendes Backupprogramm.
Kaufen Sie Backupspeicher mit ausreichend Performance und Durchsatz.
Testen Sie regelmäßig Ihre Backups.
Simulieren Sie regelmäßig eine Wiederherstellung.
Beherzigen Sie diese Empfehlungen, haben Sie einige Vorteile während eines Recovery-Vorgangs. Durch eine Backupsoftware, die sich auf eine Sicherung einer virtuellen Infrastruktur spezialisiert hat, haben Sie hier ganz anderen Möglichkeiten und Zeitfenster als etwa bei einem Backup mit Windows-Bordmitteln oder bei einer Sicherung mittels Skript. Sie können mit einer guten Software einen Teil Ihrer VMs bereits aus dem Backupspeicher heraus starten, ohne dass die Daten auf den Hypervisor oder den Storage zurück kopiert werden müssen. Dies ermöglicht Ihnen eine Wiederherstellung von unternehmenskritischen Systemen innerhalb von wenigen Minuten. Die Daten dieser VMs werden dann im Hintergrund wieder an den ursprünglichen Speicherort verschoben, ohne dass Mitarbeiter etwas davon mitbekommen. Ausgenommen vielleicht eine geringere Performance als im Regelbetrieb, aber schließlich kümmern Sie sich aktuell um einen massiven Ausfall, nicht um den Regelbetrieb.
Je besser Ihr Backupspeicher und die Anbindung an das Netzwerk, desto schneller können Sie die Daten wiederherstellen. Genau in solch einem Moment lohnt sich die Investition in Backupspeicher mit mehr als 1 GBit/s, auch wenn diese Bandbreite fast nie benötigt wird – außer in dieser kritischen Situation! Haben Sie Ihre Backups regelmäßig validiert und getestet, können Sie sicher sein, dass die Wiederherstellung selbst bei Daten, die vielleicht auf zehn oder mehr inkrementellen Backup-Dateiketten aufgeteilt sind, funktioniert.
Neben den technischen Voraussetzungen und Abhängigkeiten sollten Sie vor allem mit dem Prozess und der Wiederherstellung vertraut sein. Je besser Sie den Prozess kennen und je öfter Sie ihn durchgeführt haben, desto weniger Bauchschmerzen haben Sie im Ernstfall. Fällt ein Teil oder Ihre gesamte IT aus und Sie müssen sich mehr oder weniger das erste Mal mit einem Recovery-Prozess auseinandersetzen, kann dies entweder zu einer enormen Verzögerung führen oder Sie machen die Sache im schlimmsten Fall noch hoffnungsloser als sie eh schon ist, wenn Sie ungewollt Backupdateien löschen oder überschreiben lassen.
Ein Ausfall von wichtigen IT-Systemen ist immer mit Stress verbunden. Diese zusätzliche Belastung führt dazu, dass eher Fehler gemacht werden als wenn Sie in aller Ruhe eine Aufgabe erledigen. Im schlimmsten Fall steht jemand während der Wiederherstellung dauerhaft hinter Ihnen und beobachtet den Fortschritt. Dass dies nicht förderlich ist und die Sache nicht beschleunigt, ist eigentlich logisch, passiert aber leider trotzdem immer wieder. Wenn Sie in solchen Situationen Ihr Programm kennen und genau wissen, welche Schritte notwendig sind, ist das Gold wert. Es lässt sich gar nicht genug betonen, wie wichtig dieser Punkt ist.
Neben einer guten Dokumentation Ihrer Infrastruktur sollten Sie ein Notfallhandbuch erstellen, das alle wichtigen Schritte aufführt und ausführlich beschreibt. In einer IT-Abteilung gibt es immer Leute, die sich besser mit dem Backup und einer möglichen Wiederherstellung auskennen, als andere. Das ist normal und meist auch nicht anders realisierbar. Daher sollten die Personen, die sattelfest beim Thema Backup und Recovery sind, ihr Wissen und die Vorgehensweise in einer speziellen Form der Dokumentation festhalten. Sie sollten hier sogar darüber nachdenken, dieses Handbuch auszudrucken und redundant vorzuhalten. Das mag vielleicht ein bisschen altmodisch klingen, aber wenn die gesamte IT-Infrastruktur steht und das Notfallhandbuch in einem Wiki gespeichert ist, was ebenfalls nicht mehr zur Verfügung steht, hilft dies niemandem. Denken Sie auch daran, das Handbuch bei einer Änderung in der Infrastruktur zu aktualisieren.
Der Betrieb einer Monitoringlösung auf einer eigenen Hardware außerhalb Ihrer Hypervisor-Infrastruktur sorgt zusätzlich dafür, dass Sie beim Ausfall des Failover-Clusters oder der HA-Umgebung immer noch sehen können, welche Systeme weg und welche noch verfügbar sind. Weiterhin entdecken Sie vielleicht auch noch, was kurz vor dem Ausfall passiert ist. Erscheinen die ersten Fehler durch den Ausfall des Storage-Systems und tauchen erst kurze Zeit später Fehler der Hypervisoren auf, ist es nicht sinnvoll auf den Hypervisor-Hosts nach Fehlern zu suchen. Haben Sie diese Informationen nicht, weil sich beim Ausfall auch das Monitoring verabschiedet hat, wird eine Fehlersuche vermutlich länger dauern als mit konkreten Informationen und Hinweisen vom Monitoring.
Fazit
Ein gutes Monitoring ermöglicht es Ihnen im Idealfall im Vorfeld, ein Problem erst gar nicht auftreten zu lassen. Hierzu sollten Sie die gesamte Infrastruktur betrachten und eine Lösung wählen, die Ihnen die benötigten Daten liefert und die Anforderungen erfüllt. Reagieren Sie zeitnah bei Meldungen, vor allem bei möglichen Performance-Engpässen. Mit einem guten Backupprogramm sowie einer guten Dokumentation können Sie selbst große Ausfälle in kurzer Zeit zielgerichtet kompensieren und die Umgebung wieder in Betrieb nehmen. Dabei hilft Ihnen nicht nur ein fundiertes Wissen über die genutzten Programme und Arbeitsweisen, sondern auch eine gute Dokumentation und ein Notfallhandbuch, in dem die Schritte und Abhängigkeiten dokumentiert sind.
Autor: Jan Kappen