Configure a Hybrid DR Solution for Oracle SOA Suite
Before You Begin
See LiveLab: Oracle Database Hybrid Active Data Guard Workshop to learn about how to setup hybrid Oracle Data Guard from on-premises to Oracle Cloud Infrastructure.
Architecture
The primary system is an Oracle SOA Suite system located on-premises. The SOA system used in this document is a SOA EDG 12.2.1.4 environment that was configured following the standard Enterprise Deployment Guide for Oracle SOA Suite (EDG). Although not all scenarios follow this exact topology to the detail, the SOA EDG covers many different components, is used frequently in large deployments and implements high availability recommendations that should be applied before deploying a DR system. Hence, it is considered the best reference example of a primary system for a Hybrid DR solution for SOA. Based on this, it is highly recommended to become familiar with EDG’s details about network, storage and host set up best practices before deploying a hybrid system as explained in this document.
The standby system on Oracle Cloud Infrastructure (OCI) is a system created in an OCI tenancy that uses Oracle Cloud Infrastructure FastConnect to connect with the Oracle on-premises environment. This secondary system on OCI is created from scratch. The mid-tier is created by installing SOA on OCI virtual machines (VMs) and not an Oracle SOA Cloud Service or SOA Marketplace instance (there are restrictions in OS versions, OS users and directory structure that preclude Oracle SOA Cloud Service or SOA Marketplace instance from working properly as a standby for an on-premises system). The database tier on the OCI site is an Oracle RAC DB System.

Description of the illustration maa-soa-hybrid-dr.png
This architecture supports the following components in the primary, on-premises data center:
- On-premises network
This network is the local network used by your organization. It is one of the spokes of the topology.
- Load Balancer
Provides automated traffic distribution from a single entry point to multiple servers in the back end.
- Oracle SOA Environment
SOA EDG 12.2.1.4 environment that was configured following the standard Enterprise Deployment Guide for Oracle SOA Suite.
- Oracle Real Application Clusters (Oracle
RAC)
Oracle RAC enables you to run a single Oracle Database across multiple servers in order to maximize availability and enable horizontal scalability, while accessing shared storage. User sessions connecting to Oracle RAC instances can failover and safely replay changes during outages, without any changes to end user applications, hiding the impact of the outages from end users.
This architecture supports the following components in the secondary, stand-by environment on OCI:
- 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.
- Dynamic routing gateway (DRG)
The DRG is a virtual router that provides a path for private network traffic 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.
- FastConnect
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
- 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.
- Cloud Guard
You can use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.
- VM DB System
Oracle VM Database System is an Oracle Cloud Infrastructure (OCI) database service that enables you to build, scale, and manage full-featured Oracle databases on virtual machines. A VM database system uses OCI Block Volumes storage instead of local storage and can run Oracle Real Application Clusters (Oracle RAC) to improve availability.
- Oracle RAC DB System
Oracle Real Application Clusters (Oracle RAC) allow customers to run a single Oracle Database across multiple servers in order to maximize availability and enable horizontal scalability, while accessing shared storage. User sessions connecting to Oracle RAC instances can failover and safely replay changes during outages, without any changes to end user applications, hiding the impact of the outages from end users. The Oracle RAC high availability framework maintains service availability by storing the configuration information for each service in the Oracle Cluster Registry (OCR).
Oracle RAC DB System is on the database tier.
- 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.
- Oracle SOA Suite
Oracle SOA Suite is a comprehensive, hot-pluggable software suite that enables you to build, deploy, and manage integrations using service-oriented architecture (SOA). It provides consistent tooling, a single deployment and management model, end-to-end security, and unified metadata management.
Topology Description
In the db-tier, the primary and secondary databases are configured with Oracle Data Guard. With Oracle Data Guard, all changes that are applied to the primary database are replicated on the secondary (standby) database.
The secondary mid-tier is installed on OCI virtual machines (VMs). The Oracle Fusion Middleware binaries and SOA Domain are a replica of the primary’s binaries and SOA Domain, using Oracle Cloud Infrastructure File Storage service as the network file system solution. The primary’s host name aliases are used also as the listener addresses of the WebLogic Servers in the secondary environment. In the secondary location, the host name aliases are resolved with the secondary hosts’ IP addresses.
The web-tier in the primary data center can follow the Oracle SOA Enterprise Deployment Guide (EDG) model with an Oracle HTTP Server (OHS) and a Load Balancer (LBR). The EDG provides a comprehensive, scalable example for installing, configuring, and maintaining a secure, highly available, production-quality deployment of selected Oracle Fusion Middleware products. The environment is known as an enterprise deployment topology. In the secondary system, you can implement the web layer with only Oracle Cloud Infrastructure Load Balancing, which provides most of the features required by the enterprise deployment topology. If the system uses Oracle Access Manager WebGate for single sign-on (SSO) and requires OHS, then you must also install OHS on OCI. Details on configuring OHS in OCI are not included in this document. A unique front-end address is configured to access the applications running in the system. The virtual front-end name points to the IP of the Load Balancer on the primary site. In a switchover, the front-end name is updated in DNS to point to the IP of the OCI Load Balancer on the secondary site. It must always point to the Load Balancer IP of the site that has the primary role.
During normal business operation, the standby database is a physical
standby. It either is in the mount state, or opened in read-only mode when Active Data Guard is used. The standby database receives and applies redo
from the
primary database, but cannot be opened in read-write mode. Oracle Data Guard automatically replicates the information that resides in the database to the
secondary site, including Server Oriented Architecture (SOA) schemas, Oracle Platform
Security Services information, custom schemas, transaction logs (TLOGs), Java Database
Connectivity (JDBC) persistent stores, and more.
During the DR setup and lifecycle validation steps described in this
document, you can convert the standby database from a physical standby to a snapshot
standby. A database in snapshot standby mode is a fully updateable database. A snapshot
standby database receives and archives, but does not apply, the redo
data received from a primary database. All changes applied to a snapshot standby are
discarded when it is converted into a physical standby.
The WebLogic Domain configuration must be replicated from the primary site to the secondary. This replication is required and performed during the initial DR setup, and is also necessary during the ongoing lifecycle of the system. When configuration changes are performed in the primary domain, they must be replicated to the secondary location.
When a standby database is shutdown during normal business operation, it does not receive updates from the primary database and it might become out-of-sync. Because this can result in a data loss in a switchover scenario, it's not recommended to stop the standby database during normal business operation. The standby mid-tier hosts can be stopped. However, when standby hosts are stopped, the configuration changes that are replicated from the primary site will not be pushed to the secondary domain. In this case, when a switchover happens, the recovery time objective (RTO) is increased since the standby mid-tier hosts must be started and the domain synchronized with primary changes.
Considerations for Topology
This architecture is an Oracle SOA Enterprise Deployment Guide (EDG) model with an Oracle HTTP Server and a Load Balancer (an enterprise deployment topology). The EDG model provides a comprehensive, scalable example for installing, configuring, and maintaining a secure, highly available, production-quality deployment of selected Oracle Fusion Middleware products.
The following are the most relevant topology assumptions considered in this setup:
- The primary system is an existing SOA EDG
environment
consisting of an Oracle Real Application Clusters (Oracle RAC) database, mid-tier hosts, web-tier hosts and a Load Balancer (LBR), all installed and configured as per the SOA EDG.
- The secondary system is on Oracle Cloud Infrastructure
(OCI)
The secondary system is created from scratch on OCI.
-
Oracle SOA Suite and components
This document is focused on Oracle SOA Suite system, including its components. For example, Oracle Service Bus, Oracle Business Process Management, Oracle Enterprise Scheduler Service, and more. Although the procedures and recommendations in this document may apply to other Oracle Fusion Middleware components that are not part of Oracle SOA Suite (such as Web Center and Business Intelligence), the specifics and supportability of those are excluded from this exercise.
- The primary and secondary systems have the same number of nodes in
the mid-tier and db-tier
There are only slight differences in the implementation of the web-tier layer, given that the OCI Load Balancer can provide similar features as the on-premises Load Balancer and web-tiers.
- The primary and secondary systems use similar resources (CPU, memory,
etc.)
Although the available OCI images may not match the same exact values in CPU and memory of the existing primary configuration, the most similar images should be used. Oracle recommends using symmetric standbys that provide a similar processing power to the primary system. Otherwise, performance issues and cascade faults could occur when the workload is switched over to the OCI system.
Considerations for Network
Consider the following when configuring the network:
- Oracle Cloud
Infrastructure FastConnect
Configure Oracle Cloud Infrastructure FastConnect between the on-premises data center and the Oracle Cloud Infrastructure (OCI) region.
-
The on-premises and OCI databases must communicate with each other through Oracle SQL*Net Listener (port 1521) for Oracle Data Guard
redo
transport. -
The on-premises and OCI mid-tier hosts need to communicate with each other using the SSH port (for
rsync
copies). - Disallow connectivity between mid-tier hosts and the remote
database
It is expected that the mid-tier hosts will never connect to the remote database during runtime. The latency between on-premises and OCI typically discourages this cross-connectivity. To avoid accidental connections and workload issues, preclude the connectivity from the mid-tier hosts to the remote database.
- Virtual host names
As a best practice, it is assumed that the primary on-premises system uses virtual host names, instead of the physical node host name, as the listen addresses for the Oracle SOA Suite Oracle WebLogic Server . Virtual host names are normally aliases of the physical node host name. Using virtual host names facilitates moving configurations to different hosts; however, this is not a mandatory requirement. The configuration in this document works as long as the secondary servers in OCI can use the host names used as the listen addresses in the primary as an alias in each node (as resolved in DNS or local
/etc/hosts
). - A Virtual IP is only required for the Administration Server’s listen
address
Automatic Service Migration is supported and recommended starting with Oracle SOA Suite 12c for local high availability (HA), which means that the managed servers aren't required to use virtual IP addresses. Only the Administration Server needs a VIP for local failover. It is assumed that the Administration Server in the primary on-premises system the Administration Server in the standby on OCI use virtual IP addresses.
- Load balancer
A front-end load balancer is used in the primary on-premises environment and Oracle Cloud Infrastructure Load Balancing is used in the standby environment.
- Virtual front-end address
The primary system must use a virtual front-end name (a “vanity URL”) as the entry point for the SOA clients. This front-end name is resolved in DNS with the primary load balancer’s IP address. In a DR topology, the secondary system is configured to use the same virtual front-end name. When a switchover or failover to the secondary system occurs, the virtual front-end name is modified in the DNS to point to the secondary load balancer’s IP address. This way, access from the clients to the SOA system is agnostic to the site being used as the primary. The same applies to any virtual front-end name used in the system. For example, you can use an additional front-end name, such as
admin.example.com
, to access admin functions for the Oracle WebLogic Server Administration Console or Fusion Middleware Control Console. You can use a separated front-end name, such asosb.example.com
to access OSB services. This document uses one front-end host name for simplification.
Considerations for Storage
Consider the following when configuring the storage:
- EDG-based directory structure
Use an EDG-based directory structure for the primary system's Oracle WebLogic Server domain configuration. Use separate domain directories for the administration Oracle WebLogic Server and the managed Oracle WebLogic Servers, as described in Preparing the File System for an Enterprise Deployment. It is assumed that the primary system uses the EDG-based directory structure. The EDG directory structure is used in the examples.
- Storage replication
There is no direct replication at the storage level between on-premises and Oracle Cloud Infrastructure. The copy of the binaries and configuration from primary to standby is performed with
rsync
over Secure Shell (SSH). - Shared network file system (NFS) storage
It's a good practice to store shared folders (WLS Admin Server domain directory, deployment plans home, runtime, etc.), the FMW home binaries and local configurations (managed server domain directories, node manager folder) on shared NFS storage in the primary location. This facilitates the copy from primary to standby. Although each host will use its own binaries and its own local configuration privately, the copy of configuration between sites is easier if these reside on shared storage. By using shared storage, it's possible to mount from a unique node and execute the
rsync
copy to the remote nodes in a single operation. Without shared storage, the copy needs to happen individually, from each of the primary nodes that stores configuration or runtime data privately.
Considerations for Database
Consider the following when configuring the databases:
- Patch levels
Oracle Home for the on-premises database must be at the same patch level as the standby database.
- High availability
To get local High Availability at the database level, and according with the EDG topology, use Oracle Real Application Clusters (Oracle RAC) for both the primary and standby.
- Database service
The primary on-premises mid-tier should use an application database service to connect to the primary database.
- Oracle Cloud
Infrastructure (OCI) Database System
Use an OCI DB System, either bare metal or virtual machine, as the standby database. An Oracle Autonomous Database (ADB), either shared or dedicated, is out of the scope of this document. It does not provide a number of features required for the hybrid disaster recovery setup, such as the ability to configure Oracle Data Guard with an on-premises database, and snapshot standby conversion.
Considerations for Identity Management
Consider the following when configuring the Identity Management:
- Lightweight Directory Access Protocol (LDAP)
The system can use an external LDAP for authentication (for example, Oracle Unified Directory), as long as the external LDAP is reachable from both the primary and standby SOA systems.
- Disaster recovery solution for LDAP
The disaster recovery solution for any external LDAP service is out of the scope of this document, and it should be provided by the specific LDAP product. The DR solution for LDAP should provide a unique way to access to it (typically a virtual host name), that does not change when there's a switchover in the LDAP system.
About Required Services and Roles
This solution requires the following services and roles:
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: compartment, DB System, compute instances, FSS resources and Load Balancer. |
Network:
administrator
|
Configure the required network resources both in on-premises and OCI: Fast Connect, VCNs and subnets in OCI, network security rules and routing rules. |
Oracle Data Guard: root , oracle , and
sysdba |
Configure Oracle Data Guard between primary on-premises and standby OCI and perform role conversions. |
Oracle Database: sysdba |
Manage the databases. |
Oracle WebLogic Server: root ,
oracle |
Configure the mid-tier hosts as required: perform the OS level configuration, add host aliases, manage virtual IP addresses and mount file systems. |
Oracle WebLogic Server: Weblogic
Administrator |
Manage Oracle WebLogic Server: stop, start, and apply WebLogic configuration changes. |
See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.