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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

 

** Check DNS propagation using DNS Checker

Once DNS updated, Login to analytics using the Vanity URL.

• Open any browser; Go to Developer Tools; Select Network tab
• Make sure you are out of VPN while testing 
• Refresh the browser to see the network headers
• You will find the Public load balancer IP Address.

 

When you pause the Primary instance or switchover to Secondary instance, you can validate the Public LBR IP address has updated correctly or not.

Secondary Instance:

1. Create Private OAC instance in Region-2
2. Configure a Vanity URL
3. Create Public load balancer (Follow the same steps detailed for Primary Instance)

• For testing, you can pause Primary instance in Region-1, add the Region-2 Public LBR IP in the DNS server as type A record
• Test accessing OAC using the same Vanity URL
• After testing is completed, revert the changes at DNS server level to point to IP Address of Region1 Public LBR IP 
• Pause the Region2 OAC instance, and Resume Region 1 primary OAC instance, See Pause and Resume a Service.

Snapshot Backup:

Oracle recommends that you take snapshots at significant checkpoints, for example, before you make a major change to your content or environment. In addition, Oracle recommends that you take regular weekly snapshots or at your own defined frequency based on the rate of change of your environment and rollback requirements or RPO timelines. You advised to keep the Snapshot files on the Object Storage.

Manual Method:

• Take Snapshots and Restore.

REST API Method:

• Snapshot API
• Download Reference Scripts from Github

Recovery Guidelines:

When an unforeseen disaster happens, follow the steps below.

• Manually update the IP address at the DNS side A record value with your Secondary Public LBR IP address
• Resume the Secondary OAC instance from Region-2.
• Restore the Snapshots from the Object Storage to OAC Secondary Instance
• Test the Vanity URL. Your OAC system is ready for use!

Summary:

DR practices are a key to have resilient business continuity for OAC instances.  The combination of OCI techniques and processes will help you to achieve the RPO 24 hours and RTO 2 hours

Refer for more information,

Reference Architecture: Design a disaster recovery topology for Oracle Analytics Cloud

Technical Paper: Disaster Recovery Configuration for Oracle Analytics Cloud

 

Administering Oracle Analytics Cloud on Oracle Cloud Infrastructure (Gen 2)