1. Use OCI Full Stack Disaster Recovery Service with Oracle WebLogic Server domains
  2. Learn About Using OCI Full Stack Disaster Recovery Service with Oracle WebLogic Server Domains

Learn About Using OCI Full Stack Disaster Recovery Service with Oracle WebLogic Server Domains

You can use the Oracle Maximum Availability Architecture (MAA) best practices and scripts described in this solution with Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery Service to manage switchover and failover in your existing Oracle WebLogic Server for OCI and Oracle SOA Suite on Marketplace disaster recovery environments.

The service is an 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.

Before You Begin

Before you begin, ensure that you're familiar with the disaster recovery best practices in Oracle Cloud Infrastructure (OCI) services. This playbook applies to the following environments:

Ensure that you have basic knowledge about OCI Full Stack Disaster Recovery Service. See Full Stack Disaster Recovery.

Architecture

This architecture shows a multi-region disaster recovery implementation using Oracle Cloud Infrastructure Full Stack Disaster Recovery Service.

Description of full-stack-disaster-recovery-paas.png follows
Description of the illustration full-stack-disaster-recovery-paas.png

full-stack-disaster-recovery-paas-oracle.zip

This architecture supports the following Oracle Cloud Infrastructure (OCI) components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Virtual cloud network (VCN) and subnet

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Load balancer

    The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.

  • Full Stack Disaster Recovery Service

    Oracle Cloud Infrastructure Full Stack Disaster Recovery Service is an 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.

  • DR Protection Group

    A Disaster Recovery (DR) Protection Group organizes the components of a full stack application so that you can recover all the components together to restore the full stack application.

  • DR plans

    A Disaster Recovery (DR) plan is an automated DR workflow (a DR runbook) created by Oracle Cloud Infrastructure Full Stack Disaster Recovery Service to perform disaster recovery for all of the resources in the primary DR Protection Group. Two types of plans are available: Switchover and Failover.

  • Oracle WebLogic Server for OCI

    Oracle WebLogic Server for OCI enables you to quickly create your Java Enterprise Edition (Java EE) application environment on Oracle Cloud Infrastructure, including an Oracle WebLogic Server domain. You can configure and provision your domains along with any supporting cloud resources like compute instances, networks, and load balancers.

  • Oracle SOA Suite on Marketplace

    Oracle SOA Suite on Marketplace provides a Platform as a Service (PaaS) computing platform solution for running applications in the cloud. It includes a complete set of service infrastructure components for designing, deploying, and managing composite applications.

  • Database

    In this architecture, the database can be an Oracle Base Database Service, Oracle Exadata Database Service, or Oracle Autonomous Database Serverless.

  • Dynamic routing gateway (DRG)

    The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.

  • Data Guard

    Oracle Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to remain available without interruption. Oracle Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Oracle Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage.

About Oracle Cloud Infrastructure Full Stack Disaster Recovery Service

The following are some of the benefits of Oracle Cloud Infrastructure Full Stack Disaster Recovery Service:

  • Ability to run a switchover or failover plan with just one-click using the Oracle Cloud Infrastructure (OCI) Console.
  • Ability to use OCI APIs to invoke switchovers and failovers.
  • Provides centralized switchover and failover logs in the OCI Console.
  • Allows retrying and skipping any failed step in the switchover workflow.
  • Provides built-in integration with Oracle Data Guard for OCI Full Stack Disaster Recovery Service supported databases. You don't need to define or configure steps for the database switchover, the service automatically manages it for you.
  • Provides built-in prechecks for the steps in switchover and failover plans. You have the option to skip the prechecks.
  • Provides flexibility and it is extensible, allowing you to add user-defined steps for non built-in steps. For example, stop and start Oracle WebLogic Server, update DNS, check frontend address. The execution of these custom scripts is integrated with Oracle Cloud Agent. You can define steps to be run in parallel (within a User Defined Plan Group) or sequentially.
  • Allows you to add Oracle Maximum Availability Architecture (MAA) configuration replication scripts to an OCI Full Stack Disaster Recovery Service switchover plan. The MAA scripts can then synchronize the middle tier Oracle WebLogic Server configuration during the switchover (in the context of Oracle WebLogic Server for OCI and Oracle SOA Suite on Marketplace). You cannot use OCI Full Stack Disaster Recovery Service for scheduling ongoing configuration replications.
  • Allows you to perform manual switchovers, if needed. You can manually change the roles of the DR Protection Groups to match the current role after a manual switchover. Manual “intervention” is needed to get the desired OCI Full Stack Disaster Recovery Service system’s state, but you can convert a “manually-managed” DR system to “OCI Full Stack Disaster Recovery Service-managed” again).

You can find more details in Benefits of Full Stack Disaster Recovery.

OCI Full Stack Disaster Recovery Service offers competitive pricing, see the OCI Price List.

Considerations

Before implementing Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery Service, consider the following implications.

The actions that don't have built-in integration with OCI Full Stack Disaster Recovery Service (like stop and start of an Oracle WebLogic Server) are defined by the user. You create user defined steps and provide the scripts associated to these steps. This provides a flexible framework because users can add any custom actions to the plan. However, the reliability of these steps is out of the scope of OCI Full Stack Disaster Recovery Service. Users are responsible for their switchover’s script behavior. For example, your script must manage situations where Oracle WebLogic Server processes cannot be started on secondary because lock files were left behind in a node reboot. The difference with a manual switchover is that behaviors like this are more actionable and directly perceived when the switchover is executed manually.

This document provides the recommended scripts to perform start and stop operations on Oracle WebLogic managed servers and to perform a DNS switch. Additional custom scripts may be needed, or used, depending on each environment and topology, such as Oracle Database File Systems (DBFS) replication and Oracle Cloud Infrastructure File Storage replica.

Note:

OCI Full Stack Disaster Recovery Service doesn't schedule ongoing configuration replications.
See Oracle WebLogic Server for Oracle Cloud Infrastructure, Disaster Recovery Production and DR in the Oracle Cloud Infrastructure (OCI) for details on those specific operations.

Supported Configurations

Review the following for a summary of what OCI Full Stack Disaster Recovery Service supports in the context of disaster recovery for Oracle SOA Suite on Marketplace and Oracle WebLogic Server for OCI.

Configuration Replication Supported in OCI Full Stack Disaster Recovery Service?
Configuration Replication based on Oracle Database File System (DBFS) replica Yes
Configuration Replication based on OCI File Storage with RSYNC replica Yes
Configuration Replication based on OCI Block Volumes cross-replica No
Database Service on OCI Supported in OCI Full Stack Disaster Recovery Service?
Oracle Base Database Service (DB Systems) Yes
Oracle Exadata Database Service Yes
Oracle Autonomous Database Serverless Yes
Oracle Autonomous Database on Dedicated Exadata Infrastructure No
OCI Built-in Integrations Supported in OCI Full Stack Disaster Recovery Service?
Built-in integration with OCI Data Guard Yes
Built-in management of manually configured Oracle Data Guard instances No
Local standby database (standby in the same region) besides a remote DR No
Open standby site for validations No

Additional Details on Unsupported Items

While some configurations aren't directly provided by the OCI Full Stack Disaster Recovery Service, you can add customization to your disaster recovery plans to automatically run at specific points in the plan to provide a seamless, fully automated recovery process. The following are additional details for items that OCI Full Stack Disaster Recovery Service does not support out-of-the-box as part of the built-in automation:

  • Built-in management for standby databases created with a manual process instead of using the OCI Console or control plane.

    OCI Full Stack Disaster Recovery Service has built-in automation to handle Oracle Data Guard during a recovery if you configured Oracle Data Guard using the standard database service available in the OCI Console. However, if you installed and implemented Oracle Data Guard on your own compute instance, then you must add a custom plan group and steps to call a script to trigger Oracle Data Guard on your compute instance.

  • Additional local standby database to a remote standby (standby in the same region). You can use custom scripts to manage an additional local standby database.

  • Open secondary (standby) site for validations. You cannot create OCI Full Stack Disaster Recovery Service plans for opening the standby for testing, patching, or scaling because it can’t convert the standby database to snapshot standby.

About Required Services and Roles

This solution requires the following Oracle Cloud Infrastructure (OCI) services and roles:

  • OCI Full Stack Disaster Recovery Service

  • Oracle Data Guard

  • Oracle WebLogic Server for OCI

These are the roles needed for each service.

Service Name: Role Required to...
Oracle Cloud Infrastructure: administrator Create the required resources in the OCI tenancy: IAM policies, DR Protection Groups and DR, secrets.
Oracle Data Guard: sysdba, admin Create the password secret containing the sysdba credential.
Oracle WebLogic Server for OCI: root, oracle Setup the Oracle Cloud Agent permissions and the required user scripts.