Disaster Recovery

Mit einem gut strukturierten Disaster-Recovery-(DR-)Plan können Sie Ihren Benutzern nach Katastrophen schnell wieder Services bereitstellen.

DR dient der Vorbereitung auf Katastrophen und dem schnellen Recovery danach. Eine Katastrophe kann jedes Ereignis sein, das Ihre Anwendungen gefährdet, von Netzwerkausfällen über Geräte- und Anwendungsausfälle bis hin zu Naturkatastrophen. Es ist kaum vorherzusagen, wann Sie ein Disaster Recovery benötigen. Wenn Sie nicht kontrollieren können, wann eine Katastrophe eintritt, ist die nächstbeste Alternative, den Wiederherstellungsprozess steuern zu können.

Mit einem gut konzipierten DR-Plan können Sie sich schnell von Katastrophen erholen und die Geschäftskontinuität gewährleisten. Wenn Ihre Organisation Workloads in die Cloud verlagert, müssen Sie Ihre Kenntnisse zum Erstellen resilienter On-Premise-Systeme auf die Cloud übertragen. Oracle Cloud Infrastructure (OCI) bietet hochverfügbare, sichere und skalierbare Infrastruktur und Services, mit denen Sie Ihre Cloud-Workloads schnell, zuverlässig und sicher wiederherstellen können.

Da Multi-Tier- oder 3-Tier-Architekturen in traditionellen On-Premise-Unternehmensanwendungen üblich sind, zeigen wir Ihnen anhand einer 3-Tier-Unternehmensanwendung, wie Sie diese Anwendung mit OCI-DR-Funktionen und den zuverlässigen und resilienten Best Practices für die Cloud-Topologie ausfallsicher machen können. Das folgende Diagramm zeigt ein Beispiel für eine Unternehmensanwendung in einer Warm Standby-DR-Konfiguration.

Beispiel für eine Unternehmensanwendung in der Konfiguration des Warm Standby-Disaster Recoverys.

DR-Konzepte

Der erste Schritt bei der Planung des DR besteht in der Bestimmung des RTO-(Recovery Time Objective-)Ziels und des RPO-(Recovery Point Objective-)Ziels.

Das RTO ist die Zielzeit, innerhalb der eine bestimmte Anwendung nach einer Katastrophe wiederhergestellt werden muss. In der Regel gilt: Je kritischer die Anwendung, desto niedriger das RTO.

Das RPO ist der Zeitraum nach einer Katastrophe, für den eine Anwendung verlorene Daten tolerieren kann, bevor die Katastrophe das Geschäft beeinträchtigt.

Um einen Plan zu erstellen, der das Recovery Ihrer Anwendungen nach einer Katastrophe garantiert und kosteneffektiv ist, müssen Sie sowohl die Zielzeit als auch die Toleranz für den Datenverlust berücksichtigen.

Das Diagramm zeigt das Recovery Point Objective vor einer Katastrophe, die Katastrophe und dann das Recovery Time Objective.

Weitere Informationen finden Sie unter Best Practices zum Schutz Ihrer Cloud-Topologie vor Katastrophen.

DR-Ansatz auswählen

Einige Anwendungen sind wichtiger als andere. Die gewählte DR-Lösung hängt von vielen möglichen Anforderungen ab, darunter Verfügbarkeit, Datendauerhaftigkeit, RTO und RPO.

Bewerten Sie die DR-Methoden in der folgenden Tabelle, um zu entscheiden, welche OCI-DR-Funktionen beim Deployment von Multi-Tier-Unternehmensanwendungen auf OCI verwendet werden sollen.

DR-Methode RPO RTO Kosten
Backup und Restore Stunden Stunden $
Pilotflamme Minuten Minuten $$
Warm Standby Sekunden Minuten $$$
Aktiv/aktiv Nahe null Potenziell null $$$$

Berücksichtigen Sie sowohl Regionen als auch Availability-Domains in einer Region bei DR- und High-Availability-(HA)-Szenarios. Eine Region ist ein bestimmter geografischer Bereich. Eine Availability-Domain umfasst mindestens ein Data Center innerhalb einer Region. Wenn Ihr DR-Plan erfordert, dass DR-Standorte physisch weit auseinander liegen, kann dieses Ziel mit mehreren Regionen erreicht werden.

Bei unserer Beispielunternehmensanwendung müssen wir einen regionalen Ausfall überstehen, können aber Ausfallzeiten bewältigen, wenn eine Region betroffen ist. Aus diesen Gründen haben wir ein Warm Standby-Deployment in mehreren Regionen gewählt.

DR-Orchestrierung mit Full Stack DR verwalten

Full Stack Disaster Recovery (DR) ist ein nativer OCI-Service, der eine einfache und konsistente Schnittstelle zur Orchestrierung von DR-Vorgängen für viele verschiedene Systeme bietet. So kann jeder autorisierte Benutzer in Ihren IT-Vorgängen ein Failover oder Switchover auslösen, ohne einen der zugrunde liegenden Recovery-Prozesse verstehen zu müssen.

Full Stack DR ist die erste echte Disaster Recovery-as-a-Service-Lösung (DRaaS) von Oracle für OCI und mehr als nur eine einfache Orchestrierungs-Engine. Full Stack DR ist ein hoch skalierbarer, hochgradig erweiterbarer DR-Managementservice, der die Schritte zum Testen, Übergang oder Wiederherstellen kritischer und nicht kritischer Geschäftssysteme zwischen zwei OCI-Regionen von überall auf der Welt mit einem einzigen Klick vollständig automatisiert.

Die Probleme, mit denen Unternehmen mit einer großen Erholung konfrontiert sind

Ihr Unternehmen verfügt wahrscheinlich über mehr als nur ein paar geschäftskritische Anwendungen, die in Ihrem OCI-Tenancy gehostet werden. Um die Dinge zu verkomplizieren, verfügt jede dieser Oracle- oder Nicht-Oracle-Anwendungen über einen anderen Recovery-Prozess mit unterschiedlichen Zielen für Recovery Point und Recovery Time. Darüber hinaus können die Prozesse zur Wiederherstellung jedes verschiedenen Anwendungsstacks komplex sein und erfordern die volle Aufmerksamkeit Ihrer erfahrensten technischen Spezialisten.

Ihre IT-Organisation verfügt wahrscheinlich über die Fähigkeiten und die Entschlossenheit, ein oder zwei verschiedene Anwendungen an einem oder zwei Tagen in einem allumfassenden, umfassenden Aufwand von den führenden IT-Spezialisten des Unternehmens wiederherzustellen. Aber was passiert, wenn Ihre IT-Organisation mit der Aussicht konfrontiert ist, mehr als nur ein paar Systeme gleichzeitig wiederherzustellen?

Full Stack DR erleichtert skalierbare Wiederherstellung

Full Stack DR wurde entwickelt, um DR-Workflows in großem Maßstab zu verarbeiten, ohne dass Ihre qualifiziertesten technischen Experten einbezogen werden, falls Sie viele Systeme gleichzeitig wiederherstellen müssen. Full Stack DR normalisiert die Art und Weise, wie DR-Vorgänge mit einer konsistenten, einfachen Methode über die OCI-Konsole ausgeführt und überwacht werden.

Full Stack DR organisiert verschiedene Anwendungen in unabhängigen Schutzgruppen, ohne die Art und Weise zu ändern, wie Sie Ihre vorhandenen Oracle- und Nicht-Oracle-Anwendungen in OCI installiert und konfiguriert haben. Full Stack DR kann nur eine Komponente eines Anwendungsstacks wiederherstellen oder den gesamten Anwendungsstack mit einem einzigen Klick wiederherstellen - Sie wählen, was Sie tun möchten.

Full Stack DR validiert die Bereitschaft von DR-Plänen

Mit Full Stack DR können Sie überprüfen, ob kritische Geschäftssysteme durch unsere integrierten, vollautomatischen DR-Bereitschaftsprüfungen auf unerwartete Serviceunterbrechungen vorbereitet sind. Unsere Vorabprüfung wird automatisch der Liste der Aufgaben hinzugefügt, die Full Stack DR bei jedem DR-Vorgang durchläuft.

Die Prechecks sind unterbrechungsfrei und können jederzeit ausgeführt werden, ohne Ihre Produktionssysteme zu stören. Wir validieren die Integrität von DR-Plänen, indem wir prüfen, ob Netzwerk-, Speicher-, Compute-, Oracle-Datenbanken und alle benutzerdefinierten Skripte, die Sie einem DR-Plan hinzugefügt haben, dort sind, wo sie sich befinden sollten und bereit sind.

Flexibilität bei der Verwaltung jeder Deployment-Architektur

Flexibilität ist ein Schlüsselkonzept hinter dem Design von Full Stack DR. Verschiedene Geschäftssysteme erfordern unterschiedliche Wiederherstellungslösungen. Daher entspricht Full Stack DR der Art und Weise, wie Sie jedes einzelne Geschäftssystem auf eine Weise wiederherstellen müssen, die Ihren technischen und geschäftlichen Anforderungen entspricht. Wie Sie ein Geschäftssystem für Disaster Recovery installieren und bereitstellen, liegt bei Ihnen.

Unsere DRaaS-Lösung kann das Recovery für jedes einzelne Geschäftssystem unterschiedlich verwalten, unabhängig davon, ob es für VM-Failover, Pilotlight, Cold Standby, Warm Standby, Hot Standby oder Active/Active bereitgestellt wird. Sie übernehmen die Bereitstellung und wir übernehmen die Wiederherstellung.

Erfahren Sie mehr über Full Stack DR

Full Stack DR bietet Ihnen die Möglichkeit und Flexibilität, DR für Oracle- oder Nicht-Oracle-Anwendungen in OCI so zu implementieren, wie Sie möchten, nicht so, wie wir es wünschen.

DR-Design - Überlegungen

Je nach der von Ihnen implementierten DR-Methode müssen viele Aspekte berücksichtigt werden.

Hintergrundinformationen zu DR-Funktionen finden Sie unter DR-Funktionen von Oracle Cloud. In diesem Beispiel wird die Methode Warm Standby und die OCI-Ressourcen geprüft, die zur Implementierung von Warm Standby erforderlich sind. Dazu gehört eine zweite Region für ein regionales Deployment.

Networking

Nachdem Sie die Netzwerkgrundlage von virtuellen Cloud-Netzwerken (VCNs) und Subnetzen in den jeweiligen Regionen erstellt haben, müssen Sie die VCNs in den verschiedenen Regionen per Peering verbinden, um die Netzwerkkonnektivität zu vereinfachen.

Compute

Um Anwendungen auf Compute-Instanzen in zwei Regionen auszuführen, müssen Sie die Compute-Images in beiden Regionen verfügbar machen. Stellen Sie in der Region für DR ein minimales Setup für die Verwaltung von Warm Standby bereit. Verwenden Sie dann Kapazitätsreservierungen, um den Rest der erforderlichen Kapazität zur Ausführung aller VMs zu reservieren, wenn die DR-Region zur primären Region wird. Weitere Informationen finden Sie unter Überblick über Compute Service und Best Practices für Ihre Compute-Instanzen.

Speicher

OCI bietet eine Reihe von Speicherservices, die Block Volume, File Storage und Object Storage enthalten, die integrierte Redundanz- und High-Availability-Features bereitstellen, indem mehrere Kopien von Daten verwaltet werden. Diese Speicherservices bieten auch native Replikation, die für regionsübergreifendes Disaster Recovery konfiguriert werden kann.

Object Storage ist eine internetbasierte, leistungsstarke Speicherplattform, die zuverlässige und kostengünstige Dauerhaftigkeit von Daten bietet. Object Storage ist ein regionaler Service und ist über alle Availability-Domains in einer Region hinweg verfügbar. Die Objektspeicherreplikation kann zu DR-Zwecken regionsübergreifend konfiguriert werden.

Block Volume verfügt über ein vollständig verwaltetes und asynchrones Replikationsfeature, das das Disaster Recovery unterstützt. Wenn das Recovery Time Objective (RTO) weniger als eine Minute beträgt, können Sie Volumes und Volume-Gruppen in eine andere Region replizieren. Mit einem automatisierten Backupfeature können Sie auch absturzkonsistente Backups für Volumes und Volume-Gruppen erstellen. Diese Backups können automatisch in eine andere Region kopiert werden.

Ähnlich wie andere Speicherservices in OCI verfügt File Storage über integrierte Replikationsfeatures, die asynchron in eine andere Availability-Domain und Region repliziert werden können. Mit dem Klonenfeature von File Storage können die Daten auf der Zielseite fast sofort verfügbar gemacht werden (RTO). Für eine vollständige DR-Erfahrung repliziert die Replikation auch Snapshots mit den Hauptdateisystemdaten.

Datenbank

Das High Availability-Design soll die Anwendungsverfügbarkeit bei IaaS-Fehlerereignissen wie Knoten- oder Netzwerkausfällen sicherstellen. Die Datenbank-DR-Szenarios befassen sich mit der Vermeidung des Verlusts kritischer Geschäftsdaten aufgrund eines erheblichen und unvermeidbaren Ausfalls der Primärdatenbanken, die sich häufig auf eine gesamte Region oder eine Availability-Domain auswirken.

Wir empfehlen, dass Sie auf Maximum Availability Architecture (MAA) verweisen. Dies ist eine Gruppe von Best Practices und Referenzarchitekturen, die von Oracle Ingenieuren über viele Jahre für die integrierte Verwendung von Oracle High-Availability-, Datenschutz- und Disaster-Recovery-Technologien entwickelt wurden.

Die wichtigsten Überlegungen für ein DR-Design sind das RPO (Recovery Point Objective), das die Menge des Datenverlusts darstellt, den Ihre Anwendung tolerieren kann, und das RTO (Recovery Time Objective), das die maximale Recovery-Zeit ist, die Ihre Anwendung tolerieren kann, bevor Systeme wieder online gehen müssen. Auf dieser Grundlage gibt es verschiedene Kategorien, die MAA mit steigenden Kosten und Komplexität definiert. Diese werden als Bronze, Silber, Aurous, Gold und Platin eingestuft, wobei die Komplexität und Widerstandsfähigkeit immer weiter zunimmt. Diese bilden die Grundlage für die von MAA angegebenen DR-Referenzarchitekturen.

Maximum Availability Architecture-(MAA-)Ebenen Kernarchitektur Recovery Point Objective (RPO): Recovery Time Objective (RTO): Oracle Autonomous Database Serverless (ADB-S) Oracle Autonomous Database on Dedicated Exadata Infrastructure (ADB-D und ADB-C@C) Oracle Base Database Service (VM) Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C)
BRONZE Einzelinstanz mit lokalem Backup und repliziertem Backup Letztes Backup Stunden Out-of-the-box Out-of-the-box Out-of-the-box Out-of-the-box Out-of-the-box
SILBER RAC mit lokalem Backup und repliziertem Backup Letztes Backup Stunden (Null für geplante Wartung) Out-of-the-box Out-of-the-box Out-of-the-box für 2 Knoten (EE Extreme Performance erforderlich) Out-of-the-box Out-of-the-box
AUROUS Aktualisierbare PDB Zuletzt aktualisiert Minuten + Autonomous Data Guard Optional Optional Optional Optional
GOLD Datenbank mit standortübergreifender Active/Passive-Replikation über (Active) Data Guard Null Sekunden Nicht anwendbar + Data Guard + Data Guard (erfordert EE/EE HP für Standard DG, EE EP für Active DG) + Data Guard + Data Guard
PLATINUM Datenbank mit standortübergreifender Active/Active-Replikation über GoldenGate Null Null + GoldenGate + GoldenGate + GoldenGate + GoldenGate + GoldenGate

Dieses DR-Design und diese Strategie beschreiben die Vermeidung von Datenverlust in der Oracle-Datenbank. Eine robuste DR-Strategie muss auch Konfigurationen für die kontinuierliche Verfügbarkeit von Anwendungen berücksichtigen.

Zu den Schlüsseltechnologien, die das MAA bilden, gehören:

Monitoring

OCI Monitoring ermöglicht es Ihnen, Ihre Cloud-Ressourcen aktiv und passiv zu überwachen, um eine bessere Verfügbarkeit und konsistente Servicelevels zu erzielen. Stellen Sie sicher, dass Sie die OCI-Statusbenachrichtigungen abonniert haben, und prüfen Sie das Servicezustands-Dashboard. Ein Beispiel finden Sie unter End-to-End-Überwachung von Anwendungen, die auf Oracle Cloud Infrastructure ausgeführt werden.

Mehr erfahren

Lösungs-Playbooks:

Referenzarchitekturen:

Dokumentation und weitere Ressourcen: