Disaster Recovery Plan for Oracle Analytics Cloud using Manual Switchover Method

January 23, 2023 | 9 minute read
Bala Viswanath Guddeti
Principal Analytics Cloud Solution Technologist
Text Size 100%:

Introduction:

 

A well-architected Disaster Recovery (DR) plan enables you to recover quickly from disasters and continue to provide services to your users.

DR is the process of preparing for and recovering from a disaster. A disaster can be any event that puts your applications at risk, from network outages to equipment and application failures to natural disasters.

Oracle Analytics Cloud is a scalable and secure public cloud service that provides capabilities to explore and perform collaborative analytics for you, your workgroup, and your enterprise. OAC is available on Oracle Cloud Infrastructure Gen 2 in several regions in North America, EMEA, APAC, and LAD.

With respect to OAC, the Availability Service Level Agreement Oracle will use commercially reasonable efforts to have each such Service available with a Monthly Uptime Percentage (as defined below) of at least 99.9% during any calendar month (the “Service Commitment”). Refer The Oracle PaaS and IaaS Public Cloud Services - Pillar document provides information about Oracle Cloud Service continuity policy and service level agreements. Despite having SLA on OAC Availability, you are responsible for DR planning to provide services to your OAC users.

This post provides you reference architecture and Recovery Guidelines for OAC instance in case of DR using Manual Switchover method.

Acronyms:

DR

Disaster Recovery

RTO

Recovery Time Objective

RPO

Recovery Point Objective

OAC

Oracle Analytics Cloud

RPD

Unknown - the file storing the semantic data model.

ADW

Autonomous Data Warehouse

DB

Oracle Database

LBR

load balancer

DNS

Domain Name System

 

Assumptions:

 

This post assumes the following is in place:

Item

Notes

Data Source

Your data sources already having certain DR procedures, for example Databases synchronized using Oracle Data Guard.

Vanity URL

You have prerequisites for Vanity URL, such as custom domain and certificates.

Decision on RPO & RTO

You have ready Business Decision on DR Timelines for Recovery Point Objective (RPO) and Recovery Time Objective (RTO). For example RPO 24 hours and RTO 2 hours.

Decision on Region

You have Business Decision Multi Region DR setup or Single region DR setup. For example Ashburn Region will have Primary OAC Private Instance and Secondary (Failover) instance will be on Pause mode in Phoenix Region.

Configurations

The following configurations in the primary and Secondary instance need to synchronize based on your Change Management process. As they will not be carried on the snapshot backup.

  • Virus scanner configuration
  • Mail server configuration
  • Other saved snapshots in the source environment
  • Users (and groups)
  • Identity management configuration (example SSO)
  • Network configuration

DB Connection

Your RPD DB connection to the Primary and Secondary Databases should be the same

 

Solution:

The first step in planning for DR involves determining the recovery time objective (RTO) and recovery point objective (RPO).

The RTO is the target time within which a given application must be restored after a disaster occurs. Typically, the more critical the application, the lower the RTO.

The RPO is the period after a disaster occurs for which an application can tolerate lost data before the disaster begins to affect the business.

To build a plan that guarantees the recovery of your applications after a disaster and is cost effective, you must consider both the target time to recover and the tolerance for data loss.

Physical Architecture:

The following architecture provides a high-level overview of DR plan.

OACPrivate-x-region-DR-topology

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Sample Physical Architecture using Manual DR Method.

 

In the figure above, the OAC instances deployed on the Private Subnet for security.  Pubic LBR will facilitate the communication to the internet.  You are free to use Public OAC instances, in this case you can avoid Public LBRs. You can also ensure failover by configuring redundancy in the database tier (Oracle Data Guard recommended). You can download Reference Architecture from Oracle Architecture Center.

 

Benefits of the Architecture:

  • You can access OAC Private Instance over the Internet Securely.
  • You can save substantial costs approximately 80% on the Secondary Instance. As it can be in pause mode, contact sales for pricing details.
  • Your secondary instance will patched and maintained by Oracle even in pause mode.   
  • You can access OAC Primary and Secondary instances with the same URL.

High Level Steps:

  1. Create OAC Instance in Region-1
  2. Configure the Vanity URL
  3. Create Public load balancer 
  4. Repeat the same steps in Region-2

Detailed Steps:

Primary Instance:

  1. Create Private OAC instance in Region-1
  2. Configure the Vanity URL
  3. Create Public load balancer 

In Private subnet Security list - Add Ingress rules to allow TCP traffic to port: 443,
Source: Subnet CIDR Range of your LBR, port 443

In Public Subnet Security list-, Add Ingress rules to allow requests from Internet to port 443

For the Public LBR, Add OAC instance as backend set

Update the health check as follows

Edit the Listener with Protocol and port

At the LBR side, upload the SSL Certificates that you obtained for Vanity URL

At DNS Server side, add the Public load balancer IP in the DNS server with type A record.