Learn About Deploying a Multicloud Disaster Recovery Topology by Using Oracle Database Service for Azure

Maintaining business continuity and ensuring IT resiliency is a top priority for IT leaders today. Enterprises from every sector and industry are increasingly implementing multicloud solutions to benefit from best-in-class services, competitive pricing, agility, flexibility, and higher availability while enhancing risk management and avoiding vendor lock-in. Oracle Database Service for Microsoft Azure (OracleDB for Azure or ODSA) is an Oracle-managed service that enables customers to easily provision, access, and operate enterprise-grade Oracle Database Services in Oracle Cloud Infrastructure (OCI) with a familiar Azure-like experience.
At this moment it is not possible to Enable a Data Guard for Disaster Recovery directly from the OracleDB for Azure portal. However, the Cross-region Data Guard setup can be configured using the following options:
  • Manual Data Guard setup between two OracleDB for Azure databases.
  • OCI Managed Data Guard with one OracleDB for Azure database and one OCI Managed database.

This document provides details to configure a manual Data Guard setup between two OracleDB for Azure databases across different cloud regions. For a general overview of this solution, see "ODSA disaster recovery best practices: Exadata Database and Base Database services", which you can access from the "Explore More" topic at the end of the playbook.

Architecture

This architecture shows a Data Guard configuration across regions in OracleDB for Azure. Standby databases across regions ensure disaster recovery and higher resiliency in the event of a disaster. Oracle Data Guard enables you to quickly restore your workload to the standby database.

The following diagram shows the Data Guard configuration. Disaster recovery in OracleDB for Azure configuration consists of a production database and a DR copy in OCI provisioned from OracleDB for Azure portal. Disaster Recovery in OracleDB for Azure eliminates the costs and complexity of third-party vendors and Interconnect to manage the network in Multicloud OracleDB for Azure.

This document emulates a disaster recovery scenario in OracleDB for Azure environment. This can be used for demos, POCs, and workshops in conceptualizing the integrity and safety of the data in case of a disaster in a Multicloud environment. This document does not in any way supersede any existing whitepapers referenced in the documentation, it only builds on them.

This document focuses on setting up a disaster recovery in a multicloud OracleDB for Azure environment. However, the databases and disaster management will have to be configured and managed from the command line by using the SQL*Plus or DGMGRL command line tool until the Data Guard association is incorporated directly from OracleDB for Azure portal.


Description of odsa-dr-ref-arch.png follows
Description of the illustration odsa-dr-ref-arch.png

This architecture has the following components:
  • Region

    An Oracle Cloud Infrastructure region or an Azure region is a localized geographic area that contains one or more data centers, called availability domains (in OCI) or availability zones (in Azure). Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domain (OCI) / Availability Zone (Azure)

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • OCI Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping 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.

  • Dynamic routing gateway (DRG)

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

  • Oracle Database Service for Microsoft Azure

    Oracle Database Service for Microsoft Azure (OracleDB for Azure) allows you to easily integrate Oracle Cloud Infrastructure Database into your Azure cloud environment. OracleDB for Azure uses a service-based approach and is an alternative to manually creating complex cross-cloud deployments for your application stacks.

  • Oracle Database

    The architecture includes two Oracle databases provisioned through OracleDB for Azure.

    One of the remote databases is converted as a standby database in the Data Guard configuration. The standby database is a transactionally consistent copy of the primary database. Oracle Data Guard automatically maintains synchronization between the databases by transmitting and applying redo data from the primary database to the standby. In the event of a disaster in the primary region, Oracle Data Guard automatically fails over to the standby database when Fast-Start Failover is enabled.

  • Password wallet

    Oracle wallet provides an easy method to manage database credentials across multiple domains. It allows you to update database credentials by updating the wallet instead of having to change individual data source definitions.

  • OracleDB for Azure Multicloud Link

    A multicloud link is established between an OCI account and an Azure account to deploy the Oracle Database service in OCI and an application in Azure. To perform basic database and infrastructure management tasks, you use the OracleDB for Azure portal, which is an OCI interface with an Azure-like user experience. In the Azure portal, you can view database metrics and events. Metrics appear in Azure Application Insights, while events appear in Azure Log Analytics.

  • OracleDB for Azure Network Link

    A network link is created using Oracle Interconnect for Microsoft Azure, a high-performance, low-latency, low-jitter private tunnel connection for network traffic between OCI and Azure. Oracle has partnered with Azure to offer this connection in a designated set of OCI regions located around the world. When you sign up for OracleDB for Azure, the service configures the private connection to your database resources as part of the account linking process.

  • Azure VNet

    Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure virtual machines (VM), to securely communicate with each other, the internet, and on-premises networks.

Considerations for Deploying the Topology

Before configuring the OracleDB for Azure DR topology, gather the information that you'll need to set up the standby database. To set up this database, you need to do the following:

  1. Determine the size and CIDR block of the virtual cloud network (VCN) that you want to create, and the DNS label of the VCN for Primary and Standby in OCI. See Allowed VCN Size and Address Ranges.
  2. Determine the size and CIDR block of the virtual network (VNet) that you want to create, and the DNS label of the VNet for primary and standby databases in Azure.
  3. Determine the compute shapes to be used for the Azure VM and the VM DB system.
  4. Verify that the service limits of your tenancy can accommodate all the resources that you want to create.
  5. Determine the DB VM system display names of primary and standby databases.
  6. Determine the DB Unique names of primary and standby databases.
  7. Ensure that the name of both the databases provisioned in OracleDB for Azure are the same.
  8. Obtain the DB admin password for your database.
  9. Save the path to the public SSH key.
  10. Save the path to the private SSH key.

Understand Roles and Services

These are the services, and their associated roles, required for this solution:

Meet Deployment Prerequisites

Before attempting the steps in this playbook, you need to meet the following prerequisites.

Note:

Links to the resources listed below are available in the "Explore More" topic, at the end of this playbook.
  • Because the scenario in this playbook is specific to ODSA, you need to sign up for Oracle Database for Azure Portal.

    For instructions, see “Oracle Database Service for Azure sign up”.

  • Create Azure VNet and virtual machines in region 1 and region 2, then secure connectivity by allowing/whitelisting required IPs/ports from VNet. For more information, see the following Azure documentation:
    • Virtual Network documentation
    • Virtual machines in Azure
    • Linux on Azure
  • Create base database systems in Oracle Database Service for Azure. Create both databases with the same database name and instance name. Choose the same database version and edition for both databases.
    • Create a database from Oracle Database Service for Azure in region 1 (for example, UK South), which will be the primary.
    • Create a database from Oracle Database Service for Azure in region 2 (for example, Europe West), which will be the standby.
    Ensure that both databases are linked with the corresponding VNet from the Azure side.
  • Refer to the documentation for the necessary steps to create a database system in Oracle Database Service for Azure, depending on your requirements. For more information, see "Provisioning a Base Database".
  • Because Oracle DataGuard is a ctritical component of this solution, you should have some experience with it.