Disaster Recovery of Oracle Analytics Server on Oracle Cloud using OCI Full Stack Disaster Recovery

May 27, 2024 | 11 minute read
Veera Raghavendra Rao Koka
Consulting Member of Technical Staff
Text Size 100%:

REDWOOD

An earlier blog post discussed how to implement Oracle Analytics Server (OAS) disaster recovery on Oracle Cloud Infrastructure (OCI) through snapshot replication.

Oracle launched a disaster recovery feature in OCI, called Full Stack Disaster Recovery (Full Stack DR). This feature orchestrates the transition of compute, database, and applications between OCI regions from around the globe, with a single click. You can automate the steps needed to recover one or more business systems without redesigning or rearchitecting existing infrastructure, databases, or applications.

This blog discusses how to configure OAS disaster recovery on OCI using Full Stack DR, Oracle Database Cloud Service (DBCS) Repository Creation Utility (RCU) schemas replication, and other noteworthy features of OCI, such as block volume.

Architecture

This diagram illustrates Full Stack Disaster Recovery deployment architecture for Oracle Analytics Server.

oas dr fsdr

 

Full Stack Disaster Recovery

Refer to the Full Stack DR documentation for more information and to understand the terminology. See Overview of Full Stack Disaster Recovery and Full Stack Disaster Recovery Terminology.

You can also refer to the Oracle Analytics Cloud Full Stack DR deployment documentation to learn about Full Stack DR, how it works, and Full Stack DR terminology. See Oracle Analytics Cloud Disaster Recovery automation using the OCI Full Stack Disaster Recovery.

With Full Stack DR, you can manage Oracle Analytics Server disaster recovery (DR) from one OCI region to another on Oracle Cloud.

There are two DR models for OAS DR.

  • Cold Standby: A DR model in which very few or none of the components of the OAS secondary environment need to be pre-deployed in the standby region in preparation for a future DR transition. The OAS secondary environment is deployed as part of the DR transition. This model involves lower operating costs but a higher RTO.
  • Warm Standby: A DR model in which all of the components of the OAS secondary environment are pre-deployed in the standby region to prepare for a future DR transition. This model involves higher operating costs but a lower RTO.

For Cold Standby, you must create the Standby Oracle DBCS and Oracle ADW instances using Data Guard in the OCI secondary region before Full Stack DR plan execution. Also, some components like VCN with the Subnets, Security Rules, and Network Security Groups must be configured for the OCI secondary region in the existing compartment created for the primary region.

During the Full Stack DR plan execution, Full Stack DR orchestrates the primary Oracle DBCS and Oracle ADW switchover to standby, creates new compute instances for OAS, and starts OAS by calling the respective start-up scripts on the OAS compute VMs. The rest of the components are created at the DR plan execution time, hence the higher RTO.

For Warm Standby, you must create all the components (Oracle DBCS, Oracle ADW, VCN, Subnets, Security Rules, Network Security Groups, OAS Compute Instances, and Block Volumes) and attach them to the compute instances and load balancer (all components that OAS DR requires) before Full Stack DR plan execution.

During the Full Stack DR plan execution, Full Stack DR orchestrates the primary Oracle DBCS and Oracle ADW switchover to standby and starts all required compute instances and OAS by calling the respective start-up scripts on the OAS compute VMs. It also maps the load balancer IP address to the required DNS Name (in the future release of Full Stack DR). As the components are created before the DR plan execution, it results in a lower RTO.

Refer to these blogs to configure the DR environment,

NOTE: If your Oracle DBCS and Oracle ADW don’t have common connection strings between the primary and standby, you may need to create a script to change the connection strings in the backend OAS VM files.

Deploy Oracle Analytics Server on Oracle Cloud for Full Stack Disaster Recovery

Cold Standby Approach

Subscribe to Secondary OCI Region (Phoenix)

This example shows subscriptions to two regions in the OCI tenancy: Ashburn and Phoenix

oas fsdr

Create an Oracle Database Cloud Service Pluggable Database

You can use an Oracle Database Cloud Service (DBCS) in OCI for the RCU schemas for Oracle Analytics Server.

Create the primary Oracle DBCS pluggable database in the primary OCI region for the OAS's RCU schemas and configure a standby using the Data Guard.

Download the document Create Primary and Standby DBCS to Create RCU Schemas for OAS DR.pdf and follow the steps.

Download

Deploy Oracle Analytics Server on Oracle Cloud

You can deploy OAS on Oracle Cloud in two ways:

Follow these steps to scale out the OAS server for high availability:

  • On the first OAS node, install the software and configure (create the domain).
  • On the second OAS node, only install the software.

For more information, read the blog Scale Out Oracle Analytics Server on Oracle Cloud and On-Premises. This blog uses OAS Server node1 as the NFS Server and mounts the shared folder to both nodes as /sdd/bidata.

This blog uses OCI File System Storage to mount the export path to both OAS nodes as /sdd.

Set Up Primary Oracle Analytics Server Environment with Block Volume and File System

Download the document Set Up Primary Oracle Analytics Server Environment for Disaster Recovery Managed by OCI Full Stack Disaster Recovery.pdf . This document contains detailed steps to create an OAS primary environment with Block Volume and File System attached and mounted to the OAS compute instances.

Download

On the OCI Home Region (Ashburn)

Create an OAS Instance

  • Create an OAS instance with the domain in the Private Subnet of the VCN.

Note: Scale out OAS if you require a cluster environment. Skip the scale-out tasks if high availability isn't required.

Create a Block Volume, File System and Attach to the OAS Compute Instance

  • OAS instance on OCI Marketplace is created with boot volume by default.
  • Create a block volume in OCI Console and attach it to the OAS compute instance.
  • Restart the OAS compute VMs. Verify the attachment succeeded and OAS works correctly.

Note: If you want to continue with the boot volume and don’t want to use block volume, skip the block volume tasks.

Note: If you want to continue with the OAS node as an NFS server, skip the file system creation and attaching tasks.

Create an OCI Load Balancer

Configure an OCI Load Balancer for the OAS cluster environment. For more information, read the blog SSL Offloading at Oracle Cloud Infrastructure (OCI) Load Balancer for Oracle Analytics Server on Oracle Cloud Marketplace.

Configure Mail Settings

Configure the Data Source, Create Analyses, and Data Visualizations

  • The data source can be an on-premises Oracle Database, or an Oracle ADW or Oracle DBCS on OCI.
  • If your data source is an on-premises Oracle Database, ensure it's reachable from all the OCI regions, VCN, and private subnets.
  • Configure the RCU DBCS and the data source Oracle ADW to have the same connection strings between the primary and standby databases. Refer to the technical paper Disaster Recovery Configuration for Oracle Analytics Cloud section "Oracle Autonomous Data Warehouse as a Data Source and Oracle Database Cloud Service as a Data Source" on pages 22 to 34.

On the OCI Secondary Region (Phoenix)

Create a VCN

  • Create a Virtual Cloud Network (VCN), Subnets, and Security Rules or Network Groups in the same compartment you created for the primary region.
  • Configure the standby Oracle DBCS or Oracle ADW instance with the same connection strings.

Create a Standby Instance for DBCS and ADW

Follow the technical paper Disaster Recovery Configuration for Oracle Analytics Cloud to create a standby instance for Oracle ADW and Oracle DBCS.

Prerequisites for Full Stack DR

  • Based on your environment's components and resources, create an IAM policy with all the required access and permissions to the OCI components and resources for Full Stack DR.
  • Configure Oracle ADW for standby in the OCI DR (secondary) region using the Autonomous Data Guard.
  • Configure Oracle DBCS for standby in the OCI DR (secondary) region using the Data Guard.
  • Create a secret in an OCI vault as Full Stack DR reads the Oracle DBCS admin password from a secret in both OCI regions.
  • Create a bucket to store Full Stack DR logs in both OCI regions.
  • Ensure the block volume and file system mount instructions exist in each OAS compute node's/etc/fstab file.
  • Create a volume group with all the required block and boot volumes of the OAS Compute nodes.
  • Replicate the volume group to the OCI DR (secondary) region.
  • Replicate the file system to the OCI DR (secondary) region.
  • Create ingress and egress security rules to access the file system in the private subnet used for OAS and file system in the primary OCI region.
  • Configure the load balancer as the front end for the OAS Compute nodes in the OCI primary region.
  • In the OCI DR (secondary) region, configure a load balancer with the same SSL certificates, listener, hostname, rule sets, and so on, as the primary load balancer, except for the backends.
  • During the DR plan execution, the load balancer backends, that is, the OAS compute instances, are removed from the primary region load balancer Once OAS compute instances are created in the secondary region, they get added to the secondary region load balancer as backends.

This blog describes the Cold Standby or Moving Resources scenario.

OCI components involved in the Full Stack DR Cold Standby approach are as follows:

OAS_FSDR_Table

Upon failover, Full Stack DR moves the OAS compute VMs, block volumes, and file systems from the primary region to the DR region. Similarly, Full Stack DR switches over resources and components from the DR region to the primary region.

NOTE: In a non-moving scenario (Warm Standby), all resources and components must exist in both regions and be configured before the Full Stack DR execution. Full Stack DR only orchestrates the switchover of the Oracle ADW and Oracle DBCS and starts the OAS compute VMs and the OAS application to make the DR region resources available to end users.

For more details on Full Stack Disaster Recovery configuration and executing the DR Plan, download the document and follow the detailed steps in the section: Step-by-Step Instructions to prepare for OCI Full Stack Disaster Recovery.

Key Points

When switching from primary to secondary, always create the DR plan and execute it from the secondary OCI region.

When falling back from secondary to primary, always create the DR plan and execute it from the primary OCI region.

Step-by-Step Instructions to Prepare for OCI Full Stack Disaster Recovery

Download the document Step-by-Step Instructions to Prepare for OCI Full Stack Disaster Recovery.pdf. This document describes how to create a DR Protection Group and execute a DR plan. Follow the same steps for switchover or failover and DR drill. Also follow the same for fallback.

Download

OAS DR Testing

  • To test disaster recovery, you might need to simulate it. For example, you might need to initiate a switchover or failover Full Stack DR operation.
  • Map the DR load balancer IP address to the required DNS Name.
  • If your RCU DBCS connection strings differ across regions, you might need to modify each RCU schema data source jdbc.xml file to point to the right connection string.
  • Also, you might need to:
    • Modify the jps-config.xml file.
    • Exclude certain RCU DB files from replication between the volumes.
  • Refer to the Oracle Support document, How To Change Your Oracle Analytics Connections When You Have Moved Your RCU Database To A New Host (Doc ID 2802991.1).

Call to Action

Instead of using cross-region block volume replication for OAS file system Sync or RSync and FPSync to copy files from region to region, use the OCI Full Stack Disaster Recovery feature to orchestrate the Disaster Recovery of the OAS environment.

Since all the steps and tasks are covered in this blog (and the attached whitepapers), you can try it yourself and let us know in the Oracle Analytics Community.

If you have questions, post them in the Oracle Analytics Community and we'll follow up with answers.

REDWOOD

 

Veera Raghavendra Rao Koka

Consulting Member of Technical Staff

Oracle Analytics Service Excellence, CEAL Team


Previous Post

Usage Insights for Oracle Analytics Cloud using OCI Logging

Srinivasa Pula | 8 min read

Next Post


Create Catalog Permission Reports for Oracle Analytics Cloud using REST APIs