Disaster Recovery in der Cloud

Cloud-Snapshots... Magie oder nur ein weiteres Werkzeug?

Edward Aiello
Edward Aiello
24. August 2021 4 min Lesezeit

Ich hatte vor nicht allzu langer Zeit an einer Präsentation teilgenommen, in der es um Disaster Recovery und Business Continuity Planning (DR / BCP) in der Cloud ging. Eine Statistik wurde vorgestellt, die die Sicherung einer Multi Terabyte-Datenbank, die fast acht Stunden dauerte, mit einem Snapshot verglich, der nur acht Sekunden dauerte! Ich dachte: "Was ist dieses magische Snapshot-Zeug, das sich den Gesetzen der Physik widersetzt?" Also habe ich herauszufinden versucht, wie ein Snapshot genau funktioniert.

Backup vs. Snapshot – Übersicht auf hoher Ebene

Wie Sie vielleicht bereits wissen; Eine Sicherung ist ein READ-Vorgang, gefolgt von einem WRITE-Vorgang an einen anderen Speicherort, um eine zweite Kopie des gelesenen Artikels zu erstellen. Diese zweite Kopie kann sich auf einer anderen Festplatte/einem anderen Band oder in einem Objektspeicher in einer anderen Rechenzentrums-/Cloud-Umgebung befinden. Backups erfordern, dass eine exklusive Sperre für alles, was GELESEN wird, vorgenommen wird, um Änderungen während der Kopie zu vermeiden. Es gibt Optionen zum Erstellen von "Online-Backups", bei denen Schreibvorgänge nicht angehalten werden müssen, aber dabei gibt es einige Performance-Herausforderungen.

Ein Snapshot hingegen ist eine exakte Block-für-Block-Kopie eines vollständigen Festplatten-Volumes zu einem bestimmten Zeitpunkt. Dieser Vorgang findet auf Festplatten-/Hardware-Ebene statt, nicht auf der Anwendungs- (oder Betriebssystem-)Ebene wie bei einem Backup, so dass er viel schneller und viel weniger aufdringlich ist ... bis zu einem gewissen Grad. Wir müssen immer noch die Festplatte, von der eine Momentaufnahme gemacht wird, stilllegen und alle Speicherpuffer leeren. Allerdings für einen viel kürzeren Zeitraum als bei der exklusiven Sperre, die das Backup für die Dauer des gesamten READ-Vorgangs benötigt. Um dies zu veranschaulichen, lassen Sie uns ein wenig tiefer in das oben erwähnte Acht-Stunden- vs. Acht-Sekunden-Beispiel eintauchen.

Acht Stunden vs. acht Sekunden – was ist besser?

Nachdem eine achtstündige Sicherung abgeschlossen ist, haben Sie eine Kopie der Quelle als Backup an einem anderen Ort. Im Falle einer Datenbank müssen Sie die Sicherung weiterhin in einer Datenbankinstanz wiederherstellen, um sie verwenden zu können.

Nachdem ein Cloud-Snapshot von etwa acht Sekunden abgeschlossen ist, haben Sie ALLE geänderten Blöcke markiert, damit sie später zur weiteren Verarbeitung "gemächlich kopiert" (“lazily copied”) werden können. Der entscheidende Punkt hier ist, DASS SIE NOCH KEINE KOPIE IHRER DATEN HABEN! Sie haben nur Blöcke, die den Snapshot "markieren". Während dieses Teils des Snapshots müssen alle Datenbankaktivitäten stillgelegt werden, um die Integrität der Datenbank über alle Knoten hinweg zu gewährleisten. Dies bedeutet, dass alle Lese- und Schreibvorgänge über einen "TPASUSPEND"-Befehl angehalten werden müssen. Sobald der Markierungsvorgang abgeschlossen ist, der je nach Anzahl der Blöcke auf dem/den Volume(s) nur wenige Sekunden oder einige Minuten dauern kann, können Datenbankvorgänge fortgesetzt werden. Nachfolgende READ-Vorgänge werden ungehindert fortgesetzt, aber wenn ein WRITE-Vorgang versucht, einen Block zu ändern, der als kopiert markiert ist, MUSS der Snapshot-Prozess eine Kopie des Blocks erstellen, bevor der Schreibvorgang verarbeitet werden kann (siehe Copy-on-Write). Bei Systemen mit hohen WRITE-Workloads kann sich dies auf die Leistung der Workload auswirken, da eine Kopie jedes Blocks erstellt werden muss, bevor der Schreibvorgang erfolgen kann. Es gibt Möglichkeiten, diese Auswirkungen zu verringern, indem Snapshots für Zeiträume starker Schreibaktivitäten wie Batch-Ladefenster geplant werden.

Schnappschuss gemacht... er ist aber noch nicht fertig!

Wenn die für den Snapshot markierten Blöcke vom Cloud Anbieter in einen Objektspeicher kopiert werden, wird der Snapshot als "In Bearbeitung" angezeigt. Ich möchte an dieser Stelle anmerken, dass ich bereits erwähnt habe, dass die markierten Blöcke "gemächlich kopiert" werden. Dies bedeutet, dass dieser Teil des Cloud Snapshot-Prozesses keine SLAs darüber garantiert, wie lange es dauert, alle Blöcke in einen Objektspeicher zu kopieren. Dies geschieht im Hintergrund basierend auf den verfügbaren Ressourcen und kann nicht vom Dateneigentümer kontrolliert werden.

Sobald es als "Abgeschlossen" markiert ist, haben Sie eine Kopie Ihres Volumes in einem Objektspeicher, einen Cloud-Snapshot, in derselben Region wie Ihre Quelle. Sie sind also in einer Katastrophensituation immer noch nicht geschützt. Sie müssen nun den Snapshot aus dem Objektspeicher an einen anderen Ort kopieren, vorzugsweise in eine andere Cloud.

Um den Snapshot für die Wiederherstellung verwenden zu können, müssen Sie GENAU die gleiche Speichermenge in derselben Konfiguration zuweisen, in der ursprünglich ein Snapshot erstellt wurde, und dann die Snapshot-Blöcke wieder auf die neuen Speicher-Volumes "re-hydrieren". Denken Sie daran, dass ein Snapshot eine Point-in-Time-Kopie Ihres Speichers ist, wenn Sie also alle 12 Stunden einen Snapshot erstellen und die letzten vier Snapshots beibehalten, können Sie einen der vier Snapshot-Zeiträume wiederherstellen. Wenn Sie DR-Zwecke verfolgen, werden Sie meistens den neuesten Snapshot wiederherstellen, aber Sie wissen nun, dass Sie eine gewisse Flexibilität haben, ähnlich wie bei einem Backup.

Fazit

Zurück zur ursprünglichen Frage: "Magie oder nur ein weiteres Werkzeug?" Im Allgemeinen sind Snapshots eine großartige Möglichkeit, eine vollständige Kopie des Speichers zu erstellen, der an Ihre Compute-Knoten angefügt ist. Sie erfolgen schnell und haben relativ vernachlässigbare Auswirkungen auf Ihre Arbeitslast im Vergleich zu gleichwertigen Sicherungsvorgängen über Ihr Datenbankmodul. Aber sie sind KEINE Magie! Sie sind nur eine weitere Möglichkeit, Ihren Speicher auf ein gleichwertiges System zu kopieren und wiederherzustellen, unabhängig davon, ob es sich um dieselbe Cloud oder eine ganz andere handelt. Der Nachteil von Snapshots gegenüber Backups besteht darin, dass es keine Möglichkeit zur Wiederherstellung auf Objektebene gibt. Wenn Sie ein einzelnes, hochwertiges Objekt haben, das beschädigt wird, können Sie NICHT eben mal nur genau dieses Objekt aus einem Snapshot wiederherstellen, wie Sie es aus einer Sicherung heraus könnten. Ein weiterer Nachteil ist, dass das System, das Sie wiederherstellen, in Größe und Konfiguration mit Ihrem ursprünglichen System identisch sein MUSS. Ein Backup können Sie auf einem System mit anderer Größe wiederhergestellt, falls gewünscht. Die Quintessenz ist, sich nicht durch den Vergleich "acht Stunden vs. acht Sekunden" verwirrt zu lassen. Auch wenn ein Snapshot weniger Zeit in Anspruch nimmt, um eine Kopie Ihrer Datenbank zu erstellen, dauert es mehr als acht Sekunden, bis Sie vollständig vor einer Katastrophe geschützt sind.

Infos Edward Aiello

Edward Aiello has over 30 years of Information Technology experience ranging from software developer, to system/database administrator, to business analyst/project lead, to enterprise level architecture.  The diversity of roles he has held over the years has helped bridge gaps across all levels of the organizations where he has worked and ultimately bring value to his customers.

Zeige alle Beiträge von Edward Aiello

Bleiben Sie auf dem Laufenden

Abonnieren Sie den Blog von Teradata, um wöchentliche Einblicke zu erhalten



Ich erkläre mich damit einverstanden, dass mir die Teradata Corporation als Anbieterin dieser Website gelegentlich Teradata Marketingkommunikations-E-Mails mit Informationen über Produkte, Data Analytics und Einladungen zu Veranstaltungen und Webinaren zusendet. Ich nehme zur Kenntnis, dass ich mein Einverständnis jederzeit widerrufen kann, indem ich auf den Link zum Abbestellen klicke, der sich am Ende jeder von mir erhaltenen E-Mail befindet.

Der Schutz Ihrer Daten ist uns wichtig. Ihre persönlichen Daten werden im Einklang mit der globalen Teradata Datenschutzrichtlinie.

Erfahren Sie mehr von Teradata