DR-Methode auswählen

Entscheiden Sie je nach Ihren Geschäfts- und IT-Anforderungen die Disaster Recovery-(DR-)Methode, die für Ihr Deployment am besten geeignet ist.

Block-Volumes sichern und wiederherstellen

Backups dienen vor allem der Unterstützung von Geschäftskontinuität, Disaster Recovery und langfristiger Archivierung.

Im Folgenden werden häufig verwendete Anwendungsfälle für Block-Volume-Backups aufgeführt:

• Erstellen Sie mehrere Kopien desselben Volumes. Backups sind nützlich, wenn Sie Instanzen mit vielen Volumes benötigen, die dieselben Daten enthalten müssen.
• Sie müssen Snapshots erstellen, die Sie später auf einem neuen Volume wiederherstellen können.
• Sicherstellen, dass Sie eine zuverlässige Kopie der Daten haben, falls das primäre Volume fehlerhaft ist.

Berücksichtigen Sie beim Definieren Ihres Backupplans und Ihrer Ziele die folgenden Faktoren:

• Häufigkeit: Wie oft möchten Sie Backups Ihrer Daten erstellen?
• Wiederherstellungszeit: Wie lange darf es dauern, bis ein Backup wiederhergestellt wird und Ihre Anwendungen zugänglich sind? Die Zeit für das Erstellen eines Backups hängt von verschiedenen Faktoren ab, wie der Größe der zu sichernden Daten und der Datenmenge, die seit dem letzten Backup geändert wurde.
• Anzahl der gespeicherten Backups: Wie viele Backups müssen verfügbar sein, und nach welchem Zeitraum werden nicht mehr benötigte Backups gelöscht?

Beachten Sie beim Erstellen von Backups und Wiederherstellen von Backups die folgenden Best Practices:

• Stellen Sie vor dem Erstellen eines Backups sicher, dass die Daten konsistent sind: Synchronisieren Sie das Dateisystem, unmounten Sie das Dateisystem, wenn möglich, und speichern Sie Ihre Anwendungsdaten. Nur die Daten auf dem Datenträger werden gesichert. Wenn sich beim Erstellen eines Backups der Backupstatus von REQUEST_RECEIVED in CREATING geändert hat, können Sie wieder Daten auf das Volume schreiben. Während ein Backup ausgeführt wird, kann das Volume, das gesichert wird, nicht gelöscht werden.
• Wenn Sie ein wiederhergestelltes Volume an Compute-Instanzen anhängen möchten, an die das ursprüngliche Volume angehängt ist, beachten Sie, dass einige Betriebssysteme die Wiederherstellung identischer Volumes nicht unterstützen. Um dieses Constraint zu überwinden, ändern Sie die Partitions-IDs, bevor Sie das Volume wiederherstellen. Die Schritte zum Ändern der Partitions-ID eines Betriebssystems sind vom Betriebssystem abhängig. Weitere Informationen finden Sie in der Dokumentation zum Betriebssystem Ihrer Compute-Instanz.
• Löschen Sie das ursprüngliche Volume erst, nachdem Sie sichergestellt haben, dass das Backup erfolgreich erstellt wurde.

Wenn Ihre Anwendung mehrere Volumes verwendet, die sich über mehrere Compute-Instanzen erstrecken, verwenden Sie Volume-Gruppenbackups. Volume-Gruppen vereinfachen das Erstellen von Backups und Klonen für Anwendungen, die mehrere Volumes über mehrere Instanzen hinweg verwenden. Sie können eine gesamte Volume-Gruppe aus einem Volume-Gruppenbackup wiederherstellen, wie im folgenden Diagramm dargestellt.

Beschreibung der Abbildung volume-backup-restore.png

Eine Pilotversion erstellen

Der Begriff Pilotlicht bezieht sich auf eine kleine Flamme in einer traditionellen gasbetriebenen Heizung, die immer beleuchtet wird und zum schnellen Neustart der Heizung verwendet werden kann, wenn sie von Temperatursensoren im Haus ausgelöst wird. Im Kontext der DR besteht ein Pilotlicht aus den kritischen Kernkomponenten Ihrer Anwendung, die am DR-Standort bereitgestellt sind und die neueste Anwendungskonfiguration und kritische Daten enthalten. Diese Kern-Pilotenlichtkomponenten können dann zur Wiederherstellung einer produktionsgroßen Umgebung im Falle einer Katastrophe verwendet werden.

Im Folgenden sind die kritischen Komponenten der Pilotleuchte am DR-Standort aufgeführt:

• Database-Tier

  Mit dem Oracle Cloud Infrastructure Database-Service können Sie die gesamte Datenbank im DR-Standort (Availability-Domain, Region oder beides) bereitstellen, ohne produktionsbezogene Ressourcen zu aktivieren. Wenn DR aktiviert ist, können Sie mehr Ressourcen mit einem einzelnen REST-API-Aufruf zum Service aktivieren, ohne den Datenbankserver neu zu starten.

• Application Tier

  Sie stellen nur einen Anwendungsserver in Ihrem DR-Standort (Availability-Domain, Region oder beides) bereit, der die gesamte aktuelle Konfiguration enthält. Mit dem Feature für benutzerdefinierte Images in Oracle Cloud Infrastructure können Sie Ihr BS und Ihre Anwendungen regelmäßig sichern und mit diesen Images neue Server bereitstellen, wenn der DR-Standort aktiviert ist.

  Beispiel: Wenn eine Produktions-Site acht Anwendungsserver enthält, stellen Sie nur einen Anwendungsserver im DR-Standort bereit, und synchronisieren Sie ihn mit rsync oder einem anderen Tool mit der primären Site. Sie erstellen täglich ein benutzerdefiniertes Image von diesem Server im DR-Standort, mit dem die restlichen sieben Server bereitgestellt werden können, wenn DR aktiviert ist.

• Networking-Tier
  Verwenden Sie die folgenden Oracle Cloud Infrastructure-Features und -Services in Ihrer Pilotversion am DR-Standort

  • IP-Adressen (privat und öffentlich)
  • DNS-Service
  • Lastausgleichsservice

Aktive Standby-Datenbank verwenden

Eine Active Standby-Datenbank (nicht gemountete Standby-Datenbank) ist eine Standby-Datenbank, die schreibgeschützt ist, während die Datenbank wiederhergestellt wird. Für Active Standby sind das Feature und die Lizenz von Active Data Guard erforderlich.

Mit Active Data Guard kann die physische Standby-Datenbank für Lesevorgänge und Berichte genutzt werden, wodurch die potenzielle Workload auf der primären Datenbank reduziert wird. Active Data Guard bietet umfassenden Datenschutz mit automatischer Blockreparatur physischer Datenbeschädigungen und prüft auf andere Arten von Datenbeschädigungen wie verlorene Schreibvorgänge und logische Blockbeschädigungen. Bei der gemounteten Standby-Datenbank profitieren Sie zudem von vielen Datenschutzvorteilen, mit Ausnahme der automatischen Blockreparatur physischer Blockfehler. Recovery-Zeit (RTO) und Datenverlust (RPO) sind in der Regel sehr niedrig, wenn ein Failover auf eine Standbydatenbank erfolgt, unabhängig davon, ob sie schreibgeschützt ist oder nicht.

Berücksichtigen Sie bei der Auswahl einer DR-Methode, ob Sie symmetrische oder asymmetrische Ressourcen benötigen:

• Symmetrische Ressourcen: Dies ist die empfohlene Architektur, sodass die Standby-Datenbank symmetrisch zum primären System ist, um sicherzustellen, dass die Anwendungs- und Datenbankperformance zum Zeitpunkt des Rollenübergangs ähnlich oder identisch ist. Dadurch wird auch sichergestellt, dass die Standbydatenbank über ausreichende Ressourcen verfügt, um mit der Produktions-Workload Schritt zu halten, damit der Datenverlust zum Zeitpunkt einer Katastrophe minimal ist. Wird sie als aktive Standbydatenbank oder mit der Option Active Data Guard bereitgestellt, ist die Standbydatenbank schreibgeschützt geöffnet, während sie DR-Schutz bereitstellt. So können Sie Berichte und Abfragen auslagern.

• Asymmetrische Ressourcen: Diese Architektur ist eine horizontale Skalierungskonfiguration der Standbyumgebung. Mit Active Data Guard kann die Standbydatenbank weiterhin nur gelesen werden, sodass sie dieselben Vorteile beim Auslagern der Arbeit in die Standbydatenbank bietet. Nach dem Failover ist die Performance jedoch möglicherweise nur dann gleich, wenn Sie das System entsprechend der primären Datenbank skalieren.

  Asymmetrische oder kleinere Standbysysteme kosten weniger, haben aber möglicherweise weniger Rechen-, CPU- und Arbeitsspeicher zur Kostensenkung. Die Deaktivierung erfolgt nach einem Rollenübergang oder einem Failover-Ereignis. Sie müssen entweder nach oben (erweitern) skalieren, um dem vorherigen primären System zu entsprechen, oder eine geringere Performance oder eingeschränkte Funktionalität akzeptieren.

Cold Standby verwenden

Mit dem Begriff Cold Standby wird ein DR-Szenario beschrieben, in dem ein redundantes Replikat der primären Umgebung an einem DR-Standort bereitgestellt wird. Die Cold Standby-Umgebung wird nur aktiviert, wenn das primäre System ausfällt. Dieser Ansatz bietet eine Produktionskontinuität mit einer genau definierten Aktivierungszeit für den Switchover.

Oracle Cloud Infrastructure unterstützt das automatisierte (programmgesteuerte) Deployment einer Cold-Standby-Umgebung, in der die Kosten für die Wartung einer solchen Umgebung auf ein Minimum reduziert werden. Ihnen werden nur die aktiven Ressourcen und der persistente Speicher in Rechnung gestellt, den Sie am DR-Standort nutzen.