1. INTRODUCTION.-

For many years, Disaster Recovery (DR) has been a critical requirement for Oracle WebLogic Server customers. Hybrid DR strategies deliver low-cost disaster protection by using a secondary system on Oracle’s Cloud Infrastructure (OCI). This hybrid strategy is really attractive because it provides an entry point to Oracle’s Cloud, enabling users to test and get familiar with the behavior of WebLogic domains on OCI. This type of disaster protection provides a bridge to OCI adoption while granting availability during planned and unplanned downtime for on-premises production systems. The new Oracle WebLogic Hybrid DR framework (WLS_HYDR) automates the setup of this type of topologies. It creates a mirrored secondary in OCI for an existing WebLogic system. The framework implements Maximum Availability Architecture (MAA) best practices automatically and creates mirrored-sites for WebLogic systems including, not only the WebLogic domain itself, but also the Oracle HTTP Servers (OHS), Load Balancer, hardware and storage associated with that WebLogic Domain.

2. KEY FEATURES OF THE WLS_HYDR FRAMEWORK

The WLS_HYDR framework is opensource. You can download it from https://github.com/oracle-samples/maa/tree/main/wls-hydr. You can customize it and adjust it to your needs. It connects to your primary system (in full connection mode) or uses a backup of your WebLogic system (in disconnected mode), to analyze that primary. It then asks you to make some choices on where/how to create the secondary and once it has gathered all the required data, it starts creating compute instances, storage, subnets and all the OCI artifacts required to create a mirror of your primary. It then replicates all the Oracle Homes and configuration involved in the topology using rsync over ssh in an advanced mode that assures an exact and reliable replica of your primary. In less than an hour (using as an example a large/complex FMW SOA system) it creates a precise copy of your primary ready to take over in the event of downtime in that location. Not only it prepares your system for disasters, but it also gives you a test bed to validate production workloads exactly as you would run them in your production site.

Hybrid DR Framework

The WLS_HYDR framework reduces a process that typically takes a day (and involves many error pron tasks) to just a  few minutes. What makes it even more appealing is that it does not manipulate the configuration from primary to “make it work” in OCI. It virtualizes all the WebLogic listen addresses using OCI DNS private views so that the same deployment scripts, pipelines, etc can be used “as they are” in primary without modifications. This simplifies administration and management overhead tremendously. On top of this, WLS_HYDR keeps record of all the resources it creates and includes a cleanup utility that allows you to remove all the OCI artifacts used in a secondary in no time. This makes it really easy to run a quick test of WLS_HYDR with very low risk !

Benefits of the Hybrid DR Framework

 

3. HOW TO USE THE WLS_HYDR FRAMEWORK

You can use the WLS_HYDR framework in two main ways. Each one adjusts to different cost, Recovery Time Objective (RTO) and Recovery Point Objective (RPO) needs:

  • COMPLETE DR SETUP: The Maximum Availability Architecture “Gold” solution involves setting up continuous/private connectivity between your primary system and OCI. This is typically done with a VPN or using Fast Connect. Setting up that connectivity is out of the scope of the WLS_HYDR framework. In this scenario, WLS_HYDR connects to you primary to discover information about the WLS domain, ports, OHS configuration, front-end address and hardware capacity among other things. Once the secondary is created it is expected that continuous replication of the Database will happen with Oracle Data Guard and periodic replication of changes in the middle tier (both configuration and binaries/patches) is performed through the same Fast connect or VPN link. 
  • BACKUP AND RESTORE TO OCI: In this case, a WLS domain is restored (or migrated) to OCI from a backup. In this scenario, continuous connectivity between the primary data center and OCI is NOT needed. You upload the binary and configuration contents from primary to OCI through scp or Object Storage on a regular basis. The OCI resources are created based on this backup and the required input properties provided in the WLS_HYDR configuration files. The RTO and RPO of this solution is obviously worse than in the “COMPLETE DR SETUP” case.

In both scenarios, WLS_HYDR needs a pre-existing compute instance in OCI to run its scripts. This would typically be the bastion host that will be used to connect and manage the WLS, OHS nodes etc once the secondary system is in use. This bastion will act as the orchestrator for the different WLS_HYDR operations. Download the framework to this bastion (git clone https://github.com/oracle-samples/maa/) and make sure that the node has the required OCI and python configuration (you can refer to the WLS_HYDR README for details on this).

You will need to provide the framework with basic information about primary whether you are running a COMPLETE DR SETUP or a RESTORE TO OCI:

  • Edit the prem.env file to list nodes and users in the primary system.

  • Edit the replication.properties file to identify the primary system’s Oracle Homes and WLS domain.

  • Transfer the sysconfig_discovery.xlsx file to a Windows node to facilitate its edition. This file is used to provide properties and customization for the resources that will be created in OCI: Fill in the entries in the excel files marked as “needs custom input”. The entries marked as “default value can be used” can be customized or left in their default value.

  • Once edited, save the excel as a CSV (Comma delimited) file format and upload it to the bastion again. 

To execute the “COMPLETE DR SETUP” setup run the wls_full_setup.py script indicating the sysconfig file that will be used (the csv file created in previous steps).

For example : wls_full_setup.py -i sysconfig_discovery.csv

To execute the “BACKUP AND RESTORE TO OCI” setup you need an additional step which involves making your backup available in the bastion host in a precise directory structure

  • Create the folder structure for your backup in the bastion using the DataReplication.py init command:
    DataReplication.py init -w <nº wls nodes> -o <nº ohs nodes>
    This will create the required directory structure to place contents from primary

  • Manually upload the contents from the primary system to these folders. Read the file README_FOR_MANUAL_COPY.txt in the stage folder for details about how to copy each item.

  • Run the wls_full_setup.py script indicating the sysconfig file that will be used (the csv file created in previous steps) and using the -n option to indicate that there is no connectivity to primary.

  • For example:  wls_full_setup.py -i sysconfig_discovery.csv -n

Wait for the magic to happen and… voilá! you should have your secondary created with your entire WLS domain system ready to be used in OCI! If you need details about each step and how to customize the WLS_HYDR configuration for each use case, you can use these videos:

If your WebLogic domain is using an Oracle Database for runtime data or for metadata (like in the case of WLS JRF domains, FMW SOA or other FMW components), you can use the utilities that the MAA team provides to replicate it to secondary also

4. CONCLUSION

Protecting Oracle WebLogic systems from disasters is critical to most business applications. Oracle Cloud Infrastructure provides an ideal resilient and low cost environment to configure secondary systems that can overtake workloads should a disaster affect a primary location. WLS_HYDR is an opensource framework that automates the setup of a secondary topology in OCI while implementing MAA best practices. By “virtualizing” the primary resources in OCI it reduces the management overhead typically inherent to secondary systems.

5. ADDITIONAL INFORMATION