Learn About Disaster Recovery for Local and Regional Standbys

Ensuring business continuity is critical to success when designing applications. Achieving this requires a disaster recovery strategy that can rapidly restore service during disruptions.
For decades, organizations have relied on Oracle Exadata Database Machine and Oracle Data Guard, Oracle's premier disaster recovery technology, to support mission-critical applications, whether on-premises or within Oracle Cloud Infrastructure (OCI). Oracle Exadata Database Service on Dedicated Infrastructure on Oracle Database@AWS brings the same industry-leading performance, feature set, and price parity as Exadata on OCI. The hardware resides in AWS's data centers to provide low latency to AWS applications on top of unmatched high availability and disaster recovery capabilities, ensuring seamless operations during maintenance and in the event of disruption.

In this solution playbook, you learn how to implement disaster recovery with local and regional standbys on Oracle Database@AWS.

Before You Begin

Before you begin, ensure the following:
  • The Exadata infrastructure and the Exadata VM clusters are deployed in the standby availability zone and region.
  • The network IP CIDR ranges for the primary and standby Exadata VM clusters don't overlap.

Review the following solutions:

Review these related resources:

Architecture

This architecture shows Oracle Exadata Database Service on Oracle Database@AWS in a disaster recovery topology using two standby databases:
  • A local standby in the same region as the primary but in a different availability zone.
  • A remote standby in a different region.

Description of exadb-dbaws-dr-arch.png follows
Description of the illustration exadb-dbaws-dr-arch.png

exadb-dbaws-dr-arch-oracle.zip

Oracle Database runs in an Exadata VM cluster in the primary Region 1. For data protection and disaster recovery, Active Data Guard replicates the data to the following two Exadata VM clusters:

  • One in the same region but in a different availability zone (local standby). A local standby is ideal for failover scenarios, offering zero data loss for local failures while applications continue to operate without the performance overhead of communicating with a remote region.
  • A second standby in a different region (remote standby). A remote standby is typically used for disaster recovery or to offload read-only workloads.

Although Active Data Guard network traffic can traverse the AWS backbone, Oracle recommends this architecture which routes it over OCI for optimized throughput and latency.

The Oracle Exadata Database Service on Oracle Database@AWS 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 VCNs in different regions. Because only one DRG is allowed per VCN in OCI, a second VCN with its own DRG is required to connect the primary and standby VCNs in each region.

  • The primary Exadata VM cluster is deployed in Region 1, availability zone 1 in VCN1 with CIDR 10.10.0.0/16 and client subnet CIDR 10.10.1.0/24.
  • VCN1 has Local Peering Gateways (LPGs) LPG1 remote and LPG1 local.
  • The Hub VCN in the primary Region 1 is Hub VCN1 with CIDR 10.11.0.0/16.
  • The first standby Exadata VM Cluster is deployed in Region 1, availability zone 2 in VCN2 with CIDR 10.20.0.0/16 and client subnet CIDR 10.20.1.0/24.
  • VCN2 has two LPGs LPG2 remote and LPG2 local.
  • The Hub VCN is the same as the Hub VCN for the Primary database, Hub VCN1 as it resides in the same region.
  • Hub VCN1 has LPG Hub LPG1 and Hub LPG2 and DRG1.
  • The second standby Exadata VM cluster is deployed in Region 2 in VCN3 with CIDR 10.30.0.0/16 and client subnet CIDR 10.30.1.0/24.
  • VCN3 has a LPG LPG3 remote.
  • The Hub VCN in the remote standby Region 2 is Hub VCN3 with CIDR 10.33.0.0/16.
  • Hub VCN3 has a LPG Hub LPG3 and DRG DRG3.
  • No subnet is required for the hub VCNs to enable transit routing. Therefore, these VCNs can use very small IP CIDR ranges.

This architecture supports the following components:

  • AWS region

    AWS regions are separate geographic areas. They consist of multiple, physically separated, and isolated availability zones that are connected with low latency, high throughput, highly redundant networking.

  • AWS availability zone

    Availability zones are highly available data centers within each AWS region.

  • OCI virtual cloud network and subnet

    A virtual cloud network (VCN) is a customizable, software-defined network that you set up in an OCI region. Like traditional data center networks, VCNs give you control over your network environment. A VCN can have multiple non-overlapping classless inter-domain routing (CIDR) blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Network security group (NSG)

    NSGs act as virtual firewalls for your cloud resources. With the zero-trust security model of OCI you control the network traffic inside a VCN. An NSG consists of a set of ingress and egress security rules that apply to only a specified set of virtual network interface cards (VNICs) in a single VCN.

  • Local peering

    Local peering allows two VCNs within the same OCI region to communicate directly using private IP addresses. This communication does not traverse the internet or your on-premises network. Local peering is enabled by a Local Peering Gateway (LPG), which serves as the connection point between VCNs. Configure an LPG in each VCN and establish a peering relationship to allow instances, load balancers, and other resources in one VCN to securely access resources in another VCN within the same region.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another OCI region, an on-premises network, or a network in another cloud provider.

  • Remote peering

    Remote peering enables private communication between resources in different VCNs, which can be located in the same or different OCI regions. Each VCN uses its own Dynamic Routing Gateway (DRG) for remote peering. The DRGs securely route traffic between the VCNs over OCI's private backbone, allowing resources to communicate using private IP addresses without routing traffic over the internet or through on-premises networks. Remote peering removes the need for internet gateways or public IP addresses for instances that need to connect across regions.

  • Oracle Exadata Database Service on Dedicated Infrastructure

    Oracle Exadata Database Service on Dedicated Infrastructure enables you to leverage the power of Exadata in the cloud. Oracle Exadata Database Service delivers proven Oracle AI Database capabilities on purpose-built, optimized Oracle Exadata infrastructure in the public cloud. Built-in cloud automation, elastic resource scaling, security, and fast performance for all Oracle AI Database workloads helps you simplify management and reduce costs.

  • Oracle Data Guard

    Oracle Data Guard and Active Data Guard provide a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases and that enable production Oracle databases to remain available without interruption. Oracle Data Guard maintains these standby databases as copies of the production database by using in-memory replication. If the production database becomes unavailable due to a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Oracle Active Data Guard provides the additional ability to offload read-mostly workloads to standby databases and also provides advanced data protection features.

Recommendations

Use the following recommendations as a starting point when performing disaster recovery for Oracle Exadata Database Service on Oracle Database@AWS. 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 to offload the workload to standby with read-mostly scale-out.
  • Enable Application Continuity to mask database outages during planned and unplanned events from end-users.
  • Configure automatic backups to Oracle Database Autonomous Recovery Service in OCI. Although data is protected by Oracle Data Guard, minimize the backup workload on the database by implementing the incremental-forever backup strategy that eliminates weekly full backups. Alternatively, use Amazon Simple Storage Service for automatic backups.
  • Run backups from standby to achieve cross-region backup replication.
  • Use OCI Full Stack DR to orchestrate database switchover and failover operations.
  • Store the database's Transparent Data Encryption (TDE) keys in OCI Vault with customer-managed keys.

Considerations

When performing local and regional disaster recovery for Oracle Exadata Database Service on Oracle Database@AWS, consider the following:

  • When Exadata VM clusters are created in the Oracle Database@AWS child site, each Exadata VM cluster is provisioned in its own OCI VCN. Peer the VCNs and avoid overlapping CIDRs and ensure that the databases communicate with each other so that Data Guard can ship redo data.
  • Cross‑region latency is typically too high for synchronous transport in mission-critical applications. Hence, use Data Guard ASYNC replication across regions. Add Active Data Guard Far Sync to ensure zero data loss across regions.
  • Configure OCI as the preferred network for better performance, lower latency, higher throughput, and reduced cost; the first 10 TB/month of data egress is free across regions.
  • You can create up to six standby databases per primary using cloud tooling.

About Required Services and Roles

This solution requires the following services and roles:

  • Oracle Cloud Infrastructure Networking
  • Oracle Exadata Database Service

These are the roles needed for each service.

Service Name: Role Required to...
Oracle Exadata Database Service: manage database-family Manage the database, including adding and operating Active Data Guard deployments
OCI Networking: manage vcn-family Manage the network components, including VCNs, subnets, security rules, and VCN peering

See Oracle Products, Solutions, and Services to get what you need.