Playing with the new OCI Full Stack DR – Part 1 – Preparing the Environment

I am very happy to announce the GA of the new Oracle Cloud Infrastructure (OCI) solution that the Oracle MAA team has been working very hard to bring to you (Thank you, Suraj Ramesh).

Today we will play with the new, Full Stack DR it is a fully managed OCI disaster recovery orchestration and management service that provides comprehensive disaster recovery capabilities for all layers of an application stack, including infrastructure, middleware, database, and application across  OCI regions.

This tutorial will use the new Full Stack DR solution to:

• Achieve a comprehensive business continuity from a variety of data center outages. Using a Disaster Recovery Service for disaster recovery ensures that organizations are minimally impacted if there is a region-wide outage or Availability Domain outage.
• Provides fully automated, end-to-end disaster recovery for the entire Oracle stack, including infrastructure, databases, engineered systems, virtual infrastructure, storage, and full-stack applications in OCI. It integrates with underlying replication mechanisms that synchronize primary and standby environments and protects mission-critical data.
• Provide flexibility and integration with various Oracle platforms and non-Oracle applications and infrastructure. It generates, runs, and monitors disaster recovery plans for services and applications deployed in your tenancy. Disaster recovery operations are at the service level, so there is no impact on running other services in your tenancy. You can customize the disaster recovery plans generated by Full Stack DR based on your specific needs.

Before we start, let’s take a closer look at some benefits of using FSDR.

The Tutorial

In this tutorial (you can access this same tutorial and play with it for free at LiveLabs here), we will see how easily Full Stack DR can be used to orchestrate DR switchover operations for a Cloud-native Application deployed in OCI across two OCI regions. For this, we will:

• Use the MuShop application and its underlying resources to perform the Switchover operations across regions. The MuShop is a demo application purpose-built to showcase interoperable various cloud services on Oracle Cloud Infrastructure. The premise of MuShop is an e-commerce website offering a variety of cat products, and it is a 3-tier web application.

The Environment

Below you can find the architecture used for this tutorial.

• Ashburn is the Primary region, and Phoenix is the Standby region.

Time to Play

Now it is time to have some fun. Let’s start by login into OCI Console to prepare the environment, first, check if the region in use is Ashburn (1), if not, please change it to Ashburn, then click at the hamburger menu at the top left corner of your screen and select Compute (2) and finally, click at Instances (3).

Now at the compartment tab (as per the image below) select the compartment assigned to you as per the login details page (Expand the root compartment, then click on the Livelabs compartment, and then select the compartment assigned to you). You will see the two VMs for this tutorial.

Next, open the Cloud Shell by using the icon next to the region (1). The prompt window would open at the bottom of the page after a few seconds (2).

The next step would be to duplicate the OCI tab in the browser, leaving the one with the Cloud Shell to be used later. In the new tab, Click on the hamburger menu on the top left corner of the screen, then select Oracle Database (1), then Autonomous Processing (ATP) (2) and remember to select the compartment assigned (3) to you and click at the display name of the Autonomous Processing Database (ATP) (4) available for you (MuShopDB-XXXX).

At the ATP Page, copy the OCID used at the previously opened tab with the Cloud Shell open.

Make sure to replace the example OCID (in red below) on this example for your own before executing it.

oci db autonomous-database generate-wallet --generate-type ALL --file atpwallet.zip --password Fsdrs@123 --autonomous-database-id ocid1.autonomousdatabase.oc1.iad.anuwcljt5h22avqa3yzakzoidhe2vtcgjqpkinnrvflqk2kz3sw443zhcbna

Now is the time to download the private key for connecting to the MuShop compute VMs by using the below command in the Cloud Shell (1) and then changing the permission of the private key to 0600 (2).

wget http://bit.ly/mushopll
chmod 0600 mushopll

Now we need to move to the other tab we have open and click the hamburger menu, select Compute, then Instances, and gather the Public IPs of the two MuShop application instances.

We will move again to the tab with the Cloud Shell open and Scp (Secure Copy) the ATP Wallet to the MuShop Application compute instances (both IPs).

scp -i mushopll atpwallet.zip opc@129.213.9.205:/home/opc
scp -i mushopll atpwallet.zip opc@129.153.224.255:/home/opc

At the same Cloud Shell screen, connect to the MuShop App VM mushop-xxxxx-0, once connected, you should be able to see the atpwallet.zip file that was previously copied via scp.

ssh -i mushopll opc@129.153.224.255
ls -lrt

Now download the script to run custom changes as part of MuShop application requirement, as shown below, change the permission to execute the downloaded file and execute the mushopapp. script. Finally, exit the application VM. When complete this step, please repeat it nut this time connected to the Application VM mushop-xxxxx-1.

wget http://bit.ly/mushopapp
chmod +x mushopapp
./mushopapp
exit

ssh -i mushopll opc@129.213.9.205 
wget http://bit.ly/mushopapp
chmod +x mushopapp
./mushopapp
exit

Now is the time to create the associated disaster and recovery groups (DRPG). DRPG is a resource type used by Full Stack DR and represents a consistency grouping defined for disaster and recovery purposes. In other words, it is a collection of different OCI resources like the application servers, associated block storages, and databases.

For this exercise, we will need to open another 2 tabs within OCI and have one connected to the Ashburn region (Primary) and the other to the Phoenix region (the standby).

Let’s connect to the tab within the Ashburn region and click on the hamburger menu at the top left corner of the screen, then select the Migration and Disaster Recovery option (1), then Disaster Recovery -> DR Protection Groups (2).

At the DRPG page, ensure you are at your correct compartment (3) and click on “Create DR protection group” (4).

1. Create DRPG in the Ashburn region. Select Create DR Protection group in the Ashburn region browser tab and follow the below instructions.

• Enter name as mushop-ashburn
• Select the compartment assigned to you
• In the object storage bucket, use the drop-down option and select mushop-xxxxx (mushop-xxxxx) ( Don’t select mushop-media-xxxxx bucket)
• In the role, leave it as Not Configured
• Ignore add member
• Verify and hit create

Now is time to connect to the other tab we have open connected to the Phoenix region and repeat all previous steps to create a DRPG but change the DRPG name to “mushop-phoenix” as below:

Now that we have both DRPGs created, we will continue by associating the “mushop-ashburn” DRPG as primary and the “mushop-phoenix” DRPG as “Standby”. At the primary DRPG, follow the steps below.

Now at the standby DRPG (Phoenix), we can also see that the association is completed.

Thank you for participating in this first part of the tutorial. The second part, where you will play with the just-created environment, can be accessed here!

Kind Regards,

Francisco Munoz Alvarez