Configure a Hybrid DR Solution for Oracle SOA Suite

To ensure business continuity in the event of disasters, you'll want to implement a disaster recovery (DR) strategy for your on-premises Oracle SOA Suite that provides data protection and enables you to quickly switch to the standby system with minimal loss of data and productivity. This solution shows how to configure a hybrid DR strategy for an existing SOA system that is on-premises and the standby system is on Oracle Cloud Infrastructure (OCI). With the help of Oracle Data Guard, this DR solution provides a highly available, secure, and scalable infrastructure and services that enable you to recover from disasters reliably and securely.

Before You Begin

The enterprise deployment topology used here is an Oracle SOA Suite EDG 12.2.1.4 environment, based on the Enterprise Deployment Guide (EDG). It's considered the best reference example of a primary system for a Hybrid DR solution for SOA. Before you begin deploying a hybrid system, ensure that you're familiar with the network, storage, and host set up best practices detailed in the Enterprise Deployment Guide for Oracle SOA Suite (EDG).

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

This architecture shows the primary data center environment on-premises with a standby system on Oracle Cloud. Use this architecture for a hybrid DR solution for your on-premises Oracle SOA Suite environment.

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

maa-soa-hybrid-dr-oracle.zip

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

The Oracle SOA Suite hybrid DR topology uses an active-passive model. The primary system is an on-premises data center, and a secondary system in Oracle Cloud Infrastructure (OCI). The on-premises and OCI networks are interconnected with Oracle Cloud Infrastructure FastConnect.

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 as osb.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.

Acknowledgements

• Authors: Iratxe Etxebarria, Fermin Castro Alonso