1. Configure a hybrid DR solution for Oracle WebLogic Server
  2. Prepare the Web-tier on OCI

Prepare the Web-tier on OCI

Provision and configure your secondary site on Oracle Cloud Infrastructure (OCI) to be consistent with your primary on-premises site.

Note:

You can find Terraform code to create the resources described in this section (the OCI Load Balancer, the SSL certificate, the backend sets and backends, the routing policies, the listeners and the rule sets) in Download Code.

(Optional) Prepare the Oracle HTTP Server Hosts

Create and configure the Oracle HTTP Server compute instances in Oracle Cloud Infrastructure.

Note:

Creating and configuring Oracle HTTP Server is optional. You can configure the web-tier on OCI using only the OCI Load Balancer (without using Oracle HTTP Server).

Provision the Oracle HTTP Server Hosts

Create a compute instance on the Oracle Cloud Infrastructure (OCI) web-tier subnet for each primary, on-premises Oracle HTTP Server host. The compute instances must use the OS image and compute shape that are most similar to the image and shape used by the on-premises Oracle HTTP Server hosts.

Each Oracle HTTP Server running in OCI must have a valid License and support contract in addition to the License and support contract used to cover the Oracle HTTP Server running on-premises. You can use Oracle WebLogic Server for OCI images to create compute instances for Oracle HTTP Server on Oracle Cloud. The compute instances created with these images include the entitlement to run Oracle HTTP Server and are billed per OCPU/Hour for the entitlement to run WebLogic software when they are in running state. When creating the compute instances with Oracle WebLogic Server for OCI, you can use the Compute Instance Console or the Marketplace. These images are available for Oracle Linux 7.9 and Oracle Linux 8.5 operating systems.

This example uses two compute instances in a single availability domain within the compartment, as shown in the table.

Name Compartment Availability Domain Image Shape VCN Subnet
hydrohs1 HyDRCompmt AD1 Oracle WebLogic Enterprise Edition UCM Image (Oracle Linux 7.9) VM.Standard2.2 hydrvcn webTierSubnet
hydrohs2 HyDRCompmt AD1 Oracle WebLogic Enterprise Edition UCM Image (Oracle Linux 7.9) VM.Standard2.2 hydrvcn webTierSubnet

Perform the following to provision the compute instances using the Compute Instance Console:

  1. Log in to the OCI Console for your tenancy.
  2. Select the proper region.
  3. Click the navigation menu, select Compute. Click Instances, and then click Create Instance.
  4. Enter names for the compute instance and the compartment.
  5. Under Placement, select the Availability Domain in which to create the instance. If the OCI Region has more than one Availability Domain, then you can place the WebLogic compute instances in different Availability Domains.
  6. Under Image and Shape, click Change Image and perform the following:
    1. From the Image source drop-down list, select Oracle Images, and then select Oracle WebLogic Server Enterprise Edition UCM Image from the list of Oracle WebLogic Server for OCI images.
    2. For the selected image, click the arrow on the right, and then select the image build version for the paid images.
      • Oracle Linux 7.9 (labeled as release-ol7.9-build-timestamp)
      • Oracle Linux 8.5 (labeled as release-ol8.5-build-timestamp)
    3. Review the terms and conditions. Select the Oracle Terms of Use check box and click Select Image.
  7. Under Image and Shape, click Change Shape. Select the Instance Type and select the shape that is most similar to the primary hosts.
    See Images for Oracle WebLogic Server for OCI for a list of supported shapes.
  8. Select the VCN, subnet (web-tier subnet), and Availability Domain of your environment.
    To specify capacity type and fault domain, click Show advanced options.
  9. Configure the network for the instance. To specify advanced network settings, click Show advanced options.
  10. Under Add SSH keys, generate a key, upload your public key, or paste the keys.
  11. Under Boot Volume, specify the size and encryption options for the instance's boot volume.
  12. Click Show advanced options to configure advanced settings.
  13. Click Create.
  14. Repeat the steps to create another compute instance.

Prepare the Operating System Users and Groups

The same user and group used by the primary on-premises Oracle software are needed in the secondary compute instances.

Oracle WebLogic Server for Oracle Cloud Infrastructure images already have an oracle user and group. However, these values (user name, group name, uid, and gid) might not match the values that you have in your primary instance and you'll need to configure the secondary hosts to match the values of the primary oracle user and group. The following examples show how to configure the secondary hosts in this tier to match the values of the primary oracle user and group.

Each group and user in OCI compute instances must have the same ID on every node and the same as in the primary.
  1. Identify the user, group and IDs of the oracle user in the primary hosts by logging into an on-premises host with the oracle user, then use the command id.
    [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)

[oracle@host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
oracle:x:1001:1002::/home/oracle:/bin/bash

    The following table shows sample user and groups for a typical on-premises environment.

    User or Group Name ID Description
    User oracle 1001 The owner of Oracle software
    Groups oinstall 1002 Principal group of the oracle user
    dba 1001 Secondary group of the oracle user
  2. Identify the users, groups and IDs that exist in the secondary hosts by using SSH to access your recently created instance as the opc user. Log into a secondary hosts with the opc user, then sudo to oracle user and run the command id.
    [opc@hydrwls1 ~]$ sudo su - oracle
[oracle@hydrwls1 ~]$ id
uid=1001(oracle) gid=1001(oracle) groups=1001(oracle),1002(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    The following table shows the oracle user and group that already exist in the secondary compute instances.

    User or Group Name ID Description
    User oracle 1001 The owner of Oracle software
    Groups oracle 1001 Principal group of the oracle user
    docker 1002 Secondary group of the oracle user
  3. The following are possible scenarios and solutions:
    • The users and groups in secondary are different names and IDs than in primary.

      Solution: Create the users and groups in the secondary as they exist in the primary.

    • The users and groups in secondary are same names but different ids than in primary.

      Solution: Change the IDs in the secondary to match the IDs of primary.

    • The users and groups in the secondary are different names than those in the primary, but the same IDs.

      Solution: Change the names of the user and group in the secondary.

    • There are conflicts: some IDs of the primary user or groups are used by other users or groups in the secondary.

      Solution: Correct the conflict by changing the ID of the conflicting user or group in the secondary, and then create the user or groups in the secondary to match those that are in the primary.

    The following table is a summary of the commands that you can use to resolve conflicts:

    Action Command (run as root)
    To create a new group groupadd group_name -g group_id

    For example:

    groupadd oinstall -g 1002 groupadd dba -g 1001
    To create a new user useradd -u user_id user_name -g principal_group -G other groups

    For example:

    useradd -u 1001 oracleuser -g oinstall -G dba
    To change the primary group of the user usermod -g new_primary_groupname user_name
    To add a user to a group usermod -a -G secondary_groupname user_name
    To change the ID of a user

    usermod -u new_id user_name

    find / -user old_uid -exec chown -h user_name {} \;

    For example, the following changes the ID of the user oracle from 1001 to 501:

    usermod -u 501 oracle

    find / -user 1001 -exec chown -h oracle {} \;
    To change the ID of a group

    groupmod -g new_id group_name

    find / -group old_id -exec chgrp -h group_name {} \;

    For example, the following changes the ID of the group oracle from 1001 to 501:

    groupmod -g 501 oracle

    find / -user 1001 -exec chgrp -h oracle {} \;

    Note:

    Oracle recommends performing the changes in the secondary OCI compute instances. Do not modify the ID values in the primary.

    The following is an example where the IDs of the groups used in the primary hosts are already used by other groups in the secondary hosts. To resolve this conflict, the following actions are needed:

    1. The group docker in the secondary is using ID 1002, which conflicts with the ID of the primary group oinstall.
      To resolve the conflict, change the ID of the group docker in the secondary hosts to a different, non-conflicting ID. For example, select 1005 as the new ID and verify that it is not used by confirming that it does not appear in /etc/group file.
      [opc@hydrwls1 ~]$ sudo -s  
[root@hydrwls1 ~]$ more /etc/group | grep 1005
      When you confirm that the ID is not used, change the ID of the group to the new ID.
      [opc@hydrwls1 ~]$ sudo -s 
[root@hydrwls1 ~]$ groupmod -g 1005 docker
[root@hydrwls1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. The group oracle in the secondary uses ID 1001, which conflicts with the id of the primary group dba.
      To resolve the conflict, change the ID of the group oracle in the secondary hosts to a different, non-conflicting ID. For example, select 1006 as the new ID and verify that it is not used by confirming that it does not appear in /etc/group file.
      [opc@hydrwls1 ~]$ sudo -s 
[root@hydrwls1 ~]$ more /etc/group | grep 1006
      When you confirm that the ID is not used, change the ID of the group to the new ID.
      [opc@hydrwls1 ~]$ sudo -s 
[root@hydrwls1 ~]$ groupmod -g 1006 oracle
[root@hydrwls1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. Create oracle user’s groups oinstall and dba in the secondary hosts with the same IDs as the primary IDs. 
      [opc@hydrwls1 ~]$ sudo -s
[root@hydrwls1 ~]$ groupadd oinstall -g 1002
[root@hydrwls1 ~]$ groupadd dba -g 1001
    4. The user oracle has the same name and ID in both the primary and standby, so no changes are needed.
      However, you need to change the main group of the user to oinstall in the secondary hosts.
      [root@hydrwls1 ~]$ usermod -g oinstall oracle
      And then, add the user to the group dba. 
      [root@hydrwls1 ~]$ usermod -a -G dba oracle
    5. Confirm that the output of the command id for the oracle user in the secondary hosts matches the primary for the main and secondary groups.
      Output in the primary:
      [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
      Output in the secondary (the secondary can have additional groups):
      oracle@hydrwls1 ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
        …
    6. (Recommended) Perform a reboot of the host after these changes.
  4. (Optional, but recommended) Enable SSH access to the oracle user.
    It is useful in this DR topology because it enables the oracle user a direct connection to run the commands that are used to copy the file system contents from the primary to the secondary.
    1. Copy the public key that you use to connect to the compute instances to a text file. You'll use it later in this procedure.
    2. Log in to the instance and sudo to the root user.
    3. Create an .ssh directory in the new user's home directory.
      mkdir -p /home/oracle/.ssh
    4. Copy the SSH public key that you use to connect to the compute into the file.
      /home/oracle/.ssh/authorized_keys
    5. Change the owner and group of the /home/oracle/.ssh directory to the oracle user.
      chown -R oracle:oinstall /home/oracle/.ssh
    6. Verify the connection by connecting with SSH using the oracle user and your private key.
    7. Make the permissions of the authorized_keys file to be 600.
      chmod 600 /home/oracle/.ssh/authorized_keys

Prepare the Operating System Requirements

The Oracle HTTP Server binaries will be copied from the primary Oracle HTTP Server hosts to the secondary Oracle HTTP Server hosts. Therefore, it isn't necessary to run the runinstaller in the secondary hosts. Because the Oracle WebLogic Server for Oracle Cloud Infrastructure images are prepared for the WebLogic software, you do not need to manually add packages for WebLogic. However, these Oracle HTTP Server hosts will run the Oracle HTTP Server product. Make sure that the secondary hosts meet the requirements for Oracle HTTP Server.
  1. Ensure that your environment meets the minimum installation requirements for the products that are installed in primary hosts. Check the corresponding document in Oracle Fusion Middleware System Requirements and Specifications.
  2. Verify the required system packages for your version and OS.
  3. Install the missing system packages with yum.

    This example uses Oracle HTTP Server 12.2.1.4 and Oracle Linux 7. Some of the required packages are already installed in the Oracle Cloud Infrastructure (OCI) mid-tier compute instances. In this example, the following were missing and had to be installed using yum: 

    yum install compat-libcap1.x86_64
yum install compat-libstdc++-33.x86_64
yum install compat-libstdc++-33.i686 
yum install gcc-c++.x86_64
yum install libaio-devel.x86_64
yum install libstdc++.i686    
yum install libstdc++-devel.x86_64
yum install dejavu-serif-fonts
yum install numactl.x86_64
yum install numactl-devel.x86_64
yum install motif.x86_64
yum install motif-devel.x86_64
yum install redhat-lsb.x86_64
yum install xorg-x11-utils.x86_64
  4. Configure file and proc limits in the /etc/security/limits.conf file. Review the limits in your on-premises Oracle HTTP Server hosts and set the values in the OCI Oracle HTTP Server compute instances accordingly.

Prepare the Host Name Aliases for Oracle HTTP Server

Configure the same virtual host names that are used by the Oracle HTTP Server hosts in the primary environment as aliases in the secondary Oracle Cloud Infrastructure (OCI) Oracle HTTP Server compute instances, but point to the IP addresses of the secondary hosts.

This can be implemented in 2 ways:

  • Add the host names as aliases to the /etc/hosts files of the Oracle WebLogic Server for OCI compute instances.
  • Use a private DNS view in the secondary OCI VCN.
Use /etc/hosts Files
The virtual host names used as aliases in the primary servers are added to the /etc/hosts files of the secondary hosts, pointing to the IP addresses of the secondary hosts. This mode is valid in all scenarios when the DNS server is the same in the primary on-premises and on the secondary Oracle Cloud Infrastructure (OCI) sites, and also when separated DNS servers are used in the primary and secondary sites. The entries in the /etc/hosts file have precedence over the DNS resolution, because this is the precedence defined out-of-the-box in the directive “hosts” of the /etc/nsswitch.conf file.

However, this method requires that you manually add the entries to all of the Oracle HTTP Server hosts:

  1. Edit the /etc/oci-hostname.conf file of each Oracle HTTP Server compute instance and set the property PRESERVE_HOSTINFO=3 to preserve /etc/hosts entries across instance reboots.
  2. Use the command hostname --fqdn to identify the complete host names of the OCI compute instances.
  3. Add the following entries to the /etc/hosts file of the OCI Oracle HTTP Server compute instances:
    #################################
# ALIASES for WLS DR
#################################
# Aliases of the Oracle HTTP Server hosts
ohshost1_compute_instance_IP  ohshost1_fqdn  ohshost1_hostname    ALIASES_OF_WEBHOST1
ohshost2_compute_instance_IP  ohshost2_fqdn  ohshost2_hostname    ALIASES_OF_WEBHOST2
# The aliases for WebLogic
                                Server are added too
virtual_IP_for_admin          virtualIP_fqdn  virtualIP_hostname    ALIASES_OF_ADMINVHN
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname     ALIASES_OF_APPHOST1
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname     ALIASES_OF_APPHOST2

    Note:

    In addition to adding the virtual names of the Oracle HTTP Server hosts as aliases, the virtual names of the Oracle WebLogic Server hosts are added, pointing to the secondary WebLogic Server host's IPs. Because Oracle HTTP Server will communicate with the WebLogic Server hosts using their virtual hosts names.
    The following is an example of the /etc/hosts file in the secondary Oracle HTTP Server compute instance:
    #################################
# ALIASES for WLS DR - SECONDARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.60.10.11 hydrohs1.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs1    WEBHOST1.example.com WEBHOST1
100.60.10.12 hydrohs2.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs2    WEBHOST2.example.com WEBHOST2
# The aliases of the WLS hosts
100.70.10.20 hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com hydrwls-vip ADMINVHN.example.com ADMINVHN
100.70.10.13 hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com    hydrwls1    APPHOST1.example.com APPHOST1
100.70.10.14 hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com    hydrwls2    APPHOST2.example.com APPHOST2
    The following is an example of the existing /etc/hosts file of the primary Oracle HTTP Server hosts:
    #################################
# ALIASES for WLS DR - PRIMARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.10.10.11 host1.myopnetwork.com    host1    WEBHOST1.example.com WEBHOST1
100.10.10.12 host2.myopnetwork.com    host2    WEBHOST2.example.com WEBHOST2
# The aliases of the WebLogic
                                Server hosts
10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
10.10.10.13    host3.myopnetwork.com             host3           APPHOST1.example.com   APPHOST1
10.10.10.14    host4.myopnetwork.com             host4           APPHOST2.example.com   APPHOST2
Use the Domain Name System (DNS)
The virtual host names used by the primary Oracle HTTP Server hosts are added to the DNS resolver used by the VCN of the secondary Oracle HTTP Server hosts, pointing to the IP addresses of the secondary Oracle HTTP Server hosts. This mode is valid when separate DNS servers are used in the primary on-premises and the secondary on Oracle Cloud Infrastructure (OCI). Otherwise, it can cause conflicts in naming resolution. The server of each site should resolve these names with their own IPs.
The advantage of this method is that you can add all the entries to a private DNS view, instead of adding them to the /etc/hosts files of all of the hosts.

Add the entries for the Oracle HTTP Server virtual host names to the Private View created in OCI in the step Prepare the Mid-tier on OCI:

  1. In the OCI Console, go to secondary region and locate the private view:
    1. Click Networking, DNS Management, Private Views.
      For example, HYBRID_DR_VIRTUAL_HOSTNAMES
    2. In the private view, click the zone name that you created to add the virtual hosts.
      In this example: example.com.
    3. Add the Oracle HTTP Server virtual hosts names to this zone, but resolved with the secondary Oracle HTTP Server hosts’ IPs.

      You only need to provide the non-fqdn name in the OCI Console menu to add the record. The DNS domain of the zone is automatically added to the record.

    4. Click Publish changes.
  2. Validate the resolution SECONDARY hosts, by doing ping and nslookup of the added virtual host names.
    They must be resolved with the equivalent SECONDARY IPs.

Open the Required Ports in the OCI Host's Firewalls

Each compute instance has a local firewall service. For security reasons, the default configuration is to reject the connections for all the ports except the minimum required (ssh, dhcp). You must open the ports used by Oracle HTTP Server.
  1. Check the firewall service status and rules:
    bash-4.2# firewall-cmd --state
running
bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
    This output means that there are no ports opened other than 22.
  2. As the root user, use firewall-cmd commands to open the ports used as listen ports by Oracle HTTP Server in each Oracle HTTP Server compute instance.
    For example:
    firewall-cmd --permanent --add-port=7001/tcp 
firewall-cmd --permanent --add-port=8890/tcp 
service firewalld reload
  3. Check the firewall service status and rules:
    bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports: 7001/tcp 8890/tcp 8888/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Create the oracle User Environment Variables for Oracle HTTP Server

It's common to have Oracle HTTP Server-related environment variables in the oracle user’s profile in the Oracle HTTP Server hosts. For example, ORACLE_HOME, JDK_HOME, PATH, WEB_DOMAIN_HOME, and others.
  1. Review the oracle user’s profile files in the primary Oracle HTTP Server hosts.
  2. In secondary, add the same Oracle HTTP Server-related environment variables to the oracle user’s profile files (.bashrc, or .bash_profile).

    Note that the oracle user's .bashrc file in the Oracle HTTP Server hosts may already contain variables defined (MIDDLEWARE_HOME, WLS_HOME, and so on), but they'll probably be for your environment’s folders and are not valid for you. Make sure you remove or modify them accordingly to your environment folders.

Replicate the Oracle HTTP Server Product and Configuration from the Primary

Since the secondary Oracle HTTP Server OCI compute instances are created as the primary Oracle HTTP Server hosts (the same OS, user ids, host name aliases, and so on), you can use rsync to copy the binaries and Oracle HTTP Server configuration from the primary Oracle HTTP Server nodes.

Alternatively, you can download the Oracle HTTP Server software, install and configure it from zero in the OCI Oracle HTTP Server compute instances. This approach is out of the scope of this document. However, you must use this approach when the Oracle HTTP Server OCI compute instances have a different operating system than the primary Oracle HTTP Server hosts.

Oracle HTTP Server binaries and configuration files normally reside in private storage. In OCI, you can use the block volume that the compute instance has by default. Alternatively, you can create a new block volume for each Oracle HTTP Server compute (as described in the Prepare the OCI Block Volumes), and mount each one in the Oracle HTTP Server compute instances (as described in Mount the OCI Block Volumes).

This example uses the default block volume of the Oracle HTTP Server compute instances without creating any additional block volumes.

  1. Identify the folders of the Oracle HTTP Server binaries and configuration in the primary Oracle HTTP Server nodes.
    For example:
  2. Create the same folders in the OCI Oracle HTTP Server compute instances. You must use same path that is used in primary.
    1. SSH to the OS compute instances and sudo to root user.
    2. Create the folders and make oracle the owner.
      For example:
      bash-4.2# mkdir -p /u02/oracle/products/ohs_12214
bash-4.2# mkdir -p /u02/oracle/config/ohsdomain_12214
bash-4.2# chown -R oracle:oinstall /u02
    3. Repeat for each Oracle HTTP Server OCI compute instance.
  3. Use rsync to copy the products folder from the on-premises primary WEBHOST1 to the remote WEBHOST1. Repeat the step to copy the products folder from WEBHOST2 to remote WEBHOST2. And, repeat this step for any other Oracle HTTP Server compute instances.

    Note:

    There's an example script that you can use to copy the Oracle HTTP Server products folder from the on-premises primary WEBHOST1 to the remote WEBHOST1.

    Go to Download Code to download the script.

  4. Use rsync to copy the Oracle HTTP Server configuration folder from the on-premises primary WEBHOST1 to the remote WEBHOST1. Repeat the step to copy the configuration folder from WEBHOST2 to remote WEBHOST2. And, repeat this step for any other Oracle HTTP Server compute instances.

    Note:

    There's an example script that you can use to copy the Oracle HTTP Server configuration folder from the on-premises primary WEBHOST1 to the remote WEBHOST1.

    Go to Download Code to download the script.

  5. Copy the /etc/oraInst.loc file from the primary Oracle HTTP Server hosts and save it to the secondary hosts.
    This file just contains the location of oraInventory and does not change over time, so this copy is a one-time action.
  6. If the oraInventory folder is under the products folder, then it's copied along with Oracle HTTP Server Oracle home. If your oraInventory folder is in a different location, then ensure that you also copy it to the secondary hosts.

The Oracle HTTP Server configuration and binaries do not change frequently overtime. After this initial replication, you can repeat the same replication during the lifecycle. Alternatively, you can manually maintain the configuration of the Oracle HTTP Server in the primary and secondary by implementing the Oracle HTTP Server configuration changes in both sites.

Prepare OCI Load Balancer

Create and configure the Oracle Cloud Infrastructure Load Balancer on the cloud.

Note:

You can find Terraform code to create the resources described in this section (the OCI Load Balancer, the SSL certificate, the backend sets and backends, the routing policies, the listeners and the rule sets) in Download Code.

Provision the OCI Load Balancer

To be consistent with the primary on-premises site, provision a load balancer on your secondary site on Oracle Cloud Infrastructure (OCI) as the entry point to the system.

  1. Log into the OCI Console.
  2. Select the proper region and compartment.
  3. Navigate to Networking, then Load Balancers. Click Create Load Balancer.
  4. Select Load Balancer type.
  5. Provide a name for the load balancer.
    For example: hyDRlbr.
  6. Choose the visibility type (public or private) and the bandwidth that match your needs.
    • If your system is accessed from external clients through the internet, then choose public visibility. The OCI load balancer will use a public IP.
    • If your system is accessed from clients internally only, then you can choose private visibility to provision the load balancer with a private IP only.
  7. Select the appropriate VCN and subnet.
    For example, hydrvcn and webTierSubnet.
  8. Do not add any back end at this point.
  9. Leave the default listener with default values
  10. Click Submit.
Save the IP of the OCI Load Balancer (for example 100.100.100.10).

Upload the Certificates

Upload the certificates used by the primary load balancer.

  1. In the Console, click the Load Balancer, Certificates, then Add Certificate.
  2. Upload the public SSL cert and private key of the certificate that the primary Load Balancer uses. Upload CA (certificate authority) certificates, if used.
  3. Enter a name for the certificate, then click Add Certificate.
    The new certificate appears in the list of certificates for the Load Balancer.
  4. If you use more than one certificate to access the primary system, then repeat these steps to upload all certificates.

Create the Backend Sets

A backend set is a logical entity that contains a list of backend servers that run the same applications. When you define a backend set, you must specify a load balancing policy and a health check test. Then you can add the list of backend servers.

The configuration of the backend sets depends on whether or not you're using Oracle HTTP Server in front of the WebLogic Server hosts.

If you're using Oracle HTTP Server, then the Oracle Cloud Infrastructure (OCI) Load Balancer sends the requests to the HTTPS servers. Create a backend set for each port exposed by the HTTPS servers. For example: create one backend set for the Oracle HTTP Server listener that provides access to the applications, and another backend set for the Oracle HTTP Server listener that provides access to each Oracle WebLogic Server Administration Console.

If you're not using Oracle HTTP Server, then the OCI Load Balancer sends the requests to the WebLogic servers directly. Create a backend set for each Oracle WebLogic Server Cluster and another backend set for the Admin Server.

  1. Log into the OCI Console.
  2. Select the proper region and compartment.
  3. In the navigation menu, click Networking, and then click Load Balancers.
  4. Click the load balancer to which you want to add a backend.
  5. Click Backend Sets under the Resources menu, then click Create Backend Set.
  6. Enter the following in the Create Backend Set dialog box:
    1. Name: Specify a name for the backend set.
      Valid backend set names include only alphanumeric characters, dashes, and underscores.
    2. Traffic Distribution policy: Select Weighted Round Robin.
    3. Session Persistence: Select Enable load balancer cookie persistence.
    4. Cookie Name: Enter a name for the cookie used to enable session persistence.
    5. Attributes: Select Secure.
    6. Health Check: Select TCP to check the port or HTTP to check to the URL path (URI) and the expected answer code.
      The following are HTTP examples for Health Check:
      • OHS_Admin_backendset: URL Path /console, Status Code 302
      • OHS_HTTP_backendset:
        • URL Path /, Status Code 200 (or 404, depending on the Oracle HTTP Server configuration)
        • URL Path /app1, Status Code 200
  7. Click Create.

If you have additional WebLogic Server clusters, create a backend set for each cluster in a similar way.

The following is an example of the backend sets when you use Oracle HTTPS Server with Oracle WebLogic Server.

Component Backend Set Name Traffic Distribution Policy Session Persistence Cookie name (example) Attribute: secure Health Check
Admin Server OHS_Admin_backendset Weighted Round Robin Enable load balancer cookie persistence X-Oracle-LBR-ADMIN-Backendset Unchecked TCP or HTTP
WebLogic Clusters OHS_HTTP_backendset Weighted Round Robin Enable load balancer cookie persistence X-Oracle-LBR-OHS-HTTP-Backendset Checked TCP or HTTP

The following is an example of the backend sets when you do not use Oracle HTTP Server.

Component Backend Set Name Traffic Distribution Policy Session Persistence Cookie name (example) Attribute: secure Health Check
Admin Server Admin_backendset Weighted Round Robin Enable load balancer cookie persistence X-Oracle-LBR-ADMIN-Backendset Unchecked TCP or HTTP
WebLogic Cluster 1 WLS_Cluster1_backendset Weighted Round Robin Enable load balancer cookie persistence X-Oracle-LBR-WLSCluster1-Backendset Checked TCP or HTTP
WebLogic Cluster 2 WLS_Cluster2_backendset Weighted Round Robin Enable load balancer cookie persistence X-Oracle-LBR-WLSCluster2-Backendset Checked TCP or HTTP

If your have additional WebLogic clusters, create a backend set for each cluster in a similar way.

Define the Backends for Each Backend Set

Define the backends for each backend set in the Oracle Cloud Infrastructure (OCI) Load Balancer.

If you are using Oracle HTTP Server, then add the Oracle HTTP Server nodes and appropriate ports as backends in each backend set.

If you are not using Oracle HTTP Server, then add the Oracle WebLogic Server nodes and appropriate ports as backends in each backend set.

  1. In the Console, select a Backend Set. Click Backends, then click Add Backends.
  2. Enter the IP address and port for the server that is the backend.
The table shows the backend sets created in the example of this document when using Oracle HTTP Server:
Backend Set Name Backends
OHS_Admin_backendset Compute Instances:
  • hydrohs1, the Oracle HTTP Server port for the consoles listener (such as 7001)
  • hydrohs2, the Oracle HTTP Server port for the consoles listener (such as 7001)
OHS_HTTP_backendset Compute Instances:
  • hydrohs1, the Oracle HTTP Server port for the HTTP listener (such as 8890)
  • hydrohs2, the Oracle HTTP Server port for the HTTP listener (such as 8890)

The table shows the backend sets created in the example of this document when NOT using Oracle HTTP Server:

Backend Set Name Backends
Admin_backendset IP Addresses:
  • The Admin server virtual IP created previously, Admin server port (7001)
WLSCluster1_backendset Compute Instances:
  • hydrwls1, WLS Cluster 1 server 1 port (8001)
  • hydrwls2, WLS Cluster 1 server 1 port (8001)
WLSCluster2_backendset Compute Instances:
  • hydrwls1, WLS Cluster 2 server 1 port (9001)
  • hydrwls2, WLS Cluster 2 server 2 port (9001)

Define the Routing Policies and Configure the Rules

The routing policies are used to dispatch the incoming requests to the correct backend set. For example, a request to /console is dispatched to the Admin backend set, and a request to the /app1 is dispatched to the backend set of the Cluster where app1 is running.

If you are using Oracle HTTP Server, then you normally define the routes (such as /app1, /app2, /console, and so on) in the Oracle HTTP Server configuration. In this case, you don’t need to define the routing policies and rules in the Oracle Cloud Infrastructure (OCI) Load Balancer.

If you are not using Oracle HTTP Server, then you need to define the routing policies and rules in the OCI Load Balancer, to dispatch the requests to the appropriate backend set.

  1. In the Oracle Cloud Infrastructure Console, click the Load Balancer.
  2. Click Routing Policies, then click Create Routing Policies to define the policies.
    The routing policies are added to the Load Balancer listeners later.
  3. Enter a name for the routing policy (set of rules).
    For example, Admin_Rules.
  4. To create rules in the route policy, enter a name for the rule.
    For example, Admin_routerule.
  5. Define the rule conditions to route requests to different backend sets. Select If Any Match, then select Condition Type: Path, select Operator: Starts With, and enter a URL String.
    For example, If Any Match, Path, Starts With, /console.
  6. Select the Backend Set from the menu to configure the action.
    For example, OHS_Admin_backendset.
The table shows the routing policies and rules in the Oracle Cloud Infrastructure Load Balancer created following the example in this document when Oracle HTTP Server is not used.
Component Routing Policy Name Rule Conditions: If Any Match Path starts with Action: Route to Backend Set
Administration server consoles Admin_Rules Admin_routerule

/console

/em

 Admin_backendset
Application 1 Application_Rules WLSCluster1_routerule

/app1

 WLSCluster1_backendset
Application 2 Application_Rules WLSCluster2_routerule

/app1

 WLSCluster2_backendset

You can create as many routing policies, rules and conditions as you need for your environment.

Create the Listeners

Create the listeners for each combination of front-end name and port that is used to access the system. You must use the same host names (virtual front-end names) and ports that are used by the primary load balancer.

  1. Add the virtual front-end host name as host name in the Oracle Cloud Infrastructure Load Balancer.
  2. Create the listeners.

The following table is a summary of the listeners created in the example of this document, and their associated protocol, port, backend sets, routing policy, host name, and SSL usage. This is just as a reference example. If your system uses additional front-end host names, ports, or protocols in the primary Oracle WebLogic Server system, then you must create the corresponding listeners and host names according to your needs. For example, if you use an alternate front-end to access the Oracle WebLogic Server Console and Oracle Enterprise Manager Console.

Listener Protocol Port Backend Set Routing Policy HostName Use SSL
Admin_listener HTTP 7001

OHS_Admin_backendset (if Oracle HTTP Server is used)

Admin_backendset (if Oracle HTTP Server isn't used)

Admin_Rules wlsfrontend.example.com No
HTTPS_listener HTTPS 443

OHS_HTTP_backendset (if Oracle HTTP Server is used)

WLSCluster1_routerule (if Oracle HTTP Server isn't used)

App_Rules wlsfrontend.example.com Yes
HTTP_listener HTTP 80 N/A* N/A wlsfrontend.example.com No

* The HTTP_listener in this example is used only for redirecting requests to the HTTPS_listener (HTTPS). The backend assigned to it will not be used. But, since it is mandatory to provide one, you need to provide one that has no SSL checked (use a default empty backend set).

Create the Rule Set for SSL Headers

Create a rule set for SSL headers in the Oracle Cloud Infrastructure (OCI) Load Balancer and associate it to the HTTPS listener.

Just as in the primary site, the OCI Load Balancer terminates SSL and the communication between the Load Balancer and the back end server is performed over HTTP protocol. For this to work properly, you must add request headers in the OCI Load Balancer. These headers are added to the client requests that come to the HTTPS listener, before being dispatched to the WebLogic back end. The headers inform WebLogic that the communication from the end client to the Load Balancer used HTTPS. That way, any URL that WebLogic constructs dynamically will be correctly generated using HTTPS.
  1. Select the Load Balancer in the Console. Click Rule Sets, then Create Rule Set.
  2. Provide a name for the rule.
    For example, SSLHeaders.
  3. Check Specify Request Header Rules and add the following actions:
    Action Header Value
    Add Request Header is_ssl ssl
    Add Request Header WL-Proxy-SSL True
  4. Click Create.
  5. Click Load Balancer, then click Listener. Edit the listener that use HTTPS to associate the rule to the HTTPS listener.
  6. Click +Additional Rule Set, then select the rule set SSLHeaders.

Create the Rule Set to Redirect the HTTP Protocol to HTTPS

Create a redirect rule and associate it with the HTTP_listener to redirect port 80 to port 443. For the EDG topology, all requests that reach port 80 (HTTP) in the Load Balancer must be redirected to port 443 (HTTPS).

  1. In the Console, select the Load Balancer.
  2. Click Rule Sets, then Create Rule Set.
  3. Enter a name for the rule.
    For example, HTTP_to_HTTPS_redirect.
  4. Check Specify URL Redirect Rules and add the following actions
    • Source path: /
    • Match Type: Force Longest Prefix Match
    • Redirect to:
    • Protocol: HTTPS
    • Host: {host} (leave the default value)
    • Port: 443
    • Path: /{path} (leave the default value)
    • Query: ?{query} (leave the default value)
    • Response Code: 301 – Moved Permanently
  5. Click Load Balancer, then Listener. Edit the listener that uses HTTP port 80 to associate it to the HTTP listener.
  6. Click +Additional Rule Set and select the rule HTTP_to_HTTPS_redirect.

Add the Virtual Front-end Name and IP to the WLS Compute Instances

In a disaster recovery topology, the clients must access the system using a front-end FQDN (usually referred to as virtual front-end name or vanity URL) that is agnostic to the data center. This virtual front-end name should resolve to the Load Balancer IP address of the current active (primary) site.

The primary system should already be using a front-end virtual name that is resolved by the DNS with the IP of the primary Load Balancer. However, the Oracle WebLogic Server hosts of each site should always resolve the front-end name with its local load balancer, regardless of client-facing resolution with DNS. For this, the virtual front-end name is added to their /etc/hosts file with the appropriate IP address in each site. You can also achieve this by using different DNS servers in each site. In that case, the local DNS server would resolve the front-end name with the appropriate load balancer IP in each site.

Use /etc/hosts Files
The /etc/hosts file of the primary and secondary Oracle WebLogic Server hosts must not be altered when there is a switchover or failover. The Oracle WebLogic Server hosts will always resolve the virtual front-end name with its front-end IP. The DNS update that is needed during the switchover and failover procedures is performed in the DNS or host files used by the Oracle WebLogic Server clients.
  1. As root user, edit the /etc/oci-hostname.conf file in the secondary Oracle WebLogic Server for Oracle Cloud Infrastructure compute instances and map the front-end name to the Oracle Cloud Infrastructure (OCI) Load Balancer IP.

    The following is an example of the /etc/hosts file of the secondary Oracle WebLogic Server for OCI compute instance, including the entry for the front-end name. 

    #################################
# ALIASES in OCI 
#################################
100.70.10.20   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com      hydrwls-vip       ADMINVHN.example.com    ADMINVHN    
100.70.10.13   hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com         hydrwls1          APPHOST1.example.com    APPHOST1
100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com         hydrwls2          APPHOST2.example.com    APPHOST2

# Front-end name (resolved to secondary OCI LBR IP)
100.100.100.10    wlsfrontend.example.com
  2. If it is not already done, then follow the same steps in the primary Oracle WebLogic Server hosts. The front-end name must point to the primary load balancer IP.
    The following is an example of the /etc/hosts file of the primary, on-premises Oracle WebLogic Server host, including the entry for the front-end name. 
    #################################
# ALIASES in on-prem 
#################################
10.10.10.20   host-vip1.myopnetwork.com    host-vip1         ADMINVHN.example.com   ADMINVHN    
10.10.10.13   host3.myopnnetwork.com       host3             APPHOST1.example.com   APPHOST1
10.10.10.14   host4.myopnnetwork.com       host4             APPHOST2.example.com   APPHOST2

# Front-end name (resolved to primary Load Balancer IP)
10.10.10.100    wlsfrontend.example.com
  3. If your Oracle WebLogic Server system uses more virtual front-end names, then add them to the file following the same rule.
Use the Domain Name System (DNS)
This mode is valid when separated DNS servers are used in primary on-premises and the secondary on Oracle Cloud Infrastructure (OCI). Otherwise, it can cause conflicts in naming resolution.

If you are following this approach, you can add the front-end name (pointing to the secondary load balancer IP) to the DNS service used by the secondary mid-tiers. In primary, it is expected that the front-end name is already resolved pointing to the primary load balancer IP.

In the primary, it is expected that the front-end name is already resolved pointing to the primary load balancer IP.