Note:
- This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
- It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.
Automate a Switchover and Failover Plan for a Demo Application Deployed on OCI Kubernetes Engine with OCI Full Stack Disaster Recovery
Introduction
This tutorial demonstrates an Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) use case with a demo e-commerce application deployed on an Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes Engine or OKE) cluster.
At the time of writing this tutorial, OCI Full Stack DR has announced limited availability for OKE. In limited release, we get to try OCI Full Stack DR on OKE-based applications like MuShop, a microservices-based demo application that uses various other Oracle Cloud Infrastructure (OCI) services as one application.
We will use a warm standby approach: a disaster recovery (DR) model where some or all application components are pre-deployed in a standby region to enable a faster DR transition. Although this model involves higher operating costs, it provides a lower recovery time objective (RTO).
OCI Full Stack DR orchestrates the transition of computes, databases, and applications between OCI regions from around the globe with a single click. Customers can automate the steps needed to recover one or more business systems without redesigning or re-architecting existing infrastructure, databases, or applications without needing specialized management or conversion servers.
Deployment Architecture
Note: The primary region is Sydney and the DR region is Melbourne.
Objectives
-
As per the architecture, we will create a DR protection group (DRPG) named
Mushop-Syd
in the primary Sydney region. -
The primary DRPG contains a collection of different OCI resources that comprise an application, and which must be treated as a combined group when performing DR operations. We have added OKE and Oracle Autonomous Database Serverless (Autonomous Database Serverless) to the primary DRPG. This tutorial also provides steps to deploy the MuShop application and all other resources necessary for the deployment.
-
A similar DRPG is created at the standby Melbourne region. OKE and Autonomous Database Serverless (in standby mode) are added to the DRPG. The load balancers are not part of the DRPG, but will be running independently at both sites, as highlighted in the Deployment Architecture.
-
An association is formed between the two DRPGs.
-
At the standby DRPG (Melbourne), a DR plan is created. This plan represents a DR workflow (a sequence of steps).
-
Run a DR plan. A switchover is executed, which plans a transition of services from the primary DRPG to the standby DRPG. Switchover plans perform an orderly transition by shutting down the application stack in the primary region and then bringing it up in the standby region. Therefore, a switchover plan requires that application stack components and other required OCI services be available in both regions.
Prerequisites
-
Administrator privileges or configure the required Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) policies for OCI Full Stack DR. For more information, see Configuring Identity and Access Management (IAM) policies to use OCI Full Stack DR and Policies for OCI Full Stack DR.
-
Environment setup:
export COMPARTMENT_ID=ocid1.compartment.oc1.. export DB_NAME=fsdrdemoadb export DB_DISPLAY_NAME=fsdrdemoadb export DB_PASSWORD=<Your DB Password> export WALLET_PW=<Your DB Password> export DB_SERVICE_NAME=${DB_NAME}_tp export WALLET_ZIP=/tmp/Wallet_${DB_NAME}.zip export STANDBY_WALLET_ZIP=/tmp/Wallet_${DB_NAME}_Standby.zip export PRIMARY_REGION=ap-sydney-1 export STANDBY_REGION=ap-melbourne-1 export STANDBY_DB_NAME=${DB_NAME}_remote
Add the following lines to a file named
env
and source it.source env
Note:
- For more information about the password criteria for Autonomous Database Serverless, see About User Passwords on Autonomous Database.
- The Autonomous Database Serverless name can contain only alphanumeric characters.
- Replace the
DB_PASSWORD
andWALLET_PW
in the above environment variables.
Task 1: Install and Set Up Oracle Autonomous Database
-
Create the primary Oracle Autonomous Database.
oci db autonomous-database create --compartment-id ${COMPARTMENT_ID} \ --db-name ${DB_NAME} --admin-password ${DB_PASSWORD} --db-version 19c \ --cpu-core-count 1 --data-storage-size-in-tbs 1 \ --display-name ${DB_DISPLAY_NAME} --region ${PRIMARY_REGION}
-
Fetch the primary Oracle Autonomous Database OCID.
DB_ID=$(oci db autonomous-database list -c ${COMPARTMENT_ID} \ --region ${PRIMARY_REGION} --display-name $DB_NAME \ --query "data[?\"db-name\"=='${DB_NAME}'].id | [0]" --raw-output)
-
Create the standby DR and enable cross-region Oracle Data Guard.
oci db autonomous-database create-adb-cross-region-data-guard-details \ --compartment-id ${COMPARTMENT_ID} --db-name ${DB_NAME} --source-id ${DB_ID} \ --cpu-core-count 1 --data-storage-size-in-tbs 1 \ --region ${FAILOVER_REGION} --db-version 19c
-
Download and extract the autonomous database wallet from the primary Oracle Autonomous Database.
oci db autonomous-database generate-wallet --autonomous-database-id ${DB_ID}\ --password ${WALLET_PW} --file ${WALLET_ZIP} --region $PRIMARY_REGION
-
Unzip the wallet at the primary.
unzip ${WALLET_ZIP} -d /tmp/wallet_primary
Note:
- Keep this wallet handy as we will need to add it as the OKE secret later on.
- The wallet has to be downloaded separately for the primary and standby regions because the
tnsnames.ora
DNS entries are different.
-
Fetch the standby Oracle Autonomous Database OCID.
STANDBY_DB_ID=$(oci db autonomous-database list -c ${COMPARTMENT_ID} \ --region ${STANDBY_REGION} --display-name $STANDBY_DB_NAME \ --query "data[?\"db-name\"=='${DB_NAME}'].id | [0]" --raw-output)
-
Download and extract the autonomous database wallet from the standby Oracle Autonomous Database.
oci db autonomous-database generate-wallet --autonomous-database-id \ ${STANDBY_DB_ID} --password ${WALLET_PW} \ --file ${STANDBY_WALLET_ZIP} --region $STANDBY_REGION
-
Unzip the standby wallet.
unzip ${STANDBY_WALLET_ZIP} -d /tmp/wallet_standby
Task 2: Create an OKE Cluster
Create an OKE cluster on both the primary and DR sites. For more information, see Create a Cluster with Oracle Cloud Infrastructure Container Engine for Kubernetes.
We have used the Quick Create option to create clusters with the following information:
- Cluster Name: Enter
primary-syd-oke-demo-cluster
(Sydney) andstandby-mel-oke-demo-cluster
(Melbourne). - Kubernetes API endpoint: Select Public.
- Node Type: Select Managed.
- Select Private Workers.
- Shape: Select VM Standard E3 Flex (4 OCPU, 64 GB Memory).
- Select Oracle Linux 8.
To access your cluster, go to the OCI Console, navigate to Developer Service, Container & Artifacts, and click Kubernetes Clusters (OKE).
Or
Run the following command to access your cluster.
oci ce cluster create-kubeconfig --cluster-id <cluster-id> --file $HOME/.kube/config --region ap-sydney-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT
Task 3: Set Up Kubernetes Secrets at the Primary Site
-
Create a namespace.
kubectl create ns mushop
-
Add the Oracle Autonomous Database admin password secret.
kubectl create secret generic oadb-admin \ --namespace mushop \ --from-literal=oadb_admin_pw=${DB_PASSWORD}
-
Add the Oracle Autonomous Database connection secret.
kubectl create secret generic oadb-connection \ --namespace mushop \ --from-literal=oadb_wallet_pw=${WALLET_PW} \ --from-literal=oadb_service=${DB_SERVICE_NAME}
-
Add the primary wallet secret.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_primary
Task 4: Set Up the MuShop Application
Note: The application is only deployed at the primary region (
ap-sydney-1
).
-
Clone the repository.
git clone git@github.com:naikvenu/fsdr-demo.git
-
Go to the chart folder.
cd fsdr-demo/helm-chart/
-
Update the chart dependencies.
helm dependency update ./setup
-
Install and set up the chart.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Locate the ingress controller
EXTERNAL-IP
address.PRIMARY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Install the application on the OKE cluster.
helm upgrade --install -f ./mushop/values-dr.yaml \ fsdrmushop mushop -n mushop
-
Access the primary MuShop application using the ingress IP.
kubectl get svc mushop-utils-ingress-nginx-controller \ --namespace mushop-utilities
-
To verify the application, access
http://<primary-site-ingress-ip-address>
and ensure you see all of the MuShop catalogue products listed without errors.
Task 5: Set Up an OKE Cluster at the Standby Site
Note: Since we are using a warm standby approach, we need to create an OKE cluster and run a few basic things, like the ingress controller. The following steps will help you do that.
-
To access your cluster at the standby site, go to the OCI Console, navigate to Developer Service, Container & Artifacts, and click Kubernetes Clusters (OKE).
Or
Run the following command to access your cluster at the standby site.
oci ce cluster create-kubeconfig --cluster-id <cluster-id> --file $HOME/.kube/config --region ap-sydney-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT
-
Clone the repository.
git clone git@github.com:naikvenu/fsdr-demo.git
Or
git clone https://github.com/naikvenu/fsdr-demo
-
Go to the charts folder.
cd fsdr-demo/helm-chart/
-
Update the chart dependencies.
helm dependency update ./setup
-
Install and set up the charts. This is required to deploy an ingress controller (OCI Load Balancer) to access the application.
Note: This step will only deploy an ingress controller (OCI Load Balancer) and not the full application.
helm upgrade --install mushop-utils setup --dependency-update --namespace mushop-utilities --create-namespace
-
Locate the ingress controller
EXTERNAL-IP
address.STANDBY_EXTERNAL_IP=$(kubectl get svc -n mushop-utilities mushop-utils-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
-
Create a MuShop namespace.
kubectl create namespace mushop
-
Create a secret for the wallet.
kubectl create secret generic oadb-wallet \ --namespace mushop --from-file=/tmp/wallet_standby
Note: We are using a standby wallet.
Task 6: Set Up DNS Zones (Optional)
At the primary region, go to the OCI Console, navigate to Networking, DNS Management, Zones, and click Create Zone.
Configuration:
The Zone type : Primary
‘A’ record: “mushop”
The zone name should match your Purchased Domain Name. Enter the nameservers to be added to your domain.
The application will be accessible at https://mushop.<your-domain>.com
.
Task 7: Create Health Checks (Optional)
Health checks are required to set up OCI DNS traffic steering policies.
Run the following command to create health checks.
oci health-checks http-monitor create --compartment-id ${COMPARTMENT_ID} --display-name fsdr-test --interval-in-seconds 30 --targets '[“${PRIMARY_EXTERNAL_IP}”]' --protocol http --path "/" --port 80
Or
Go to the OCI Console, navigate to Observability & Management, Monitoring, Healthchecks, click Create Health Check, and enter the following information.
- Name: Enter
FSDR-APP-HEALTHCHECK
. - Targets: Enter the IPs of both primary and standby load balancers.
- Protocol: Select http.
- Port: Enter 80.
- Target Path: Enter
/
. - Method: Select GET.
- Timeout: Enter 30.
- Interval: Enter 30 seconds.
Task 8: Configure the Traffic Management Steering Policy (Optional)
Go to the OCI Console, navigate to Networking, DNS Management, Traffic Management Steering Policies, click Create Traffic Management Steering Policy, and enter the following information.
- Name: Enter
FSDR-POLICY
. - TTL: Enter 60 seconds.
- Pool 1:
- Name: Enter
Primary
. - Type: Select A.
- Rdata: Enter the IP of the primary load balancer.
- Name: Enter
- Pool 2:
- Name: Enter
Standby
. - Type: Select A.
- Rdata: Enter the IP of the standby load balancer.
- Name: Enter
- Select Pool Priority:
- Pool1
- Pool2
- Attach the health check created in Task 7.
Task 9: Set Up OCI Full Stack DR
-
Create a DRPG in both regions. Go to the OCI Console, navigate to Migration & Disaster Recovery and click DR protection groups. For example,
primary-drpg-sydney
andstandby-drpg-melbourne
. -
Associate the DRPGs. Go to the OCI Console, navigate to Migration & Disaster Recovery, DR protection groups, and click Associate.
-
Add resources to the DRPG (Sydney region). Go to the OCI Console, navigate to Migration & Disaster Recovery, DR protection groups, Members, and click Add Member.
-
Add the OKE cluster and Oracle Autonomous Database.
-
Add resources to the DRPG (Melbourne region) - OKE cluster and Oracle Autonomous Database.
-
Create a DR plan at the standby region (Melbourne). Go to the OCI Console, navigate to Migration & Disaster Recovery, DR protection groups, Plans, and click Create Plan.
The following image shows a DR plan that orchestrates recovery for an entire application stack, which can include other services along with OKE.
As you can see from the image, we have built-in steps for OKE. The OCI Full Stack DR service runs an internally developed backup tool. This tool will periodically take the cluster’s backups of Deployments, Replica Sets, Pods, CronJobs, Daemon Sets, and so on.
The backups will be stored in the OCI Object Storage bucket that we specified in the member property.
-
OKE - Stop Backup and Cleanup (Primary): This stops the backups and terminates all the mentioned resources in the OKE cluster.
-
OKE - Restore (Standby): Using the backup, it restores the latest backup in the DR OKE cluster, so you will have all the resources created in the OKE cluster.
-
OKE - Schedule Reverse Backup (Standby): Set the reverse backup for the switchback plan.
If you are using PersistentVolume (PV) and PersistentVolumeClaim (PVC), you need to configure cross-region volume groups (block storage) and cross-region FSS replication (file storage) and add those as members in the DRPG. This will create additional plan groups, like what we saw for OKE and Oracle Autonomous Database.
-
-
Perform a switchover. This step must be performed from the standby site (Melbourne).
Go to the OCI Console, navigate to Migration & Disaster Recovery, DR protection groups, and click Execute DR Plan.
Task 10: Test and Validate the Application
Access the application from the standby region and ensure everything works. The application should be accessible at https://mushop.domain.com
or use the http://standbyloadbalancerIP.com
address.
Ensure you can access the catalogue items, indicating that the standby database is fully operational.
Note: In this tutorial, we have excluded steps to include SSL certificates on OCI Load Balancer and using OCI Web Application Firewall. These two components can be added to production environments.
Next Steps
You have seen how an e-commerce application based on microservices, deployed on OCI Kubernetes Engine, can be configured with the OCI Full Stack DR service to enable disaster recovery in a warm standby mode. We showed how this application can seamlessly fail over without any manual intervention. For more information, see the OCI Full Stack DR documentation in the Related Links section.
Related Links
Acknowledgments
-
Author - Venugopal Naik (Principal Cloud Architect)
-
Contributors - Raphael Teixeira (Principal Member of Technical Staff for FSDR ), Suraj Ramesh (Principal Product Manager for MAA)
More Learning Resources
Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.
For product documentation, visit Oracle Help Center.
Automate a Switchover and Failover Plan for a Demo Application Deployed on OCI Kubernetes Engine with OCI Full Stack Disaster Recovery
G23539-01
December 2024