Introduction
Ensuring uninterrupted business continuity is critical to success when designing applications. Achieving this requires a robust disaster recovery strategy designed to quickly restore functionality in case of disruptions.
For years, businesses have trusted Oracle Exadata Database Service with Oracle’s premier disaster recovery technologies to power critical applications, both on-premises and within Oracle Cloud Infrastructure (OCI). Now, Oracle Exadata Database Service on Oracle Database@Azure delivers the same cutting-edge performance, feature set, and cost-effectiveness as Exadata on OCI. By utilizing Microsoft Azure’s availability zones (AZs) and regions, it offers low latency to Azure’s applications on top of unparalleled high availability and disaster recovery, guaranteeing smooth operations during routine maintenance and unforeseen outages.
Architecture
This architecture shows Oracle Exadata Database Service on Oracle Database@Azure in a cross-region disaster recovery topology using two remote standby databases.
For data protection, the Oracle Database is running in an Exadata virtual machine (VM) cluster in the primary region, with Oracle Active Data Guard replicating the data to two standby databases running on Exadata VM clusters in two different standby regions. This provides flexibility for both data protection and disaster recovery. A remote standby database setup ensures data protection against regional failures. Additionally, it can be used to offload read-only query processing. The application should be replicated across regions to avoid higher latency after switching over to a standby database.
You can route Active Data Guard traffic through the Azure network. However, this architecture focuses on Active Data Guard network traffic through the OCI network to optimize network throughput and latency.
The Oracle Exadata Database Service on Oracle Database@Azure network is connected to the Exadata client subnet using a Dynamic Routing Gateway (DRG) managed by Oracle. A DRG is also required to create a peer connection between Virtual Cloud Networks (VCNs) in different regions. Because only one DRG is allowed per VCN in OCI, a second VCN acting as a Hub VCN with its own DRG is required to connect the primary and standby VCNs in each region. In this example:
- The primary Exadata VM cluster is deployed in
Region 1inVCN1with CIDR 10.10.0.0/16. - The hub VCN in the primary region is
HubVCN1with CIDR 10.11.0.0/16. - The first standby Exadata VM cluster is deployed in
Region 2inVCN2with CIDR 10.20.0.0/16. - The hub VCN in the first standby region is
HubVCN2with CIDR 10.22.0.0/16. - The second standby Exadata VM cluster is deployed in
Region 3inVCN3with CIDR 10.30.0.0/16. - The hub VCN in the second standby region is
HubVCN3with CIDR 10.33.0.0/16.
No subnet is required for the hub VCNs to enable transit routing, therefore, these VCNs can use very small IP CIDR ranges. The VCNs on the OCI child site were created after the Oracle Exadata Database Service VM clusters on Oracle Database@Azure were created for the primary and standby databases.
Recommendations
Use the following recommendations as a starting point when performing disaster recovery for Oracle Exadata Database Service on Oracle Database@Azure. Your requirements might differ from the architecture described here.
- Use Active Data Guard for comprehensive data corruption prevention with automatic block repair, online upgrades and migrations, and offload workload to standby with read-mostly scale-out.
- Enable Application Continuity to mask database outages during planned and unplanned events from end-users and ensure uninterrupted applications.
- Set up automatic backup to Oracle Database Autonomous Recovery Service (in Azure or OCI) even though the data is protected by Oracle Data Guard to minimize the backup workload on the database by implementing the incremental forever backup strategy that eliminates weekly full backups. Alternatively, customers can use OCI Object Storage for automatic backups.
- Enable backups from standby to achieve backup replication across regions.
- Use OCI Full Stack DR to orchestrate database switchover and failover operations.
- Use OCI Vault to store the database’s Transparent Data Encryption (TDE) keys using customer-managed keys.
Considerations
When performing cross-regional disaster recovery for Oracle Exadata Database Service on Oracle Database@Azure, consider the following.
- When Exadata VM clusters are created in the Oracle Database@Azure child site, each VM cluster is created within its own OCI VCN. Oracle Data Guard requires that the databases communicate with each other to ship redo data. The VCNs must be peered to enable this communication. Hence, the Exadata VM cluster VCNs must not share overlapping IP CIDR ranges.
- Preparation for a disaster scenario requires a comprehensive approach that considers different business requirements and availability architectures and that encompasses those considerations in an actionable, high availability (HA) and disaster recovery (DR) plan. The scenario described here provides guidelines to help select the approach that best fits your application deployment by using a simple but effective failover for the disaster recovery configuration in your Oracle Cloud Infrastructure (OCI) and Microsoft Azure environments.
- Oracle Cloud Infrastructure is the preferred network for achieving better performance, measured by latency and throughput, and for achieving reduced cost, including the first 10 TB/Month egress for free.
- You can create up to 6 standby databases for a primary database via Cloud Tooling.
- Creating a standby database associated with another standby database (cascading standby) is not supported via Cloud Tooling.
Deploy
To configure the network communication between regions shown in the above architecture diagram, complete the following high-level steps.
Primary Region
1. Add the following ingress rules to the Security List of the client subnet of VCN1 to allow incoming traffic from VCN2 and VCN3.
| Stateless | Source | IP Protocol | Source Port Range | Destination Port Range | Allows | Description |
|---|---|---|---|---|---|---|
| No | 10.20.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | allow ingress from VCN2 |
| No | 10.30.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | allow ingress from VCN3 |
2. Create Virtual Cloud Network HubVCN1 with CIDR 10.11.0.0/16.
3. Create Local Peering Gateway HubLPG1 in Virtual Cloud Network HubVCN1.
4. Create Local Peering Gateway LPG1R in Virtual Cloud Network VCN1.
5. Establish the local peering connection between LPG1R and HubLPG1.
6. Add route rules to the Route Table of the client subnet of VCN1 to forward traffic targeted for VCN2 and VCN3 to LPG1R.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.20.0.0/16 | Local Peering Gateway | LPG1R | Static | traffic to VCN2 |
| 10.30.0.0/16 | Local Peering Gateway | LPG1R | Static | traffic to VCN3 |
7. Create Route Table HubLPG1rt in HubVCN1.
8. Associate Route Table HubLPG1rt to Local Peering Gateway HubLPG1.
9. Create Dynamic Routing Gateway DRG1.
10. Create Route Table DRG1rt in HubVCN1.
11. Add a route rule to Route Table DRG1rt to forward traffic targeted for VCN1 to HubLPG1.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.10.0.0/16 | Local Peering Gateway | HubLPG1 | Static | traffic to VCN1 |
12. Attach DRG1 to HubVCN1. Choose “Autogenerated Drg Route Table for VCN attachments”, select existing Route Table DRG1rt, and choose “VCN CIDR blocks”.
13. Create two Remote Peering Connections in DRG1, named RPC1a and RPC1b.
14. Add two route rules to HubLPG1rt to forward traffic targeted for VCN2 and VCN3 to DRG1.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.20.0.0/16 | Dynamic Routing Gateway | DRG1 | Static | traffic to VCN2 |
| 10.30.0.0/16 | Dynamic Routing Gateway | DRG1 | Static | traffic to VCN3 |
First Standby Region (Region 2)
1. Add the following ingress rules to the Security List of the client subnet of VCN2 to allow incoming traffic from VCN1 and VCN3.
| Stateless | Source | IP Protocol | Source Port Range | Destination Port Range | Allows | Description |
|---|---|---|---|---|---|---|
| No | 10.10.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | allow ingress from VCN1 |
| No | 10.30.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | allow ingress from VCN3 |
2. Create Virtual Cloud Network HubVCN2 with CIDR 10.22.0.0/16.
3. Create Local Peering Gateway HubLPG2 in Virtual Cloud Network HubVCN2.
4. Create Local Peering Gateway LPG2R in Virtual Cloud Network VCN2.
5. Establish the local peering connection between LPG2R and HubLPG2.
6. Add route rules to the Route Table of the client subnet of VCN2 to forward traffic targeted for VCN1 and VCN3 to LPG2R.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.10.0.0/16 | Local Peering Gateway | LPG2R | Static | traffic to VCN1 |
| 10.30.0.0/16 | Local Peering Gateway | LPG2R | Static | traffic to VCN3 |
7. Create Route Table HubLPG2rt in HubVCN2.
8. Associate Route Table HubLPG2rt to Local Peering Gateway HubLPG2.
9. Create Dynamic Routing Gateway DRG2.
10. Create Route Table DRG2rt in HubVCN2.
11. Add a route rule to DRG2rt to forward traffic targeted for VCN2 to HubLPG2.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.20.0.0/16 | Local Peering Gateway | HubLPG2 | Static | traffic to VCN2 |
12. Attach DRG2 to HubVCN2. Choose “Autogenerated Drg Route Table for VCN attachments”, select existing Route Table DRG2rt, and choose “VCN CIDR blocks”.
13. Create two Remote Peering Connections in DRG2, named RPC2a and RPC2c.
14. Establish remote peering connection between RPC1a (region 1) and RPC2a (region 2).
15. Add two route rules to HubLPG2rt to forward traffic targeted for VCN1 and VCN3 to DRG2.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.10.0.0/16 | Dynamic Routing Gateway | DRG2 | Static | traffic to VCN1 |
| 10.30.0.0/16 | Dynamic Routing Gateway | DRG2 | Static | traffic to VCN3 |
Second Standby Region (Region 3)
1. Add the following ingress rules to the Security List of the client subnet of VCN3 to allow incoming traffic from VCN1 and VCN2.
| Stateless | Source | IP Protocol | Source Port Range | Destination Port Range | Allows | Description |
|---|---|---|---|---|---|---|
| No | 10.10.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | allow ingress from VCN1 |
| No | 10.20.0.0/16 | TCP | 1521 | 1521 | TCP traffic for ports: 1521 | allow ingress from VCN2 |
2. Create Virtual Cloud Network HubVCN3 with CIDR 10.33.0.0/16.
3. Create Local Peering Gateway HubLPG3 in Virtual Cloud Network HubVCN3.
4. Create Local Peering Gateway LPG3R in Virtual Cloud Network VCN3.
5. Establish the local peering connection between LPG3R and HubLPG3.
6. Add route rules to the Route Table of the client subnet of VCN3 to forward traffic targeted for VCN1 and VCN2 to LPG3R.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.10.0.0/16 | Local Peering Gateway | LPG3R | Static | traffic to VCN1 |
| 10.20.0.0/16 | Local Peering Gateway | LPG3R | Static | traffic to VCN2 |
7. Create Route Table HubLPG3rt in HubVCN3.
8. Associate Route Table HubLPG3rt to Local Peering Gateway HubLPG3.
9. Create Dynamic Routing Gateway DRG3.
10. Create Route Table DRG3rt in HubVCN3.
11. Add a route rule to DRG3rt to forward traffic targeted for VCN3 to HubLPG3.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.30.0.0/16 | Local Peering Gateway | HubLPG3 | Static | traffic to VCN3 |
12. Attach DRG3 to HubVCN3. Choose “Autogenerated Drg Route Table for VCN attachments”, select existing Route Table DRG3rt, and choose “VCN CIDR blocks”.
13. Create two Remote Peering Connections in DRG3, named RPC3b and RPC3c.
14. Establish remote peering connection between RPC1b (region 1) and RPC3b (region 3).
15. Establish remote peering connection between RPC2c (region 2) and RPC3c (region 3).
16. Add two route rules to HubLPG3rt to forward traffic targeted for VCN1 and VCN2 to DRG3.
| Destination | Target Type | Target | Route Type | Description |
|---|---|---|---|---|
| 10.10.0.0/16 | Dynamic Routing Gateway | DRG3 | Static | traffic to VCN1 |
| 10.20.0.0/16 | Dynamic Routing Gateway | DRG3 | Static | traffic to VCN2 |
Database Heartbeat 