OCI Full Stack DR

Disaster Recovery (DR) setup plays a crucial role in real-time environments, as it is essential for business continuity. Whether disasters occur due to nature or human mistakes, organizations proactively prepare with a disaster setup before deploying their production systems.

Cloud service providers (CSPs) have recognized the significance of DR setup and have taken it seriously. They have introduced managed services for efficiently provisioning and maintaining DR setups. Moreover, some CSPs offer options to automate the creation of DR setups and also take care of the ongoing management of the DR environment.

Generally, when we refer to DR, the focus is more often on data replication to different locations. However, relying solely on data replication may not be sufficient to ensure seamless business operations during a disaster. While data is a critical aspect, it is equally important to have applications up and running at the disaster location, along with other dependent processes fully functional. This implies that, in addition to data, other essential resources must also be available at the disaster site.

Cloud environments are meticulously designed with networking, compute, storage, and other crucial components. Considering the significance of DR setup, the replicated environment, which could be located in a different region, must maintain a similar architecture to the source environment, with minimal changes to capacity. The DR environment should encompass all the necessary resources to seamlessly run the complete stack of the source environment. To achieve this, the answer lies in Full Stack DR, a comprehensive solution available in OCI (Oracle Cloud Infrastructure).

Full Stack DR is an Oracle Native DRaaS (Disaster Recovery As a Service) solution designed to orchestrate DR operations like Switchover and Failover in OCI with a single click of a button. Full Stack DR can be used for both inter and intra region OCI resources. Oracle recommends using inter regions for better DR capabilities.

How it Works

1) First decide target region to have DR. Ensure that OCI Full Stack DR service is available at source and target regions.

2) Choose resources that need to be become part of Full Stack DR. Within a tenancy there could be resources created for Dev and Production environments. List out the resources that needs DR services.

3) Create Protection groups at Source and Target region.

4) Associate the protection groups.

5) At the source side add the chosen resources to Full Stack DR as member.

6) Create switchover or Failover plan in Full Stack DR.

7) Customize the switchover or failover plan, depending on the application requirement with additional steps.

8) Execute pre-checks of the DR plan.

9) Execute the DR plan.

Let see in action

1. Login into OCI portal and choose source region. Click Migration & Disaster Recovery -> Disaster Recovery.\

2. Click Create DR Protection Group

3. Provide a name and choose compartment to create Protection groups. Object storage bucket to be provided to store logs of Full Stack DR. Leave the role as Not configured. It can be configured after creating Protection group at Standby region. Member also can be added later.

4. Repeat the same step at DR/Standby region to create Protection group .

5. At this stage we have Protection group at primary and standby region. In the Primary Protection group, click Associate button and provide standby region and protection group details to configure primary and standby roles.

At this stage Primary and Standby role has been defined in Full Stack DR.

6. Now its time to add members at Primary side that needs to be part of DR operations.

7. We can add members by choosing their resource type.

Compute, Autonomous database, Oracle Base Database (DBCS), Oracle ExaCS DB and Volume group can be added as member.

Based on chosen resource type further details will be collected.

Once the member is added at primary, it will be listed. In this example we have added compute instance and its associated boot volume group as member.

8. The next step is creating Switchover/Failover plan. It needs to be done from Target/Standby region. Choose Plan type wither Failover or Switchover and create the plan.

Click the plan after creation. It will list out the steps that will be carried for executing this plan.

In this example we could see steps that executed part of switchover. Each step in the plan is called as group and each group could have sub set of activities to perform that particular step.

We can update steps in the group.

We can modify the timeout parameter and Error more (whether we want to stop or continue if we face some error).

9. The beauty of this plan group is that it has flexibility to incorporate new groups (user defined steps) during execution. User-defined tasks can be added as groups, such as notifying users about the switchover/failover or initiating specific services (Web server, Database server) at the time of switchover/failover. Custom scripts can be created to execute these desired functionalities and integrated into the step.

Click Add group button

Click Add Step button

The group step collects details about name, error code and timeout value. The execution script for this step can be provided via Object storage or specify the script located in some server or invoke a function to perform desired functionality.

For Run Local Script, it will query the server having the script, its location and the user to execute the script.

10. Once all the required steps are added into the plan, we can check integrity of this plan by executing prechecks.

Success of Prechecks gives the guarantee that real time execution will go without any issues and also we get to know time taken at each step to execute.

11. To perform the real switchover/failover click Execute DR plan button. It will perform actual steps execution.

We could see output same like prechecks.

Failover also can be done on the same way. We could invoke Switchover/Failover through portal.

Key Advantages:

1. Full stack DR creation is very simple and it doesn’t require any expertise.
2. Switchover/Failover can be invoked with few clicks.
3. Prechecks can be executed anytime. The success of prechecks execution guarantess that all prerequisites to perform switchover/failover in place.
4. It can incorporate the existing DR setups. It doesn’t demand any changes in the existing DR setup.