Share via


Notfallwiederherstellungsszenario für eine Oracle Database 12c-Datenbank in einer Azure-Umgebung

Gilt für: ✔️ Linux-VMs

Annahmen

  • Sie besitzen Grundkenntnisse des Aufbaus von Oracle Data Guard und von Azure-Umgebungen.

Ziele

  • Entwerfen der Topologie und Konfiguration, die Ihre Anforderungen an die Notfallwiederherstellung (Disaster Recovery, DR) erfüllen.

Szenario 1: Primäre und DR-Standorte in Azure

Ein Kunde verfügt am primären Standort über eine Oracle-Datenbank. Ein DR-Standort befindet sich in einer anderen Region. Der Kunde verwendet Oracle Data Guard für die schnelle Wiederherstellung zwischen diesen Standorten. Der primäre Standort verfügt auch über eine sekundäre Datenbank für Berichte und andere Zwecke.

Topologie

Hier ein Überblick über den Aufbau von Azure:

  • Zwei Standorte (ein primärer Standort und ein DR-Standort)
  • Zwei virtuelle Netzwerke
  • Zwei Oracle-Datenbanken mit Data Guard (primär und Standby)
  • Zwei Oracle-Datenbanken mit Golden Gate oder Data Guard (nur am primären Standort)
  • Zwei Anwendungsdienste, einer am primären und einer am DR-Standort
  • Eine Verfügbarkeitsgruppe, die für Datenbank- und Anwendungsdienste am primären Standort verwendet wird
  • Eine Jumpbox an jedem Standort, die den Zugriff auf das private Netzwerk einschränkt und nur Anmeldung durch einen Administrator zulässt
  • Jumpbox, Anwendungsdienst, Datenbank und VPN-Gateway befinden sich in separaten Subnetzen
  • Netzwerksicherheitsgruppe (Network Security Group, NSG) wird auf den Anwendungs- und Datenbanksubnetzen erzwungen

Diagramm mit primären und DR-Standorten in Azure.

Szenario 2: Lokaler primärer Standort und DR-Standort in Azure

Ein Kunde verfügt über eine lokale Oracle-Datenbank (primärer Standort). Ein DR-Standort befindet sich in Azure. Oracle Data Guard wird für die schnelle Wiederherstellung zwischen diesen Standorten verwendet. Der primäre Standort verfügt auch über eine sekundäre Datenbank für Berichte und andere Zwecke.

Es gibt zwei Ansätze für diesen Aufbau.

Ansatz 1: Direkte Verbindungen zwischen dem lokalen Standort und Azure, für die die TCP-Ports in der Firewall geöffnet sein müssen

Wir empfehlen keine direkten Verbindungen, da sie die TCP-Ports für die Außenwelt verfügbar machen.

Topologie

Hier ein Überblick über den Aufbau von Azure:

  • Ein DR-Standort
  • Ein virtuelles Netzwerk
  • Eine Oracle-Datenbank mit Data Guard (aktiv)
  • Ein Anwendungsdienst am DR-Standort
  • Eine Jumpbox, die den Zugriff auf das private Netzwerk einschränkt und nur Anmeldung durch einen Administrator zulässt
  • Jumpbox, Anwendungsdienst, Datenbank und VPN-Gateway befinden sich in separaten Subnetzen
  • Netzwerksicherheitsgruppe (Network Security Group, NSG) wird auf den Anwendungs- und Datenbanksubnetzen erzwungen
  • Eine NSG-Richtlinie/Regel, um den eingehenden TCP-Port 1521 (oder einen benutzerdefinierten) zuzulassen
  • Eine NSG-Richtlinie/Regel, damit nur die lokale/n IP-Adresse/n (Datenbank oder Anwendung) auf das virtuelle Netzwerk zugreifen kann/können

Diagramm: Direkte Verbindungen zwischen dem lokalen Standort und Azure, für die TCP-Ports in der Firewall geöffnet sein müssen.

Ansatz 2: Site-to-Site-VPN

Das Site-to-Site-VPN ist ein besserer Ansatz. Weitere Informationen zum Einrichten eines VPN finden Sie unter Erstellen eines virtuellen Netzwerks mit einer Site-to-Site-VPN-Verbindung per CLI.

Topologie

Hier ein Überblick über den Aufbau von Azure:

  • Ein DR-Standort
  • Ein virtuelles Netzwerk
  • Eine Oracle-Datenbank mit Data Guard (aktiv)
  • Ein Anwendungsdienst am DR-Standort
  • Eine Jumpbox, die den Zugriff auf das private Netzwerk einschränkt und nur Anmeldung durch einen Administrator zulässt
  • Jumpbox, Anwendungsdienst, Datenbank und VPN-Gateway befinden sich in separaten Subnetzen
  • Netzwerksicherheitsgruppe (Network Security Group, NSG) wird auf den Anwendungs- und Datenbanksubnetzen erzwungen
  • Site-to-Site-VPN-Verbindung zwischen lokalem Standort und Azure

Screenshot der DR-Topologieseite

Zusätzliche Lektüre

Nächste Schritte