Oracle Corporation
09/24/2024 | Press release | Distributed by Public on 09/23/2024 22:17
OCI Full Stack Disaster Recovery expands its built-in capabilities ...
Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery (DR) continues to expand its built-in capabilities with the introduction of seven new features for Oracle database and storage services in OCI. These highly anticipated additions provide more comprehensive coverage of OCI services for fully automated failovers, switchovers, and disaster recovery drills for compute, storage, databases, and load balancers.
In this blog post, we describe the new features at a high level and explain basic concepts needed to add the resources as members to what Full Stack DR calls disaster recovery protection groups (DRPGs).
OCI Storage services that Full Stack DR supports
Full Stack DR recently introduced Object Storage as a new built-in, native resource type that the service can automatically manage during a disaster recovery operation. Full Stack DR now orchestrates recovery for all the following OCI storage services:
Block Storage
File Storage
Object Storage
Supported OCI Database services
Full Stack DR also introduced built-in support for four other OCI Oracle Database services. Customers can configure Autonomous Data Guard or Data Guard using the Oracle Cloud Console for any Oracle database in the following list, then Full Stack DR orchestrates recovery using the OCI native APIs each database service provides to trigger failovers and switchovers using Data Guard:
Autonomous Database Serverless
Autonomous Dedicated Infrastructure
Autonomous Dedicated Cloud@Customer
Oracle Base Database Service
Oracle Exadata Database Service on Dedicated
Oracle Exadata Database Service on Cloud@Customer
Oracle Exadata Database Service on Exascale Infrastructure
All supported database services allow adding multiple primary and standby databases to the DRPGs at each region. Customers can mix and match different database services into the same DR protection groups and plans as needed for any given application stack.
For example, you can include two Base databases, three Autonomous Dedicated Infrastructure databases and three Exadata databases on Exascale if that is required for a particular business system. All recovery steps for each database are automatically prepopulated into any failover or switchover disaster recovery plans that are created.
Autonomous Database snapshot standby for disaster recovery drills
Autonomous Database Serverless has been a built-in resource type in Full Stack DR from the beginning. The exciting news is that the Autonomous Database Serverless engineering team has been busy adding more APIs to create and manage snapshot standby, full clones, and refreshable clones.
Full Stack DR now allows you to choose between any of these Autonomous Data Guard standby options as part of a disaster recovery drill in the standby region. You can choose the options for either Autonomous Database Transaction Processing or Data Warehouse databases that are members of DRPGs.
The standby snapshot feature is also available with Autonomous Dedicated Infrastructure and Autonomous Dedicated Cloud@Customer, but these OCI services don't support refreshable or full clones currently.
Although database administrators can create snapshot standbys for Exadata and Base Database as a service (DBaaS) using the command line, OCI APIs that create and manage snapshot standbys aren't yet available with these services. So, Full Stack DR can't automatically prepopulate disaster recovery drills with the steps needed to set up a read-write copy of databases in the standby region when running a disaster recovery drill. DBaaS engineering has their sights set on providing the snapshot standby feature enhancement in the future, but we will let you know when these crucial APIs are available to prepopulate disaster recovery drills with the steps to automatically set up the databases in the standby region for testing.
Autonomous Database console links to Full Stack DR
This new feature of Autonomous Database Serverless was released into production this last August and is a noteworthy step toward much tighter integration between OCI Database services and OCI Disaster Recovery as a Service (DRaaS) with Full Stack DR. For a closer look at this new feature, read Suraj Ramesh's post, OCI Autonomous Database Provides more Insights into Full Stack DR from the ADB Serverless Pages in the OCI Console.
Screenshot 1: Autonomous Database console integration with Full Stack DR
Screenshot 1: Full Stack DR integration within Autonomous Database Serverless Console
How these new features work with Full Stack DR
All OCI services, compute, storage, databases, and networking are first created and deployed outside of the Full Stack DR workflow using normal OCI services. For example, create Object Storage buckets in both regions, then enable cross-region replication using the Object Storage service.
Likewise, all the supported Oracle Databases are provisioned outside of the Full Stack DR workflow using the OCI service console for the desired databases. Autonomous Data Guard or Data Guard are also enabled or configured in the OCI console for the databases of choice. This is how all OCI services are deployed before adding anything to Full Stack DR.
Select from an increasing portfolio of OCI resource types
Add any number and combination of desired compute, block storage, file storage, object storage, databases, and load balancers to Full Stack DR Protection Groups. What you add is completely up to you and entirely dependent on what OCI resources are part of a business system or application stack.
Screenshot 2 below highlights the storage and databases that are now first-class citizens of Full Stack DR. First-class citizens all have built-in intelligence needed to pre-populate DR plans with all the steps need to orchestrate recovery for a given resource.
Screenshot 2: built-in resource types
Screenshot 2: built-in resource types
Add existing resources to DR protection groups
There are always two DR Protection Groups for any single business system or application stack. They are created in two different regions or availability domains and associated with each other as peers.
A business system typically has OCI resources running or existing in each region. For example, primary databases will have a standby database in the standby region or availability domain. Therefore, any number of primary databases are added as members to the DR protection group with the primary role as shown in Screenshot 3. Then all corresponding standby databases are added to the DR protection group with the standby role.
Screenshot 3: DR Protection Group members
Screenshot 3: DR Protection Group members
Not all OCI resources have corresponding objects in the standby region. Read our documentation to understand more.
Create DR plans in the standby DR protection group
Always create three basic DR plans in the DR protection group that has the standby role as shown in Screenshot 4 below. The role of primary and standby is a function of the DR protection group, not the region. The roles are fluid, so it is a good idea to get out to the habit of thinking about a region as production and its peer as "DR". Full Stack DR automatically changes the roles of the protection groups so they are ready to perform a recovery in the other direction after a DR plan has completed executing a recovery.
Assuming region1 is primary and region2 is standby, you will create the three DR plans in region2 as shown in the screenshot below. These DR plans are used to transition the workload from region1 to region2.
Screenshot 4: DR Plan types
Screenshot 4: DR Plan types
Each supported resource type such asAutonomous Dedicated Database, Autonomous Database Cloud@Customer, and Object Storage, has the built-in intelligence needed to generate DR plans pre-populated with the right recovery steps in the right order as shown in Screenshot 5 below.
Screenshot 5: Basic DR Plan showing basic built-in Plan Groups
Screenshot 5: DR Plan showing basic built-in Plan Groups
Many of our customers are very happy with what Full Stack DR automates using the built-in plan groups as shown in Screenshot 5 above, but the goal is to automate 100% of the recovery for any given business system. The goal of full automation requires some more work to customize the basic DR plans to do what you need as seen in Screenshot 6 below.
Full Stack DR doesn't have built-in intelligent modules for applications. This is because there are currently no Oracle or non-Oracle applications that provide OCI native APIs to manage recovery. Data Guard, block storage, file storage, object storage and other OCI services we support out-of-the-box have the native OCI APIs needed to orchestrate automated recoveries.
Full Stack DR can still orchestrate recovery for almost any Oracle or non-Oracle application by adding user-defined Plan Groups and steps to any DR plan through our extensible framework as shown in Screenshot 6. For more about information about modifying plans, refer to the OCI disaster recovery documentation.
Screenshot 6: DR Plan showing custom user-defined Plan Groups
Screenshot 6: DR Plan showing custom user-defined Plan Groups
Preform a Switchover to test plans and change role to standby
Create the same three DR plans in region1 once the DR plans are completely ready in region2. Region1 must inherit the standby role before the DR plans can be created there. Execute the switchover plan in region2 so the workload is moved to region2. This will make region1 the standby region. Create the same three plans in region1 so Full Stack DR has a way to transition the workload back to region1.
Test DR plans often without impacting production
DR Drills and periodic prechecks are extremely important tools for ensuring the integrity and viability of your DR plans. Prechecks cost nothing to run and will catch even minor inconsistencies and changes in your environment that will impact the success of a recovery.
DR drills can be run without any worry over impacting your production workload. This type of DR plan will hydrate a copy of the production compute, storage, databases, and load balancer backend sets at the standby region with zero impact on your production workload.
Want to know more?
If you haven't seen Full Stack Disaster Recovery in action yet, ask your Oracle account team to set up a demonstration with Full Stack DR product management today.
Customer success stories
athenahealth (software & services for health systems)
Sculptor Capital Management (asset management using Oracle PeopleSoft)
Winfo Solutions (consulting for Oracle E-Business Suite)
Documentation
What Is Disaster Recovery? A Beginner's Guide
Full Stack Disaster Recovery service overview on Oracle.com
Full Stack DR user guide on Oracle.com
Full Stack DR pricing calculator on Oracle.com
Hands-on labs
JD Edwards hands-on live lab
MuShop beginner hands-on lab (learn the basics)
PeopleSoft hands-on live lab
OHC tutorials explaining how to automate recovery for applications
Automate Recovery for Oracle Analytics Cloud
Automate Recovery for Oracle Analytics Server
Automate Recovery for Oracle Integration Generation 2
Automate Recovery for Enterprise Performance Manager
Automate Recovery for Oracle PostgreSQL
Automate Recovery for Oracle WebLogic Server
YouTube Playlists
Full Stack DR: Deep Dive
Learn from the experts